From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 00:05:21 2008 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 E364516A417 for ; Sun, 17 Feb 2008 00:05:21 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id A6F7113C469 for ; Sun, 17 Feb 2008 00:05:21 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 36E0C1DE; Sat, 16 Feb 2008 17:50:01 -0600 (CST) Date: Sat, 16 Feb 2008 17:50:01 -0600 From: "Christian S.J. Peron" To: d@delphij.net Message-ID: <20080216235001.GA80694@sub.vaned.net> References: <47B1F8B7.7030803@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B1F8B7.7030803@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 00:05:22 -0000 On Tue, Feb 12, 2008 at 11:51:19AM -0800, Xin LI wrote: [..] > > Hi, > > Is there anyone working on valgrind on newer FreeBSD releases, or some > work-alikes? > > Cheers, Yes, check out the //depot/projects/valgrind/... perforce project. It works pretty well. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 09:59:07 2008 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 A9E7216A420 for ; Sun, 17 Feb 2008 09:59:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4911F13C467 for ; Sun, 17 Feb 2008 09:59:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id BC98743D547 for ; Sun, 17 Feb 2008 11:59:04 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id G2UtYR+sNgJT for ; Sun, 17 Feb 2008 11:59:04 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3790D43D52E for ; Sun, 17 Feb 2008 11:59:04 +0200 (EET) Message-ID: <47B8055C.4060305@icyb.net.ua> Date: Sun, 17 Feb 2008 11:58:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <47B4A514.1020103@icyb.net.ua> In-Reply-To: <47B4A514.1020103@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: cpu stats and another interrupt question 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, 17 Feb 2008 09:59:07 -0000 Come on, guys, simple yes or no would be enough for me :-) on 14/02/2008 22:31 Andriy Gapon said the following: > Dear hackers, > I'd like to check with you if my understanding of some code is correct. > > If we speak about a typical older i386 system, with UP and "AT" PIC, I > think this is how the CPU utilization stats are collected. > RTC is configured to generate interrupts (IRQ8) 128 times per second. > Each time interrupt is generated RTC interrupt handler (I will use > simple non technical terms) takes a peek at what was interrupted and > depending on the properties of that thing (kernel thread) bills a tick > to particular category. E.g. if it sees that the "idle" thread is > interrupted then a tick is billed to "idle", if an interrupt thread is > interrupted (software or hardware) then a tick is billed to interrupt, > if a thread is running user-mode code then a tick is billed to "user" or > "nice", otherwise it's "system". > I understand that I oversimplify, but is the above correct in general ? > > Another, unrelated, question. > Considering this snippet from sys/i386/isa/atpic.c, i8259_init(): > #ifndef PC98 > /* OCW2_L1 sets priority order to 3-7, 0-2 (com2 first). */ > if (!slave) > outb(pic->at_ioaddr, OCW2_R | OCW2_SL | OCW2_L1); > #endif > > Do I understand correctly the code and the comment that here we use a > feature of 8259 PIC that can be called "cyclic shift of interrupt > priorities" ? > So, we really have the following order of interrupts, from higher > priority to lower: 3-7,0,1,8-15? Considering two chained 8259s, of course. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 15:41:58 2008 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 6CFB116A419 for ; Sun, 17 Feb 2008 15:41:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E3F3013C455 for ; Sun, 17 Feb 2008 15:41:57 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 86FC343F601 for ; Sun, 17 Feb 2008 17:41:56 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id BqORwUrNqEpk for ; Sun, 17 Feb 2008 17:41:56 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DA46043F600 for ; Sun, 17 Feb 2008 17:41:55 +0200 (EET) Message-ID: <47B855C0.4010703@icyb.net.ua> Date: Sun, 17 Feb 2008 17:41:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: multiple interrupts between cli and sti 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, 17 Feb 2008 15:41:58 -0000 The following question might more relevant to some different mailing list that is not freebsd-specific, but I think my chances are pretty high here too. I read a bunch of docs on x86, on interrupts and a spec of 8259A. And while I think I have a pretty good idea how interrupts work in x86-based system in most case, there is one case that puzzles me. Let's consider the following scenario. Environment: i386 system, 8259A PIC, default interrupt priorities, no auto-eoi. 1. cpu executes cli, from now maskable interrupts are masked 2. an interrupt of lower priority occurs (say irq1) 2.1. 8259A sets the corresponding IRR bit and asserts cpu interrupt line 2.2. cpu goes on with whatever it is doing 3. another interrupt, with higher priority occurs (say irq0) 3.1. 8259A sees that it's a higher priority interrupt, sets another bit in IRR, does some magic on the cpu interrupt line, in the end it is still asserted 3.2. cpu goes on with whatever it is doing 4. cpu executes sti 4.1. interrupts are unmasked 4.2. cpu sees interrupt line status, "conversation" with the PIC takes place 4.3. PIC provides cpu with vector number of pending interrupt request with the highest priority (irq0 in our example), sets ISR bit 4.4. cpu executes interrupt handler through interrupt gate, so interrupts are masked again 4.5. current interrupt handler does its job and signal EOI to PIC, PIC clears the ISR bit 4.6. current interrupt handler finishes via iret unmasking interrupts again And here's what I am fuzzy about. Upon getting EOI for current interrupt PIC should interrupt processor again, so that it serves the second pending interrupt. Am I correct ? How fast does this happen? Is there a window for the processor to return to executing whatever it had before the first interrupt ? I mean, will it be: ... -> iret -> xxx -> xxx -> interrupted again or ... -> iret -> interrupted again Is this a deterministic behavior ? Or some timings are at play? Thank you in advance. I hope this was not a too trivial or too boring question :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 16:46:26 2008 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 1A95116A420 for ; Sun, 17 Feb 2008 16:46:26 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.32]) by mx1.freebsd.org (Postfix) with SMTP id 3893013C465 for ; Sun, 17 Feb 2008 16:46:24 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 19680 invoked from network); 17 Feb 2008 16:19:43 -0000 Received: from adsl246.dyn234.pacific.net.sg (HELO P2120.somewherefaraway.com) (oceanare@210.24.234.246) by smtpgate2.pacific.net.sg with ESMTPA; 17 Feb 2008 16:19:42 -0000 Message-ID: <47B85E92.9010206@pacific.net.sg> Date: Mon, 18 Feb 2008 00:19:30 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Andriy Gapon References: <47B855C0.4010703@icyb.net.ua> In-Reply-To: <47B855C0.4010703@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: multiple interrupts between cli and sti 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, 17 Feb 2008 16:46:26 -0000 Hi, Andriy Gapon wrote: I cannot tell you if this is still the same for modern designs. > ... -> iret -> interrupted again This was the behaviour earlier. > > Is this a deterministic behavior ? Or some timings are at play? The PIC should never release the Interrupt signal to the CPU as long as a single interrupt is not serviced. But the 8259 can be programmed to trigger via level or slope. So, this behaviour is only seen when level triggering is used. As I said at the bginning, I do not know how current designs handle it. Erich From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 17:09:58 2008 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 AB48C16A418 for ; Sun, 17 Feb 2008 17:09:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 60CA413C4CC for ; Sun, 17 Feb 2008 17:09:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 6AB22744005; Sun, 17 Feb 2008 19:09:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id y06v9k6xmSJR; Sun, 17 Feb 2008 19:09:57 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id C4A36744004; Sun, 17 Feb 2008 19:09:56 +0200 (EET) Message-ID: <47B86A63.1040205@icyb.net.ua> Date: Sun, 17 Feb 2008 19:09:55 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Erich Dollansky References: <47B855C0.4010703@icyb.net.ua> <47B85E92.9010206@pacific.net.sg> In-Reply-To: <47B85E92.9010206@pacific.net.sg> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: multiple interrupts between cli and sti 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, 17 Feb 2008 17:09:58 -0000 on 17/02/2008 18:19 Erich Dollansky said the following: > Hi, > > Andriy Gapon wrote: > > I cannot tell you if this is still the same for modern designs. > >> ... -> iret -> interrupted again > > This was the behaviour earlier. >> Is this a deterministic behavior ? Or some timings are at play? > > The PIC should never release the Interrupt signal to the CPU as long as > a single interrupt is not serviced. > > But the 8259 can be programmed to trigger via level or slope. > > So, this behaviour is only seen when level triggering is used. > > As I said at the bginning, I do not know how current designs handle it. But I thought level/edge thing is about interrupts between devices and PIC, not between PIC and CPU. I might be confused, though. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 17 17:14:30 2008 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 E47AE16A419 for ; Sun, 17 Feb 2008 17:14:30 +0000 (UTC) (envelope-from girishvenkatachalam@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF4D13C447 for ; Sun, 17 Feb 2008 17:14:30 +0000 (UTC) (envelope-from girishvenkatachalam@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1129417rvb.43 for ; Sun, 17 Feb 2008 09:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject:message-id:reply-to:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=jo3ooTlvtA65rsWLaOukzs8O00o4Zzth3oeA/1gy1WM=; b=QXh1/J+nH9DEvopJjMZ/ZcnA4B4rdeh2W4lenoZp7i2QUuIFMveneUUVW+zS6kiAW4/CnvWndoy4pIXnhXxZRq8Bf58PCFLQpN1hSDXYFRUyx1MpOqhORqqI4ek9WJSueT1Tba6jYnAqWK1h55mBUSKrMDRrA7VckZxeZ+DyqNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Ud1DCdlg3m/eGuXUtr7crZP6TEhnD3h9ZDDftG1ohLUOl3chB0cG65Os8BZoJbLgBEfMnMh+2paI0ZGzNcMWqEw63p7aRa4270D2+bkmsQkALrKfdFZlv6H4U6OzmfTlRUm8IEgSKcf5XCkdVCOP4kqk5oeJGJx1jQrPIP6Y7Z4= Received: by 10.141.169.9 with SMTP id w9mr3224650rvo.241.1203266942970; Sun, 17 Feb 2008 08:49:02 -0800 (PST) Received: from saraswathy.madambakam.org ( [59.92.15.52]) by mx.google.com with ESMTPS id f21sm7197180rvb.15.2008.02.17.08.49.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Feb 2008 08:49:02 -0800 (PST) Received: by saraswathy.madambakam.org (Postfix, from userid 1002) id CB24F39FF5C; Sun, 17 Feb 2008 22:18:57 +0530 (IST) Date: Sun, 17 Feb 2008 22:18:57 +0530 From: Girish Venkatachalam To: freebsd-hackers@freebsd.org Message-ID: <20080217164857.GA15657@saraswathy.madambakam.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <47B4A514.1020103@icyb.net.ua> <47B8055C.4060305@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B8055C.4060305@icyb.net.ua> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: cpu stats and another interrupt question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: girishvenkatachalam@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 17:14:31 -0000 On 11:58:52 Feb 17, Andriy Gapon wrote: > > Come on, guys, simple yes or no would be enough for me :-) > Okay. I am going to give my free advice. You obviously know what that means. Please take it with a pinch of salt. > on 14/02/2008 22:31 Andriy Gapon said the following: > > Dear hackers, > > I'd like to check with you if my understanding of some code is correct. > > > > If we speak about a typical older i386 system, with UP and "AT" PIC, I > > think this is how the CPU utilization stats are collected. > > RTC is configured to generate interrupts (IRQ8) 128 times per second. > > Each time interrupt is generated RTC interrupt handler (I will use > > simple non technical terms) takes a peek at what was interrupted and > > depending on the properties of that thing (kernel thread) bills a tick > > to particular category. E.g. if it sees that the "idle" thread is > > interrupted then a tick is billed to "idle", if an interrupt thread is > > interrupted (software or hardware) then a tick is billed to interrupt, > > if a thread is running user-mode code then a tick is billed to "user" or > > "nice", otherwise it's "system". > > I understand that I oversimplify, but is the above correct in general ? I have no clue about older PCs. I am quite young myself. :) However my "guess" would be that RTC is unrelated to what you are talking. Interrupts and CPU time ticks have nothing to do with the RTC chip. Please correct me if I am wrong. CPU ticks are generated by a separate crystal inside the uC itself. And these software interrupts have to be serviced or else you will lose time. This can sometimes happen but in extreme cases this could affect processes in an adverse manner of course. Years ago I was in a similar situation when working on Novell Netware. That said I have no clue about older PCs. So I could be entirely wrong here... > > > > Another, unrelated, question. > > Considering this snippet from sys/i386/isa/atpic.c, i8259_init(): > > #ifndef PC98 > > /* OCW2_L1 sets priority order to 3-7, 0-2 (com2 first). */ > > if (!slave) > > outb(pic->at_ioaddr, OCW2_R | OCW2_SL | OCW2_L1); > > #endif > > > > Do I understand correctly the code and the comment that here we use a > > feature of 8259 PIC that can be called "cyclic shift of interrupt > > priorities" ? > > So, we really have the following order of interrupts, from higher > > priority to lower: 3-7,0,1,8-15? Considering two chained 8259s, of course. If you are talking about the 8259C PIC then where are two 8259s coming from? I was under the impression that one PIC is sufficient for a typical daisy chained interrupt handling mechanism. Yet another wild guess. Now it is time to sleep. Good nite. -Girish From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 05:28:56 2008 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 A327916A417; Mon, 18 Feb 2008 05:28:56 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 7B48613C44B; Mon, 18 Feb 2008 05:28:56 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id DBF868FD79; Sun, 17 Feb 2008 22:28:55 -0700 (MST) Date: Sun, 17 Feb 2008 22:28:55 -0700 From: Brad Davis To: freebsd-hackers@FreeBSD.org Message-ID: <20080218052855.GE49382@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Status Reports for the Fourth Quarter of 2007 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, 18 Feb 2008 05:28:56 -0000 Hi Everyone, The FreeBSD Status Reports for the Fourth Quarter of 2007 are now available at: http://www.freebsd.org/news/status/report-2007-10-2007-12.html Regards, Brad Davis From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 08:53:54 2008 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 D283216A419 for ; Mon, 18 Feb 2008 08:53:54 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id 61EC713C461 for ; Mon, 18 Feb 2008 08:53:54 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180183180.adsl.alicedsl.de [85.180.183.180]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id m1I8rROk021274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2008 09:53:28 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m1I8rPUX002379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 09:53:25 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m1I8rNNP002378; Mon, 18 Feb 2008 09:53:23 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Mon, 18 Feb 2008 09:53:23 +0100 From: Ulrich Spoerlein To: "Christian S.J. Peron" Message-ID: <20080218085323.GA1439@roadrunner.spoerlein.net> Mail-Followup-To: "Christian S.J. Peron" , d@delphij.net, freebsd-hackers@freebsd.org References: <47B1F8B7.7030803@delphij.net> <20080216235001.GA80694@sub.vaned.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080216235001.GA80694@sub.vaned.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@FreeBSD.org, d@delphij.net Subject: Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 08:53:54 -0000 On Sat, 16.02.2008 at 17:50:01 -0600, Christian S.J. Peron wrote: > On Tue, Feb 12, 2008 at 11:51:19AM -0800, Xin LI wrote: > [..] > > > > Hi, > > > > Is there anyone working on valgrind on newer FreeBSD releases, or some > > work-alikes? > > > > Cheers, > > Yes, check out the //depot/projects/valgrind/... perforce project. It > works pretty well. When will mere mortals like us get a chance to play with it? I found valgrind _very_ useful back in the 5.x and 6.x days. Thanks for the porting! Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 09:10:35 2008 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 CC0D316A46C for ; Mon, 18 Feb 2008 09:10:35 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8826813C4DB for ; Mon, 18 Feb 2008 09:10:35 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-91-221.net-htp.de [89.182.91.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id 70119A44529; Mon, 18 Feb 2008 10:10:33 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Mon, 18 Feb 2008 10:10:43 +0100 User-Agent: KMail/1.9.7 References: <47B1F8B7.7030803@delphij.net> <20080216235001.GA80694@sub.vaned.net> <20080218085323.GA1439@roadrunner.spoerlein.net> In-Reply-To: <20080218085323.GA1439@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802181010.44055.wundram@beenic.net> Cc: "Christian S.J. Peron" Subject: Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 09:10:35 -0000 Am Montag, 18. Februar 2008 09:53:23 schrieb Ulrich Spoerlein: > When will mere mortals like us get a chance to play with it? I found > valgrind _very_ useful back in the 5.x and 6.x days. I just wanted to say that I'd also be very interested in testing it out (if you need testers for it), because currently I always (have to try to) compile applications I want to memcheck (which is my main reason for using valgrind) on Linux, which is a slight PITA. I'd be running it on i386, anyway. Thanks for any feedback in advance, and thanks for the effort! -- Heiko Wundram Product & Application Development From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 10:23:48 2008 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 EF53E16A417 for ; Mon, 18 Feb 2008 10:23:48 +0000 (UTC) (envelope-from rmgls@free.fr) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id AF50E13C468 for ; Mon, 18 Feb 2008 10:23:48 +0000 (UTC) (envelope-from rmgls@free.fr) Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix2-g20.free.fr (Postfix) with ESMTP id 0B2932376CF0 for ; Mon, 18 Feb 2008 09:05:48 +0100 (CET) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id F0200322868 for ; Mon, 18 Feb 2008 11:06:21 +0100 (CET) Received: from free.fr (evr27-1-88-172-40-194.fbx.proxad.net [88.172.40.194]) by smtp7-g19.free.fr (Postfix) with ESMTP id D4D6E32286D for ; Mon, 18 Feb 2008 11:06:21 +0100 (CET) From: rmgls@free.fr To: freebsd-hackers@freebsd.org Date: Mon, 18 Feb 2008 11:06:18 +0100 Sender: rmgls@free.fr Message-Id: <20080218100621.D4D6E32286D@smtp7-g19.free.fr> Subject: pci support for /usr/share/example/drivers? 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, 18 Feb 2008 10:23:49 -0000 Hi, all, the scripts in /usr/share/examples/drivers, Author: Julian Elischer create two isa skeletons for drivers. i would like to create a skeleton for a pci driver. Please, can you help me by pointing out all diffs needed for this purpose? Thanks for your suggestions. rmgls@free.fr From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 11:50:43 2008 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 4DC3E16A418 for ; Mon, 18 Feb 2008 11:50:43 +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 0498713C46A for ; Mon, 18 Feb 2008 11:50:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C847D2085; Mon, 18 Feb 2008 12:50:36 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id ADA662084; Mon, 18 Feb 2008 12:50:36 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 8C1EB8447F; Mon, 18 Feb 2008 12:50:36 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Heiko Wundram \(Beenic\)" References: <47B1F8B7.7030803@delphij.net> <20080216235001.GA80694@sub.vaned.net> <20080218085323.GA1439@roadrunner.spoerlein.net> <200802181010.44055.wundram@beenic.net> Date: Mon, 18 Feb 2008 12:50:36 +0100 In-Reply-To: <200802181010.44055.wundram@beenic.net> (Heiko Wundram's message of "Mon\, 18 Feb 2008 10\:10\:43 +0100") Message-ID: <86d4qu7ab7.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, "Christian S.J. Peron" Subject: Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 11:50:43 -0000 "Heiko Wundram (Beenic)" writes: > Ulrich Spoerlein writes: > > When will mere mortals like us get a chance to play with it? I found > > valgrind _very_ useful back in the 5.x and 6.x days. > I just wanted to say that I'd also be very interested in testing it > out (if you need testers for it), because currently I always (have to > try to) compile applications I want to memcheck (which is my main > reason for using valgrind) on Linux, which is a slight PITA. > > I'd be running it on i386, anyway. The ports version is a little outdated, but it works fine on i386. What peter@ and phk@ are doing in p4 is to port a newer version to FreeBSD and add amd64 support. Hopefully, the upstream vendor will adopt those patches so it doesn't have to be done over for every major valgrind release. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 12:02:11 2008 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 4A2C016A417 for ; Mon, 18 Feb 2008 12:02:11 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0E08B13C468 for ; Mon, 18 Feb 2008 12:02:10 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-91-221.net-htp.de [89.182.91.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id 6449FA44529; Mon, 18 Feb 2008 13:02:09 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= Date: Mon, 18 Feb 2008 13:02:19 +0100 User-Agent: KMail/1.9.7 References: <47B1F8B7.7030803@delphij.net> <200802181010.44055.wundram@beenic.net> <86d4qu7ab7.fsf@ds4.des.no> In-Reply-To: <86d4qu7ab7.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802181302.20071.wundram@beenic.net> Cc: freebsd-hackers@freebsd.org Subject: Re: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 12:02:11 -0000 Am Montag, 18. Februar 2008 12:50:36 schrieben Sie: > The ports version is a little outdated, but it works fine on i386. What > peter@ and phk@ are doing in p4 is to port a newer version to FreeBSD > and add amd64 support. Hopefully, the upstream vendor will adopt those > patches so it doesn't have to be done over for every major valgrind > release. Not true. The ports version(s, both valgrind and valgrind-snapshot) don't work on FreeBSD 7, simply because the system call table for 7.0 hasn't been updated yet, and it also fails to compile on the current GCC (whereas the latter is an easy fix, which I could post as a pr, but didn't so far, because of the unresolved issues wrt. the new system calls, which I can't/don't have time to fix). I last tried installing valgrind about a week ago; if you tell me that something changed in that week (haven't done a csup since then), I'll gladly try again, but AFAIK, nothing's changed (i.e., it doesn't work on 7 so far). -- Heiko Wundram Product & Application Development From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 13:05:11 2008 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 6068E16A41A for ; Mon, 18 Feb 2008 13:05:11 +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 16A6A13C514 for ; Mon, 18 Feb 2008 13:05:10 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=NYvpxdz6IJviHT6w8nLDNQ9cE5EnW6oFTbEKObQjS2bcioyTfwNo5zVkZhJP3cAiDscww/venf93HUR4VWyrmIDNZxQ7aZUfwxKzJ5bvMaZ8BKgFXowE3sADzbAhoqCHZBpjWQvDYBDB+/1Jq5P31EjUL4Iojo2irico5MLDL+M=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JR5gD-000Jmh-Gx; Mon, 18 Feb 2008 16:05:09 +0300 Date: Mon, 18 Feb 2008 16:05:08 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47B97C96.1080206@zirakzigil.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:05:11 -0000 Giulio, Mon, Feb 18, 2008 at 01:39:50PM +0100, Giulio Ferro wrote: > first of all thanks for your effort. No problems ;)) > Unfortunately I couldn't still get the synaptyc driver work on my laptop. > > Here's what I did: > 1) I extracted the port driver with "make extract patch" > 2) put your patch in /usr/ports/x11-drivers/synaptics/files (I named it > "newpatch") > 3) applied the patch with that directory with patch < newpatch No, the patch I had supplied is the patch-to-the-patch ;)) So you should 1) Do 'make clean' in the port's directory. 2) Apply the patch with 'patch -p1 < /path/to/the/supplied/patchfile'. 3) Build and install the port. Sorry, I was not clear enough on how to apply the modification. Please, try again if you have some spare time. Thanks! -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 13:06:54 2008 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 6DF7016A420 for ; Mon, 18 Feb 2008 13:06:54 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id A906D13C45E for ; Mon, 18 Feb 2008 13:06:51 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 84406 invoked by uid 98); 18 Feb 2008 12:40:09 -0000 Received: from 85.18.102.52 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(85.18.102.52):. Processed in 0.349553 secs); 18 Feb 2008 12:40:09 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(85.18.102.52):. Processed in 0.349553 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@85.18.102.52) by 0 with SMTP; 18 Feb 2008 12:40:08 -0000 Message-ID: <47B97C96.1080206@zirakzigil.org> Date: Mon, 18 Feb 2008 13:39:50 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin , freebsd-hackers@freebsd.org References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> In-Reply-To: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> Content-Type: multipart/mixed; boundary="------------060802060308000607030702" Cc: Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:06:54 -0000 This is a multi-part message in MIME format. --------------060802060308000607030702 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Giulio, good day. > > Long time ago, in December 2007, we discuissed the problem with > Synaptics touchpad driver for FreeBSD in the freebsd-hackers list. > I had corrected the problem and driver seems to work, but I need > more testing with real hardware. I had opened the FreeBSD PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=120783 > > It will be great if you will be able to try the patch in the PR > (I assume that you still have FreeBSD/amd64 and Xorg on some of > your machines) and report the result either to the list or as the > PR followup. > > Thank you! > Hi Eygene, first of all thanks for your effort. Unfortunately I couldn't still get the synaptyc driver work on my laptop. Here's what I did: 1) I extracted the port driver with "make extract patch" 2) put your patch in /usr/ports/x11-drivers/synaptics/files (I named it "newpatch") 3) applied the patch with that directory with patch < newpatch 4) compiled the driver with make install clean 5) loaded the driver in /boot/loader.conf (as per pkg-message) 6) modified the /etc/X11/xorg.conf (//) 7) disabled the moused demon (//) When I launched startx the xorg server aborted with the same "No Device specified" I got the last time. I attach the complete log of the server. I hope it will be of help to you. Regards. --------------060802060308000607030702 Content-Type: text/plain; name="xorg_synapt.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg_synapt.log" X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-PRERELEASE amd64 Current Operating System: FreeBSD aurynmob2.giulioferro.it 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Wed Jan 30 22:06:30 CET 2008 root@aurynmob2.giulioferro.it:/usr/obj/usr/src/sys/AURYNMOB2 amd64 Build Date: 18 February 2008 10:16:05AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 18 13:23:34 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "* Generic VESA compatible" (**) |-->Input Device "Keyboard1" (**) |-->Input Device "Synaptics_Touchpad" (**) Option "DontVTSwitch" (**) Option "DontZap" (**) Option "DontZoom" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) RgbPath set to "/usr/local/share/X11/rgb" (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) No default mouse found, adding one (**) |-->Input Device "" (II) Loader magic: 0x680ce0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (WW) OS did not count PCI devices, guessing wildly (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2a00 card 104d,9016 rev 0c class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2a01 card 0000,0000 rev 0c class 06,04,00 hdr 01 (II) PCI: 00:1a:0: chip 8086,2834 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2835 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,283a card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,284b card 104d,9016 rev 03 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,283f card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2841 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:2: chip 8086,2843 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2830 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2831 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2832 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,2836 card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev f3 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2811 card 104d,9016 rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,2850 card 104d,9016 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,282a card 104d,9016 rev 03 class 01,04,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,283e card 104d,9016 rev 03 class 0c,05,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0407 card 104d,9016 rev a1 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 11ab,4363 card 104d,9016 rev 13 class 02,00,00 hdr 00 (II) PCI: 06:00:0: chip 8086,4222 card 8086,1051 rev 02 class 02,80,00 hdr 00 (II) PCI: 08:03:0: chip 104c,8039 card fffc,ffff rev 00 class 06,07,00 hdr 82 (II) PCI: 08:03:1: chip 104c,803a card 104d,9016 rev 00 class 0c,00,10 hdr 80 (II) PCI: 08:03:2: chip 104c,803b card 104d,9016 rev 00 class 01,80,00 hdr 80 (II) PCI: 08:04:0: chip 1131,7133 card 1461,e836 rev d1 class 04,80,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,9), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x001a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x00002000 - 0x00002fff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xcc000000 - 0xceffffff (0x3000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,3), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0xf0000000 - 0xf1ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 4: bridge is at (0:28:1), (0,4,5), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 4 I/O range: [0] -1 0 0x00004000 - 0x000040ff (0x100) IX[B] [1] -1 0 0x00004400 - 0x000044ff (0x100) IX[B] [2] -1 0 0x00004800 - 0x000048ff (0x100) IX[B] [3] -1 0 0x00004c00 - 0x00004cff (0x100) IX[B] (II) Bus 4 non-prefetchable memory range: [0] -1 0 0xf8000000 - 0xf9ffffff (0x2000000) MX[B] (II) Bus 4 prefetchable memory range: [0] -1 0 0xf2000000 - 0xf3ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 6: bridge is at (0:28:2), (0,6,7), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 6 I/O range: [0] -1 0 0x00005000 - 0x000050ff (0x100) IX[B] [1] -1 0 0x00005400 - 0x000054ff (0x100) IX[B] [2] -1 0 0x00005800 - 0x000058ff (0x100) IX[B] [3] -1 0 0x00005c00 - 0x00005cff (0x100) IX[B] (II) Bus 6 non-prefetchable memory range: [0] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B] (II) Bus 6 prefetchable memory range: [0] -1 0 0xf4000000 - 0xf5ffffff (0x2000000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 8: bridge is at (0:30:0), (0,8,9), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 8 I/O range: [0] -1 0 0x0000f000 - 0x0000f0ff (0x100) IX[B] [1] -1 0 0x0000f400 - 0x0000f4ff (0x100) IX[B] [2] -1 0 0x0000f800 - 0x0000f8ff (0x100) IX[B] [3] -1 0 0x0000fc00 - 0x0000fcff (0x100) IX[B] (II) Bus 8 non-prefetchable memory range: [0] -1 0 0xfc000000 - 0xfc0fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 9: bridge is at (8:3:0), (8,9,9), BCTRL: 0x0744 (VGA_EN is cleared) (--) PCI:*(1:0:0) nVidia Corporation GeForce 8600M GT rev 161, Mem @ 0xce000000/24, 0xd0000000/28, 0xcc000000/25, I/O @ 0x2000/7 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xffffffff (0x4000000) MX[B]E [3] -1 0 0xfc006000 - 0xfc007fff (0x2000) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc307fff (0x4000) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc3fffff (0x100000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304fff (0x800) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018ff (0x20) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018bf (0x20) IX[B]E [21] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000187f (0x40) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x000018ff (0x100) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) PCI Memory resource overlap reduced 0xfc000000 from 0xffffffff to 0xfc003fff (II) PCI Memory resource overlap reduced 0xfc006000 from 0xfc007fff to 0xfc0067ff (II) PCI Memory resource overlap reduced 0xfc304000 from 0xfc307fff to 0xfc3047ff (II) PCI I/O resource overlap reduced 0x000018c0 from 0x000018ff to 0x000018df (II) PCI I/O resource overlap reduced 0x000018e0 from 0x000018ff to 0x000018e7 (II) PCI I/O resource overlap reduced 0x000018a0 from 0x000018bf to 0x000018af (II) PCI I/O resource overlap reduced 0x00001880 from 0x000018ff to 0x0000189f (II) PCI I/O resource overlap reduced 0x00001840 from 0x0000187f to 0x0000185f (II) PCI Memory resource overlap reduced 0xfc300000 from 0xfc3fffff to 0xfc303fff (II) PCI Memory resource overlap reduced 0xfc304800 from 0xfc304fff to 0xfc304bff (II) PCI I/O resource overlap reduced 0x00001800 from 0x000018ff to 0x0000181f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [3] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [21] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) All system resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "type1" will be loaded by default. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "synaptics" (II) Loading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "type1" (II) Loading /usr/local/lib/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "nv" (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 1.4.0, module version = 2.1.7 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "synaptics" (II) Reloading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64, Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400, GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go, GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420, GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go, GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL, GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL, GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X, GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X, GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL, Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI, GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3, GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600, GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL, Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X, GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL, Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra, GeForce FX 5800, Quadro FX 2000, Quadro FX 1000, GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT, GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700, GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200, GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250, GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M, Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI, GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra, GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra, GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700, GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE, GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700, Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800, GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT, GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000, GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT, GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400, Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT, GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600, GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL, GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550, Quadro FX 540, GeForce 6200, GeForce 6500, GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM), GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400, GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 6800, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX, GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800, GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE, GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400, GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M, GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT, GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT, GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT, Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560, GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS, GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M, Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500, Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100, GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8400 GS, GeForce 8600M GT, GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M, Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M, Quadro FX 360M, Quadro NVS 290, GeForce 8800 GT, Quadro FX 3700 (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset GeForce 8600M GT found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [18] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [19] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [23] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [24] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [25] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [26] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [27] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [28] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [29] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [30] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [31] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [32] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [33] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [34] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [35] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [36] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [37] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (II) NV(0): Initializing int10 (==) NV(0): Write-combining range (0xa0000,0x20000) was already clear (==) NV(0): Write-combining range (0xc0000,0x40000) was already clear (II) NV(0): Primary V_BIOS segment is: 0xc000 (==) NV(0): Write-combining range (0x0,0x1000) was already clear (--) NV(0): Console is VGA mode 0x3 (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor (==) NV(0): Using hardware cursor (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (==) NV(0): Write-combining range (0xce000000,0x1000000) was already clear (II) NV(0): MMIO registers mapped at 0x802c00000 (--) NV(0): Total video RAM: 256.0 MB (--) NV(0): BAR1 size: 256.0 MB (--) NV(0): Mapped memory: 255.0 MB (==) NV(0): Write-combining range (0xd0000000,0xff00000) was already clear (II) NV(0): Linear framebuffer mapped at 0x803c00000 (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module "i2c" already built-in (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module "ddc" already built-in (--) NV(0): Connector map: (--) NV(0): [N/A] -> SOR0 (LVDS) (--) NV(0): Bus 0 -> DAC1 (--) NV(0): Bus 1 -> SOR1 (--) NV(0): Load detection: 279 (II) NV(0): I2C bus "I2C0" initialized. (II) NV(0): Output VGA1 using monitor section My Monitor (II) NV(0): I2C bus "I2C1" initialized. (II) NV(0): Output DVI1 has no monitor section (II) NV(0): LVDS native size 1920x1200 (II) NV(0): Output LVDS has no monitor section (II) NV(0): Probing for EDID on I2C bus 0... (II) NV(0): I2C device "I2C0:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C0:ddc2" removed. (II) NV(0): ... none found (--) NV(0): Trying load detection on VGA1 ... nothing. (II) NV(0): Probing for EDID on I2C bus 1... (II) NV(0): I2C device "I2C1:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C1:ddc2" removed. (II) NV(0): ... none found (II) NV(0): Output VGA1 disconnected (II) NV(0): Output DVI1 disconnected (II) NV(0): Output LVDS connected (II) NV(0): Output LVDS using initial mode 1920x1200 (--) NV(0): Virtual size is 1920x1920 (pitch 2048) (**) NV(0): Driver mode "1920x1200" (**) NV(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) NV(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NV(0): Default mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz (II) NV(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz (II) NV(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NV(0): Default mode "512x384": 32.5 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (D) (II) NV(0): Modeline "512x384"x60.0 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (48.4 kHz) (==) NV(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 2.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B] [1] 0 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] [2] 0 0 0xce000000 - 0xceffffff (0x1000000) MX[B] [3] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [8] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [9] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [10] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [11] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [12] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [13] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [14] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [15] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [16] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [17] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [18] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [19] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [20] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [21] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [22] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [23] 0 0 0x00002000 - 0x0000207f (0x80) IX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [27] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [28] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [29] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [30] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [31] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [32] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [33] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [34] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [35] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [36] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [37] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [38] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [39] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [40] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [41] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (--) NV(0): 239.95 MB available for offscreen pixmaps (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (==) NV(0): Backing store disabled (==) NV(0): Silken mouse enabled (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/local/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) NV(0): Setting screen physical size to 508 x 317 (**) Option "CoreKeyboard" (**) Keyboard1: always reports core events (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard1: XkbLayout: "us" (**) Option "XkbVariant" "intl" (**) Keyboard1: XkbVariant: "intl" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) Synaptics touchpad driver version 0.14.6 (1406) Synaptics_Touchpad no synaptics event device found (checked 10 nodes) Synaptics_Touchpad The /dev/input/event* device nodes seem to be missing (EE) xf86OpenSerial: No Device specified. Synaptics driver unable to open device (EE) PreInit failed for input device "Synaptics_Touchpad" (II) UnloadModule: "synaptics" Fatal server error: Caught signal 11. Server aborting --------------060802060308000607030702-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 13:49:21 2008 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 225D316A420 for ; Mon, 18 Feb 2008 13:49:21 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 4E73913C44B for ; Mon, 18 Feb 2008 13:49:19 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 85164 invoked by uid 98); 18 Feb 2008 13:49:18 -0000 Received: from 85.18.102.52 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(85.18.102.52):. Processed in 0.040126 secs); 18 Feb 2008 13:49:18 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(85.18.102.52):. Processed in 0.040126 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@85.18.102.52) by 0 with SMTP; 18 Feb 2008 13:49:18 -0000 Message-ID: <47B98CCC.804@zirakzigil.org> Date: Mon, 18 Feb 2008 14:49:00 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> In-Reply-To: <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 13:49:21 -0000 Eygene Ryabinkin wrote: > Please, try again if you have some spare time. > > Ok. Now the server starts, but the mouse pointer isn't moving... in the ServerLayout section I have this: #InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Synaptics_Touchpad" "CorePointer" and I didn't start the moused demon. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 14:15:37 2008 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 952BB16A417 for ; Mon, 18 Feb 2008 14:15:37 +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 4C24113C4FB for ; Mon, 18 Feb 2008 14:15:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=k9SPv7Oh5/hSN4riiVmZaoLSfpIwVf8rxuQX1tDbpy/UR1w6iYlEQDwV1gprn+iNtpgskw0jFt+z1iBXUYxcyWyUgXxo1pDQNgsCIGCjXXEUb4iBvnHja0aSsDaJCeZXUFhCuJl9A6AKSr3h3xX01B0ij6RGAYerGS+ClkVr6ak=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JR6mO-000KE8-9G; Mon, 18 Feb 2008 17:15:36 +0300 Date: Mon, 18 Feb 2008 17:15:35 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47B98CCC.804@zirakzigil.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 14:15:37 -0000 Mon, Feb 18, 2008 at 02:49:00PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Please, try again if you have some spare time. > > Ok. Now the server starts, Good ;)) > but the mouse pointer isn't moving... Bad :(( > in the ServerLayout section I have this: > #InputDevice "Mouse1" "CorePointer" > InputDevice "Keyboard1" "CoreKeyboard" > InputDevice "Synaptics_Touchpad" "CorePointer" And if you'll try 'InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvents"'? I have it in my Synaptics config @i386 and I vaguely recall that this was needed to enable the touchpad and USB mouse to work together. May be this will fix your problems. If not, drop me a letter, I'll try to get the real hardware into my hands and test it. But this likely won't be done until the end of the week, sorry. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 15:01:08 2008 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 B005716A474 for ; Mon, 18 Feb 2008 15:01:08 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 5074D13C4E1 for ; Mon, 18 Feb 2008 15:01:04 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 86032 invoked by uid 98); 18 Feb 2008 15:01:02 -0000 Received: from 85.18.102.52 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(85.18.102.52):. Processed in 0.314008 secs); 18 Feb 2008 15:01:02 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(85.18.102.52):. Processed in 0.314008 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@85.18.102.52) by 0 with SMTP; 18 Feb 2008 15:01:02 -0000 Message-ID: <47B99D9B.9050609@zirakzigil.org> Date: Mon, 18 Feb 2008 16:00:43 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> In-Reply-To: <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> Content-Type: multipart/mixed; boundary="------------050004060200050400030105" Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:01:08 -0000 This is a multi-part message in MIME format. --------------050004060200050400030105 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: >> in the ServerLayout section I have this: >> #InputDevice "Mouse1" "CorePointer" >> InputDevice "Keyboard1" "CoreKeyboard" >> InputDevice "Synaptics_Touchpad" "CorePointer" >> > > And if you'll try > 'InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvents"'? > > Nothing changes, sorry... > If not, drop me a letter, I'll try to get the real hardware into > my hands and test it. But this likely won't be done until the end > of the week, sorry. > Thanks again. I include the complete log of the xorg session, I hope it can help you somehow. If you need me further tests just say so... Bye. --------------050004060200050400030105 Content-Type: text/plain; name="xorg_synapt.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg_synapt.log" X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-PRERELEASE amd64 Current Operating System: FreeBSD aurynmob2.giulioferro.it 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Wed Jan 30 22:06:30 CET 2008 root@aurynmob2.giulioferro.it:/usr/obj/usr/src/sys/AURYNMOB2 amd64 Build Date: 18 February 2008 10:16:05AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 18 15:46:59 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "* Generic VESA compatible" (**) |-->Input Device "Keyboard1" (**) |-->Input Device "Synaptics_Touchpad" (**) Option "DontVTSwitch" (**) Option "DontZap" (**) Option "DontZoom" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) RgbPath set to "/usr/local/share/X11/rgb" (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) No default mouse found, adding one (**) |-->Input Device "" (II) Loader magic: 0x680ce0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (WW) OS did not count PCI devices, guessing wildly (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2a00 card 104d,9016 rev 0c class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2a01 card 0000,0000 rev 0c class 06,04,00 hdr 01 (II) PCI: 00:1a:0: chip 8086,2834 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2835 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,283a card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,284b card 104d,9016 rev 03 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,283f card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2841 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:2: chip 8086,2843 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2830 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2831 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2832 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,2836 card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev f3 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2811 card 104d,9016 rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,2850 card 104d,9016 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,282a card 104d,9016 rev 03 class 01,04,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,283e card 104d,9016 rev 03 class 0c,05,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0407 card 104d,9016 rev a1 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 11ab,4363 card 104d,9016 rev 13 class 02,00,00 hdr 00 (II) PCI: 06:00:0: chip 8086,4222 card 8086,1051 rev 02 class 02,80,00 hdr 00 (II) PCI: 08:03:0: chip 104c,8039 card fffc,ffff rev 00 class 06,07,00 hdr 82 (II) PCI: 08:03:1: chip 104c,803a card 104d,9016 rev 00 class 0c,00,10 hdr 80 (II) PCI: 08:03:2: chip 104c,803b card 104d,9016 rev 00 class 01,80,00 hdr 80 (II) PCI: 08:04:0: chip 1131,7133 card 1461,e836 rev d1 class 04,80,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,9), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x001a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x00002000 - 0x00002fff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xcc000000 - 0xceffffff (0x3000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,3), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0xf0000000 - 0xf1ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 4: bridge is at (0:28:1), (0,4,5), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 4 I/O range: [0] -1 0 0x00004000 - 0x000040ff (0x100) IX[B] [1] -1 0 0x00004400 - 0x000044ff (0x100) IX[B] [2] -1 0 0x00004800 - 0x000048ff (0x100) IX[B] [3] -1 0 0x00004c00 - 0x00004cff (0x100) IX[B] (II) Bus 4 non-prefetchable memory range: [0] -1 0 0xf8000000 - 0xf9ffffff (0x2000000) MX[B] (II) Bus 4 prefetchable memory range: [0] -1 0 0xf2000000 - 0xf3ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 6: bridge is at (0:28:2), (0,6,7), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 6 I/O range: [0] -1 0 0x00005000 - 0x000050ff (0x100) IX[B] [1] -1 0 0x00005400 - 0x000054ff (0x100) IX[B] [2] -1 0 0x00005800 - 0x000058ff (0x100) IX[B] [3] -1 0 0x00005c00 - 0x00005cff (0x100) IX[B] (II) Bus 6 non-prefetchable memory range: [0] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B] (II) Bus 6 prefetchable memory range: [0] -1 0 0xf4000000 - 0xf5ffffff (0x2000000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 8: bridge is at (0:30:0), (0,8,9), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 8 I/O range: [0] -1 0 0x0000f000 - 0x0000f0ff (0x100) IX[B] [1] -1 0 0x0000f400 - 0x0000f4ff (0x100) IX[B] [2] -1 0 0x0000f800 - 0x0000f8ff (0x100) IX[B] [3] -1 0 0x0000fc00 - 0x0000fcff (0x100) IX[B] (II) Bus 8 non-prefetchable memory range: [0] -1 0 0xfc000000 - 0xfc0fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 9: bridge is at (8:3:0), (8,9,9), BCTRL: 0x0744 (VGA_EN is cleared) (--) PCI:*(1:0:0) nVidia Corporation GeForce 8600M GT rev 161, Mem @ 0xce000000/24, 0xd0000000/28, 0xcc000000/25, I/O @ 0x2000/7 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xffffffff (0x4000000) MX[B]E [3] -1 0 0xfc006000 - 0xfc007fff (0x2000) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc307fff (0x4000) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc3fffff (0x100000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304fff (0x800) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018ff (0x20) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018bf (0x20) IX[B]E [21] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000187f (0x40) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x000018ff (0x100) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) PCI Memory resource overlap reduced 0xfc000000 from 0xffffffff to 0xfc003fff (II) PCI Memory resource overlap reduced 0xfc006000 from 0xfc007fff to 0xfc0067ff (II) PCI Memory resource overlap reduced 0xfc304000 from 0xfc307fff to 0xfc3047ff (II) PCI I/O resource overlap reduced 0x000018c0 from 0x000018ff to 0x000018df (II) PCI I/O resource overlap reduced 0x000018e0 from 0x000018ff to 0x000018e7 (II) PCI I/O resource overlap reduced 0x000018a0 from 0x000018bf to 0x000018af (II) PCI I/O resource overlap reduced 0x00001880 from 0x000018ff to 0x0000189f (II) PCI I/O resource overlap reduced 0x00001840 from 0x0000187f to 0x0000185f (II) PCI Memory resource overlap reduced 0xfc300000 from 0xfc3fffff to 0xfc303fff (II) PCI Memory resource overlap reduced 0xfc304800 from 0xfc304fff to 0xfc304bff (II) PCI I/O resource overlap reduced 0x00001800 from 0x000018ff to 0x0000181f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [3] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [21] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) All system resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "type1" will be loaded by default. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "synaptics" (II) Loading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "type1" (II) Loading /usr/local/lib/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "nv" (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 1.4.0, module version = 2.1.7 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "synaptics" (II) Reloading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64, Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400, GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go, GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420, GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go, GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL, GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL, GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X, GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X, GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL, Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI, GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3, GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600, GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL, Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X, GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL, Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra, GeForce FX 5800, Quadro FX 2000, Quadro FX 1000, GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT, GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700, GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200, GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250, GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M, Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI, GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra, GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra, GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700, GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE, GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700, Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800, GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT, GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000, GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT, GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400, Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT, GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600, GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL, GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550, Quadro FX 540, GeForce 6200, GeForce 6500, GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM), GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400, GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 6800, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX, GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800, GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE, GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400, GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M, GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT, GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT, GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT, Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560, GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS, GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M, Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500, Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100, GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8400 GS, GeForce 8600M GT, GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M, Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M, Quadro FX 360M, Quadro NVS 290, GeForce 8800 GT, Quadro FX 3700 (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset GeForce 8600M GT found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [18] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [19] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [23] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [24] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [25] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [26] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [27] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [28] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [29] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [30] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [31] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [32] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [33] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [34] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [35] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [36] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [37] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (II) NV(0): Initializing int10 (==) NV(0): Write-combining range (0xa0000,0x20000) was already clear (==) NV(0): Write-combining range (0xc0000,0x40000) was already clear (II) NV(0): Primary V_BIOS segment is: 0xc000 (==) NV(0): Write-combining range (0x0,0x1000) was already clear (--) NV(0): Console is VGA mode 0x3 (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor (==) NV(0): Using hardware cursor (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (==) NV(0): Write-combining range (0xce000000,0x1000000) was already clear (II) NV(0): MMIO registers mapped at 0x802c00000 (--) NV(0): Total video RAM: 256.0 MB (--) NV(0): BAR1 size: 256.0 MB (--) NV(0): Mapped memory: 255.0 MB (==) NV(0): Write-combining range (0xd0000000,0xff00000) was already clear (II) NV(0): Linear framebuffer mapped at 0x803c00000 (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module "i2c" already built-in (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module "ddc" already built-in (--) NV(0): Connector map: (--) NV(0): [N/A] -> SOR0 (LVDS) (--) NV(0): Bus 0 -> DAC1 (--) NV(0): Bus 1 -> SOR1 (--) NV(0): Load detection: 279 (II) NV(0): I2C bus "I2C0" initialized. (II) NV(0): Output VGA1 using monitor section My Monitor (II) NV(0): I2C bus "I2C1" initialized. (II) NV(0): Output DVI1 has no monitor section (II) NV(0): LVDS native size 1920x1200 (II) NV(0): Output LVDS has no monitor section (II) NV(0): Probing for EDID on I2C bus 0... (II) NV(0): I2C device "I2C0:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C0:ddc2" removed. (II) NV(0): ... none found (--) NV(0): Trying load detection on VGA1 ... nothing. (II) NV(0): Probing for EDID on I2C bus 1... (II) NV(0): I2C device "I2C1:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C1:ddc2" removed. (II) NV(0): ... none found (II) NV(0): Output VGA1 disconnected (II) NV(0): Output DVI1 disconnected (II) NV(0): Output LVDS connected (II) NV(0): Output LVDS using initial mode 1920x1200 (--) NV(0): Virtual size is 1920x1920 (pitch 2048) (**) NV(0): Driver mode "1920x1200" (**) NV(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) NV(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NV(0): Default mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz (II) NV(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz (II) NV(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NV(0): Default mode "512x384": 32.5 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (D) (II) NV(0): Modeline "512x384"x60.0 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (48.4 kHz) (==) NV(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 2.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B] [1] 0 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] [2] 0 0 0xce000000 - 0xceffffff (0x1000000) MX[B] [3] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [8] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [9] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [10] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [11] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [12] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [13] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [14] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [15] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [16] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [17] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [18] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [19] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [20] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [21] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [22] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [23] 0 0 0x00002000 - 0x0000207f (0x80) IX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [27] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [28] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [29] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [30] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [31] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [32] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [33] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [34] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [35] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [36] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [37] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [38] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [39] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [40] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [41] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (--) NV(0): 239.95 MB available for offscreen pixmaps (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (==) NV(0): Backing store disabled (==) NV(0): Silken mouse enabled (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/local/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) NV(0): Setting screen physical size to 508 x 317 (**) Option "CoreKeyboard" (**) Keyboard1: always reports core events (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard1: XkbLayout: "us" (**) Option "XkbVariant" "intl" (**) Keyboard1: XkbVariant: "intl" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) Synaptics touchpad driver version 0.14.6 (1406) (**) Option "Device" "/dev/psm0" (**) Option "SHMConfig" "off" (**) Option "LeftEdge" "1700" (**) Option "RightEdge" "5300" (**) Option "TopEdge" "1700" (**) Option "BottomEdge" "4200" (**) Option "FingerLow" "25" (**) Option "FingerHigh" "30" (**) Option "MaxTapTime" "180" (**) Option "MaxTapMove" "220" (**) Option "VertScrollDelta" "100" (**) Option "HorizScrollDelta" "100" (**) Option "UpDownScrolling" "on" (**) Option "LeftRightScrolling" "on" (**) Option "ScrollButtonRepeat" "100" (--) Synaptics_Touchpad synaptics touchpad found (--) Synaptics Touchpad, model: 0 (--) Firmware: 6.3 (--) Sensor: 1 (--) new absolute packet format (--) Touchpad has extended capability bits (--) -> multifinger detection (--) -> palm detection (**) Option "CorePointer" (**) Synaptics_Touchpad: always reports core events (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/psm0" (--) : Device: "/dev/psm0" (==) : Protocol: "Auto" (**) Option "AlwaysCore" (**) : doesn't report core events (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (**) : Sensitivity: 1 (II) evaluating device () (II) XINPUT: Adding extended input device "" (type: MOUSE) (II) evaluating device (Synaptics_Touchpad) (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) (II) evaluating device (Keyboard1) (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) Synaptics DeviceInit called SynapticsCtrl called. (II) : SetupAuto: hw.iftype is 3, hw.model is 13 (II) : SetupAuto: protocol is SysMouse (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device Synaptics DeviceOn called (EE) xf86OpenSerial: Cannot open device /dev/psm0 Device busy. (WW) Synaptics_Touchpad: cannot open input device couldn't enable device 3 Fatal server error: Caught signal 10. Server aborting Synaptics DeviceOff called --------------050004060200050400030105-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 15:25:17 2008 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 C909016A41B for ; Mon, 18 Feb 2008 15:25:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6D31D13C4CC for ; Mon, 18 Feb 2008 15:25:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 6ED1243F63E for ; Mon, 18 Feb 2008 17:25:15 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um6pVOlAC4Y0 for ; Mon, 18 Feb 2008 17:25:15 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0B70B43D614 for ; Mon, 18 Feb 2008 17:25:14 +0200 (EET) Message-ID: <47B9A359.9080502@icyb.net.ua> Date: Mon, 18 Feb 2008 17:25:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: sched_ule: roundrobin_callout replacement ? 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, 18 Feb 2008 15:25:17 -0000 I see that sched_4bsd has a NOP callout with a purpose of forcing a context switch (via softclock), so that something like a preemption could happen (e.g. for threads in a tight calculation loop). What serves the similar purpose for sched_ule? Or, how sched_ule deals with the issue without needing softclock's help? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 15:40:58 2008 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 DF8B016A418 for ; Mon, 18 Feb 2008 15:40:58 +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 93F9213C4D3 for ; Mon, 18 Feb 2008 15:40:58 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=jbQROxIYMcTXQGNqQ0+sWDGI124dbleLf0uY1h/Dpsv4gsvOjK8BBif1DNZ1yUNpqkCAUUV+iBSf83r34kDOfzFWiTqxl25CNuenm0YRRMJL942decKbObZV3KjbXNAY3nRYjO12GTi+pP4vnb9MKAxNOB3BQU1sBxUJZrjJ6SI=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JR86z-000Kk5-Cq; Mon, 18 Feb 2008 18:40:57 +0300 Date: Mon, 18 Feb 2008 18:40:56 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47B99D9B.9050609@zirakzigil.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:40:59 -0000 Giulio, Mon, Feb 18, 2008 at 04:00:43PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> And if you'll try >> 'InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvents"'? >> >> > Nothing changes, sorry... > >> If not, drop me a letter, I'll try to get the real hardware into >> my hands and test it. But this likely won't be done until the end >> of the week, sorry. >> > > Thanks again. I include the complete log of the xorg session, I hope it can > help you somehow. Yes, the following lines are very suspicious: ----- > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (==) : Protocol: "Auto" > (**) Option "AlwaysCore" > (**) : doesn't report core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) evaluating device () > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (II) evaluating device (Synaptics_Touchpad) > (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) > (II) evaluating device (Keyboard1) > (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 ----- It seems to me that you have another mouse device called '' that uses "auto" protocol and finds your mouse at /dev/psm0 and being SysMouse. Can you show your full xorg.conf? Thanks! -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 15:49:35 2008 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 B304316A468 for ; Mon, 18 Feb 2008 15:49:35 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 1A7A613C45E for ; Mon, 18 Feb 2008 15:49:33 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 86429 invoked by uid 98); 18 Feb 2008 15:49:32 -0000 Received: from 85.18.102.52 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(85.18.102.52):. Processed in 0.061495 secs); 18 Feb 2008 15:49:32 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(85.18.102.52):. Processed in 0.061495 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@85.18.102.52) by 0 with SMTP; 18 Feb 2008 15:49:32 -0000 Message-ID: <47B9A8F9.4090700@zirakzigil.org> Date: Mon, 18 Feb 2008 16:49:13 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070203010408050307010106" Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 15:49:35 -0000 This is a multi-part message in MIME format. --------------070203010408050307010106 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Yes, the following lines are very suspicious: > ----- > > ----- > > It seems to me that you have another mouse device called ' pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 > and being SysMouse. Can you show your full xorg.conf? > Sure, find it attached... --------------070203010408050307010106 Content-Type: text/plain; name="xorg.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg.conf" # File generated by xorgconfig. # # Copyright 2004 The X.Org Foundation # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # The X.Org Foundation BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. # # Except as contained in this notice, the name of The X.Org Foundation shall # not be used in advertising or otherwise to promote the sale, use or other # dealings in this Software without prior written authorization from # The X.Org Foundation. # # ********************************************************************** # Refer to the xorg.conf(5) man page for details about the format of # this file. # ********************************************************************** # ********************************************************************** # Module section -- this section is used to specify # which dynamically loadable modules to load. # ********************************************************************** # Section "Module" # This loads the DBE extension module. Load "dbe" # Double buffer extension # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that module. SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection # This loads the font modules # Load "type1" Load "freetype" # Load "xtt" # This loads the GLX module Load "glx" # This loads the DRI module Load "dri" Load "synaptics" EndSection # ********************************************************************** # Files section. This allows default font and rgb paths to be set # ********************************************************************** Section "Files" # The location of the RGB database. Note, this is the name of the # file minus the extension (like ".txt" or ".db"). There is normally # no need to change the default. # RgbPath "/usr/local/share/X11/rgb" # Multiple FontPath entries are allowed (which are concatenated together), # as well as specifying multiple comma-separated entries in one FontPath # command (or a combination of both methods) # # FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" FontPath "/usr/local/lib/X11/fonts/local/" # FontPath "/usr/local/lib/X11/fonts/Speedo/" # FontPath "/usr/local/lib/X11/fonts/TrueType/" # FontPath "/usr/local/lib/X11/fonts/freefont/" # The module search path. The default path is shown here. # ModulePath "/usr/local/lib/modules" EndSection # ********************************************************************** # Server flags section. # ********************************************************************** Section "ServerFlags" # Uncomment this to cause a core dump at the spot where a signal is # received. This may leave the console in an unusable state, but may # provide a better stack trace in the core dump to aid in debugging # Option "NoTrapSignals" # Uncomment this to disable the VT switch sequence # (where n is 1 through 12). This allows clients to receive these key # events. Option "DontVTSwitch" # Uncomment this to disable the server abort sequence # This allows clients to receive this key event. Option "DontZap" # Uncomment this to disable the / mode switching # sequences. This allows clients to receive these key events. Option "Dont Zoom" # Uncomment this to disable tuning with the xvidtune client. With # it the client can still run and fetch card and monitor attributes, # but it will not be allowed to change them. If it tries it will # receive a protocol error. # Option "DisableVidModeExtension" # Uncomment this to enable the use of a non-local xvidtune client. # Option "AllowNonLocalXvidtune" # Uncomment this to disable dynamically modifying the input device # (mouse and keyboard) settings. # Option "DisableModInDev" # Uncomment this to enable the use of a non-local client to # change the keyboard or mouse settings (currently only xset). # Option "AllowNonLocalModInDev" EndSection # ********************************************************************** # Input devices # ********************************************************************** # ********************************************************************** # Core keyboard's InputDevice section # ********************************************************************** Section "InputDevice" Identifier "Keyboard1" Driver "kbd" # For most OSs the protocol can be omitted (it defaults to "Standard"). # When using XQUEUE (only for SVR3 and SVR4, but not Solaris), # uncomment the following line. # Option "Protocol" "Xqueue" Option "AutoRepeat" "500 30" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) # Option "Xleds" "1 2 3" # Option "LeftAlt" "Meta" # Option "RightAlt" "ModeShift" # To customise the XKB settings to suit your keyboard, modify the # lines below (which are the defaults). For example, for a non-U.S. # keyboard, you will probably want to use: # Option "XkbModel" "pc105" # If you have a US Microsoft Natural keyboard, you can use: # Option "XkbModel" "microsoft" # # Then to change the language, change the Layout setting. # For example, a german layout can be obtained with: # Option "XkbLayout" "de" # or: # Option "XkbLayout" "de" # Option "XkbVariant" "nodeadkeys" # # If you'd like to switch the positions of your capslock and # control keys, use: # Option "XkbOptions" "ctrl:swapcaps" # These are the default XKB settings for Xorg # Option "XkbRules" "xorg" # Option "XkbModel" "pc105" # Option "XkbLayout" "us" # Option "XkbVariant" "" # Option "XkbOptions" "" # Option "XkbDisable" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" Option "XkbVariant" "intl" EndSection # ********************************************************************** # Core Pointer's InputDevice section # ********************************************************************** Section "InputDevice" # Identifier and driver Identifier "Mouse1" Driver "mouse" Option "Protocol" "sysmouse" # SysMouse Option "Device" "/dev/sysmouse" # When using XQUEUE, comment out the above two lines, and uncomment # the following line. # Option "Protocol" "Xqueue" # Mouse-speed setting for PS/2 mouse. # Option "Resolution" "256" # Baudrate and SampleRate are only for some Logitech mice. In # almost every case these lines should be omitted. # Option "BaudRate" "9600" # Option "SampleRate" "150" # Mouse wheel mapping. Default is to map vertical wheel to buttons 4 & 5, # horizontal wheel to buttons 6 & 7. Change if your mouse has more than # 3 buttons and you need to map the wheel to different button ids to avoid # conflicts. Option "ZAxisMapping" "4 5 6 7" # Emulate3Buttons is an option for 2-button mice # Emulate3Timeout is the timeout in milliseconds (default is 50ms) # Option "Emulate3Buttons" # Option "Emulate3Timeout" "50" # ChordMiddle is an option for some 3-button Logitech mice # Option "ChordMiddle" EndSection Section "InputDevice" Identifier "Synaptics_Touchpad" Driver "synaptics" #Option "SendCoreEvents" Option "Device" "/dev/psm0" Option "Protocol" "psm" Option "LeftEdge" "1700" Option "RightEdge" "5300" Option "TopEdge" "1700" Option "BottomEdge" "4200" Option "FingerLow" "25" Option "FingerHigh" "30" Option "MaxTapTime" "180" Option "MaxTapMove" "220" Option "VertScrollDelta" "100" Option "HorizScrollDelta" "100" Option "MinSpeed" "0.06" Option "MaxSpeed" "0.06" Option "AccelFactor" "0.0010" Option "ScrollButtonRepeat" "100" Option "UpDownScrolling" "on" Option "UpDownRepeat" "on" Option "LeftRightScrolling" "on" Option "LeftRightRepeat" "on" # "SHMConfig on" seems good works with synclient(1). But this # options is insecure. I recommended "off" as default. Option "SHMConfig" "off" # If you use circular touchpad, uncomment them. # Option "CircularPad" "on" # Option "CircularScrolling" "on" # Option "CircScrollDelta" "0.5" EndSection # ********************************************************************** # Other input device sections # this is optional and is required only if you # are using extended input devices. This is for example only. Refer # to the xorg.conf man page for a description of the options. # ********************************************************************** # # Section "InputDevice" # Identifier "Mouse2" # Driver "mouse" # Option "Protocol" "MouseMan" # Option "Device" "/dev/mouse2" # EndSection # # Section "InputDevice" # Identifier "spaceball" # Driver "magellan" # Option "Device" "/dev/cua0" # EndSection # # Section "InputDevice" # Identifier "spaceball2" # Driver "spaceorb" # Option "Device" "/dev/cua0" # EndSection # # Section "InputDevice" # Identifier "touchscreen0" # Driver "microtouch" # Option "Device" "/dev/ttyS0" # Option "MinX" "1412" # Option "MaxX" "15184" # Option "MinY" "15372" # Option "MaxY" "1230" # Option "ScreenNumber" "0" # Option "ReportingMode" "Scaled" # Option "ButtonNumber" "1" # Option "SendCoreEvents" # EndSection # # Section "InputDevice" # Identifier "touchscreen1" # Driver "elo2300" # Option "Device" "/dev/ttyS0" # Option "MinX" "231" # Option "MaxX" "3868" # Option "MinY" "3858" # Option "MaxY" "272" # Option "ScreenNumber" "0" # Option "ReportingMode" "Scaled" # Option "ButtonThreshold" "17" # Option "ButtonNumber" "1" # Option "SendCoreEvents" # EndSection # ********************************************************************** # Monitor section # ********************************************************************** # Any number of monitor sections may be present Section "Monitor" Identifier "My Monitor" # HorizSync is in kHz unless units are specified. # HorizSync may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. HorizSync 31.5 - 64.3 # HorizSync 30-64 # multisync # HorizSync 31.5, 35.2 # multiple fixed sync frequencies # HorizSync 15-25, 30-50 # multiple ranges of sync frequencies # VertRefresh is in Hz unless units are specified. # VertRefresh may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. VertRefresh 50-100 EndSection # ********************************************************************** # Graphics device section # ********************************************************************** # Any number of graphics device sections may be present # Standard VGA Device: Section "Device" Identifier "Standard VGA" VendorName "Unknown" BoardName "Unknown" # The chipset line is optional in most cases. It can be used to override # the driver's chipset detection, and should not normally be specified. # Chipset "generic" # The Driver line must be present. When using run-time loadable driver # modules, this line instructs the server to load the specified driver # module. Even when not using loadable driver modules, this line # indicates which driver should interpret the information in this section. Driver "vga" # The BusID line is used to specify which of possibly multiple devices # this section is intended for. When this line isn't present, a device # section can only match up with the primary video device. For PCI # devices a line like the following could be used. This line should not # normally be included unless there is more than one video device # intalled. # BusID "PCI:0:10:0" # VideoRam 256 # Clocks 25.2 28.3 EndSection # Device configured by xorgconfig: Section "Device" Identifier "* Generic VESA compatible" Driver "nv" #VideoRam 262144 # Insert Clocks lines here if appropriate EndSection # ********************************************************************** # Screen sections # ********************************************************************** # Any number of screen sections may be present. Each describes # the configuration of a single screen. A single specific screen section # may be specified from the X server command line with the "-screen" # option. Section "Screen" Identifier "Screen 1" Device "* Generic VESA compatible" Monitor "My Monitor" DefaultDepth 24 Subsection "Display" Depth 8 Modes "1280x1024" "1024x768" "800x600" "640x480" ViewPort 0 0 EndSubsection Subsection "Display" Depth 16 Modes "1600x1200" "1024x768" "800x600" "640x480" ViewPort 0 0 EndSubsection Subsection "Display" Depth 24 Modes "1600x1200" ViewPort 0 0 EndSubsection EndSection # ********************************************************************** # ServerLayout sections. # ********************************************************************** # Any number of ServerLayout sections may be present. Each describes # the way multiple screens are organised. A specific ServerLayout # section may be specified from the X server command line with the # "-layout" option. In the absence of this, the first section is used. # When now ServerLayout section is present, the first Screen section # is used alone. Section "ServerLayout" # The Identifier line must be present Identifier "Simple Layout" # Each Screen line specifies a Screen section name, and optionally # the relative position of other screens. The four names after # primary screen name are the screens to the top, bottom, left and right # of the primary screen. In this example, screen 2 is located to the # right of screen 1. Screen "Screen 1" # Each InputDevice line specifies an InputDevice section name and # optionally some options to specify the way the device is to be # used. Those options include "CorePointer", "CoreKeyboard" and # "SendCoreEvents". #InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvent" EndSection # Section "DRI" # Mode 0666 # EndSection --------------070203010408050307010106-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 16:04:16 2008 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 29D6816A417 for ; Mon, 18 Feb 2008 16:04:16 +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 D154313C45A for ; Mon, 18 Feb 2008 16:04:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=HI/VL8ffAZD8Zkeb2qjxwVDM/oBXSfSaJcpk0TtqJN/bKhgmC7tKhpitQ0z+yoCgeiqqjuCxHS4TNe15jLDmuh/Hx3nJ0iA88WKyUJYMevuoEWTIZvUR8KSfgYQNIylnekQinhoqW45wkPwU12Hi+gFmEBEcTQNDO+K1wWt17xo=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JR8TW-000KtE-DB; Mon, 18 Feb 2008 19:04:14 +0300 Date: Mon, 18 Feb 2008 19:04:13 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47B9A8F9.4090700@zirakzigil.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 16:04:16 -0000 Mon, Feb 18, 2008 at 04:49:13PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Yes, the following lines are very suspicious: >> ----- >> ----- >> >> It seems to me that you have another mouse device called '> pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 >> and being SysMouse. Can you show your full xorg.conf? >> > > > Sure, find it attached... Aargh, this is the funny thing: you have no devices that are handled by the 'mouse' driver. And Xorg automatically adds one. Please, uncomment your 'Mouse1' device inside "ServerLayout", start moused and try again. The '' should disappear. And probably mices will start working. It will be good to see Xorg.log from this attempt. Thank you! -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 17:35:25 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id D9D2516A417; Mon, 18 Feb 2008 17:35:24 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Tue, 19 Feb 2008 02:35:24 +0900 From: Norikatsu Shigemura To: Eygene Ryabinkin Message-Id: <20080219023524.22197aee.nork@FreeBSD.org> In-Reply-To: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Giulio Ferro Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:35:25 -0000 Hi Eygene, thanks for your summary! On Mon, 18 Feb 2008 19:04:13 +0300 Eygene Ryabinkin wrote: > >> It seems to me that you have another mouse device called ' >> pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 > >> and being SysMouse. Can you show your full xorg.conf? > > Sure, find it attached... > Aargh, this is the funny thing: you have no devices that are handled > by the 'mouse' driver. And Xorg automatically adds one. > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > moused and try again. The '' should disappear. > And probably mices will start working. > It will be good to see Xorg.log from this attempt. I'm using x11-drivers/synaptics on FreeBSD/i386. I don't have any problem which many people said. I have two questions: a. Anyone, do you install x11-drivers/xf86-input-void? I didn't install x11-drivers/xf86-input-void. b. If you install x11-drivers/xf86-input-void, please check following setting. Section "InputDevice" Identifier "dummy" Driver "void" EndSection I read source files of Xserver and void driver, but I didn't understand these relations:-(. So I don't know that it's correct to fix this problem by way of b. And, if x11-drivers/ xf86-input-void is not installed, that's solution will be crashed. From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 17:36:32 2008 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 1006C16A468; Mon, 18 Feb 2008 17:36:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 703BC13C448; Mon, 18 Feb 2008 17:36:31 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.70] (account mc467741@c2i.net [62.113.133.70] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 811110443; Mon, 18 Feb 2008 17:36:23 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 18 Feb 2008 17:37:22 +0100 User-Agent: KMail/1.9.7 References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> In-Reply-To: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802181737.22947.hselasky@c2i.net> Cc: Tofig Suleymanov , hackers@freebsd.org Subject: Re: if_start() and sending packets problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:36:32 -0000 Hi, > > Doing tcpdump on the interface and pinging does not show any packets > flowing. Please note that tcpdump shows the arp who-has request right > after I assign the ip address. > If think you have to use the BPF macros before you get anything in tcpdump. BTW: Have you looked at any other USB network drivers ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 17:36:32 2008 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 1006C16A468; Mon, 18 Feb 2008 17:36:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 703BC13C448; Mon, 18 Feb 2008 17:36:31 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.133.70] (account mc467741@c2i.net [62.113.133.70] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 811110443; Mon, 18 Feb 2008 17:36:23 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 18 Feb 2008 17:37:22 +0100 User-Agent: KMail/1.9.7 References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> In-Reply-To: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802181737.22947.hselasky@c2i.net> Cc: Tofig Suleymanov , hackers@freebsd.org Subject: Re: if_start() and sending packets problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 17:36:32 -0000 Hi, > > Doing tcpdump on the interface and pinging does not show any packets > flowing. Please note that tcpdump shows the arp who-has request right > after I assign the ip address. > If think you have to use the BPF macros before you get anything in tcpdump. BTW: Have you looked at any other USB network drivers ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 18:23:28 2008 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 4E6C016A419; Mon, 18 Feb 2008 18:23:28 +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 F2C6513C45A; Mon, 18 Feb 2008 18:23:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Xd/0T5OFthp9SxIZNX6FE6m6yp9f4GwJUCuYXuxH4Ywe6uLuFejVw1m2LWenFPKAcOL8vyiajM+hirYeLxKCt4oBSL2xdWCt3shZzTGwgOtVfNgB/5BS3SlyDHqa63aJ6Dd0sc2hp4JnpZoqI5FGhtGZ+OOktiRp8oBg7eH5qjY=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRAeE-000Liq-9W; Mon, 18 Feb 2008 21:23:26 +0300 Date: Mon, 18 Feb 2008 21:23:24 +0300 From: Eygene Ryabinkin To: Norikatsu Shigemura Message-ID: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> <20080219023524.22197aee.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080219023524.22197aee.nork@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-hackers@freebsd.org, Giulio Ferro Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 18:23:28 -0000 Norikatsu, good day. Tue, Feb 19, 2008 at 02:35:24AM +0900, Norikatsu Shigemura wrote: > Hi Eygene, thanks for your summary! You're welcome! > On Mon, 18 Feb 2008 19:04:13 +0300 > Eygene Ryabinkin wrote: > > >> It seems to me that you have another mouse device called ' > >> pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 > > >> and being SysMouse. Can you show your full xorg.conf? > > > Sure, find it attached... > > Aargh, this is the funny thing: you have no devices that are handled > > by the 'mouse' driver. And Xorg automatically adds one. > > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > > moused and try again. The '' should disappear. > > And probably mices will start working. > > It will be good to see Xorg.log from this attempt. > > I'm using x11-drivers/synaptics on FreeBSD/i386. I don't have > any problem which many people said. > > I have two questions: > > a. Anyone, do you install x11-drivers/xf86-input-void? > I didn't install x11-drivers/xf86-input-void. Personally, I am not using xf86-input-void, because I am using standard system mouse with synaptics touchpad, so I don't need 'void' input device. > b. If you install x11-drivers/xf86-input-void, please check > following setting. > > Section "InputDevice" > Identifier "dummy" > Driver "void" > EndSection > > I read source files of Xserver and void driver, but I didn't > understand these relations:-(. If you'll look at http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;h=dbe158efc6e365cd5bd064d848df3a4f0c0d35f4;hb=43d9edd31e31b33b9da4a50d8ab05004881c8d5a;f=hw/xfree86/common/xf86Config.c#l1611 you will see that server tries to add the mouse driver if there is no drivers of type 'mouse' or 'void'. The hack with adding the "dummy" input device with type "void" disables generation of default mouse driver. This was the true hack and it was a bit beautified in http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=ba9f5138fc32a7a7b97bcf941bc92751b7c6c2c0 now there is a boolean option "AllowEmptyInput" that inhibits creation of core mouse and keyboard in any case. > So I don't know that it's > correct to fix this problem by way of b. And, if x11-drivers/ > xf86-input-void is not installed, that's solution will be crashed. Xorg server 1.4 already has "AllowEmptyInput", so Giulio and others who want to run only Synaptics driver, can add the string ----- Option "AllowEmptyInput" ----- to their "ServerFlags" section and see no automagically added devices. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 18:27:51 2008 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 5CDA816A41B; Mon, 18 Feb 2008 18:27:51 +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 1062813C45A; Mon, 18 Feb 2008 18:27:51 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=MlHKiaP6Q7pNOEZcNtAukjZJHdn/24wjJlhCW4c/KQW1o34tKHajQErwWaM+N1UVBs5JX0xdqxbXIF2gRz7GaAugMKyRJUdcY+CzC+gE8QJIKp/B293mFahfYRlXrpCSlp8L5z0QxHA+q5HPC05IYqOQqz0RTcxjFPCJYz8xG1w=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRAiT-000LkI-UH; Mon, 18 Feb 2008 21:27:50 +0300 Date: Mon, 18 Feb 2008 21:27:48 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: Roman Kurakin , freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 18:27:51 -0000 Giulio, Roman, Mon, Feb 18, 2008 at 07:04:13PM +0300, Eygene Ryabinkin wrote: > Aargh, this is the funny thing: you have no devices that are handled > by the 'mouse' driver. And Xorg automatically adds one. > > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > moused and try again. The '' should disappear. > And probably mices will start working. There is a better way that I had found while was answering to Norikatsu's letter: add the string ----- Option "AllowEmptyInput" ----- to your xorg.conf "ServerFlags" section and you should see no additional mouse devices and probably Synaptics mice will be alive. Roman, this concerns you too ;)) Please, try it if you prefer to use single pointer from touchpad. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 18:36:04 2008 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 D8E5D16A419 for ; Mon, 18 Feb 2008 18:36:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id C678513C461 for ; Mon, 18 Feb 2008 18:36:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 18 Feb 2008 10:36:03 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 54718127286; Mon, 18 Feb 2008 10:36:03 -0800 (PST) Message-ID: <47B9D019.2060300@elischer.org> Date: Mon, 18 Feb 2008 10:36:09 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: rmgls@free.fr References: <20080218100621.D4D6E32286D@smtp7-g19.free.fr> In-Reply-To: <20080218100621.D4D6E32286D@smtp7-g19.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: pci support for /usr/share/example/drivers? 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, 18 Feb 2008 18:36:04 -0000 rmgls@free.fr wrote: > Hi, all, > > the scripts in /usr/share/examples/drivers, > Author: Julian Elischer > create two isa skeletons for drivers. > > i would like to create a skeleton for a pci driver. > Please, can you help me by pointing out all diffs needed for this purpose? > > Thanks for your suggestions. > > rmgls@free.fr > _______________________________________________ > 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" Wonderful Idea. Warner was going to do this about 4 years ago He may even have some code sitting around.. :-) From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 21:54:58 2008 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 EB99316A49C for ; Mon, 18 Feb 2008 21:54:58 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 2098713C4CE for ; Mon, 18 Feb 2008 21:54:55 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 89382 invoked by uid 98); 18 Feb 2008 21:54:54 -0000 Received: from 192.168.1.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(192.168.1.11):. Processed in 0.057665 secs); 18 Feb 2008 21:54:54 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(192.168.1.11):. Processed in 0.057665 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@192.168.1.11) by 0 with SMTP; 18 Feb 2008 21:54:53 -0000 Message-ID: <47B9FE9B.2060002@zirakzigil.org> Date: Mon, 18 Feb 2008 22:54:35 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------020002070808090508050600" Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 21:54:59 -0000 This is a multi-part message in MIME format. --------------020002070808090508050600 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > Aargh, this is the funny thing: you have no devices that are handled > by the 'mouse' driver. And Xorg automatically adds one. > > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > moused and try again. The '' should disappear. > And probably mices will start working. > > It will be good to see Xorg.log from this attempt. > Ok, now I've uncommented both mouse1 and synaptics: -------- InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Synaptics_Touchpad" "CorePointer" -------- and the moused demon. Here's is what I get: 1) The mouse pointer now moves 2) The drag and drop with double click on the touchpad _doesn't_ work 3) Window scrolling with the touchpad _doesn't_ work (either horizontally or vertically) I attach the log of the attempt. --------------020002070808090508050600 Content-Type: text/plain; name="xorg_synapt.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xorg_synapt.log" X.Org X Server 1.4.0 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.0-PRERELEASE amd64 Current Operating System: FreeBSD aurynmob2.giulioferro.it 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Wed Jan 30 22:06:30 CET 2008 root@aurynmob2.giulioferro.it:/usr/obj/usr/src/sys/AURYNMOB2 amd64 Build Date: 18 February 2008 10:16:05AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 18 15:46:59 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "* Generic VESA compatible" (**) |-->Input Device "Keyboard1" (**) |-->Input Device "Synaptics_Touchpad" (**) Option "DontVTSwitch" (**) Option "DontZap" (**) Option "DontZoom" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/lib/X11/fonts/local/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/lib/X11/fonts/local/"). (==) Including the default font path /usr/local/lib/X11/fonts/misc/,/usr/local/lib/X11/fonts/TTF/,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1/,/usr/local/lib/X11/fonts/100dpi/,/usr/local/lib/X11/fonts/75dpi/. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (==) RgbPath set to "/usr/local/share/X11/rgb" (==) ModulePath set to "/usr/local/lib/xorg/modules" (II) No default mouse found, adding one (**) |-->Input Device "" (II) Loader magic: 0x680ce0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on freebsd (II) LoadModule: "pcidata" (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (WW) OS did not count PCI devices, guessing wildly (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2a00 card 104d,9016 rev 0c class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2a01 card 0000,0000 rev 0c class 06,04,00 hdr 01 (II) PCI: 00:1a:0: chip 8086,2834 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1a:1: chip 8086,2835 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1a:7: chip 8086,283a card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1b:0: chip 8086,284b card 104d,9016 rev 03 class 04,03,00 hdr 00 (II) PCI: 00:1c:0: chip 8086,283f card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2841 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:2: chip 8086,2843 card 0000,0000 rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2830 card 104d,9016 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2831 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2832 card 104d,9016 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,2836 card 104d,9016 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card 0000,0000 rev f3 class 06,04,01 hdr 01 (II) PCI: 00:1f:0: chip 8086,2811 card 104d,9016 rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,2850 card 104d,9016 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,282a card 104d,9016 rev 03 class 01,04,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,283e card 104d,9016 rev 03 class 0c,05,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0407 card 104d,9016 rev a1 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 11ab,4363 card 104d,9016 rev 13 class 02,00,00 hdr 00 (II) PCI: 06:00:0: chip 8086,4222 card 8086,1051 rev 02 class 02,80,00 hdr 00 (II) PCI: 08:03:0: chip 104c,8039 card fffc,ffff rev 00 class 06,07,00 hdr 82 (II) PCI: 08:03:1: chip 104c,803a card 104d,9016 rev 00 class 0c,00,10 hdr 80 (II) PCI: 08:03:2: chip 104c,803b card 104d,9016 rev 00 class 01,80,00 hdr 80 (II) PCI: 08:04:0: chip 1131,7133 card 1461,e836 rev d1 class 04,80,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,9), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x001a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0x00002000 - 0x00002fff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xcc000000 - 0xceffffff (0x3000000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,3), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0x00003000 - 0x000030ff (0x100) IX[B] [1] -1 0 0x00003400 - 0x000034ff (0x100) IX[B] [2] -1 0 0x00003800 - 0x000038ff (0x100) IX[B] [3] -1 0 0x00003c00 - 0x00003cff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0 0xf0000000 - 0xf1ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 4: bridge is at (0:28:1), (0,4,5), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 4 I/O range: [0] -1 0 0x00004000 - 0x000040ff (0x100) IX[B] [1] -1 0 0x00004400 - 0x000044ff (0x100) IX[B] [2] -1 0 0x00004800 - 0x000048ff (0x100) IX[B] [3] -1 0 0x00004c00 - 0x00004cff (0x100) IX[B] (II) Bus 4 non-prefetchable memory range: [0] -1 0 0xf8000000 - 0xf9ffffff (0x2000000) MX[B] (II) Bus 4 prefetchable memory range: [0] -1 0 0xf2000000 - 0xf3ffffff (0x2000000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 6: bridge is at (0:28:2), (0,6,7), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 6 I/O range: [0] -1 0 0x00005000 - 0x000050ff (0x100) IX[B] [1] -1 0 0x00005400 - 0x000054ff (0x100) IX[B] [2] -1 0 0x00005800 - 0x000058ff (0x100) IX[B] [3] -1 0 0x00005c00 - 0x00005cff (0x100) IX[B] (II) Bus 6 non-prefetchable memory range: [0] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B] (II) Bus 6 prefetchable memory range: [0] -1 0 0xf4000000 - 0xf5ffffff (0x2000000) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 8: bridge is at (0:30:0), (0,8,9), BCTRL: 0x0004 (VGA_EN is cleared) (II) Bus 8 I/O range: [0] -1 0 0x0000f000 - 0x0000f0ff (0x100) IX[B] [1] -1 0 0x0000f400 - 0x0000f4ff (0x100) IX[B] [2] -1 0 0x0000f800 - 0x0000f8ff (0x100) IX[B] [3] -1 0 0x0000fc00 - 0x0000fcff (0x100) IX[B] (II) Bus 8 non-prefetchable memory range: [0] -1 0 0xfc000000 - 0xfc0fffff (0x100000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (II) PCI-to-CardBus bridge: (II) Bus 9: bridge is at (8:3:0), (8,9,9), BCTRL: 0x0744 (VGA_EN is cleared) (--) PCI:*(1:0:0) nVidia Corporation GeForce 8600M GT rev 161, Mem @ 0xce000000/24, 0xd0000000/28, 0xcc000000/25, I/O @ 0x2000/7 (II) Addressable bus resource ranges are [0] -1 0 0x00000000 - 0xffffffff (0x100000000) MX[B] [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) Active PCI resource ranges: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xffffffff (0x4000000) MX[B]E [3] -1 0 0xfc006000 - 0xfc007fff (0x2000) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc307fff (0x4000) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc3fffff (0x100000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304fff (0x800) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018ff (0x40) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018ff (0x20) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018bf (0x20) IX[B]E [21] -1 0 0x00001880 - 0x000018ff (0x80) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000187f (0x40) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x000018ff (0x100) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) PCI Memory resource overlap reduced 0xfc000000 from 0xffffffff to 0xfc003fff (II) PCI Memory resource overlap reduced 0xfc006000 from 0xfc007fff to 0xfc0067ff (II) PCI Memory resource overlap reduced 0xfc304000 from 0xfc307fff to 0xfc3047ff (II) PCI I/O resource overlap reduced 0x000018c0 from 0x000018ff to 0x000018df (II) PCI I/O resource overlap reduced 0x000018e0 from 0x000018ff to 0x000018e7 (II) PCI I/O resource overlap reduced 0x000018a0 from 0x000018bf to 0x000018af (II) PCI I/O resource overlap reduced 0x00001880 from 0x000018ff to 0x0000189f (II) PCI I/O resource overlap reduced 0x00001840 from 0x0000187f to 0x0000185f (II) PCI Memory resource overlap reduced 0xfc300000 from 0xfc3fffff to 0xfc303fff (II) PCI Memory resource overlap reduced 0xfc304800 from 0xfc304fff to 0xfc304bff (II) PCI I/O resource overlap reduced 0x00001800 from 0x000018ff to 0x0000181f (II) Active PCI resource ranges after removing overlaps: [0] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [1] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [2] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [3] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [4] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [5] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [6] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [7] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [8] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [9] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [10] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [11] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [12] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [13] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [14] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [15] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [16] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [17] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [18] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [19] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [20] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [21] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [22] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [23] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [24] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [25] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [26] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) All system resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "freetype" will be loaded. This was enabled by default and also specified in the config file. (II) "type1" will be loaded by default. (II) "record" will be loaded by default. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "freetype" (II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project" compiled for 1.4.0, module version = 2.1.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font FreeType (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) Loading extension XFree86-DRI (II) LoadModule: "synaptics" (II) Loading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) Module synaptics: vendor="X.Org Foundation" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "type1" (II) Loading /usr/local/lib/xorg/modules/fonts//libtype1.so (II) Module type1: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.2 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Type1 (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension RECORD (II) LoadModule: "nv" (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so (II) Module nv: vendor="X.Org Foundation" compiled for 1.4.0, module version = 2.1.7 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) LoadModule: "synaptics" (II) Reloading /usr/local/lib/xorg/modules/input//synaptics_drv.so (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) NV: driver for NVIDIA chipsets: RIVA 128, RIVA TNT, RIVA TNT2, Unknown TNT2, Vanta, RIVA TNT2 Ultra, RIVA TNT2 Model 64, Aladdin TNT2, GeForce 256, GeForce DDR, Quadro, GeForce2 MX/MX 400, GeForce2 MX 100/200, GeForce2 Go, Quadro2 MXR/EX/Go, GeForce2 Integrated GPU, GeForce2 GTS, GeForce2 Ti, GeForce2 Ultra, Quadro2 Pro, GeForce4 MX 460, GeForce4 MX 440, GeForce4 MX 420, GeForce4 MX 440-SE, GeForce4 440 Go, GeForce4 420 Go, GeForce4 420 Go 32M, GeForce4 460 Go, Quadro4 550 XGL, GeForce4 440 Go 64M, Quadro NVS, Quadro4 500 GoGL, GeForce4 410 Go 16M, GeForce4 MX 440 with AGP8X, GeForce4 MX 440SE with AGP8X, GeForce4 MX 420 with AGP8X, GeForce4 MX 4000, GeForce4 448 Go, GeForce4 488 Go, Quadro4 580 XGL, Quadro4 NVS 280 SD, Quadro4 380 XGL, Quadro NVS 50 PCI, GeForce4 448 Go, GeForce4 MX Integrated GPU, GeForce3, GeForce3 Ti 200, GeForce3 Ti 500, Quadro DCC, GeForce4 Ti 4600, GeForce4 Ti 4400, GeForce4 Ti 4200, Quadro4 900 XGL, Quadro4 750 XGL, Quadro4 700 XGL, GeForce4 Ti 4800, GeForce4 Ti 4200 with AGP8X, GeForce4 Ti 4800 SE, GeForce4 4200 Go, Quadro4 700 GoGL, Quadro4 980 XGL, Quadro4 780 XGL, GeForce FX 5800 Ultra, GeForce FX 5800, Quadro FX 2000, Quadro FX 1000, GeForce FX 5600 Ultra, GeForce FX 5600, GeForce FX 5600XT, GeForce FX Go5600, GeForce FX Go5650, Quadro FX Go700, GeForce FX 5200, GeForce FX 5200 Ultra, GeForce FX 5200, GeForce FX 5200LE, GeForce FX Go5200, GeForce FX Go5250, GeForce FX 5500, GeForce FX 5100, GeForce FX Go5200 32M/64M, Quadro NVS 55/280 PCI, Quadro FX 500/600 PCI, GeForce FX Go53xx Series, GeForce FX Go5100, GeForce FX 5900 Ultra, GeForce FX 5900, GeForce FX 5900XT, GeForce FX 5950 Ultra, GeForce FX 5900ZT, Quadro FX 3000, Quadro FX 700, GeForce FX 5700 Ultra, GeForce FX 5700, GeForce FX 5700LE, GeForce FX 5700VE, GeForce FX Go5700, GeForce FX Go5700, Quadro FX Go1000, Quadro FX 1100, GeForce 6800 Ultra, GeForce 6800, GeForce 6800 LE, GeForce 6800 XE, GeForce 6800 XT, GeForce 6800 GT, GeForce 6800 GT, GeForce 6800 GS, GeForce 6800 XT, Quadro FX 4000, GeForce 6800 GS, GeForce 6800, GeForce 6800 LE, GeForce 6800 XT, GeForce Go 6800, GeForce Go 6800 Ultra, Quadro FX Go1400, Quadro FX 3450/4000 SDI, Quadro FX 1400, GeForce 6600 GT, GeForce 6600, GeForce 6600 LE, GeForce 6600 VE, GeForce Go 6600, GeForce 6610 XL, GeForce Go 6600 TE/6200 TE, GeForce 6700 XL, GeForce Go 6600, GeForce Go 6600 GT, Quadro FX 550, Quadro FX 550, Quadro FX 540, GeForce 6200, GeForce 6500, GeForce 6200 TurboCache(TM), GeForce 6200SE TurboCache(TM), GeForce 6200 LE, GeForce Go 6200, Quadro NVS 285, GeForce Go 6400, GeForce Go 6200, GeForce Go 6400, GeForce 6250, GeForce 6800, GeForce 6800 LE, GeForce 6800 GT, GeForce 6800 XT, GeForce 6200, GeForce 6200 A-LE, GeForce 7800 GTX, GeForce 7800 GTX, GeForce 7800 GT, GeForce 7800 GS, GeForce 7800 SLI, GeForce Go 7800, GeForce Go 7800 GTX, Quadro FX 4500, GeForce 7300 LE, GeForce 7300 SE, GeForce Go 7200, GeForce Go 7300, GeForce Go 7400, GeForce Go 7400 GS, Quadro NVS 110M, Quadro NVS 120M, Quadro FX 350M, GeForce 7500 LE, Quadro FX 350, GeForce 7300 GS, GeForce 7600 GT, GeForce 7600 GS, GeForce 7300 GT, GeForce 7600 LE, GeForce 7300 GT, GeForce Go 7700, GeForce Go 7600, GeForce Go 7600 GT, Quadro NVS 300M, GeForce Go 7900 SE, Quadro FX 550M, Quadro FX 560, GeForce 7900 GTX, GeForce 7900 GT, GeForce 7900 GS, GeForce Go 7900 GS, GeForce Go 7900 GTX, Quadro FX 2500M, Quadro FX 1500M, Quadro FX 5500, Quadro FX 3500, Quadro FX 1500, Quadro FX 4500 X2, GeForce 6150, GeForce 6150 LE, GeForce 6100, GeForce Go 6150, GeForce Go 6100, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 Ultra, Quadro FX 5600, Quadro FX 4600, GeForce 8600 GTS, GeForce 8600 GT, GeForce 8400 GS, GeForce 8600M GT, GeForce 8700M GT, Quadro FX 370, Quadro NVS 320M, Quadro FX 570M, Quadro FX 1600M, Quadro FX 570, Quadro FX 1700, GeForce 8500 GT, GeForce 8400 GS, GeForce 8300 GS, GeForce 8600M GS, GeForce 8400M GT, GeForce 8400M GS, GeForce 8400M G, Quadro NVS 140M, Quadro NVS 130M, Quadro NVS 135M, Quadro FX 360M, Quadro NVS 290, GeForce 8800 GT, Quadro FX 3700 (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset GeForce 8600M GT found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [18] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [19] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [20] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [21] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [22] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [23] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [24] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [25] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [26] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [27] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [28] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [29] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [30] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [31] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [32] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [5] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [6] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [7] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [8] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [9] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [10] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [11] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [12] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [13] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [14] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [15] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [16] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [17] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [18] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [19] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [20] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [21] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [22] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [23] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [24] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [25] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [26] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [27] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [28] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [29] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [30] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [31] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [32] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [33] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [34] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [35] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [36] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [37] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (II) NV(0): Initializing int10 (==) NV(0): Write-combining range (0xa0000,0x20000) was already clear (==) NV(0): Write-combining range (0xc0000,0x40000) was already clear (II) NV(0): Primary V_BIOS segment is: 0xc000 (==) NV(0): Write-combining range (0x0,0x1000) was already clear (--) NV(0): Console is VGA mode 0x3 (**) NV(0): Depth 24, (--) framebuffer bpp 32 (==) NV(0): RGB weight 888 (==) NV(0): Default visual is TrueColor (==) NV(0): Using hardware cursor (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (==) NV(0): Write-combining range (0xce000000,0x1000000) was already clear (II) NV(0): MMIO registers mapped at 0x802c00000 (--) NV(0): Total video RAM: 256.0 MB (--) NV(0): BAR1 size: 256.0 MB (--) NV(0): Mapped memory: 255.0 MB (==) NV(0): Write-combining range (0xd0000000,0xff00000) was already clear (II) NV(0): Linear framebuffer mapped at 0x803c00000 (II) Loading sub module "i2c" (II) LoadModule: "i2c"(II) Module "i2c" already built-in (II) Loading sub module "ddc" (II) LoadModule: "ddc"(II) Module "ddc" already built-in (--) NV(0): Connector map: (--) NV(0): [N/A] -> SOR0 (LVDS) (--) NV(0): Bus 0 -> DAC1 (--) NV(0): Bus 1 -> SOR1 (--) NV(0): Load detection: 279 (II) NV(0): I2C bus "I2C0" initialized. (II) NV(0): Output VGA1 using monitor section My Monitor (II) NV(0): I2C bus "I2C1" initialized. (II) NV(0): Output DVI1 has no monitor section (II) NV(0): LVDS native size 1920x1200 (II) NV(0): Output LVDS has no monitor section (II) NV(0): Probing for EDID on I2C bus 0... (II) NV(0): I2C device "I2C0:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C0:ddc2" removed. (II) NV(0): ... none found (--) NV(0): Trying load detection on VGA1 ... nothing. (II) NV(0): Probing for EDID on I2C bus 1... (II) NV(0): I2C device "I2C1:ddc2" registered at address 0xA0. (II) NV(0): I2C device "I2C1:ddc2" removed. (II) NV(0): ... none found (II) NV(0): Output VGA1 disconnected (II) NV(0): Output DVI1 disconnected (II) NV(0): Output LVDS connected (II) NV(0): Output LVDS using initial mode 1920x1200 (--) NV(0): Virtual size is 1920x1920 (pitch 2048) (**) NV(0): Driver mode "1920x1200" (**) NV(0): Default mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (II) NV(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (**) NV(0): Default mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz (II) NV(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (**) NV(0): Default mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 59.9 Hz (II) NV(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (**) NV(0): Default mode "512x384": 32.5 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz (D) (II) NV(0): Modeline "512x384"x60.0 32.50 512 524 592 672 384 385 388 403 doublescan -hsync -vsync (48.4 kHz) (==) NV(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.0 ABI class: X.Org Video Driver, version 2.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B] [1] 0 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B] [2] 0 0 0xce000000 - 0xceffffff (0x1000000) MX[B] [3] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0 0xfc006800 - 0xfc006fff (0x800) MX[B]E [8] -1 0 0xfc005000 - 0xfc005fff (0x1000) MX[B]E [9] -1 0 0xfc000000 - 0xfc003fff (0x4000) MX[B]E [10] -1 0 0xfc006000 - 0xfc0067ff (0x800) MX[B]E [11] -1 0 0xfa000000 - 0xfbffffff (0x2000000) MX[B]E [12] -1 0 0xf6000000 - 0xf7ffffff (0x2000000) MX[B]E [13] -1 0 0xfc304000 - 0xfc3047ff (0x800) MX[B]E [14] -1 0 0xfc304c00 - 0xfc304fff (0x400) MX[B]E [15] -1 0 0xfc300000 - 0xfc303fff (0x4000) MX[B]E [16] -1 0 0xfc304800 - 0xfc304bff (0x400) MX[B]E [17] -1 0 0xcc000000 - 0xcdffffff (0x2000000) MX[B](B) [18] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [19] -1 0 0xce000000 - 0xceffffff (0x1000000) MX[B](B) [20] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [21] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [22] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [23] 0 0 0x00002000 - 0x0000207f (0x80) IX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x00003000 - 0x000030ff (0x100) IX[B]E [27] -1 0 0x00001c00 - 0x00001cff (0x100) IX[B]E [28] -1 0 0x000018c0 - 0x000018df (0x20) IX[B]E [29] -1 0 0x000018b4 - 0x000018b7 (0x4) IX[B]E [30] -1 0 0x000018e0 - 0x000018e7 (0x8) IX[B]E [31] -1 0 0x000018e8 - 0x000018ef (0x8) IX[B]E [32] -1 0 0x000018f0 - 0x000018ff (0x10) IX[B]E [33] -1 0 0x000018a0 - 0x000018af (0x10) IX[B]E [34] -1 0 0x00001880 - 0x0000189f (0x20) IX[B]E [35] -1 0 0x00001860 - 0x0000187f (0x20) IX[B]E [36] -1 0 0x00001840 - 0x0000185f (0x20) IX[B]E [37] -1 0 0x00001820 - 0x0000183f (0x20) IX[B]E [38] -1 0 0x00001800 - 0x0000181f (0x20) IX[B]E [39] -1 0 0x00002000 - 0x0000207f (0x80) IX[B](B) [40] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [41] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (--) NV(0): 239.95 MB available for offscreen pixmaps (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (==) NV(0): Backing store disabled (==) NV(0): Silken mouse enabled (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. (--) RandR disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension XAccessControlExtension (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/local/lib/xorg/modules/extensions//libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (II) NV(0): Setting screen physical size to 508 x 317 (**) Option "CoreKeyboard" (**) Keyboard1: always reports core events (**) Option "Protocol" "standard" (**) Keyboard1: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard1: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard1: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard1: XkbLayout: "us" (**) Option "XkbVariant" "intl" (**) Keyboard1: XkbVariant: "intl" (**) Option "CustomKeycodes" "off" (**) Keyboard1: CustomKeycodes disabled (II) Synaptics touchpad driver version 0.14.6 (1406) (**) Option "Device" "/dev/psm0" (**) Option "SHMConfig" "off" (**) Option "LeftEdge" "1700" (**) Option "RightEdge" "5300" (**) Option "TopEdge" "1700" (**) Option "BottomEdge" "4200" (**) Option "FingerLow" "25" (**) Option "FingerHigh" "30" (**) Option "MaxTapTime" "180" (**) Option "MaxTapMove" "220" (**) Option "VertScrollDelta" "100" (**) Option "HorizScrollDelta" "100" (**) Option "UpDownScrolling" "on" (**) Option "LeftRightScrolling" "on" (**) Option "ScrollButtonRepeat" "100" (--) Synaptics_Touchpad synaptics touchpad found (--) Synaptics Touchpad, model: 0 (--) Firmware: 6.3 (--) Sensor: 1 (--) new absolute packet format (--) Touchpad has extended capability bits (--) -> multifinger detection (--) -> palm detection (**) Option "CorePointer" (**) Synaptics_Touchpad: always reports core events (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/psm0" (--) : Device: "/dev/psm0" (==) : Protocol: "Auto" (**) Option "AlwaysCore" (**) : doesn't report core events (==) : Emulate3Buttons, Emulate3Timeout: 50 (**) : ZAxisMapping: buttons 4 and 5 (**) : Buttons: 9 (**) : Sensitivity: 1 (II) evaluating device () (II) XINPUT: Adding extended input device "" (type: MOUSE) (II) evaluating device (Synaptics_Touchpad) (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) (II) evaluating device (Keyboard1) (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) Synaptics DeviceInit called SynapticsCtrl called. (II) : SetupAuto: hw.iftype is 3, hw.model is 13 (II) : SetupAuto: protocol is SysMouse (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device Synaptics DeviceOn called (EE) xf86OpenSerial: Cannot open device /dev/psm0 Device busy. (WW) Synaptics_Touchpad: cannot open input device couldn't enable device 3 Fatal server error: Caught signal 10. Server aborting Synaptics DeviceOff called --------------020002070808090508050600-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 22:03:03 2008 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 83C2016A418 for ; Mon, 18 Feb 2008 22:03:03 +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 395BB13C4E8 for ; Mon, 18 Feb 2008 22:03:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=H4kas+6X8VM2rONAmsjITKsutdXyfYz06ZRgiIiSTH2ZlsPcTekygAN/2r3dKQA0V0GiOhODMKpYrnY6CHRnuwSK28degrHEbHpjEP3cbi+3H+/ANVDs8ST2usdFNkNCQHZwWw2zEAbS6A460FKO0kGm0mYl9rR3K0juNDa6xnQ=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRE4j-000N0e-UW; Tue, 19 Feb 2008 01:03:02 +0300 Date: Tue, 19 Feb 2008 01:03:00 +0300 From: Eygene Ryabinkin To: Giulio Ferro Message-ID: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> <47B9FE9B.2060002@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47B9FE9B.2060002@zirakzigil.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 22:03:03 -0000 Giulio, Mon, Feb 18, 2008 at 10:54:35PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Please, uncomment your 'Mouse1' device inside "ServerLayout", start >> moused and try again. The '' should disappear. >> And probably mices will start working. > > Ok, now I've uncommented both mouse1 and synaptics: > -------- > InputDevice "Mouse1" "CorePointer" > InputDevice "Keyboard1" "CoreKeyboard" > InputDevice "Synaptics_Touchpad" "CorePointer" > -------- > > and the moused demon. > > Here's is what I get: > 1) The mouse pointer now moves Cool. > 2) The drag and drop with double click on the touchpad _doesn't_ work Never tried this feature myself. Will try it tomorrow on my notebook. Did it ever worked for you? > 3) Window scrolling with the touchpad _doesn't_ work (either horizontally or > vertically) Is something reported if you spawn 'xev' and try to scroll via touchpad while the pointer is upon the xev window? > I attach the log of the attempt. Seems like this is the old one: > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 18 15:46:59 2008 > [...] > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (==) : Protocol: "Auto" > (**) Option "AlwaysCore" > (**) : doesn't report core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) evaluating device () > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (II) evaluating device (Synaptics_Touchpad) > (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) > (II) evaluating device (Keyboard1) > (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 > > Fatal server error: > Caught signal 10. Server aborting > > Synaptics DeviceOff called -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 18 22:09:11 2008 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 07B4116A419 for ; Mon, 18 Feb 2008 22:09:11 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id 1B74613C4D5 for ; Mon, 18 Feb 2008 22:09:09 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 89570 invoked by uid 98); 18 Feb 2008 22:09:08 -0000 Received: from 192.168.1.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:0(192.168.1.11):. Processed in 0.041618 secs); 18 Feb 2008 22:09:08 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:0(192.168.1.11):. Processed in 0.041618 secs) Received: from unknown (HELO aurynmob2.giulioferro.it) (auryn@zirakzigil.org@192.168.1.11) by 0 with SMTP; 18 Feb 2008 22:09:08 -0000 Message-ID: <47BA01F2.1060008@zirakzigil.org> Date: Mon, 18 Feb 2008 23:08:50 +0100 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.5 (X11/20070724) MIME-Version: 1.0 To: Eygene Ryabinkin References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Kurakin , freebsd-hackers@freebsd.org Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 22:09:11 -0000 Eygene Ryabinkin wrote: > There is a better way that I had found while was answering to > Norikatsu's letter: add the string > ----- > Option "AllowEmptyInput" > ----- > to your xorg.conf "ServerFlags" section and you should see no > additional mouse devices and probably Synaptics mice will be alive. > Ok, I'll try tomorrow... From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 01:18:26 2008 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 B764616A418 for ; Tue, 19 Feb 2008 01:18:26 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC0D13C4D5 for ; Tue, 19 Feb 2008 01:18:26 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1595205wxd.7 for ; Mon, 18 Feb 2008 17:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=PVr8prQ2XKeafUqabiDgrepFk5uvCo08TYX9R9yE7Ow=; b=Fpi8qxknBJwaAdrNQIX6RHgk7egLvU9PZ7Cd9fYK5Q0KQui7nzMEs+FY5lzBn/Ho4LOT5wigQ61CqXVfyAr/F8xoUoK73pqI5XliPxIkln9fNkM1n0PUjkGa0mZzY9oP7shxfzAOeARtFieMZTIRsCJerqaDkC9h72vrzC+yb90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=cQpnUZtt1ZXct2t2pQO73lmwitd5b6sYKOtPdApj5WuAYIEH7abSY3u247A3cu2gaTr3xq+xeZsT5jmqc7YLOSOagbXKliolrMep2RddqBy/k2OLLfx1DwS6Kfb92CHyoYBccXo8sPvRg7fKp3vR5Uy6batKChcN3y/PcJJrFpU= Received: by 10.142.127.10 with SMTP id z10mr4892126wfc.122.1203383901874; Mon, 18 Feb 2008 17:18:21 -0800 (PST) Received: by 10.142.51.19 with HTTP; Mon, 18 Feb 2008 17:18:21 -0800 (PST) Message-ID: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> Date: Mon, 18 Feb 2008 17:18:21 -0800 From: "Jerry Toung" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: encrypted executables 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, 19 Feb 2008 01:18:26 -0000 Good afternoon list, anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. I found something called 'burneye' but it's for Linux. Thank you all, Jerry From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 01:38:59 2008 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 A09BD16A479 for ; Tue, 19 Feb 2008 01:38:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 693FD13C50D for ; Tue, 19 Feb 2008 01:38:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:d5b5:6ecd:4337:66df] (unknown [IPv6:2001:7b8:3a7:0:d5b5:6ecd:4337:66df]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 98BA63E; Tue, 19 Feb 2008 02:38:57 +0100 (CET) Message-ID: <47BA3334.4040707@andric.com> Date: Tue, 19 Feb 2008 02:39:00 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.13pre (Windows/20080218) MIME-Version: 1.0 To: Jerry Toung References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> In-Reply-To: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables 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, 19 Feb 2008 01:38:59 -0000 On 2008-02-19 02:18, Jerry Toung wrote: > anybody knows of a tool to encrypt executables under FreeBSD? may be from > the ports? > I am not talking about simple file encryption. Can you elaborate on what you *are* talking about then? Some security-by-obscurity scheme, perhaps? :) From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 02:09:59 2008 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 C97B016A417 for ; Tue, 19 Feb 2008 02:09:59 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 29E8613C43E for ; Tue, 19 Feb 2008 02:09:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1J29uBk014297; Tue, 19 Feb 2008 04:09:56 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1J29uFI024924; Tue, 19 Feb 2008 04:09:56 +0200 Received: from kobe.laptop (adsl48-14.kln.forthnet.gr [77.49.175.14]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1J29si5018136; Tue, 19 Feb 2008 04:09:56 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m1J29rK6009064; Tue, 19 Feb 2008 04:09:53 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m1J29r1g009063; Tue, 19 Feb 2008 04:09:53 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 19 Feb 2008 04:09:52 +0200 From: Giorgos Keramidas To: Dimitry Andric Message-ID: <20080219020952.GA8914@kobe.laptop> References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BA3334.4040707@andric.com> Cc: freebsd-hackers@freebsd.org, Jerry Toung Subject: Re: encrypted executables 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, 19 Feb 2008 02:09:59 -0000 On 2008-02-19 02:39, Dimitry Andric wrote: >On 2008-02-19 02:18, Jerry Toung wrote: >> anybody knows of a tool to encrypt executables under FreeBSD? may be >> from the ports? >> >> I am not talking about simple file encryption. > > Can you elaborate on what you *are* talking about then? Some > security-by-obscurity scheme, perhaps? :) Encrypted executables, using some sort of stream or block cipher may not be something which looks *very* useful, but there are a few interesting things which can be done with executable encryption and signatures. One of them is described here: http://blogs.sun.com/darren/entry/signed_solaris_10_binaries From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 03:54:16 2008 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 81FB516A418 for ; Tue, 19 Feb 2008 03:54:16 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8F213C468 for ; Tue, 19 Feb 2008 03:54:16 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1646666wxd.7 for ; Mon, 18 Feb 2008 19:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=GqkbWYet8zogjIJ5p/o+FkYkJEd9MIzOT9aR9iDoa24=; b=QlvQJDoupeIAEImp8C4VmfYBoY6VGDIY+1mmq5ZbdZP3iYSukR6vU5cE8dtr1nTTJ4p/rbdHz4IjYY6k+XCwLtnFrYnY+PKCvZJkSM3YiRx0sTqX4yJbPKGSnwwufumrkTvvBb6tZDwfRLW0bXRfysxfo6ygAU49+sq7sC4UsRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TMoVzH3RNlky9kPOWsakh3RVxASYYoHOWp+VEGiiE+cT+MonEkt4JEEm3AV6PvEYlb/N7pa92gdZxAu0JmizetwymG2QEA7WPFzNnLakhIC/owIRATa+6GXctOY+8VZzsefIQhMMgLxRCrxQ+SBqU7JOrcPFm4xqlu9JNXUTNG8= Received: by 10.142.133.15 with SMTP id g15mr3765268wfd.9.1203393254583; Mon, 18 Feb 2008 19:54:14 -0800 (PST) Received: by 10.142.51.19 with HTTP; Mon, 18 Feb 2008 19:54:14 -0800 (PST) Message-ID: <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> Date: Mon, 18 Feb 2008 19:54:14 -0800 From: "Jerry Toung" To: "Dimitry Andric" In-Reply-To: <47BA3334.4040707@andric.com> MIME-Version: 1.0 References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables 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, 19 Feb 2008 03:54:16 -0000 On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: > On 2008-02-19 02:18, Jerry Toung wrote: > > anybody knows of a tool to encrypt executables under FreeBSD? may be > from > > the ports? > > I am not talking about simple file encryption. > > Can you elaborate on what you *are* talking about then? Some > security-by-obscurity scheme, perhaps? :) I need to encrypt elf binaries. I'd like to make it harder for the bad guy to reverse engineer my app. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 04:09:21 2008 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 1BBB516A417 for ; Tue, 19 Feb 2008 04:09:21 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 82E6E13C4D1 for ; Tue, 19 Feb 2008 04:09:20 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1J49Ivr009815; Tue, 19 Feb 2008 06:09:18 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1J49IQV008089; Tue, 19 Feb 2008 06:09:18 +0200 Received: from kobe.laptop (adsl48-14.kln.forthnet.gr [77.49.175.14]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1J49FfY023807; Tue, 19 Feb 2008 06:09:16 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m1J49ENx014849; Tue, 19 Feb 2008 06:09:14 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m1J49Dpl014848; Tue, 19 Feb 2008 06:09:13 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 19 Feb 2008 06:09:13 +0200 From: Giorgos Keramidas To: Jerry Toung Message-ID: <20080219040912.GA14809@kobe.laptop> References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> Cc: freebsd-hackers@freebsd.org, Dimitry Andric Subject: Re: encrypted executables 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, 19 Feb 2008 04:09:21 -0000 On 2008-02-18 19:54, Jerry Toung wrote: >On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: >>On 2008-02-19 02:18, Jerry Toung wrote: >>> anybody knows of a tool to encrypt executables under FreeBSD? may be >>> from the ports? I am not talking about simple file encryption. >> >> Can you elaborate on what you *are* talking about then? Some >> security-by-obscurity scheme, perhaps? :) > > I need to encrypt elf binaries. I'd like to make it harder for the bad > guy to reverse engineer my app. You know about truss/ktrace/strace already, right? It may be moot to encrypt the ELF binary, if the `bad guy' can access the running image of the process *after* it has been decrypted to execute. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 04:15:20 2008 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 66FBD16A419 for ; Tue, 19 Feb 2008 04:15:20 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 02EBC13C458 for ; Tue, 19 Feb 2008 04:15:19 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 50913 invoked by uid 1001); 19 Feb 2008 04:14:00 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Mon, 18 Feb 2008 23:13:59 -0500 Date: Mon, 18 Feb 2008 23:13:59 -0500 To: freebsd-hackers@freebsd.org Message-ID: <20080218231359.7601cd70@bhuda.mired.org> In-Reply-To: <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Subject: Re: encrypted executables 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, 19 Feb 2008 04:15:20 -0000 On Mon, 18 Feb 2008 19:54:14 -0800 "Jerry Toung" wrote: > On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: > > On 2008-02-19 02:18, Jerry Toung wrote: > > > anybody knows of a tool to encrypt executables under FreeBSD? may be > > from > > > the ports? > > > I am not talking about simple file encryption. > > > > Can you elaborate on what you *are* talking about then? Some > > security-by-obscurity scheme, perhaps? :) > I need to encrypt elf binaries. I'd like to make it harder for the bad guy > to reverse engineer my app. Basically the DRM problem (only executing your property under conditions you specify, not under those the end user might want). A *lot* of money has been spent trying to do this, but nobody has done it yet. Some very smart people have concluded it can't be done. That said, you did say "harder", not "impossible". Making it harder is certainly possible, depending on the conditions. What are they conditions you want this to work under? FWIW, the only thing that in this area is to not let them run the critical parts of your app on their hardware. Put those on your service, exported via the network, and then give the end user a UI that talks to that. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 04:37:22 2008 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 39BDD16A41B for ; Tue, 19 Feb 2008 04:37:22 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id DD3BC13C459 for ; Tue, 19 Feb 2008 04:37:21 +0000 (UTC) (envelope-from jrytoung@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1658931wxd.7 for ; Mon, 18 Feb 2008 20:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=5BkxP68gf2doZWSjdN8gQok7HWPS1zWnZQI/k7xQrec=; b=iJ4Jz42yJLtnfPaHZxYZZ5/pjuWyCUX7b5nIJIp4+nIar4ayKIDfQZ8+/kMXIrXjqe/8xULV3aQ6SP5vJuySjMAKVqhxNrgPZYAFmqGcsvseJ8VlES6ibRkmSo7JSbywDU/z6FC8u3OecOiyEwD6anOV6INuetZ+YVuHLvyOwmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EEkgSMnjFewFalb1LN0rtcW6TKzCSC7l9OWbIzT7HY2ylHxz+CeFGHAHlg7jkTSDMrKJAdKXvOmC9Z2HjWfnjidzc1aaAxb9l9ttXrQ6Lttx9Lf6/DAhViFIPLus7Sx+ghY6iLg8G7JhhAmugD79QS/j3zMbqfrOwb+p6dA9iSk= Received: by 10.142.104.9 with SMTP id b9mr4992061wfc.48.1203395840507; Mon, 18 Feb 2008 20:37:20 -0800 (PST) Received: by 10.142.51.19 with HTTP; Mon, 18 Feb 2008 20:37:20 -0800 (PST) Message-ID: <86068e730802182037w22073ee9of3f0faae3238c37b@mail.gmail.com> Date: Mon, 18 Feb 2008 20:37:20 -0800 From: "Jerry Toung" To: "Mike Meyer" In-Reply-To: <20080218231359.7601cd70@bhuda.mired.org> MIME-Version: 1.0 References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080218231359.7601cd70@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables 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, 19 Feb 2008 04:37:22 -0000 On Feb 18, 2008 8:13 PM, Mike Meyer < mwm-keyword-freebsdhackers2.e313df@mired.org> wrote: > > Basically the DRM problem (only executing your property under > conditions you specify, not under those the end user might want). A > *lot* of money has been spent trying to do this, but nobody has done > it yet. Some very smart people have concluded it can't be done. > > That said, you did say "harder", not "impossible". Making it harder is > certainly possible, depending on the conditions. What are they > conditions you want this to work under? > > FWIW, the only thing that in this area is to not let them run the > critical parts of your app on their hardware. Put those on your > service, exported via the network, and then give the end user a UI > that talks to that. > thank you all for the feedback. Yep, DRM issues, it doesn't hurt to try. Jerry > > -- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 04:46:04 2008 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 6978916A418 for ; Tue, 19 Feb 2008 04:46:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2748813C43E for ; Tue, 19 Feb 2008 04:46:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1J4dToN032687; Mon, 18 Feb 2008 21:39:29 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 18 Feb 2008 21:44:59 -0700 (MST) Message-Id: <20080218.214459.-861064602.imp@bsdimp.com> To: keramida@ceid.upatras.gr From: "M. Warner Losh" In-Reply-To: <20080219040912.GA14809@kobe.laptop> References: <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, dimitry@andric.com, jrytoung@gmail.com Subject: Re: encrypted executables 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, 19 Feb 2008 04:46:04 -0000 In message: <20080219040912.GA14809@kobe.laptop> Giorgos Keramidas writes: : On 2008-02-18 19:54, Jerry Toung wrote: : >On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: : >>On 2008-02-19 02:18, Jerry Toung wrote: : >>> anybody knows of a tool to encrypt executables under FreeBSD? may be : >>> from the ports? I am not talking about simple file encryption. : >> : >> Can you elaborate on what you *are* talking about then? Some : >> security-by-obscurity scheme, perhaps? :) : > : > I need to encrypt elf binaries. I'd like to make it harder for the bad : > guy to reverse engineer my app. : : You know about truss/ktrace/strace already, right? : : It may be moot to encrypt the ELF binary, if the `bad guy' can access : the running image of the process *after* it has been decrypted to : execute. kill -ABRT will generate a core file. Often times, the core file can be quite useful in recovering the original executable. emacs has used this technique for years to 'preload' stuff, take a core dump, then re-run the core file after some post-processing. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 10:49:05 2008 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 B676F16A420 for ; Tue, 19 Feb 2008 10:49:05 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE5613C465 for ; Tue, 19 Feb 2008 10:49:05 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 66F903F61B2; Tue, 19 Feb 2008 11:49:04 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 268473F61E5; Tue, 19 Feb 2008 11:49:03 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 539CE9BF12; Tue, 19 Feb 2008 10:44:03 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3DFCC405B; Tue, 19 Feb 2008 11:44:03 +0100 (CET) Date: Tue, 19 Feb 2008 11:44:03 +0100 From: Jeremie Le Hen To: "M. Warner Losh" Message-ID: <20080219104403.GF81996@obiwan.tataz.chchile.org> References: <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <20080218.214459.-861064602.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080218.214459.-861064602.imp@bsdimp.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-hackers@FreeBSD.org Subject: Re: encrypted executables 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, 19 Feb 2008 10:49:05 -0000 Hi Warner, On Mon, Feb 18, 2008 at 09:44:59PM -0700, M. Warner Losh wrote: > kill -ABRT > > will generate a core file. > > Often times, the core file can be quite useful in recovering the > original executable. > > emacs has used this technique for years to 'preload' stuff, take a > core dump, then re-run the core file after some post-processing. Do you have some pointers about this, please? Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 12:05:38 2008 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 46F9016A417 for ; Tue, 19 Feb 2008 12:05:38 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id CC8A613C4E3 for ; Tue, 19 Feb 2008 12:05:36 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: by ug-out-1314.google.com with SMTP id y2so1424151uge.37 for ; Tue, 19 Feb 2008 04:05:35 -0800 (PST) Received: by 10.67.119.15 with SMTP id w15mr4432653ugm.73.1203422735278; Tue, 19 Feb 2008 04:05:35 -0800 (PST) Received: from ?192.168.1.5? ( [81.21.81.41]) by mx.google.com with ESMTPS id 31sm6846872ugg.47.2008.02.19.04.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Feb 2008 04:05:34 -0800 (PST) Message-ID: <47BAC5FD.9020906@freebsd.az> Date: Tue, 19 Feb 2008 16:05:17 +0400 From: Tofig Suleymanov User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Hans Petter Selasky References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> <200802181737.22947.hselasky@c2i.net> In-Reply-To: <200802181737.22947.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Feb 2008 12:37:01 +0000 Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: if_start() and sending packets problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 12:05:38 -0000 Hans Petter Selasky wrote: > Hi, > > >> Doing tcpdump on the interface and pinging does not show any packets >> flowing. Please note that tcpdump shows the arp who-has request right >> after I assign the ip address. >> >> > > If think you have to use the BPF macros before you get anything in tcpdump. > > Exactly. > BTW: Have you looked at any other USB network drivers ? > > yes I did. Very helpful. Thanks, Tofig. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 12:30:28 2008 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 2274216A41B for ; Tue, 19 Feb 2008 12:30:28 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id A7DD813C4D1 for ; Tue, 19 Feb 2008 12:30:27 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: by ug-out-1314.google.com with SMTP id y2so1433197uge.37 for ; Tue, 19 Feb 2008 04:30:26 -0800 (PST) Received: by 10.67.119.15 with SMTP id w15mr4432653ugm.73.1203422735278; Tue, 19 Feb 2008 04:05:35 -0800 (PST) Received: from ?192.168.1.5? ( [81.21.81.41]) by mx.google.com with ESMTPS id 31sm6846872ugg.47.2008.02.19.04.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Feb 2008 04:05:34 -0800 (PST) Message-ID: <47BAC5FD.9020906@freebsd.az> Date: Tue, 19 Feb 2008 16:05:17 +0400 From: Tofig Suleymanov User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Hans Petter Selasky References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> <200802181737.22947.hselasky@c2i.net> In-Reply-To: <200802181737.22947.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Feb 2008 13:10:52 +0000 Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: if_start() and sending packets problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 12:30:28 -0000 Hans Petter Selasky wrote: > Hi, > > >> Doing tcpdump on the interface and pinging does not show any packets >> flowing. Please note that tcpdump shows the arp who-has request right >> after I assign the ip address. >> >> > > If think you have to use the BPF macros before you get anything in tcpdump. > > Exactly. > BTW: Have you looked at any other USB network drivers ? > > yes I did. Very helpful. Thanks, Tofig. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 15:17:08 2008 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 1469016A475 for ; Tue, 19 Feb 2008 15:17:08 +0000 (UTC) (envelope-from mcj@bluetonic.org) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by mx1.freebsd.org (Postfix) with ESMTP id 336FC13C4EB for ; Tue, 19 Feb 2008 15:17:06 +0000 (UTC) (envelope-from mcj@bluetonic.org) Received: by ik-out-1112.google.com with SMTP id c21so751811ika.3 for ; Tue, 19 Feb 2008 07:17:05 -0800 (PST) Received: by 10.150.156.9 with SMTP id d9mr2520318ybe.116.1203432750307; Tue, 19 Feb 2008 06:52:30 -0800 (PST) Received: from ico.bluetonic.org ( [70.245.112.92]) by mx.google.com with ESMTPS id a38sm13520593rnc.6.2008.02.19.06.52.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Feb 2008 06:52:28 -0800 (PST) Message-Id: <35B9ADBA-9AA3-4C61-98D7-3AE22B77CD53@bluetonic.org> From: Carey Jones To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 08:52:24 -0600 X-Mailer: Apple Mail (2.919.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help debugging kernel dump? 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, 19 Feb 2008 15:17:08 -0000 I have been getting occasional reboots on my FreeBSD 6-STABLE machine. I haven't figured out a pattern on it yet, but the most recent crash was during some pretty heavy NFS usage, and I see nfsd in the dump, so perhaps that has something to do with it. Could anyone assist in deciphering the cause of this? This is the first time it's crashed on me once I enabled debugging, so I can't say for sure whether or not this is common to all of them. Thanks, -c mcj@ark ~ % uname -a FreeBSD ark.bluetonic.org 6.3-STABLE FreeBSD 6.3-STABLE #4: Wed Jan 23 19:10:47 CST 2008 root@ark.bluetonic.org:/usr/obj/usr/src/sys/ARK i386 root@ark ...src/sys/ARK # kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Unde fined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: free: address 0xca0f6300(0xca0f6000) has not been allocated. Uptime: 18h38m31s Dumping 1279 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1279MB (327408 pages) 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc0553a74 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc0553da6 in panic ( fmt=0xc0744037 "free: address %p(%p) has not been allocated.\n") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0545ab5 in free (addr=0xca0f6300, mtp=0x0) at /usr/src/sys/kern/kern_malloc.c:374 #4 0xc06701f3 in nfssvc_nfsd (td=0x0) at /usr/src/sys/nfsserver/nfs_syscalls.c:544 #5 0xc066f455 in nfssvc (td=0xc522e300, uap=0xed9ced04) at /usr/src/sys/nfsserver/nfs_syscalls.c:181 #6 0xc0711332 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0, tf_ebp = -1077941464, tf_isp = -308482716, tf_ebx = 0, tf_edx = -1077936144, tf_ecx = 2, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671902679, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941492, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984 #7 0xc06fb5ef in Xint0x80_syscall () at /usr/src/sys/i386/i386/ exception.s:200 #8 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 17:34:19 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from freefall.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 7941016A41A; Tue, 19 Feb 2008 17:34:18 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Wed, 20 Feb 2008 02:34:17 +0900 From: Norikatsu Shigemura To: Eygene Ryabinkin Message-Id: <20080220023417.ab04de0f.nork@FreeBSD.org> In-Reply-To: References: <1xLCUYBNbj8sdUVp/UxnkYWg5h4@PIbJXusKFhenD3syFE+hwapDAcI> <47B97C96.1080206@zirakzigil.org> <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> <20080219023524.22197aee.nork@FreeBSD.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Giulio Ferro Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 17:34:19 -0000 Hi Eygene. On Mon, 18 Feb 2008 21:23:24 +0300 Eygene Ryabinkin wrote: > If you'll look at > http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;h=dbe158efc6e365cd5bd064d848df3a4f0c0d35f4;hb=43d9edd31e31b33b9da4a50d8ab05004881c8d5a;f=hw/xfree86/common/xf86Config.c#l1611 > you will see that server tries to add the mouse driver if there is > no drivers of type 'mouse' or 'void'. The hack with adding the "dummy" > input device with type "void" disables generation of default mouse > driver. This was the true hack and it was a bit beautified in > http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=ba9f5138fc32a7a7b97bcf941bc92751b7c6c2c0 > now there is a boolean option "AllowEmptyInput" that inhibits creation > of core mouse and keyboard in any case. Grrrrrrr.... orz > > So I don't know that it's > > correct to fix this problem by way of b. And, if x11-drivers/ > > xf86-input-void is not installed, that's solution will be crashed. > Xorg server 1.4 already has "AllowEmptyInput", so Giulio and others > who want to run only Synaptics driver, can add the string > ----- > Option "AllowEmptyInput" > ----- > to their "ServerFlags" section and see no automagically added devices. I've got it! I confidently committed these solutions! Thank you!! From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 17:51:54 2008 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 82B0F16A498; Tue, 19 Feb 2008 17:51:54 +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 2F2C113C469; Tue, 19 Feb 2008 17:51:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=CwLLAZoUDubWrnMhDpxl9hklcg5QjTeHxnB9h5dNx/iJLjydN/lm0kgUCtTauxr+S4WNNu2cevjGgRJ0OGdyz1+9qqNvz8ZTbY2Fe+So6KWxL0e5SYwnTxMgj3nP64Btl6aAw87coy2K02fDFCBEZeyVpCFTfHzaVsVAuZUOSxU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JRWdD-0004ID-Kb; Tue, 19 Feb 2008 20:51:51 +0300 Date: Tue, 19 Feb 2008 20:51:50 +0300 From: Eygene Ryabinkin To: Norikatsu Shigemura Message-ID: References: <2FpBxFvRMYTG0dQsWse9q7pKV8Y@8Af7teRYKqmQGMEC0xw84kqB83k> <47B98CCC.804@zirakzigil.org> <3l2h+px9k81jQrhpZARxo9ydv5g@Qf/k/EONkq0kVqnQID/zr6zCz2c> <47B99D9B.9050609@zirakzigil.org> <47B9A8F9.4090700@zirakzigil.org> <20080219023524.22197aee.nork@FreeBSD.org> <20080220023417.ab04de0f.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080220023417.ab04de0f.nork@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-hackers@FreeBSD.org, Giulio Ferro Subject: Re: Synaptics Xorg driver for FreeBSD/amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 17:51:54 -0000 Norikatsu, good day. Wed, Feb 20, 2008 at 02:34:17AM +0900, Norikatsu Shigemura wrote: > > Xorg server 1.4 already has "AllowEmptyInput", so Giulio and others > > who want to run only Synaptics driver, can add the string > > ----- > > Option "AllowEmptyInput" > > ----- > > to their "ServerFlags" section and see no automagically added devices. > > I've got it! I confidently committed these solutions! Thank you for the commit! I can only add that the "AllowEmptyInput" appeared in the xorg-server-1.3.99.0, dated 31-Jul-2007 (see http://xorg.freedesktop.org/releases/individual/xserver/). And FreeBSD port of xorg-server was updated from 1.2 to 1.4 at Thu Sep 13 19:44:55 2007: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-server/distinfo.diff?r1=1.7;r2=1.8 So maybe it is worth to mention in the pkg-message about old hack with the 'void' input device -- just in case someone will try to run new Synaptics driver with older xorg-server and problems will arise. > Thank you!! My pleasure! ;)) -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 19:43:44 2008 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 D90E716A41B for ; Tue, 19 Feb 2008 19:43:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 51EE513C459 for ; Tue, 19 Feb 2008 19:43:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1JJheRC044357; Tue, 19 Feb 2008 20:43:42 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1JJhdrJ044356; Tue, 19 Feb 2008 20:43:39 +0100 (CET) (envelope-from olli) Date: Tue, 19 Feb 2008 20:43:39 +0100 (CET) Message-Id: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Feb 2008 20:43:43 +0100 (CET) X-Mailman-Approved-At: Tue, 19 Feb 2008 19:51:49 +0000 Cc: Subject: /boot/loader graphics support & extensibility 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, 19 Feb 2008 19:43:45 -0000 Hi everyone, I'm currently working on adding graphics support to the boot loader. At the moment only the standard VGA mode 640 x 480 at 4 bit depth (16 colors) is supported, but support for other modes can be added in the future. Only i386 and amd64 machines with VGA BIOS are supported. Here's a screen shot of my work in progress: http://www.secnetix.de/olli/FreeBSD/vloader/screenshot.png It will not replace the current text menu ("beastie.4th"), so you can still use it on your Hercules monochrome or CGA machine or with serial console, of course. I need a little help with a few design decisions regarding the implementation. First, I'm not sure if and how the infrastructure of the existing code should be used to allow future support for other architectures or other kind of hardware. This is a list of things that comes to mind: (a) Support for i386/amd64 machines that have VGA hard- ware but no VGA BIOS (this is different from the system BIOS!). Is there a sufficiently large number of such systems that it would be desirable to support them? (b) Support for non-i386/amd64 machines that have VGA hardware (ia64, powerpc, ...). (c) Support for non-VGA graphics hardware (any platform). (d) Did I forget anything? Personally I won't be able to implement any of the above because I only have standard i386/amd64 hardware. But if someone else wants to implement it, my code certainly shouldn't get in the way. Currently my code is simply compiled conditionally, depending on make(1) variables (${MACHINE_ARCH}), so it is only included for i386 and amd64. So, basically, if multiple platforms are supported, the source file with the graphics support functions would be selected based on ${MACHINE_ARCH}. Would that be sufficient? I have looked at the archsw, but I'm not sure if that gives any additional benefit in this case. For a different architecture you ahve to compile a different binary anyway, so it seems that it is sufficient to make the decision at build time, so the additional indirection of the archsw isn't required. Please someone correct me if I'm wrong. By the way, please have a look at the current graphics.h file which defines the interface between the implementation of the graphics functions and FICL: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/olli/boot/ficl/i386/graphics.h By the way, the Forth code that produced the above screen shot only used the PCX functions to load the background image, and the text functions to print the menu. Comments appreciated. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 20:09:07 2008 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 5733816A418; Tue, 19 Feb 2008 20:09:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id C97FD13C448; Tue, 19 Feb 2008 20:09:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 5674B744005; Tue, 19 Feb 2008 22:09:05 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id NaDqh34s+7pb; Tue, 19 Feb 2008 22:09:05 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 19F81744003; Tue, 19 Feb 2008 22:09:03 +0200 (EET) Message-ID: <47BB375C.5010208@icyb.net.ua> Date: Tue, 19 Feb 2008 22:09:00 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> In-Reply-To: <47B84E61.3060401@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: cx_lowest and CPU usage 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, 19 Feb 2008 20:09:07 -0000 More news about the issue. Finally, I stopped being blind and tried to use KTR. Graphs produces by schedgraph confirmed my suspicion that system spends most if its time in idle thread (sleeping). But, but, RTC interrupt hits with high precision into the relatively very short intervals when swi4 runs. It seems that relatively long transition times of C2 on this hardware cause this "synchronization" but I am not sure exactly how. It is even harder to say how long does it take the hardware (chipset+cpu) to wake from that sleep on interrupt. One interesting thing that I immediately noticed is that having DUMMYNET in my kernel caused a huge difference. A typical KTR sequence looks like this: 1. we are in idle thread (apparently sleeping in C2) 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is waken and idle thread enabled interrupts after post-C2 processing) 3. hardclock() checks if there is any timeout to be processed by softclock, and thanks to dummynet, we have its callout scheduled each tick 4. hardclock() schedules swi4 to run I am fuzzy about the following step, I see traces, but I don't know the code. So I write my guess and knowledgeable people can correct me. 5. near the end of interrupt handler routine we have critical_exit() call, it can call mi_switch() if current thread needs to be preempted by a different thread; in this case interrupt code is executed in context of the system idle thread and the idle thread is "owing preemption" to swi4 (see step4) 6. so apparently mi_switch happens in the idle thread and execution jumps to swi4 thread, which now exits from mi_switch() in soft interrupt loop routine 7. so far, starting from step 2, execution is with disabled interrupts; now swi4 unlocks spin mutex lock and that enables interrupts (see the previous message quoted below) 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently it has been pending for some time now 9. statclock is called and because we are on a swi thread this rtc tick is charged to "interrupts" So, here we are. But I am still not sure why the above happens so "deterministically" - RTC interrupt can happen anywhere between 2 clock interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, that shouldn't be enough to always put IRQ0 and IRQ8 "together". Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load on completely idle system. That is still a lot, but is much less than 99% I had before :-) Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and cx_lowest=C2. I hope that this much cleaner experiment would give more insights. But even now we can be sure that our cpu statistics code is not always adequate. This is because IRQ8 is not processed like some super-interrupt that looks on a system from above. It is a regular participant of the system, it competes with IRQ0 and is affected by scheduler's decisions. Especially those made while in interrupt handler. on 17/02/2008 17:10 Andriy Gapon said the following: > on 14/02/2008 23:31 Andriy Gapon said the following: >> I ran a series of tests, repeating each twice to be sure that I didn't >> make any mistake. >> All tests were performed in single-user mode, so the system was as idle >> as possible, top reported idle as 99.N% - 100%. >> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >> Here's the results: >> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% > > I did some testing and here are some additional data. > Running with sched_ule and hz=1000 I measured that mean time spent in C2 > state (from starting to go into it, till completely returning from it) > is ~860us (end_time - start_time, no overhead adjustments). > Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, > the rest is spread almost uniformly over the remaining intervals of > range 0-1000%. > > Here's a typical backtrace for statclock execution: > #9 0xc04cce26 in statclock (usermode=0) at > /system/src/sys/kern/kern_clock.c:447 > #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at > /system/src/sys/i386/isa/clock.c:236 > #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, > frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 > #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at > /system/src/sys/i386/isa/atpic.c:596 > #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 > #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 > #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at > /system/src/sys/kern/kern_intr.c:1137 > #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , > arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 > #17 0xc06a0bc0 in fork_trampoline () at > /system/src/sys/i386/i386/exception.s:205 > > I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from > thread_unlock() in the following snippet: > 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { > 1133 TD_SET_IWAIT(td); > 1134 ie->ie_count = 0; > 1135 mi_switch(SW_VOL, NULL); > 1136 } > 1137 thread_unlock(td); > > This happens almost deterministically. > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 20:38:13 2008 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 077CC16A418 for ; Tue, 19 Feb 2008 20:38:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id E818013C461 for ; Tue, 19 Feb 2008 20:38:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m1JKRED3011385; Tue, 19 Feb 2008 12:27:14 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m1JKRBpd029413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2008 12:27:12 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 12:27:06 -0800 References: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility 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, 19 Feb 2008 20:38:13 -0000 On Feb 19, 2008, at 11:43 AM, Oliver Fromme wrote: > It will not replace the current text menu ("beastie.4th"), > so you can still use it on your Hercules monochrome or CGA > machine or with serial console, of course. We can probably forget about those configurations. > This is a list of things that comes to mind: > > (a) Support for i386/amd64 machines that have VGA hard- > ware but no VGA BIOS (this is different from the > system BIOS!). Is there a sufficiently large number > of such systems that it would be desirable to support > them? Yes, see (b). > (b) Support for non-i386/amd64 machines that have VGA > hardware (ia64, powerpc, ...). Yes, see (a). > (c) Support for non-VGA graphics hardware (any platform). Think sparc64, here. Abstraction of the hardware should be enough to make it easy for someone with the specs in hand and the hardware on the shelf. > Personally I won't be able to implement any of the above > because I only have standard i386/amd64 hardware. But > if someone else wants to implement it, my code certainly > shouldn't get in the way. I agree. > Currently my code is simply compiled conditionally, > depending on make(1) variables (${MACHINE_ARCH}), so it > is only included for i386 and amd64. > > So, basically, if multiple platforms are supported, the > source file with the graphics support functions would be > selected based on ${MACHINE_ARCH}. > > Would that be sufficient? I have looked at the archsw, > but I'm not sure if that gives any additional benefit > in this case. For a different architecture you ahve to > compile a different binary anyway, so it seems that it > is sufficient to make the decision at build time, so the > additional indirection of the archsw isn't required. > Please someone correct me if I'm wrong. True; the archsw is mostly bogus. We can simply call, say, arch_copyin(), rather than do it indirectly with archsw.arch_copyin(). So, there's no need to go through archsw per-se. The point is mostly one of abstracting the hardware using the right "call-back" functions. > Comments appreciated. I love the screenshot. I'm going to use the background in my VTY driver as well :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 19 21:42:59 2008 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 8C4C916A46C; Tue, 19 Feb 2008 21:42:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E1AEC13C4DB; Tue, 19 Feb 2008 21:42:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 150BF744005; Tue, 19 Feb 2008 23:42:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id uUZfMHERMuyN; Tue, 19 Feb 2008 23:42:56 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id C05B6744003; Tue, 19 Feb 2008 23:42:55 +0200 (EET) Message-ID: <47BB4D5C.9000406@icyb.net.ua> Date: Tue, 19 Feb 2008 23:42:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> In-Reply-To: <47BB375C.5010208@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: cx_lowest and CPU usage 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, 19 Feb 2008 21:42:59 -0000 Here are two traces, one for completely idle system (single-user) with C2 disabled and the other with C2 enabled: http://www.icyb.net.ua/~avg/c1.ktr.gz http://www.icyb.net.ua/~avg/c2.ktr.gz Traces are produced with KTR_ALL and taken for approx. 3 seconds (sysctl; sleep 3; sysctl). And a small untidy quick-hack perl script that calculates time difference (in microseconds) between occurrence of a clock interrupt (rtc or clk) and the previous trace line: http://www.icyb.net.ua/~avg/ktr_pl.txt Some interesting results: C1, rtc: values all over the range ("uniformly"), from 1us to 989us; C1, clk: also various values from 2us to 995us, with most values ("naturally") being at the upper end > 900us. C2, clk: handful of values in the lower and middle range, vast majority is higher than 900us C2, rtc: all values are less than 4us (!!!) The last result most probably means that RTC IRQ was not the interrupt to wake CPU from sleeping state. The first possibility that comes to mind is that on this particular hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. Is this possible? Are there known instances of such breakage? Are there other possible explanations? on 19/02/2008 22:09 Andriy Gapon said the following: > More news about the issue. Finally, I stopped being blind and tried to > use KTR. > Graphs produces by schedgraph confirmed my suspicion that system spends > most if its time in idle thread (sleeping). > But, but, RTC interrupt hits with high precision into the relatively > very short intervals when swi4 runs. > It seems that relatively long transition times of C2 on this hardware > cause this "synchronization" but I am not sure exactly how. It is even > harder to say how long does it take the hardware (chipset+cpu) to wake > from that sleep on interrupt. > One interesting thing that I immediately noticed is that having DUMMYNET > in my kernel caused a huge difference. > A typical KTR sequence looks like this: > 1. we are in idle thread (apparently sleeping in C2) > 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is > waken and idle thread enabled interrupts after post-C2 processing) > 3. hardclock() checks if there is any timeout to be processed by > softclock, and thanks to dummynet, we have its callout scheduled each tick > 4. hardclock() schedules swi4 to run > > I am fuzzy about the following step, I see traces, but I don't know the > code. So I write my guess and knowledgeable people can correct me. > 5. near the end of interrupt handler routine we have critical_exit() > call, it can call mi_switch() if current thread needs to be preempted by > a different thread; in this case interrupt code is executed in context > of the system idle thread and the idle thread is "owing preemption" to > swi4 (see step4) > 6. so apparently mi_switch happens in the idle thread and execution > jumps to swi4 thread, which now exits from mi_switch() in soft interrupt > loop routine > 7. so far, starting from step 2, execution is with disabled interrupts; > now swi4 unlocks spin mutex lock and that enables interrupts (see the > previous message quoted below) > 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently > it has been pending for some time now > 9. statclock is called and because we are on a swi thread this rtc tick > is charged to "interrupts" > > So, here we are. But I am still not sure why the above happens so > "deterministically" - RTC interrupt can happen anywhere between 2 clock > interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, > that shouldn't be enough to always put IRQ0 and IRQ8 "together". > > Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and > HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load > on completely idle system. That is still a lot, but is much less than > 99% I had before :-) > > Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and > cx_lowest=C2. I hope that this much cleaner experiment would give more > insights. > > But even now we can be sure that our cpu statistics code is not always > adequate. This is because IRQ8 is not processed like some > super-interrupt that looks on a system from above. It is a regular > participant of the system, it competes with IRQ0 and is affected by > scheduler's decisions. Especially those made while in interrupt handler. > > > > on 17/02/2008 17:10 Andriy Gapon said the following: >> on 14/02/2008 23:31 Andriy Gapon said the following: >>> I ran a series of tests, repeating each twice to be sure that I didn't >>> make any mistake. >>> All tests were performed in single-user mode, so the system was as idle >>> as possible, top reported idle as 99.N% - 100%. >>> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >>> Here's the results: >>> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >>> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >>> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >>> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% >> I did some testing and here are some additional data. >> Running with sched_ule and hz=1000 I measured that mean time spent in C2 >> state (from starting to go into it, till completely returning from it) >> is ~860us (end_time - start_time, no overhead adjustments). >> Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, >> the rest is spread almost uniformly over the remaining intervals of >> range 0-1000%. >> >> Here's a typical backtrace for statclock execution: >> #9 0xc04cce26 in statclock (usermode=0) at >> /system/src/sys/kern/kern_clock.c:447 >> #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at >> /system/src/sys/i386/isa/clock.c:236 >> #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, >> frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 >> #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at >> /system/src/sys/i386/isa/atpic.c:596 >> #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 >> #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 >> #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at >> /system/src/sys/kern/kern_intr.c:1137 >> #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , >> arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 >> #17 0xc06a0bc0 in fork_trampoline () at >> /system/src/sys/i386/i386/exception.s:205 >> >> I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from >> thread_unlock() in the following snippet: >> 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { >> 1133 TD_SET_IWAIT(td); >> 1134 ie->ie_count = 0; >> 1135 mi_switch(SW_VOL, NULL); >> 1136 } >> 1137 thread_unlock(td); >> >> This happens almost deterministically. >> > > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 07:41:25 2008 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 CD51C16A40A for ; Wed, 20 Feb 2008 07:41:25 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8A49C13C442 for ; Wed, 20 Feb 2008 07:41:25 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2010776wri.3 for ; Tue, 19 Feb 2008 23:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=y6iI/Sk2V5S2MP3mMNS3Yfpp74g5JYmS0nrffK9itFA=; b=UBQJ5IRIKWUhsoaB9aqw+3b3IbMZ5LNz58rKpET1SOqDR1vSLzrGDZyTSr3U7IioBJAx+t2OP8Fl46maRXTxlX3OPTmHkJaK8dKUjfJ5qw0m29/xn7/D/kwKDKfzvcuBLg9Ytx5Al3ohGvSQiHZQNyE11669QsCiJcneoY/1+9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=JPRF0912olqzeGib0CRFll8AYLoGw3gLaQGR6kD165L17VVw2e0CBdzda1V4yxqTvN3ro0VU1ALCbDnz8CuIdRbOCNYl9KUsoqaTkibQ14bFVQCC2eshvgSWoFy9bUxLQXxPWbgo+Sf5oy+vOMJSWoG0fL/kp86uQn7vYcRZ1l0= Received: by 10.143.8.10 with SMTP id l10mr6159951wfi.181.1203493283802; Tue, 19 Feb 2008 23:41:23 -0800 (PST) Received: from ?192.168.12.92? ( [213.152.137.38]) by mx.google.com with ESMTPS id 43sm14636612wri.3.2008.02.19.23.41.21 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Feb 2008 23:41:22 -0800 (PST) Message-ID: <47BBD9A2.4000706@gmail.com> Date: Wed, 20 Feb 2008 10:41:22 +0300 From: sam User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [trouble] restart network & vlan`s interface 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, 20 Feb 2008 07:41:25 -0000 hello description of my trouble: part of /etc/rc.conf -------------------------------------- |cloned_interfaces="vlan0" ifconfig_vlan0="inet 10.25.6.20 netmask 255.255.255.0 vlan 11 vlandev rl0" |-------------------------------------- part of command output (/etc/rc.d/netif restart && /etc/rc.d/routing restart) -------------------------------------- |Stopping network: lo0 rl0 pfsync0 pflog0 vlan0. ifconfig: SIOCIFCREATE2: File exists ifconfig: SIOCSETVLAN: Device busy| -------------------------------------- after - vlan0 is not configured -------------------------------------- # uname -rms FreeBSD 7.0-PRERELEASE i386 -------------------------------------- please help me for writing /etc/rc.conf with vlan`s interfaces (without problem network sub-system restart) /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 08:27:40 2008 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 2E42416A403 for ; Wed, 20 Feb 2008 08:27:40 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from hermes.hst.org.za (onix.hst.org.za [209.203.2.133]) by mx1.freebsd.org (Postfix) with ESMTP id 58D2D13C4F0 for ; Wed, 20 Feb 2008 08:27:38 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from sysadmin.hst.org.za (sysadmin.int.dbn.hst.org.za [10.1.1.20]) (authenticated bits=0) by hermes.hst.org.za (8.13.8/8.13.8) with ESMTP id m1K7v2kv045858 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 20 Feb 2008 09:57:02 +0200 (SAST) (envelope-from jonathan+freebsd-hackers@hst.org.za) From: Jonathan McKeown Organization: Health Systems Trust To: freebsd-hackers@freebsd.org User-Agent: KMail/1.7.2 References: <200802191943.m1JJhdrJ044356@lurza.secnetix.de> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline X-UID: 2081 X-Length: 1315 Date: Wed, 20 Feb 2008 10:17:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200802201017.11382.jonathan+freebsd-hackers@hst.org.za> X-Spam-Score: -4.399 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.61 on 209.203.2.133 Subject: Re: /boot/loader graphics support & extensibility 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, 20 Feb 2008 08:27:40 -0000 On Tuesday 19 February 2008 22:27, Marcel Moolenaar wrote: > On Feb 19, 2008, at 11:43 AM, Oliver Fromme wrote: > > It will not replace the current text menu ("beastie.4th"), > > so you can still use it on your Hercules monochrome or CGA > > machine or with serial console, of course. ^^^^^^^^^^^^^^^^^^^ > We can probably forget about those configurations. I hope you just missed the reference to serial console, rather than suggesting that serial console support is going to be dropped in favour of pretty pictures. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 12:57:47 2008 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 9D5D916A404 for ; Wed, 20 Feb 2008 12:57:47 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id C04BC13C44B for ; Wed, 20 Feb 2008 12:57:46 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1KCviUj085855; Wed, 20 Feb 2008 13:57:45 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1KCvibX085854; Wed, 20 Feb 2008 13:57:44 +0100 (CET) (envelope-from olli) Date: Wed, 20 Feb 2008 13:57:44 +0100 (CET) Message-Id: <200802201257.m1KCvibX085854@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Feb 2008 13:57:45 +0100 (CET) X-Mailman-Approved-At: Wed, 20 Feb 2008 13:11:00 +0000 Cc: Subject: Re: /boot/loader graphics support & extensibility 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, 20 Feb 2008 12:57:47 -0000 Marcel Moolenaar wrote: > Oliver Fromme wrote: > > > It will not replace the current text menu ("beastie.4th"), > > so you can still use it on your Hercules monochrome or CGA > > machine or with serial console, of course. > > We can probably forget about those configurations. OK, maybe not Hercules or CGA cards, but there are certainly situations where a pure text-based menu is required. > > This is a list of things that comes to mind: > > > > (a) Support for i386/amd64 machines that have VGA hard- > > ware but no VGA BIOS (this is different from the > > system BIOS!). Is there a sufficiently large number > > of such systems that it would be desirable to support > > them? > > Yes, see (b). > > > (b) Support for non-i386/amd64 machines that have VGA > > hardware (ia64, powerpc, ...). > > Yes, see (a). I understand the "yes" part, but I do not understand the "see (a)/(b)" part. :-) What does the recursive reference mean? Just out of curiosity, what would be examples of machines that fall in categry (a)? I think maybe x86-based Macs which don't have a BIOS (and probably no VGA BIOS either), but do they really have VGA-compatible hardware? I'm sorry if that's a stupid question, I've never touched an x86 Mac. > > (c) Support for non-VGA graphics hardware (any platform). > > Think sparc64, here. Abstraction of the hardware should be > enough to make it easy for someone with the specs in hand > and the hardware on the shelf. Yes, I agree. I played with CG6 graphics hardware on 32bit sparc machines myself, about 12 years ago. > > Currently my code is simply compiled conditionally, > > depending on make(1) variables (${MACHINE_ARCH}), so it > > is only included for i386 and amd64. > > > > So, basically, if multiple platforms are supported, the > > source file with the graphics support functions would be > > selected based on ${MACHINE_ARCH}. > > > > Would that be sufficient? I have looked at the archsw, > > but I'm not sure if that gives any additional benefit > > in this case. For a different architecture you ahve to > > compile a different binary anyway, so it seems that it > > is sufficient to make the decision at build time, so the > > additional indirection of the archsw isn't required. > > Please someone correct me if I'm wrong. > > True; the archsw is mostly bogus. We can simply call, say, > arch_copyin(), rather than do it indirectly with > archsw.arch_copyin(). So, there's no need to go through > archsw per-se. The point is mostly one of abstracting the > hardware using the right "call-back" functions. OK. I will have to implement a certain level of abstraction for the graphics functions anyway: The current code (in perforce) supports 4bit planar modes only, but it should be possible to support other modes (e.g. 8bit linear). Of course, the FICL interface should not need to care about it. Therefore all graphics functions must go through a "switch" that executes the right function depending on the graphics mode. Dos that sound reasonable? However, I'm not sure how to go about the initialization of the graphics mode. Currently I have a FICL word called "vmode" that takes an integer parameter from the stack which is the VGA mode number. That is, this line: 18 vmode will switch to VGA mode 0x12 (that's 640 x 480 @ 4bit) by calling the appropriate VGA BIOS function. This is all in the ficl/i386/* subdirectory, so it's compiled only for the i386 boot loader. If someone else writes support for some sparc64 graphics hardware, that code would be located in ficl/sparc64/* so it would be compiled in when building the loader for sparc64. However, on sparc64 there is no such thing as VGA mode 0x12, so the vmode instruction has to have a different interface. I'm not really sure what to do here. One possible approach would be to let "vmode" take three parameters: x resolution, y resoluton, depth. So you could type: 640 480 4 vmode In that case every graphics driver needs to have a table that maps resolution and depth to mode numbers. OK. But what if the desired mode isn't supported at all? For example, the sparc CG6 does not support the above mode at all. Should the vmode instructon fail in such a case? The above means: When you port a certain graphical boot menu to a different architecture, you will have to change the Forth code. You will probably also have to change other things, such as the font and the background image. The whole idea of a graphical boot menu is inherently unportable. That's why abstracting the hardware is somewhat difficult. > > Comments appreciated. > > I love the screenshot. I'm going to use the background in > my VTY driver as well :-) It's based on the artwork from Anton Gural, so credit should go to him. In fact I simply took the wallpaper from www.freebsd.org/logo.html (the last one at the bottom of that page), modified it a little bit and adapted it to the size and bit depth required for the 640x480 standard VGA mode. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 13:17:45 2008 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 A5EE916A409 for ; Wed, 20 Feb 2008 13:17:45 +0000 (UTC) (envelope-from tdamas@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by mx1.freebsd.org (Postfix) with ESMTP id 3903513C4F8 for ; Wed, 20 Feb 2008 13:17:44 +0000 (UTC) (envelope-from tdamas@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2148131wri.3 for ; Wed, 20 Feb 2008 05:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ekpj1zuJfh9EcI2LOEMAmc1rgGeKgqaJIDYTLyiNVho=; b=Bim5s9jPtbWfx+E1fIpS023Ov2I/OKtkQBrY4eViCRUEoSgNNoAjzjvladiRAl+15RnDh7+ZE8Z6FY8HZNcso1hQg7MJaTbanP7FWY1jXvlarV3QAge1rhqSxbJKPbOuCwA4jK2e3fqxnuq9c1zneoIeu2Tb/b8lr86B/WcAf8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HIb21OxtT02wMoj2sylvxOhOvdfTgzD19PMfT1X0SsQWp40J6eVW/lKD9vkOAUvEbNKV8ej34gnhfHNajWnbil6T9gV17/+jVk6sZmU+qp07anTzVWzFrrSiR6ziBjw2T/AoKzkAS0QEmpfnFsSIqAVNdNkQU0mYPA9rMBYiR3U= Received: by 10.142.172.12 with SMTP id u12mr4120575wfe.168.1203511883330; Wed, 20 Feb 2008 04:51:23 -0800 (PST) Received: by 10.142.200.17 with HTTP; Wed, 20 Feb 2008 04:51:23 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 09:51:23 -0300 From: "Thiago Damas" To: freebsd-hackers@freebsd.org In-Reply-To: <20080219040912.GA14809@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> Subject: Re: encrypted executables 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, 20 Feb 2008 13:17:45 -0000 And if you make a wrapper, and execute like a shell script: #!/usr/local/bin/mysecyritywrapper <...encryted code goes where...> In this way. it'll be hard to use truss, ktrace, strace etc... []s On Feb 19, 2008 1:09 AM, Giorgos Keramidas wrote: > On 2008-02-18 19:54, Jerry Toung wrote: > >On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: > >>On 2008-02-19 02:18, Jerry Toung wrote: > >>> anybody knows of a tool to encrypt executables under FreeBSD? may be > >>> from the ports? I am not talking about simple file encryption. > >> > >> Can you elaborate on what you *are* talking about then? Some > >> security-by-obscurity scheme, perhaps? :) > > > > I need to encrypt elf binaries. I'd like to make it harder for the bad > > guy to reverse engineer my app. > > You know about truss/ktrace/strace already, right? > > It may be moot to encrypt the ELF binary, if the `bad guy' can access > the running image of the process *after* it has been decrypted to > execute. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 14:12:42 2008 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 8DB2B16A415 for ; Wed, 20 Feb 2008 14:12:42 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5BC13C465 for ; Wed, 20 Feb 2008 14:12:41 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id B8CF55F41 for ; Wed, 20 Feb 2008 14:52:48 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zQETDUA6mt+N for ; Wed, 20 Feb 2008 14:52:45 +0100 (CET) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id BD1D45F1A for ; Wed, 20 Feb 2008 14:52:45 +0100 (CET) Message-ID: <47BC30AD.20600@bsdunix.ch> Date: Wed, 20 Feb 2008 14:52:45 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.9 (X11/20080218) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------030309040008010403090205" Subject: new syslogd option for adding local timestamp 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, 20 Feb 2008 14:12:42 -0000 This is a multi-part message in MIME format. --------------030309040008010403090205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi list I ported the -T option from netbsd syslogd.c to freebsd syslog. "Add a -T flag to syslogd, which causes it to use local time for messages received from the network. Useful for collecting logs from devices which do not have correct time or if you need localtime anyway. It does not replace original timestamp. It just adds the localtime at the beginning of the string" Is this done correctly? I had no trouble during my tests with remote logging from several router and switches from cisco and foundry. If everything is correct, any chance we can add this to freebsd syslogd? Regards, Tom --------------030309040008010403090205 Content-Type: text/plain; name="syslogd.c-diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslogd.c-diff" --- syslogd.c.orig 2008-02-20 14:00:11.000000000 +0100 +++ syslogd.c 2008-02-20 14:00:27.000000000 +0100 @@ -292,6 +292,7 @@ struct allowedpeer *AllowedPeers; /* List of allowed peers */ static int NumAllowed; /* Number of entries in AllowedPeers */ +static int RemoteAddDate; /* always add date to messages from network */ static int UniquePriority; /* Only log specified priority? */ static int LogFacPri; /* Put facility and priority in log message: */ @@ -321,7 +322,7 @@ static void log_deadchild(pid_t, int, const char *); static void markit(void); static int skip_message(const char *, const char *, int); -static void printline(const char *, char *); +static void printline(const char *, char *, int); static void printsys(char *); static int p_open(const char *, pid_t *); static void readklog(void); @@ -351,7 +352,7 @@ socklen_t len; bindhostname = NULL; - while ((ch = getopt(argc, argv, "46Aa:b:cCdf:kl:m:nop:P:sS:uv")) != -1) + while ((ch = getopt(argc, argv, "46Aa:b:cCdf:kl:m:nop:P:sS:Tuv")) != -1) switch (ch) { case '4': family = PF_INET; @@ -448,6 +449,9 @@ errx(1, "%s path too long, exiting", optarg); funix_secure.name = optarg; break; + case 'T': + RemoteAddDate = 1; + break; case 'u': /* only log specified priority */ UniquePriority++; break; @@ -640,7 +644,7 @@ hname = cvthname((struct sockaddr *)&frominet); unmapped((struct sockaddr *)&frominet); if (validate((struct sockaddr *)&frominet, hname)) - printline(hname, line); + printline(hname, line, RemoteAddDate ? ADDDATE : 0); } else if (l < 0 && errno != EINTR) logerror("recvfrom inet"); } @@ -653,7 +657,7 @@ (struct sockaddr *)&fromunix, &len); if (l > 0) { line[l] = '\0'; - printline(LocalHostName, line); + printline(LocalHostName, line, 0); } else if (l < 0 && errno != EINTR) logerror("recvfrom unix"); } @@ -693,7 +697,7 @@ { fprintf(stderr, "%s\n%s\n%s\n%s\n", - "usage: syslogd [-46ACcdknosuv] [-a allowed_peer]", + "usage: syslogd [-46ACcdknosTuv] [-a allowed_peer]", " [-b bind_address] [-f config_file]", " [-l [mode:]path] [-m mark_interval]", " [-P pid_file] [-p log_socket]"); @@ -705,7 +709,7 @@ * on the appropriate log files. */ static void -printline(const char *hname, char *msg) +printline(const char *hname, char *msg, int flags) { char *p, *q; long n; @@ -758,7 +762,7 @@ } *q = '\0'; - logmsg(pri, line, hname, 0); + logmsg(pri, line, hname, flags); } /* --------------030309040008010403090205 Content-Type: text/plain; name="syslogd.8-diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslogd.8-diff" --- syslogd.8.orig 2008-02-20 14:18:55.000000000 +0100 +++ syslogd.8 2008-02-20 14:18:59.000000000 +0100 @@ -225,6 +225,12 @@ If specified twice, no network socket will be opened at all, which also disables logging to remote machines. +.It Fl T +Always use the local time and date for messages received from the +network, instead of the timestamp field supplied in the message +by the remote host. +This is useful if some of the originating hosts can't keep time +properly or are unable to generate a correct timestamp. .It Fl u Unique priority logging. Only log messages at the specified priority. @@ -291,6 +297,14 @@ option is specified); therefore, they must be created manually before running .Nm . +.Pp +The date and time are taken from the received message. +If the format of the timestamp field is incorrect, time obtained from +the local host is used instead. +This can be overriden by the +.Fl T +flag. +.Pp .Sh FILES .Bl -tag -width /var/run/syslog.pid -compact .It Pa /etc/syslog.conf --------------030309040008010403090205-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 15:48:09 2008 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 E60E116A404 for ; Wed, 20 Feb 2008 15:48:09 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 82BAB13C44B for ; Wed, 20 Feb 2008 15:48:09 +0000 (UTC) (envelope-from mwm@mired.org) Received: (qmail 44848 invoked from network); 20 Feb 2008 15:46:47 -0000 Received: from unknown (HELO mbook-fbsd) (192.168.195.2) by 0 with SMTP; 20 Feb 2008 15:46:47 -0000 Date: Wed, 20 Feb 2008 10:47:16 -0500 From: Mike Meyer To: "Thiago Damas" Message-ID: <20080220104716.339552f3@mbook-fbsd> In-Reply-To: References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> Organization: Meyer Consulting X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.5; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Feb 2008 15:55:17 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables 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, 20 Feb 2008 15:48:10 -0000 On Wed, 20 Feb 2008 09:51:23 -0300 "Thiago Damas" wrote: > And if you make a wrapper, and execute like a shell script: > > #!/usr/local/bin/mysecyritywrapper > <...encryted code goes where...> > > > In this way. it'll be hard to use truss, ktrace, strace etc... Depends on how you're using "hard". If you mean "lots of work", then yes, it'll make it harder by adding work. If you mean "difficult", then no, it won't make it harder, because the extra work you added is all well understood, so it's just more work, not more difficult work. Me, I'd use gcore to get an ELF core image. Turning that into a real executable is a well-understood process. Any modern LISP system will have tools to do it, and emacs has been doing it for decades to get a binary with all the emacs elisp packages pre-loaded. If that's to much work, you start by dissecting mysecuritywrapper, which is pretty much exactly as hard as dissecting the executable sans encryption. After that's done, you can replace it with your own code to take advantage of those tools. Either way, this just adds more work, not more difficulty. []s > > > > On Feb 19, 2008 1:09 AM, Giorgos Keramidas wrote: > > On 2008-02-18 19:54, Jerry Toung wrote: > > >On Feb 18, 2008 5:39 PM, Dimitry Andric wrote: > > >>On 2008-02-19 02:18, Jerry Toung wrote: > > >>> anybody knows of a tool to encrypt executables under FreeBSD? may be > > >>> from the ports? I am not talking about simple file encryption. > > >> > > >> Can you elaborate on what you *are* talking about then? Some > > >> security-by-obscurity scheme, perhaps? :) > > > > > > I need to encrypt elf binaries. I'd like to make it harder for the bad > > > guy to reverse engineer my app. > > > > You know about truss/ktrace/strace already, right? > > > > It may be moot to encrypt the ELF binary, if the `bad guy' can access > > the running image of the process *after* it has been decrypted to > > execute. > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Mike Meyer http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 16:19:21 2008 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 96CEB16A405 for ; Wed, 20 Feb 2008 16:19:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id F411013C447 for ; Wed, 20 Feb 2008 16:19:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1KGJJHE099848; Wed, 20 Feb 2008 10:19:19 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1KGJJUj099847; Wed, 20 Feb 2008 10:19:19 -0600 (CST) (envelope-from brooks) Date: Wed, 20 Feb 2008 10:19:19 -0600 From: Brooks Davis To: sam Message-ID: <20080220161919.GA99421@lor.one-eyed-alien.net> References: <47BBD9A2.4000706@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <47BBD9A2.4000706@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 20 Feb 2008 10:19:19 -0600 (CST) Cc: freebsd-hackers@freebsd.org Subject: Re: [trouble] restart network & vlan`s interface 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, 20 Feb 2008 16:19:21 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 10:41:22AM +0300, sam wrote: > hello >=20 > description of my trouble: >=20 > part of /etc/rc.conf > -------------------------------------- > |cloned_interfaces=3D"vlan0" > ifconfig_vlan0=3D"inet 10.25.6.20 netmask 255.255.255.0 vlan 11 vlandev r= l0" > |-------------------------------------- >=20 > part of command output (/etc/rc.d/netif restart && /etc/rc.d/routing=20 > restart) > -------------------------------------- > |Stopping network: lo0 rl0 pfsync0 pflog0 vlan0. > ifconfig: SIOCIFCREATE2: File exists > ifconfig: SIOCSETVLAN: Device busy| > -------------------------------------- > after - vlan0 is not configured >=20 > -------------------------------------- > # uname -rms > FreeBSD 7.0-PRERELEASE i386 > -------------------------------------- >=20 > please help me for writing /etc/rc.conf with vlan`s interfaces (withou= t=20 > problem network sub-system restart) We don't really support running /etc/rc.d/netif restart without an interface argument at this time. We should probably catch that case and report an error until someone finds time to fix it. -- Brooks --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHvFMGXY6L6fI4GtQRAivfAJ9aqYOiJA97syg+AphEIyuYgEy1JACgnO4R uKCwY1KcfDWjwIPSZi807Fs= =NjO3 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:01:00 2008 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 F183F16A402 for ; Wed, 20 Feb 2008 17:01:00 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 79DEA13C468 for ; Wed, 20 Feb 2008 17:01:00 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2170307fgg.35 for ; Wed, 20 Feb 2008 09:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=q3ZVDpu5ZJOMCQDnwGWkcwxE7UAFnsVAgUiNYtB4pRU=; b=hi80LI+7ntZ7Y2+MRIAq6djmIGg/PnI3+IMBdXqnCEeboBCZhUtZILTOrN1DXnTpO4M1nmYHN4a0Dv74ZGiNeByylDLJnnjQNImI0ZoiW/7FYLEz56+ueEfg9kVaXLDWxnRbfVCjgMfR2YrJDFDyrBUf6fsegzlTZjRirmFiydU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZZo2m3dl7Yej+LWnNJihZkqD9dFRFIpx2AJQSSOgju+TBrbL/N0PGJPTqG1b8TfA08H5f3Sh7odySJN9yKPh9WfrufSV0JMi+fNEQ4gYK9y6ZyyIqEap8n6JJrlA2o5JplHK50yI1gr/bdziLUdf7eM6h4el0Tq1X2vouRha3Hg= Received: by 10.86.72.15 with SMTP id u15mr8452725fga.11.1203526859535; Wed, 20 Feb 2008 09:00:59 -0800 (PST) Received: from ?192.168.12.92? ( [217.74.44.57]) by mx.google.com with ESMTPS id 3sm14136930fge.7.2008.02.20.09.00.57 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Feb 2008 09:00:58 -0800 (PST) Message-ID: <47BC5CCA.8060003@gmail.com> Date: Wed, 20 Feb 2008 20:00:58 +0300 From: sam User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brooks Davis References: <47BBD9A2.4000706@gmail.com> <20080220161919.GA99421@lor.one-eyed-alien.net> In-Reply-To: <20080220161919.GA99421@lor.one-eyed-alien.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [trouble] restart network & vlan`s interface 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, 20 Feb 2008 17:01:01 -0000 Brooks Davis wrote: > On Wed, Feb 20, 2008 at 10:41:22AM +0300, sam wrote: > >> >> please help me for writing /etc/rc.conf with vlan`s interfaces (without >> problem network sub-system restart) >> > > We don't really support running /etc/rc.d/netif restart without an interface > argument at this time. We should probably catch that case and report an > error until someone finds time to fix it. > > -- Brooks > i have this trouble with command: # /etc/netstart restart /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:08:27 2008 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 336AE16A404; Wed, 20 Feb 2008 17:08:27 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 904C713C474; Wed, 20 Feb 2008 17:08:26 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1KH8PQN000399; Wed, 20 Feb 2008 11:08:25 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1KH8P6V000398; Wed, 20 Feb 2008 11:08:25 -0600 (CST) (envelope-from brooks) Date: Wed, 20 Feb 2008 11:08:25 -0600 From: Brooks Davis To: sam Message-ID: <20080220170825.GA347@lor.one-eyed-alien.net> References: <47BBD9A2.4000706@gmail.com> <20080220161919.GA99421@lor.one-eyed-alien.net> <47BC5CCA.8060003@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <47BC5CCA.8060003@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 20 Feb 2008 11:08:25 -0600 (CST) Cc: freebsd-hackers@freebsd.org, Brooks Davis Subject: Re: [trouble] restart network & vlan`s interface 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, 20 Feb 2008 17:08:27 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 08:00:58PM +0300, sam wrote: > Brooks Davis wrote: >> On Wed, Feb 20, 2008 at 10:41:22AM +0300, sam wrote: >> =20 >>>=20 >>> please help me for writing /etc/rc.conf with vlan`s interfaces=20 >>> (without problem network sub-system restart) >>> =20 >>=20 >> We don't really support running /etc/rc.d/netif restart without an=20 >> interface >> argument at this time. We should probably catch that case and report an >> error until someone finds time to fix it. >>=20 >> -- Brooks >> =20 > i have this trouble with command: >=20 > # /etc/netstart restart=20 /etc/netstart just ignores it's arguments. It's really intended for those times when you want to bring networking up from singleuser mode, not what you chance configurations. We do not currently have a one-size-fits-all mechanism for handling network configuration changes. -- Brooks --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHvF6IXY6L6fI4GtQRAt6XAKCpNW/tOrt0olrG6JRQshTYt5d2bgCeIAvd PkbFwQe68PrS8bUQkH9XDxk= =UDKB -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 17:26:23 2008 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 12F8116A400 for ; Wed, 20 Feb 2008 17:26:23 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.73]) by mx1.freebsd.org (Postfix) with ESMTP id E94E113C457 for ; Wed, 20 Feb 2008 17:26:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp008-s [10.150.69.71]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id m1KHQMT8008598; Wed, 20 Feb 2008 09:26:22 -0800 (PST) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp008/MantshX 4.0) with ESMTP id m1KHPTtN021690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2008 09:25:43 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802201257.m1KCvibX085854@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 09:25:28 -0800 References: <200802201257.m1KCvibX085854@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility 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, 20 Feb 2008 17:26:23 -0000 On Feb 20, 2008, at 4:57 AM, Oliver Fromme wrote: > Marcel Moolenaar wrote: >> Oliver Fromme wrote: >> >>> It will not replace the current text menu ("beastie.4th"), >>> so you can still use it on your Hercules monochrome or CGA >>> machine or with serial console, of course. >> >> We can probably forget about those configurations. > > OK, maybe not Hercules or CGA cards, but there are > certainly situations where a pure text-based menu is > required. Yes, agreed. Maybe we should just call them serial consoles, knowing that they don't have to be. >>> This is a list of things that comes to mind: >>> >>> (a) Support for i386/amd64 machines that have VGA hard- >>> ware but no VGA BIOS (this is different from the >>> system BIOS!). Is there a sufficiently large number >>> of such systems that it would be desirable to support >>> them? >> >> Yes, see (b). >> >>> (b) Support for non-i386/amd64 machines that have VGA >>> hardware (ia64, powerpc, ...). >> >> Yes, see (a). > > I understand the "yes" part, but I do not understand the > "see (a)/(b)" part. :-) What does the recursive reference > mean? It means that they can be treated the same: there's no VGA BIOS that can be used. There may be support in the firmware for setting graphics mode, but once you have the abstraction in place, then that just falls into place. > Just out of curiosity, what would be examples of machines > that fall in categry (a)? I think maybe x86-based Macs > which don't have a BIOS (and probably no VGA BIOS either), > but do they really have VGA-compatible hardware? Yes. They have VGA compatible hardware. They either have the Intel chipset (Mac Mini) or nVidia (MacBook). Both start up in VGA compatible mode by default, but which EFI puts in some non-VGA mode right from the start. >>> (c) Support for non-VGA graphics hardware (any platform). >> >> Think sparc64, here. Abstraction of the hardware should be >> enough to make it easy for someone with the specs in hand >> and the hardware on the shelf. > > Yes, I agree. I played with CG6 graphics hardware on 32bit > sparc machines myself, about 12 years ago. > >>> Currently my code is simply compiled conditionally, >>> depending on make(1) variables (${MACHINE_ARCH}), so it >>> is only included for i386 and amd64. >>> >>> So, basically, if multiple platforms are supported, the >>> source file with the graphics support functions would be >>> selected based on ${MACHINE_ARCH}. >>> >>> Would that be sufficient? I have looked at the archsw, >>> but I'm not sure if that gives any additional benefit >>> in this case. For a different architecture you ahve to >>> compile a different binary anyway, so it seems that it >>> is sufficient to make the decision at build time, so the >>> additional indirection of the archsw isn't required. >>> Please someone correct me if I'm wrong. >> >> True; the archsw is mostly bogus. We can simply call, say, >> arch_copyin(), rather than do it indirectly with >> archsw.arch_copyin(). So, there's no need to go through >> archsw per-se. The point is mostly one of abstracting the >> hardware using the right "call-back" functions. > > OK. > > I will have to implement a certain level of abstraction > for the graphics functions anyway: The current code > (in perforce) supports 4bit planar modes only, but it > should be possible to support other modes (e.g. 8bit > linear). Of course, the FICL interface should not need > to care about it. Therefore all graphics functions must > go through a "switch" that executes the right function > depending on the graphics mode. > > Dos that sound reasonable? I haven't looked at the code yet, so I don't know which graphics functions we're talking about. You may want to keep in mind that EFI basically defines a single graphics function: bitblt. If the graphics functions are variations of bitblt, then yes, it's very reasonable. > However, I'm not sure how to go about the initialization > of the graphics mode. Currently I have a FICL word > called "vmode" that takes an integer parameter from the > stack which is the VGA mode number. That is, this line: > > 18 vmode > > will switch to VGA mode 0x12 (that's 640 x 480 @ 4bit) > by calling the appropriate VGA BIOS function. This is > all in the ficl/i386/* subdirectory, so it's compiled > only for the i386 boot loader. > > If someone else writes support for some sparc64 graphics > hardware, that code would be located in ficl/sparc64/* > so it would be compiled in when building the loader for > sparc64. > > However, on sparc64 there is no such thing as VGA mode > 0x12, so the vmode instruction has to have a different > interface. I'm not really sure what to do here. > > One possible approach would be to let "vmode" take > three parameters: x resolution, y resoluton, depth. > So you could type: > > 640 480 4 vmode > > In that case every graphics driver needs to have a table > that maps resolution and depth to mode numbers. OK. > But what if the desired mode isn't supported at all? > For example, the sparc CG6 does not support the above > mode at all. Should the vmode instructon fail in such > a case? Why not have the platform set a suitable graphics mode? In other words: rather than have the end-user code determine a mode, which they can't do reliably, why not have the mode be set for the end-user code. It seems to me that there are 2 ways of thinking about consoles. One is the traditional way of not assuming too much and just use the console in a serial fashion so that it works with dump terminals as well. The other is the graphical way of thinking which removes any and all levels of abstraction (other than using BIOS mode numbers????) and demands that the user can set every little bit that can be set. There's an in-between. The loader exists only to load a kernel. We want it to look nice, but there's no reason to tweak resolutions so that you can see the kernel being loader in HD. The platform, which includes the firmware, knows best which resolutions look good. This could very well be a non-VGA mode. The best thing we can do is work with what is given to us by the firmware or the platform. Then it will look nice and it will work in cases we don't know how to set the mode, but we know it's graphical. > The whole idea of a graphical boot menu is inherently > unportable. That's why abstracting the hardware is > somewhat difficult. It's not unportable, it's just parameterized :-) I'm not going to suggest that you write for all platforms and hardware combinations. I hope however that with some thought you can implement it for i386 with VGA BIOS in such a way that someone can later extend the support in some direction, without having to rewrite the whole thing... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 18:27:56 2008 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 725B116A404 for ; Wed, 20 Feb 2008 18:27:56 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id EEF1B13C46B for ; Wed, 20 Feb 2008 18:27:55 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so1205916tid.3 for ; Wed, 20 Feb 2008 10:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=OjcaEQWI5osc0iuvaHSr1U/78BbbTSPbSy5usQ8nJfg=; b=RSPOXjzIS6COdmX3t1Lo9g71+UrphfFWC6lMI3CK3asacVnwpswIq/TpkNLIIxtHVs0s2gaH1abMfXWsLW5xemMTjYjtjSn+Ra+lXXdO9CVGAG3TSihOnRNkhLxOWNC3W+otrwtHuf8Bo+qo3sMtxrA3dXwWyhi6kHdSgZvtVhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lqLcqE21gLVFqLcdhMynvV7/8mVHS04l+LIPgsavewDXHCxNNQev9AHVwTr/lDooL6XM1lyzHRpegKsHPC7PLyEOeqcKMJ4+PuJuwCSwJhRy4f123ZB9CkndTwFETlPQuv4AjLVIugrsZA+JaprjimwjPBbZQB195We8TpOERjk= Received: by 10.150.148.7 with SMTP id v7mr2853398ybd.26.1203532073083; Wed, 20 Feb 2008 10:27:53 -0800 (PST) Received: by 10.64.195.8 with HTTP; Wed, 20 Feb 2008 10:27:52 -0800 (PST) Message-ID: <5f67a8c40802201027r17ffef92ga5089bc8badde506@mail.gmail.com> Date: Wed, 20 Feb 2008 13:27:52 -0500 From: "Zaphod Beeblebrox" To: "Brooks Davis" In-Reply-To: <20080220170825.GA347@lor.one-eyed-alien.net> MIME-Version: 1.0 References: <47BBD9A2.4000706@gmail.com> <20080220161919.GA99421@lor.one-eyed-alien.net> <47BC5CCA.8060003@gmail.com> <20080220170825.GA347@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, sam Subject: Re: [trouble] restart network & vlan`s interface 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, 20 Feb 2008 18:27:56 -0000 On Feb 20, 2008 12:08 PM, Brooks Davis wrote: > On Wed, Feb 20, 2008 at 08:00:58PM +0300, sam wrote: > > Brooks Davis wrote: > >> On Wed, Feb 20, 2008 at 10:41:22AM +0300, sam wrote: > >> > >>> > >>> please help me for writing /etc/rc.conf with vlan`s interfaces > >>> (without problem network sub-system restart) > >>> > > /etc/netstart just ignores it's arguments. It's really intended for > those times when you want to bring networking up from singleuser > mode, not what you chance configurations. We do not currently have a > one-size-fits-all mechanism for handling network configuration changes. > > -- Brooks > Which inevitably leads to problems in running systems where the "restart configuration" does not match the "running configuration" of the network. It's a non-trivial problem. non-trivial to solve, non-trivial to be left unsolved. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 18:34:01 2008 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 3B99B16A402; Wed, 20 Feb 2008 18:34:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 846E413C447; Wed, 20 Feb 2008 18:34:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3033F43CA06; Wed, 20 Feb 2008 20:33:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id mkO68n+gBezk; Wed, 20 Feb 2008 20:33:59 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DB83D43C9C9; Wed, 20 Feb 2008 20:33:57 +0200 (EET) Message-ID: <47BC7287.6000301@icyb.net.ua> Date: Wed, 20 Feb 2008 20:33:43 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> In-Reply-To: <47BB4D5C.9000406@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Subject: Re: cx_lowest and CPU usage 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, 20 Feb 2008 18:34:01 -0000 on 19/02/2008 23:42 Andriy Gapon said the following: > The last result most probably means that RTC IRQ was not the interrupt > to wake CPU from sleeping state. > The first possibility that comes to mind is that on this particular > hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. So it seems that this was true. Here's a shortcut to the relevant info: PIIX4E (FW82371EB) specification DEVACTB — DEVICE ACTIVITY B (FUNCTION 3) pci register description BRLD_EN_IRQ8, bit 5 $ pciconf -r pci0:0:7:3 0x58 03040c07 > Is this possible? > Are there known instances of such breakage? > Are there other possible explanations? > > on 19/02/2008 22:09 Andriy Gapon said the following: >> More news about the issue. Finally, I stopped being blind and tried to >> use KTR. >> Graphs produces by schedgraph confirmed my suspicion that system spends >> most if its time in idle thread (sleeping). >> But, but, RTC interrupt hits with high precision into the relatively >> very short intervals when swi4 runs. >> It seems that relatively long transition times of C2 on this hardware >> cause this "synchronization" but I am not sure exactly how. It is even >> harder to say how long does it take the hardware (chipset+cpu) to wake >> from that sleep on interrupt. >> One interesting thing that I immediately noticed is that having DUMMYNET >> in my kernel caused a huge difference. >> A typical KTR sequence looks like this: >> 1. we are in idle thread (apparently sleeping in C2) >> 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is >> waken and idle thread enabled interrupts after post-C2 processing) >> 3. hardclock() checks if there is any timeout to be processed by >> softclock, and thanks to dummynet, we have its callout scheduled each tick >> 4. hardclock() schedules swi4 to run >> >> I am fuzzy about the following step, I see traces, but I don't know the >> code. So I write my guess and knowledgeable people can correct me. >> 5. near the end of interrupt handler routine we have critical_exit() >> call, it can call mi_switch() if current thread needs to be preempted by >> a different thread; in this case interrupt code is executed in context >> of the system idle thread and the idle thread is "owing preemption" to >> swi4 (see step4) >> 6. so apparently mi_switch happens in the idle thread and execution >> jumps to swi4 thread, which now exits from mi_switch() in soft interrupt >> loop routine >> 7. so far, starting from step 2, execution is with disabled interrupts; >> now swi4 unlocks spin mutex lock and that enables interrupts (see the >> previous message quoted below) >> 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently >> it has been pending for some time now >> 9. statclock is called and because we are on a swi thread this rtc tick >> is charged to "interrupts" >> >> So, here we are. But I am still not sure why the above happens so >> "deterministically" - RTC interrupt can happen anywhere between 2 clock >> interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, >> that shouldn't be enough to always put IRQ0 and IRQ8 "together". >> >> Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and >> HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load >> on completely idle system. That is still a lot, but is much less than >> 99% I had before :-) >> >> Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and >> cx_lowest=C2. I hope that this much cleaner experiment would give more >> insights. >> >> But even now we can be sure that our cpu statistics code is not always >> adequate. This is because IRQ8 is not processed like some >> super-interrupt that looks on a system from above. It is a regular >> participant of the system, it competes with IRQ0 and is affected by >> scheduler's decisions. Especially those made while in interrupt handler. >> >> >> >> on 17/02/2008 17:10 Andriy Gapon said the following: >>> on 14/02/2008 23:31 Andriy Gapon said the following: >>>> I ran a series of tests, repeating each twice to be sure that I didn't >>>> make any mistake. >>>> All tests were performed in single-user mode, so the system was as idle >>>> as possible, top reported idle as 99.N% - 100%. >>>> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >>>> Here's the results: >>>> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >>>> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >>>> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >>>> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% >>> I did some testing and here are some additional data. >>> Running with sched_ule and hz=1000 I measured that mean time spent in C2 >>> state (from starting to go into it, till completely returning from it) >>> is ~860us (end_time - start_time, no overhead adjustments). >>> Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, >>> the rest is spread almost uniformly over the remaining intervals of >>> range 0-1000%. >>> >>> Here's a typical backtrace for statclock execution: >>> #9 0xc04cce26 in statclock (usermode=0) at >>> /system/src/sys/kern/kern_clock.c:447 >>> #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at >>> /system/src/sys/i386/isa/clock.c:236 >>> #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, >>> frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 >>> #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at >>> /system/src/sys/i386/isa/atpic.c:596 >>> #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 >>> #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 >>> #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at >>> /system/src/sys/kern/kern_intr.c:1137 >>> #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , >>> arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 >>> #17 0xc06a0bc0 in fork_trampoline () at >>> /system/src/sys/i386/i386/exception.s:205 >>> >>> I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from >>> thread_unlock() in the following snippet: >>> 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { >>> 1133 TD_SET_IWAIT(td); >>> 1134 ie->ie_count = 0; >>> 1135 mi_switch(SW_VOL, NULL); >>> 1136 } >>> 1137 thread_unlock(td); >>> >>> This happens almost deterministically. >>> >> > > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 20:08:46 2008 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 0BB1116A400 for ; Wed, 20 Feb 2008 20:08:46 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFAA013C44B for ; Wed, 20 Feb 2008 20:08:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1KK8arl008044; Wed, 20 Feb 2008 21:08:43 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1KK8ZoJ008043; Wed, 20 Feb 2008 21:08:35 +0100 (CET) (envelope-from olli) Date: Wed, 20 Feb 2008 21:08:35 +0100 (CET) Message-Id: <200802202008.m1KK8ZoJ008043@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 20 Feb 2008 21:08:43 +0100 (CET) Cc: Subject: Re: /boot/loader graphics support & extensibility 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, 20 Feb 2008 20:08:46 -0000 Marcel Moolenaar wrote: > Oliver Fromme wrote: > > I understand the "yes" part, but I do not understand the > > "see (a)/(b)" part. :-) What does the recursive reference > > mean? > > It means that they can be treated the same: Ah, OK. It's clear to me now. > > Just out of curiosity, what would be examples of machines > > that fall in categry (a)? I think maybe x86-based Macs > > which don't have a BIOS (and probably no VGA BIOS either), > > but do they really have VGA-compatible hardware? > > Yes. They have VGA compatible hardware. OK. > They either have > the Intel chipset (Mac Mini) or nVidia (MacBook). Both > start up in VGA compatible mode by default, but which > EFI puts in some non-VGA mode right from the start. OK, thanks for the information. By the way: Will the standard i386 /boot/loader work on an EFI machine, or does it require a different loader binary? If the former, then there must be some code that probes whether BIOS or EFI is present, and takes care of using one or the other. At a quick glance I wasn't able to find such code. One final question: What happens if you try to call a BIOS interrupt (such as the 0x10 video interrupt) on an EFI machine? Will it crash? Or is there a compatibility layer that returns "not supported"? > > I will have to implement a certain level of abstraction > > for the graphics functions anyway: The current code > > (in perforce) supports 4bit planar modes only, but it > > should be possible to support other modes (e.g. 8bit > > linear). Of course, the FICL interface should not need > > to care about it. Therefore all graphics functions must > > go through a "switch" that executes the right function > > depending on the graphics mode. > > > > Dos that sound reasonable? > > I haven't looked at the code yet, so I don't know > which graphics functions we're talking about. Here's an excerpt from the .h file (it's not complete): void gfx_setcolor(int index, int color); void gfx_setrgb(int color, int red, int green, int blue); void gfx_usecolor(int color); void gfx_pixel(int x, int y); void gfx_rect(int x, int y, int width, int height); void gfx_line(int x1, int y1, int x2, int y2); void gfx_triangle(int x1, int y1, int x2, int y2, int x3, int y3); void gfx_circle(int x, int y, int diameter); struct fontinfo *gfx_loadfont(char *filename); void gfx_text(int *x, int *y, unsigned char *text, int length); unsigned char *gfx_loadpcx(char *filename); void gfx_showpcx(unsigned char *pcx, int xstart, int ystart); > You may want to keep in mind that EFI basically > defines a single graphics function: bitblt. If the > graphics functions are variations of bitblt, then > yes, it's very reasonable. Actually I don't plan to use a bitblit function at all, because it's not really feasible in standard VGA modes. > > However, I'm not sure how to go about the initialization > > of the graphics mode. Currently I have a FICL word > > called "vmode" that takes an integer parameter from the > > stack which is the VGA mode number. That is, this line: > > > > 18 vmode > > > > will switch to VGA mode 0x12 (that's 640 x 480 @ 4bit) > > by calling the appropriate VGA BIOS function. This is > > all in the ficl/i386/* subdirectory, so it's compiled > > only for the i386 boot loader. > > > > If someone else writes support for some sparc64 graphics > > hardware, that code would be located in ficl/sparc64/* > > so it would be compiled in when building the loader for > > sparc64. > > > > However, on sparc64 there is no such thing as VGA mode > > 0x12, so the vmode instruction has to have a different > > interface. I'm not really sure what to do here. > > > > One possible approach would be to let "vmode" take > > three parameters: x resolution, y resoluton, depth. > > So you could type: > > > > 640 480 4 vmode > > > > In that case every graphics driver needs to have a table > > that maps resolution and depth to mode numbers. OK. > > But what if the desired mode isn't supported at all? > > For example, the sparc CG6 does not support the above > > mode at all. Should the vmode instructon fail in such > > a case? > > Why not have the platform set a suitable graphics mode? > In other words: rather than have the end-user code > determine a mode, which they can't do reliably, why > not have the mode be set for the end-user code. So you mean that "vmode" wouldn't take any arguments at all? That would be possible. But then there will be other problems. For example, lets say that the i386 loader decides to use 640x480 @4bit, and the sparc64 loader decides that 1152x900 @8bit is "best". The Forth code clearly needs a way to query the resolution and bit depth that was set, so it can chose an appropriate background image. It might also have to chose a different font. So the bottom line is that the Forth code cannot easily be abstracted from the hardware anyway. There's also a problem when VESA support is added: It's not possible to reliable detect what resolutions the attached monitor supports, so by default we must use 640x480 anyway, even if VESA support is present and the hardware can do 1600x1200 or whatever. Using a higher- resolution mode is a decision that needs to be made by the admin, not by the loader, so there must be a way for the Forth code to request a specific resolution. > It seems to me that there are 2 ways of thinking about > consoles. One is the traditional way of not assuming > too much and just use the console in a serial fashion > so that it works with dump terminals as well. The other > is the graphical way of thinking which removes any and > all levels of abstraction (other than using BIOS mode > numbers????) and demands that the user can set every > little bit that can be set. There will be users who want exactly that, i.e. be able to set every little bit that can be set. I already got such requests in private mail. Of course, it would be pretty easy to implement both. So you have one function that simply set the mode that the driver thinks is best (that would be a 640x480 mode in the i386 case). And a second function that takes resolution and depth as parameters, in order to switch to a specific mode. There could be a special depth value (0 or -1) indicating "I don't care, just give me whatever you can at this resolution". > There's an in-between. The loader exists only to load > a kernel. We want it to look nice, but there's no > reason to tweak resolutions so that you can see the > kernel being loader in HD. The platform, which > includes the firmware, knows best which resolutions > look good. I bet there will be people who disagree with the firmware about which resolution looks good. > This could very well be a non-VGA mode. > The best thing we can do is work with what is given > to us by the firmware or the platform. Then it will > look nice and it will work in cases we don't know > how to set the mode, but we know it's graphical. I agree that the Forth code should not need to know how to set a mode. I will change the current interface in my code so it doesn't use VGA mode numbers. My goal is that the Forth code should not have to care about the graphics hardware at all, as long as the underlying driver supports a resolution that the Forth code is prepared to deal with. > > The whole idea of a graphical boot menu is inherently > > unportable. That's why abstracting the hardware is > > somewhat difficult. > > It's not unportable, it's just parameterized :-) > > I'm not going to suggest that you write for all > platforms and hardware combinations. I hope however > that with some thought you can implement it for > i386 with VGA BIOS in such a way that someone can > later extend the support in some direction, without > having to rewrite the whole thing... Unfortunately, the graphics functions are very specific to VGA. Someone implementing support for different kind of graphics hardware will have to rewrite all of them. I don't think there's much I can do about it. It's not feasible to define a hardware-specific setpixel function and let all other functions use it. That would make all functions slower. A _lot_ slower. Orders of magnitude slower. In VGA planar modes, you have to select each of the four bitplanes, one after another (using inb + mask + outb to the ISA registers), in order to set a single pixel. Doing that for every single pixel in a character string or PCX image would be prohibitively inefficient. These functions need to deal with the bits directly, and only switch planes if necessary. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 21:12:30 2008 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 CE50516A406 for ; Wed, 20 Feb 2008 21:12:30 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 6AF0213C469 for ; Wed, 20 Feb 2008 21:12:30 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 20 Feb 2008 21:12:29 +0000 (GMT) Date: Wed, 20 Feb 2008 21:12:29 +0000 From: David Malone To: Thomas Vogt Message-ID: <20080220211229.GA90587@walton.maths.tcd.ie> References: <47BC30AD.20600@bsdunix.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BC30AD.20600@bsdunix.ch> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: new syslogd option for adding local timestamp 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, 20 Feb 2008 21:12:30 -0000 Hi Thomas, The -T option looks reasonable to me - can you submit a PR and let me know what number it is. I'll have a look at making the change. David. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 21:44:50 2008 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 BF66516A404 for ; Wed, 20 Feb 2008 21:44:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id A745213C448 for ; Wed, 20 Feb 2008 21:44:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp001-s [10.150.69.64]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m1KLiorN023820; Wed, 20 Feb 2008 13:44:50 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp001/MantshX 4.0) with ESMTP id m1KLihkC010820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2008 13:44:44 -0800 (PST) Message-Id: <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802202008.m1KK8ZoJ008043@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 13:44:42 -0800 References: <200802202008.m1KK8ZoJ008043@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility 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, 20 Feb 2008 21:44:50 -0000 On Feb 20, 2008, at 12:08 PM, Oliver Fromme wrote: > By the way: Will the standard i386 /boot/loader work > on an EFI machine, or does it require a different loader > binary? It needs a different loader. If you want to support EFI the right way, it also needs a different kernel -- one that respects the memory map. But that's a different story :-) > If the former, then there must be some code that probes > whether BIOS or EFI is present, and takes care of using > one or the other. At a quick glance I wasn't able to > find such code. Correct. > One final question: What happens if you try to call a > BIOS interrupt (such as the 0x10 video interrupt) on > an EFI machine? Will it crash? Or is there a > compatibility layer that returns "not supported"? Assume it will crash. The EFI machine may be ia64, which makes "int 10h" especially wrong. On i386/amd64 It's best to assume that there's no BIOS emulation. I don't think BIOS emulation is standard on Macs. I think that's what BootCamp is for and it's optional. >> I haven't looked at the code yet, so I don't know >> which graphics functions we're talking about. > > Here's an excerpt from the .h file (it's not complete): > > void gfx_setcolor(int index, int color); > void gfx_setrgb(int color, int red, int green, int blue); > void gfx_usecolor(int color); > void gfx_pixel(int x, int y); > void gfx_rect(int x, int y, int width, int height); > void gfx_line(int x1, int y1, int x2, int y2); > void gfx_triangle(int x1, int y1, int x2, int y2, int x3, int y3); > void gfx_circle(int x, int y, int diameter); > struct fontinfo *gfx_loadfont(char *filename); > void gfx_text(int *x, int *y, unsigned char *text, int length); > unsigned char *gfx_loadpcx(char *filename); > void gfx_showpcx(unsigned char *pcx, int xstart, int ystart); > >> You may want to keep in mind that EFI basically >> defines a single graphics function: bitblt. If the >> graphics functions are variations of bitblt, then >> yes, it's very reasonable. > > Actually I don't plan to use a bitblit function at all, > because it's not really feasible in standard VGA modes. What do you mean by that? I implemented bitblt for VGA for vtc(4). Take a look at: http://people.freebsd.org/~marcel/vga.diff [patch extracted from the tty branch in Perforce] >>> However, I'm not sure how to go about the initialization >>> of the graphics mode. Currently I have a FICL word >>> called "vmode" that takes an integer parameter from the >>> stack which is the VGA mode number. That is, this line: >>> >>> 18 vmode >>> >>> will switch to VGA mode 0x12 (that's 640 x 480 @ 4bit) >>> by calling the appropriate VGA BIOS function. This is >>> all in the ficl/i386/* subdirectory, so it's compiled >>> only for the i386 boot loader. >>> >>> If someone else writes support for some sparc64 graphics >>> hardware, that code would be located in ficl/sparc64/* >>> so it would be compiled in when building the loader for >>> sparc64. >>> >>> However, on sparc64 there is no such thing as VGA mode >>> 0x12, so the vmode instruction has to have a different >>> interface. I'm not really sure what to do here. >>> >>> One possible approach would be to let "vmode" take >>> three parameters: x resolution, y resoluton, depth. >>> So you could type: >>> >>> 640 480 4 vmode >>> >>> In that case every graphics driver needs to have a table >>> that maps resolution and depth to mode numbers. OK. >>> But what if the desired mode isn't supported at all? >>> For example, the sparc CG6 does not support the above >>> mode at all. Should the vmode instructon fail in such >>> a case? >> >> Why not have the platform set a suitable graphics mode? >> In other words: rather than have the end-user code >> determine a mode, which they can't do reliably, why >> not have the mode be set for the end-user code. > > So you mean that "vmode" wouldn't take any arguments > at all? Correct. > That would be possible. But then there will be other > problems. For example, lets say that the i386 loader > decides to use 640x480 @4bit, and the sparc64 loader > decides that 1152x900 @8bit is "best". > > The Forth code clearly needs a way to query the resolution > and bit depth that was set, so it can chose an appropriate > background image. It might also have to chose a different > font. Yes, that's generally the difficulty with graphics. > So the bottom line is that the Forth code cannot easily > be abstracted from the hardware anyway. Well, it cannot be abstracted from the graphics settings, but it is abstracted from the hardware. > There's also a problem when VESA support is added: It's > not possible to reliable detect what resolutions the > attached monitor supports, so by default we must use > 640x480 anyway, even if VESA support is present and the > hardware can do 1600x1200 or whatever. Using a higher- > resolution mode is a decision that needs to be made by > the admin, not by the loader, so there must be a way > for the Forth code to request a specific resolution. This does not have to be done in Forth. If in Forth you simply say "Switch to graphics" and the platform code looks up an environment variable for the actual mode, then the user is still control of the resolution. In fact, this is much more user friendly than having the user edit Forth code, which he/she may not... >> It seems to me that there are 2 ways of thinking about >> consoles. One is the traditional way of not assuming >> too much and just use the console in a serial fashion >> so that it works with dump terminals as well. The other >> is the graphical way of thinking which removes any and >> all levels of abstraction (other than using BIOS mode >> numbers????) and demands that the user can set every >> little bit that can be set. > > There will be users who want exactly that, i.e. be able > to set every little bit that can be set. I already got > such requests in private mail. While I understand the request, it should not be forgotten that it's easy to end up with nothing if you allow the user control over everything. On top of that, we can't use any code in the loader from the kernel, so whatever support we add, we need to add to the kernel too. At least, I think it's lame to support fancy graphics in the loader and then not support at least the same in the kernel. If you raise the bar for the loader, you also have to raise it for the kernel. How else would the kernel be able to use the console? So, the question is: how important is it for the user to be able to tweak it all. Is it merely people going nuts over it (like a toddler going nuts over candy) than we should simply forget about it (and tell the user to grow up :-). If there's an actual reason for it (say: to support HD TVs) then it's something that we could keep in mind if we think it's the future (I have my Mac Mini hooked up to my TV, so it's real for me). > Of course, it would be pretty easy to implement both. > So you have one function that simply set the mode that > the driver thinks is best (that would be a 640x480 mode > in the i386 case). And a second function that takes > resolution and depth as parameters, in order to switch > to a specific mode. There could be a special depth > value (0 or -1) indicating "I don't care, just give > me whatever you can at this resolution". Yes. If common code doesn't care about the setting, then it's easy enough to allow the user to pick the setting of choice... >> There's an in-between. The loader exists only to load >> a kernel. We want it to look nice, but there's no >> reason to tweak resolutions so that you can see the >> kernel being loader in HD. The platform, which >> includes the firmware, knows best which resolutions >> look good. > > I bet there will be people who disagree with the firmware > about which resolution looks good. True. But in that case you want to change the setting in the firmware, not in the loader. If you want to depend on the firmware/BIOS for mode setting then you also have to depend on the Firmware/BIOS to allow the user to select a setting of choice. Here too the loader then pretty much as to work with whatever it gets thrown at it. >> This could very well be a non-VGA mode. >> The best thing we can do is work with what is given >> to us by the firmware or the platform. Then it will >> look nice and it will work in cases we don't know >> how to set the mode, but we know it's graphical. > > I agree that the Forth code should not need to know how to > set a mode. I will change the current interface in my code > so it doesn't use VGA mode numbers. > > My goal is that the Forth code should not have to care > about the graphics hardware at all, as long as the > underlying driver supports a resolution that the Forth > code is prepared to deal with. Agreed. Even if that's standard VGA for now... > It's not feasible to define a hardware-specific setpixel > function and let all other functions use it. That would > make all functions slower. A _lot_ slower. Orders of > magnitude slower. In VGA planar modes, you have to > select each of the four bitplanes, one after another > (using inb + mask + outb to the ISA registers), in order > to set a single pixel. Doing that for every single pixel > in a character string or PCX image would be prohibitively > inefficient. These functions need to deal with the bits > directly, and only switch planes if necessary. That's why there's bitblt. See the URL above... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 21:51:48 2008 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 B95E116A46C for ; Wed, 20 Feb 2008 21:51:48 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 735D813C45B for ; Wed, 20 Feb 2008 21:51:48 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 30A8D5E44; Wed, 20 Feb 2008 22:51:47 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zcAUUW8+usWk; Wed, 20 Feb 2008 22:51:43 +0100 (CET) Received: from [192.168.1.105] (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id C73CD5E29; Wed, 20 Feb 2008 22:51:43 +0100 (CET) Message-Id: From: Thomas Vogt To: David Malone In-Reply-To: <20080220211229.GA90587@walton.maths.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 22:51:43 +0100 References: <47BC30AD.20600@bsdunix.ch> <20080220211229.GA90587@walton.maths.tcd.ie> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@freebsd.org Subject: Re: new syslogd option for adding local timestamp 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, 20 Feb 2008 21:51:48 -0000 Hi David Am 20.02.2008 um 22:12 schrieb David Malone: > Hi Thomas, > > The -T option looks reasonable to me - can you submit a PR and let > me know what number it is. I'll have a look at making the change. Thank you. http://www.freebsd.org/cgi/query-pr.cgi?pr=120891 Regards, Thomas From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 22:03:15 2008 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 3B79916A404 for ; Wed, 20 Feb 2008 22:03:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3CAA13C4D1 for ; Wed, 20 Feb 2008 22:03:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id 03BE228486; Thu, 21 Feb 2008 06:03:14 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id BBD35EC433A; Thu, 21 Feb 2008 06:03:13 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id HwF58Gw29E1W; Thu, 21 Feb 2008 06:03:08 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 72EDFEB0A2E; Thu, 21 Feb 2008 06:03:06 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=nWVetk+ktLaEBM7SzXyf86cZk+7BZHhza7PUAd4rmr7pDdeluMXBD6NFBuiXXQQ8H PFjiqCtPUBPveTzK+RDRQ== Message-ID: <47BCA398.6000201@delphij.net> Date: Wed, 20 Feb 2008 14:03:04 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: Carey Jones References: <35B9ADBA-9AA3-4C61-98D7-3AE22B77CD53@bluetonic.org> In-Reply-To: <35B9ADBA-9AA3-4C61-98D7-3AE22B77CD53@bluetonic.org> X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Help debugging kernel dump? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 22:03:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carey Jones wrote: > I have been getting occasional reboots on my FreeBSD 6-STABLE machine. > I haven't figured out a pattern on it yet, but the most recent crash was > during some pretty heavy NFS usage, and I see nfsd in the dump, so > perhaps that has something to do with it. Could anyone assist in > deciphering the cause of this? This is the first time it's crashed on > me once I enabled debugging, so I can't say for sure whether or not this > is common to all of them. Just a glance at the code, will this work? Index: nfs_srvsock.c =================================================================== RCS file: /home/ncvs/src/sys/nfsserver/nfs_srvsock.c,v retrieving revision 1.94.2.3 diff -p -u -r1.94.2.3 nfs_srvsock.c - --- nfs_srvsock.c 2 Sep 2006 23:58:20 -0000 1.94.2.3 +++ nfs_srvsock.c 20 Feb 2008 22:02:23 -0000 @@ -721,6 +721,7 @@ nfsrv_dorec(struct nfssvc_sock *slp, str if (nd->nd_cr != NULL) crfree(nd->nd_cr); free((caddr_t)nd, M_NFSRVDESC); + *ndp = NULL; return (error); } *ndp = nd; - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvKOYi+vbBBjt66ARAnIxAJ9MyIqcMspJLd9bI+9ikEb1WH4KvgCfSF2u OaIOdWK+kjGcm/usa/xGzhg= =3e+s -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 22:55:44 2008 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 5F82216A404; Wed, 20 Feb 2008 22:55:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 53F2D13C43E; Wed, 20 Feb 2008 22:55:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0B6B7744007; Thu, 21 Feb 2008 00:55:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 99tCpyNppiy9; Thu, 21 Feb 2008 00:55:36 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A7BCA744006; Thu, 21 Feb 2008 00:55:35 +0200 (EET) Message-ID: <47BCAFE3.9050703@icyb.net.ua> Date: Thu, 21 Feb 2008 00:55:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-i386@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: PIIX4 chipset: (non-)exit from CPU states C2, C3 on interrupt 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, 20 Feb 2008 22:55:44 -0000 This is a report on an issue that I had with using C2 CPU power state on a system based on PIIX4E chipset. I think that other users of the chipsets from PIIX4 family might be affected as well. Also, this might be an informative reading for hackers chasing similar problems. Reference material: Intel(R) 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4) Datasheet http://www.intel.com/design/intarch/datashts/290562.htm Intel® 82371AB PIIX4, Intel® 82371EB PIIX4E and Intel® 82371MB PIIX4M Specification Update http://www.intel.com/design/chipsets/specupdt/297738.htm Intel® 82371EB (PIIX4E) Specification Update http://www.intel.com/design/chipsets/specupdt/290635.htm Relevant information can be found in the following sections of the original document and in updates/corrections/errata for them: 11.2. Clock Control 7.2.3. PMCNTRL—POWER MANAGEMENT CONTROL REGISTER (IO) 7.1.16. DEVACTB—DEVICE ACTIVITY B (FUNCTION 3) My summarized understanding: To behave in ACPI-compliant way with respect to C2 and C3 states the chipset must generate "Stop Break" events on any interrupt. This is because ACPI specification says the following about C2 state: "The hardware can exit this state for any reason, but must always exit this state whenever an interrupt is to be presented to the processor." For C3 it repeats the same and adds the following: "or when BM_RLD is set and a bus master is attempting to gain access to memory." According to PIIX4 documents the chipset exits "clock control state" either on "Stop Break" event or on "Burst" event. I leave the latter out of consideration because it is not ACPI compliant, CPU state is controlled by hardware, not by OS. Here's an excerpt from description of DEVACTB register, 6 lower bits are described: 5 IRQ8# Clock Event Enable (BRLD_EN_IRQ8)—R/W. 1=Enable an unmasked IRQ8# to, when asserted, generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 4 PME Clock Event Enable (BRLD_EN_PME)—R/W. 1=Enable an asserted SMI#, GPI1#, PWRBTN#, or LID signal to generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 3 Undefined. Must be written as a 0. 2 Keyboard/Mouse Global Reload Enable (GRLD_EN_KBC_MS)—R/W. 1=Enable an assertion of IRQ1 or IRQ12/M to reload the Global Standby Timer. 0=Disable. 1 IRQ Clock Event Enable (BRLD_EN_IRQ)—R/W. 1=Enable an unmasked IRQ[1,3:7,9:15], NMI, or INIT to generate a Burst event or Stop Break event. 0=Disable. 0 IRQ0 Clock Event Enable (BRLD_EN_IRQ0)—R/W. 1=Enable an unmasked IRQ0 to generate a Burst event or Stop Break event. 0=Disable. In order for the hardware to behave in ACPI-compliant way, that is to generate "Stop Break" events on all interrupts, the following bits of this register must be set: 0 - for IRQ0, 5 - for IRQ8, 1 - for the rest of the maskable interrupts You can read a saga about my investigation of a C2 behavior of a FreeBSD 7.0-RC1 system installed on a hardware based on PIIX4E chipset: http://docs.FreeBSD.org/cgi/mid.cgi?479F0ED4.9030709 This is a long thread with a couple of side-branches that keeps you in suspense until the very end. For those without time to waste, the following link is a pointer to where the most interesting details appear: http://docs.FreeBSD.org/cgi/mid.cgi?47BB375C.5010208 In short: on this system bit 5 of the mentioned above register was reset (i.e. 0), so RTC/IRQ8 didn't cause exit from C2 state. Thus, with cx_lowest=C2, RTC interrupt was handled at the predictable times, usually back-to-back after IRQ0 handler. As a result statclock() gathered CPU usage information (user:nice:system:interrupt:idle) at quite deterministic moments, so the statics was very biased in favor of interrupt usage. This is what the register had after boot: $ pciconf -r pci0:0:7:3 0x58 03040c07 After doing the following CPU statics became reasonable: pciconf -w pci0:0:7:3 0x58 0x03040c27 >From pciconf -lv: intsmb0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class = bridge In the end, my suggestion is that acpi_cpu code should check value of those 3 bits and set them if necessary. I am not actually sure why I have bit 5 reset to 0. Maybe because this is a fault of a vendor of my motherboard/BIOS. Maybe I unwittingly caused this by changing some BIOS setting, but if this is the case, then the setting must appear under a name and description that I would never relate to this issue. Another possible resolution is to check the bits, but instead of changing them just refuse to use anything lower than C1. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 20 23:57:13 2008 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 0247816A402; Wed, 20 Feb 2008 23:57:13 +0000 (UTC) (envelope-from cristi@roedu.net) Received: from alpha.roedu.net (alpha.roedu.net [81.180.250.131]) by mx1.freebsd.org (Postfix) with ESMTP id A610813C458; Wed, 20 Feb 2008 23:57:12 +0000 (UTC) (envelope-from cristi@roedu.net) Received: from localhost (localhost [127.0.0.1]) by alpha.roedu.net (Postfix) with ESMTP id 1FCF79B750; Thu, 21 Feb 2008 01:57:10 +0200 (EET) X-Virus-Scanned: amavisd-new at roedu.net Received: from alpha.roedu.net ([127.0.0.1]) by localhost (alpha.roedu.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y6-iW1qyArM; Thu, 21 Feb 2008 01:57:09 +0200 (EET) Received: from [86.125.188.48] (cl-86-125-188-48.cablelink.mures.rdsnet.ro [86.125.188.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alpha.roedu.net (Postfix) with ESMTP id 0F2989B6FD; Thu, 21 Feb 2008 01:57:09 +0200 (EET) Message-ID: <47BCBE54.1060508@roedu.net> Date: Thu, 21 Feb 2008 01:57:08 +0200 From: Cristian KLEIN User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Eygene Ryabinkin References: <47728D80.5010507@zirakzigil.org> <475A8637.9020507@zirakzigil.org> <20071212155244.GJ1442@daemon.grid.kiae.ru> <4760114D.6020203@zirakzigil.org> <47950952.6040909@roedu.net> <41549.193.226.5.33.1201087601.squirrel@mail.roedu.net> <47ACBC73.8070309@roedu.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Giulio Ferro , nork@freebsd.org Subject: Re: 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: Wed, 20 Feb 2008 23:57:13 -0000 Eygene Ryabinkin wrote: > Cristian, good day. > > Fri, Feb 08, 2008 at 10:32:51PM +0200, Cristian KLEIN wrote: >> Thank you very much for 'pinging'. :) As the driver synaptics driver din >> not change for month, I speculate there might have been a change in the >> Xorg API, especially related to sucking configuration options. > > No, I had found the first problem and sent the message to the list > shortly after the 'ping' mail. It has the patch attached. If you > had not received it, it is strange, but anyway, here is the URL > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023272.html > > Make mistakenly thought that your Synaptics driver should be compiled > for i386, not for amd64. Patch will change the situation back to > normal. > >> Is there any way I could help? > > Yes, please, try the mentioned patch and report back ;)) Sorry for the really long delay. The patch works perfectly on my Fujitsu-Siemens V5545. From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 01:26:41 2008 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 4B75416A400 for ; Thu, 21 Feb 2008 01:26:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8716713C469 for ; Thu, 21 Feb 2008 01:26:40 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.204] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m1L1QdUP028884; Wed, 20 Feb 2008 17:26:40 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <47BCD34F.7010309@freebsd.org> Date: Wed, 20 Feb 2008 17:26:39 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thiago Damas References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 01:26:41 -0000 Thiago Damas wrote: > And if you make a wrapper, and execute like a shell script: > > #!/usr/local/bin/mysecyritywrapper > <...encryted code goes where...> > > In this way. it'll be hard to use truss, ktrace, strace etc... No, not really. All of those tools can trace through to sub-processes, so whenever the code gets decrypted and starts executing (whether it's in the main process or in a sub-process), they'll be able to follow the system calls it makes. The key fact about DRM is that it is theoretically impossible. Of course, that's what makes it such an interesting problem in practice. ;-) Cheers, Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 03:05:44 2008 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 E09AA16A402 for ; Thu, 21 Feb 2008 03:05:44 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: from episec.com (episec.com [69.55.237.141]) by mx1.freebsd.org (Postfix) with SMTP id 9070613C4CC for ; Thu, 21 Feb 2008 03:05:44 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 65970 invoked by uid 1024); 21 Feb 2008 02:39:03 -0000 Date: Wed, 20 Feb 2008 21:39:03 -0500 From: ari edelkind To: freebsd-hackers@freebsd.org Message-ID: <20080221023902.GI79355@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@freebsd.org References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BCD34F.7010309@freebsd.org> Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:05:45 -0000 > >#!/usr/local/bin/mysecyritywrapper > ><...encryted code goes where...> > > > > In this way. it'll be hard to use truss, ktrace, strace etc... > > No, not really. All of those tools can trace through > to sub-processes, so whenever the code gets decrypted and > starts executing (whether it's in the main process or > in a sub-process), they'll be able to follow the system > calls it makes. Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is already being traced. As for core files, a process can use setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory pages may be encrypted or unloaded, to be decrypted or loaded on demand. An approach that handles all of the above, with the possible exception of setrlimit(RLIMIT_CORE,...), is "shiva", though it's available only for linux and distributed as an executable. http://www.securiteam.com/tools/5XP041FA0U.html Even then, the developers explicitly state that this can only slow the determined attacker in his endeavors, but the solutions everyone seems to be proposing here won't help. Mind you, it's true that disabling core dumps with a resource limit doesn't keep one from creating a core image using gcore, but since gcore generally must either attach to a process using ptrace() or access mapped code segments in the original binary (depending on the implementation), it won't help in such a case, either. That said, here's a set of slides from a talk on attacking shiva-encrypted binaries: http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-eagle/bh-fed-03-eagle.pdf ari From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 03:19:41 2008 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 96D2E16A407 for ; Thu, 21 Feb 2008 03:19:41 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 562B213C442 for ; Thu, 21 Feb 2008 03:19:41 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 08757E7A3E0; Thu, 21 Feb 2008 03:19:40 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 81875175D0; Thu, 21 Feb 2008 04:18:56 +0100 (CET) Date: Thu, 21 Feb 2008 04:18:56 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20080221031856.GA17599@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, ari edelkind References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221023902.GI79355@episec.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: ari edelkind Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:19:41 -0000 On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote: > Mind you, it's true that disabling core dumps with a resource limit > doesn't keep one from creating a core image using gcore, but since gcore > generally must either attach to a process using ptrace() or access > mapped code segments in the original binary (depending on the > implementation), it won't help in such a case, either. What prevents me from patching the kernel (!) to just ignore the resource limit? Nothing. Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 05:55:11 2008 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 BFAD416A403 for ; Thu, 21 Feb 2008 05:55:11 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 8549313C44B for ; Thu, 21 Feb 2008 05:55:11 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 37487 invoked by uid 0); 21 Feb 2008 05:55:10 -0000 Received: from unknown (HELO wideload.network.lan) (xistence@0x58.com@68.228.228.123) by mailexchange.osnn.net with SMTP; 21 Feb 2008 05:55:10 -0000 Cc: FreeBSD Hackers Message-Id: <07F059CA-D46C-4B2E-B047-FE65E7FAA6FD@0x58.com> From: Bert JW Regeer In-Reply-To: <20080221031856.GA17599@britannica.bec.de> Content-Type: multipart/signed; boundary=Apple-Mail-1--219709801; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 22:54:33 -0700 References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> <20080221031856.GA17599@britannica.bec.de> X-Mailer: Apple Mail (2.919.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 05:55:11 -0000 --Apple-Mail-1--219709801 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 20, 2008, at 20:18 , Joerg Sonnenberger wrote: > On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote: >> Mind you, it's true that disabling core dumps with a resource limit >> doesn't keep one from creating a core image using gcore, but since >> gcore >> generally must either attach to a process using ptrace() or access >> mapped code segments in the original binary (depending on the >> implementation), it won't help in such a case, either. > > What prevents me from patching the kernel (!) to just ignore the > resource limit? Nothing. > > Joerg Or for that matter ignoring the first ptrace() so that on the second ptrace call we make we can attach without a problem? On an open system like FreeBSD or Linux it is practically impossible to guarantee that the binary that is encrypted can't be tampered with in such a way, or have it's un-encrypted code dumped. Even on Windows this is hard, since the kernel is open for so many attack vectors, including but not limited to writing new kernel modules that hook certain kernel functions to do what I just mentioned. The openness of an Open Source system that allows an attacker to easily modify the OS the executables are running on is the biggest problem. There is no guaranteed code execution path, no guarantee that syscall's will do what you ask them to do. Bert JW Regeer --Apple-Mail-1--219709801-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 06:16:16 2008 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 ABCCB16A402 for ; Thu, 21 Feb 2008 06:16:16 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: from episec.com (episec.com [69.55.237.141]) by mx1.freebsd.org (Postfix) with SMTP id 79F0413C45D for ; Thu, 21 Feb 2008 06:16:16 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 81853 invoked by uid 1024); 21 Feb 2008 06:16:16 -0000 Date: Thu, 21 Feb 2008 01:16:16 -0500 From: ari edelkind To: freebsd-hackers@freebsd.org Message-ID: <20080221061616.GJ79355@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@freebsd.org References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> <20080221031856.GA17599@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221031856.GA17599@britannica.bec.de> Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 06:16:16 -0000 joerg@britannica.bec.de wrote: > What prevents me from patching the kernel (!) to just ignore the > resource limit? Nothing. Exactly! I mean, it won't help that much if you have pages that haven't been loaded or decrypted. But if you're patching the kernel anyway, you can always have it log the decrypted pages as they're loaded. There wasn't anything in my original e-mail that should make you think i was claiming you couldn't defeat binary encryption and protection measures (especially not the link that i included about defeating shiva). But naive simplistic methods are... just that. ari From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 07:28:44 2008 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 8D47E16A403 for ; Thu, 21 Feb 2008 07:28:44 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4878713C4F2 for ; Thu, 21 Feb 2008 07:28:44 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3585926pyb.10 for ; Wed, 20 Feb 2008 23:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=nbbsAwFox66ww9R5HkCUsGpCuhBCRNyVtL2kwwwQBLI=; b=huVavVtLl9GsqxVaqYy33KOq61Ugj2hyWUMEl0/EtUNVwy4aG9J5Ge52MdlUUXyb6zmEwdBys60AM5TIWgR0i9DrWnvg3HNyfRtQLKHNGP1I4o2wX+w588RBsTcXmPAzerYRrK7RNA/nqH4p7LYJRwHjIOhpcv+z/QrwF+WRsZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=Y9u/jZ/hy8QRgW9JfH5/rjWjht+DO3L7UXJraFVW/Qzs/OQfbgR78lIrsb3qHu5wW8nTSuA8vy6UkFgc4zowsdqKj8zuvrf+5kDFMIgxZ7TKZZG2A7JV0ktW4OpFlxkK247D51gAzFDRvikmBVb+IC9uEc+EhBKaVYhQduvk4AA= Received: by 10.65.250.11 with SMTP id c11mr18648504qbs.22.1203578923330; Wed, 20 Feb 2008 23:28:43 -0800 (PST) Received: from ?192.168.1.4? ( [98.212.164.35]) by mx.google.com with ESMTPS id a29sm9894017qbd.4.2008.02.20.23.28.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Feb 2008 23:28:42 -0800 (PST) In-Reply-To: <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> References: <200802202008.m1KK8ZoJ008043@lurza.secnetix.de> <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17781e098278be044d3d86d52e0f432e@gmail.com> Content-Transfer-Encoding: 7bit From: Joshua Isom Date: Thu, 21 Feb 2008 01:30:25 -0600 To: Marcel Moolenaar X-Mailer: Apple Mail (2.624) Cc: freebsd-hackers@FreeBSD.ORG, Oliver Fromme Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 07:28:44 -0000 On Feb 20, 2008, at 3:44 PM, Marcel Moolenaar wrote: >> That would be possible. But then there will be other >> problems. For example, lets say that the i386 loader >> decides to use 640x480 @4bit, and the sparc64 loader >> decides that 1152x900 @8bit is "best". >> >> The Forth code clearly needs a way to query the resolution >> and bit depth that was set, so it can chose an appropriate >> background image. It might also have to chose a different >> font. > > Yes, that's generally the difficulty with graphics. Consider other potential issues. I use a widescreen monitor that does 1440x900, which isn't supported by vga or vesa, so if I wanted an image that was actually full screen and "pixel perfect" I'd be out of luck. But at the same time, I use amd64 and I'm stuck with 80x25 for the console. But if you can figure some of the tricky stuff out, at least it could be made to not look stretched like the Ubuntu load screen. >> So the bottom line is that the Forth code cannot easily >> be abstracted from the hardware anyway. > > Well, it cannot be abstracted from the graphics settings, > but it is abstracted from the hardware. > >> There's also a problem when VESA support is added: It's >> not possible to reliable detect what resolutions the >> attached monitor supports, so by default we must use >> 640x480 anyway, even if VESA support is present and the >> hardware can do 1600x1200 or whatever. Using a higher- >> resolution mode is a decision that needs to be made by >> the admin, not by the loader, so there must be a way >> for the Forth code to request a specific resolution. > > This does not have to be done in Forth. If in Forth you > simply say "Switch to graphics" and the platform code > looks up an environment variable for the actual mode, > then the user is still control of the resolution. In > fact, this is much more user friendly than having the > user edit Forth code, which he/she may not... Relying on people to edit the code means being responsible for fixing their breaks, which they will of course break. No warranty doesn't mean no responsibility. >>> It seems to me that there are 2 ways of thinking about >>> consoles. One is the traditional way of not assuming >>> too much and just use the console in a serial fashion >>> so that it works with dump terminals as well. The other >>> is the graphical way of thinking which removes any and >>> all levels of abstraction (other than using BIOS mode >>> numbers????) and demands that the user can set every >>> little bit that can be set. >> >> There will be users who want exactly that, i.e. be able >> to set every little bit that can be set. I already got >> such requests in private mail. > > While I understand the request, it should not be forgotten > that it's easy to end up with nothing if you allow the user > control over everything. On top of that, we can't use any > code in the loader from the kernel, so whatever support we > add, we need to add to the kernel too. At least, I think > it's lame to support fancy graphics in the loader and then > not support at least the same in the kernel. If you raise > the bar for the loader, you also have to raise it for the > kernel. How else would the kernel be able to use the console? > > So, the question is: how important is it for the user to > be able to tweak it all. Is it merely people going nuts > over it (like a toddler going nuts over candy) than we > should simply forget about it (and tell the user to grow > up :-). If there's an actual reason for it (say: to support > HD TVs) then it's something that we could keep in mind if > we think it's the future (I have my Mac Mini hooked up to > my TV, so it's real for me). For the desktop OS aspect of FreeBSD I think it'd be good. MacOS X hides the console unless you go into single user mode or boot verbosely, which gives a more user friendly appearance. And if you have any meaningless errors, the user probably won't see them to complain about them. No one would care about this idea for their rack server, but people would want it for their desktop. >> Of course, it would be pretty easy to implement both. >> So you have one function that simply set the mode that >> the driver thinks is best (that would be a 640x480 mode >> in the i386 case). And a second function that takes >> resolution and depth as parameters, in order to switch >> to a specific mode. There could be a special depth >> value (0 or -1) indicating "I don't care, just give >> me whatever you can at this resolution". > > Yes. If common code doesn't care about the setting, then > it's easy enough to allow the user to pick the setting > of choice... > >>> There's an in-between. The loader exists only to load >>> a kernel. We want it to look nice, but there's no >>> reason to tweak resolutions so that you can see the >>> kernel being loader in HD. The platform, which >>> includes the firmware, knows best which resolutions >>> look good. >> >> I bet there will be people who disagree with the firmware >> about which resolution looks good. > > True. But in that case you want to change the setting in > the firmware, not in the loader. If you want to depend on > the firmware/BIOS for mode setting then you also have to > depend on the Firmware/BIOS to allow the user to select > a setting of choice. Here too the loader then pretty much > as to work with whatever it gets thrown at it. > >>> This could very well be a non-VGA mode. >>> The best thing we can do is work with what is given >>> to us by the firmware or the platform. Then it will >>> look nice and it will work in cases we don't know >>> how to set the mode, but we know it's graphical. >> >> I agree that the Forth code should not need to know how to >> set a mode. I will change the current interface in my code >> so it doesn't use VGA mode numbers. >> >> My goal is that the Forth code should not have to care >> about the graphics hardware at all, as long as the >> underlying driver supports a resolution that the Forth >> code is prepared to deal with. > > Agreed. Even if that's standard VGA for now... > >> It's not feasible to define a hardware-specific setpixel >> function and let all other functions use it. That would >> make all functions slower. A _lot_ slower. Orders of >> magnitude slower. In VGA planar modes, you have to >> select each of the four bitplanes, one after another >> (using inb + mask + outb to the ISA registers), in order >> to set a single pixel. Doing that for every single pixel >> in a character string or PCX image would be prohibitively >> inefficient. These functions need to deal with the bits >> directly, and only switch planes if necessary. > > That's why there's bitblt. See the URL above... > > -- > Marcel Moolenaar > xcllnt@mac.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 Thu Feb 21 08:59:39 2008 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 8B5D416A406 for ; Thu, 21 Feb 2008 08:59:39 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 2795113C465 for ; Thu, 21 Feb 2008 08:59:38 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1L8xZov018465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 19:59:35 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1L8xUOO045013; Thu, 21 Feb 2008 19:59:30 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1L8xTDo045012; Thu, 21 Feb 2008 19:59:29 +1100 (EST) (envelope-from peter) Date: Thu, 21 Feb 2008 19:59:29 +1100 From: Peter Jeremy To: Marcel Moolenaar Message-ID: <20080221085929.GJ51095@server.vk2pj.dyndns.org> References: <200802202008.m1KK8ZoJ008043@lurza.secnetix.de> <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8S1fMsFYqgBC+BN/" Content-Disposition: inline In-Reply-To: <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org, Oliver Fromme Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 08:59:39 -0000 --8S1fMsFYqgBC+BN/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 01:44:42PM -0800, Marcel Moolenaar wrote: >control over everything. On top of that, we can't use any >code in the loader from the kernel, so whatever support we >add, we need to add to the kernel too. We can't re-use the same executable bytes but, with care, we should be able to reuse some of the source code. > At least, I think >it's lame to support fancy graphics in the loader and then >not support at least the same in the kernel. If you raise >the bar for the loader, you also have to raise it for the >kernel. How else would the kernel be able to use the console? We already have splash(4) and can support a character-mode interface to a graphics-mode adapter. IMHO, the major reason for having graphics support in the kernel is KGI/GGI - which offers the possibility of being able to use DDB from X. >So, the question is: how important is it for the user to >be able to tweak it all. For GGI, quite important because the kernel is defining the X resolution. Whether that needs to be the same as the resolution used by the boot loader is a different question. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --8S1fMsFYqgBC+BN/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvT1x/opHv/APuIcRAhnrAKDED6Q1woXR1W1lV9cy2b7ivutEZgCeI3pm b7eQ5Z0ZYrzCZ/gt1J8hCpM= =zjEN -----END PGP SIGNATURE----- --8S1fMsFYqgBC+BN/-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 09:53:02 2008 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 F0B7816A401 for ; Thu, 21 Feb 2008 09:53:02 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id BDBEC13C45B for ; Thu, 21 Feb 2008 09:53:02 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-158-149.net-htp.de [89.182.158.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id EBEB7A44529 for ; Thu, 21 Feb 2008 10:53:00 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Thu, 21 Feb 2008 10:53:15 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802211053.16113.wundram@beenic.net> Subject: OT: Stream structures in bzlib and zlib X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 09:53:03 -0000 Hey all! I'm currently working on a project using zlib and bzlib, and I'm currently slightly stomped by the fact that both define the input buffer in their stream structure as non-const. Generally, I'd assume that the input buffer is never changed (by any of the compression/decompression functions), and that it should thus be defined as a const pointer. My wrappers for them assume the same, of course. I've read the zlib manual, and there is some obscure function which uses the input buffer as temporary storage (restoring it on exit), but at least for the code paths I'm taking (the standard deflate/inflate), I'm pretty confident after skimming through the sources that they don't modify the input buffer and don't call into the function that does modify it (and thus a const_cast<> to set it up is perfectly okay). For bzlib, I'm less sure, as the sources are somewhat convoluted, and I probably didn't find all references to the input buffer in the code paths I checked. Before I go and test whether bzlib modifies the input buffer for temporaries (by simply passing it data in a RO segment and checking whether I get a SIGSEGV), is there anyone out there who's hit the same "problem" before and might shed some more insight whether I'll have to copy the data before setting it up in a stream structure as input? Thanks for any reply! -- Heiko Wundram Product & Application Development From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 10:09:22 2008 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 184F716A402 for ; Thu, 21 Feb 2008 10:09:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E640E13C467 for ; Thu, 21 Feb 2008 10:09:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1LA9IRE040773; Thu, 21 Feb 2008 11:09:18 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1LA9HZw040772; Thu, 21 Feb 2008 11:09:17 +0100 (CET) (envelope-from olli) Date: Thu, 21 Feb 2008 11:09:17 +0100 (CET) Message-Id: <200802211009.m1LA9HZw040772@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com In-Reply-To: <1E2E2F4B-5169-42B4-AFFC-259B401F7F60@mac.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 21 Feb 2008 11:09:19 +0100 (CET) Cc: Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 10:09:22 -0000 Marcel Moolenaar wrote: > On Feb 20, 2008, at 12:08 PM, Oliver Fromme wrote: > > By the way: Will the standard i386 /boot/loader work > > on an EFI machine, or does it require a different loader > > binary? > > It needs a different loader. If you want to support EFI > the right way, it also needs a different kernel -- one > that respects the memory map. But that's a different > story :-) OK. > > One final question: What happens if you try to call a > > BIOS interrupt (such as the 0x10 video interrupt) on > > an EFI machine? Will it crash? Or is there a > > compatibility layer that returns "not supported"? > > Assume it will crash. OK. That question was just out of curiosity. I assume such a situation will not arise in practice. > > > I haven't looked at the code yet, so I don't know > > > which graphics functions we're talking about. > > > > Here's an excerpt from the .h file (it's not complete): > > > > void gfx_setcolor(int index, int color); > > void gfx_setrgb(int color, int red, int green, int blue); > > void gfx_usecolor(int color); > > void gfx_pixel(int x, int y); > > void gfx_rect(int x, int y, int width, int height); > > void gfx_line(int x1, int y1, int x2, int y2); > > void gfx_triangle(int x1, int y1, int x2, int y2, int x3, int y3); > > void gfx_circle(int x, int y, int diameter); > > struct fontinfo *gfx_loadfont(char *filename); > > void gfx_text(int *x, int *y, unsigned char *text, int length); > > unsigned char *gfx_loadpcx(char *filename); > > void gfx_showpcx(unsigned char *pcx, int xstart, int ystart); > > > > > You may want to keep in mind that EFI basically > > > defines a single graphics function: bitblt. If the > > > graphics functions are variations of bitblt, then > > > yes, it's very reasonable. > > > > Actually I don't plan to use a bitblit function at all, > > because it's not really feasible in standard VGA modes. > > What do you mean by that? Maybe we have different understandings what bitblit means. My understanding is that bitblit is a raster operation between two bitmaps (typically "AND" and "OR" operations for masking regions). I've done such things on the Amiga 20 years ago (hardware-assisted by a coprocessor called "Blitter"). I don't see how such functionality helps in this situation, i.e. abstracting graphics functions from the hardware. > I implemented bitblt for VGA for vtc(4). Take a look at: > http://people.freebsd.org/~marcel/vga.diff > > [patch extracted from the tty branch in Perforce] That's good code, but how does it help abstracting the hardware? I think I might just fail to see the obvious because I haven't had enough coffee in the morning yet. For example, lets say there's a function to draw a rectangle (in fact there _is_ such a function in my code). The Forth code to draw a rectangle covering the whole screen at 640x480 would look like this: 480 640 0 0 vrect The FICL word pops the parameters from the Forth stack and calls a function gfx_rect(). This will go through an abstraction switch so it calls an appropriate function depending on the bitmap format of the current mode, i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() and gfx_true24_rect(). Each of these functions implements the graphics operation in the most efficient way for the particular bitmap format. How would the above work with a bitblit function, exactly? > > > Why not have the platform set a suitable graphics mode? > > > In other words: rather than have the end-user code > > > determine a mode, which they can't do reliably, why > > > not have the mode be set for the end-user code. > > > > So you mean that "vmode" wouldn't take any arguments > > at all? > > Correct. > > > That would be possible. But then there will be other > > problems. For example, lets say that the i386 loader > > decides to use 640x480 @4bit, and the sparc64 loader > > decides that 1152x900 @8bit is "best". > > > > The Forth code clearly needs a way to query the resolution > > and bit depth that was set, so it can chose an appropriate > > background image. It might also have to chose a different > > font. > > Yes, that's generally the difficulty with graphics. > > > So the bottom line is that the Forth code cannot easily > > be abstracted from the hardware anyway. > > Well, it cannot be abstracted from the graphics settings, > but it is abstracted from the hardware. True. I agree. What I meant to say was this: The hardware dictates which graphics settings are available. So the Forth code depends on the hardware indirectly. But of course it shouldn't have to know anything about the hardware itself. > > There's also a problem when VESA support is added: It's > > not possible to reliable detect what resolutions the > > attached monitor supports, so by default we must use > > 640x480 anyway, even if VESA support is present and the > > hardware can do 1600x1200 or whatever. Using a higher- > > resolution mode is a decision that needs to be made by > > the admin, not by the loader, so there must be a way > > for the Forth code to request a specific resolution. > > This does not have to be done in Forth. If in Forth you > simply say "Switch to graphics" and the platform code > looks up an environment variable for the actual mode, > then the user is still control of the resolution. In > fact, this is much more user friendly than having the > user edit Forth code, which he/she may not... You're completely right, of course. I didn't mean to say the the user will have to edit Forth code (I wish loader would use a different language, but that's a different story). My plan is that there will be a configuration snippet (maybe in loader.conf, maybe separate, I haven't spent many thoughts on it yet). It will contain things such as the file name of the background image, font, colors for the text, position of the menu, etc. It should also contain the desired resolution (if not the default). It should be fairly easy to edit. The Forth code will only have to be edited if the user wants to create something completely different that's not covered by the configuration settings. So the situation will be similar to what it is now in regards to the text menu: The use can select whether he wants the ASCIII beastie or the big "FreeBSD" text, and whether he wants it in color or b/w. He can also disable the menu completely. But if he wants to make major changes, such as adding new menu items, or changing the ASCII logo, he'll have to dig into the Forth code. What do you think? By the way, all of the screenshots I've made so far should be possible without modifying any Forth code (I haven't implemented that yet, i.e. I _did_ have to modify the Forth code, but this is only temporary). > > > It seems to me that there are 2 ways of thinking about > > > consoles. One is the traditional way of not assuming > > > too much and just use the console in a serial fashion > > > so that it works with dump terminals as well. The other > > > is the graphical way of thinking which removes any and > > > all levels of abstraction (other than using BIOS mode > > > numbers????) and demands that the user can set every > > > little bit that can be set. > > > > There will be users who want exactly that, i.e. be able > > to set every little bit that can be set. I already got > > such requests in private mail. > > While I understand the request, it should not be forgotten > that it's easy to end up with nothing if you allow the user > control over everything. On top of that, we can't use any > code in the loader from the kernel, so whatever support we > add, we need to add to the kernel too. At least, I think > it's lame to support fancy graphics in the loader and then > not support at least the same in the kernel. If you raise > the bar for the loader, you also have to raise it for the > kernel. How else would the kernel be able to use the console? Basically I agree that whatever graphics support is added to the loader should be possible to add to the kernel later, too. In fact that might be the best way to solve the problem that VESA modes cannot be used with FreeBSD/amd64: Let the loader switch to the desired VESA mode and give all information necessary to access the frame buffer to the kernel, so the VESA BIOS is out of the way. > So, the question is: how important is it for the user to > be able to tweak it all. If the user had no way of specifying a resolution, then there would be no point in supporting VESA, because there wouldn't be a way to specify a VESA mode at anything else than 640x480. > Is it merely people going nuts > over it (like a toddler going nuts over candy) than we > should simply forget about it (and tell the user to grow > up :-). If there's an actual reason for it (say: to support > HD TVs) then it's something that we could keep in mind if > we think it's the future (I have my Mac Mini hooked up to > my TV, so it's real for me). Well, personally I would also like to be able to use the capabilities of my hardware. My main "workstation" at home is a notebook. When using the default VGA resolution of 640x480, the hardware scales it up to the TFT resolution, and it doesn't do a particularly good job at it ... It's butt ugly and distorted. As a user, I would certainly welcome an option (in loader.conf or whatever) that enables me to select a better resolution. Is that like a toddler going nuts over candy? > > Of course, it would be pretty easy to implement both. > > So you have one function that simply set the mode that > > the driver thinks is best (that would be a 640x480 mode > > in the i386 case). And a second function that takes > > resolution and depth as parameters, in order to switch > > to a specific mode. There could be a special depth > > value (0 or -1) indicating "I don't care, just give > > me whatever you can at this resolution". > > Yes. If common code doesn't care about the setting, then > it's easy enough to allow the user to pick the setting > of choice... Right. My goal is that it should work that way. > > > There's an in-between. The loader exists only to load > > > a kernel. We want it to look nice, but there's no > > > reason to tweak resolutions so that you can see the > > > kernel being loader in HD. The platform, which > > > includes the firmware, knows best which resolutions > > > look good. > > > > I bet there will be people who disagree with the firmware > > about which resolution looks good. > > True. But in that case you want to change the setting in > the firmware, not in the loader. If you want to depend on > the firmware/BIOS for mode setting then you also have to > depend on the Firmware/BIOS to allow the user to select > a setting of choice. Here too the loader then pretty much > as to work with whatever it gets thrown at it. Hm. I'm not sure I understand. Lets take an example: By default the loader decides to use 640x480 @4bit (or maybe @8bit if VESA support present). Now some user wants to use VESA mode 1024x768 instead. And yet another user would prefer Mode-X 360x480 @8bit with his own 256-color background image. How are these users supposed to do that? There's no way in the BIOS to tune anything. I think the most appropriate way would be a setting in loader.conf or another configuration file. > > My goal is that the Forth code should not have to care > > about the graphics hardware at all, as long as the > > underlying driver supports a resolution that the Forth > > code is prepared to deal with. > > Agreed. Even if that's standard VGA for now... OK. > > It's not feasible to define a hardware-specific setpixel > > function and let all other functions use it. That would > > make all functions slower. A _lot_ slower. Orders of > > magnitude slower. In VGA planar modes, you have to > > select each of the four bitplanes, one after another > > (using inb + mask + outb to the ISA registers), in order > > to set a single pixel. Doing that for every single pixel > > in a character string or PCX image would be prohibitively > > inefficient. These functions need to deal with the bits > > directly, and only switch planes if necessary. > > That's why there's bitblt. See the URL above... I don't see how it helps for all the graphics functions. See my paragraph above about bitblit. Best regards Oliver PS: I just took a few minutes to make yet another screen design, it's based on the design of the www.freebsd.og web pages. It includes both the logo and the daemon mascot: http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Software gets slower faster than hardware gets faster." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 10:15:58 2008 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 457A716A400; Thu, 21 Feb 2008 10:15:58 +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 EE88E13C45E; Thu, 21 Feb 2008 10:15:57 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=CGQgItFmZq0Zra0sU+sYQmOZdvtFvzaciM+HA1VvO13zA09eeESpB6FElMhHVFgBxBS4YmysaWD9h4Liql4afk/PchJMrtCWy3l+ehTv9vVgBtL7wuTlklrDI+MvHJvUILwMd9rplKcYbf5kHFRwcpCUkYCf5oiwbpptcxvjJf4=; Received: from amnesiac.at.no.dns ([144.206.182.200]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JS8T6-000Ina-D2; Thu, 21 Feb 2008 13:15:56 +0300 Date: Thu, 21 Feb 2008 13:15:55 +0300 From: Eygene Ryabinkin To: Cristian KLEIN Message-ID: References: <20071212155244.GJ1442@daemon.grid.kiae.ru> <4760114D.6020203@zirakzigil.org> <47950952.6040909@roedu.net> <41549.193.226.5.33.1201087601.squirrel@mail.roedu.net> <47ACBC73.8070309@roedu.net> <47BCBE54.1060508@roedu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <47BCBE54.1060508@roedu.net> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-hackers@freebsd.org, Giulio Ferro , nork@freebsd.org Subject: Re: 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: Thu, 21 Feb 2008 10:15:58 -0000 Cristian, good day. Thu, Feb 21, 2008 at 01:57:08AM +0200, Cristian KLEIN wrote: >> Yes, please, try the mentioned patch and report back ;)) > > Sorry for the really long delay. No problems ;)) > The patch works perfectly on my Fujitsu-Siemens V5545. Thanks for the report! Norikatsu already kindly committed my patch, so you can update your ports and rebuild Synaptics driver -- it should work too and you'll not miss the modifications. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 12:48:57 2008 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 C964A16A403 for ; Thu, 21 Feb 2008 12:48:57 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 588B713C44B for ; Thu, 21 Feb 2008 12:48:57 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so2466494uge.37 for ; Thu, 21 Feb 2008 04:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=dWU5iotveoXsGNcn/mjO/m4x8S0eGOrtGwnD0P4vSOA=; b=WJlGNDw80rgAewgeYnFuSkkRPajLeYYPu9lB50FHRZw5vk4kJggpUA5OXpIx1biY7dhNrdLrYQF8xVJQurq09xtIMHJVdCzcTuVTvqzuBSrV6WrIR5UOL8sCl7rm5BKcKpkMwkuukJFJX7J5gxuiXOgfW/RVx/BVVT36PvoRN78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SXcK6iJTAdv4GZjAkx0+qhqmZ/Op7eImNnaEDzlU6B7Fi9arCKIOL1X8UY41h8zS0EY7k4dUatNnB45CvCsAAXWTjFH54rHyj25EkzcRJKHwJ3fOOPiCfHLaNMonf0tTz5I88EKke1atlJQ6yf0U3cTBATkKo1iN/WkvaSYsi5M= Received: by 10.66.224.19 with SMTP id w19mr878199ugg.34.1203598135719; Thu, 21 Feb 2008 04:48:55 -0800 (PST) Received: from ?192.168.12.92? ( [217.74.44.57]) by mx.google.com with ESMTPS id 3sm15256557fge.7.2008.02.21.04.48.54 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Feb 2008 04:48:54 -0800 (PST) Message-ID: <47BD7337.2020503@gmail.com> Date: Thu, 21 Feb 2008 15:48:55 +0300 From: sam User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Robert Watson References: <46C55191.2050205@gmail.com> <20070821145603.L50579@fledge.watson.org> <46CAF217.7040204@gmail.com> <20070821151108.Y53914@fledge.watson.org> <46CAF4E9.2030700@gmail.com> <20070821152327.R53914@fledge.watson.org> <46CBE096.90805@gmail.com> <20070828175313.B90180@fledge.watson.org> In-Reply-To: <20070828175313.B90180@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, trustedbsd-audit@FreeBSD.org, freebsd-audit@freebsd.org Subject: OpenBSM & Jails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:48:57 -0000 hello i am using OpenBSM on System with jails part of praudit output / action write file in jail -------------------------------------------------- header,176,10,open(2) - write,creat,trunc,0,Thu Feb 21 13:45:06 2008, + 501 msec,argument,3,0x81ed,mode,argument,2,0x601,flags,path,//site/svn/dev.lineage2.dom/pamm/hooks/post-commit,attribute,755,www,www,88,800911,3234053,subject,lynx,root,wheel,root,wheel,44680,44668,56876,10.15.1.116,return,success,4,trailer,176, -------------------------------------------------- please add jail-identification in output (cat /dev/auditpipe | praudit -lp) /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 16:23:03 2008 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 81ACE16A402 for ; Thu, 21 Feb 2008 16:23:03 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.8]) by mx1.freebsd.org (Postfix) with ESMTP id A221213C458 for ; Thu, 21 Feb 2008 16:23:02 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8) with ESMTP id m1LGN112071736 for ; Thu, 21 Feb 2008 11:23:01 -0500 (EST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8/Submit) id m1LGN1e9071735 for hackers@freebsd.org; Thu, 21 Feb 2008 11:23:01 -0500 (EST) (envelope-from mwlucas) Date: Thu, 21 Feb 2008 11:23:01 -0500 From: "Michael W. Lucas" To: hackers@freebsd.org Message-ID: <20080221162301.GA71695@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Thu, 21 Feb 2008 11:23:01 -0500 (EST) Cc: Subject: ath0 will not associate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 16:23:03 -0000 Hi, Runing -current i386 as of February 19. Tried to use an ath wireless on my laptop, it wouldn't associate using: # ifconfig ath0 ssid GoAway wepkey 0xdeadbeef1234567890deadbeef wepmode on Set "wlandebug scan+auth+assoc", got the following in /var/log/messages. (I've trimmed to 100 lines, the remainder is more of the same. Any suggestions, folks? Proper next steps to debug? Thanks, ==ml Feb 21 09:45:57 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 Feb 21 09:45:57 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:45:57 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:45:57 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) Feb 21 09:47:34 stretchlimo kernel: ath0: detached Feb 21 09:47:38 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 Feb 21 09:47:38 stretchlimo kernel: ath0: [ITHREAD] Feb 21 09:47:38 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 09:47:38 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 09:47:38 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 09:47:44 stretchlimo kernel: ath0: detached Feb 21 11:03:36 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 Feb 21 11:03:36 stretchlimo kernel: ath0: [ITHREAD] Feb 21 11:03:36 stretchlimo kernel: ath0: using obsoleted if_watchdog interface Feb 21 11:03:36 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 Feb 21 11:03:36 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_check_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, flush Feb 21 11:09:40 stretchlimo kernel: ath0: scan set 1g, 6g, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200 Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1b -> 1g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 165a -> 50S [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 50S -> 58S [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 58S -> 152S [active, dwell min 20 max 200] Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200] Feb 21 11:09:46 stretchlimo kernel: ath0: sta_pick_bss: no scan candidate Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: done, restart [ticks 5357219, dwell min 20 scanend 2152835125] Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 160S -> 1g [active, dwell min 20 max 200] Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 165a -> 50S [active, dwell min 20 max 200] Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 50S -> 58S [active, dwell min 20 max 200] Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 58S -> 152S [active, dwell min 20 max 200] Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200] Feb 21 11:09:51 stretchlimo kernel: ath0: sta_pick_bss: no scan candidate Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: done, restart [ticks 5362959, dwell min 20 scanend 2152835125] Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 160S -> 1g [active, dwell min 20 max 200] Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] -- Michael W. Lucas mwlucas@BlackHelicopters.org, mwlucas@FreeBSD.org http://www.BlackHelicopters.org/~mwlucas/ Now Shipping: "Absolute FreeBSD" -- http://www.AbsoluteFreeBSD.com On 5/4/2007, the TSA kept 3 pairs of my soiled undies "for security reasons." From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 16:38:08 2008 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 A655516A403 for ; Thu, 21 Feb 2008 16:38:08 +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 633F713C448 for ; Thu, 21 Feb 2008 16:38:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5295C208E; Thu, 21 Feb 2008 17:38:02 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 45144208C; Thu, 21 Feb 2008 17:38:02 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 2D4318448A; Thu, 21 Feb 2008 17:38:02 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Thiago Damas" References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> Date: Thu, 21 Feb 2008 17:38:02 +0100 In-Reply-To: (Thiago Damas's message of "Wed\, 20 Feb 2008 09\:51\:23 -0300") Message-ID: <86lk5e5kph.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 16:38:08 -0000 "Thiago Damas" writes: > And if you make a wrapper, and execute like a shell script: > > #!/usr/local/bin/mysecyritywrapper > <...encryted code goes where...> > > In this way. it'll be hard to use truss, ktrace, strace etc... Uh, no, not at all. Not even a little. Hint: 'ktrace -i'. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 16:41:18 2008 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 4255416A400 for ; Thu, 21 Feb 2008 16:41:18 +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 F249813C447 for ; Thu, 21 Feb 2008 16:41:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id A8DF02087; Thu, 21 Feb 2008 17:41:14 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 9A4C42085; Thu, 21 Feb 2008 17:41:14 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 6AA318448A; Thu, 21 Feb 2008 17:41:14 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: ari edelkind References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> Date: Thu, 21 Feb 2008 17:41:14 +0100 In-Reply-To: <20080221023902.GI79355@episec.com> (ari edelkind's message of "Wed\, 20 Feb 2008 21\:39\:03 -0500") Message-ID: <86hcg25kk5.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 16:41:18 -0000 ari edelkind writes: > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > already being traced. As for core files, a process can use > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > pages may be encrypted or unloaded, to be decrypted or loaded on > demand. The person running the application can trivially replace ktrace(), ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. Ensuring that LD_PRELOAD is invisible to the application is left as an exercise to the reader. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 16:43:51 2008 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 385BA16A404 for ; Thu, 21 Feb 2008 16:43:51 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id ED3D313C44B for ; Thu, 21 Feb 2008 16:43:50 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 8ED5EE7A3E1 for ; Thu, 21 Feb 2008 16:43:49 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 2B0E2175D0; Thu, 21 Feb 2008 17:43:07 +0100 (CET) Date: Thu, 21 Feb 2008 17:43:07 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20080221164307.GG6746@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200802211053.16113.wundram@beenic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802211053.16113.wundram@beenic.net> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: OT: Stream structures in bzlib and zlib X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 16:43:51 -0000 On Thu, Feb 21, 2008 at 10:53:15AM +0100, Heiko Wundram (Beenic) wrote: > Before I go and test whether bzlib modifies the input buffer for temporaries > (by simply passing it data in a RO segment and checking whether I get a > SIGSEGV), is there anyone out there who's hit the same "problem" before and > might shed some more insight whether I'll have to copy the data before > setting it up in a stream structure as input? The buffers are not modified for the compression path. Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 17:11:50 2008 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 3DE4316A401 for ; Thu, 21 Feb 2008 17:11:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A4B3313C45B for ; Thu, 21 Feb 2008 17:11:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1LHBZx5061945; Thu, 21 Feb 2008 18:11:40 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1LHBZ3b061944; Thu, 21 Feb 2008 18:11:35 +0100 (CET) (envelope-from olli) Date: Thu, 21 Feb 2008 18:11:35 +0100 (CET) Message-Id: <200802211711.m1LHBZ3b061944@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, des@des.no, edelkind-freebsd-hackers@episec.com In-Reply-To: <86hcg25kk5.fsf@ds4.des.no> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 21 Feb 2008 18:11:41 +0100 (CET) Cc: Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 17:11:50 -0000 Dag-Erling Smørgrav wrote: > ari edelkind writes: > > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > > already being traced. As for core files, a process can use > > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > > pages may be encrypted or unloaded, to be decrypted or loaded on > > demand. > > The person running the application can trivially replace ktrace(), > ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. Right. And for a static binary (which doesn't respect LD_PRELOAD), it's fairly trivial to patch the syscalls so they're a no-op when called from the binary. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In my experience the term "transparent proxy" is an oxymoron (like jumbo shrimp). "Transparent" proxies seem to vary from the distortions of a funhouse mirror to barely translucent. I really, really dislike them when trying to figure out the corrective lenses needed with each of them. -- R. Kevin Oberman, Network Engineer From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 17:26:51 2008 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 0C7A516A400 for ; Thu, 21 Feb 2008 17:26:51 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: from episec.com (episec.com [69.55.237.141]) by mx1.freebsd.org (Postfix) with SMTP id C55AD13C4E5 for ; Thu, 21 Feb 2008 17:26:50 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 13675 invoked by uid 1024); 21 Feb 2008 17:26:50 -0000 Date: Thu, 21 Feb 2008 12:26:50 -0500 From: ari edelkind To: freebsd-hackers@freebsd.org Message-ID: <20080221172650.GK79355@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@freebsd.org References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> <86hcg25kk5.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86hcg25kk5.fsf@ds4.des.no> Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 17:26:51 -0000 des@des.no wrote: > ari edelkind writes: > > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is > > already being traced. As for core files, a process can use > > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory > > pages may be encrypted or unloaded, to be decrypted or loaded on > > demand. > > The person running the application can trivially replace ktrace(), > ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. And any application that executes its own code before running the system's dynamic loader -- or is statically linked, for that matter -- is free to unset LD_PRELOAD. There are many attack vectors. There are plenty of countermeasures. There are numerous attacks on each countermeasure. It goes on. This is all common knowledge, even among those creating anti-reverse-engineering techniques; in fact, it's usually prominently stated in an included disclaimer. It's unfortunate to note that, in many countries these days, the most effective deterrent against attacks on binary encryption is legal action. Some corporations add just-in-time page decryption to their binaries specifically for this recourse (e.g., against a competitor who creates applications that hook into the original software). ari From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 19:17:00 2008 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 5AC0F16A574 for ; Thu, 21 Feb 2008 19:17:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.78]) by mx1.freebsd.org (Postfix) with ESMTP id CB35913C4F7 for ; Thu, 21 Feb 2008 19:16:59 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id m1LJH0Yc016331 for ; Thu, 21 Feb 2008 11:17:00 -0800 (PST) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id m1LJGqVK023520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Feb 2008 11:16:53 -0800 (PST) Message-Id: <754FD289-9E26-4368-9AB4-64F3ECB6CDFC@mac.com> From: Marcel Moolenaar To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <200802211009.m1LA9HZw040772@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 11:16:51 -0800 References: <200802211009.m1LA9HZw040772@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 19:17:00 -0000 On Feb 21, 2008, at 2:09 AM, Oliver Fromme wrote: >>> >>> Actually I don't plan to use a bitblit function at all, >>> because it's not really feasible in standard VGA modes. >> >> What do you mean by that? > > Maybe we have different understandings what bitblit means. > My understanding is that bitblit is a raster operation > between two bitmaps (typically "AND" and "OR" operations > for masking regions). I've done such things on the Amiga > 20 years ago (hardware-assisted by a coprocessor called > "Blitter"). I think they may fundamentally be the same thing. The bitblt I refer to is Bit Block Transfer. While the bitblt API could support bit-wise operations while it's copying, it's main purpose is to move a bit-array (tile/sprite) from RAM to VRAM, or possibly between VRAM locations. Everything that needs to be done can be done with a bitblt. It also happens to be the operation that was first accelerated... The abstraction is in the details of how a bit-mask or image map needs to be written to VRAM to have it appear as a char. or an image on the screen. >> I implemented bitblt for VGA for vtc(4). Take a look at: >> http://people.freebsd.org/~marcel/vga.diff >> >> [patch extracted from the tty branch in Perforce] > > That's good code, but how does it help abstracting the > hardware? I think I might just fail to see the obvious > because I haven't had enough coffee in the morning yet. The higher lever TTY code simply calls bitblt with a bit mask of the glyph to be printed and doesn't need to know about the details of the display. As such, simple console output works at any resolution and with any color depth. At the same time the VGA driver is abstracted from any high-level details, like fonts or character sets. This means that it's easy to write an accelerated driver for some graphics hardware. You simply implement mode setting and bitblt and you're good to go. > For example, lets say there's a function to draw a > rectangle (in fact there _is_ such a function in my code). > The Forth code to draw a rectangle covering the whole > screen at 640x480 would look like this: > > 480 640 0 0 vrect > > The FICL word pops the parameters from the Forth stack > and calls a function gfx_rect(). This will go through > an abstraction switch so it calls an appropriate function > depending on the bitmap format of the current mode, > i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() > and gfx_true24_rect(). Each of these functions implements > the graphics operation in the most efficient way for the > particular bitmap format. > > How would the above work with a bitblit function, exactly? You bitblt the 4 edges. I didn't say it was the most performance optimal thing to do. I only said that it can be abstracted that way. Rectangles are better abstracted with a linedraw primitive, but unless you really want generic line drawing capabilities in the loader, it's probably not worth implementing it.... >>>> That would be possible. But then there will be other >>> problems. For example, lets say that the i386 loader >>> decides to use 640x480 @4bit, and the sparc64 loader >>> decides that 1152x900 @8bit is "best". >>> >>> The Forth code clearly needs a way to query the resolution >>> and bit depth that was set, so it can chose an appropriate >>> background image. It might also have to chose a different >>> font. >> >> Yes, that's generally the difficulty with graphics. >> >>> So the bottom line is that the Forth code cannot easily >>> be abstracted from the hardware anyway. >> >> Well, it cannot be abstracted from the graphics settings, >> but it is abstracted from the hardware. > > True. I agree. > > What I meant to say was this: The hardware dictates which > graphics settings are available. So the Forth code depends > on the hardware indirectly. But of course it shouldn't > have to know anything about the hardware itself. Yes. My vtc(4) driver, which puts graphics support in the kernel, is having the same problems with bitmaps. I have a nice logo (the 4.4 daemon: see http://www.mckusick.com/beastie/shirts/source.html), but I only have it for the standard VGA 4-bit color mode. I need a separate one for 16-bit and/or 256-bit colors... >>> There's also a problem when VESA support is added: It's >>> not possible to reliable detect what resolutions the >>> attached monitor supports, so by default we must use >>> 640x480 anyway, even if VESA support is present and the >>> hardware can do 1600x1200 or whatever. Using a higher- >>> resolution mode is a decision that needs to be made by >>> the admin, not by the loader, so there must be a way >>> for the Forth code to request a specific resolution. >> >> This does not have to be done in Forth. If in Forth you >> simply say "Switch to graphics" and the platform code >> looks up an environment variable for the actual mode, >> then the user is still control of the resolution. In >> fact, this is much more user friendly than having the >> user edit Forth code, which he/she may not... > > You're completely right, of course. > > I didn't mean to say the the user will have to edit Forth > code (I wish loader would use a different language, but > that's a different story). :-) > My plan is that there will be a configuration snippet > (maybe in loader.conf, maybe separate, I haven't spent > many thoughts on it yet). It will contain things such > as the file name of the background image, font, colors > for the text, position of the menu, etc. It should > also contain the desired resolution (if not the default). > It should be fairly easy to edit. Yeah. Something along those lines should do it. > The Forth code will only have to be edited if the user > wants to create something completely different that's > not covered by the configuration settings. > > So the situation will be similar to what it is now in > regards to the text menu: The use can select whether > he wants the ASCIII beastie or the big "FreeBSD" text, > and whether he wants it in color or b/w. He can also > disable the menu completely. But if he wants to make > major changes, such as adding new menu items, or changing > the ASCII logo, he'll have to dig into the Forth code. > > What do you think? I think that sounds good. I do have another datapoint. I leave it up to you whether that's something that needs to be considered or not: EFI supports multiple consoles. In other words, the EFI console can be both the display and the serial line at the same time. Clearly, graphics mode is something that you generally cannot duplicate over the serial line. However, modulo the logo and background, if the graphics console is like a text console or serial console, then you can still have them both. The serial console simply doesn't get copied the logo and background, but since everything else is text anyway, this should not be a problem. My ia64 machines use serial consoles, because syscons hasn't been ported (and I'm not planning to yet). However, it would be great if we could get the EFI loader working in graphics mode already and it would be especially great if that doesn't break the dual console setting in EFI. The question before us is: worth a try or not worth it... > Basically I agree that whatever graphics support is added to > the loader should be possible to add to the kernel later, > too. In fact that might be the best way to solve the > problem that VESA modes cannot be used with FreeBSD/amd64: > Let the loader switch to the desired VESA mode and give > all information necessary to access the frame buffer to > the kernel, so the VESA BIOS is out of the way. Agreed. This also works on powerpc or sparc64, where the firmware sets the graphics mode and all we have to do is make use of it. It's all part of the vtc(4) driver effort too: we don't have to have a driver that knows how to set the mode. All that suffices is a driver that can figure out the mode in which the hardware is, and knows how to use the mode. >> So, the question is: how important is it for the user to >> be able to tweak it all. > > If the user had no way of specifying a resolution, then > there would be no point in supporting VESA, because there > wouldn't be a way to specify a VESA mode at anything else > than 640x480. If we're going to use the loader to set the graphics mode for the kernel, then obviously it becomes more important for the loader to be able to switch to modes the user likes best... >> ell, personally I would also like to be able to use the > capabilities of my hardware. My main "workstation" at home > is a notebook. When using the default VGA resolution of > 640x480, the hardware scales it up to the TFT resolution, > and it doesn't do a particularly good job at it ... It's > butt ugly and distorted. As a user, I would certainly > welcome an option (in loader.conf or whatever) that enables > me to select a better resolution. > > Is that like a toddler going nuts over candy? Yes and no. I can image that the user wants control over the desktop. Power to the people. But here we're talking about the boot process. For Joe User nothing more than a waiting period. What does it matter, really, that a nice logo is a bit distorted? Would it be nicer if we could avoid the scaling? Yes, definitely. But it's not the first priority. The graphics world is one with many pitfalls, obstacles and controversies. I think it's best to get something basic off the ground first. I think performance is not a concern. Once you have the basic functionality, you'll also have a wishlist of things you want to do better; performance one of them in all likelyhood. The apparently simple problem of avoiding the scaling means that you need to understand much more of the graphics hardware and need to support DDC so that you know the capabilities and restrictions of the system. My Sony Vaio doesn't scale for example. It always has the resolution set to the native of 1024x768 and simply shows a 640x480 image in the center. Ideally you use the native resolution, but if you avoid borders and backgrounds and only use a simple logo in the center, then you won't even notice... Anyway: those are just my views. Not at all important in the grand scheme of things, because in the end we probably all want the same thing. It's just the getting there where we differ on :-) >>> Of course, it would be pretty easy to implement both. >>> So you have one function that simply set the mode that >>> the driver thinks is best (that would be a 640x480 mode >>> in the i386 case). And a second function that takes >>> resolution and depth as parameters, in order to switch >>> to a specific mode. There could be a special depth >>> value (0 or -1) indicating "I don't care, just give >>> me whatever you can at this resolution". >> >> Yes. If common code doesn't care about the setting, then >> it's easy enough to allow the user to pick the setting >> of choice... > > Right. My goal is that it should work that way. > >>>> There's an in-between. The loader exists only to load >>>> a kernel. We want it to look nice, but there's no >>>> reason to tweak resolutions so that you can see the >>>> kernel being loader in HD. The platform, which >>>> includes the firmware, knows best which resolutions >>>> look good. >>> >>> I bet there will be people who disagree with the firmware >>> about which resolution looks good. >> >> True. But in that case you want to change the setting in >> the firmware, not in the loader. If you want to depend on >> the firmware/BIOS for mode setting then you also have to >> depend on the Firmware/BIOS to allow the user to select >> a setting of choice. Here too the loader then pretty much >> as to work with whatever it gets thrown at it. > > Hm. I'm not sure I understand. > > Lets take an example: By default the loader decides to > use 640x480 @4bit (or maybe @8bit if VESA support present). > Now some user wants to use VESA mode 1024x768 instead. > And yet another user would prefer Mode-X 360x480 @8bit > with his own 256-color background image. How are these > users supposed to do that? There's no way in the BIOS > to tune anything. I think the most appropriate way would > be a setting in loader.conf or another configuration file. You're right. I was thinking too much about Open Firmware. On PCs the user typically has no way to set a graphics mode, so the loader is the place to do it. Sorry for the confusion. > PS: I just took a few minutes to make yet another screen > design, it's based on the design of the www.freebsd.og > web pages. It includes both the logo and the daemon > mascot: > > http://www.secnetix.de/olli/FreeBSD/vloader/screenshot5.png Another great image. I think we're finally moving into the 20th century :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 21:49:11 2008 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 9290016A403 for ; Thu, 21 Feb 2008 21:49:11 +0000 (UTC) (envelope-from gizmen@blurp.pl) Received: from albion.azs.pwr.wroc.pl (albion.azs.pwr.wroc.pl [156.17.17.145]) by mx1.freebsd.org (Postfix) with ESMTP id 5015613C448 for ; Thu, 21 Feb 2008 21:49:11 +0000 (UTC) (envelope-from gizmen@blurp.pl) Received: from gizmen (blurp.t2.ds.pwr.wroc.pl [156.17.224.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by albion.azs.pwr.wroc.pl (Postfix) with ESMTP id 7FAF1115FC for ; Thu, 21 Feb 2008 22:29:41 +0100 (CET) From: Bartosz Giza To: freebsd-hackers@freebsd.org Date: Thu, 21 Feb 2008 22:29:40 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802212229.40988.gizmen@blurp.pl> Subject: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 21:49:11 -0000 Hi, I have found quite interesting feature on one of router that lately i have taken to administer. What i knew was that file /var/run/dmesg.boot holds data from kernel buffer that is taken right after file system(s) are mounted. Lately i have found that one router writes to this file data from kernel buffer when system is going to reeboot. Below are few lines from this file. What you can see are lines from kernel right before reeboot. I have never seen before such lines in this file. And this is quite interesting. Could anyone tell me how can i achieve such funcionality on other systems ? I have tried to find on google about this but i couldn't find anything similar to this. ------ Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 0 0 done All buffers synced. GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. GEOM_MIRROR: Device gm0 destroyed. Uptime: 71d13h58m11s Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sun Feb 18 20:05:19 CET 2007 ------ -- Pozdrawiam Bartosz Giza From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 22:04:31 2008 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 AA1B116A402 for ; Thu, 21 Feb 2008 22:04:31 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4A94513C465 for ; Thu, 21 Feb 2008 22:04:30 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m1LM4HR5076036; Thu, 21 Feb 2008 23:04:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m1LM4BRR068125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 23:04:11 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m1LM4BI9084011; Thu, 21 Feb 2008 23:04:11 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m1LM4Ax7084010; Thu, 21 Feb 2008 23:04:10 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2008 23:04:10 +0100 From: Bernd Walter To: Bartosz Giza Message-ID: <20080221220410.GL80751@cicely12.cicely.de> References: <200802212229.40988.gizmen@blurp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802212229.40988.gizmen@blurp.pl> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:04:31 -0000 On Thu, Feb 21, 2008 at 10:29:40PM +0100, Bartosz Giza wrote: > Hi, > > I have found quite interesting feature on one of router that lately i have > taken to administer. > What i knew was that file /var/run/dmesg.boot holds data from kernel buffer > that is taken right after file system(s) are mounted. > Lately i have found that one router writes to this file data from kernel > buffer when system is going to reeboot. Below are few lines from this file. > What you can see are lines from kernel right before reeboot. I have never seen > before such lines in this file. And this is quite interesting. Could anyone > tell me how can i achieve such funcionality on other systems ? I have tried > to find on google about this but i couldn't find anything similar to this. You can even see the panic message if it was the reason for reboot. This works on every system where the RAM is not cleared on reboot. For example on every alpha, on my old IBM notebook, on Soekris systems, on at least some Intel server boards, ... Just not on vanilla PC, because their BIOS clears the RAM contents, so the old dmesg buffer is lost on the next kernel start. x86 that don't clear the RAM exists, just as my notebook and Soekris, but those are not very common. It is nothing which is configuriable though. Of course you could ask your board vendor to send you a less destructive BIOS, but I don't expect any positive result from that. I guess the main reason for this is that most are using the same BIOS framework and don't think about it. > ------ > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 2 2 0 0 done > All buffers synced. > GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. > GEOM_MIRROR: Device gm0 destroyed. > Uptime: 71d13h58m11s > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE #0: Sun Feb 18 20:05:19 CET 2007 > ------ > > -- > Pozdrawiam > Bartosz Giza > _______________________________________________ > 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" -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 22:36:47 2008 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 3014616A405 for ; Thu, 21 Feb 2008 22:36:47 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id CBF6313C45B for ; Thu, 21 Feb 2008 22:36:46 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m1LMFlrQ067957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:15:48 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47BDF813.1010604@errno.com> Date: Thu, 21 Feb 2008 14:15:47 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Michael W. Lucas" References: <20080221162301.GA71695@bewilderbeast.blackhelicopters.org> In-Reply-To: <20080221162301.GA71695@bewilderbeast.blackhelicopters.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: hackers@freebsd.org Subject: Re: ath0 will not associate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:36:47 -0000 Michael W. Lucas wrote: > Hi, > > Runing -current i386 as of February 19. > > Tried to use an ath wireless on my laptop, it wouldn't associate using: > > # ifconfig ath0 ssid GoAway wepkey 0xdeadbeef1234567890deadbeef wepmode on > > Set "wlandebug scan+auth+assoc", got the following in > /var/log/messages. (I've trimmed to 100 lines, the remainder is more > of the same. > > Any suggestions, folks? Proper next steps to debug? > > Thanks, > ==ml > > Feb 21 09:45:57 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 > Feb 21 09:45:57 stretchlimo kernel: ath0: [ITHREAD] > Feb 21 09:45:57 stretchlimo kernel: ath0: using obsoleted if_watchdog interface > Feb 21 09:45:57 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 > Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 > Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) Not good. You don't indicate what channel the ap is using but presumably it's not 40. I see no other similar msgs so presumably this was a one time occurence? Did you eject the card mid-scan? > Feb 21 09:47:34 stretchlimo kernel: ath0: detached > Feb 21 09:47:38 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 > Feb 21 09:47:38 stretchlimo kernel: ath0: [ITHREAD] > Feb 21 09:47:38 stretchlimo kernel: ath0: using obsoleted if_watchdog interface > Feb 21 09:47:38 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 > Feb 21 09:47:38 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 > Feb 21 09:47:44 stretchlimo kernel: ath0: detached > Feb 21 11:03:36 stretchlimo kernel: ath0: mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus0 > Feb 21 11:03:36 stretchlimo kernel: ath0: [ITHREAD] > Feb 21 11:03:36 stretchlimo kernel: ath0: using obsoleted if_watchdog interface > Feb 21 11:03:36 stretchlimo kernel: ath0: Ethernet address: 00:80:c8:1f:8c:43 > Feb 21 11:03:36 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 > Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_check_scan: active scan, duration 2147483647, desired mode auto, flush > Feb 21 11:09:40 stretchlimo kernel: ath0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, flush > Feb 21 11:09:40 stretchlimo kernel: ath0: scan set 1g, 6g, 11g, 7g, 52a, 56a, 60a, 64a, 36a, 40a, 44a, 48a, 2g, 3g, 4g, 5g, 8g, 9g, 10g, 149a, 153a, 157a, 161a, 165a, 50S, 58S, 152S, 160S dwell min 20 max 200 > Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1b -> 1g [active, dwell min 20 max 200] > Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] > Feb 21 11:09:40 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] > Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] > Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] > Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] > Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] > Feb 21 11:09:41 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] > Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] > Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] > Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] > Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] > Feb 21 11:09:42 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] > Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] > Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] > Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] > Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] > Feb 21 11:09:43 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] > Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] > Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] > Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] > Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] > Feb 21 11:09:44 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] > Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] > Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 165a -> 50S [active, dwell min 20 max 200] > Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 50S -> 58S [active, dwell min 20 max 200] > Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 58S -> 152S [active, dwell min 20 max 200] > Feb 21 11:09:45 stretchlimo kernel: ath0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200] > Feb 21 11:09:46 stretchlimo kernel: ath0: sta_pick_bss: no scan candidate > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: done, restart [ticks 5357219, dwell min 20 scanend 2152835125] > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 160S -> 1g [active, dwell min 20 max 200] > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] > Feb 21 11:09:46 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] > Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] > Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] > Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] > Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] > Feb 21 11:09:47 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] > Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] > Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] > Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] > Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] > Feb 21 11:09:48 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] > Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] > Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] > Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] > Feb 21 11:09:49 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] > Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 10g -> 149a [active, dwell min 20 max 200] > Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] > Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] > Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] > Feb 21 11:09:50 stretchlimo kernel: ath0: scan_next: chan 161a -> 165a [active, dwell min 20 max 200] > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 165a -> 50S [active, dwell min 20 max 200] > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 50S -> 58S [active, dwell min 20 max 200] > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 58S -> 152S [active, dwell min 20 max 200] > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 152S -> 160S [active, dwell min 20 max 200] > Feb 21 11:09:51 stretchlimo kernel: ath0: sta_pick_bss: no scan candidate > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: done, restart [ticks 5362959, dwell min 20 scanend 2152835125] > Feb 21 11:09:51 stretchlimo kernel: ath0: scan_next: chan 160S -> 1g [active, dwell min 20 max 200] > Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] > Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] > Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] > Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 7g -> 52a [active, dwell min 20 max 200] > Feb 21 11:09:52 stretchlimo kernel: ath0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] > Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] > Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] > Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] > Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] > Feb 21 11:09:53 stretchlimo kernel: ath0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] > Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] > Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] > Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] > Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] > Feb 21 11:09:54 stretchlimo kernel: ath0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] > Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] > Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] > Feb 21 11:09:55 stretchlimo kernel: ath0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] So the card never saw any beacon/probe response frames from any ap's. Are there any besides the one you're trying to use? Can you setup a 2nd laptop and sniff to see if your laptop is sending ProbeRequest on the channel the ap is using and/or whether it sees frames this laptop doesn't see? BTW I think you're missing a deftxkey 1 in your ifconfig line. Sam From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 01:59:30 2008 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 A80EC16A517 for ; Fri, 22 Feb 2008 01:59:30 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0B013C457 for ; Fri, 22 Feb 2008 01:59:30 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.204] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id m1M1xLUP037350; Thu, 21 Feb 2008 17:59:27 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <47BE2C79.1080203@freebsd.org> Date: Thu, 21 Feb 2008 17:59:21 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Heiko Wundram (Beenic)" References: <200802211053.16113.wundram@beenic.net> In-Reply-To: <200802211053.16113.wundram@beenic.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: OT: Stream structures in bzlib and zlib 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, 22 Feb 2008 01:59:30 -0000 Heiko Wundram (Beenic) wrote: > Hey all! > > I'm currently working on a project using zlib and bzlib, and I'm currently > slightly stomped by the fact that both define the input buffer in their > stream structure as non-const. I think they're not defined as const just to maintain compatibility with old and/or broken compilers. libarchive treats them as const and has never had any problems from this. Cheers, Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 08:28:55 2008 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 92C4C16A400 for ; Fri, 22 Feb 2008 08:28:55 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F13D13C468 for ; Fri, 22 Feb 2008 08:28:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1M8SZdq097646; Fri, 22 Feb 2008 09:28:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1M8SZkj097645; Fri, 22 Feb 2008 09:28:35 +0100 (CET) (envelope-from olli) Date: Fri, 22 Feb 2008 09:28:35 +0100 (CET) Message-Id: <200802220828.m1M8SZkj097645@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, gizmen@blurp.pl In-Reply-To: <200802212229.40988.gizmen@blurp.pl> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 22 Feb 2008 09:28:36 +0100 (CET) Cc: Subject: Re: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, gizmen@blurp.pl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 08:28:55 -0000 Bartosz Giza wrote: > I have found quite interesting feature on one of router that lately i have > taken to administer. > What i knew was that file /var/run/dmesg.boot holds data from kernel buffer > that is taken right after file system(s) are mounted. > Lately i have found that one router writes to this file data from kernel > buffer when system is going to reeboot. Below are few lines from this file. > What you can see are lines from kernel right before reeboot. I have never seen > before such lines in this file. And this is quite interesting. Could anyone > tell me how can i achieve such funcionality on other systems ? I have tried > to find on google about this but i couldn't find anything similar to this. Upon a reboot, the kernel is usually loaded to the same physical addresses in RAM where it was before, so the dmesg buffer will be at the same location, too (unless you built a new kernel, of course). So all the contents from before reboot are still there -- *IF* the system BIOS didn't clear the RAM. Then the old contents will end up in /var/run/dmesg.boot, too. You could try looking at your BIOS setup. Some have an option called "Quick POST" or similar. If you enable it, the BIOS will skip the RAM test (which is rather useless anyway) which clears the RAM. It might help, but it depends very much on your mainboard and BIOS. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 09:25:06 2008 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 EE7ED16A402 for ; Fri, 22 Feb 2008 09:25:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id E408713C45E for ; Fri, 22 Feb 2008 09:25:06 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id BDB241CC038; Fri, 22 Feb 2008 01:25:06 -0800 (PST) Date: Fri, 22 Feb 2008 01:25:06 -0800 From: Jeremy Chadwick To: freebsd-hackers@FreeBSD.ORG, gizmen@blurp.pl Message-ID: <20080222092506.GA25704@eos.sc1.parodius.com> References: <200802212229.40988.gizmen@blurp.pl> <200802220828.m1M8SZkj097645@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802220828.m1M8SZkj097645@lurza.secnetix.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 09:25:07 -0000 On Fri, Feb 22, 2008 at 09:28:35AM +0100, Oliver Fromme wrote: > Bartosz Giza wrote: > > I have found quite interesting feature on one of router that lately i have > > taken to administer. > > What i knew was that file /var/run/dmesg.boot holds data from kernel buffer > > that is taken right after file system(s) are mounted. > > Lately i have found that one router writes to this file data from kernel > > buffer when system is going to reeboot. Below are few lines from this file. > > What you can see are lines from kernel right before reeboot. I have never seen > > before such lines in this file. And this is quite interesting. Could anyone > > tell me how can i achieve such funcionality on other systems ? I have tried > > to find on google about this but i couldn't find anything similar to this. > > Upon a reboot, the kernel is usually loaded to the same > physical addresses in RAM where it was before, so the > dmesg buffer will be at the same location, too (unless > you built a new kernel, of course). So all the contents > from before reboot are still there -- *IF* the system > BIOS didn't clear the RAM. Then the old contents will > end up in /var/run/dmesg.boot, too. > > You could try looking at your BIOS setup. Some have an > option called "Quick POST" or similar. If you enable > it, the BIOS will skip the RAM test (which is rather > useless anyway) which clears the RAM. It might help, > but it depends very much on your mainboard and BIOS. There is also kern.msgbuf_clear. However, this is a sysctl, which means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output after the OS had started. Bummer. It would be useful if there was a loader.conf variable which was the equivalent of msgbuf_clear. In fact, I'm wondering why the message buffer isn't cleared on shutdown/immediately prior to reboot... Interesting tidbit: We have one production machine which when booted into single-user via serial console for a world install, retains all of the output from that single-user session even once rebooted and brought back into multi-user mode. This poses a substantial security risk, especially during the mergemaster phase (we can discuss why if anyone is curious). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 09:32:19 2008 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 E6C8316A406 for ; Fri, 22 Feb 2008 09:32:19 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id BE9B013C4E7 for ; Fri, 22 Feb 2008 09:32:19 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 21440 invoked by uid 0); 22 Feb 2008 09:32:19 -0000 Received: from unknown (HELO wideload.network.lan) (xistence@0x58.com@68.228.228.123) by mailexchange.osnn.net with SMTP; 22 Feb 2008 09:32:19 -0000 Message-Id: <689B489C-D63C-4BA4-BA13-A9429032CB8B@0x58.com> From: Bert JW Regeer To: Jeremy Chadwick In-Reply-To: <20080222092506.GA25704@eos.sc1.parodius.com> Content-Type: multipart/signed; boundary=Apple-Mail-1--120283250; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 02:31:39 -0700 References: <200802212229.40988.gizmen@blurp.pl> <200802220828.m1M8SZkj097645@lurza.secnetix.de> <20080222092506.GA25704@eos.sc1.parodius.com> X-Mailer: Apple Mail (2.919.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Hackers Subject: Re: memory not cleared on reboot (Was: cool feature of dmesg.boot file) 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, 22 Feb 2008 09:32:20 -0000 --Apple-Mail-1--120283250 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 22, 2008, at 02:25 , Jeremy Chadwick wrote: > [...] > > Interesting tidbit: We have one production machine which when booted > into single-user via serial console for a world install, retains all > of > the output from that single-user session even once rebooted and > brought > back into multi-user mode. This poses a substantial security risk, > especially during the mergemaster phase (we can discuss why if > anyone is > curious). > > -- > | Jeremy Chadwick jdc at > parodius.com | > | Parodius Networking http://www.parodius.com/ > | > | UNIX Systems Administrator Mountain View, CA, > USA | > | Making life hard for others since 1977. PGP: > 4BD6C0CB | This is more scary: http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-effective/ Which is the exact effect you are seeing. Cheerio, Bert JW Regeer --Apple-Mail-1--120283250-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 09:53:02 2008 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 9E49616A400; Fri, 22 Feb 2008 09:53:02 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 126C013C4CE; Fri, 22 Feb 2008 09:53:01 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1M9qsF7001106; Fri, 22 Feb 2008 10:52:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1M9qskE001105; Fri, 22 Feb 2008 10:52:54 +0100 (CET) (envelope-from olli) Date: Fri, 22 Feb 2008 10:52:54 +0100 (CET) Message-Id: <200802220952.m1M9qskE001105@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG, gizmen@blurp.pl In-Reply-To: <20080222092506.GA25704@eos.sc1.parodius.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 22 Feb 2008 10:52:55 +0100 (CET) Cc: Subject: Re: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG, gizmen@blurp.pl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 09:53:02 -0000 Jeremy Chadwick wrote: > Oliver Fromme wrote: > > Upon a reboot, the kernel is usually loaded to the same > > physical addresses in RAM where it was before, so the > > dmesg buffer will be at the same location, too (unless > > you built a new kernel, of course). So all the contents > > from before reboot are still there -- *IF* the system > > BIOS didn't clear the RAM. Then the old contents will > > end up in /var/run/dmesg.boot, too. > > > > You could try looking at your BIOS setup. Some have an > > option called "Quick POST" or similar. If you enable > > it, the BIOS will skip the RAM test (which is rather > > useless anyway) which clears the RAM. It might help, > > but it depends very much on your mainboard and BIOS. > > There is also kern.msgbuf_clear. However, this is a sysctl, which > means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output > after the OS had started. Bummer. > > It would be useful if there was a loader.conf variable which was the > equivalent of msgbuf_clear. In fact, I'm wondering why the message > buffer isn't cleared on shutdown/immediately prior to reboot... So you can see panic messages and other useful things that happened before the reboot. It's a _feature_, not a bug. > Interesting tidbit: We have one production machine which when booted > into single-user via serial console for a world install, retains all of > the output from that single-user session even once rebooted and brought > back into multi-user mode. This poses a substantial security risk, > especially during the mergemaster phase (we can discuss why if anyone is > curious). sysctl security.bsd.unprivileged_read_msgbuf=0 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:09:24 2008 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 6EB0F16A400 for ; Fri, 22 Feb 2008 10:09:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6474D13C45B for ; Fri, 22 Feb 2008 10:09:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 1F1521CC033; Fri, 22 Feb 2008 02:09:24 -0800 (PST) Date: Fri, 22 Feb 2008 02:09:24 -0800 From: Jeremy Chadwick To: freebsd-hackers@FreeBSD.ORG, gizmen@blurp.pl Message-ID: <20080222100924.GA26637@eos.sc1.parodius.com> References: <20080222092506.GA25704@eos.sc1.parodius.com> <200802220952.m1M9qskE001105@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802220952.m1M9qskE001105@lurza.secnetix.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 10:09:24 -0000 On Fri, Feb 22, 2008 at 10:52:54AM +0100, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Oliver Fromme wrote: > > > Upon a reboot, the kernel is usually loaded to the same > > > physical addresses in RAM where it was before, so the > > > dmesg buffer will be at the same location, too (unless > > > you built a new kernel, of course). So all the contents > > > from before reboot are still there -- *IF* the system > > > BIOS didn't clear the RAM. Then the old contents will > > > end up in /var/run/dmesg.boot, too. > > > > > > You could try looking at your BIOS setup. Some have an > > > option called "Quick POST" or similar. If you enable > > > it, the BIOS will skip the RAM test (which is rather > > > useless anyway) which clears the RAM. It might help, > > > but it depends very much on your mainboard and BIOS. > > > > There is also kern.msgbuf_clear. However, this is a sysctl, which > > means if set to 1 in /etc/sysctl.conf, you'd lose your dmesg output > > after the OS had started. Bummer. > > > > It would be useful if there was a loader.conf variable which was the > > equivalent of msgbuf_clear. In fact, I'm wondering why the message > > buffer isn't cleared on shutdown/immediately prior to reboot... > > So you can see panic messages and other useful things that > happened before the reboot. It's a _feature_, not a bug. I've never seen a single kernel panic push output into the kernel message buffer; do you mean things ike automatic stack trace dumping on panic? (We have this disabled, which may be why I've never seen it). Either way, it's a feature with major security implications. So, for those of us who are concerned about master.passwd changes via mergemaster being stuffed into msgbuf, how do we disable said feature? (Before answering, see below as well). > > Interesting tidbit: We have one production machine which when booted > > into single-user via serial console for a world install, retains all of > > the output from that single-user session even once rebooted and brought > > back into multi-user mode. This poses a substantial security risk, > > especially during the mergemaster phase (we can discuss why if anyone is > > curious). > > sysctl security.bsd.unprivileged_read_msgbuf=0 No can do -- we have many users who look at dmesg for a reason: logging of coredumped binaries (kern.logsigexit=1), and if there were any signs of disk or network issues during that time. I've tried using that in the past and got significant flack from our userbase. If you'd like, I can have them chime in on this thread as validation. Using security.bsd.unprivileged_read_msgbuf=0 to "solve" said concern is an ineffective workaround in our case. I'm willing to bet others feel the same way. Maybe I should look into writing a patch that does in fact clear the buffer immediately before reboot, and tie it to a sysctl. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:22:37 2008 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 D81A916A402 for ; Fri, 22 Feb 2008 10:22:37 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8B17B13C46A for ; Fri, 22 Feb 2008 10:22:37 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id 2D2D6BFEC79; Fri, 22 Feb 2008 10:22:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id aWqV11joBDHN; Fri, 22 Feb 2008 10:22:25 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 6B4C9BFEB7A; Fri, 22 Feb 2008 10:22:25 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1MAMPDU094996; Fri, 22 Feb 2008 11:22:25 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1MAMO52094995; Fri, 22 Feb 2008 11:22:24 +0100 (CET) (envelope-from rink) Date: Fri, 22 Feb 2008 11:22:24 +0100 From: Rink Springer To: Jeremy Chadwick Message-ID: <20080222102224.GA87406@rink.nu> References: <20080222092506.GA25704@eos.sc1.parodius.com> <200802220952.m1M9qskE001105@lurza.secnetix.de> <20080222100924.GA26637@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222100924.GA26637@eos.sc1.parodius.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 10:22:37 -0000 On Fri, Feb 22, 2008 at 02:09:24AM -0800, Jeremy Chadwick wrote: > Maybe I should look into writing a patch that does in fact clear the > buffer immediately before reboot, and tie it to a sysctl. I suggest just making a loader tunable to do this. I think the following should do it (untested): --- subr_prf.c 2007-03-08 07:44:34.000000000 +0100 +++ subr_prf.new.c 2008-02-22 11:21:53.000000000 +0100 @@ -913,14 +913,20 @@ msgbufinit(void *ptr, int size) { char *cp; + char *rv; static struct msgbuf *oldp = NULL; size -= sizeof(*msgbufp); cp = (char *)ptr; msgbufp = (struct msgbuf *)(cp + size); - msgbuf_reinit(msgbufp, cp, size); - if (msgbufmapped && oldp != msgbufp) - msgbuf_copy(oldp, msgbufp); + rv = getenv("kern.ignore_old_msgbuf"); + if (rv != NULL && strncmp(rv, "1", 1) != 0) { + msgbuf_clear(mbp); + } else { + msgbuf_reinit(msgbufp, cp, size); + if (msgbufmapped && oldp != msgbufp) + msgbuf_copy(oldp, msgbufp); + } msgbufmapped = 1; oldp = msgbufp; } Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:31:39 2008 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 4183316A401; Fri, 22 Feb 2008 10:31:39 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9897513C4E9; Fri, 22 Feb 2008 10:31:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1MAVapa002815; Fri, 22 Feb 2008 11:31:37 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1MAVajJ002806; Fri, 22 Feb 2008 11:31:36 +0100 (CET) (envelope-from olli) Date: Fri, 22 Feb 2008 11:31:36 +0100 (CET) Message-Id: <200802221031.m1MAVajJ002806@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG In-Reply-To: <20080222100924.GA26637@eos.sc1.parodius.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 22 Feb 2008 11:31:37 +0100 (CET) Cc: Subject: Re: cool feature of dmesg.boot file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, koitsu@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 10:31:39 -0000 Jeremy Chadwick wrote: > Oliver Fromme wrote: > > [...] > Either way, it's a feature with major security implications. So, for > those of us who are concerned about master.passwd changes via > mergemaster being stuffed into msgbuf, how do we disable said feature? > (Before answering, see below as well). > > > sysctl security.bsd.unprivileged_read_msgbuf=0 > > No can do -- we have many users who look at dmesg for a reason: logging > of coredumped binaries (kern.logsigexit=1), and if there were any signs > of disk or network issues during that time. I've tried using that in > the past and got significant flack from our userbase. If you'd like, I > can have them chime in on this thread as validation. > > Using security.bsd.unprivileged_read_msgbuf=0 to "solve" said concern > is an ineffective workaround in our case. I'm willing to bet others > feel the same way. Personally I think that normal users shouldn't need to be able to see the kernel's message buffer. Of course there are certainly people who disagree. :-) How about allowing people access to /var/log/messages (it's world-readable by default). The kernel's messages such as signal exits will be there, too. It's much more useful anyway because it has timestamps, unlike dmesg. Of course you would have to set kern.log_console_output=0 so the mergemaster session does not get logged. By the way, it's possible to tell mergemaster to ignore master.passwd in single user mode on the console so it won't turn up at all. You can merge any changes that are necessary by running mergemaster -p before going to single-user mode. That's what I usually do. > Maybe I should look into writing a patch that does in fact clear the > buffer immediately before reboot, and tie it to a sysctl. Well, you could simply type "sysctl kern.msgbuf_clear=1" right before you reboot. Or make a wrapper script for reboot (or a shell alias) so you don't have to remember. If you insist on writing a patch, then please make it default off. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:46:31 2008 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 C273516A400 for ; Fri, 22 Feb 2008 10:46:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id B8B3B13C45D for ; Fri, 22 Feb 2008 10:46:31 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A3DB01CC033; Fri, 22 Feb 2008 02:46:31 -0800 (PST) Date: Fri, 22 Feb 2008 02:46:31 -0800 From: Jeremy Chadwick To: freebsd-hackers@FreeBSD.ORG Message-ID: <20080222104631.GA27523@eos.sc1.parodius.com> References: <20080222100924.GA26637@eos.sc1.parodius.com> <200802221031.m1MAVajJ002806@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802221031.m1MAVajJ002806@lurza.secnetix.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 10:46:31 -0000 On Fri, Feb 22, 2008 at 11:31:36AM +0100, Oliver Fromme wrote: > If you insist on writing a patch, then please make it > default off. rink@ just provided one, and it does default to off. I fully agree with defaulting it to off as well; those of us that want it on can set it as such in loader.conf. I'll try out said patch this weekend. Assuming it works, and does get committed, I'll be more than happy to submit a PR along with a patch to update the loader.8 manpage, documenting kern.ignore_old_msgbuf. Thanks! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:51:23 2008 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 E9C8516A400; Fri, 22 Feb 2008 10:51:23 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id A849313C458; Fri, 22 Feb 2008 10:51:23 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id 9D5B2BFEC7A; Fri, 22 Feb 2008 10:51:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id WWucCUvp2sCi; Fri, 22 Feb 2008 10:51:14 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 08CD6BFEB7F; Fri, 22 Feb 2008 10:51:14 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1MApDR7096778; Fri, 22 Feb 2008 11:51:13 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1MApDUw096777; Fri, 22 Feb 2008 11:51:13 +0100 (CET) (envelope-from rink) Date: Fri, 22 Feb 2008 11:51:13 +0100 From: Rink Springer To: Jeremy Chadwick Message-ID: <20080222105113.GB87406@rink.nu> References: <20080222100924.GA26637@eos.sc1.parodius.com> <200802221031.m1MAVajJ002806@lurza.secnetix.de> <20080222104631.GA27523@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080222104631.GA27523@eos.sc1.parodius.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 10:51:24 -0000 On Fri, Feb 22, 2008 at 02:46:31AM -0800, Jeremy Chadwick wrote: > I'll try out said patch this weekend. Assuming it works, and does get > committed, I'll be more than happy to submit a PR along with a patch to > update the loader.8 manpage, documenting kern.ignore_old_msgbuf. Sounds good to me. I'll give it a try this weekend as well, but let me know if it works for you. I'll commit it and MFC it to 6/7-STABLE then. Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:56:42 2008 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 DB4D116A400 for ; Fri, 22 Feb 2008 10:56:42 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from in.niksun.com (210.18.76.166.sify.net [210.18.76.166]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6D313C474 for ; Fri, 22 Feb 2008 10:56:42 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from sharadc.in.niksun.com (unknown [10.60.5.27]) by in.niksun.com (Postfix) with ESMTP id B9A695D39; Fri, 22 Feb 2008 16:20:14 +0530 (IST) From: Sharad Chandra Organization: NIKSUN To: freebsd-hackers@freebsd.org Date: Fri, 22 Feb 2008 15:58:42 +0530 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802221558.42443.sharadc@in.niksun.com> Subject: usleep 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, 22 Feb 2008 10:56:42 -0000 Hi Guys, Does usleep work for you? i just saw it is implemented over nanosleep which passes a struct timeval to "select". on my system, one of instance for usleep and select sleep value. provided (sec).(microsec) => select (sleep) usleep (sleep) 0.000000 => select: 0.000004 usleep: 0.000008 0.000001 => select: 0.002199 usleep: 0.001758 0.000002 => select: 0.004125 usleep: 0.001688 0.000003 => select: 0.005546 usleep: 0.001999 0.000004 => select: 0.006645 usleep: 0.002045 0.000005 => select: 0.001374 usleep: 0.002034 0.000006 => select: 0.002480 usleep: 0.001996 0.000007 => select: 0.006715 usleep: 0.001998 0.000008 => select: 0.002297 usleep: 0.001662 0.000009 => select: 0.002635 usleep: 0.001999 0.000010 => select: 0.003717 usleep: 0.001988 -- Thanks Sharad Chandra From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 10:56:43 2008 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 DE04416A401 for ; Fri, 22 Feb 2008 10:56:42 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from in.niksun.com (210.18.76.166.sify.net [210.18.76.166]) by mx1.freebsd.org (Postfix) with ESMTP id 79FFB13C46E for ; Fri, 22 Feb 2008 10:56:42 +0000 (UTC) (envelope-from sharadc@in.niksun.com) Received: from sharadc.in.niksun.com (unknown [10.60.5.27]) by in.niksun.com (Postfix) with ESMTP id 706C35D27; Fri, 22 Feb 2008 16:11:58 +0530 (IST) From: Sharad Chandra Organization: NIKSUN To: freebsd-hackers@freebsd.org Date: Fri, 22 Feb 2008 15:50:25 +0530 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802221550.26129.sharadc@in.niksun.com> Subject: Start Fire nic card. 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, 22 Feb 2008 10:56:43 -0000 Hi, How does dual port star fire nic card time stamp? Is the sheduling round robin. if it is, there can be chances, a frame comes later than other can get lesser timestamp. -- Thanks Sharad Chandra From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 13:24:42 2008 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 9AFE116A402; Fri, 22 Feb 2008 13:24:42 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd2mo3so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7E92E13C442; Fri, 22 Feb 2008 13:24:42 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd3mr4so.prod.shaw.ca (pd3mr4so-qfe3.prod.shaw.ca [10.0.141.180]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JWN000SX3T6OO00@l-daemon>; Fri, 22 Feb 2008 05:24:42 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd3mr4so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JWN006EY3T58AC0@pd3mr4so.prod.shaw.ca>; Fri, 22 Feb 2008 05:24:42 -0700 (MST) Received: from soralx ([24.87.3.133]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JWN00J3V3T5U150@l-daemon>; Fri, 22 Feb 2008 05:24:41 -0700 (MST) Date: Fri, 22 Feb 2008 04:24:41 -0800 From: soralx@cydem.org In-reply-to: <20080222104631.GA27523@eos.sc1.parodius.com> To: freebsd-hackers@FreeBSD.ORG Message-id: <20080222042441.1ff40a0b@soralx> MIME-version: 1.0 X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.8; i386-portbld-freebsd7.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20080222100924.GA26637@eos.sc1.parodius.com> <200802221031.m1MAVajJ002806@lurza.secnetix.de> <20080222104631.GA27523@eos.sc1.parodius.com> Cc: koitsu@freebsd.org Subject: Re: cool feature of dmesg.boot file 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, 22 Feb 2008 13:24:42 -0000 > On Fri, Feb 22, 2008 at 11:31:36AM +0100, Oliver Fromme wrote: > > If you insist on writing a patch, then please make it > > default off. > > rink@ just provided one, and it does default to off. I fully agree with > defaulting it to off as well; those of us that want it on can set it as > such in loader.conf. > > I'll try out said patch this weekend. Assuming it works, and does get > committed, I'll be more than happy to submit a PR along with a patch to > update the loader.8 manpage, documenting kern.ignore_old_msgbuf. IMHO, 'kern.forget_old_msgbuf' would more accurately describe what it does [SorAlx] ridin' VS1400 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 13:37:32 2008 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 E6C4B16A400 for ; Fri, 22 Feb 2008 13:37:32 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from mail.beenic.net (mail.beenic.net [83.246.72.40]) by mx1.freebsd.org (Postfix) with ESMTP id B30C513C45B for ; Fri, 22 Feb 2008 13:37:32 +0000 (UTC) (envelope-from wundram@beenic.net) Received: from [192.168.1.38] (a89-182-150-142.net-htp.de [89.182.150.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.beenic.net (Postfix) with ESMTP id A41EAA44529 for ; Fri, 22 Feb 2008 14:37:30 +0100 (CET) From: "Heiko Wundram (Beenic)" Organization: Beenic Networks GmbH To: freebsd-hackers@freebsd.org Date: Fri, 22 Feb 2008 14:37:48 +0100 User-Agent: KMail/1.9.7 References: <200802221558.42443.sharadc@in.niksun.com> In-Reply-To: <200802221558.42443.sharadc@in.niksun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802221437.48293.wundram@beenic.net> Subject: Re: usleep 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, 22 Feb 2008 13:37:33 -0000 Am Freitag, 22. Februar 2008 11:28:42 schrieb Sharad Chandra: > Does usleep work for you? i just saw it is implemented over nanosleep > which passes a struct timeval to "select". Quoting from POSIX: """ The usleep() function will cause the calling thread to be suspended from execution until either the number of real-time microseconds specified by the argument useconds has elapsed or a signal is delivered to the calling thread and its action is to invoke a signal-catching function or to terminate the process. The suspension time may be longer than requested due to the scheduling of other activity by the system. """ See the last sentence, specifically. So, yes, the behaviour you're seeing is pretty much expected, simply because _user_ processes are scheduled in timeslices, which depend on the HZ setting of the kernel. -- Heiko Wundram Product & Application Development From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 15:28:43 2008 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 714C016A407 for ; Fri, 22 Feb 2008 15:28:43 +0000 (UTC) (envelope-from marduk@portaone.com) Received: from bugor.portaone.com (bugor.portaone.com [65.61.203.147]) by mx1.freebsd.org (Postfix) with ESMTP id 61F7713C45D for ; Fri, 22 Feb 2008 15:28:43 +0000 (UTC) (envelope-from marduk@portaone.com) Received: from k3-gw.portaone.com ([193.28.87.193] helo=[192.168.10.98]) by bugor.portaone.com (8.11.3/8.11.3) with ESMTP id 1JSZbs-0002tY-BO; Fri, 22 Feb 2008 07:14:48 -0800 Message-ID: <47BEE6E7.9030804@portaone.com> Date: Fri, 22 Feb 2008 17:14:47 +0200 From: Andrew Pogrebennyk User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200802221558.42443.sharadc@in.niksun.com> In-Reply-To: <200802221558.42443.sharadc@in.niksun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sharad Chandra Subject: Re: usleep 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, 22 Feb 2008 15:28:43 -0000 Sharad, Additionally, this C routine is considered obsolete (unlike shell command by the same name). The interaction of this function with SIGALRM and other timer functions such as sleep(), alarm(), setitimer(), and nanosleep() is unspecified. Additionally, its use in multi-threaded programs can lead to somewhat surprising results. Use nanosleep(2) or setitimer(2) instead. Sharad Chandra wrote: > Hi Guys, > > Does usleep work for you? i just saw it is implemented over nanosleep which > passes a struct timeval to "select". > > on my system, one of instance for usleep and select sleep value. > > provided > (sec).(microsec) => select (sleep) usleep (sleep) > 0.000000 => select: 0.000004 usleep: 0.000008 > 0.000001 => select: 0.002199 usleep: 0.001758 > 0.000002 => select: 0.004125 usleep: 0.001688 > 0.000003 => select: 0.005546 usleep: 0.001999 > 0.000004 => select: 0.006645 usleep: 0.002045 > 0.000005 => select: 0.001374 usleep: 0.002034 > 0.000006 => select: 0.002480 usleep: 0.001996 > 0.000007 => select: 0.006715 usleep: 0.001998 > 0.000008 => select: 0.002297 usleep: 0.001662 > 0.000009 => select: 0.002635 usleep: 0.001999 > 0.000010 => select: 0.003717 usleep: 0.001988 > > -- > > Thanks > Sharad Chandra -- Sincerely, Andrew Pogrebennyk From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 16:05:04 2008 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 9F85216A407; Fri, 22 Feb 2008 16:05:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 22BDB13C459; Fri, 22 Feb 2008 16:05:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E9ED943FA41; Fri, 22 Feb 2008 18:05:02 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ytRs3ICfiOFV; Fri, 22 Feb 2008 18:05:01 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4A71B43CEAD; Fri, 22 Feb 2008 18:05:00 +0200 (EET) Message-ID: <47BEF2AA.900@icyb.net.ua> Date: Fri, 22 Feb 2008 18:04:58 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------060709010905010700020005" Cc: Subject: Re: cx_lowest and CPU usage 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, 22 Feb 2008 16:05:04 -0000 This is a multi-part message in MIME format. --------------060709010905010700020005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit on 20/02/2008 20:33 Andriy Gapon said the following: > on 19/02/2008 23:42 Andriy Gapon said the following: >> The last result most probably means that RTC IRQ was not the interrupt >> to wake CPU from sleeping state. >> The first possibility that comes to mind is that on this particular >> hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. > > So it seems that this was true. > Here's a shortcut to the relevant info: > PIIX4E (FW82371EB) specification > DEVACTB — DEVICE ACTIVITY B (FUNCTION 3) pci register description > BRLD_EN_IRQ8, bit 5 > > $ pciconf -r pci0:0:7:3 0x58 > 03040c07 Attached is a patch that fixes the issue for me (without any side-effects) and should not cause any harm for others. -- Andriy Gapon --------------060709010905010700020005 Content-Type: text/x-patch; name="acpi_cpu-piix4-irqs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_cpu-piix4-irqs.patch" --- acpi_cpu.c.orig 2008-02-21 21:08:16.000000000 +0200 +++ acpi_cpu.c 2008-02-21 21:13:54.000000000 +0200 @@ -113,6 +113,12 @@ #define PCI_REVISION_B_STEP 1 #define PCI_REVISION_4E 2 #define PCI_REVISION_4M 3 +#define PIIX4_DEVACTB_REG 0x58 +#define PIIX4_BRLD_EN_IRQ0 (1<<0) +#define PIIX4_BRLD_EN_IRQ (1<<1) +#define PIIX4_BRLD_EN_IRQ8 (1<<5) +#define PIIX4_STOP_BREAK_MASK (PIIX4_BRLD_EN_IRQ0 | PIIX4_BRLD_EN_IRQ | PIIX4_BRLD_EN_IRQ8) +#define PIIX4_PCNTRL_BST_EN (1<<10) /* Platform hardware resource information. */ static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ @@ -1004,6 +1010,7 @@ acpi_cpu_quirks(void) { device_t acpi_dev; + uint32_t val; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -1052,12 +1059,25 @@ * See erratum #18 ("C3 Power State/BMIDE and Type-F DMA * Livelock") from the January 2002 PIIX4 specification update. * Applies to all PIIX4 models. + * + * Also, make sure that all interrupts cause a "Stop Break" + * event to exit from C2 state. */ + case PCI_REVISION_A_STEP: + case PCI_REVISION_B_STEP: case PCI_REVISION_4E: case PCI_REVISION_4M: cpu_quirks |= CPU_QUIRK_NO_C3; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu: working around PIIX4 bug, disabling C3\n")); + + val = pci_read_config(acpi_dev, PIIX4_DEVACTB_REG, 4); + if ((val & PIIX4_STOP_BREAK_MASK) != PIIX4_STOP_BREAK_MASK) { + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "PIIX4: enabling IRQs to generate Stop Break\n")); + val |= PIIX4_STOP_BREAK_MASK; + pci_write_config(acpi_dev, PIIX4_DEVACTB_REG, val, 4); + } break; default: break; --------------060709010905010700020005-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 16:08:52 2008 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 7EEFD16A404 for ; Fri, 22 Feb 2008 16:08:52 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-5-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id 696D213C459 for ; Fri, 22 Feb 2008 16:08:52 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id D4D14F164 for ; Fri, 22 Feb 2008 09:53:09 -0600 (CST) Received: from [128.194.81.7] (unknown [128.194.81.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-5-int.cis.tamu.edu (Postfix) with ESMTP id 34262F048 for ; Fri, 22 Feb 2008 09:53:09 -0600 (CST) Message-Id: <49B17835-A03A-4186-8669-B942668FEBF2@tamu.edu> From: David Duchscher To: hackers@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 09:53:09 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: amavisd-new at tamu.edu Cc: Subject: Winbond IO chip driver 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, 22 Feb 2008 16:08:52 -0000 It was suggested that this list may be a better place to post my request. I have started work on a WinBond chip driver (currently only the W83627HF chip) to provide access to the chips watchdog timer and sensors. I have never written a driver before and my C is rather rusty so I figured I would post what I currently have in hopes that some kind soul would take pity on me. What I have so far is located here: http://freebsd.tamu.edu/wbio/ The driver does attach and the watchdog timer works for the chip in my test machine running FreeBSD 6.3. TData sheets are here: http://www.winbond-usa.com/en/content/view/143/273/ Any advice, pointers, documents would be much appreciated. Thanks for your time... -- DaveD From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 17:34:49 2008 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 D304D16A409 for ; Fri, 22 Feb 2008 17:34:49 +0000 (UTC) (envelope-from truckline@tagshop.it) Received: from smtp.eutelia.it (mp1-smtp-5.eutelia.it [62.94.10.165]) by mx1.freebsd.org (Postfix) with ESMTP id 9E67413C4DD for ; Fri, 22 Feb 2008 17:34:49 +0000 (UTC) (envelope-from truckline@tagshop.it) Received: from ip-21-96.sn2.eutelia.it (ip-21-96.sn2.eutelia.it [83.211.21.96]) by smtp.eutelia.it (Eutelia) with SMTP id B29F848CC0 for ; Fri, 22 Feb 2008 18:05:46 +0100 (CET) Received: from [83.211.21.96] (port=24260 helo=ip-21-96.sn2.eutelia.it) by mx1.freebsd.org with esmtp id ef389-3d87-76 for hackers@freebsd.org; Fri, 22 Feb 2008 18:05:42 +0100 Message-ID: <47BF00E6.2080701@freebsd.org> Date: Fri, 22 Feb 2008 18:05:42 +0100 From: "Joey" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) To: "Erin" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Eradicates classrooms and traveling call without delay 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, 22 Feb 2008 17:34:49 -0000 F A S T T R A C K D E G R E E P R O G R A M Obtain the degree you deserve, based on your present knowledge and life experience. A prosperous future, money earning power, and the Admiration of all. Degrees from an Established, Prestigious, Leading Institution. Your Degree will show exactly what you really can do. Get the Job, Promotion, Business Opportunity and Social Advancement you Desire! Eliminates classrooms and traveling. Achieve your Bachelors, Masters, MBA, or PhD in the field of your expertise Professional and affordable Call now - your Graduation is a phone call away. Please call: +1 - 206 30 - 903 - 3 - 6 From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 18:08:26 2008 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 C11ED16A401 for ; Fri, 22 Feb 2008 18:08:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6228713C501 for ; Fri, 22 Feb 2008 18:08:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1MI8HXl011267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 05:08:18 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1MI8H0Q036496; Sat, 23 Feb 2008 05:08:17 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1MI8Ehm036459; Sat, 23 Feb 2008 05:08:14 +1100 (EST) (envelope-from peter) Date: Sat, 23 Feb 2008 05:08:14 +1100 From: Peter Jeremy To: Andrew Pogrebennyk Message-ID: <20080222180813.GD51095@server.vk2pj.dyndns.org> References: <200802221558.42443.sharadc@in.niksun.com> <47BEE6E7.9030804@portaone.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/ZYM6PqDyfNytx60" Content-Disposition: inline In-Reply-To: <47BEE6E7.9030804@portaone.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org, Sharad Chandra Subject: Re: usleep 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, 22 Feb 2008 18:08:26 -0000 --/ZYM6PqDyfNytx60 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2008 at 05:14:47PM +0200, Andrew Pogrebennyk wrote: >Additionally, this C routine is considered obsolete Can you provide a reference for this please. > (unlike shell command by the same name). I've never seen a shell function called usleep. Which shell are you using? > The interaction of this function with SIGALRM >and other timer functions such as sleep(), alarm(), setitimer(), and >nanosleep() is unspecified. Possibly on some OSs but not on FreeBSD. > Additionally, its use in multi-threaded >programs can lead to somewhat surprising results. Such as? If you are talking about having the process suspended instead of the thread then this is dependent on the threading library and the thread attributes and is no more or less surprising than any other similar function. > Use nanosleep(2) or setitimer(2) instead. If you bothered to read what Sharad had said, the man page or the source, you would find that usleep(3) _is_ implemented using nanosleep(2) so there is no point in using nanosleep() instead of usleep(). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --/ZYM6PqDyfNytx60 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvw+N/opHv/APuIcRAlgwAKC8b44TjBzig/OooY82Fnf0wu3UcQCggZAs HSlB6bjHDAOz5IGIiaGUvDY= =lFml -----END PGP SIGNATURE----- --/ZYM6PqDyfNytx60-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 18:18:23 2008 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 199EF16A405 for ; Fri, 22 Feb 2008 18:18:23 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 99A7613C458 for ; Fri, 22 Feb 2008 18:18:22 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so629830fka.11 for ; Fri, 22 Feb 2008 10:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=9mL7+FRjAvzVc6v5cC6SilYkTXTh0Vxbnjy5TygP+WU=; b=mH37R0w970OM4foWqfX4jLEzkrorumpzrJq4tkiqNL4LLUb5vjcGaCBexKSLFME2wnJIhDb87Am3fkqbiFc53NW/Z9JccmCmdKl9JaRrAh7t8y8E+qpEWJfjjoTy3PFeoIBvbspR00EmwiAosQ2OMy5JOC97CmlaXztQQU1HX5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=piJRTsFvdaMs5QSUJBgeapWmWnaeY25VdpS4MDvrBaUj+cN9+XyIZx09FZHVfypVmi7Utjgu5VCDRXtKNx3n3eeugW2m7SM9dSWyoy9B3pm7dulRz0Zit2abs/GZu5bb8as+BdIhbyw2nUgZiQbVuH++6oGjyhnYqslmGJkC4EE= Received: by 10.82.121.15 with SMTP id t15mr513671buc.1.1203702791486; Fri, 22 Feb 2008 09:53:11 -0800 (PST) Received: from ?88.214.149.122? ( [88.214.149.122]) by mx.google.com with ESMTPS id p10sm1587572gvf.8.2008.02.22.09.53.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 09:53:10 -0800 (PST) Message-Id: <77122846-92A6-47D2-B94C-3368AF167963@fnop.net> From: Rui Paulo To: Andriy Gapon In-Reply-To: <47BEF2AA.900@icyb.net.ua> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 17:53:03 +0000 References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> <47BEF2AA.900@icyb.net.ua> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo X-Mailman-Approved-At: Fri, 22 Feb 2008 18:24:16 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: cx_lowest and CPU usage 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, 22 Feb 2008 18:18:23 -0000 I'll handle this. Thanks! On Feb 22, 2008, at 4:04 PM, Andriy Gapon wrote: > on 20/02/2008 20:33 Andriy Gapon said the following: >> on 19/02/2008 23:42 Andriy Gapon said the following: >>> The last result most probably means that RTC IRQ was not the =20 >>> interrupt >>> to wake CPU from sleeping state. >>> The first possibility that comes to mind is that on this particular >>> hardware RTC interrupt (IRQ8) is not able to wake the system from =20= >>> C2 state. >> >> So it seems that this was true. >> Here's a shortcut to the relevant info: >> PIIX4E (FW82371EB) specification >> DEVACTB =97 DEVICE ACTIVITY B (FUNCTION 3) pci register description >> BRLD_EN_IRQ8, bit 5 >> >> $ pciconf -r pci0:0:7:3 0x58 >> 03040c07 > > Attached is a patch that fixes the issue for me (without any > side-effects) and should not cause any harm for others. > > --=20 > Andriy Gapon > --- acpi_cpu.c.orig 2008-02-21 21:08:16.000000000 +0200 > +++ acpi_cpu.c 2008-02-21 21:13:54.000000000 +0200 > @@ -113,6 +113,12 @@ > #define PCI_REVISION_B_STEP 1 > #define PCI_REVISION_4E 2 > #define PCI_REVISION_4M 3 > +#define PIIX4_DEVACTB_REG 0x58 > +#define PIIX4_BRLD_EN_IRQ0 (1<<0) > +#define PIIX4_BRLD_EN_IRQ (1<<1) > +#define PIIX4_BRLD_EN_IRQ8 (1<<5) > +#define PIIX4_STOP_BREAK_MASK (PIIX4_BRLD_EN_IRQ0 | =20 > PIIX4_BRLD_EN_IRQ | PIIX4_BRLD_EN_IRQ8) > +#define PIIX4_PCNTRL_BST_EN (1<<10) > > /* Platform hardware resource information. */ > static uint32_t cpu_smi_cmd; /* Value to write to = SMI_CMD. */ > @@ -1004,6 +1010,7 @@ > acpi_cpu_quirks(void) > { > device_t acpi_dev; > + uint32_t val; > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > > @@ -1052,12 +1059,25 @@ > * See erratum #18 ("C3 Power State/BMIDE and Type-F DMA > * Livelock") from the January 2002 PIIX4 specification update. > * Applies to all PIIX4 models. > + * > + * Also, make sure that all interrupts cause a "Stop Break" > + * event to exit from C2 state. > */ > + case PCI_REVISION_A_STEP: > + case PCI_REVISION_B_STEP: > case PCI_REVISION_4E: > case PCI_REVISION_4M: > cpu_quirks |=3D CPU_QUIRK_NO_C3; > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > "acpi_cpu: working around PIIX4 bug, disabling C3\n")); > + > + val =3D pci_read_config(acpi_dev, PIIX4_DEVACTB_REG, 4); > + if ((val & PIIX4_STOP_BREAK_MASK) !=3D = PIIX4_STOP_BREAK_MASK) { > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "PIIX4: enabling IRQs to generate Stop Break\n")); > + val |=3D PIIX4_STOP_BREAK_MASK; > + pci_write_config(acpi_dev, PIIX4_DEVACTB_REG, val, 4); > + } > break; > default: > break; > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-=20 > unsubscribe@freebsd.org" -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 20:39:59 2008 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 A628D16A402 for ; Fri, 22 Feb 2008 20:39:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A69CB13C44B for ; Fri, 22 Feb 2008 20:39:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1MKdu5i027997; Fri, 22 Feb 2008 21:39:56 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1MKduRf027996; Fri, 22 Feb 2008 21:39:56 +0100 (CET) (envelope-from olli) Date: Fri, 22 Feb 2008 21:39:56 +0100 (CET) Message-Id: <200802222039.m1MKduRf027996@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <754FD289-9E26-4368-9AB4-64F3ECB6CDFC@mac.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 22 Feb 2008 21:39:57 +0100 (CET) Cc: Subject: Re: /boot/loader graphics support & extensibility 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, 22 Feb 2008 20:39:59 -0000 Marcel Moolenaar wrote: > [Oliver explains bitblit, then Marcel explains bitblt.] OK, so we mean the same thing, bascially. > The higher lever TTY code simply calls bitblt with a > bit mask of the glyph to be printed and doesn't need to > know about the details of the display. As such, simple > console output works at any resolution and with any > color depth. > > At the same time the VGA driver is abstracted from any > high-level details, like fonts or character sets. This > means that it's easy to write an accelerated driver for > some graphics hardware. You simply implement mode > setting and bitblt and you're good to go. Yes, that'll work well for putting characters on the screen. But I don't think it is suitable for generic graphics operations, even (and especially) for drawing single pixels. > > For example, lets say there's a function to draw a > > rectangle (in fact there _is_ such a function in my code). > > The Forth code to draw a rectangle covering the whole > > screen at 640x480 would look like this: > > > > 480 640 0 0 vrect > > > > The FICL word pops the parameters from the Forth stack > > and calls a function gfx_rect(). This will go through > > an abstraction switch so it calls an appropriate function > > depending on the bitmap format of the current mode, > > i.e. there will be gfx_planar4_rect(), gfx_linear8_rect() > > and gfx_true24_rect(). Each of these functions implements > > the graphics operation in the most efficient way for the > > particular bitmap format. > > > > How would the above work with a bitblit function, exactly? > > You bitblt the 4 edges. I didn't say it was the most > performance optimal thing to do. I only said that it > can be abstracted that way. I'm sorry, I should have been clearer, that gfx_rect() function draws a filled rectangle. I don't think it makes sense to have a function for non-filled rectangles, because -- as you say -- that can easily and efficiently done by drawing 4 lines (I implemented efficient functions for vertical and horizontal lines, and a function for generic lines). Efficient line functions are important if someone wants to implement a simple windowing system in Forth (no, I'm not going to do this, but if someone else wants to, I won't hold him off). > Yes. My vtc(4) driver, which puts graphics support in the > kernel, is having the same problems with bitmaps. I have > a nice logo (the 4.4 daemon: see > http://www.mckusick.com/beastie/shirts/source.html), but > I only have it for the standard VGA 4-bit color mode. I need > a separate one for 16-bit and/or 256-bit colors... For the loader, I plan to support bitmaps in an upwards- compatible way. E.g. you should be able to use a 4bit PCX file in 8bit and 24bit modes (but not the other way round). > I think that sounds good. I do have another datapoint. > I leave it up to you whether that's something that needs > to be considered or not: > > EFI supports multiple consoles. In other words, the > EFI console can be both the display and the serial > line at the same time. Clearly, graphics mode is > something that you generally cannot duplicate over > the serial line. However, modulo the logo and > background, if the graphics console is like a text > console or serial console, then you can still have > them both. The serial console simply doesn't get > copied the logo and background, but since everything > else is text anyway, this should not be a problem. > > My ia64 machines use serial consoles, because > syscons hasn't been ported (and I'm not planning to > yet). However, it would be great if we could get the > EFI loader working in graphics mode already and > it would be especially great if that doesn't break the > dual console setting in EFI. > > The question before us is: worth a try or not worth > it... Sounds like a good plan, but I won't be able to help, because I know nothing about EFI, and I don't have any EFI machines. However, I will keep those EFI features in mind that you explained, and I will try make it possible that such support can easily be added at a later time. > > Well, personally I would also like to be able to use the > > capabilities of my hardware. My main "workstation" at home > > is a notebook. When using the default VGA resolution of > > 640x480, the hardware scales it up to the TFT resolution, > > and it doesn't do a particularly good job at it ... It's > > butt ugly and distorted. As a user, I would certainly > > welcome an option (in loader.conf or whatever) that enables > > me to select a better resolution. > > > > Is that like a toddler going nuts over candy? > > Yes and no. I can image that the user wants control over > the desktop. Power to the people. But here we're talking > about the boot process. For Joe User nothing more than > a waiting period. What does it matter, really, that a nice > logo is a bit distorted? Would it be nicer if we could avoid > the scaling? Yes, definitely. But it's not the first priority. I agree, it's definitely not first priority. I want to get the basic functionality done which will work with standard VGA and nothing else. There will be no VESA support at the beginning, or anything else. It's on my to-do list, but with lower priority. But I need to keep all those future enhancements in mind, even if they're not first priority, or otherwise it might become more difficult later on to add those features. I also want to avoid breaking the syntax of FICL words once they're established. That's why I have to think about all that now. > The graphics world is one with many pitfalls, obstacles > and controversies. I think it's best to get something basic > off the ground first. I agree. Absolutely. > I think performance is not a concern. > Once you have the basic functionality, you'll also have a > wishlist of things you want to do better; performance one > of them in all likelyhood. Performance isn't my highest priority, but not the lowest either. I try to do things in a way so that they're not horribly inefficient. At the very least I try to do it in a way so that they can be made more efficient easily. > I think we're finally moving into the 20th century :-) Even the 21st, I hope. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 21:59:54 2008 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 65BB216A403 for ; Fri, 22 Feb 2008 21:59:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5BABA13C442 for ; Fri, 22 Feb 2008 21:59:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m1MLxr08001839; Fri, 22 Feb 2008 13:59:53 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m1MLxpjS018563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2008 13:59:52 -0800 (PST) Message-Id: <073CCEB2-3124-4631-A034-6A23544A6177@mac.com> From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802222039.m1MKduRf027996@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 13:59:50 -0800 References: <200802222039.m1MKduRf027996@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility 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, 22 Feb 2008 21:59:54 -0000 On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote: >> At the same time the VGA driver is abstracted from any >> high-level details, like fonts or character sets. This >> means that it's easy to write an accelerated driver for >> some graphics hardware. You simply implement mode >> setting and bitblt and you're good to go. > > Yes, that'll work well for putting characters on the > screen. But I don't think it is suitable for generic > graphics operations, even (and especially) for drawing > single pixels. True. What do you envision? How generic do you think we should make it? For me the difference between an abstraction solely based on bitblt and an abstraction that includes a couple more primitives is minimal. The key aspect is that we should not have to duplicate 1000 lines of code, of which less than 10% deals with the hardware. This, for example, is a problem with syscons and the keyboard- and video switch interfaces. The keyboard switch interface alone has 18 functions???? That's a bad abstraction, nothing else. >>> You bitblt the 4 edges. I didn't say it was the most >> performance optimal thing to do. I only said that it >> can be abstracted that way. > > I'm sorry, I should have been clearer, that gfx_rect() > function draws a filled rectangle. I see. In that case it's a single bitblt operation :-) > For the loader, I plan to support bitmaps in an upwards- > compatible way. E.g. you should be able to use a 4bit > PCX file in 8bit and 24bit modes (but not the other way > round). That's an excellent plan. >> But I need to keep all those future enhancements in > mind, even if they're not first priority, or otherwise > it might become more difficult later on to add those > features. I also want to avoid breaking the syntax of > FICL words once they're established. That's why I > have to think about all that now. Yes. >> I think performance is not a concern. >> Once you have the basic functionality, you'll also have a >> wishlist of things you want to do better; performance one >> of them in all likelyhood. > > Performance isn't my highest priority, but not the lowest > either. I try to do things in a way so that they're not > horribly inefficient. At the very least I try to do it > in a way so that they can be made more efficient easily. Agreed. Be aware of making the mistake to separate and distinguish between variations of a single operation at too high a level. For example: it's much more costly to separate vertical line drawing from horizontal line drawing from any other kind of line drawing at the MI layer, than it is at the hardware level. The hardware level needs to check the parameters anyway and unless there's hardware acceleration it'll perform separate code paths most of the time. The upshot of a single line drawing primitive is that you don't have to worry about the coordinates and which API function you must call. This is important when the coordinates are parameters to some function and you'll find yourself coding like: if (isvertical(x1,y1,x2,y2)) drawline_vertical(...) elif (ishorizontal(x1,y1,x2,y2)) drawline_horizontal(...) else drawline_generic(...) With hardware acceleration you may not have to care at all and when you need to draw the line in software, you need to test the coordinates anyway and split the work based on angle even. In that case you also split horizontal and vertical. Anyway: that's enough out of me. I think what you're doing is great and I can't wait to see it realized... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 22:28:51 2008 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 0E7FB16A400 for ; Fri, 22 Feb 2008 22:28:51 +0000 (UTC) (envelope-from kayve@sfsu.edu) Received: from iron3.sfsu.edu (iron3.sfsu.edu [130.212.10.128]) by mx1.freebsd.org (Postfix) with ESMTP id 01A4013C474 for ; Fri, 22 Feb 2008 22:28:50 +0000 (UTC) (envelope-from kayve@sfsu.edu) X-onepass: IPPSC X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN7avkeC1Apk/2dsb2JhbACvHwQ Received: from smtp01.sfsu.edu ([130.212.10.100]) by iron3.sfsu.edu with ESMTP; 22 Feb 2008 14:28:50 -0800 Received: from apollo ([130.212.10.167]) by mail05a.sfsu.edu (Lotus Domino Release 7.0.3HF100) with ESMTP id 2008022214284931-4309 ; Fri, 22 Feb 2008 14:28:49 -0800 Date: Fri, 22 Feb 2008 14:28:49 -0800 (PST) From: KAYVEN RIESE X-X-Sender: kayve@apollo To: "Heiko Wundram (Beenic)" In-Reply-To: <200802221437.48293.wundram@beenic.net> Message-ID: References: <200802221558.42443.sharadc@in.niksun.com> <200802221437.48293.wundram@beenic.net> MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MAIL05a/SERVERS/SFSU(Release 7.0.3HF100 | December 5, 2007) at 02/22/2008 14:28:49, Serialize by Router on SMTP01/SERVERS/SFSU(Release 7.0.3|September 26, 2007) at 02/22/2008 14:28:49, Serialize complete at 02/22/2008 14:28:49 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: usleep 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, 22 Feb 2008 22:28:51 -0000 On Fri, 22 Feb 2008, Heiko Wundram (Beenic) wrote: > Am Freitag, 22. Februar 2008 11:28:42 schrieb Sharad Chandra: >> Does usleep work for you? i just saw it is implemented over nanosleep >> which passes a struct timeval to "select". > > Quoting from POSIX: > > """ > The usleep() function will cause the calling thread to be suspended from > execution until either the number of real-time microseconds specified by the > argument useconds has elapsed or a signal is delivered to the calling thread > and its action is to invoke a signal-catching function or to terminate the > process. The suspension time may be longer than requested due to the > scheduling of other activity by the system. > """ oh.. you DID say "microseconds" .. i was going to assume complete ignorance in pointing out that "u" is used because it looks remotely like the greek letter "mu" which is the metric abbreviation for "micro" wich is 10^-6 hope i am not being real obvious. > > See the last sentence, specifically. > > So, yes, the behaviour you're seeing is pretty much expected, simply because > _user_ processes are scheduled in timeslices, which depend on the HZ setting > of the kernel. > > -- > Heiko Wundram > Product & Application Development > _______________________________________________ > 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" > *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 23:38:39 2008 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 C0E0616A400 for ; Fri, 22 Feb 2008 23:38:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id BC09913C448 for ; Fri, 22 Feb 2008 23:38:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A00D51CC033; Fri, 22 Feb 2008 15:38:39 -0800 (PST) Date: Fri, 22 Feb 2008 15:38:39 -0800 From: Jeremy Chadwick To: David Duchscher Message-ID: <20080222233839.GA59633@eos.sc1.parodius.com> References: <49B17835-A03A-4186-8669-B942668FEBF2@tamu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B17835-A03A-4186-8669-B942668FEBF2@tamu.edu> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: hackers@freebsd.org Subject: Re: Winbond IO chip driver 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, 22 Feb 2008 23:38:39 -0000 On Fri, Feb 22, 2008 at 09:53:09AM -0600, David Duchscher wrote: > It was suggested that this list may be a better place to post my request. > > I have started work on a WinBond chip driver (currently only the W83627HF > chip) to provide access to the chips watchdog timer and sensors. I have > never written a driver before and my C is rather rusty so I figured I would > post what I currently have in hopes that some kind soul would take pity on > me. What I have so far is located here: > > http://freebsd.tamu.edu/wbio/ > > The driver does attach and the watchdog timer works for the chip in my test > machine running FreeBSD 6.3. TData sheets are here: > > http://www.winbond-usa.com/en/content/view/143/273/ > > Any advice, pointers, documents would be much appreciated. Somewhat related: I can work with you on this, if need be. I've been working with both the Winbond W83627HF and (more so) the Winbond W83793G, talking to both via SMBus, so that we have a way to monitor fans and thermal information on our Supermicro boxes. I've written an application that fetches said information per Supermicro specs (they deviate from Winbond's specifications a bit, since they appear to use resistors on some of the thermistors at different resistances -- and to make matters worse, the ICs are silkscreened on the board as W83627HFs but are actually W83793G -- really weird): FAN1 = 0 rpm FAN2 = 0 rpm FAN3 = 0 rpm FAN4 = 3366 rpm FAN5 = 1475 rpm FAN6 = 1193 rpm VCOREA (Vcore) = 1.292 V VCOREB (+1.5V) = 1.542 V VTT (P_VTT) = 1.204 V VSEN1(-12V) = -12.288 V VSEN2 (Vdimm) = 1.824 V 3VSEN (+3.3V) = 3.360 V 12VSEN (+12V) = 11.904 V 5VDD (+5V) = 4.998 V 5VSB (5Vsb) = 5.046 V VBAT (Vbatt) = 3.184 V TD1 = 30 C TR1 = 42 C TR2 = 33 C It would be ideal if we could get something going similar to Linux's lmsensors project, though with watchdog support too. However, I do not agree with the "auto-probe" method of finding out what HW IC is used; I would much rather have a configuration database of motherboards and what actual chip code they should use, ditto with "one-offs" (where some mainboard vendors use different slave addresses or I/O base ports). Yes, it would require more work, but it would guarantee functionality, and not present nightmare situations for users and developers, e.g. "I get SOME temperatures, but I don't know if they're right, and these voltages are totally wrong", etc... Finally, I have not played with the watchdog capabilities at all. Watchdogs are pretty cool though. :-) I'll look at your code over the next few weeks... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 06:00:53 2008 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 592AD16A400 for ; Sat, 23 Feb 2008 06:00:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EB12613C467 for ; Sat, 23 Feb 2008 06:00:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1N5xENV031006 for ; Fri, 22 Feb 2008 22:59:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 22 Feb 2008 22:59:37 -0700 (MST) Message-Id: <20080222.225937.-146245356.imp@bsdimp.com> To: hackers@FreeBSD.ORG From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: find -lname and -ilname implemented 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, 23 Feb 2008 06:00:53 -0000 Please find enclosed a patch that implements -lname and -ilname in FreeBSD's find. There's some shell scripts that insist on these gnu findtools features. Comments? Warner Index: find.1 =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/find.1,v retrieving revision 1.82 diff -u -r1.82 find.1 --- find.1 28 Feb 2007 10:19:25 -0000 1.82 +++ find.1 23 Feb 2008 05:57:30 -0000 @@ -436,6 +436,10 @@ is numeric and there is no such group name, then .Ar gname is treated as a group ID. +.It Ic -ilname Ar pattern +Like +.Ic -lname , +but the match is case insensitive. .It Ic -iname Ar pattern Like .Ic -name , @@ -455,6 +459,10 @@ True if the file has .Ar n links. +.It Ic -lname Ar pattern +Like +.Ic -name , +but the must also be a symbolic link. .It Ic -ls This primary always evaluates to true. The following information for the current file is written to standard output: Index: find.h =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/find.h,v retrieving revision 1.19 diff -u -r1.19 find.h --- find.h 14 May 2006 20:23:01 -0000 1.19 +++ find.h 22 Feb 2008 19:38:21 -0000 @@ -74,6 +74,7 @@ #define F_EXECPLUS 0x00020000 /* -exec ... {} + */ #define F_TIME_B 0x00040000 /* one of -Btime, -Bnewer, -newerB* */ #define F_TIME2_B 0x00080000 /* one of -newer?B */ +#define F_LINK 0x00100000 /* lname or liname */ /* node definition */ typedef struct _plandata { Index: function.c =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/function.c,v retrieving revision 1.58 diff -u -r1.58 function.c --- function.c 27 May 2006 18:27:41 -0000 1.58 +++ function.c 22 Feb 2008 19:50:13 -0000 @@ -1063,6 +1063,8 @@ int f_name(PLAN *plan, FTSENT *entry) { + if ((plan->flags & F_LINK) && !S_ISLNK(entry->fts_statp->st_mode)) + return 0; return !fnmatch(plan->c_data, entry->fts_name, plan->flags & F_IGNCASE ? FNM_CASEFOLD : 0); } @@ -1076,6 +1078,8 @@ pattern = nextarg(option, argvp); new = palloc(option); new->c_data = pattern; + if (new->flags & F_LINK) + ftsoptions &= ~FTS_NOSTAT; return new; } Index: option.c =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/option.c,v retrieving revision 1.25 diff -u -r1.25 option.c --- option.c 5 Apr 2006 23:06:11 -0000 1.25 +++ option.c 22 Feb 2008 19:37:33 -0000 @@ -88,7 +88,9 @@ { "-inum", c_inum, f_inum, 0 }, { "-ipath", c_name, f_path, F_IGNCASE }, { "-iregex", c_regex, f_regex, F_IGNCASE }, + { "-liname", c_name, f_name, F_LINK | F_IGNCASE }, { "-links", c_links, f_links, 0 }, + { "-lname", c_name, f_name, F_LINK }, { "-ls", c_ls, f_ls, 0 }, { "-maxdepth", c_mXXdepth, f_always_true, F_MAXDEPTH }, { "-mindepth", c_mXXdepth, f_always_true, 0 }, From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 07:03:59 2008 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 9204016A400 for ; Sat, 23 Feb 2008 07:03:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3666813C459 for ; Sat, 23 Feb 2008 07:03:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1N72jW7031450 for ; Sat, 23 Feb 2008 00:02:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 00:03:08 -0700 (MST) Message-Id: <20080223.000308.686168314.imp@bsdimp.com> To: hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080222.225937.-146245356.imp@bsdimp.com> References: <20080222.225937.-146245356.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 07:03:59 -0000 Sorry to be lame and follow up to my original email, but Ruslan was way too quick to give me feedback :-) I also did a few more of the really easy ones, and added a list of ones that we haven't implemented yet. Comments? Warner Index: extern.h =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/extern.h,v retrieving revision 1.23 diff -u -r1.23 extern.h --- extern.h 14 May 2006 20:23:00 -0000 1.23 +++ extern.h 23 Feb 2008 06:23:02 -0000 @@ -90,6 +90,7 @@ exec_f f_empty; exec_f f_exec; exec_f f_expr; +exec_f f_false; exec_f f_flags; exec_f f_fstype; exec_f f_group; Index: find.1 =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/find.1,v retrieving revision 1.82 diff -u -r1.82 find.1 --- find.1 28 Feb 2007 10:19:25 -0000 1.82 +++ find.1 23 Feb 2008 06:53:39 -0000 @@ -293,6 +293,12 @@ Please refer to the .Ic -atime primary description for information on supported time units. +.It Ic -d +Same as +.Ic depth . +Gnu find implements this as a primary in mistaken emulation of +.Fx +.Xr find 1 . .It Ic -delete Delete found files and/or directories. Always returns true. @@ -365,6 +371,15 @@ the string .Dq Li {} is not qualified. +.It Ic -execdir Ar utility Oo Ar argument ... Oc Li {} + +Same as +.Ic -execdir , +except that +.Dq Li {} +is replaced with as many pathnames as possible for each invocation of +.Ar utility . +This behaviour is similar to that of +.Xr xargs 1 . .It Ic -flags Oo Cm - Ns | Ns Cm + Oc Ns Ar flags , Ns Ar notflags The flags are specified using symbolic names (see .Xr chflags 1 ) . @@ -436,6 +451,10 @@ is numeric and there is no such group name, then .Ar gname is treated as a group ID. +.It Ic -ilname Ar pattern +Like +.Ic -lname , +but the match is case insensitive. .It Ic -iname Ar pattern Like .Ic -name , @@ -451,10 +470,18 @@ Like .Ic -regex , but the match is case insensitive. +.It Ic -iwholename Ar pattern +The same thing as +.Ic -ipath , +for Gnu find compatibility. .It Ic -links Ar n True if the file has .Ar n links. +.It Ic -lname Ar pattern +Like +.Ic -name , +but the matched file must also be a symbolic link. .It Ic -ls This primary always evaluates to true. The following information for the current file is written to standard output: @@ -497,6 +524,10 @@ .It Ic -mnewer Ar file Same as .Ic -newer . +.It Ic -mount +The same thing as +.Ic -xdev , +for Gnu find compatibility. .It Ic -mtime Ar n Ns Op Cm smhdw If no units are specified, this primary evaluates to true if the difference between the file last modification time and the time @@ -747,6 +778,10 @@ is numeric and there is no such user name, then .Ar uname is treated as a user ID. +.It Ic -wholename Ar pattern +The same thing as +.Ic -path , +for Gnu find compatibility. .El .Pp All primaries which take a numeric argument allow the number to be @@ -770,13 +805,17 @@ true. .Pp .It Cm \&! Ar expression -.It Cm -false Ar expression .It Cm -not Ar expression This is the unary .Tn NOT operator. It evaluates to true if the expression is false. .Pp +.It Cm -false +Always false. +.It Cm -true +Always true. +.Pp .It Ar expression Cm -and Ar expression .It Ar expression expression The Index: find.h =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/find.h,v retrieving revision 1.19 diff -u -r1.19 find.h --- find.h 14 May 2006 20:23:01 -0000 1.19 +++ find.h 23 Feb 2008 06:54:11 -0000 @@ -74,6 +74,7 @@ #define F_EXECPLUS 0x00020000 /* -exec ... {} + */ #define F_TIME_B 0x00040000 /* one of -Btime, -Bnewer, -newerB* */ #define F_TIME2_B 0x00080000 /* one of -newer?B */ +#define F_LINK 0x00100000 /* lname or ilname */ /* node definition */ typedef struct _plandata { Index: function.c =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/function.c,v retrieving revision 1.58 diff -u -r1.58 function.c --- function.c 27 May 2006 18:27:41 -0000 1.58 +++ function.c 23 Feb 2008 06:29:16 -0000 @@ -474,7 +474,7 @@ /* * always_true -- * - * Always true, used for -maxdepth, -mindepth, -xdev and -follow + * Always true, used for -maxdepth, -mindepth, -xdev, -follow, and -true */ int f_always_true(PLAN *plan __unused, FTSENT *entry __unused) @@ -1063,6 +1063,8 @@ int f_name(PLAN *plan, FTSENT *entry) { + if ((plan->flags & F_LINK) && !S_ISLNK(entry->fts_statp->st_mode)) + return 0; return !fnmatch(plan->c_data, entry->fts_name, plan->flags & F_IGNCASE ? FNM_CASEFOLD : 0); } @@ -1076,6 +1078,8 @@ pattern = nextarg(option, argvp); new = palloc(option); new->c_data = pattern; + if (new->flags & F_LINK) + ftsoptions &= ~FTS_NOSTAT; return new; } @@ -1353,7 +1357,7 @@ return new; } -/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or */ +/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or, c_true, c_false */ PLAN * c_simple(OPTION *option, char ***argvp __unused) @@ -1635,3 +1639,16 @@ } /* c_or == c_simple */ + +/* + * -false + * + * Always false. + */ +int +f_false(PLAN *plan __unused, FTSENT *entry __unused) +{ + return 0; +} + +/* c_false == c_simple */ Index: option.c =================================================================== RCS file: /cache/ncvs/src/usr.bin/find/option.c,v retrieving revision 1.25 diff -u -r1.25 option.c --- option.c 5 Apr 2006 23:06:11 -0000 1.25 +++ option.c 23 Feb 2008 06:57:54 -0000 @@ -58,6 +58,7 @@ int typecompare(const void *, const void *); /* NB: the following table must be sorted lexically. */ +/* Options listed with C++ comments are in gnu find, but not our find */ static OPTION const options[] = { { "!", c_simple, f_not, 0 }, { "(", c_simple, f_openparen, 0 }, @@ -74,26 +75,38 @@ { "-cmin", c_Xmin, f_Xmin, F_TIME_C }, { "-cnewer", c_newer, f_newer, F_TIME_C }, { "-ctime", c_Xtime, f_Xtime, F_TIME_C }, + { "-d", c_depth, f_depth, 0 }, +// -daystart { "-delete", c_delete, f_delete, 0 }, { "-depth", c_depth, f_depth, 0 }, { "-empty", c_empty, f_empty, 0 }, { "-exec", c_exec, f_exec, 0 }, { "-execdir", c_exec, f_exec, F_EXECDIR }, - { "-false", c_simple, f_not, 0 }, + { "-false", c_simple, f_false, 0 }, { "-flags", c_flags, f_flags, 0 }, +// -fls { "-follow", c_follow, f_always_true, 0 }, +// -fprint +// -fprint0 +// -fprintf { "-fstype", c_fstype, f_fstype, 0 }, +// -gid { "-group", c_group, f_group, 0 }, +// -ignore_readdir_race + { "-ilname", c_name, f_name, F_LINK | F_IGNCASE }, { "-iname", c_name, f_name, F_IGNCASE }, { "-inum", c_inum, f_inum, 0 }, { "-ipath", c_name, f_path, F_IGNCASE }, { "-iregex", c_regex, f_regex, F_IGNCASE }, + { "-iwholename",c_name, f_path, F_IGNCASE }, { "-links", c_links, f_links, 0 }, + { "-lname", c_name, f_name, F_LINK }, { "-ls", c_ls, f_ls, 0 }, { "-maxdepth", c_mXXdepth, f_always_true, F_MAXDEPTH }, { "-mindepth", c_mXXdepth, f_always_true, 0 }, { "-mmin", c_Xmin, f_Xmin, 0 }, { "-mnewer", c_newer, f_newer, 0 }, + { "-mount", c_xdev, f_always_true, 0 }, { "-mtime", c_Xtime, f_Xtime, 0 }, { "-name", c_name, f_name, 0 }, { "-newer", c_newer, f_newer, 0 }, @@ -118,6 +131,8 @@ { "-newermm", c_newer, f_newer, 0 }, { "-newermt", c_newer, f_newer, F_TIME2_T }, { "-nogroup", c_nogroup, f_nogroup, 0 }, +// -noignore_readdir_race +// -noleaf { "-not", c_simple, f_not, 0 }, { "-nouser", c_nouser, f_nouser, 0 }, { "-o", c_simple, f_or, 0 }, @@ -128,12 +143,19 @@ { "-perm", c_perm, f_perm, 0 }, { "-print", c_print, f_print, 0 }, { "-print0", c_print, f_print0, 0 }, +// -printf { "-prune", c_simple, f_prune, 0 }, +// -quit { "-regex", c_regex, f_regex, 0 }, +// -samefile { "-size", c_size, f_size, 0 }, + { "-true", c_simple, f_always_true, 0 }, { "-type", c_type, f_type, 0 }, +// -uid n { "-user", c_user, f_user, 0 }, + { "-wholename", c_name, f_path, 0 }, { "-xdev", c_xdev, f_always_true, 0 }, +// -xtype }; /* From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 15:21:03 2008 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 DD7A716A403 for ; Sat, 23 Feb 2008 15:21:03 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF5213C467 for ; Sat, 23 Feb 2008 15:21:03 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8) with ESMTP id m1NFJe1U084752; Sat, 23 Feb 2008 10:19:40 -0500 (EST) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.1/8.13.8/Submit) id m1NFJedJ084751; Sat, 23 Feb 2008 10:19:40 -0500 (EST) (envelope-from mwlucas) Date: Sat, 23 Feb 2008 10:19:40 -0500 From: "Michael W. Lucas" To: Sam Leffler Message-ID: <20080223151940.GA84703@bewilderbeast.blackhelicopters.org> References: <20080221162301.GA71695@bewilderbeast.blackhelicopters.org> <47BDF813.1010604@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BDF813.1010604@errno.com> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Sat, 23 Feb 2008 10:19:40 -0500 (EST) Cc: hackers@freebsd.org Subject: Re: ath0 will not associate 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, 23 Feb 2008 15:21:03 -0000 On Thu, Feb 21, 2008 at 02:15:47PM -0800, Sam Leffler wrote: > Michael W. Lucas wrote: > >Feb 21 09:45:57 stretchlimo kernel: ath0: mac 5.6 phy 4.1 radio 0.0 > >Feb 21 09:47:34 stretchlimo kernel: ath0: ath_chan_set: unable to reset > >channel 40 (5200 Mhz, flags 0x140 hal flags 0x140) > > Not good. You don't indicate what channel the ap is using but > presumably it's not 40. I see no other similar msgs so presumably > this was a one time occurence? Did you eject the card mid-scan? I let it run for a couple minutes, then removed the card. I don't think this is something to worry about. > So the card never saw any beacon/probe response frames from any ap's. > Are there any besides the one you're trying to use? Can you setup a 2nd > laptop and sniff to see if your laptop is sending ProbeRequest on the > channel the ap is using and/or whether it sees frames this laptop > doesn't see? Just wanted to let you know I'm working on this. You wouldn't think it so hard, but the other laptop is my wife's "don't-you-dare-touch-this-I-need-it-for-my-masters" Windows laptop. Live CD works, but the internal card is a Dell 1470 and my other wireless card is a wi0 b-only. So I'm reading up on ndiswrapper this weekend. Will be back as soon as I get an adequate sniffer working. > BTW I think you're missing a deftxkey 1 in your ifconfig line. Thanks. ==ml -- Michael W. Lucas mwlucas@BlackHelicopters.org, mwlucas@FreeBSD.org http://www.BlackHelicopters.org/~mwlucas/ Now Shipping: "Absolute FreeBSD" -- http://www.AbsoluteFreeBSD.com On 5/4/2007, the TSA kept 3 pairs of my soiled undies "for security reasons." From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 17:37:14 2008 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 CD12A16A400 for ; Sat, 23 Feb 2008 17:37:14 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 73F0F13C442 for ; Sat, 23 Feb 2008 17:37:14 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 46070 invoked by uid 1001); 23 Feb 2008 17:35:57 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Sat, 23 Feb 2008 12:35:57 -0500 Date: Sat, 23 Feb 2008 12:35:56 -0500 To: freebsd-hackers@freebsd.org, "M. Warner Losh" Message-ID: <20080223123556.3eee709d@bhuda.mired.org> In-Reply-To: <20080223.000308.686168314.imp@bsdimp.com> References: <20080222.225937.-146245356.imp@bsdimp.com> <20080223.000308.686168314.imp@bsdimp.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Cc: Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 17:37:14 -0000 On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: > Sorry to be lame and follow up to my original email, but Ruslan was > way too quick to give me feedback :-) > > I also did a few more of the really easy ones, and added a list of > ones that we haven't implemented yet. > > Comments? How about a question: why are you turning the FreeBSD find into the GNU find? The changes in the first patch looked like they added real functionality that wasn't available in other tools. These seem to be gratuitous changes to make things compatible with GNU. If I want a GNU-compatible find on FreeBSD, I can install the misc/findutils port. If I really wanted the GNU toolset, I could run them on a Linux kernel. However, I'm more comfortable with the Unix toolset (which GNU, as it's own name points out, *isn't*), so the direction taken by these patches make me more than a bit uncomfortable. Hence the question: why are you turning the FreeBSD find into the GNU find? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 18:01:00 2008 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 D3EA616A400 for ; Sat, 23 Feb 2008 18:01:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 828B313C455 for ; Sat, 23 Feb 2008 18:01:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1NI0NoK047376; Sat, 23 Feb 2008 11:00:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 11:00:47 -0700 (MST) Message-Id: <20080223.110047.-397883947.imp@bsdimp.com> To: mwm@mired.org From: "M. Warner Losh" In-Reply-To: <20080223123556.3eee709d@bhuda.mired.org> References: <20080222.225937.-146245356.imp@bsdimp.com> <20080223.000308.686168314.imp@bsdimp.com> <20080223123556.3eee709d@bhuda.mired.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 18:01:00 -0000 In message: <20080223123556.3eee709d@bhuda.mired.org> Mike Meyer writes: : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: : : > Sorry to be lame and follow up to my original email, but Ruslan was : > way too quick to give me feedback :-) : > : > I also did a few more of the really easy ones, and added a list of : > ones that we haven't implemented yet. : > : > Comments? : : How about a question: why are you turning the FreeBSD find into the : GNU find? The changes in the first patch looked like they added real : functionality that wasn't available in other tools. These seem to be : gratuitous changes to make things compatible with GNU. The changes aren't gratuitous. They are well thought out to ensure maximum compatibility. : If I want a GNU-compatible find on FreeBSD, I can install the : misc/findutils port. If I really wanted the GNU toolset, I could run : them on a Linux kernel. However, I'm more comfortable with the Unix : toolset (which GNU, as it's own name points out, *isn't*), so the : direction taken by these patches make me more than a bit : uncomfortable. I looked for a bit last night and couldn't find the gnu find port. It was faster and easier for me to implement the trivial bit of functionality in our find than to try to compile gnu's findutils from scratch. I know, I'm lame because I could find it in the list, so that's a weak excuse. : Hence the question: why are you turning the FreeBSD find into the GNU : find? Because, frankly, I'm getting tired of installing the gnu versions of the tools for trivial reasons. I don't like doing that. Openwrt requires certain features of GNU find. There's no reason why these features shouldn't be present in the base system find. None. It is absolutely silly install a whole other program when our find would need such trivial tweaks to make it work. It is yet another barrier to entry for people converting from Linux to FreeBSD. There's lots of useful scripts that have been written for the embedded world that, sadly, assume more functionality in our tools than are present. They don't always do nice autoconf things to find the right tool to use. The trivial differences between gnu find and our find serve no real purpose. I can dig up numbers for the size difference in the code, but my experience tells me it is less than 1k. This is a lot more efficient than installing gnufind, which must be > 1k in size. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 18:05:45 2008 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 342FD16A404 for ; Sat, 23 Feb 2008 18:05:45 +0000 (UTC) (envelope-from atom@smasher.org) Received: from atom.smasher.org (atom.smasher.org [69.55.237.145]) by mx1.freebsd.org (Postfix) with SMTP id 117F713C45E for ; Sat, 23 Feb 2008 18:05:44 +0000 (UTC) (envelope-from atom@smasher.org) Received: (qmail 7248 invoked by uid 1000); 23 Feb 2008 01:08:56 -0000 Message-ID: <20080223010856.7244.qmail@smasher.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Date: Sat, 23 Feb 2008 14:08:54 +1300 (NZDT) From: Atom Smasher MIME-Version: 1.0 OpenPGP: id=0xB88D52E4D9F57808; algo=1 (RSA); size=4096; url=http://atom.smasher.org/pgp.txt To: hackers@freebsd.org X-POM: The Moon is Waning Gibbous (97% of Full) X-Hashcash: 1:20:0802230108:hackers@freebsd.org::RawPPWZJKxSabc+3:00000000000000 0000000000000000000000000JvY X-Hashcash: 1:20:0802230108:pjd@freebsd.org::HKWc1XAKoJNbBSQY:000000000000000000 0000000000000000000000000CFh Cc: Pawel Jakub Dawidek Subject: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 18:05:45 -0000 article below. does anyone know how this affects eli/geli? from the geli man page: "detach - Detach the given providers, which means remove the devfs entry and clear the keys from memory." does that mean that geli properly wipes keys from RAM when a laptop is turned off? -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring." -- J. Kegler ---------- Forwarded message ---------- Organization: EFF Date: Fri, 22 Feb 2008 13:08:00 -0600 (CST) From: EFFector list Subject: EFFector 21.06: Open Source Advocate, Canadian Copyfighter, and AT&T Whistleblower Win Pioneer Awards * Research Team Finds Security Flaw in Popular Disk Encryption Technologies Laptops in "Sleep" or "Hibernation" Mode Most Vulnerable to Attack San Francisco - A team including the Electronic Frontier Foundation, Princeton University, and other researchers have found a major security flaw in several popular disk encryption technologies that leaves encrypted data vulnerable to attack and exposure. "People trust encryption to protect sensitive data when their computer is out of their immediate control," said EFF Staff Technologist Seth Schoen, a member of the research team. "But this new class of vulnerabilities shows it is not a sure thing. Whether your laptop is stolen, or you simply lose track of it for a few minutes at airport security, the information inside can still be read by a clever attacker." The researchers cracked several widely used disk encryption technologies, including Microsoft's BitLocker, Apple's FileVault, TrueCrypt, and dm-crypt. These "secure" disk encryption systems are supposed to protect sensitive information if a computer is stolen or otherwise accessed. However, in a paper and video published on the Internet today, the researchers show that data is vulnerable because encryption keys and passwords stored in a computer's temporary memory -- or RAM -- do not disappear immediately after losing power. "These types of attacks were often thought to be in the realm of the NSA," said Jacob Appelbaum, an independent computer security researcher and member of the research team. "But we discovered that on most computers, even without power applied for several seconds, data stored in RAM seemed to remain when power was reapplied. We then wrote programs to collect the contents of memory after the computers were rebooted." Laptops are particularly vulnerable to this attack, especially when they are turned on but locked, or in a "sleep" or "hibernation" mode entered when the laptop's cover is shut. Even though the machines require a password to unlock the screen, the encryption keys are already located in the RAM, which provides an opportunity for attackers with malicious intent. The research released today shows that these attacks are likely to be effective against many other disk encryption systems because these technologies have many architectural features in common. Servers with encrypted hard drives are also vulnerable. "We've broken disk encryption products in exactly the case when they seem to be most important these days: laptops that contain sensitive corporate data or personal information about business customers," said J. Alex Halderman, a Ph.D. candidate in Princeton's computer science department. "Unlike many security problems, this isn't a minor flaw; it is a fundamental limitation in the way these systems were designed." In addition to Schoen, Appelbaum, and Halderman, the research team included William Paul of Wind River Systems, and Princeton graduate students Nadia Heninger, William Clarkson, Joseph Calandrino, Ariel Feldman as well as Princeton Professor Edward Felten, the director of the Center for Information Technology Policy and a member of EFF's Board of Directors. The researchers have submitted the paper for publication and it is currently undergoing review. In the meantime, the researchers have contacted the developers of BitLocker, which is included in some versions of Windows Vista, Apple's FileVault, and the open source TrueCrypt and dm-crypt products, to make them aware of the vulnerability. One effective countermeasure is to turn a computer off entirely, though in some cases even this does not provide protection. For the full paper "Lest We Remember: Cold Boot Attacks on Encryption Keys," a demonstration video, and other background information: http://citp.princeton.edu/memory/ For this release: http://www.eff.org/press/archives/2008/02/21-0 ### From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 18:20:55 2008 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 9C9DC16A402 for ; Sat, 23 Feb 2008 18:20:55 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 59F6813C459 for ; Sat, 23 Feb 2008 18:20:55 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 46823 invoked by uid 1001); 23 Feb 2008 18:19:39 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Sat, 23 Feb 2008 13:19:38 -0500 Date: Sat, 23 Feb 2008 13:19:37 -0500 To: freebsd-hackers@freebsd.org Message-ID: <20080223131937.182373b2@bhuda.mired.org> In-Reply-To: <20080223.110047.-397883947.imp@bsdimp.com> References: <20080222.225937.-146245356.imp@bsdimp.com> <20080223.000308.686168314.imp@bsdimp.com> <20080223123556.3eee709d@bhuda.mired.org> <20080223.110047.-397883947.imp@bsdimp.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 18:20:55 -0000 On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" wrote: > In message: <20080223123556.3eee709d@bhuda.mired.org> > Mike Meyer writes: > : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: > : > : > Sorry to be lame and follow up to my original email, but Ruslan was > : > way too quick to give me feedback :-) > : > > : > I also did a few more of the really easy ones, and added a list of > : > ones that we haven't implemented yet. > : > > : > Comments? > : > : How about a question: why are you turning the FreeBSD find into the > : GNU find? The changes in the first patch looked like they added real > : functionality that wasn't available in other tools. These seem to be > : gratuitous changes to make things compatible with GNU. > > The changes aren't gratuitous. They are well thought out to ensure > maximum compatibility. That they add no new functionality, but only exist to make things compatible with GNU are what make them gratuitous to me. > It is yet another barrier to entry for people converting from Linux to > FreeBSD. There's lots of useful scripts that have been written for > the embedded world that, sadly, assume more functionality in our tools > than are present. They don't always do nice autoconf things to find > the right tool to use. The trivial differences between gnu find and > our find serve no real purpose. The problem with this argument is that there are no limits on it, other than the developers definition of "trivial". OS X has already carried this argument to the point that they've replaced /bin/sh with bash. While I understand that it's easier to fix the BSD find, have you tried filing bug reports with patches for the tools that assume GNU find? That would help people outside the BSD community as well. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 18:40:56 2008 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 5B7A616A405 for ; Sat, 23 Feb 2008 18:40:56 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (cl-92.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:5b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBE413C4F6 for ; Sat, 23 Feb 2008 18:40:56 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 9FF5961C3A; Sat, 23 Feb 2008 19:40:54 +0100 (CET) Message-ID: <47C068B5.2090000@thedarkside.nl> Date: Sat, 23 Feb 2008 19:40:53 +0100 From: Pieter de Boer User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: Atom Smasher References: <20080223010856.7244.qmail@smasher.org> In-Reply-To: <20080223010856.7244.qmail@smasher.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 18:40:56 -0000 Atom Smasher wrote: > article below. does anyone know how this affects eli/geli? > > from the geli man page: "detach - Detach the given providers, which > means remove the devfs entry and clear the keys from memory." does that > mean that geli properly wipes keys from RAM when a laptop is turned off? > > The attack you're referencing is carried out by cold rebooting a system. Simply put: pull power cord, insert power cord. The volumes are never detached, as the shutdown sequence is never run. This attack has to be defended against in hardware; it exploits a 'feature' of modern day RAM chips, which can not be controlled by software. Anything that is in RAM when the attack is carried out, will be compromised. As encrypted volumes simply require keys to be in memory to be able to use the volumes, the encryption software is vulnerable to this attack. I see no reason why GELI/GBDE wouldn't be affected. A possible counter-measure would be to add wiping features to the RAM modules themselves. When power is lost, the memory could wipe itself. Still not perfect, but would certainly help. -- Pieter From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 18:56:20 2008 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 9AA3016A401 for ; Sat, 23 Feb 2008 18:56:20 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 973E213C4CC for ; Sat, 23 Feb 2008 18:56:20 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7767C1CC033; Sat, 23 Feb 2008 10:56:20 -0800 (PST) Date: Sat, 23 Feb 2008 10:56:20 -0800 From: Jeremy Chadwick To: Pieter de Boer Message-ID: <20080223185620.GA98105@eos.sc1.parodius.com> References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C068B5.2090000@thedarkside.nl> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: hackers@freebsd.org, Atom Smasher Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 18:56:20 -0000 On Sat, Feb 23, 2008 at 07:40:53PM +0100, Pieter de Boer wrote: > Atom Smasher wrote: >> article below. does anyone know how this affects eli/geli? >> from the geli man page: "detach - Detach the given providers, which means >> remove the devfs entry and clear the keys from memory." does that mean >> that geli properly wipes keys from RAM when a laptop is turned off? > The attack you're referencing is carried out by cold rebooting a system. > Simply put: pull power cord, insert power cord. The volumes are never > detached, as the shutdown sequence is never run. > > This attack has to be defended against in hardware; it exploits a 'feature' > of modern day RAM chips, which can not be controlled by software. Anything > that is in RAM when the attack is carried out, will be compromised. As > encrypted volumes simply require keys to be in memory to be able to use the > volumes, the encryption software is vulnerable to this attack. I see no > reason why GELI/GBDE wouldn't be affected. It's interesting that you classified this as a "feature" (in quotes), because there's nothing "modern" about said "feature". This issue has existed since the beginning of RAM chip engineering; I can even confirm this "feature" exists on old video game consoles such as the Nintendo and Super Nintendo (where there were strict guidelines put in place by Nintendo, requiring developers to initialise certain areas of memory and certain memory-mapped I/O registers during hard or soft resets). > A possible counter-measure would be to add wiping features to the RAM > modules themselves. When power is lost, the memory could wipe itself. Still > not perfect, but would certainly help. Proper software should be memset() or bzero()'ing memory space it mallocs. I've gotten in the habit of doing this for years, purely as a safety net. If said software doesn't do this, it's very likely succeptable. So the OP's question about ELI/GELI stands -- does it properly zero out memory it allocates before using it? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:04:01 2008 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 7703116A407 for ; Sat, 23 Feb 2008 19:04:01 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (cl-92.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:5b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 486B413C4E8 for ; Sat, 23 Feb 2008 19:04:01 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 4B16561C3A for ; Sat, 23 Feb 2008 20:04:00 +0100 (CET) Message-ID: <47C06E1F.5020308@thedarkside.nl> Date: Sat, 23 Feb 2008 20:03:59 +0100 From: Pieter de Boer User-Agent: Thunderbird 2.0.0.6 (X11/20071105) MIME-Version: 1.0 To: hackers@freebsd.org References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com> In-Reply-To: <20080223185620.GA98105@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 19:04:01 -0000 Jeremy Chadwick wrote: > It's interesting that you classified this as a "feature" (in quotes), > because there's nothing "modern" about said "feature". This issue has > existed since the beginning of RAM chip engineering; I can even confirm > this "feature" exists on old video game consoles such as the Nintendo > and Super Nintendo (where there were strict guidelines put in place by > Nintendo, requiring developers to initialise certain areas of memory > and certain memory-mapped I/O registers during hard or soft resets). I shouldnt've used the word 'modern', then. > Proper software should be memset() or bzero()'ing memory space it > mallocs. I've gotten in the habit of doing this for years, purely as a > safety net. If said software doesn't do this, it's very likely > succeptable. That is not relevant to the issue. The issue is that the keys are in memory when the encrypted filesystem is in use. The keys can be read by pulling and reinserting the power plug and restarting into a tool that can dump memory (or by placing the memory modules in another system). The keys to encrypted volumes can be found in this dump, leading to a compromise of the data. -- Pieter From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:07:16 2008 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 E378216A401 for ; Sat, 23 Feb 2008 19:07:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A049113C468 for ; Sat, 23 Feb 2008 19:07:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1NJ5l6h048259; Sat, 23 Feb 2008 12:05:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 12:05:46 -0700 (MST) Message-Id: <20080223.120546.74701383.imp@bsdimp.com> To: mwm-keyword-freebsdhackers2.e313df@mired.org From: Warner Losh In-Reply-To: <20080223131937.182373b2@bhuda.mired.org> References: <20080223123556.3eee709d@bhuda.mired.org> <20080223.110047.-397883947.imp@bsdimp.com> <20080223131937.182373b2@bhuda.mired.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 19:07:17 -0000 From: Mike Meyer Subject: Re: find -lname and -ilname implemented Date: Sat, 23 Feb 2008 13:19:37 -0500 > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" wrote: > > > In message: <20080223123556.3eee709d@bhuda.mired.org> > > Mike Meyer writes: > > : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: > > : > > : > Sorry to be lame and follow up to my original email, but Ruslan was > > : > way too quick to give me feedback :-) > > : > > > : > I also did a few more of the really easy ones, and added a list of > > : > ones that we haven't implemented yet. > > : > > > : > Comments? > > : > > : How about a question: why are you turning the FreeBSD find into the > > : GNU find? The changes in the first patch looked like they added real > > : functionality that wasn't available in other tools. These seem to be > > : gratuitous changes to make things compatible with GNU. > > > > The changes aren't gratuitous. They are well thought out to ensure > > maximum compatibility. > > That they add no new functionality, but only exist to make things > compatible with GNU are what make them gratuitous to me. It adds functionality. That doesn't make it gratuitous. One might just as well call 'POSIX' compatibility gratuitous. Like it or not, the GNU utilities represent a de-facto standard that we must conform to. > > It is yet another barrier to entry for people converting from Linux to > > FreeBSD. There's lots of useful scripts that have been written for > > the embedded world that, sadly, assume more functionality in our tools > > than are present. They don't always do nice autoconf things to find > > the right tool to use. The trivial differences between gnu find and > > our find serve no real purpose. > > The problem with this argument is that there are no limits on it, > other than the developers definition of "trivial". OS X has already > carried this argument to the point that they've replaced /bin/sh with > bash. Don't be rediculous. I added 1k of extra space to an existing utility. That was part of the calculous in my making the changes I did. Or course, we may need to adopt features from bash into our /bin/sh as time marches forward. This is no different from what the project has always done. There's nothing new that I've done. Reviewing all the utilities one will find where people have added features or enhanced compatibility with other gnu tools. Don't make me quote all the cvs log entries to prove this point (but I will if you don't believe me). > While I understand that it's easier to fix the BSD find, have you > tried filing bug reports with patches for the tools that assume GNU > find? That would help people outside the BSD community as well. Like spitting in the ocean. There's a bunch of different such tools and it is a better investment of my time and everybody else's time to make FreeBSD's find work better in these environments rather than trying to fix all the places that use it. I'm also not sure that the maintainers would buy the argument you are making here. People outside the BSD community generally use gnu tools. The percentage of people using other Unicies is small, and typically they don't have source to rebuild (Solaris/OpenSolaris is one exception I can think of). In short, I'm continuig the long tradition that we've done as FreeBSD and that BSD and other Unix vendors did before us: compatibility with other implementations. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:32:13 2008 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 0A13316A403 for ; Sat, 23 Feb 2008 19:32:13 +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 BE52313C465 for ; Sat, 23 Feb 2008 19:32:12 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=bN/FT+JCr8qIRQ0Wl/jndxXgI0+MsrMM5y4qlj6lZh6/ZAK+mLgeHMj9YL46Ft71O2d5m65ZIQU7lpKtiT0zwrlUO+gokyUzIfpD4H1Gd8IqhY8lH2Es/QZws75Gkm73tn1csnfil3EsY4kR7xyn5PSp96DyLG0AhQyICkZ4YXE=; Received: from amnesiac.at.no.dns (ppp83-237-104-147.pppoe.mtu-net.ru [83.237.104.147]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JT06U-000CbL-9i; Sat, 23 Feb 2008 22:32:10 +0300 Date: Sat, 23 Feb 2008 22:32:02 +0300 From: Eygene Ryabinkin To: Jeremy Chadwick Message-ID: References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080223185620.GA98105@eos.sc1.parodius.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: hackers@freebsd.org, Pieter de Boer , Atom Smasher Subject: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies] 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, 23 Feb 2008 19:32:13 -0000 Jeremy, list, good day. Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote: > > A possible counter-measure would be to add wiping features to the RAM > > modules themselves. When power is lost, the memory could wipe itself. Still > > not perfect, but would certainly help. > > Proper software should be memset() or bzero()'ing memory space it > mallocs. I've gotten in the habit of doing this for years, purely as a > safety net. If said software doesn't do this, it's very likely > succeptable. > > So the OP's question about ELI/GELI stands -- does it properly zero out > memory it allocates before using it? Excuse me, but I think that you're confusing two things: zeroing or, generally, initializing memory before the first use (it what is you're talking about) and sanitizing sensitive data like passwords and keys after they were used (it is what OP was talking about). The answer to the original question: yes, geli module cleans all keys and passphrases after use with bzero(). As it was mentioned, this will not help you, if you have your geli-encrypted partition mounted and someone performs the attack by replugging the power and dumping the memory image. But there is another concern with bzero(): it is well-known function. Especially for compilers. And it is bad: some arrays inside g_eli, that hold decryption keys are the local variables. And they are not used after the final bzero() call, so optimizing compiler can eliminate the bzero() completely, as the "not relevant". I don't know if GCC does it -- I should check and will do this tomorrow, because it is already too late in Russia for this day ;)) For example, OpenSSL has the OPENSSL_cleanse() function whose purpose is two-fold (from http://cvs.openssl.org/chngview?cn=9301): ----- *) New function OPENSSL_cleanse(), which is used to cleanse a section of memory from it's contents. This is done with a counter that will place alternating values in each byte. This can be used to solve two issues: 1) the removal of calls to memset() by highly optimizing compilers, and 2) cleansing with other values than 0, since those can be read through on certain media, for example a swap space on disk. [Geoff Thorpe] ----- The '1)' is what I was talking about. '2)' is not very clear to me now, I should research what Geoff meant. If anyone has an idea, please comment. May be the crypto(4,9) framework should receive the function, that will be simular to the OPENSSL_cleanse. And that function should be used for wiping of the sensitive data. Will try to post an update once it will be more clear to me. -- Eygene From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:40:29 2008 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 1054916A40D for ; Sat, 23 Feb 2008 19:40:29 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 873FF13C459 for ; Sat, 23 Feb 2008 19:40:28 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1NJOSZT019571; Sat, 23 Feb 2008 21:24:28 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1NJORs0004001; Sat, 23 Feb 2008 21:24:27 +0200 Received: from [192.168.136.22] ([62.1.173.114]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1NJOPfw015723; Sat, 23 Feb 2008 21:24:27 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=dds@FreeBSD.org; spf=permerror Authentication-Results: MX-IN-05.forthnet.gr header.from=dds@FreeBSD.org; sender-id=permerror Message-ID: <47C072E9.9020900@FreeBSD.org> Date: Sat, 23 Feb 2008 21:24:25 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Pieter de Boer References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> In-Reply-To: <47C068B5.2090000@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, Atom Smasher Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 19:40:29 -0000 Pieter de Boer wrote: > Atom Smasher wrote: >> article below. does anyone know how this affects eli/geli? >> >> from the geli man page: "detach - Detach the given providers, which >> means remove the devfs entry and clear the keys from memory." does >> that mean that geli properly wipes keys from RAM when a laptop is >> turned off? >> >> > The attack you're referencing is carried out by cold rebooting a system. > Simply put: pull power cord, insert power cord. The volumes are never > detached, as the shutdown sequence is never run. > > This attack has to be defended against in hardware; it exploits a > 'feature' of modern day RAM chips, which can not be controlled by > software. Anything that is in RAM when the attack is carried out, will > be compromised. As encrypted volumes simply require keys to be in memory > to be able to use the volumes, the encryption software is vulnerable to > this attack. I see no reason why GELI/GBDE wouldn't be affected. > > A possible counter-measure would be to add wiping features to the RAM > modules themselves. When power is lost, the memory could wipe itself. > Still not perfect, but would certainly help. > There are (at least) two attack methods. One is indeed based on memory chips that retain their data after a shutdown, and software can't easily protect against this attack. The only way I can think would be to reserve a processor register for storing the encryption key. However, a second attack method is based on rebooting a hibernated machine with a different operating system and retrieving the encryption keys from the hybernation dump. One can protect against this attack by having the hybernation sequence unmount the encrypted filesystems and wipe out the keys from memory. Diomidis Spinellis - http://www.spinellis.gr From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:51:03 2008 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 920CA16A411 for ; Sat, 23 Feb 2008 19:51:03 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: from web50306.mail.re2.yahoo.com (web50306.mail.re2.yahoo.com [206.190.38.60]) by mx1.freebsd.org (Postfix) with SMTP id 536A913C4E7 for ; Sat, 23 Feb 2008 19:51:03 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: (qmail 88679 invoked by uid 60001); 23 Feb 2008 19:24:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=S8Y4yR/ysLZUiYJkNQFKItRoQfB9r8jzMuH/chXXe/634rMDKJjzOG45abpQhPpvFQkSne72zM0/OhsnXBHf2deTgXS/OxhZb+cIqNmkqj4yTLyeGosWKxUeuR3J5F1gVnc9npZhMuT2eiIKYxVZH+R/WoDBgT5vi0K0hlofcW8=; X-YMail-OSG: ax_K7jsVM1kPVv_pav4TOPkMivxF7QDoa7kcjd9RPQJkKwXFqUqtySWB7yVHAVEoaQ-- Received: from [210.215.149.194] by web50306.mail.re2.yahoo.com via HTTP; Sat, 23 Feb 2008 11:24:22 PST Date: Sat, 23 Feb 2008 11:24:22 -0800 (PST) From: Tim Clewlow To: hackers@freebsd.org In-Reply-To: <47C06E1F.5020308@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <760775.85636.qm@web50306.mail.re2.yahoo.com> Cc: Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 19:51:03 -0000 --- Pieter de Boer wrote: > Jeremy Chadwick wrote: > > > It's interesting that you classified this as a "feature" (in quotes), > > because there's nothing "modern" about said "feature". This issue has > > existed since the beginning of RAM chip engineering; I can even confirm > > this "feature" exists on old video game consoles such as the Nintendo > > and Super Nintendo (where there were strict guidelines put in place by > > Nintendo, requiring developers to initialise certain areas of memory > > and certain memory-mapped I/O registers during hard or soft resets). > I shouldnt've used the word 'modern', then. > > > Proper software should be memset() or bzero()'ing memory space it > > mallocs. I've gotten in the habit of doing this for years, purely as a > > safety net. If said software doesn't do this, it's very likely > > succeptable. > That is not relevant to the issue. The issue is that the keys are in > memory when the encrypted filesystem is in use. The keys can be read by > pulling and reinserting the power plug and restarting into a tool that > can dump memory (or by placing the memory modules in another system). > The keys to encrypted volumes can be found in this dump, leading to a > compromise of the data. Many BIOS have fast and slow boot options - they are usually set to fast by default. The slow boot option often checks RAM and effectively wipes RAM in the process. If the BIOS is password protected then the only way to break in is to reset the BIOS by removing the BIOS battery. Given that RAM degrades over a short period of no power, and that arranging to physically pull the BIOS battery most likely exceeds that time limit, then this would effectively be one solution. Although it will mean always booting the slow way. Tim. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:53:05 2008 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 ED59F16A40B for ; Sat, 23 Feb 2008 19:53:05 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id EA0B813C478 for ; Sat, 23 Feb 2008 19:53:05 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id BEF601CC038; Sat, 23 Feb 2008 11:53:05 -0800 (PST) Date: Sat, 23 Feb 2008 11:53:05 -0800 From: Jeremy Chadwick To: Eygene Ryabinkin Message-ID: <20080223195305.GA99738@eos.sc1.parodius.com> References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Cc: hackers@freebsd.org, Pieter de Boer , Atom Smasher Subject: Re: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies] 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, 23 Feb 2008 19:53:06 -0000 On Sat, Feb 23, 2008 at 10:32:02PM +0300, Eygene Ryabinkin wrote: > Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote: > > > A possible counter-measure would be to add wiping features to the RAM > > > modules themselves. When power is lost, the memory could wipe itself. Still > > > not perfect, but would certainly help. > > > > Proper software should be memset() or bzero()'ing memory space it > > mallocs. I've gotten in the habit of doing this for years, purely as a > > safety net. If said software doesn't do this, it's very likely > > succeptable. > > > > So the OP's question about ELI/GELI stands -- does it properly zero out > > memory it allocates before using it? > > Excuse me, but I think that you're confusing two things: zeroing > or, generally, initializing memory before the first use (it what > is you're talking about) and sanitizing sensitive data like passwords > and keys after they were used (it is what OP was talking about). Yep, you're quite right -- I am/was definitely confusing the two. As far as the secondary option goes, I suppose that's also up to software to address, but honestly I have no real idea how one would do that. Cryptography and overall "data sanitisation" (to ensure security) are significantly over my head. Thanks for correcting me, though! Always good to learn something. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 20:33:18 2008 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 048A516A400 for ; Sat, 23 Feb 2008 20:33:18 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D60113C4E8 for ; Sat, 23 Feb 2008 20:33:17 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1NKXG03039561; Sat, 23 Feb 2008 14:33:16 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1NKXGsh039560; Sat, 23 Feb 2008 14:33:16 -0600 (CST) (envelope-from brooks) Date: Sat, 23 Feb 2008 14:33:16 -0600 From: Brooks Davis To: Tim Clewlow Message-ID: <20080223203316.GC38485@lor.one-eyed-alien.net> References: <47C06E1F.5020308@thedarkside.nl> <760775.85636.qm@web50306.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <760775.85636.qm@web50306.mail.re2.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sat, 23 Feb 2008 14:33:16 -0600 (CST) Cc: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 20:33:18 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 11:24:22AM -0800, Tim Clewlow wrote: >=20 > --- Pieter de Boer wrote: >=20 > > Jeremy Chadwick wrote: > >=20 > > > It's interesting that you classified this as a "feature" (in quotes), > > > because there's nothing "modern" about said "feature". This issue has > > > existed since the beginning of RAM chip engineering; I can even confi= rm > > > this "feature" exists on old video game consoles such as the Nintendo > > > and Super Nintendo (where there were strict guidelines put in place by > > > Nintendo, requiring developers to initialise certain areas of memory > > > and certain memory-mapped I/O registers during hard or soft resets). > > I shouldnt've used the word 'modern', then. > >=20 > > > Proper software should be memset() or bzero()'ing memory space it > > > mallocs. I've gotten in the habit of doing this for years, purely as= a > > > safety net. If said software doesn't do this, it's very likely > > > succeptable. > > That is not relevant to the issue. The issue is that the keys are in=20 > > memory when the encrypted filesystem is in use. The keys can be read by= =20 > > pulling and reinserting the power plug and restarting into a tool that= =20 > > can dump memory (or by placing the memory modules in another system).= =20 > > The keys to encrypted volumes can be found in this dump, leading to a= =20 > > compromise of the data. >=20 > Many BIOS have fast and slow boot options - they are usually set to fast = by > default. The slow boot option often checks RAM and effectively wipes RAM = in the > process. If the BIOS is password protected then the only way to break in = is to > reset the BIOS by removing the BIOS battery. Given that RAM degrades over= a > short period of no power, and that arranging to physically pull the BIOS > battery most likely exceeds that time limit, then this would effectively = be one > solution. Although it will mean always booting the slow way. You should actually read the paper. :) They successfully defeat both of these type of protections by using canned air to chill the ram and transplanting it into another machine. -- Brooks --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHwIMLXY6L6fI4GtQRApg1AJ9hyAz37r85t4gy1rGjq1LR/m8jvQCdGzjv AVwa5cDFYE5Gq0EWkYMJOgM= =Gwfr -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 20:55:13 2008 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 4FC5716A405 for ; Sat, 23 Feb 2008 20:55:13 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id F058913C468 for ; Sat, 23 Feb 2008 20:55:12 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 52191 invoked by uid 1001); 23 Feb 2008 20:53:56 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Sat, 23 Feb 2008 15:53:55 -0500 Date: Sat, 23 Feb 2008 15:53:55 -0500 To: freebsd-hackers@freebsd.org Message-ID: <20080223155355.3f80b77f@bhuda.mired.org> In-Reply-To: <20080223.120546.74701383.imp@bsdimp.com> References: <20080223123556.3eee709d@bhuda.mired.org> <20080223.110047.-397883947.imp@bsdimp.com> <20080223131937.182373b2@bhuda.mired.org> <20080223.120546.74701383.imp@bsdimp.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 20:55:13 -0000 On Sat, 23 Feb 2008 12:05:46 -0700 (MST) Warner Losh wrote: > From: Mike Meyer > > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" wrote: > > > > > In message: <20080223123556.3eee709d@bhuda.mired.org> > > > Mike Meyer writes: > > > : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: > > > : > > > : > Sorry to be lame and follow up to my original email, but Ruslan was > > > : > way too quick to give me feedback :-) > > > : > > > > : > I also did a few more of the really easy ones, and added a list of > > > : > ones that we haven't implemented yet. > > > : > > > > : > Comments? > > > : > > > : How about a question: why are you turning the FreeBSD find into the > > > : GNU find? The changes in the first patch looked like they added real > > > : functionality that wasn't available in other tools. These seem to be > > > : gratuitous changes to make things compatible with GNU. > > > > > > The changes aren't gratuitous. They are well thought out to ensure > > > maximum compatibility. > > > > That they add no new functionality, but only exist to make things > > compatible with GNU are what make them gratuitous to me. > It adds functionality. That doesn't make it gratuitous. One might > just as well call 'POSIX' compatibility gratuitous. Like it or not, > the GNU utilities represent a de-facto standard that we must conform > to. POSIX is a well-defined standard, endorsed by a large number of companies. GNU's just a bag of programs which only have one commonality as far as I can tell: the software license. There's another de-facto standard from a company in Redmond, that's *much* more popular than GNU, and probably more consistent. If FreeBSD is going to conform to implementations instead of standards, I'd rather it conform to that one than GNU. > > > It is yet another barrier to entry for people converting from Linux to > > > FreeBSD. There's lots of useful scripts that have been written for > > > the embedded world that, sadly, assume more functionality in our tools > > > than are present. They don't always do nice autoconf things to find > > > the right tool to use. The trivial differences between gnu find and > > > our find serve no real purpose. > > > > The problem with this argument is that there are no limits on it, > > other than the developers definition of "trivial". OS X has already > > carried this argument to the point that they've replaced /bin/sh with > > bash. > > Don't be rediculous. I added 1k of extra space to an existing > utility. That was part of the calculous in my making the changes I > did. What's ridiculous? That the only limit is the developers definition of "trivial"? Care to provide another one? That OS X turned /bin/sh into bash? I'd agree that that's ridiculous, except it's a fact. That they did it to make OS X more compatible with Linux? Would you like me to try and dig up the mail from jkh (I'm pretty sure it was him) that says that's why they did it? > Or course, we may need to adopt features from bash into our /bin/sh as > time marches forward. > > This is no different from what the project has always done. There's > nothing new that I've done. Reviewing all the utilities one will find > where people have added features or enhanced compatibility with other > gnu tools. I believe you. If you're going to add a feature, accessing it the same way as GNU does makes some sense (providing GNU's not completely broken, anyway). And I'm sure there are cases where things were tweaked just to make them more compatible, because there's constant pressure to do so, even if the changes in question add nothing but bloat to the system. > In short, I'm continuig the long tradition that we've done as FreeBSD > and that BSD and other Unix vendors did before us: compatibility with > other implementations. I suspect your definition of "long tradition" is a lot shorter than mine. That's they only way I can make that statement make sense - at least the part about BSD and other Unix vendors. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:22:40 2008 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 E30AF16A410 for ; Sat, 23 Feb 2008 21:22:40 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from hermes.hst.org.za (onix.hst.org.za [209.203.2.133]) by mx1.freebsd.org (Postfix) with ESMTP id AFA6613C538 for ; Sat, 23 Feb 2008 21:22:38 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from [10.1.11.1] ([10.1.11.1]) (authenticated bits=0) by hermes.hst.org.za (8.13.8/8.13.8) with ESMTP id m1NLEMn3058803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Feb 2008 23:14:23 +0200 (SAST) (envelope-from jonathan+freebsd-hackers@hst.org.za) From: Jonathan McKeown To: freebsd-hackers@freebsd.org Date: Sat, 23 Feb 2008 23:22:45 +0200 User-Agent: KMail/1.9.4 X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Spam-Score: -4.399 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.61 on 209.203.2.133 Subject: find -lname and -ilname implemented 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, 23 Feb 2008 21:22:41 -0000 [Sorry to break threading - I deleted the thread before deciding to respond. I can see both sides of this discussion, but I did want to add some hopefully thought-provoking comments late on a Saturday night]. [M Warner Losh] > From: Mike Meyer > Subject: Re: find -lname and -ilname implemented > Date: Sat, 23 Feb 2008 13:19:37 -0500 > > > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" wrote: > > > In message: <20080223123556.3eee709d at bhuda.mired.org> > > > > > > Mike Meyer writes: > > > : How about a question: why are you turning the FreeBSD find into the > > > : GNU find? The changes in the first patch looked like they added real > > > : functionality that wasn't available in other tools. These seem to be > > > : gratuitous changes to make things compatible with GNU. > > > > > > The changes aren't gratuitous. They are well thought out to ensure > > > maximum compatibility. > > > > That they add no new functionality, but only exist to make things > > compatible with GNU are what make them gratuitous to me. > > It adds functionality. > What functionality does find path -lname name add that isn't already available from find path -name name -type l and what other combinations should be special-cased like this? > That doesn't make it gratuitous. One might > just as well call 'POSIX' compatibility gratuitous. Like it or not, > the GNU utilities represent a de-facto standard that we must conform > to. So what we're saying is that the Linux community is now as arrogant as Microsoft? I don't much like the suggestion that everyone must conform to the GNU utilities because GNU/Linux has a dominant position, whether what they do makes sense or not, or whether or not it complies with published standards. In particular, I think comparing a documented standard from a professional body with ``use and custom'' in one particular developer community is specious. At the very least, when patching the manpage, you could point out that this is a (potentially non-portable) GNU extension - in the same way that every other extension to the POSIX standard is noted. > > > It is yet another barrier to entry for people converting from Linux to > > > FreeBSD. I keep seeing this argument or variations of it. Yes, different Unix-like OSes do things slightly differently. As far as I can see (and I used Linux exclusively for as long as I have now been a FreeBSD user, and may well use it again in future), the major ``barrier to entry'' is the Linux mindset that the Linux way is the only way. In many ways, the sooner a Linux convert is forced to face that assumption and overcome it, the better for them. Of course, if we're in some sort of religious war for converts, perhaps we should change the default configuration of ssh to match the Linux distros on which remote root access is enabled by default; do away with the wheel group and let anyone su to root; install sudo by default instead of having a root password; and so on, and so on, and so on... > > > There's lots of useful scripts that have been written for > > > the embedded world that, sadly, assume more functionality in our tools > > > than are present. They don't always do nice autoconf things to find > > > the right tool to use. The trivial differences between gnu find and > > > our find serve no real purpose. So if a script is non-portable because the developer doesn't know any better, every OS it might be run on should change itself to match the developer's faulty expectations, rather than someone pointing the developer to a resource on portable scripting? > > The problem with this argument is that there are no limits on it, > > other than the developers definition of "trivial". OS X has already > > carried this argument to the point that they've replaced /bin/sh with > > bash. > > Don't be rediculous. I added 1k of extra space to an existing > utility. That was part of the calculous in my making the changes I > did. > > Or course, we may need to adopt features from bash into our /bin/sh as > time marches forward. Oh goody. Don't get me wrong - I use bash as my user shell; but my scripts tend to start off #!/bin/sh. On my system /usr/local/bin/bash is 6 times the size of /bin/sh, not to mention the insane list of dependencies. The suggestion that we will have to incorporate some of that complexity into /bin/sh, again in order to meet the expectations of Linux users who don't know, and can't be bothered to find out, that there are shells other than bash, and standards other than GNU/Linux, fills me with horror. > This is no different from what the project has always done. There's > nothing new that I've done. Reviewing all the utilities one will find > where people have added features or enhanced compatibility with other > gnu tools. Don't make me quote all the cvs log entries to prove this > point (but I will if you don't believe me). > > > While I understand that it's easier to fix the BSD find, have you > > tried filing bug reports with patches for the tools that assume GNU > > find? That would help people outside the BSD community as well. > > Like spitting in the ocean. There's a bunch of different such tools > and it is a better investment of my time and everybody else's time to > make FreeBSD's find work better in these environments rather than > trying to fix all the places that use it. > > I'm also not sure that the maintainers would buy the argument you are > making here. People outside the BSD community generally use gnu > tools. The percentage of people using other Unicies is small, and > typically they don't have source to rebuild (Solaris/OpenSolaris is > one exception I can think of). > > In short, I'm continuig the long tradition that we've done as FreeBSD > and that BSD and other Unix vendors did before us: compatibility with > other implementations. Yes, where it makes sense. I'm not at all convinced that this change makes as much sense as you obviously think it does - especially given that it doesn't add previously unavailable functionality, and that we have a ports system which includes a patch stage for dealing with this sort of gratuitous non-portability in ported applications. Jonathan From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:46:26 2008 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 5FE3016A403 for ; Sat, 23 Feb 2008 21:46:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 64C8513C43E for ; Sat, 23 Feb 2008 21:46:25 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m1NLkNpP089427; Sat, 23 Feb 2008 22:46:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m1NLkMNR089426; Sat, 23 Feb 2008 22:46:22 +0100 (CET) (envelope-from olli) Date: Sat, 23 Feb 2008 22:46:22 +0100 (CET) Message-Id: <200802232146.m1NLkMNR089426@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xcllnt@mac.com In-Reply-To: <073CCEB2-3124-4631-A034-6A23544A6177@mac.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Sat, 23 Feb 2008 22:46:24 +0100 (CET) Cc: Subject: Re: /boot/loader graphics support & extensibility 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, 23 Feb 2008 21:46:26 -0000 Marcel Moolenaar wrote: > On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote: > > Yes, that'll work well for putting characters on the > > screen. But I don't think it is suitable for generic > > graphics operations, even (and especially) for drawing > > single pixels. > > True. What do you envision? How generic do you think > we should make it? > > For me the difference between an abstraction solely > based on bitblt and an abstraction that includes a > couple more primitives is minimal. The key aspect is > that we should not have to duplicate 1000 lines of > code, of which less than 10% deals with the hardware. > This, for example, is a problem with syscons and the > keyboard- and video switch interfaces. The keyboard > switch interface alone has 18 functions???? That's a > bad abstraction, nothing else. Yes, I'm aware of the problem. All the screenshots that I've made so far use only three functions: Displaying PCX images, printing characters, and drawing filled rectangles (e.g. to clear the screen or parts of it). That's not really much. I'm inclined to implement specialized versions of these functions for each of the bitmap formats, which is currently just two: 4bit planar (16 colors) and 8bit linear (256 colors). Currently I also have implemented several other functions such as line drawing, filled triangles, circles etc., but I'm not sure if it's worth keeping them. I'll have to think about it a bit more. At the moment I don't plan to support modes with more than 8 bits (but of course if someone else wants to do it, that would be fine with me). Typically you can dither truecolor images to 8 bit at very good quality (with gimp, imagemagick, netpbm, whatever), so there's no need for hicolor or truecolor modes. It should also be pointed out that there are a lot of variants of bitmap formats, and different graphics hardware supports different subset of these: 15 bit hicolor (5-5-5), 16 bit hicolor (5-6-5), 24 bit truecolor, 32 bit true- color, and each of these with different component orders (RGB or BGR), resulting in at least eight different formats. You have to support them all, which is somewhat complicated (although not difficult). The situation might be completely different on non-VGA hardware, of course. > > I'm sorry, I should have been clearer, that gfx_rect() > > function draws a filled rectangle. > > I see. In that case it's a single bitblt operation :-) But how would it work in reality? I guess you have something like this in mind; please correct me if I'm wrong: - The Forth code calls the rectangle function. - The hardware-independend gfx_rect function allocates a sufficiently large temporary memory buffer, then draws the rectangle into it. - Then it calls the hardware-dependent bitblt function, which copies the contents from the temporary buffer to the graphics frame buffer. There are two problems that I can see with that approach (not mentioning performance): First, what will be the bitmap format of the temporary memory buffer? The first possibility would be to make it the same as the graphics frame buffer, so the bitblt function would just have to shovel bits (except that it might have to shift bits if the buffer's contents don't happen to have the right alignment already). But then we need multiple rectangle functions, one for every bitmap format supported, so the abstraction doesn't really buy us much. The second possibility is to make the temporary buffer independent from the bitmap format of the graphics mode, i.e. use a fixed format. In order to be able to support truecolor modes, that fixed format would have to be a truecolor format, too. So then the rectangle function would draw a 24bit or 32bit truecolor rectangle (even if the graphics mode is only 4 bit), and the bitblt function would have to convert it back to the actual bitmap format of the graphics mode, possibly having to do palette lookups. That is horribly inefficient, and there's no easy way for optimizations. The second problem is that some graphics functions need to work with masks. For example, the function that prints a character is supposed to overlay the background, i.e. _not_ clear the rectangular area that the character occupies (this is to allow things such as ligatures, accent characters, shadow, bold and outline effects etc). So the bitblt function would have to take two input bitmaps (one being the pixel source and one being the mask) and perform the neccessary logical operations, in addition to the shifting (which also applies to the mask), format conversion, palette lookup, ... Sure, all of that could be implemented, but I fear that it would be much more complicated and bloated in the end. The current rectangle function for 4bit planar modes is about 15 lines of C code (not counting comments). The PCX display function is basically a straight-forward loop of about 20 lines of C code. That's not really a huge amount. And I have to confess that I don't think it's too bad that I'll have to write another 15 lines for an 8bit rectangle function, and another 20 lines for the 8bit PCX display loop. Probably less, because the 8bit linear modes are much simpler than the 4bit planar modes. On the other hand, writing bitblt functions that do all of the things that I explained above would cost several hundred lines of code. And in the end it would be slower by an order of magnitude. These are just my thoughts. I certainly don't want to dismiss the idea of bitblt completely, but I think the disadvantages outweigh the benefits in this case. > Agreed. Be aware of making the mistake to separate and > distinguish between variations of a single operation at > too high a level. Yes, I know what you mean. I try to keep it in mind. > For example: it's much more costly to > separate vertical line drawing from horizontal line > drawing from any other kind of line drawing at the MI > layer, than it is at the hardware level. The hardware > level needs to check the parameters anyway and unless > there's hardware acceleration it'll perform separate > code paths most of the time. The upshot of a single line > drawing primitive is that you don't have to worry about > the coordinates and which API function you must call. > This is important when the coordinates are parameters > to some function and you'll find yourself coding like: > > if (isvertical(x1,y1,x2,y2)) > drawline_vertical(...) > elif (ishorizontal(x1,y1,x2,y2)) > drawline_horizontal(...) > else > drawline_generic(...) > > With hardware acceleration you may not have to care at > all and when you need to draw the line in software, > you need to test the coordinates anyway and split the > work based on angle even. In that case you also split > horizontal and vertical. I do have a generic line drawing function (using the well-known Bresenham algorithm) as well as specialized functions for vertical and horizontal lines. However, there is no code like the one above. The hline and vline functions are rather intended to be used for cases where the Forth programmer knows in advance that the line will be horizontal or vertical, e.g. when underlining a word, drawing a frame and similar things. For random lines the generic line function should be used, even if the line happens to be vertical or horizontal. It's not worth making a distinction for that case. > Anyway: that's enough out of me. I think what you're > doing is great and I can't wait to see it realized... Thank you very much for taking part in this discussion, it helps a lot. I even learned a little bit about EFI. :) My next steps: - Find a spare box and install 8-current (so far I'm using RELENG_7 for development and testing). - Continue cleaning up and committing to Perforce. - If I have something that works, I'll prepare diffs for review and a tarball for people to test and play. Beware, I'm not working full-time of this, so it might take a little while (I have a full-time job, a wife, other hobbies, so my time is a bit limited). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:49:15 2008 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 B689F16A404 for ; Sat, 23 Feb 2008 21:49:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E10F13C458 for ; Sat, 23 Feb 2008 21:49:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1NLnE0e040544; Sat, 23 Feb 2008 15:49:14 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1NLnDmX040543; Sat, 23 Feb 2008 15:49:13 -0600 (CST) (envelope-from brooks) Date: Sat, 23 Feb 2008 15:49:13 -0600 From: Brooks Davis To: Mike Meyer Message-ID: <20080223214913.GE39699@lor.one-eyed-alien.net> References: <20080222.225937.-146245356.imp@bsdimp.com> <20080223.000308.686168314.imp@bsdimp.com> <20080223123556.3eee709d@bhuda.mired.org> <20080223.110047.-397883947.imp@bsdimp.com> <20080223131937.182373b2@bhuda.mired.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EXKGNeO8l0xGFBjy" Content-Disposition: inline In-Reply-To: <20080223131937.182373b2@bhuda.mired.org> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sat, 23 Feb 2008 15:49:14 -0600 (CST) Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 21:49:15 -0000 --EXKGNeO8l0xGFBjy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 01:19:37PM -0500, Mike Meyer wrote: > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" wrote: >=20 > > In message: <20080223123556.3eee709d@bhuda.mired.org> > > Mike Meyer writes: > > : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" wrote: > > :=20 > > : > Sorry to be lame and follow up to my original email, but Ruslan was > > : > way too quick to give me feedback :-) > > : >=20 > > : > I also did a few more of the really easy ones, and added a list of > > : > ones that we haven't implemented yet. > > : >=20 > > : > Comments? > > :=20 > > : How about a question: why are you turning the FreeBSD find into the > > : GNU find? The changes in the first patch looked like they added real > > : functionality that wasn't available in other tools. These seem to be > > : gratuitous changes to make things compatible with GNU. > >=20 > > The changes aren't gratuitous. They are well thought out to ensure > > maximum compatibility. >=20 > That they add no new functionality, but only exist to make things > compatible with GNU are what make them gratuitous to me. >=20 > > It is yet another barrier to entry for people converting from Linux to > > FreeBSD. There's lots of useful scripts that have been written for > > the embedded world that, sadly, assume more functionality in our tools > > than are present. They don't always do nice autoconf things to find > > the right tool to use. The trivial differences between gnu find and > > our find serve no real purpose. >=20 > The problem with this argument is that there are no limits on it, > other than the developers definition of "trivial". OS X has already > carried this argument to the point that they've replaced /bin/sh with > bash. >=20 > While I understand that it's easier to fix the BSD find, have you > tried filing bug reports with patches for the tools that assume GNU > find? That would help people outside the BSD community as well. I think you may underestimate the value of compatibility. For example, I think a lot of the successes bsdtar is having are due to the fact that it's as much of a dropin replacement for gnutar is possible. If we want to increase our market share one of the ways we can do it is to make things easier for people who are interested in adopting our technologies for what ever reason. If we can spend a few KB here and there to make their transition easier, I think it's well worth it. -- Brooks --EXKGNeO8l0xGFBjy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHwJTZXY6L6fI4GtQRAhGyAKDiwBJqpq5Rxn6uvdTxVomg/AxAjQCfbht1 2nIq6/eJFEuh/2Tsm0mn8m8= =+2qK -----END PGP SIGNATURE----- --EXKGNeO8l0xGFBjy-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:57:03 2008 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 97D5C16A400 for ; Sat, 23 Feb 2008 21:57:03 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id CDC4213C44B for ; Sat, 23 Feb 2008 21:57:02 +0000 (UTC) (envelope-from mozolevsky@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so284791uge.37 for ; Sat, 23 Feb 2008 13:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=FWk1PVRycHeadssfCosns6VNQeo/FK98VtPgpGHyeOE=; b=VDLlufCh+7D4qB/vXxCXWUATdvGQvVYJxF0DGqpMRR0z7fxpQjKp2xiUFy2qt1vf+Ka0ccUBMbg1hZSja7C5cz7L3U1g7HZukxAkx2bOMmwA2uzgJfh7PvNOgX10OGA98T9a5YpPUnC7Moh8E2iDJW6vvkay6JGpxgYC/nF96hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lU7GaEo8nSmhRMmbl/WpOAMIZVLLX7XQlGfG3Mr0im+AbLUxMfGFZc2hGUl5kCtpypA/D42fuBFiodSl5ikWMGycylGGxGesyqf4TsgrveXIrERwliHE82+Wy8OVVA+gitfX0TUPsOiTOdQpwaBHce/jtZaiLD5c4Z237KuH/g4= Received: by 10.67.116.19 with SMTP id t19mr919290ugm.47.1203802138475; Sat, 23 Feb 2008 13:28:58 -0800 (PST) Received: by 10.66.220.6 with HTTP; Sat, 23 Feb 2008 13:28:58 -0800 (PST) Message-ID: Date: Sat, 23 Feb 2008 21:28:58 +0000 From: "Igor Mozolevsky" Sender: mozolevsky@gmail.com To: "Brooks Davis" In-Reply-To: <20080223203316.GC38485@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47C06E1F.5020308@thedarkside.nl> <760775.85636.qm@web50306.mail.re2.yahoo.com> <20080223203316.GC38485@lor.one-eyed-alien.net> X-Google-Sender-Auth: be3e3d49b4387e0e Cc: hackers@freebsd.org, Tim Clewlow Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 21:57:03 -0000 On 23/02/2008, Brooks Davis wrote: > > You should actually read the paper. :) They successfully defeat both > of these type of protections by using canned air to chill the ram and > transplanting it into another machine. Easy to get around this attack - store the key on a usb stick/cd/whatever and every time the OS needs to access the encrypted date the key should be read, data decrypted, then key wiped from the memory; or have the daemon erase the key from memory every T minutes and re-acquire the key at next access attempt... Or you could carry something that emits a huge EMI pulse to destroy the data on the disk... From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 22:06:25 2008 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 06EDF16A401 for ; Sat, 23 Feb 2008 22:06:25 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id A49FB13C457 for ; Sat, 23 Feb 2008 22:06:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1NM6K68001847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Feb 2008 09:06:22 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1NM6KhX095586; Sun, 24 Feb 2008 09:06:20 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1NM6Kar095585; Sun, 24 Feb 2008 09:06:20 +1100 (EST) (envelope-from peter) Date: Sun, 24 Feb 2008 09:06:20 +1100 From: Peter Jeremy To: Mike Meyer Message-ID: <20080223220620.GH34425@server.vk2pj.dyndns.org> References: <20080223123556.3eee709d@bhuda.mired.org> <20080223.110047.-397883947.imp@bsdimp.com> <20080223131937.182373b2@bhuda.mired.org> <20080223.120546.74701383.imp@bsdimp.com> <20080223155355.3f80b77f@bhuda.mired.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20080223155355.3f80b77f@bhuda.mired.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 22:06:25 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 03:53:55PM -0500, Mike Meyer wrote: >On Sat, 23 Feb 2008 12:05:46 -0700 (MST) Warner Losh wrot= e: >> It adds functionality. That doesn't make it gratuitous. One might >> just as well call 'POSIX' compatibility gratuitous. Like it or not, >> the GNU utilities represent a de-facto standard that we must conform >> to. > >POSIX is a well-defined standard, endorsed by a large number of >companies. GNU's just a bag of programs which only have one >commonality as far as I can tell: the software license. There's >another de-facto standard from a company in Redmond, that's *much* >more popular than GNU, and probably more consistent. If FreeBSD is >going to conform to implementations instead of standards, I'd rather >it conform to that one than GNU. I would also support POSIX in preference to GNU. IMHO, this discussion is all about portability. Warner wants to extend the FreeBSD find(1) so it can handle some non-portable constructs that he has run into. If those extensions are not incompatible with existing FreeBSD and POSIX and are generally useful without significantly bloating find(1) then it is probably OK to add them. At the same, time, the find(1) man page needs to clearly distinguish between the parts of find that are POSIX-complaint, the parts that are GNU extensions and the parts that are [Free]BSD extensions. This is necessary so that when I'm developing tools, I can avoid non-portable extensions (unlike whoever developed the scripts Warner is trying to use). If the FreeBSD project does not make it clear what functionality is safe to rely on then we run the risk of falling into the Linux trap where people write bash scripts because they believe it is the standard. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHwJjc/opHv/APuIcRAirWAJ0SOlGNuumptmVOzJrHvOgXFtjW0QCgkUlk mHCCwY97f8p1bG3iWqcv3go= =WSND -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 22:53:56 2008 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 7EE5816A403 for ; Sat, 23 Feb 2008 22:53:56 +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 53F8A13C474 for ; Sat, 23 Feb 2008 22:53:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B48542087; Sat, 23 Feb 2008 23:53:52 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2EFB9207E; Sat, 23 Feb 2008 23:53:52 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 050B78448C; Sat, 23 Feb 2008 23:53:51 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Meyer References: <20080222.225937.-146245356.imp@bsdimp.com> <20080223.000308.686168314.imp@bsdimp.com> <20080223123556.3eee709d@bhuda.mired.org> Date: Sat, 23 Feb 2008 23:53:51 +0100 In-Reply-To: <20080223123556.3eee709d@bhuda.mired.org> (Mike Meyer's message of "Sat\, 23 Feb 2008 12\:35\:56 -0500") Message-ID: <86skzjqo74.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 22:53:56 -0000 Mike Meyer writes: > How about a question: why are you turning the FreeBSD find into the > GNU find? The changes in the first patch looked like they added real > functionality that wasn't available in other tools. These seem to be > gratuitous changes to make things compatible with GNU. No, they're useful additions. If you don't like them, just don't use them. > If I want a GNU-compatible find on FreeBSD, I can install the > misc/findutils port. If I really wanted the GNU toolset, I could run > them on a Linux kernel. However, I'm more comfortable with the Unix > toolset [...] If you want the Unix toolset, you definitely don't want FreeBSD. I'm sure know where to find Solaris. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 22:54:14 2008 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 878FF16A401 for ; Sat, 23 Feb 2008 22:54:14 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id 7139A13C457 for ; Sat, 23 Feb 2008 22:54:14 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 28540 invoked by uid 1001); 23 Feb 2008 22:27:56 -0000 Date: Sat, 23 Feb 2008 14:27:33 -0800 From: "David E. Thiel" To: freebsd-hackers@freebsd.org Message-ID: <20080223222733.GI12067@redundancy.redundancy.org> References: <20080223010856.7244.qmail@smasher.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080223010856.7244.qmail@smasher.org> X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg X-Face: %H~{$1~NOw1y#%mM6{|4:/ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 22:54:14 -0000 On Sat, Feb 23, 2008 at 02:08:31PM +1300, Atom Smasher wrote: > article below. does anyone know how this affects eli/geli? There's fairly little any disk crypto system can do to thoroughly defend against this. The best workaround currently is to turn off your machine when not in use. This has always been a good idea, since even without this attack, a running or sleeping machine can simply be retained until the appearance of a 0-day in the kernel or other running services. Granted, that often takes a while for FreeBSD. ;) Also, keeping your *really* sensitive data in a separate encrypted store which isn't always mounted is probably a good idea. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 22:56:52 2008 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 E84D716A4D8 for ; Sat, 23 Feb 2008 22:56:52 +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 BE29B13C45D for ; Sat, 23 Feb 2008 22:56:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AEFFC2085; Sat, 23 Feb 2008 23:56:49 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 377E6207F; Sat, 23 Feb 2008 23:56:49 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1642584492; Sat, 23 Feb 2008 23:56:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jonathan McKeown References: <200802232322.45288.jonathan+freebsd-hackers@hst.org.za> Date: Sat, 23 Feb 2008 23:56:49 +0100 In-Reply-To: <200802232322.45288.jonathan+freebsd-hackers@hst.org.za> (Jonathan McKeown's message of "Sat\, 23 Feb 2008 23\:22\:45 +0200") Message-ID: <86oda7qo26.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 22:56:53 -0000 Jonathan McKeown writes: > What functionality does > > find path -lname name > > add that isn't already available from > > find path -name name -type l those are two entirely different things; -lname applies to the target of the symlink, not the symlink itself. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 23:08:34 2008 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 AACEF16A401 for ; Sat, 23 Feb 2008 23:08:34 +0000 (UTC) (envelope-from ap@bnc.net) Received: from bis.bonn.org (www.bis.bonn.org [217.110.117.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2F04C13C457 for ; Sat, 23 Feb 2008 23:08:33 +0000 (UTC) (envelope-from ap@bnc.net) X-Junk-Score: 2 [X] X-SpamCatcher-Score: 2 [X] X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by bis.bonn.org (CommuniGate Pro SMTP 5.2c4) with ESMTPSA id 9479766; Sat, 23 Feb 2008 23:10:39 +0100 X-SpamCatcher-Score: 2 [X] Received: from [194.39.194.142] (account ap HELO wasabi.wlan.bnc.net) by bnc.net (CommuniGate Pro SMTP 5.2.0) with ESMTPSA id 3077296; Sat, 23 Feb 2008 23:08:21 +0100 Message-Id: <7E17999C-6F1A-4BF0-96CE-2BB579C3A8C3@bnc.net> From: Achim Patzner To: "Igor Mozolevsky" In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-2-11517567; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 23 Feb 2008 23:08:20 +0100 References: <47C06E1F.5020308@thedarkside.nl> <760775.85636.qm@web50306.mail.re2.yahoo.com> <20080223203316.GC38485@lor.one-eyed-alien.net> X-Mailer: Apple Mail (2.919.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 23:08:34 -0000 --Apple-Mail-2-11517567 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Am 23.02.2008 um 22:28 schrieb Igor Mozolevsky: > Or you could carry something that emits a huge EMI pulse to destroy > the data on the disk... It would be easier to buy a MacBook Air... Achim --Apple-Mail-2-11517567-- From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 23:30:46 2008 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 14FCA16A404 for ; Sat, 23 Feb 2008 23:30:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E107C13C465 for ; Sat, 23 Feb 2008 23:30:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1NNSCud051585 for ; Sat, 23 Feb 2008 16:28:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 16:28:36 -0700 (MST) Message-Id: <20080223.162836.-1286958600.imp@bsdimp.com> To: freebsd-hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <20080223155355.3f80b77f@bhuda.mired.org> References: <20080223131937.182373b2@bhuda.mired.org> <20080223.120546.74701383.imp@bsdimp.com> <20080223155355.3f80b77f@bhuda.mired.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 23:30:46 -0000 In message: <20080223155355.3f80b77f@bhuda.mired.org> Mike Meyer writes: : > In short, I'm continuig the long tradition that we've done as FreeBSD : > and that BSD and other Unix vendors did before us: compatibility with : > other implementations. : : I suspect your definition of "long tradition" is a lot shorter than : mine. That's they only way I can make that statement make sense - at : least the part about BSD and other Unix vendors. Long tradition here spans about 30 years. SunOS 3.5 had many switches that did nothing, but were there for compatibility with System III systems, as one example. If you look at the evolution of /bin/sh in FreeBSD you'll notice that over the years it has accumulated much that is POSIX. If you look at the evolution of FreeBSD itself, you'll notice a change from a 'POSIX is evil, except where proven otherwise' mindset to a 'POSIX is a good thing, except where proven otherwise.' Lots of people hated POSIX back in the day, but today you'll not find too many people still in that camp. POSIX used to be less well defined than it is today. The GNU extensions have even been standardized as POSIX extensions over the years. It is my belief, based on experience in bringing over tools from other systems (read Linux) that there's a need to support these extensions, much like there was a need to support POSIX semantics 10 years ago. While not well codified, they are none-the-less in widespread use. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 23:34:54 2008 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 9E74416A402; Sat, 23 Feb 2008 23:34:54 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6EF13C457; Sat, 23 Feb 2008 23:34:54 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:d436:4a43:60a1:371c] (unknown [IPv6:2001:7b8:3a7:0:d436:4a43:60a1:371c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 331593C; Sun, 24 Feb 2008 00:34:53 +0100 (CET) Message-ID: <47C0AD9D.2070701@andric.com> Date: Sun, 24 Feb 2008 00:34:53 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0.0.13pre (Windows/20080218) MIME-Version: 1.0 To: Atom Smasher References: <20080223010856.7244.qmail@smasher.org> In-Reply-To: <20080223010856.7244.qmail@smasher.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, Pawel Jakub Dawidek Subject: Re: Security Flaw in Popular Disk Encryption Technologies 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, 23 Feb 2008 23:34:54 -0000 On 2008-02-23 02:08, Atom Smasher wrote: > article below. does anyone know how this affects eli/geli? > > from the geli man page: "detach - Detach the given providers, which means > remove the devfs entry and clear the keys from memory." does that mean > that geli properly wipes keys from RAM when a laptop is turned off? This is a physical attack, and there's nothing you can do in software to prevent it. Of course geli or other software can attempt to erase the keys from RAM as soon as it's done using them, but it won't prevent hijacking them beforehand. It's the same with all physical attacks: hardware sniffers, keyloggers, TEMPEST, etc. You need physical (hardware) protection to secure against these, not software. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 23:48:50 2008 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 4356A16A405 for ; Sat, 23 Feb 2008 23:48:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1D713C448 for ; Sat, 23 Feb 2008 23:48:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1NNlggw051993; Sat, 23 Feb 2008 16:47:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 16:48:06 -0700 (MST) Message-Id: <20080223.164806.-674897155.imp@bsdimp.com> To: jonathan+freebsd-hackers@hst.org.za From: "M. Warner Losh" In-Reply-To: <200802232322.45288.jonathan+freebsd-hackers@hst.org.za> References: <200802232322.45288.jonathan+freebsd-hackers@hst.org.za> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 23:48:50 -0000 In message: <200802232322.45288.jonathan+freebsd-hackers@hst.org.za> Jonathan McKeown writes: : What functionality does : : find path -lname name : : add that isn't already available from : : find path -name name -type l : : and what other combinations should be special-cased like this? What it does is make busybox and openwrt scrpits work better. One could argue that one should change the scripts, but that's not likely to happen. What does -iname add that a properly constructed regular expression for the name not have? Convenience. So apart from the fact that it is used in real scripts, it is also more convenient. Why do we use tools with short cuts? Because it saves us time. : Yes, where it makes sense. I'm not at all convinced that this change makes as : much sense as you obviously think it does - especially given that it doesn't : add previously unavailable functionality, and that we have a ports system : which includes a patch stage for dealing with this sort of gratuitous : non-portability in ported applications. The change absolutely makes sense, and so far none of the arguments against it are really worth the time to respond to. I'm using packages not in the ports system. Frankly, the more gratuitous differences with the gnu tools we have, the harder the sell will be for companies wanting to replace their Linux systems with FreeBSD ones. The changes I made were absolutely trivial in the scheme of things. This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 23:51:56 2008 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 155BF16A402 for ; Sat, 23 Feb 2008 23:51:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E381713C45D for ; Sat, 23 Feb 2008 23:51:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m1NNncgh052003; Sat, 23 Feb 2008 16:49:38 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 23 Feb 2008 16:50:02 -0700 (MST) Message-Id: <20080223.165002.-1219417475.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20080223220620.GH34425@server.vk2pj.dyndns.org> References: <20080223.120546.74701383.imp@bsdimp.com> <20080223155355.3f80b77f@bhuda.mired.org> <20080223220620.GH34425@server.vk2pj.dyndns.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, mwm-keyword-freebsdhackers2.e313df@mired.org Subject: Re: find -lname and -ilname implemented 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, 23 Feb 2008 23:51:56 -0000 In message: <20080223220620.GH34425@server.vk2pj.dyndns.org> Peter Jeremy writes: : At the same, time, the find(1) man page needs to clearly distinguish : between the parts of find that are POSIX-complaint, the parts that are : GNU extensions and the parts that are [Free]BSD extensions. This is : necessary so that when I'm developing tools, I can avoid non-portable : extensions (unlike whoever developed the scripts Warner is trying to : use). If the FreeBSD project does not make it clear what functionality : is safe to rely on then we run the risk of falling into the Linux trap : where people write bash scripts because they believe it is the standard. All the GNU extensions were flagged as such when I committed the man page updates. However, if I missed one or two, or if there's other extensions to posix that aren't tagged as such, I'll be happy to do the leg work to tag them better in the man page. Warner