From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 04:59:47 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8EF5106564A for ; Sun, 13 May 2012 04:59:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E8198FC0A for ; Sun, 13 May 2012 04:59:47 +0000 (UTC) Received: by werg1 with SMTP id g1so2368734wer.13 for ; Sat, 12 May 2012 21: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:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=lQIXIxB1We3hi3/BXAm0nhAVm35NbzCnHe17nUddVws=; b=nZKV8FjgmV2c7iuCZ88kPisjO+lwik4gz8rMz/dR+JLK5rxu8k3kZ5NzBthcwDTzRL CTJZUH2PH8IFV1Sgk2MCPmWQAC9Ms0WBnHot2of5+Pie+yz5O3N3JptKl1OPjCnISe/9 NE6eggRMON6Yxu7HXbsysgTNiHu71yuxZ+3dXEQoiSf62OPJeYxVWaxOflc6KfKUUcVj RDZlp7sepjdPJCUI2ifUxY+DJpj08FtEput2NdIpp3QxmyceCZBLpXaemaRDotBFti7C oi6ZfMAG984SR8OsVV3fd649rjPyYLDoZs7L/ieVF0BRJSsPqKfybqcg82h4blFTqXB/ CdTA== MIME-Version: 1.0 Received: by 10.180.76.232 with SMTP id n8mr8953053wiw.2.1336885186359; Sat, 12 May 2012 21:59:46 -0700 (PDT) Received: by 10.216.163.136 with HTTP; Sat, 12 May 2012 21:59:46 -0700 (PDT) In-Reply-To: References: <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> <20120512073446.GM71676@acme.spoerlein.net> Date: Sun, 13 May 2012 00:59:46 -0400 Message-ID: From: Arnaud Lacombe To: Arnaud Lacombe , hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 04:59:48 -0000 Hi, On Sat, May 12, 2012 at 10:27 AM, Arnaud Lacombe wrote= : > Hi, > > On Sat, May 12, 2012 at 3:34 AM, Ulrich Sp=F6rlein wr= ote: >> On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Sp=F6rlein = wrote: >>> > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >>> >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein wrote: >>> >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >>> >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe wrote: >>> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on = the github tree ? >>> >> >> > >>> >> >> Ulrich, ping ? >>> >> > >>> >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to my >>> >> > attention. I missed the push --all flag. :/ >>> >> > >>> >> FWIW, the github mirror[0] of the completed SVN tree has not seen an= y >>> >> upgrade for a week now. Did some script broke ? >>> >> >>> >> Thanks, >>> >> =A0- Arnaud >>> >> >>> >> [0]: https://github.com/freebsd/freebsd >>> > >>> > Yeah, sorry about that. Monitoring is not that great, so you should >>> > always ping me directly. >>> > >>> > The problem is that people dump files at random places in the Subvers= ion >>> > tree and that cannot easily be translated to branches. This time it w= as >>> > /vendor/flex/FreeBSD-Xlist >>> > >>> It would seem the full SVN mirror on github is out-of-sync again, at >>> least, the `user/imp/extern_cc' is missing. >> >> user/ isn't pushed to github (and I consider also not pushing projects/ >> into it), as their webfrontend often craps out with too many branches. >> >> You can get it from git.freebsd.org directly. >> > ok, there seem to be a valid repository at > `git://git.freebsd.org/freebsd'. It might take some time to clone it > from BSDCan, so I'll wait to be back to base to clone. It sounds I'll > need to re-export/re-import all my branches.. again > ok, that repository looks complete... the drawback of using it is that I'll lost the possibility to share anything on github or gitorious... Could it be thought to have all git mirror around (gitorious, github, your.org, ...), to actually be simple clone of this specific repository, to be able to facilitate code sharing among them ?? Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 07:24:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5B0B1065670; Sun, 13 May 2012 07:24:46 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 6F81B8FC08; Sun, 13 May 2012 07:24:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4D7HLRv079525; Sun, 13 May 2012 07:17:21 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id af4meg9v63azpsdbvu9kdk27tn; Sun, 13 May 2012 07:17:21 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sun, 13 May 2012 00:17:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 07:24:46 -0000 On May 12, 2012, at 4:36 PM, Tim Kientzle wrote: >=20 > On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >=20 >> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>=20 >>> On the AM3358, the DRAM starts at 0x8000 0000 >>> on boot, so I'm trying to find a clean way to convince >>> the loader's ELF code to put the kernel there. >>=20 >> Look at what I did for ia64. All that frobbing should be done >> in the machine specific implementation of arch_copyin, arch_copyout >> and arch_readin. It's a kluge to do it in elf_loadimage. >=20 > That sounds like a reasonable approach. I've started > working down that path=85 but it looks like I'll have to fix > a lot of the FDT code along the way. I'm getting close. In particular, I've reworked the FDT code so that it correctly uses copyout() to parse data in the kernel. Of course, in order to use libfdt to actually manipulate the device tree, I have to copyout() the entire blob into a malloc'ed buffer. So now I need to understand how to copyin() the blob back into the kernel address space. Should I overwrite the FDT in the kernel with the edited FDT? That doesn't feel quite right, but it's essentially what the FDT code here was trying to do before. I could also implement something similar to file_loadraw() that would allow me to create a new module from an in-memory buffer. I think that might be a little cleaner. Is there already something like this? Tim From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 12:09:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26020106564A for ; Sun, 13 May 2012 12:09:51 +0000 (UTC) (envelope-from willingbug@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2F3A8FC08 for ; Sun, 13 May 2012 12:09:50 +0000 (UTC) Received: by obcni5 with SMTP id ni5so7853367obc.13 for ; Sun, 13 May 2012 05:09:50 -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=4y+5qElIZG+57O4Ow49czPFwzfMwweD/+96auzHillw=; b=V9LNSfdIfJig7jUFTlKBqCXg/YBnb7DUsiUCWq5IagLJZGhezk99KVh8XUtZ1o9XCz RTHxmyEplYkucFnDkshQpvyhd31lGIv7Cw1k2tz4vq0gesClt16OpVPE5tt2dVS5AvHe l7tFukKAkNAXR/HYmqISbaXyAOxxMS/Ae5tX+Fv9CjxNZgS6gsdX2Lm2obdQ8jkCMpw+ POePoPfhHcSord38yL5vx9pBJv7ENPIcXH+mQTp8zoC/HnPt8Rc1PcnI9ocSbjGIr4S1 jPrh0/LYvGcgqGJdWkluUBCp7+sYGyu+I51UHL74oTxiXiw9QYGqYIqsp1wYoM4DyQga 1rkQ== MIME-Version: 1.0 Received: by 10.182.131.7 with SMTP id oi7mr6356185obb.74.1336910990532; Sun, 13 May 2012 05:09:50 -0700 (PDT) Received: by 10.182.52.167 with HTTP; Sun, 13 May 2012 05:09:50 -0700 (PDT) Date: Sun, 13 May 2012 20:09:50 +0800 Message-ID: From: cz li To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 12:09:51 -0000 I installed FreeBSD9.0 to IBM R51.Gnome startup black screen, only to restart.My graphics card is "82852/855GM Integrated Graphics Device".Is there any solution?Can you give me a detailed step=EF=BC=9F =E3=80=80 Thank you! chao zhong li 2.12/5/13 From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 16:37:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B88EE106566C for ; Sun, 13 May 2012 16:37:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 722F08FC0C for ; Sun, 13 May 2012 16:37:22 +0000 (UTC) Received: by vbmv11 with SMTP id v11so5691094vbm.13 for ; Sun, 13 May 2012 09:37: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:content-transfer-encoding; bh=ixj5C5Gem1hBn+7vRx1t4NZMws5gzgsBr6AqXLJiavw=; b=xg2KUpOPKqtBhl9aX8DNrkZ70mMDsgqczoCyvt5/k0sN+gRpCybKNMJ/ruOU76OlBD cBrbOx/0+8mP1N2Uw2SI7fX6K5RpjR9jshUq++BXA/rJZKTiZAS6yr73+tXSKlnjPPNh 8u2eQSWwwtfS8o846XIaQaSP1mhhs3+wW+fnnCLk6MiYLR4OX1DAPz9p+d3hXKfY/jYP yzsiDz/+UD3IHgZ8Gfwt3Kv7WMS1CAwOOPfLOWl1Fv0edBOVpjNmOwSPhdBsvwOD/fiF /BjYwzDghbJ3uON+yzPTtfJKifESyDTJv0HiGyWqciZJL2cothCUoZ0cTab+pE5fcSLs ci/w== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr3402159vcw.55.1336927041857; Sun, 13 May 2012 09:37:21 -0700 (PDT) Received: by 10.220.7.148 with HTTP; Sun, 13 May 2012 09:37:21 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 May 2012 09:37:21 -0700 Message-ID: From: Garrett Cooper To: cz li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 16:37:22 -0000 On Sun, May 13, 2012 at 5:09 AM, cz li wrote: > =C2=A0 =C2=A0I installed FreeBSD9.0 to IBM R51.Gnome startup black screen= , > only to restart.My graphics card is "82852/855GM Integrated Graphics > Device".Is there any solution?Can you give me a detailed step=EF=BC=9F > =E3=80=80=C2=A0 =C2=A0 =C2=A0 Thank you! That card isn't fully supported on FreeBSD yet (it's GEM based), but you can use one of the other drivers (like vesa, etc) in the meantime and hold tight for when GEM support will be available in FreeBSD. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 19:34:15 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B881065672 for ; Sun, 13 May 2012 19:34:15 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id A4F038FC1C for ; Sun, 13 May 2012 19:34:14 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2832141wgb.1 for ; Sun, 13 May 2012 12:34: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 :content-type:content-transfer-encoding; bh=lj+FclipmKxsIzDtsiZ5dt2YMlcfxpnLUfSsfogCajc=; b=JYRjpITKFoD4bTUVbNMBMnnR9Du5Zxmv1fGG/hI2Gi+cVur1Mhec7vIU5ON0gJClzN ox82UyzGkAIrqjxhD7mSEHZLl9KSOJsEr7OUi/CwAhFcO/Uj/YcGxl9eKL9n+UdA4lmQ PRhLHriAF1aEVVKow1wAXrz63qb+wCukp0w9Wjh5R8YTpfhGWgRK+SYTXfCYCQPkgHRI q2RvOi+G/QSrWuMVMyVr5OR9DMo+taeeGdr8EhgYr0ByugnvPdgZGWGWkGrP2Jt4p78K ++Jk+UhnOqCIx7euatmwbfhxC6XTgCZyT1910IrmNUh07ulJ60gzQRAc5qn5YmSFUHBF eLJw== MIME-Version: 1.0 Received: by 10.180.79.72 with SMTP id h8mr13648552wix.1.1336937648407; Sun, 13 May 2012 12:34:08 -0700 (PDT) Received: by 10.216.163.136 with HTTP; Sun, 13 May 2012 12:34:08 -0700 (PDT) In-Reply-To: References: <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> <20111211130819.GH83814@acme.spoerlein.net> <20120512073446.GM71676@acme.spoerlein.net> Date: Sun, 13 May 2012 15:34:08 -0400 Message-ID: From: Arnaud Lacombe To: Arnaud Lacombe , hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 19:34:15 -0000 Hi, On Sun, May 13, 2012 at 12:59 AM, Arnaud Lacombe wrote= : > Hi, > > On Sat, May 12, 2012 at 10:27 AM, Arnaud Lacombe wro= te: >> Hi, >> >> On Sat, May 12, 2012 at 3:34 AM, Ulrich Sp=F6rlein w= rote: >>> On Fri, 2012-05-11 at 16:49:42 -0400, Arnaud Lacombe wrote: >>>> Hi, >>>> >>>> On Sun, Dec 11, 2011 at 8:08 AM, Ulrich Sp=F6rlein = wrote: >>>> > On Sun, 2011-12-04 at 18:42:38 -0500, Arnaud Lacombe wrote: >>>> >> On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein wrote: >>>> >> > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >>>> >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe wrote: >>>> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on= the github tree ? >>>> >> >> > >>>> >> >> Ulrich, ping ? >>>> >> > >>>> >> > Oops, sorry for the delay! Fixed now, thanks for bringing it to m= y >>>> >> > attention. I missed the push --all flag. :/ >>>> >> > >>>> >> FWIW, the github mirror[0] of the completed SVN tree has not seen a= ny >>>> >> upgrade for a week now. Did some script broke ? >>>> >> >>>> >> Thanks, >>>> >> =A0- Arnaud >>>> >> >>>> >> [0]: https://github.com/freebsd/freebsd >>>> > >>>> > Yeah, sorry about that. Monitoring is not that great, so you should >>>> > always ping me directly. >>>> > >>>> > The problem is that people dump files at random places in the Subver= sion >>>> > tree and that cannot easily be translated to branches. This time it = was >>>> > /vendor/flex/FreeBSD-Xlist >>>> > >>>> It would seem the full SVN mirror on github is out-of-sync again, at >>>> least, the `user/imp/extern_cc' is missing. >>> >>> user/ isn't pushed to github (and I consider also not pushing projects/ >>> into it), as their webfrontend often craps out with too many branches. >>> >>> You can get it from git.freebsd.org directly. >>> >> ok, there seem to be a valid repository at >> `git://git.freebsd.org/freebsd'. It might take some time to clone it >> from BSDCan, so I'll wait to be back to base to clone. It sounds I'll >> need to re-export/re-import all my branches.. again >> > ok, that repository looks complete... the drawback of using it is that > I'll lost the possibility to share anything on github or gitorious... > Could it be thought to have all git mirror around (gitorious, github, > your.org, ...), to actually be simple clone of this specific > repository, to be able to facilitate code sharing among them ?? > answer to myself, the git://git.freebsd.org/freebsd and the repository on github seem to actually be the same tree. github just has less branches exported in it. That's a good news ! - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 02:39:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A3CF106564A for ; Mon, 14 May 2012 02:39:46 +0000 (UTC) (envelope-from willingbug@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7CA98FC14 for ; Mon, 14 May 2012 02:39:45 +0000 (UTC) Received: by obcni5 with SMTP id ni5so8956577obc.13 for ; Sun, 13 May 2012 19:39:44 -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=Ir2x6HW8SyYwXHcZqWzYVVcAZi4ezSX2ad2yN3ueg+c=; b=NzzfRZBDBAL5JipqKmc6L9gvjKej6pU9xx6gVKoUUm8htDYLY0U1DpIh0IlQDpe80p xbskrGoGFoDv2vBrw4DCvTdvHmc4/5bS2IaqwnIxSttsZ4rEefcJCphib8/af29kmPhB jUU5uc9AwtD8CZhzlP3OpBOvgPlu5J77OfNGKeo/v6GhWGuXaZNFyzqm+B8d/CNhVUDL wzdOsaMf5WTL1xNi1mjCIySzkKhXTwOw3u4dVR9hMUBO8MYk/seQQe1W2vJVp4wq+jBS n0sIRfz6D6ZxLjYXYwVeb7YpQzpr6Qs7j5Isb+d4p01ll1vM3YlBDNcfmEk15ewt3DZz dmng== MIME-Version: 1.0 Received: by 10.60.6.8 with SMTP id w8mr9458351oew.3.1336963184399; Sun, 13 May 2012 19:39:44 -0700 (PDT) Received: by 10.182.52.167 with HTTP; Sun, 13 May 2012 19:39:44 -0700 (PDT) Date: Mon, 14 May 2012 10:39:44 +0800 Message-ID: From: cz li To: freebsd-hackers Content-Type: text/plain; charset=UTF-8 Subject: FreeBSD supports kernel preemption? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 02:39:46 -0000 FreeBSD supports kernel preemption? Kernel preemption mechanism is what?Where can I find detailed information about it? Thank you! chao zhong li 2012/05/14 From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 06:36:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427E11065670 for ; Mon, 14 May 2012 06:36:15 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD3008FC0A for ; Mon, 14 May 2012 06:36:14 +0000 (UTC) Received: by laai10 with SMTP id i10so3098938laa.13 for ; Sun, 13 May 2012 23:36:13 -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=OgFC7TCxL/DuC1XXrA7CNtTfAM3K/JcSpm8sJbOZAkQ=; b=iMezowye5aosflHPmWNO3K1+ipGoZBW3CXXWenYzxFLhVlY0UVnjHIXZ84SjrK8bjA +Uu1GzfFHIidboAZElQDfErt9R0qG8h219RFBSAGN/gCr3stBGgejlX6ZGUF9L7kQ9z5 dVoaMjFd2TV2QkGnJzV7slDg11BJkijQ6WOxbR5AW7ZI3U3e4kqyX6IzRXe4CInTjzTw QCBtkG4NhVbRE3EaNMuVLDv1hhJyGscmJilyQgLT0vERT1dor/wfCvtOwRLipIjiZH2m EbxSUz+cR04hDqp2/lktKmd0lbfOXHhCYBDUd0PojRRCJprHm6a+Y/MJ7x0y7i6oZEPF MmgQ== MIME-Version: 1.0 Received: by 10.112.29.166 with SMTP id l6mr1519196lbh.68.1336977373256; Sun, 13 May 2012 23:36:13 -0700 (PDT) Received: by 10.152.24.131 with HTTP; Sun, 13 May 2012 23:36:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 May 2012 08:36:13 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: cz li Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers Subject: Re: FreeBSD supports kernel preemption? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 06:36:15 -0000 On Mon, May 14, 2012 at 4:39 AM, cz li wrote: > FreeBSD supports kernel preemption? Kernel preemption mechanism is > what?Where can I find detailed information about it? Just Google it. Have a look at this[1] [1] http://en.wikipedia.org/wiki/Preemption_%28computing%29 > > Thank you! > > chao zhong li > 2012/05/14 > _______________________________________________ > 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 14 09:03:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FD67106566C for ; Mon, 14 May 2012 09:03:11 +0000 (UTC) (envelope-from dgeorgester@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC248FC0C for ; Mon, 14 May 2012 09:03:11 +0000 (UTC) Received: by yhgm50 with SMTP id m50so5114879yhg.13 for ; Mon, 14 May 2012 02:03: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=gznYpdBUyT7HqOgLkIhTto7rT5Vx6SWHIiDRVmt9kN0=; b=iOlREFzPCILn/3PZq5hHvxvdmaLl7gwuX4gJ1go52KGfVRjPiCg3kFKJWe2mgq31en CJIcf0mUbeBo1ucYdNFQL5TmFZ4pT/8/q2xJ91el1RoMKo0T6s1Q9aKl8j5XlXGT81Op k5sE0zGfsP6Lp+5y7qKrHNCqlmgjlhG6rBe2p85cABaIAJKp9f+F2cSC5junxsZmDOzu pq+K05FzJzmwGSB9NklwHHWzIiLkvHb6kY+x8LwCRqyjg4fALmX5qFoyvgEkVsK1PtpJ RbXyca5kV1k4cVgPkI8YyJfWz1d0aC0M/UjFtsHYd7PwL9PElTeVxl3pK1ytB+bChFKm HdkA== MIME-Version: 1.0 Received: by 10.236.175.105 with SMTP id y69mr7126368yhl.83.1336986190618; Mon, 14 May 2012 02:03:10 -0700 (PDT) Received: by 10.146.165.3 with HTTP; Mon, 14 May 2012 02:03:10 -0700 (PDT) Date: Mon, 14 May 2012 11:03:10 +0200 Message-ID: From: David George To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 14 May 2012 11:23:56 +0000 Subject: FreeBSD IPSec adventures X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 09:03:11 -0000 Hello All. I have been working on a project where the goal has been to convert the FreeBSD IPSec stack to a userspace application. The project is pretty far along, so I thought I would dump my observations/experiences with regards the IPSec stack here. (Hopefully this is the correct forum) 1) SADB_X_SPDUPDATE (PFKEY call to update an existing Security Policy) I found that FreeBSD creates a new policy with a new unique Security Policy ID when performing an SP update. There appears to be no definitive RFC for this behaviour, I found this text in an IETF memo titled "MOBIKE Extensions for PF_KEY": " SADB_X_SPDUPDATE: If an existing SPD entry should be updated, the IKEv2 implementation sends a SADB_X_SPDUPDATE message to the kernel. This massage has the following format: The kernel responds with a message of the form: The meaning of the payloads is the same as for the SADB_X_SPDADD message. All the content of a SPD entry can be changed except the sadb_x_policy_id field and the source/destination addresses, which are the inner addresses in tunnel mode. However, the tunnel endpoint addresses, which only exist in tunnel mode, can be changed using a SADB_X_SPDUPDATE message. " I think that the approach of not modifying the policy ID is the more sensible; and as it turns out, was something that my work required. Does anyone know why FreeBSD takes this approach? 2) ESP + Authentication Crypto Performance I ran into some performance issues when using ESP with any authentication. The problem is that only one crypto device can be used for the ESP transform. This makes it impossible to use AESNI with ESP+auth with FreeBSD as it stands, which amounts to a major performance penalty. This looked tricky to resolve properly, as it seems to be an infrastructural problem. 3) SHA1 Performance I also had some problems with the opencrypto software SHA1 performance. By substituting the opencrypto sha1 call with an openssl library call the time to do a 1000B hash reduced to under half. Has anyone else noted SHA1 performance problems? Would be great to have some comments from FreeBSD gurus. Kind regards, David George From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 14:13:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530C8106566B for ; Mon, 14 May 2012 14:13:46 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id AFBA88FC16 for ; Mon, 14 May 2012 14:13:45 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4EEDdQs063146; Mon, 14 May 2012 16:13:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4EEDdxr063143; Mon, 14 May 2012 16:13:39 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Mon, 14 May 2012 16:13:39 +0200 (CEST) From: Wojciech Puchar To: cz li 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Mon, 14 May 2012 16:13:40 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:13:46 -0000 > I installed FreeBSD9.0 to IBM R51.Gnome startup black screen, > only to restart.My graphics card is "82852/855GM Integrated Graphics > Device".Is there any solution?Can you give me a detailed step? > ? Thank you! same thing here. it is not video card dependent IMHO > > chao zhong li > 2.12/5/13 > _______________________________________________ > 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 14 17:46:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA201065674 for ; Mon, 14 May 2012 17:46:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 218BE8FC0C for ; Mon, 14 May 2012 17:46:20 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 9tV31j00E1wfjNsA1tlEzH; Mon, 14 May 2012 17:45:14 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id 9tlD1j00h4NgCEG8jtlDp4; Mon, 14 May 2012 17:45:14 +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 q4EHjB1S094414; Mon, 14 May 2012 11:45:11 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Robert Simmons In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 May 2012 11:45:11 -0600 Message-ID: <1337017511.1503.70.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 Subject: Re: csh builtin command problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 17:46:20 -0000 On Wed, 2012-05-09 at 21:34 -0400, Robert Simmons wrote: > I'm trying to use sysv style echo in /bin/csh and I've hit a wall as > to how to get it to work. > > The following does not have the outcome that I'm looking for: > > # echo_style=sysv > # echo test\ttest > test > # cat test > testttest > > I want this: > > # echo test\ttest > test > # cat test > test test > > Any thoughts? What I see on 8.3 is this: % set echo_style=sysv % echo test\ttest testttest % echo "test\ttest" test test % So it seems from this very minimal test that the implementation of echo is correct, but the parsing of the command line in csh requires that the \t in the arg be protected with quotes. (I don't normally spend any longer in csh than it takes for a .cshrc to launch bash, and even that's only on systems where I don't control /etc/passwd to just use bash directly.) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 17:51:23 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 646A4106566B for ; Mon, 14 May 2012 17:51:23 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 168938FC12 for ; Mon, 14 May 2012 17:51:22 +0000 (UTC) Received: by vbmv11 with SMTP id v11so6962363vbm.13 for ; Mon, 14 May 2012 10:51:22 -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:content-transfer-encoding; bh=PpDJiJ1rb4YK+0d59XqQMgq0A3lG8X3zlsUsfFDAnWk=; b=rFQfF+1d5086658Sk0yCwR/ZY849aGZ3QsEmnzhPSosVIb+OcgplkGYlOU1sSzRBbU 8Xw12myi5xZmmOW1mW0p9ecngybNLSXq7NLU+/vQPKjo73dB3X7Ue7vqSmotmg2CdDK3 OdDTXGwwSDF0uAxRin9AAdRNyUh9ssroJwE04MgJMzq1imOpEYMWOrnFHkZUc1RWWXaz L96MqF3l4g9dhpaBZmRNLSApHEposAGZ740sdne2Ul2Z5e4naAsbdJDf7DUEDjNcL99d XGFNxt9iswak6vKRe9Aj/f8ea/yjVfK2NWgBkJ+MWJDyFa2pFhCMhN+9T1M8W7xYkSKi HsQw== MIME-Version: 1.0 Received: by 10.220.218.208 with SMTP id hr16mr5504113vcb.49.1337017882387; Mon, 14 May 2012 10:51:22 -0700 (PDT) Received: by 10.52.112.167 with HTTP; Mon, 14 May 2012 10:51:22 -0700 (PDT) In-Reply-To: <1337017511.1503.70.camel@revolution.hippie.lan> References: <1337017511.1503.70.camel@revolution.hippie.lan> Date: Mon, 14 May 2012 13:51:22 -0400 Message-ID: From: Robert Simmons To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: csh builtin command problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 17:51:23 -0000 On Mon, May 14, 2012 at 1:45 PM, Ian Lepore wrote: > On Wed, 2012-05-09 at 21:34 -0400, Robert Simmons wrote: >> I'm trying to use sysv style echo in /bin/csh and I've hit a wall as >> to how to get it to work. >> >> The following does not have the outcome that I'm looking for: >> >> # echo_style=3Dsysv >> # echo test\ttest > test >> # cat test >> testttest >> >> I want this: >> >> # echo test\ttest > test >> # cat test >> test =A0 =A0test >> >> Any thoughts? > > What I see on 8.3 is this: > > % set echo_style=3Dsysv > % echo test\ttest > testttest > % echo "test\ttest" > test =A0 =A0test > % > > So it seems from this very minimal test that the implementation of echo > is correct, but the parsing of the command line in csh requires that the > \t in the arg be protected with quotes. =A0(I don't normally spend any > longer in csh than it takes for a .cshrc to launch bash, and even that's > only on systems where I don't control /etc/passwd to just use bash > directly.) Thanks. I should have tried double quotes. That works. From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 21:39:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 939C6106566C for ; Mon, 14 May 2012 21:39:26 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 41A508FC0A for ; Mon, 14 May 2012 21:39:26 +0000 (UTC) Received: (qmail 15845 invoked from network); 14 May 2012 17:39:20 -0400 Received: from softdnserror (HELO ?172.16.1.166?) (71.234.176.233) by mail.atlantawebhost.com with SMTP; 14 May 2012 17:39:19 -0400 Message-ID: <4FB17B85.9080701@shadowsun.net> Date: Mon, 14 May 2012 17:39:17 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> In-Reply-To: X-Enigmail-Version: 1.5pre X-Enigmail-Draft-Status: 513 Content-Type: multipart/mixed; boundary="------------050703030500030000060805" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 21:39:26 -0000 This is a multi-part message in MIME format. --------------050703030500030000060805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/10/12 07:45, Marcel Moolenaar wrote: > > On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > >> Here are some specific points to be decided: >> >> * An EFI boot service could potentially function similarly to >> [zfs]loader. Alternatively, it could function like >> gpt[zfs]boot, though this might require modifying loader(8) since >> EFI boot services run in protected/long mode, and have different >> system information table formats. It seems having the EFI boot service load the kernel directly is the way to go, based on Andrey's reply, the existing code, and my own intuition. I just wanted to ask, in case there was some compelling reason to have the EFI boot service load loader(8) instead. > Now, as for the FreeBSD boot loader: it's currently an EFI > program/image that can be run from within EFI and that uses the > boot- and runtime services to load the FreeBSD kernel from a file > system it knows about in some GPT partition. The loader is stored > in the EFI system partition so that it can be found and run. Sounds good. Also, Apple machines do things a bit differently, but it shouldn't be too much trouble to deal with. The Apple firmware looks for an HFS+ partition, and loads a specific file from it. A simple workaround is just to wrap the EFI boot program in an HFS+ filesystem. I have some half-finished code that does this on my hard drive. Also, the apple firmware starts in graphics (as opposed to text) mode. > >> * How much of what EFI provides do we want to use? There are >> advantages and disadvantages both ways. There are alot of features described in the EFI specification. It might be good to plan to use some of them, either now, or in the future. In particular, I noticed something about signing for boot services and drivers, which seems like it could be a great security feature (though not something I'd do this summer), though I haven't looked closely at it yet. On the other hand, I think it's a good idea to use libstand/libi386 whenever possible, even if it ends up calling through to EFI functions, as it keeps things standardized. >> * How much of the kernel needs to be changed to boot/run from an >> EFI boot? > > The hand-off will be different. In particular, a proper loader will > not load the kernel at some hardcoded address. Instead it will use > EFI's memory allocation routines to get available memory chunks and > load a kernel there. Since the kernel may not occupy a single > contiguous range in physical memory this way, you want the loader > to set up page tables as well. > > Put differently: the current state of affairs is that the EFI > loader we have loads a kernel, but can't boot it. Good to know. Here are some other questions/issues on my mind: If I understand things correctly, boot2 handles the switch to protected mode (as well as enabling A20), both loader(8) and the kernel begin their execution in a protected mode environment. Can I get an absolute confirmation on this? Obviously if this is not the case, then there will need to be another (protected mode) entry point into the kernel. I know some drivers rely on BIOS calls (vga, for instance, and I think some drivers for RAID cards do as well). These might (or might not) need to be modified. > You need to support both anyways. But not at the same time. The > machine either boots BIOS or EFI and depending on that will it use > the EFI loader or use the MBR to load boot code. There's nothing to > try. > > Key is to have a single kernel loadable and bootable by either the > EFI loader or using the "legacy" loader. Yes, I think it's prudent to make it possible for users to boot a given kernel with EFI or legacy BIOS, so that a bug doesn't leave early adopters "stuck" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPsXuEAAoJENSCzbQ+koZ7yaIP/1MGDIUCVN2HR9QOteKxg4U2 YeDZQ/C+s3xG5rnztfY5u5b5o9tEVoQJiBcvk+6+9JRW1cBhEUzAjgWnKDL5QMid RWql/rOPrg2jRhaRYQrh0dN9kkI0Dzdfm+N53Fmf0jat9fn11n5fYVzcA+WnFHTr eQ7IZNKGdJg7zzTC6+cDHz4wRjr+Lozp2Yk5hptsc4Xu3CkHus/7LRIoyfgEEc6r XwvjdBPYv9Jr6XirBFrZHjHNU/XvjUnD+bKyaEAhlUekLE/1J7Ge3oK0dqC3/zNh 5dP2ArQ0Xj91HzG2U8cDQs4SWp4AzIONygq5SdZeX+d78cpMJCzqzmxh3fdW2Aa9 oh40Aulqlj3BfeA7pak0Qe7SmDCi3OaZVI1z/HVbQD8utY4CxFmq7z6lnKBj6Y08 w9TyilE/px4AFy54nhjNke7eRfapu1g1Iz881oOHRtPcwecshTbjQWeBUQzc+3gV zE0L2NwUxUt5eWfw2jyC8bSK/mboMMBXpt4Zd4hBWjYKYcvbfaSSHS5Ys70Nlq30 GHjFphMz4MMpJbCO4ak/fMEJJPCDrDdoIT9QfUglyo3GjwI1BzUQF5iFoHFfqd/o hrcW+hgIVjb/qRT/Yr0qjEumoCnQLMHPcc8ylVVL1wt0qDyUL9XnjPiKRisQ4uqv lLNBhd+3V8SBV8V7sl0J =yyPA -----END PGP SIGNATURE----- --------------050703030500030000060805-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 22:08:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C1F31065673 for ; Mon, 14 May 2012 22:08:52 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFAF28FC0C for ; Mon, 14 May 2012 22:08:51 +0000 (UTC) Received: by yenl8 with SMTP id l8so6124788yen.13 for ; Mon, 14 May 2012 15:08: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=yrvQt2xFF1+JnF7ApHnN+THhr7WjluJxR3Z5/Vqmmnw=; b=D+WpLxlRBumT9eXTihFMp+RChBV1tMFAO2IcNxSz8dZ1GP4yPCIRzCqqiGMTwpvQm8 1jLLsE8V5mA3NjPuWkqgo2/csCNYgKarscfFiIq0oXqrIMftFSxgMBgX2G6d2FKsDM7W eE2cAILuWLaw7sC6KKRr3igTpZBdj3Y3B8Zs8yebkhnu8Uti3GNbVTMopGMc/VOlbsM+ 8MddTdPerc2e0L/NQJmW2Dr8B5AgYLXzAFI0axDnNTAUvhdEY5PRAuRU6wPb8AAIo6pI tZH1d+fvMnQMAhcxhBFCizo/R2Jn1UYUKXR1gQJhC13/nWO0wptwz17RLvCbONU4BcqK F9PA== MIME-Version: 1.0 Received: by 10.42.19.72 with SMTP id a8mr81256icb.39.1337033330922; Mon, 14 May 2012 15:08:50 -0700 (PDT) Received: by 10.43.51.69 with HTTP; Mon, 14 May 2012 15:08:50 -0700 (PDT) Date: Mon, 14 May 2012 18:08:50 -0400 Message-ID: From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 22:08:52 -0000 I have a HP Pavilion g7-1365dx laptop that is constantly freezing up (doesn't respond to any key/mouse actions except the power switch) at random times the most reasonable explination I can think of is overheating and thus I have gotten one of those laptop mats that has a fan in it but to no avail (makes it less likely but now that stuff is heating up in late spring [I have no AC]) it is happening again... I use the machine for totally routine desktop stuff (surfing the web, watching flash movies and some lite java development).... my guess is that for some reason the FreeBSD CPU/bus speed controls and such are not working based on the following item I found in my dmesg's: acpi_tz0: _CRT value is absurd, ignored (-273.2C) I have no other clues so far From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 22:43:42 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02A4E1065674 for ; Mon, 14 May 2012 22:43:42 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd28124.kasserver.com (dd28124.kasserver.com [85.13.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id B5C6E8FC17 for ; Mon, 14 May 2012 22:43:41 +0000 (UTC) Received: from taiko.lan (ppp-88-217-23-20.dynamic.mnet-online.de [88.217.23.20]) by dd28124.kasserver.com (Postfix) with ESMTPSA id 2F4C21D8020C; Tue, 15 May 2012 00:37:45 +0200 (CEST) Message-ID: <4FB1891F.4090703@chillt.de> Date: Tue, 15 May 2012 00:37:19 +0200 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120514 Thunderbird/12.0.1 MIME-Version: 1.0 To: Aryeh Friedman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 22:43:42 -0000 Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell laptop and for me, this sysctl always reports the temperature. - Bartosz From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 22:56:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AB7C106566B for ; Mon, 14 May 2012 22:56:48 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 157698FC08 for ; Mon, 14 May 2012 22:56:47 +0000 (UTC) Received: by yenl8 with SMTP id l8so6167856yen.13 for ; Mon, 14 May 2012 15:56: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=3NKco47npsrD1viMAHJL8BbGjqCVJs3A1j9oXQVxlCk=; b=j5t9dlDvitPFyywE6mWC9MzuMlOQKBaD2l5Wy+sPhq6AMOEoAZ8XAbFrUFBVyRdAfe LadthCZkKTjDJGUJ3JhwkCk/oxustQvMhc1DrnbpSj+WXoprdaVNURiGi7xwiL41tT8e 4XKivmgFx4/iKJjLHwK0JzpjASvoIq/G8oPW9dAy0socgYoHQDOIhvWHEDs628qKIpFO 02ZB48W2+yDPb3KMq066abq73hgQUdYx4hS2TBembS1sCA8NvsWNNbkbGx69JIwjJzIZ qCGnaOwU0Gk0a03tFLnFPwjIRR6Rmhb70lyhhSWGdnV3jCrmufkoArR1KJ0ZQkOMCbGJ cF9A== MIME-Version: 1.0 Received: by 10.50.222.134 with SMTP id qm6mr5230861igc.49.1337036207375; Mon, 14 May 2012 15:56:47 -0700 (PDT) Received: by 10.43.51.69 with HTTP; Mon, 14 May 2012 15:56:47 -0700 (PDT) In-Reply-To: <4FB1891F.4090703@chillt.de> References: <4FB1891F.4090703@chillt.de> Date: Mon, 14 May 2012 18:56:47 -0400 Message-ID: From: Aryeh Friedman To: Bartosz Fabianowski Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 22:56:48 -0000 On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski wrote: > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > laptop and for me, this sysctl always reports the temperature. > > - Bartosz ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature sysctl: unknown oid 'dev.cpu.0.temperature' ~/Desktop aryeh@localhost% sysctl dev.cpu.0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.C000 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1500 dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 400/1734 300/1300 200/867 100/433 dev.cpu.0.cx_supported: C1/0 C2/100 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 233us From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 23:02:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA252106564A for ; Mon, 14 May 2012 23:02:22 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5108FC0A for ; Mon, 14 May 2012 23:02:22 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SU4HV-0002Fa-1u; Tue, 15 May 2012 00:02:21 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SU4HU-0006aL-Fr; Tue, 15 May 2012 00:02:20 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q4EN2KmE014866; Tue, 15 May 2012 00:02:20 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q4EN2KxM014865; Tue, 15 May 2012 00:02:20 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Tue, 15 May 2012 00:02:20 +0100 From: Anton Shterenlikht To: Aryeh Friedman Message-ID: <20120514230219.GA14856@mech-cluster241.men.bris.ac.uk> References: <4FB1891F.4090703@chillt.de> 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: Bartosz Fabianowski , FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:02:22 -0000 On Mon, May 14, 2012 at 06:56:47PM -0400, Aryeh Friedman wrote: > On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski wrote: > > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > > laptop and for me, this sysctl always reports the temperature. > > > > - Bartosz > > ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature > sysctl: unknown oid 'dev.cpu.0.temperature' > ~/Desktop aryeh@localhost% sysctl dev.cpu.0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1500 > dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 > 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 > 400/1734 300/1300 200/867 100/433 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 233us > _______________________________________________ GEN8> sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 105.0C hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 1 hw.acpi.thermal.tz0._TC2: 2 hw.acpi.thermal.tz0._TSP: 100 GEN8> See acpi_thermal(4) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 23:07:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D394C106564A for ; Mon, 14 May 2012 23:07:26 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B41F8FC16 for ; Mon, 14 May 2012 23:07:26 +0000 (UTC) Received: by yhgm50 with SMTP id m50so6149813yhg.13 for ; Mon, 14 May 2012 16:07: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=F7fwP88uZDwTVNRqpdr1NqedzCUc9/WHMBjVCrQiDiA=; b=CjL0MbOnvKkvZVqkmz+u+G3G3Lx+gU6tQc7dpQmfhpadXnpZ+6CTE+3Xu8QbXuKn4C cDsvzbSqFtkrUnONLcfjn8hY3IzJfqYBYjjaNB1+oVI/KUJVc4oklDiItkVcqGHd9Fu1 4iCsV1+Y7wciTA5KefwU11oNUmhl0aF6RDYoTUaCWnen5Lqd51fdqN/Z0G23/i52eGq8 B8HdMwK0Boi2geLzl+/B9kUK65u2RZS5bShfc+/BalFc/2ue9/tQIVVtjWeE2hiDEYWM SUt0ntTtXsVpgL5IE4VzSy+oyQPHsZqiotnhJcWWTf4SBxEs9X1dJljvBsU9S9YT/j45 Ec4w== MIME-Version: 1.0 Received: by 10.50.89.130 with SMTP id bo2mr5163687igb.19.1337036845729; Mon, 14 May 2012 16:07:25 -0700 (PDT) Received: by 10.43.51.69 with HTTP; Mon, 14 May 2012 16:07:25 -0700 (PDT) In-Reply-To: <20120514230219.GA14856@mech-cluster241.men.bris.ac.uk> References: <4FB1891F.4090703@chillt.de> <20120514230219.GA14856@mech-cluster241.men.bris.ac.uk> Date: Mon, 14 May 2012 19:07:25 -0400 Message-ID: From: Aryeh Friedman To: Anton Shterenlikht Content-Type: text/plain; charset=ISO-8859-1 Cc: Bartosz Fabianowski , FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:07:27 -0000 On Mon, May 14, 2012 at 7:02 PM, Anton Shterenlikht wrote: > On Mon, May 14, 2012 at 06:56:47PM -0400, Aryeh Friedman wrote: >> On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski wrote: >> > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell >> > laptop and for me, this sysctl always reports the temperature. >> > >> > - Bartosz >> >> ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature >> sysctl: unknown oid 'dev.cpu.0.temperature' >> ~/Desktop aryeh@localhost% sysctl dev.cpu.0 >> dev.cpu.0.%desc: ACPI CPU >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.C000 >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.freq: 1500 >> dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 >> 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 >> 400/1734 300/1300 200/867 100/433 >> dev.cpu.0.cx_supported: C1/0 C2/100 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_usage: 100.00% 0.00% last 233us >> _______________________________________________ > > GEN8> sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 61.0C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 95.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 105.0C > hw.acpi.thermal.tz0._ACx: 75.0C 65.0C 50.0C 40.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 1 > hw.acpi.thermal.tz0._TC2: 2 > hw.acpi.thermal.tz0._TSP: 100 > GEN8> > > See acpi_thermal(4) > hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 94.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: 105.0C hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 2 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 30 From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 23:20:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7436F106564A for ; Mon, 14 May 2012 23:20:35 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 54F468FC08 for ; Mon, 14 May 2012 23:20:35 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 9z6e1j0091ZMdJ4ACzKViS; Mon, 14 May 2012 23:19:29 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta16.emeryville.ca.mail.comcast.net with comcast id 9zKU1j00s4NgCEG8czKUGq; Mon, 14 May 2012 23:19:29 +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 q4ENJQVn094612; Mon, 14 May 2012 17:19:26 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Aryeh Friedman In-Reply-To: References: <4FB1891F.4090703@chillt.de> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 May 2012 17:19:26 -0600 Message-ID: <1337037566.1503.100.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Bartosz Fabianowski , FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:20:35 -0000 On Mon, 2012-05-14 at 18:56 -0400, Aryeh Friedman wrote: > On Mon, May 14, 2012 at 6:37 PM, Bartosz Fabianowski wrote: > > Try sysctl dev.cpu.0.temperature. I have a notoriously overheating Dell > > laptop and for me, this sysctl always reports the temperature. > > > > - Bartosz > > ~/Desktop aryeh@localhost% sysctl dev.cpu.0.temperature > sysctl: unknown oid 'dev.cpu.0.temperature' > ~/Desktop aryeh@localhost% sysctl dev.cpu.0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1500 > dev.cpu.0.freq_levels: 1500/7260 1400/6056 1225/5299 1200/5125 > 1100/4500 1000/4095 900/3753 800/3468 700/3034 600/2601 500/2167 > 400/1734 300/1300 200/867 100/433 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 233us dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe you need to kldload it? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 23:26:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6903A1065670 for ; Mon, 14 May 2012 23:26:59 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 21D6C8FC0A for ; Mon, 14 May 2012 23:26:59 +0000 (UTC) Received: by yhgm50 with SMTP id m50so6164763yhg.13 for ; Mon, 14 May 2012 16:26: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 :content-type; bh=eNYScajxeuAdA6tv8xtp2x/CdRcP+KqVWwyW7h4UaFo=; b=TxkAhICy6SVE2LaZiWBw8CpHGZA4XmaU/sQDfqlIsez2DO2WmyX2x+NXto+voI4ajp f3Z6rf1vA0pVMh9qx5ihUSAtoenvArY1wZc3maslEOxtvWuV/1oIl2nu3sl2OiAT5wvc ejeDGeccHI2vdvQlxlbrOsdrpdUJAtoW9hllnoTZxuqbouCNjqRoXqWjLiLmlQuQiIAL qjf3rzBqooxE05Ee/pPkt5T0frWpRbCKkHfEoeJgCyyh/Pd8jzfsBgmim7fYs7fs/9mu WO82xFEYj/TpnH0Gf53zAzuFKezs5DPEqzXNlNhxXbPDKeyAXitA3NXrV2vWSkPbGvTQ mtng== MIME-Version: 1.0 Received: by 10.50.222.134 with SMTP id qm6mr5270852igc.49.1337038012065; Mon, 14 May 2012 16:26:52 -0700 (PDT) Received: by 10.43.51.69 with HTTP; Mon, 14 May 2012 16:26:52 -0700 (PDT) In-Reply-To: <1337037566.1503.100.camel@revolution.hippie.lan> References: <4FB1891F.4090703@chillt.de> <1337037566.1503.100.camel@revolution.hippie.lan> Date: Mon, 14 May 2012 19:26:52 -0400 Message-ID: From: Aryeh Friedman To: Ian Lepore , FreeBSD Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:26:59 -0000 > > dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe you > need to kldload it? > > -- Ian > > Added coretemp and still no sysctl of that name From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 00:07:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78CAE106566C for ; Tue, 15 May 2012 00:07:15 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4805C8FC0C for ; Tue, 15 May 2012 00:07:15 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0F67C37B49A; Mon, 14 May 2012 19:02:07 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7308B1772E; Mon, 14 May 2012 19:02:06 -0500 (CDT) Date: Mon, 14 May 2012 19:02:06 -0500 From: "Matthew D. Fuller" To: Ian Lepore Message-ID: <20120515000206.GR45091@over-yonder.net> References: <4FB1891F.4090703@chillt.de> <1337037566.1503.100.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1337037566.1503.100.camel@revolution.hippie.lan> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.4 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: Bartosz Fabianowski , Aryeh Friedman , FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 00:07:15 -0000 On Mon, May 14, 2012 at 05:19:26PM -0600 I heard the voice of Ian Lepore, and lo! it spake thus: > > dev.cpu.0.temperature is provided by the coretemp(4) driver, maybe > you need to kldload it? A quick Google suggests that model (g7-1365dx) is an AMD Llano proc, so I doubt "coretemp — device driver for Intel Core on-die digital thermal sensor" is going to he much help 8-} amdtemp(4) would be the possible choice. But I don't know whether it can handle Llano. >From the specs, it looks like it has a discrete graphics card as well as the integrated too. Since I'm pretty sure that combo isn't supported (and you're probably just running VESA anyway), the discrete is dead weight, and if it doesn't turn itself flat off (I don't know if it does or not), it may be contributing to heat problems. -- 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 Tue May 15 08:00:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9B61106566B for ; Tue, 15 May 2012 08:00:56 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:70:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4EB8FC15 for ; Tue, 15 May 2012 08:00:56 +0000 (UTC) Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3VsB6Q6MzPz4KMZ2; Tue, 15 May 2012 10:00:46 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 3VsB6Q5fkVz4KK5f; Tue, 15 May 2012 10:00:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id xVQcQnIVcC6u; Tue, 15 May 2012 10:00:46 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-54-128.dynamic.mnet-online.de [93.104.54.128]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS; Tue, 15 May 2012 10:00:45 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 4EBD82686A; Tue, 15 May 2012 10:00:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 27F7226867; Tue, 15 May 2012 10:00:45 +0200 (CEST) Date: Tue, 15 May 2012 10:00:44 +0200 (CEST) From: Michael Reifenberger To: Eric McCorkle In-Reply-To: <4FB17B85.9080701@shadowsun.net> Message-ID: References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> 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 Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 08:00:56 -0000 On Mon, 14 May 2012, Eric McCorkle wrote: ... > If I understand things correctly, boot2 handles the switch to > protected mode (as well as enabling A20), both loader(8) and the > kernel begin their execution in a protected mode environment. Can I > get an absolute confirmation on this? Obviously if this is not the > case, then there will need to be another (protected mode) entry point > into the kernel. > No. *boot* and *loader should be the same on X32 and AMD64. The kernel seems to switch to long mode in /sys/amd64/amd64/mpboot.S Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 12:05:31 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A02DD1065687 for ; Tue, 15 May 2012 12:05:31 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 206CC8FC0C for ; Tue, 15 May 2012 12:05:30 +0000 (UTC) Received: by bkvi18 with SMTP id i18so5157006bkv.13 for ; Tue, 15 May 2012 05:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=hkxIZOlwrdK5lx30Tq/TIw/gsM//UqXvHA0TykNh4LU=; b=hf+BUywE+yiGRMXZkv0tNjVFZesgLeZZQaXuN6AUQJL69b0/Jd1AruTT8VfiCZySTX PMDWNLXdOpserUAnqq1O9bxuBd2t1fusp2hLvpw2njXu4soCpiLoS4HYddK89H7+d2qg lkijTPydRrJtOdAw0egqcke7brfpw96yCHlybFz3XbhO1DRLZUPzfDUU2G22jQWqKJf0 4qsFdHpXOGV6wMOTzLc6TSNDrp3cqjKdAuI8zj0QtBd1vpVsbSIoJcZg/c9cL2FXuzUR V1dDdsLJnIR8HgDA+uuVL5VBuHkz1qUVGQAO7c2iFBMloVKtIs66sn05KiyszKxuo8L9 Q94A== Received: by 10.204.151.204 with SMTP id d12mr4310597bkw.72.1337083530125; Tue, 15 May 2012 05:05:30 -0700 (PDT) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id e20sm41183509bkv.10.2012.05.15.05.05.10 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 05:05:28 -0700 (PDT) Message-ID: <20120515.120527.783.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Tue, 15 May 2012 14:05:27 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <4FB1891F.4090703@chillt.de> <20120514230219.GA14856@mech-cluster241.men.bris.ac.uk> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 12:05:31 -0000 ----- Original Message -----=0D=0AFrom: Aryeh Friedman = =0D=0A=0D=0AThere is something special about = laptops, which distincts them from desktop and server = hardware.=0D=0ARequirement for cooling maintaince!=0D=0A=0D=0A> = hw.acpi.thermal.tz0.temperature: 94.0C=0D=0A=0D=0AThis pretty much says = it all.=0D=0AFix starts when you turn OFF your laptop and disassemble it, = in order to get to the heatsink and fan.=0D=0ADon't remove heatsink as it = is tied to CPU and you don't have thermal paste.=0D=0A=0D=0AClean fan = with alcohol and sticks and also paths thru which air circulates. Those = surfaces must be super clean.=0D=0A=0D=0AI had a same case of CPU = throtling at ~85=B0=0D=0AAfter I did this maintance I'm having a "new" = laptop which operates at 45 - 55=B0 at 100% CPU, for hours=0D=0AOnly in = extreme cases it is throtled to 90%=0D=0A=0D=0ABe prepared to go very = deep in your laptop. I had to remove almost everything except MBO and CPU = and GPU.=0D=0A=0D=0AAfter that use vacuum cleaner each 6 months, on = fan=0D=0A65-70=B0 indicates maintaince time.=0D=0A=0D=0A=0D=0ADomagoj = Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 12:32:42 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F8C106566B for ; Tue, 15 May 2012 12:32:42 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id AE55B8FC08 for ; Tue, 15 May 2012 12:32:41 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SUGvb-0000a2-6F; Tue, 15 May 2012 13:32:35 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SUGvb-0005sn-1a; Tue, 15 May 2012 13:32:35 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q4FCWYES056499; Tue, 15 May 2012 13:32:34 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q4FCWYQp056498; Tue, 15 May 2012 13:32:34 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Tue, 15 May 2012 13:32:34 +0100 From: Anton Shterenlikht To: rank1seeker@gmail.com Message-ID: <20120515123234.GC56431@mech-cluster241.men.bris.ac.uk> References: <4FB1891F.4090703@chillt.de> <20120514230219.GA14856@mech-cluster241.men.bris.ac.uk> <20120515.120527.783.1@DOMY-PC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120515.120527.783.1@DOMY-PC> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 12:32:42 -0000 On Tue, May 15, 2012 at 02:05:27PM +0200, rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: Aryeh Friedman > > There is something special about laptops, which distincts them from desktop and server hardware. > Requirement for cooling maintaince! > > > hw.acpi.thermal.tz0.temperature: 94.0C > > This pretty much says it all. > Fix starts when you turn OFF your laptop and disassemble it, in order to get to the heatsink and fan. > Don't remove heatsink as it is tied to CPU and you don't have thermal paste. I just did this on compaq 6715s laptop. I had to remove the heatsink for cleaning. I replaced the thermal paste. You can get it for under 5 GBP. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 15:35:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55154106566C for ; Tue, 15 May 2012 15:35:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF248FC15 for ; Tue, 15 May 2012 15:35:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 89409B948; Tue, 15 May 2012 11:35:21 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 15 May 2012 11:35:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <1336493232.1503.29.camel@revolution.hippie.lan> In-Reply-To: <1336493232.1503.29.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151135.19269.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 11:35:21 -0400 (EDT) Cc: Ian Lepore Subject: Re: Calling tsleep(9) with interrupts disabled X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:35:22 -0000 On Tuesday, May 08, 2012 12:07:12 pm Ian Lepore wrote: > I just realized that I've accidentally coded a sequence similar to this > in a driver: > > s = intr_disable(); > // do stuff here > tsleep(sc, 0, "twird", hz / 4); > // more stuff > intr_restore(s); > > Much to my surpise this works, including waking up due to wakeup(sc) > being called from an interrupt handler. So apparently tsleep() results > in interrupts being re-enabled during the sleep, although nothing in the > manpage says that will happen. > > Can I safely rely on this behavior, or is it working by accident? > > (Please no lectures on the evils of disabling interrupts... This is not > a multi-GHz multi-core Xeon, it's a 180mhz embedded SoC with buggy > builtin devices that will drop or corrupt data if an interrupt happens > during the "do stuff here" part of the code.) This happens to work because spinlock_enter/spinlock_exit also disable interrupts (so the new thread will re-enable interrupts when it resumes). However, if we switched spinlock_enter/exit to do something else in the future (e.g. to raise TPR as I have patches to do), then this would break. One option is to use spinlock_enter/exit instead of intr_disable/restore. However, you should probably just use a spin lock instead and use msleep_spin() instead of tsleep(). You can then use the spin lock in your filter interrupt handler around wakeup to prevent lost wakeups. Note that in a kernel without the SMP option, spin locks just devolve to spinlock_enter/exit anyway. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 16:38:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13221065674; Tue, 15 May 2012 16:38:51 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA068FC17; Tue, 15 May 2012 16:38:51 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9984FC4B2C; Tue, 15 May 2012 18:38:40 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id TkaZKmfC+lE9; Tue, 15 May 2012 18:38:39 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id BE14AC4B12; Tue, 15 May 2012 18:38:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Rafal Jaworowski In-Reply-To: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> Date: Tue, 15 May 2012 18:38:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Tim Kientzle , Marcel Moolenaar Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 16:38:52 -0000 On 2012-05-13, at 09:17, Tim Kientzle wrote: > On May 12, 2012, at 4:36 PM, Tim Kientzle wrote: >>=20 >> On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >>=20 >>> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>>=20 >>>> On the AM3358, the DRAM starts at 0x8000 0000 >>>> on boot, so I'm trying to find a clean way to convince >>>> the loader's ELF code to put the kernel there. >>>=20 >>> Look at what I did for ia64. All that frobbing should be done >>> in the machine specific implementation of arch_copyin, arch_copyout >>> and arch_readin. It's a kluge to do it in elf_loadimage. >>=20 >> That sounds like a reasonable approach. I've started >> working down that path=85 but it looks like I'll have to fix >> a lot of the FDT code along the way. >=20 > I'm getting close. In particular, I've reworked the FDT code > so that it correctly uses copyout() to parse data in the > kernel. Of course, in order to use libfdt to actually > manipulate the device tree, I have to copyout() the > entire blob into a malloc'ed buffer. >=20 > So now I need to understand how to copyin() the > blob back into the kernel address space. >=20 > Should I overwrite the FDT in the kernel with the > edited FDT? That doesn't feel quite right, but it's > essentially what the FDT code here was trying to > do before. >=20 > I could also implement something similar to file_loadraw() > that would allow me to create a new module from an > in-memory buffer. I think that might be a little cleaner. >=20 > Is there already something like this? A given DTB (loaded dynamically or statically embedded in the kernel) = has some small amount of free space inside it so it is possible to = perform in-place modifications, adding properties / nodes until you run = our of this space (libfdt code will handle cases when exceeding this and = would fail gracefully). The fixup mechanism currently implemented does = minor modifications of the device tree in this fashion. My understanding is that if you'd like to modify the blob in a major way = you need to relocate it into a new location with more padding (there's = facility for relocation in libfdt already) and then modify it = accordingly. This won't be possible however with the statically embedded = DTB in the kernel as you cannot grow this space easily. The way to go = here would be to create a DTB metadatum (as if the DTB was loaded = dynamically from standalone blob file) with sufficient space, relocate = the statically embedded original content into this metadatum, do = modifications there and pass this new copy (as part of regular loader(8) = metadata) to the kernel for processing. The building blocks are there = (DTB loaded as metadata) and should work. Rafal From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 17:03:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49037106566C for ; Tue, 15 May 2012 17:03:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E36E8FC12 for ; Tue, 15 May 2012 17:03:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8684BB911; Tue, 15 May 2012 13:03:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 15 May 2012 11:38:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151138.43864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 13:03:27 -0400 (EDT) Cc: Eric McCorkle Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 17:03:29 -0000 On Tuesday, May 15, 2012 4:00:44 am Michael Reifenberger wrote: > On Mon, 14 May 2012, Eric McCorkle wrote: > ... > > If I understand things correctly, boot2 handles the switch to > > protected mode (as well as enabling A20), both loader(8) and the > > kernel begin their execution in a protected mode environment. Can I > > get an absolute confirmation on this? Obviously if this is not the > > case, then there will need to be another (protected mode) entry point > > into the kernel. > > > > No. > *boot* and *loader should be the same on X32 and AMD64. > The kernel seems to switch to long mode in /sys/amd64/amd64/mpboot.S No. That is only for AP startup. The loader switches to long mode for an amd64 kernel before it starts the kernel. For i386, boot2 and the loader both start the kernel while running in flat 32-bit protected mode (so no paging). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 17:03:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DE651065673 for ; Tue, 15 May 2012 17:03:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 336998FC15 for ; Tue, 15 May 2012 17:03:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 91711B95B; Tue, 15 May 2012 13:03:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 15 May 2012 11:44:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> In-Reply-To: <4FB17B85.9080701@shadowsun.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205151144.38123.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 13:03:28 -0400 (EDT) Cc: Eric McCorkle Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 17:03:29 -0000 On Monday, May 14, 2012 5:39:17 pm Eric McCorkle wrote: > On 05/10/12 07:45, Marcel Moolenaar wrote: > > > > On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > > > >> Here are some specific points to be decided: > >> > >> * An EFI boot service could potentially function similarly to > >> [zfs]loader. Alternatively, it could function like > >> gpt[zfs]boot, though this might require modifying loader(8) since > >> EFI boot services run in protected/long mode, and have different > >> system information table formats. > > It seems having the EFI boot service load the kernel directly is the > way to go, based on Andrey's reply, the existing code, and my own > intuition. I just wanted to ask, in case there was some compelling > reason to have the EFI boot service load loader(8) instead. So this means /boot/loader will be an EFI service, yes? > On the other hand, I think it's a good idea to use libstand/libi386 > whenever possible, even if it ends up calling through to EFI > functions, as it keeps things standardized. Eh, not sure if we really want to do that. For example, we are probably better off using EFI's GPT parsing code than depending on all the gunk to do that in biosdisk.c. Presumably the EFI boot loader wouldn't even use biosdisk.c or bioscd.c for example, but only libstand drivers that talk to EFI. Not sure if Rui's EFI loader already does this. > Good to know. Here are some other questions/issues on my mind: > > If I understand things correctly, boot2 handles the switch to > protected mode (as well as enabling A20), both loader(8) and the > kernel begin their execution in a protected mode environment. Can I > get an absolute confirmation on this? Obviously if this is not the > case, then there will need to be another (protected mode) entry point > into the kernel. The i386 kernel assumes it starts out with a flat 32-bit mode with the kernel loaded into a contiguous memory region at a fixed physical address. If we need a relocatable kernel (as Marcel hinted at I think), then that adds a fair bit of complication. The amd64 kernel assumes it starts in long mode (the bootinfo64.c bits in the loader setup initial page tables, etc.). I think the amd64 kernel also has to be loaded into contiguous memory at a fixed physical address currently. > I know some drivers rely on BIOS calls (vga, for instance, and I think > some drivers for RAID cards do as well). These might (or might not) > need to be modified. Nah, nothing in amd64 calls the BIOS (we don't support VM86). The only thing I am aware of is the VESA bits but those use an emulator, they don't let the CPU natively run BIOS routines. i386 could be adopted to do the same, but it also doesn't make BIOS calls on modern systems outside of the VESA driver (it used to use VM86 to probe memory, but now it uses the SMAP passed in by the loader if it exists and only falls back to VM86 calls if it doesn't). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 21:30:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF2D11065686 for ; Tue, 15 May 2012 21:30:32 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id 288E18FC1B for ; Tue, 15 May 2012 21:30:31 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4FLUT6Z013409; Wed, 16 May 2012 00:30:31 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Wed, 16 May 2012 00:30:20 +0300 Message-ID: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> Date: Wed, 16 May 2012 00:30:20 +0300 From: tzabal@it.teithe.gr To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 21:30:32 -0000 Hello Community, I have the project "Automated Kernel Crash Reporting System" for this GSoC and I would like to discuss my plans about it before starting the coding on May 21. I have created a page in the FreeBSD Wiki (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) where I describe in details the architecture of the system. Here are some points that I would like to be discussed: * The implementation of the kcrashreporter is planned to be done in two shell scripts. The first shell script is a rc.d script and the second is the actual program. I choose to code it in shell because kcrashreporter invokes the kgdb to collect the necessary debugging information. I think that using the shell instead of traditional programming language for this kind of job is more straightforward and natural. Do you have a different opinion? * Can you recommend a secure way of sending a report from a FreeBSD system to the Central Collector machine? * Which data do you want kcrashreporter to collect? At the moment I have considered the panic message, the backtrace, the version level of the release, the hardware platform (uname -vm) and the configuration file of the panicked kernel (config -x `sysctl -n kern.bootfile`). * Do you propose a different Web Server than the Apache HTTP Server? For example, on my initial planning I had included MySQL as the selected DBMS and after some discussions I changed to PostgreSQL. Any comment regarding the project is more than welcome. Thank you, Tzanetos ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 01:13:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0D31065672 for ; Wed, 16 May 2012 01:13:40 +0000 (UTC) (envelope-from willingbug@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC828FC1D for ; Wed, 16 May 2012 01:13:40 +0000 (UTC) Received: by obcni5 with SMTP id ni5so353901obc.13 for ; Tue, 15 May 2012 18:13:39 -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:content-transfer-encoding; bh=9kJfnTgzR4/7PUEcZueRmAiWkHN9BMEcC3zbkphi0MM=; b=zy57bdfHgLzG+G5zkX4gvaC7eAwxGOnbvti9MpUxi1MI91PyEyp4/pnn2n30UHHYxN Z5gtfht45djP0NYZObbtGv1wNooOlxM0ba4Jftz+4gDCV8E/dGvnrxKIR0+iZLfgQOkD JGn1ddfR0urIssm6unB6i/e7OfBBFj08WZjKmVtQdxbAD+z1JfCxQkIHOKMJ3IW8bwL+ BYGuKsgn9WTV6RSLF9+cf9h1O3aBDb0H+lXidhn/7liK5tBt0orKK+nt3gzwpmHciTqN QkJ1hqDHB++g1pfe2CDhFQ49w4QwHK/TAyGs0LdgwrLvSbgN52Zh8eWhgxAGJ7ooT8Y4 1HyQ== MIME-Version: 1.0 Received: by 10.182.52.38 with SMTP id q6mr1024132obo.8.1337130818970; Tue, 15 May 2012 18:13:38 -0700 (PDT) Received: by 10.182.52.167 with HTTP; Tue, 15 May 2012 18:13:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 May 2012 09:13:38 +0800 Message-ID: From: cz li To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 01:13:40 -0000 FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? 2012/5/14 Wojciech Puchar : >> =C2=A0 I installed FreeBSD9.0 to IBM R51.Gnome startup black screen, >> only to restart.My graphics card is "82852/855GM Integrated Graphics >> Device".Is there any solution?Can you give me a detailed step? >> ? =C2=A0 =C2=A0 =C2=A0Thank you! > > > same thing here. it is not video card dependent IMHO > >> >> chao zhong li >> 2.12/5/13 >> _______________________________________________ >> 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 Wed May 16 04:55:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AECFC1065673; Wed, 16 May 2012 04:55:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 696CC8FC0C; Wed, 16 May 2012 04:55:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4G4ta7i097766; Wed, 16 May 2012 04:55:36 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cjwceifix7u97pzjty2ewj4y5s; Wed, 16 May 2012 04:55:36 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> Date: Tue, 15 May 2012 21:55:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> To: Rafal Jaworowski X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 04:55:43 -0000 On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote: >>=20 >> Should I overwrite the FDT in the kernel with the >> edited FDT? That doesn't feel quite right, but it's >> essentially what the FDT code here was trying to >> do before. >=20 > A given DTB (loaded dynamically or statically embedded in the kernel) = has some small amount of free space inside it so it is possible to = perform in-place modifications, adding properties / nodes until you run = our of this space (libfdt code will handle cases when exceeding this and = would fail gracefully). The fixup mechanism currently implemented does = minor modifications of the device tree in this fashion. I've fixed the code in sys/boot/fdt/ to do all access through = copyout/copyin. I'm waiting for a "make universe" to make sure I didn't break something inadvertently, and will probably commit it tomorrow. Right now, this just copies the DTB to a malloc-ed area, modifies the copy and then writes it back to the same place (either in the kernel or in a separately-loaded blob). It seems to work correctly even when copyout/copyin are doing address translations. > ... if you'd like to modify the blob in a major way you need to = relocate it into a new location with more padding =85. create a DTB = metadatum (as if the DTB was loaded dynamically from standalone blob = file) with sufficient space, =85. and pass this new copy (as part of = regular loader(8) metadata) to the kernel for processing. The building = blocks are there (DTB loaded as metadata) and should work. Yes, I see how that would work. Is there a real use for this? I could take a look at it once I'm finished with the current ubldr work I'm doing. Tim From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:32:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E209106566C; Wed, 16 May 2012 05:32:18 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 146448FC0C; Wed, 16 May 2012 05:32:17 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 79848B801B; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 7410CB8008; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 6E6C3BA03E; Wed, 16 May 2012 09:32:09 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 3870DBA022; Wed, 16 May 2012 09:32:09 +0400 (MSK) Message-ID: <4FB33BD9.3030501@FreeBSD.org> Date: Wed, 16 May 2012 09:32:09 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> In-Reply-To: <201205151144.38123.jhb@freebsd.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-hackers@freebsd.org, Eric McCorkle Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:32:18 -0000 On 15.05.2012 19:44, John Baldwin wrote: >> It seems having the EFI boot service load the kernel directly is the >> way to go, based on Andrey's reply, the existing code, and my own >> intuition. I just wanted to ask, in case there was some compelling >> reason to have the EFI boot service load loader(8) instead. > > So this means /boot/loader will be an EFI service, yes? No, EFI services are things that EFI firmware provides. Our /boot/loader will be an EFI application and it will use EFI services. >> On the other hand, I think it's a good idea to use libstand/libi386 >> whenever possible, even if it ends up calling through to EFI >> functions, as it keeps things standardized. > > Eh, not sure if we really want to do that. For example, we are probably > better off using EFI's GPT parsing code than depending on all the gunk to do > that in biosdisk.c. As i see we already have sys/boot/efi/libefi/efipart.c that uses EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL provides access to each disk and partition. AFAIK it supports only GPT and MBR+EBR, so there might be some problems with ZFS support, because we can use ZFS atop of BSD partition. > Presumably the EFI boot loader wouldn't even use biosdisk.c or bioscd.c for > example, but only libstand drivers that talk to EFI. Not sure if Rui's EFI > loader already does this. AFAIK, ia64 loader works in that way. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:37:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34B83106564A for ; Wed, 16 May 2012 05:37:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 702398FC15 for ; Wed, 16 May 2012 05:37:16 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4G5anJX026746; Wed, 16 May 2012 07:36:51 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4G5amN8026743; Wed, 16 May 2012 07:36:49 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 May 2012 07:36:48 +0200 (CEST) From: Wojciech Puchar To: Aryeh Friedman 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 May 2012 07:36:52 +0200 (CEST) Cc: FreeBSD Mailing List Subject: Re: diagonising a overheating problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:37:27 -0000 diagonising? means diagnosing agonising? good word :) > that for some reason the FreeBSD CPU/bus speed controls and such are > not working based on the following item I found in my dmesg's: > > acpi_tz0: _CRT value is absurd, ignored (-273.2C) > seems like superfluid helium produced in that temperature fills whole machine and turns some insulators to superconductors resulting in faults ;) Or actually - thermometer chip on your motherboard failed, and because of it no fans turn on because temperature is "low". From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:40:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FDB106564A for ; Wed, 16 May 2012 05:40:13 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id C5E0E8FC08 for ; Wed, 16 May 2012 05:40:12 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4G5e3sX026761; Wed, 16 May 2012 07:40:03 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4G5e359026758; Wed, 16 May 2012 07:40:03 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 May 2012 07:40:02 +0200 (CEST) From: Wojciech Puchar To: David Brodbeck In-Reply-To: Message-ID: References: <20120430085748.GA56921@server.vk2pj.dyndns.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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 May 2012 07:40:03 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Peter Jeremy Subject: Re: NFS - slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:40:13 -0000 >> same. am i doing something wrong? > > I found NFSv4 to be much *slower* than NFSv3 on FreeBSD, when I > benchmarked it a year or so ago. both are just right in you read (NFSv4 taking a bit more CPU), and both are awful at writes. for me now the only way to get NFS working well is to use unfsd with fsync commented out in sources. get very fast and not compliant with NFS protocol, which i don't care. i don't have database logs on NFS, but sometimes need to run non freebsd device without HDD and compile something using NFS disk. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:41:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EA88106566C for ; Wed, 16 May 2012 05:41:08 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 746028FC0C for ; Wed, 16 May 2012 05:41:07 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4G5f2QP026772; Wed, 16 May 2012 07:41:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4G5f2ZF026769; Wed, 16 May 2012 07:41:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 May 2012 07:41:01 +0200 (CEST) From: Wojciech Puchar To: Stephen Montgomery-Smith In-Reply-To: <4FA56943.7020508@missouri.edu> Message-ID: References: <20120504191111.153790@gmx.com> <20120504234220.5ba8141b@bhuda.mired.org> <201205051511.08578.mitchell@wyatt672earp.force9.co.uk> <4FA56943.7020508@missouri.edu> 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.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 May 2012 07:41:02 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Ways to promote FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:41:08 -0000 great idea! On Sat, 5 May 2012, Stephen Montgomery-Smith wrote: > Find some mailing lists that have nothing to do with FreeBSD, and barrage > them with spam promoting FreeBSD. > > :-) > _______________________________________________ > 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 16 05:42:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F4B106566C; Wed, 16 May 2012 05:42:10 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id B87EB8FC0A; Wed, 16 May 2012 05:42:09 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4G5fxYm026783; Wed, 16 May 2012 07:41:59 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4G5fwn0026780; Wed, 16 May 2012 07:41:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 May 2012 07:41:58 +0200 (CEST) From: Wojciech Puchar To: Devin Teske In-Reply-To: Message-ID: References: <20120504191111.153790@gmx.com> <20120504234220.5ba8141b@bhuda.mired.org> <3FFA8D05-005B-4405-ACD7-E8473F9BDCBE@fisglobal.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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 May 2012 07:42:00 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Devin Teske , Mike Meyer Subject: Re: Ways to promote FreeBSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:42:10 -0000 > Today, FreeBSD works on some of the most powerful equipment in the world. Equipment where price is hardly an issue. We have a great many to thank for that. and works on low end hardware. The same FreeBSD and it can be tuned well for both cases. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 05:43:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA4461065677 for ; Wed, 16 May 2012 05:43:39 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 27BA08FC14 for ; Wed, 16 May 2012 05:43:38 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4G5hXLk026790; Wed, 16 May 2012 07:43:34 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4G5hXJs026787; Wed, 16 May 2012 07:43:33 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 May 2012 07:43:33 +0200 (CEST) From: Wojciech Puchar To: tzabal@it.teithe.gr In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> Message-ID: References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> 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.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 May 2012 07:43:34 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 05:43:39 -0000 sorry if off topic but is today Google needed to do anything and must supervise everything? Cannot people just write a code as they always did? > I have created a page in the FreeBSD Wiki > (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 06:43:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 903341065672 for ; Wed, 16 May 2012 06:43:21 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8B88FC17 for ; Wed, 16 May 2012 06:43:21 +0000 (UTC) Received: from kibab-darwin.local (unknown [46.115.52.32]) by mx0.deglitch.com (Postfix) with ESMTPSA id 0E3478FC2D; Wed, 16 May 2012 10:43:17 +0400 (MSK) Message-ID: <4FB34CF0.6000306@kibab.com> Date: Wed, 16 May 2012 08:45:04 +0200 From: Ilya Bakulin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tzabal@it.teithe.gr References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5229D14324EBB1C89B86CA14" Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 06:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5229D14324EBB1C89B86CA14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15.05.12 23:30, tzabal@it.teithe.gr wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for this > GSoC and I would like to discuss my plans about it before starting the > coding on May 21. > * Can you recommend a secure way of sending a report from a FreeBSD > system to the Central Collector machine? > You can use scp(1) and ship a SSH public key with your software. The target server must be configured to disable PTY allocation for this key, so only SCP/SFTP transfer will be possible. > * Which data do you want kcrashreporter to collect? At the moment I > have considered the panic message, the backtrace, the version level of > the release, the hardware platform (uname -vm) and the configuration > file of the panicked kernel (config -x `sysctl -n kern.bootfile`). Collecting the list of loaded modules (kldstat) is also nessesary :-) > * Do you propose a different Web Server than the Apache HTTP Server? > For example, on my initial planning I had included MySQL as the > selected DBMS and after some discussions I changed to PostgreSQL. As far as I remember, you're going to use PHP as a programming language? In this case Apache is a good choice. I would however recommend using www/nginx and PHP in FastCGI mode (FPM option in lang/php5 port). This is a preffered setup for almost all Russian highloaded websites. At the beginning using Apache is a reasonable choice. --=20 Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru --------------enig5229D14324EBB1C89B86CA14 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.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zTPUACgkQo9vlj1oadwjIKACcDJ7BVhon2VjrWckpio/lKTna X1YAn0m5+JlPfi6qe4WWElGcuhC2KEiJ =aPwK -----END PGP SIGNATURE----- --------------enig5229D14324EBB1C89B86CA14-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 06:46:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3030B106566C for ; Wed, 16 May 2012 06:46:28 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id D014C8FC1E for ; Wed, 16 May 2012 06:46:27 +0000 (UTC) Received: from kibab-darwin.local (unknown [46.115.52.32]) by mx0.deglitch.com (Postfix) with ESMTPSA id BF4688FC27; Wed, 16 May 2012 10:46:24 +0400 (MSK) Message-ID: <4FB34DAF.5000901@kibab.com> Date: Wed, 16 May 2012 08:48:15 +0200 From: Ilya Bakulin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tzabal@it.teithe.gr References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig52C2EB5AF83D2754548C9B61" Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 06:46:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig52C2EB5AF83D2754548C9B61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15.05.12 23:30, tzabal@it.teithe.gr wrote: > * The implementation of the kcrashreporter is planned to be done in > two shell scripts. Are you really going to name your program "kcrashreporter"? I'd suggest using a different name since everything matching "^k" is automatically associated with KDE Project :-) --=20 Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru --------------enig52C2EB5AF83D2754548C9B61 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.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+zTa8ACgkQo9vlj1oadwiSxgCguXuzq5bhtZVKghXGcAhzIDLo RDIAoMe+My5JpBCG9hObEy8h8nkNWqn+ =beZO -----END PGP SIGNATURE----- --------------enig52C2EB5AF83D2754548C9B61-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 11:14:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19194106566B for ; Wed, 16 May 2012 11:14:58 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id 818F08FC1A for ; Wed, 16 May 2012 11:14:57 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4GBEvAh005603; Wed, 16 May 2012 14:14:57 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Wed, 16 May 2012 14:14:53 +0300 Message-ID: <20120516141453.127614gk3lnkc6jx@webmail.teithe.gr> Date: Wed, 16 May 2012 14:14:53 +0300 From: tzabal@it.teithe.gr To: Wojciech Puchar References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 11:14:58 -0000 Quoting Wojciech Puchar : > sorry if off topic but is today Google needed to do anything and > must supervise everything? Cannot people just write a code as they > always did? I think that Google only suggests the 21st of May the starting date for coding. If you start earlier, you will not face any penalties. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 11:45:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64A40106566C for ; Wed, 16 May 2012 11:45:27 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id B30458FC08 for ; Wed, 16 May 2012 11:45:26 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4GBjSrM008453; Wed, 16 May 2012 14:45:29 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Wed, 16 May 2012 14:45:24 +0300 Message-ID: <20120516144524.19813u8j0pnxpbh0@webmail.teithe.gr> Date: Wed, 16 May 2012 14:45:24 +0300 From: tzabal@it.teithe.gr To: Ilya Bakulin References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <4FB34CF0.6000306@kibab.com> In-Reply-To: <4FB34CF0.6000306@kibab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 11:45:27 -0000 Quoting Ilya Bakulin : > On 15.05.12 23:30, tzabal@it.teithe.gr wrote: >> Hello Community, >> >> I have the project "Automated Kernel Crash Reporting System" for this >> GSoC and I would like to discuss my plans about it before starting the >> coding on May 21. > >> * Can you recommend a secure way of sending a report from a FreeBSD >> system to the Central Collector machine? >> > You can use scp(1) and ship a SSH public key with your software. The > target server must be configured to disable PTY allocation for this key, > so only SCP/SFTP transfer will be possible. Good, this is a scenario that I was looking for. >> * Which data do you want kcrashreporter to collect? At the moment I >> have considered the panic message, the backtrace, the version level of >> the release, the hardware platform (uname -vm) and the configuration >> file of the panicked kernel (config -x `sysctl -n kern.bootfile`). > Collecting the list of loaded modules (kldstat) is also nessesary :-) You are right. Added to the list. >> * Do you propose a different Web Server than the Apache HTTP Server? >> For example, on my initial planning I had included MySQL as the >> selected DBMS and after some discussions I changed to PostgreSQL. > As far as I remember, you're going to use PHP as a programming language? Yes, PHP along with SQL for the Server Side part. > In this case Apache is a good choice. I would however recommend using > www/nginx and PHP in FastCGI mode (FPM option in lang/php5 port). This > is a preffered setup for almost all Russian highloaded websites. > At the beginning using Apache is a reasonable choice. I have never used nginx before. I have considered also the lighttpd. Both with BSD licenses (nginx with a 2-clause BSD like license) and FastCGI support. As I read from Wikipedia, PHP performance has received special attention in lighttpd. I will test both Web servers and then I will make up my mind. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 11:55:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6911065673 for ; Wed, 16 May 2012 11:55:32 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id 19A868FC16 for ; Wed, 16 May 2012 11:55:31 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4GBtY4e009558; Wed, 16 May 2012 14:55:34 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Wed, 16 May 2012 14:55:30 +0300 Message-ID: <20120516145530.22443uhwtvtjz0s2@webmail.teithe.gr> Date: Wed, 16 May 2012 14:55:30 +0300 From: tzabal@it.teithe.gr To: Ilya Bakulin References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <4FB34DAF.5000901@kibab.com> In-Reply-To: <4FB34DAF.5000901@kibab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 11:55:32 -0000 Quoting Ilya Bakulin : > On 15.05.12 23:30, tzabal@it.teithe.gr wrote: >> * The implementation of the kcrashreporter is planned to be done in >> two shell scripts. > Are you really going to name your program "kcrashreporter"? I'd suggest > using a different name since everything matching "^k" is automatically > associated with KDE Project :-) As you already said, everything starting with a 'k' is automatically associated with the KDE Project, but only in the Desktop world. Many FreeBSD tools that are related with the kernel starts with a 'k' too. For example consider the Kernel Debugger (kgdb), the program for displaying the loaded kernel modules (kldstat) and the programs for loading (kldload) and unloading (kldunload) a module from the kernel. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 12:35:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5071065753 for ; Wed, 16 May 2012 12:35:14 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4A5E28FC0C for ; Wed, 16 May 2012 12:35:05 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT7Oe8p6Wp2JaHkEFvyZHT1cngN7zee2a@postini.com; Wed, 16 May 2012 05:35:10 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 May 2012 05:34:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 16 May 2012 08:34:23 -0400 From: Andrew Duane To: "tzabal@it.teithe.gr" , "freebsd-hackers@freebsd.org" Date: Wed, 16 May 2012 08:34:24 -0400 Thread-Topic: GSoC Project: Automated Kernel Crash Reporting System - Discussion Thread-Index: Ac0y4gRRBZs8nNz6Q4GvsiHWOuryTwAfHjnw Message-ID: References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: RE: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 12:35:14 -0000 SSdtIGludGVyZXN0ZWQgaW4gdGhlIHNlcnZlciBzaWRlIG9mIHRoaXMgcHJvamVjdCwgYXMgaXQn cyBzb21ldGhpbmcgd2UndmUgYmVlbiB3b3JraW5nIG9uIGhlcmUuIFdlIGFyZSBkZXZlbG9waW5n IGFuIGludGVybmFsIHRvb2wgZm9yIG91ciBvd24gY3Jhc2ggcmVwb3J0aW5nIHRoYXQgZG9lcyBh bmFseXNpcyBvZiBiYWNrdHJhY2VzIGFuZCBwcm92aWRlcyBhIHByZXR0eSBhY2N1cmF0ZSBzeW5v cHNpcyBvZiB3aGF0IGhhcHBlbmVkLiBJIGhhdmUgYSBzZXQgb2YgaGV1cmlzdGljcyB0aGF0IGNh biBmaW5kIHZhcmlvdXMgcGFuaWMgYW5kIHRyYXAgaXNzdWVzIGFjcm9zcyBkaWZmZXJlbnQgQ1BV IGFyY2hpdGVjdHVyZXMsIGFuZCB3YWxrIHVwIHRoZSB0cmFjZSB0byB0aGUgcmVhbCBjdWxwcml0 LiBUaGlzIGluY2x1ZGVzLCBmb3IgZXhhbXBsZSwgdGhhdCBpZiBtZW1zZXQgdHJhcHMgdGhlIHJl YWwgcHJvYmxlbSB3YXMgbWVtc2V0J3MgY2FsbGVyLCBub3QgbWVtc2V0IGl0c2VsZi4NCg0KV2Ug dGhlbiB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBiZSBhYmxlIHRvIHNlYXJjaCBmb3IgZHVwbGlj YXRlIGJ1ZyByZXBvcnRzIGJlZm9yZSBvcGVuaW5nIG5ldyBvbmVzLCBhbmQgY2FuIGhlbHAgYXNz aWduIHRvIHRoZSByaWdodCB0ZWFtIGJhc2VkIG9uIHNvbWUgbGlzdHMgb2YgZmlsZSBhbmQvb3Ig cm91dGluZSBwYXR0ZXJucy4gVGhlcmUgaXMgYWxzbyBhICJoaW50IiBmYWNpbGl0eSB0byBleHRl bmQgdGhlIGNyYXNoIGR1bXAgZGF0YSBjb2xsZWN0aW9uIGZvciBkaWZmZXJlbnQga2luZHMgb2Yg Y3Jhc2hlcyAoZS5nLiBtZW1vcnkgZXhoYXVzdGlvbiwgbG9jayBpc3N1ZXMsIGV0Yy4pDQoNCsKg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCkFuZHJldyBEdWFuZQ0KSnVuaXBl ciBOZXR3b3Jrcw0KKzEgOTc4LTU4OS0wNTUxIChvKQ0KKzEgNjAzLTc3MC03MDg4IChtKQ0KYWR1 YW5lQGp1bmlwZXIubmV0DQoNCsKgDQoNCg== From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 13:25:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96B861065670 for ; Wed, 16 May 2012 13:25:01 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3E58C8FC0A for ; Wed, 16 May 2012 13:25:01 +0000 (UTC) Received: (qmail 32239 invoked from network); 16 May 2012 09:24:55 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 16 May 2012 09:24:55 -0400 Message-ID: <4FB3AAA6.3090708@shadowsun.net> Date: Wed, 16 May 2012 09:24:54 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> In-Reply-To: <201205151144.38123.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------050608040106050909000000" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 13:25:01 -0000 This is a multi-part message in MIME format. --------------050608040106050909000000 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/15/12 11:44, John Baldwin wrote: > The i386 kernel assumes it starts out with a flat 32-bit mode with > the kernel loaded into a contiguous memory region at a fixed > physical address. If we need a relocatable kernel (as Marcel > hinted at I think), then that adds a fair bit of complication. > > The amd64 kernel assumes it starts in long mode (the bootinfo64.c > bits in the loader setup initial page tables, etc.). I think the > amd64 kernel also has to be loaded into contiguous memory at a > fixed physical address currently. > Seems like an initial workaround could be to allocate a space big enough for all the necessary ELF segments, and split it up ourselves. Do the kernel and modules actually do anything that depends on being in a contiguous space in some way (ie some relocation trick)? Because it seems like it shouldn't really matter otherwise. > Nah, nothing in amd64 calls the BIOS (we don't support VM86). The > only thing I am aware of is the VESA bits but those use an > emulator, they don't let the CPU natively run BIOS routines. i386 > could be adopted to do the same, but it also doesn't make BIOS > calls on modern systems outside of the VESA driver (it used to use > VM86 to probe memory, but now it uses the SMAP passed in by the > loader if it exists and only falls back to VM86 calls if it > doesn't). Yeah, I've seen the x86emu code, when I was trying to track down a suspend/resume problem. The thing I'm wondering is if the BIOS info/code will even be there at all when EFI booting. I suppose the only way to really know is to get the kernel booting and see... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPs6qmAAoJENSCzbQ+koZ7JOUP+QF6XWyiTfiVmWQifzgkZWzi BaOzqeDsQjlMqvf6W8Xb0MzQNWdtqhtEEf3d5528UEWWzcKEji9ra9+CuBQZA3Iv kramgQgC6kSfS8GocTTmoY6VcigTBT4IJpTRRmX2juYV1X5pJe9wSklNh1Cj7/nG azy2eB5lAlAArtGPew7pDPuyiiTFkfZ6Zxcy64g+h/eQ8esJW6n9UN87swHmfcHH u3pX433fbFNOnLihpSzYP97bzZjwHJJZXEmlezOVIvxjoJfZIxeCl7KOwZUh3Q0Z +TbC+++WLGEdmpnDUYhu2/THP776Un/Jpkk4rRo1wPlXFRHv6T9aQJsju1onqG3C KruEUPBTA8TLNid2gY0JPx1MHkTerxMezdr5/6ycEw6Anr4JE5xGT7GKBKiLmxCB 7hZnDcvdqJ3MFVk5gdBuKC608Z96bG0akB2z77ich0f7A78cc6WoSY45ksZMEzt4 8CjDbmPlcLGqNlH29wveIMbE+nUyVc+oOrK3qTlvQPloGpKewEnC3bgYxAMgW2d2 KF1HuIfg9yqtyi8t2W6I1qhY1BufalcNOde8R01lRvCji1tZVbdq/+uydHPyO2Ie uJ99zT1o9Nq4p53+5l1cRjgOLjZnr01h94r35vT/q7Mni6SUZN/rmlLc7pyvxMg5 yS6VWWlwBgUV/UZiQSxn =tWkp -----END PGP SIGNATURE----- --------------050608040106050909000000-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 13:56:33 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32BB41065670; Wed, 16 May 2012 13:56:33 +0000 (UTC) (envelope-from inebriateh97@rsi.com) Received: from vodafone.it (net-188-217-211-138.cust.dsl.vodafone.it [188.217.211.138]) by mx1.freebsd.org (Postfix) with ESMTP id C95158FC0C; Wed, 16 May 2012 13:56:32 +0000 (UTC) Received: from apache by kcladcjbkdmerjgkemtge.barronheating.com with local (Exim 4.63) (envelope-from <, , >) id Z1K52E-T7SMXM-8X for , , ; Wed, 16 May 2012 14:56:31 +0100 To: , , Date: Wed, 16 May 2012 14:56:31 +0100 From: , , Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Cc: Subject: Your monthly income can be increased to 1950 dollars paid. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 13:56:33 -0000 We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email Curtis@eureseurope.com and I will answer you personally as soon as possible Sincerely, Curtis Ali From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 14:00:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB5CB106564A for ; Wed, 16 May 2012 14:00:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 42A258FC18 for ; Wed, 16 May 2012 14:00:44 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so5393783wgb.1 for ; Wed, 16 May 2012 07:00:43 -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=iitCo1De3X+pRspUPlAZUogtZjHOz/9vmRNyXevDNdM=; b=XEjCjsbtoiVL34vksY3ldvxAgSKNQT+8IWIk8mpEJ1REn14OvqwcHSfO1AyhKJsi3l 2Bu8EqmDhLNbHWJW/5vT7b2Ras/tfezNHNdXnBa+IWUEjfONfZgSO5LhO8J5TODtkOlq b8dfP5rbt07XvWEEkAMWMHTQCT7ygLtYhHXCXQsQXpvgBlU95eQJ7l0CvizhaEdPculJ 7EnxaAaMGkMpHUX8XKNlRPEzABUF/8l5NWLMT5MnRy1ypa1eqziR0NSVPuajTJTTEuiF 7PHJ9LYn4k5ythwVuE2O3YwRTvwNyE/UyNedz6+x3XWdLJQmegkSEXXyE5ygN0Yo64oX zt+w== Received: by 10.180.92.130 with SMTP id cm2mr8394241wib.4.1337176842776; Wed, 16 May 2012 07:00:42 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id h8sm9395880wix.4.2012.05.16.07.00.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 07:00:41 -0700 (PDT) Date: Wed, 16 May 2012 16:00:33 +0200 From: Mateusz Guzik To: tzabal@it.teithe.gr Message-ID: <20120516140033.GB2470@dft-labs.eu> References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:00:44 -0000 On Wed, May 16, 2012 at 12:30:20AM +0300, tzabal@it.teithe.gr wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for > this GSoC and I would like to discuss my plans about it before > starting the coding on May 21. > Cogratulations. :) > I have created a page in the FreeBSD Wiki (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. > > Here are some points that I would like to be discussed: > > * The implementation of the kcrashreporter is planned to be done in > two shell scripts. The first shell script is a rc.d script and the > second is the actual program. I choose to code it in shell because > kcrashreporter invokes the kgdb to collect the necessary debugging > information. I think that using the shell instead of traditional > programming language for this kind of job is more straightforward > and natural. Do you have a different opinion? > Are you going to support textdumps? I would like to note that some machines have swap space only for textdumps, so I think you should support these. ddb is equiped with a lot of cool commands that show various important debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such facilities so you will have to implement those first if you decide to use it (btw I think these would be useful even without this project). Take a look at tools/debugscripts. That being said, I would give a priority to support for textdumps (and in case kgdb support cannot be finished in time, I would make sure that the project is expendable enough to support information obtained from kgdb and possibly other sources). > * Can you recommend a secure way of sending a report from a FreeBSD > system to the Central Collector machine? > I don't know if these are good ideas (no clue about cryptography), but I would either: - HTTP POST data over SSL or - HTTP POST data encrypted with some public key > * Which data do you want kcrashreporter to collect? At the moment I > have considered the panic message, the backtrace, the version level > of the release, the hardware platform (uname -vm) and the > configuration file of the panicked kernel (config -x `sysctl -n > kern.bootfile`). > hardware information, dmesg, locks, locked vnodes, mount points, ps, backtraces of all threads Basically if ddb can show something easly enough (or you will be able to make it do so), the report should contain it. > * Do you propose a different Web Server than the Apache HTTP Server? > For example, on my initial planning I had included MySQL as the > selected DBMS and after some discussions I changed to PostgreSQL. > I guess this site won't be very busy, so whatever popular httpd you will choose it should be fine (although I would stick with either apache or nginx). No clue about databases. Also it would be nice to have a way to contact the owner of machine that submitted the report. One way I can think of is the ability to specify e-mail address (say in rc.conf?) that will be included in the report. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 16:40:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD584106564A for ; Wed, 16 May 2012 16:40:39 +0000 (UTC) (envelope-from s@samu.pl) Received: from mail.mydevil.net (mail.mydevil.net [94.23.92.220]) by mx1.freebsd.org (Postfix) with ESMTP id 93EB58FC0C for ; Wed, 16 May 2012 16:40:39 +0000 (UTC) Received: from [192.168.1.101] (user-109-243-244-3.play-internet.pl [109.243.244.3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mydevil.net (Postfix) with ESMTPSA id DAC03ACCF for ; Wed, 16 May 2012 18:30:42 +0200 (CEST) Message-ID: <4FB3D65E.4020107@samu.pl> Date: Wed, 16 May 2012 18:31:26 +0200 From: =?UTF-8?B?SmFrdWIgU3phZnJhxYRza2k=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org. X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Separating IP addresses between users X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 16:40:39 -0000 Hi! So, I was given a task to separate IP addresses from (or between) users. The server has two groups of IP addresses, public and private. A public IP can be used by any user. A private IP can be used only by one, specific user. At the beginning, there were two obvious ways to perform this: a firewall, and jails. IPFW offers uid-based rules, but after some tests that didn't end up very well - the server used to freeze, or even crash because of this. So - jails. That would be a good way, I could even use the same rootfs for every jail to avoid tons of mountpoints, and I could specify a list of IP addresses for evey jail (a standard public pool, and one or more private IP, if it belongs to an user). So I've made a virtual machine and, unfortunatelly, I had to hit the ground - with more than 600-700 users the system used to freeze for 5-10 seconds each 1-2 minute, and then come back with a load of 700 and more. When I started something like 850-900 jails, the system was useless. And here, I need to separate more than 2000 users. Maybe this is the wrong maillist to ask such questions, but what would be the best approach to do this task? Has anybody tried to do this before? If not, can it be done in MAC framework, as a loadable module, or do I have to dig deeper? As usual: sorry for my bad english, it's not my native language. -- Best regards, Jakub SzafraÅ„ski From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 16:43:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84BB7106564A for ; Wed, 16 May 2012 16:43:47 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 024C68FC08 for ; Wed, 16 May 2012 16:43:46 +0000 (UTC) Received: by laai10 with SMTP id i10so924628laa.13 for ; Wed, 16 May 2012 09:43: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=Vqvrm3vCnolL4WJZQLr+EPpQBI+wcSmGuHEikqn4ayo=; b=F3HrR5DQrak7PNLKvWhwIxIJjdKN4hIudnY5Z6HzE/K8vZMfiCaW1SFjYIWBHf2NhB JLls46MtneShaL3CAW4NQpoax1l7d/BFzbzwqVgChOvdHWGQt9piZvAoA/zwldyaRs1l DrbSG50G8X6fbq9vDpOjMkhiBTO63DD6ZMjwvSXdhjSYDI6GVQXQIQWE5kQTfh+dvY75 9P1PajJ+hjHi/Ev6mJqg5N5UGSGgs31rKQD2GnkeeW1uYQwbZwBiV+v0EqdONny/WYXZ sgAKgWFCFytnOZbb0R10L+H7z69lPRnOIfBOzR1QUUJrW8PThd/QcxfoVK/NHYNM6bC6 q1jg== MIME-Version: 1.0 Received: by 10.112.99.71 with SMTP id eo7mr1633981lbb.84.1337186625599; Wed, 16 May 2012 09:43:45 -0700 (PDT) Received: by 10.152.24.131 with HTTP; Wed, 16 May 2012 09:43:45 -0700 (PDT) In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> Date: Wed, 16 May 2012 18:43:45 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: tzabal@it.teithe.gr Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 16:43:47 -0000 On Tue, May 15, 2012 at 11:30 PM, wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for this GSoC > and I would like to discuss my plans about it before starting the coding on > May 21. > > I have created a page in the FreeBSD Wiki > (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. > > Here are some points that I would like to be discussed: > > * The implementation of the kcrashreporter is planned to be done in two > shell scripts. The first shell script is a rc.d script and the second is the > actual program. I choose to code it in shell because kcrashreporter invokes > the kgdb to collect the necessary debugging information. I think that using > the shell instead of traditional programming language for this kind of job > is more straightforward and natural. Do you have a different opinion? > > * Can you recommend a secure way of sending a report from a FreeBSD system > to the Central Collector machine? > > * Which data do you want kcrashreporter to collect? At the moment I have > considered the panic message, the backtrace, the version level of the > release, the hardware platform (uname -vm) and the configuration file of the > panicked kernel (config -x `sysctl -n kern.bootfile`). I wonder if it would be good to have a configuration file to specify the amount of information (the type of, also) the system is going to send. Just my 2 cents. > > * Do you propose a different Web Server than the Apache HTTP Server? For > example, on my initial planning I had included MySQL as the selected DBMS > and after some discussions I changed to PostgreSQL. > > > Any comment regarding the project is more than welcome. > > Thank you, > Tzanetos > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > 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 16 19:36:17 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E0761065672 for ; Wed, 16 May 2012 19:36:17 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BACC8FC1F for ; Wed, 16 May 2012 19:36:16 +0000 (UTC) Received: by bkvi18 with SMTP id i18so1265145bkv.13 for ; Wed, 16 May 2012 12:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=EvNH4M8WjoEmTEaBV4apKBpLFysaLSvCEemI0vvVm5U=; b=wFHEq4SlD2Vzr61u6XYbTUN/j/LefUYgz3cLnfuliOE+M5SJgd7Xv3ykBKyY4RX6WR rfllkfOl91Rs6soIQ6nWmXudHFQiH5rmgbNsv8LEQZkOOCvk4bw6bigYk3VvD2rIS4hM 9eIpkX5imHCSlj8r6nnsIX6ygS3up+jMYxg7s3BlVrAtd2Dm7RPNXihZAMujRIc05F3k d3rxCQxlgZxY/hKa5Ts+4R0X02LudInAGTwod5W1Ns9lTiW9ZyCIo99MsDVTjCyHGKHn 6pZ6mB0o8vGl4EN6chrvDB4IHUT/tilVDT+0VmERyI6MCxfjw9w5r0HxgmoDHTDbjI9I GjkQ== Received: by 10.205.130.6 with SMTP id hk6mr1686405bkc.64.1337196975364; Wed, 16 May 2012 12:36:15 -0700 (PDT) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id zx16sm7158505bkb.13.2012.05.16.12.36.11 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 12:36:13 -0700 (PDT) Message-ID: <20120516.193613.183.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Wed, 16 May 2012 21:36:13 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Periodic ports checksum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 19:36:17 -0000 REL 8.2 added script for finding installed port's files, with mismatched = checksum:=0D=0A/etc/periodic/security/460.chkportsum=0D=0A=0D=0AIt also = said to look for it at # man 5 periodic.conf=0D=0A=0D=0AHowever, even up = to now in REL 9.0, there is no reference to it, in man = pages.=0D=0A--=0D=0Adaily_status_security_chkportsum_enable=3D=0D=0A--=0D=0A..., = is missing.=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 20:28:06 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2415A1065672 for ; Wed, 16 May 2012 20:28:06 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id C35038FC0C for ; Wed, 16 May 2012 20:28:05 +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=ybAg61 6S1DYMnp/seZHRYTs0y28pCkoVE0NLHoI3qvfXXoDcNLbtlwjujABYu2D6ICk0Ao eJabCjBpwnEqJvOpCpP460Zk/TXP/O0D1wIf0X7FPT25IzTSs01WTMTdQm+Emccs y/aiOo8lqBy+nS9hY51/0WKnpX8SPBv2vbGfU= 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=+2NRk1icqqNi mqEXOOXdgRkx/KdXK6Wp/aikZDkeWCU=; b=P5XPv46ETfQxKGTZgPSOgWTk+/Gh xHaYkKkUa0SbHZwPuF6FD0OhTuL3Zj1KipKgIEc/hPVbizKJik4S3A0nI5iqXFJ9 uS7nyCzTQiKW0VDNkCkUQuhmb9nskahEaXWRg1xXlErg6eL6p2PqzohSKSaPJ1L+ cAswIrc48QdVqyM= Received: (qmail 85233 invoked from network); 16 May 2012 15:28:04 -0500 Received: from unknown (HELO ?192.168.0.107?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 16 May 2012 15:28:04 -0500 Message-ID: <4FB40DD3.3000202@shatow.net> Date: Wed, 16 May 2012 15:28:03 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: rank1seeker@gmail.com References: <20120516.193613.183.2@DOMY-PC> In-Reply-To: <20120516.193613.183.2@DOMY-PC> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Periodic ports checksum X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:28:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/16/2012 02:36 PM, rank1seeker@gmail.com wrote: > REL 8.2 added script for finding installed port's files, with > mismatched checksum: /etc/periodic/security/460.chkportsum > > It also said to look for it at # man 5 periodic.conf > > However, even up to now in REL 9.0, there is no reference to it, in > man pages. -- daily_status_security_chkportsum_enable= -- ..., is > missing. > Thank you for your report. I've filed a PR with patch to update the manpage and CC'd you. Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPtA3RAAoJEG54KsA8mwz52hYP/2Si1++1+hAgm1+uL47ivqIY FKorUG+2RFYV2YktqDGRM8WNJ3O+wtbJBLOer+Wnl9qlUgcDdzKyUB7IBHMKJsoa KTCPJzUM6lhyhLqyRUXIOqMfxeV4xMMPZOX5vXRYJ+dd8K0Y+aVjVB8iW4JxDugC D2U/oTI2352naIimuu2pEYU0ntATSeMCLek6DA99yT0hqlcF88qZtlG3NWpfWzcl iEQ7GF1Sbsh2Yy3L4ABqlvCBck9DYSk3z2niAhnqcYgRLnep9rtgsfyqMsLw7IlL 68ABE5Couz+CuHK/yA82I1/DjScs4AgMJ6cTe0L7dsjqcBj1ZNN9U1o4VXIGcR+4 LhEtc03juHqAg8vXzEtZ6+goXXAp8txAHGwvtamXupUFqVnXdMg6xdU9qInJqbxl JGwvwqhtyh57aNdGuWiwhmg6i/Y8QocelM3i8YKpmY+xfAzKGQtArrv5lUKUyII8 x0z88FF1TTn3PZoHD8n+4APumrNrLjp8QJ0Il5KH8BLo7Gf/4rCkSOAB4Bw4zRFe DnzFAsrA3dwJOY39EJ6IyksowdnjB26Y7ZtXZCS0xrv5Lt/ISUF8kH0ctSL+d8up dnK8mt4OTUVQdYTP9fhkl3lBx54qNzksp+C1FGP94Yuu0/CdrjkK1G0REY5LE78/ +Iyi6lqwvMGfsmbAbuMK =c8y8 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 20:37:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBE2A106566B for ; Wed, 16 May 2012 20:37:47 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id 29FE28FC15 for ; Wed, 16 May 2012 20:37:46 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4GKbq3c029560; Wed, 16 May 2012 23:37:53 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Wed, 16 May 2012 23:37:44 +0300 Message-ID: <20120516233744.1314398bowqaykuw@webmail.teithe.gr> Date: Wed, 16 May 2012 23:37:44 +0300 From: tzabal@it.teithe.gr To: Mateusz Guzik References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> In-Reply-To: <20120516140033.GB2470@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:37:47 -0000 Quoting Mateusz Guzik : > On Wed, May 16, 2012 at 12:30:20AM +0300, tzabal@it.teithe.gr wrote: >> Hello Community, >> >> I have the project "Automated Kernel Crash Reporting System" for >> this GSoC and I would like to discuss my plans about it before >> starting the coding on May 21. >> > > Cogratulations. :) > >> I have created a page in the FreeBSD Wiki >> (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) >> where I describe in details the architecture of the system. >> >> Here are some points that I would like to be discussed: >> >> * The implementation of the kcrashreporter is planned to be done in >> two shell scripts. The first shell script is a rc.d script and the >> second is the actual program. I choose to code it in shell because >> kcrashreporter invokes the kgdb to collect the necessary debugging >> information. I think that using the shell instead of traditional >> programming language for this kind of job is more straightforward >> and natural. Do you have a different opinion? >> > > Are you going to support textdumps? > > I would like to note that some machines have swap space only for > textdumps, so I think you should support these. Support for textdumps is already on the list. > ddb is equiped with a lot of cool commands that show various important > debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such > facilities so you will have to implement those first if you decide to > use it (btw I think these would be useful even without this project). > Take a look at tools/debugscripts. > That being said, I would give a priority to support for textdumps (and > in case kgdb support cannot be finished in time, I would make sure that > the project is expendable enough to support information obtained from > kgdb and possibly other sources). Indeed, DDB is equipped with features that kgdb does not provide but only kgdb has access to the full debug information whenever we want because of its operation on the core dump. As far as I understand, if we want to use DDB to collect the debugging information, we have to do it *immediately* after the kernel panic and before the first reboot. Also consider that DDB is not included in the generic FreeBSD kernel of -STABLE and -RELEASE. You have to compile a custom kernel with the options KDB and DDB. I think that the nature of DDB as an on-line debugger is a restriction mainly for the manual behavior of kcrashreporter. I do not think that I could update the kgdb with the features that DDB provides, but if it is mandatory to collect these information and kgdb cannot, I will do my best. > I don't know if these are good ideas (no clue about cryptography), but I > would either: > - HTTP POST data over SSL > or > - HTTP POST data encrypted with some public key Nice. What about curl over the HTTPS protocol? > hardware information, dmesg, locks, locked vnodes, mount points, ps, > backtraces of all threads > > Basically if ddb can show something easly enough (or you will be able to > make it do so), the report should contain it. First I will try to search if and how we can obtain these information using kgdb. > I guess this site won't be very busy, so whatever popular httpd you will > choose it should be fine (although I would stick with either apache or > nginx). No clue about databases. One more vote for nginx. > Also it would be nice to have a way to contact the owner of machine that > submitted the report. One way I can think of is the ability to specify > e-mail address (say in rc.conf?) that will be included in the report. This is a feature that is included from the initial planning and with the way that you proposed :) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 20:59:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CFF1106566C for ; Wed, 16 May 2012 20:59:19 +0000 (UTC) (envelope-from bfalk_bsd@brandonfa.lk) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC1068FC17 for ; Wed, 16 May 2012 20:59:18 +0000 (UTC) Received: by obcni5 with SMTP id ni5so2005120obc.13 for ; Wed, 16 May 2012 13:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brandonfa.lk; s=google; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=evwtxoog+YEHiUhZ7rDiYxFALCri7ZKRBa8q0RsqQsE=; b=LXsQ9RQu6QROaypXkaxdy9w7TOOo0K9PpBiowvpAxCNTlmNk+krOM2IZ1ccwJh7761 y+Uik0Jr4IoJNrKTfM4ow3hVbtQBrZseGWyEqDLNdSWVrakKEsSqd8/H7T/Th0Vf0Kd7 06hQ+HPBhMTMUtDBbDTWmCCXuDFikh4AeQxYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=evwtxoog+YEHiUhZ7rDiYxFALCri7ZKRBa8q0RsqQsE=; b=IfFgVJXU/aZ8OZErqPaQeHl3BzXkvlbjor8VbOCFSrrxl5B0w/b3T9WQKjmRl1R/yt +Sa63lRMWJVJ9Zye8lTfSoRqZAUmgcM5KBokKkQ8i4Tyv5KSlNxMn+ZC4HffvPM2x9h2 RPQtr6d2Clb0oC47f07zwaBb9OgzdOXndjIyr9nZK0yTyqJjYdNhcKfBo/Gm8HOAwK3g oqi5Jyx92aQLH/P3H3UlAU+Ax8OoA1syQRkOlFOQD3qmH7uM1RLGESvv7WwBVxFHIiG8 A0/B70c0XAqqvx0JvC/Mkbpq1pcQW2Y67c8ctxwCZIL84BtcNcUyEOe+FM0+5fjeczdI kCRg== Received: by 10.182.167.104 with SMTP id zn8mr4097677obb.62.1337201958245; Wed, 16 May 2012 13:59:18 -0700 (PDT) Received: from [192.168.42.121] (wsip-184-183-177-134.dc.dc.cox.net. [184.183.177.134]) by mx.google.com with ESMTPS id j4sm3349117obn.19.2012.05.16.13.59.17 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 13:59:17 -0700 (PDT) Message-ID: <4FB41523.2000106@brandonfa.lk> Date: Wed, 16 May 2012 16:59:15 -0400 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnl74ZETC3oCgqC8NfoYG/t56I+lEUiinkAnHbVM9PDEU5jqX7PgPVkk+PxkeSyNphwJd09 Subject: High-res Timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:59:19 -0000 Does anyone have a quick list of high-resolution timer functions? Both user-land and kernel-land? It would be greatly appreciated (doing some performance timing for applications). -Brandon From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 21:10:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0C810657A5 for ; Wed, 16 May 2012 21:10:33 +0000 (UTC) (envelope-from tzabal@it.teithe.gr) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1596F8FC18 for ; Wed, 16 May 2012 21:10:32 +0000 (UTC) Received: from localhost (babel.noc.teithe.gr [195.251.240.240]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id q4GLAd4i002006; Thu, 17 May 2012 00:10:40 +0300 Received: from 37.32.238.191 ([37.32.238.191]) by webmail.teithe.gr (Horde Framework) with HTTP; Thu, 17 May 2012 00:10:31 +0300 Message-ID: <20120517001031.18402r4tg4k89x3b@webmail.teithe.gr> Date: Thu, 17 May 2012 00:10:31 +0300 From: tzabal@it.teithe.gr To: Fernando =?utf-8?b?QXBlc3RlZ3XDrWE=?= References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 21:10:33 -0000 Quoting Fernando Apesteguía : > I wonder if it would be good to have a configuration file to specify > the amount of information (the type of, also) the system is going to > send. > > Just my 2 cents. This would be a useful feature. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 01:44:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 018BB106564A for ; Thu, 17 May 2012 01:44:15 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C7C788FC15; Thu, 17 May 2012 01:44:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4H1iDm5055001; Thu, 17 May 2012 01:44:14 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4FB457EC.20908@gmail.com> Date: Thu, 17 May 2012 09:44:12 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brandon Falk References: <4FB41523.2000106@brandonfa.lk> In-Reply-To: <4FB41523.2000106@brandonfa.lk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: High-res Timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 01:44:15 -0000 On 2012/5/17 4:59, Brandon Falk wrote: > Does anyone have a quick list of high-resolution timer functions? Both > user-land and kernel-land? It would be greatly appreciated (doing some > performance timing for applications). > > -Brandon AFAIK, there is no high-resolution timer available. From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 01:59:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9106D106566B; Thu, 17 May 2012 01:59:12 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A8FB8FC15; Thu, 17 May 2012 01:59:12 +0000 (UTC) Received: by yenl8 with SMTP id l8so1723390yen.13 for ; Wed, 16 May 2012 18:59: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=hTkVcqA30jO87OjfXJNdrCibJB1CFK4Wh4Q/47xp3SE=; b=GmT3eWOjU/xTGRaTptvQDDRwCPcdtEWWXSSjoCAXzPVkax+elpotBtbJ8CpwV35sZv 6RnOkkY+HCDQCCEbS2SQv5L4cYBJfWBP4rGKYph9DbwZApD/PGQWvQdvf3xnMPsI+p/v W4U4hxlGVvzgntw0Jar16xM9fgRgYoDpwsX/Q9b4XNNhvBDQGcXK4qorRyAxSP0fFWOD 5GxIqkpkHIj0FTxiV0DH34C+8LiHBBg5uPTMAVw0lM0P9Xfk0FO9PxuiPKZW5GGHzsyt EWggkYv1OwmZEGUcN50cy6nmrsMzygSNkWgxpKH0VuMiChwqyNPuWtixcTi3jqwjlRpr 4IyQ== MIME-Version: 1.0 Received: by 10.50.163.5 with SMTP id ye5mr12055311igb.37.1337219951238; Wed, 16 May 2012 18:59:11 -0700 (PDT) Received: by 10.231.219.193 with HTTP; Wed, 16 May 2012 18:59:11 -0700 (PDT) In-Reply-To: <4FB457EC.20908@gmail.com> References: <4FB41523.2000106@brandonfa.lk> <4FB457EC.20908@gmail.com> Date: Wed, 16 May 2012 20:59:11 -0500 Message-ID: From: Zhihao Yuan To: davidxu@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Brandon Falk Subject: Re: High-res Timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 01:59:12 -0000 On Wed, May 16, 2012 at 8:44 PM, David Xu wrote: > On 2012/5/17 4:59, Brandon Falk wrote: >> >> Does anyone have a quick list of high-resolution timer functions? Both >> user-land and kernel-land? It would be greatly appreciated (doing some >> performance timing for applications). >> >> -Brandon > > > AFAIK, there is no high-resolution timer available. /usr/ports/emulators/rtc ? > > > _______________________________________________ > 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" -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 03:54:46 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D471065670 for ; Thu, 17 May 2012 03:54:46 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7B18FC14 for ; Thu, 17 May 2012 03:54:46 +0000 (UTC) Received: by yenl8 with SMTP id l8so1792729yen.13 for ; Wed, 16 May 2012 20:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=sPjSnZIDZ3A7+RyELg3JQKMhVB2qOTLIPaZLb4rxbzw=; b=KdAdf0qFWmp5+QrvJG294yXhZjsNRW+P6A6YYDA/fAQu5OwPeY+FHN5Dx6yCSG0q+n y9mLxyRKHsOTmXcEqk93uvmv69JZek2k5Hnlbw9lnT+3UPzeOKe817GBj/0F2oNNXUU0 LOilL+PHa98lR9ynJGIQx/24L24Tho7RBcNCM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=sPjSnZIDZ3A7+RyELg3JQKMhVB2qOTLIPaZLb4rxbzw=; b=WI3Ne7d9DV8bET4lMy1bFiUYC70buT9H211FC0cU/41w7bviXiEn/pqdyejEw3oDxv VmyCpCEKWI75N21HSo3/UVhq1wAPBJOvM7CGkKkfypqiM+gnp9Bldbq0NSDMpAJ3ECLw 9Z3rIci3HoX7h3aNDTB5P1bYC783gAup+U7UVJMWFidDfMnEjes8PVr1e2s+YUIEQubQ mSI1g3PZM/B5ninQ8A7Jo9kgbH3ODeHM5MbWA1pA0+4bzpQ9Fbw022YnLlkC8iV8jpAI FjIgQROuAqpZe5+3r836/q6b4IPiwcIu52jwyM9q5tsEb3M/qTs41mIW5FJ97ACHiBqq 4KCA== Received: by 10.50.12.199 with SMTP id a7mr11802839igc.71.1337226885761; Wed, 16 May 2012 20:54:45 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id eo5sm9872669igc.7.2012.05.16.20.54.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 20:54:45 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4H3sgXl062190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2012 23:54:42 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4H3sfsH059444; Wed, 16 May 2012 23:54:41 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Wed, 16 May 2012 23:54:41 -0400 From: Jason Hellenthal To: hackers@FreeBSD.org Message-ID: <20120517035441.GA91666@DataIX.net> References: <4FB41523.2000106@brandonfa.lk> <4FB457EC.20908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQkJZkM5moiAaAwDKD3vkMT4XA+GVkgRbVbKXMYlczOBaBzWEt8FzrI36Q/RxADnss9Igv0e Cc: Bruce Evans , davidxu@FreeBSD.org, Brandon Falk Subject: Re: High-res Timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 03:54:47 -0000 > >> > >> Does anyone have a quick list of high-resolution timer functions? Both > >> user-land and kernel-land? It would be greatly appreciated (doing some > >> performance timing for applications). > >> clocks(7) - various system timers getitimer(2), setitimer(2) - get/set value of interval timer see ( man -k timer ) list for some other references. I am not sure what sort of high resolution you are refering to but maybe these will lead you in the right direction. Bruce Evans CCd - he may have quite a bit that could be added to this. I always find what he has to say very enlightening. -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 08:38:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5D2106564A for ; Thu, 17 May 2012 08:38:47 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id F0AD28FC08 for ; Thu, 17 May 2012 08:38:45 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 6A3B4D4814F; Thu, 17 May 2012 10:38:39 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 46251B08; Thu, 17 May 2012 10:38:38 +0200 (CEST) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 16C5851A7B; Thu, 17 May 2012 08:38:38 +0000 (UTC) Date: Thu, 17 May 2012 10:38:37 +0200 From: Jeremie Le Hen To: tzabal@it.teithe.gr Message-ID: <20120517083837.GB16038@felucia.tataz.chchile.org> Mail-Followup-To: tzabal@it.teithe.gr, Ilya Bakulin , freebsd-hackers@freebsd.org References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <4FB34CF0.6000306@kibab.com> <20120516144524.19813u8j0pnxpbh0@webmail.teithe.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120516144524.19813u8j0pnxpbh0@webmail.teithe.gr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ilya Bakulin , freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 08:38:47 -0000 On Wed, May 16, 2012 at 02:45:24PM +0300, tzabal@it.teithe.gr wrote: > > In this case Apache is a good choice. I would however recommend using > > www/nginx and PHP in FastCGI mode (FPM option in lang/php5 port). This > > is a preffered setup for almost all Russian highloaded websites. > > At the beginning using Apache is a reasonable choice. > > I have never used nginx before. I have considered also the lighttpd. > Both with BSD licenses (nginx with a 2-clause BSD like license) and > FastCGI support. As I read from Wikipedia, PHP performance has > received special attention in lighttpd. I will test both Web servers > and then I will make up my mind. I think the HTTP server is not a big deal unless there is a really useful feature in one that the other doesn't provide. Most of the work will be done by the PHP backend anyway. >From an architectural point of view, best practices nowadays are leaning toward external PHP processes with FastCGI, as described by Ilya. There are alternatives to FPM, such as sysutils/py-supervisor. I don't know who will be administrating this server in the end, but I think it would be good to ask the FreeBSD webmaster team opinion though. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 10:13:41 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 873531065670; Thu, 17 May 2012 10:13:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id E62608FC14; Thu, 17 May 2012 10:13:40 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4HADKe4029544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 20:13:22 +1000 Date: Thu, 17 May 2012 20:13:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jason Hellenthal In-Reply-To: <20120517035441.GA91666@DataIX.net> Message-ID: <20120517195950.V1317@besplex.bde.org> References: <4FB41523.2000106@brandonfa.lk> <4FB457EC.20908@gmail.com> <20120517035441.GA91666@DataIX.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 17 May 2012 11:16:23 +0000 Cc: Bruce Evans , hackers@freebsd.org, davidxu@freebsd.org, Brandon Falk Subject: Re: High-res Timers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 10:13:41 -0000 On Wed, 16 May 2012, Jason Hellenthal wrote: >>>> Does anyone have a quick list of high-resolution timer functions? Both >>>> user-land and kernel-land? It would be greatly appreciated (doing some >>>> performance timing for applications). > > clocks(7) - various system timers > getitimer(2), setitimer(2) - get/set value of interval timer > > see ( man -k timer ) list for some other references. I think the original poster wants timestamping functions. "Timer function" normally means a timer-interrupt-scheduling function. clocks(7) is bogus and more than 10 years out of date. It is mostly about hardware and virtual clock oscillators that may be used to build timestamping and timer functions (mostly the former). > I am not sure what sort of high resolution you are refering to but maybe > these will lead you in the right direction. Bruce Evans CCd - he may > have quite a bit that could be added to this. I always find what he has > to say very enlightening. Generally, some of the timestamping functions have high resolution, but are too slow to use if you make a lot of timestamps, and if you don't make a lot of timestamps then you don't need very high resolution. Bruce From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 11:39:45 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53CAD106564A; Thu, 17 May 2012 11:39:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 195A28FC08; Thu, 17 May 2012 11:39:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10166; Thu, 17 May 2012 14:39:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB4E377.8050805@FreeBSD.org> Date: Thu, 17 May 2012 14:39:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gleb Smirnoff , current@FreeBSD.org References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> <4F2079B3.80305@FreeBSD.org> In-Reply-To: <4F2079B3.80305@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 11:39:45 -0000 on 25/01/2012 23:52 Andriy Gapon said the following: > on 24/01/2012 14:32 Gleb Smirnoff said the following: >> Yes, now: >> >> Rebooting... >> lock order reversal: >> 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ /usr/src/head/sys/kern/kern_shutdown.c:542 >> 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ /usr/src/head/sys/dev/uart/uart_cpu.h:92 >> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ /usr/src/head/sys/kern/kern_cons.c:500 > > OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no new > details... > > It's still intriguing to me why the LOR *doesn't* happen [*] with > stop_scheduler_on_panic=0. But I don't see a productive way to pursue this > investigation further. Salve Glebius! After your recent nudging I took yet another look at this issue and it seems that I have some findings. For those who might get interested here is a convenience reference to the whole thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 A short summary. Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && !WITNESS_SKIPSPIN (this is important) and a system uses serial console via uart. Then, if stop_scheduler_on_panic is set to zero the system can be rebooted without a problem. On the other hand, if stop_scheduler_on_panic is enabled, then the system first runs into a LOR when calling printf() in cpu_reset() and then it runs into a panic when printf is recursively called from witness(9) to report the LOR. The panic happens because of the recursion on cnputs_mtx, which should ensure that cnputs() output is not intermingled and which is not flagged to support recursion. There are two things about this report that greatly confused and puzzled me: 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how could it be possible that changing its value affects behavior of the system when panic(9) is not called?! 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks is actually predefined in witness order_lists[] such that uart_hwmtx must come before smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in shutdown_reset(), then we call cpu_reset, then it calls printf and from there we get to uart_hwmtx for serial console output. So the order between these spinlocks is always violated in the x86 SMP reboot path. How come witness(9) doesn't _always_ detect this LOR? How come it didn't detect this LOR before any "stop scheduler" commits?! [Spoiler alert :-)] Turns out that the two puzzles above are closely related. Let's first list all the things that change when stop_scheduler_on_panic is enabled and a panic happens: - other CPUs are stopped (forced to spin) - interrupts on current CPU are disabled - by virtue of the above the current thread should be the only thread running (unless it executes a voluntary switch) - all locks are "busted", they are completely ignored / bypassed - by virtue of the above no lock invariants and witness checks are performed, so no lock order checking, no recursion checking, etc So, what I observe is this: when stop_scheduler_on_panic is disabled, the LOR is actually detected as it should be. witness(9) works properly here. Once the LOR is detected witness(9) wants to report it using printf(9). That's where we run into the cnputs_mtx recursion panic. It's all exactly as with stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic using printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() detects locks recursion again (this is independent of witness(9)) and calls panic(9) again. Then panic(9) wants to report the panic using printf(9)... I assume that when the stack is exhausted we run into a double fault and dblfault_handler wants to print something again... Likely we eventually run into a triple fault which resets the machine. Although, I recall some old reports of machines hanging during reboot in a place suspiciously close to where the described ordeal happens... But if the machine doesn't hang we get a full appearance of the reset successfully happening (modulo some last messages missing). With stop_scheduler_on_panic enabled and all the locks being ignored we, of course, do not run into any secondary lock recursions and resulting panics. So the system is able to at least panic "gracefully" (still we should have just reported the LOR gracefully, no panic is required). Some obvious conclusions: - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause of the problem; it should be fixed one way or other - either by correcting witness order_lists[] or by avoiding the LOR in shutdown_reset/cpu_reset; - because witness(9) uses printf(9) to report problems, it is very fragile to use witness with any locks that can be acquired under printf(9) - stop_scheduler_on_panic just uncovers the true bug There are probably other conclusions that can be made. I welcome any suggestions on how to fix the problems discovered. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 12:53:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 248781065670 for ; Thu, 17 May 2012 12:53:58 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A5F318FC17 for ; Thu, 17 May 2012 12:53:57 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1831768wgb.31 for ; Thu, 17 May 2012 05:53:56 -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=u2s4p6c0r4o3sYhoVMPmDSw8LSXG/M9LlR4tqU1xDvI=; b=hMyj8Iph/x7YoaUVbd6YR/KcuJWS67D13EbIYO1kzRIHKrKjPkLio0KQaa8A1LGF8x O3HhINxG79OY9YnZ2hg+iLNDGW3W5m+Djn8e4jKfjWstBH2bo6TQsL8QeEAJ8I3Xv43t 75g325xMGrc9JlWpmlvbSBjtQ6holTt9p4wMqHs+Mp2kVMVatdShe8cNSmQULMmvSMYc 9QZRs4RHlROG73fVo0UbjKx+0kEmByamq/P+TyvqTA4NL+KqmYRAJHX86eBdqQTL0Dth YkJGYDCtJqVUpt1DlNiUsaG20aQTPq5uKaSdvBXG/MfTBMDtevZrxk4Ed38HPDVgciwm caIg== Received: by 10.216.143.200 with SMTP id l50mr4772562wej.58.1337259236467; Thu, 17 May 2012 05:53:56 -0700 (PDT) Received: from dft-labs.eu (dft-labs.eu. [80.87.128.179]) by mx.google.com with ESMTPS id m1sm25716034wic.6.2012.05.17.05.53.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 05:53:55 -0700 (PDT) Date: Thu, 17 May 2012 14:53:48 +0200 From: Mateusz Guzik To: tzabal@it.teithe.gr Message-ID: <20120517125348.GA26081@dft-labs.eu> References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120516233744.1314398bowqaykuw@webmail.teithe.gr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 12:53:58 -0000 On Wed, May 16, 2012 at 11:37:44PM +0300, tzabal@it.teithe.gr wrote: > Quoting Mateusz Guzik : > > >On Wed, May 16, 2012 at 12:30:20AM +0300, tzabal@it.teithe.gr wrote: > >>Hello Community, > >> > >>I have the project "Automated Kernel Crash Reporting System" for > >>this GSoC and I would like to discuss my plans about it before > >>starting the coding on May 21. > >> > > > >Cogratulations. :) > > > >>I have created a page in the FreeBSD Wiki (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > >>where I describe in details the architecture of the system. > >> > >>Here are some points that I would like to be discussed: > >> > >>* The implementation of the kcrashreporter is planned to be done in > >>two shell scripts. The first shell script is a rc.d script and the > >>second is the actual program. I choose to code it in shell because > >>kcrashreporter invokes the kgdb to collect the necessary debugging > >>information. I think that using the shell instead of traditional > >>programming language for this kind of job is more straightforward > >>and natural. Do you have a different opinion? > >> > > > >Are you going to support textdumps? > > > >I would like to note that some machines have swap space only for > >textdumps, so I think you should support these. > > Support for textdumps is already on the list. > > >ddb is equiped with a lot of cool commands that show various important > >debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such > >facilities so you will have to implement those first if you decide to > >use it (btw I think these would be useful even without this project). > >Take a look at tools/debugscripts. > >That being said, I would give a priority to support for textdumps (and > >in case kgdb support cannot be finished in time, I would make sure that > >the project is expendable enough to support information obtained from > >kgdb and possibly other sources). > > Indeed, DDB is equipped with features that kgdb does not provide but > only kgdb has access to the full debug information whenever we want > because of its operation on the core dump. As far as I understand, > if we want to use DDB to collect the debugging information, we have > to do it *immediately* after the kernel panic and before the first > reboot. Also consider that DDB is not included in the generic > FreeBSD kernel of -STABLE and -RELEASE. You have to compile a custom > kernel with the options KDB and DDB. I think that the nature of DDB > as an on-line debugger is a restriction mainly for the manual > behavior of kcrashreporter. Maybe this is a gross misunderstanting on my side, but I'm pretty sure that: DDB supports simple form of scripting that allows series of commands to be run on certain events, e.g. kernel panic. Output can be captured ("capture on"). textdump is a part of DDB that saves aforementioned output. In other words, there are no textdumps without DDB and there is no problem with running DDB commands automatically after panic. Also it looks like you will have to actually add DDB to GENERIC in order to obtain textdumps in default installations. > I do not think that I could update the kgdb with the features that > DDB provides, but if it is mandatory to collect these information > and kgdb cannot, I will do my best. > > >I don't know if these are good ideas (no clue about cryptography), but I > >would either: > >- HTTP POST data over SSL > >or > >- HTTP POST data encrypted with some public key > > Nice. What about curl over the HTTPS protocol? > curl would be ok, except it's not in the base system. Actually I just now checked for tools in base that support HTTP POST and couldn't find any. Should've checked before proposing such solution, sorry. > >hardware information, dmesg, locks, locked vnodes, mount points, ps, > >backtraces of all threads > > > >Basically if ddb can show something easly enough (or you will be able to > >make it do so), the report should contain it. > > First I will try to search if and how we can obtain these > information using kgdb. > > > >I guess this site won't be very busy, so whatever popular httpd you will > >choose it should be fine (although I would stick with either apache or > >nginx). No clue about databases. > > One more vote for nginx. > > >Also it would be nice to have a way to contact the owner of machine that > >submitted the report. One way I can think of is the ability to specify > >e-mail address (say in rc.conf?) that will be included in the report. > > This is a feature that is included from the initial planning and > with the way that you proposed :) > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 13:20:41 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C006C106564A for ; Thu, 17 May 2012 13:20:41 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42BF38FC12 for ; Thu, 17 May 2012 13:20:40 +0000 (UTC) Received: by lbon10 with SMTP id n10so1792338lbo.13 for ; Thu, 17 May 2012 06:20:40 -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=GRe8eK3TxLwxe9+utMpQSIkFMNpBvBMESoXOp4WaoJw=; b=VhQYKPEkqgE7Zn6ejQy8tiSdqcY6p4CNPo0t409fw7dIM48BLtpeV9Rs1MKpIK452+ 6Svy4FHGURPqRkGdA7gaL+oyvoM2EkHU3hvWsRJVDQZezXx8nXAXkLicQVvWmNpgBWZj rPhPXux3PJ8tJhEhbbYzJffd3+gUlhwgAOIYzJ5rXu87tMkE8P9uL2B5SxejEyOrwxJx PriPYDnhevihERwP+VhjID0CDDkXeaevckeerwzWbLnR5zuHBjOZwyUT5woBJhcw7P8I 64xmO+yEHeJHOYLOZA9mPua3khYpCJo3QnrZ/5YGRDkRLMssshWZCyeFUuG4D3G9H/vg Gx9w== MIME-Version: 1.0 Received: by 10.112.29.131 with SMTP id k3mr3132099lbh.53.1337260839877; Thu, 17 May 2012 06:20:39 -0700 (PDT) Received: by 10.112.60.65 with HTTP; Thu, 17 May 2012 06:20:39 -0700 (PDT) Date: Thu, 17 May 2012 15:20:39 +0200 Message-ID: From: Svatopluk Kraus To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 13:20:41 -0000 Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. 1. [no cache] attribute No problem as memory is coherent. 2. [write throught] attribute The part A can be invalidated without loss of any data. It's not problem too. 3. [write back] attribute In general, there is no way how to keep both parts consistent. At the start of DMA transaction, the cache line is written back and invalidated. However, as we know nothing about memory associated with part A of the cache line, the cache line can be filled again at any time and messing up DMA transaction if flushed. Even if the cache line is only filled but not flushed during DMA transaction, we must make it coherent with memory after that. There is a trick with saving part A of the line into temporary buffer, invalidating the line, and restoring part A in current ARM (MIPS) implementation. However, if somebody is writting to memory associated with part A of the line during this trick, the part A will be messed up. Moreover, the part A can be part of another DMA transaction. To safely use DMA with no coherent memory, a memory with [no cache] or [write throught] attributes can be used without problem. A memory with [write back] attribute must be aligned on CACHE_LINE_SIZE. However, for example mbuf, a buffer for DMA can be part of a structure which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We can know that nobody will write to the structure during DMA transaction, so it's safe to use the buffer event if it's not aligned on CACHE_LINE_SIZE. So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we must support additional information to DMA transaction. It should be easy to support the information about drivers data buffers. However, what about OS data buffers like mentioned mbufs? The question is following. Is or can be guaranteed for all or at least well-known OS data buffers which can be part of DMA access that the not CACHE_LINE_SIZE aligned buffers are surrounded by data which belongs to the same object as the buffer and the data is not written by OS when given to a driver? Any answer is appreciated. However, 'bounce pages' is not an answer. Thanks, Svata From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 13:28:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 980A91065672 for ; Thu, 17 May 2012 13:28:09 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 456AF8FC19 for ; Thu, 17 May 2012 13:28:09 +0000 (UTC) Received: (qmail 29066 invoked from network); 17 May 2012 09:28:03 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 17 May 2012 09:28:03 -0400 Message-ID: <4FB4FCE2.7060509@shadowsun.net> Date: Thu, 17 May 2012 09:28:02 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> <4FB33BD9.3030501@FreeBSD.org> In-Reply-To: <4FB33BD9.3030501@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------020706010607010508060305" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 13:28:09 -0000 This is a multi-part message in MIME format. --------------020706010607010508060305 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/16/12 01:32, Andrey V. Elsukov wrote: > As i see we already have sys/boot/efi/libefi/efipart.c that uses > EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL > provides access to each disk and partition. AFAIK it supports only > GPT and MBR+EBR, so there might be some problems with ZFS support, > because we can use ZFS atop of BSD partition. > I'd need to take a look, but if the efi loaders are not directly calling the EFI_BLOCK_IO_PROTOCOL functions, then it should be easy to implement a layer that understands BSDlabels. IA64 might have a solution. Then again, is a BSDlabel really necessary on a GPT disk? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtPziAAoJENSCzbQ+koZ7WZwQAKPN80f/I3obnwSNgSeJ9RyJ q14FYshFuOyaiPPm+HsRdJsv82rdOx9AWi5uuBLTjGADHQ7FdVZTk7fIvhSakUHN d6s/FTcxpLopnibNApXXPNla2fHi25qz8c4axd/4XyxoJ1EGIWnXJ3pQ8R/GCNhK olXDocZ+vylO6IW0ta2C4yq2rYFLNCKoR5+Kdoo4B/S+NEguqBCUW/DXTvWqeJw5 GJGzCTDmCKGaOp9LrSQ5jws4XmnqsoBFeL7Zd1Yu40KvS3QyhHpeh1GCZklq3ncG xdGcK4P7/rwrfR3zSf0tHFCbt1o7BJ0XNHL4MrZflbGuQFGvIbdReXNmLi4QDvKS 7QzqsbbtgnL6NrWfJ/Z4UqEZt0dKAj9wZNX5AVP+p2KJomSoV2NPnuuFKAtoiGfe 282daJ4q3D60fxfdo/rExdpA6k2usnxZDCyFM15hhg4jJQDnl32Yj9ym5bbTeDDU Uqoh1Ka/Oj/RtRXHLFdAdL34Jm4RyFgeaRUtVD7o7f5ASCHx0EuFFAh1eZTqFCEi yN1V1+z8FE7va0fQDO7a5S+2O8Hph9K+W8Dxcuq1g/Rg8mBZ8Klny6etWghP6vvR ISiqdMvLkfqqF3eVcB/EY9rLahHr14kabMtSWLRVurVjEPxZ/ju0+9342z3vcY75 xIQe8JfKjuOjkclmpioa =flEs -----END PGP SIGNATURE----- --------------020706010607010508060305-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 14:07:40 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446D91065670; Thu, 17 May 2012 14:07:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 266D78FC15; Thu, 17 May 2012 14:07:38 +0000 (UTC) Received: by lbon10 with SMTP id n10so1846079lbo.13 for ; Thu, 17 May 2012 07:07: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FVoHhCR4eLsHfe96Y2UqH2+D56DRqpTAsa8JIpwIPGM=; b=03+fJiwLCRGYfprZtXPDiXZ9MGQmAardCi16C9/Zlyk7iicOGCohj4DeBbK+OWrlZp R0mvxjSDLTD1gYEU89CHa2gpXJjClIfVIrucipj9T/8y+5Sg4/GDb1hKDO+D6NDzN5bN Lz9sw8gFMJ4tFFAedN86Chrh7z2dubPVYG5Qu6AG1cVpFWA1JMevoMrgUITX7kqODc0b JD9zwl+bxTHZAyNy17phW8VNMM73AVwInrlDxyNDw7K7f85wfEb7GSil3Z6JyCthvm8s W4ZqiqDyDlw34SdJrNEBIGyKVDRYO7jLEzZS6O9FFtPbcccLkIGL41zXlVN+EsbBkIKd E17g== MIME-Version: 1.0 Received: by 10.152.135.105 with SMTP id pr9mr7242041lab.37.1337263657727; Thu, 17 May 2012 07:07:37 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Thu, 17 May 2012 07:07:37 -0700 (PDT) In-Reply-To: <4FB4E377.8050805@FreeBSD.org> References: <4F1D18A5.8010006@FreeBSD.org> <20120123130743.GI16676@glebius.int.ru> <4F1D6830.60602@FreeBSD.org> <20120123162410.GN16676@glebius.int.ru> <20120123162606.GO16676@FreeBSD.org> <4F1D8E2B.30800@FreeBSD.org> <20120123164659.GQ16676@glebius.int.ru> <4F1D9128.3030501@FreeBSD.org> <20120124115424.GX16676@glebius.int.ru> <4F1E9F5F.8080209@FreeBSD.org> <20120124123245.GZ16676@glebius.int.ru> <4F2079B3.80305@FreeBSD.org> <4FB4E377.8050805@FreeBSD.org> Date: Thu, 17 May 2012 15:07:37 +0100 X-Google-Sender-Auth: xeySoIxqn6F6IL_1txyq-7se1RA Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org, Gleb Smirnoff , current@freebsd.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:07:40 -0000 2012/5/17, Andriy Gapon : > on 25/01/2012 23:52 Andriy Gapon said the following: >> on 24/01/2012 14:32 Gleb Smirnoff said the following: >>> Yes, now: >>> >>> Rebooting... >>> lock order reversal: >>> 1st 0xffffffff80937140 smp rendezvous (smp rendezvous) @ >>> /usr/src/head/sys/kern/kern_shutdown.c:542 >>> 2nd 0xfffffe0001f5d838 uart_hwmtx (uart_hwmtx) @ >>> /usr/src/head/sys/dev/uart/uart_cpu.h:92 >>> panic: mtx_lock_spin: recursed on non-recursive mutex cnputs_mtx @ >>> /usr/src/head/sys/kern/kern_cons.c:500 >> >> OK, so it's just a plain LOR between smp rendezvous and uart_hwmtx, no >> new >> details... >> >> It's still intriguing to me why the LOR *doesn't* happen [*] with >> stop_scheduler_on_panic=0. But I don't see a productive way to pursue >> this >> investigation further. > > Salve Glebius! > After your recent nudging I took yet another look at this issue and it seems > that > I have some findings. > > For those who might get interested here is a convenience reference to the > whole > thread on gmane: http://thread.gmane.org/gmane.os.freebsd.current/139307 > > A short summary. > Prerequisites: an SMP x86 system, its kernel is configured with WITNESS && > !WITNESS_SKIPSPIN (this is important) and a system uses serial console via > uart. > Then, if stop_scheduler_on_panic is set to zero the system can be rebooted > without > a problem. On the other hand, if stop_scheduler_on_panic is enabled, then > the > system first runs into a LOR when calling printf() in cpu_reset() and then > it runs > into a panic when printf is recursively called from witness(9) to report the > LOR. > The panic happens because of the recursion on cnputs_mtx, which should > ensure > that cnputs() output is not intermingled and which is not flagged to > support > recursion. > > There are two things about this report that greatly confused and puzzled > me: > 1. stop_scheduler_on_panic variable is used _only_ in panic(9). So how > could it > be possible that changing its value affects behavior of the system when > panic(9) > is not called?! > > 2. The LOR in question happens between "smp rendezvous" (smp_ipi_mtx) and > "uart_hwmtx" (sc_hwmtx_s in uart core) spin locks. The order of these locks > is > actually predefined in witness order_lists[] such that uart_hwmtx must come > before > smp_ipi_mtx. But in the reboot path we first take smp_ipi_mtx in > shutdown_reset(), then we call cpu_reset, then it calls printf and from > there we > get to uart_hwmtx for serial console output. So the order between these > spinlocks > is always violated in the x86 SMP reboot path. > How come witness(9) doesn't _always_ detect this LOR? > How come it didn't detect this LOR before any "stop scheduler" commits?! > > [Spoiler alert :-)] > > Turns out that the two puzzles above are closely related. > Let's first list all the things that change when stop_scheduler_on_panic is > enabled and a panic happens: > - other CPUs are stopped (forced to spin) > - interrupts on current CPU are disabled > - by virtue of the above the current thread should be the only thread > running > (unless it executes a voluntary switch) > - all locks are "busted", they are completely ignored / bypassed > - by virtue of the above no lock invariants and witness checks are > performed, so > no lock order checking, no recursion checking, etc > > So, what I observe is this: when stop_scheduler_on_panic is disabled, the > LOR is > actually detected as it should be. witness(9) works properly here. Once > the LOR > is detected witness(9) wants to report it using printf(9). That's where we > run > into the cnputs_mtx recursion panic. It's all exactly as with > stop_scheduler_on_panic enabled. Then panic(9) wants to report the panic > using > printf(9), which goes to cnputs() again, where _mtx_lock_spin_flags() > detects > locks recursion again (this is independent of witness(9)) and calls > panic(9) > again. Then panic(9) wants to report the panic using printf(9)... > I assume that when the stack is exhausted we run into a double fault and > dblfault_handler wants to print something again... Likely we eventually run > into > a triple fault which resets the machine. Although, I recall some old > reports of > machines hanging during reboot in a place suspiciously close to where the > described ordeal happens... > But if the machine doesn't hang we get a full appearance of the reset > successfully > happening (modulo some last messages missing). > > With stop_scheduler_on_panic enabled and all the locks being ignored we, of > course, do not run into any secondary lock recursions and resulting panics. > So > the system is able to at least panic "gracefully" (still we should have > just > reported the LOR gracefully, no panic is required). > > Some obvious conclusions: > - the "smp rendezvous" and "uart_hwmtx" LOR is real and it is the true cause > of > the problem; it should be fixed one way or other - either by correcting > witness > order_lists[] or by avoiding the LOR in shutdown_reset/cpu_reset; > - because witness(9) uses printf(9) to report problems, it is very fragile > to use > witness with any locks that can be acquired under printf(9) > - stop_scheduler_on_panic just uncovers the true bug Thanks for working on this. My thoughts on the matter: - We should not printf() in cpu_reset() which is supposed to be a very low level primitives, usable by any context. Acquiring console spinlocks there is not really a wise choice. - I'd like to see witness being based on an alternative approach, but we may find something that doesn't wrap up (thus a bufring ala KTR is not appropriate) and can work also in SMP context (thus a lockfree algorithm is not appropriate). I don't have any good solution for this on the top of my idea, but of course, relying on a path acquiring locks for a lock protector is not a great idea. The only other thing we may do is marking locks involved in the printf() path with NO_WITNESS, but that of course won't solve the deadlock problem itself. - On a related note, I once had a patch that was having BSP recovering from deadlock in the reset code and panic/print informations, under DIAGNOSTIC. I may find it again and post here. Definitively, I think that we need to make cpu_reset() locks agnostic and if you agree I can make a patch for that. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 15:00:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C953D106566B for ; Thu, 17 May 2012 15:00:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A00348FC15 for ; Thu, 17 May 2012 15:00:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B5A51B94F; Thu, 17 May 2012 11:00:38 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 17 May 2012 10:36:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FA95960.7090908@shadowsun.net> <201205151144.38123.jhb@freebsd.org> <4FB3AAA6.3090708@shadowsun.net> In-Reply-To: <4FB3AAA6.3090708@shadowsun.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205171036.45009.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:38 -0400 (EDT) Cc: Eric McCorkle Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:00:39 -0000 On Wednesday, May 16, 2012 9:24:54 am Eric McCorkle wrote: > On 05/15/12 11:44, John Baldwin wrote: > > The i386 kernel assumes it starts out with a flat 32-bit mode with > > the kernel loaded into a contiguous memory region at a fixed > > physical address. If we need a relocatable kernel (as Marcel > > hinted at I think), then that adds a fair bit of complication. > > > > The amd64 kernel assumes it starts in long mode (the bootinfo64.c > > bits in the loader setup initial page tables, etc.). I think the > > amd64 kernel also has to be loaded into contiguous memory at a > > fixed physical address currently. > > > > Seems like an initial workaround could be to allocate a space big > enough for all the necessary ELF segments, and split it up ourselves. > > Do the kernel and modules actually do anything that depends on being > in a contiguous space in some way (ie some relocation trick)? Because > it seems like it shouldn't really matter otherwise. They are statically linked at a fixed address. Modules can be wherever, but the kernel has to be at the physical address it is linked for (unless you make the kernel relocatable). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 15:00:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C86D9106566C for ; Thu, 17 May 2012 15:00:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5568FC16 for ; Thu, 17 May 2012 15:00:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1508B9AD; Thu, 17 May 2012 11:00:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 17 May 2012 10:39:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> In-Reply-To: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201205171039.25118.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:40 -0400 (EDT) Cc: tzabal@it.teithe.gr Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:00:40 -0000 On Tuesday, May 15, 2012 5:30:20 pm tzabal@it.teithe.gr wrote: > Hello Community, > > I have the project "Automated Kernel Crash Reporting System" for this > GSoC and I would like to discuss my plans about it before starting the > coding on May 21. > > I have created a page in the FreeBSD Wiki > (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem) > where I describe in details the architecture of the system. > > Here are some points that I would like to be discussed: > > * The implementation of the kcrashreporter is planned to be done in > two shell scripts. The first shell script is a rc.d script and the > second is the actual program. I choose to code it in shell because > kcrashreporter invokes the kgdb to collect the necessary debugging > information. I think that using the shell instead of traditional > programming language for this kind of job is more straightforward and > natural. Do you have a different opinion? Have you looked at /usr/sbin/crashinfo? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 15:00:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BAF41065670 for ; Thu, 17 May 2012 15:00:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 50FFA8FC17 for ; Thu, 17 May 2012 15:00:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C6D21B9BB; Thu, 17 May 2012 11:00:40 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 17 May 2012 10:42:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> In-Reply-To: <20120516140033.GB2470@dft-labs.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201205171042.08597.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 May 2012 11:00:40 -0400 (EDT) Cc: Mateusz Guzik , tzabal@it.teithe.gr Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:00:41 -0000 On Wednesday, May 16, 2012 10:00:33 am Mateusz Guzik wrote: > Are you going to support textdumps? > > I would like to note that some machines have swap space only for > textdumps, so I think you should support these. > > ddb is equiped with a lot of cool commands that show various important > debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such > facilities so you will have to implement those first if you decide to > use it (btw I think these would be useful even without this project). > Take a look at tools/debugscripts. > > That being said, I would give a priority to support for textdumps (and > in case kgdb support cannot be finished in time, I would make sure that > the project is expendable enough to support information obtained from > kgdb and possibly other sources). Note that it is not hard to support these in kgdb. I have gdb scripts that already provide equivalents to 'show lockchain' and many other commands. However, the problem with textdumps (which are still worth reporting), is that for hard bugs a developer often wants to ask the submitter for specific information, and won't know what to ask for until looking at the general information. There simply isn't a way to grab all the possible information up front in textdumps. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 15:51:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05194106574A for ; Thu, 17 May 2012 15:51:55 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id AA1E08FC1D for ; Thu, 17 May 2012 15:51:54 +0000 (UTC) Received: (qmail 25696 invoked from network); 17 May 2012 11:51:54 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 17 May 2012 11:51:53 -0400 Message-ID: <4FB51E98.6050109@shadowsun.net> Date: Thu, 17 May 2012 11:51:52 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> <201205151144.38123.jhb@freebsd.org> <4FB3AAA6.3090708@shadowsun.net> <201205171036.45009.jhb@freebsd.org> In-Reply-To: <201205171036.45009.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:51:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/17/12 10:36, John Baldwin wrote: >> Do the kernel and modules actually do anything that depends on >> being in a contiguous space in some way (ie some relocation >> trick)? Because it seems like it shouldn't really matter >> otherwise. > > They are statically linked at a fixed address. Modules can be > wherever, but the kernel has to be at the physical address it is > linked for (unless you make the kernel relocatable). > Hmm. That would definitely be an issue. Are there any reasons inherent to the way the kernel runs that would prevent that from being done? Alternately, it seems you could set up page tables in the EFI loader, though getting the handoff right would be trick to say the least. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtR6YAAoJENSCzbQ+koZ7JS4P+wfFfj4U/1OVy4cIyYc39XDt i+LDP1Eq/uSVnVB0Jj58yAMWR0ssrjA4/4DATN/59d5as42o4vN9alf6v+82o8CV mTIiaqynFvTGXaEdZE/tXz1TDshjt5zUMXjoBSMfkrVxHLhTvJNImmk6Zlc5lfQm GJ194X4rhiRK3BRyEWK0sHaGie88GYXcrZBr5iyLvi4MkqS6HnC5rV3ZaXQ4uqz3 po4eHbuIeU88INnL7qGULnGiZzGoTULaFdheDMxU7UtD++kGxpRfhqsCkJ3RbRb6 BxqI70CrKPBp/6CILSsaYqPKzn8Ew5xmG7qoxfBgmqLNOfoSyTsmybGXotRocxlO EQIG0BEcEu51OGAh5eDADBnfNw347cyGwdtr0HI7rPegK4CNedc5uf/OMoHlNz2F 9guzJLkG7Ruk6oIIyP5wn3m5uB1S5mJ0c5jow9Vxfie20TVzzHhZSNn6ipryt8iT FbN/sMReLudVlpEv5aQ2N1Y4YH2lt9Qqbg4h5qpQ6l89mGredGb4jOHJTKFchCLp N9B185r2O5emFV2jS6C/Nkcdqmp69hg/4jxn8aOVR2dmt//gBMy3KYlflLaBSIzQ r0Wzga+a/GOTX90ii1386q7HhQtAb0facBA3A0h0k9fb9BFra2LUO/vkXMLrxqUR +z8kQiLx8O0gFAanF7gN =sSDg -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 15:57:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745DB1065673 for ; Thu, 17 May 2012 15:57:57 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED608FC21 for ; Thu, 17 May 2012 15:57:56 +0000 (UTC) Received: (qmail 26802 invoked from network); 17 May 2012 11:57:56 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 17 May 2012 11:57:56 -0400 Message-ID: <4FB52003.8030409@shadowsun.net> Date: Thu, 17 May 2012 11:57:55 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> In-Reply-To: <4FA95960.7090908@shadowsun.net> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 15:57:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/08/12 13:35, Eric McCorkle wrote: > Hello everyone, > > I'm going to be working on EFI boot support on the amd64/i386 > platforms as a GSoC project. The idea is to allow booting from > EFI (as opposed to legacy BIOS) on these platforms, so that FreeBSD > can continue to support a wide range of hardware as EFI begins to > replace BIOS. ... Just to bring this up, when was the last time anyone actually built the i386 EFI loader? There might be a bit of work to be done to bring it back into a buildable state. There most certainly *is* some work needed to be able to build on amd64. I spent last night poking around, and identified a few things, but I probably shouldn't go any farther until the 21st (or at least until I have a repository) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtSADAAoJENSCzbQ+koZ7ydYP/3g6pxpVfRxofDTtLH3MmElW TPMKuTJD4kZqbEjds0u7iXg2uweqUGajMQvOfHi6KXvmKriswrmortrLgMgJCI8P 5HoiS0WDrwRvdL38y5DpzpKZ1rc7RjWS0pEKpPYx3DQh0bps0sb1iAcI8gdPliNL /qRmeLNfiTcaYTOILgPcbWlLnIFYMmg5hmz7zjlIdZYWeBtVdKfrtw6hLCzJqoyz QfL4mzOrBNuXx4jw1yLk3qU7hxsrMkzN3Jm9HOJCb9D/4mDHvF3jmv/o0Jx9hacx Yt9gsYSd/Ot4hOQmB2d9KjOrZMrK5s+JhvknC1sMXz4UD7b6L/AItEpm0OiX1Ls6 2L1Fxob8V0VDZd4JJuZDFWAhqQ6dh9O5mQHrHxTCjEhYIDNPy367L9TdqLtggWN0 EMjVJqfg0XxLRP7vLopax/H6zpd0p8vXUGSxLiKXe4IHWIggPFgaWehslSzgTIu6 2xaETVkaBxt2JXo8ArAyfsvyW6JcZqYp2R2JAUXTNa/PX2Cn9iPFvnsqF7Ir3M5T /cabcrc69fARbRGCtL/vEY0ZHZ33b6K+ACJEmGuamZbDB0Xxe3dgRt+hSWFwjKfq 8+WP7xJ4dfkjICZ/+HXmO9n58myNd2hoBAWQwdG230p55YL2iuqGc2apqnZCsb5o KJVEWBn9VWYBxB/k7yoq =YxYV -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 16:01:35 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9595106566C for ; Thu, 17 May 2012 16:01:35 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCFD8FC16 for ; Thu, 17 May 2012 16:01:35 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3001984pbb.13 for ; Thu, 17 May 2012 09:01: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=dXJSWdiJB+QsS7Bjsf8CjG8+72w7wLCBZDHsILV1rKw=; b=wlef4YGMcAJTGFmEKe+aqhmwpi1M/P21g0eEhwSyWmf9AFHveAQqhuIPSaffTDmqyN +1h8Y4yaWdh8OgO67l3j9iYBrcDnDf5Znn0EZ777YKbSxIUI8JwTEaTaXX2sgKn2iKI5 LqfXC06ls1J5KaK4/RXg6N2cCECumHyTE9AbHOoY+XV7JGK/rGREDMVUv1TsJqFfaLsl 3MUNfbKNK1CnBnY3o7+kLYHnGu7GXEAqsVA8X3tVRNngTkUwShjAGN74QdYyRvZHGceU V1T0ckrLz75p+als/IwWyuOr3OdE9bPHD+W2zhRA+JsHu2LoYafEzyqsVttoma1RITsn 70wQ== MIME-Version: 1.0 Received: by 10.68.203.225 with SMTP id kt1mr28688539pbc.133.1337270495017; Thu, 17 May 2012 09:01:35 -0700 (PDT) Received: by 10.68.49.227 with HTTP; Thu, 17 May 2012 09:01:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 May 2012 11:01:34 -0500 Message-ID: From: Mark Tinguely To: Svatopluk Kraus Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 16:01:35 -0000 On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus wrote: > Hi, > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > looked at implementation in ARM tree, but IMHO it only works with some > assumptions. There is a problem with DMA on memory block which is not > aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > Then first cache line associated with the buffer can be divided into > two parts, A and B, where A is a memory we know nothing about it and B > is buffer memory. The same stands for last cache line associatted with > the buffer. We have no problem if a memory is coherent. Otherwise it > depends on memory attributes. > > 1. [no cache] attribute > No problem as memory is coherent. > > 2. [write throught] attribute > The part A can be invalidated without loss of any data. It's not problem too. > > 3. [write back] attribute > In general, there is no way how to keep both parts consistent. At the > start of DMA transaction, the cache line is written back and > invalidated. However, as we know nothing about memory associated with > part A of the cache line, the cache line can be filled again at any > time and messing up DMA transaction if flushed. Even if the cache line > is only filled but not flushed during DMA transaction, we must make it > coherent with memory after that. There is a trick with saving part A > of the line into temporary buffer, invalidating the line, and > restoring part A in current ARM (MIPS) implementation. However, if > somebody is writting to memory associated with part A of the line > during this trick, the part A will be messed up. Moreover, the part A > can be part of another DMA transaction. > > To safely use DMA with no coherent memory, a memory with [no cache] or > [write throught] attributes can be used without problem. A memory with > [write back] attribute must be aligned on CACHE_LINE_SIZE. > > However, for example mbuf, a buffer for DMA can be part of a structure > which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We > can know that nobody will write to the structure during DMA > transaction, so it's safe to use the buffer event if it's not aligned > on CACHE_LINE_SIZE. > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > we want to avoid bounce pages overhead, we must support additional > information to DMA transaction. It should be easy to support the > information about drivers data buffers. However, what about OS data > buffers like mentioned mbufs? > > The question is following. Is or can be guaranteed for all or at least > well-known OS data buffers which can be part of DMA access that the > not CACHE_LINE_SIZE aligned buffers are surrounded by data which > belongs to the same object as the buffer and the data is not written > by OS when given to a driver? > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > Thanks, Svata Sigh. A several ideas by several people, but a good answer has not been created yet. SMP will make this worse. To make things worse, there are drivers that use memory from the stack as DMA buffers. I was hoping that mbufs are pretty well self-contained, unless you expect to modify them while DMA is happening. This is on my to-do list. --Mark. From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 20:07:32 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 505341065673 for ; Thu, 17 May 2012 20:07:32 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3169E8FC14 for ; Thu, 17 May 2012 20:07:32 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id B2dP1j0011zF43QA187XME; Thu, 17 May 2012 20:07:31 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id B87W1j00Z4NgCEG8k87XJd; Thu, 17 May 2012 20:07:31 +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 q4HK7TBr097698; Thu, 17 May 2012 14:07:29 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 May 2012 14:07:28 -0600 Message-ID: <1337285248.1503.308.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:07:32 -0000 On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: > Hi, > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > looked at implementation in ARM tree, but IMHO it only works with some > assumptions. There is a problem with DMA on memory block which is not > aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > Then first cache line associated with the buffer can be divided into > two parts, A and B, where A is a memory we know nothing about it and B > is buffer memory. The same stands for last cache line associatted with > the buffer. We have no problem if a memory is coherent. Otherwise it > depends on memory attributes. > > 1. [no cache] attribute > No problem as memory is coherent. > > 2. [write throught] attribute > The part A can be invalidated without loss of any data. It's not problem too. > > 3. [write back] attribute > In general, there is no way how to keep both parts consistent. At the > start of DMA transaction, the cache line is written back and > invalidated. However, as we know nothing about memory associated with > part A of the cache line, the cache line can be filled again at any > time and messing up DMA transaction if flushed. Even if the cache line > is only filled but not flushed during DMA transaction, we must make it > coherent with memory after that. There is a trick with saving part A > of the line into temporary buffer, invalidating the line, and > restoring part A in current ARM (MIPS) implementation. However, if > somebody is writting to memory associated with part A of the line > during this trick, the part A will be messed up. Moreover, the part A > can be part of another DMA transaction. > > To safely use DMA with no coherent memory, a memory with [no cache] or > [write throught] attributes can be used without problem. A memory with > [write back] attribute must be aligned on CACHE_LINE_SIZE. > > However, for example mbuf, a buffer for DMA can be part of a structure > which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We > can know that nobody will write to the structure during DMA > transaction, so it's safe to use the buffer event if it's not aligned > on CACHE_LINE_SIZE. > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > we want to avoid bounce pages overhead, we must support additional > information to DMA transaction. It should be easy to support the > information about drivers data buffers. However, what about OS data > buffers like mentioned mbufs? > > The question is following. Is or can be guaranteed for all or at least > well-known OS data buffers which can be part of DMA access that the > not CACHE_LINE_SIZE aligned buffers are surrounded by data which > belongs to the same object as the buffer and the data is not written > by OS when given to a driver? > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > Thanks, Svata I'm adding freebsd-arm@ to the CC list; that's where this has been discussed before. Your analysis is correct... to the degree that it works at all right now, it's working by accident. At work we've been making the good accident a bit more likely by setting the minimum allocation size to arm_dcache_align in kern_malloc.c. This makes it somewhat less likely that unrelated objects in the kernel are sharing a cache line, but it also reduces the effectiveness of the cache somewhat. Another factor, not mentioned in your analysis, is the size of the IO operation. Even if the beginning of the DMA buffer is cache-aligned, if the size isn't exactly a multiple of the cache line size you still have the partial flush situation and all of its problems. It's not guaranteed that data surrounding a DMA buffer will be untouched during the DMA, even when that surrounding data is part of the same conceptual object as the IO buffer. It's most often true, but certainly not guaranteed. In addition, as Mark pointed out in a prior reply, sometimes the DMA buffer is on the stack, and even returning from the function that starts the IO operation affects the cacheline associated with the DMA buffer. Consider something like this: void do_io() { int buffer; start_read(&buffer); // maybe do other stuff here wait_for_read_done(); } start_read() gets some IO going, so before it returns a call has been made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets done on the cacheline containing the variable 'buffer'. The act of returning from the start_read() function causes that cacheline to get reloaded, so now the stale pre-DMA value of the variable 'buffer' is in cache again. Right after that, the DMA completes so that ram has a newer value that belongs in the buffer variable and the copy in the cacheline is stale. Before control gets into the wait_for_read_done() routine that will attempt to handle the POSTREAD partial cacheline flush, another thread gets control and begins setting up a new DMA for another device, different buffer. This time it's a read using a 64K buffer for disk IO. The busdma sync code calls cpu_dcache_inv_range() for that buffer but because the range is so large, it gets turned into a cpu_dcache_wbinv_all() because that's cheaper than looping through an arbitrarily large range invalidating a line at a time. Except, ooops, that means we write back to ram the cacheline holding the stale value of the 'buffer' variable, wiping out the data brought in by DMA before the partial cachline flush code could do its dance to preserve it. There are several variations of the above scenario; it doesn't require a stack-allocated buffer to trigger a writeback of a stale value. Any cacheline that gets dirtied after a PREREAD invalidate can end up overwriting fresh DMA data in ram with stale data from the cacheline at any time, because any call to cpu_dcache_inv_range() or cpu_dcache_wbinv_range() can get turned into a cpu_dcache_wbinv_all(). That means any DMA operation and also a context switch which calls cpu_dcache_wbinv_all(). If you rule out bounce buffers as a solution, then I think that may leave us with just one option: make the pages uncacheable for the duration of the DMA. Essentially force a DMA_COHERENT buffer if the driver didn't already do so. I think doing so blindly may have performance implications every bit as bad as using bounce buffers. (For example, turning off cache on a stack page could really hurt.) The code to do the remapping already exists in pmap.c as part of handling multiple mappings for VIVT caches. From the busdma code you could accomplish the remapping by making a temporary writable kernel mapping for the buffer pages in the PRE handling and undo that mapping in the POST handling. It may be that a hybrid approach would work. For an unaligned buffer, if it isn't already DMA_COHERENT, then if it is below a certain size bounce it, otherwise remap the buffer's pages. When I was knee-deep in this problem last summer one of the things I noticed in our systems was that large DMA operations (1 KByte or larger buffers) tend to be DMA_COHERENT buffers, and when not they're already cache aligned and a power of two in size. For us the partial cacheline flush situations are almost always caused by tiny IO of 1 to 128 bytes length, usually serial-comms or usb related. I think pre-allocating a few pages for bouncing small unaligned IO would be a big win compared to remapping the pages as uncacheable. The remapping has to take locks and search lists of pages and so on; it should be way faster to do a small memcpy() instead. Buffers bigger than some (perhaps tunable) limit would get remapped instead of bounced. It also might be nice to have a knob to enable logging when bouncing or remapping is used to avoid partial cacheline operations, to make it easy to find drivers that could be tweaked for better performance. If you're bouncing 2 or 3 operations per second with a 4-byte buffer that's no big deal. If every network packet is resulting in bouncing/remapping you'd want to know about that. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 21:17:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7918E1065672 for ; Thu, 17 May 2012 21:17:10 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm5-vm1.bullet.mail.ne1.yahoo.com (nm5-vm1.bullet.mail.ne1.yahoo.com [98.138.91.32]) by mx1.freebsd.org (Postfix) with SMTP id 31AA88FC08 for ; Thu, 17 May 2012 21:17:10 +0000 (UTC) Received: from [98.138.90.52] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 21:17:04 -0000 Received: from [98.138.226.165] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 21:17:04 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 17 May 2012 21:17:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 143733.53294.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 95529 invoked by uid 60001); 17 May 2012 21:17:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337289423; bh=sWBO2XscNbWZVTR21yjTNpOggKxZZVBwtcTNuanQUpA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AOVBJERZPMHiQJ2F3jg/BHV/QIU2FMjGK40Tc8Iy6piB32HonXxNGzV/23Hkjsynn3gmBDDmIwxq9HhHOB4OR3k8W8XAlAaEszgGfEc/vMwksBDApvIn9CPuSadah6jxhSXMYvb4Y9uJ3298cZEZAmiXoGJBpTxt0mdFFuCk3uI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vV9r5IzQ6w0BfrEoI9502uGDrPPe4Ft7cRKbG6BdHYruIhWPd3mcfQws5BHw3L9YZ/kXfm2CyN48d4vHZMwNa6YYyRfbAFWY36FydIQyeOxvhQoDZlWglDNAZQo3LIjrLm5nWOjRM1OWcf3IOoSgVrtuk2ZYn/U7VGeTBA9DpPI=; X-YMail-OSG: m9MT9M4VM1nzpFLgyW8hzkYg_f8QdZK_pe6ky4eCcM4IyUq RIrHK7CZODkXq7jvg3hcZfYMDQnsPrRl9es_cOZexLTNkDdZl7EcoDpBn.56 lYSycxCwVAHxT10tzyECKO.s1IzHgKEF3LKFQAadfTkGhXULtF4vV1CI4MgX 4Dv7yF631c6XhbLjqoaLa9hRErOZ3IQGi0qIf6xms8OE75i1.h0opu4ZmnrA EuLAh1Pl9H1BLH5vGfICrReLIBuQ1rkPWMm4pxEVm3CbyeuAR4KqlLAdGqc8 frwDNlT_Sveh2w1boA62psJm.y7xbDeaCx7iIIgIOKXVIyIIEGfoPhTbAE40 3Lfs2aCtcX..IOyCOWAh8oZHZAS_YMp2KPdA.1uIIJJTCqNiq.q6ia2t9Y4T Ov4_JKvgCUoqGdMfYCMruKcxzjePMubTXyG8WZNcO3m77Z0vZZvtWf3HP90f gn8FIMvVRgf3R.NQzjpXUcwWVXibgX0xbeDfvgc_oM52WSimz0iMAnHz8y7t 3OfV4PWzBtdRbfVAE0xiniUVmgi_rMCoIxhcBAmCMtpc- Received: from [173.164.238.34] by web122503.mail.ne1.yahoo.com via HTTP; Thu, 17 May 2012 14:17:03 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337289423.15300.YahooMailClassic@web122503.mail.ne1.yahoo.com> Date: Thu, 17 May 2012 14:17:03 -0700 (PDT) From: Jason Usher To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 May 2012 21:26:42 +0000 Subject: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 21:17:10 -0000 I have some old 6.x FreeBSD systems that need their OpenSSH upgraded.=0A=0A= Everything goes just fine, but when I am done, existing clients are now pre= sented with this message:=0A=0A=0AWARNING: DSA key found for host hostname= =0Ain /root/.ssh/known_hosts:12=0ADSA key fingerprint 4c:29:4b:6e:b8:6b:fa:= 49.......=0A=0AThe authenticity of host 'hostname (10.1.2.3)' can't be esta= blished=0Abut keys of different type are already known for this host.=0ARSA= key fingerprint is a3:22:3d:cf:f2:46:09:f2......=0AAre you sure you want t= o continue connecting (yes/no)=0A=0A=0AAnd as you can imagine, existing aut= omated jobs now all fail.=0A=0AI have no control over the clients.=A0 Assum= e the clients cannot be touched at all.=0A=0ASo, the good news is, this app= ears to have been discussed/documented here:=0A=0Ahttp://www.mail-archive.c= om/bugs@crater.dragonflybsd.org/msg04860.html=0A=0A... but I'm afraid that = changing that line in myproposal.h BACK TO ssh-dss,ssh-rsa does not solve t= he problem.=A0 I did indeed make that change to myproposal.h, manually, and= then build the openssh-portable port, but the behavior persists.=0A=0AIf I= simply REMOVE the RSA keys, the error goes away, and existing DSA-using cl= ients no longer bomb out, but this is NOT a good solution for two reasons:= =0A=0A1. anytime I HUP, or start sshd, it's going to create new RSA keys fo= r me=0A=0A2. It's possible that some clients out there really have been usi= ng RSA all along (who knows) and now they are completely broken, since RSA = is not there at all.=0A=0AI'm more than happy to muck around in the source = with further little edits, just like I did with myproposal.h, but I have no= idea what they would be.=0A=0ACan anyone help me "make new ssh behave like= old one" ?=0A=0AThanks.=0A From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 22:17:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FFF2106566B for ; Thu, 17 May 2012 22:17:15 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 135C88FC15 for ; Thu, 17 May 2012 22:17:15 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2970347yhg.13 for ; Thu, 17 May 2012 15:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=zHwZQrcJgdfusqrhAhIhy6x+8Xwr/W6xwFfvNbktdJM=; b=ZblPldScTeo9CmdWLnI+MwDu1A5ddWsgQzEGgXAUX3tZIhBYotVyOsBBbzl1W4CRh+ aVaRmcmKENBMprBzog+X5Qw5IeYKJHhu9AeTXfr80eLwRL9n5zikqMkQGXxt7bxpsSbm eYrNme4BXx3+ZDUEip1wFkSQFfXXJIf4MwtHA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=zHwZQrcJgdfusqrhAhIhy6x+8Xwr/W6xwFfvNbktdJM=; b=mWT5K23aLbQrDX84ZT+9BzZ0rhBi8ZbK9sRRIt0FY6dI+sD78Qhl8iqb3vfWUfZGxt MbEX1om1wbsTKKtZBDgP3MTSEqNcJefMRIig0pSTg6vIKB6ngE7SFGKJzJWKD1DOlF2+ XQcB+Nldq2ruz1JqPHlhuwz6OItE67ZUbFFnqLACcejjg1WURwAwSQ5NzT4cC2t6aIPO BculO9sSrUA8XUYArvIcSyABJQYn5poPYAiZV/xU6ye1DjQmIGaNKoetef7U0OI2yGVX sqKcBRY7MfkJKwr8yJ3D3GZru04gXpSAOX+ji31aLTbMgB5HzYduqkxYXXZw1bc95jUE QiRA== Received: by 10.50.89.227 with SMTP id br3mr14030941igb.47.1337293033216; Thu, 17 May 2012 15:17:13 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id b11sm8826180igq.7.2012.05.17.15.17.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 15:17:12 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4HMH9pp029253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 18:17:10 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4HMH9J6028776; Thu, 17 May 2012 18:17:09 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 17 May 2012 18:17:09 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120517221709.GA47168@DataIX.net> References: <1337289423.15300.YahooMailClassic@web122503.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <1337289423.15300.YahooMailClassic@web122503.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQlOgcXw+cW9Hou7w5zOaEWBeygCW44ogSrJfWtZbi6y3/FchYOetfSMkDVSQURj8KtMLpNp Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 22:17:15 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher wrote: > I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. >=20 > Everything goes just fine, but when I am done, existing clients are now p= resented with this message: >=20 >=20 > WARNING: DSA key found for host hostname > in /root/.ssh/known_hosts:12 > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49....... >=20 > The authenticity of host 'hostname (10.1.2.3)' can't be established > but keys of different type are already known for this host. > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2...... > Are you sure you want to continue connecting (yes/no) >=20 You must be using different keys for your server than the one that has been generated before the upgrade. Just copy your keys over to the new location and restart the server daemon and you should be fine. copy /etc/ssh/* -> /usr/local/etc/ssh/ >=20 > And as you can imagine, existing automated jobs now all fail. >=20 > I have no control over the clients.? Assume the clients cannot be touched= at all. >=20 > So, the good news is, this appears to have been discussed/documented here: >=20 > http://www.mail-archive.com/bugs@crater.dragonflybsd.org/msg04860.html >=20 > ... but I'm afraid that changing that line in myproposal.h BACK TO ssh-ds= s,ssh-rsa does not solve the problem.? I did indeed make that change to myp= roposal.h, manually, and then build the openssh-portable port, but the beha= vior persists. >=20 > If I simply REMOVE the RSA keys, the error goes away, and existing DSA-us= ing clients no longer bomb out, but this is NOT a good solution for two rea= sons: >=20 > 1. anytime I HUP, or start sshd, it's going to create new RSA keys for me >=20 > 2. It's possible that some clients out there really have been using RSA a= ll along (who knows) and now they are completely broken, since RSA is not t= here at all. >=20 > I'm more than happy to muck around in the source with further little edit= s, just like I did with myproposal.h, but I have no idea what they would be. >=20 > Can anyone help me "make new ssh behave like old one" ? >=20 > Thanks. >=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 - (2^(N-1)) --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPtXjkAAoJEBSh2Dr1DU7WacoIAKt4D9JBDM53SFKhqSsrKqMu neb49B0tmSo1JgNTDHOm6Yix1tuWExxIhXjXihroUZL8EYuzNRsLGoaDdO7+Gb3Q JXoojO6MMBA1SCYOpbFqTKl9WhX+U2uhxuuqerXNwtRGoev1pu8dw7blUgZMX9X2 QnXE1TfD1PY1qtQZixqCiZFlmphzpZW53ouOUQPn7rjY9cRsBFZuw2wriDtvBOg+ HntuIFFP032EM8yIPp43izZDOW2Y5MIfNHF+98f+1S00WGEwxkiPBJc2DwF0F/Og RGwGrgZ66BB2q8i7N5TBE4JOcJbV8GstqxyPdR0548EDG/egXAr0so5oeyMH9ik= =qMpP -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 23:22:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF0E01065672 for ; Thu, 17 May 2012 23:22:43 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 568278FC1C for ; Thu, 17 May 2012 23:22:43 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2993127ggn.13 for ; Thu, 17 May 2012 16:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=eoqVUbYxSpbK6v8iOlNcB2mAu6AwAC6lFaBcoyJCd8o=; b=NHzQFGxnYPC5t7FcQ+wIgKCPwqrPXXurEwYvSYK/TzHJH//ydv+kVTwcAlSvBvT0rE xqnJ4lqYwU0zNCgVFkUznaQiJ83KWJANCpp5dxCrAtWXBRRZrJ0noREMHJJmYs4ZWJ1V 3V9nuv2JHp4MvfVTe9zsBFHcFI+hKRU463SRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=eoqVUbYxSpbK6v8iOlNcB2mAu6AwAC6lFaBcoyJCd8o=; b=cAGoBePl4IEniZ+YYR4hIwJa5w3sojiylQuZ08tBTi5uJzLh0SenNnsKjl8kzv6omq RSGDTBr/LTKV1ZbFV2n77fllVdgWwH7GyT9H14YCbDdP88ODewRe+hI9FtnQO4+8eJkt deMF5IEWO0VEuDgLS2cFEiCwOrItSjEqcqNsOZd2gHzwLBpebN0k3vWpPz+VujwXx89c QU3APQK6aRU03j1o5CXkxjymtdrbOizWSdmGE8lZ54Du/HKR3P9uZZSl/RPOxlQNu1ki I3LnFv50IkeMwsF0vDwdCb2L43aJbl/bNpwMf1k30E0hJdTAONDxge02AOV/hLMK1pOO 9v9A== Received: by 10.42.19.138 with SMTP id c10mr1266226icb.27.1337296962339; Thu, 17 May 2012 16:22:42 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id ay4sm9031609igb.1.2012.05.17.16.22.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 16:22:42 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4HNMd76084474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 19:22:39 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4HNMctP084209; Thu, 17 May 2012 19:22:38 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 17 May 2012 19:22:38 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120517232238.GA91365@DataIX.net> References: <20120517221709.GA47168@DataIX.net> <1337295971.82236.YahooMailClassic@web122505.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337295971.82236.YahooMailClassic@web122505.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQlGM202kmzIYii0ntvMhxtWyNl9NEEFo8eR9QesulyNzKMXdYFuSXmvD30Lgu2CTVGItrvS Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:22:43 -0000 On Thu, May 17, 2012 at 04:06:11PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > > wrote: > > > I have some old 6.x FreeBSD systems that need their > > OpenSSH upgraded. > > > > > > Everything goes just fine, but when I am done, existing > > clients are now presented with this message: > > > > > > > > > WARNING: DSA key found for host hostname > > > in /root/.ssh/known_hosts:12 > > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49....... > > > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > > established > > > but keys of different type are already known for this > > host. > > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2...... > > > Are you sure you want to continue connecting (yes/no) > > > > > > > You must be using different keys for your server than the > > one that has > > been generated before the upgrade. Just copy your keys over > > to the new > > location and restart the server daemon and you should be > > fine. > > > > copy /etc/ssh/* -> /usr/local/etc/ssh/ > > > You didn't read that error message. Sorry I misread that. Decieving message... > > That is not the standard "key mismatch" error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. > > The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. > > I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). Have you attempted to change that order via sshd_config and placing the DSA directive before the RSA one ? -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 01:19:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6479A106566C for ; Fri, 18 May 2012 01:19:08 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC2D58FC0C for ; Fri, 18 May 2012 01:19:07 +0000 (UTC) Received: by yenl8 with SMTP id l8so3050771yen.13 for ; Thu, 17 May 2012 18:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=mO7wrAh9GLyuI/xQ64aX1AxIFgD2632zBvObUZGtx2Q=; b=T4BjYkw8Ms6hVWi9WpSLt918MA18YY8nC82Jq8Vtj4eaBmi/H75BiUpf/x1b8BXwrv ud5wxP3enc7LJKJLi7qnJPz2Tn+2UzgX4VeXmv1IkIUOP7ir5t6CDghbqH4XoDY+7yWY xkS8ArZKSCsVJ7CKpdB6QZOiMvKujRskiDAWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=mO7wrAh9GLyuI/xQ64aX1AxIFgD2632zBvObUZGtx2Q=; b=a3Mr4Eajf1EQ2HFjuRuW+tUhcpiYYyl50KrDzi5OP26qaK2YJ5Fz+1M7U+hS+8OSSF YWiPo7vn4QTiTMP2UX3VmqG0es+vJhSh5h8lzWg3lvlYJsDfudVz6b1ofenPpUERLUmg +7jZtbB5cmrMMer6VjV7ojVkra9mcfBlzfghsyQvfymSlrX/KboidY0Mk8syjTCWKXSD ylzvdRFYCS3ZM3abUA0S8NKVp3yOYvWTQ/zelfYrJ8+9tcp9zhXenCxB6aHxuWa0DC0/ LPh9I7IzY+tyum+5rATM5cJDsfJInoRGETaTQSOxW+WMVJo+gSJ4hKlwKrqRB/zd/B44 SuEQ== Received: by 10.42.89.72 with SMTP id f8mr6103630icm.33.1337303946680; Thu, 17 May 2012 18:19:06 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id eo5sm12064317igc.7.2012.05.17.18.19.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 May 2012 18:19:06 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4I1J4W4059176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 21:19:04 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4I1J478059108; Thu, 17 May 2012 21:19:04 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 17 May 2012 21:19:04 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120518011904.GA82007@DataIX.net> References: <20120517232238.GA91365@DataIX.net> <1337297198.76003.YahooMailClassic@web122503.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337297198.76003.YahooMailClassic@web122503.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQlRGUuVFkf9FxDK4faMTSfCTQh/Io1kMFN5QsCB5WI15wRxkZDF0ll+3/aOMeHdRNFVRHaA Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 01:19:08 -0000 On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > > That is not the standard "key mismatch" error that you > > assumed it was.? Look at it again - it is saying that > > we do have a key for this server of type DSA, but the client > > is receiving one of type RSA, etc. > > > > > > The keys are the same - they have not changed at all - > > they are just being presented to clients in the reverse > > order, which is confusing them and breaking automated, > > key-based login. > > > > > > I need to take current ssh server behavior (rsa, then > > dss) and change it back to the old order (dss, then rsa). > > > > Have you attempted to change that order via sshd_config and > > placing the > > DSA directive before the RSA one ? > > > sshd_config has no such config directive. ssh_config does, but that's for clients, and I have no way to interact with the clients. > > It would indeed be very nice if this key order, which seems like a prime candidate for configuration, was a configurable option in sshd_config, but it is not. > > I am fairly certain that I need to hack up some source files, and I thought I had it with myproposal.h (see link in OP) but there must be more, because that small change does not fix things... You don't have any of this in your config ? # HostKey for protocol version 1 #HostKey /usr/local/etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh/ssh_host_rsa_key #HostKey /usr/local/etc/ssh/ssh_host_dsa_key #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 23:01:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B93C91065672 for ; Thu, 17 May 2012 23:01:59 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm37-vm2.bullet.mail.ne1.yahoo.com (nm37-vm2.bullet.mail.ne1.yahoo.com [98.138.229.130]) by mx1.freebsd.org (Postfix) with SMTP id 637A28FC14 for ; Thu, 17 May 2012 23:01:59 +0000 (UTC) Received: from [98.138.90.57] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:01:58 -0000 Received: from [98.138.226.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:01:58 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:01:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 603691.84212.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 22319 invoked by uid 60001); 17 May 2012 23:01:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337295718; bh=1i/A/Qr9HjezPqxc89vS9EDEjkW38J5qkOsCVMj6NFE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Svt6a2Tl864qzcGxoZlIAYMCVXB8P7oGDGNYvRvPx5fciH+K3F5Xu1n7/Bx9qaPPsjqCbY7vDu3WSgJQmGRw2ejtNmObKDCY3Ba1MZBHSe3I1MiJIra/sq9zZZOUj8N+jmt4XwF8q651qV9sbM5z6UyYZXy2zH6V5zeA1ISCBAQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z3fNrwxoPVoK2l5dVjHVIl+1br7v8HO7aoscTLTVwGxot3/X9YZH85q1FjkfdliL9zLPdq1EoU1ofaPmARBn/U/kVF21BEWGidQCxTaKMu53VxxOh9/Z0FC4zVWvCagE2I9eNGN0uFaWb4a4LYQ+CL1Rda/l3MbiNugPCblT+Eg=; X-YMail-OSG: Ye8PsDUVM1lejoJTlp2aPN7fvnF7oeTr_BHShKW0l7D08RY _cfPDhGDj72oQIZStP0G4.c8rHY_HAjsGixLr07Sp5NZRZalDUbY4Dvr5mzE MId5S8qF26GXCP9eEd27jqLkBXC.wgEB8tj.d653N4la6oPHdwekX6MLI4.c gHfAfF1qiIrateUSZEcc3IdEAO82_J5MycDOFQkdh2Ack64eQs6SDAA_rNgH 8ZQKfMGMtj3jNkQaU1YPJYMdn2X0XeS4eToWaGuWlAmnS4DN_EkTbGZmMKOs Kc9tcS_J9EAnpVP8IZf97qkzv7cFtNTqKGqCy0yZum_HLthnOdf6_1h2E5Zo e5LjtoSpC0UILCQu9ufspVgpEFUlawW0qOSe3V0i0h45w1jh.b93tXalLm0h GGAhUytQqsJitwmKeE3nTnT1d Received: from [173.164.238.34] by web122504.mail.ne1.yahoo.com via HTTP; Thu, 17 May 2012 16:01:58 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337295718.17290.YahooMailClassic@web122504.mail.ne1.yahoo.com> Date: Thu, 17 May 2012 16:01:58 -0700 (PDT) From: Jason Usher To: Garrett Cooper In-Reply-To: <19CAB027-0B70-43FE-AEF5-11A6D548282D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 May 2012 02:37:06 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:01:59 -0000 =0A=0A--- On Thu, 5/17/12, Garrett Cooper wrote:=0A=0A= > > ... but I'm afraid that changing that line in=0A> myproposal.h BACK TO = ssh-dss,ssh-rsa does not solve the=0A> problem.=C2=A0 I did indeed make tha= t change to=0A> myproposal.h, manually, and then build the openssh-portable= =0A> port, but the behavior persists.=0A> > =0A> > If I simply REMOVE the R= SA keys, the error goes away,=0A> and existing DSA-using clients no longer = bomb out, but this=0A> is NOT a good solution for two reasons:=0A> > =0A> >= 1. anytime I HUP, or start sshd, it's going to create=0A> new RSA keys for= me=0A> > =0A> > 2. It's possible that some clients out there really=0A> ha= ve been using RSA all along (who knows) and now they are=0A> completely bro= ken, since RSA is not there at all.=0A> > =0A> > I'm more than happy to muc= k around in the source with=0A> further little edits, just like I did with = myproposal.h, but=0A> I have no idea what they would be.=0A> > =0A> > Can a= nyone help me "make new ssh behave like old one"=0A> ?=0A> =0A> You can pro= bably issue an option via -o with ssh to skip the=0A> prompt (see ssh_confi= g=E2=80=A6 maybe there's something in there=0A> that can help you). No, I'm= not referring to=0A> StrictHostKeyChecking either :).=0A=0A=0AThat's on th= e client side.=0A=0AI don't have access to the clients. I have no way to i= nteract with the clients at all.=0A=0AI need a way to configure (or patch) = the OpenSSH server such that it presents keys in the same order (first DSS,= then RSA) as it used to.=0A=0AAnyone ? From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 23:06:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84EF3106564A for ; Thu, 17 May 2012 23:06:40 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm6-vm3.bullet.mail.ne1.yahoo.com (nm6-vm3.bullet.mail.ne1.yahoo.com [98.138.91.136]) by mx1.freebsd.org (Postfix) with SMTP id 39D9B8FC15 for ; Thu, 17 May 2012 23:06:17 +0000 (UTC) Received: from [98.138.90.50] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:06:11 -0000 Received: from [98.138.89.172] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:06:11 -0000 Received: from [127.0.0.1] by omp1028.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:06:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 600052.8968.bm@omp1028.mail.ne1.yahoo.com Received: (qmail 10531 invoked by uid 60001); 17 May 2012 23:06:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337295971; bh=9y7DYA2FCuNNE4Y7NA2Q+DU3RQceqJgju0zZt8QDaE4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vB6DIKn5eLNPDnYG7O+pnYLTNj8m+Fl6oiMXBacpBavle/z1fW9pwwx07yIgw7+0ot9lJAvetW5HyZEOtSA2G/8QqeljWsojgkuB3A1jVESfySf7revwEwIitQixgn/rNo22EQgSDyml8KB2JMSWwHnWP8c/155px65F+JOyrIg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=v+TJPSrW8dTN5dfl1gTvOc1n+nNSKt8CcLVG5eaxiuzlmpOGLRgjcXtauvsuWnH5uKFO49eLoxTmIqxVmyABj87L6dA2hrZa6PH4cWw4ROBzFiUW/2/3lp8yluwlyHhe2B2X4ERBY56cB5KXmSFsFz+W5rhnICaJx9THFUZthOk=; X-YMail-OSG: fnr2PAEVM1npm61GPm4xiNBF7CJNXMIYOcpipZDB4HX6W9Q OmUEgNpvYDk53rUdvuRFD5X.2AAbfQyE9yOFJIuRtRVx7mQux6ZN34AclHFa 1Z5FcE_9Z0wQsLgBvomu0VAFLif5GVH5Dp_b2Ypr60wxmNidO_bPa5gAMhpB fA3PQ2a578twvWNZ3J_FWcHwModiu3bTxeOa_VTokfhpjhnzuyMa4ezFt96f s5Ky6BBJT.XwTVfN8iMvYo64L5yRsTOXcoyulz0ON2J5mc2NLYYoV7idvF7w QT4KDAZ59rVACwnkFCfkQ_lIF051tNW5JF9csyAsoSVjqZivXy4oKfmdS8ha oc1FpKlC8yDAop6YDmaj27uTXiB6LekZl.ppxk0vET7V7n32VU7hGNL4aWfr gucgNZOKbG5ghOZIO3IoJravdv6N_rNRZo1NPLUrjGdDO4y4cNQ-- Received: from [173.164.238.34] by web122505.mail.ne1.yahoo.com via HTTP; Thu, 17 May 2012 16:06:11 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337295971.82236.YahooMailClassic@web122505.mail.ne1.yahoo.com> Date: Thu, 17 May 2012 16:06:11 -0700 (PDT) From: Jason Usher To: Jason Hellenthal In-Reply-To: <20120517221709.GA47168@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 18 May 2012 02:37:23 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:06:40 -0000 --- On Thu, 5/17/12, Jason Hellenthal wrote: > On Thu, May 17, 2012 at 02:17:03PM -0700, Jason Usher > wrote: > > I have some old 6.x FreeBSD systems that need their > OpenSSH upgraded. > > > > Everything goes just fine, but when I am done, existing > clients are now presented with this message: > > > > > > WARNING: DSA key found for host hostname > > in /root/.ssh/known_hosts:12 > > DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49....... > > > > The authenticity of host 'hostname (10.1.2.3)' can't be > established > > but keys of different type are already known for this > host. > > RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2...... > > Are you sure you want to continue connecting (yes/no) > > > > You must be using different keys for your server than the > one that has > been generated before the upgrade. Just copy your keys over > to the new > location and restart the server daemon and you should be > fine. > > copy /etc/ssh/* -> /usr/local/etc/ssh/ You didn't read that error message. That is not the standard "key mismatch" error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). From owner-freebsd-hackers@FreeBSD.ORG Thu May 17 23:26:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F69B1065670 for ; Thu, 17 May 2012 23:26:39 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm16-vm2.bullet.mail.ne1.yahoo.com (nm16-vm2.bullet.mail.ne1.yahoo.com [98.138.91.92]) by mx1.freebsd.org (Postfix) with SMTP id 406538FC14 for ; Thu, 17 May 2012 23:26:39 +0000 (UTC) Received: from [98.138.90.52] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:26:38 -0000 Received: from [98.138.88.238] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:26:38 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 17 May 2012 23:26:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 769988.34560.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 98261 invoked by uid 60001); 17 May 2012 23:26:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337297198; bh=I/Qzprx/MmyA3t575CKC9cwM5eEmsyKoXwW5huu8Xj8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UQo/1bLcfXoK+g0DniGzULHE/M7csdVsN+s7YjF/UM8EfOMHwUKr95LXrrCRsLNIAY0enajR+FmzzqDfIobZv/orPpJdcBQNLWgy+e7l8owotns8x7iqOBGf2X4JS9kEckisyket7uFghPz8HddEwg+SFaXAvnKuP5eJg306W8A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Du7nosBf2cOFILtkmVPPqpOtoTP8qg1x0iFti5kjLbrMCCuKtGb2BYSjZN181OOtQl2hO7d628p6HQxB35dex4QuwHit7KqP1weom25DwQx+WKe/i+u2+8+j5bDya24ehIe1djQAHdgnDk08UvJ6S6CiYhQnZJoEYxaUW1HM1/k=; X-YMail-OSG: hd3op6YVM1lN8E1H_osubS6uFbRoYZxnRXOxu4R1jYapGA5 jJOT6UZcgcdg2kJu.95YnKAsJ1lKmt4bTIi2Qtv2Hd_Njbtb2D8kdaN3GGQ3 s2i5m4o8v6QiooqFl7eU2IZOAYyjhwY0eP_w4QchJtXi_mwLXbaABpO3uFtu LfDwojjLcEQdQ7_jzBOO19ssOqV4pzSEZDpvIoE5RCDVAZOLe2b2XaqRUAmA ll0vRszTrhI9cDXmU4PXSyhqz0MTw4ToYlgPCwuD9YMLldUGQ0JbHMdZQCcz RirVliAZ9BgG4h2LVwF8hKeXukDq3AJ7B4x221tEJm99eqQhCQft3pbRfqBp RDoiYGy4KQjtKZHF37mgJZENil21tfR7H_W_fjnbVwtbV2jARUSs8PR7TaFl vsnQ2TE.37Qg1XPTM16bsqkpZnbeRykExPdnvdyG3dKVnSCvpbg-- Received: from [173.164.238.34] by web122503.mail.ne1.yahoo.com via HTTP; Thu, 17 May 2012 16:26:38 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337297198.76003.YahooMailClassic@web122503.mail.ne1.yahoo.com> Date: Thu, 17 May 2012 16:26:38 -0700 (PDT) From: Jason Usher To: Jason Hellenthal In-Reply-To: <20120517232238.GA91365@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 May 2012 02:38:58 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:26:39 -0000 =0A=0A--- On Thu, 5/17/12, Jason Hellenthal wrote:= =0A=0A> > That is not the standard "key mismatch" error that you=0A> assume= d it was.=A0 Look at it again - it is saying that=0A> we do have a key for = this server of type DSA, but the client=0A> is receiving one of type RSA, e= tc.=0A> > =0A> > The keys are the same - they have not changed at all -=0A>= they are just being presented to clients in the reverse=0A> order, which i= s confusing them and breaking automated,=0A> key-based login.=0A> > =0A> > = I need to take current ssh server behavior (rsa, then=0A> dss) and change i= t back to the old order (dss, then rsa).=0A> =0A> Have you attempted to cha= nge that order via sshd_config and=0A> placing the=0A> DSA directive before= the RSA one ?=0A=0A=0Asshd_config has no such config directive. ssh_confi= g does, but that's for clients, and I have no way to interact with the clie= nts.=0A=0AIt would indeed be very nice if this key order, which seems like = a prime candidate for configuration, was a configurable option in sshd_conf= ig, but it is not.=0A=0AI am fairly certain that I need to hack up some sou= rce files, and I thought I had it with myproposal.h (see link in OP) but th= ere must be more, because that small change does not fix things... From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 08:33:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79636106564A for ; Fri, 18 May 2012 08:33:56 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail-new.kirov.so-ups.ru (mail-new.kirov.so-ups.ru [178.74.170.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2206F8FC12 for ; Fri, 18 May 2012 08:33:56 +0000 (UTC) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail-new.kirov.so-ups.ru (Postfix) with ESMTP id 38669A1E27; Fri, 18 May 2012 12:25:00 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 86807B9FC0; Fri, 18 May 2012 12:24:42 +0400 (MSK) Received: from [127.0.0.1] (unknown [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 50EBAB9FB0; Fri, 18 May 2012 12:24:42 +0400 (MSK) Message-ID: <4FB6074A.3000802@FreeBSD.org> Date: Fri, 18 May 2012 12:24:42 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Eric McCorkle References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> <4FB33BD9.3030501@FreeBSD.org> <4FB4FCE2.7060509@shadowsun.net> In-Reply-To: <4FB4FCE2.7060509@shadowsun.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 08:33:56 -0000 On 17.05.2012 17:28, Eric McCorkle wrote: >> As i see we already have sys/boot/efi/libefi/efipart.c that uses >> EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL >> provides access to each disk and partition. AFAIK it supports only >> GPT and MBR+EBR, so there might be some problems with ZFS support, >> because we can use ZFS atop of BSD partition. > > > I'd need to take a look, but if the efi loaders are not directly > calling the EFI_BLOCK_IO_PROTOCOL functions, then it should be easy to > implement a layer that understands BSDlabels. IA64 might have a solution. > > Then again, is a BSDlabel really necessary on a GPT disk? It might be necessary for the ZFS case. ZFS can use several devices/partitions and they should be accessible while booting. -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 10:20:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B888D1065679 for ; Fri, 18 May 2012 10:20:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 6E11D8FC1D for ; Fri, 18 May 2012 10:20:12 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1SVK8E-0006c8-Ks for freebsd-hackers@freebsd.org; Fri, 18 May 2012 13:09:58 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 May 2012 13:09:58 +0300 From: Daniel Braniss Message-ID: Subject: portmaster and php 5.4/5.3 issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 10:20:12 -0000 hi, doing portmaster -a today wants to upgrade php5.3 to php5.4 which I'm not ready yet, so I dis-installed php5 and installed php53, but now portmaster wants to upgrade the php extentiosn to 5.4 even though php is 5.3.13. what (if any :-), is the magic to convince portmaster to compile the php53-* extensions instead of php5-* extensions? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 14:13:44 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B245106566C; Fri, 18 May 2012 14:13:44 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC718FC0C; Fri, 18 May 2012 14:13:43 +0000 (UTC) Received: by laai10 with SMTP id i10so2956261laa.13 for ; Fri, 18 May 2012 07:13: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=Uqzy/MF3GEKb4ELQoTPrC7ndv18u7EXDo3wTOpWQVlQ=; b=DYbMMoKTyxXfRZxWBU+HhFji+zH13xLbrgI03eCYjuAJegPCi9R5lmgcaJ57BPAo1Q b5N7bAUAxsxNDyvllLB9CiY33Cmr+I/XLXw9T0ntkBfA7WhfhHW/4th5k0Wt2Pye/Wjf 3x2vD6wkBzUP01NnD9h0WToXXZwvZf3ValUb1GZKfmvol97pGz/CCEefIzRe8/stiHIj 4mgCsZ3mvzbHnE/UBYGtdo70nPixyg70zDi8T9lvDR7Sl295/tkkL8IikyjNfEd7L+Av FN9NAkLPtI4m7nONEYumuvLgTf0Bql3hThKByUajqsagZk8rQWmIWRA+dGjmm8tYiop7 jbcA== MIME-Version: 1.0 Received: by 10.152.48.6 with SMTP id h6mr11237327lan.30.1337350421929; Fri, 18 May 2012 07:13:41 -0700 (PDT) Received: by 10.112.60.65 with HTTP; Fri, 18 May 2012 07:13:41 -0700 (PDT) In-Reply-To: <1337285248.1503.308.camel@revolution.hippie.lan> References: <1337285248.1503.308.camel@revolution.hippie.lan> Date: Fri, 18 May 2012 16:13:41 +0200 Message-ID: From: Svatopluk Kraus To: Ian Lepore , Mark Tinguely , Richard Hodges Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:13:44 -0000 On Thu, May 17, 2012 at 10:07 PM, Ian Lepore wrote: > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: >> Hi, >> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've >> looked at implementation in ARM tree, but IMHO it only works with some >> assumptions. There is a problem with DMA on memory block which is not >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. >> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. >> Then first cache line associated with the buffer can be divided into >> two parts, A and B, where A is a memory we know nothing about it and B >> is buffer memory. The same stands for last cache line associatted with >> the buffer. We have no problem if a memory is coherent. Otherwise it >> depends on memory attributes. >> >> 1. [no cache] attribute >> No problem as memory is coherent. >> >> 2. [write throught] attribute >> The part A can be invalidated without loss of any data. It's not problem= too. >> >> 3. [write back] attribute >> In general, there is no way how to keep both parts consistent. At the >> start of DMA transaction, the cache line is written back and >> invalidated. However, as we know nothing about memory associated with >> part A of the cache line, the cache line can be filled again at any >> time and messing up DMA transaction if flushed. Even if the cache line >> is only filled but not flushed during DMA transaction, we must make it >> coherent with memory after that. There is a trick with saving part A >> of the line into temporary buffer, invalidating the line, and >> restoring part A in current ARM (MIPS) implementation. However, if >> somebody is writting to memory associated with part A of the line >> during this trick, the part A will be messed up. Moreover, the part A >> can be part of another DMA transaction. >> >> To safely use DMA with no coherent memory, a memory with [no cache] or >> [write throught] attributes can be used without problem. A memory with >> [write back] attribute must be aligned on CACHE_LINE_SIZE. >> >> However, for example mbuf, a buffer for DMA can be part of a structure >> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We >> can know that nobody will write to the structure during DMA >> transaction, so it's safe to use the buffer event if it's not aligned >> on CACHE_LINE_SIZE. >> >> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and >> we want to avoid bounce pages overhead, we must support additional >> information to DMA transaction. It should be easy to support the >> information about drivers data buffers. However, what about OS data >> buffers like mentioned mbufs? >> >> The question is following. Is or can be guaranteed for all or at least >> well-known OS data buffers which can be part of DMA access that the >> not CACHE_LINE_SIZE aligned buffers are surrounded by data which >> belongs to the same object as the buffer and the data is not written >> by OS when given to a driver? >> >> Any answer is appreciated. However, 'bounce pages' is not an answer. >> >> Thanks, Svata > > I'm adding freebsd-arm@ to the CC list; that's where this has been > discussed before. > > Your analysis is correct... to the degree that it works at all right > now, it's working by accident. =A0At work we've been making the good > accident a bit more likely by setting the minimum allocation size to > arm_dcache_align in kern_malloc.c. =A0This makes it somewhat less likely > that unrelated objects in the kernel are sharing a cache line, but it > also reduces the effectiveness of the cache somewhat. > > Another factor, not mentioned in your analysis, is the size of the IO > operation. =A0Even if the beginning of the DMA buffer is cache-aligned, i= f > the size isn't exactly a multiple of the cache line size you still have > the partial flush situation and all of its problems. > > It's not guaranteed that data surrounding a DMA buffer will be untouched > during the DMA, even when that surrounding data is part of the same > conceptual object as the IO buffer. =A0It's most often true, but certainl= y > not guaranteed. =A0In addition, as Mark pointed out in a prior reply, > sometimes the DMA buffer is on the stack, and even returning from the > function that starts the IO operation affects the cacheline associated > with the DMA buffer. =A0Consider something like this: > > =A0 =A0void do_io() > =A0 =A0{ > =A0 =A0 =A0 =A0int buffer; > =A0 =A0 =A0 =A0start_read(&buffer); > =A0 =A0 =A0 =A0// maybe do other stuff here > =A0 =A0 =A0 =A0wait_for_read_done(); > =A0 =A0} > > start_read() gets some IO going, so before it returns a call has been > made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets > done on the cacheline containing the variable 'buffer'. =A0The act of > returning from the start_read() function causes that cacheline to get > reloaded, so now the stale pre-DMA value of the variable 'buffer' is in > cache again. =A0Right after that, the DMA completes so that ram has a > newer value that belongs in the buffer variable and the copy in the > cacheline is stale. > > Before control gets into the wait_for_read_done() routine that will > attempt to handle the POSTREAD partial cacheline flush, another thread > gets control and begins setting up a new DMA for another device, > different buffer. =A0This time it's a read using a 64K buffer for disk IO= . > The busdma sync code calls cpu_dcache_inv_range() for that buffer but > because the range is so large, it gets turned into a > cpu_dcache_wbinv_all() because that's cheaper than looping through an > arbitrarily large range invalidating a line at a time. > > Except, ooops, that means we write back to ram the cacheline holding the > stale value of the 'buffer' variable, wiping out the data brought in by > DMA before the partial cachline flush code could do its dance to > preserve it. > > There are several variations of the above scenario; it doesn't require a > stack-allocated buffer to trigger a writeback of a stale value. =A0Any > cacheline that gets dirtied after a PREREAD invalidate can end up > overwriting fresh DMA data in ram with stale data from the cacheline at > any time, because any call to cpu_dcache_inv_range() or > cpu_dcache_wbinv_range() can get turned into a cpu_dcache_wbinv_all(). > That means any DMA operation and also a context switch which calls > cpu_dcache_wbinv_all(). > > If you rule out bounce buffers as a solution, then I think that may > leave us with just one option: =A0make the pages uncacheable for the > duration of the DMA. =A0Essentially force a DMA_COHERENT buffer if the > driver didn't already do so. =A0I think doing so blindly may have > performance implications every bit as bad as using bounce buffers. =A0(Fo= r > example, turning off cache on a stack page could really hurt.) =A0The cod= e > to do the remapping already exists in pmap.c as part of handling > multiple mappings for VIVT caches. =A0From the busdma code you could > accomplish the remapping by making a temporary writable kernel mapping > for the buffer pages in the PRE handling and undo that mapping in the > POST handling. > > It may be that a hybrid approach would work. =A0For an unaligned buffer, > if it isn't already DMA_COHERENT, then if it is below a certain size > bounce it, otherwise remap the buffer's pages. =A0When I was knee-deep in > this problem last summer one of the things I noticed in our systems was > that large DMA operations (1 KByte or larger buffers) tend to be > DMA_COHERENT buffers, and when not they're already cache aligned and a > power of two in size. =A0For us the partial cacheline flush situations ar= e > almost always caused by tiny IO of 1 to 128 bytes length, usually > serial-comms or usb related. Good to know. > > I think pre-allocating a few pages for bouncing small unaligned IO would > be a big win compared to remapping the pages as uncacheable. =A0The > remapping has to take locks and search lists of pages and so on; it > should be way faster to do a small memcpy() instead. =A0Buffers bigger > than some (perhaps tunable) limit would get remapped instead of > bounced. > > It also might be nice to have a knob to enable logging when bouncing or > remapping is used to avoid partial cacheline operations, to make it easy > to find drivers that could be tweaked for better performance. =A0If you'r= e > bouncing 2 or 3 operations per second with a 4-byte buffer that's no big > deal. =A0If every network packet is resulting in bouncing/remapping you'd > want to know about that. It sounds resonable for me. > > -- Ian Thanks for replies. So, we have to check DMA buffers if they are aligned and if not, we have two possibilies in general. 1. To not assume anything about surrounding data around unaligned DMA buffer at all. This always leads to bouncing or memory attributes changing in no coherent case. 2. To add new flag (something like BUS_DMA_UNALIGNED_SAFE) and set it in dmamap load functions in cases that we know it's safe to use an unaligned buffer. This way we can avoid bouncing in some cases. I didn't know about drivers that are using DMA buffers on stack. However, to patch such a driver is something I can do on my own. I.e., I always can decide that a driver buffer is safe for DMA even unaligned. Moreover, for example, DMA descriptors rings are defined as an array in some net drivers and a descriptor size could be smaller than CACHE_LINE_SIZE. The drivers must be modified anyway to made descriptors coherent or aligned. What I can do in a driver it's not so simple in case of OS buffers like mbufs. I can check how mbufs are used in current implementation and say, yes, it's safe to use them unaligned. However, it can be changed in next release if anybody won't take care of it. It would be nice to have a maintained list of OS buffers which are DMA safe in respect of CACHE_LINE_SIZE. Is the flag and the list interesting for somebody else? Some more notes. SMP makes things worse and ARM11mpcore is about SMP too. For example, another thread could be open about that how to flush caches (exclusive L1 cache) in SMP case. I'm not sure how to correctly change memory attributes on page which is in use. Making new temporary mapping with different attributes is wrong and does not help at all. It's question how to do TLB and cache flushes on two and more processors and be sure that everything is OK. It could be slow and maybe, changing memory attributes on the fly is not a good idea at all. Svata From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 14:52:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46DDF106566C for ; Fri, 18 May 2012 14:52:04 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1514E8FC14 for ; Fri, 18 May 2012 14:52:04 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 0364A7E851; Fri, 18 May 2012 06:52:01 -0800 (AKDT) Message-ID: <4FB6620D.8060001@acsalaska.net> Date: Fri, 18 May 2012 16:51:57 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mateusz Guzik References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr> <20120517125348.GA26081@dft-labs.eu> In-Reply-To: <20120517125348.GA26081@dft-labs.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, tzabal@it.teithe.gr Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:52:04 -0000 On 17-5-2012 14:53, Mateusz Guzik wrote: > On Wed, May 16, 2012 at 11:37:44PM +0300, tzabal@it.teithe.gr wrote: >> Nice. What about curl over the HTTPS protocol? >> > > curl would be ok, except it's not in the base system. For this reason, it's probably best to use tar(1) to package up multiple files and implement http put support in libfetch(3). You may also need to implement 305 Use Proxy support. -- Mel From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 20:11:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E5301065674 for ; Fri, 18 May 2012 20:11:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id CA9A38FC18 for ; Fri, 18 May 2012 20:11:25 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4IKBB0s037621 for ; Fri, 18 May 2012 22:11:11 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4IKBBHD037618 for ; Fri, 18 May 2012 22:11:11 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 May 2012 22:11:11 +0200 (CEST) From: User Wojtek To: freebsd-hackers@freebsd.org 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.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 May 2012 22:11:11 +0200 (CEST) Subject: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:11:27 -0000 what are proper settings a) 4kB fragments so everything is 4k aligned? SSD drives itself reports as 512 byte blocks, but it is recomenned constantly on many places about 4K alignment for SSD. b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD c) anything else? i use b) now. From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 20:55:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88524106566C for ; Fri, 18 May 2012 20:55:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id 140D08FC08 for ; Fri, 18 May 2012 20:55:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id 698BDA7071; Fri, 18 May 2012 22:54:29 +0200 (CEST) Message-ID: <4FB6B713.7080807@FreeBSD.org> Date: Fri, 18 May 2012 22:54:43 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: User Wojtek References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:55:01 -0000 On 2012-05-18 22:11, User Wojtek wrote: > what are proper settings > > a) 4kB fragments so everything is 4k aligned? SSD drives itself reports > as 512 byte blocks, but it is recomenned constantly on many places about > 4K alignment for SSD. That 4k alignment is most likely meant for so-called "advanced format" hard drives (the good old magnetic platter ones); these present 512 byte sectors to the ATA interface, but use 4096 byte sectors internally. With SSDs however, you cannot automatically tell what their erase block size is. Some of them use 128kB, others 256kB, and there are probably also devices with variable erase block sizes. You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) > b) small fragments (like 1KB) to reduce space usage, as there is no > seeking so it will not slow down but save space on relatively small SSD I don't think you would want to write lots of very small fragments to any SSD. :) > c) anything else? Be sure to use "-t enable" when creating the filesystem: -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 20:58:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9201106564A for ; Fri, 18 May 2012 20:58:08 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm14-vm1.bullet.mail.ne1.yahoo.com (nm14-vm1.bullet.mail.ne1.yahoo.com [98.138.91.38]) by mx1.freebsd.org (Postfix) with SMTP id 860C38FC12 for ; Fri, 18 May 2012 20:58:08 +0000 (UTC) Received: from [98.138.90.51] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2012 20:58:02 -0000 Received: from [98.138.89.192] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 18 May 2012 20:58:02 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 18 May 2012 20:58:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 148013.46715.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 63771 invoked by uid 60001); 18 May 2012 20:58:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337374682; bh=i8poTO+AU2/JkNUTg98WVlDMX+Q0VIqrXSXghoYg+lw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ojsc9CKosSBf3huTS1m977VrFBZ6DkdYCzij+kGM1W2J9BlwRrj/EFX3jNZ6iWaoNqxWELJiz8ZoIAKj9tn21YmiilwHKW7vV5n9OFSZEXBCACyeR9Vyp6NuOAq8CqyYCPYC2TfMVLNzfc6VPMFCfzlVs9GIIBaUaMTpq6BP/EY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=O8KqRvAaje23sM0wruxxqz5VDqhFKkmL/wSFHMcynHcBFzHHP4hUZy07Y9iLCVQyBI/NdsW4N1uAaOTa0nZISWy+LCJoCATOOT2hs7/54bPtaaF3dzn3TSRvnkeXw+LCv0WOWRGH/9cJcQ2f0R2WFF0lhJ9f5tGDgWGoIBtSklk=; X-YMail-OSG: eP_XITkVM1nFwmRqZCovXaJFWT4t057tM0LMnO6PPNRh1Vz cvlLIDgxQPmzK7fuUa30PeV02tI8tNIRqkd5PxrrOKUkObqWsUc8ON6qV73u BrinUmPEUukreusSLwTSrP9hxnXmflvjI9tX80EgINmvQf7GMWzv9Eke9A5y ymou7lwVabOq5c6GC2HDPNCh_RFVIDbiqPQQrtJ9XsttA284Zs47B0gsrGGz ysBz6C4yOrvTw_tgDO3yZL79mOSqbcyEuubkZHAmwlSsdY2TRZw.50MQ5ehK 6NADNqRPqPpi8pG4Hm4OntnC8ETXo_2L8SlFfDZchC.aNBIbHy8KUvQj0L25 5Bk.nFN6dyUh7aO2KiJzpQlhEEm54wlwUEa3acsFWZGb2K0DZbVdyFrSi36o UbwEljngtc2BdVkNkSrubpvpNooHRUsxnAeqsMlEeE18S5WIwuw-- Received: from [173.164.238.34] by web122504.mail.ne1.yahoo.com via HTTP; Fri, 18 May 2012 13:58:01 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337374681.54894.YahooMailClassic@web122504.mail.ne1.yahoo.com> Date: Fri, 18 May 2012 13:58:01 -0700 (PDT) From: Jason Usher To: Jason Hellenthal In-Reply-To: <20120518011904.GA82007@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 May 2012 21:11:20 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:58:09 -0000 =0A=0A--- On Thu, 5/17/12, Jason Hellenthal wrote:= =0A=0A> On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher=0A> wrote:=0A= > > =0A> > =0A> > --- On Thu, 5/17/12, Jason Hellenthal =0A> wrote:=0A> > =0A> > > > That is not the standard "key mismatch" e= rror=0A> that you=0A> > > assumed it was.? Look at it again - it is saying= =0A> that=0A> > > we do have a key for this server of type DSA, but=0A> the= client=0A> > > is receiving one of type RSA, etc.=0A> > > > =0A> > > > The= keys are the same - they have not changed=0A> at all -=0A> > > they are ju= st being presented to clients in the=0A> reverse=0A> > > order, which is co= nfusing them and breaking=0A> automated,=0A> > > key-based login.=0A> > > >= =0A> > > > I need to take current ssh server behavior=0A> (rsa, then=0A> >= > dss) and change it back to the old order (dss,=0A> then rsa).=0A> > > = =0A> > > Have you attempted to change that order via=0A> sshd_config and=0A= > > > placing the=0A> > > DSA directive before the RSA one ?=0A> > =0A> > = =0A> > sshd_config has no such config directive.=A0=0A> ssh_config does, bu= t that's for clients, and I have no way=0A> to interact with the clients.= =0A> > =0A> > It would indeed be very nice if this key order, which=0A> see= ms like a prime candidate for configuration, was a=0A> configurable option = in sshd_config, but it is not.=0A> > =0A> > I am fairly certain that I need= to hack up some source=0A> files, and I thought I had it with myproposal.h= (see link in=0A> OP) but there must be more, because that small change doe= s=0A> not fix things...=0A> =0A> You don't have any of this in your config = ?=0A> =0A> # HostKey for protocol version 1=0A> #HostKey /usr/local/etc/ssh= /ssh_host_key=0A> # HostKeys for protocol version 2=0A> HostKey /usr/local/= etc/ssh/ssh_host_rsa_key=0A> #HostKey /usr/local/etc/ssh/ssh_host_dsa_key= =0A> #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key=0A=0A=0AYes, but that d= oesn't help, for reasons I mentioned earlier.=0A=0ASimply removing RSA func= tionality would (of course) cause it to stop presenting RSA keys first, but= what about clients who (for whatever reason, who knows) negotiated RSA key= s previously ? Then they would break.=0A=0AThis is a very simple requireme= nt:=0A=0AOpenSSH server used to present keys in the order: DSA first, then= RSA. I need to get back to that same behavior.=0A=0AHow do I do that ? From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 21:12:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ED16106564A for ; Fri, 18 May 2012 21:12:48 +0000 (UTC) (envelope-from azet@azet.org) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F18F78FC1E for ; Fri, 18 May 2012 21:12:47 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3308105wgb.31 for ; Fri, 18 May 2012 14:12:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=jp1Mz4pzy4n8SY8QeMVBa5fBxSfHoC6YwVdPLLWHUrk=; b=SkavTSG2gd7t/EuU719G+nDEKWTfaPl12Q+3fb3McU6zka6St5H3vT3M2BCZi5o2WM 2KFus5yS1bSk3o5kSh1EdJQ53ChtG3kCimGUVVPU7VutXU6m/2k+tdTM9DqPi42k657C mxufudeIs3d+evYdfwZue02EPZobxkjO9PoS7Trqus6XtMVNC9QAqbJVyumZLdzBrG16 LN04xGLP0JK3xOQM2zNaJnjO5sehb/ACrgMHhIac7AOtw4GcCCeeqtaKh3ROZ0WtJteG lJbskBWFW3KImDelmnbTpQ8ZpmzfsdSCtXpbbIvWzdp9OLj1pM1SXpoK7/kifVMs2J5U oS5g== MIME-Version: 1.0 Received: by 10.216.143.223 with SMTP id l73mr7725140wej.97.1337375567028; Fri, 18 May 2012 14:12:47 -0700 (PDT) Received: by 10.194.55.39 with HTTP; Fri, 18 May 2012 14:12:46 -0700 (PDT) In-Reply-To: References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> Date: Fri, 18 May 2012 23:12:46 +0200 Message-ID: From: Aaron Zauner To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkBOiIGHFIm55FEg9DWoCmlLKs1jYwMRp4ilwEiIRX/VhBIBhMv8gUjL94KFmM4YBP/Zb9p Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 21:12:48 -0000 hi, first of; grats on getting the project. very interesting. > * Can you recommend a secure way of sending a report from a FreeBSD system > to the Central Collector machine? i don't know if the use of a gnu tool would conflict with FreeBSD politics but you could use tar(1) or an equivalent and GPG. this would also be protocol independent. e.g.: you can use a public key for the central server to encrypt traffic destined for the server. > * Do you propose a different Web Server than the Apache HTTP Server? For > example, on my initial planning I had included MySQL as the selected DBMS > and after some discussions I changed to PostgreSQL. lighttpd works very well and fast with PHP in my experience. varnish-cache is also pretty cool for heavy loads or distributed setups. postgres is a good choice. From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 22:17:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9062B106564A for ; Fri, 18 May 2012 22:17:47 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from ps-1-b.compliancesafe.com (ps-1-b.compliancesafe.com [216.81.161.162]) by mx1.freebsd.org (Postfix) with ESMTP id 468D08FC0A for ; Fri, 18 May 2012 22:17:46 +0000 (UTC) Received: from mail.palisadesystems.com (localhost [127.0.0.1]) by ps-1-b.compliancesafe.com (8.14.4/8.14.3) with ESMTP id q4IM6xsW087636 for ; Fri, 18 May 2012 17:06:59 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Received: from guysmbp.dyn.palisadesys.com (GuysMBP.dyn.palisadesys.com [172.16.2.90]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id q4ILwh8Y049732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 May 2012 16:58:43 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com q4ILwh8Y049732 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=palisadesys.com; s=mail; t=1337378323; bh=Jxga24JsyWMcgrQ7bt9QGudJRY09JZf9VdZ+DbKDOHY=; l=128; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=jH9hBa6PDBWGnCthO1s+bIh2jyTvmMHz4kzMBIsLXuYJoEw9oPBWTYFqZG58OF4YY NedVPhnOp2FH41JhqRniI69FGSN9cKNot7CJfswW37u6YkfggDPvhRoOYGWADN9GDY S+Q6gvNHd4sIZcRMjdEzpR5EbY05CM8Ei8N/krJ8= From: Guy Helmer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 May 2012 16:58:42 -0500 Message-Id: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Fri, 18 May 2012 16:58:43 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: q4ILwh8Y049732 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=2.084, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, J_CHICKENPOX_53 0.60, J_CHICKENPOX_54 0.60, J_CHICKENPOX_56 0.60, J_CHICKENPOX_63 0.60, J_CHICKENPOX_92 0.60, RP_8BIT 1.98) X-Palisade-MailScanner-From: ghelmer@palisadesys.com X-Spam-Status: No X-PacketSure-Scanned: Yes Subject: Review of changes for getnetgrent.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 22:17:47 -0000 To close PR bin/83340, I have this change worked up to resolve memory = allocation failure handling and avoid creating bad entries in the grp = list due to memory allocation failures while building a new entry. Before committing, I wanted to run it past others to see if there were = any problems with it. Thanks, Guy > svn diff lib/libc/gen Index: lib/libc/gen/getnetgrent.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 --- lib/libc/gen/getnetgrent.c (revision 235606) +++ lib/libc/gen/getnetgrent.c (working copy) @@ -203,9 +203,7 @@ if (parse_netgrp(group)) endnetgrent(); else { - grouphead.grname =3D (char *) - malloc(strlen(group) + 1); - strcpy(grouphead.grname, group); + grouphead.grname =3D strdup(group); } if (netf) fclose(netf); @@ -417,7 +415,7 @@ parse_netgrp(const char *group) { char *spos, *epos; - int len, strpos; + int len, strpos, freepos; #ifdef DEBUG int fields; #endif @@ -454,9 +452,9 @@ while (pos !=3D NULL && *pos !=3D '\0') { if (*pos =3D=3D '(') { grp =3D (struct netgrp *)malloc(sizeof (struct = netgrp)); + if (grp =3D=3D NULL) + return(1); bzero((char *)grp, sizeof (struct netgrp)); - grp->ng_next =3D grouphead.gr; - grouphead.gr =3D grp; pos++; gpos =3D strsep(&pos, ")"); #ifdef DEBUG @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] =3D = (char *) malloc(len + 1); + if (grp->ng_str[strpos] = =3D=3D NULL) { + for (freepos =3D = 0; freepos < strpos; freepos++) + if = (grp->ng_str[freepos] !=3D NULL) + = free(grp->ng_str[freepos]); + free(grp); + return(1); + } bcopy(spos, = grp->ng_str[strpos], len + 1); } @@ -490,6 +495,8 @@ grp->ng_str[strpos] =3D NULL; } } + grp->ng_next =3D grouphead.gr; + grouphead.gr =3D grp; #ifdef DEBUG /* * Note: on other platforms, malformed netgroup @@ -526,7 +533,7 @@ static struct linelist * read_for_group(const char *group) { - char *pos, *spos, *linep, *olinep; + char *pos, *spos, *linep; int len, olen; int cont; struct linelist *lp; @@ -534,6 +541,7 @@ #ifdef YP char *result; int resultlen; + linep =3D NULL; =20 while (_netgr_yp_enabled || fgets(line, LINSIZ, netf) !=3D NULL) = { if (_netgr_yp_enabled) { @@ -554,6 +562,7 @@ free(result); } #else + linep =3D NULL; while (fgets(line, LINSIZ, netf) !=3D NULL) { #endif pos =3D (char *)&line; @@ -576,8 +585,14 @@ pos++; if (*pos !=3D '\n' && *pos !=3D '\0') { lp =3D (struct linelist *)malloc(sizeof (*lp)); + if (lp =3D=3D NULL)=20 + return(NULL); lp->l_parsed =3D 0; lp->l_groupname =3D (char *)malloc(len + 1); + if (lp->l_groupname =3D=3D NULL) { + free(lp); + return(NULL); + } bcopy(spos, lp->l_groupname, len); *(lp->l_groupname + len) =3D '\0'; len =3D strlen(pos); @@ -595,15 +610,15 @@ } else cont =3D 0; if (len > 0) { - linep =3D (char *)malloc(olen + = len + 1); - if (olen > 0) { - bcopy(olinep, linep, = olen); - free(olinep); + linep =3D (char = *)reallocf(linep, olen + len + 1); + if (linep =3D=3D NULL) { + free(lp->l_groupname); + free(lp); + return(NULL); } bcopy(pos, linep + olen, len); olen +=3D len; *(linep + olen) =3D '\0'; - olinep =3D linep; } if (cont) { if (fgets(line, LINSIZ, netf)) { @@ -634,5 +649,5 @@ */ rewind(netf); #endif - return ((struct linelist *)0); + return (NULL); } -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 23:09:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E34F1065678 for ; Fri, 18 May 2012 23:09:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 41FD48FC0C for ; Fri, 18 May 2012 23:09:19 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 9E30816AF4; Fri, 18 May 2012 16:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1337382553; bh=/stOw9zT4/GH1Poe3ybj2Di1iXHmg3V6B9GOxRTAF6k=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=S1d8TiUwC9rFyDBKuTXsxADKyk/h70eJ28OEcCZPdnwPWKhXjdK7gw3ngaU/3HGl9 Bi8DHkE3o4ZupNMKWH/zVXJlTQO1tYADINeez5otvK1feEFHnuYw+nm+3dGbiT5kCe wlAUVWH/6lAzysshF0qKUIBvH3n/QbMZqXa2MRPM= Message-ID: <4FB6D698.9030305@delphij.net> Date: Fri, 18 May 2012 16:09:12 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Guy Helmer References: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> In-Reply-To: <4EE466CC-5F93-485C-8E1F-907F8049FD61@palisadesys.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: Review of changes for getnetgrent.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 23:09:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/18/12 14:58, Guy Helmer wrote: > To close PR bin/83340, I have this change worked up to resolve > memory allocation failure handling and avoid creating bad entries > in the grp list due to memory allocation failures while building a > new entry. > > Before committing, I wanted to run it past others to see if there > were any problems with it. %%% @@ -477,6 +475,13 @@ if (len > 0) { grp->ng_str[strpos] = (char *) malloc(len + 1); + if (grp->ng_str[strpos] == NULL) { + for (freepos = 0; freepos < strpos; freepos++) + if (grp->ng_str[freepos] != NULL) + free(grp->ng_str[freepos]); + free(grp); + return(1); + } bcopy(spos, grp->ng_str[strpos], len + 1); %%% The if (grp->ng_str[freepos] != NULL) here seems to be unnecessary to me because in most cases these are false, and free() does the test regardless. Also, I think freepos can be declared within this scope level. There are a few return without space between the keyword and return value. Other than these it looks fine to me. Thanks for working on this! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPttaYAAoJEG80Jeu8UPuzFEsH/i7JwIPdk15sP3E2/YpesYQu veavnS6tebylFhniKukN4GRsS5mpbs9AmnxbNUBfF7InlzcnxOeUX9mHJepxbZQX Bz8wgsvfxlrrseIyscdwm7b4XQK3dLv+VwpbQ4fqACOX1kGEQ/GsIc65JLyp2Gzo fRLkHRAO5s3FVT5f11vsy2Ry16AmQhL2Sg9+mrGqeIbhppmDCgWfoF+rmD/7fn15 0OuJNn/S3Cz3zo+ZHI9OE1W8mkMox4kznQmv6vH/hM3Gk1cY9h66UybuBWsY31dI WF5Y5WoJBuncFlDxGkaZv2jiRAqgkfWILVWKcjyejtGgVYPEWAjIgHLyyVk7H4g= =ewU+ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri May 18 23:43:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C95AD1065672 for ; Fri, 18 May 2012 23:43:59 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 82DD38FC17 for ; Fri, 18 May 2012 23:43:59 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q4INhmBb062227; Fri, 18 May 2012 16:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1337384629; bh=AxS1tCCP9vr/bmp5Iy9WfmX8EpsMFFao5mdD+ZYF2bU=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=fwLp38DULM5LoaoHAt1mf/Xy4B++YYa6XoNBwBgBKRgjfUJEhdZvqQAlsr8PUeTkJ 4UfNuNzf8bjWGHSOd14REEoU/+7Y0kokImy92VfF9dwrUIwZ7pf0HFAgqpub4NtrTd c7sRdzB1oioHR4wFuB683f75PjkW2eKcD7yFDoSQ= From: Sean Bruno To: cz li In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 18 May 2012 16:42:48 -0700 Message-ID: <1337384568.3050.3.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 384628002 Cc: "freebsd-hackers@freebsd.org" Subject: Re: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:43:59 -0000 On Tue, 2012-05-15 at 18:13 -0700, cz li wrote: > FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? according to man 4 radeon, the x2300 is supported. according to man 4 radeonhd, it supports both. Take a look at the man page. You might have to do a port upgrade of your xorg installation. Or, PC-BSD 9 for your desktop might be an alternative. Sean From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 00:10:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59F1D1065688 for ; Sat, 19 May 2012 00:10:00 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8128FC16 for ; Sat, 19 May 2012 00:09:59 +0000 (UTC) Received: by obcni5 with SMTP id ni5so6167682obc.13 for ; Fri, 18 May 2012 17:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=ALDWcwTP4sVCTwzUTsgtbyMSST0q5sKWDmydW9SAmHs=; b=L0ba3MgxzsTKBL+hNSFpzhHbw3mMMZ0bTdyfuSo3+L0cGmcwYKNF4mKVBcobImpjUU KagukM5spzo7DO69WKywqt9qwXnIsch9ayOVec48hfBinnK4C0lCRgxKk4sUl9msJ/wS 4t+YOugI7kph8oYR48KKAw0PClRaVezFJtiLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=ALDWcwTP4sVCTwzUTsgtbyMSST0q5sKWDmydW9SAmHs=; b=gGGmil+ssHC5LVq0kSUK3t8qv0lMJZYKiZc/5GRYpBHROgM8J2cU0nSlGkQ3Ymezhr aaFt+4mfqWYRioQcT7E0EjkDnZjuvE7E1Uvz08+ZbvCwx0w9zks/4ZegSPCi/q9Dnio1 6UZBvXXSjT5ti6IFCLSw9jyjaZ+4wwpzSsguIwWNDF9g9oTQcsEskXZcR7DF9i0JQZmY OX4UjmDNzLEn/O8VcE98iOGwigoByxwwP09dAjMlGmKuS0G+wKu1Jf5O6xNIhAmFI/z8 bsLmYikx8bYCoJOvZUDhJ+4QbNSDsXGI6Xcu16ysMfahe90zgi0axFdlvhqhL/GJn3l2 Z7Zw== Received: by 10.50.185.232 with SMTP id ff8mr2237013igc.5.1337386199211; Fri, 18 May 2012 17:09:59 -0700 (PDT) Received: from DataIX.net (24-247-238-117.dhcp.aldl.mi.charter.com. [24.247.238.117]) by mx.google.com with ESMTPS id if4sm1222308igc.10.2012.05.18.17.09.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 17:09:58 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q4J09ttH012512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2012 20:09:55 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q4J09s4F012336; Fri, 18 May 2012 20:09:54 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Fri, 18 May 2012 20:09:54 -0400 From: Jason Hellenthal To: Jason Usher Message-ID: <20120519000954.GA6110@DataIX.net> References: <20120518011904.GA82007@DataIX.net> <1337374681.54894.YahooMailClassic@web122504.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337374681.54894.YahooMailClassic@web122504.mail.ne1.yahoo.com> X-Gm-Message-State: ALoCoQn6PBfrpi6Or6pH3n1Pg8nCdZOZdBSTbt1Q3rsw4+WFM59wwgY7xhSz06h9d6cjzhlWjwX+ Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 00:10:00 -0000 On Fri, May 18, 2012 at 01:58:01PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher > > wrote: > > > > > > > > > --- On Thu, 5/17/12, Jason Hellenthal > > wrote: > > > > > > > > That is not the standard "key mismatch" error > > that you > > > > assumed it was.? Look at it again - it is saying > > that > > > > we do have a key for this server of type DSA, but > > the client > > > > is receiving one of type RSA, etc. > > > > > > > > > > The keys are the same - they have not changed > > at all - > > > > they are just being presented to clients in the > > reverse > > > > order, which is confusing them and breaking > > automated, > > > > key-based login. > > > > > > > > > > I need to take current ssh server behavior > > (rsa, then > > > > dss) and change it back to the old order (dss, > > then rsa). > > > > > > > > Have you attempted to change that order via > > sshd_config and > > > > placing the > > > > DSA directive before the RSA one ? > > > > > > > > > sshd_config has no such config directive.? > > ssh_config does, but that's for clients, and I have no way > > to interact with the clients. > > > > > > It would indeed be very nice if this key order, which > > seems like a prime candidate for configuration, was a > > configurable option in sshd_config, but it is not. > > > > > > I am fairly certain that I need to hack up some source > > files, and I thought I had it with myproposal.h (see link in > > OP) but there must be more, because that small change does > > not fix things... > > > > You don't have any of this in your config ? > > > > # HostKey for protocol version 1 > > #HostKey /usr/local/etc/ssh/ssh_host_key > > # HostKeys for protocol version 2 > > HostKey /usr/local/etc/ssh/ssh_host_rsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_dsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key > > > Yes, but that doesn't help, for reasons I mentioned earlier. > > Simply removing RSA functionality would (of course) cause it to stop presenting RSA keys first, but what about clients who (for whatever reason, who knows) negotiated RSA keys previously ? Then they would break. > > This is a very simple requirement: > > OpenSSH server used to present keys in the order: DSA first, then RSA. I need to get back to that same behavior. > > How do I do that ? Not sure if you missed what I was saying or if I read that correctly. But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key ??? Just for brevity. -- - (2^(N-1)) From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 03:04:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAE30106564A for ; Sat, 19 May 2012 03:04:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 641398FC15 for ; Sat, 19 May 2012 03:04:18 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4J34Hjg027783; Fri, 18 May 2012 21:04:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4J34H9X027780; Fri, 18 May 2012 21:04:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 18 May 2012 21:04:17 -0600 (MDT) From: Warren Block To: Sean Bruno In-Reply-To: <1337384568.3050.3.camel@powernoodle-l7.corp.yahoo.com> Message-ID: References: <1337384568.3050.3.camel@powernoodle-l7.corp.yahoo.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.2.7 (wonkity.com [127.0.0.1]); Fri, 18 May 2012 21:04:17 -0600 (MDT) Cc: "freebsd-hackers@freebsd.org" , cz li Subject: Re: gnome start error?help me. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 03:04:18 -0000 On Fri, 18 May 2012, Sean Bruno wrote: > On Tue, 2012-05-15 at 18:13 -0700, cz li wrote: >> FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? > > according to man 4 radeon, the x2300 is supported. according to man 4 > radeonhd, it supports both. radeonhd is unmaintained, no commits in two years. The current radeon driver is part of xf86-video-ati. It should handle an X2300, although I don't have one to test. From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 03:54:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31C6106564A for ; Sat, 19 May 2012 03:54:29 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A9F448FC0C for ; Sat, 19 May 2012 03:54:29 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4J3sPxj015549; Sat, 19 May 2012 03:54:25 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 9wp9i6c5kqygaccwvpzcru2tfi; Sat, 19 May 2012 03:54:25 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <4FB6620D.8060001@acsalaska.net> Date: Fri, 18 May 2012 20:54:25 -0700 Content-Transfer-Encoding: 7bit Message-Id: <01A33A03-3068-46E8-958F-500216E4E912@kientzle.com> References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr> <20120517125348.GA26081@dft-labs.eu> <4FB6620D.8060001@acsalaska.net> To: Mel Flynn X-Mailer: Apple Mail (2.1257) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , tzabal@it.teithe.gr Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 03:54:29 -0000 On May 18, 2012, at 7:51 AM, Mel Flynn wrote: > On 17-5-2012 14:53, Mateusz Guzik wrote: >> On Wed, May 16, 2012 at 11:37:44PM +0300, tzabal@it.teithe.gr wrote: > >>> Nice. What about curl over the HTTPS protocol? >>> >> >> curl would be ok, except it's not in the base system. > > For this reason, it's probably best to use tar(1) to package up multiple > files and implement http put support in libfetch(3). You may also need > to implement 305 Use Proxy support. Depends on where the files are coming from. If you have files on disk, then tar(1) might be a good choice. If you're going to have to construct the files, then you can maybe avoid writing them to disk by using libarchive(3) directly instead of going through the tar command-line interface. Tim From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 08:40:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A474106564A; Sat, 19 May 2012 08:40:44 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D78238FC12; Sat, 19 May 2012 08:40:41 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4J8eWag013169; Sat, 19 May 2012 10:40:33 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4J8eWnS013166; Sat, 19 May 2012 10:40:32 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 19 May 2012 10:40:32 +0200 (CEST) From: User Wojtek To: Dimitry Andric In-Reply-To: <4FB6B713.7080807@FreeBSD.org> Message-ID: References: <4FB6B713.7080807@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 passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 19 May 2012 10:40:33 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 08:40:44 -0000 > You may be able to find the exact erase block size in the technical > documentation of your specific SSD. But the manufacturers don't always > tell. :) > > >> b) small fragments (like 1KB) to reduce space usage, as there is no >> seeking so it will not slow down but save space on relatively small SSD > > I don't think you would want to write lots of very small fragments to > any SSD. :) i do - i have quite a lot of small files. with 4kB fragments i am losing 10% of space. but found it is right settings - Sandforce controller actually manages data with 4kB blocks. > > >> c) anything else? > > Be sure to use "-t enable" when creating the filesystem: > > -t enable | disable > Turn on/off the TRIM enable flag. If enabled, and if the under- > lying device supports the BIO_DELETE command, the file system > will send a delete request to the underlying device for each > freed block. The trim enable flag is typically set when the > underlying device uses flash-memory as the device can use the > delete command to pre-zero or at least avoid copying blocks that > have been deleted. already done. thanks From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 08:54:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04904106566C; Sat, 19 May 2012 08:54:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id AF36A8FC0C; Sat, 19 May 2012 08:54:54 +0000 (UTC) Received: from [188.174.61.117] (helo=localhost.my.domain) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SVfR1-0005Vg-Hk; Sat, 19 May 2012 10:54:47 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.4/8.14.3) with ESMTP id q4J8sjdQ003008; Sat, 19 May 2012 10:54:46 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.4/8.14.3/Submit) id q4J8sjjv003007; Sat, 19 May 2012 10:54:45 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 19 May 2012 10:54:45 +0200 From: Matthias Apitz To: User Wojtek Message-ID: <20120519085444.GA2966@tinyCurrent> References: <4FB6B713.7080807@FreeBSD.org> 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: 188.174.61.117 Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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, 19 May 2012 08:54:55 -0000 El día Saturday, May 19, 2012 a las 10:40:32AM +0200, User Wojtek escribió: > > You may be able to find the exact erase block size in the technical > > documentation of your specific SSD. But the manufacturers don't always > > tell. :) > > ... Hi, Some weeks ago in the context of Openmoko (my Linux based cellphone) I came across to this very interesting article about file systems and SSD; even if the article is in Linux context, it contains useful information about how SSD behaves when updating blocks on SSD. https://lwn.net/Articles/428584/ I have to admit, that I run an EeePC 900 netbook for many years now (with now FreeBSD 10-CURRENT) and the only special option for the SSD (the EeePC has only two SSD) is -noatime on mounting. But this is just a small netbook to read stuff or write something when I'm in town and does not need performance tweaking. HIH matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ 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 Sat May 19 11:44:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62872106566C; Sat, 19 May 2012 11:44:11 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 253688FC0A; Sat, 19 May 2012 11:44:01 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4JBher5037846; Sat, 19 May 2012 13:43:42 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4JBbgKE028079; Sat, 19 May 2012 13:37:42 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 19 May 2012 13:37:42 +0200 (CEST) From: User Wojtek To: Matthias Apitz In-Reply-To: <20120519085444.GA2966@tinyCurrent> Message-ID: References: <4FB6B713.7080807@FreeBSD.org> <20120519085444.GA2966@tinyCurrent> 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.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 19 May 2012 13:43:43 +0200 (CEST) Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 11:44:11 -0000 what is really bad in SSD is that they are not flash chips interfaced to computer (so flash-designed filesystem could be written) but complex hard drive emulators. But this way they could sell this to windows users. > > https://lwn.net/Articles/428584/ seems like i have it right. i use noatime ALWAYS no matter if it is real disk or emulated in flash memory. From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 13:49:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DCA6106566B; Sat, 19 May 2012 13:49:49 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id DA2678FC0C; Sat, 19 May 2012 13:49:48 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q4JDnlHE030650; Sat, 19 May 2012 07:49:47 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q4JDnlOx030647; Sat, 19 May 2012 07:49:47 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 19 May 2012 07:49:47 -0600 (MDT) From: Warren Block To: Matthias Apitz In-Reply-To: <20120519085444.GA2966@tinyCurrent> Message-ID: References: <4FB6B713.7080807@FreeBSD.org> <20120519085444.GA2966@tinyCurrent> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-829386930-1337435387=:30455" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 19 May 2012 07:49:47 -0600 (MDT) Cc: User Wojtek , Dimitry Andric , freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 13:49:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-829386930-1337435387=:30455 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 19 May 2012, Matthias Apitz wrote: > El día Saturday, May 19, 2012 a las 10:40:32AM +0200, User Wojtek escribió: > >>> You may be able to find the exact erase block size in the technical >>> documentation of your specific SSD. But the manufacturers don't always >>> tell. :) >>> ... > > Hi, > > Some weeks ago in the context of Openmoko (my Linux based cellphone) > I came across to this very interesting article about file systems and > SSD; even if the article is in Linux context, it contains useful > information about how SSD behaves when updating blocks on SSD. > > https://lwn.net/Articles/428584/ That's an excellent article. It mentions a flashbench tool which can help determine data for a particular SSD: git://git.linaro.org/people/arnd/flashbench.git I haven't tried it yet. ---902635197-829386930-1337435387=:30455-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 14:52:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C84D1065670 for ; Sat, 19 May 2012 14:52:28 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7544B8FC0A for ; Sat, 19 May 2012 14:52:27 +0000 (UTC) Received: by lbon10 with SMTP id n10so3781786lbo.13 for ; Sat, 19 May 2012 07:52:26 -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=8Km6Mu30sV/h1pXPBwV45p1ZAnCLtpj3zaCR3QTeDcM=; b=U29W9j36Qfjw1iSFa42G1lvEdIJhtuJGA/pC3cGaK8GXoMDNmEiXTBQWBnY/va5jX8 Fwpx4BPunEU2kv8jtU+DDrUV+HY8Hjc1dL6xqbsjANJ+56vAj3b8t8C5gbhd2xOEfMof e6s1+AqU+MwiWR4gmkS07pyTwoQtq8Ckx3JdDutRmWAS/JUX9qTsZhCHYXw1Zu3N0MPu FircVg88qxjwObLJj1wNnnAzgDVI5PIVmYcsoIr8yD0otISOVhuSm6yyzHzIpfsFAf8s Tym2W7bcvxwHuEc7Z7Yr3Cgntyoj8h/fTEUX+agREba+ZOCoDptor0T7HVXHC5M/ZNi8 ulEQ== MIME-Version: 1.0 Received: by 10.152.145.41 with SMTP id sr9mr8142054lab.25.1337439146242; Sat, 19 May 2012 07:52:26 -0700 (PDT) Received: by 10.152.24.131 with HTTP; Sat, 19 May 2012 07:52:26 -0700 (PDT) Date: Sat, 19 May 2012 16:52:26 +0200 Message-ID: From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Radeon, DRM and crash on 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 14:52:28 -0000 Hi, I'm having some system crashes from time to time. I had this before but until recently I couldn't set my system so I could get crash dumps. My video card is a ATI Mobility Radeon 9700. I'm running FreeBSD 9.0-RELEASE for amd64. These are excerpts from two crash dumps text files: core.txt.3: Fatal trap 28: machine check trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff816480a3 stack pointer = 0x28:0xffffff804a5eb970 frame pointer = 0x28:0xffffff804a5eb990 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 3 current process = 2254 (Xorg) trap number = 28 panic: machine check trap cpuid = 0 KDB: stack backtrace: #0 0xffffffff80869abe at kdb_backtrace+0x5e #1 0xffffffff80833fb7 at panic+0x187 #2 0xffffffff80b18b80 at trap_fatal+0x290 #3 0xffffffff80b190c0 at trap+0x110 #4 0xffffffff80b0396f at calltrap+0x8 #5 0xffffffff816a305b at drm_ioctl+0x31b #6 0xffffffff8075597b at devfs_ioctl_f+0x7b #7 0xffffffff8087afb1 at kern_ioctl+0x111 #8 0xffffffff8087b1df at sys_ioctl+0xef #9 0xffffffff80b18480 at amd64_syscall+0x450 #10 0xffffffff80b03c57 at Xfast_syscall+0xf7 Unread portion of the kernel message buffer: MCA: Bank 4, Status 0xb200000000070f0f MCA: Global Cap 0x0000000000000105, Status 0x0000000000000004 MCA: Vendor "AuthenticAMD", ID 0xf4a, APIC ID 0 MCA: CPU 0 UNCOR PCC BUSLG ??? ERR Other timed out core.txt.4 Fatal trap 28: machine check trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff816462b6 stack pointer = 0x28:0xffffff804a5eb930 frame pointer = 0x28:0xffffff804a5eb940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 3 current process = 2254 (Xorg) trap number = 28 panic: machine check trap cpuid = 0 KDB: stack backtrace: #0 0xffffffff80869abe at kdb_backtrace+0x5e #1 0xffffffff80833fb7 at panic+0x187 #2 0xffffffff80b18b80 at trap_fatal+0x290 #3 0xffffffff80b190c0 at trap+0x110 #4 0xffffffff80b0396f at calltrap+0x8 #5 0xffffffff8164f3cc at radeon_cp_indirect+0x24c #6 0xffffffff816a305b at drm_ioctl+0x31b #7 0xffffffff8075597b at devfs_ioctl_f+0x7b #8 0xffffffff8087afb1 at kern_ioctl+0x111 #9 0xffffffff8087b1df at sys_ioctl+0xef #10 0xffffffff80b18480 at amd64_syscall+0x450 #11 0xffffffff80b03c57 at Xfast_syscall+0xf7 dmesg | grep agp agp0: on hostb0 drm.ko is loaded and agp is included in kernel. AGP for the card seems to be properly detected: dmesg | grep drm drm0: on vgapci0 info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized radeon 1.31.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 grep -i "Direct rendering" /var/log/Xorg.0.log (II) RADEON(0): Direct rendering enabled The crash is not easily reproducible but seems to be more likely to occur the more activity there is in the screen (like when scrolling a window quite fast). Any help is appreciated. Thanks in advance. From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 16:12:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE4E81065673 for ; Sat, 19 May 2012 16:12:22 +0000 (UTC) (envelope-from ahmadtux@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 959888FC0A for ; Sat, 19 May 2012 16:12:22 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5638315pbb.13 for ; Sat, 19 May 2012 09:12:22 -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=Sn0KVcK8yWtkwSGheQTSTGU8wbpiqOuwWPWCmtR9u8Y=; b=RXhVv9xjbujA6M+XVBu0o4HouKFXaxXVz7z9TgjsWbDHHxintoixdEX60IzbgB/UWj ocvgLg48jLkhYY5c3ADfQLVcv1liq7JyuUYKTpMekkLH08KefO7nnRWOUGNOfFSi93wL s+e2dA8UUktfmHLuvsRQV/EjX3jlODRV5cDiJERu3VTohS1RrRe9KnXyXpT7LLVVogDp rRxrjWxpXGidg62Yz9507RmwtUfqcGPg5wlHTHCdHu4/BcI1GxhqRp1owuCCTnvFDvy7 IM/+xuAKfnYODLr+UwZpFVYkLUqI2EqCKDQX8gNen7IgCuuOBQmpPTn3yaEqoQjKIXa7 B1QA== MIME-Version: 1.0 Received: by 10.68.226.99 with SMTP id rr3mr50557117pbc.48.1337443942249; Sat, 19 May 2012 09:12:22 -0700 (PDT) Received: by 10.68.233.7 with HTTP; Sat, 19 May 2012 09:12:22 -0700 (PDT) Date: Sat, 19 May 2012 20:42:22 +0430 Message-ID: From: =?UTF-8?B?2LPbjNivINin2K3ZhdivINit2LPbjNmG24w=?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Booting Ubuntu and freebsd side by side X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahmadtux@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 16:12:22 -0000 Hi! How can I boot Ubuntu12.4 do with FreeBSD9 ? when I using boot0 , Linux was shown, but would not start without a message! Where is the problem? can launch freebsd with Ubuntu GRUB? How? -- Enjoy the rest ... From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 18:00:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D688C1065679 for ; Sat, 19 May 2012 18:00:57 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 53AA68FC17 for ; Sat, 19 May 2012 18:00:57 +0000 (UTC) Received: by lbon10 with SMTP id n10so3860150lbo.13 for ; Sat, 19 May 2012 11:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=noj9OXfQTlBSEFZTbzr6sPZv3lGdej7A70U7gWigBPQ=; b=mzrTX3Cn56h2XrL79yES2BgtCuCciR4cgepDxNNUkf+XFROi96BOdT/Mu9QvRYbls/ ZM8+HVV61AqplHR9d0CJzu7mXOUvR45S/GK0AWod6eMMZeIcmpXOTdIdmlqWfDeof+TN 94xoPeop91yvIwbcJMmJ413TOJooTjGie/d2YVPb2MGoPI9dSuvXfoolRnWT7W7AywjL btAXSyzm5aW3dRrkow9X8XA7QA+jdtj6GR55Dhb+YA8zHnc1YO7k/pwXJRJluIOBVS2U 8dlVCGUVgL2Zu9CYKHwgkqLXWJ4ErlVgAquDxCmrjqlLzCZ+VvAH4Xq6XrelPO8U+7hP K3Qg== Received: by 10.112.36.42 with SMTP id n10mr6562232lbj.7.1337450456118; Sat, 19 May 2012 11:00:56 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.82.187]) by mx.google.com with ESMTPS id gt19sm17903989lab.17.2012.05.19.11.00.53 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 11:00:54 -0700 (PDT) From: rozhuk.im@gmail.com To: "'User Wojtek'" , References: In-Reply-To: Date: Sun, 20 May 2012 03:00:46 +0900 Message-ID: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: Ac01MpzdVxOWxnhjQVqcRxQYTJLnwQAti7ZA Cc: Subject: RE: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:00:57 -0000 Partition must be aligned to: # gpart show => 34 62533229 ada0 GPT (29G) 34 6 - free - (3.0k) - for align 40 512 1 freebsd-boot (256k) - size 4k aligned 552 62532648 2 freebsd-ufs (29G) - size 4k aligned 62533200 63 - free - (31k) > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of User Wojtek > Sent: Saturday, May 19, 2012 5:11 AM > To: freebsd-hackers@freebsd.org > Subject: proper newfs options for SSD disk > > what are proper settings > > a) 4kB fragments so everything is 4k aligned? SSD drives itself reports > as 512 byte blocks, but it is recomenned constantly on many places > about 4K alignment for SSD. > > b) small fragments (like 1KB) to reduce space usage, as there is no > seeking so it will not slow down but save space on relatively small SSD > > c) anything else? > > > i use b) now. > _______________________________________________ > 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 19 18:09:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC5521065672 for ; Sat, 19 May 2012 18:09:10 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7437E8FC1D for ; Sat, 19 May 2012 18:09:10 +0000 (UTC) Received: from [82.113.121.79] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SVo5S-0001tj-VN; Sat, 19 May 2012 20:09:07 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q4JI9396001298; Sat, 19 May 2012 20:09:04 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q4JI92S7001296; Sat, 19 May 2012 20:09:02 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sat, 19 May 2012 20:09:02 +0200 From: Matthias Apitz To: rozhuk.im@gmail.com Message-ID: <20120519180901.GA1264@tiny> References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.121.79 Cc: 'User Wojtek' , freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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, 19 May 2012 18:09:10 -0000 El día Sunday, May 20, 2012 a las 03:00:46AM +0900, rozhuk.im@gmail.com escribió: > Partition must be aligned to: > > # gpart show > => 34 62533229 ada0 GPT (29G) > 34 6 - free - (3.0k) - for align > 40 512 1 freebsd-boot (256k) - size 4k aligned > 552 62532648 2 freebsd-ufs (29G) - size 4k aligned > 62533200 63 - free - (31k) My EeePC netbook shows for the two SSD: $ uname -a FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 $ gpart show => 63 7880481 ada0 MBR (3.8G) 63 7880481 1 freebsd [active] (3.8G) => 63 31522113 ada1 MBR (15G) 63 31522113 1 freebsd [active] (15G) => 0 7880481 ada0s1 BSD (3.8G) 0 16 - free - (8.0k) 16 7880465 1 freebsd-ufs (3.8G) => 0 31522113 ada1s1 BSD (15G) 0 16 - free - (8.0k) 16 31522097 1 freebsd-ufs (15G) matthias -- Matthias Apitz e - w http://www.unixarea.de/ 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 Sat May 19 18:36:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7054C106566C for ; Sat, 19 May 2012 18:36:12 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB2888FC15 for ; Sat, 19 May 2012 18:36:11 +0000 (UTC) Received: by lbon10 with SMTP id n10so3873041lbo.13 for ; Sat, 19 May 2012 11:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=SwxcsLjDkilTvCX/q+E0B7xyj7rYSEVl+HQHuQrXZO4=; b=d42uM5MuD97pJNeRQze3xqppJ4SdoGOB6+dhNVO6TvDTceCoLurwXDafChlIEBy7jt u5KCQyPjKgm4sye/tIz/ilXX2zl8YD27MeRoM7/UP8EQ73cCsqefhge6jMpA2yDujWwU eZStEV+RAxD0QTQ7q8pTVtfjRjrgsDbc57lPZQDgGrTZocRsQv7h1FuTeyGdCsgIJ70z TQ0uCDOOIBBHxkpPyG5bzqDRf3V4tBGJ11d0Iom7HiVeMa0PjYolCs4ZfrCtkVqwjTSH pqButa/Z0iAs5Ewfi6qNocb+P+iW1wrP+QEj/54tVlXGl1rTvics5Rc5hWeEd80ROAM7 O0Cg== Received: by 10.112.85.42 with SMTP id e10mr114520lbz.17.1337452570536; Sat, 19 May 2012 11:36:10 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.82.187]) by mx.google.com with ESMTPS id gd9sm9130652lbb.15.2012.05.19.11.36.07 (version=SSLv3 cipher=OTHER); Sat, 19 May 2012 11:36:09 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Matthias Apitz'" References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> In-Reply-To: <20120519180901.GA1264@tiny> Date: Sun, 20 May 2012 03:36:01 +0900 Message-ID: <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: Ac016nxwOTcufmeBTReBkI3kx/n9NwAAzt+Q Cc: 'User Wojtek' , freebsd-hackers@freebsd.org Subject: RE: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:36:12 -0000 > My EeePC netbook shows for the two SSD: > > $ uname -a > FreeBSD tiny 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r226986: Tue Nov 1 > 14:27:40 CET 2011 guru@caracas:/usr/obj/usr/src/sys/GENERIC i386 > $ gpart show > => 63 7880481 ada0 MBR (3.8G) > 63 7880481 1 freebsd [active] (3.8G) > > => 63 31522113 ada1 MBR (15G) > 63 31522113 1 freebsd [active] (15G) > > => 0 7880481 ada0s1 BSD (3.8G) > 0 16 - free - (8.0k) > 16 7880465 1 freebsd-ufs (3.8G) > > => 0 31522113 ada1s1 BSD (15G) > 0 16 - free - (8.0k) > 16 31522097 1 freebsd-ufs (15G) > Do not use MBR (or manually do all to align). 63 - not 4k aligned. From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 18:47:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAA811065670 for ; Sat, 19 May 2012 18:47:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 22E398FC0A for ; Sat, 19 May 2012 18:47:46 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q4JIlZPR091225; Sat, 19 May 2012 20:47:35 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q4JIlZ3l091219; Sat, 19 May 2012 20:47:35 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 19 May 2012 20:47:35 +0200 (CEST) From: User Wojtek To: =?UTF-8?B?2LPbjNivINin2K3ZhdivINit2LPbjNmG24w=?= 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 19 May 2012 20:47:35 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: Booting Ubuntu and freebsd side by side X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 18:47:47 -0000 > How can I boot Ubuntu12.4 do with FreeBSD9 ? > when I using boot0 , Linux was shown, but would not start without a message! > Where is the problem? > > can launch freebsd with Ubuntu GRUB? > How? install ubuntu (or whatever) on one MBR partition, FreeBSD on another then install partition selector with boot0cfg -B /dev/yourdisk and select F1...F4 at boot. that simple From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 18:59:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D44106568E for ; Sat, 19 May 2012 18:59:52 +0000 (UTC) (envelope-from ahmadtux@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 55B5B8FC08 for ; Sat, 19 May 2012 18:59:52 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5732483pbb.13 for ; Sat, 19 May 2012 11:59:52 -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=39gLu+64RW5ovgUuk80kU/Dnw5FyENx1xanu5APs+bA=; b=tvJn4SaWiShupflcWk6z7ONWAy0wWBiR9Mr7HJUMoYMvJo1LXOx+6glgF9J8xKc427 PY6c6yg9kBbxGqJsLitEWMYUNmc6HJDXQjhlP+hNF+0a06nGVfrr6VUKcEAyN9C4nTiU 9pSV2R8b6ZyPqAU+vBybOAJt1QDpSV2oK4HKa0knQfEkJ9c8TN0DYCVvs2zoF7cCn+Sh kcJsKrXQqwPEavH3LyGBVmzoSEzuY4B+ePdU4eVFKnaA3XEqp7Vvdp6pP9lgbJojb54W TNj2Jr2msWgPt9tDzRth2w+i8tx5LYVp2DZaQQrIOgH0poLea34qA+4ZS1WOZ3ako7dV NDFg== MIME-Version: 1.0 Received: by 10.68.230.68 with SMTP id sw4mr26216268pbc.142.1337453991794; Sat, 19 May 2012 11:59:51 -0700 (PDT) Received: by 10.68.233.7 with HTTP; Sat, 19 May 2012 11:59:51 -0700 (PDT) Received: by 10.68.233.7 with HTTP; Sat, 19 May 2012 11:59:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 May 2012 23:29:51 +0430 Message-ID: From: =?UTF-8?B?2LPbjNivINin2K3ZhdivINit2LPbjNmG24w=?= 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.5 Subject: Re: Booting Ubuntu and freebsd side by side X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahmadtux@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:59:52 -0000 I used boot0 with boot9cfg : boot0cfg -B -b /boot/boot0 ada0 And I can see boot0 menu ,but Ubuntu can't boot! On May 19, 2012 11:26 PM, "=D8=B3=DB=8C=D8=AF =D8=A7=D8=AD=D9=85=D8=AF =D8= =AD=D8=B3=DB=8C=D9=86=DB=8C" wrote: > I used boot0 with boot9cfg : > boot0cfg -B -b /boot/boot0 > And I can see boot0 menu ,but Ubuntu can't boot! > On May 19, 2012 11:17 PM, "User Wojtek" > wrote: > >> How can I boot Ubuntu12.4 do with FreeBSD9 ? >>> when I using boot0 , Linux was shown, but would not start without a >>> message! >>> Where is the problem? >>> >>> can launch freebsd with Ubuntu GRUB? >>> How? >>> >> >> install ubuntu (or whatever) on one MBR partition, FreeBSD on another >> then install partition selector with >> >> boot0cfg -B /dev/yourdisk >> >> and select F1...F4 at boot. >> that simple >> > From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 19:40:54 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11E0106566B for ; Sat, 19 May 2012 19:40:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 290F18FC0C for ; Sat, 19 May 2012 19:40:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA05199; Sat, 19 May 2012 22:40:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SVpWF-000Bwo-MN; Sat, 19 May 2012 22:40:51 +0300 Message-ID: <4FB7F743.9020405@FreeBSD.org> Date: Sat, 19 May 2012 22:40:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= References: In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers Subject: Re: Radeon, DRM and crash on 9.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 19:40:54 -0000 on 19/05/2012 17:52 Fernando Apesteguía said the following: > Hi, > > I'm having some system crashes from time to time. I had this before > but until recently I couldn't set my system so I could get crash > dumps. > > My video card is a ATI Mobility Radeon 9700. I'm running FreeBSD > 9.0-RELEASE for amd64. These are excerpts from two crash dumps text > files: > > core.txt.3: > > Fatal trap 28: machine check trap while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff816480a3 > stack pointer = 0x28:0xffffff804a5eb970 > frame pointer = 0x28:0xffffff804a5eb990 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 3 > current process = 2254 (Xorg) > trap number = 28 > panic: machine check trap > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80869abe at kdb_backtrace+0x5e > #1 0xffffffff80833fb7 at panic+0x187 > #2 0xffffffff80b18b80 at trap_fatal+0x290 > #3 0xffffffff80b190c0 at trap+0x110 > #4 0xffffffff80b0396f at calltrap+0x8 > #5 0xffffffff816a305b at drm_ioctl+0x31b > #6 0xffffffff8075597b at devfs_ioctl_f+0x7b > #7 0xffffffff8087afb1 at kern_ioctl+0x111 > #8 0xffffffff8087b1df at sys_ioctl+0xef > #9 0xffffffff80b18480 at amd64_syscall+0x450 > #10 0xffffffff80b03c57 at Xfast_syscall+0xf7 > > > Unread portion of the kernel message buffer: > MCA: Bank 4, Status 0xb200000000070f0f > MCA: Global Cap 0x0000000000000105, Status 0x0000000000000004 > MCA: Vendor "AuthenticAMD", ID 0xf4a, APIC ID 0 > MCA: CPU 0 UNCOR PCC BUSLG ??? ERR Other timed out Did you notice that you were getting the machine check exceptions? You might want to google for this term. Anyway, there is sysutils/mcelog port and this is how mcelog utility decodes the above report: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge Northbridge Watchdog error bit57 = processor context corrupt bit61 = error uncorrected bus error 'generic participation, request timed out generic error mem transaction generic access, level generic' STATUS b200000000070f0f MCGSTATUS 4 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 4 > core.txt.4 > > Fatal trap 28: machine check trap while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff816462b6 > stack pointer = 0x28:0xffffff804a5eb930 > frame pointer = 0x28:0xffffff804a5eb940 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 3 > current process = 2254 (Xorg) > trap number = 28 > panic: machine check trap > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80869abe at kdb_backtrace+0x5e > #1 0xffffffff80833fb7 at panic+0x187 > #2 0xffffffff80b18b80 at trap_fatal+0x290 > #3 0xffffffff80b190c0 at trap+0x110 > #4 0xffffffff80b0396f at calltrap+0x8 > #5 0xffffffff8164f3cc at radeon_cp_indirect+0x24c > #6 0xffffffff816a305b at drm_ioctl+0x31b > #7 0xffffffff8075597b at devfs_ioctl_f+0x7b > #8 0xffffffff8087afb1 at kern_ioctl+0x111 > #9 0xffffffff8087b1df at sys_ioctl+0xef > #10 0xffffffff80b18480 at amd64_syscall+0x450 > #11 0xffffffff80b03c57 at Xfast_syscall+0xf7 > > dmesg | grep agp > agp0: on hostb0 > > drm.ko is loaded and agp is included in kernel. > > AGP for the card seems to be properly detected: > > dmesg | grep drm > drm0: on vgapci0 > info: [drm] AGP at 0xe0000000 256MB > info: [drm] Initialized radeon 1.31.0 20080613 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R300 Microcode > info: [drm] Num pipes: 1 > > grep -i "Direct rendering" /var/log/Xorg.0.log > (II) RADEON(0): Direct rendering enabled > > The crash is not easily reproducible but seems to be more likely to > occur the more activity there is in the screen (like when scrolling a > window quite fast). > > Any help is appreciated. > > Thanks in advance. > _______________________________________________ > 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" > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 20:02:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E72B3106566B for ; Sat, 19 May 2012 20:02:38 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id ADF088FC16 for ; Sat, 19 May 2012 20:02:36 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 5331B7E849; Sat, 19 May 2012 12:02:34 -0800 (AKDT) Message-ID: <4FB7FC55.2060905@acsalaska.net> Date: Sat, 19 May 2012 22:02:29 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tim Kientzle References: <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr> <20120517125348.GA26081@dft-labs.eu> <4FB6620D.8060001@acsalaska.net> <01A33A03-3068-46E8-958F-500216E4E912@kientzle.com> In-Reply-To: <01A33A03-3068-46E8-958F-500216E4E912@kientzle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , tzabal@it.teithe.gr Subject: Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 20:02:39 -0000 On 19-5-2012 5:54, Tim Kientzle wrote: > > On May 18, 2012, at 7:51 AM, Mel Flynn wrote: > >> On 17-5-2012 14:53, Mateusz Guzik wrote: >>> On Wed, May 16, 2012 at 11:37:44PM +0300, tzabal@it.teithe.gr wrote: >> >>>> Nice. What about curl over the HTTPS protocol? >>>> >>> >>> curl would be ok, except it's not in the base system. >> >> For this reason, it's probably best to use tar(1) to package up multiple >> files and implement http put support in libfetch(3). You may also need >> to implement 305 Use Proxy support. > > Depends on where the files are coming from. If you > have files on disk, then tar(1) might be a good choice. > If you're going to have to construct the files, then you > can maybe avoid writing them to disk by using libarchive(3) > directly instead of going through the tar command-line > interface. As I read the original intent is to post crashdumps at a specified remote location through rc(8) using an sh(1) script on the next reboot. tar seemed appropriate. I'm only mentioning extending libfetch(3), because it will be easy for fetch(1) to pick it up, it benefits more than just this project and once integrated into fetch(1) can be used in said script above. Other than openssh we don't really have a good tool in the base system to put local files elsewhere securely. Also, if the BUGS section of fetch(3) is out of date, I'm happy to be corrected :) -- Mel From owner-freebsd-hackers@FreeBSD.ORG Sat May 19 23:55:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A7891065675; Sat, 19 May 2012 23:55:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id BEC758FC0A; Sat, 19 May 2012 23:55:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id A3FC1A7071; Sun, 20 May 2012 01:54:51 +0200 (CEST) Message-ID: <4FB832DB.7070203@FreeBSD.org> Date: Sun, 20 May 2012 01:55:07 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: Gleb Kurtsou References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> <20111209181550.GA3555@reks> <20111210012124.GA95149@reks> In-Reply-To: <20111210012124.GA95149@reks> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mdf@freebsd.org, freebsd-hackers@freebsd.org, Piotr Nowak , Rafal Jaworowski , Nathan Whitehorn , Arnaud Lacombe , Ryan Stone Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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 May 2012 23:55:12 -0000 On 2011-12-10 02:21, Gleb Kurtsou wrote: > Please find test case and test results attached. (gcc-test1.shar.txt) > > The long story short: only gcc-4.2 is affected, gcc 3.4, 4.4 and 4.6 are > ok. clang is ok. (test-cc.txt) > > Nearly all of the workarounds I used in original test doesn't work in > this test case (see #ifdef BAD_FIX in sources). > > gcc 4.2 fails even with -O1, it has nothing to do with > -fno-omit-frame-pointer, finline-functions, etc. (test-cflags.txt) > > Compile with -DFIX1 to work around problem (replace struct assignment > with memcpy): > % make test XFLAGS="-O2 -DFIX1" > rm -f gcc-test1 src1.o src2.o src3.o > cc -O2 -DFIX1 -g -std=gnu99 -c src1.c > cc -O2 -DFIX1 -g -std=gnu99 -c src2.c > cc -O2 -DFIX1 -g -std=gnu99 -c src3.c > cc -O2 -DFIX1 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o > /home/gleb/projects/gcc-test1/gcc-test1 > ok > > Happy hacking! Hi Gleb, I did some bisecting, and I found the exact gcc trunk revision that fixes this bug: http://gcc.gnu.org/viewcvs?view=revision&revision=119760 So far the good news, now the bad news: this revision is actually a merge from gcc's mem-ssa branch! The full diff is almost 10,000 lines... Also, although it's still under GPLv2, the diff doesn't apply cleanly to our version. :(