From owner-freebsd-arch@FreeBSD.ORG Sun Nov 22 11:27:49 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A08106566B for ; Sun, 22 Nov 2009 11:27:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D55BE8FC12 for ; Sun, 22 Nov 2009 11:27:48 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 45802730DA; Sun, 22 Nov 2009 12:17:32 +0100 (CET) Date: Sun, 22 Nov 2009 12:17:32 +0100 From: Luigi Rizzo To: arch@freebsd.org Message-ID: <20091122111732.GA45909@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: anyone interested in helping fixing the 'tcc' compiler ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 11:27:49 -0000 Hi, I have recently started playing with the Tiny C Compuler (lang/tcc) which is amazingly useful for prototyping, but has problem generating non-static binaries in FreeBSD -- basically it produces a bogus elf file which our loader does not like. Static binaries work fine, as well as 'tcc -run ' (compile and run on the fly -- you should really try it if you haven't yet). There is an open PR on this http://www.freebsd.org/cgi/query-pr.cgi?pr=138481 and the problem is known upstream but no fix http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html However, from the description it does not seem a horribly hard problem. Perhaps someone with a bit of knowledge on how our ld-elf.so works should not have a hard time pinpointing the problem so that other people can fix it ? Any takers ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Sun Nov 22 16:41:00 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B4D106566C for ; Sun, 22 Nov 2009 16:41:00 +0000 (UTC) (envelope-from rodolfo.manin@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id E98DE8FC0C for ; Sun, 22 Nov 2009 16:40:59 +0000 (UTC) Received: by yxe1 with SMTP id 1so4273054yxe.3 for ; Sun, 22 Nov 2009 08:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=/LkqeP5GBTnzfH5nzeKaOW/rOTLrPTafKlcquQMqUAs=; b=qL/jmbQJFCwrzejEpQI6tlwJDrddvbA1BBMKsDXjHEL3IA/GovZIpKVQbSCnC6Yvfn UKbjPEMm5Nor40QTGjkEHyFd3Bv8EogLRWHj35nwHuAsnNYlqeLCGj0JiTqGm2PbVT1p Ziqg+tpezSFVfUu6XaAusr5fdWxqo4X7zeF2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=q+bppLY2jcgnDhvbqHY6gKskiTRkd7WFVyqReEYddQBTUJS/aWgVzYsSAIAM6jicvE 2VRNmIpFsQnbnRwAOSM6DaRl+sAjXQit+DQJJ8smdFRmtOlCawUHsgx+EO+cTRzCbcz+ PaYfpDiGcoDKxGTnAnwvyeQv75v/KdK53CXUE= MIME-Version: 1.0 Received: by 10.101.200.32 with SMTP id c32mr3279705anq.94.1258906691067; Sun, 22 Nov 2009 08:18:11 -0800 (PST) From: Rodolfo Manin Date: Sun, 22 Nov 2009 14:17:51 -0200 Message-ID: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: "AP #1 failed" installing 8.0-RC3 amd64 on a DK 790FX-M2RS motherboard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 16:41:00 -0000 Hi! I'm tying to install FreeBSD amd64 on a system with the following configuration: - CPU: AMD Phenon X4 9550 - Motherboard: DFI LanParty DK 790FX-M2RS - AMD 790FX + SB600 (Award BIOS / "AWRDACPI") - Memory: 4Gb - Video board: ATI Radeon 3870 Booting the installation CD-ROM works fine for FreeBSD 6.9, but it panics with an "AP #1 (PHY# 1) failed!" error for 7.0, 7.1, 7.2 and 8.0-RC3. If I boot with ACPI disabled, I get a lot of "unable to allocate IRQ" errors (for almost all of my devices), and it halts on "start_init: trying /stand/sysinstall". With SMP disabled (kern.smp.disabled=1), it boots fine. Yesterday, I updated my motherboard's BIOS to the latest version available at DFI's website, and spent the morning playing with the BIOS setup options, but the result was always the same. I posted a "complete report" (including the full output of boot messages - with and without ACPI enabled) at FreeBSD's Hardware Forum (http://forums.freebsd.org/showthread.php?t=8565). I think this occurs because FreeBSD could not start the other cores of my CPU (function "start_ap" at "mp_machdep.c"). Does somebody have any clue about this issue? Is there something else I could try? I like FreeBSD a lot, and I'm really looking forward to have FreeBSD running on this machine! :) Thanks a lot in advice!! Rodolfo From owner-freebsd-arch@FreeBSD.ORG Sun Nov 22 16:47:38 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A1F71065670 for ; Sun, 22 Nov 2009 16:47:38 +0000 (UTC) (envelope-from rodolfo.manin@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id CA6688FC12 for ; Sun, 22 Nov 2009 16:47:37 +0000 (UTC) Received: by ywh42 with SMTP id 42so4560687ywh.28 for ; Sun, 22 Nov 2009 08:47:37 -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 :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=cMajoTRZzAy0YXF6uKErD643/frfZ243WwqsrfAOlnU=; b=VYBUV8R46dInm7mS/Qs3NmBeDEBAMBVC0WwY9Y5gpV4AvqZK8JcmNmUrv38VzF9ibn kaCyU05hNgysXWWFbAm6Aq4xIOulpE8jmJ1/1hLcGclfo1yeEvfDcxPtYU0m/0EBxSmo IeZ3VUxpujEQr4oVJYgpfXN7K5jvyH85l/P4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Pigzx5mKQZms1RkycHAXtbwQJc556+sNZOkQnY+quu/iL3Lv2nqNqwd6/ttwGkd5sZ vyKWLqfnqCEhArx58Bg1bUPy8+M1xHrJycD7IPDhF2a85zM0NKwfnfjm7iK8Tr6keZBa 4GtN1qWeWJZVWPxgv0FQhLokrJw0XstAN15oI= MIME-Version: 1.0 Received: by 10.101.141.9 with SMTP id t9mr3166042ann.188.1258906945159; Sun, 22 Nov 2009 08:22:25 -0800 (PST) In-Reply-To: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> References: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> From: Rodolfo Manin Date: Sun, 22 Nov 2009 14:22:05 -0200 Message-ID: <7ff738ef0911220822m11cc623aw3f4e868d5c43af3d@mail.gmail.com> To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: "AP #1 failed" installing 8.0-RC3 amd64 on a DK 790FX-M2RS motherboard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 16:47:38 -0000 Hi! I'm tying to install FreeBSD amd64 on a system with the following configura= tion: - CPU: AMD Phenon X4 9550 - Motherboard: DFI LanParty DK 790FX-M2RS - AMD 790FX + SB600 (Award BIOS / "AWRDACPI") - Memory: 4Gb - Video board: ATI Radeon 3870 Booting the installation CD-ROM works fine for FreeBSD 6.9, but it panics with an "AP #1 (PHY# 1) failed!" error for 7.0, 7.1, 7.2 and 8.0-RC3. =A0If I boot with ACPI disabled, I get a lot of "unable to allocate IRQ" errors (for almost all of my devices), and it halts on "start_init: trying /stand/sysinstall". =A0With SMP disabled (kern.smp.disabled=3D1), it boots fine. Yesterday, I updated my motherboard's BIOS to the latest version available at DFI's website, and spent the morning playing with the BIOS setup options, but the result was always the same. I posted a "complete report" (including the full output of boot messages - with and without ACPI enabled) at FreeBSD's Hardware Forum (http://forums.freebsd.org/showthread.php?t=3D8565). I think this occurs because FreeBSD could not start the other cores of my CPU (function "start_ap" at "mp_machdep.c"). Does somebody have any clue about this issue? =A0Is there something else I could try? =A0I like FreeBSD a lot, and I'm really looking forward to have FreeBSD running on this machine! :) Thanks a lot!! cheers, Rodolfo From owner-freebsd-arch@FreeBSD.ORG Mon Nov 23 11:06:48 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE2F106566C for ; Mon, 23 Nov 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B1ADE8FC16 for ; Mon, 23 Nov 2009 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nANB6m55070057 for ; Mon, 23 Nov 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nANB6m44070055 for freebsd-arch@FreeBSD.org; Mon, 23 Nov 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Nov 2009 11:06:48 GMT Message-Id: <200911231106.nANB6m44070055@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 23 12:26:55 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8806B1065670 for ; Mon, 23 Nov 2009 12:26:55 +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 4A4568FC0C for ; Mon, 23 Nov 2009 12:26:55 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 17EBD6D41B; Mon, 23 Nov 2009 12:26:54 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DAF74844F2; Mon, 23 Nov 2009 13:26:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Luigi Rizzo References: <20091122111732.GA45909@onelab2.iet.unipi.it> Date: Mon, 23 Nov 2009 13:26:53 +0100 In-Reply-To: <20091122111732.GA45909@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Sun, 22 Nov 2009 12:17:32 +0100") Message-ID: <86d439who2.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: arch@freebsd.org Subject: Re: anyone interested in helping fixing the 'tcc' compiler ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:26:55 -0000 Luigi Rizzo writes: > I have recently started playing with the Tiny C Compuler (lang/tcc) > which is amazingly useful for prototyping, Looks pretty useless to me: des@ds4 /usr/ports/lang/tcc% sudo make install clean Password: =3D=3D=3D> tcc-0.9.25 is only for i386, while you are running amd64. *** Error code 1 > However, from the description it does not seem a horribly > hard problem. Perhaps someone with a bit of knowledge on > how our ld-elf.so works should not have a hard time pinpointing > the problem so that other people can fix it ? Actually, ld-elf.so is not that scary. Take a look at rtld(1) and start setting debugging envars. Set up a jail so you can mess around with the jail's ld-elf.so without bricking your system. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Nov 23 12:57:50 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8839D106568D for ; Mon, 23 Nov 2009 12:57:50 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC188FC12 for ; Mon, 23 Nov 2009 12:57:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C1596730DA; Mon, 23 Nov 2009 14:05:46 +0100 (CET) Date: Mon, 23 Nov 2009 14:05:46 +0100 From: Luigi Rizzo To: Dag-Erling Sm??rgrav Message-ID: <20091123130546.GA69098@onelab2.iet.unipi.it> References: <20091122111732.GA45909@onelab2.iet.unipi.it> <86d439who2.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d439who2.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: anyone interested in helping fixing the 'tcc' compiler ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 12:57:50 -0000 On Mon, Nov 23, 2009 at 01:26:53PM +0100, Dag-Erling Sm??rgrav wrote: > Luigi Rizzo writes: > > I have recently started playing with the Tiny C Compuler (lang/tcc) > > which is amazingly useful for prototyping, > > Looks pretty useless to me: > > des@ds4 /usr/ports/lang/tcc% sudo make install clean > Password: > ===> tcc-0.9.25 is only for i386, while you are running amd64. > *** Error code 1 the message is actually misleading. The code seems to be able to generate code for 64bit and arm. It's just the port that is not enabling the feature. It is also true that the upstream distribution is not very actively maintained so some things may be flakey. > > However, from the description it does not seem a horribly > > hard problem. Perhaps someone with a bit of knowledge on > > how our ld-elf.so works should not have a hard time pinpointing > > the problem so that other people can fix it ? > > Actually, ld-elf.so is not that scary. Take a look at rtld(1) and start > setting debugging envars. Set up a jail so you can mess around with the > jail's ld-elf.so without bricking your system. yeah, i have started doing some things there. First i found that tcc is not generating the PHDR Program Header that freebsd mostly requires. Next, there seems to be some discrepancy on how entries are tagged in the dynamic segment: what on linux is REL i think should become JMPREL or PLTGOT on FreeBSD. Anyways, i am working on it... From owner-freebsd-arch@FreeBSD.ORG Mon Nov 23 23:07:11 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70D33106566B for ; Mon, 23 Nov 2009 23:07:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by mx1.freebsd.org (Postfix) with ESMTP id F3B1F8FC13 for ; Mon, 23 Nov 2009 23:07:10 +0000 (UTC) Received: by bwz20 with SMTP id 20so4507227bwz.14 for ; Mon, 23 Nov 2009 15:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=siYWF3gkhasZbqhf0479jBCZlr5/yZT4kMMMj9QwA58=; b=xVPdYqvAPGAeLTWhlddHd4DXnM4NyXF+wB4sWUdtSWtcy6yjXjbOuyNCSTkS9nJKrN 5+S8k1wEmDNttTVdUF3VkiZQoFlOCICqIrI/BUS64mrCmxJx+G3QFZ41ZCrDgCNFnRut 2OW/rVA/q9NqDPPXnNuNy9LDa7rt6Smj2qAiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=ki9Suol8P5rzRNjHwfQkPT+mkBuNNHJfWA63pgWGFnShEmetBc0zlwbz/Cg6tLfZhE 8YliDw/SuEnLbYslsvBMM6D6+Sfy4ene+0+NAavT3UVzQrad47gfj4OGk6i/31NjBkq0 25mOLUXUqemqyqql6plo0ApPbyi5KJq2UJ/DU= Received: by 10.204.3.211 with SMTP id 19mr5081534bko.153.1259017629793; Mon, 23 Nov 2009 15:07:09 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm1587267fxm.6.2009.11.23.15.07.09 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 15:07:09 -0800 (PST) Sender: Alexander Motin Message-ID: <4B0B159B.9040305@FreeBSD.org> Date: Tue, 24 Nov 2009 01:07:07 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: atausb perspectives X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:07:11 -0000 Hi. At this moment we have two possible ways to support USB mass storages: umass and atausb. First one handles USB mass storage devices as SCSI ones by using CAM infrastructure. It is working and maintained. Second one was made to do the same using ata(4), is reports devices as ATAPI (in fact the same SCSI). But it is out of build since I can remember. Looking on atausb state and ata(4) perspectives generally, I can't find any reason for having atausb in the tree. What is the public opinion, can we just drop it now? -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Tue Nov 24 00:56:20 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9689B1065672; Tue, 24 Nov 2009 00:56:20 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id EE0938FC0C; Tue, 24 Nov 2009 00:56:19 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so1364042qwb.7 for ; Mon, 23 Nov 2009 16:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=C2LBcuGonSWeQ0yrs4v/rtTRH9kG5kbY/KOevrM/Nr0=; b=HvtgnSw8GnxNYb2tMiOdSGzoWt7jEe+JVIRPkvzecvWtJ4+HszQGR6uyUVgKR1Phqc AKtS2+gM99GKpuYvSEfb506bSZ54WskUDSO/wXvZG//QmwN4NT94Y8JZTFy+znMIBixy OjNuaAa8q6Y+7NYQWjXmCUjZRfi+xT3VzR1aM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=DuPd3HEAjd7u3BSpSfDnhgYj0DR5BPKHusbILmQHI/S4PbFX41cTia2UZxFIbNfsrg HW3MgzGFuRPa0M4Np5lKwq42J4aPPwVNciG2lDRxDuGb65BEEiTQa9VYNuN3QChlQjgn 5hkGwrDHgwsrqx954E8ybAu/czGu1Vb120nME= Received: by 10.224.33.195 with SMTP id i3mr2826419qad.386.1259024179372; Mon, 23 Nov 2009 16:56:19 -0800 (PST) Received: from kan.dnsalias.net (c-24-91-218-112.hsd1.ma.comcast.net [24.91.218.112]) by mx.google.com with ESMTPS id 5sm10246187qwg.28.2009.11.23.16.56.17 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 16:56:18 -0800 (PST) Date: Mon, 23 Nov 2009 19:56:11 -0500 From: Alexander Kabaev To: freebsd-arch@freebsd.org Message-ID: <20091123195611.150549a0@kan.dnsalias.net> In-Reply-To: <4B0B159B.9040305@FreeBSD.org> References: <4B0B159B.9040305@FreeBSD.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/VzI7EKpOBd+8Q+=_pke68rn"; protocol="application/pgp-signature" Cc: Alexander Motin Subject: Re: atausb perspectives X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:56:20 -0000 --Sig_/VzI7EKpOBd+8Q+=_pke68rn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Nov 2009 01:07:07 +0200 Alexander Motin wrote: > Hi. >=20 > At this moment we have two possible ways to support USB mass storages: > umass and atausb. First one handles USB mass storage devices as SCSI > ones by using CAM infrastructure. It is working and maintained. Second > one was made to do the same using ata(4), is reports devices as ATAPI > (in fact the same SCSI). But it is out of build since I can remember. >=20 > Looking on atausb state and ata(4) perspectives generally, I can't > find any reason for having atausb in the tree. What is the public > opinion, can we just drop it now? >=20 > --=20 > Alexander Motin I think the rule is simple and well known: if code rots and nobody steps up as a new maintainer, it gets booted out of the tree. Looks like atausb is firmly in that category. Unless someone raises a hand=20 My $0.02 --=20 Alexander Kabaev --Sig_/VzI7EKpOBd+8Q+=_pke68rn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iD8DBQFLCy8wQ6z1jMm+XZYRAgNRAJ4iQxhsQWCIoFuVWc3Ban8LzGdUigCbBrh5 k3h5emolxlRr/H84QR8eKRk= =9OmV -----END PGP SIGNATURE----- --Sig_/VzI7EKpOBd+8Q+=_pke68rn-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 24 09:15:10 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD59106566B for ; Tue, 24 Nov 2009 09:15:10 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 588A38FC15 for ; Tue, 24 Nov 2009 09:15:10 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NCrUG-0007fk-Io for freebsd-arch@freebsd.org; Tue, 24 Nov 2009 10:15:04 +0100 Received: from c-82-209-158-92.cust.bredband2.com ([82.209.158.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Nov 2009 10:15:04 +0100 Received: from mc by c-82-209-158-92.cust.bredband2.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Nov 2009 10:15:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Michael Widerkrantz Date: Tue, 24 Nov 2009 09:46:27 +0100 Organization: Temple of the Moby Hack Lines: 16 Message-ID: <864ookqpi4.fsf@brain.hack.org> References: <20091122111732.GA45909@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-82-209-158-92.cust.bredband2.com User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.3 (berkeley-unix) Cancel-Lock: sha1:8N0Wzb8870yPV6NBuTepo0aBcTY= Sender: news Subject: Re: anyone interested in helping fixing the 'tcc' compiler ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 09:15:10 -0000 Luigi Rizzo , 2009-11-22 12:17 (+0100): > I have recently started playing with the Tiny C Compuler (lang/tcc) > which is amazingly useful for prototyping, but has problem generating > non-static binaries in FreeBSD You might want to look at PCC (lang/pcc) as well if you're only looking for a fast C compiler, although I admit that I was blown away when I read that TCC was used to boot a Linux kernel from source in 15 seconds back in 2004. I also think PCC is in more active development than TCC. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 25 15:08:22 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285DC106566B; Wed, 25 Nov 2009 15:08:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8621D8FC08; Wed, 25 Nov 2009 15:08:21 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id nAPEgBab038887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2009 15:42:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id nAPEg8gM050420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:42:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id nAPEg8Tl062010; Wed, 25 Nov 2009 15:42:08 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id nAPEg8Vo062009; Wed, 25 Nov 2009 15:42:08 +0100 (CET) (envelope-from ticso) Date: Wed, 25 Nov 2009 15:42:08 +0100 From: Bernd Walter To: Peter Jeremy Message-ID: <20091125144208.GZ20716@cicely7.cicely.de> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091120062637.GA49534@server.vk2pj.dyndns.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Rui Paulo , Attilio Rao , FreeBSD Arch , gnn@freebsd.org Subject: Re: [PATCH] Protect inetd and cron from being killed under high-pressure swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:08:22 -0000 On Fri, Nov 20, 2009 at 05:26:37PM +1100, Peter Jeremy wrote: > On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: > >> At Mon, 16 Nov 2009 16:02:08 +0100, > >> Attilio Rao wrote: > >>> > >>> This simple patch protects inetd and cron from being killed under > >>> high-pressure swapping systems: > >>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff > > >Yes, the idea is good, but should we really trust inetd and crond that much ? > >Are there other daemons that do this? > > As an alternative approach, how about placing a wrapper process around > them which will restart them if they die? init(8) unofficially provides > this (I've used it in the past) - maybe we should formalise this. init(8) is nice, but not an option within jails. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 25 17:14:40 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C964106566C for ; Wed, 25 Nov 2009 17:14:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA8D8FC16 for ; Wed, 25 Nov 2009 17:14:40 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D90C29E3DF; Wed, 25 Nov 2009 09:14:39 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id D6F7D2D601A; Wed, 25 Nov 2009 09:14:38 -0800 (PST) Message-ID: <4B0D65FE.9020603@elischer.org> Date: Wed, 25 Nov 2009 09:14:38 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ticso@cicely.de References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> <20091125144208.GZ20716@cicely7.cicely.de> In-Reply-To: <20091125144208.GZ20716@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Attilio Rao , gnn@freebsd.org, FreeBSD Arch Subject: Re: [PATCH] Protect inetd and cron from being killed under high-pressure swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:14:40 -0000 Bernd Walter wrote: > On Fri, Nov 20, 2009 at 05:26:37PM +1100, Peter Jeremy wrote: >> On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: >>>> At Mon, 16 Nov 2009 16:02:08 +0100, >>>> Attilio Rao wrote: >>>>> This simple patch protects inetd and cron from being killed under >>>>> high-pressure swapping systems: >>>>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff >>> Yes, the idea is good, but should we really trust inetd and crond that much ? >>> Are there other daemons that do this? >> As an alternative approach, how about placing a wrapper process around >> them which will restart them if they die? init(8) unofficially provides >> this (I've used it in the past) - maybe we should formalise this. > > init(8) is nice, but not an option within jails. we are considering whether a jail should have its own init... > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 05:21:37 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 254AC106566C for ; Thu, 26 Nov 2009 05:21:37 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id D70E68FC0C for ; Thu, 26 Nov 2009 05:21:36 +0000 (UTC) Received: from gonzo by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NDWQC-0007jO-LS; Thu, 26 Nov 2009 06:57:36 +0200 Date: Thu, 26 Nov 2009 06:57:36 +0200 From: Oleksandr Tymoshenko To: arch@freebsd.org Message-ID: <20091126045736.GA25431@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/7.0-STABLE (i386) User-Agent: Mutt/1.5.20 (2009-06-14) Cc: embedded@frebsd.org Subject: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:21:37 -0000 Recently I've been working on GPIO framework that, I believe, is much needed for embedded applications of FreeBSD. Now framework is mature enough to show it to the world, so this is my request for review. Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff sys/gpio.h is based on the same file from NetBSD but all the other files have been written from the scratch. Description: GPIO stands for General Purpose Input/Output. This interface may be thought of as a set of pins which could serve as input or output having logical 0 and logical 1 as their values (some other options are applicable, but they're not crucial for this explanation). Most common usage of GPIO interface is LED and button control for various SoCs. Architecture: I tried to separate hardware implementation from logic as much as possible. All the HW-independent stuff resides in sys/dev/gpio directory. It consists of gpioc (GPIO controller device), gpiobus (bus that manages devices attached to GPIO controller) and gpioled (implementation of LED driver that illustrates usage pattern of gpiobus, utilizes led(4) interface). HW-dependent part might be a part of SoC, I2C extender, whatever. It should implement interface defined in sys/dev/gpio/gpio_if.m: gpio_pin_max - get maximum pin available gpio_pin_getcaps - get capabilities for given pin gpio_pin_getflags - get flags for given pin gpio_pin_setflags - set flags for given pin gpio_pin_getname - get pin name (if any) gpio_pin_set - set pin value gpio_pin_get - get pin value gpio_pin_toggle - toggle(invert) pin value And on attaching HW driver should add gpioc and gpiobus as its children. gpioc creates /dev/gpiocX entry that is used by gpioctl application for managing GPIO pins using following ioctls: GPIOMAXPIN - get maximum pin available GPIOGETCONFIG - get flags/capabilities/name for given pin GPIOSETCONFIG - set flags for given pin GPIOGET - get pin value GPIOSET - set pin value GPIOTOGGLE - toggle(invert) pin value gpioctl usage: gpioctl -f ctldev -l [-v] gpioctl -f ctldev -t pin gpioctl -f ctldev -c pin flag ... gpioctl -f ctldev pin [0|1] gpiobus manages devices attached to gpio controller. Its interface is a subset of of gpio_if.m interface and allows child devices talk to GPIO controller. At the moment children could be set only by hints file and pin space is limited to 32. Example: # RF led hint.gpioled.0.at="gpiobus0" hint.gpioled.0.name="rf" # pin 2 hint.gpioled.0.pins=0x0004 Interface functions: gpiobus_pin_getcaps - get capabilities for given pin gpiobus_pin_getflags - get flags for given pin gpiobus_pin_setflags - set flags for given pin gpiobus_pin_set - set pin value gpiobus_pin_get - get pin value gpiobus_pin_toggle - toggle(invert) pin value Reference implementation of child device is sys/dev/gpio/gpioled.c It provides on/off function for led(4) API Any comments/feedback are welcome -- gonzo From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 06:18:06 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928ED1065676; Thu, 26 Nov 2009 06:18:06 +0000 (UTC) (envelope-from freebsd-arch@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 355528FC0C; Thu, 26 Nov 2009 06:18:05 +0000 (UTC) Received: from via.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Thu, 26 Nov 2009 07:03:55 +0100 id 0002E094.4B0E1A4B.000032D3 From: Milan Obuch To: freebsd-arch@freebsd.org Date: Thu, 26 Nov 2009 07:07:02 +0100 User-Agent: KMail/1.9.10 References: <20091126045736.GA25431@bluezbox.com> In-Reply-To: <20091126045736.GA25431@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911260707.03168.freebsd-arch@dino.sk> Cc: Oleksandr Tymoshenko Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 06:18:06 -0000 On Thursday 26 November 2009 05:57:36 Oleksandr Tymoshenko wrote: > Recently I've been working on GPIO framework that, I believe, > is much needed for embedded applications of FreeBSD. Now framework > is mature enough to show it to the world, so this is my request > for review. > > Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff > sys/gpio.h is based on the same file from NetBSD but all the other > files have been written from the scratch. > I was working some time ago on something similar, but did not have enough time to make it able to show to public, then lost it in some disk crash or some such. Nevertheless, my work was based on some older gio work, probably for 4-something, available on the web somewhere (I have no URL now at hand), and OpenBSD implementation. They differed in one area - one implementation used bit array for pins' internal structure, the other some linked list structure, what makes it easy to build a non-contiguous pin array. I am not sure which one was used in my implementation then... I try to find it - somewhere on my disks or CFs. Anyway, I will try to look at your work in next amount of my free time and comment on the code side, if I will have anything, but now, some general comments on your mail. I have some WRAP boards, where some GPIOs are used to drive three status LEDs and attach a soft reset button, add-on board with LPC SuperIO chip with some tens of GPIOs and some other SuperIOs where I can test things, x86 based. Also there are some PRs open for NSLU2 (ARM SoC based), where some GPIOs are used for LEDs and button(s), too. You might consider them too, if you did not already. I can test something for NSLU2, too, but I did not manage to master it completely yet. And, one more general note, I found GPIOs are used internally in many various add-on cards, like atheros based wireless adapters (ath driver), various TV grabber cards - mostly for i2c setting of tuner parameters etc. Usefullness of covering these with general GPIO framework should be considered, though. > Description: > > GPIO stands for General Purpose Input/Output. This interface may be > thought of as a set of pins which could serve as input or output > having logical 0 and logical 1 as their values (some other options > are applicable, but they're not crucial for this explanation). > Most common usage of GPIO interface is LED and button control for > various SoCs. > > Architecture: > > I tried to separate hardware implementation from logic as much as > possible. All the HW-independent stuff resides in sys/dev/gpio > directory. It consists of gpioc (GPIO controller device), > gpiobus (bus that manages devices attached to GPIO controller) > and gpioled (implementation of LED driver that illustrates usage > pattern of gpiobus, utilizes led(4) interface). > I was able to build and think it is still usefull to add gpioi2c. It worked for me well as a bit banged replacement for geode's access.bus controller, which I was unable to use directly, but that's another story. I think it is usefull addition. > HW-dependent part might be a part of SoC, I2C extender, whatever. > It should implement interface defined in sys/dev/gpio/gpio_if.m: > gpio_pin_max - get maximum pin available > gpio_pin_getcaps - get capabilities for given pin > gpio_pin_getflags - get flags for given pin > gpio_pin_setflags - set flags for given pin > gpio_pin_getname - get pin name (if any) > gpio_pin_set - set pin value > gpio_pin_get - get pin value > gpio_pin_toggle - toggle(invert) pin value > And on attaching HW driver should add gpioc and gpiobus as its > children. > Did you think about ability to use interrupt abilities of GPIO? In my work I added a hook to call a script via devd for pins selected (a special flag or something). This way it is easy to execute a script on a button press. > gpioc creates /dev/gpiocX entry that is used by gpioctl application > for managing GPIO pins using following ioctls: > GPIOMAXPIN - get maximum pin available > GPIOGETCONFIG - get flags/capabilities/name for given pin > GPIOSETCONFIG - set flags for given pin > GPIOGET - get pin value > GPIOSET - set pin value > GPIOTOGGLE - toggle(invert) pin value > gpioctl usage: > gpioctl -f ctldev -l [-v] > gpioctl -f ctldev -t pin > gpioctl -f ctldev -c pin flag ... > gpioctl -f ctldev pin [0|1] > > gpiobus manages devices attached to gpio controller. Its interface > is a subset of of gpio_if.m interface and allows child devices talk > to GPIO controller. At the moment children could be set only by hints > file and pin space is limited to 32. Example: > > # RF led > hint.gpioled.0.at="gpiobus0" > hint.gpioled.0.name="rf" > # pin 2 > hint.gpioled.0.pins=0x0004 > > Interface functions: > gpiobus_pin_getcaps - get capabilities for given pin > gpiobus_pin_getflags - get flags for given pin > gpiobus_pin_setflags - set flags for given pin > gpiobus_pin_set - set pin value > gpiobus_pin_get - get pin value > gpiobus_pin_toggle - toggle(invert) pin value > > Reference implementation of child device is sys/dev/gpio/gpioled.c > It provides on/off function for led(4) API > > Any comments/feedback are welcome It's all for now, but I hope I showed I am definitely interested in such a framework being incorporated in FreeBSD. When time permits, I will work a bit on it, too. Regards, Milan From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 07:51:42 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35D841065672 for ; Thu, 26 Nov 2009 07:51:42 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id E588E8FC17 for ; Thu, 26 Nov 2009 07:51:41 +0000 (UTC) Received: from [24.87.52.209] (helo=lair.bluezbox.com) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NDYgn-000B2m-Qo; Thu, 26 Nov 2009 09:22:56 +0200 Message-ID: <4B0E2C8D.1090700@bluezbox.com> Date: Wed, 25 Nov 2009 23:21:49 -0800 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Milan Obuch References: <20091126045736.GA25431@bluezbox.com> <200911260707.03168.freebsd-arch@dino.sk> In-Reply-To: <200911260707.03168.freebsd-arch@dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 07:51:42 -0000 Milan Obuch wrote: > On Thursday 26 November 2009 05:57:36 Oleksandr Tymoshenko wrote: > > Anyway, I will try to look at your work in next amount of my free time and > comment on the code side, if I will have anything, but now, some general > comments on your mail. I have some WRAP boards, where some GPIOs are used to > drive three status LEDs and attach a soft reset button, add-on board with LPC > SuperIO chip with some tens of GPIOs and some other SuperIOs where I can test > things, x86 based. Thanks, I'd appreciate it. > Also there are some PRs open for NSLU2 (ARM SoC based), where some GPIOs are > used for LEDs and button(s), too. You might consider them too, if you did not > already. I can test something for NSLU2, too, but I did not manage to master > it completely yet. > > And, one more general note, I found GPIOs are used internally in many various > add-on cards, like atheros based wireless adapters (ath driver), various TV > grabber cards - mostly for i2c setting of tuner parameters etc. Usefullness > of covering these with general GPIO framework should be considered, though. Yes, I'm aware of this kind of GPIO use. Not sure how it fit into device tree model though. May be some additional API calls will be required. > Did you think about ability to use interrupt abilities of GPIO? In my work I > added a hook to call a script via devd for pins selected (a special flag or > something). This way it is easy to execute a script on a button press. Yes, I thought about it but postponed for next stage. My idea was to have ioctl that would block waiting for interrupt but I like your devd approach better. Thanks! Looking forward to you review and feedback. -- gonzo From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 08:27:08 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0032C1065676 for ; Thu, 26 Nov 2009 08:27:07 +0000 (UTC) (envelope-from freebsd-arch@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0658FC15 for ; Thu, 26 Nov 2009 08:27:06 +0000 (UTC) Received: from via.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Thu, 26 Nov 2009 09:27:05 +0100 id 0002E094.4B0E3BD9.00003985 From: Milan Obuch To: freebsd-arch@freebsd.org Date: Thu, 26 Nov 2009 09:26:59 +0100 User-Agent: KMail/1.9.10 References: <20091126045736.GA25431@bluezbox.com> <200911260707.03168.freebsd-arch@dino.sk> <4B0E2C8D.1090700@bluezbox.com> In-Reply-To: <4B0E2C8D.1090700@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911260927.00787.freebsd-arch@dino.sk> Cc: Oleksandr Tymoshenko Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:27:08 -0000 On Thursday 26 November 2009 08:21:49 Oleksandr Tymoshenko wrote: Only small add-on - in my mail archives I found this link http://www.nano-system.com/cgi-bin/cvsweb.cgi/freebsd/kernel/dev/gpiobus/ I looked over there in the past and probably used it as an inspiration. Also, there is lm75 driver able to work on gpio as well (i2c temperature sensor). I still need to find my older work (or some traces of it) - for some reason CF used for debugging on WRAP does not boot any more, but I saved some images somewhere, so it is still possible, given some time is available... Milan From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 09:16:42 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793631065679; Thu, 26 Nov 2009 09:16:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id AD0198FC13; Thu, 26 Nov 2009 09:16:41 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=HegQLxz4BK_eN1qGPMUA:9 a=qedAMZySXq26Xl73EcrYT6v6cbcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1169560490; Thu, 26 Nov 2009 09:16:37 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 26 Nov 2009 09:18:14 +0100 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091126045736.GA25431@bluezbox.com> In-Reply-To: <20091126045736.GA25431@bluezbox.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911260918.15169.hselasky@c2i.net> Cc: Oleksandr Tymoshenko , embedded@frebsd.org Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 09:16:42 -0000 On Thursday 26 November 2009 05:57:36 Oleksandr Tymoshenko wrote: > Recently I've been working on GPIO framework that, I believe, > is much needed for embedded applications of FreeBSD. Now framework > is mature enough to show it to the world, so this is my request > for review. > > Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff > sys/gpio.h is based on the same file from NetBSD but all the other > files have been written from the scratch. > > Description: > > GPIO stands for General Purpose Input/Output. This interface may be > thought of as a set of pins which could serve as input or output > having logical 0 and logical 1 as their values (some other options > are applicable, but they're not crucial for this explanation). > Most common usage of GPIO interface is LED and button control for > various SoCs. > > Architecture: > > I tried to separate hardware implementation from logic as much as > possible. All the HW-independent stuff resides in sys/dev/gpio > directory. It consists of gpioc (GPIO controller device), > gpiobus (bus that manages devices attached to GPIO controller) > and gpioled (implementation of LED driver that illustrates usage > pattern of gpiobus, utilizes led(4) interface). > > HW-dependent part might be a part of SoC, I2C extender, whatever. > It should implement interface defined in sys/dev/gpio/gpio_if.m: > gpio_pin_max - get maximum pin available > gpio_pin_getcaps - get capabilities for given pin > gpio_pin_getflags - get flags for given pin > gpio_pin_setflags - set flags for given pin > gpio_pin_getname - get pin name (if any) > gpio_pin_set - set pin value > gpio_pin_get - get pin value > gpio_pin_toggle - toggle(invert) pin value > And on attaching HW driver should add gpioc and gpiobus as its > children. > > gpioc creates /dev/gpiocX entry that is used by gpioctl application > for managing GPIO pins using following ioctls: > GPIOMAXPIN - get maximum pin available > GPIOGETCONFIG - get flags/capabilities/name for given pin > GPIOSETCONFIG - set flags for given pin > GPIOGET - get pin value > GPIOSET - set pin value > GPIOTOGGLE - toggle(invert) pin value > gpioctl usage: > gpioctl -f ctldev -l [-v] > gpioctl -f ctldev -t pin > gpioctl -f ctldev -c pin flag ... > gpioctl -f ctldev pin [0|1] > > gpiobus manages devices attached to gpio controller. Its interface > is a subset of of gpio_if.m interface and allows child devices talk > to GPIO controller. At the moment children could be set only by hints > file and pin space is limited to 32. Example: > > # RF led > hint.gpioled.0.at="gpiobus0" > hint.gpioled.0.name="rf" > # pin 2 > hint.gpioled.0.pins=0x0004 > > Interface functions: > gpiobus_pin_getcaps - get capabilities for given pin > gpiobus_pin_getflags - get flags for given pin > gpiobus_pin_setflags - set flags for given pin > gpiobus_pin_set - set pin value > gpiobus_pin_get - get pin value > gpiobus_pin_toggle - toggle(invert) pin value > > Reference implementation of child device is sys/dev/gpio/gpioled.c > It provides on/off function for led(4) API > > Any comments/feedback are welcome Are there any functions to setup interrupts on GPIO pins? --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 13:59:34 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BCCA106566C; Thu, 26 Nov 2009 13:59:34 +0000 (UTC) (envelope-from ed@80386.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A0EB58FC15; Thu, 26 Nov 2009 13:59:33 +0000 (UTC) Received: from [10.0.0.12] (d83-180-9-80.cust.tele2.nl [83.180.9.80]) (Authenticated sender: ed) by palm.hoeg.nl (Postfix) with ESMTPSA id 7C0F21CCF3; Thu, 26 Nov 2009 14:59:32 +0100 (CET) References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> <20091125144208.GZ20716@cicely7.cicely.de> <4B0D65FE.9020603@elischer.org> Message-Id: From: Ed Schouten To: Julian Elischer In-Reply-To: <4B0D65FE.9020603@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (7D11) Mime-Version: 1.0 (iPod Mail 7D11) Date: Thu, 26 Nov 2009 14:59:38 +0100 Cc: Rui Paulo , Attilio Rao , FreeBSD Arch , "ticso@cicely.de" , "gnn@freebsd.org" Subject: Re: [PATCH] Protect inetd and cron from being killed under high-pressure swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 13:59:34 -0000 That would be very useful. That would allow us to run gettys inside jails as well. -- Ed Schouten (from iPod) WWW: http://80386.nl/ On 25 nov 2009, at 18:14, Julian Elischer wrote: > Bernd Walter wrote: >> On Fri, Nov 20, 2009 at 05:26:37PM +1100, Peter Jeremy wrote: >>> On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: >>>>> At Mon, 16 Nov 2009 16:02:08 +0100, >>>>> Attilio Rao wrote: >>>>>> This simple patch protects inetd and cron from being killed under >>>>>> high-pressure swapping systems: >>>>>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff >>>> Yes, the idea is good, but should we really trust inetd and crond >>>> that much ? >>>> Are there other daemons that do this? >>> As an alternative approach, how about placing a wrapper process >>> around >>> them which will restart them if they die? init(8) unofficially >>> provides >>> this (I've used it in the past) - maybe we should formalise this. >> init(8) is nice, but not an option within jails. > > we are considering whether a jail should have its own init... > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch- > unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 16:48:15 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C13481065670 for ; Thu, 26 Nov 2009 16:48:15 +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 9C0B48FC18 for ; Thu, 26 Nov 2009 16:48:15 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Nov 2009 08:36:15 -0800 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E021D4CFC@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Protect inetd and cron from being killedunder high-pressure swapping Thread-Index: AcpuoMk1f9AasAmlSRCd5CUHgCp2IgAFQcFW References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> <20091125144208.GZ20716@cicely7.cicely.de> <4B0D65FE.9020603@elischer.org> From: "Matthew Fleming" To: "Ed Schouten" , "Julian Elischer" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Rui Paulo , Attilio Rao , gnn@freebsd.org, ticso@cicely.de, FreeBSD Arch Subject: RE: [PATCH] Protect inetd and cron from being killedunder high-pressure swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 16:48:15 -0000 > we are considering whether a jail should have its own init... Just FYI: The AIX version of jails each had their own init process. I wasnt = directly working on that project/team, so I dont know all the details. = The only thing I remember was a few bugs my co-workers mentioned: first = there were several places that assumed init was pid 1, and they all = needed changing. Second was I think some weird issues managing when the = jails init was supposed to actually quit. Last, when AIX wanted to send = a signal to a processs parent like SIGCHILD, AIX needed to be careful = which init to send it to for unparented processes, otherwise an init = would get a signal for a process id it couldnt actually see. Cheers, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Nov 26 17:26:31 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5991065670 for ; Thu, 26 Nov 2009 17:26:31 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id E53348FC15 for ; Thu, 26 Nov 2009 17:26:30 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.5.136]) by core.tav.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1NDhac-000OOQ-L9; Thu, 26 Nov 2009 18:53:07 +0200 Message-ID: <4B0EB245.2060408@freebsd.org> Date: Thu, 26 Nov 2009 08:52:21 -0800 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hans Petter Selasky References: <20091126045736.GA25431@bluezbox.com> <200911260918.15169.hselasky@c2i.net> In-Reply-To: <200911260918.15169.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Core-Spam-Level: / X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > > Are there any functions to setup interrupts on GPIO pins? Not at the moment, but I plan to add interrupt support later. [...] Content analysis details: (0.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 4.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% [score: 0.9774] -1.4 AWL AWL: From: address is in the auto white-list Cc: embedded@frebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] GPIO framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:26:31 -0000 > > Are there any functions to setup interrupts on GPIO pins? Not at the moment, but I plan to add interrupt support later. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 27 23:42:52 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09B7106566B; Fri, 27 Nov 2009 23:42:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA28FC13; Fri, 27 Nov 2009 23:42:51 +0000 (UTC) Received: by fxm10 with SMTP id 10so1711821fxm.14 for ; Fri, 27 Nov 2009 15:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Wq48v7fmzzDIQzSlnDOCmbKM4qslUIBLa8EWscNUX1I=; b=gbw78aa8RiFvUuv+xi40sqhyLypcWc69GwsK0HfU+o8cWfpMHTl9b2iTeyFLibiCxo sLXmb3CI+bOeuvUuMTVy/2hYl2N+aCh2otMyJOC9mGbsyOfvYNeZy+AKw4Ysi6VifWfD 5jS5n/L3myzd7KfSiXitpT/T1S7AIHa+m56UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=R4S1tlP7lf+G9pcLTEDmsYvLQfdLAdPFEV/urjJSh6ApwGHuYcruSugqGuMIz51jc9 iykrNXnaxRMr0Rj7O/UJw39ibbELUhdT3FJy4YbDedmtwbrhLPMqyQiHBk6PPB37F6pA wCGpf9Io7LFJCz2wXcl0Nz6FVEXHhQl8ENRNo= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.144.195 with SMTP id a3mr250837fav.103.1259365370823; Fri, 27 Nov 2009 15:42:50 -0800 (PST) Date: Sat, 28 Nov 2009 00:42:50 +0100 X-Google-Sender-Auth: c81e84e93859ad00 Message-ID: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> From: Attilio Rao To: FreeBSD Arch , John Baldwin , Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: Subject: [PATCH] Statclock aliasing by LAPIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 23:42:52 -0000 Handling all the three clocks (hardclock, softclock, profclock) within the LAPIC can lead to aliasing for the softclock and profclock because hz is sized to fit mainly hardclock. The fashion to handle all of them within the LAPIC was introduced in 2005 and before than the softclock and profclock were supposed to be handled in the rtc. Right now, too, there is the necessary support to handle profclock and statclock in atrtc which gets enabled if the LAPIC signals it can't take in charge the three clocks. The proposed patch reverts the situation preferring the atrtc to handle the statclock and profclock (then a different source from the LAPIC) and then avoid the aliasing problem: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/statclock_aliasing/statclock_aliasing3.diff In this patch, lapic_setup_clock() has been changed in order to return a three-states variable which identified if the LAPIC got in charge all the three clocks, just the hardclock or none of them (the current situation is just none/all) and the rtc handling runs subsequently. A tunable as been added to force LAPI to get in charge all the three clocks if needed. In ia32 atrtc compiling is linked to atpic compiling, so a compile time flag has been added to check if atpic is not present and in case force LAPIC to take in charge all the three clocks (which is still better than the 'safe belt values' still present in the rtc code). Please note that statclock and profclock are widely used in our kernel (rusage is, for example, statclock driven) and fixing this would result in specific improvements (as a several-reported wrong CPU usage statistic in top). This bug has been found by Sandvine Incorporated. Reviews, comments and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Nov 28 00:21:37 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0128310656A4 for ; Sat, 28 Nov 2009 00:21:37 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 95CE08FC14 for ; Sat, 28 Nov 2009 00:21:36 +0000 (UTC) Received: from [76.77.86.2] (helo=[10.80.5.136]) by expo.ukrweb.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NEAmp-000O3y-S4; Sat, 28 Nov 2009 02:03:42 +0200 Message-ID: <4B1068AE.9020806@bluezbox.com> Date: Fri, 27 Nov 2009 16:02:54 -0800 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Balmer References: <20091127204603.GA81260@bluezbox.com> <4B10450F.4020004@msys.ch> In-Reply-To: <4B10450F.4020004@msys.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, embedded@freebsd.org Subject: Re: [gonzo@freebsd.org: [RFC] GPIO framework] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 00:21:37 -0000 Marc Balmer wrote: > Oleksandr Tymoshenko schrieb: >> Forwarding RFC to embedded@ because there was typo in Cc address in >> the original message :( >> >> ----- Forwarded message from Oleksandr Tymoshenko >> ----- >> >> Date: Thu, 26 Nov 2009 06:57:36 +0200 >> From: Oleksandr Tymoshenko >> To: arch@freebsd.org >> Cc: embedded@frebsd.org >> Subject: [RFC] GPIO framework >> User-Agent: Mutt/1.5.20 (2009-06-14) >> >> Recently I've been working on GPIO framework that, I believe, is much >> needed for embedded applications of FreeBSD. Now framework >> is mature enough to show it to the world, so this is my request for >> review. >> >> Patch: http://people.freebsd.org/~gonzo/mips/gpio.diff >> sys/gpio.h is based on the same file from NetBSD but all the other >> files have been written from the scratch. > > why that? Because the hard stuff is hwpart <-> bus <-> devices hierarchy and their interoperability. For these I wanted to use kobj/newbus API and it's not available in NetBSD. The rest of the code is relatively simple. >> Description: >> >> GPIO stands for General Purpose Input/Output. This interface may be >> thought of as a set of pins which could serve as input or output >> having logical 0 and logical 1 as their values (some other options >> are applicable, but they're not crucial for this explanation). >> Most common usage of GPIO interface is LED and button control for >> various SoCs. > > we do much more, since years: we attach I2C buses over GPIO, or 1-Wire > buses. GPIO is not just for LEDs. I know, these two were picked as an example. >> Reference implementation of child device is sys/dev/gpio/gpioled.c >> It provides on/off function for led(4) API >> >> Any comments/feedback are welcome >> > > it suffers from the same problems my implementation in other BSD > suffers: No interrupt capabilities, no capability to build buses wider > than 1 bit. Adding interrupts should not be an issue. Child devices setup handlers on gpiobus using bus_setup_intr. HW implementation catches interrupts and reports pins to gpiobus via GPIOBUS_INTR() method and then bus dispatches interrupts to child devices. There might be some hidden pitfalls but I can't tell them from the top of my head. Some additional info on interrupts/userland interaction here: http://lists.freebsd.org/pipermail/freebsd-arch/2009-November/009711.html Could you elaborate on multi-bit buses? I'm not well acquainted with this area so any examples would help :) > your gpioctl command line syntax is not nice. Why? Since there is no need for complex rule language as in, for instance, ipfw I decided to use traditional getopt approach. > I suggest you take a closer look at gpio in NetBSD and that we work > together on this. My offer stands. I appreciate your offer but as it was mentioned above the most vital part is not OS-independent and it makes adopting NetBSD gpio framework somewhat complicated. Having ioctl-wise compatibility may turn out useful though. I'll think about it. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 28 18:49:42 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F0281065672 for ; Sat, 28 Nov 2009 18:49:42 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id B7EAE8FC08 for ; Sat, 28 Nov 2009 18:49:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 39409730DA; Sat, 28 Nov 2009 19:57:45 +0100 (CET) Date: Sat, 28 Nov 2009 19:57:45 +0100 From: Luigi Rizzo To: arch@freebsd.org Message-ID: <20091128185745.GA7612@onelab2.iet.unipi.it> References: <20091122111732.GA45909@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20091122111732.GA45909@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: [[atch] Re: anyone interested in helping fixing the 'tcc' compiler ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 18:49:42 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline followup to myself due to scarce success... I have done some partial step in fixing the ELF produced by tcc to work with freebsd. A patch is attached which works for simple programs but not for more complex ones. I found the following problems: - tcc does not produce a PHDR program header, which caused the linker to fail. This should be fixed by this patch. - the relocation sections produced by tcc apparently include a mix of JMP and non JMP relocations in the same place. Our loader complains when it finds this mix. I have changed the section definitions but it seems to work only for simple things (Hello World -style). - the relocation info is not in the place rtld is looking for. What i found is that UNDEF symbols had the offset to be patched in the dynsym section, instead of the .got section where (apparently) our loader is looking for. The function patch_dynsym_undef() in the patch attached seems to handle this, but I am not sure how general is this. With this patch the simplest example programs (ex1, ex2, ex3, ex5) do work, but ex4 (which uses -lX11) fails to load ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/i386/reloc.c:292 (I hope i can track this later). cheers luigi On Sun, Nov 22, 2009 at 12:17:32PM +0100, Luigi Rizzo wrote: > Hi, > I have recently started playing with the Tiny C Compuler (lang/tcc) > which is amazingly useful for prototyping, but has problem generating > non-static binaries in FreeBSD -- basically it produces a bogus > elf file which our loader does not like. > Static binaries work fine, as well as 'tcc -run ' (compile > and run on the fly -- you should really try it if you haven't yet). > > There is an open PR on this > > http://www.freebsd.org/cgi/query-pr.cgi?pr=138481 > > and the problem is known upstream but no fix > > http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html > > However, from the description it does not seem a horribly > hard problem. Perhaps someone with a bit of knowledge on > how our ld-elf.so works should not have a hard time pinpointing > the problem so that other people can fix it ? > > Any takers ? > > cheers > luigi --Nq2Wo0NMKNjxTN9z--