From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 8 02:19:14 2009 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 DFAA8106566C for ; Sun, 8 Nov 2009 02:19:14 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id 70AD08FC08 for ; Sun, 8 Nov 2009 02:19:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,702,1249250400"; d="txt'?scan'208";a="228374111" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 08 Nov 2009 03:19:12 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id AB4B61B0766; Sun, 8 Nov 2009 03:19:12 +0100 (CET) Date: Sun, 08 Nov 2009 03:19:05 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20091108021905f0889e8400001ff7-a_best01+ Cc: Alan Cox Subject: mmap(2) with MAP_ANON honouring offset although it shouldn't 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, 08 Nov 2009 02:19:15 -0000 This is a MIME encoded multipart message. --+permail-20091108021905f0889e8400001ff7-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit no problem. i've sent the final patch as followup to kern/71258 and also attached it to this message. to make it short. what's being changed by the patch: 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 would be great if you could have a look at the patch if you've got a spare minute. cheers. alex --+permail-20091108021905f0889e8400001ff7-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vmmmap.c.patch.txt" SW5kZXg6IHN5cy92bS92bV9tbWFwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX21tYXAuYwko cmV2aXNpb24gMTk5MDE2KQorKysgc3lzL3ZtL3ZtX21tYXAuYwkod29ya2luZyBjb3B5KQpAQCAt MjQ0LDYgKzI0NCw5IEBACiAJCXBvcyA9IDA7CiAJfQogCisJaWYgKGZsYWdzICYgTUFQX0FOT04g JiYgcG9zICE9IDApCisJCXJldHVybiAoRUlOVkFMKTsKKwogCS8qCiAJICogQWxpZ24gdGhlIGZp bGUgcG9zaXRpb24gdG8gYSBwYWdlIGJvdW5kYXJ5LAogCSAqIGFuZCBzYXZlIGl0cyBwYWdlIG9m ZnNldCBjb21wb25lbnQuCkBAIC0zMDAsNyArMzAzLDYgQEAKIAkJaGFuZGxlID0gTlVMTDsKIAkJ aGFuZGxlX3R5cGUgPSBPQkpUX0RFRkFVTFQ7CiAJCW1heHByb3QgPSBWTV9QUk9UX0FMTDsKLQkJ cG9zID0gMDsKIAl9IGVsc2UgewogCQkvKgogCQkgKiBNYXBwaW5nIGZpbGUsIGdldCBmcCBmb3Ig dmFsaWRhdGlvbiBhbmQK --+permail-20091108021905f0889e8400001ff7-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 8 17:32:41 2009 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 506AD106566C for ; Sun, 8 Nov 2009 17:32:41 +0000 (UTC) (envelope-from randyhyde@me.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9E28FC08 for ; Sun, 8 Nov 2009 17:32:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8 Received: from spool003.mac.com ([10.150.69.53]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KSS000BGTX8UM10@asmtp028.mac.com> for freebsd-hackers@freebsd.org; Sun, 08 Nov 2009 08:32:18 -0800 (PST) Received: from webmail036 ([10.13.128.36]) by spool003.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KSS00BG5TXNKX50@spool003.mac.com> for freebsd-hackers@freebsd.org; Sun, 08 Nov 2009 08:32:11 -0800 (PST) Date: Sun, 08 Nov 2009 08:32:11 -0800 From: Randall Hyde To: freebsd-hackers@freebsd.org Message-id: <99460406942256701304784967284744984406-Webmail@me.com> Received: from [71.83.93.238] from webmail.me.com with HTTP; Sun, 08 Nov 2009 08:32:11 -0800 X-Originating-IP: 71.83.93.238 X-Mailman-Approved-At: Sun, 08 Nov 2009 18:00:28 +0000 Subject: HLA v2.6 for FreeBSD is now available 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, 08 Nov 2009 17:32:41 -0000 Hi All, HLA v2.6 for FreeBSD is now available from the HLA download site on Webster: http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/HighLevelAsm/dnld.html v2.6 includes full PE/COFF native code generation for Win32, ELF native code generation for Linux and FreeBSD, and Mach-O native code generation for Mac OS X. v2.6 also implements a new overloads declaration for high-level-like procedure, method, and iterator calls. This is above and beyond the usual set of defect corrections. HLA is a high-level 32-bit x86 assembler that supports the 32-bit 80x86 instruction set as well as adding a set of high-level-like language features. More information on HLA is available at http://webster.cs.ucr.edu. Cheers, Randy Hyde From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 00:47:51 2009 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 9709D106566B for ; Mon, 9 Nov 2009 00:47:51 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 29BF48FC17 for ; Mon, 9 Nov 2009 00:47:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,705,1249250400"; d="txt'?scan'208";a="287742832" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Nov 2009 01:47:47 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 04BA31B07BE; Mon, 9 Nov 2009 01:47:46 +0100 (CET) Date: Mon, 09 Nov 2009 01:47:40 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009110900474080e26a0b00002e97-a_best01+ Cc: Subject: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 00:47:51 -0000 This is a MIME encoded multipart message. --+permail-2009110900474080e26a0b00002e97-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit any thoughts on these small changes to burncd? alex --+permail-2009110900474080e26a0b00002e97-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLmMJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuYwkod29ya2luZyBjb3B5KQpAQCAtNzgsMTMgKzc4LDE2IEBACiB7CiAJaW50IGFyZywgYWRk ciwgY2gsIGZkOwogCWludCBkYW8gPSAwLCBlamVjdCA9IDAsIGZpeGF0ZSA9IDAsIGxpc3QgPSAw LCBtdWx0aSA9IDAsIHByZWVtcCA9IDA7Ci0JaW50IG5vZ2FwID0gMCwgc3BlZWQgPSA0ICogMTc3 LCB0ZXN0X3dyaXRlID0gMCwgZm9yY2UgPSAwOworCWludCBub2dhcCA9IDAsIHNwZWVkID0gMCwg dGVzdF93cml0ZSA9IDAsIGZvcmNlID0gMDsKIAlpbnQgYmxvY2tfc2l6ZSA9IDAsIGJsb2NrX3R5 cGUgPSAwLCBjZG9wZW4gPSAwLCBkdmRydyA9IDA7CiAJY29uc3QgY2hhciAqZGV2OwogCiAJaWYg KChkZXYgPSBnZXRlbnYoIkNEUk9NIikpID09IE5VTEwpCiAJCWRldiA9ICIvZGV2L2FjZDAiOwog CisJaWYgKChzcGVlZCA9IGdldGVudigiU1BFRUQiKSkgPT0gTlVMTCkKKwkJc3BlZWQgPSA0ICog MTc3OworCiAJd2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiZGVmOkZsbW5wcXM6dHYi KSkgIT0gLTEpIHsKIAkJc3dpdGNoIChjaCkgewogCQljYXNlICdkJzoKSW5kZXg6IHVzci5zYmlu L2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9idXJuY2QvYnVybmNkLjgJ KHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAkod29ya2luZyBj b3B5KQpAQCAtMTY0LDYgKzE2NCwxMiBAQAogLkZsIGYKIGZsYWcuCiAuRWwKKy5CbCAtdGFnIC13 aWR0aCAiLkV2IFNQRUVEIgorLkl0IEV2IFNQRUVECitUaGUgd3JpdGUgc3BlZWQgdG8gdXNlIGlm IG9uZSBpcyBub3Qgc3BlY2lmaWVkIHdpdGggdGhlCisuRmwgcworZmxhZy4KKy5FbAogLlNoIEZJ TEVTCiAuQmwgLXRhZyAtd2lkdGggIi5QYSAvZGV2L2FjZDAiCiAuSXQgUGEgL2Rldi9hY2QwCg== --+permail-2009110900474080e26a0b00002e97-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 00:53:22 2009 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 8C8AD106568D for ; Mon, 9 Nov 2009 00:53:22 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 468468FC0A for ; Mon, 9 Nov 2009 00:53:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 7FCF014D9ACE; Mon, 9 Nov 2009 01:53:19 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P0LTu6IWlHUs; Mon, 9 Nov 2009 01:53:17 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 3375F14D569A; Mon, 9 Nov 2009 01:53:17 +0100 (CET) Message-ID: <4AF767FA.7040004@FreeBSD.org> Date: Mon, 09 Nov 2009 01:53:14 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 00:53:22 -0000 Alexander Best escribió: > any thoughts on these small changes to burncd? > > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > + int nogap = 0, speed = 0, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > + speed = 4 * 177; > + It seems incorrect. The speed variable is of type int, while getenv returns char *. You should first assign getenv("SPEED") to a char * variable and if it isn't NULL then you should convert it to int or fall back to the default value otherwise. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 01:02:42 2009 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 E545D106568D for ; Mon, 9 Nov 2009 01:02:42 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5B28FC15 for ; Mon, 9 Nov 2009 01:02:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id CCEA314D9ACE; Mon, 9 Nov 2009 02:02:41 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D3pZEA4ZNWWE; Mon, 9 Nov 2009 02:02:39 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4E2D514D569A; Mon, 9 Nov 2009 02:02:39 +0100 (CET) Message-ID: <4AF76A2C.400@FreeBSD.org> Date: Mon, 09 Nov 2009 02:02:36 +0100 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Best References: <4AF767FA.7040004@FreeBSD.org> In-Reply-To: <4AF767FA.7040004@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 01:02:43 -0000 Gabor Kovesdan escribió: > Alexander Best escribió: >> any thoughts on these small changes to burncd? >> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; >> + int nogap = 0, speed = 0, test_write = 0, force = 0; >> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; >> const char *dev; >> >> if ((dev = getenv("CDROM")) == NULL) >> dev = "/dev/acd0"; >> >> + if ((speed = getenv("SPEED")) == NULL) >> + speed = 4 * 177; >> + > It seems incorrect. The speed variable is of type int, while getenv > returns char *. You should first assign getenv("SPEED") to a char * > variable and if it isn't NULL then you should convert it to int or > fall back to the default value otherwise. And one more thing. Personally, I think that a more specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED is just too general. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 01:19:13 2009 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 5C03A106566C for ; Mon, 9 Nov 2009 01:19:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id B4BC38FC13 for ; Mon, 9 Nov 2009 01:19:12 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,705,1249250400"; d="txt'?scan'208";a="287743941" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Nov 2009 02:19:11 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9323B1B07BE; Mon, 9 Nov 2009 02:19:11 +0100 (CET) Date: Mon, 09 Nov 2009 02:19:05 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Gabor Kovesdan Message-ID: In-Reply-To: <4AF76A2C.400@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009110901190580e26a0b0000354f-a_best01+ Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 01:19:13 -0000 This is a MIME encoded multipart message. --+permail-2009110901190580e26a0b0000354f-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Gabor Kovesdan schrieb am 2009-11-09: > Gabor Kovesdan escribi=F3: > >Alexander Best escribi=F3: > >>any thoughts on these small changes to burncd? > >> - int nogap =3D 0, speed =3D 4 * 177, test_write =3D 0, force =3D 0= ; > >>+ int nogap =3D 0, speed =3D 0, test_write =3D 0, force =3D 0; > >> int block_size =3D 0, block_type =3D 0, cdopen =3D 0, dvdrw =3D 0; > >> const char *dev; > >> if ((dev =3D getenv("CDROM")) =3D=3D NULL) > >> dev =3D "/dev/acd0"; > >>+ if ((speed =3D getenv("SPEED")) =3D=3D NULL) > >>+ speed =3D 4 * 177; > >>+ > >It seems incorrect. The speed variable is of type int, while getenv > >returns char *. You should first assign getenv("SPEED") to a char * > >variable and if it isn't NULL then you should convert it to int or > >fall back to the default value otherwise. > And one more thing. Personally, I think that a more > specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED > is just too general. > -- > Gabor Kovesdan > FreeBSD Volunteer > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org thanks for the help. how about this revised patch? cheers. alex --+permail-2009110901190580e26a0b0000354f-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLjgJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuOAkod29ya2luZyBjb3B5KQpAQCAtMTY0LDYgKzE2NCwxMiBAQAogLkZsIGYKIGZsYWcuCiAu RWwKKy5CbCAtdGFnIC13aWR0aCAiLkV2IFdSSVRFX1NQRUVEIgorLkl0IEV2IFdSSVRFX1NQRUVE CitUaGUgd3JpdGUgc3BlZWQgdG8gdXNlIGlmIG9uZSBpcyBub3Qgc3BlY2lmaWVkIHdpdGggdGhl CisuRmwgcworZmxhZy4KKy5FbAogLlNoIEZJTEVTCiAuQmwgLXRhZyAtd2lkdGggIi5QYSAvZGV2 L2FjZDAiCiAuSXQgUGEgL2Rldi9hY2QwCkluZGV4OiB1c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gdXNyLnNiaW4vYnVybmNkL2J1cm5jZC5jCShyZXZpc2lvbiAxOTkwNjQp CisrKyB1c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJKHdvcmtpbmcgY29weSkKQEAgLTgwLDExICs4 MCwyMCBAQAogCWludCBkYW8gPSAwLCBlamVjdCA9IDAsIGZpeGF0ZSA9IDAsIGxpc3QgPSAwLCBt dWx0aSA9IDAsIHByZWVtcCA9IDA7CiAJaW50IG5vZ2FwID0gMCwgc3BlZWQgPSA0ICogMTc3LCB0 ZXN0X3dyaXRlID0gMCwgZm9yY2UgPSAwOwogCWludCBibG9ja19zaXplID0gMCwgYmxvY2tfdHlw ZSA9IDAsIGNkb3BlbiA9IDAsIGR2ZHJ3ID0gMDsKLQljb25zdCBjaGFyICpkZXY7CisJY29uc3Qg Y2hhciAqZGV2LCAqZW52X3NwZWVkOwogCiAJaWYgKChkZXYgPSBnZXRlbnYoIkNEUk9NIikpID09 IE5VTEwpCiAJCWRldiA9ICIvZGV2L2FjZDAiOwogCisJaWYgKChlbnZfc3BlZWQgPSBnZXRlbnYo IldSSVRFX1NQRUVEIikpICE9IE5VTEwpCisJCWlmIChzdHJjYXNlY21wKCJtYXgiLCBnZXRlbnYp ID09IDApCisJCQlzcGVlZCA9IENEUl9NQVhfU1BFRUQ7CisJCWVsc2UKKwkJCXNwZWVkID0gYXRv aShlbnZfc3BlZWQpICogMTc3OworCQlpZiAoc3BlZWQgPD0gMCkKKwkJCWVycngoRVhfVVNBR0Us ICJJbnZhbGlkIHNwZWVkOiAlcyIsIGVudl9zcGVlZCk7CisJfQorCiAJd2hpbGUgKChjaCA9IGdl dG9wdChhcmdjLCBhcmd2LCAiZGVmOkZsbW5wcXM6dHYiKSkgIT0gLTEpIHsKIAkJc3dpdGNoIChj aCkgewogCQljYXNlICdkJzoK --+permail-2009110901190580e26a0b0000354f-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 01:22:44 2009 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 A5069106566B for ; Mon, 9 Nov 2009 01:22:44 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0944D8FC15 for ; Mon, 9 Nov 2009 01:22:43 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,705,1249250400"; d="txt'?scan'208";a="287744038" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Nov 2009 02:22:43 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2453B1B07BE; Mon, 9 Nov 2009 02:22:43 +0100 (CET) Date: Mon, 09 Nov 2009 02:22:36 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Gabor Kovesdan Message-ID: In-Reply-To: <4AF76A2C.400@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009110901223680e26a0b000035b7-a_best01+ Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 01:22:44 -0000 This is a MIME encoded multipart message. --+permail-2009110901223680e26a0b000035b7-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Gabor Kovesdan schrieb am 2009-11-09: > Gabor Kovesdan escribi=F3: > >Alexander Best escribi=F3: > >>any thoughts on these small changes to burncd? > >> - int nogap =3D 0, speed =3D 4 * 177, test_write =3D 0, force =3D 0= ; > >>+ int nogap =3D 0, speed =3D 0, test_write =3D 0, force =3D 0; > >> int block_size =3D 0, block_type =3D 0, cdopen =3D 0, dvdrw =3D 0; > >> const char *dev; > >> if ((dev =3D getenv("CDROM")) =3D=3D NULL) > >> dev =3D "/dev/acd0"; > >>+ if ((speed =3D getenv("SPEED")) =3D=3D NULL) > >>+ speed =3D 4 * 177; > >>+ > >It seems incorrect. The speed variable is of type int, while getenv > >returns char *. You should first assign getenv("SPEED") to a char * > >variable and if it isn't NULL then you should convert it to int or > >fall back to the default value otherwise. > And one more thing. Personally, I think that a more > specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED > is just too general. > -- > Gabor Kovesdan > FreeBSD Volunteer > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org ooops. this one fixes the typos. ;) alex --+permail-2009110901223680e26a0b000035b7-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatchtypos.txt" LS0tIGJ1cm5jZC5jLnR5cG8JMjAwOS0xMS0wOSAwMjoxOTo0Ny4wMDAwMDAwMDAgKzAxMDAKKysr IGJ1cm5jZC5jCTIwMDktMTEtMDkgMDI6MjA6MjcuMDAwMDAwMDAwICswMTAwCkBAIC04NSw4ICs4 NSw4IEBACiAJaWYgKChkZXYgPSBnZXRlbnYoIkNEUk9NIikpID09IE5VTEwpCiAJCWRldiA9ICIv ZGV2L2FjZDAiOwogCi0JaWYgKChlbnZfc3BlZWQgPSBnZXRlbnYoIldSSVRFX1NQRUVEIikpICE9 IE5VTEwpCi0JCWlmIChzdHJjYXNlY21wKCJtYXgiLCBnZXRlbnYpID09IDApCisJaWYgKChlbnZf c3BlZWQgPSBnZXRlbnYoIldSSVRFX1NQRUVEIikpICE9IE5VTEwpIHsKKwkJaWYgKHN0cmNhc2Vj bXAoIm1heCIsIGVudl9zcGVlZCkgPT0gMCkKIAkJCXNwZWVkID0gQ0RSX01BWF9TUEVFRDsKIAkJ ZWxzZQogCQkJc3BlZWQgPSBhdG9pKGVudl9zcGVlZCkgKiAxNzc7Cg== --+permail-2009110901223680e26a0b000035b7-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 07:10:09 2009 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 C93A41065672 for ; Mon, 9 Nov 2009 07:10:09 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3988FC14 for ; Mon, 9 Nov 2009 07:10:09 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 5430BEB484E; Mon, 9 Nov 2009 09:10:08 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 43ECC452F7; Mon, 9 Nov 2009 09:10:08 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvEAARemxKot; Mon, 9 Nov 2009 09:10:08 +0200 (EET) Received: from kobe.laptop (adsl317-61.kln.forthnet.gr [188.4.41.61]) by mail.ceid.upatras.gr (Postfix) with ESMTP id E7648452F5; Mon, 9 Nov 2009 09:10:07 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nA97A7IE016171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 09:10:07 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nA97A6E4016170; Mon, 9 Nov 2009 09:10:06 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Alexander Best References: Date: Mon, 09 Nov 2009 09:10:06 +0200 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 01:47:40 +0100 (CET)") Message-ID: <873a4o2my9.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 07:10:09 -0000 --=-=-= On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best wrote: > any thoughts on these small changes to burncd? > > Index: usr.sbin/burncd/burncd.c > =================================================================== > --- usr.sbin/burncd/burncd.c (revision 199064) > +++ usr.sbin/burncd/burncd.c (working copy) > @@ -78,13 +78,16 @@ > { > int arg, addr, ch, fd; > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0; > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > + int nogap = 0, speed = 0, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > + speed = 4 * 177; > + > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > switch (ch) { > case 'd': Hi Alexander, The idea seems very good, but since the value of SPEED is user supplied data, I would rather see a bit of validation code after getenv(). With this version of the patch, burncd would happily accept and try to use values that are quite absurd, i.e.: env SPEED=12234567890 burncd ... It may also be sensible to do the translation from "human readable" speed values and the multiplication with 177 _after_ the value has been parsed from getenv(), so that e.g. one can write: env SPEED=4 burncd and get behavior similar to the current default. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkr3wE4ACgkQ1g+UGjGGA7YjFgCfXgfRdV1pVOnfH/AMcQy3HmLw Bx8An2bcrDqoGuT+yA6SFkYkDr9qxrSJ =sORN -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 07:19:37 2009 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 4EE3E1065693 for ; Mon, 9 Nov 2009 07:19:37 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id B52F18FC1B for ; Mon, 9 Nov 2009 07:19:35 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id E799AEB47CD; Mon, 9 Nov 2009 09:19:34 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id D1CB2452F9; Mon, 9 Nov 2009 09:19:34 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-LWZYCuhYcl; Mon, 9 Nov 2009 09:19:34 +0200 (EET) Received: from kobe.laptop (adsl317-61.kln.forthnet.gr [188.4.41.61]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 725E1451B2; Mon, 9 Nov 2009 09:19:34 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nA97JXEE016257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 09:19:33 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nA97JX3O016256; Mon, 9 Nov 2009 09:19:33 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Alexander Best References: Date: Mon, 09 Nov 2009 09:19:33 +0200 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 02:22:36 +0100 (CET)") Message-ID: <87y6mg17y2.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-hackers@FreeBSD.org, Gabor Kovesdan Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 07:19:37 -0000 --=-=-= On Mon, 09 Nov 2009 02:22:36 +0100 (CET), Alexander Best wrote: > --- burncd.c.typo 2009-11-09 02:19:47.000000000 +0100 > +++ burncd.c 2009-11-09 02:20:27.000000000 +0100 > @@ -85,8 +85,8 @@ > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > > - if ((env_speed = getenv("WRITE_SPEED")) != NULL) > - if (strcasecmp("max", getenv) == 0) > + if ((env_speed = getenv("WRITE_SPEED")) != NULL) { > + if (strcasecmp("max", env_speed) == 0) > speed = CDR_MAX_SPEED; > else > speed = atoi(env_speed) * 177; atoi() doesn't really have error checking and it does not necessarily affect `errno'. I'd probably prefer something that uses strtoul() and a few more value/range checks, i.e.: : #include : #include : : { : char *endp; : long xspeed; : : speed = 4 * 177; : if ((env_speed = getenv("SPEED")) != NULL) { : if (strcasecmp("max", env_speed) == 0) { : speed = CDR_MAX_SPEED; : } else { : end = NULL; : errno = 0; : xspeed = strtol(env_speed, &endp, 0); : if (errno != 0 || (endp != NULL && endp != str && : *endp != '\0' && (isdigit(*endp) != 0 || : isspace(*endp) == 0))) : err(1, "invalid write speed: %s", env_speed); : if (xspeed < 0 || xspeed > INT_MAX) : err(1, "write speed out of range: %ld", xspeed); : speed = (int)xspeed * 177; : } : } : } --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkr3woUACgkQ1g+UGjGGA7agFQCgqABc/G2c+47gxRnqiK81gcyJ PDMAniHujYEVHvgmUk+0ooepIwI778kT =OfHv -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 10:00:45 2009 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 68EA7106566B; Mon, 9 Nov 2009 10:00:45 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 292CA8FC16; Mon, 9 Nov 2009 10:00:45 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 412496D44C; Mon, 9 Nov 2009 10:00:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2531484503; Mon, 9 Nov 2009 11:00:44 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Giorgos Keramidas References: <87y6mg17y2.fsf@kobe.laptop> Date: Mon, 09 Nov 2009 11:00:43 +0100 In-Reply-To: <87y6mg17y2.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 09 Nov 2009 09:19:33 +0200") Message-ID: <86hbt4j9v8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Alexander Best , Gabor Kovesdan Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 10:00:45 -0000 Giorgos Keramidas writes: > atoi() doesn't really have error checking and it does not necessarily > affect `errno'. man 3 expand_number And please don't call it SPEED or WRITE_SPEED or anything generic; call it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar used to specify the device is called CDROM, not DEVICE. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 11:59:43 2009 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 3CC831065672; Mon, 9 Nov 2009 11:59:43 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id A2CBB8FC15; Mon, 9 Nov 2009 11:59:42 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id B0E89EB47AF; Mon, 9 Nov 2009 13:37:31 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id A0BDD452B4; Mon, 9 Nov 2009 13:37:31 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCcJObyEIXLp; Mon, 9 Nov 2009 13:37:31 +0200 (EET) Received: from kobe.laptop (ppp-94-64-211-25.home.otenet.gr [94.64.211.25]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 571C7451B2; Mon, 9 Nov 2009 13:37:31 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nA9BbUK9003585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 13:37:30 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nA9BbTq0003584; Mon, 9 Nov 2009 13:37:29 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86hbt4j9v8.fsf@ds4.des.no> ("Dag-Erling =?iso-8859-1?Q?Sm=F8?= =?iso-8859-1?Q?rgrav=22's?= message of "Mon, 09 Nov 2009 11:00:43 +0100") References: <87y6mg17y2.fsf@kobe.laptop> <86hbt4j9v8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) Date: Mon, 09 Nov 2009 13:37:22 +0200 Message-ID: <87vdhkgc99.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org, Alexander Best , Gabor Kovesdan Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 11:59:43 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 09 Nov 2009 11:00:43 +0100, Dag-Erling Sm=F8rgrav wrot= e: > Giorgos Keramidas writes: >> atoi() doesn't really have error checking and it does not necessarily >> affect `errno'. > > man 3 expand_number I know, but thanks. In this case, expand_number's logic for parsing possible SI suffixes is not useful and may be slightly confusing. I'm not sure what CDROM_SPEED=3D'4m' would mean for burncd's -s option, for example. > And please don't call it SPEED or WRITE_SPEED or anything generic; call > it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar > used to specify the device is called CDROM, not DEVICE. Good point. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkr3/vgACgkQ1g+UGjGGA7Y2+ACdFLfjx1Nm0icvPhGlwa107q+r O0gAn3ORD0ATJtV9gYZMQpVCk7onZEYl =g4qT -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 12:32:23 2009 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 24AB2106568F; Mon, 9 Nov 2009 12:32:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D76D78FC08; Mon, 9 Nov 2009 12:32:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 29AC86D41B; Mon, 9 Nov 2009 12:32:22 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0BFEB844D2; Mon, 9 Nov 2009 13:32:22 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Giorgos Keramidas References: <87y6mg17y2.fsf@kobe.laptop> <86hbt4j9v8.fsf@ds4.des.no> <87vdhkgc99.fsf@kobe.laptop> Date: Mon, 09 Nov 2009 13:32:21 +0100 In-Reply-To: <87vdhkgc99.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 09 Nov 2009 13:37:22 +0200") Message-ID: <86skcnj2ui.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Alexander Best , Gabor Kovesdan Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 12:32:23 -0000 Giorgos Keramidas writes: > Dag-Erling Sm=C3=B8rgrav wrote: > > man 3 expand_number > I know, but thanks. In this case, expand_number's logic for parsing > possible SI suffixes is not useful and may be slightly confusing. > > I'm not sure what CDROM_SPEED=3D'4m' would mean for burncd's -s option, > for example. Hmm, I thought the speed was expressed in kBps or something... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 14:39:17 2009 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 25B0A1065693 for ; Mon, 9 Nov 2009 14:39:17 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id A8B0E8FC1C for ; Mon, 9 Nov 2009 14:39:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,708,1249250400"; d="scan'208";a="228503710" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 09 Nov 2009 15:39:14 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id BE4E11B0751; Mon, 9 Nov 2009 15:39:14 +0100 (CET) Date: Mon, 09 Nov 2009 15:39:14 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Giorgos Keramidas Message-ID: In-Reply-To: <873a4o2my9.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 14:39:17 -0000 Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best > wrote: > > any thoughts on these small changes to burncd? > > Index: usr.sbin/burncd/burncd.c > > =================================================================== > > --- usr.sbin/burncd/burncd.c (revision 199064) > > +++ usr.sbin/burncd/burncd.c (working copy) > > @@ -78,13 +78,16 @@ > > { > > int arg, addr, ch, fd; > > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, > > preemp = 0; > > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > > + int nogap = 0, speed = 0, test_write = 0, force = 0; > > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > > const char *dev; > > if ((dev = getenv("CDROM")) == NULL) > > dev = "/dev/acd0"; > > + if ((speed = getenv("SPEED")) == NULL) > > + speed = 4 * 177; > > + > > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > > switch (ch) { > > case 'd': > Hi Alexander, > The idea seems very good, but since the value of SPEED is user > supplied > data, I would rather see a bit of validation code after getenv(). > With > this version of the patch, burncd would happily accept and try to use > values that are quite absurd, i.e.: > env SPEED=12234567890 burncd ... > It may also be sensible to do the translation from "human readable" > speed values and the multiplication with 177 _after_ the value has > been > parsed from getenv(), so that e.g. one can write: > env SPEED=4 burncd > and get behavior similar to the current default. i don't quite get why the value supplied with the envar has to be validated. if the user supplies a speed value using the -s switch no validation (except <= 0) is being performed either. also i think there's a speed check in the atapi code. if the speed requested is > the maximum driver speed it gets set to the maximum driver speed automatically. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 14:52:13 2009 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 99045106568D for ; Mon, 9 Nov 2009 14:52:13 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 05D8F8FC0C for ; Mon, 9 Nov 2009 14:52:12 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id E3672EB47FE; Mon, 9 Nov 2009 16:52:11 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id C4D2E452A4; Mon, 9 Nov 2009 16:52:11 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YMkqdsuC5gk; Mon, 9 Nov 2009 16:52:11 +0200 (EET) Received: from kobe.laptop (ppp-94-64-236-65.home.otenet.gr [94.64.236.65]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 78AA0451B2; Mon, 9 Nov 2009 16:52:11 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nA9EqATw006008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 16:52:10 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nA9Eq91N006007; Mon, 9 Nov 2009 16:52:10 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Alexander Best References: Date: Mon, 09 Nov 2009 16:52:09 +0200 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 15:28:29 +0100 (CET)") Message-ID: <87hbt3hht2.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 14:52:13 -0000 On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best wrote: > Giorgos Keramidas schrieb am 2009-11-09: >> Hi Alexander, > >> The idea seems very good, but since the value of SPEED is user >> supplied data, I would rather see a bit of validation code after >> getenv(). With this version of the patch, burncd would happily >> accept and try to use values that are quite absurd, i.e.: > >> env SPEED=12234567890 burncd ... > >> It may also be sensible to do the translation from "human readable" >> speed values and the multiplication with 177 _after_ the value has >> been parsed from getenv(), so that e.g. one can write: > >> env SPEED=4 burncd > >> and get behavior similar to the current default. > > i don't quite get why the value supplied with the envar has to be > validated. if the user supplies a speed value using the -s switch no > validation (except <= 0) is being performed either. This is probably me being paranoid. I'd prefer *both* places to check the supplied value for invalid values, even if the check is something like "negative numbers are not ok". > also i think there's a speed check in the atapi code. if the speed > requested is > the maximum driver speed it gets set to the maximum > driver speed automatically. If the capping happens automatically we're fine. From a cursory look at the kernel sources this morning, I didn't manage to find a speed-range check in sys/dev/ata. The acd_set_speed() code is a small function: : static int : acd_set_speed(device_t dev, int rdspeed, int wrspeed) : { : int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed, : wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; : int error; : : error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30); : if (!error) : acd_get_cap(dev); : return error; : } and that's all. It probably relies on the hardware to cap the speed, but I am not very familiar with the rest of the ATA code to be sure. Your patch is fine, but as a followup commit I'd probably like seeing atoi() go away. AFAICT, it currently allows invalid speed values, defaulting to speed=0 when a user types: burncd -s foobar [options ...] We can fix that later though :) From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 15:50:20 2009 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 7E32C106568F for ; Mon, 9 Nov 2009 15:50:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 518C88FC30 for ; Mon, 9 Nov 2009 15:50:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DD0C046B0D; Mon, 9 Nov 2009 10:50:19 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 176AD8A01F; Mon, 9 Nov 2009 10:50:19 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 9 Nov 2009 09:27:04 -0500 User-Agent: KMail/1.9.7 References: <761362.20406.qm@web113204.mail.gq1.yahoo.com> In-Reply-To: <761362.20406.qm@web113204.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911090927.05010.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 09 Nov 2009 10:50:19 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Trever Subject: Re: Why is default value of NKPT so small? mfsroot 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, 09 Nov 2009 15:50:20 -0000 On Friday 06 November 2009 2:19:51 pm Trever wrote: > Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h? > > It seems to me that it's too small, though I'm wondering if there are some considerations in changing it's value that I should know about. > > Too small because: making it a little more than twice as large (so you can get about a 300MB mfsroot to boot) means you can (by default) boot a standard FreeBSD system into memory, and I know I can't be the only one who would value that a great deal for many reasons. As it stands you have to ax things out (like depenguinator does, for example). Or you have to recompile the kernel. > > Does it have to be like this? > > Which leads me to two more questions: > - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask. > - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)? I keep meaning to make NKPT a kernel option for i386. Try this patch, it should let you add 'options NKPT=xxx' to your kernel config. Index: conf/options.i386 =================================================================== --- conf/options.i386 (revision 198997) +++ conf/options.i386 (working copy) @@ -12,6 +12,7 @@ MAXMEM MPTABLE_FORCE_HTT MP_WATCHDOG +NKPT opt_pmap.h PERFMON PMAP_SHPGPERPROC opt_pmap.h POWERFAIL_NMI opt_trap.h Index: i386/i386/mp_machdep.c =================================================================== --- i386/i386/mp_machdep.c (revision 198997) +++ i386/i386/mp_machdep.c (working copy) @@ -30,6 +30,7 @@ #include "opt_cpu.h" #include "opt_kstack_pages.h" #include "opt_mp_watchdog.h" +#include "opt_pmap.h" #include "opt_sched.h" #include "opt_smp.h" Index: i386/xen/mp_machdep.c =================================================================== --- i386/xen/mp_machdep.c (revision 198997) +++ i386/xen/mp_machdep.c (working copy) @@ -31,6 +31,7 @@ #include "opt_cpu.h" #include "opt_kstack_pages.h" #include "opt_mp_watchdog.h" +#include "opt_pmap.h" #include "opt_sched.h" #include "opt_smp.h" -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 15:50:21 2009 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 58DBC106566C for ; Mon, 9 Nov 2009 15:50:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 29C638FC19 for ; Mon, 9 Nov 2009 15:50:21 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D342A46B29; Mon, 9 Nov 2009 10:50:20 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1D00B8A020; Mon, 9 Nov 2009 10:50:20 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 9 Nov 2009 09:31:12 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911090931.12494.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 09 Nov 2009 10:50:20 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best , Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't 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, 09 Nov 2009 15:50:21 -0000 On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote: > no problem. i've sent the final patch as followup to kern/71258 and also > attached it to this message. to make it short. what's being changed by the > patch: > > 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL > 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 > > would be great if you could have a look at the patch if you've got a spare > minute. I didn't think 2) changed? I.e. both the old and new code do this, so only 1) is changing? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 15:57:54 2009 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 B826A1065692; Mon, 9 Nov 2009 15:57:54 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 09EE08FC0C; Mon, 9 Nov 2009 15:57:53 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,708,1249250400"; d="scan'208";a="18034605" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 09 Nov 2009 16:57:52 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 6F1941B0751; Mon, 9 Nov 2009 16:57:52 +0100 (CET) Date: Mon, 09 Nov 2009 16:57:52 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Message-ID: In-Reply-To: <200911090931.12494.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: Re: mmap(2) with MAP_ANON honouring offset although it shouldn't 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, 09 Nov 2009 15:57:54 -0000 John Baldwin schrieb am 2009-11-09: > On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote: > > no problem. i've sent the final patch as followup to kern/71258 and > > also > > attached it to this message. to make it short. what's being changed > > by the > > patch: > > 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL > > 2) if MAP_STACK is defined and offset !=0 ====> offset = 0 > > would be great if you could have a look at the patch if you've got > > a spare > > minute. > I didn't think 2) changed? I.e. both the old and new code do this, > so only 1) > is changing? you're right sorry about that mistake. so the only aspect of mmap() the patch changes is: if MAP_ANON is defined and offset !=0 ====> return EINVAL cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 18:01:52 2009 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 8DA79106566C; Mon, 9 Nov 2009 18:01:52 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id D68C68FC0C; Mon, 9 Nov 2009 18:01:51 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,710,1249250400"; d="txt'?scan'208";a="287825002" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Nov 2009 19:01:50 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id D80FA1B0767; Mon, 9 Nov 2009 19:01:49 +0100 (CET) Date: Mon, 09 Nov 2009 19:01:43 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Giorgos Keramidas Message-ID: In-Reply-To: <87hbt3hht2.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20091109180143f0889e84000046bf-a_best01+ Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 18:01:52 -0000 This is a MIME encoded multipart message. --+permail-20091109180143f0889e84000046bf-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best > wrote: > > Giorgos Keramidas schrieb am 2009-11-09: > >> Hi Alexander, > >> The idea seems very good, but since the value of SPEED is user > >> supplied data, I would rather see a bit of validation code after > >> getenv(). With this version of the patch, burncd would happily > >> accept and try to use values that are quite absurd, i.e.: > >> env SPEED=12234567890 burncd ... > >> It may also be sensible to do the translation from "human > >> readable" > >> speed values and the multiplication with 177 _after_ the value has > >> been parsed from getenv(), so that e.g. one can write: > >> env SPEED=4 burncd > >> and get behavior similar to the current default. > > i don't quite get why the value supplied with the envar has to be > > validated. if the user supplies a speed value using the -s switch > > no > > validation (except <= 0) is being performed either. > This is probably me being paranoid. I'd prefer *both* places to > check > the supplied value for invalid values, even if the check is something > like "negative numbers are not ok". > > also i think there's a speed check in the atapi code. if the speed > > requested is > the maximum driver speed it gets set to the maximum > > driver speed automatically. > If the capping happens automatically we're fine. From a cursory look > at > the kernel sources this morning, I didn't manage to find a > speed-range > check in sys/dev/ata. The acd_set_speed() code is a small function: > : static int > : acd_set_speed(device_t dev, int rdspeed, int wrspeed) > : { > : int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed, > : wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0 }; > : int error; > : > : error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30); > : if (!error) > : acd_get_cap(dev); > : return error; > : } > and that's all. It probably relies on the hardware to cap the speed, > but I am not very familiar with the rest of the ATA code to be sure. > Your patch is fine, but as a followup commit I'd probably like seeing > atoi() go away. AFAICT, it currently allows invalid speed values, > defaulting to speed=0 when a user types: > burncd -s foobar [options ...] > We can fix that later though :) ok. so do you think this patch is sufficient then? once committed i'll see if i can add some extra validation to the envar as well as the -s switch and will also have a look at the validation the ATA code is doing atm. alex --+permail-20091109180143f0889e84000046bf-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLjgJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuOAkod29ya2luZyBjb3B5KQpAQCAtMTY0LDYgKzE2NCwxMiBAQAogLkZsIGYKIGZsYWcuCiAu RWwKKy5CbCAtdGFnIC13aWR0aCAiLkV2IEJVUk5DRF9TUEVFRCIKKy5JdCBFdiBCVVJOQ0RfU1BF RUQKK1RoZSB3cml0ZSBzcGVlZCB0byB1c2UgaWYgb25lIGlzIG5vdCBzcGVjaWZpZWQgd2l0aCB0 aGUKKy5GbCBzCitmbGFnLgorLkVsCiAuU2ggRklMRVMKIC5CbCAtdGFnIC13aWR0aCAiLlBhIC9k ZXYvYWNkMCIKIC5JdCBQYSAvZGV2L2FjZDAKSW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2Qu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJKHJldmlzaW9uIDE5OTA2 NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJuY2QuYwkod29ya2luZyBjb3B5KQpAQCAtODAsMTEg KzgwLDIwIEBACiAJaW50IGRhbyA9IDAsIGVqZWN0ID0gMCwgZml4YXRlID0gMCwgbGlzdCA9IDAs IG11bHRpID0gMCwgcHJlZW1wID0gMDsKIAlpbnQgbm9nYXAgPSAwLCBzcGVlZCA9IDQgKiAxNzcs IHRlc3Rfd3JpdGUgPSAwLCBmb3JjZSA9IDA7CiAJaW50IGJsb2NrX3NpemUgPSAwLCBibG9ja190 eXBlID0gMCwgY2RvcGVuID0gMCwgZHZkcncgPSAwOwotCWNvbnN0IGNoYXIgKmRldjsKKwljb25z dCBjaGFyICpkZXYsICplbnZfc3BlZWQ7CiAKIAlpZiAoKGRldiA9IGdldGVudigiQ0RST00iKSkg PT0gTlVMTCkKIAkJZGV2ID0gIi9kZXYvYWNkMCI7CiAKKwlpZiAoKGVudl9zcGVlZCA9IGdldGVu digiQlVSTkNEX1NQRUVEIikpICE9IE5VTEwpIHsKKwkJaWYgKHN0cmNhc2VjbXAoIm1heCIsIGVu dl9zcGVlZCkgPT0gMCkKKwkJCXNwZWVkID0gQ0RSX01BWF9TUEVFRDsKKwkJZWxzZQorCQkJc3Bl ZWQgPSBhdG9pKGVudl9zcGVlZCkgKiAxNzc7CisJCWlmIChzcGVlZCA8PSAwKQorCQkJZXJyeChF WF9VU0FHRSwgIkludmFsaWQgc3BlZWQ6ICVzIiwgZW52X3NwZWVkKTsKKwl9CisKIAl3aGlsZSAo KGNoID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJkZWY6RmxtbnBxczp0diIpKSAhPSAtMSkgewogCQlz d2l0Y2ggKGNoKSB7CiAJCWNhc2UgJ2QnOgo= --+permail-20091109180143f0889e84000046bf-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 18:07:38 2009 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 7B5F51065676 for ; Mon, 9 Nov 2009 18:07:38 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id DED698FC1C for ; Mon, 9 Nov 2009 18:07:37 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id DE2EAEB47E4; Mon, 9 Nov 2009 20:07:36 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id C891F452B4; Mon, 9 Nov 2009 20:07:36 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-0bcIOzqsCT; Mon, 9 Nov 2009 20:07:36 +0200 (EET) Received: from kobe.laptop (ppp-94-64-244-12.home.otenet.gr [94.64.244.12]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 60B62452A4; Mon, 9 Nov 2009 20:07:36 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nA9I7ZYo043818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 20:07:35 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nA9I7YFF043812; Mon, 9 Nov 2009 20:07:34 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Alexander Best References: Date: Mon, 09 Nov 2009 20:07:29 +0200 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 19:01:43 +0100 (CET)") Message-ID: <87k4xzbmhq.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 18:07:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best wrote: >Giorgos Keramidas schrieb am 2009-11-09: >> > i don't quite get why the value supplied with the envar has to be >> > validated. if the user supplies a speed value using the -s switch >> > no validation (except <=3D 0) is being performed either. > >> This is probably me being paranoid. I'd prefer *both* places to >> check the supplied value for invalid values, even if the check is >> something like "negative numbers are not ok". > >> > also i think there's a speed check in the atapi code. if the speed >> > requested is > the maximum driver speed it gets set to the maximum >> > driver speed automatically. > >> Your patch is fine, but as a followup commit I'd probably like seeing >> atoi() go away. AFAICT, it currently allows invalid speed values, >> defaulting to speed=3D0 when a user types: > >> burncd -s foobar [options ...] > >> We can fix that later though :) > > ok. so do you think this patch is sufficient then? once committed i'll > see if i can add some extra validation to the envar as well as the -s > switch and will also have a look at the validation the ATA code is > doing atm. Yes, the patch attached below is fine, and IMO it would be ok to commit it, minus a couple of tiny details: sorting the BURNCD_SPEED environment variable before the current CDROM item in the manpage, and bumping the manpage modification date near .Dd to today. %%% Index: usr.sbin/burncd/burncd.8 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- usr.sbin/burncd/burncd.8 (revision 199064) +++ usr.sbin/burncd/burncd.8 (working copy) @@ -164,6 +164,12 @@ .Fl f flag. .El +.Bl -tag -width ".Ev BURNCD_SPEED" +.It Ev BURNCD_SPEED +The write speed to use if one is not specified with the +.Fl s +flag. +.El .Sh FILES .Bl -tag -width ".Pa /dev/acd0" .It Pa /dev/acd0 Index: usr.sbin/burncd/burncd.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 =2D-- usr.sbin/burncd/burncd.c (revision 199064) +++ usr.sbin/burncd/burncd.c (working copy) @@ -80,11 +80,20 @@ int dao =3D 0, eject =3D 0, fixate =3D 0, list =3D 0, multi =3D 0, preemp= =3D 0; int nogap =3D 0, speed =3D 4 * 177, test_write =3D 0, force =3D 0; int block_size =3D 0, block_type =3D 0, cdopen =3D 0, dvdrw =3D 0; =2D const char *dev; + const char *dev, *env_speed; =20 if ((dev =3D getenv("CDROM")) =3D=3D NULL) dev =3D "/dev/acd0"; =20 + if ((env_speed =3D getenv("BURNCD_SPEED")) !=3D NULL) { + if (strcasecmp("max", env_speed) =3D=3D 0) + speed =3D CDR_MAX_SPEED; + else + speed =3D atoi(env_speed) * 177; + if (speed <=3D 0) + errx(EX_USAGE, "Invalid speed: %s", env_speed); + } + while ((ch =3D getopt(argc, argv, "def:Flmnpqs:tv")) !=3D -1) { switch (ch) { case 'd': %%% --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkr4WmYACgkQ1g+UGjGGA7biPQCbBZxm07AJZwoEWF8rNFByihOt EQQAnjtgH5Wz8erNPv1XGxFcGi9Ixerw =mZ8m -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 19:03:16 2009 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 6D085106566C; Mon, 9 Nov 2009 19:03:16 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id C8C718FC1D; Mon, 9 Nov 2009 19:03:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,710,1249250400"; d="scan'208";a="18048238" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 09 Nov 2009 20:03:14 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4B74B1B0751; Mon, 9 Nov 2009 20:03:14 +0100 (CET) Date: Mon, 09 Nov 2009 20:03:13 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Giorgos Keramidas Message-ID: In-Reply-To: <87k4xzbmhq.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 19:03:16 -0000 Giorgos Keramidas schrieb am 2009-11-09: > On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best > wrote: > >Giorgos Keramidas schrieb am 2009-11-09: > >> > i don't quite get why the value supplied with the envar has to > >> > be > >> > validated. if the user supplies a speed value using the -s > >> > switch > >> > no validation (except <= 0) is being performed either. > >> This is probably me being paranoid. I'd prefer *both* places to > >> check the supplied value for invalid values, even if the check is > >> something like "negative numbers are not ok". > >> > also i think there's a speed check in the atapi code. if the > >> > speed > >> > requested is > the maximum driver speed it gets set to the > >> > maximum > >> > driver speed automatically. > >> Your patch is fine, but as a followup commit I'd probably like > >> seeing > >> atoi() go away. AFAICT, it currently allows invalid speed values, > >> defaulting to speed=0 when a user types: > >> burncd -s foobar [options ...] > >> We can fix that later though :) > > ok. so do you think this patch is sufficient then? once committed > > i'll > > see if i can add some extra validation to the envar as well as the > > -s > > switch and will also have a look at the validation the ATA code is > > doing atm. > Yes, the patch attached below is fine, and IMO it would be ok to > commit > it, minus a couple of tiny details: sorting the BURNCD_SPEED > environment > variable before the current CDROM item in the manpage, and bumping > the > manpage modification date near .Dd to today. > %%% > Index: usr.sbin/burncd/burncd.8 > =================================================================== > --- usr.sbin/burncd/burncd.8 (revision 199064) > +++ usr.sbin/burncd/burncd.8 (working copy) > @@ -164,6 +164,12 @@ > .Fl f > flag. > .El > +.Bl -tag -width ".Ev BURNCD_SPEED" > +.It Ev BURNCD_SPEED > +The write speed to use if one is not specified with the > +.Fl s > +flag. > +.El > .Sh FILES > .Bl -tag -width ".Pa /dev/acd0" > .It Pa /dev/acd0 > Index: usr.sbin/burncd/burncd.c > =================================================================== > --- usr.sbin/burncd/burncd.c (revision 199064) > +++ usr.sbin/burncd/burncd.c (working copy) > @@ -80,11 +80,20 @@ > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, > preemp = 0; > int nogap = 0, speed = 4 * 177, test_write = 0, force = 0; > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0; > - const char *dev; > + const char *dev, *env_speed; > if ((dev = getenv("CDROM")) == NULL) > dev = "/dev/acd0"; > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) { > + if (strcasecmp("max", env_speed) == 0) > + speed = CDR_MAX_SPEED; > + else > + speed = atoi(env_speed) * 177; > + if (speed <= 0) > + errx(EX_USAGE, "Invalid speed: %s", > env_speed); > + } > + > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) { > switch (ch) { > case 'd': > %%% ok. thanks a lot. maybe somebody will step up and commit this. i'm not familiar with the man() syntax so i might need some time to add the changes you recommended. also it seems the ENVIREMENT section needs to be aligned differently now that it has more than > 1 entry. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 19:25:05 2009 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 94FF7106566C; Mon, 9 Nov 2009 19:25:05 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id DBAD08FC15; Mon, 9 Nov 2009 19:25:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,711,1249250400"; d="txt'?scan'208";a="287831286" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 09 Nov 2009 20:25:03 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9A7EB1B0751; Mon, 9 Nov 2009 20:25:03 +0100 (CET) Date: Mon, 09 Nov 2009 20:24:56 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: <87k4xzbmhq.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200911091924561e86ffa8000070ba-a_best01+ Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Giorgos Keramidas Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 19:25:05 -0000 This is a MIME encoded multipart message. --+permail-200911091924561e86ffa8000070ba-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable here's the final patch. would be great if somebody could commit this one. t= he only thing i'm not 100% sure about are the burncd(8) changes. i'm not that familiar with the man syntax. thanks go out to keramida@ and des@ for their help. alex =2E..just realised the topic makes no sense. ;) what i meant to write was probably "[patch] burncd: honour envar SPEED". ;) --+permail-200911091924561e86ffa8000070ba-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLjgJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuOAkod29ya2luZyBjb3B5KQpAQCAtMjcsNyArMjcsNyBAQAogLlwiCiAuXCIgJEZyZWVCU0Qk CiAuXCIKLS5EZCBNYXkgMiwgMjAwNQorLkRkIE5vdiA5LCAyMDA5CiAuT3MKIC5EdCBCVVJOQ0Qg OAogLlNoIE5BTUUKQEAgLTE1OCw3ICsxNTgsMTEgQEAKIC5TaCBFTlZJUk9OTUVOVAogVGhlIGZv bGxvd2luZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgYWZmZWN0IHRoZSBleGVjdXRpb24gb2YKIC5O bSA6Ci0uQmwgLXRhZyAtd2lkdGggIi5FdiBDRFJPTSIKKy5CbCAtdGFnIC13aWR0aCAiLkV2IEJV Uk5DRF9TUEVFRCIKKy5JdCBFdiBCVVJOQ0RfU1BFRUQKK1RoZSB3cml0ZSBzcGVlZCB0byB1c2Ug aWYgb25lIGlzIG5vdCBzcGVjaWZpZWQgd2l0aCB0aGUKKy5GbCBzCitmbGFnLgogLkl0IEV2IENE Uk9NCiBUaGUgQ0QgZGV2aWNlIHRvIHVzZSBpZiBvbmUgaXMgbm90IHNwZWNpZmllZCB3aXRoIHRo ZQogLkZsIGYKSW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1 c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1 cm5jZC9idXJuY2QuYwkod29ya2luZyBjb3B5KQpAQCAtODAsMTEgKzgwLDIwIEBACiAJaW50IGRh byA9IDAsIGVqZWN0ID0gMCwgZml4YXRlID0gMCwgbGlzdCA9IDAsIG11bHRpID0gMCwgcHJlZW1w ID0gMDsKIAlpbnQgbm9nYXAgPSAwLCBzcGVlZCA9IDQgKiAxNzcsIHRlc3Rfd3JpdGUgPSAwLCBm b3JjZSA9IDA7CiAJaW50IGJsb2NrX3NpemUgPSAwLCBibG9ja190eXBlID0gMCwgY2RvcGVuID0g MCwgZHZkcncgPSAwOwotCWNvbnN0IGNoYXIgKmRldjsKKwljb25zdCBjaGFyICpkZXYsICplbnZf c3BlZWQ7CiAKIAlpZiAoKGRldiA9IGdldGVudigiQ0RST00iKSkgPT0gTlVMTCkKIAkJZGV2ID0g Ii9kZXYvYWNkMCI7CiAKKwlpZiAoKGVudl9zcGVlZCA9IGdldGVudigiQlVSTkNEX1NQRUVEIikp ICE9IE5VTEwpIHsKKwkJaWYgKHN0cmNhc2VjbXAoIm1heCIsIGVudl9zcGVlZCkgPT0gMCkKKwkJ CXNwZWVkID0gQ0RSX01BWF9TUEVFRDsKKwkJZWxzZQorCQkJc3BlZWQgPSBhdG9pKGVudl9zcGVl ZCkgKiAxNzc7CisJCWlmIChzcGVlZCA8PSAwKQorCQkJZXJyeChFWF9VU0FHRSwgIkludmFsaWQg c3BlZWQ6ICVzIiwgZW52X3NwZWVkKTsKKwl9CisKIAl3aGlsZSAoKGNoID0gZ2V0b3B0KGFyZ2Ms IGFyZ3YsICJkZWY6RmxtbnBxczp0diIpKSAhPSAtMSkgewogCQlzd2l0Y2ggKGNoKSB7CiAJCWNh c2UgJ2QnOgo= --+permail-200911091924561e86ffa8000070ba-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 20:24:49 2009 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 830D3106566B for ; Mon, 9 Nov 2009 20:24:49 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 10E8E8FC1C for ; Mon, 9 Nov 2009 20:24:48 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,711,1249250400"; d="scan'208";a="18052860" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 09 Nov 2009 21:24:47 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id A6A5C1B0767; Mon, 9 Nov 2009 21:24:47 +0100 (CET) Date: Mon, 09 Nov 2009 21:24:46 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: help needed to fix contrib/ee crash/exit when receiving SIGWINCH 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, 09 Nov 2009 20:24:49 -0000 since you've tested the patch on 7-stable do think it's mature enough to be committed to that branch? alex From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 20:58:23 2009 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 450EF106566B; Mon, 9 Nov 2009 20:58:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 060D58FC16; Mon, 9 Nov 2009 20:58:23 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 46D826D41B; Mon, 9 Nov 2009 20:58:22 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EBBF184503; Mon, 9 Nov 2009 21:58:21 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: Date: Mon, 09 Nov 2009 21:58:21 +0100 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 20:24:56 +0100 (CET)") Message-ID: <86aayvfmaa.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Giorgos Keramidas Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 20:58:23 -0000 Alexander Best writes: >=20=20 > + if ((env_speed =3D getenv("BURNCD_SPEED")) !=3D NULL) { > + if (strcasecmp("max", env_speed) =3D=3D 0) > + speed =3D CDR_MAX_SPEED; > + else > + speed =3D atoi(env_speed) * 177; > + if (speed <=3D 0) > + errx(EX_USAGE, "Invalid speed: %s", env_speed); > + } > + > while ((ch =3D getopt(argc, argv, "def:Flmnpqs:tv")) !=3D -1) { > switch (ch) { > case 'd': You realize you're duplicating 6 lines of non-trivial code for no good reason? env_speed =3D getenv("BURNCD_SPEED"); while ((ch =3D getopt(...)) !=3D -1) { switch (ch) { case 's': env_speed =3D optarg; break; ... } } if (env_speed !=3D NULL) { if (strcasecmp...) { ... } } DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 21:05:19 2009 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 A939D106566B; Mon, 9 Nov 2009 21:05:19 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 5836B8FC08; Mon, 9 Nov 2009 21:05:18 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id nA9KYBiL016294; Mon, 9 Nov 2009 20:34:11 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7awF-0007OB-NH; Mon, 09 Nov 2009 20:34:11 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nA9KYBkC071706; Mon, 9 Nov 2009 20:34:11 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nA9KYAxG071694; Mon, 9 Nov 2009 20:34:10 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 9 Nov 2009 20:34:09 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> Message-ID: <20091109195045.Q13027@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing 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, 09 Nov 2009 21:05:19 -0000 On Wed, 14 Oct 2009, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz Nice! I've got the following device in my laptop: heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Management Engine Interface (Mobile 4 Series Chipset)' class = simple comms I've added this device to the code, and loaded it: heci0: mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x02: heci0: status = 0x00 heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 heci0: found ME client at address 0x06: heci0: status = 0x00 heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 heci0: found ME client at address 0x22: heci0: status = 0x00 heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 heci0: found ME client at address 0x23: heci0: status = 0x00 heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C heci0: found ME client at address 0x24: heci0: status = 0x00 heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB However, running the heci-qst.c program you supplied: psi# ./heci-qst ioctl HECI_CONNECT: No such file or directory And output to the console: heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607 Other than seeing that it doesn't appear in the list above, I don't know if this is expected or not... Secondly, I get a panic on module unlaod. I haven't spent any time looking at this, if you haven't fixed it yet let me know and I'll look into it further. I'm not even sure how it's getting that far into the detach routine before panicing, if dev really does = 0xdeadc0dedeadc0de #8 0xffffffff808580d3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) at /usr/src/sys/kern/kern_mutex.c:827 #10 0xffffffff812221c6 in heci_detach () from /usr/src/sys/modules/heci/heci.ko #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) at device_if.h:212 #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, what=Variable "what" is not available. ) at /usr/src/sys/kern/subr_bus.c:1156 #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) at /usr/src/sys/kern/kern_module.c:266 #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, flags=0) at /usr/src/sys/kern/kern_linker.c:633 #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, fileid=Variable "fileid" is not available. ) at /usr/src/sys/kern/kern_linker.c:1092 Let me know if there's anything else I can test. Thanks, Gavin From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 9 21:11:34 2009 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 EED391065679; Mon, 9 Nov 2009 21:11:34 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDC18FC08; Mon, 9 Nov 2009 21:11:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,711,1249250400"; d="txt'?scan'208";a="18054944" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 09 Nov 2009 22:11:32 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id C381C1B0751; Mon, 9 Nov 2009 22:11:32 +0100 (CET) Date: Mon, 09 Nov 2009 22:11:25 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: In-Reply-To: <86aayvfmaa.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200911092111251e86ffa80000575d-a_best01+ Cc: freebsd-hackers@FreeBSD.org, Giorgos Keramidas Subject: Re: [patch] burncd: honour for envar SPEED 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, 09 Nov 2009 21:11:35 -0000 This is a MIME encoded multipart message. --+permail-200911092111251e86ffa80000575d-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=F8rgrav schrieb am 2009-11-09: > Alexander Best writes: > > + if ((env_speed =3D getenv("BURNCD_SPEED")) !=3D NULL) { > > + if (strcasecmp("max", env_speed) =3D=3D 0) > > + speed =3D CDR_MAX_SPEED; > > + else > > + speed =3D atoi(env_speed) * 177; > > + if (speed <=3D 0) > > + errx(EX_USAGE, "Invalid speed: %s", > > env_speed); > > + } > > + > > while ((ch =3D getopt(argc, argv, "def:Flmnpqs:tv")) !=3D -1) { > > switch (ch) { > > case 'd': > You realize you're duplicating 6 lines of non-trivial code for no > good > reason? > env_speed =3D getenv("BURNCD_SPEED"); > while ((ch =3D getopt(...)) !=3D -1) { > switch (ch) { > case 's': > env_speed =3D optarg; > break; > ... > } > } > if (env_speed !=3D NULL) { > if (strcasecmp...) { > ... > } > } > DES good point. is this one better? alex --+permail-200911092111251e86ffa80000575d-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLjgJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuOAkod29ya2luZyBjb3B5KQpAQCAtMjcsNyArMjcsNyBAQAogLlwiCiAuXCIgJEZyZWVCU0Qk CiAuXCIKLS5EZCBNYXkgMiwgMjAwNQorLkRkIE5vdiA5LCAyMDA5CiAuT3MKIC5EdCBCVVJOQ0Qg OAogLlNoIE5BTUUKQEAgLTE1OCw3ICsxNTgsMTEgQEAKIC5TaCBFTlZJUk9OTUVOVAogVGhlIGZv bGxvd2luZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgYWZmZWN0IHRoZSBleGVjdXRpb24gb2YKIC5O bSA6Ci0uQmwgLXRhZyAtd2lkdGggIi5FdiBDRFJPTSIKKy5CbCAtdGFnIC13aWR0aCAiLkV2IEJV Uk5DRF9TUEVFRCIKKy5JdCBFdiBCVVJOQ0RfU1BFRUQKK1RoZSB3cml0ZSBzcGVlZCB0byB1c2Ug aWYgb25lIGlzIG5vdCBzcGVjaWZpZWQgd2l0aCB0aGUKKy5GbCBzCitmbGFnLgogLkl0IEV2IENE Uk9NCiBUaGUgQ0QgZGV2aWNlIHRvIHVzZSBpZiBvbmUgaXMgbm90IHNwZWNpZmllZCB3aXRoIHRo ZQogLkZsIGYKSW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1 c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJKHJldmlzaW9uIDE5OTA2NCkKKysrIHVzci5zYmluL2J1 cm5jZC9idXJuY2QuYwkod29ya2luZyBjb3B5KQpAQCAtODAsMTEgKzgwLDEzIEBACiAJaW50IGRh byA9IDAsIGVqZWN0ID0gMCwgZml4YXRlID0gMCwgbGlzdCA9IDAsIG11bHRpID0gMCwgcHJlZW1w ID0gMDsKIAlpbnQgbm9nYXAgPSAwLCBzcGVlZCA9IDQgKiAxNzcsIHRlc3Rfd3JpdGUgPSAwLCBm b3JjZSA9IDA7CiAJaW50IGJsb2NrX3NpemUgPSAwLCBibG9ja190eXBlID0gMCwgY2RvcGVuID0g MCwgZHZkcncgPSAwOwotCWNvbnN0IGNoYXIgKmRldjsKKwljb25zdCBjaGFyICpkZXYsICplbnZf c3BlZWQ7CiAKIAlpZiAoKGRldiA9IGdldGVudigiQ0RST00iKSkgPT0gTlVMTCkKIAkJZGV2ID0g Ii9kZXYvYWNkMCI7CiAKKwllbnZfc3BlZWQgPSBnZXRlbnYoIkJVUk5DRF9TUEVFRCIpOworCiAJ d2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiZGVmOkZsbW5wcXM6dHYiKSkgIT0gLTEp IHsKIAkJc3dpdGNoIChjaCkgewogCQljYXNlICdkJzoKQEAgLTEyNCwxMiArMTI2LDcgQEAKIAkJ CWJyZWFrOwogCiAJCWNhc2UgJ3MnOgotCQkJaWYgKHN0cmNhc2VjbXAoIm1heCIsIG9wdGFyZykg PT0gMCkKLQkJCQlzcGVlZCA9IENEUl9NQVhfU1BFRUQ7Ci0JCQllbHNlCi0JCQkJc3BlZWQgPSBh dG9pKG9wdGFyZykgKiAxNzc7Ci0JCQlpZiAoc3BlZWQgPD0gMCkKLQkJCQllcnJ4KEVYX1VTQUdF LCAiSW52YWxpZCBzcGVlZDogJXMiLCBvcHRhcmcpOworCQkJZW52X3NwZWVkID0gb3B0YXJnOwog CQkJYnJlYWs7CiAKIAkJY2FzZSAndCc6CkBAIC0xNDcsNiArMTQ0LDEzIEBACiAJYXJnYyAtPSBv cHRpbmQ7CiAJYXJndiArPSBvcHRpbmQ7CiAKKwlpZiAoc3RyY2FzZWNtcCgibWF4IiwgZW52X3Nw ZWVkKSA9PSAwKQorCQkgc3BlZWQgPSBDRFJfTUFYX1NQRUVEOworCWVsc2UKKwkJc3BlZWQgPSBh dG9pKGVudl9zcGVlZCkgKiAxNzc7CisJaWYgKHNwZWVkIDw9IDApCisJCWVycngoRVhfVVNBR0Us ICJJbnZhbGlkIHNwZWVkOiAlcyIsIG9wdGFyZyk7CisJCQogCWlmIChhcmdjID09IDApCiAJCXVz YWdlKCk7CiAK --+permail-200911092111251e86ffa80000575d-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 08:00:31 2009 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 4020D106566B; Tue, 10 Nov 2009 08:00:31 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 023558FC0A; Tue, 10 Nov 2009 08:00:30 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8DDC46D41B; Tue, 10 Nov 2009 08:00:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 60AB684531; Tue, 10 Nov 2009 09:00:29 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: Date: Tue, 10 Nov 2009 09:00:29 +0100 In-Reply-To: (Alexander Best's message of "Mon, 09 Nov 2009 22:11:25 +0100 (CET)") Message-ID: <863a4mg676.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Giorgos Keramidas Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 08:00:31 -0000 Alexander Best writes: > good point. is this one better? Yes (modulo indentation - run your code through tabify) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 11:54:13 2009 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 0A91A106566B; Tue, 10 Nov 2009 11:54:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9443A8FC22; Tue, 10 Nov 2009 11:54:11 +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 NAA11835; Tue, 10 Nov 2009 13:54:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AF95461.2030700@icyb.net.ua> Date: Tue, 10 Nov 2009 13:54:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> In-Reply-To: <20091109195045.Q13027@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing 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, 10 Nov 2009 11:54:13 -0000 on 09/11/2009 22:34 Gavin Atkinson said the following: > On Wed, 14 Oct 2009, Andriy Gapon wrote: >> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: >> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 >> >> I actually got around to implementing it (in initial/basic form): >> http://people.freebsd.org/~avg/heci.tgz > > Nice! > > I've got the following device in my laptop: > > heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Management Engine Interface (Mobile 4 Series > Chipset)' > class = simple comms > > I've added this device to the code, and loaded it: > > heci0: mem > 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0 I will add this ID and name to the driver. > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x02: > heci0: status = 0x00 > heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7 > heci0: found ME client at address 0x06: > heci0: status = 0x00 > heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06 > heci0: found ME client at address 0x22: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7 > heci0: found ME client at address 0x23: > heci0: status = 0x00 > heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C > heci0: found ME client at address 0x24: > heci0: status = 0x00 > heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB Thanks a lot for testing! > However, running the heci-qst.c program you supplied: > > psi# ./heci-qst > ioctl HECI_CONNECT: No such file or directory > > And output to the console: > > heci0: could not find ME client with given guid: > 6B5205B9-8185-4519-B889-D98724B58607 > > Other than seeing that it doesn't appear in the list above, I don't know > if this is expected or not... Yes, this is expected if you don't have ME client with this GUID. Perhaps, there is no QST firmware in the ME or it is disabled. Also, I am not sure but I think that it could be possible that you have a newer version of QST and its GUID is different. If you feel adventurous, you could try substituting GUID value in heci-qst.c with values reported by the driver. Perhaps it would work, perhaps you'd get a crash or hang or just an ioctl error. > Secondly, I get a panic on module unlaod. I haven't spent any time > looking at this, if you haven't fixed it yet let me know and I'll look > into it further. To my shame I still haven't got around to testing the driver with head tree and diagnostics enabled. I do not see any problems on stable/7 without diagnostics. Robert Noland has reported that he had a lockup on module unload with head sources. I will investigate this. BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if debugger reports it correctly). This looks like the memory was already freed. > I'm not even sure how it's getting that far into the detach routine > before panicing, if dev really does = 0xdeadc0dedeadc0de > > #8 0xffffffff808580d3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) > at /usr/src/sys/kern/kern_mutex.c:827 > #10 0xffffffff812221c6 in heci_detach () > from /usr/src/sys/modules/heci/heci.ko > #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) > at device_if.h:212 > #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, > what=Variable "what" is not available. > ) at /usr/src/sys/kern/subr_bus.c:1156 > #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) > at /usr/src/sys/kern/kern_module.c:266 > #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, > flags=0) at /usr/src/sys/kern/kern_linker.c:633 > #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, > fileid=Variable "fileid" is not available. > ) at /usr/src/sys/kern/kern_linker.c:1092 > > Let me know if there's anything else I can test. > > Thanks, Nothing else I can think of right now. Thanks again! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 15:50:16 2009 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 D6DB01065696; Tue, 10 Nov 2009 15:50:16 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay1.uni-muenster.de (ZIVM-EXRELAY1.UNI-MUENSTER.DE [128.176.192.14]) by mx1.freebsd.org (Postfix) with ESMTP id 342348FC22; Tue, 10 Nov 2009 15:50:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,716,1249250400"; d="txt'?scan'208";a="287923233" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 10 Nov 2009 16:50:14 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 70DF91B0751; Tue, 10 Nov 2009 16:50:14 +0100 (CET) Date: Tue, 10 Nov 2009 16:50:07 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: In-Reply-To: <863a4mg676.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-200911101550071e86ffa800005ac8-a_best01+ Cc: freebsd-hackers@FreeBSD.org, Giorgos Keramidas Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 15:50:17 -0000 This is a MIME encoded multipart message. --+permail-200911101550071e86ffa800005ac8-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=F8rgrav schrieb am 2009-11-10: > Alexander Best writes: > > good point. is this one better? > Yes (modulo indentation - run your code through tabify) > DES oops. found another problem. if BURNCD_SPEED and -s aren't defined strcasec= mp segfaults because env_speed is NULL. does this patch take care of the problem? alex ps: would be nice if strcasecmp could protect itself from segfault with one= or both of the args being NULL. --+permail-200911101550071e86ffa800005ac8-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="burncdspeedpatch.txt" SW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuOAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9i dXJuY2QvYnVybmNkLjgJKHJldmlzaW9uIDE5OTEyNSkKKysrIHVzci5zYmluL2J1cm5jZC9idXJu Y2QuOAkod29ya2luZyBjb3B5KQpAQCAtMjcsNyArMjcsNyBAQAogLlwiCiAuXCIgJEZyZWVCU0Qk CiAuXCIKLS5EZCBNYXkgMiwgMjAwNQorLkRkIE5vdiA5LCAyMDA5CiAuT3MKIC5EdCBCVVJOQ0Qg OAogLlNoIE5BTUUKQEAgLTE1OCw3ICsxNTgsMTEgQEAKIC5TaCBFTlZJUk9OTUVOVAogVGhlIGZv bGxvd2luZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgYWZmZWN0IHRoZSBleGVjdXRpb24gb2YKIC5O bSA6Ci0uQmwgLXRhZyAtd2lkdGggIi5FdiBDRFJPTSIKKy5CbCAtdGFnIC13aWR0aCAiLkV2IEJV Uk5DRF9TUEVFRCIKKy5JdCBFdiBCVVJOQ0RfU1BFRUQKK1RoZSB3cml0ZSBzcGVlZCB0byB1c2Ug aWYgb25lIGlzIG5vdCBzcGVjaWZpZWQgd2l0aCB0aGUKKy5GbCBzCitmbGFnLgogLkl0IEV2IENE Uk9NCiBUaGUgQ0QgZGV2aWNlIHRvIHVzZSBpZiBvbmUgaXMgbm90IHNwZWNpZmllZCB3aXRoIHRo ZQogLkZsIGYKSW5kZXg6IHVzci5zYmluL2J1cm5jZC9idXJuY2QuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1 c3Iuc2Jpbi9idXJuY2QvYnVybmNkLmMJKHJldmlzaW9uIDE5OTEyNSkKKysrIHVzci5zYmluL2J1 cm5jZC9idXJuY2QuYwkod29ya2luZyBjb3B5KQpAQCAtODAsMTEgKzgwLDEzIEBACiAJaW50IGRh byA9IDAsIGVqZWN0ID0gMCwgZml4YXRlID0gMCwgbGlzdCA9IDAsIG11bHRpID0gMCwgcHJlZW1w ID0gMDsKIAlpbnQgbm9nYXAgPSAwLCBzcGVlZCA9IDQgKiAxNzcsIHRlc3Rfd3JpdGUgPSAwLCBm b3JjZSA9IDA7CiAJaW50IGJsb2NrX3NpemUgPSAwLCBibG9ja190eXBlID0gMCwgY2RvcGVuID0g MCwgZHZkcncgPSAwOwotCWNvbnN0IGNoYXIgKmRldjsKKwljb25zdCBjaGFyICpkZXYsICplbnZf c3BlZWQ7CiAKIAlpZiAoKGRldiA9IGdldGVudigiQ0RST00iKSkgPT0gTlVMTCkKIAkJZGV2ID0g Ii9kZXYvYWNkMCI7CiAKKwllbnZfc3BlZWQgPSBnZXRlbnYoIkJVUk5DRF9TUEVFRCIpOworCiAJ d2hpbGUgKChjaCA9IGdldG9wdChhcmdjLCBhcmd2LCAiZGVmOkZsbW5wcXM6dHYiKSkgIT0gLTEp IHsKIAkJc3dpdGNoIChjaCkgewogCQljYXNlICdkJzoKQEAgLTEyNCwxMiArMTI2LDcgQEAKIAkJ CWJyZWFrOwogCiAJCWNhc2UgJ3MnOgotCQkJaWYgKHN0cmNhc2VjbXAoIm1heCIsIG9wdGFyZykg PT0gMCkKLQkJCQlzcGVlZCA9IENEUl9NQVhfU1BFRUQ7Ci0JCQllbHNlCi0JCQkJc3BlZWQgPSBh dG9pKG9wdGFyZykgKiAxNzc7Ci0JCQlpZiAoc3BlZWQgPD0gMCkKLQkJCQllcnJ4KEVYX1VTQUdF LCAiSW52YWxpZCBzcGVlZDogJXMiLCBvcHRhcmcpOworCQkJZW52X3NwZWVkID0gb3B0YXJnOwog CQkJYnJlYWs7CiAKIAkJY2FzZSAndCc6CkBAIC0xNDcsNiArMTQ0LDE1IEBACiAJYXJnYyAtPSBv cHRpbmQ7CiAJYXJndiArPSBvcHRpbmQ7CiAKKwlpZiAoZW52X3NwZWVkID09IE5VTEwpCisJCTsK KwllbHNlIGlmIChzdHJjYXNlY21wKCJtYXgiLCBlbnZfc3BlZWQpID09IDApCisJCXNwZWVkID0g Q0RSX01BWF9TUEVFRDsKKwllbHNlCisJCXNwZWVkID0gYXRvaShlbnZfc3BlZWQpICogMTc3Owor CWlmIChzcGVlZCA8PSAwKQorCQllcnJ4KEVYX1VTQUdFLCAiSW52YWxpZCBzcGVlZDogJXMiLCBv cHRhcmcpOworCiAJaWYgKGFyZ2MgPT0gMCkKIAkJdXNhZ2UoKTsKIAo= --+permail-200911101550071e86ffa800005ac8-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 16:03:27 2009 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 E4FB91065692 for ; Tue, 10 Nov 2009 16:03:27 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id C10D68FC15 for ; Tue, 10 Nov 2009 16:03:27 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nAAG3Ro05498; Tue, 10 Nov 2009 08:03:27 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nAAG3R122152; Tue, 10 Nov 2009 08:03:27 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Tue, 10 Nov 2009 08:03:26 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Alexander Best In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Giorgos Keramidas , freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 16:03:28 -0000 On Tue, 10 Nov 2009, Alexander Best wrote: > ps: would be nice if strcasecmp could protect itself from segfault with one or > both of the args being NULL. I disagree. What do you think it should do instead? Return 0? If it did, would you have found your bug? The same argument could be made for any of the string.h functions, but I don't think it actually holds water. Such checks add overhead, and only provide an illusion of safety. Sure, strcasecmp could avoid causing the segfault itself, but at the cost of letting a broken program continue and possibly cause more damage. It could call abort(), but then you'd just have the same result (program terminates) with a different signal, and doing your check in software rather than letting the MMU hardware do it. It could print a message, but that pollutes the program's output, and 15 seconds debugging the core dump will reveal the problem anyway. Having a library function "protect itself" in this manner is not actually helpful, IMHO. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 16:17:41 2009 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 2B7BB1065676; Tue, 10 Nov 2009 16:17:41 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 807958FC08; Tue, 10 Nov 2009 16:17:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,717,1249250400"; d="scan'208";a="18138248" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 10 Nov 2009 17:17:38 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id E88C81B0751; Tue, 10 Nov 2009 17:17:38 +0100 (CET) Date: Tue, 10 Nov 2009 17:17:38 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Nate Eldredge Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Giorgos Keramidas , freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 16:17:41 -0000 Nate Eldredge schrieb am 2009-11-10: > On Tue, 10 Nov 2009, Alexander Best wrote: > >ps: would be nice if strcasecmp could protect itself from segfault > >with one or > >both of the args being NULL. > I disagree. What do you think it should do instead? Return 0? If > it did, would you have found your bug? > The same argument could be made for any of the string.h functions, > but I don't think it actually holds water. Such checks add > overhead, and only provide an illusion of safety. Sure, strcasecmp > could avoid causing the segfault itself, but at the cost of letting > a broken program continue and possibly cause more damage. It could > call abort(), but then you'd just have the same result (program > terminates) with a different signal, and doing your check in > software rather than letting the MMU hardware do it. It could print > a message, but that pollutes the program's output, and 15 seconds > debugging the core dump will reveal the problem anyway. > Having a library function "protect itself" in this manner is not > actually helpful, IMHO. > -- > Nate Eldredge > nate@thatsmathematics.com you're right. hundreds of functions cause segfaults when arg or args are NULL. either we add safety checks for all of them (massive overhead) or just leave them the way they are. also: these functions aren't being used by regular users, but developers and it's hard finding a developer who isn't experienced with dealing with NULL pointers. ;) so problems with NULL pointers are usually fixed very quickly. alex From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 16:59:43 2009 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 1E34E106566B; Tue, 10 Nov 2009 16:59:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 70B4F8FC1B; Tue, 10 Nov 2009 16:59:41 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id nAAGxaZv091698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 18:59:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id nAAGxaLM065435; Tue, 10 Nov 2009 18:59:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id nAAGxaC9065434; Tue, 10 Nov 2009 18:59:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Nov 2009 18:59:36 +0200 From: Kostik Belousov To: Nate Eldredge Message-ID: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FyU5fTJCTr/6Eq8v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Alexander Best , Giorgos Keramidas , freebsd-hackers@freebsd.org, Dag-Erling Sm?rgrav Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 16:59:43 -0000 --FyU5fTJCTr/6Eq8v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote: > On Tue, 10 Nov 2009, Alexander Best wrote: >=20 > >ps: would be nice if strcasecmp could protect itself from segfault with= =20 > >one or > >both of the args being NULL. >=20 > I disagree. What do you think it should do instead? Return 0? If it=20 > did, would you have found your bug? >=20 > The same argument could be made for any of the string.h functions, but I= =20 > don't think it actually holds water. Such checks add overhead, and only= =20 > provide an illusion of safety. Sure, strcasecmp could avoid causing the= =20 > segfault itself, but at the cost of letting a broken program continue and= =20 > possibly cause more damage. It could call abort(), but then you'd just= =20 > have the same result (program terminates) with a different signal, and=20 > doing your check in software rather than letting the MMU hardware do it.= =20 > It could print a message, but that pollutes the program's output, and 15= =20 > seconds debugging the core dump will reveal the problem anyway. >=20 > Having a library function "protect itself" in this manner is not actually= =20 > helpful, IMHO. I remember System V to actually map zero page at 0, thus causing all string functions to behave like it was supplied empty string when argument is NULL. I believe Solaris still provides the library that could be LD_PRELOADed for the same effect. --FyU5fTJCTr/6Eq8v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkr5m/cACgkQC3+MBN1Mb4jYmgCg5jHeHRzSzO+PvtkNvOxyjYzT od4An0/l2yjXKYZdvKtAiIaIeUvi0xlt =u16l -----END PGP SIGNATURE----- --FyU5fTJCTr/6Eq8v-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 17:12:51 2009 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 D37E71065670; Tue, 10 Nov 2009 17:12:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 74D608FC0C; Tue, 10 Nov 2009 17:12:49 +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 TAA19720; Tue, 10 Nov 2009 19:12:48 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AF99F10.8020703@icyb.net.ua> Date: Tue, 10 Nov 2009 19:12:48 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> In-Reply-To: <4AF95461.2030700@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org, Robert Noland Subject: Re: heci: a new driver for review and testing 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, 10 Nov 2009 17:12:51 -0000 on 10/11/2009 13:54 Andriy Gapon said the following: > on 09/11/2009 22:34 Gavin Atkinson said the following: >> Secondly, I get a panic on module unlaod. I haven't spent any time >> looking at this, if you haven't fixed it yet let me know and I'll look >> into it further. > > To my shame I still haven't got around to testing the driver with head tree and > diagnostics enabled. I do not see any problems on stable/7 without diagnostics. > Robert Noland has reported that he had a lockup on module unload with head > sources. I will investigate this. > BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if > debugger reports it correctly). This looks like the memory was already freed. I think I've found one bug in the heci code that could cause this - SLIST element was first freed and then removed from the list. I've uploaded updated sources (that should include your PCI ID too), could you please re-test? >> I'm not even sure how it's getting that far into the detach routine >> before panicing, if dev really does = 0xdeadc0dedeadc0de >> >> #8 0xffffffff808580d3 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:224 >> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e) >> at /usr/src/sys/kern/kern_mutex.c:827 >> #10 0xffffffff812221c6 in heci_detach () >> from /usr/src/sys/modules/heci/heci.ko >> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de) >> at device_if.h:212 >> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800, >> what=Variable "what" is not available. >> ) at /usr/src/sys/kern/subr_bus.c:1156 >> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800) >> at /usr/src/sys/kern/kern_module.c:266 >> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200, >> flags=0) at /usr/src/sys/kern/kern_linker.c:633 >> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380, >> fileid=Variable "fileid" is not available. >> ) at /usr/src/sys/kern/kern_linker.c:1092 >> >> Let me know if there's anything else I can test. >> >> Thanks, > > Nothing else I can think of right now. OK, I came up with something :) Could you please send me verbose version of driver attachment messages (debug.bootverbose=1)? Thank you! BTW, Robert, you also promised me those :) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 17:24:34 2009 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 78A051065694 for ; Tue, 10 Nov 2009 17:24:34 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B66C8FC12 for ; Tue, 10 Nov 2009 17:24:33 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 09:12:30 -0800 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E0338FCC2@seaxch09.desktop.isilon.com> In-Reply-To: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [patch] burncd: honour for envar SPEED Thread-Index: AcpiJ1uWRDDQopBKSxK/tWFmRb32wgAAI49A References: <20091110165936.GC2331@deviant.kiev.zoral.com.ua> From: "Matthew Fleming" To: Subject: RE: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 17:24:34 -0000 > On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote: > > On Tue, 10 Nov 2009, Alexander Best wrote: > > > > >ps: would be nice if strcasecmp could protect itself from segfault > > >with one or both of the args being NULL. > > > > I disagree. What do you think it should do instead? Return 0? If it > > did, would you have found your bug? > > > > [snip] >=20 > I remember System V to actually map zero page at 0, thus causing all > string functions to behave like it was supplied empty string when argument > is NULL. I believe Solaris still provides the library that could be > LD_PRELOADed for the same effect. Just an anecdote: My sophomore year of undergrad (1994), I was learning C for the first time. We had to write some little thing, and on the machines in the lab my C program ran great; I had debugged it (I thought) and turned it in. The instructor took my source, compiled it on Linux, and it segfaulted when run (I think trying to print a NULL string). If HP-UX hadn't been trying to be "friendly" I would have been able to fully debug my code. I am sure that if I'd known then what I know now I could have made it bug free. But my experience is that a lot of code is, by necessity, written by people who aren't experts in everything they're doing. So an early segfault would have helped me in that C programming class. OTOH, if instead it had been an application someone paid money for, and it segfaulted in an untested error case instead of being graceful, I'd be mad too. Probably at the app writer, but still... Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 18:42:33 2009 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 F1C111065672; Tue, 10 Nov 2009 18:42:33 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 782FC8FC24; Tue, 10 Nov 2009 18:42:33 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id nAAIgR3l015505; Tue, 10 Nov 2009 18:42:27 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1N7vfe-0001gy-V6; Tue, 10 Nov 2009 18:42:26 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id nAAIgQSQ066589; Tue, 10 Nov 2009 18:42:26 GMT (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id nAAIgQev066586; Tue, 10 Nov 2009 18:42:26 GMT (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 10 Nov 2009 18:42:26 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Andriy Gapon In-Reply-To: <4AF99F10.8020703@icyb.net.ua> Message-ID: <20091110184016.S61601@ury.york.ac.uk> References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing 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, 10 Nov 2009 18:42:34 -0000 On Tue, 10 Nov 2009, Andriy Gapon wrote: > on 10/11/2009 13:54 Andriy Gapon said the following: >> on 09/11/2009 22:34 Gavin Atkinson said the following: >>> Secondly, I get a panic on module unlaod. I haven't spent any time >>> looking at this, if you haven't fixed it yet let me know and I'll look >>> into it further. >> >> To my shame I still haven't got around to testing the driver with head tree and >> diagnostics enabled. I do not see any problems on stable/7 without diagnostics. >> Robert Noland has reported that he had a lockup on module unload with head >> sources. I will investigate this. >> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if >> debugger reports it correctly). This looks like the memory was already freed. > > I think I've found one bug in the heci code that could cause this - SLIST element > was first freed and then removed from the list. > I've uploaded updated sources (that should include your PCI ID too), could you > please re-test? That seems to have fixed it, thanks! It also fixes the malloc() calls with locks held. > Could you please send me verbose version of driver attachment messages > (debug.bootverbose=1)? > Thank you! Sure! http://people.freebsd.org/~gavin/heci-verbose.txt Gavin From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 20:13:45 2009 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 C3CAF106566C; Tue, 10 Nov 2009 20:13:45 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 81CA88FC0C; Tue, 10 Nov 2009 20:13:44 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D41446D41B; Tue, 10 Nov 2009 20:13:43 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7B800844CC; Tue, 10 Nov 2009 21:13:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Best References: Date: Tue, 10 Nov 2009 21:13:43 +0100 In-Reply-To: (Alexander Best's message of "Tue, 10 Nov 2009 17:17:38 +0100 (CET)") Message-ID: <86y6me2l54.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Giorgos Keramidas , Nate Eldredge Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 20:13:45 -0000 Alexander Best writes: > you're right. hundreds of functions cause segfaults when arg or args > are NULL. either we add safety checks for all of them (massive > overhead) or just leave them the way they are. The consensus in the C community is that adding such checks does more harm than good, because a NULL pointer is usually a symptom of a bug somewhere else in the application, and checking for a NULL pointer will either hide that bug or trigger another error somewhere down the line, possibly making the real bug harder to find, rather than easier. (next week's topic: the return value of malloc(0)...) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 20:24:30 2009 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 3825B106568F for ; Tue, 10 Nov 2009 20:24:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 93CD68FC0C for ; Tue, 10 Nov 2009 20:24:29 +0000 (UTC) Received: by bwz5 with SMTP id 5so447154bwz.3 for ; Tue, 10 Nov 2009 12:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zPcbj3JASpUtajP78zw3wyFAnVn2nlPniK8hmR0vN28=; b=GZtgrUk4AMxaIOkpetWZNot9AuhxyEIXi3v+t2oKCCDZzMvvugI31UpYg4ShRstFzA OEdbmUVhUscyObIoKhV1Atpqktj9Ap5swOj4MsAAEtsRXynsiYhKBJlsolPT7DzJgT0c QkqC/HcgfgWvbHq2RscTV0gWtORhMlkMdzVQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eMs4IF2wqPNq1Heit80L2yb4Ch+KrB2URhtUPzwqC+h8ezBLZksL8f8vIeTQKgdv+8 Gppf/WXLtbXWbqnluhUSvxUrtxN8z6QLkU2YYh/zARb6rR/tWPRMYshCoUcOgUi2VNLw 43Pq/caz80++WjZgtsArTfmSLGCbVDX7s2YAw= MIME-Version: 1.0 Received: by 10.204.25.207 with SMTP id a15mr597868bkc.8.1257884668524; Tue, 10 Nov 2009 12:24:28 -0800 (PST) In-Reply-To: <86y6me2l54.fsf@ds4.des.no> References: <86y6me2l54.fsf@ds4.des.no> Date: Tue, 10 Nov 2009 23:24:28 +0300 Message-ID: From: pluknet To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , Giorgos Keramidas , Nate Eldredge , freebsd-hackers@freebsd.org Subject: Re: [patch] burncd: honour for envar SPEED 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, 10 Nov 2009 20:24:30 -0000 2009/11/10 Dag-Erling Sm=F8rgrav : > Alexander Best writes: >> you're right. hundreds of functions cause segfaults when arg or args >> are NULL. =A0either we add safety checks for all of them (massive >> overhead) or just leave them the way they are. > > The consensus in the C community is that adding such checks does more > harm than good, because a NULL pointer is usually a symptom of a bug > somewhere else in the application, and checking for a NULL pointer will > either hide that bug or trigger another error somewhere down the line, > possibly making the real bug harder to find, rather than easier. > And which is a way some well known OS' developers like to choose to fix sec.holes. No cookie. P.S. I apologize for flaming on this. > (next week's topic: the return value of malloc(0)...) > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 10 21:10:57 2009 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 682B3106568B for ; Tue, 10 Nov 2009 21:10:57 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id F17228FC2A for ; Tue, 10 Nov 2009 21:10:56 +0000 (UTC) Received: by bwz5 with SMTP id 5so491399bwz.3 for ; Tue, 10 Nov 2009 13:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=h43ih3mGm07CIpPF50XR96gZ8m6ofGAPnvzy6fj0cwI=; b=L/lgiXxK/DCTlt71fPKvHRY+NRshu32+u+i3S8aYWMQ8H0AtXI8vTf5cAECRE/gRwa 9jxBkBr9bBsjBaVjvXA5sU+ZJ0RNjLPCevzdWSemZA8OR2i7J0eL9B6/aU2rcO/5ZPot 2NOQwqsT5mvImAylgmhTWtLRytSipzKiIPh9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cTtzK8mYhlGhoKqq8nJxPWWGqX1agTah4H/QhViEQoXoopGcofwjyOQgsVdhavxBNU fJQ87aByRnwwFCtetzoLr74lyep02/X2zfbTcgn8v37gJTMSQlw61/XafU1hny0qjZX6 Y9B+gGtK2HxdosTUMNV/AT/Jm4rANNcLK3tsA= MIME-Version: 1.0 Received: by 10.204.32.76 with SMTP id b12mr552860bkd.165.1257886006067; Tue, 10 Nov 2009 12:46:46 -0800 (PST) Date: Tue, 10 Nov 2009 21:46:46 +0100 Message-ID: From: David DEMELIER To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 10 Nov 2009 21:59:27 +0000 Subject: Alps GlidePoint driver for synaptics. 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, 10 Nov 2009 21:10:57 -0000 Hello there, I noticed that for the moment there is no support for alps based touchpads, is there anyone working on a driver for -CURRENT ? This is my touchpad : I: Bus=0011 Vendor=0002 Product=0008 Version=7321 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio4/input0 S: Sysfs=/devices/platform/i8042/serio4/input/input6 U: Uniq= H: Handlers=mouse2 event6 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003 Cheers, David. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 11 00:14:07 2009 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 834481065670 for ; Wed, 11 Nov 2009 00:14:07 +0000 (UTC) (envelope-from psteele@maxiscale.com) Received: from server505.appriver.com (server505c.appriver.com [98.129.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0C28FC1E for ; Wed, 11 Nov 2009 00:14:07 +0000 (UTC) X-Policy: GLOBAL - maxiscale.com X-Primary: psteele@maxiscale.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: psteele@maxiscale.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.23.14 X-Note-Reverse-DNS: ht01.exg5.exghost.com X-Note-WHTLIST: psteele@maxiscale.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 112 113 114 115 119 120 131 217 X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.23.14] (HELO ht01.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.2.14) with ESMTPS id 16246017 for freebsd-hackers@freebsd.org; Tue, 10 Nov 2009 17:14:10 -0600 Received: from mbx03.exg5.exghost.com ([169.254.1.164]) by ht01.exg5.exghost.com ([98.129.23.14]) with mapi; Tue, 10 Nov 2009 17:14:05 -0600 From: Peter Steele To: "freebsd-hackers@freebsd.org" Date: Tue, 10 Nov 2009 17:14:02 -0600 Thread-Topic: Converting a bootable USB stick in to bootable CD-ROM Thread-Index: AcpiW321VLM7ZSDpSgCcl8Q5E1Vn6A== Message-ID: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3394F75B@MBX03.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Converting a bootable USB stick in to bootable CD-ROM 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, 11 Nov 2009 00:14:07 -0000 I posted this on the -questions list but didn't get any replies. I have a F= reeBSD image that I install on USB sticks to build new systems. When the st= ick boots it automatically clones itself on the system's hard drive, creati= ng partitions and other configuration parameters that are programmed into t= he stick's cloning logic. I want to create a similar mechanism using a boot= able CD-ROM. The biggest difference in the process of course is that the CD= -ROM itself is read-only so clearly there needs to be an mfsroot involved i= n the process. I looked at how the FreeBSD Live CD is setup and the loader.= conf file has these lines: mfsroot_load=3D"YES" mfsroot_type=3D"mfs_root" mfsroot_name=3D"/boot/mfsroot" along with the file /boot/mfsroot.gz and no /etc/fstab. The fstab on my USB= stick version has root mounted as /etc/da0s1a and clearly that isn't going= to work. I changed my core BSD image accordingly, duplicating the mfsroot = settings in my loader.conf. I used the command below to create the iso file from the BSD image I prepar= ed. mkisofs -R -no-emul-boot -o /tmp/bsd.iso -b boot/cdboot /bsd When this iso is copied to a CD, it does boot. However, it doesn't seem to = be picking up the mfsroot config and complains that the system is running f= rom on a read-only file system, which of course is what I'm trying to avoid= . I assume I simply have the boot config setup wrong. I essentially want the = same kind of thing that's done for BSD Live. Can anyone point me to the rig= ht info for setting up this kind of bootable BSD CD? From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 11 13:17:39 2009 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 D61B6106566C; Wed, 11 Nov 2009 13:17:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AE6F68FC08; Wed, 11 Nov 2009 13:17:38 +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 PAA12149; Wed, 11 Nov 2009 15:17:37 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4AFAB970.6060603@icyb.net.ua> Date: Wed, 11 Nov 2009 15:17:36 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Gavin Atkinson References: <4AD6067E.2010503@icyb.net.ua> <20091109195045.Q13027@ury.york.ac.uk> <4AF95461.2030700@icyb.net.ua> <4AF99F10.8020703@icyb.net.ua> <20091110184016.S61601@ury.york.ac.uk> In-Reply-To: <20091110184016.S61601@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing 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, 11 Nov 2009 13:17:39 -0000 on 10/11/2009 20:42 Gavin Atkinson said the following: > On Tue, 10 Nov 2009, Andriy Gapon wrote: >> on 10/11/2009 13:54 Andriy Gapon said the following: >>> on 09/11/2009 22:34 Gavin Atkinson said the following: >> I think I've found one bug in the heci code that could cause this - >> SLIST element >> was first freed and then removed from the list. >> I've uploaded updated sources (that should include your PCI ID too), >> could you >> please re-test? > > That seems to have fixed it, thanks! It also fixes the malloc() calls > with locks held. > >> Could you please send me verbose version of driver attachment messages >> (debug.bootverbose=1)? >> Thank you! > > Sure! > > http://people.freebsd.org/~gavin/heci-verbose.txt Thank you for the testing and data! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 00:29:11 2009 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 94DB71065676 for ; Fri, 13 Nov 2009 00:29:11 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA9E8FC17 for ; Fri, 13 Nov 2009 00:29:10 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.44,732,1249250400"; d="scan'208";a="18380540" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 13 Nov 2009 01:29:09 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2F7651B0751; Fri, 13 Nov 2009 01:29:09 +0100 (CET) Date: Fri, 13 Nov 2009 01:29:08 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jilles Tjoelker Subject: [patch] add pwait utility 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, 13 Nov 2009 00:29:11 -0000 thanks a lot. great little application. especially the -v switch is very useful to developers who need quick exit signal feedback from a closing/crashing app imo. would be great to see this committed to HEAD soon. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 02:08:36 2009 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 E7E1E1065672 for ; Fri, 13 Nov 2009 02:08:36 +0000 (UTC) (envelope-from sh@visor.slugabed.org) Received: from visor.slugabed.org (visor.slugabed.org [64.69.77.108]) by mx1.freebsd.org (Postfix) with ESMTP id CA4D38FC0A for ; Fri, 13 Nov 2009 02:08:36 +0000 (UTC) Received: from visor.slugabed.org (sh@localhost [127.0.0.1]) by visor.slugabed.org (8.13.8/8.13.8) with ESMTP id nAD28ZUg074628 for ; Thu, 12 Nov 2009 18:08:35 -0800 (PST) (envelope-from sh@visor.slugabed.org) Received: (from sh@localhost) by visor.slugabed.org (8.13.8/8.13.8/Submit) id nAD28ZEV074627 for freebsd-hackers@freebsd.org; Thu, 12 Nov 2009 18:08:35 -0800 (PST) (envelope-from sh) Date: Thu, 12 Nov 2009 18:08:35 -0800 From: Sean Hamilton To: freebsd-hackers@freebsd.org Message-ID: <20091113020835.GE12442@visor.slugabed.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: NUMA support; tweaking TCP for GPRS 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, 13 Nov 2009 02:08:37 -0000 Greetings -hackers, I have two unrelated questions. First, what is the status of NUMA support in FreeBSD? Is there a performance penalty on Nehalem-class systems, compared with Linux, which advertises NUMA awareness? Google seems to turn up very little on this subject. Second, I am using a FreeBSD server to talk to equipment which has a GPRS internet connection. This is fairly high latency (approximately one second RTT) and is prone to bursts of packet loss, or bursts of extremely high latency -- perhaps up to a minute. These intervals cause many retransmissions, which I presume is a good strategy over the internet, but not so good for GPRS. For my application, latency is mostly irrelevant. However, data over GPRS is very expensive, so I would like to reduce as much as possible the number of TCP retransmissions made on the FreeBSD side, possibly at the expense of latency. So, I am looking for suggestions on how to achieve this, via sysctl, setsockopt, etc. There seems to be a lot of literature regarding TCP tuning, but usually the focus is on improving performance, not reducing network traffic. The "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) seem interesting, but it's not clear to me exactly how they might be adjusted for this purpose. Thanks in advance, -- Sean Hamilton From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 10:16:59 2009 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 377FC106566B for ; Fri, 13 Nov 2009 10:16:59 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout7.freenet.de (mout7.freenet.de [IPv6:2001:748:100:40::2:9]) by mx1.freebsd.org (Postfix) with ESMTP id C9B4C8FC19 for ; Fri, 13 Nov 2009 10:16:58 +0000 (UTC) Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout7.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1N8tD7-00030P-E3; Fri, 13 Nov 2009 11:16:57 +0100 Received: from tf43c.t.pppool.de ([89.55.244.60]:38694 helo=ernst.jennejohn.org) by 1.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1N8tD7-0004P0-67; Fri, 13 Nov 2009 11:16:57 +0100 Date: Fri, 13 Nov 2009 11:16:56 +0100 From: Gary Jennejohn To: Sean Hamilton Message-ID: <20091113111656.5dd3beaa@ernst.jennejohn.org> In-Reply-To: <20091113020835.GE12442@visor.slugabed.org> References: <20091113020835.GE12442@visor.slugabed.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: NUMA support; tweaking TCP for GPRS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 10:16:59 -0000 On Thu, 12 Nov 2009 18:08:35 -0800 Sean Hamilton wrote: > Second, I am using a FreeBSD server to talk to equipment > which has a GPRS internet connection. This is fairly high > latency (approximately one second RTT) and is prone to > bursts of packet loss, or bursts of extremely high latency > -- perhaps up to a minute. These intervals cause many > retransmissions, which I presume is a good strategy over the > internet, but not so good for GPRS. > > For my application, latency is mostly irrelevant. However, > data over GPRS is very expensive, so I would like to reduce > as much as possible the number of TCP retransmissions made > on the FreeBSD side, possibly at the expense of latency. > > So, I am looking for suggestions on how to achieve this, via > sysctl, setsockopt, etc. There seems to be a lot of > literature regarding TCP tuning, but usually the focus is on > improving performance, not reducing network traffic. The > "rexmit_min" and "rexmit_sop" sysctls mentioned in tcp(4) > seem interesting, but it's not clear to me exactly how they > might be adjusted for this purpose. > > Thanks in advance, > Highjacking this thread. This won't help you, but it would be interesting to have the new Delay Tolerant Networking protocol developed by Vint Cerf for NASA in FreeBSD. Supposedly it's already in Android. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 05:39:15 2009 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 CD1B51065670 for ; Fri, 13 Nov 2009 05:39:15 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170]) by mx1.freebsd.org (Postfix) with ESMTP id 533888FC08 for ; Fri, 13 Nov 2009 05:39:14 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.3/8.14.3) with ESMTP id nAD5In3g036054; Fri, 13 Nov 2009 00:18:49 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.3/8.14.3/Submit) id nAD5In2e036051; Fri, 13 Nov 2009 00:18:49 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AykRJN6Qt4" Content-Transfer-Encoding: 7bit Message-ID: <19196.60473.337121.565916@hergotha.csail.mit.edu> Date: Fri, 13 Nov 2009 00:18:49 -0500 From: Garrett Wollman To: current@freebsd.org, hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 21) "Educational Television" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 13 Nov 2009 00:18:49 -0500 (EST) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hergotha.csail.mit.edu X-Mailman-Approved-At: Fri, 13 Nov 2009 12:18:14 +0000 Cc: Subject: CFR: Exceedingly minor fixes to libc 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, 13 Nov 2009 05:39:16 -0000 --AykRJN6Qt4 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit If you have a moment, please take a look at the following patch. It contains some very minor fixes to various parts of libc which were found by the clang static analyzer. They fall into a few categories: 1) Bug fixes in very rare situations (mostly error-handling code that has probably never been executed). 2) Dead store elimination. 3) Elimination of unused variables. (Or in a few cases, making use of them.) Some minor style problems were also fixed in the vicinity. There should be no functional changes except in very unusual conditions. -GAWollman --AykRJN6Qt4 Content-Type: text/plain Content-Description: patch for libc Content-Disposition: inline; filename="libc.diff.head" Content-Transfer-Encoding: 7bit Index: stdio/fvwrite.c =================================================================== --- stdio/fvwrite.c (revision 199242) +++ stdio/fvwrite.c (working copy) @@ -60,7 +60,7 @@ char *nl; int nlknown, nldist; - if ((len = uio->uio_resid) == 0) + if (uio->uio_resid == 0) return (0); /* make sure we can write */ if (prepwrite(fp) != 0) Index: stdio/vfwprintf.c =================================================================== --- stdio/vfwprintf.c (revision 199242) +++ stdio/vfwprintf.c (working copy) @@ -293,7 +293,7 @@ * number of characters to print. */ p = mbsarg; - insize = nchars = 0; + insize = nchars = nconv = 0; mbs = initial_mbs; while (nchars != (size_t)prec) { nconv = mbrlen(p, MB_CUR_MAX, &mbs); Index: stdio/xprintf_time.c =================================================================== --- stdio/xprintf_time.c (revision 199242) +++ stdio/xprintf_time.c (working copy) @@ -64,7 +64,6 @@ intmax_t t, tx; int i, prec, nsec; - prec = 0; if (pi->is_long) { tv = *((struct timeval **)arg[0]); t = tv->tv_sec; @@ -78,6 +77,8 @@ } else { tp = *((time_t **)arg[0]); t = *tp; + nsec = 0; + prec = 0; } p = buf; Index: stdio/fgetws.c =================================================================== --- stdio/fgetws.c (revision 199242) +++ stdio/fgetws.c (working copy) @@ -89,7 +89,7 @@ if (!__mbsinit(&fp->_mbstate)) /* Incomplete character */ goto error; - *wsp++ = L'\0'; + *wsp = L'\0'; FUNLOCKFILE(fp); return (ws); Index: rpc/getnetconfig.c =================================================================== --- rpc/getnetconfig.c (revision 199242) +++ rpc/getnetconfig.c (working copy) @@ -412,13 +412,13 @@ * Noone needs these entries anymore, then frees them. * Make sure all info in netconfig_info structure has been reinitialized. */ - q = p = ni.head; + q = ni.head; ni.eof = ni.ref = 0; ni.head = NULL; ni.tail = NULL; mutex_unlock(&ni_lock); - while (q) { + while (q != NULL) { p = q->next; if (q->ncp->nc_lookups != NULL) free(q->ncp->nc_lookups); free(q->ncp); Index: rpc/svc_raw.c =================================================================== --- rpc/svc_raw.c (revision 199242) +++ rpc/svc_raw.c (working copy) @@ -176,9 +176,8 @@ msg->acpted_rply.ar_results.proc = (xdrproc_t) xdr_void; msg->acpted_rply.ar_results.where = NULL; - if (!xdr_replymsg(xdrs, msg) || - !SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where)) - stat = FALSE; + stat = xdr_replymsg(xdrs, msg) && + SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where); } else { stat = xdr_replymsg(xdrs, msg); } Index: rpc/clnt_raw.c =================================================================== --- rpc/clnt_raw.c (revision 199242) +++ rpc/clnt_raw.c (working copy) @@ -92,13 +92,13 @@ rpcprog_t prog; rpcvers_t vers; { - struct clntraw_private *clp = clntraw_private; + struct clntraw_private *clp; struct rpc_msg call_msg; - XDR *xdrs = &clp->xdr_stream; - CLIENT *client = &clp->client_object; + XDR *xdrs; + CLIENT *client; mutex_lock(&clntraw_lock); - if (clp == NULL) { + if ((clp = clntraw_private) == NULL) { clp = (struct clntraw_private *)calloc(1, sizeof (*clp)); if (clp == NULL) { mutex_unlock(&clntraw_lock); @@ -110,6 +110,9 @@ clp->_raw_buf = __rpc_rawcombuf; clntraw_private = clp; } + xdrs = &clp->xdr_stream; + client = &clp->client_object; + /* * pre-serialize the static part of the call msg and stash it away */ Index: rpc/svc_vc.c =================================================================== --- rpc/svc_vc.c (revision 199242) +++ rpc/svc_vc.c (working copy) @@ -141,7 +141,7 @@ r = mem_alloc(sizeof(*r)); if (r == NULL) { warnx("svc_vc_create: out of memory"); - goto cleanup_svc_vc_create; + return NULL; } r->sendsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)sendsize); r->recvsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)recvsize); Index: rpc/getrpcent.c =================================================================== --- rpc/getrpcent.c (revision 199242) +++ rpc/getrpcent.c (working copy) @@ -698,7 +698,7 @@ return (NS_RETURN); } - memcpy(&new_rpc, rpc, sizeof(struct rpcent)); + new_rpc = *rpc; *buffer_size = desired_size; memset(buffer, 0, desired_size); Index: rpc/rpcb_st_xdr.c =================================================================== --- rpc/rpcb_st_xdr.c (revision 199242) +++ rpc/rpcb_st_xdr.c (working copy) @@ -89,7 +89,6 @@ rpcbs_rmtcalllist *objp; { int32_t *buf; - struct rpcbs_rmtcalllist **pnext; if (xdrs->x_op == XDR_ENCODE) { buf = XDR_INLINE(xdrs, 6 * BYTES_PER_XDR_UNIT); @@ -123,8 +122,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - pnext = &objp->next; - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -162,7 +160,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -190,7 +188,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); Index: rpc/key_call.c =================================================================== --- rpc/key_call.c (revision 199242) +++ rpc/key_call.c (working copy) @@ -302,7 +302,7 @@ void *localhandle; struct netconfig *nconf; struct netconfig *tpconf; - struct key_call_private *kcp = key_call_private_main; + struct key_call_private *kcp; struct timeval wait_time; struct utsname u; int main_thread; Index: yp/yplib.c =================================================================== --- yp/yplib.c (revision 199242) +++ yp/yplib.c (working copy) @@ -241,7 +241,7 @@ ypmatch_cache_lookup(struct dom_binding *ypdb, char *map, keydat *key, valdat *val) { - struct ypmatch_ent *c = ypdb->cache; + struct ypmatch_ent *c; ypmatch_cache_expire(ypdb); Index: gen/setmode.c =================================================================== --- gen/setmode.c (revision 199242) +++ gen/setmode.c (working copy) @@ -86,7 +86,7 @@ set = (const BITCMD *)bbox; newmode = omode; - for (value = 0;; set++) + for (;; set++) switch(set->cmd) { /* * When copying the user, group or other bits around, we "know" @@ -147,6 +147,7 @@ } #define ADDCMD(a, b, c, d) \ + do { \ if (set >= endset) { \ BITCMD *newset; \ setlen += SET_LEN_INCR; \ @@ -161,7 +162,8 @@ saveset = newset; \ endset = newset + (setlen - 2); \ } \ - set = addcmd(set, (a), (b), (c), (d)) + set = addcmd(set, (a), (b), (c), (d)); \ + } while (0) #define STANDARD_BITS (S_ISUID|S_ISGID|S_IRWXU|S_IRWXG|S_IRWXO) @@ -173,11 +175,12 @@ BITCMD *set, *saveset, *endset; sigset_t sigset, sigoset; mode_t mask; - int equalopdone=0, permXbits, setlen; + int equalopdone, permXbits, setlen; long perml; if (!*p) return (NULL); + equalopdone = 0; /* * Get a copy of the mask for the permissions that are mask relative. @@ -299,16 +302,10 @@ * Add any permissions that we haven't already * done. */ - if (perm || (op == '=' && !equalopdone)) { - if (op == '=') - equalopdone = 1; + if (perm || (op == '=' && !equalopdone)) ADDCMD(op, who, perm, mask); - perm = 0; - } - if (permXbits) { + if (permXbits) ADDCMD('X', who, permXbits, mask); - permXbits = 0; - } goto apply; } } Index: gen/wordexp.c =================================================================== --- gen/wordexp.c (revision 199242) +++ gen/wordexp.c (working copy) @@ -320,7 +320,7 @@ if (c == '\0' || level != 0) return (WRDE_SYNTAX); } else - c = *--words; + --words; break; default: break; Index: gen/getcap.c =================================================================== --- gen/getcap.c (revision 199242) +++ gen/getcap.c (working copy) @@ -647,7 +647,7 @@ cgetnext(char **bp, char **db_array) { size_t len; - int done, hadreaderr, i, savederrno, status; + int done, hadreaderr, savederrno, status; char *cp, *line, *rp, *np, buf[BSIZE], nbuf[BSIZE]; u_int dummy; @@ -658,7 +658,7 @@ (void)cgetclose(); return (-1); } - for(;;) { + for (;;) { if (toprec && !gottoprec) { gottoprec = 1; line = toprec; @@ -709,7 +709,6 @@ /* * Line points to a name line. */ - i = 0; done = 0; np = nbuf; for (;;) { Index: gen/getpwent.c =================================================================== --- gen/getpwent.c (revision 199242) +++ gen/getpwent.c (working copy) @@ -257,22 +257,19 @@ pwd_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; - char *orig_buf; - size_t orig_buf_size; struct passwd new_pwd; size_t desired_size, size; char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -282,8 +279,7 @@ } pwd = va_arg(ap, struct passwd *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = sizeof(struct passwd) + sizeof(char *) + strlen(pwd->pw_name) + 1; @@ -361,8 +357,6 @@ pwd_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; char *orig_buf; size_t orig_buf_size; @@ -370,12 +364,13 @@ char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -921,7 +916,7 @@ errnop); } while (how == nss_lt_all && !(rv & NS_TERMINATE)); fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } @@ -1876,7 +1871,6 @@ syslog(LOG_ERR, "getpwent memory allocation failure"); *errnop = ENOMEM; - rv = NS_UNAVAIL; break; } st->compat = COMPAT_MODE_NAME; @@ -1940,7 +1934,7 @@ break; } fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } Index: gen/getgrent.c =================================================================== --- gen/getgrent.c (revision 199242) +++ gen/getgrent.c (working copy) @@ -207,22 +207,19 @@ grp_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; - char *orig_buf; - size_t orig_buf_size; struct group new_grp; size_t desired_size, size, mem_size; char *p, **mem; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -232,8 +229,7 @@ } grp = va_arg(ap, struct group *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = _ALIGNBYTES + sizeof(struct group) + sizeof(char *); @@ -302,8 +298,6 @@ grp_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; char *orig_buf; size_t orig_buf_size; @@ -314,10 +308,10 @@ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -1100,6 +1094,9 @@ case nss_lt_all: map = "group.byname"; break; + default: + *errnop = EINVAL; + return (NS_UNAVAIL); } grp = va_arg(ap, struct group *); buffer = va_arg(ap, char *); @@ -1392,6 +1389,13 @@ } break; case NS_RETURN: + /* + * If _nsdispatch() sets *errnop to ERANGE (can it?) + * we need a valid file position. Assume it might + * close st->fp, too (can it?). + */ + if (st->fp != NULL) + pos = ftello(st->fp); goto fin; default: break; @@ -1450,7 +1454,7 @@ pos = ftello(st->fp); } fin: - if (!stayopen && st->fp != NULL) { + if (st->fp != NULL && !stayopen) { fclose(st->fp); st->fp = NULL; } Index: gen/getusershell.c =================================================================== --- gen/getusershell.c (revision 199242) +++ gen/getusershell.c (working copy) @@ -124,7 +124,7 @@ if ((fp = fopen(_PATH_SHELLS, "r")) == NULL) return NS_UNAVAIL; - sp = cp = line; + cp = line; while (fgets(cp, MAXPATHLEN + 1, fp) != NULL) { while (*cp != '#' && *cp != '/' && *cp != '\0') cp++; Index: gen/pw_scan.c =================================================================== --- gen/pw_scan.c (revision 199242) +++ gen/pw_scan.c (working copy) @@ -202,7 +202,7 @@ if (p[0]) pw->pw_fields |= _PWF_SHELL; - if ((p = strsep(&bp, ":"))) { /* too many */ + if (strsep(&bp, ":") != NULL) { /* too many */ fmt: if (flags & _PWSCAN_WARN) warnx("corrupted entry"); Index: net/sctp_sys_calls.c =================================================================== --- net/sctp_sys_calls.c (revision 199242) +++ net/sctp_sys_calls.c (working copy) @@ -242,7 +242,8 @@ struct sockaddr *sa; struct sockaddr_in *sin; struct sockaddr_in6 *sin6; - int i, sz, argsz; + int i, argsz; + size_t sz; uint16_t sport = 0; /* validate the flags */ @@ -268,7 +269,7 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; sin = (struct sockaddr_in *)sa; if (sin->sin_port) { @@ -284,7 +285,7 @@ } } } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; sin6 = (struct sockaddr_in6 *)sa; if (sin6->sin6_port) { @@ -318,10 +319,10 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; } else { /* invalid address family specified */ Index: net/getservent.c =================================================================== --- net/getservent.c (revision 199242) +++ net/getservent.c (working copy) @@ -476,11 +476,11 @@ struct nis_state *st; int rv; - enum nss_lookup_type how; char *name; char *proto; int port; + enum nss_lookup_type how; struct servent *serv; char *buffer; size_t bufsize; @@ -491,7 +491,8 @@ name = NULL; proto = NULL; - how = (enum nss_lookup_type)mdata; + + how = (intptr_t)mdata; switch (how) { case nss_lt_name: name = va_arg(ap, char *); Index: posix1e/acl_delete_entry.c =================================================================== --- posix1e/acl_delete_entry.c (revision 199242) +++ posix1e/acl_delete_entry.c (working copy) @@ -89,20 +89,20 @@ return (-1); } - if ((acl->ats_acl.acl_cnt < 1) || - (acl->ats_acl.acl_cnt > ACL_MAX_ENTRIES)) { + if ((acl_int->acl_cnt < 1) || + (acl_int->acl_cnt > ACL_MAX_ENTRIES)) { errno = EINVAL; return (-1); } - for (i = 0; i < acl->ats_acl.acl_cnt;) { - if (_entry_matches(&(acl->ats_acl.acl_entry[i]), entry_d)) { + for (i = 0; i < acl_int->acl_cnt;) { + if (_entry_matches(&(acl_int->acl_entry[i]), entry_d)) { /* ...shift the remaining entries... */ - for (j = i; j < acl->ats_acl.acl_cnt - 1; ++j) - acl->ats_acl.acl_entry[j] = - acl->ats_acl.acl_entry[j+1]; + for (j = i; j < acl_int->acl_cnt - 1; ++j) + acl_int->acl_entry[j] = + acl_int->acl_entry[j+1]; /* ...drop the count and zero the unused entry... */ - acl->ats_acl.acl_cnt--; - bzero(&acl->ats_acl.acl_entry[j], + acl_int->acl_cnt--; + bzero(&acl_int->acl_entry[j], sizeof(struct acl_entry)); acl->ats_cur_entry = 0; Index: inet/inet_cidr_pton.c =================================================================== --- inet/inet_cidr_pton.c (revision 199242) +++ inet/inet_cidr_pton.c (working copy) @@ -236,7 +236,6 @@ endp[- i] = colonp[n - i]; colonp[n - i] = 0; } - tp = endp; } memcpy(dst, tmp, NS_IN6ADDRSZ); --AykRJN6Qt4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 14:57:59 2009 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 69D91106568B for ; Fri, 13 Nov 2009 14:57:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 247F58FC12 for ; Fri, 13 Nov 2009 14:57:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CC1BA46B3B; Fri, 13 Nov 2009 09:57:58 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0CCC58A01B; Fri, 13 Nov 2009 09:57:58 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 13 Nov 2009 09:34:55 -0500 User-Agent: KMail/1.9.7 References: <20091113020835.GE12442@visor.slugabed.org> In-Reply-To: <20091113020835.GE12442@visor.slugabed.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911130934.55996.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 13 Nov 2009 09:57:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Sean Hamilton Subject: Re: NUMA support; tweaking TCP for GPRS 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, 13 Nov 2009 14:57:59 -0000 On Thursday 12 November 2009 9:08:35 pm Sean Hamilton wrote: > Greetings -hackers, > > I have two unrelated questions. > > First, what is the status of NUMA support in FreeBSD? Is > there a performance penalty on Nehalem-class systems, > compared with Linux, which advertises NUMA awareness? Google > seems to turn up very little on this subject. Yes, there is a penalty. I have some very simplistic NUMA support in a p4 branch (//depot/user/jhb/numa/...) that just makes threads allocate memory close to the current CPU when requesting a free page. It's not very general purpose, but it can be useful if you pin all your tasks to specific packages. I haven't tested it with non-pinned workloads to see what effect it has. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 15:37:12 2009 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 88E361065679 for ; Fri, 13 Nov 2009 15:37:12 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 4B28A8FC1B for ; Fri, 13 Nov 2009 15:37:12 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 10EFB35A82B; Fri, 13 Nov 2009 16:37:11 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id EDB7E33C92; Fri, 13 Nov 2009 16:37:10 +0100 (CET) Date: Fri, 13 Nov 2009 16:37:10 +0100 From: Jilles Tjoelker To: Garrett Wollman Message-ID: <20091113153710.GA99645@stack.nl> References: <19196.60473.337121.565916@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19196.60473.337121.565916@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org Subject: Re: CFR: Exceedingly minor fixes to libc 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, 13 Nov 2009 15:37:12 -0000 On Fri, Nov 13, 2009 at 12:18:49AM -0500, Garrett Wollman wrote: > If you have a moment, please take a look at the following patch. It > contains some very minor fixes to various parts of libc which were > found by the clang static analyzer. They fall into a few categories: > 1) Bug fixes in very rare situations (mostly error-handling code that > has probably never been executed). > 2) Dead store elimination. > 3) Elimination of unused variables. (Or in a few cases, making use of > them.) > Some minor style problems were also fixed in the vicinity. There > should be no functional changes except in very unusual conditions. This looks mostly ok, with a few exceptions. > [...] > Index: gen/getpwent.c > =================================================================== > --- gen/getpwent.c (revision 199242) > +++ gen/getpwent.c (working copy) > @@ -257,22 +257,19 @@ > [...] > @@ -1876,7 +1871,6 @@ > syslog(LOG_ERR, > "getpwent memory allocation failure"); > *errnop = ENOMEM; > - rv = NS_UNAVAIL; > break; > } > st->compat = COMPAT_MODE_NAME; I think this change hides the wrongness in the handling of malloc errors while leaving it as broken as it is. > [...] > Index: net/getservent.c > =================================================================== > --- net/getservent.c (revision 199242) > +++ net/getservent.c (working copy) > @@ -476,11 +476,11 @@ > struct nis_state *st; > int rv; > > - enum nss_lookup_type how; > char *name; > char *proto; > int port; > > + enum nss_lookup_type how; > struct servent *serv; > char *buffer; > size_t bufsize; > @@ -491,7 +491,8 @@ > > name = NULL; > proto = NULL; > - how = (enum nss_lookup_type)mdata; > + > + how = (intptr_t)mdata; > switch (how) { > case nss_lt_name: > name = va_arg(ap, char *); In what way is this an improvement? > Index: posix1e/acl_delete_entry.c > =================================================================== > --- posix1e/acl_delete_entry.c (revision 199242) > +++ posix1e/acl_delete_entry.c (working copy) > @@ -89,20 +89,20 @@ > return (-1); > } > > - if ((acl->ats_acl.acl_cnt < 1) || > - (acl->ats_acl.acl_cnt > ACL_MAX_ENTRIES)) { > + if ((acl_int->acl_cnt < 1) || > + (acl_int->acl_cnt > ACL_MAX_ENTRIES)) { > errno = EINVAL; > return (-1); > } If you are changing this code anyway, consider fixing a style bug (extraneous parentheses) here. > - for (i = 0; i < acl->ats_acl.acl_cnt;) { > - if (_entry_matches(&(acl->ats_acl.acl_entry[i]), entry_d)) { > + for (i = 0; i < acl_int->acl_cnt;) { > + if (_entry_matches(&(acl_int->acl_entry[i]), entry_d)) { > /* ...shift the remaining entries... */ > - for (j = i; j < acl->ats_acl.acl_cnt - 1; ++j) > - acl->ats_acl.acl_entry[j] = > - acl->ats_acl.acl_entry[j+1]; > + for (j = i; j < acl_int->acl_cnt - 1; ++j) > + acl_int->acl_entry[j] = > + acl_int->acl_entry[j+1]; > /* ...drop the count and zero the unused entry... */ > - acl->ats_acl.acl_cnt--; > - bzero(&acl->ats_acl.acl_entry[j], > + acl_int->acl_cnt--; > + bzero(&acl_int->acl_entry[j], > sizeof(struct acl_entry)); > acl->ats_cur_entry = 0; > -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 16:15:37 2009 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 198461065670; Fri, 13 Nov 2009 16:15:37 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 68A1B8FC19; Fri, 13 Nov 2009 16:15:35 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nADGF2fV040288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Nov 2009 01:15:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 14 Nov 2009 01:15:02 +0900 Message-ID: From: Hajimu UMEMOTO To: Garrett Wollman In-Reply-To: <19196.60473.337121.565916@hergotha.csail.mit.edu> References: <19196.60473.337121.565916@hergotha.csail.mit.edu> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RC3 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 14 Nov 2009 01:15:03 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: CFR: Exceedingly minor fixes to libc 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, 13 Nov 2009 16:15:37 -0000 Hi, >>>>> On Fri, 13 Nov 2009 00:18:49 -0500 >>>>> Garrett Wollman said: wollman> Index: inet/inet_cidr_pton.c wollman> =================================================================== wollman> --- inet/inet_cidr_pton.c (revision 199242) wollman> +++ inet/inet_cidr_pton.c (working copy) wollman> @@ -236,7 +236,6 @@ wollman> endp[- i] = colonp[n - i]; wollman> colonp[n - i] = 0; wollman> } wollman> - tp = endp; wollman> } wollman> wollman> memcpy(dst, tmp, NS_IN6ADDRSZ); Since this function is vendor import one from ISC, such cosmetic change may cause problem during further import. So, you should send this patch to ISC folks 1st. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 19:58:26 2009 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 265DC106566C for ; Fri, 13 Nov 2009 19:58:26 +0000 (UTC) (envelope-from beckman@angryox.com) Received: from nog.angryox.com (nog.angryox.com [70.164.19.87]) by mx1.freebsd.org (Postfix) with ESMTP id E9DBC8FC16 for ; Fri, 13 Nov 2009 19:58:25 +0000 (UTC) Received: from nog.angryox.com (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id E45282C3D0E for ; Fri, 13 Nov 2009 19:42:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=angryox.com; h=date:from :to:subject:message-id:mime-version:content-type; s= powerfulgood; bh=EOnu9q7IXtnyjF42EyIwnHrCdgE=; b=BbjKVwJMeIzfKoO o/xjUepTwP6MFz1sutoannClF5u2dgoypj6wBJoZsQN1A/otn6+GBiVowb7Ztu5a V+vFn9G0RtA3OgYVM4Ih2xIBhP1LuHN5YotE8uf4eVD0z7XVc9GPdp0bhujE0X3T IGT3MxUM9KYc5jWUqih7XXUnXJcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=angryox.com; h=date:from:to :subject:message-id:mime-version:content-type; q=dns; s= powerfulgood; b=dS/4rnos8oxg5GjhOxv7OW4DIk66tElOHECgz9qirt9Hu23Y Tej239NLfuPkXHI1ul92LPgr7Un+j43n162up5q76kROzy7yfF0DIiYTGs0uPyGH GIshcvnjHL9AEqCbFXrgLPzM+H1UlB55LpjQkm/auwYM3uYbiUZsWfFu6nM= Received: by nog.angryox.com (Postfix, from userid 1001) id DC3352C3D08; Fri, 13 Nov 2009 19:42:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id DB9422C3D05 for ; Fri, 13 Nov 2009 14:42:07 -0500 (EST) Date: Fri, 13 Nov 2009 14:42:07 -0500 From: Peter Beckman 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 Subject: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 13 Nov 2009 19:58:26 -0000 I've been scratching my head all day on an issue that's been frustrating. I've got two FreeBSD 6.2 instances installed on two M600 blades, and am moving to a new datacenter with M600 blades and trying to install FreeBSD 7.2 or 8. But as others on this list and elsewhere have mentioned, seemingly without resolution, is that it doesn't work. http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html http://forums.freebsd.org/showthread.php?t=486 I was able to install 6.4 on it today, but I'm still at a loss as to why 7.x and even 8.x will not. Did the architecture change in such a way that it could no longer support M600 blades? Did someone leave something out of the standard ISO kernel? Am I not doing it right? Happy to pass along my dmesg.boot; I'm not sure how to troubleshoot this, or where to look for documentation that says something in the M600 is no longer supported, or that what was supported in the M600 was changed that now causes FreeBSD to hang instead of booting. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 13 22:53:49 2009 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 99AA01065672 for ; Fri, 13 Nov 2009 22:53:49 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: from web113202.mail.gq1.yahoo.com (web113202.mail.gq1.yahoo.com [98.136.165.123]) by mx1.freebsd.org (Postfix) with SMTP id 542F28FC08 for ; Fri, 13 Nov 2009 22:53:49 +0000 (UTC) Received: (qmail 22534 invoked by uid 60001); 13 Nov 2009 22:53:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258152828; bh=xwkBmdFBufFNUvzKKeuKBBw7/+QuZOlm4qJpzatdaXI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=KChlOHDcsZoTvkwXl9qkMw32PGXMexdAZAgBTk6LAY3OrBs1YNdYq6ZTKH+wQeIqIlGOwEQmKof0BsgWnBaEIngWm/L7sJKZ9nyx58bZ2ErDwK0QzD8drftzF4U+MjEGbUmdlHZV4l2DqtdDwklx3fpTBTYRM9WutOCI269QbBA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=i2C880noj0g88RTtXKfIgZ/9qMDxn4WOAW7iizrLWnm5PJqPC25QtsvlK0RUqYdmT4qzKeBwRMxN0M+dbtz3B3JIGru3vq8wB0syuje60xQb6OqgmL9EWa8BXpCQUltMgbh0RjkoyJcUUGzeO3Ul+GXEybZjpz9sQKT3RfBDAe4=; Message-ID: <801850.20206.qm@web113202.mail.gq1.yahoo.com> X-YMail-OSG: 7f0CIqYVM1lmpYaiwURTXUoI94imktsJkR3y_xt0VVBDLDDUogHDCfnO.Uemy5augySh_L1hrFevfnvL.y391vFSY6mBWb9U82ZAGspN.EWb0uCpsM61Z3L9KH8iHNzLJMqcUphJeLBvFDHlGOgUC_MWwF6fVd5LrzeXrB0mAAVn8C7.UzOARGl_Etavq0K693Hj8V323XzHNW7dkjQfx5bAy_VoR9TSeLMOUZ7w5uW1kRCd9sGCGQHMoAgWkdpKBhk- Received: from [128.55.19.49] by web113202.mail.gq1.yahoo.com via HTTP; Fri, 13 Nov 2009 14:53:48 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4 Date: Fri, 13 Nov 2009 14:53:48 -0800 (PST) From: Trever To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: bad source in the distro iso'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: Fri, 13 Nov 2009 22:53:49 -0000 I noticed in 7.2 that the /usr/src installed from the ISO downloads would not build without first sup'ing for a few updates. (disc1.iso's) I notice in the 8.0RC2&3 that some of the source files are corrupted. Not a media issue, checksum's have always been confirmed good. Is this normal, for the packaged source to be "bad"? One of the nice things about BSD is that it comes with everything to build itself, but if the source won't build without first updating... Just curious. Trever From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 06:51:40 2009 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 3EAC71065676 for ; Sat, 14 Nov 2009 06:51:40 +0000 (UTC) (envelope-from manolis@FreeBSD.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by mx1.freebsd.org (Postfix) with ESMTP id A1F888FC0A for ; Sat, 14 Nov 2009 06:51:39 +0000 (UTC) Received: from pulstar.local (ppp-94-69-68-99.home.otenet.gr [94.69.68.99]) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id nAE6WtJc001241; Sat, 14 Nov 2009 08:32:55 +0200 Message-ID: <4AFE4F17.6050007@FreeBSD.org> Date: Sat, 14 Nov 2009 08:32:55 +0200 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Trever References: <801850.20206.qm@web113202.mail.gq1.yahoo.com> In-Reply-To: <801850.20206.qm@web113202.mail.gq1.yahoo.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: bad source in the distro iso'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: Sat, 14 Nov 2009 06:51:40 -0000 Trever wrote: > I noticed in 7.2 that the /usr/src installed from the ISO downloads would not build without first sup'ing for a few updates. (disc1.iso's) > > I notice in the 8.0RC2&3 that some of the source files are corrupted. > > Not a media issue, checksum's have always been confirmed good. > > Is this normal, for the packaged source to be "bad"? > > One of the nice things about BSD is that it comes with everything to build itself, but if the source won't build without first updating... > > Just curious. > > Trever > > There must be something wrong at your end. I routinely run make buildworld / make release using -RELEASE sources and never had any problems. Are you sure you are installing *all* the sources, both kernel and world? It could be that something goes wrong during decompression, though I suspect this would happen to other files as well leading to a non-working system. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 07:57:56 2009 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 9817D106566B for ; Sat, 14 Nov 2009 07:57:56 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3758FC12 for ; Sat, 14 Nov 2009 07:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:MIME-Version:Content-Type:Sender; bh=0heDKyu7GxAAtZ8pHc G91lu08lCMb8JdYj/f/DPOtMM=; b=YqjfcslFunL/eBL6GgfTSvHavhfgM4qr0E lCdNlXOrOjt/cjZcyntLUnz6Fwv0v9MnA+l2m3kNGGxq/x8YUByC1Syzj3io3ZUA 0NOCt5VSogIV00O9emSPAYibnpQaRUnaoaqLXgZoCvJzfJqP28zhUKwmW5OGIC/I MMlghd6h7csfICeIaCp48GbceUwSXbSGaX+wFHVVMZxGrmahbXt8Cqx5E5GL81mJ Lk1YYVTG5FBGOBZuSdEtHEu4DPFQqeD6KDEiIP6rHsWLJ9M2ke4nqLRYVnhVGKef R5FOQRwVBJQiYR3CTBDMtU6sy5zDIvd5iRI/RyjDzt3SoCG3Wp/g== Received: from shadow.codelabs.ru (cdma-92-36-69-228.msk.skylink.ru [92.36.69.228]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N9DW6-0008et-1z; Sat, 14 Nov 2009 10:57:54 +0300 Date: Sat, 14 Nov 2009 10:57:55 +0300 From: Eygene Ryabinkin To: Trever Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: rea-fbsd@codelabs.ru Cc: freebsd-hackers@FreeBSD.org Subject: Re: bad source in the distro iso's X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 07:57:56 -0000 Trever wrote: > I noticed in 7.2 that the /usr/src installed from the ISO downloads > would not build without first sup'ing for a few updates. > (disc1.iso's) > > I notice in the 8.0RC2&3 that some of the source files are corrupted. Can you be precise in what's going wrong? What objects can't be built, what are error messages, etc? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 11:45:38 2009 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 8DFCE1065679 for ; Sat, 14 Nov 2009 11:45:38 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEBD8FC16 for ; Sat, 14 Nov 2009 11:45:36 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 220314C80F1 for ; Sat, 14 Nov 2009 12:45:32 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 280064C8049 for ; Sat, 14 Nov 2009 12:45:30 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id nAEBjPUW001331; Sat, 14 Nov 2009 12:45:26 +0100 (CET) From: Thierry Herbelot To: freebsd-hackers@freebsd.org Date: Sat, 14 Nov 2009 13:45:19 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200911141245.20217.thierry.herbelot@free.fr> X-Mailman-Approved-At: Sat, 14 Nov 2009 12:50:04 +0000 Cc: Peter Beckman Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 11:45:38 -0000 Le Friday 13 November 2009, Peter Beckman a écrit : > I've been scratching my head all day on an issue that's been frustrating. > > I've got two FreeBSD 6.2 instances installed on two M600 blades, and am > moving to a new datacenter with M600 blades and trying to install FreeBSD > 7.2 or 8. But as others on this list and elsewhere have mentioned, > seemingly without resolution, is that it doesn't work. > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html > http://forums.freebsd.org/showthread.php?t=486 > > I was able to install 6.4 on it today, but I'm still at a loss as to why > 7.x and even 8.x will not. Did the architecture change in such a way that > it could no longer support M600 blades? Did someone leave something out of > the standard ISO kernel? Am I not doing it right? > > Happy to pass along my dmesg.boot; Hello, from the two URLs you provide, it seems that i386 is working (for all FreeBSD versions) and only amd64 is failing : can you confirm this ? then, one of the first steps would be a the dmesg of both a succeeding and a failing kernels (verbose !) TfH PS : is there any more recent version of the Dell BIOS ? > I'm not sure how to troubleshoot this, > or where to look for documentation that says something in the M600 is no > longer supported, or that what was supported in the M600 was changed that > now causes FreeBSD to hang instead of booting. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 13:33:30 2009 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 13C16106566C for ; Sat, 14 Nov 2009 13:33:30 +0000 (UTC) (envelope-from prvs=156906d90f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 979CB8FC18 for ; Sat, 14 Nov 2009 13:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1258205007; x=1258809807; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=zNhWrSvK8eiflnXfwpLO3 VsU5M2Z75zHUx2SydE3Ry4=; b=gjnU83MGBT9+L8C56zWLMkkaHnq4rT8WvjLQn eeXl9ziqBi56f4+79MhIWGIKSt8xyeAZKdW7DgCv7ispSwZ4rEf5IScZ9ORpF5JD E0zj9lLTkl8dNT+pR5TfE0Zp9/xu/6hKzAhuBM9f4BTIzo3rsCMjUiBM0TOynzRM rCcgFo= X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 14 Nov 2009 13:23:27 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008597932.msg for ; Sat, 14 Nov 2009 13:23:27 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 14 Nov 2009 13:23:27 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 217.41.255.162 X-Return-Path: prvs=156906d90f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> From: "Steven Hartland" To: "Thierry Herbelot" , References: <200911141245.20217.thierry.herbelot@free.fr> Date: Sat, 14 Nov 2009 13:23:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Peter Beckman Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 13:33:30 -0000 Yes I can confirm that. Regards Steve ----- Original Message ----- From: "Thierry Herbelot" > from the two URLs you provide, it seems that i386 is working (for all FreeBSD > versions) and only amd64 is failing : can you confirm this ? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 15:31:33 2009 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 846431065672 for ; Sat, 14 Nov 2009 15:31:33 +0000 (UTC) (envelope-from thierry.herbelot@laposte.net) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id D9AEA8FC19 for ; Sat, 14 Nov 2009 15:31:31 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id D2008D1A860 for ; Sat, 14 Nov 2009 16:12:58 +0100 (CET) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 6A3214C808E for ; Sat, 14 Nov 2009 16:12:52 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7D2864C801A for ; Sat, 14 Nov 2009 16:12:50 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id nAEFCiJi021881; Sat, 14 Nov 2009 16:12:44 +0100 (CET) From: Thierry Herbelot To: freebsd-hackers@freebsd.org Date: Sat, 14 Nov 2009 17:12:38 +0200 User-Agent: KMail/1.9.10 References: <200911141245.20217.thierry.herbelot@free.fr> <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> In-Reply-To: <1691ED1396D14B8CA5AB95152C3041E0@multiplay.co.uk> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200911141612.38908.thierry.herbelot@laposte.net> Cc: Steven Hartland , Peter Beckman Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 15:31:33 -0000 Le Saturday 14 November 2009, Steven Hartland a écrit : > Yes I can confirm that. then, could you please provide the verbose dmesg for both working and non-working configurations ? TfH > > Regards > Steve > ----- Original Message ----- > From: "Thierry Herbelot" > > > from the two URLs you provide, it seems that i386 is working (for all > > FreeBSD versions) and only amd64 is failing : can you confirm this ? > From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 15:48:45 2009 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 286C3106568D for ; Sat, 14 Nov 2009 15:48:45 +0000 (UTC) (envelope-from beckman@angryox.com) Received: from nog.angryox.com (nog.angryox.com [70.164.19.87]) by mx1.freebsd.org (Postfix) with ESMTP id D3C8E8FC12 for ; Sat, 14 Nov 2009 15:48:44 +0000 (UTC) Received: from nog.angryox.com (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id 7D2B62C3D3F; Sat, 14 Nov 2009 15:48:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=angryox.com; h=date:from :to:cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=powerfulgood; bh=NeM+oabhkTCRpG/248t0H3CgSyQ=; b= gtGa0hfw1fdGfbvW8OSka8cSOve9oETuPaaz/VckcJlHRZ2iF9tsNVnuheQLGbNr pdN8bKuzQ5ERq8D8NEWvfB/RhInFPQTP3rlRZKKON/zEE6sVNb/jHAc28fFG134d faUFlscikoE1OPzJaJWa/qHziYFrhX5ZLCTj7Azt2Js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=angryox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; q=dns; s=powerfulgood; b=y3lKtVAz9xmkmH+D1YfcUIhV 6lstgi+1/X+JfnINsvPBN66WkhRoW6g6mMD6UbqJUg5ejF5dutHfQdrQMfiwiLaW ovC16/hqp5hEIWllZTVNPBo9T8wFxosakpnFYwzgcnK4hvgjG3WBvuvfOyjBqDK/ tr0BJvlGamcHe4Sb0o0= Received: by nog.angryox.com (Postfix, from userid 1001) id 61EAA2C3D3E; Sat, 14 Nov 2009 15:48:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nog.angryox.com (Postfix) with ESMTP id 60F6A2C3D3D; Sat, 14 Nov 2009 10:48:43 -0500 (EST) Date: Sat, 14 Nov 2009 10:48:43 -0500 From: Peter Beckman To: Thierry Herbelot In-Reply-To: <200911141245.20217.thierry.herbelot@free.fr> Message-ID: References: <200911141245.20217.thierry.herbelot@free.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-151665445-1258213723=:10412" Cc: freebsd-hackers@freebsd.org Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 15:48:45 -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. --0-151665445-1258213723=:10412 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On Sat, 14 Nov 2009, Thierry Herbelot wrote: > Le Friday 13 November 2009, Peter Beckman a =C3=A9crit : >> I've been scratching my head all day on an issue that's been frustrati= ng. >> >> I've got two FreeBSD 6.2 instances installed on two M600 blades, and a= m >> moving to a new datacenter with M600 blades and trying to install Free= BSD >> 7.2 or 8. But as others on this list and elsewhere have mentioned, >> seemingly without resolution, is that it doesn't work. >> >> >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.ht= ml >> http://forums.freebsd.org/showthread.php?t=3D486 >> >> I was able to install 6.4 on it today, but I'm still at a loss as to w= hy >> 7.x and even 8.x will not. Did the architecture change in such a way = that >> it could no longer support M600 blades? Did someone leave something o= ut of >> the standard ISO kernel? Am I not doing it right? >> >> Happy to pass along my dmesg.boot; > > from the two URLs you provide, it seems that i386 is working (for all F= reeBSD > versions) and only amd64 is failing : can you confirm this ? > > then, one of the first steps would be a the dmesg of both a succeeding = and a > failing kernels (verbose !) I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of which fail to boot on the Dell M600. I was able to boot the bootonly 6.4 ISO, install via the net, and a fri= end suggested I try binary updating. I have been able to binary update to 7.0-RELEASE thus far. I'm trying to get to 8.0-RC3 via binary update n= ow, and will report back. I believe the issue is not with FreeBSD but the bootonly ISO. It could also be a problem with the other ISOs, I'm not yet sure. > PS : is there any more recent version of the Dell BIOS ? According to the iDRAC, the firmware 2.2.3 reported as installed is wha= t Dell reports as the latest version (August 2009). -------------------------------------------------------------------------= -- Peter Beckman Internet G= uy beckman@angryox.com http://www.angryox.co= m/ -------------------------------------------------------------------------= -- --0-151665445-1258213723=:10412-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 16:20:57 2009 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 F21D01065679 for ; Sat, 14 Nov 2009 16:20:56 +0000 (UTC) (envelope-from thierry.herbelot@laposte.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7A12B8FC1C for ; Sat, 14 Nov 2009 16:20:54 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 699FB4C8163 for ; Sat, 14 Nov 2009 17:20:50 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 308214C8025 for ; Sat, 14 Nov 2009 17:20:48 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id nAEGKhXl015891; Sat, 14 Nov 2009 17:20:44 +0100 (CET) From: Thierry Herbelot To: freebsd-hackers@freebsd.org Date: Sat, 14 Nov 2009 18:20:38 +0200 User-Agent: KMail/1.9.10 References: <200911141245.20217.thierry.herbelot@free.fr> In-Reply-To: X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200911141720.38432.thierry.herbelot@laposte.net> Cc: Peter Beckman Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 16:20:57 -0000 Le Saturday 14 November 2009, Peter Beckman a écrit : > On Sat, 14 Nov 2009, Thierry Herbelot wrote: > > Le Friday 13 November 2009, Peter Beckman a écrit : > >> I've been scratching my head all day on an issue that's been > >> frustrating. > >> > >> I've got two FreeBSD 6.2 instances installed on two M600 blades, and am > >> moving to a new datacenter with M600 blades and trying to install > >> FreeBSD 7.2 or 8. But as others on this list and elsewhere have > >> mentioned, seemingly without resolution, is that it doesn't work. > >> > >> > >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029147.html > >> http://forums.freebsd.org/showthread.php?t=486 > >> > >> I was able to install 6.4 on it today, but I'm still at a loss as to why > >> 7.x and even 8.x will not. Did the architecture change in such a way > >> that it could no longer support M600 blades? Did someone leave > >> something out of the standard ISO kernel? Am I not doing it right? > >> > >> Happy to pass along my dmesg.boot; > > > > from the two URLs you provide, it seems that i386 is working (for all > > FreeBSD versions) and only amd64 is failing : can you confirm this ? > > > > then, one of the first steps would be a the dmesg of both a succeeding > > and a failing kernels (verbose !) > > I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of > which fail to boot on the Dell M600. aha ! anyway, even with a CDROM, you can boot *verbose* and note where the boot stops (even if there won't be a serial console, write down the blocking device probe) TfH > > I was able to boot the bootonly 6.4 ISO, install via the net, and a > friend suggested I try binary updating. I have been able to binary update > to 7.0-RELEASE thus far. I'm trying to get to 8.0-RC3 via binary update > now, and will report back. (a more robust, and slower, way to upgrade is via make buildworld / make buildkernel) > > I believe the issue is not with FreeBSD but the bootonly ISO. It could > also be a problem with the other ISOs, I'm not yet sure. we may get a hint if/when someone sends some verbose dmesg ;-) > > > PS : is there any more recent version of the Dell BIOS ? > > According to the iDRAC, the firmware 2.2.3 reported as installed is what > Dell reports as the latest version (August 2009). fine > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 14 17:19:29 2009 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 26AA1106566B for ; Sat, 14 Nov 2009 17:19:29 +0000 (UTC) (envelope-from thierry.herbelot@laposte.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 880B38FC0C for ; Sat, 14 Nov 2009 17:19:26 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 0EE2F4C811B for ; Sat, 14 Nov 2009 18:19:23 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 1CCDA4C8184 for ; Sat, 14 Nov 2009 18:19:21 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id nAEHJHux018791; Sat, 14 Nov 2009 18:19:18 +0100 (CET) From: Thierry Herbelot To: Peter Beckman Date: Sat, 14 Nov 2009 19:19:11 +0200 User-Agent: KMail/1.9.10 References: <200911141720.38432.thierry.herbelot@laposte.net> In-Reply-To: X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200911141819.12000.thierry.herbelot@laposte.net> Cc: "freebsd-hackers@FreeBSD.ORG" Subject: Re: Dell M600 Blade: 6.4 works, 7.x and 8.x fail to boot 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, 14 Nov 2009 17:19:29 -0000 Le Saturday 14 November 2009, Peter Beckman a écrit : [SNIP] > >>> > >>> then, one of the first steps would be a the dmesg of both a succeeding > >>> and a failing kernels (verbose !) > >> > >> I tried the bootonly ISOs for 7.x and 8.x, both amd64 and i386, all of > >> which fail to boot on the Dell M600. > > > > aha ! > > > > anyway, even with a CDROM, you can boot *verbose* and note where the boot > > stops (even if there won't be a serial console, write down the blocking > > device probe) > > Can you shoot me a link to the docs on how to do this? I haven't been > able to find out how. speaking from memory : just before the kernel starts, you should have the *loader* menu (with the ASCII graphics depicting beastie), where you can choose between boot options, and option 5 is boot verbose (like 4 is boot single) TfH > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman@angryox.com http://www.angryox.com/ > ---------------------------------------------------------------------------