From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 04:36:02 2010 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 A4C48106566B for ; Sun, 7 Mar 2010 04:36:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8098FC18 for ; Sun, 7 Mar 2010 04:36:02 +0000 (UTC) Received: (qmail 22772 invoked by uid 399); 7 Mar 2010 04:36:01 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Mar 2010 04:36:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B932D30.7050307@FreeBSD.org> Date: Sat, 06 Mar 2010 20:36:00 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <0ECDEB94-E60E-45C7-98AC-5E948DE4649C@dragondata.com> In-Reply-To: <0ECDEB94-E60E-45C7-98AC-5E948DE4649C@dragondata.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ACPI/power implementation causing performance loss with i7/Nehalem turbo boost X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Mar 2010 04:36:02 -0000 On 03/05/10 20:14, Kevin Day wrote: > > Recently I bumped into something very weird. In some CPU heavy workloads, FreeBSD ran faster inside VMware's ESX hypervisor than it did running natively on bare metal. Simple pure CPU applications (such as "openssl speed") would run 10-30% faster on VMware. This seemed very counterintuitive, until I discovered what I believe to be the cause. > > Intel Nehalem and i5/i7 processors have a feature called "Turbo Boost", where the more cores that are inactive (ACPI states C2 or C3) the higher the clock rate of the active cores. In some processors increasing the clock speed by more than 1ghz. On a hunch, I disabled turbo boost (through the BIOS) on our ESX system, and this brought the speeds back on par with the bare metal FreeBSD box. > > So, it seems that the VMware hypervisor is deactivating cores on the CPU when idle, but FreeBSD itself isn't. Is anyone working on giving FreeBSD's idle loop/scheduler the ability to go into deeper sleep states? It seems this would have more than just a power savings benefit now. > > Intel documentation on Turbo Boost: http://download.intel.com/design/processor/applnots/320354.pdf?iid=tech_tb+paper Howdy Kevin, :) Back in December I started a thread on a related topic because my C2D laptop running -current was running much hotter than usual. Several people were kind enough to offer me suggestions about tuning that I think might be applicable in your situation. I think someone else already gave you the URL http://wiki.freebsd.org/TuningPowerConsumption which was very helpful. Here is what I ended up with after some fiddling with the recommendations from there, and from those kind enough to help me: /boot/loader.conf: hw.pci.do_power_nodriver=3 hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 hint.apic.0.clock=0 kern.hz=100 hint.atrtc.0.clock=0 hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 /etc/rc.conf: powerd_enable="yes" # Run powerd to lower our power usage. powerd_flags="-a adaptive -b adaptive -n adaptive" performance_cpu_freq="NONE" # Online CPU frequency economy_cpu_freq="NONE" # Offline CPU frequency performance_cx_lowest="C3" # Online CPU idle state economy_cx_lowest="C3" # Offline CPU idle state hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 06:31:09 2010 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 ED1611065670; Sun, 7 Mar 2010 06:31:08 +0000 (UTC) (envelope-from selphie.keller@gmail.com) Received: from mail-pz0-f196.google.com (mail-pz0-f196.google.com [209.85.222.196]) by mx1.freebsd.org (Postfix) with ESMTP id B20E08FC15; Sun, 7 Mar 2010 06:31:08 +0000 (UTC) Received: by pzk34 with SMTP id 34so593366pzk.3 for ; Sat, 06 Mar 2010 22:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references:subject :date:message-id:mime-version:content-type:content-transfer-encoding :x-mailer:in-reply-to:x-mimeole:thread-index; bh=WGCVuUSe1Hlmax1Km2Jl7RXMT9ps1f2E27dASMoiZ88=; b=ATgETb6sQ/a9v9/qmQTOtpFLjI22sF/rExMNBwoXpQXZCETvTy9q+fImn+EHqJDGpB vQ3kIZG7kwj0wvVUwgPQth/CaLcyBh0ZgeUWIHkVcSie65w4uu5JKmGv2bAtd3w7gdvB pp7/xy0+3SFGIV/5kQElgrwd8C8yZOdUJ+4oo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :x-mimeole:thread-index; b=O8P6vZIJtXgNSHiXHYU/Ehateq6deCcyP4zeQ/vtJhwZ9GnhycXrvCbAOxGlTEH7Rs NJvPyBUxjvKdvKJrCge9cKWwajvZ4cVA1mnTlMriBLtDNwnfmF74uipMAT7iReTlJs2+ 2fqc4RRwZBZNi9geMh822Bs99ApQLXphQVoRM= Received: by 10.141.107.12 with SMTP id j12mr2063944rvm.181.1267943468279; Sat, 06 Mar 2010 22:31:08 -0800 (PST) Received: from 2WIRE304 (c-69-181-16-61.hsd1.ca.comcast.net [69.181.16.61]) by mx.google.com with ESMTPS id 23sm3331110pzk.14.2010.03.06.22.31.06 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Mar 2010 22:31:06 -0800 (PST) From: Selphie Keller To: "'Robert Watson'" References: <2BD4195B78BE4E4E9F4953B3196590E3@2WIRE304> Date: Sat, 6 Mar 2010 22:31:07 -0800 Message-ID: <579475BD01D74701A452FF632CA8BF98@2WIRE304> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acq9TXZlhY62huVjTXSZngHCtKRswgAcEwrw Cc: freebsd-hackers@freebsd.org Subject: RE: mac_mls mac_biba mac_lomac patches to fix ptys_equal mib support for new /dev/pts in FreeBSD 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Mar 2010 06:31:09 -0000 Robert, I have security.mac.mls.revocation_enabled set to 0, sshd was running as mls/equal(equal-equal) and my staff user was running as mls/2(low-high) and sshd gave the error message: Feb 25 21:46:14 labyrinth sshd[90850]: error: /dev/pts/5: Permission denied Feb 25 21:46:14 labyrinth sshd[90850]: error: open /dev/tty failed - could not set controlling tty: Permission denied where /dev/pts/5 was set as mls/low, which does seem to be a normal response when you have a higher grade trying to write to a lower grade with mls enforced. However, this error only occurs when a higher grade logs into the machine with mls/2(low-high) and is trying to write to /dev/pts/* with mls/low, when a insecure user logs in as mls/low(low-low) errors are not seen or if the user is exempted as mls/equal(equal-equal). I can recompile the module without the patch and regress it back to try and recreate the issues, if needed. -Selphie -----Original Message----- From: Robert Watson [mailto:rwatson@FreeBSD.org] Sent: Saturday, March 06, 2010 8:53 AM To: Selphie Keller Cc: freebsd-hackers@freebsd.org Subject: RE: mac_mls mac_biba mac_lomac patches to fix ptys_equal mib support for new /dev/pts in FreeBSD 8 On Tue, 2 Mar 2010, Selphie Keller wrote: > - (2) Could you let me know how your login.conf + user labels are > configured, and show me the output of "ps -axZ | grep sshd"? > > /etc/login.conf label configurations I use > > Staff users: label=mls/2(low-high) > Deamons: label=mls/equal(equal-equal) > Insecure users: label=mls/low(low-low) > > If you need the exact data from login.conf I can provide it, but is a bit > tricky as I use tc= to call from one class to another class and override, in > which default class is mls/low. Am I right in thinking that you have security.mac.biba.revocation_enabled and/or security.mac.mls.revocation_enabled set? Revocation being enabled might explain why you're seeing this issue, but other users aren't reporting problems. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 10:55:04 2010 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 50588106566C for ; Sun, 7 Mar 2010 10:55:04 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 03D378FC0A for ; Sun, 7 Mar 2010 10:55:03 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id BB19E1394F8; Sun, 7 Mar 2010 12:54:57 +0200 (EET) Date: Sun, 7 Mar 2010 12:54:57 +0200 From: Jaakko Heinonen To: Garrett Cooper Message-ID: <20100307105457.GB9015@a91-153-117-195.elisa-laajakaista.fi> References: <6413.1266433105@critter.freebsd.dk> <20100218064545.J2074@besplex.bde.org> <20100218095538.GA2318@a91-153-117-195.elisa-laajakaista.fi> <20100225195138.GA3323@a91-153-117-195.elisa-laajakaista.fi> <20100226091923.X2605@delplex.bde.org> <20100228174936.GA1252@a91-153-117-195.elisa-laajakaista.fi> <20100305055758.GA1062@a91-153-117-195.elisa-laajakaista.fi> <7d6fde3d1003060113t72164fdbn3d0367d2fec540c1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d6fde3d1003060113t72164fdbn3d0367d2fec540c1@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Poul-Henning Kamp , Bruce Evans , Alexander Best Subject: Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Mar 2010 10:55:04 -0000 On 2010-03-06, Garrett Cooper wrote: > > > >        http://people.freebsd.org/~jh/patches/lookup-root.2.diff > > 1. EBUSY's new definition doesn't look correct for rename(2) given > POSIX's definition ( > http://www.opengroup.org/onlinepubs/009695399/functions/rename.html ): > > [EBUSY] > [CX] [Option Start] The directory named by old or new is currently > in use by the system or another process, and the implementation > considers this an error. [Option End] Well, I don't think that it conflicts with POSIX. The root directory is in use by the system and it's not allowed to be renamed. > 2. I also did some quick snooping around and all filesystems that > support symlinks that FreeBSD has, sans ZFS [*], seem to support > EMLINK. Should we add this to the documentation? Probably, but it's not related to the changes made by the patch. -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 14:15:28 2010 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 634F6106566C for ; Sun, 7 Mar 2010 14:15:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id E26A68FC12 for ; Sun, 7 Mar 2010 14:15:27 +0000 (UTC) Received: by fxm23 with SMTP id 23so4031650fxm.3 for ; Sun, 07 Mar 2010 06:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IaOwqCnIG+cbvTObMpWf6e6Sik26fXtTXwPEI84wCFw=; b=TagUOrDXZ4NWNq6oEe9IQS/gZmWef5iwcJsVTAuoRzrSSdjXZS/tX2PMclpctYlOOZ qG5Jz+Q63touDjEuJ0yaMlrihs+emx6FFxBqYsBonpuJ3fvHjRkAE+oGvEDsvWdCjzjE gTabnMWF+vhG/lL1OEv1S+eZ8b3N3eE4bzZMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Usxz66zNDXA8R9c2QZyhT3QNYz9sdBkmAPJ2hK104W4lBpxatPZ8WFJoLyQA7ki5Aw bKBrzmLm9q6K6mrlJsjMEZRq485hxrQ/ZpWSY2xqgp75DjuEfj4e7TuXF0SRP4tIBXb6 wF+v5cO87a+arJkDvMlTvVg8AyYldi9l4tvJM= Received: by 10.87.72.3 with SMTP id z3mr3261453fgk.31.1267971326639; Sun, 07 Mar 2010 06:15:26 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2392404fxm.3.2010.03.07.06.15.25 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Mar 2010 06:15:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4B93B4FB.2090408@FreeBSD.org> Date: Sun, 07 Mar 2010 16:15:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Kevin Day References: <1267863782.00226478.1267851002@10.7.7.3> <1267867387.00226487.1267855802@10.7.7.3> <1267870984.00226502.1267859402@10.7.7.3> In-Reply-To: <1267870984.00226502.1267859402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ACPI/power implementation causing performance loss with i7/Nehalem turbo boost X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Mar 2010 14:15:28 -0000 Kevin Day wrote: > On Mar 6, 2010, at 12:05 AM, Daniel O'Connor wrote: > Yeah, sorry for not mentioning that I had tried this and didn't see any change, so I thought I was on the wrong track. > > # sysctl hw.acpi.cpu.cx_lowest=C3 > hw.acpi.cpu.cx_lowest: C1 -> C3 > > but it doesn't look like it's ever leaving C1: > > hw.acpi.cpu.cx_lowest: C3 > dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us You have too high interrupt rate for the C-states entering latencies reported by your ACPI. You should significantly reduce number of interrupts per core. For example, by setting: kern.hz=100 hint.apic.0.clock=0 hint.atrtc.0.clock=0 -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 20:57:49 2010 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 434E01065670 for ; Sun, 7 Mar 2010 20:57:49 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7F78FC15 for ; Sun, 7 Mar 2010 20:57:48 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o27KwPiI066288 for ; Sun, 7 Mar 2010 12:58:25 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4B941347.3060900@mahan.org> Date: Sun, 07 Mar 2010 12:57:43 -0800 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Need a build target X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 07 Mar 2010 20:57:49 -0000 All, Just wanted some confirmation, but I have a need where I need to build just the kernel toolchain, kernel and the full toolchain and include files. The first two I can do via 'make kernel-toolchain' and 'make buildkernel'. However, to get the complete build toolchain and include files, suitable for building user applications, I still need to do a full 'buildworld'. As you are probably inferring, this is for a cross-compile environment. I have looked through both src/Makefile and src/Makefile.inc1 and cannot see a target that will give me that capability. I think I need to a target to do this for me. WTOOLSMAKE_TGTS= .if !defined(SUBDIR_OVERRIDE) WTOOLSMAKE_TGTS+= _worldtmp _legacy _bootstrap-tools .endif WTOOLSMAKE_TGTS+= _cleanobj _obj _build_tools .if !defined(SUBDIR_OVERRIDE) WTOOLSMAKE_TGTS+= _cross-tools .endif WTOOLSMAKE_TGTS+= _includes _libraries buildworldtools: buildwtools_prologue ${WTOOLSMAKE_TGTS} buildwtools_epilogue .ORDER buildwtools_prologue ${WTOOLSMAKE_TGTS} buildwtools_epilogue buildwtools_prologue: @echo "--------------------------------------------------------------" @echo ">>> World build tools started on `LC_ALL=C date`" @echo "--------------------------------------------------------------" buildwtools_epilogue: @echo "--------------------------------------------------------------" @echo ">>> World build tools started on `LC_ALL=C date`" @echo "--------------------------------------------------------------" This should then build the complete set of binutils, compiler, libraries and include files, yes? Thanks for any direction, Patrick From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 7 23:38:40 2010 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 13EFF106566C for ; Sun, 7 Mar 2010 23:38:40 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id CF5588FC15 for ; Sun, 7 Mar 2010 23:38:39 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id E529663319D for ; Mon, 8 Mar 2010 00:21:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 70AF22CEDB3 for ; Sun, 7 Mar 2010 23:21:49 +0100 (CET) Date: Sun, 7 Mar 2010 23:21:46 +0100 From: Patrick Lamaiziere To: freebsd-hackers@FreeBSD.ORG Message-ID: <20100307232146.6b57f610@davenulle.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Cc: Subject: Dead store elimination in the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 23:38:40 -0000 Hello, I'm asking if FreeBSD is safe regarding dead store elimination made by gcc? By example, in crypto drivers, sensitive datas are cleared by a bzero() after use to avoid potential leakages. But the bzero() by itself is useless, is it removed by gcc? Thanks, regards. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 11:16:09 2010 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 33D8B106566B; Mon, 8 Mar 2010 11:16:09 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mail.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with ESMTP id D6A268FC14; Mon, 8 Mar 2010 11:16:08 +0000 (UTC) Received: from localhost (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 2B02493579; Mon, 8 Mar 2010 12:16:07 +0100 (CET) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by localhost (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id ox1Ui2F+dQtX; Mon, 8 Mar 2010 12:16:04 +0100 (CET) Received: from aurynmob2.giulioferro.it (unknown [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id C05A79356D; Mon, 8 Mar 2010 12:16:04 +0100 (CET) Message-ID: <4B94DC74.7070001@zirakzigil.org> Date: Mon, 08 Mar 2010 12:16:04 +0100 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100223 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: NFS Client error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 11:16:09 -0000 Freebsd 8 stable amd64 It mounts different file systems by NFS (with locking) on a data server directly connected (gigabit) to the server Apache running in a several jails on those nfs folders. Now and then I get huge slow-down. When I look in the logs I get thousand of lines like these: Mar 5 11:50:52 virt2 kernel: vm_fault: pager read error, pid 46487 (httpd) Mar 5 11:50:52 virt2 kernel: pid 46487 (httpd), uid 80: exited on signal 11 What should I do? From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 13:54:53 2010 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 6215B106566B for ; Mon, 8 Mar 2010 13:54:53 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mx1.freebsd.org (Postfix) with ESMTP id A4DF48FC12 for ; Mon, 8 Mar 2010 13:54:50 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS5UBqXABf2i0/1Rw2nvJ9RHjfDw3fiuK@postini.com; Mon, 08 Mar 2010 05:54:52 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 8 Mar 2010 05:54:41 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 8 Mar 2010 08:54:40 -0500 From: Andrew Duane To: Patrick Lamaiziere , "freebsd-hackers@freebsd.org" Date: Mon, 8 Mar 2010 08:54:40 -0500 Thread-Topic: Dead store elimination in the kernel? Thread-Index: Acq+T1nVG/2BwBHRTH6zXJMtxV08IgAd1Rug Message-ID: References: <20100307232146.6b57f610@davenulle.org> In-Reply-To: <20100307232146.6b57f610@davenulle.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: Dead store elimination in the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 13:54:53 -0000 owner-freebsd-hackers@freebsd.org wrote: > Hello, >=20 > I'm asking if FreeBSD is safe regarding dead store elimination made > by gcc?=20 >=20 > By example, in crypto drivers, sensitive datas are cleared by a > bzero() after use to avoid potential leakages. But the bzero() by > itself is useless, is it removed by gcc? >=20 > Thanks, regards. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" I would think the "correct" way to handle this is to make sure all appropri= ate items are declared volatile. This would eliminate dead store eliminatio= n, as the compiler can tell they are not dead. Unfortunately, the history of drivers (or any code) correctly using volatil= e declarations is intermittent at best. /Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 15:34:28 2010 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 118E01065672; Mon, 8 Mar 2010 15:34:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D4E228FC14; Mon, 8 Mar 2010 15:34:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84FA846B1A; Mon, 8 Mar 2010 10:34:27 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DF2288A021; Mon, 8 Mar 2010 10:34:26 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 8 Mar 2010 09:46:10 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100304213329.GJ57205@bunrab.catwhisker.org> <7d6fde3d1003060041p225e8718n29a8e75a718237a@mail.gmail.com> <201003060729.01225.jpaetzel@freebsd.org> In-Reply-To: <201003060729.01225.jpaetzel@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003080946.10876.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Mar 2010 10:34:26 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Josh Paetzel , Garrett Cooper , randi@freebsd.org, David Wolfskill Subject: Re: Scripting sysinstall(8) to create & use multiple slices on a disk? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:34:28 -0000 On Saturday 06 March 2010 8:28:54 am Josh Paetzel wrote: > I'd also like to mention John saying you can build a custom mfsroot to use > additional tools during install...I go a different tack on this. I'm a huge > fan of python, and like to use it for installers. Rather than build a custom > mfsroot with python what I prefer to do is build a chroot that the target > machine boots diskless off. Then I chroot into that directory and install > whatever tools I want using ports/packages. I find that getting FreeBSD to > boot diskless is so easy that I've had it accidentally happen more than once > when I wanted something else to happen. Installing ports in a chroot is also > pretty trivial. Building a custom mfsroot has a bit of a learning curve with > a fairly expensive trial and error penalty. I agree that building a custom mfsroot from scratch would be a bit of a PITA. I generally cheat by just patching src/release//boot_crunch.conf to add the tools I want to use. I find dialog(1) useful for popping up sysinstall-style dialog boxes from shell scripts. I have also seen folks build a completely separate MFS root separate from the release process. While that was more tedious to get started, it was certainly more flexible. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 15:34:29 2010 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 BD0A01065690 for ; Mon, 8 Mar 2010 15:34:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C12E8FC16 for ; Mon, 8 Mar 2010 15:34:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3DF1E46B51; Mon, 8 Mar 2010 10:34:29 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 28D598A025; Mon, 8 Mar 2010 10:34:28 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 8 Mar 2010 09:47:57 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4B916BD0.7030501@delphij.net> <20100306083916.GI21344@acme.spoerlein.net> In-Reply-To: <20100306083916.GI21344@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201003080947.58027.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Mar 2010 10:34:28 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best , Ulrich =?iso-8859-1?q?Sp=F6rlein?= , Xin LI Subject: Re: tiny lib/libkvm/kvm_proc.c correction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 15:34:29 -0000 On Saturday 06 March 2010 3:39:17 am Ulrich Sp=F6rlein wrote: > On Fri, 05.03.2010 at 12:38:40 -0800, Xin LI wrote: > > On 2010/03/05 11:59, Alexander Best wrote: > > > Xin LI schrieb am 2010-03-05: > > > On 2010/03/05 11:26, Alexander Best wrote: > > >>>> hi there. does this look right? > > >=20 > > > Not to me, the value is not to be used this way and the comments > > > above the code explained the same thing. > > >=20 > > > I think we should use cputick2usec but it's not available to userland > > > (one have to copy cpu_tick_frequency and friends). > > >=20 > > >> damn you're right. i completely overlooked that comment. would it be= =20 worth > > >> making cputick2usec available to userland? is kvm_proc.c the only=20 candidate in > > >> need of converting cpu ticks to usecs? > >=20 > > I'm not sure how to do that unfortunately, is there a way to expose a > > kernel variable to userland which also works on a crash dump? >=20 > ticks *is* available to libkvm, not sure what happens on crashdumps, > though. The following patchset has not been tested: >=20 >=20 https://www.spoerlein.net/gitweb/?p=3Dfreebsd.work/.git;a=3Dcommitdiff;h=3D= d500a051eb75dd234166bb11485c0a953aefce1d I'm fine with this patch so long as you are reading 'ticks' from the crash= =20 dump. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 15:34:30 2010 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 C9D9C10656DD for ; Mon, 8 Mar 2010 15:34:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3EF8FC17 for ; Mon, 8 Mar 2010 15:34:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4FA1846B46; Mon, 8 Mar 2010 10:34:30 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id ADD9F8A01F; Mon, 8 Mar 2010 10:34:29 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 8 Mar 2010 09:49:38 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4B941347.3060900@mahan.org> In-Reply-To: <4B941347.3060900@mahan.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003080949.38766.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Mar 2010 10:34:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Patrick Mahan Subject: Re: Need a build target X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 15:34:30 -0000 On Sunday 07 March 2010 3:57:43 pm Patrick Mahan wrote: > > All, > > Just wanted some confirmation, but I have a need where I need > to build just the kernel toolchain, kernel and the full toolchain > and include files. The first two I can do via 'make kernel-toolchain' > and 'make buildkernel'. However, to get the complete build toolchain > and include files, suitable for building user applications, I still > need to do a full 'buildworld'. Perhaps 'make toolchain' would work? You can then use 'make buildenv' to do interactive builds. I think you can use SUBDIR_OVERRIDE with 'make buildworld' to build specific subdirectories. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 17:02:20 2010 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 7084D106566B for ; Mon, 8 Mar 2010 17:02:20 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id D68888FC2E for ; Mon, 8 Mar 2010 17:02:19 +0000 (UTC) Received: from park.js.berklix.net (p549A675D.dip.t-dialin.net [84.154.103.93]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o28H2G8X049815 for ; Mon, 8 Mar 2010 17:02:17 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o28H29ZE090937 for ; Mon, 8 Mar 2010 18:02:09 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o28H23MG056963 for ; Mon, 8 Mar 2010 18:02:09 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201003081702.o28H23MG056963@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 08 Mar 2010 18:02:03 +0100 Sender: jhs@berklix.com Cc: Subject: kbdcontrol: how to get us.iso on ukbd & en.iso on atkbd ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 17:02:20 -0000 Hi hackers@ Am I missing something obvious, or is a bit more needed in man kbdcontrol ? /etc/rc.conf keymap="uk.iso.kbd" sets laptop internal keycaps to English OK, But What kbdcontrol[s] set an external USB keyboard (only) to eg American (or German etc), while leaving internal in English ? (American or German will here later depend on devd.conf vendor id, or ~/.login . (de.iso.kbd useful for test as it toggles Y/Z )). ( I don't have a problem with devd.conf, I've got that working fine for X with xmodmap (as long as X session has already started) using /etc/rc.conf & devd.conf . devd_flags="-f /site/etc/devd/jhs.conf" http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/devd/jhs.conf ) kbdmap # Works OK but sets both internal & external keyboard maps. uname -r # 8.0-RELEASE su kbdcontrol -k /dev/ukbd0 -l de.iso cannot open /dev/ukbd0: Device busy setting keymap: Inappropriate ioctl for device kbdcontrol -k /dev/ukbd0 -l de.iso < /dev/console cannot open /dev/ukbd0: Device busy kbdcontrol -A /dev/ukbd0 -k /dev/kbdmux0 unable to obtain keyboard information: Inappropriate ioctl for device cannot open /dev/kbdmux0: Device busy kbdcontrol -A /dev/kbdmux0 -k /dev/ukbd0 unable to obtain keyboard information: Inappropriate ioctl for device cannot open /dev/ukbd0: Device busy kbdcontrol -K < /dev/console kbd1 kbdmux0, type:AT 101/102 (2) kbdcontrol -a ukbd1 -l uk.iso < /dev/console kbd1 kbdmux0, type:AT 101/102 (2) kbdcontrol: unable to (un)mux the keyboard: Invalid argument sysctl -a | grep kbd | sort dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.FNC0.KBC_ dev.atkbdc.0.%parent: acpi0 dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.ukbd.0.%desc: vendor 0x1241 product 0x1203, class 0/0, rev 2.00/2.30, addr 2 dev.ukbd.0.%driver: ukbd dev.ukbd.0.%location: port=1 interface=0 dev.ukbd.0.%parent: uhub1 dev.ukbd.0.%pnpinfo: vendor=0x1241 product=0x1203 devclass=0x00 devsubclass=0x00 sernum="" release=0x0230 intclass=0x03 intsubclass=0x01 hw.kbd.keymap_restrict_change: 0 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.usb.ukbd.debug: 0 hw.usb.ukbd.no_leds: 0 Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 18:56:11 2010 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 BC1561065675 for ; Mon, 8 Mar 2010 18:56:11 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFD08FC1F for ; Mon, 8 Mar 2010 18:56:09 +0000 (UTC) Received: from mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o28IurMF083640; Mon, 8 Mar 2010 10:56:53 -0800 (PST) (envelope-from mahan@mahan.org) Message-Id: <201003081856.o28IurMF083640@ns.mahan.org> To: John Baldwin In-reply-to: <201003080949.38766.jhb@freebsd.org> References: <4B941347.3060900@mahan.org> <201003080949.38766.jhb@freebsd.org> Comments: In-reply-to John Baldwin message dated "Mon, 08 Mar 2010 09:49:38 -0500." Date: Mon, 08 Mar 2010 10:56:09 -0800 From: Patrick Mahan Cc: freebsd-hackers@freebsd.org Subject: Re: Need a build target X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 18:56:11 -0000 > On Sunday 07 March 2010 3:57:43 pm Patrick Mahan wrote: > > > > All, > > > > Just wanted some confirmation, but I have a need where I need > > to build just the kernel toolchain, kernel and the full toolchain > > and include files. The first two I can do via 'make kernel-toolchain' > > and 'make buildkernel'. However, to get the complete build toolchain > > and include files, suitable for building user applications, I still > > need to do a full 'buildworld'. > > Perhaps 'make toolchain' would work? You can then use 'make buildenv' > to do interactive builds. I think you can use SUBDIR_OVERRIDE with 'make > buildworld' to build specific subdirectories. > I believe you are correct. This should build exactly what I need. As always, this list helps me when I'm stuck, Patrick From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 21:31:20 2010 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 2EC89106566C for ; Mon, 8 Mar 2010 21:31:20 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id DE8758FC14 for ; Mon, 8 Mar 2010 21:31:18 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so15529qwi.7 for ; Mon, 08 Mar 2010 13:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0qMkGzDdEIfBL0DRO8V2nwHtsr0G5n1OHsfmwzsOBog=; b=gw8etElNPI5aIs7dDw1hdAq4lFZzqOzc4jCnNBlCh3ytlA/38bAI60V0MB4nXzY38b qy/LNx8ePy/PIpMf38G2lZWBvdrgooxIb6ByozPByMUKWhpCH9zVB0df4xybWsYDjlaJ JkAPwEncks43Z4hH+VVhQxxFhbL1g0aZbSb+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WjIqGdr/Rjar3U4q2K/rYvZzCw7cVmOwweY+lHl2e1q6fisxKdtKyetmJSZpws2DPW EnW8FwF8i3Cj7+nXMdOuzriwEyW3Ri3EZrIr7rG0x3Z0xX6oM9NblGZtMp8PBhRrjJSO pOwSvh4Wk6dsJ3SehMXsC4cBK0E5QfinlbV8c= MIME-Version: 1.0 Received: by 10.229.240.4 with SMTP id ky4mr1744261qcb.35.1268082261796; Mon, 08 Mar 2010 13:04:21 -0800 (PST) In-Reply-To: <201003081702.o28H23MG056963@fire.js.berklix.net> References: <201003081702.o28H23MG056963@fire.js.berklix.net> Date: Mon, 8 Mar 2010 13:04:21 -0800 Message-ID: From: Maksim Yevmenkin To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: kbdcontrol: how to get us.iso on ukbd & en.iso on atkbd ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 21:31:20 -0000 On Mon, Mar 8, 2010 at 9:02 AM, Julian H. Stacey wrote: > Hi hackers@ > Am I missing something obvious, or is a bit more needed in man kbdcontrol ? possibly the later :) > What kbdcontrol[s] set an external USB keyboard (only) > to eg American (or German etc), while leaving internal in English ? well, it may or may not work, depending on whether you want or don't want to use both keyboards at the same time [...] > su > kbdcontrol -k /dev/ukbd0 -l de.iso > cannot open /dev/ukbd0: Device busy > setting keymap: Inappropriate ioctl for device > kbdcontrol -k /dev/ukbd0 -l de.iso < /dev/console > cannot open /dev/ukbd0: Device busy > kbdcontrol -A /dev/ukbd0 -k /dev/kbdmux0 > unable to obtain keyboard information: Inappropriate ioctl for device > cannot open /dev/kbdmux0: Device busy > kbdcontrol -A /dev/kbdmux0 -k /dev/ukbd0 > unable to obtain keyboard information: Inappropriate ioctl for device > cannot open /dev/ukbd0: Device busy > kbdcontrol -K < /dev/console > kbd1 > kbdmux0, type:AT 101/102 (2) > kbdcontrol -a ukbd1 -l uk.iso < /dev/console > kbd1 > kbdmux0, type:AT 101/102 (2) > kbdcontrol: unable to (un)mux the keyboard: Invalid argument well, you should be using keyboard name (not keyboard device node name) in attach/detach, i.e. something like % kbdcontrol -A ukbd0 < /dev/ttyv0 to detach ukbd0 from kbdmux. as you have realized, you can not do anything to a keyboard if kbdmux has control over it. so, you need to detach keyboard first. because kbdmux is essentially "master" keyboard if you set keyboard map on kbdmux, it will set the same keyboard map on all the "slave" keyboards. you might want to try - detach keyboard from kbdmux - set map on detached keyboard - reattach keyboard to kbdmux kbdmux does not set map on KBADDKBD ioctl(), so, in theory, it *might* work. also, please keep in mind that kbdmux will always set "slave" keyboard into K_RAW mode. thanks, max From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 8 22:59:51 2010 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 C1ED41065676; Mon, 8 Mar 2010 22:59:51 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 777578FC08; Mon, 8 Mar 2010 22:59:51 +0000 (UTC) Received: from bel.soho.vwsoft.com (p4FE238E9.dip.t-dialin.net [79.226.56.233]) by Mail.elbekies.net (Postfix) with ESMTPA id 0B0112E05A; Mon, 8 Mar 2010 23:59:47 +0100 (CET) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id 5E8AF33C86; Mon, 8 Mar 2010 23:59:26 +0100 (CET) Message-ID: <4B958151.8060707@vwsoft.com> Date: Mon, 08 Mar 2010 23:59:29 +0100 From: volker@vwsoft.com User-Agent: Thunderbird 2.0.0.23 (X11/20100306) MIME-Version: 1.0 To: Giulio Ferro References: <4B94DC74.7070001@zirakzigil.org> In-Reply-To: <4B94DC74.7070001@zirakzigil.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: 0B0112E05A.AC24F X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1268693987.7479@WIKk2VA0DpPYgeyKHYr8ew Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: NFS Client error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 08 Mar 2010 22:59:51 -0000 On 03/08/10 12:16, Giulio Ferro wrote: > Freebsd 8 stable amd64 > > It mounts different file systems by NFS (with locking) on a > data server directly connected (gigabit) to the server > > Apache running in a several jails on those nfs folders. > > Now and then I get huge slow-down. When I look in the logs > I get thousand of lines like these: > Mar 5 11:50:52 virt2 kernel: vm_fault: pager read error, pid 46487 (httpd) > Mar 5 11:50:52 virt2 kernel: pid 46487 (httpd), uid 80: exited on > signal 11 > > > What should I do? Giulio, it seems this is anyhow not related to network (nfs) operations. It's looking like a problem in the VM. I think it makes sense to have a look at the httpd.core file if the binary has been linked with debugging symbols turned on. Also I think at first, it may not hurt to look at vmstat -m output. You may want to change ${subject} and post to stable@ to drive more attention to your problem. Volker From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 13:53:10 2010 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 3B75C106564A; Tue, 9 Mar 2010 13:53:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1568FC17; Tue, 9 Mar 2010 13:53:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B282F46B91; Tue, 9 Mar 2010 08:53:09 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 044678A021; Tue, 9 Mar 2010 08:53:09 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 9 Mar 2010 07:44:09 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4B94DC74.7070001@zirakzigil.org> <4B958151.8060707@vwsoft.com> In-Reply-To: <4B958151.8060707@vwsoft.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003090744.09149.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 09 Mar 2010 08:53:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: volker@vwsoft.com, freebsd-net@freebsd.org, Giulio Ferro Subject: Re: NFS Client error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 13:53:10 -0000 On Monday 08 March 2010 5:59:29 pm volker@vwsoft.com wrote: > On 03/08/10 12:16, Giulio Ferro wrote: > > Freebsd 8 stable amd64 > > > > It mounts different file systems by NFS (with locking) on a > > data server directly connected (gigabit) to the server > > > > Apache running in a several jails on those nfs folders. > > > > Now and then I get huge slow-down. When I look in the logs > > I get thousand of lines like these: > > Mar 5 11:50:52 virt2 kernel: vm_fault: pager read error, pid 46487 (httpd) > > Mar 5 11:50:52 virt2 kernel: pid 46487 (httpd), uid 80: exited on > > signal 11 > > > > > > What should I do? > > Giulio, > > it seems this is anyhow not related to network (nfs) operations. It's > looking like a problem in the VM. I think it makes sense to have a look > at the httpd.core file if the binary has been linked with debugging > symbols turned on. Also I think at first, it may not hurt to look at > vmstat -m output. > > You may want to change ${subject} and post to stable@ to drive more > attention to your problem. That's not quite true. If you take a page fault on a mmap'd file backed by NFS (e.g. an executable or shared library) and an NFS READ RPC to satisfy the page fault fails, then you could get this error. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 18:59:18 2010 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 3902D106566C; Tue, 9 Mar 2010 18:59:18 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id D901A8FC18; Tue, 9 Mar 2010 18:59:17 +0000 (UTC) Received: from bel.soho.vwsoft.com (p4FE2343A.dip.t-dialin.net [79.226.52.58]) by Mail.elbekies.net (Postfix) with ESMTPA id CFBE82E05A; Tue, 9 Mar 2010 19:59:10 +0100 (CET) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id BB0F433C7C; Tue, 9 Mar 2010 19:58:53 +0100 (CET) Message-ID: <4B969A71.20308@vwsoft.com> Date: Tue, 09 Mar 2010 19:58:57 +0100 From: volker@vwsoft.com User-Agent: Thunderbird 2.0.0.23 (X11/20100306) MIME-Version: 1.0 To: John Baldwin References: <4B94DC74.7070001@zirakzigil.org> <4B958151.8060707@vwsoft.com> <201003090744.09149.jhb@freebsd.org> In-Reply-To: <201003090744.09149.jhb@freebsd.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: CFBE82E05A.A9AF2 X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1268765954.105@p+hScOZ4jUh6/JQUWDFJMQ Cc: freebsd-hackers@freebsd.org, Giulio Ferro , freebsd-net@freebsd.org Subject: Re: NFS Client error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 18:59:18 -0000 On 03/09/10 13:44, John Baldwin wrote: > On Monday 08 March 2010 5:59:29 pm volker@vwsoft.com wrote: >> On 03/08/10 12:16, Giulio Ferro wrote: >>> Freebsd 8 stable amd64 >>> >>> It mounts different file systems by NFS (with locking) on a >>> data server directly connected (gigabit) to the server >>> >>> Apache running in a several jails on those nfs folders. >>> >>> Now and then I get huge slow-down. When I look in the logs >>> I get thousand of lines like these: >>> Mar 5 11:50:52 virt2 kernel: vm_fault: pager read error, pid 46487 > (httpd) >>> Mar 5 11:50:52 virt2 kernel: pid 46487 (httpd), uid 80: exited on >>> signal 11 >>> >>> >>> What should I do? >> Giulio, >> >> it seems this is anyhow not related to network (nfs) operations. It's >> looking like a problem in the VM. I think it makes sense to have a look >> at the httpd.core file if the binary has been linked with debugging >> symbols turned on. Also I think at first, it may not hurt to look at >> vmstat -m output. >> >> You may want to change ${subject} and post to stable@ to drive more >> attention to your problem. > > That's not quite true. If you take a page fault on a mmap'd file backed by > NFS (e.g. an executable or shared library) and an NFS READ RPC to satisfy the > page fault fails, then you could get this error. > John, thank you for pointing that out. I've forgotten the mmap'ing of files over nfs as a possible source of that problem. With 8-stable I'm seeing mbufs leaking with nfs operation. It may or may not be related to Giulio's problem. Volker From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 20:40:30 2010 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 D68FB1065670 for ; Tue, 9 Mar 2010 20:40:30 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by mx1.freebsd.org (Postfix) with ESMTP id 930B48FC12 for ; Tue, 9 Mar 2010 20:40:30 +0000 (UTC) Received: by yxe14 with SMTP id 14so1194465yxe.7 for ; Tue, 09 Mar 2010 12:40:29 -0800 (PST) Received: by 10.101.11.14 with SMTP id o14mr564081ani.196.1268167229570; Tue, 09 Mar 2010 12:40:29 -0800 (PST) Received: from vpn177.ord02.your.org (vpn177.ord02.your.org [204.9.55.177]) by mx.google.com with ESMTPS id 21sm5894390iwn.15.2010.03.09.12.40.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 12:40:28 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Mar 2010 14:40:26 -0600 Message-Id: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> To: FreeBSD Hackers Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 20:40:30 -0000 I'm troubleshooting a pretty weird problem with running FreeBSD 8.0 = (amd64) inside VMware ESX/ESXi servers. We've got a wide range of = physical servers running identical copies of VMware and identical = FreeBSD virtual machines. Everything works fine on all of our servers = for Windows and Linux VMs, but FreeBSD running on Opteron 2352 physical = servers takes an average of about 20 minutes to boot. Normally I would = chalk this up to being a VMware bug, but the situation that's actually = occurring is somewhat interesting. If I boot up on an Opteron 2218 system, it boots normally. If I boot the = exact same VM moved to a 2352, I get: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 (very long pause) ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] then booting normally. The pause is between 1 and 60 minutes (somewhat variable, and i'm not = sure on what). After it eventually boots, everything seems fine. Doing a = diff between the 2218(-) and 2352(+) servers' verbose boots, I see: -ACPI timer: 0/90 0/23 1/1 1/1 1/1 1/1 0/12 1/1 1/1 1/1 -> 7 +ACPI timer: 0/162 0/1546 0/1119 0/150 0/165 0/778 0/123 0/203 0/83 0/93 = -> 0 This looks more interesting. If I'm reading acpi_timer_test() correctly, = the ACPI timer isn't particularly good on the 2218, but is flat out = unusable on the 2352. I don't know if this is a symptom or the actual = cause of the problem, though. Disabling ACPI results in an instant boot up, but the SCSI PCI device = isn't found which makes it kinda pointless. Before I delve too deeply into this, does this ring any bells to anyone? From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 21:36:19 2010 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 D810E106564A for ; Tue, 9 Mar 2010 21:36:19 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7388FC0C for ; Tue, 9 Mar 2010 21:36:19 +0000 (UTC) Received: from bel.soho.vwsoft.com (p4FE2343A.dip.t-dialin.net [79.226.52.58]) by Mail.elbekies.net (Postfix) with ESMTPA id 570592E05A for ; Tue, 9 Mar 2010 22:20:16 +0100 (CET) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by bel.soho.vwsoft.com (Postfix) with ESMTP id BE15233C7C for ; Tue, 9 Mar 2010 22:19:58 +0100 (CET) Message-ID: <4B96BB82.5090805@vwsoft.com> Date: Tue, 09 Mar 2010 22:20:02 +0100 From: volker@vwsoft.com User-Agent: Thunderbird 2.0.0.23 (X11/20100306) MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-ID: 570592E05A.AA272 X-Elbekies-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com MailScanner-NULL-Check: 1268774417.03407@o2OkIk5e1NKwtPCNrEa0kA Cc: Subject: southbridge recognition X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 21:36:19 -0000 Hi! For some driver enhancements, I need to decide (by code) which southbridge (Intel, AMD is all that matters) the driver is facing. What's the best (portable wise) way to distinguish the chipset? Intel supports two pages of 128 byte CMOS RAM, AMD supports 1 page of 256 byte (addressing is different). Is there any way to query the CMOS RAM size? I failed to find a way while reading Intel & AMD chipset documentation. Older chipsets supported only 64 (very old) or 128 byte. Recent (as of for the last 15 years or so) chipsets supports more. As our current nvram(4) driver only works with 128 byte RAM size, is anybody interested in seeing the nvram(4) driver enhanced for extended memory areas? I do have working code but that assumes an Intel ICH or 440LX chipset (fails for SB{67]xx for some reason :). Thank you for any pointers! Volker From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 22:02:21 2010 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 CFE741065670 for ; Tue, 9 Mar 2010 22:02:21 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by mx1.freebsd.org (Postfix) with ESMTP id 697708FC0C for ; Tue, 9 Mar 2010 22:02:21 +0000 (UTC) Received: by ewy28 with SMTP id 28so2067543ewy.13 for ; Tue, 09 Mar 2010 14:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3vnRUZUXk8o9no//9VjRZZFj46iPkpglI3pquh0KKg8=; b=BZKdt0bKpQdjYle8EeLwSt3YLNiuwemgMsMK3Y4L4jdDNCK+8SexJeIVU8R86pOAIk 207+dByn/WXvxAzsVoNASnDTsN8hox4FKMj0Z+16PRXLMvIeHysTDedVKefhFUSy7+Bs 02DTgpOArxtc4ignCX3cuYu45nOgeT3uqY/XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jFitV8MlpwJELzQ1V0752NA1kdnkAdzO6/F11TuG1UaxHc/minPAHvgOeHK0GX7nxa KtOIZV6vxQR5kh5FCcjeA26xBW+5NSgSh7zVlDAV78pI/dbtq8LgTgla//wOWLwTFGhH kXTt4GgvEFXCL91qJHEkKtKf/pNM1v/oM4a/A= MIME-Version: 1.0 Received: by 10.213.1.145 with SMTP id 17mr4455784ebf.46.1268172140319; Tue, 09 Mar 2010 14:02:20 -0800 (PST) In-Reply-To: <4B96BB82.5090805@vwsoft.com> References: <4B96BB82.5090805@vwsoft.com> Date: Tue, 9 Mar 2010 17:02:20 -0500 Message-ID: From: Ryan Stone To: volker@vwsoft.com Content-Type: text/plain; charset=ISO-8859-1 Cc: hackers@freebsd.org Subject: Re: southbridge recognition X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 22:02:21 -0000 Can you look at the device/vendor IDs of pci device 0:31:0? That's always worked for me, but I've only ever done it on Intel platforms so I'm not sure if it works on AMD chipsets. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 9 22:35:09 2010 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 CC8CA106567F for ; Tue, 9 Mar 2010 22:35:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE0E8FC13 for ; Tue, 9 Mar 2010 22:35:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4F34246B89; Tue, 9 Mar 2010 17:35:09 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9AA548A01F; Tue, 9 Mar 2010 17:35:08 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 9 Mar 2010 17:27:09 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> In-Reply-To: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003091727.09188.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 09 Mar 2010 17:35:08 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kevin Day Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 09 Mar 2010 22:35:09 -0000 On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote: > > I'm troubleshooting a pretty weird problem with running FreeBSD 8.0 (amd64) inside VMware ESX/ESXi servers. We've got a wide range of physical servers running identical copies of VMware and identical FreeBSD virtual machines. Everything works fine on all of our servers for Windows and Linux VMs, but FreeBSD running on Opteron 2352 physical servers takes an average of about 20 minutes to boot. Normally I would chalk this up to being a VMware bug, but the situation that's actually occurring is somewhat interesting. > > If I boot up on an Opteron 2218 system, it boots normally. If I boot the exact same VM moved to a 2352, I get: > > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > (very long pause) > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > > then booting normally. It's probably worth adding some printfs to narrow down where the pause is happening. This looks to be all during the acpi_attach() routine, so maybe you can start there. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 00:42:05 2010 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 140CB1065729 for ; Wed, 10 Mar 2010 00:42:05 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C455B8FC19 for ; Wed, 10 Mar 2010 00:42:04 +0000 (UTC) Received: by yxe12 with SMTP id 12so1366002yxe.28 for ; Tue, 09 Mar 2010 16:42:04 -0800 (PST) Received: by 10.150.47.11 with SMTP id u11mr228934ybu.140.1268181723915; Tue, 09 Mar 2010 16:42:03 -0800 (PST) Received: from vpn177.ord02.your.org (vpn177.ord02.your.org [204.9.55.177]) by mx.google.com with ESMTPS id 22sm6054134iwn.0.2010.03.09.16.42.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Mar 2010 16:42:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Kevin Day In-Reply-To: <201003091727.09188.jhb@freebsd.org> Date: Tue, 9 Mar 2010 18:42:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> <201003091727.09188.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1077) Cc: freebsd-hackers@freebsd.org Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 00:42:05 -0000 On Mar 9, 2010, at 4:27 PM, John Baldwin wrote: > On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote: >>=20 >>=20 >> If I boot up on an Opteron 2218 system, it boots normally. If I boot = the=20 > exact same VM moved to a 2352, I get: >>=20 >> acpi0: on motherboard >> PCIe: Memory Mapped configuration base @ 0xe0000000 >> (very long pause) >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: [MPSAFE] >> acpi0: [ITHREAD] >>=20 >> then booting normally. >=20 > It's probably worth adding some printfs to narrow down where the pause = is=20 > happening. This looks to be all during the acpi_attach() routine, so = maybe=20 > you can start there. Okay, good pointer. This is what I've narrowed down: acpi_enable_pcie() calls pcie_cfgregopen(). It's called here with = pcie_cfgregopen(0xe0000000, 0, 255). inside pcie_cfgregopen, the pause = starts here: /* XXX: We should make sure this really fits into the direct = map. */ pcie_base =3D (vm_offset_t)pmap_mapdev(base, (maxbus + 1) << = 20); pmap_mapdev calls pmap_mapdev_attr, and in there this evaluates to true: /* * If the specified range of physical addresses fits within the = direct * map window, use the direct map.=20 */ if (pa < dmaplimit && pa + size < dmaplimit) { so we call pmap_change_attr which called pmap_change_attr_locked. It's = changing 0x10000000 bytes starting at 0xffffff00e0000000. The very last = line before returning from pmap_change_attr_locked is: pmap_invalidate_cache_range(base, tmpva); And this is where the delay is. This is calling MFENCE/CLFLUSH in a loop = 8 million times. We actually had a problem with CLFLUSH causing panics = on these same CPUs under Xen, which is partially why we're looking at = VMware now. (see kern/138863). I'm wondering if VMware didn't encounter = the same problem and replace CLFLUSH with a software emulated version = that is far slower... based on the speed is probably invalidating the = entire cache. A quick change to pmap_invalidate_cache_range to just = clear the entire cache if the area being cleared is over 8MB seems to = have fixed it. i.e.: else if (cpu_feature & CPUID_CLFSH) { to else if ((cpu_feature & CPUID_CLFSH) && ((eva-sva) < (2<<22))) { However, I'm a little blurry on if everything leading to this point is = correct. It's ending up with 256MB of memory for the pci area, which = seems really excessive. Is the problem just that it wants room for 256 = busses, or...? Anyone know this code path well enough to know if this is = deviating from the norm? -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 00:56:11 2010 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 A3E6B1065674 for ; Wed, 10 Mar 2010 00:56:11 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by mx1.freebsd.org (Postfix) with ESMTP id 011BE8FC0C for ; Wed, 10 Mar 2010 00:56:10 +0000 (UTC) Received: by ewy28 with SMTP id 28so2109694ewy.13 for ; Tue, 09 Mar 2010 16:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=r7UN/cI/07cVBC9augFIhtWoe3u0waI/Y5vNkCmOOrI=; b=fidbCAm0y85gu7Ipv0kqnepmXaER6XWbggdWFTqIM3zIGM8KJbeqFAZwGq7xkOy9og QHaalwAzEIpRnWJIG9acyT9bjiP36MPPxqDVUJsD4huxMCEswV11lGk9ASb06vOQYHV7 DjzxYBgImdX6AkeKyGCMBoXx6QXRfN9VTzFCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kOvT1cERU1+2Uu15sbmRQmAVGkLtVFvRPXmWsrFxxBubf9U9Kw8muEESyhh8KdafmU V8ZDBj288/ZFpYZLzxYqqwIpvRC+vsLx6b8eDjVWRd//kWQ4E7QY6fEKXceesWco2kCj XQKXq2MDG7qxvKqER1K7d+fFW0ErAk1yuCiRw= MIME-Version: 1.0 Received: by 10.213.99.143 with SMTP id u15mr4438201ebn.86.1268182569788; Tue, 09 Mar 2010 16:56:09 -0800 (PST) In-Reply-To: <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> <201003091727.09188.jhb@freebsd.org> <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> Date: Tue, 9 Mar 2010 19:56:09 -0500 Message-ID: From: Ryan Stone To: Kevin Day Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 00:56:11 -0000 256MB is correct. The PCI standard allows for up to 256 buses, each with up to 32 slots, and each slot can have up to 8 functions. PCIe devices have a full 4096 bytes worth of configuration registers. Multiply all that and you get 256MB. Also, keep in mind that it's not allocating 256MB of memory; it's allocating 256MB of address space and memory-mapping the configuration registers in that space. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 02:57:59 2010 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 8235B106564A for ; Wed, 10 Mar 2010 02:57:59 +0000 (UTC) (envelope-from drsmithy@gmail.com) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1458FC2E for ; Wed, 10 Mar 2010 02:57:58 +0000 (UTC) Received: by ewy28 with SMTP id 28so2133248ewy.13 for ; Tue, 09 Mar 2010 18:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=0JOT8LyGs3gX1QBVJqO1CeocjpbrIvYa/OI09SWqcK0=; b=aE3k+PTX4+YoTyiZdJJW70FT/nDj7wpPqHXJX6Cl6mrar8vHL+ncQwn98hN9hmdzv7 3O/HMJeU8sAobFOG8V2kS/P0H0Eo1G7IInQ1CNXn00aP32ZNyaLogCkKpMu4uxdT/KIE vly+Q7CYEGqmg49SYj75KkAOtB7hZNmu4gtc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l8lKE1PFP6VfXhDXr70nwqR7qL3YqkqAZlqw+Bj/ISsumFMqY81hlmg895wnAxAZVm Btugo0orpqUTNDOuxGE17pvrpQA4p7Z/XSq9g9hquq9lhKy7HNrTygGi3+m9NBxP6PUS 4kMqw3gsP1iewG3MgGUgfi75jlAlUUEb6pEwA= MIME-Version: 1.0 Received: by 10.213.96.203 with SMTP id i11mr499943ebn.9.1268188469993; Tue, 09 Mar 2010 18:34:29 -0800 (PST) Date: Tue, 9 Mar 2010 19:34:29 -0700 Message-ID: <3c6517d51003091834h520f7415t7e657bce3e0f9157@mail.gmail.com> From: Christopher Smith To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: VMDirectPath with FreeBSD 8 VM under ESXi 4.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: Wed, 10 Mar 2010 02:57:59 -0000 I wasn't 100% on where this should go, but -hackers seemed like a reasoned starting point. My overall objective is to setup a ZFS fileserver VM, and for my first attempt I am trying to use VMDirectPath (ie: PCI pass-through) with a FreeBSD 8.0 VM under ESXi 4 to pass-through the moterboard chipset SATA controller (and when I expand in the future, the SAS controller I get). Unfortunately, whenever I add the mapped PCI device to the VM, it powers itself off about halfway through the boot sequence. I have confirmed it's not a fundamental problem by trying Linux and OpenSolaris VMs - both can see the PCI device (an Intel 3420 chipset SATA controller) and the drives attached to it. This problem only occurs with the FreeBSD 8.0 (and 7.3RC2) VMs. I've also tried booting up the FreeBSD installer DVD on the bare hardware, to make sure it's not a problem with that particular controller. The relevant part of the vmware.log that is generated is: Code: Sep 19 05:19:26.676: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple Sep 19 05:19:26.677: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple Sep 19 05:19:26.677: vcpu-0| ASSERT bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266 Sep 19 05:19:30.295: vcpu-0| Backtrace: Sep 19 05:19:30.295: vcpu-0| Backtrace[0] 0x5e521d88 eip 0xbbf58ed Sep 19 05:19:30.295: vcpu-0| Backtrace[1] 0x5e5221c8 eip 0xb7f405c Sep 19 05:19:30.295: vcpu-0| Backtrace[2] 0x5e522218 eip 0xb9cafca Sep 19 05:19:30.295: vcpu-0| Backtrace[3] 0x5e522248 eip 0xb9b929e Sep 19 05:19:30.295: vcpu-0| Backtrace[4] 0x5e5222a8 eip 0xb9e92fd Sep 19 05:19:30.295: vcpu-0| Backtrace[5] 0x5e5222d8 eip 0xb9e9442 Sep 19 05:19:30.295: vcpu-0| Backtrace[6] 0x5e5222e8 eip 0xb9b8c5d Sep 19 05:19:30.295: vcpu-0| Backtrace[7] 0x5e5223c8 eip 0xb8efea1 Sep 19 05:19:30.295: vcpu-0| Backtrace[8] 0x5e5224b8 eip 0x173a24fb Sep 19 05:19:30.295: vcpu-0| Backtrace[9] 00000000 eip 0x17489e3e Sep 19 05:19:30.295: vcpu-0| SymBacktrace[0] 0x5e521d88 eip 0xbbf58ed in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[1] 0x5e5221c8 eip 0xb7f405c in function Panic in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[2] 0x5e522218 eip 0xb9cafca in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[3] 0x5e522248 eip 0xb9b929e in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[4] 0x5e5222a8 eip 0xb9e92fd in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[5] 0x5e5222d8 eip 0xb9e9442 in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[6] 0x5e5222e8 eip 0xb9b8c5d in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[7] 0x5e5223c8 eip 0xb8efea1 in function (null) in object /bin/vmx loaded at 0xb795000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[8] 0x5e5224b8 eip 0x173a24fb in function (null) in object /lib/libpthread.so.0 loaded at 0x1739d000 Sep 19 05:19:30.295: vcpu-0| SymBacktrace[9] 00000000 eip 0x17489e3e in function clone in object /lib/libc.so.6 loaded at 0x173b8000 Sep 19 05:19:30.295: vcpu-0| Msg_Post: Error Sep 19 05:19:30.295: vcpu-0| [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-0) Sep 19 05:19:30.295: vcpu-0| ASSERT bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266 Sep 19 05:19:30.295: vcpu-0| [msg.panic.haveLog] A log file is available in "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD 8.0/vmware.log". [msg.panic.haveCore] A core file is available in "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD 8.0/vmx-zdump.003". [msg.panic.requestSupport.withLogAndCore] Please request support and include the contents of the log file and core file. [msg.panic.requestSupport.vmSupport.vmx86] Sep 19 05:19:30.296: vcpu-0| To collect data to submit to VMware support, run "vm-support". Sep 19 05:19:30.296: vcpu-0| [msg.panic.response] We will respond on the basis of your support entitlement. Sep 19 05:19:30.296: vcpu-0| ---------------------------------------- Sep 19 05:19:30.396: vmx| VTHREAD watched thread 4 "vcpu-0" died Sep 19 05:19:30.498: mks| VTHREAD watched thread 0 "vmx" died Sep 19 05:19:30.804: vcpu-1| VTHREAD watched thread 0 "vmx" died The troubleshooting steps I have already tried are: * Using only a single vCPU * Choosing "ACPI Disabled" from the boot menu * Choosing "Safe Mode" from the boot menu There seems to be at least one other person having this problem (http://communities.vmware.com/message/1490705), and given it is a very different PCI device, it seems to me this is probably a generic issue using PCi passthrough and FreeBSD. Does anyone out there have any ideas ? Cheers, CS From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 04:01:42 2010 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 3FD45106564A for ; Wed, 10 Mar 2010 04:01:42 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id EFA3A8FC1D for ; Wed, 10 Mar 2010 04:01:41 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o2A41dTo099227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Mar 2010 22:01:40 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o2A41dh5000216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Mar 2010 22:01:39 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o2A41dkd000193; Tue, 9 Mar 2010 22:01:39 -0600 (CST) (envelope-from dan) Date: Tue, 9 Mar 2010 22:01:38 -0600 From: Dan Nelson To: Christopher Smith Message-ID: <20100310040138.GI12122@dan.emsphone.com> References: <3c6517d51003091834h520f7415t7e657bce3e0f9157@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c6517d51003091834h520f7415t7e657bce3e0f9157@mail.gmail.com> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 09 Mar 2010 22:01:40 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-hackers@freebsd.org Subject: Re: VMDirectPath with FreeBSD 8 VM under ESXi 4.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: Wed, 10 Mar 2010 04:01:42 -0000 In the last episode (Mar 09), Christopher Smith said: > I wasn't 100% on where this should go, but -hackers seemed like a reasoned > starting point. > > My overall objective is to setup a ZFS fileserver VM, and for my first > attempt I am trying to use VMDirectPath (ie: PCI pass-through) with a > FreeBSD 8.0 VM under ESXi 4 to pass-through the moterboard chipset SATA > controller (and when I expand in the future, the SAS controller I get). > Unfortunately, whenever I add the mapped PCI device to the VM, it powers > itself off about halfway through the boot sequence. > > I have confirmed it's not a fundamental problem by trying Linux and > OpenSolaris VMs - both can see the PCI device (an Intel 3420 chipset SATA > controller) and the drives attached to it. This problem only occurs with > the FreeBSD 8.0 (and 7.3RC2) VMs. > > I've also tried booting up the FreeBSD installer DVD on the bare hardware, > to make sure it's not a problem with that particular controller. > > The relevant part of the vmware.log that is generated is: > Code: > > Sep 19 05:19:26.676: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple > Sep 19 05:19:26.677: vcpu-0| PCIPassthru: 000:31.2 : barSize: 2048 is not pgsize multiple > Sep 19 05:19:26.677: vcpu-0| ASSERT bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266 > Sep 19 05:19:30.295: vcpu-0| Backtrace: > Sep 19 05:19:30.295: vcpu-0| Backtrace[0] 0x5e521d88 eip 0xbbf58ed > Sep 19 05:19:30.295: vcpu-0| Backtrace[1] 0x5e5221c8 eip 0xb7f405c > Sep 19 05:19:30.295: vcpu-0| Backtrace[2] 0x5e522218 eip 0xb9cafca > Sep 19 05:19:30.295: vcpu-0| Backtrace[3] 0x5e522248 eip 0xb9b929e > Sep 19 05:19:30.295: vcpu-0| Backtrace[4] 0x5e5222a8 eip 0xb9e92fd > Sep 19 05:19:30.295: vcpu-0| Backtrace[5] 0x5e5222d8 eip 0xb9e9442 > Sep 19 05:19:30.295: vcpu-0| Backtrace[6] 0x5e5222e8 eip 0xb9b8c5d > Sep 19 05:19:30.295: vcpu-0| Backtrace[7] 0x5e5223c8 eip 0xb8efea1 > Sep 19 05:19:30.295: vcpu-0| Backtrace[8] 0x5e5224b8 eip 0x173a24fb > Sep 19 05:19:30.295: vcpu-0| Backtrace[9] 00000000 eip 0x17489e3e > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[0] 0x5e521d88 eip 0xbbf58ed in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[1] 0x5e5221c8 eip 0xb7f405c in function Panic in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[2] 0x5e522218 eip 0xb9cafca in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[3] 0x5e522248 eip 0xb9b929e in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[4] 0x5e5222a8 eip 0xb9e92fd in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[5] 0x5e5222d8 eip 0xb9e9442 in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[6] 0x5e5222e8 eip 0xb9b8c5d in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[7] 0x5e5223c8 eip 0xb8efea1 in function (null) in object /bin/vmx loaded at 0xb795000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[8] 0x5e5224b8 eip 0x173a24fb in function (null) in object /lib/libpthread.so.0 loaded at 0x1739d000 > Sep 19 05:19:30.295: vcpu-0| SymBacktrace[9] 00000000 eip 0x17489e3e in function clone in object /lib/libc.so.6 loaded at 0x173b8000 > Sep 19 05:19:30.295: vcpu-0| Msg_Post: Error > Sep 19 05:19:30.295: vcpu-0| [msg.log.error.unrecoverable] VMware ESX > unrecoverable error: (vcpu-0) > Sep 19 05:19:30.295: vcpu-0| ASSERT > bora/vmcore/vmx/main/physMem.c:2148 bugNr=254266 > Sep 19 05:19:30.295: vcpu-0| [msg.panic.haveLog] A log file is > available in "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD > 8.0/vmware.log". [msg.panic.haveCore] A core file is available in > "/vmfs/volumes/4aaf3595-47d35fcc-a053-0030489f04bf/FreeBSD > 8.0/vmx-zdump.003". [msg.panic.requestSupport.withLogAndCore] Please > request support and include the contents of the log file and core > file. [msg.panic.requestSupport.vmSupport.vmx86] > Sep 19 05:19:30.296: vcpu-0| To collect data to submit to VMware > support, run "vm-support". > Sep 19 05:19:30.296: vcpu-0| [msg.panic.response] We will respond on > the basis of your support entitlement. Looks like you crashed VMWare. That shouldn't happen. Send the log and core file to VMWare support and they should be able to help you. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 09:30:01 2010 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 BD6B31065672 for ; Wed, 10 Mar 2010 09:30:01 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A73A48FC1F for ; Wed, 10 Mar 2010 09:30:01 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 617331A3C4D; Wed, 10 Mar 2010 01:30:01 -0800 (PST) Date: Wed, 10 Mar 2010 01:30:01 -0800 From: Alfred Perlstein To: Ed Schouten , hackers@freebsd.org Message-ID: <20100310093001.GL22317@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: tty or script(1) weirdness? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 09:30:01 -0000 Hey Ed, Hackers I've been experiencing a weird issue where when I invoke a program via script and it exits after much output, it seems to have its output truncated. The data winds up not on the screen or in the log file. I have a link here to a set of scripts that will easily provoke this issue. The shell script "test.sh" calls the perl script under "script" then makes sure that the expected number of characters are emitted. If you run "test.sh" with an argument, it will have the perl script "sleep(1)", then you will not see the problem. As a stop-gap, I'm probably going to add the sleep(1) to my code at work, but I'm worried that: 1) I'm dumb and am doing something really silly and ought to be mocked for it. :) 2) Something is broken in the tty system? 3) Script has more bugs than I had originally thoughts. Anyhow, to test this: 1) download the suite. 2) run "sh test.sh" to see the bug 3) run "sh test.sh yes" to not see the bug (sleep called) Here's a link to the scripts: http://www.mu.org/~bright/scripttest/ -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 11:28:01 2010 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 0F0EA106566B; Wed, 10 Mar 2010 11:28:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 42F788FC0C; Wed, 10 Mar 2010 11:27:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o2ABRrFD000812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 13:27:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o2ABRru7082765; Wed, 10 Mar 2010 13:27:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o2ABRrwt082764; Wed, 10 Mar 2010 13:27:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Mar 2010 13:27:53 +0200 From: Kostik Belousov To: Kevin Day Message-ID: <20100310112753.GW2489@deviant.kiev.zoral.com.ua> References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> <201003091727.09188.jhb@freebsd.org> <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrCuQK91QKw8CgBg" Content-Disposition: inline In-Reply-To: <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 11:28:01 -0000 --nrCuQK91QKw8CgBg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 09, 2010 at 06:42:02PM -0600, Kevin Day wrote: >=20 > On Mar 9, 2010, at 4:27 PM, John Baldwin wrote: >=20 > > On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote: > >>=20 > >>=20 > >> If I boot up on an Opteron 2218 system, it boots normally. If I boot t= he=20 > > exact same VM moved to a 2352, I get: > >>=20 > >> acpi0: on motherboard > >> PCIe: Memory Mapped configuration base @ 0xe0000000 > >> (very long pause) > >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > >> acpi0: [MPSAFE] > >> acpi0: [ITHREAD] > >>=20 > >> then booting normally. > >=20 > > It's probably worth adding some printfs to narrow down where the pause = is=20 > > happening. This looks to be all during the acpi_attach() routine, so m= aybe=20 > > you can start there. >=20 > Okay, good pointer. This is what I've narrowed down: >=20 > acpi_enable_pcie() calls pcie_cfgregopen(). It's called here with pcie_cf= gregopen(0xe0000000, 0, 255). inside pcie_cfgregopen, the pause starts here: >=20 > /* XXX: We should make sure this really fits into the direct map.= */ > pcie_base =3D (vm_offset_t)pmap_mapdev(base, (maxbus + 1) << 20); >=20 > pmap_mapdev calls pmap_mapdev_attr, and in there this evaluates to true: >=20 > /* > * If the specified range of physical addresses fits within the d= irect > * map window, use the direct map.=20 > */ > if (pa < dmaplimit && pa + size < dmaplimit) { >=20 > so we call pmap_change_attr which called pmap_change_attr_locked. It's ch= anging 0x10000000 bytes starting at 0xffffff00e0000000. The very last line= before returning from pmap_change_attr_locked is: >=20 > pmap_invalidate_cache_range(base, tmpva); >=20 > And this is where the delay is. This is calling MFENCE/CLFLUSH in a loop = 8 million times. We actually had a problem with CLFLUSH causing panics on t= hese same CPUs under Xen, which is partially why we're looking at VMware no= w. (see kern/138863). I'm wondering if VMware didn't encounter the same pro= blem and replace CLFLUSH with a software emulated version that is far slowe= r... based on the speed is probably invalidating the entire cache. A quick = change to pmap_invalidate_cache_range to just clear the entire cache if the= area being cleared is over 8MB seems to have fixed it. i.e.: >=20 > else if (cpu_feature & CPUID_CLFSH) { >=20 > to >=20 > else if ((cpu_feature & CPUID_CLFSH) && ((eva-sva) < (2<<22))) { >=20 >=20 > However, I'm a little blurry on if everything leading to this point is co= rrect. It's ending up with 256MB of memory for the pci area, which seems re= ally excessive. Is the problem just that it wants room for 256 busses, or..= .? Anyone know this code path well enough to know if this is deviating from= the norm? I think that the idea not to for CLFLUSH in the loop for large regions is good. We do not extract the L2/L3 cache size now, I suppose that 2MB estimation is good for most situations. commit bbac1632d349d68b905df644656ce9a8e4aed094 Author: Konstantin Belousov Date: Wed Mar 10 13:07:51 2010 +0200 Fall back to wbinvd when region for CLFLUSH is >=3D 2MB. =20 Submitted by: Kevin Day diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 07db5d1..4361be0 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -994,7 +994,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_= t eva) =20 if (cpu_feature & CPUID_SS) ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { + else if ((cpu_feature & CPUID_CLFSH) !=3D 0 && + eva - sva < 2 * 1024 * 1024) { =20 /* * Otherwise, do per-cache line flush. Use the mfence @@ -1011,7 +1012,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offse= t_t eva) =20 /* * No targeted cache flush methods are supported by CPU, - * globally invalidate cache as a last resort. + * or the supplied range is bigger then 2MB. + * Globally invalidate cache. */ pmap_invalidate_cache(); } diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c index 4b2e34f..f448071 100644 --- a/sys/i386/i386/pmap.c +++ b/sys/i386/i386/pmap.c @@ -996,7 +996,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_= t eva) =20 if (cpu_feature & CPUID_SS) ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { + else if ((cpu_feature & CPUID_CLFSH) !=3D 0 && + eva - sva < 2 * 1024 * 1024) { =20 /* * Otherwise, do per-cache line flush. Use the mfence @@ -1013,7 +1014,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offse= t_t eva) =20 /* * No targeted cache flush methods are supported by CPU, - * globally invalidate cache as a last resort. + * or the supplied range is bigger then 2MB. + * Globally invalidate cache. */ pmap_invalidate_cache(); } --nrCuQK91QKw8CgBg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuXgjgACgkQC3+MBN1Mb4h9bgCdHEWAhJgy8etu0V/25HzAUReT HAQAoOg1b0P04PSDQgGlbHb4Xz+bpXSv =A58O -----END PGP SIGNATURE----- --nrCuQK91QKw8CgBg-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 12:11:53 2010 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 39DF8106564A for ; Wed, 10 Mar 2010 12:11:53 +0000 (UTC) (envelope-from ryu.planka@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id C46AF8FC19 for ; Wed, 10 Mar 2010 12:11:52 +0000 (UTC) Received: by bwz8 with SMTP id 8so4176433bwz.3 for ; Wed, 10 Mar 2010 04:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=r4LdHKk4P7No/9GSI3u0B/oYmCVejykO6b9D3NaaSCo=; b=hOL3Vv1DzJZdoB04l0Mw/PinJcqj4PnsE7O688DoojcF45reuY6kZ3rY4Civml6QEV CEWO8XYkwLCF9VeLCPGs8ci89ZO56Lz10yg1lr+jopORsQ8DJAWgwn+dZ5QQLkMExsG/ Rn2CZswv69z7x0ww0HW8Ba6yS75oJC1FqRRJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F6wVU92Hg1q4HPXB2yE8IFM+CYYSQBmKMRrSG4g0SQDmYcvRYTUld2rUQFI9iwu+QP jvDAoRz2xJdsIo40hUL+RsIS5WHNunkQAOafK37qTQC5HGRyz6Mn+eMC5XkgA2nRLbbs POYv8i0OMIRs+ByoKLAZnuSwr0pZP5TBX24U0= MIME-Version: 1.0 Received: by 10.204.131.210 with SMTP id y18mr1496680bks.100.1268221218576; Wed, 10 Mar 2010 03:40:18 -0800 (PST) Date: Wed, 10 Mar 2010 13:40:18 +0200 Message-ID: From: son goku To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: physio and vmapbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 12:11:53 -0000 Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf->b_data was updated according to buf->b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 13:15:26 2010 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 6BD4E106566C for ; Wed, 10 Mar 2010 13:15:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 97E818FC08 for ; Wed, 10 Mar 2010 13:15:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13651; Wed, 10 Mar 2010 15:00:54 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B979805.8090504@icyb.net.ua> Date: Wed, 10 Mar 2010 15:00:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Ryan Stone , volker@vwsoft.com References: <4B96BB82.5090805@vwsoft.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: southbridge recognition X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 13:15:26 -0000 on 10/03/2010 00:02 Ryan Stone said the following: > Can you look at the device/vendor IDs of pci device 0:31:0? That's > always worked for me, but I've only ever done it on Intel platforms so > I'm not sure if it works on AMD chipsets. I think that better yet is to examine vendor of device 0:0:0. Something like: dev = pci_find_bsf(0, 0, 0); pci_get_vendorid(dev); With all the checks and stuff. Please keep in mind that there could be other vendors too (e.g. nvidia). Also, access to the upper RTC NVRAM bank may be disabled in chipset configuration. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 13:27:17 2010 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 7CA04106566C for ; Wed, 10 Mar 2010 13:27:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC558FC12 for ; Wed, 10 Mar 2010 13:27:16 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13955; Wed, 10 Mar 2010 15:27:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B979E31.1050509@icyb.net.ua> Date: Wed, 10 Mar 2010 15:27:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: volker@vwsoft.com References: <4B96BB82.5090805@vwsoft.com> In-Reply-To: <4B96BB82.5090805@vwsoft.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------060602050004030601060907" Cc: hackers@freebsd.org Subject: Re: southbridge recognition X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 13:27:17 -0000 This is a multi-part message in MIME format. --------------060602050004030601060907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 09/03/2010 23:20 volker@vwsoft.com said the following: > Hi! > > For some driver enhancements, I need to decide (by code) which > southbridge (Intel, AMD is all that matters) the driver is facing. > > What's the best (portable wise) way to distinguish the chipset? > > Intel supports two pages of 128 byte CMOS RAM, AMD supports 1 page of > 256 byte (addressing is different). > > Is there any way to query the CMOS RAM size? I failed to find a way > while reading Intel & AMD chipset documentation. Older chipsets > supported only 64 (very old) or 128 byte. Recent (as of for the last 15 > years or so) chipsets supports more. > > As our current nvram(4) driver only works with 128 byte RAM size, is > anybody interested in seeing the nvram(4) driver enhanced for extended > memory areas? I do have working code but that assumes an Intel ICH or > 440LX chipset (fails for SB{67]xx for some reason :). > > Thank you for any pointers! Volker, BTW, I have a couple of local patches/hacks for this myself. But without any auto detection. Maybe you could find some bits of them useful. piix4-rtc-nvram-quirk.diff - enables access to upper 128 bytes on PIIX4 (440BX) systems in chipset configuration intel-rtc-nvram.diff - enables access to upper 128 bytes, Intel way dev-nvram.diff - changes behavior of /dev/nvram to what is more convenient for me, breaks compatibility with existing apps using it (if any by now): 1) bytes are counted from offset zero, not 14, but the first 14 bytes (RTC status and control) are always 0xff 2) checksum is not recalculated, it's left for userland to do (not all systems might want to do that in old BIOS way) amd-cmos-nvram.diff - enables access to upper 128 bytes, AMD way Two last patches are on top of the intel-rtc-nvram.diff patch, not against the clean tree. -- Andriy Gapon --------------060602050004030601060907 Content-Type: text/plain; name="piix4-rtc-nvram-quirk.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="piix4-rtc-nvram-quirk.diff" diff --git a/sys/dev/pci/fixup_pci.c b/sys/dev/pci/fixup_pci.c index 13fc4b1..566e503 100644 --- a/sys/dev/pci/fixup_pci.c +++ b/sys/dev/pci/fixup_pci.c @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); static int fixup_pci_probe(device_t dev); static void fixwsc_natoma(device_t dev); static void fixc1_nforce2(device_t dev); +static void fixrtc_piix4(device_t dev); static device_method_t fixup_pci_methods[] = { /* Device interface */ @@ -77,6 +78,9 @@ fixup_pci_probe(device_t dev) case 0x12378086: /* Intel 82440FX (Natoma) */ fixwsc_natoma(dev); break; + case 0x71108086: /* Intel PIIX4 */ + fixrtc_piix4(dev); + break; case 0x01e010de: /* nVidia nForce2 */ fixc1_nforce2(dev); break; @@ -105,6 +109,21 @@ fixwsc_natoma(device_t dev) #endif } +/* Enable access to upper 128-byte bank of RTC NVRAM */ +static void +fixrtc_piix4(device_t dev) +{ + uint8_t rtccfg; + + rtccfg = pci_read_config(dev, 0xcb, 1); + if (!(rtccfg & 0x04)) { + printf("Enabling access to RTC NVRAM upper 128-byte extended bank\n"); + rtccfg |= 0x04; + pci_write_config(dev, 0xcb, rtccfg, 1); + } +} + + /* * Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work * around a hang that is triggered when the CPU generates a very fast --------------060602050004030601060907 Content-Type: text/plain; name="intel-rtc-nvram.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intel-rtc-nvram.diff" diff --git a/sys/dev/nvram/nvram.c b/sys/dev/nvram/nvram.c index 164287e..7c323f7 100644 --- a/sys/dev/nvram/nvram.c +++ b/sys/dev/nvram/nvram.c @@ -53,7 +53,7 @@ */ #define NVRAM_FIRST RTC_DIAG /* 14 */ -#define NVRAM_LAST 128 +#define NVRAM_LAST 256 #define CKSUM_FIRST 2 #define CKSUM_LAST 31 @@ -113,6 +113,7 @@ nvram_write(struct cdev *dev, struct uio *uio, int flags) u_char v; int error = 0; int i; + int recalc = 0; uint16_t sum; sx_xlock(&nvram_lock); @@ -129,20 +130,24 @@ nvram_write(struct cdev *dev, struct uio *uio, int flags) /* Bring in user data and write */ while (uio->uio_resid > 0 && error == 0) { nv_off = uio->uio_offset + NVRAM_FIRST; - if (nv_off < NVRAM_FIRST || nv_off >= NVRAM_LAST) { - sx_xunlock(&nvram_lock); - return (0); /* Signal EOF */ - } + if (nv_off < NVRAM_FIRST || nv_off >= NVRAM_LAST) + break; + if (nv_off >= (NVRAM_FIRST + CKSUM_FIRST) + && nv_off <= (NVRAM_FIRST + CKSUM_LAST)) + recalc = 1; + /* Single byte at a time */ error = uiomove(&v, 1, uio); writertc(nv_off, v); } /* Recalculate checksum afterwards */ - sum = 0; - for (i = CKSUM_FIRST; i <= CKSUM_LAST; i++) - sum += rtcin(NVRAM_FIRST + i); - writertc(NVRAM_FIRST + CKSUM_MSB, sum >> 8); - writertc(NVRAM_FIRST + CKSUM_LSB, sum); + if (recalc) { + sum = 0; + for (i = CKSUM_FIRST; i <= CKSUM_LAST; i++) + sum += rtcin(NVRAM_FIRST + i); + writertc(NVRAM_FIRST + CKSUM_MSB, sum >> 8); + writertc(NVRAM_FIRST + CKSUM_LSB, sum); + } sx_xunlock(&nvram_lock); return (error); } diff --git a/sys/isa/rtc.h b/sys/isa/rtc.h index 018a4ed..43a9c15 100644 --- a/sys/isa/rtc.h +++ b/sys/isa/rtc.h @@ -115,12 +115,12 @@ extern struct mtx clock_lock; extern int atrtcclock_disable; int atrtc_setup_clock(void); -int rtcin(int reg); +u_char rtcin(u_char reg); void atrtc_start(void); void atrtc_rate(unsigned rate); void atrtc_enable_intr(void); void atrtc_restore(void); -void writertc(int reg, u_char val); +void writertc(u_char reg, u_char val); #endif #endif /* _I386_ISA_RTC_H_ */ diff --git a/sys/x86/isa/atrtc.c b/sys/x86/isa/atrtc.c index 777c720..9f9f0ac 100644 --- a/sys/x86/isa/atrtc.c +++ b/sys/x86/isa/atrtc.c @@ -59,35 +59,51 @@ static u_char rtc_statusb = RTCSB_24HR; * RTC support routines */ -int -rtcin(int reg) +u_char +rtcin(u_char reg) { u_char val; + int idxr; + int datr; + + if (reg & 0x80) + idxr = IO_RTC + 2; /* upper bank */ + else + idxr = IO_RTC; /* lower bank */ + datr = idxr + 1; RTC_LOCK; if (rtc_reg != reg) { inb(0x84); - outb(IO_RTC, reg); + outb(idxr, reg & 0x7f); rtc_reg = reg; inb(0x84); } - val = inb(IO_RTC + 1); + val = inb(datr); RTC_UNLOCK; return (val); } void -writertc(int reg, u_char val) +writertc(u_char reg, u_char val) { + int idxr; + int datr; + + if (reg & 0x80) + idxr = IO_RTC + 2; /* upper bank */ + else + idxr = IO_RTC; /* lower bank */ + datr = idxr + 1; RTC_LOCK; if (rtc_reg != reg) { inb(0x84); - outb(IO_RTC, reg); + outb(idxr, reg & 0x7f); rtc_reg = reg; inb(0x84); } - outb(IO_RTC + 1, val); + outb(datr, val); inb(0x84); RTC_UNLOCK; } --------------060602050004030601060907 Content-Type: text/plain; name="dev-nvram.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dev-nvram.diff" diff --git a/sys/dev/nvram/nvram.c b/sys/dev/nvram/nvram.c index 7c323f7..716f4b9 100644 --- a/sys/dev/nvram/nvram.c +++ b/sys/dev/nvram/nvram.c @@ -39,33 +39,15 @@ #include -/* - * Linux-style /dev/nvram driver - * - * cmos ram starts at bytes 14 through 128, for a total of 114 bytes. - * The driver exposes byte 14 as file offset 0. - * - * Offsets 2 through 31 are checksummed at offset 32, 33. - * In order to avoid the possibility of making the machine unbootable at the - * bios level (press F1 to continue!), we refuse to allow writes if we do - * not see a pre-existing valid checksum. If the existing sum is invalid, - * then presumably we do not know how to make a sum that the bios will accept. - */ #define NVRAM_FIRST RTC_DIAG /* 14 */ -#define NVRAM_LAST 256 - -#define CKSUM_FIRST 2 -#define CKSUM_LAST 31 -#define CKSUM_MSB 32 -#define CKSUM_LSB 33 +#define NVRAM_LAST 0xff static d_open_t nvram_open; static d_read_t nvram_read; static d_write_t nvram_write; static struct cdev *nvram_dev; -static struct sx nvram_lock; static struct cdevsw nvram_cdevsw = { .d_version = D_VERSION, @@ -94,12 +76,19 @@ nvram_read(struct cdev *dev, struct uio *uio, int flags) u_char v; int error = 0; + if (uio->uio_offset < 0) + return 0; + while (uio->uio_resid > 0 && error == 0) { - nv_off = uio->uio_offset + NVRAM_FIRST; - if (nv_off < NVRAM_FIRST || nv_off >= NVRAM_LAST) + nv_off = uio->uio_offset; + if (nv_off > NVRAM_LAST) return (0); /* Signal EOF */ + /* Single byte at a time */ - v = rtcin(nv_off); + if (nv_off < NVRAM_FIRST) + v = 0xff; + else + v = rtcin(nv_off); error = uiomove(&v, 1, uio); } return (error); @@ -112,44 +101,28 @@ nvram_write(struct cdev *dev, struct uio *uio, int flags) int nv_off; u_char v; int error = 0; - int i; - int recalc = 0; - uint16_t sum; - - sx_xlock(&nvram_lock); - - /* Assert that we understand the existing checksum first! */ - sum = rtcin(NVRAM_FIRST + CKSUM_MSB) << 8 | - rtcin(NVRAM_FIRST + CKSUM_LSB); - for (i = CKSUM_FIRST; i <= CKSUM_LAST; i++) - sum -= rtcin(NVRAM_FIRST + i); - if (sum != 0) { - sx_xunlock(&nvram_lock); - return (EIO); - } + + if (uio->uio_offset < 0) + return 0; + /* Bring in user data and write */ - while (uio->uio_resid > 0 && error == 0) { - nv_off = uio->uio_offset + NVRAM_FIRST; - if (nv_off < NVRAM_FIRST || nv_off >= NVRAM_LAST) - break; - if (nv_off >= (NVRAM_FIRST + CKSUM_FIRST) - && nv_off <= (NVRAM_FIRST + CKSUM_LAST)) - recalc = 1; + while (uio->uio_resid > 0) { + nv_off = uio->uio_offset; + if (nv_off > NVRAM_LAST) + return (0); /* Single byte at a time */ error = uiomove(&v, 1, uio); + if (error) + return (error); + + if (nv_off < NVRAM_FIRST) + continue; + writertc(nv_off, v); } - /* Recalculate checksum afterwards */ - if (recalc) { - sum = 0; - for (i = CKSUM_FIRST; i <= CKSUM_LAST; i++) - sum += rtcin(NVRAM_FIRST + i); - writertc(NVRAM_FIRST + CKSUM_MSB, sum >> 8); - writertc(NVRAM_FIRST + CKSUM_LSB, sum); - } - sx_xunlock(&nvram_lock); - return (error); + + return (0); } static int @@ -157,14 +130,12 @@ nvram_modevent(module_t mod __unused, int type, void *data __unused) { switch (type) { case MOD_LOAD: - sx_init(&nvram_lock, "nvram"); nvram_dev = make_dev(&nvram_cdevsw, 0, UID_ROOT, GID_KMEM, 0640, "nvram"); break; case MOD_UNLOAD: case MOD_SHUTDOWN: destroy_dev(nvram_dev); - sx_destroy(&nvram_lock); break; default: return (EOPNOTSUPP); --------------060602050004030601060907 Content-Type: text/plain; name="amd-cmos-nvram.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="amd-cmos-nvram.diff" diff --git a/sys/amd64/conf/NOTES b/sys/amd64/conf/NOTES index 8b56e54..d18736e 100644 --- a/sys/amd64/conf/NOTES +++ b/sys/amd64/conf/NOTES @@ -86,6 +86,11 @@ options BPF_JITTER # Provide read/write access to the memory in the clock chip. device nvram # Access to rtc cmos via /dev/nvram +# Whether 72h/73h access to RTC NVRAM should use 7-bit index and +# access only 128 bytes of upper bank (Intel chipsets) or it can +# use 8-bit index and access all 256 bytes of NVRAM (AMD chipsets). +#options RTC_8BIT_EXTINDEX + ##################################################################### # MISCELLANEOUS DEVICES AND OPTIONS diff --git a/sys/conf/options.amd64 b/sys/conf/options.amd64 index 5617da4..30af3cc 100644 --- a/sys/conf/options.amd64 +++ b/sys/conf/options.amd64 @@ -61,3 +61,6 @@ KDTRACE_FRAME opt_kdtrace.h BPF_JITTER opt_bpf.h XENHVM opt_global.h + +# ISA options +RTC_8BIT_EXTINDEX opt_isa.h diff --git a/sys/conf/options.i386 b/sys/conf/options.i386 index 83f8286..a4ce060 100644 --- a/sys/conf/options.i386 +++ b/sys/conf/options.i386 @@ -117,3 +117,7 @@ BPF_JITTER opt_bpf.h NATIVE opt_global.h XEN opt_global.h + +# ISA options +RTC_8BIT_EXTINDEX opt_isa.h + diff --git a/sys/i386/conf/NOTES b/sys/i386/conf/NOTES index af3da83..4fb11ae 100644 --- a/sys/i386/conf/NOTES +++ b/sys/i386/conf/NOTES @@ -261,6 +261,11 @@ options BPF_JITTER # Provide read/write access to the memory in the clock chip. device nvram # Access to rtc cmos via /dev/nvram +# Whether 72h/73h access to RTC NVRAM should use 7-bit index and +# access only 128 bytes of upper bank (Intel chipsets) or it can +# use 8-bit index and access all 256 bytes of NVRAM (AMD chipsets). +#options RTC_8BIT_EXTINDEX + ##################################################################### # MISCELLANEOUS DEVICES AND OPTIONS diff --git a/sys/x86/isa/atrtc.c b/sys/x86/isa/atrtc.c index 9f9f0ac..a77e14c 100644 --- a/sys/x86/isa/atrtc.c +++ b/sys/x86/isa/atrtc.c @@ -75,7 +75,11 @@ rtcin(u_char reg) RTC_LOCK; if (rtc_reg != reg) { inb(0x84); +#ifndef RTC_8BIT_EXTINDEX outb(idxr, reg & 0x7f); +#else + outb(idxr, reg); +#endif rtc_reg = reg; inb(0x84); } @@ -99,7 +103,11 @@ writertc(u_char reg, u_char val) RTC_LOCK; if (rtc_reg != reg) { inb(0x84); +#ifndef RTC_8BIT_EXTINDEX outb(idxr, reg & 0x7f); +#else + outb(idxr, reg); +#endif rtc_reg = reg; inb(0x84); } --------------060602050004030601060907-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 13:32:29 2010 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 B50CE1065675 for ; Wed, 10 Mar 2010 13:32:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 452678FC0A for ; Wed, 10 Mar 2010 13:32:28 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o2ADWOhB014284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 15:32:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o2ADWOxk083677; Wed, 10 Mar 2010 15:32:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o2ADWOim083676; Wed, 10 Mar 2010 15:32:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Mar 2010 15:32:24 +0200 From: Kostik Belousov To: son goku Message-ID: <20100310133224.GA2489@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IxlmieUzCzCqf3CN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: physio and vmapbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 13:32:29 -0000 --IxlmieUzCzCqf3CN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2010 at 01:40:18PM +0200, son goku wrote: > Hi hackers, > I have some experience with other UNIX kernels but none with FreeBSD. > FreeBSD interests me for a potential project I might be involved in , and > therefore I started researching it. > Browsing through the I/O layer code, I stumbled upon something that looked > strange, and perhaps you guys can help me with it. > Mainly, when reading the physio path, when the I/O buffer is from user-mo= de, > physio calls vmapbuf. The comments says that vmapbuf actually maps the > user-buffer into kernel address space. From my experience, such mapping is > needed only for very old devices that use PIO. Newer device just use DMA = for > data copy, and therefore don't need the mapping, instead they just need to > pin the memory. Checking out vmapbuf only confused me further, I couldn't > find where such kernel mapping was taken place, nevertheless I did saw th= at > the buf->b_data was updated according to buf->b_saveaddr in some weird > offset calculation. > Adding to this confusion, there is a buf field called b_kvabase which > supposedly stores the kernel virtual address which wasn't touched at all!! >=20 > Any help with understanding the flow and the usage of those fields/variab= les > will be greatly appreciated!! For normal VMIO buffers, b_kvabase is provided on the buffer initialization, see getnewbuf() and allocbuf(). b_saveaddr is initialized equial to b_kvabase. But note that physio uses pbufs, that are essentially buffer header and some reserved kva space. Note the bp =3D getpbuf(NULL); sa =3D bp->b_data; at the start of physio(), and then bp->b_saveaddr =3D sa; later at the buffer set up. vmapbuf() looks up the pages using vm_fault_quick()/pmap_extract_and_hold() loop, and then maps the pages into pbuf kva by pmap_qenter(). --IxlmieUzCzCqf3CN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuXn2cACgkQC3+MBN1Mb4g6PACfRQhCUjG0Zh4jf+ycymPc1Xiw GQgAn3Xw6LqplAY0+/3S7RgADjvzq/dI =SAjw -----END PGP SIGNATURE----- --IxlmieUzCzCqf3CN-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 13:49:30 2010 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 E0DE2106566B for ; Wed, 10 Mar 2010 13:49:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B64DE8FC08 for ; Wed, 10 Mar 2010 13:49:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 71D1846B1A; Wed, 10 Mar 2010 08:49:30 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 967008A01F; Wed, 10 Mar 2010 08:49:29 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 10 Mar 2010 07:53:14 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003100753.14092.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Mar 2010 08:49:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: son goku Subject: Re: physio and vmapbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 13:49:31 -0000 On Wednesday 10 March 2010 6:40:18 am son goku wrote: > Hi hackers, > I have some experience with other UNIX kernels but none with FreeBSD. > FreeBSD interests me for a potential project I might be involved in , and > therefore I started researching it. > Browsing through the I/O layer code, I stumbled upon something that looked > strange, and perhaps you guys can help me with it. > Mainly, when reading the physio path, when the I/O buffer is from user-mode, > physio calls vmapbuf. The comments says that vmapbuf actually maps the > user-buffer into kernel address space. From my experience, such mapping is > needed only for very old devices that use PIO. Newer device just use DMA for > data copy, and therefore don't need the mapping, instead they just need to > pin the memory. Checking out vmapbuf only confused me further, I couldn't > find where such kernel mapping was taken place, nevertheless I did saw that > the buf->b_data was updated according to buf->b_saveaddr in some weird > offset calculation. > Adding to this confusion, there is a buf field called b_kvabase which > supposedly stores the kernel virtual address which wasn't touched at all!! > > Any help with understanding the flow and the usage of those fields/variables > will be greatly appreciated!! bus_dma (which drivers use to manage DMA), still uses virtual addressed buffers to build scatter/gather lists of physical addresses for DMA transfers. There has been much discussion and some prototype work to change this, but it's not a trivial project. (I have converted physio to using bio's backed by sglist's with no kernel addresses in a prototype branch in p4 for example.) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 13:49:35 2010 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 3FD87106566C for ; Wed, 10 Mar 2010 13:49:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F23618FC18 for ; Wed, 10 Mar 2010 13:49:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8CB9346B85; Wed, 10 Mar 2010 08:49:34 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B54DA8A01F; Wed, 10 Mar 2010 08:49:33 -0500 (EST) From: John Baldwin To: Kostik Belousov Date: Wed, 10 Mar 2010 08:17:07 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> <20100310112753.GW2489@deviant.kiev.zoral.com.ua> In-Reply-To: <20100310112753.GW2489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003100817.07277.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Mar 2010 08:49:33 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Kevin Day Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 13:49:35 -0000 On Wednesday 10 March 2010 6:27:53 am Kostik Belousov wrote: > On Tue, Mar 09, 2010 at 06:42:02PM -0600, Kevin Day wrote: > > > > On Mar 9, 2010, at 4:27 PM, John Baldwin wrote: > > > > > On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote: > > >> > > >> > > >> If I boot up on an Opteron 2218 system, it boots normally. If I boot the > > > exact same VM moved to a 2352, I get: > > >> > > >> acpi0: on motherboard > > >> PCIe: Memory Mapped configuration base @ 0xe0000000 > > >> (very long pause) > > >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > > >> acpi0: [MPSAFE] > > >> acpi0: [ITHREAD] > > >> > > >> then booting normally. > > > > > > It's probably worth adding some printfs to narrow down where the pause is > > > happening. This looks to be all during the acpi_attach() routine, so maybe > > > you can start there. > > > > Okay, good pointer. This is what I've narrowed down: > > > > acpi_enable_pcie() calls pcie_cfgregopen(). It's called here with pcie_cfgregopen(0xe0000000, 0, 255). inside pcie_cfgregopen, the pause starts here: > > > > /* XXX: We should make sure this really fits into the direct map. */ > > pcie_base = (vm_offset_t)pmap_mapdev(base, (maxbus + 1) << 20); > > > > pmap_mapdev calls pmap_mapdev_attr, and in there this evaluates to true: > > > > /* > > * If the specified range of physical addresses fits within the direct > > * map window, use the direct map. > > */ > > if (pa < dmaplimit && pa + size < dmaplimit) { > > > > so we call pmap_change_attr which called pmap_change_attr_locked. It's changing 0x10000000 bytes starting at 0xffffff00e0000000. The very last line before returning from pmap_change_attr_locked is: > > > > pmap_invalidate_cache_range(base, tmpva); > > > > And this is where the delay is. This is calling MFENCE/CLFLUSH in a loop 8 million times. We actually had a problem with CLFLUSH causing panics on these same CPUs under Xen, which is partially why we're looking at VMware now. (see kern/138863). I'm wondering if VMware didn't encounter the same problem and replace CLFLUSH with a software emulated version that is far slower... based on the speed is probably invalidating the entire cache. A quick change to pmap_invalidate_cache_range to just clear the entire cache if the area being cleared is over 8MB seems to have fixed it. i.e.: > > > > else if (cpu_feature & CPUID_CLFSH) { > > > > to > > > > else if ((cpu_feature & CPUID_CLFSH) && ((eva-sva) < (2<<22))) { > > > > > > However, I'm a little blurry on if everything leading to this point is correct. It's ending up with 256MB of memory for the pci area, which seems really excessive. Is the problem just that it wants room for 256 busses, or...? Anyone know this code path well enough to know if this is deviating from the norm? > > I think that the idea not to for CLFLUSH in the loop for large regions > is good. We do not extract the L2/L3 cache size now, I suppose that 2MB > estimation is good for most situations. > > commit bbac1632d349d68b905df644656ce9a8e4aed094 > Author: Konstantin Belousov > Date: Wed Mar 10 13:07:51 2010 +0200 > > Fall back to wbinvd when region for CLFLUSH is >= 2MB. > > Submitted by: Kevin Day This looks good to me. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 14:54:04 2010 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 E1C94106566B for ; Wed, 10 Mar 2010 14:54:04 +0000 (UTC) (envelope-from ryu.planka@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 62FD88FC1C for ; Wed, 10 Mar 2010 14:54:04 +0000 (UTC) Received: by bwz8 with SMTP id 8so4325327bwz.3 for ; Wed, 10 Mar 2010 06:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=J4UjZ+y3Ea3aZOUi2pk7p2Mx7dXm6+Uou3XS5mcKUTE=; b=o6Wa0wu1m2uKtF+RPqrav4HOPJSB5j1tBSnylMGmKm8j1q0JCO7IH4uZU53vHiaFAP PgHvn108nqSTt8AKl/1H5MZu4l4c58hYKcNT8OoSzZqM82/nKFauWz9ZLYEEagABzjhD s4GdFrianlPI28FSNXN5swlehGcjfe1knbOKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=d665zSjU15oDadh5oi66LUypcc4/WaoL7jQiC7Ou0XphfENiJvQtoGR3KMNkzMQC/A sB7zf2sqlyf+V7ZZzubTWi6nIukwhnbLhkRXfFy+OQtaJ3jWlQS8jfKSQDBPKemAZT52 zn7mAobd8ZaQlklQTcDZ2YbIGOYcjSmY052/w= MIME-Version: 1.0 Received: by 10.204.5.154 with SMTP id 26mr1848406bkv.62.1268232843285; Wed, 10 Mar 2010 06:54:03 -0800 (PST) In-Reply-To: <201003100753.14092.jhb@freebsd.org> References: <201003100753.14092.jhb@freebsd.org> Date: Wed, 10 Mar 2010 16:54:03 +0200 Message-ID: From: son goku To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: physio and vmapbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 14:54:05 -0000 Thx John for the information. Seems weird to me that FreeBSD still requires kernel mapping. There must be some performance hit due to the additional mapping which are not really needed (devices after all mostly deal with bus relative address space which is usually plain physical addresses unless there is some IOMMU). I know for sure that most modern UNIX OS, and even Windows don't generate those mapping unless the driver asked for it explicitly. I guess this is noticeable only for raw I/O from user-mode, all other IO clients (such as file-system) are kernel based so this shouldn't be an issue. I now wonder whether FreeBSD is often used for running high-performance database which use user-mode raw I/O... Many thanks, Goku. On Wed, Mar 10, 2010 at 2:53 PM, John Baldwin wrote: > On Wednesday 10 March 2010 6:40:18 am son goku wrote: > > Hi hackers, > > I have some experience with other UNIX kernels but none with FreeBSD. > > FreeBSD interests me for a potential project I might be involved in , and > > therefore I started researching it. > > Browsing through the I/O layer code, I stumbled upon something that > looked > > strange, and perhaps you guys can help me with it. > > Mainly, when reading the physio path, when the I/O buffer is from > user-mode, > > physio calls vmapbuf. The comments says that vmapbuf actually maps the > > user-buffer into kernel address space. From my experience, such mapping > is > > needed only for very old devices that use PIO. Newer device just use DMA > for > > data copy, and therefore don't need the mapping, instead they just need > to > > pin the memory. Checking out vmapbuf only confused me further, I couldn't > > find where such kernel mapping was taken place, nevertheless I did saw > that > > the buf->b_data was updated according to buf->b_saveaddr in some weird > > offset calculation. > > Adding to this confusion, there is a buf field called b_kvabase which > > supposedly stores the kernel virtual address which wasn't touched at > all!! > > > > Any help with understanding the flow and the usage of those > fields/variables > > will be greatly appreciated!! > > bus_dma (which drivers use to manage DMA), still uses virtual addressed > buffers to build scatter/gather lists of physical addresses for DMA > transfers. > There has been much discussion and some prototype work to change this, but > it's not a trivial project. (I have converted physio to using bio's backed > by > sglist's with no kernel addresses in a prototype branch in p4 for example.) > > -- > John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 16:58:27 2010 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 C39AD106566C for ; Wed, 10 Mar 2010 16:58:27 +0000 (UTC) (envelope-from prvs=16855aad97=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 58A198FC14 for ; Wed, 10 Mar 2010 16:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1268239684; x=1268844484; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=BxsJkbeULe069vy77LtcG6IZU7b1DamXQI 2E+YaND7o=; b=GhBacuyXA52rMmPIMV9xuG97ihD/4vF2ASgoFRSEiuLAIgxLXd cPzGni0C0HLkHDDLx+K6KX4Hjy2KdNeHKqmSmVpLIRIEES5lN1Rvsf8oALQkEB5Q B+6sJGInGm3pcpw2Cn22+WMPBG4d3jtmHR4fE65Ycr3zIMgIixo8t3Mr4= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 10 Mar 2010 16:48:04 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009579409.msg for ; Wed, 10 Mar 2010 16:48:04 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 10 Mar 2010 16:48:04 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.96 X-Return-Path: prvs=16855aad97=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 10 Mar 2010 16:47:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 16:58:27 -0000 Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. The problem with looking for info on this is that a lot of the high listed articles in Google etc are from way back when, 2000 - 2007 during which time quite a bit can change. So what are peoples current day experience with the two options? A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? 2. Is postfix that much easier? 3. What would people use for: 3.1. POP / IMAP support? 3.2. Web Mail? 3.2. AV / Spam filtering? Any advice, opinions on a full mail solution on FreeBSD would be appreciated. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 17:02:31 2010 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 A6F971065674 for ; Wed, 10 Mar 2010 17:02:31 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 71BEE8FC14 for ; Wed, 10 Mar 2010 17:02:31 +0000 (UTC) Received: (qmail 42955 invoked from network); 10 Mar 2010 17:02:30 -0000 Received: from unknown (HELO ?10.0.0.170?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 10 Mar 2010 17:02:30 -0000 Message-ID: <4B97D097.5020500@acm.poly.edu> Date: Wed, 10 Mar 2010 12:02:15 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: Steven Hartland References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 17:02:31 -0000 Steven Hartland wrote: > Ok so I'm looking to replace our current windows mail > server using mdaemon with a FreeBSD solution, having > looked around there seems to be differing opinions > of which is the best option to go with between sendmail > and postfix. > > The problem with looking for info on this is that a > lot of the high listed articles in Google etc are > from way back when, 2000 - 2007 during which time > quite a bit can change. > > So what are peoples current day experience with the > two options? > > A few key question come to mind:- > 1. Has sendmail's config moved away from the black art > it once was? > 2. Is postfix that much easier? > 3. What would people use for: > 3.1. POP / IMAP support? > 3.2. Web Mail? > 3.2. AV / Spam filtering? > > Any advice, opinions on a full mail solution on FreeBSD > would be appreciated. > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" I'm happily using qmail for several years (but that's not what you asked about), Dovecot for POP3 and IMAP, and Roundcube for webmail. -Boris From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 17:54:55 2010 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 1AA6A1065676 for ; Wed, 10 Mar 2010 17:54:55 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id A830B8FC19 for ; Wed, 10 Mar 2010 17:54:48 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so431375qwi.7 for ; Wed, 10 Mar 2010 09:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=650nq7xHhMBZha6QUufhYUDYWXQTJKzABEIC4Zx6j4g=; b=gJqdzYNSYqUxr7BJcUhT+jpx2wGJSf4ZpFGxgibpcNSgnluMAkuFx7IIraoDh8KkAk 65c/TloQMchgU8NhvbOI8MBFFX3MwiCvpMUnFv3hDihjfvjrARyrzrCtdT9ofcgwV0V3 ZKMPwAgigzA5j6I9cDQBbmwK0rM4WlqsHlR0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=r/je4bf/Aly3TkSqDsNFlMEcZAgJh8zQhbZ6ltDcOaM04/pzNCBTkxeyBQq30XEwwD r00yRc8kdp5At3+05eNmonNmZX5V4GUfzTwuGiEdQMlcZn1R2pPpqftTn+GQnatNegLQ cnAXNDZGmwjWbq0RKyzU9Ku2eNTXnwDo0f6A0= MIME-Version: 1.0 Received: by 10.229.38.74 with SMTP id a10mr762857qce.103.1268243684042; Wed, 10 Mar 2010 09:54:44 -0800 (PST) Date: Wed, 10 Mar 2010 23:24:43 +0530 Message-ID: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 17:54:55 -0000 Just trying to understand the build dependency for ctfconvert... I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a (cddl/lib/libctf/) Now the snippet in bsd.lib.mk has this check for various target suffixes, .c.So: .if defined(CTFCONVERT) ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} .endif and sys.mk .c .if defined(CTFCONVERT) ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} .endif My query, libctf includes in it's Makefile, so will the above not try to run 'ctfconvert' on libctf itself? From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 18:07:29 2010 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 5AE721065678 for ; Wed, 10 Mar 2010 18:07:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFC68FC16 for ; Wed, 10 Mar 2010 18:07:29 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2AI7STC020594; Wed, 10 Mar 2010 10:07:28 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id F1ABC2D601E; Wed, 10 Mar 2010 10:07:27 -0800 (PST) Message-ID: <4B97DFDE.10302@elischer.org> Date: Wed, 10 Mar 2010 10:07:26 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: son goku References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org Subject: Re: physio and vmapbuf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 18:07:29 -0000 son goku wrote: > Hi hackers, > I have some experience with other UNIX kernels but none with FreeBSD. > FreeBSD interests me for a potential project I might be involved in , and > therefore I started researching it. > Browsing through the I/O layer code, I stumbled upon something that looked > strange, and perhaps you guys can help me with it. > Mainly, when reading the physio path, when the I/O buffer is from user-mode, > physio calls vmapbuf. The comments says that vmapbuf actually maps the > user-buffer into kernel address space. From my experience, such mapping is > needed only for very old devices that use PIO. yes, though to some of us that is relatively recent, and in fact we still need PIO mode for quite a few devices in the embedded space. (I have a soekris machine with a flash card that I need to use PIO mode to reach). We have been saying for some time (me personally for about 18 years) that we need to handle unmapped IO better. I don't believe that it has been done yet (*), but you certainly sound like the right person to take on that project :-) (*) I last looked at physio a few years ago so if someone snuck in unmapped IO in the mean-while, please excuse me. > Newer device just use DMA for > data copy, and therefore don't need the mapping, instead they just need to > pin the memory. Checking out vmapbuf only confused me further, I couldn't > find where such kernel mapping was taken place, nevertheless I did saw that > the buf->b_data was updated according to buf->b_saveaddr in some weird > offset calculation. > Adding to this confusion, there is a buf field called b_kvabase which > supposedly stores the kernel virtual address which wasn't touched at all!! > > Any help with understanding the flow and the usage of those fields/variables > will be greatly appreciated!! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 18:40:02 2010 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 40B01106564A for ; Wed, 10 Mar 2010 18:40:02 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7368FC17 for ; Wed, 10 Mar 2010 18:40:01 +0000 (UTC) Received: from park.js.berklix.net (p549A669A.dip.t-dialin.net [84.154.102.154]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o2AIdqLD093456; Wed, 10 Mar 2010 18:39:53 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o2AIdimD015671; Wed, 10 Mar 2010 19:39:44 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o2AIdSTL001004; Wed, 10 Mar 2010 19:39:34 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201003101839.o2AIdSTL001004@fire.js.berklix.net> To: Boris Kochergin From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 10 Mar 2010 12:02:15 EST." <4B97D097.5020500@acm.poly.edu> Date: Wed, 10 Mar 2010 19:39:28 +0100 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org, Steven Hartland Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 18:40:02 -0000 > > 3.1. POP / IMAP support? > about), Dovecot for POP3 and IMAP, and Roundcube for webmail. My servers use: - sendmail, I've not tried things such as qmail. One doesnt generally have to futz much with .cf files, (but its useful to look at & tweak the easy bits, even if some of the lower rules are magic not for mortals ;-) Sendmail uses .mc via m4 (I keep all my .mc in a single .cpp) http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/sendmail/common.cpp - /usr/ports/mail/openwebmail for webmail I'm happy with it, but I've not tried others. - /usr/ports/mail/popd /usr/local/libexec/popd (Installed but not tried popt-1.7_1 qpopper-2.53_5) With /usr/ports/mail/popd on 3 servers 1 x FreeBSD-6.3 popd-2.2.2a_4 2 x FreeBSD-7.2 popd-2.2.2a_4 I have definately received periodic data corruption, but never tracked it down to report it, I first noticed on multi meg gpg bins that wouldnt decrypt (prob one doesnt notice when people send eg pictures or .pdf or .wmv ) PS 1 I have notes on SASL with URLs to other pages. http://www.berklix.com/~jhs/txt/sasl.lmth & I run majordomo, 'cos long ago I got bitten by & reported a bug in mailman that would lock up a slowish server. http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/mail/mailman/files/ PPS I guess maybe this thread might have better started on isp@freebsd.org, but too late to move there now I suppose. You've raised interesting questions, I look forward to reading what others use. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 18:41:53 2010 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 59176106566B; Wed, 10 Mar 2010 18:41:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 20AF48FC17; Wed, 10 Mar 2010 18:41:53 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 6634E1CD0C; Wed, 10 Mar 2010 19:41:52 +0100 (CET) Date: Wed, 10 Mar 2010 19:41:52 +0100 From: Ed Schouten To: Alfred Perlstein Message-ID: <20100310184152.GF8200@hoeg.nl> References: <20100310093001.GL22317@elvis.mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PyVBLkVRa/gQBUbw" Content-Disposition: inline In-Reply-To: <20100310093001.GL22317@elvis.mu.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: tty or script(1) weirdness? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 18:41:53 -0000 --PyVBLkVRa/gQBUbw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alfred, * Alfred Perlstein wrote: > 1) download the suite. > 2) run "sh test.sh" to see the bug > 3) run "sh test.sh yes" to not see the bug (sleep called) Hmmm... It seems this is a TTY bug. When you close a TTY, the final close() call should get stuck until all data is actually drained. This doesn't seem to happen properly. You can easily test this by performing a tcdrain() right after running your perl script: #include | int | main(int argc, char *argv[]) | { |=20 | tcdrain(0); | } I'll see what I can do. --=20 Ed Schouten WWW: http://80386.nl/ --PyVBLkVRa/gQBUbw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuX5/AACgkQ52SDGA2eCwWA8gCfSTlqSQfoE0fK0kL35xTscdVD FWsAn0OvE3D8r03afpO4ddVhcdip4+DJ =esZ+ -----END PGP SIGNATURE----- --PyVBLkVRa/gQBUbw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 18:47:09 2010 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 EC48F1065673 for ; Wed, 10 Mar 2010 18:47:09 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7A61F8FC1D for ; Wed, 10 Mar 2010 18:47:09 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so846328fga.13 for ; Wed, 10 Mar 2010 10:47:08 -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=4haQxnnj3mPiy/2q4O/6oTGznF34am96JmD9zhtVAyo=; b=sWrI47PIBB9XOtR7iHx7FzHzdsSqtTr4G6L1Ue2WEXig+pFs3SL0f1hLLdqWu5jPeQ +vL9N3PeS5BY3f8DD0X9AYw6VOg7ZnP+lV+QL6oTyvR6HpeTicFL0iSq4gIxUhztqfS1 CZtsHz8ghklo18l0u6XsbGOD+DMyCE0QoabN4= 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=iYtIhCQEvK61mDlUs1WOES2Z58hunKrZW8Hb6Gxnlha3zGyhaUw8bum4odD2F7Iu9t rGC1TG68khEz2tvHM2E7r+TzdCxkBMu7cnz8NFlfaqdqgd9f+KSfYEYMg05nj458Q16v RM/K3R6fakcESkNv5c7MmLOH4pWwnyJDbMzX8= Received: by 10.87.15.14 with SMTP id s14mr2017301fgi.8.1268245240182; Wed, 10 Mar 2010 10:20:40 -0800 (PST) Received: from [172.16.0.7] ([85.198.160.156]) by mx.google.com with ESMTPS id 15sm1235217fxm.12.2010.03.10.10.20.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 10:20:38 -0800 (PST) Message-ID: <4B97E2F2.70704@gmail.com> Date: Wed, 10 Mar 2010 20:20:34 +0200 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Steven Hartland References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 18:47:10 -0000 Steven Hartland wrote: > A few key question come to mind:- > 1. Has sendmail's config moved away from the black art > it once was? No. > 2. Is postfix that much easier? Yes. > 3. What would people use for: > 3.1. POP / IMAP support? Dovecot. As a bonus, Postfix can use Dovecot's SASL for authentication. > 3.2. Web Mail? Don't use it, sorry. > 3.2. AV / Spam filtering? I can't recommend a spam filter, but greytrapping via mail/spamd is a blessing: it catches 100% of spam on my (low-volume) mail server. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 19:08:16 2010 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 3BEE3106564A for ; Wed, 10 Mar 2010 19:08:16 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id E25A48FC17 for ; Wed, 10 Mar 2010 19:08:15 +0000 (UTC) Received: from localhost (overdrive.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 10 Mar 2010 13:58:11 -0500 id 0003F405.000000004B97EBC3.00013490 Date: Wed, 10 Mar 2010 13:58:11 -0500 From: Bill Moran To: Vitaly Magerya Message-Id: <20100310135811.6f766c6c.wmoran@collaborativefusion.com> In-Reply-To: <4B97E2F2.70704@gmail.com> References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B97E2F2.70704@gmail.com> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Steven Hartland Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 19:08:16 -0000 In response to Vitaly Magerya : > > > 3.2. Web Mail? > > Don't use it, sorry. I recommend squirrelmail. Unless you require some obscene feature-rich craziness (in that case, have fun installing IMP). I've used it with Postfix/Dovecot for a few years now with no trouble. Why is this discussion on hackers@? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 19:08:46 2010 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 8F7B11065674; Wed, 10 Mar 2010 19:08:46 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.211.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1B38FC12; Wed, 10 Mar 2010 19:08:45 +0000 (UTC) Received: by ywh5 with SMTP id 5so279564ywh.13 for ; Wed, 10 Mar 2010 11:08:44 -0800 (PST) Received: by 10.101.155.19 with SMTP id h19mr1481281ano.43.1268248124630; Wed, 10 Mar 2010 11:08:44 -0800 (PST) Received: from vpn177.ord02.your.org (vpn177.ord02.your.org [204.9.55.177]) by mx.google.com with ESMTPS id 21sm6922265iwn.15.2010.03.10.11.08.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 11:08:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Kevin Day In-Reply-To: <20100310112753.GW2489@deviant.kiev.zoral.com.ua> Date: Wed, 10 Mar 2010 13:08:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C7A849F-2571-48E7-AA75-B6F87C2352C1@dragondata.com> <201003091727.09188.jhb@freebsd.org> <207B4180-B8AF-4C93-8BC7-7F1FFEEBB713@dragondata.com> <20100310112753.GW2489@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1077) Cc: freebsd-hackers@freebsd.org Subject: Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 19:08:46 -0000 On Mar 10, 2010, at 5:27 AM, Kostik Belousov wrote: > I think that the idea not to for CLFLUSH in the loop for large regions > is good. We do not extract the L2/L3 cache size now, I suppose that = 2MB > estimation is good for most situations. >=20 > commit bbac1632d349d68b905df644656ce9a8e4aed094 Thanks for everyone's help. This has actually increased the boot up = speed of all of our Opteron based boxes through VMware ESX. I'll report = the problem to VMware, but I'm betting this is a side effect of the = CLFLUSH problems in virtualized Opteron machines that they worked around = with a much slower function. -- Kevin =20= From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 19:12:19 2010 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 0B44A106566C for ; Wed, 10 Mar 2010 19:12:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id A7C9D8FC25 for ; Wed, 10 Mar 2010 19:12:18 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 50C63A56870; Thu, 11 Mar 2010 03:12:17 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id PoQwZXM81+xM; Thu, 11 Mar 2010 03:12:07 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 86047A5680B; Thu, 11 Mar 2010 03:12: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=CBBzVvMN0XwuoL4EqB31stlys6r8+MvYdscpwYAbhgjwZ9v7YxrmIlbm8O9XZ0PId liLehb6TL5qCqtJS+QBcQ== Message-ID: <4B97EF02.8040905@delphij.net> Date: Wed, 10 Mar 2010 11:12:02 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Steven Hartland References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; 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: To sendmail or to postfix that is the question? 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, 10 Mar 2010 19:12:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/03/10 08:47, Steven Hartland wrote: > A few key question come to mind:- > 1. Has sendmail's config moved away from the black art > it once was? No, but the m4 based configuration would make your life easier. > 2. Is postfix that much easier? Yes, I would highly recommend using postfix if you don't want to spend a lot of time on mail server. As a bonus postfix have better track record in terms of security. > 3. What would people use for: > 3.1. POP / IMAP support? Dovecot or cyrus-imapd. I'd personally recommend dovecot for new deployments, since it supports features like using different storage for different subfolders (i.e. use Mailbox for archive, etc). > 3.2. Web Mail? Connecting from IMAP: squirrelmail, roundcube, etc., I'm not a big fan of web mail though. > 3.2. AV / Spam filtering? amavisd-new + clamav. Note that clamav is somewhat CPU hungry if you have high e-mail volume, consider deploying multiple layer of delivery system (multiple MX serving anti-spam purpose, and deliver to a group of backend system; this could be an overkill for small to medium sized companies, though). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLl+8CAAoJEATO+BI/yjfBX1wIAJgT8QPLi7H2iS2RBJ8J2JDr 62ngaY0q099b8ajCgiIPWm7IMyvlEyIf3FVde9tbQls2UiojDkJR8Frd/rNGBfja mF/6tMSs77skN3vyoZzX1hj98rMbLx7ccPUwzZTFxgOsoRXpFKu+V+t9TDfqiRh5 3gSBlyinqTuoQzpO9PPjRACzY0sZLtTsyy2GoX52HeSjKn4kh2SogTcf1I9Y/+cq Eap91F4J8vKmqHh4Eqm5qAJ+WT2JwkwQpnHAjG6bej4x05kmNE6OLT7O83dip1Ga RzafJRgCPIgkSeh7f/v+rCv653jxSNswo1kJ+6HfDKkUc4l+naoP+ZKL1bo2RKo= =G5Ri -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 19:32:01 2010 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 1B05D106564A for ; Wed, 10 Mar 2010 19:32:01 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id EAF918FC08 for ; Wed, 10 Mar 2010 19:32:00 +0000 (UTC) Received: (qmail 30826 invoked from network); 10 Mar 2010 19:32:00 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Mar 2010 19:32:00 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 25A7C50886; Wed, 10 Mar 2010 14:31:59 -0500 (EST) From: Lowell Gilbert To: "Steven Hartland" References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> Date: Wed, 10 Mar 2010 14:31:59 -0500 In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> (Steven Hartland's message of "Wed, 10 Mar 2010 16:47:57 -0000") Message-ID: <444okoc6s0.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 10 Mar 2010 19:40:32 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 19:32:01 -0000 "Steven Hartland" writes: > A few key question come to mind:- > 1. Has sendmail's config moved away from the black art > it once was? Somewhat. The configurations are done with m4 these days, but there's a lot of black magic possible with the many potential combinations of features and options. > 2. Is postfix that much easier? Yes. However, the black magic in sendmail is very powerful. > 3. What would people use for: > 3.1. POP / IMAP support? Separate problem. I use dovecot and I like it, but it's just a household server. > 3.2. Web Mail? I don't do that, because I don't want to go to the effort of making sure it is and stays secure, but from what I hear I'd probably try squirrelmail first if I were doing it. > 3.2. AV / Spam filtering? I use spamassassin. You can plug most other analyzers into it. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 20:04:11 2010 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 71B6E1065673; Wed, 10 Mar 2010 20:04:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 12DCD8FC18; Wed, 10 Mar 2010 20:04:11 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 22BE21CD0C; Wed, 10 Mar 2010 21:04:10 +0100 (CET) Date: Wed, 10 Mar 2010 21:04:10 +0100 From: Ed Schouten To: Alfred Perlstein Message-ID: <20100310200410.GG8200@hoeg.nl> References: <20100310093001.GL22317@elvis.mu.org> <20100310184152.GF8200@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+n6TW4Th6de8VKLL" Content-Disposition: inline In-Reply-To: <20100310184152.GF8200@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers Subject: Re: tty or script(1) weirdness? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 20:04:11 -0000 --+n6TW4Th6de8VKLL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > Hmmm... It seems this is a TTY bug. When you close a TTY, the final > close() call should get stuck until all data is actually drained. This > doesn't seem to happen properly. Some further research: it's not a TTY bug, but a bug in script(1). The script parent process leaves a file descriptor open, which means output is never properly drained. I can't reproduce this issue after applying this patch: %%% Index: script.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- script.c (revision 204965) +++ script.c (working copy) @@ -158,6 +158,8 @@ } if (child =3D=3D 0) doshell(argv); + else + close(slave); =20 if (flushtime > 0) tvp =3D &tv; %%% --=20 Ed Schouten WWW: http://80386.nl/ --+n6TW4Th6de8VKLL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuX+zoACgkQ52SDGA2eCwVbYwCfUTBou5Vzo+E4KNt9YHYiNACh OJAAniGffxBvByrof+uLZhqp+Pix6Bzg =9+gw -----END PGP SIGNATURE----- --+n6TW4Th6de8VKLL-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 21:50:41 2010 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 4AF95106566B; Wed, 10 Mar 2010 21:50:41 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id A305A8FC08; Wed, 10 Mar 2010 21:50:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,616,1262559600"; d="scan'208";a="28112451" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 10 Mar 2010 22:50:38 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id C68421B07C1; Wed, 10 Mar 2010 22:50:38 +0100 (CET) Date: Wed, 10 Mar 2010 22:50:38 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Jaakko Heinonen , Message-ID: In-Reply-To: <20100305055758.GA1062@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Poul-Henning Kamp , Bruce Evans Subject: Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2010 21:50:41 -0000 Jaakko Heinonen schrieb am 2010-03-05: > On 2010-02-28, Jaakko Heinonen wrote: > > > > http://people.freebsd.org/~jh/patches/lookup-root.diff > I have updated the patch taking some of bde's comments into account. > The > new version also includes updates for namei(9) manual page. could this panic have been triggered by the patch? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x12 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8048af0f stack pointer = 0x28:0xffffff8040495000 frame pointer = 0x28:0xffffff8040495020 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1402 (sh) Tracing pid 1402 tid 100092 td 0xffffff000729d000 strlen() at strlen+0x1f kvprintf() at kvprintf+0x1027 vsnprintf() at vsnprintf+0x48 panic() at panic+0x15f _mtx_lock_flags() at _mtx_lock_flags+0xc5 fdesc_allocvp() at fdesc_allocvp+0xbf fdesc_lookup() at fdesc_lookup+0x15c VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x11c VOP_LOOKUP() at VOP_LOOKUP+0x45 lookup() at lookup+0x8cf namei() at namei+0x730 vn_open_cred() at vn_open_cred+0x114 vn_open() at vn_open+0x55 kern_openat() at kern_openat+0x178 kern_open() at kern_open+0x3e open() at open+0x26 syscall() at syscall+0x2a7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x8009a3bec, rsp = 0x7fffffffd3c8, rbp = 0x800e143b0 --- this was 100% reducible when doing `portsnap fetch` though i changed a lot of stuff in my kernel config and reverted a lot of src patches to resolve the issue so i'm not sure what exactly was causing it. cheers. alex > The patch is attached to this mail and also found at: > http://people.freebsd.org/~jh/patches/lookup-root.2.diff From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 23:42:20 2010 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 8E7C01065672 for ; Wed, 10 Mar 2010 23:42:20 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id ECD968FC16 for ; Wed, 10 Mar 2010 23:42:19 +0000 (UTC) Received: (qmail invoked by alias); 10 Mar 2010 23:42:18 -0000 Received: from static.kpn.net (EHLO baloo.cs.uni-paderborn.de) [77.60.197.217] by mail.gmx.net (mp049) with SMTP; 11 Mar 2010 00:42:18 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+ZdXgYgQWZffOiz8umo9GLGYtKo1PgP+d14JmHmf 701ugKa/YvPbuH Received: from [127.0.0.1] by baloo.cs.uni-paderborn.de with esmtp (Exim 4.70) (envelope-from ) id KZ3B6G-0004RG-QN for freebsd-hackers@freebsd.org; Thu, 11 Mar 2010 00:42:16 +0100 Message-ID: <4B982E57.2050408@gmx.de> Date: Thu, 11 Mar 2010 00:42:15 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 23:42:20 -0000 Am 10.03.2010 17:47, schrieb Steven Hartland: > Ok so I'm looking to replace our current windows mail > server using mdaemon with a FreeBSD solution, having > looked around there seems to be differing opinions > of which is the best option to go with between sendmail > and postfix. The best -- well, you'll know that with hindsight if you've tried both. > The problem with looking for info on this is that a > lot of the high listed articles in Google etc are > from way back when, 2000 - 2007 during which time > quite a bit can change. > > So what are peoples current day experience with the > two options? > > A few key question come to mind:- > 1. Has sendmail's config moved away from the black art > it once was? > 2. Is postfix that much easier? > 3. What would people use for: > 3.1. POP / IMAP support? > 3.2. Web Mail? > 3.2. AV / Spam filtering? sendmail's configuration was never a black art unless you needed features beyond what the m4 macro set supported. Instead, it was a matter of reading the README file and the "op.*" manual, writing/adjusting the .mc files, and grinding the .mc file through m4 to process it into the .cf files. Postfix can be easier to configure, and I personally prefer it over sendmail -- and it appears to have had fewer and milder security issues and a more security-aware design - and it's been faster in my setups. Still you need to understand what you're doing, and Postfix has evolved into a feature-rich MTA, so you don't get to know it in an hour of reading. I've deployed a few postfix + Dovecot + amavisd-new setups; these systems don't need webmail. I used to use sqwebmail on a few sites. -- Matthias Andree From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 10 23:56:15 2010 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 7B0B4106564A for ; Wed, 10 Mar 2010 23:56:15 +0000 (UTC) (envelope-from prvs=16855aad97=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8FD8FC0C for ; Wed, 10 Mar 2010 23:56:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1268265373; x=1268870173; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=9CO1+Ub4SzY9YeaiaXHoC yZedRnTXCDonDbDx2xGCsI=; b=cgyzCgeL22igDNqqwhWv0avpETskCGDYh8PLl EHXpw4M5LUcESD9qBVGPwX4YQ28bORqGV+VcrRRSgsV/T4N09UEA5PG9mGTchvAZ ptR+QlFY73jenmanQnY9YqefLQVIxMOx7wR6zy2zomPhh/+/xevGzaoehQdy2bwv +4fD+g= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 10 Mar 2010 23:56:13 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009582388.msg for ; Wed, 10 Mar 2010 23:56:13 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 10 Mar 2010 23:56:13 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.96 X-Return-Path: prvs=16855aad97=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <8C03EC5BBF954A80A128DF8EF96E7EDE@multiplay.co.uk> From: "Steven Hartland" To: "Bill Moran" , "Vitaly Magerya" References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk><4B97E2F2.70704@gmail.com> <20100310135811.6f766c6c.wmoran@collaborativefusion.com> Date: Wed, 10 Mar 2010 23:54:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Wed, 10 Mar 2010 23:56:15 -0000 ----- Original Message ----- From: "Bill Moran" > I recommend squirrelmail. Unless you require some obscene feature-rich > craziness (in that case, have fun installing IMP). I've used it with > Postfix/Dovecot for a few years now with no trouble. > > Why is this discussion on hackers@? Couldn't see a really appropriate list tbh, as pointed out though perhaps isp@ would have been better. Thanks for all the feedback and ideas so far :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 08:05:00 2010 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 8B4841065670 for ; Thu, 11 Mar 2010 08:05:00 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by mx1.freebsd.org (Postfix) with ESMTP id 416528FC08 for ; Thu, 11 Mar 2010 08:05:00 +0000 (UTC) Received: by qyk14 with SMTP id 14so4547556qyk.9 for ; Thu, 11 Mar 2010 00:04:59 -0800 (PST) Received: by 10.224.87.66 with SMTP id v2mr1876719qal.343.1268292942068; Wed, 10 Mar 2010 23:35:42 -0800 (PST) Received: from [192.168.1.37] (ppp-58-8-202-189.revip2.asianet.co.th [58.8.202.189]) by mx.google.com with ESMTPS id 23sm6147576qyk.7.2010.03.10.23.35.39 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 23:35:40 -0800 (PST) Message-ID: <4B989DD6.601@pathscale.com> Date: Thu, 11 Mar 2010 14:37:58 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: Shrikanth Kamath References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> In-Reply-To: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 08:05:00 -0000 Shrikanth Kamath wrote: > Just trying to understand the build dependency for ctfconvert... > > I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a > (cddl/lib/libctf/) > > Now the snippet in bsd.lib.mk has this check for various target suffixes, > > .c.So: > .if defined(CTFCONVERT) > ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > .endif > > and sys.mk > > .c > .if defined(CTFCONVERT) > ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > .endif > > My query, libctf includes in it's Makefile, so will the above > not try to > run 'ctfconvert' on libctf itself? > I'm going to make some assumptions and go out on a limb here.. The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg repo) When OpenSolaris is built they convert stab debugging information over to CTF (compressed text format?). This is done so that they can have debugging information, but without the overhead of stab (or dwarf2). I don't know how much of the original onnv-gate Makefiles came over from OpenSolaris, but assuming the FBSD kernel doesn't need/use CTF format this dependency can and probably should go away. (Only (k)mdb supports CTF that I'm aware of?) Hopefully this is useful information and I'm not too wrong or someone will correct me Best, ./C From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:26:40 2010 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 58ECB106564A for ; Thu, 11 Mar 2010 09:26:40 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAE58FC14 for ; Thu, 11 Mar 2010 09:26:39 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so693600qwi.7 for ; Thu, 11 Mar 2010 01:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PkFjFDYqTH9Ect1xQ2PqOQXlJAC7UbYLcA0Nwl3ZKFU=; b=nHsD7qqjVMJLgH7DmPP7vri9JU5KUskgP1fNdeClOVCAnjeBIC1U3DXGcjc0L+D1Iy aefNwze60uhJhcWL+4ccJn0vhC41g3b5IcbqBhyuJz3XiDpz71fnhCjaE2fKYMcQowvR hHQxxEI/grnIbrnMRocLHxBp8m3kjpDUWt9Gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dX6wxjR6Ag3+glzWnqJgsdZTCtPDOESF71ZHL6nok/9yI/qFRVgFxhimt8RoKV9/Dl B54XwJg/uNX/3M0UvzLRvmN75YOJMPazg/PY0ZDWU0lOVoQOSck/BGQcLrCimOOAD171 XrNRbPbcrXrD54eapoS89AA1eep/v+bXsQKtg= MIME-Version: 1.0 Received: by 10.229.211.210 with SMTP id gp18mr218652qcb.31.1268299588459; Thu, 11 Mar 2010 01:26:28 -0800 (PST) In-Reply-To: References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> Date: Thu, 11 Mar 2010 14:56:26 +0530 Message-ID: <291941b81003110126y9640f08oe542938940b0b566@mail.gmail.com> From: Shrikanth Kamath To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, =?ISO-8859-1?B?Qy4gQmVyZ3N0cvZt?= Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:26:40 -0000 Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My understanding here is ctfconvert needs to build the ctfdata for the kernel image and the kernel loadable modules. If we were to DTrace 'DTrace' then we need the ctfdata for the files under cddl/ and sys/cddl, is that correct= ? 2010/3/11 Marius N=FCnnerich > 2010/3/11 "C. Bergstr=F6m" : > > Shrikanth Kamath wrote: > >> > >> Just trying to understand the build dependency for ctfconvert... > >> > >> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.= a > >> (cddl/lib/libctf/) > >> > >> Now the snippet in bsd.lib.mk has this check for various target > suffixes, > >> > >> .c.So: > >> .if defined(CTFCONVERT) > >> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > >> .endif > >> > >> and sys.mk > >> > >> .c > >> .if defined(CTFCONVERT) > >> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} > >> .endif > >> > >> My query, libctf includes in it's Makefile, so will the > >> above > >> not try to > >> run 'ctfconvert' on libctf itself? > >> > > > > I'm going to make some assumptions and go out on a limb here.. > > > > The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg > repo) > > When OpenSolaris is built they convert stab debugging information over > to > > CTF (compressed text format?). This is done so that they can have > debugging > > information, but without the overhead of stab (or dwarf2). I don't kno= w > how > > much of the original onnv-gate Makefiles came over from OpenSolaris, bu= t > > assuming the FBSD kernel doesn't need/use CTF format this dependency ca= n > and > > probably should go away. (Only (k)mdb supports CTF that I'm aware of?) > > > > Hopefully this is useful information and I'm not too wrong or someone > will > > correct me > > The CTF information is needed by DTrace. > My guess is that it will run ctfconvert on itself so it should be > there from a prior install or it is part of some early toolchain > stuff. > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:30:43 2010 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 A8413106566B for ; Thu, 11 Mar 2010 09:30:43 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE2F8FC0A for ; Thu, 11 Mar 2010 09:30:43 +0000 (UTC) Received: by gyf2 with SMTP id 2so479069gyf.13 for ; Thu, 11 Mar 2010 01:30:42 -0800 (PST) Received: by 10.91.63.29 with SMTP id q29mr1969627agk.2.1268299838654; Thu, 11 Mar 2010 01:30:38 -0800 (PST) Received: from [192.168.1.37] (ppp-58-8-202-189.revip2.asianet.co.th [58.8.202.189]) by mx.google.com with ESMTPS id 35sm2479414yxh.15.2010.03.11.01.30.35 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Mar 2010 01:30:37 -0800 (PST) Message-ID: <4B98B8C6.6010309@pathscale.com> Date: Thu, 11 Mar 2010 16:32:54 +0700 From: =?UTF-8?B?IkMuIEJlcmdzdHLDtm0i?= User-Agent: Thunderbird 2.0.0.22 (X11/20090909) MIME-Version: 1.0 To: =?UTF-8?B?TWFyaXVzIE7DvG5uZXJpY2g=?= References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Shrikanth Kamath Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:30:43 -0000 Marius Nünnerich wrote: > 2010/3/11 "C. Bergström" : > >> Shrikanth Kamath wrote: >> >>> Just trying to understand the build dependency for ctfconvert... >>> >>> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a >>> (cddl/lib/libctf/) >>> >>> Now the snippet in bsd.lib.mk has this check for various target suffixes, >>> >>> .c.So: >>> .if defined(CTFCONVERT) >>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .endif >>> >>> and sys.mk >>> >>> .c >>> .if defined(CTFCONVERT) >>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>> .endif >>> >>> My query, libctf includes in it's Makefile, so will the >>> above >>> not try to >>> run 'ctfconvert' on libctf itself? >>> >>> >> I'm going to make some assumptions and go out on a limb here.. >> >> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg repo) >> When OpenSolaris is built they convert stab debugging information over to >> CTF (compressed text format?). This is done so that they can have debugging >> information, but without the overhead of stab (or dwarf2). I don't know how >> much of the original onnv-gate Makefiles came over from OpenSolaris, but >> assuming the FBSD kernel doesn't need/use CTF format this dependency can and >> probably should go away. (Only (k)mdb supports CTF that I'm aware of?) >> >> Hopefully this is useful information and I'm not too wrong or someone will >> correct me >> > > The CTF information is needed by DTrace. > My guess is that it will run ctfconvert on itself so it should be > there from a prior install or it is part of some early toolchain > stuff. > CTF is needed by DTrace where? The build may depend on it, but this is probably for legacy reasons only. DTrace in opensolaris isn't dependent on it to function correctly. Replace the $(CTFCONVERT) and a few other utilities with /bin/true and the build will succeed. (I can only speak first hand from OSUNIX/OpenSolaris though and not FBSD..) From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:35:39 2010 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 C0CDE106566B for ; Thu, 11 Mar 2010 09:35:39 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A88598FC14 for ; Thu, 11 Mar 2010 09:35:39 +0000 (UTC) Received: by pwj4 with SMTP id 4so112170pwj.13 for ; Thu, 11 Mar 2010 01:35:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.202.1 with SMTP id z1mr1268661wff.53.1268298292899; Thu, 11 Mar 2010 01:04:52 -0800 (PST) X-Originating-IP: [196.210.202.6] Date: Thu, 11 Mar 2010 11:04:52 +0200 Message-ID: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> From: Cole To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: bus_space_tag, bus_space_handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:35:39 -0000 Hi. Im currently needing to write to a few registers for a PCI device. The driver is provided, but it does not contain support for writing specific registers itself. I also do not with to modify the driver. I would like to know what the best method would be for writing to these registers, the best way to go about getting bus_space_tag, and handle for the connected pci device. Im currently using FreeBSD 7.x. Regards /Cole From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:40:14 2010 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 0C7C2106566C for ; Thu, 11 Mar 2010 09:40:14 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id B38488FC14 for ; Thu, 11 Mar 2010 09:40:13 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so695835qwi.7 for ; Thu, 11 Mar 2010 01:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xDzdYssMPRNlLAbFPAcbMeK9eKARtQFSHk9atJA2Ls0=; b=IiujqaIJH2FIApBplzZBEijK2dIccqSU/fJhPd3x9RidSaGFdFonvIEtLlKuUIPs+d JtwLE/RkPfn/s/xp6iAeq+UP78dZXX6JnoKhdXbUMrA0TUtvoeOb8ycoqWOs/iBfm5f+ Zvx0w0exafKFNYUC7ydRzphBSDfK5GfEzKRNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Vzr/HkSN3XaeNQFyGMpxjYPNN91i0ZA6OKFPVZ/jfHb69FJgdtm6bUr3X92QMNzLHC dqyggLZY9GlsBdCHkJvAvIMi20hXGM3akKbVeY2LVpVOXT/MXoeS8ZutBoU8KHDpGCln PWMxGaK/DOk4RaTIU6ZUoett6XrY+7GErYlYU= MIME-Version: 1.0 Received: by 10.229.191.76 with SMTP id dl12mr970564qcb.97.1268300412431; Thu, 11 Mar 2010 01:40:12 -0800 (PST) In-Reply-To: <4B98B8C6.6010309@pathscale.com> References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> <4B98B8C6.6010309@pathscale.com> Date: Thu, 11 Mar 2010 15:10:12 +0530 Message-ID: <291941b81003110140h7add81d9w1547b22c9769aca1@mail.gmail.com> From: Shrikanth Kamath To: =?ISO-8859-1?B?Qy4gQmVyZ3N0cvZt?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, =?ISO-8859-1?Q?Marius_N=FCnnerich?= Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:40:14 -0000 This DTrace wiki page mandates the CTF option when enabling DTrace, http://wiki.freebsd.org/DTrace#head-41e7ce9a981893f126bd67c0eb77f388e2213d9= d 2010/3/11 "C. Bergstr=F6m" > Marius N=FCnnerich wrote: > >> 2010/3/11 "C. Bergstr=F6m" : >> >> >>> Shrikanth Kamath wrote: >>> >>> >>>> Just trying to understand the build dependency for ctfconvert... >>>> >>>> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.= a >>>> (cddl/lib/libctf/) >>>> >>>> Now the snippet in bsd.lib.mk has this check for various target >>>> suffixes, >>>> >>>> .c.So: >>>> .if defined(CTFCONVERT) >>>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .endif >>>> >>>> and sys.mk >>>> >>>> .c >>>> .if defined(CTFCONVERT) >>>> ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .endif >>>> >>>> My query, libctf includes in it's Makefile, so will the >>>> above >>>> not try to >>>> run 'ctfconvert' on libctf itself? >>>> >>>> >>>> >>> I'm going to make some assumptions and go out on a limb here.. >>> >>> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg >>> repo) >>> When OpenSolaris is built they convert stab debugging information over >>> to >>> CTF (compressed text format?). This is done so that they can have >>> debugging >>> information, but without the overhead of stab (or dwarf2). I don't kno= w >>> how >>> much of the original onnv-gate Makefiles came over from OpenSolaris, bu= t >>> assuming the FBSD kernel doesn't need/use CTF format this dependency ca= n >>> and >>> probably should go away. (Only (k)mdb supports CTF that I'm aware of?) >>> >>> Hopefully this is useful information and I'm not too wrong or someone >>> will >>> correct me >>> >>> >> >> The CTF information is needed by DTrace. >> My guess is that it will run ctfconvert on itself so it should be >> there from a prior install or it is part of some early toolchain >> stuff. >> >> > CTF is needed by DTrace where? The build may depend on it, but this is > probably for legacy reasons only. DTrace in opensolaris isn't dependent = on > it to function correctly. Replace the $(CTFCONVERT) and a few other > utilities with /bin/true and the build will succeed. (I can only speak > first hand from OSUNIX/OpenSolaris though and not FBSD..) > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:40:39 2010 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 EDB241065675 for ; Thu, 11 Mar 2010 09:40:38 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 928A98FC19 for ; Thu, 11 Mar 2010 09:40:38 +0000 (UTC) Received: by wwb28 with SMTP id 28so155928wwb.13 for ; Thu, 11 Mar 2010 01:40:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.87.66 with SMTP id x44mr838435wee.96.1268300437233; Thu, 11 Mar 2010 01:40:37 -0800 (PST) In-Reply-To: <291941b81003110126y9640f08oe542938940b0b566@mail.gmail.com> References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> <291941b81003110126y9640f08oe542938940b0b566@mail.gmail.com> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Thu, 11 Mar 2010 10:40:17 +0100 Message-ID: To: Shrikanth Kamath Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, =?UTF-8?Q?C=2E_Bergstr=C3=B6m?= Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:40:39 -0000 On Thu, Mar 11, 2010 at 10:26, Shrikanth Kamath wrote: > Any idea if ctfconvert is needed to run on the cddl and sys/cddl files? My > understanding here is ctfconvert > needs to build the ctfdata for the kernel image and the kernel loadable > modules. If we were to DTrace 'DTrace' then > we need the ctfdata for the files under cddl/ and sys/cddl, is that correct? ctf information is needed for everything we want to dtrace. We even need it for tracing userland stuff but that doesn't work right now for other reasons. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:41:23 2010 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 A34AB106567B for ; Thu, 11 Mar 2010 09:41:23 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 462218FC27 for ; Thu, 11 Mar 2010 09:41:23 +0000 (UTC) Received: by wwb28 with SMTP id 28so156296wwb.13 for ; Thu, 11 Mar 2010 01:41:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.200 with SMTP id c50mr1808756wef.164.1268300482277; Thu, 11 Mar 2010 01:41:22 -0800 (PST) In-Reply-To: <4B98B8C6.6010309@pathscale.com> References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> <4B98B8C6.6010309@pathscale.com> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Thu, 11 Mar 2010 10:41:02 +0100 Message-ID: To: =?UTF-8?Q?C=2E_Bergstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Shrikanth Kamath Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:41:23 -0000 2010/3/11 "C. Bergstr=C3=B6m" : > Marius N=C3=BCnnerich wrote: >> >> 2010/3/11 "C. Bergstr=C3=B6m" : >> >>> >>> Shrikanth Kamath wrote: >>> >>>> >>>> Just trying to understand the build dependency for ctfconvert... >>>> >>>> I see ctfconvert (cddl/usr.bin/ctfconvert/) =C2=A0has dependency on li= bctf.a >>>> (cddl/lib/libctf/) >>>> >>>> Now the snippet in bsd.lib.mk has this check for various target >>>> suffixes, >>>> >>>> .c.So: >>>> .if defined(CTFCONVERT) >>>> =C2=A0 =C2=A0 =C2=A0 ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .endif >>>> >>>> and sys.mk >>>> >>>> .c >>>> .if defined(CTFCONVERT) >>>> =C2=A0 =C2=A0 =C2=A0 ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >>>> .endif >>>> >>>> My query, libctf includes =C2=A0 in it's Makefile, so will= the >>>> above >>>> not try to >>>> run 'ctfconvert' on libctf itself? >>>> >>>> >>> >>> I'm going to make some assumptions and go out on a limb here.. >>> >>> The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg >>> repo) >>> =C2=A0When OpenSolaris is built they convert stab debugging information= over >>> to >>> CTF (compressed text format?). =C2=A0This is done so that they can have >>> debugging >>> information, but without the overhead of stab (or dwarf2). =C2=A0I don'= t know >>> how >>> much of the original onnv-gate Makefiles came over from OpenSolaris, bu= t >>> assuming the FBSD kernel doesn't need/use CTF format this dependency ca= n >>> and >>> probably should go away. =C2=A0(Only (k)mdb supports CTF that I'm aware= of?) >>> >>> Hopefully this is useful information and I'm not too wrong or someone >>> will >>> correct me >>> >> >> The CTF information is needed by DTrace. >> My guess is that it will run ctfconvert on itself so it should be >> there from a prior install or it is part of some early toolchain >> stuff. >> > > CTF is needed by DTrace where? =C2=A0The build may depend on it, but this= is > probably for legacy reasons only. =C2=A0DTrace in opensolaris isn't depen= dent on > =C2=A0it to function correctly. =C2=A0Replace the $(CTFCONVERT) and a few= other > utilities with /bin/true and the build will succeed. =C2=A0(I can only sp= eak > first hand from OSUNIX/OpenSolaris though and not FBSD..) The build will succeed but dtracing something with the FBT provider won't. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 09:49:41 2010 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 ADDAD1065676 for ; Thu, 11 Mar 2010 09:49:41 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 54B8F8FC1E for ; Thu, 11 Mar 2010 09:49:40 +0000 (UTC) Received: by wwb28 with SMTP id 28so160249wwb.13 for ; Thu, 11 Mar 2010 01:49:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.166.148 with SMTP id g20mr725652wel.78.1268299179272; Thu, 11 Mar 2010 01:19:39 -0800 (PST) In-Reply-To: <4B989DD6.601@pathscale.com> References: <291941b81003100954n276d467an234c24e28f3b28e5@mail.gmail.com> <4B989DD6.601@pathscale.com> From: =?UTF-8?Q?Marius_N=C3=BCnnerich?= Date: Thu, 11 Mar 2010 10:19:19 +0100 Message-ID: To: =?UTF-8?Q?C=2E_Bergstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Shrikanth Kamath Subject: Re: ctfconvert dependency... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 09:49:41 -0000 2010/3/11 "C. Bergstr=C3=B6m" : > Shrikanth Kamath wrote: >> >> Just trying to understand the build dependency for ctfconvert... >> >> I see ctfconvert (cddl/usr.bin/ctfconvert/) =C2=A0has dependency on libc= tf.a >> (cddl/lib/libctf/) >> >> Now the snippet in bsd.lib.mk has this check for various target suffixes= , >> >> .c.So: >> .if defined(CTFCONVERT) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >> .endif >> >> and sys.mk >> >> .c >> .if defined(CTFCONVERT) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0${CTFCONVERT} ${CTFFLAGS} ${.TARGET} >> .endif >> >> My query, libctf includes =C2=A0 in it's Makefile, so will t= he >> above >> not try to >> run 'ctfconvert' on libctf itself? >> > > I'm going to make some assumptions and go out on a limb here.. > > The CDDL code in FBSD came from OpenSolaris (specifically onnv-gate hg re= po) > =C2=A0When OpenSolaris is built they convert stab debugging information o= ver to > CTF (compressed text format?). =C2=A0This is done so that they can have d= ebugging > information, but without the overhead of stab (or dwarf2). =C2=A0I don't = know how > much of the original onnv-gate Makefiles came over from OpenSolaris, but > assuming the FBSD kernel doesn't need/use CTF format this dependency can = and > probably should go away. =C2=A0(Only (k)mdb supports CTF that I'm aware o= f?) > > Hopefully this is useful information and I'm not too wrong or someone wil= l > correct me The CTF information is needed by DTrace. My guess is that it will run ctfconvert on itself so it should be there from a prior install or it is part of some early toolchain stuff. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 10:29:19 2010 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 01EB0106566B for ; Thu, 11 Mar 2010 10:29:19 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id B4F108FC1A for ; Thu, 11 Mar 2010 10:29:18 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id A975213992F; Thu, 11 Mar 2010 12:29:12 +0200 (EET) Date: Thu, 11 Mar 2010 12:29:12 +0200 From: Jaakko Heinonen To: Alexander Best Message-ID: <20100311102911.GA2574@a91-153-117-195.elisa-laajakaista.fi> References: <20100305055758.GA1062@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.org, Poul-Henning Kamp , Bruce Evans Subject: Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 10:29:19 -0000 On 2010-03-10, Alexander Best wrote: > could this panic have been triggered by the patch? It doesn't look like it's caused by the patch. > panic() at panic+0x15f > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > fdesc_allocvp() at fdesc_allocvp+0xbf > fdesc_lookup() at fdesc_lookup+0x15c > > this was 100% reducible when doing `portsnap fetch` though i changed a lot of > stuff in my kernel config and reverted a lot of src patches to resolve the > issue so i'm not sure what exactly was causing it. The panic happened in fdescfs code. Did you have local patches related to fdescfs? -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 10:40:59 2010 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 7C3D110656A8 for ; Thu, 11 Mar 2010 10:40:59 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 07B058FC1B for ; Thu, 11 Mar 2010 10:40:58 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o2BADLWL019519; Thu, 11 Mar 2010 10:13:21 GMT (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4B98C241.8090400@fletchermoorland.co.uk> Date: Thu, 11 Mar 2010 10:13:21 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20091217) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.4 required=10.0 tests=ALL_TRUSTED,BAYES_50, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: Steven Hartland Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 10:40:59 -0000 Steven Hartland wrote: > Ok so I'm looking to replace our current windows mail > server using mdaemon with a FreeBSD solution, having > looked around there seems to be differing opinions > of which is the best option to go with between sendmail > and postfix. > > ... > > Any advice, opinions on a full mail solution on FreeBSD > would be appreciated. > > Regards > Steve > Sorry to hi-jack your thread, but this is also something I am currently looking in to I really wanted to use Sendmail as a friend knows Sendmail fairly well and I have a Sendmail book, but what I am wanting is the ability to have mail for virtual users, ie I might have 4 admin accounts, admin@domain1.com admin@domain2.com admin@domain3.com and admin@domain4.com and want all the accounts to be independent of each other and not necessarily have a real UNIX user account. I know I can create 4 different admin accounts say admin1, admin2, admin3, admin4 and then use the "virtual users" table, but I can see that getting a little messy and from the end user's point they are going to have unusual login names. I know I can do this in Postfix, but is it possible in Sendmail? Cheers Paul From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 10:57:49 2010 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 DA1B2106564A; Thu, 11 Mar 2010 10:57:49 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 747B28FC18; Thu, 11 Mar 2010 10:57:49 +0000 (UTC) Received: from [195.4.92.24] (helo=14.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1Npg5M-0006e6-Ny; Thu, 11 Mar 2010 11:57:48 +0100 Received: from p57ae1b2e.dip0.t-ipconnect.de ([87.174.27.46]:55241 helo=ernst.jennejohn.org) by 14.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1Npg5M-0005vD-8z; Thu, 11 Mar 2010 11:57:48 +0100 Date: Thu, 11 Mar 2010 11:57:47 +0100 From: Gary Jennejohn To: Ed Schouten Message-ID: <20100311115747.1678c3dd@ernst.jennejohn.org> In-Reply-To: <20100310200410.GG8200@hoeg.nl> References: <20100310093001.GL22317@elvis.mu.org> <20100310184152.GF8200@hoeg.nl> <20100310200410.GG8200@hoeg.nl> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , Alfred Perlstein Subject: Re: tty or script(1) weirdness? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 10:57:49 -0000 On Wed, 10 Mar 2010 21:04:10 +0100 Ed Schouten wrote: > * Ed Schouten wrote: > > Hmmm... It seems this is a TTY bug. When you close a TTY, the final > > close() call should get stuck until all data is actually drained. This > > doesn't seem to happen properly. > > Some further research: it's not a TTY bug, but a bug in script(1). > The script parent process leaves a file descriptor open, which means > output is never properly drained. > > I can't reproduce this issue after applying this patch: > > %%% > Index: script.c > =================================================================== > --- script.c (revision 204965) > +++ script.c (working copy) > @@ -158,6 +158,8 @@ > } > if (child == 0) > doshell(argv); > + else > + close(slave); > > if (flushtime > 0) > tvp = &tv; > %%% > Looks very convincing. I say commit it. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 11:08:54 2010 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 9472E106566C for ; Thu, 11 Mar 2010 11:08:54 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD4B8FC23 for ; Thu, 11 Mar 2010 11:08:53 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o2BB8caj013401 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Mar 2010 11:08:39 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4B98CF36.7040303@infracaninophile.co.uk> Date: Thu, 11 Mar 2010 11:08:38 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Paul Wootton References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B98C241.8090400@fletchermoorland.co.uk> In-Reply-To: <4B98C241.8090400@fletchermoorland.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-hackers@freebsd.org, Steven Hartland Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 11:08:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/03/2010 10:13:21, Paul Wootton wrote: > Sorry to hi-jack your thread, but this is also something I am currently > looking in to > > I really wanted to use Sendmail as a friend knows Sendmail fairly well > and I have a Sendmail book, but what I am wanting is the ability to have > mail for virtual users, ie I might have 4 admin accounts, > admin@domain1.com admin@domain2.com admin@domain3.com and > admin@domain4.com and want all the accounts to be independent of each > other and not necessarily have a real UNIX user account. I know I can > create 4 different admin accounts say admin1, admin2, admin3, admin4 and > then use the "virtual users" table, but I can see that getting a little > messy and from the end user's point they are going to have unusual login > names. > I know I can do this in Postfix, but is it possible in Sendmail? Sure, this is possible in sendmail, and you have already identified the way to do it: virtusertable, but as you say, the local user accounts end up looking pretty unusual. Unless you've got a delivery system that also takes account of the domain part of an e-mail address (something that is pretty unusual with sendmail(8)) you have to map all of the accepted mail addresses into a set of local userids: so admin@domainX.com --> admin-domainX. The only good way of doing that is with virtusertable, since that's the only aliasing mechanism in sendmail which looks at the domain part of an address. aliases treats all of the RHSes as equivalent, so long as they belong to the set of addresses sendmail knows is locally delivered. On the other hand, virtusertable is a 1:1 transformation, aliases is a 1:many transformation -- the two different address transformation mechanisms is a historical peculiarity of sendmail and makes virtual server setups like this pretty tricky. To deliver to mailboxes where the userid includes a domain part, you have to have a mail-user database distinct from the password file and you will need to rewrite large parts of the basic message processing in sendmail.cf. As well, you'll need a fairly heavy-weight IMAP server like cyrus IMAPd for this functionality (does dovecot support it? no idea.) Doing this sort of stuff in other MTAs is easier than doing it in sendmail. postfix would be my choice. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuYzzYACgkQ8Mjk52CukIxSMwCffdtKiVQ8XWvpjLPs+zMmsDth aw8Ani9AhuC04YMAkLsDLfMWhR4mo9QP =FMxw -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 11:12:13 2010 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 0066B106566B; Thu, 11 Mar 2010 11:12:13 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0788FC08; Thu, 11 Mar 2010 11:12:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,619,1262559600"; d="scan'208";a="298833591" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 11 Mar 2010 12:12:10 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 364F71B0768; Thu, 11 Mar 2010 12:12:10 +0100 (CET) Date: Thu, 11 Mar 2010 12:12:09 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Jaakko Heinonen Message-ID: In-Reply-To: <20100311102911.GA2574@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Poul-Henning Kamp , Bruce Evans Subject: Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 11:12:13 -0000 Jaakko Heinonen schrieb am 2010-03-11: > On 2010-03-10, Alexander Best wrote: > > could this panic have been triggered by the patch? > It doesn't look like it's caused by the patch. > > panic() at panic+0x15f > > _mtx_lock_flags() at _mtx_lock_flags+0xc5 > > fdesc_allocvp() at fdesc_allocvp+0xbf > > fdesc_lookup() at fdesc_lookup+0x15c > > this was 100% reducible when doing `portsnap fetch` though i > > changed a lot of > > stuff in my kernel config and reverted a lot of src patches to > > resolve the > > issue so i'm not sure what exactly was causing it. > The panic happened in fdescfs code. Did you have local patches > related > to fdescfs? after reverting a few patches (including yours) i got rid of the problem. i then re-applied your patch and noticed that (as you said) it wasn't causing the panic. i don't have any fdescfs specific patches in my src. i suspect however [1] being responsible for the panic. after backing it out i got no more panics in connection with `portsnap fetch`. [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70400.html thanks for the help oh...and btw.: i'm not sure but i think i've asked this question once before in this thread: in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check for "." and "/" after applying your patch. isn't this all being done by calling namei() now? cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 11:15:21 2010 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 3FDCA106566B for ; Thu, 11 Mar 2010 11:15:21 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id C71498FC16 for ; Thu, 11 Mar 2010 11:15:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,619,1262559600"; d="txt'?scan'208";a="238855677" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 11 Mar 2010 12:15:18 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id EF11F1B0768; Thu, 11 Mar 2010 12:15:18 +0100 (CET) Date: Thu, 11 Mar 2010 12:15:11 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100311111511f0889e8400003418-a_best01+ Cc: Subject: [patch] tiny comment fix in sys/kern/vfs_syscalls.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 11:15:21 -0000 This is a MIME encoded multipart message. --+permail-20100311111511f0889e8400003418-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit nothing spectacular. ;) alex --+permail-20100311111511f0889e8400003418-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="vfssyscalls.c.patch.txt" SW5kZXg6IHN5cy9rZXJuL3Zmc19zeXNjYWxscy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL3Zm c19zeXNjYWxscy5jCShyZXZpc2lvbiAyMDQ5ODgpCisrKyBzeXMva2Vybi92ZnNfc3lzY2FsbHMu Ywkod29ya2luZyBjb3B5KQpAQCAtMTA2MCw3ICsxMDYwLDcgQEAKIAlBVURJVF9BUkdfTU9ERSht b2RlKTsKIAkvKiBYWFg6IGF1ZGl0IGRpcmZkICovCiAJLyoKLQkgKiBPbmx5IG9uZSBvZiB0aGUg T19FWEVDLCBPX1JET05MWSwgT19XUk9OTFkgYW5kIE9fUkRXUiBtYXkKKwkgKiBPbmx5IG9uZSBv ZiB0aGUgT19FWEVDLCBPX1JET05MWSwgT19XUk9OTFkgYW5kIE9fUkRXUiBmbGFncyBtYXkKIAkg KiBiZSBzcGVjaWZpZWQuCiAJICovCiAJaWYgKGZsYWdzICYgT19FWEVDKSB7Cg== --+permail-20100311111511f0889e8400003418-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 10:54:06 2010 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 40F6C1065674 for ; Thu, 11 Mar 2010 10:54:06 +0000 (UTC) (envelope-from roberto@keltia.net) Received: from keltia.net (unknown [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id EAE9D8FC0C for ; Thu, 11 Mar 2010 10:54:05 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 89F50FA2 for ; Thu, 11 Mar 2010 11:54:04 +0100 (CET) Date: Thu, 11 Mar 2010 11:54:00 +0100 From: Ollivier Robert To: freebsd-hackers@freebsd.org Message-ID: <20100311105359.GA34091@roberto-al.eurocontrol.fr> References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 11 Mar 2010 11:54:04 +0100 (CET) X-Mailman-Approved-At: Thu, 11 Mar 2010 12:32:02 +0000 Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 10:54:06 -0000 According to Steven Hartland: > 1. Has sendmail's config moved away from the black art > it once was? Well, not really. .cf files are still .cf files but most people don't use them directly (except old farts ;-)). .mc files are the easiest way to configure sendmail (and of course tables) > 2. Is postfix that much easier? Yes. You get tables for everything as well but it is IMHO cleaner. > 3. What would people use for: > 3.1. POP / IMAP support? dovecot is the one I found the easiest to work with. > 3.2. Web Mail? Don't use it so I can't advise. > 3.2. AV / Spam filtering? clamav-milter along with milter-greylist rocks. Spam filtering is more done at the user level through bogofilter though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:13:16 2010 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 68086106564A; Thu, 11 Mar 2010 13:13:16 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id C11308FC14; Thu, 11 Mar 2010 13:13:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,620,1262559600"; d="scan'208";a="28160783" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 11 Mar 2010 14:13:14 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 68C7D1B07E7; Thu, 11 Mar 2010 14:13:14 +0100 (CET) Date: Thu, 11 Mar 2010 14:13:13 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Message-ID: In-Reply-To: <201003080947.58027.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= , Xin LI Subject: Re: tiny lib/libkvm/kvm_proc.c correction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 13:13:16 -0000 John Baldwin schrieb am 2010-03-08: > On Saturday 06 March 2010 3:39:17 am Ulrich Sp=F6rlein wrote: > > On Fri, 05.03.2010 at 12:38:40 -0800, Xin LI wrote: > > > On 2010/03/05 11:59, Alexander Best wrote: > > > > Xin LI schrieb am 2010-03-05: > > > > On 2010/03/05 11:26, Alexander Best wrote: > > > >>>> hi there. does this look right? > > > > Not to me, the value is not to be used this way and the > > > > comments > > > > above the code explained the same thing. > > > > I think we should use cputick2usec but it's not available to > > > > userland > > > > (one have to copy cpu_tick_frequency and friends). > > > >> damn you're right. i completely overlooked that comment. would > > > >> it be > worth > > > >> making cputick2usec available to userland? is kvm_proc.c the > > > >> only > candidate in > > > >> need of converting cpu ticks to usecs? > > > I'm not sure how to do that unfortunately, is there a way to > > > expose a > > > kernel variable to userland which also works on a crash dump? > > ticks *is* available to libkvm, not sure what happens on > > crashdumps, > > though. The following patchset has not been tested: i've just had a look at the overall use of bintime2timeval in the src. it's not used very often. i only found a handful of calls and in fact with the exception of kvm_proc.c bintime2timeval() always gets used with a proper struct bintime. so i guess it's okay to import cputick2usec() exclusively to kvm_proc.c. cheers. alex > https://www.spoerlein.net/gitweb/?p=3Dfreebsd.work/.git;a=3Dcommitdiff;h= =3Dd500a051eb75dd234166bb11485c0a953aefce1d > I'm fine with this patch so long as you are reading 'ticks' from the > crash > dump. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:17:03 2010 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 51C3F1065677 for ; Thu, 11 Mar 2010 13:17:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id B79C28FC2B for ; Thu, 11 Mar 2010 13:17:02 +0000 (UTC) Received: from park.js.berklix.net (p549A4219.dip.t-dialin.net [84.154.66.25]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o2BDGqSv011143; Thu, 11 Mar 2010 13:16:52 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o2BDGia7030916; Thu, 11 Mar 2010 14:16:45 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o2BDGYLG047645; Thu, 11 Mar 2010 14:16:39 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201003111316.o2BDGYLG047645@fire.js.berklix.net> To: Paul Wootton From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 11 Mar 2010 10:13:21 GMT." <4B98C241.8090400@fletchermoorland.co.uk> Date: Thu, 11 Mar 2010 14:16:34 +0100 Sender: jhs@berklix.com Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 13:17:03 -0000 > I really wanted to use Sendmail as a friend knows Sendmail fairly well > and I have a Sendmail book, but what I am wanting is the ability to have > mail for virtual users, ie I might have 4 admin accounts, > admin@domain1.com admin@domain2.com admin@domain3.com and > admin@domain4.com and want all the accounts to be independent of each > other and not necessarily have a real UNIX user account. I know I can > create 4 different admin accounts say admin1, admin2, admin3, admin4 and > then use the "virtual users" table, but I can see that getting a little > messy and from the end user's point they are going to have unusual login > names. > I know I can do this in Postfix, but is it possible in Sendmail? Yes its possible. I do that with sendmail for a friend's domain I host Here's an anonymised real operational sample from my server with comment added /etc/mail/virtusertable hostmaster@sparedomain.com hostmaster hostmaster@www.sparedomain.com hostmaster # I take the hostmaster cos hes not competent to. friend-local-acc-on-my-host@sparedomain.com sparedomain-default # friend-local-acc-on-my-host@ is redundant as # done by default, but left for clarity. # could also go to secretary-of-friend@anywhere-else.com # example@sparedomain.com some@where_else @sparedomain.com sparedomain-default # this collects all of # friends-new-colleague-he-hasnt-told-me-about@sparedomain.com # random-guess-by-spammer@sparedomain.com @www.sparedomain.com sparedomain-default # divert any mail re friends web site to the friend. /etc/mail/aliases: # switchable choice depending if I POP serve the friend or forward. sparedomain-default: friend@some-other-domain.com # sparedomain-default: friend-local-acc-on-my-host PS I skimmed but didnt really understand Matthew's posting, (not saying its right or wrong, just didnt grasp it), but I have sendmail working fine for my @berklix.org & for a friend's @surfacevision.com So Paul, you can use sendmail for this if you want. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.org Old 20s expire 30 6 2010 http://www.bankofengland.co.uk/banknotes/twentyv/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:17:35 2010 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 C06301065674 for ; Thu, 11 Mar 2010 13:17:35 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC098FC27 for ; Thu, 11 Mar 2010 13:17:35 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 58B902166EF; Thu, 11 Mar 2010 15:17:29 +0200 (EET) Date: Thu, 11 Mar 2010 15:17:29 +0200 From: Jaakko Heinonen To: Alexander Best Message-ID: <20100311131728.GC3008@a91-153-117-195.elisa-laajakaista.fi> References: <20100311102911.GA2574@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@FreeBSD.org, Poul-Henning Kamp , Bruce Evans Subject: Re: namei() returns EISDIR for "/" (Re: svn commit: r203990 - head/lib/libc/sys) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 13:17:35 -0000 On 2010-03-11, Alexander Best wrote: > in sys/kern/vfs_syscalls.c:kern_rmdirat() there's still local code to check > for "." and "/" after applying your patch. isn't this all being done by > calling namei() now? Looking at it quickly I think that the "." case is handled by lookup() since r199137. However the VV_ROOT test is for all mount points not just for "/". -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:25:41 2010 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 109CF106566C for ; Thu, 11 Mar 2010 13:25:41 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 39F2E8FC28 for ; Thu, 11 Mar 2010 13:25:39 +0000 (UTC) Received: (qmail invoked by alias); 11 Mar 2010 13:25:35 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp055) with SMTP; 11 Mar 2010 14:25:35 +0100 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX192Jy5yul52wx7R1qpdG0L391TXhUS+RlUV4Zbczo BK3+g4DaYQvpPh Date: Thu, 11 Mar 2010 14:27:41 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Message-Id: <10610127213209@192.168.2.69> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 13:25:41 -0000 Hi, i am looking for a way to curb SATA speed to 1.5 GBit/s to avoid write failures with an eSATA attached DVD burner. I tried this as superuser: # atacontrol mode acd1 current mode = SATA300 # atacontrol mode acd1 SATA150 current mode = SATA300 # atacontrol mode acd1 current mode = SATA300 with obviously no success. $ uname -a FreeBSD ... 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 atapicam is running. ------------------------------------------------ The problem of the burner appears as checksum errors during write operations (but not during reading, strangely). It hits both, FreeBSD 8.0 and Debian Linux 5.04. But Debian switches to 1.5 GBit/s after a few errors and then works fine, whereas FreeBSD stays error prone. E.g. writing to a DVD+RW by $ dd if=/dev/zero bs=1M count=100 of=/dev/cd1 100+0 records in 100+0 records out 104857600 bytes transferred in 195.130322 secs (537372 bytes/sec) yields only 10 % of normal speed and afterwards i get from dmesg: acd1: FAILURE - REQUEST_SENSE timed out acd1: FAILURE - REQUEST_SENSE timed out (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 41 40 0 0 20 0 (cd1:ata2:0:0:0): CAM Status: SCSI Status Error (cd1:ata2:0:0:0): SCSI Status: Check Condition (cd1:ata2:0:0:0): HARDWARE FAILURE asc:8,3 (cd1:ata2:0:0:0): Logical unit communication CRC error (Ultra-DMA/32) (cd1:ata2:0:0:0): Retrying Command (per Sense Data) acd1: FAILURE - WRITE_BIG timed out ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 8f c0 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 92 60 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 a1 a0 0 0 20 0 ... (cd1:ata2:0:0:0): WRITE(10). CDB: 2a 0 0 0 c7 60 0 0 20 0 ... acd1: FAILURE - REQUEST_SENSE timed out I then tried via /dev/acd1. The behavior got quite nasty: $ dd if=/dev/zero bs=1M count=100 of=/dev/acd1 was stuck for at least 15 minutes. Uninterruptible. I had to reboot. dmesg reported sparsely: acd1: FAILURE - WRITE_BIG HARDWARE ERROR asc=0x08 ascq=0x03 Further tries with /dev/acd1 yielded: $ dd if=/dev/zero bs=1M count=100 of=/dev/acd1 dd: /dev/acd1: Input/output error 2+0 records in 1+0 records out 1048576 bytes transferred in 0.882248 secs (1188527 bytes/sec) with dmesg: acd1: FAILURE - WRITE_BIG HARDWARE ERROR asc=0x08 ascq=0x03 acd1: TIMEOUT - WRITE_BIG retrying (1 retry left) Reading data works fine $ dd if=/dev/cd1 bs=1M count=1000 of=/dev/null 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 127.781828 secs (8205987 bytes/sec) at nearly twice the speed of flawless writing. The same drive works well at USB or inside the computer at SATA. Nevertheless i would like to get eSATA ready so that i can test SATA drives without opening the computer box. ------------------------------------------------ Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:43:38 2010 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 6BB9C106566B for ; Thu, 11 Mar 2010 13:43:38 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id F21AA8FC26 for ; Thu, 11 Mar 2010 13:43:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,620,1262559600"; d="txt'?scan'208";a="28163446" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 11 Mar 2010 14:43:36 +0100 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id C79361B0750; Thu, 11 Mar 2010 14:43:36 +0100 (CET) Date: Thu, 11 Mar 2010 14:43:29 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-201003111343291e86ffa800005d56-a_best01+ Cc: Subject: Re: Re: [patch] extending {amd64|i386} cpu info X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 13:43:38 -0000 This is a MIME encoded multipart message. --+permail-201003111343291e86ffa800005d56-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit since ed@ noticed that there's no CPUID_TO_STEPPING() macro this new patch adds one. i checked and include/specialreg.h is only available on amd64, i386 and pc98. all the latter does however is: #include cheers. alex --+permail-201003111343291e86ffa800005d56-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="identcpu.patch.txt" SW5kZXg6IGFtZDY0L2luY2x1ZGUvc3BlY2lhbHJlZy5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGFtZDY0L2lu Y2x1ZGUvc3BlY2lhbHJlZy5oCShyZXZpc2lvbiAyMDQ5NzcpCisrKyBhbWQ2NC9pbmNsdWRlL3Nw ZWNpYWxyZWcuaAkod29ya2luZyBjb3B5KQpAQCAtMTY5LDYgKzE2OSw4IEBACiAjZGVmaW5lCUNQ VUlEX0ZBTUlMWQkJMHgwMDAwMGYwMAogI2RlZmluZQlDUFVJRF9FWFRfTU9ERUwJCTB4MDAwZjAw MDAKICNkZWZpbmUJQ1BVSURfRVhUX0ZBTUlMWQkweDBmZjAwMDAwCisjZGVmaW5lIENQVUlEX1RP X1NURVBQSU5HKGlkKSBcCisgICAgKChpZCkgJiBDUFVJRF9TVEVQUElORykKICNkZWZpbmUJQ1BV SURfVE9fTU9ERUwoaWQpIFwKICAgICAoKCgoaWQpICYgQ1BVSURfTU9ERUwpID4+IDQpIHwgXAog ICAgICgoKGlkKSAmIENQVUlEX0VYVF9NT0RFTCkgPj4gMTIpKQpJbmRleDogYW1kNjQvYW1kNjQv aWRlbnRjcHUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhbWQ2NC9hbWQ2NC9pZGVudGNwdS5jCShyZXZpc2lv biAyMDQ5NzcpCisrKyBhbWQ2NC9hbWQ2NC9pZGVudGNwdS5jCSh3b3JraW5nIGNvcHkpCkBAIC0x ODcsNyArMTg3LDEyIEBACiAJaWYgKGNwdV92ZW5kb3JfaWQgPT0gQ1BVX1ZFTkRPUl9JTlRFTCB8 fAogCSAgICBjcHVfdmVuZG9yX2lkID09IENQVV9WRU5ET1JfQU1EIHx8CiAJICAgIGNwdV92ZW5k b3JfaWQgPT0gQ1BVX1ZFTkRPUl9DRU5UQVVSKSB7Ci0JCXByaW50ZigiICBTdGVwcGluZyA9ICV1 IiwgY3B1X2lkICYgMHhmKTsKKwkJcHJpbnRmKCIgIFN0ZXBwaW5nID0gJXUiCisJCSAgICAgICAi ICBNb2RlbCA9ICV1IgorCQkgICAgICAgIiAgRmFtaWx5ID0gJXUiLAorCQkgICAgICAgQ1BVSURf VE9fU1RFUFBJTkcoY3B1X2lkKSwKKwkJICAgICAgIENQVUlEX1RPX01PREVMKGNwdV9pZCksCisJ CSAgICAgICBDUFVJRF9UT19GQU1JTFkoY3B1X2lkKSk7CiAJCWlmIChjcHVfaGlnaCA+IDApIHsK IAogCQkJLyoKSW5kZXg6IGkzODYvaW5jbHVkZS9zcGVjaWFscmVnLmgKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g aTM4Ni9pbmNsdWRlL3NwZWNpYWxyZWcuaAkocmV2aXNpb24gMjA0OTc3KQorKysgaTM4Ni9pbmNs dWRlL3NwZWNpYWxyZWcuaAkod29ya2luZyBjb3B5KQpAQCAtMTY2LDYgKzE2Niw4IEBACiAjZGVm aW5lCUNQVUlEX0ZBTUlMWQkJMHgwMDAwMGYwMAogI2RlZmluZQlDUFVJRF9FWFRfTU9ERUwJCTB4 MDAwZjAwMDAKICNkZWZpbmUJQ1BVSURfRVhUX0ZBTUlMWQkweDBmZjAwMDAwCisjZGVmaW5lIENQ VUlEX1RPX1NURVBQSU5HKGlkKSBcCisgICAgKChpZCkgJiBDUFVJRF9TVEVQUElORykKICNkZWZp bmUJQ1BVSURfVE9fTU9ERUwoaWQpIFwKICAgICAoKCgoaWQpICYgQ1BVSURfTU9ERUwpID4+IDQp IHwgXAogICAgICgoKChpZCkgJiBDUFVJRF9GQU1JTFkpID49IDB4NjAwKSA/IFwKSW5kZXg6IGkz ODYvaTM4Ni9pZGVudGNwdS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGkzODYvaTM4Ni9pZGVudGNwdS5jCShy ZXZpc2lvbiAyMDQ5NzcpCisrKyBpMzg2L2kzODYvaWRlbnRjcHUuYwkod29ya2luZyBjb3B5KQpA QCAtNjcyLDcgKzY3MiwxMiBAQAogCSAgICBjcHVfdmVuZG9yX2lkID09IENQVV9WRU5ET1JfTlND IHx8CiAJCShjcHVfdmVuZG9yX2lkID09IENQVV9WRU5ET1JfQ1lSSVggJiYKIAkJICgoY3B1X2lk ICYgMHhmMDApID4gMHg1MDApKSkgewotCQlwcmludGYoIiAgU3RlcHBpbmcgPSAldSIsIGNwdV9p ZCAmIDB4Zik7CisJCXByaW50ZigiICBTdGVwcGluZyA9ICV1IgorCQkgICAgICAgIiAgTW9kZWwg PSAldSIKKwkJICAgICAgICIgIEZhbWlseSA9ICV1IiwKKwkJICAgICAgIENQVUlEX1RPX1NURVBQ SU5HKGNwdV9pZCksCisJCSAgICAgICBDUFVJRF9UT19NT0RFTChjcHVfaWQpLAorCQkgICAgICAg Q1BVSURfVE9fRkFNSUxZKGNwdV9pZCkpOwogCQlpZiAoY3B1X3ZlbmRvcl9pZCA9PSBDUFVfVkVO RE9SX0NZUklYKQogCQkJcHJpbnRmKCIgIERJUj0weCUwNHgiLCBjeXJpeF9kaWQpOwogCQlpZiAo Y3B1X2hpZ2ggPiAwKSB7Cg== --+permail-201003111343291e86ffa800005d56-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 13:54:58 2010 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 F32121065675 for ; Thu, 11 Mar 2010 13:54:58 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0EB8FC17 for ; Thu, 11 Mar 2010 13:54:57 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o2BDsrkd023054; Thu, 11 Mar 2010 13:54:53 GMT (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4B98F62D.9000100@fletchermoorland.co.uk> Date: Thu, 11 Mar 2010 13:54:53 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20091217) MIME-Version: 1.0 To: "Julian H. Stacey" References: <201003111316.o2BDGYLG047645@fire.js.berklix.net> In-Reply-To: <201003111316.o2BDGYLG047645@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,BAYES_00, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 13:54:59 -0000 Julian H. Stacey wrote: >> I really wanted to use Sendmail as a friend knows Sendmail fairly well >> and I have a Sendmail book, but what I am wanting is the ability to have >> mail for virtual users, ie I might have 4 admin accounts, >> admin@domain1.com admin@domain2.com admin@domain3.com and >> admin@domain4.com and want all the accounts to be independent of each >> other and not necessarily have a real UNIX user account. I know I can >> create 4 different admin accounts say admin1, admin2, admin3, admin4 and >> then use the "virtual users" table, but I can see that getting a little >> messy and from the end user's point they are going to have unusual login >> names. >> I know I can do this in Postfix, but is it possible in Sendmail? >> > > Yes its possible. I do that with sendmail for a friend's domain I host > Here's an anonymised real operational sample from my server with comment added > > ... > > PS I skimmed but didnt really understand Matthew's posting, (not > saying its right or wrong, just didnt grasp it), but I have sendmail > working fine for my @berklix.org & for a friend's @surfacevision.com > So Paul, you can use sendmail for this if you want. > > Cheers, > Julian > Thanks but unfortunately this really wont help me too much. My fault for not posting it before, but I currently have 9 domains (with a likely hood of another couple more being added), with an range from 5 to 15 different email accounts per domain, hence me thinking it might get a little messy with all the UNIX accounts and virtual user table. Cheers Paul From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 14:11:07 2010 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 82558106567D for ; Thu, 11 Mar 2010 14:11:07 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 450588FC12 for ; Thu, 11 Mar 2010 14:11:07 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4B5CC1FFC53; Thu, 11 Mar 2010 14:11:06 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 222008449F; Thu, 11 Mar 2010 15:11:06 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthias Andree References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B982E57.2050408@gmx.de> Date: Thu, 11 Mar 2010 15:11:06 +0100 In-Reply-To: <4B982E57.2050408@gmx.de> (Matthias Andree's message of "Thu, 11 Mar 2010 00:42:15 +0100") Message-ID: <86vdd3kkxx.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 14:11:07 -0000 Matthias Andree writes: > sendmail's configuration was never a black art unless you needed > features beyond what the m4 macro set supported. The m4 macro set is a fairly recent development. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 14:17:51 2010 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 6720F1065780 for ; Thu, 11 Mar 2010 14:17:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 382C18FC15 for ; Thu, 11 Mar 2010 14:17:51 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CC31E46B1A; Thu, 11 Mar 2010 09:17:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 25EA88A01F; Thu, 11 Mar 2010 09:17:50 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 11 Mar 2010 08:14:30 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> In-Reply-To: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003110814.31009.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Mar 2010 09:17:50 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: bus_space_tag, bus_space_handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 14:17:51 -0000 On Thursday 11 March 2010 4:04:52 am Cole wrote: > Hi. > > Im currently needing to write to a few registers for a PCI device. The > driver is provided, but it does not contain support for writing > specific registers itself. I also do not with to modify the driver. > > I would like to know what the best method would be for writing to > these registers, the best way to go about getting bus_space_tag, and > handle for the connected pci device. > > Im currently using FreeBSD 7.x. You will most likely need to modify the driver. The PCI bus code only hands out valid resources for a given BAR to the device_t for a given device. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 14:17:52 2010 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 70CE2106564A for ; Thu, 11 Mar 2010 14:17:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 412B08FC19 for ; Thu, 11 Mar 2010 14:17:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E88AE46B0C; Thu, 11 Mar 2010 09:17:51 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 33F198A021; Thu, 11 Mar 2010 09:17:51 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 11 Mar 2010 09:07:04 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201003110907.04859.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 11 Mar 2010 09:17:51 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best Subject: Re: [patch] extending {amd64|i386} cpu info X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 14:17:52 -0000 On Thursday 11 March 2010 8:43:29 am Alexander Best wrote: > since ed@ noticed that there's no CPUID_TO_STEPPING() macro this new patch > adds one. i checked and include/specialreg.h is only available on amd64, i386 > and pc98. all the latter does however is: > > #include I don't think we need the CPUID_TO_STEPPING() macro as stepping is still a simple mask operation. The other macros were added when the operations became more complicated. I do have a version of your patch I plan to commit soon. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 14:32:38 2010 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 5E324106564A for ; Thu, 11 Mar 2010 14:32:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 120A08FC1A for ; Thu, 11 Mar 2010 14:32:37 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o2BEWbes001179 for ; Thu, 11 Mar 2010 06:32:37 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o2BEWbPe001178 for hackers@freebsd.org; Thu, 11 Mar 2010 06:32:37 -0800 (PST) (envelope-from david) Date: Thu, 11 Mar 2010 06:32:37 -0800 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20100311143237.GP57205@bunrab.catwhisker.org> References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B982E57.2050408@gmx.de> <86vdd3kkxx.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j/dCmPD2xgTAf6cP" Content-Disposition: inline In-Reply-To: <86vdd3kkxx.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: To sendmail or to postfix that is the question? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 14:32:38 -0000 --j/dCmPD2xgTAf6cP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 11, 2010 at 03:11:06PM +0100, Dag-Erling Sm=F8rgrav wrote: > Matthias Andree writes: > > sendmail's configuration was never a black art unless you needed > > features beyond what the m4 macro set supported. >=20 > The m4 macro set is a fairly recent development. I was using it in 1993. With respect, perspectives as to "never" or "recent" tend to be subjective. (Some folks on this list may well have not been born yet in 1993.) FWIW: * The FreeBSD.org mail infrastructure uses Postfix. In general, I find its configuration cleaner & more orthogonal than that of sendmail. * I still use sendmail at home -- partly because there are still things I can do with sendmail that I don't know how to do with Postfix (e.g., taking action based on the lack of a header), partly because I still find sendmail logs easier to parse and undertsand, and partly from inertia. And we have Greg Shapiro shepherding sendmail in the FreeBSD source tree, which is wonderful. * I worked at an installation that had a fair amount of infrastructure built around the use of qmail a few years back. I hope to never repeat that experience, and would not willingly use qmail ever again. * I have no experience with administering other MTAs. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --j/dCmPD2xgTAf6cP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkuY/wQACgkQmprOCmdXAD3yjQCfW/Q+mmhQSekd/wLtTnhGYogf 9/YAmwSGlm9vwUZcbtn7jJfqYVD+uSil =1dkn -----END PGP SIGNATURE----- --j/dCmPD2xgTAf6cP-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 14:49:59 2010 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 09CC7106566B for ; Thu, 11 Mar 2010 14:49:59 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id B9AF68FC08 for ; Thu, 11 Mar 2010 14:49:58 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (Postfix) with ESMTPS id 08BBB5CA9; Thu, 11 Mar 2010 15:49:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1268318998; bh=+ixoSq3Plb48g5QVlOHOtRkAUI4q0YHYv7neS/PVRVU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=s6MZedbt2B0GcaxZI80lMwAm8ctINrrLjtiTgvVGvigjKGjnrjmReJdVh9tAL2lmr bHgAS/xW3F0M2BZUlALXcMEKhI5HwHWncu6JQESXuoSJk38+lGS/N6bzT/0irX+GxH 1pz9zp82fZCSnh/BolRdkERcXru3kL1OlZKazK4k= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o2BEnvO7052065; Thu, 11 Mar 2010 15:49:57 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Thu, 11 Mar 2010 15:49:57 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Paul Wootton Message-ID: <20100311144957.GA51031@acme.spoerlein.net> Mail-Followup-To: Paul Wootton , "Julian H. Stacey" , freebsd-hackers@freebsd.org References: <201003111316.o2BDGYLG047645@fire.js.berklix.net> <4B98F62D.9000100@fletchermoorland.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4B98F62D.9000100@fletchermoorland.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, "Julian H. Stacey" Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 14:49:59 -0000 On Thu, 11.03.2010 at 13:54:53 +0000, Paul Wootton wrote: >Julian H. Stacey wrote: > >> I really wanted to use Sendmail as a friend knows Sendmail fairly well > >> and I have a Sendmail book, but what I am wanting is the ability to have > >> mail for virtual users, ie I might have 4 admin accounts, > >> admin@domain1.com admin@domain2.com admin@domain3.com and > >> admin@domain4.com and want all the accounts to be independent of each > >> other and not necessarily have a real UNIX user account. I know I can > >> create 4 different admin accounts say admin1, admin2, admin3, admin4 and > >> then use the "virtual users" table, but I can see that getting a little > >> messy and from the end user's point they are going to have unusual login > >> names. > >> I know I can do this in Postfix, but is it possible in Sendmail? > >> > > > > Yes its possible. I do that with sendmail for a friend's domain I host > > Here's an anonymised real operational sample from my server with comment added > > > > ... > > > > PS I skimmed but didnt really understand Matthew's posting, (not > > saying its right or wrong, just didnt grasp it), but I have sendmail > > working fine for my @berklix.org & for a friend's @surfacevision.com > > So Paul, you can use sendmail for this if you want. > > > > Cheers, > > Julian > > > >Thanks but unfortunately this really wont help me too much. >My fault for not posting it before, but I currently have 9 domains (with >a likely hood of another couple more being added), with an range from 5 >to 15 different email accounts per domain, hence me thinking it might >get a little messy with all the UNIX accounts and virtual user table. > Use LDAP. That's what I did. Works fine with sendmail and dovecot, once you have it working, you will find out, that it's actually documented pretty decently. One of those things you always have to find out on hindsight :) Cheers, Uli From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 15:06:51 2010 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 E55CE106564A for ; Thu, 11 Mar 2010 15:06:51 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A57128FC1C for ; Thu, 11 Mar 2010 15:06:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E0B081FFC53 for ; Thu, 11 Mar 2010 15:06:49 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BC42784495; Thu, 11 Mar 2010 16:06:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: hackers@freebsd.org References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B982E57.2050408@gmx.de> <86vdd3kkxx.fsf@ds4.des.no> <20100311143237.GP57205@bunrab.catwhisker.org> Date: Thu, 11 Mar 2010 16:06:49 +0100 In-Reply-To: <20100311143237.GP57205@bunrab.catwhisker.org> (David Wolfskill's message of "Thu, 11 Mar 2010 06:32:37 -0800") Message-ID: <86r5nqlwxi.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 15:06:52 -0000 David Wolfskill writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Matthias Andree writes: > > > sendmail's configuration was never a black art unless you needed > > > features beyond what the m4 macro set supported. > > The m4 macro set is a fairly recent development. > I was using it in 1993. ISTR it did not become official until much later? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 15:18:28 2010 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 975321065672 for ; Thu, 11 Mar 2010 15:18:28 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 306E88FC12 for ; Thu, 11 Mar 2010 15:18:28 +0000 (UTC) Received: from [195.4.92.25] (helo=15.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1Npg9H-0004tY-P1; Thu, 11 Mar 2010 12:01:51 +0100 Received: from p57ae1b2e.dip0.t-ipconnect.de ([87.174.27.46]:64910 helo=ernst.jennejohn.org) by 15.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1Npg9H-0008C2-Ev; Thu, 11 Mar 2010 12:01:51 +0100 Date: Thu, 11 Mar 2010 12:01:37 +0100 From: Gary Jennejohn To: Cole Message-ID: <20100311120137.23ec543b@ernst.jennejohn.org> In-Reply-To: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> References: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: bus_space_tag, bus_space_handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 15:18:28 -0000 On Thu, 11 Mar 2010 11:04:52 +0200 Cole wrote: > Hi. > > Im currently needing to write to a few registers for a PCI device. The > driver is provided, but it does not contain support for writing > specific registers itself. I also do not with to modify the driver. > > I would like to know what the best method would be for writing to > these registers, the best way to go about getting bus_space_tag, and > handle for the connected pci device. > > Im currently using FreeBSD 7.x. > Take a look at pciconf(8). Might help. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 16:36:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A2D541065674; Thu, 11 Mar 2010 16:36:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Thu, 11 Mar 2010 11:36:20 -0500 User-Agent: KMail/1.6.2 References: <201003110907.04859.jhb@freebsd.org> In-Reply-To: <201003110907.04859.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003111136.29999.jkim@FreeBSD.org> Cc: Alexander Best Subject: Re: [patch] extending {amd64|i386} cpu info X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 16:36:39 -0000 On Thursday 11 March 2010 09:07 am, John Baldwin wrote: > On Thursday 11 March 2010 8:43:29 am Alexander Best wrote: > > since ed@ noticed that there's no CPUID_TO_STEPPING() macro this > > new patch adds one. i checked and include/specialreg.h is only > > available on amd64, > > i386 > > > and pc98. all the latter does however is: > > > > #include > > I don't think we need the CPUID_TO_STEPPING() macro as stepping is > still a simple mask operation. The other macros were added when > the operations became more complicated. Just for the record, I added CPUID_TO_* macros and I absolutely agree that we don't need CPUID_TO_STEPPING(). > I do have a version of your patch I plan to commit soon. Thanks! Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 19:48:51 2010 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 4272B1065670 for ; Thu, 11 Mar 2010 19:48:51 +0000 (UTC) (envelope-from kabaev@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 C44368FC19 for ; Thu, 11 Mar 2010 19:48:50 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so46213fga.13 for ; Thu, 11 Mar 2010 11:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=FJEa/6UqLfs3DixVKI6bDw+1dLYqyRqdgD9r59fbFXM=; b=xEVg6JXUMFw0frQ0pF02cWBfsk0c2O0E/8peBk4W30moUfdGy1CoM9deZX1+/TAYM4 TlIAuFZ0plHZoz4ZWeTX+WIfbUZXRLdlT474Iqn7XcI/OiVfoiUghwB42EHQnWKzQ1lY nh9IVFstPxZjHR7XPvIEsN90QFLt9nNSZO5NQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=iwSSOvASWrY59DScEJpkQSkBGJLvcE0XXDjXObzufCo+uod4+w0WfRA7OUMdvoTWMl Cs3GY+qpCCD4Q73g8jzptAQVDNYaJRtvzYgz5gwbkqhQCPP+2whes7zW4wZz+FVD6tuJ Szgj2fPV7Jgim/tpS9CvUOBD0praAYFDiLjXA= Received: by 10.87.45.20 with SMTP id x20mr84518fgj.63.1268335074031; Thu, 11 Mar 2010 11:17:54 -0800 (PST) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id d4sm68085fga.11.2010.03.11.11.17.51 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Mar 2010 11:17:52 -0800 (PST) Date: Thu, 11 Mar 2010 14:17:46 -0500 From: Alexander Kabaev Cc: freebsd-hackers@freebsd.org Message-ID: <20100311141746.7bce7b98@kan.dnsalias.net> In-Reply-To: <201003110814.31009.jhb@freebsd.org> References: <9f206d1a1003110104p2f329103mc882c99bcc15ea51@mail.gmail.com> <201003110814.31009.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/KkWBbKu+E5NGgF+tVYd=RJW"; protocol="application/pgp-signature" Subject: Re: bus_space_tag, bus_space_handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 19:48:51 -0000 --Sig_/KkWBbKu+E5NGgF+tVYd=RJW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 11 Mar 2010 08:14:30 -0500 John Baldwin wrote: > On Thursday 11 March 2010 4:04:52 am Cole wrote: > > Hi. > >=20 > > Im currently needing to write to a few registers for a PCI device. > > The driver is provided, but it does not contain support for writing > > specific registers itself. I also do not with to modify the driver. > >=20 > > I would like to know what the best method would be for writing to > > these registers, the best way to go about getting bus_space_tag, and > > handle for the connected pci device. > >=20 > > Im currently using FreeBSD 7.x. >=20 > You will most likely need to modify the driver. The PCI bus code > only hands out valid resources for a given BAR to the device_t for a > given device. >=20 > --=20 > John Baldwin I used /dev/mem and dd in the past for this purpose. Not pretty and custom tool beats it any day, but it does work. --=20 Alexander Kabaev --Sig_/KkWBbKu+E5NGgF+tVYd=RJW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFLmUHeQ6z1jMm+XZYRAuT1AKDA7Ac2GZxICvQyyc/qgZySPjdudACeIvJh 89txqnr8KKl5cjAQ3z/P2Lg= =8xmK -----END PGP SIGNATURE----- --Sig_/KkWBbKu+E5NGgF+tVYd=RJW-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 20:46:57 2010 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 7F9B1106566C for ; Thu, 11 Mar 2010 20:46:57 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 602F78FC08 for ; Thu, 11 Mar 2010 20:46:57 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAC15B.FD6C5005" Date: Thu, 11 Mar 2010 12:47:02 -0800 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E037DD783@seaxch09.desktop.isilon.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: memguard(9) rewrite Thread-Index: AcrBXAByD9zxjEMsTGqGkjirja8qJg== From: "Matthew Fleming" To: "FreeBSD Hackers" Subject: memguard(9) rewrite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 20:46:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC15B.FD6C5005 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This patch is against something close to stable/7. We've found internally that memguard(9) isn't very usable for debugging; it seems to run out of resources and do other unfriendly things. This patch is my first attempt to make it more usable. The basic changes are: - take a lot more KVA if available - use vm_map_findspace() directly, with a moving cursor, so that KVA is not reused for a while. When the cursor gets to the end of the map, start from the beginning which will re-use KVA. - free the physical pages and KVA on a memguard_free(). This requires no extra space for tracking, and no additional locks beyond the vm_map lock. Since on amd64 the KVA reserved is generally more than physical memory, there's also a limit on the physical memory used to keep memguard's page promotions from using up all the system resources. I hope this is useful. I'm working on code to add unused pages on each side of the allocation to detect memory overflow and underflow, and also some knobs to limit page promotions to larger allocations, and also randomly guarding any call to malloc(9). This code is going into our HEAD build today; in a few days I'll have good system test results to know if I butchered anything. I don't have a good test rig for CURRENT, but I can produce a patch against CURRENT that has no references to Isilon tags or isi_* filenames if desired. Is there anyone who wants to take such a patch and commit it? Should I send this to freebsd-arch as well? Thanks, matthew ------_=_NextPart_001_01CAC15B.FD6C5005 Content-Type: application/octet-stream; name="memguard.diff" Content-Transfer-Encoding: base64 Content-Description: memguard.diff Content-Disposition: attachment; filename="memguard.diff" SW5kZXg6IGNvbmYvZmlsZXMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29uZi9maWxlcwkocmV2aXNpb24gMTQz NTUwKQorKysgY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMjI2NiwzMSArMjI2NiwzMiBA QCB1ZnMvdWZzL3Vmc19leHRhdHRyLmMJCW9wdGlvbmFsIGZmcwogdWZzL3Vmcy91ZnNfZ2pvdXJu YWwuYwkJb3B0aW9uYWwgZmZzCiB1ZnMvdWZzL3Vmc19pbm9kZS5jCQlvcHRpb25hbCBmZnMKIHVm cy91ZnMvdWZzX2xvb2t1cC5jCQlvcHRpb25hbCBmZnMKIHVmcy91ZnMvdWZzX3F1b3RhLmMJCW9w dGlvbmFsIGZmcwogdWZzL3Vmcy91ZnNfdmZzb3BzLmMJCW9wdGlvbmFsIGZmcwogdWZzL3Vmcy91 ZnNfdm5vcHMuYwkJb3B0aW9uYWwgZmZzCiB2bS9kZWZhdWx0X3BhZ2VyLmMJCXN0YW5kYXJkCiB2 bS9kZXZpY2VfcGFnZXIuYwkJc3RhbmRhcmQKIHZtL3BoeXNfcGFnZXIuYwkJCXN0YW5kYXJkCiB2 bS9yZWR6b25lLmMJCQlvcHRpb25hbCBERUJVR19SRURaT05FCiB2bS9zZ19wYWdlci5jCQkJc3Rh bmRhcmQKIHZtL3N3YXBfcGFnZXIuYwkJCXN0YW5kYXJkCiB2bS91bWFfY29yZS5jCQkJc3RhbmRh cmQKIHZtL3VtYV9kYmcuYwkJCXN0YW5kYXJkCiB2bS92bV9jb250aWcuYwkJCXN0YW5kYXJkCi12 bS9tZW1ndWFyZC5jCQkJb3B0aW9uYWwgREVCVUdfTUVNR1VBUkQKKyN2bS9tZW1ndWFyZC5jCQkJ b3B0aW9uYWwgREVCVUdfTUVNR1VBUkQKK3ZtL2lzaV9tZW1ndWFyZC5jCQlvcHRpb25hbCBERUJV R19NRU1HVUFSRAogdm0vdm1fZmF1bHQuYwkJCXN0YW5kYXJkCiB2bS92bV9nbHVlLmMJCQlzdGFu ZGFyZAogdm0vdm1faW5pdC5jCQkJc3RhbmRhcmQKIHZtL3ZtX2tlcm4uYwkJCXN0YW5kYXJkCiB2 bS92bV9tYXAuYwkJCXN0YW5kYXJkCiB2bS92bV9tZXRlci5jCQkJc3RhbmRhcmQKIHZtL3ZtX21t YXAuYwkJCXN0YW5kYXJkCiB2bS92bV9vYmplY3QuYwkJCXN0YW5kYXJkCiB2bS92bV9wYWdlLmMJ CQlzdGFuZGFyZAogdm0vdm1fcGFnZW91dC5jCQkJc3RhbmRhcmQKIHZtL3ZtX3BhZ2VyLmMJCQlz dGFuZGFyZAogdm0vdm1fcGh5cy5jCQkJc3RhbmRhcmQKIHZtL3ZtX3Jlc2Vydi5jCQkJc3RhbmRh cmQKIHZtL3ZtX3VuaXguYwkJCXN0YW5kYXJkCiB2bS92bV96ZXJvaWRsZS5jCQlzdGFuZGFyZApJ bmRleDoga2Vybi9rZXJuX21hbGxvYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGtlcm4va2Vybl9tYWxsb2Mu YwkocmV2aXNpb24gMTQzNTUwKQorKysga2Vybi9rZXJuX21hbGxvYy5jCSh3b3JraW5nIGNvcHkp CkBAIC02OCwzMyArNjgsMzEgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2lmZGVmIE1BTExP Q19MRUFLU19DSEVDSwogI2luY2x1ZGUgPHN5cy9pc2lfZm9ybWF0Lmg+CiAjZW5kaWYgLyogTUFM TE9DX0xFQUtTX0NIRUNLICovCiAKICNpbmNsdWRlIDx2bS92bS5oPgogI2luY2x1ZGUgPHZtL3Bt YXAuaD4KICNpbmNsdWRlIDx2bS92bV9wYXJhbS5oPgogI2luY2x1ZGUgPHZtL3ZtX2tlcm4uaD4K ICNpbmNsdWRlIDx2bS92bV9leHRlcm4uaD4KICNpbmNsdWRlIDx2bS92bV9tYXAuaD4KICNpbmNs dWRlIDx2bS92bV9wYWdlLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+CiAjaW5jbHVkZSA8dm0vdW1h X2ludC5oPgogI2luY2x1ZGUgPHZtL3VtYV9kYmcuaD4KIAotI2lmZGVmIERFQlVHX01FTUdVQVJE CiAjaW5jbHVkZSA8dm0vbWVtZ3VhcmQuaD4KLSNlbmRpZgogI2lmZGVmIERFQlVHX1JFRFpPTkUK ICNpbmNsdWRlIDx2bS9yZWR6b25lLmg+CiAjZW5kaWYKIAogI2lmIGRlZmluZWQoSU5WQVJJQU5U UykgJiYgZGVmaW5lZChfX2kzODZfXykKICNpbmNsdWRlIDxtYWNoaW5lL2NwdS5oPgogI2VuZGlm CiAKICNpbmNsdWRlIDxkZGIvZGRiLmg+CiAKICNpZmRlZiBLRFRSQUNFX0hPT0tTCiAjaW5jbHVk ZSA8c3lzL2R0cmFjZV9ic2QuaD4KIAogZHRyYWNlX21hbGxvY19wcm9iZV9mdW5jX3QJZHRyYWNl X21hbGxvY19wcm9iZTsKICNlbmRpZgpAQCAtNjQyLDM0ICs2NDAsMzYgQEAgbWFsbG9jKHVuc2ln bmVkIGxvbmcgc2l6ZSwgc3RydWN0IG1hbGxvYwogCWlmICgoZmxhZ3MgJiBNX05PV0FJVCkgJiYg KG1hbGxvY19mYWlsdXJlX3JhdGUgIT0gMCkpIHsKIAkJYXRvbWljX2FkZF9pbnQoJm1hbGxvY19u b3dhaXRfY291bnQsIDEpOwogCQlpZiAoKG1hbGxvY19ub3dhaXRfY291bnQgJSBtYWxsb2NfZmFp bHVyZV9yYXRlKSA9PSAwKSB7CiAJCQlhdG9taWNfYWRkX2ludCgmbWFsbG9jX2ZhaWx1cmVfY291 bnQsIDEpOwogCQkJdF9tYWxsb2NfZmFpbCA9IHRpbWVfdXB0aW1lOwogCQkJcmV0dXJuIChOVUxM KTsKIAkJfQogCX0KICNlbmRpZgogI2lmIDAJLyogWFhYIFByZXNlbnRseSBJc2lsb24gYWxsb3dz IGJsb2NraW5nIGluIGludGVycnVwdCBjb250ZXh0LiAqLwogCWlmIChmbGFncyAmIE1fV0FJVE9L KQogCQlLQVNTRVJUKGN1cnRocmVhZC0+dGRfaW50cl9uZXN0aW5nX2xldmVsID09IDAsCiAJCSAg ICgibWFsbG9jKE1fV0FJVE9LKSBpbiBpbnRlcnJ1cHQgY29udGV4dCIpKTsKICNlbmRpZgogCi0j aWZkZWYgREVCVUdfTUVNR1VBUkQKLQlpZiAobWVtZ3VhcmRfY21wKG10cCkpCi0JCXJldHVybiBt ZW1ndWFyZF9hbGxvYyhzaXplLCBmbGFncyk7Ci0jZW5kaWYKKwlpZiAobWVtZ3VhcmRfY21wKG10 cCwgc2l6ZSkpIHsKKwkJdmEgPSBtZW1ndWFyZF9hbGxvYyhzaXplLCBmbGFncyk7CisJCWlmICh2 YSAhPSBOVUxMKQorCQkJcmV0dXJuIHZhOworCQkvKiBUaGlzIGlzIHVuZm9ydHVuYXRlIGJ1dCBz aG91bGQgbm90IGJlIGZhdGFsLiAqLworCX0KIAogI2lmZGVmIERFQlVHX1JFRFpPTkUKIAlzaXpl ID0gcmVkem9uZV9zaXplX250b3Ioc2l6ZSk7CiAjZW5kaWYKIAogI2lmZGVmIE1BTExPQ19MRUFL U19DSEVDSwogCWlmIChtdHAtPmtzX2NoZWNrX2xlYWtzKSB7CiAJCWZvciAocGFkID0gNjQ7IHBh ZCA8IHNpemUgJiYgcGFkIDwgUEFHRV9TSVpFOyBwYWQgPDw9IDEpCiAJCQk7CiAJCXNpemUgKz0g cGFkOwogCX0gZWxzZQogCQlwYWQgPSAwOwogI2VuZGlmIC8qIE1BTExPQ19MRUFLU19DSEVDSyAq LwogCiAJaWYgKHNpemUgPD0gS01FTV9aTUFYKSB7CkBAIC03NDMsMzYgKzc0MywzNCBAQCBtYWxs b2ModW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgbWFsbG9jCiAgKglUaGlzIHJvdXRpbmUgbWF5 IG5vdCBibG9jay4KICAqLwogdm9pZAogZnJlZSh2b2lkICphZGRyLCBzdHJ1Y3QgbWFsbG9jX3R5 cGUgKm10cCkKIHsKIAl1bWFfc2xhYl90IHNsYWI7CiAJdV9sb25nIHNpemU7CiAjaWZkZWYgTUFM TE9DX0xFQUtTX0NIRUNLCiAJc3RydWN0IGxlYWtfbm9kZSAqbm9kZTsKICNlbmRpZiAvKiBNQUxM T0NfTEVBS1NfQ0hFQ0sgKi8KIAogCS8qIGZyZWUoTlVMTCwgLi4uKSBkb2VzIG5vdGhpbmcgKi8K IAlpZiAoYWRkciA9PSBOVUxMKQogCQlyZXR1cm47CiAKLSNpZmRlZiBERUJVR19NRU1HVUFSRAot CWlmIChtZW1ndWFyZF9jbXAobXRwKSkgeworCWlmIChpc19tZW1ndWFyZF9hZGRyKGFkZHIpKSB7 CiAJCW1lbWd1YXJkX2ZyZWUoYWRkcik7CiAJCXJldHVybjsKIAl9Ci0jZW5kaWYKIAogI2lmZGVm IERFQlVHX1JFRFpPTkUKIAlyZWR6b25lX2NoZWNrKGFkZHIpOwogCWFkZHIgPSByZWR6b25lX2Fk ZHJfbnRvcihhZGRyKTsKICNlbmRpZgogCiAJc2l6ZSA9IDA7CiAKICNpZmRlZiBNQUxMT0NfTEVB S1NfQ0hFQ0sKIAlpZiAobXRwLT5rc19jaGVja19sZWFrcykgewogCQlub2RlID0gKChzdHJ1Y3Qg bGVha19ub2RlICoqKWFkZHIpWy0xXTsKIAkJbXR4X2xvY2soJmxlYWtfbXR4KTsKIAkJTElTVF9S RU1PVkUobm9kZSwgbGVha19saW5rKTsKIAkJbXR4X3VubG9jaygmbGVha19tdHgpOwogCQljYWxs X3N0YWNrX2NsZWFuKCZub2RlLT5zdGFjayk7CkBAIC04MjEsNzUgKzgxOSw3MCBAQCBmcmVlKHZv aWQgKmFkZHIsIHN0cnVjdCBtYWxsb2NfdHlwZSAqbXRwCiB2b2lkICoKIHJlYWxsb2Modm9pZCAq YWRkciwgdW5zaWduZWQgbG9uZyBzaXplLCBzdHJ1Y3QgbWFsbG9jX3R5cGUgKm10cCwgaW50IGZs YWdzKQogewogCXVtYV9zbGFiX3Qgc2xhYjsKIAl1bnNpZ25lZCBsb25nIGFsbG9jOwogCXZvaWQg Km5ld2FkZHI7CiAKIAkvKiByZWFsbG9jKE5VTEwsIC4uLikgaXMgZXF1aXZhbGVudCB0byBtYWxs b2MoLi4uKSAqLwogCWlmIChhZGRyID09IE5VTEwpCiAJCXJldHVybiAobWFsbG9jKHNpemUsIG10 cCwgZmxhZ3MpKTsKIAogCS8qCiAJICogWFhYOiBTaG91bGQgcmVwb3J0IGZyZWUgb2Ygb2xkIG1l bW9yeSBhbmQgYWxsb2Mgb2YgbmV3IG1lbW9yeSB0bwogCSAqIHBlci1DUFUgc3RhdHMuCiAJICov Ci0KLSNpZmRlZiBERUJVR19NRU1HVUFSRAotaWYgKG1lbWd1YXJkX2NtcChtdHApKSB7Ci0Jc2xh YiA9IE5VTEw7Ci0JYWxsb2MgPSBzaXplOwotfSBlbHNlIHsKLSNlbmRpZgotCisJaWYgKGlzX21l bWd1YXJkX2FkZHIoYWRkcikpIHsKKwkJc2xhYiA9IE5VTEw7CisJCWFsbG9jID0gc2l6ZTsKKwkJ Z290byByZW1hbGxvYzsKKwl9CiAjaWZkZWYgREVCVUdfUkVEWk9ORQogCXNsYWIgPSBOVUxMOwog CWFsbG9jID0gcmVkem9uZV9nZXRfc2l6ZShhZGRyKTsKLSNlbHNlCisJZ290byByZW1hbGxvYzsK KyNlbmRpZiAvKiAhREVCVUdfUkVEWk9ORSAqLworCiAjaWZkZWYgTUFMTE9DX0xFQUtTX0NIRUNL CiAJaWYgKG10cC0+a3NfY2hlY2tfbGVha3MpCiAJCXNsYWIgPSB2dG9zbGFiKCgodm1fb2Zmc2V0 X3QgKilhZGRyKVstMV0gJiB+KFVNQV9TTEFCX01BU0spKTsKIAllbHNlCiAjZW5kaWYgLyogTUFM TE9DX0xFQUtTX0NIRUNLICovCiAJCXNsYWIgPSB2dG9zbGFiKCh2bV9vZmZzZXRfdClhZGRyICYg fihVTUFfU0xBQl9NQVNLKSk7CiAKIAkvKiBTYW5pdHkgY2hlY2sgKi8KIAlLQVNTRVJUKHNsYWIg IT0gTlVMTCwKIAkgICAgKCJyZWFsbG9jOiBhZGRyZXNzICVwIG91dCBvZiByYW5nZSIsICh2b2lk ICopYWRkcikpOwogCiAJLyogR2V0IHRoZSBzaXplIG9mIHRoZSBvcmlnaW5hbCBibG9jayAqLwog CWlmICghKHNsYWItPnVzX2ZsYWdzICYgVU1BX1NMQUJfTUFMTE9DKSkKIAkJYWxsb2MgPSBzbGFi LT51c19rZWctPnVrX3NpemU7CiAJZWxzZQogCQlhbGxvYyA9IHNsYWItPnVzX3NpemU7CiAKICNp ZmRlZiBNQUxMT0NfTEVBS1NfQ0hFQ0sKIAlpZiAobXRwLT5rc19jaGVja19sZWFrcykKIAkJLyoq IEFkanVzdCB0aGUgYWxsb2Mgc2l6ZSBieSBzdWJ0cmFjdGluZyB0aGUgc2l6ZSBvZiB0aGUgcGFk LiAqLwogCQlhbGxvYyAtPSAoKGNhZGRyX3QpYWRkciAtICgoY2FkZHJfdCAqKWFkZHIpWy0xXSk7 CiAjZW5kaWYgLyogTUFMTE9DX0xFQUtTX0NIRUNLICovCiAKIAkvKiBSZXVzZSB0aGUgb3JpZ2lu YWwgYmxvY2sgaWYgYXBwcm9wcmlhdGUgKi8KIAlpZiAoc2l6ZSA8PSBhbGxvYwogCSAgICAmJiAo c2l6ZSA+IChhbGxvYyA+PiBSRUFMTE9DX0ZSQUNUSU9OKSB8fCBhbGxvYyA9PSBNSU5BTExPQ1NJ WkUpKQogCQlyZXR1cm4gKGFkZHIpOwotI2VuZGlmIC8qICFERUJVR19SRURaT05FICovCi0KLSNp ZmRlZiBERUJVR19NRU1HVUFSRAotfQotI2VuZGlmCiAKK3JlbWFsbG9jOgogCS8qIEFsbG9jYXRl IGEgbmV3LCBiaWdnZXIgKG9yIHNtYWxsZXIpIGJsb2NrICovCiAJaWYgKChuZXdhZGRyID0gbWFs bG9jKHNpemUsIG10cCwgZmxhZ3MpKSA9PSBOVUxMKQogCQlyZXR1cm4gKE5VTEwpOwogCiAJLyog Q29weSBvdmVyIG9yaWdpbmFsIGNvbnRlbnRzICovCiAJYmNvcHkoYWRkciwgbmV3YWRkciwgbWlu KHNpemUsIGFsbG9jKSk7CiAJZnJlZShhZGRyLCBtdHApOwogCXJldHVybiAobmV3YWRkcik7CiB9 CiAKIC8qCiAgKglyZWFsbG9jZjogc2FtZSBhcyByZWFsbG9jKCkgYnV0IGZyZWUgbWVtb3J5IG9u IGZhaWx1cmUuCiAgKi8KIHZvaWQgKgogcmVhbGxvY2Yodm9pZCAqYWRkciwgdW5zaWduZWQgbG9u ZyBzaXplLCBzdHJ1Y3QgbWFsbG9jX3R5cGUgKm10cCwgaW50IGZsYWdzKQpAQCAtOTAwLDMxICs4 OTMsMzEgQEAgcmVhbGxvY2Yodm9pZCAqYWRkciwgdW5zaWduZWQgbG9uZyBzaXplLAogCQlmcmVl KGFkZHIsIG10cCk7CiAJcmV0dXJuIChtZW0pOwogfQogCiAvKiBYWFhSU1MgdHVybiBzb21lIGV4 dHJhIGNoZWNrcyBvbiBpZiB3ZSdyZSBzZWVpbmcgc2NyaWJibGVycyAqLwogI2RlZmluZSBTQ1JJ QkJMRVJfQ0hFQ0tTIDEKIAogLyoKICAqIEluaXRpYWxpemUgdGhlIGtlcm5lbCBtZW1vcnkgYWxs b2NhdG9yCiAgKi8KIC8qIEFSR1NVU0VEKi8KIHN0YXRpYyB2b2lkCiBrbWVtaW5pdCh2b2lkICpk dW1teSkKIHsKIAl1X2ludDhfdCBpbmR4OwotCXVfbG9uZyBtZW1fc2l6ZTsKKwl1X2xvbmcgbWVt X3NpemUsIHRtcDsKIAlpbnQgaTsKICAKIAltdHhfaW5pdCgmbWFsbG9jX210eCwgIm1hbGxvYyIs IE5VTEwsIE1UWF9ERUYpOwogCW10eF9pbml0KCZtYWxsb2NfcGlnc19tdHgsICJtYWxsb2NfcGln cyIsIE5VTEwsIE1UWF9ERUYpOwogI2lmZGVmIE1BTExPQ19MRUFLU19DSEVDSwogCW10eF9pbml0 KCZsZWFrX210eCwgIm1hbGxvY19sZWFrcyIsIE5VTEwsIE1UWF9ERUYpOwogI2VuZGlmIC8qIE1B TExPQ19MRUFLU19DSEVDSyAqLwogCiAJLyoKIAkgKiBUcnkgdG8gYXV0by10dW5lIHRoZSBrZXJu ZWwgbWVtb3J5IHNpemUsIHNvIHRoYXQgaXQgaXMKIAkgKiBtb3JlIGFwcGxpY2FibGUgZm9yIGEg d2lkZXIgcmFuZ2Ugb2YgbWFjaGluZSBzaXplcy4KIAkgKiBPbiBhbiBYODYsIGEgVk1fS01FTV9T SVpFX1NDQUxFIHZhbHVlIG9mIDQgaXMgZ29vZCwgd2hpbGUKIAkgKiBhIFZNX0tNRU1fU0laRSBv ZiAxMk1CIGlzIGEgZmFpciBjb21wcm9taXNlLiAgVGhlCiAJICogVk1fS01FTV9TSVpFX01BWCBp cyBkZXBlbmRlbnQgb24gdGhlIG1heGltdW0gS1ZBIHNwYWNlCiAJICogYXZhaWxhYmxlLCBhbmQg b24gYW4gWDg2IHdpdGggYSB0b3RhbCBLVkEgc3BhY2Ugb2YgMjU2TUIsCkBAIC05NjgsNDkgKzk2 MSw0MCBAQCBrbWVtaW5pdCh2b2lkICpkdW1teSkKIAogCS8qCiAJICogTGltaXQga21lbSB2aXJ0 dWFsIHNpemUgdG8gdHdpY2UgdGhlIHBoeXNpY2FsIG1lbW9yeS4KIAkgKiBUaGlzIGFsbG93cyBm b3Iga21lbSBtYXAgc3BhcnNlbmVzcywgYnV0IGxpbWl0cyB0aGUgc2l6ZQogCSAqIHRvIHNvbWV0 aGluZyBzYW5lLiBCZSBjYXJlZnVsIHRvIG5vdCBvdmVyZmxvdyB0aGUgMzJiaXQKIAkgKiBpbnRz IHdoaWxlIGRvaW5nIHRoZSBjaGVjay4KIAkgKi8KIAlpZiAoKCh2bV9rbWVtX3NpemUgLyAyKSAv IFBBR0VfU0laRSkgPiB2bV9jbnQudl9wYWdlX2NvdW50KQogCQl2bV9rbWVtX3NpemUgPSAyICog dm1fY250LnZfcGFnZV9jb3VudCAqIFBBR0VfU0laRTsKIAogCS8qCiAJICogVHVuZSBzZXR0aW5n cyBiYXNlZCBvbiB0aGUga21lbSBtYXAncyBzaXplIGF0IHRoaXMgdGltZS4KIAkgKi8KIAlpbml0 X3BhcmFtMyh2bV9rbWVtX3NpemUgLyBQQUdFX1NJWkUpOwogCisJdG1wID0gbWVtZ3VhcmRfZnVk Z2Uodm1fa21lbV9zaXplLCB2bV9rbWVtX3NpemVfbWF4KTsKIAlrbWVtX21hcCA9IGttZW1fc3Vi YWxsb2Moa2VybmVsX21hcCwgJmttZW1iYXNlLCAma21lbWxpbWl0LAotCSAgICB2bV9rbWVtX3Np emUsIFRSVUUpOworCSAgICB0bXAsIFRSVUUpOwogCWttZW1fbWFwLT5zeXN0ZW1fbWFwID0gMTsK LQotI2lmZGVmIERFQlVHX01FTUdVQVJECiAJLyoKIAkgKiBJbml0aWFsaXplIE1lbUd1YXJkIGlm IHN1cHBvcnQgY29tcGlsZWQgaW4uICBNZW1HdWFyZCBpcyBhCiAJICogcmVwbGFjZW1lbnQgYWxs b2NhdG9yIHVzZWQgZm9yIGRldGVjdGluZyB0YW1wZXItYWZ0ZXItZnJlZQogCSAqIHNjZW5hcmlv cyBhcyB0aGV5IG9jY3VyLiAgSXQgaXMgb25seSB1c2VkIGZvciBkZWJ1Z2dpbmcuCiAJICovCi0J dm1fbWVtZ3VhcmRfZGl2aXNvciA9IDEwOwotCVRVTkFCTEVfSU5UX0ZFVENIKCJ2bS5tZW1ndWFy ZC5kaXZpc29yIiwgJnZtX21lbWd1YXJkX2Rpdmlzb3IpOwotCi0JLyogUGljayBhIGNvbnNlcnZh dGl2ZSB2YWx1ZSBpZiBwcm92aWRlZCB2YWx1ZSBzdWNrcy4gKi8KLQlpZiAoKHZtX21lbWd1YXJk X2Rpdmlzb3IgPD0gMCkgfHwKLQkgICAgKCh2bV9rbWVtX3NpemUgLyB2bV9tZW1ndWFyZF9kaXZp c29yKSA9PSAwKSkKLQkJdm1fbWVtZ3VhcmRfZGl2aXNvciA9IDEwOwotCW1lbWd1YXJkX2luaXQo a21lbV9tYXAsIHZtX2ttZW1fc2l6ZSAvIHZtX21lbWd1YXJkX2Rpdmlzb3IpOwotI2VuZGlmCisJ bWVtZ3VhcmRfaW5pdChrbWVtX21hcCk7CiAKIAl1bWFfc3RhcnR1cDIoKTsKIAogCW10X3pvbmUg PSB1bWFfemNyZWF0ZSgibXRfem9uZSIsIHNpemVvZihzdHJ1Y3QgbWFsbG9jX3R5cGVfaW50ZXJu YWwpLAogI2lmIGRlZmluZWQoSU5WQVJJQU5UUykgfHwgZGVmaW5lZChTQ1JJQkJMRVJfQ0hFQ0tT KQogCSAgICBtdHJhc2hfY3RvciwgbXRyYXNoX2R0b3IsIG10cmFzaF9pbml0LCBtdHJhc2hfZmlu aSwKICNlbHNlCiAJICAgIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsCiAjZW5kaWYKIAkgICAgVU1B X0FMSUdOX1BUUiwgVU1BX1pPTkVfTUFMTE9DCiAjaWZkZWYgU0NSSUJCTEVSX0NIRUNLUwogCSAg ICB8IFVNQV9aT05FX01BWEJVQ0tFVAogI2VuZGlmCiAJICAgICk7CiAJZm9yIChpID0gMCwgaW5k eCA9IDA7IGttZW16b25lc1tpbmR4XS5rel9zaXplICE9IDA7IGluZHgrKykgewpJbmRleDogdm0v dm1fa2Vybi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHZtL3ZtX2tlcm4uYwkocmV2aXNpb24gMTQzNTUwKQor Kysgdm0vdm1fa2Vybi5jCSh3b3JraW5nIGNvcHkpCkBAIC0yOTAsMzUgKzI5MCwzMiBAQCBpc2lf a21lbV9tYWxsb2NfZmFpbGVkKHZtX21hcF90IG1hcCwgdm1fCiAgKiAJKGttZW1fb2JqZWN0KS4g IFRoaXMsIGNvbWJpbmVkIHdpdGggdGhlIGZhY3QgdGhhdCBvbmx5IG1hbGxvYyB1c2VzCiAgKiAJ dGhpcyByb3V0aW5lLCBlbnN1cmVzIHRoYXQgd2Ugd2lsbCBuZXZlciBibG9jayBpbiBtYXAgb3Ig b2JqZWN0IHdhaXRzLgogICoKICAqIAlXZSBkb24ndCB3b3JyeSBhYm91dCBleHBhbmRpbmcgdGhl IG1hcCAoYWRkaW5nIGVudHJpZXMpIHNpbmNlIGVudHJpZXMKICAqIAlmb3Igd2lyZWQgbWFwcyBh cmUgc3RhdGljYWxseSBhbGxvY2F0ZWQuCiAgKgogICoJYG1hcCcgaXMgT05MWSBhbGxvd2VkIHRv IGJlIGttZW1fbWFwIG9yIG9uZSBvZiB0aGUgbWJ1ZiBzdWJtYXBzIHRvCiAgKgl3aGljaCB3ZSBu ZXZlciBmcmVlLgogICovCiB2bV9vZmZzZXRfdAoga21lbV9tYWxsb2MobWFwLCBzaXplLCBmbGFn cykKIAl2bV9tYXBfdCBtYXA7CiAJdm1fc2l6ZV90IHNpemU7CiAJaW50IGZsYWdzOwogewotCXZt X29mZnNldF90IG9mZnNldCwgaTsKLQl2bV9tYXBfZW50cnlfdCBlbnRyeTsKIAl2bV9vZmZzZXRf dCBhZGRyOwotCXZtX3BhZ2VfdCBtOwotCWludCBwZmxhZ3M7CisJaW50IGksIHJ2OwogCiAJc2l6 ZSA9IHJvdW5kX3BhZ2Uoc2l6ZSk7CiAJYWRkciA9IHZtX21hcF9taW4obWFwKTsKIAogCS8qCiAJ ICogTG9jYXRlIHN1ZmZpY2llbnQgc3BhY2UgaW4gdGhlIG1hcC4gIFRoaXMgd2lsbCBnaXZlIHVz IHRoZSBmaW5hbAogCSAqIHZpcnR1YWwgYWRkcmVzcyBmb3IgdGhlIG5ldyBtZW1vcnksIGFuZCB0 aHVzIHdpbGwgdGVsbCB1cyB0aGUKIAkgKiBvZmZzZXQgd2l0aGluIHRoZSBrZXJuZWwgbWFwLgog CSAqLwogCXZtX21hcF9sb2NrKG1hcCk7CiAJaWYgKHZtX21hcF9maW5kc3BhY2UobWFwLCB2bV9t YXBfbWluKG1hcCksIHNpemUsICZhZGRyKSkgewogCQl2bV9tYXBfdW5sb2NrKG1hcCk7CiAKICAg ICAgICAgICAgICAgICBpZiAoKGZsYWdzICYgTV9OT1dBSVQpID09IDApIHsKIAkJCWZvciAoaSA9 IDA7IGkgPCA4OyBpKyspIHsKQEAgLTMzOCwzMCArMzM1LDU3IEBAIGttZW1fbWFsbG9jKG1hcCwg c2l6ZSwgZmxhZ3MpCiAJCQkJcGFuaWNfc3RhcnQoImttZW1fbWFsbG9jKCVsZCk6ICVzIHRvbyBz bWFsbC4iLAogCQkJCSAgICAobG9uZylzaXplLCBtYXAgPT0ga21lbV9tYXAgPyAia21lbV9tYXAi IDoKIAkJCQkgICAgIm1idWYgc3BhY2UiKTsKIAkJCQlpZiAobV9leGhhdXN0ZWRfY2IpCiAJCQkJ CW1fZXhoYXVzdGVkX2NiKCk7CiAJCQkJZWxzZQogCQkJCQlwcmludF9tYnVmX3VzYWdlKCk7CiAJ CQkJcHJpbnRfYWxsb2NfcGlncygpOwogCQkJCXBhbmljX2ZpbmlzaCgpOwogCQkJfQogCQl9IGVs c2UgewogCQkJaXNpX2ttZW1fbWFsbG9jX2ZhaWxlZChtYXAsIHNpemUpOwogCQkJcmV0dXJuICgw KTsKIAkJfQogCX0KKworCS8qIGJlZ2luIElzaWxvbiAqLworCXJ2ID0ga21lbV9iYWNrKG1hcCwg YWRkciwgc2l6ZSwgZmxhZ3MpOworCS8qIGVuZCBJc2lsb24gKi8KKwl2bV9tYXBfdW5sb2NrKG1h cCk7CisKKwlyZXR1cm4gKHJ2ID09IEtFUk5fU1VDQ0VTUyA/IGFkZHIgOiAodm1fb2Zmc2V0X3Qp TlVMTCk7Cit9CisKKy8qCisgKiBJc2lsb246IHNwbGl0IHVwIHRoZSB3b3JrIG9mIGttZW1fbWFs bG9jIGludG8gb25lIHJvdXRpbmUgdGhhdAorICogZmluZHMgdGhlIGFkZHJlc3MgdG8gdXNlLCBh bmQgYW5vdGhlciB0byBnZXQgcGFnZXMgZm9yIHRoZQorICogYWRkcmVzc2VzLgorICovCitpbnQK K2ttZW1fYmFjayh2bV9tYXBfdCBtYXAsIHZtX29mZnNldF90IGFkZHIsIHZtX3NpemVfdCBzaXpl LCBpbnQgZmxhZ3MpCit7CisJdm1fb2Zmc2V0X3Qgb2Zmc2V0LCBpOworCXZtX21hcF9lbnRyeV90 IGVudHJ5OworCXZtX3BhZ2VfdCBtOworCWludCBwZmxhZ3M7CisKKwkvKgorCSAqIFhYWCB0aGUg bWFwIG11c3QgYmUgbG9ja2VkIGZvciB3cml0ZSBvbiBlbnRyeSwgYnV0IHRoZXJlJ3MKKwkgKiBu byB3YXkgdG8gYXNzZXJ0IHRoYXQuCisJICovCisKIAlvZmZzZXQgPSBhZGRyIC0gVk1fTUlOX0tF Uk5FTF9BRERSRVNTOwogCXZtX29iamVjdF9yZWZlcmVuY2Uoa21lbV9vYmplY3QpOwogCXZtX21h cF9pbnNlcnQobWFwLCBrbWVtX29iamVjdCwgb2Zmc2V0LCBhZGRyLCBhZGRyICsgc2l6ZSwKIAkJ Vk1fUFJPVF9BTEwsIFZNX1BST1RfQUxMLCAwKTsKIAogCWlmICgoZmxhZ3MgJiAoTV9OT1dBSVR8 TV9VU0VfUkVTRVJWRSkpID09IE1fTk9XQUlUKQogCQlwZmxhZ3MgPSBWTV9BTExPQ19JTlRFUlJV UFQgfCBWTV9BTExPQ19XSVJFRDsKIAllbHNlCiAJCXBmbGFncyA9IFZNX0FMTE9DX1NZU1RFTSB8 IFZNX0FMTE9DX1dJUkVEOwogCiAJaWYgKGZsYWdzICYgTV9aRVJPKQogCQlwZmxhZ3MgfD0gVk1f QUxMT0NfWkVSTzsKIAlpZiAoZmxhZ3MgJiBNX05PRFVNUCkKIAkJcGZsYWdzIHw9IFZNX0FMTE9D X05PRFVNUDsKIApAQCAtMzkwLDMyICs0MTQsMzEgQEAgcmV0cnk6CiAJCQkgKiBUaGV5IGFyZSBh bHJlYWR5IG1hcmtlZCBidXN5LiAgQ2FsbGluZwogCQkJICogdm1fbWFwX2RlbGV0ZSBiZWZvcmUg dGhlIHBhZ2VzIGhhcyBiZWVuIGZyZWVkIG9yCiAJCQkgKiB1bmJ1c2llZCB3aWxsIGNhdXNlIGEg ZGVhZGxvY2suCiAJCQkgKi8KIAkJCXdoaWxlIChpICE9IDApIHsKIAkJCQlpIC09IFBBR0VfU0la RTsKIAkJCQltID0gdm1fcGFnZV9sb29rdXAoa21lbV9vYmplY3QsCiAJCQkJCQkgICBPRkZfVE9f SURYKG9mZnNldCArIGkpKTsKIAkJCQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7CiAJCQkJdm1fcGFn ZV91bndpcmUobSwgMCk7CiAJCQkJdm1fcGFnZV9mcmVlKG0pOwogCQkJCXZtX3BhZ2VfdW5sb2Nr X3F1ZXVlcygpOwogCQkJfQogCQkJVk1fT0JKRUNUX1VOTE9DSyhrbWVtX29iamVjdCk7CiAJCQl2 bV9tYXBfZGVsZXRlKG1hcCwgYWRkciwgYWRkciArIHNpemUpOwotCQkJdm1fbWFwX3VubG9jayht YXApOwotCQkJcmV0dXJuICgwKTsKKwkJCXJldHVybiAoS0VSTl9OT19TUEFDRSk7CiAJCX0KIAkJ aWYgKGZsYWdzICYgTV9aRVJPICYmIChtLT5mbGFncyAmIFBHX1pFUk8pID09IDApCiAJCQlwbWFw X3plcm9fcGFnZShtKTsKIAkJbS0+dmFsaWQgPSBWTV9QQUdFX0JJVFNfQUxMOwogCQlLQVNTRVJU KChtLT5mbGFncyAmIFBHX1VOTUFOQUdFRCkgIT0gMCwKIAkJICAgICgia21lbV9tYWxsb2M6IHBh Z2UgJXAgaXMgbWFuYWdlZCIsIG0pKTsKIAl9CiAJVk1fT0JKRUNUX1VOTE9DSyhrbWVtX29iamVj dCk7CiAKIAkvKgogCSAqIE1hcmsgbWFwIGVudHJ5IGFzIG5vbi1wYWdlYWJsZS4gQXNzZXJ0OiB2 bV9tYXBfaW5zZXJ0KCkgd2lsbCBuZXZlcgogCSAqIGJlIGFibGUgdG8gZXh0ZW5kIHRoZSBwcmV2 aW91cyBlbnRyeSBzbyB0aGVyZSB3aWxsIGJlIGEgbmV3IGVudHJ5CiAJICogZXhhY3RseSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgYWRkcmVzcyByYW5nZSBhbmQgaXQgd2lsbCBoYXZlCiAJICogd2ly ZWRfY291bnQgPT0gMC4KIAkgKi8KQEAgLTQzNCwzMyArNDU3LDMxIEBAIHJldHJ5OgogCiAJLyoK IAkgKiBMb29wIHRocnUgcGFnZXMsIGVudGVyaW5nIHRoZW0gaW4gdGhlIHBtYXAuCiAJICovCiAJ Vk1fT0JKRUNUX0xPQ0soa21lbV9vYmplY3QpOwogCWZvciAoaSA9IDA7IGkgPCBzaXplOyBpICs9 IFBBR0VfU0laRSkgewogCQltID0gdm1fcGFnZV9sb29rdXAoa21lbV9vYmplY3QsIE9GRl9UT19J RFgob2Zmc2V0ICsgaSkpOwogCQkvKgogCQkgKiBCZWNhdXNlIHRoaXMgaXMga2VybmVsX3BtYXAs IHRoaXMgY2FsbCB3aWxsIG5vdCBibG9jay4KIAkJICovCiAJCXBtYXBfZW50ZXIoa2VybmVsX3Bt YXAsIGFkZHIgKyBpLCBWTV9QUk9UX0FMTCwgbSwgVk1fUFJPVF9BTEwsCiAJCSAgICBUUlVFKTsK IAkJdm1fcGFnZV93YWtldXAobSk7CiAJfQogCVZNX09CSkVDVF9VTkxPQ0soa21lbV9vYmplY3Qp OwotCXZtX21hcF91bmxvY2sobWFwKTsKLQotCXJldHVybiAoYWRkcik7CisJcmV0dXJuIChLRVJO X1NVQ0NFU1MpOwogfQogCiAvKgogICoJa21lbV9hbGxvY193YWl0OgogICoKICAqCUFsbG9jYXRl cyBwYWdlYWJsZSBtZW1vcnkgZnJvbSBhIHN1Yi1tYXAgb2YgdGhlIGtlcm5lbC4gIElmIHRoZSBz dWJtYXAKICAqCWhhcyBubyByb29tLCB0aGUgY2FsbGVyIHNsZWVwcyB3YWl0aW5nIGZvciBtb3Jl IG1lbW9yeSBpbiB0aGUgc3VibWFwLgogICoKICAqCVRoaXMgcm91dGluZSBtYXkgYmxvY2suCiAg Ki8KIHZtX29mZnNldF90CiBrbWVtX2FsbG9jX3dhaXQobWFwLCBzaXplKQogCXZtX21hcF90IG1h cDsKIAl2bV9zaXplX3Qgc2l6ZTsKIHsKSW5kZXg6IHZtL21lbWd1YXJkLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gdm0vbWVtZ3VhcmQuaAkocmV2aXNpb24gMTQzNTUwKQorKysgdm0vbWVtZ3VhcmQuaAkod29y a2luZyBjb3B5KQpAQCAtMTQsMjEgKzE0LDMyIEBACiAgKgogICogVEhJUyBTT0ZUV0FSRSBJUyBQ Uk9WSURFRCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKICAqIElN UExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBM SUVEIFdBUlJBTlRJRVMKICAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQ QVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCiAgKiBJTiBOTyBFVkVOVCBTSEFMTCBU SEUgQVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCiAgKiBJTkNJREVO VEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQKICAqIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdP T0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwKICAqIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJV U0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQogICogVEhFT1JZ IE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1Ig VE9SVAogICogKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBB TlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GCiAgKiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklT RUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgogICoKICAqICRGcmVlQlNEJAog ICovCiAKLWV4dGVybiB1X2ludCB2bV9tZW1ndWFyZF9kaXZpc29yOworI2luY2x1ZGUgIm9wdF92 bS5oIgogCi12b2lkCW1lbWd1YXJkX2luaXQodm1fbWFwX3QgcGFyZW50X21hcCwgdW5zaWduZWQg bG9uZyBzaXplKTsKLXZvaWQgCSptZW1ndWFyZF9hbGxvYyh1bnNpZ25lZCBsb25nIHNpemUsIGlu dCBmbGFncyk7Ci12b2lkCW1lbWd1YXJkX2ZyZWUodm9pZCAqYWRkcik7Ci1pbnQJbWVtZ3VhcmRf Y21wKHN0cnVjdCBtYWxsb2NfdHlwZSAqbXRwKTsKKyNpZmRlZiBERUJVR19NRU1HVUFSRAordW5z aWduZWQgbG9uZwltZW1ndWFyZF9mdWRnZSh1bnNpZ25lZCBsb25nLCB1bnNpZ25lZCBsb25nKTsK K3ZvaWQJbWVtZ3VhcmRfaW5pdChzdHJ1Y3Qgdm1fbWFwICopOwordm9pZCAJKm1lbWd1YXJkX2Fs bG9jKHVuc2lnbmVkIGxvbmcsIGludCk7Cit2b2lkCW1lbWd1YXJkX2ZyZWUodm9pZCAqKTsKK2lu dAltZW1ndWFyZF9jbXAoc3RydWN0IG1hbGxvY190eXBlICosIHVuc2lnbmVkIGxvbmcpOworaW50 CWlzX21lbWd1YXJkX2FkZHIodm9pZCAqKTsKKyNlbHNlCisjZGVmaW5lCW1lbWd1YXJkX2Z1ZGdl KHNpemUsIHh4eCkJKHNpemUpCisjZGVmaW5lCW1lbWd1YXJkX2luaXQobWFwKQkJZG8geyB9IHdo aWxlICgwKQorI2RlZmluZQltZW1ndWFyZF9hbGxvYyhzaXplLCBmbGFncykJTlVMTAorI2RlZmlu ZQltZW1ndWFyZF9mcmVlKGFkZHIpCQlkbyB7IH0gd2hpbGUgKDApCisjZGVmaW5lCW1lbWd1YXJk X2NtcChtdHAsIHNpemUpCQkwCisjZGVmaW5lCWlzX21lbWd1YXJkX2FkZHIoYWRkcikJCTAKKyNl bmRpZgpJbmRleDogdm0vaXNpX21lbWd1YXJkLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdm0vaXNpX21lbWd1 YXJkLmMJKHJldmlzaW9uIDApCisrKyB2bS9pc2lfbWVtZ3VhcmQuYwkocmV2aXNpb24gMCkKQEAg LTAsMCArMSwzNTYgQEAKKy8qCisgKiBDb3B5cmlnaHQgKGMpIDIwMDUsCisgKiAgICAgQm9za28g TWlsZWtpYyA8Ym1pbGVraWNARnJlZUJTRC5vcmc+LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAq CisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3 aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0 aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJp YnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0Cisg KiAgICBub3RpY2UgdW5tb2RpZmllZCwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMsIGFuZCB0aGUg Zm9sbG93aW5nCisgKiAgICBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJp bmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGlj ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBp biB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRl ZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURF RCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKyAqIElNUExJRUQg V0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdB UlJBTlRJRVMKKyAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCisgKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVU SE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCisgKiBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBC VVQKKyAqIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9S IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwKKyAqIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQorICogVEhFT1JZIE9GIExJ QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVAor ICogKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZ IE9VVCBPRiBUSEUgVVNFIE9GCisgKiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2Rl ZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworLyoKKyAqIE1lbUd1YXJkIGlzIGEgc2lt cGxlIHJlcGxhY2VtZW50IGFsbG9jYXRvciBmb3IgZGVidWdnaW5nIG9ubHkKKyAqIHdoaWNoIHBy b3ZpZGVzIEVsZWN0cmljRmVuY2Utc3R5bGUgbWVtb3J5IGJhcnJpZXIgcHJvdGVjdGlvbiBvbgor ICogb2JqZWN0cyBiZWluZyBhbGxvY2F0ZWQsIGFuZCBpcyB1c2VkIHRvIGRldGVjdCB0YW1wZXJp bmctYWZ0ZXItZnJlZQorICogc2NlbmFyaW9zLgorICoKKyAqIFNlZSB0aGUgbWVtZ3VhcmQoOSkg bWFuIHBhZ2UgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdXNpbmcgTWVtR3VhcmQuCisgKi8KKwor I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1ZGUg PHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNpbmNsdWRlIDxzeXMvcXVl dWUuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9tdXRleC5oPgorI2lu Y2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisKKyNpbmNsdWRl IDx2bS92bS5oPgorI2luY2x1ZGUgPHZtL3VtYS5oPgorI2luY2x1ZGUgPHZtL3ZtX3BhcmFtLmg+ CisjaW5jbHVkZSA8dm0vdm1fcGFnZS5oPgorI2luY2x1ZGUgPHZtL3ZtX21hcC5oPgorI2luY2x1 ZGUgPHZtL3ZtX29iamVjdC5oPgorI2luY2x1ZGUgPHZtL3ZtX2V4dGVybi5oPgorI2luY2x1ZGUg PHZtL21lbWd1YXJkLmg+CisKK1NZU0NUTF9OT0RFKF92bSwgT0lEX0FVVE8sIG1lbWd1YXJkLCBD VExGTEFHX1JXLCBOVUxMLCAiTWVtR3VhcmQgZGF0YSIpOworLyoKKyAqIFRoZSB2bV9tZW1ndWFy ZF9kaXZpc29yIHZhcmlhYmxlIGNvbnRyb2xzIGhvdyBtdWNoIG9mIGttZW1fbWFwIHNob3VsZCBi ZQorICogcmVzZXJ2ZWQgZm9yIE1lbUd1YXJkLgorICovCitzdGF0aWMgdV9pbnQgdm1fbWVtZ3Vh cmRfZGl2aXNvcjsKK1NZU0NUTF9VSU5UKF92bV9tZW1ndWFyZCwgT0lEX0FVVE8sIGRpdmlzb3Is IENUTEZMQUdfUkRUVU4sCisgICAgJnZtX21lbWd1YXJkX2Rpdmlzb3IsCisgICAgMCwgIihrbWVt X3NpemUvbWVtZ3VhcmRfZGl2aXNvcikgPT0gbWVtZ3VhcmQgc3VibWFwIHNpemUiKTsgICAgIAor CisvKgorICogU2hvcnQgZGVzY3JpcHRpb24gKGtzX3Nob3J0ZGVzYykgb2YgbWVtb3J5IHR5cGUg dG8gbW9uaXRvci4KKyAqLworc3RhdGljIGNoYXIgdm1fbWVtZ3VhcmRfZGVzY1sxMjhdID0gIiI7 CitzdGF0aWMgc3RydWN0IG1hbGxvY190eXBlICp2bV9tZW1ndWFyZF9tdHlwZSA9IE5VTEw7CitU VU5BQkxFX1NUUigidm0ubWVtZ3VhcmQuZGVzYyIsIHZtX21lbWd1YXJkX2Rlc2MsIHNpemVvZih2 bV9tZW1ndWFyZF9kZXNjKSk7CitzdGF0aWMgaW50CittZW1ndWFyZF9zeXNjdGxfZGVzYyhTWVND VExfSEFORExFUl9BUkdTKQoreworCWNoYXIgZGVzY1tzaXplb2Yodm1fbWVtZ3VhcmRfZGVzYyld OworCWludCBlcnJvcjsKKworCXN0cmxjcHkoZGVzYywgdm1fbWVtZ3VhcmRfZGVzYywgc2l6ZW9m KGRlc2MpKTsKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfc3RyaW5nKG9pZHAsIGRlc2MsIHNpemVv ZihkZXNjKSwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQor CQlyZXR1cm4gKGVycm9yKTsKKworCW10eF9sb2NrKCZtYWxsb2NfbXR4KTsKKwkvKgorCSAqIElm IG10cCBpcyBOVUxMLCBpdCB3aWxsIGJlIGluaXRpYWxpemVkIGluIG1lbWd1YXJkX2NtcCgpLgor CSAqLworCXZtX21lbWd1YXJkX210eXBlID0gbWFsbG9jX2Rlc2MydHlwZShkZXNjKTsKKwlzdHJs Y3B5KHZtX21lbWd1YXJkX2Rlc2MsIGRlc2MsIHNpemVvZih2bV9tZW1ndWFyZF9kZXNjKSk7CisJ bXR4X3VubG9jaygmbWFsbG9jX210eCk7CisJcmV0dXJuIChlcnJvcik7Cit9CitTWVNDVExfUFJP Qyhfdm1fbWVtZ3VhcmQsIE9JRF9BVVRPLCBkZXNjLAorICAgIENUTFRZUEVfU1RSSU5HIHwgQ1RM RkxBR19SVyB8IENUTEZMQUdfTVBTQUZFLCAwLCAwLAorICAgIG1lbWd1YXJkX3N5c2N0bF9kZXNj LCAiQSIsICJTaG9ydCBkZXNjcmlwdGlvbiBvZiBtZW1vcnkgdHlwZSB0byBtb25pdG9yIik7CisK K3N0YXRpYyBzdHJ1Y3Qgdm1fbWFwICptZW1ndWFyZF9tYXA7CitzdGF0aWMgdm1fb2Zmc2V0X3Qg bWVtZ3VhcmRfY3Vyc29yOworc3RhdGljIHZtX3NpemVfdCBtZW1ndWFyZF9tYXBzaXplOworc3Rh dGljIHZtX3NpemVfdCBtZW1ndWFyZF9waHlzbGltaXQ7CitzdGF0aWMgdV9sb25nIG1lbWd1YXJk X3dyYXA7CitzdGF0aWMgdV9sb25nIG1lbWd1YXJkX3N1Y2M7CitzdGF0aWMgdV9sb25nIG1lbWd1 YXJkX2ZhaWxfa3ZhOworc3RhdGljIHVfbG9uZyBtZW1ndWFyZF9mYWlsX3BnczsKKworU1lTQ1RM X1VMT05HKF92bV9tZW1ndWFyZCwgT0lEX0FVVE8sIGN1cnNvciwgQ1RMRkxBR19SRCwKKyAgICAm bWVtZ3VhcmRfY3Vyc29yLCAwLCAiTWVtR3VhcmQgY3Vyc29yIik7CitTWVNDVExfVUxPTkcoX3Zt X21lbWd1YXJkLCBPSURfQVVUTywgbWFwc2l6ZSwgQ1RMRkxBR19SRCwKKyAgICAmbWVtZ3VhcmRf bWFwc2l6ZSwgMCwgIk1lbUd1YXJkIHByaXZhdGUgdm1fbWFwIHNpemUiKTsKK1NZU0NUTF9VTE9O Ryhfdm1fbWVtZ3VhcmQsIE9JRF9BVVRPLCBwaHlzX2xpbWl0LCBDVExGTEFHX1JELAorICAgICZt ZW1ndWFyZF9waHlzbGltaXQsIDAsICJMaW1pdCBvbiBNZW1HdWFyZCBtZW1vcnkgY29uc3VtcHRp b24iKTsKK1NZU0NUTF9VTE9ORyhfdm1fbWVtZ3VhcmQsIE9JRF9BVVRPLCB3cmFwY250LCBDVExG TEFHX1JELAorICAgICZtZW1ndWFyZF93cmFwLCAwLCAiTWVtR3VhcmQgY3Vyc29yIHdyYXAgY291 bnQiKTsKK1NZU0NUTF9VTE9ORyhfdm1fbWVtZ3VhcmQsIE9JRF9BVVRPLCBudW1hbGxvYywgQ1RM RkxBR19SRCwKKyAgICAmbWVtZ3VhcmRfc3VjYywgMCwgIkNvdW50IG9mIHN1Y2Nlc3NmdWwgTWVt R3VhcmQgYWxsb2NhdGlvbnMiKTsKK1NZU0NUTF9VTE9ORyhfdm1fbWVtZ3VhcmQsIE9JRF9BVVRP LCBmYWlsX2t2YSwgQ1RMRkxBR19SRCwKKyAgICAmbWVtZ3VhcmRfZmFpbF9rdmEsIDAsICJNZW1H dWFyZCBmYWlsdXJlcyBkdWUgdG8gbGFjayBvZiBLVkEiKTsKK1NZU0NUTF9VTE9ORyhfdm1fbWVt Z3VhcmQsIE9JRF9BVVRPLCBmYWlsX3BncywgQ1RMRkxBR19SRCwKKyAgICAmbWVtZ3VhcmRfZmFp bF9wZ3MsIDAsICJNZW1HdWFyZCBmYWlsdXJlcyBkdWUgdG8gbGFjayBvZiBwYWdlcyIpOworCisv KgorICogUmV0dXJuIGEgZnVkZ2VkIHZhbHVlIGZvciB2bV9rbWVtX3NpemUgZm9yIGFsbG9jYXRp bmcgdGhlCisgKiBrZXJuZWxfbWFwLiAgVGhlIG1lbWd1YXJkIG1lbW9yeSB3aWxsIGJlIGEgc3Vi bWFwLgorICovCit1bnNpZ25lZCBsb25nCittZW1ndWFyZF9mdWRnZSh1bnNpZ25lZCBsb25nIHZt X2ttZW1fc2l6ZSwgdW5zaWduZWQgbG9uZyB2bV9rbWVtX21heCkKK3sKKwl1X2xvbmcgbWVtX3Bn cyA9IHZtX2NudC52X3BhZ2VfY291bnQ7CisKKwl2bV9tZW1ndWFyZF9kaXZpc29yID0gMTA7CisJ VFVOQUJMRV9JTlRfRkVUQ0goInZtLm1lbWd1YXJkLmRpdmlzb3IiLCAmdm1fbWVtZ3VhcmRfZGl2 aXNvcik7CisKKwkvKiBQaWNrIGEgY29uc2VydmF0aXZlIHZhbHVlIGlmIHByb3ZpZGVkIHZhbHVl IHN1Y2tzLiAqLworCWlmICgodm1fbWVtZ3VhcmRfZGl2aXNvciA8PSAwKSB8fAorCSAgICAoKHZt X2ttZW1fc2l6ZSAvIHZtX21lbWd1YXJkX2Rpdmlzb3IpID09IDApKQorCQl2bV9tZW1ndWFyZF9k aXZpc29yID0gMTA7CisJLyoKKwkgKiBMaW1pdCBjb25zdW1wdGlvbiBvZiBwYWdlcyB0byAxL3Zt X21lbWd1YXJkX2Rpdmlzb3Igb2YKKwkgKiBzeXN0ZW0gbWVtb3J5LiAgSWYgdGhlIEtWQSBpcyBz bWFsbGVyIHRoYW4gdGhpcyB0aGVuIHRoZQorCSAqIEtWQSBsaW1pdCBjb21lcyBpbnRvIHBsYXkg Zmlyc3QuICBUaGlzIHByZXZlbnRzIG1lbWd1YXJkJ3MKKwkgKiBwYWdlIHByb21vdGlvbnMgZnJv bSBjb21wbGV0ZWx5IHVzaW5nIHVwIG1lbW9yeSwgc2luY2UgbW9zdAorCSAqIG1hbGxvYyg5KSBj YWxscyBhcmUgc3ViLXBhZ2UuCisJICovCisJbWVtZ3VhcmRfcGh5c2xpbWl0ID0gKG1lbV9wZ3Mg LyB2bV9tZW1ndWFyZF9kaXZpc29yKSAqIFBBR0VfU0laRTsKKwkvKgorCSAqIFdlIHdhbnQgYXMg bXVjaCBLVkEgYXMgd2UgY2FuIHRha2Ugc2FmZWx5LiAgVXNlIGF0IG1vc3Qgb3VyCisJICogYWxs b3R0ZWQgZnJhY3Rpb24gb2Yga21lbV9tYXguICBMaW1pdCB0aGlzIHRvIHR3aWNlIHRoZQorCSAq IHBoeXNpY2FsIG1lbW9yeSB0byBhdm9pZCB1c2luZyB0b28gbXVjaCBtZW1vcnkgYXMgcGFnZXRh YmxlCisJICogcGFnZXMuCisJICovCisJbWVtZ3VhcmRfbWFwc2l6ZSA9IHZtX2ttZW1fbWF4IC8g dm1fbWVtZ3VhcmRfZGl2aXNvcjsKKwkvKiBzaXplIG11c3QgYmUgbXVsdGlwbGUgb2YgUEFHRV9T SVpFICovCisJbWVtZ3VhcmRfbWFwc2l6ZSA9IHJvdW5kX3BhZ2UobWVtZ3VhcmRfbWFwc2l6ZSk7 CisJaWYgKG1lbWd1YXJkX21hcHNpemUgLyAoMiAqIFBBR0VfU0laRSkgPiBtZW1fcGdzKQorCQlt ZW1ndWFyZF9tYXBzaXplID0gbWVtX3BncyAqIDIgKiBQQUdFX1NJWkU7CisJaWYgKHZtX2ttZW1f c2l6ZSArIG1lbWd1YXJkX21hcHNpemUgPiB2bV9rbWVtX21heCkKKwkJcmV0dXJuICh2bV9rbWVt X21heCk7CisJcmV0dXJuICh2bV9rbWVtX3NpemUgKyBtZW1ndWFyZF9tYXBzaXplKTsKK30KKwor LyoKKyAqIEluaXRpYWxpemUgdGhlIE1lbUd1YXJkIG1vY2sgYWxsb2NhdG9yLiAgQWxsIG9iamVj dHMgZnJvbSBNZW1HdWFyZCBjb21lCisgKiBvdXQgb2YgYSBzaW5nbGUgVk0gbWFwIChjb250aWd1 b3VzIGNodW5rIG9mIGFkZHJlc3Mgc3BhY2UpLgorICovCit2b2lkCittZW1ndWFyZF9pbml0KHZt X21hcF90IHBhcmVudF9tYXApCit7CisJdm1fb2Zmc2V0X3QgYmFzZSwgbGltaXQ7CisKKwltZW1n dWFyZF9tYXAgPSBrbWVtX3N1YmFsbG9jKHBhcmVudF9tYXAsICZiYXNlLCAmbGltaXQsCisJICAg IG1lbWd1YXJkX21hcHNpemUsIEZBTFNFKTsKKwltZW1ndWFyZF9tYXAtPnN5c3RlbV9tYXAgPSAx OworCUtBU1NFUlQobWVtZ3VhcmRfbWFwc2l6ZSA9PSBsaW1pdCAtIGJhc2UsCisJICAgICgiRXhw ZWN0ZWQgJWxkLCBnb3QgJWxkIiwgbWVtZ3VhcmRfbWFwc2l6ZSwgbGltaXQgLSBiYXNlKSk7CisJ bWVtZ3VhcmRfY3Vyc29yID0gYmFzZTsKKworCXByaW50ZigiTUVNR1VBUkQgREVCVUdHSU5HIEFM TE9DQVRPUiBJTklUSUFMSVpFRDpcbiIpOworCXByaW50ZigiXHRNRU1HVUFSRCBtYXAgYmFzZTog MHglbHhcbiIsIGJhc2UpOworCXByaW50ZigiXHRNRU1HVUFSRCBtYXAgbGltaXQ6IDB4JWx4XG4i LCBsaW1pdCk7CisJcHJpbnRmKCJcdE1FTUdVQVJEIG1hcCBzaXplOiAlbGQgS0J5dGVzXG4iLCBt ZW1ndWFyZF9tYXBzaXplID4+IDEwKTsKK30KKworLyoKKyAqIFJ1biB0aGluZ3MgdGhhdCBjYW4n dCBiZSBkb25lIGFzIGVhcmx5IGFzIG1lbWd1YXJkX2luaXQoKS4KKyAqLworc3RhdGljIHZvaWQK K21lbWd1YXJkX3N5c2luaXQodm9pZCkKK3sKKwlzdHJ1Y3Qgc3lzY3RsX29pZF9saXN0ICpwYXJl bnQ7CisKKwlwYXJlbnQgPSBTWVNDVExfU1RBVElDX0NISUxEUkVOKF92bV9tZW1ndWFyZCk7CisK KwlTWVNDVExfQUREX1VMT05HKE5VTEwsIHBhcmVudCwgT0lEX0FVVE8sICJtYXBzdGFydCIsIENU TEZMQUdfUkQsCisJICAgICZtZW1ndWFyZF9tYXAtPm1pbl9vZmZzZXQsICJNZW1HdWFyZCBLVkEg YmFzZSIpOworCVNZU0NUTF9BRERfVUxPTkcoTlVMTCwgcGFyZW50LCBPSURfQVVUTywgIm1hcGxp bWl0IiwgQ1RMRkxBR19SRCwKKwkgICAgJm1lbWd1YXJkX21hcC0+bWF4X29mZnNldCwgIk1lbUd1 YXJkIEtWQSBlbmQiKTsKKwlTWVNDVExfQUREX1VMT05HKE5VTEwsIHBhcmVudCwgT0lEX0FVVE8s ICJtYXB1c2VkIiwgQ1RMRkxBR19SRCwKKwkgICAgJm1lbWd1YXJkX21hcC0+c2l6ZSwgIk1lbUd1 YXJkIEtWQSB1c2VkIik7Cit9CitTWVNJTklUKG1lbWd1YXJkLCBTSV9TVUJfS0xELCBTSV9PUkRF Ul9BTlksIG1lbWd1YXJkX3N5c2luaXQsIE5VTEwpOworCisvKgorICogdjJzaXplcCgpIGNvbnZl cnRzIGEgdmlydHVhbCBhZGRyZXNzIG9mIHRoZSBmaXJzdCBwYWdlIGFsbG9jYXRlZCBmb3IKKyAq IGFuIGl0ZW0gdG8gYSBwb2ludGVyIHRvIHVfbG9uZyByZWNvcmRpbmcgdGhlIHNpemUgb2YgdGhl IG9yaWdpbmFsCisgKiBhbGxvY2F0aW9uIHJlcXVlc3QuCisgKgorICogVGhpcyByb3V0aW5lIGlz IHZlcnkgc2ltaWxhciB0byB0aG9zZSBkZWZpbmVkIGJ5IFVNQSBpbiB1bWFfaW50LmguCisgKiBU aGUgZGlmZmVyZW5jZSBpcyB0aGF0IHRoaXMgcm91dGluZSBzdG9yZXMgdGhlIG1nZmlmbyBpbiBv bmUgb2YgdGhlCisgKiBwYWdlJ3MgZmllbGRzIHRoYXQgaXMgdW51c2VkIHdoZW4gdGhlIHBhZ2Ug aXMgd2lyZWQgcmF0aGVyIHRoYW4gdGhlCisgKiBvYmplY3QgZmllbGQsIHdoaWNoIGlzIHVzZWQu CisgKi8KK3N0YXRpYyB1X2xvbmcgKgordjJzaXplcCh2bV9vZmZzZXRfdCB2YSkKK3sKKwlzdHJ1 Y3Qgdm1fcGFnZSAqcDsKKworCXAgPSBQSFlTX1RPX1ZNX1BBR0UocG1hcF9rZXh0cmFjdCh2YSkp OworCUtBU1NFUlQocC0+d2lyZV9jb3VudCAhPSAwICYmIHAtPnF1ZXVlID09IFBRX05PTkUsCisJ ICAgICgiTUVNR1VBUkQ6IEV4cGVjdGVkIHdpcmVkIHBhZ2UgJXAgaW4gdnRvbWdmaWZvISIsIHAp KTsKKwlyZXR1cm4gKHVfbG9uZyAqKSZwLT5wYWdlcS50cWVfbmV4dDsKK30KKworLyoKKyAqIEFs bG9jYXRlIGEgc2luZ2xlIG9iamVjdCBvZiBzcGVjaWZpZWQgc2l6ZSB3aXRoIHNwZWNpZmllZCBm bGFncworICogKGVpdGhlciBNX1dBSVRPSyBvciBNX05PV0FJVCkuCisgKi8KK3ZvaWQgKgorbWVt Z3VhcmRfYWxsb2ModW5zaWduZWQgbG9uZyByZXFfc2l6ZSwgaW50IGZsYWdzKQoreworCXZtX29m ZnNldF90IGFkZHI7CisJdV9sb25nIHNpemU7CisJaW50IHJ2OworCisJc2l6ZSA9IHJvdW5kX3Bh Z2UocmVxX3NpemUpOworCWlmIChzaXplID09IDApCisJCXJldHVybiBOVUxMOworCXZtX21hcF9s b2NrKG1lbWd1YXJkX21hcCk7CisJLyoKKwkgKiBXaGVuIHdlIHBhc3Mgb3VyIG1lbW9yeSBsaW1p dCwgcmVqZWN0IHN1Yi1wYWdlIGFsbG9jYXRpb25zLgorCSAqIFBhZ2Utc2l6ZSBhbmQgbGFyZ2Vy IGFsbG9jYXRpb25zIHdpbGwgdXNlIHRoZSBzYW1lIGFtb3VudAorCSAqIG9mIHBoeXNpY2FsIG1l bW9yeSB3aGV0aGVyIHdlIGFsbG9jYXRlIG9yIGhhbmQgb2ZmIHRvCisJICogdW1hX2xhcmdlX2Fs bG9jKCksIHNvIGtlZXAgdGhvc2UuCisJICovCisJaWYgKG1lbWd1YXJkX21hcC0+c2l6ZSA+PSBt ZW1ndWFyZF9waHlzbGltaXQgJiYKKwkgICAgcmVxX3NpemUgPCBQQUdFX1NJWkUpIHsKKwkJYWRk ciA9ICh2bV9vZmZzZXRfdClOVUxMOworCQltZW1ndWFyZF9mYWlsX3BncysrOworCQlnb3RvIG91 dDsKKwl9CisJLyoKKwkgKiBLZWVwIGEgbW92aW5nIGN1cnNvciBzbyB3ZSBkb24ndCByZWN5Y2xl IEtWQSBhcyBsb25nIGFzCisJICogcG9zc2libGUuICBJdCdzIG5vdCBwZXJmZWN0LCBzaW5jZSB3 ZSBkb24ndCBrbm93IGluIHdoYXQKKwkgKiBvcmRlciBwcmV2aW91cyBhbGxvY2F0aW9ucyB3aWxs IGJlIGZyZWUnZCwgYnV0IGl0J3Mgc2ltcGxlCisJICogYW5kIGZhc3QsIGFuZCByZXF1aXJlcyBP KDEpIGFkZGl0aW9uYWwgc3RvcmFnZS4KKwkgKgorCSAqIFhYWCBUaGlzIHNjaGVtZSB3aWxsIGxl YWQgdG8gZ3JlYXRlciBmcmFnbWVudGF0aW9uIG9mIHRoZQorCSAqIG1hcCwgdW5sZXNzIHZtX21h cF9maW5kc3BhY2UoKSBpcyB0d2Vha2VkLgorCSAqLworCWZvciAoOzspIHsKKwkJcnYgPSB2bV9t YXBfZmluZHNwYWNlKG1lbWd1YXJkX21hcCwgbWVtZ3VhcmRfY3Vyc29yLAorCQkgICAgc2l6ZSwg JmFkZHIpOworCQlpZiAocnYgPT0gS0VSTl9TVUNDRVNTKQorCQkJYnJlYWs7CisJCS8qCisJCSAq IFRoZSBtYXAgaGFzIG5vIHNwYWNlLiAgVGhpcyBtYXkgYmUgZHVlIHRvCisJCSAqIGZyYWdtZW50 YXRpb24sIG9yIGJlY2F1c2UgdGhlIGN1cnNvciBpcyBuZWFyIHRoZQorCQkgKiBlbmQgb2YgdGhl IG1hcC4KKwkJICovCisJCWlmIChtZW1ndWFyZF9jdXJzb3IgPT0gdm1fbWFwX21pbihtZW1ndWFy ZF9tYXApKSB7CisJCQltZW1ndWFyZF9mYWlsX2t2YSsrOworCQkJYWRkciA9ICh2bV9vZmZzZXRf dClOVUxMOworCQkJZ290byBvdXQ7CisJCX0KKwkJbWVtZ3VhcmRfd3JhcCsrOworCQltZW1ndWFy ZF9jdXJzb3IgPSB2bV9tYXBfbWluKG1lbWd1YXJkX21hcCk7CisJfQorCXJ2ID0ga21lbV9iYWNr KG1lbWd1YXJkX21hcCwgYWRkciwgc2l6ZSwgZmxhZ3MpOworCWlmIChydiAhPSBLRVJOX1NVQ0NF U1MpIHsKKwkJbWVtZ3VhcmRfZmFpbF9wZ3MrKzsKKwkJYWRkciA9ICh2bV9vZmZzZXRfdClOVUxM OworCQlnb3RvIG91dDsKKwl9CisJbWVtZ3VhcmRfY3Vyc29yID0gYWRkciArIHNpemU7CisJKnYy c2l6ZXAodHJ1bmNfcGFnZShhZGRyKSkgPSByZXFfc2l6ZTsKKwltZW1ndWFyZF9zdWNjKys7Citv dXQ6CisJdm1fbWFwX3VubG9jayhtZW1ndWFyZF9tYXApOworCXJldHVybiAoKHZvaWQgKilhZGRy KTsKK30KKworaW50Citpc19tZW1ndWFyZF9hZGRyKHZvaWQgKmFkZHIpCit7CisJdm1fb2Zmc2V0 X3QgYSA9ICh2bV9vZmZzZXRfdCkodWludHB0cl90KWFkZHI7CisKKwlyZXR1cm4gKGEgPj0gbWVt Z3VhcmRfbWFwLT5taW5fb2Zmc2V0ICYmIGEgPCBtZW1ndWFyZF9tYXAtPm1heF9vZmZzZXQpOwor fQorCisvKgorICogRnJlZSBzcGVjaWZpZWQgc2luZ2xlIG9iamVjdC4KKyAqLwordm9pZAorbWVt Z3VhcmRfZnJlZSh2b2lkICpwdHIpCit7CisJdm1fb2Zmc2V0X3QgYWRkcjsKKwl1X2xvbmcgcmVx X3NpemUsIHNpemU7CisJY2hhciAqdGVtcDsKKwlpbnQgaTsKKworCWFkZHIgPSB0cnVuY19wYWdl KCh1aW50cHRyX3QpcHRyKTsKKwlyZXFfc2l6ZSA9ICp2MnNpemVwKGFkZHIpOworCXNpemUgPSBy b3VuZF9wYWdlKHJlcV9zaXplKTsKKworCS8qCisJICogUGFnZSBzaG91bGQgbm90IGJlIGd1YXJk ZWQgcmlnaHQgbm93LCBzbyBmb3JjZSBhIHdyaXRlLgorCSAqIFRoZSBwdXJwb3NlIG9mIHRoaXMg aXMgdG8gaW5jcmVhc2UgdGhlIGxpa2VsaWhvb2Qgb2YKKwkgKiBjYXRjaGluZyBhIGRvdWJsZS1m cmVlLCBidXQgbm90IG5lY2Vzc2FyaWx5IGEKKwkgKiB0YW1wZXItYWZ0ZXItZnJlZSAodGhlIHNl Y29uZCB0aHJlYWQgZnJlZWluZyBtaWdodCBub3QKKwkgKiB3cml0ZSBiZWZvcmUgZnJlZWluZywg c28gdGhpcyBmb3JjZXMgaXQgdG8gYW5kLAorCSAqIHN1YnNlcXVlbnRseSwgdHJpZ2dlciBhIGZh dWx0KS4KKwkgKi8KKwl0ZW1wID0gcHRyOworCWZvciAoaSA9IDA7IGkgPCBzaXplOyBpICs9IFBB R0VfU0laRSkKKwkJdGVtcFtpXSA9ICdNJzsKKworCWttZW1fZnJlZShtZW1ndWFyZF9tYXAsIGFk ZHIsIHNpemUpOworfQorCitpbnQKK21lbWd1YXJkX2NtcChzdHJ1Y3QgbWFsbG9jX3R5cGUgKm10 cCwgdW5zaWduZWQgbG9uZyBzaXplKQoreworCisjaWYgMQorCS8qCisJICogVGhlIHNhZmVzdCB3 YXkgb2YgY29tcGFyc2lvbiBpcyB0byBhbHdheXMgY29tcGFyZSBzaG9ydCBkZXNjcmlwdGlvbgor CSAqIHN0cmluZyBvZiBtZW1vcnkgdHlwZSwgYnV0IGl0IGlzIGFsc28gdGhlIHNsb3dlc3Qgd2F5 LgorCSAqLworCXJldHVybiAoc3RyY21wKG10cC0+a3Nfc2hvcnRkZXNjLCB2bV9tZW1ndWFyZF9k ZXNjKSA9PSAwKTsKKyNlbHNlCisJLyoKKwkgKiBJZiB3ZSBjb21wYXJlIHBvaW50ZXJzLCB0aGVy ZSBhcmUgdHdvIHBvc3NpYmxlIHByb2JsZW1zOgorCSAqIDEuIE1lbW9yeSB0eXBlIHdhcyB1bmxv YWRlZCBhbmQgbmV3IG1lbW9yeSB0eXBlIHdhcyBhbGxvY2F0ZWQgYXQgdGhlCisJICogICAgc2Ft ZSBhZGRyZXNzLgorCSAqIDIuIE1lbW9yeSB0eXBlIHdhcyB1bmxvYWRlZCBhbmQgbG9hZGVkIGFn YWluLCBidXQgYWxsb2NhdGVkIGF0IGEKKwkgKiAgICBkaWZmZXJlbnQgYWRkcmVzcy4KKwkgKi8K KwlpZiAodm1fbWVtZ3VhcmRfbXR5cGUgIT0gTlVMTCkKKwkJcmV0dXJuIChtdHAgPT0gdm1fbWVt Z3VhcmRfbXR5cGUpOworCWlmIChzdHJjbXAobXRwLT5rc19zaG9ydGRlc2MsIHZtX21lbWd1YXJk X2Rlc2MpID09IDApIHsKKwkJdm1fbWVtZ3VhcmRfbXR5cGUgPSBtdHA7CisJCXJldHVybiAoMSk7 CisJfQorCXJldHVybiAoMCk7CisjZW5kaWYKK30KClByb3BlcnR5IGNoYW5nZXMgb246IHZtL2lz aV9tZW1ndWFyZC5jCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KQWRkZWQ6IHN2bjptaW1lLXR5cGUKICAgKyB0ZXh0L3Bs YWluCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiAgICsgbmF0aXZlCgpJbmRleDogdm0vdm1fZXh0ZXJu LmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gdm0vdm1fZXh0ZXJuLmgJKHJldmlzaW9uIDE0MzU1MCkKKysrIHZt L3ZtX2V4dGVybi5oCSh3b3JraW5nIGNvcHkpCkBAIC01NCwzMCArNTQsMzEgQEAgaW50IHNicmso c3RydWN0IHRocmVhZCAqLCB2b2lkICosIGludCAqKQogaW50IHNzdGsoc3RydWN0IHRocmVhZCAq LCB2b2lkICosIGludCAqKTsKIGludCBzd2Fwb24oc3RydWN0IHRocmVhZCAqLCB2b2lkICosIGlu dCAqKTsKICNlbmRpZgkJCS8qIFRZUEVERUZfRk9SX1VBUCAqLwogCiBpbnQga2VybmFjYyh2b2lk ICosIGludCwgaW50KTsKIHZtX29mZnNldF90IGttZW1fYWxsb2Modm1fbWFwX3QsIHZtX3NpemVf dCk7CiB2bV9vZmZzZXRfdCBrbWVtX2FsbG9jX2NvbnRpZyh2bV9tYXBfdCBtYXAsIHZtX3NpemVf dCBzaXplLCBpbnQgZmxhZ3MsCiAgICAgdm1fcGFkZHJfdCBsb3csIHZtX3BhZGRyX3QgaGlnaCwg dW5zaWduZWQgbG9uZyBhbGlnbm1lbnQsCiAgICAgdW5zaWduZWQgbG9uZyBib3VuZGFyeSwgdm1f bWVtYXR0cl90IG1lbWF0dHIpOwogdm1fb2Zmc2V0X3Qga21lbV9hbGxvY19ub2ZhdWx0KHZtX21h cF90LCB2bV9zaXplX3QpOwogdm1fb2Zmc2V0X3Qga21lbV9hbGxvY193YWl0KHZtX21hcF90LCB2 bV9zaXplX3QpOwogdm9pZCBrbWVtX2ZyZWUodm1fbWFwX3QsIHZtX29mZnNldF90LCB2bV9zaXpl X3QpOwogdm9pZCBrbWVtX2ZyZWVfd2FrZXVwKHZtX21hcF90LCB2bV9vZmZzZXRfdCwgdm1fc2l6 ZV90KTsKIHZvaWQga21lbV9pbml0KHZtX29mZnNldF90LCB2bV9vZmZzZXRfdCk7CiB2bV9vZmZz ZXRfdCBrbWVtX21hbGxvYyh2bV9tYXBfdCwgdm1fc2l6ZV90LCBib29sZWFuX3QpOworaW50IGtt ZW1fYmFjayh2bV9tYXBfdCwgdm1fb2Zmc2V0X3QsIHZtX3NpemVfdCwgaW50KTsKIHZtX21hcF90 IGttZW1fc3ViYWxsb2Modm1fbWFwX3QsIHZtX29mZnNldF90ICosIHZtX29mZnNldF90ICosIHZt X3NpemVfdCwKICAgICBib29sZWFuX3QpOwogdm9pZCBzd2Fwb3V0X3Byb2NzKGludCk7CiBpbnQg dXNlcmFjYyh2b2lkICosIGludCwgaW50KTsKIGludCB2bV9mYXVsdCh2bV9tYXBfdCwgdm1fb2Zm c2V0X3QsIHZtX3Byb3RfdCwgaW50KTsKIHZvaWQgdm1fZmF1bHRfY29weV9lbnRyeSh2bV9tYXBf dCwgdm1fbWFwX3QsIHZtX21hcF9lbnRyeV90LCB2bV9tYXBfZW50cnlfdCk7CiB2b2lkIHZtX2Zh dWx0X3Vud2lyZSh2bV9tYXBfdCwgdm1fb2Zmc2V0X3QsIHZtX29mZnNldF90LCBib29sZWFuX3Qp OwogaW50IHZtX2ZhdWx0X3dpcmUodm1fbWFwX3QsIHZtX29mZnNldF90LCB2bV9vZmZzZXRfdCwg Ym9vbGVhbl90LCBib29sZWFuX3QpOwogaW50IHZtX2Zvcmtwcm9jKHN0cnVjdCB0aHJlYWQgKiwg c3RydWN0IHByb2MgKiwgc3RydWN0IHRocmVhZCAqLCBzdHJ1Y3Qgdm1zcGFjZSAqLCBpbnQpOwog dm9pZCB2bV93YWl0cHJvYyhzdHJ1Y3QgcHJvYyAqKTsKIGludCB2bV9tbWFwKHZtX21hcF90LCB2 bV9vZmZzZXRfdCAqLCB2bV9zaXplX3QsIHZtX3Byb3RfdCwgdm1fcHJvdF90LCBpbnQsIG9ianR5 cGVfdCwgdm9pZCAqLCB2bV9vb2Zmc2V0X3QpOwogdm9pZCB2bV9zZXRfcGFnZV9zaXplKHZvaWQp Owogc3RydWN0IHZtc3BhY2UgKnZtc3BhY2VfYWxsb2Modm1fb2Zmc2V0X3QsIHZtX29mZnNldF90 KTsKIHN0cnVjdCB2bXNwYWNlICp2bXNwYWNlX2Zvcmsoc3RydWN0IHZtc3BhY2UgKik7CiBpbnQg dm1zcGFjZV9leGVjKHN0cnVjdCBwcm9jICosIHZtX29mZnNldF90LCB2bV9vZmZzZXRfdCk7Cg== ------_=_NextPart_001_01CAC15B.FD6C5005-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 21:24:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9D652106566C for ; Thu, 11 Mar 2010 21:24:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Thu, 11 Mar 2010 16:24:48 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_i+VmLqoe2tbAbnx" Message-Id: <201003111624.51018.jkim@FreeBSD.org> Subject: [RFC] Saving the latest errno from syscalls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 21:24:58 -0000 --Boundary-00=_i+VmLqoe2tbAbnx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline While I was debugging syscalls, I found a very useful field in struct thread, td_errno. It seems it was added for dtrace but it is only populated on amd64 and i386. Is the attached patch acceptable for maintainers of other platforms? Thanks, Jung-uk Kim --Boundary-00=_i+VmLqoe2tbAbnx Content-Type: text/plain; charset="iso-8859-1"; name="syscall.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="syscall.diff" Index: sys/arm/arm/trap.c =================================================================== --- sys/arm/arm/trap.c (revision 205027) +++ sys/arm/arm/trap.c (working copy) @@ -928,6 +928,10 @@ syscall(struct thread *td, trapframe_t *frame, u_i AUDIT_SYSCALL_ENTER(code, td); error = (*callp->sy_call)(td, args); AUDIT_SYSCALL_EXIT(error, td); + + /* Save the latest error return value. */ + td->td_errno = error; + KASSERT(td->td_ar == NULL, ("returning from syscall with td_ar set!")); } Index: sys/powerpc/booke/trap.c =================================================================== --- sys/powerpc/booke/trap.c (revision 205027) +++ sys/powerpc/booke/trap.c (working copy) @@ -413,6 +413,9 @@ syscall(struct trapframe *frame) error = (*callp->sy_call)(td, params); AUDIT_SYSCALL_EXIT(error, td); + /* Save the latest error return value. */ + td->td_errno = error; + CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", p->p_comm, syscallnames[code], td->td_retval[0]); } Index: sys/powerpc/aim/trap.c =================================================================== --- sys/powerpc/aim/trap.c (revision 205027) +++ sys/powerpc/aim/trap.c (working copy) @@ -409,6 +409,9 @@ syscall(struct trapframe *frame) error = (*callp->sy_call)(td, params); AUDIT_SYSCALL_EXIT(error, td); + /* Save the latest error return value. */ + td->td_errno = error; + CTR3(KTR_SYSC, "syscall: p=%s %s ret=%x", td->td_name, syscallnames[code], td->td_retval[0]); } Index: sys/sparc64/sparc64/trap.c =================================================================== --- sys/sparc64/sparc64/trap.c (revision 205027) +++ sys/sparc64/sparc64/trap.c (working copy) @@ -652,6 +652,9 @@ syscall(struct trapframe *tf) error = (*sa.callp->sy_call)(td, sa.argp); AUDIT_SYSCALL_EXIT(error, td); + /* Save the latest error return value. */ + td->td_errno = error; + CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx", p, error, syscallnames[sa.code], td->td_retval[0], td->td_retval[1]); Index: sys/ia64/ia64/trap.c =================================================================== --- sys/ia64/ia64/trap.c (revision 205027) +++ sys/ia64/ia64/trap.c (working copy) @@ -974,6 +974,9 @@ syscall(struct trapframe *tf) error = (*callp->sy_call)(td, args); AUDIT_SYSCALL_EXIT(error, td); + /* Save the latest error return value. */ + td->td_errno = error; + cpu_set_syscall_retval(td, error); td->td_syscalls++; Index: sys/ia64/ia32/ia32_trap.c =================================================================== --- sys/ia64/ia32/ia32_trap.c (revision 205027) +++ sys/ia64/ia32/ia32_trap.c (working copy) @@ -127,6 +127,9 @@ ia32_syscall(struct trapframe *tf) AUDIT_SYSCALL_ENTER(code, td); error = (*callp->sy_call)(td, args64); AUDIT_SYSCALL_EXIT(error, td); + + /* Save the latest error return value. */ + td->td_errno = error; } switch (error) { Index: sys/sun4v/sun4v/trap.c =================================================================== --- sys/sun4v/sun4v/trap.c (revision 205027) +++ sys/sun4v/sun4v/trap.c (working copy) @@ -666,6 +666,9 @@ syscall(struct trapframe *tf) error = (*callp->sy_call)(td, argp); AUDIT_SYSCALL_EXIT(error, td); + /* Save the latest error return value. */ + td->td_errno = error; + CTR5(KTR_SYSC, "syscall: p=%p error=%d %s return %#lx %#lx ", p, error, syscallnames[code], td->td_retval[0], td->td_retval[1]); --Boundary-00=_i+VmLqoe2tbAbnx-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 17:07:44 2010 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 70F8E1065672 for ; Thu, 11 Mar 2010 17:07:44 +0000 (UTC) (envelope-from moon.bocal@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 041A58FC12 for ; Thu, 11 Mar 2010 17:07:43 +0000 (UTC) Received: by fxm1 with SMTP id 1so292765fxm.13 for ; Thu, 11 Mar 2010 09:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SwYs8QyiZsrZL+0PBd6C0IYXPPTmZZIHMu+ZysWThas=; b=pH9rZiEFjiKeGKKvBfVtUPkBAAjGAhNJ+ASXFPj8NOWm6/FFrS1ru6R4lmIUR4FONt V/uQSHlvfb7apbTBjqGdO6U1O0ewMZXoGSQBarAO9eZcbUys28dF7C2VqZ6U6DJd5efY ROkWTlTtoSep96sgVaHDs1n2H1aTqghMLW1Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eI0Z3784h852I0IoV98sz99sCqrleAw/Pcb9hHZvYwAXOXOuHl/BJeK8EmjIE+yRY3 4nc2XwP5C3LqfyWyKIFFhCme1JBF8J4xtg8dbLWOyhcY9PB+GEZAuuOUiqMhecWXhEwB vMCl1hPE1DjOhmnD1hAL8+C723vBnlfUEhuJQ= MIME-Version: 1.0 Received: by 10.102.211.40 with SMTP id j40mr1898762mug.65.1268325587016; Thu, 11 Mar 2010 08:39:47 -0800 (PST) In-Reply-To: <444okoc6s0.fsf@be-well.ilk.org> References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <444okoc6s0.fsf@be-well.ilk.org> Date: Thu, 11 Mar 2010 17:39:46 +0100 Message-ID: <3f1354251003110839r19ccfb7cme651ef035fe0f09c@mail.gmail.com> From: Buschini Edouard To: Lowell Gilbert X-Mailman-Approved-At: Thu, 11 Mar 2010 22:28:07 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Steven Hartland Subject: Re: To sendmail or to postfix that is the 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: Thu, 11 Mar 2010 17:07:44 -0000 Hi, Roundcube is a web pop or imap client. It's simple and light. And you just need Php and any sql base. Roundcube support ssl/tls on imap connection. You also can use a virtusertable to login. 2010/3/10 Lowell Gilbert > "Steven Hartland" writes: > > > A few key question come to mind:- > > 1. Has sendmail's config moved away from the black art > > it once was? > > Somewhat. The configurations are done with m4 these days, but there's > a lot of black magic possible with the many potential combinations of > features and options. > > > 2. Is postfix that much easier? > > Yes. However, the black magic in sendmail is very powerful. > > > 3. What would people use for: > > 3.1. POP / IMAP support? > > Separate problem. I use dovecot and I like it, but it's just a > household server. > > > 3.2. Web Mail? > > I don't do that, because I don't want to go to the effort of making sure > it is and stays secure, but from what I hear I'd probably try > squirrelmail first if I were doing it. > > > 3.2. AV / Spam filtering? > > I use spamassassin. You can plug most other analyzers into it. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- // Buschini Edouard :: Moon // Epitech university // moon.bocal@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 22:55:37 2010 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 6BA6F106564A for ; Thu, 11 Mar 2010 22:55:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 56DD58FC12 for ; Thu, 11 Mar 2010 22:55:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ500EF00VQ3190@asmtp028.mac.com>; Thu, 11 Mar 2010 13:55:07 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003110202 From: Marcel Moolenaar In-reply-to: <201003111624.51018.jkim@FreeBSD.org> Date: Thu, 11 Mar 2010 13:55:02 -0800 Message-id: <8EE3605E-6E39-44A1-9E3A-5A37E1921D27@mac.com> References: <201003111624.51018.jkim@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1077) Cc: freebsd-hackers@freebsd.org Subject: Re: [RFC] Saving the latest errno from syscalls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 22:55:37 -0000 On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > While I was debugging syscalls, I found a very useful field in struct > thread, td_errno. It seems it was added for dtrace but it is only > populated on amd64 and i386. Is the attached patch acceptable for > maintainers of other platforms? Isn't it better to do it in cpu_set_syscall_retval()? That way you catch all cases, plus you can save the translated error as well... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 18:30:53 2010 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 3EFE71065674; Thu, 11 Mar 2010 18:30:53 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (bayringfw.portcityweb.com [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id D1A498FC20; Thu, 11 Mar 2010 18:30:52 +0000 (UTC) Received: from [127.0.0.1] ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Thu, 11 Mar 2010 12:50:54 -0500 Message-ID: <4B992D7A.3060401@greatbaysoftware.com> Date: Thu, 11 Mar 2010 12:50:50 -0500 From: Charles Owens MIME-Version: 1.0 To: Jack Vogel References: <4B79297D.9080403@FreeBSD.org> <4B79205B.619A0A1A@verizon.net> <4B7ADFC6.7020202@FreeBSD.org> <4B7DE3CC.7040704@FreeBSD.org> <20100219034255.GG11675@michelle.cdnetworks.com> <2a41acea1002182343i1ef0124fm8e2f6cc56846454c@mail.gmail.com> In-Reply-To: <2a41acea1002182343i1ef0124fm8e2f6cc56846454c@mail.gmail.com> X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 X-Mailman-Approved-At: Thu, 11 Mar 2010 23:02:07 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Maxim Sobolev , Sergey Babkin , freebsd-net@freebsd.org, Alfred Perlstein , FreeBSD Hackers , "David G. Lawrence" Subject: Re: Sudden mbuf demand increase and shortage under the load (igb issue?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 18:30:53 -0000 Hello Jack, We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new Intel server box (based on their S5520UR motherboard). So far we've seen only oddness with link-state (it wants to always say "active", with no cable plugged in, unless we do an ifconfig up/down/up), but I'm concerned that we might fall victim to other symptoms mentioned if we put the system under load. Would you recommend we apply the igb patch you've mentioned? Is it in RELENG_8 yet, or is it still under development? Thanks very much, Charles Charles Owens Great Bay Software, Inc. Jack Vogel wrote: > This thread is confusing, first he says its an igb problem, then you offer > an em patch :) > > I have an important rev of igb that I am about ready to release, anyone that > wishes to > test against a problem they have would be welcome to have early access, just > let me > know. > > I am not sure about this ich10 change, there are client NICs that > specifically do NOT > support jumbo frames, I'll need to look into it tomorrow at work. > > Jack > > > On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: > > >> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >> >>> Folks, >>> >>> Indeed, it looks like igb(4) issue. Replacing the card with the >>> desktop-grade em(4)-supported card has fixed the problem for us. The >>> system has been happily pushing 110mbps worth of RTP traffic and 2000 >>> concurrent calls without any problems for two days now. >>> >>> em0@pci0:7:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> subclass = ethernet >>> >>> em0: port 0xec00-0xec1f mem >>> 0xfbee0000-0xfbefffff,0xfbe00000-0xfbe7ffff,0xfbedc000-0xfbedffff irq 24 >>> at device 0.0 on pci7 >>> em0: Using MSIX interrupts >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: Ethernet address: 00:1b:21:50:02:49 >>> >>> I really think that this has to be addressed before 7.3 release is out. >>> FreeBSD used to be famous for its excellent network performance and it's >>> shame to see that deteriorating due to sub-standard quality drivers. >>> Especially when there is a multi-billion vendor supporting the driver in >>> question. No finger pointing, but it really looks like either somebody >>> is not doing his job or the said vendor doesn't care so much about >>> supporting FreeBSD. I am pretty sure the vendor in question has access >>> to numerous load-testing tools, that should have catched this issue. >>> >>> This is the second time during the past 6 months I have issue with the >>> quality of the Intel-based drivers - the first one is filed as >>> kern/140326, which has stalled apparently despite me providing all >>> necessary debug information. >>> >>> >> I can reproduce this bug on my box and I guess the root cause comes >> from PBA(Packet Buffer Allocation) configuration. Some controllers >> seems to require more TX buffer size to use 9000 MTU. The datasheet >> is not clear which controller has how much amount of Packet Buffer >> storage. This parameter seems to affect performance a lot because >> increasing TX buffer size results in decreasing RX buffer size. The >> attached patch seems to fix the issue for me but Jack may know >> better the hardware details as publicly available datasheet seems >> to be useless here. >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 18:31:41 2010 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 22C64106566C; Thu, 11 Mar 2010 18:31:41 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (bayringfw.portcityweb.com [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E88FC1F; Thu, 11 Mar 2010 18:31:40 +0000 (UTC) Received: from [127.0.0.1] ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Thu, 11 Mar 2010 13:31:42 -0500 Message-ID: <4B99370A.1090209@greatbaysoftware.com> Date: Thu, 11 Mar 2010 13:31:38 -0500 From: Charles Owens MIME-Version: 1.0 To: Jack Vogel References: <4B79297D.9080403@FreeBSD.org> <4B79205B.619A0A1A@verizon.net> <4B7ADFC6.7020202@FreeBSD.org> <4B7DE3CC.7040704@FreeBSD.org> <20100219034255.GG11675@michelle.cdnetworks.com> <2a41acea1002182343i1ef0124fm8e2f6cc56846454c@mail.gmail.com> <4B992D7A.3060401@greatbaysoftware.com> In-Reply-To: <4B992D7A.3060401@greatbaysoftware.com> X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 X-Mailman-Approved-At: Thu, 11 Mar 2010 23:02:39 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, Maxim Sobolev , Sergey Babkin , FreeBSD Hackers , Alfred Perlstein , freebsd-net@freebsd.org, "David G. Lawrence" Subject: Re: Sudden mbuf demand increase and shortage under the load (igb issue?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 18:31:41 -0000 I've dug around in the source repo... it appears the new code is just shy of being MFC'd. Any known caveats with the new code or is it by all accounts good to go? I'm going to try testing it in 8.0. Thanks Charles Owens Great Bay Software, Inc. Charles Owens wrote: > Hello Jack, > > We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new > Intel server box (based on their S5520UR motherboard). So far we've > seen only oddness with link-state (it wants to always say "active", with > no cable plugged in, unless we do an ifconfig up/down/up), but I'm > concerned that we might fall victim to other symptoms mentioned if we > put the system under load. > > Would you recommend we apply the igb patch you've mentioned? Is it in > RELENG_8 yet, or is it still under development? > > Thanks very much, > Charles > > Charles Owens > Great Bay Software, Inc. > > > > Jack Vogel wrote: > >> This thread is confusing, first he says its an igb problem, then you offer >> an em patch :) >> >> I have an important rev of igb that I am about ready to release, anyone that >> wishes to >> test against a problem they have would be welcome to have early access, just >> let me >> know. >> >> I am not sure about this ich10 change, there are client NICs that >> specifically do NOT >> support jumbo frames, I'll need to look into it tomorrow at work. >> >> Jack >> >> >> On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: >> >> >> >>> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >>> >>> >>>> Folks, >>>> >>>> Indeed, it looks like igb(4) issue. Replacing the card with the >>>> desktop-grade em(4)-supported card has fixed the problem for us. The >>>> system has been happily pushing 110mbps worth of RTP traffic and 2000 >>>> concurrent calls without any problems for two days now. >>>> >>>> em0@pci0:7:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> class = network >>>> subclass = ethernet >>>> >>>> em0: port 0xec00-0xec1f mem >>>> 0xfbee0000-0xfbefffff,0xfbe00000-0xfbe7ffff,0xfbedc000-0xfbedffff irq 24 >>>> at device 0.0 on pci7 >>>> em0: Using MSIX interrupts >>>> em0: [ITHREAD] >>>> em0: [ITHREAD] >>>> em0: [ITHREAD] >>>> em0: Ethernet address: 00:1b:21:50:02:49 >>>> >>>> I really think that this has to be addressed before 7.3 release is out. >>>> FreeBSD used to be famous for its excellent network performance and it's >>>> shame to see that deteriorating due to sub-standard quality drivers. >>>> Especially when there is a multi-billion vendor supporting the driver in >>>> question. No finger pointing, but it really looks like either somebody >>>> is not doing his job or the said vendor doesn't care so much about >>>> supporting FreeBSD. I am pretty sure the vendor in question has access >>>> to numerous load-testing tools, that should have catched this issue. >>>> >>>> This is the second time during the past 6 months I have issue with the >>>> quality of the Intel-based drivers - the first one is filed as >>>> kern/140326, which has stalled apparently despite me providing all >>>> necessary debug information. >>>> >>>> >>>> >>> I can reproduce this bug on my box and I guess the root cause comes >>> from PBA(Packet Buffer Allocation) configuration. Some controllers >>> seems to require more TX buffer size to use 9000 MTU. The datasheet >>> is not clear which controller has how much amount of Packet Buffer >>> storage. This parameter seems to affect performance a lot because >>> increasing TX buffer size results in decreasing RX buffer size. The >>> attached patch seems to fix the issue for me but Jack may know >>> better the hardware details as publicly available datasheet seems >>> to be useless here. >>> >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 11 23:15:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D1529106564A; Thu, 11 Mar 2010 23:15:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-hackers@freebsd.org Date: Thu, 11 Mar 2010 18:15:07 -0500 User-Agent: KMail/1.6.2 References: <201003111624.51018.jkim@FreeBSD.org> <8EE3605E-6E39-44A1-9E3A-5A37E1921D27@mac.com> In-Reply-To: <8EE3605E-6E39-44A1-9E3A-5A37E1921D27@mac.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003111815.10186.jkim@FreeBSD.org> Cc: Marcel Moolenaar Subject: Re: [RFC] Saving the latest errno from syscalls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 11 Mar 2010 23:15:19 -0000 On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote: > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > > While I was debugging syscalls, I found a very useful field in > > struct thread, td_errno. It seems it was added for dtrace but it > > is only populated on amd64 and i386. Is the attached patch > > acceptable for maintainers of other platforms? > > Isn't it better to do it in cpu_set_syscall_retval()? > That way you catch all cases, plus you can save the > translated error as well... I just took amd64/i386 as an example and I was not sure whether it was meant to store translated error or not. Does anyone with DTrace internal knowledge answer the question? Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 05:28:48 2010 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 F2EC41065673 for ; Fri, 12 Mar 2010 05:28:48 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [95.108.130.93]) by mx1.freebsd.org (Postfix) with ESMTP id A72DE8FC21 for ; Fri, 12 Mar 2010 05:28:48 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward11.mail.yandex.net (Yandex) with ESMTP id EE3F7F48528; Fri, 12 Mar 2010 08:28:46 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1268371726; bh=3EIymZvEZgnXoT19tpk7YblElDpoQ6uTZ157Xt//Wys=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LaQzEeQHz067+Ps1bhnCEGstAHkyVM7DmplONONDm9z25Z3H22gOT+0yNUukNjdQz 7KEBo5mDVjlnSfAmLnjqWzmVf5am3yyYO73yClKljeiYJ8qu9thIIw6gNu6EkESoq5 j35TUayRGO53Kzf3xIrzkLw0LcFqwg9EKsAX4yZ0= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id A9A66D300EE; Fri, 12 Mar 2010 08:28:46 +0300 (MSK) Message-ID: <4B99D10E.9030007@yandex.ru> Date: Fri, 12 Mar 2010 08:28:46 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Thomas Schmitt References: <10610127213209@192.168.2.69> In-Reply-To: <10610127213209@192.168.2.69> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1268371726 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 05:28:49 -0000 On 11.03.2010 16:27, Thomas Schmitt wrote: > i am looking for a way to curb SATA speed to > 1.5 GBit/s to avoid write failures with an eSATA > attached DVD burner. Can you show `pciconf -l` output? -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 06:42:41 2010 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 95F12106564A for ; Fri, 12 Mar 2010 06:42:41 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0AD118FC0C for ; Fri, 12 Mar 2010 06:42:40 +0000 (UTC) Received: (qmail invoked by alias); 12 Mar 2010 06:42:39 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp020) with SMTP; 12 Mar 2010 07:42:39 +0100 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX19xFYl/CvlxJcqyZtx7Gd3ELSPQsK0bdjevqU43EE o5xVjVY/kQsuXx Date: Fri, 12 Mar 2010 07:44:46 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org References: <4B99D10E.9030007@yandex.ru> In-Reply-To: <4B99D10E.9030007@yandex.ru> Message-Id: <10609484503607@192.168.2.69> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 06:42:41 -0000 Hi, Andrey V. Elsukov wrote: > Can you show `pciconf -l` output? # pciconf -l hostb0@pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x79111002 rev=0x00 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x79121002 chip=0x79121002 rev=0x00 hdr=0x01 pcib2@pci0:0:6:0: class=0x060400 card=0x50001458 chip=0x79161002 rev=0x00 hdr=0x01 atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 ohci0@pci0:0:18:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 ohci1@pci0:0:18:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 ehci0@pci0:0:18:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 ohci2@pci0:0:19:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 ohci3@pci0:0:19:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 ehci1@pci0:0:19:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 none0@pci0:0:20:0: class=0x0c0500 card=0x43851458 chip=0x43851002 rev=0x3c hdr=0x00 atapci1@pci0:0:20:1: class=0x01018a card=0x50021458 chip=0x439c1002 rev=0x00 hdr=0x00 none1@pci0:0:20:2: class=0x040300 card=0xa0021458 chip=0x43831002 rev=0x00 hdr=0x00 isab0@pci0:0:20:3: class=0x060100 card=0x50011458 chip=0x439d1002 rev=0x00 hdr=0x00 pcib3@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 ohci4@pci0:0:20:5: class=0x0c0310 card=0x50041458 chip=0x43991002 rev=0x00 hdr=0x00 hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00 hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00 hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00 hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00 hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00 vgapci0@pci0:1:5:0: class=0x030000 card=0xd0001458 chip=0x796e1002 rev=0x00 hdr=0x00 none2@pci0:1:5:2: class=0x040300 card=0x79191458 chip=0x79191002 rev=0x00 hdr=0x00 re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 08:38:31 2010 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 E13241065672 for ; Fri, 12 Mar 2010 08:38:31 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 257008FC15 for ; Fri, 12 Mar 2010 08:38:30 +0000 (UTC) Received: (qmail invoked by alias); 12 Mar 2010 08:38:29 -0000 Received: from f055165223.adsl.alicedsl.de (EHLO baloo.cs.uni-paderborn.de) [78.55.165.223] by mail.gmx.net (mp022) with SMTP; 12 Mar 2010 09:38:29 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX18Dx9Ja6BIDe32YUBX1/6rZ16cv2iaLf6uV7xesDG HnkbTXbmQvTM2x Received: from [127.0.0.1] (helo=balu.cs.uni-paderborn.de) by baloo.cs.uni-paderborn.de with esmtp (Exim 4.70) (envelope-from ) id KZ5UO2-0003D8-O7; Fri, 12 Mar 2010 09:38:26 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: =?iso-8859-15?Q?Dag-Erling_Sm=F8rgrav?= References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B982E57.2050408@gmx.de> <86vdd3kkxx.fsf@ds4.des.no> Date: Fri, 12 Mar 2010 09:38:26 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Matthias Andree" Message-ID: In-Reply-To: <86vdd3kkxx.fsf@ds4.des.no> User-Agent: Opera Mail/10.50 (Win32) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Fri, 12 Mar 2010 08:38:32 -0000 Dag-Erling Smørgrav wrote on 2010-03-11: > Matthias Andree writes: >> sendmail's configuration was never a black art unless you needed >> features beyond what the m4 macro set supported. > > The m4 macro set is a fairly recent development. If "more than a decade" is a "fairly recent development", then you're right. -- Matthias Andree From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 09:29:48 2010 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 3EF18106564A; Fri, 12 Mar 2010 09:29:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A38FB8FC19; Fri, 12 Mar 2010 09:29:47 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o2C9TWtn027972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2010 11:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o2C9TWVe053931; Fri, 12 Mar 2010 11:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o2C9TWuk053930; Fri, 12 Mar 2010 11:29:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Mar 2010 11:29:32 +0200 From: Kostik Belousov To: Jung-uk Kim Message-ID: <20100312092932.GJ2489@deviant.kiev.zoral.com.ua> References: <201003111624.51018.jkim@FreeBSD.org> <8EE3605E-6E39-44A1-9E3A-5A37E1921D27@mac.com> <201003111815.10186.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7epHAAa1/vAPJ6LR" Content-Disposition: inline In-Reply-To: <201003111815.10186.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar Subject: Re: [RFC] Saving the latest errno from syscalls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Mar 2010 09:29:48 -0000 --7epHAAa1/vAPJ6LR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote: > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote: > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > > > While I was debugging syscalls, I found a very useful field in > > > struct thread, td_errno. It seems it was added for dtrace but it > > > is only populated on amd64 and i386. Is the attached patch > > > acceptable for maintainers of other platforms? > > > > Isn't it better to do it in cpu_set_syscall_retval()? > > That way you catch all cases, plus you can save the > > translated error as well... >=20 > I just took amd64/i386 as an example and I was not sure whether it was=20 > meant to store translated error or not. Does anyone with DTrace=20 > internal knowledge answer the question? I do not know that much about DTrace, but it seems that setting td_errno in cpu_set_syscall_retval() is too late. Dtrace has a probe after the syscall return, and it is called right before cpu_set_syscall_retval() can be reasonably called. The probe only issued for syscall that goes into sysent. --7epHAAa1/vAPJ6LR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuaCXwACgkQC3+MBN1Mb4iYGQCfbxmtBnBDez8DMbLGZLKuXcYj SRQAoNdLRhK4xmEf5VRk6OJBJauQjvAQ =W5iU -----END PGP SIGNATURE----- --7epHAAa1/vAPJ6LR-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 11:04:21 2010 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 2DBF71065670 for ; Fri, 12 Mar 2010 11:04:21 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D99998FC1C for ; Fri, 12 Mar 2010 11:04:20 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F3CF91FFC51; Fri, 12 Mar 2010 11:04:18 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D044C844DA; Fri, 12 Mar 2010 12:04:18 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Matthias Andree" References: <1AE2F4B0675743BAB0C54954FBA787CA@multiplay.co.uk> <4B982E57.2050408@gmx.de> <86vdd3kkxx.fsf@ds4.des.no> Date: Fri, 12 Mar 2010 12:04:18 +0100 In-Reply-To: (Matthias Andree's message of "Fri, 12 Mar 2010 09:38:26 +0100") Message-ID: <867hphiyx9.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: To sendmail or to postfix that is the 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: Fri, 12 Mar 2010 11:04:21 -0000 "Matthias Andree" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Matthias Andree writes: > > > sendmail's configuration was never a black art unless you needed > > > features beyond what the m4 macro set supported. > > The m4 macro set is a fairly recent development. > If "more than a decade" is a "fairly recent development", Well, yes, actually. I remember having to edit sendmail.cf even for trivial stuff like setting the sender domain and the outgoing smtp relay, what, fifteen years ago? Definitely less than fifteen. I still have the first edition of the bat book; it's almost as thick as my single-volume paperback edition of The Lord of the Rings, and has larger pages. More importantly, if you raise your eyes a few centimeters, you'll notice the word "never" which I think we can all agree is patently untrue. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 18:32:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7BBC9106566B; Fri, 12 Mar 2010 18:32:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Kostik Belousov Date: Fri, 12 Mar 2010 13:32:07 -0500 User-Agent: KMail/1.6.2 References: <201003111624.51018.jkim@FreeBSD.org> <201003111815.10186.jkim@FreeBSD.org> <20100312092932.GJ2489@deviant.kiev.zoral.com.ua> In-Reply-To: <20100312092932.GJ2489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003121332.16979.jkim@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Marcel Moolenaar Subject: Re: [RFC] Saving the latest errno from syscalls. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Mar 2010 18:32:28 -0000 On Friday 12 March 2010 04:29 am, Kostik Belousov wrote: > On Thu, Mar 11, 2010 at 06:15:07PM -0500, Jung-uk Kim wrote: > > On Thursday 11 March 2010 04:55 pm, Marcel Moolenaar wrote: > > > On Mar 11, 2010, at 1:24 PM, Jung-uk Kim wrote: > > > > While I was debugging syscalls, I found a very useful field > > > > in struct thread, td_errno. It seems it was added for dtrace > > > > but it is only populated on amd64 and i386. Is the attached > > > > patch acceptable for maintainers of other platforms? > > > > > > Isn't it better to do it in cpu_set_syscall_retval()? > > > That way you catch all cases, plus you can save the > > > translated error as well... > > > > I just took amd64/i386 as an example and I was not sure whether > > it was meant to store translated error or not. Does anyone with > > DTrace internal knowledge answer the question? > > I do not know that much about DTrace, but it seems that setting > td_errno in cpu_set_syscall_retval() is too late. Dtrace has a > probe after the syscall return, and it is called right before > cpu_set_syscall_retval() can be reasonably called. The probe only > issued for syscall that goes into sysent. Ah, I can see that now. So, if/when we implement DTrace SYSCALL provider for other arches, this is the right place. :-) Thanks! Jung-uk Kim From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 18:35:06 2010 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 6D4391065676 for ; Fri, 12 Mar 2010 18:35:06 +0000 (UTC) (envelope-from cole@opteqint.net) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54F7D8FC16 for ; Fri, 12 Mar 2010 18:35:06 +0000 (UTC) Received: by pvg3 with SMTP id 3so714865pvg.13 for ; Fri, 12 Mar 2010 10:35:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.84.2 with SMTP id m2mr838430wfl.56.1268418905661; Fri, 12 Mar 2010 10:35:05 -0800 (PST) X-Originating-IP: [196.210.202.6] Date: Fri, 12 Mar 2010 20:35:05 +0200 Message-ID: <9f206d1a1003121035w503840c4q69fde2174f19e9c9@mail.gmail.com> From: Cole To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: device_t, resource, and softc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Mar 2010 18:35:06 -0000 Hi. Im busy implementing a kernel module to enable me to read/write certain control registers for a PCI card. I do not wish to modify the existing driver, merely create an add-on module that can be loaded to accomplish what I need. I can easily get the device_t structure of the device, and I know I can use device_get_softc, to get the softc of the structure. I also see there used to be a bus_get_resource function that no longer seems to be documented or has a man page on FreeBSD. So I was wondering if there is a way to get the resource for the device using the device_t structure, which would allow me to easily use the rman_get_bustag, and rman_get_bushandle functions to get the bus_tag and bus_handle values for the device and its resouce. Regards /Cole From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 18:27:08 2010 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 733CB106566B for ; Fri, 12 Mar 2010 18:27:08 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 411AE8FC18 for ; Fri, 12 Mar 2010 18:27:08 +0000 (UTC) Received: from vesper.usenix.org (vesper.usenix.org [131.106.3.142]) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id o2CINhZU013470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 12 Mar 2010 10:27:07 -0800 (PST) Message-Id: From: Lionel Garth Jones To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 12 Mar 2010 10:27:07 -0800 X-Mailer: Apple Mail (2.936) X-DCC-Usenix-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Fri, 12 Mar 2010 18:58:17 +0000 Subject: SSV '10 Call for Papers Now Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:27:08 -0000 On behalf of the 5th International Workshop on Systems Software Verification (SSV '10) program committee, we'd like to invite you to contribute papers that focus on finding real, applicable solutions to systems software verification problems. Paper registration and abstracts are due Friday, May 28, 2010, 11:59 p.m. Samoan time (UTC-11). Industrial-strength software analysis and verification has advanced in recent years through the introduction of model checking, automated and interactive theorem proving, and static analysis techniques, as well as correctness by design, correctness by contract, and model-driven development. However, many techniques are working under restrictive assumptions that are invalidated by complex embedded systems software such as operating system kernels, low-level device drivers, or microcontroller code. The aim of this workshop is to bring together researchers and developers from both academia and industry who are facing real software and real problems with the goal of finding real, applicable solutions. By "real" we mean problems such as time-to-market or reliability that the industry is facing. A real solution is one that is applicable to the problem in industry and not one that only applies to an abstract, academic, toy version of it. In this workshop we will discuss software analysis and development techniques and tools; this forum will serve as a platform to discuss open problems and future challenges in dealing with existing and upcoming systems-level code. Topics include but are not limited to: * Model checking * Automated and interactive theorem proving * Static analysis * Automated testing * Model-driven development * Embedded systems development * Programming languages * Verifying compilers * Software certification * Software tools * Experience reports Paper registration and abstracts are due Friday, May 28, 2010, 11:59 p.m. Samoan time (UTC-11). For more details on the submission process, please see the complete Call for Papers at: http://www.usenix.org/ssv10/cfpa/ SSV '10 will be held immediately following the 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI '10), which will take place October 4-6, 2010. We look forward to receiving your submissions! Ralf Huuck, NICTA and University of New South Wales, Australia Gerwin Klein, NICTA and University of New South Wales, Australia Bastian Schlich, RWTH Aachen University, Germany SSV '10 Program Co-Chairs ssv10chairs@usenix.org P.S. We'd like to thank our sponsors NICTA and Microsoft Research for their support. --------------------------------- Call for Papers 5th International Workshop on Systems Software Verification October 6-7, 2010 Vancouver, BC, Canada http://www.usenix.org/ssv10/cfpa/ Paper registration and abstracts due: Friday, May 28, 2010, 11:59 p.m. Samoan time (UTC-11) From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 12 21:04:08 2010 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 219AE1065670 for ; Fri, 12 Mar 2010 21:04:08 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id D867D8FC0A for ; Fri, 12 Mar 2010 21:04:07 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 11A1C1E0013C; Fri, 12 Mar 2010 22:04:06 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o2CL1Jss028002; Fri, 12 Mar 2010 22:01:19 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o2CL1I7s028001; Fri, 12 Mar 2010 22:01:18 +0100 (CET) (envelope-from nox) Date: Fri, 12 Mar 2010 22:01:18 +0100 (CET) From: Juergen Lock Message-Id: <201003122101.o2CL1I7s028001@triton8.kn-bremen.de> To: scdbackup@gmx.net X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <10609484503607@192.168.2.69> References: <4B99D10E.9030007@yandex.ru> Organization: home X-Mailman-Approved-At: Fri, 12 Mar 2010 22:10:25 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 21:04:08 -0000 In article <10609484503607@192.168.2.69> you write: >Hi, > >Andrey V. Elsukov wrote: >> Can you show `pciconf -l` output? > ># pciconf -l >hostb0@pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x79111002 rev=0x00 hdr=0x00 >pcib1@pci0:0:1:0: class=0x060400 card=0x79121002 chip=0x79121002 rev=0x00 hdr=0x01 >pcib2@pci0:0:6:0: class=0x060400 card=0x50001458 chip=0x79161002 rev=0x00 hdr=0x01 >atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 That looks like an SB700 aka ATI IXP700 which should be supported by ahci(4) on FreeBSD >= 8.0 and then hopefully will slow down to sata150 if you set hint.ahcich.X.sata_rev=1 in /boot/device.hints (see man ahci.) The controller doesn't like scsi commands sent to non-atapi devices like ada(4) tho (they cause the bus to hang), so if your burning app does things like `cdrecord -scanbus' and you are on 8.0 release (as opposed to stable/8 or head where I think this condition is catched now) you might want to try the patch in this posting: http://docs.freebsd.org/cgi/mid.cgi?4B6358F3.7080908 (Click on the `Raw E-Mail' link at the top to grab the patch, I hope it applies to 8.0 release too...) More about ahci(4) is here: http://ivoras.sharanet.org/blog/tree/2009-11-17.trying-ahci-in-8.0.html As mentioned there disks will rename from adX to adaY, another option to cope with that if you don't want to adjust fstab each time you dis/enable ahci(4) is to mount them by using /dev/ufsid/XXXX device nodes at least if you still use ufs; you can find the device node to use by doing: dumpfs /dev/adXsYa | sed -n '/id/{s-^.*\[ \(.*\) \(.*\) \]$-/dev/ufsid/\1\2-;p;q;}' (you still have to take care of swap manually then tho, and dumpdev in rc.conf if you have it set explicitly.) Once fstab is fixed, have ahci.ko loaded via loader.conf and reboot: ahci_load="YES" - or if you want to try it only temporary at first you can also escape to the loader prompt from the beastie menu and then type: load ahci boot -v or: load ahci boot -v -s if you want to try it in single user mode first. Oh and with ahci the burner will appear as a cd(4) device automatically so you also don't need atapicam anymore. And you may be able to change ahci(4) sata speed at runtime too using camcontrol, http://docs.freebsd.org/cgi/mid.cgi?4B18DDDA.3050608 tho I don't know whether 8.0 release has that part of the code yet. HTH, :) Juergen From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 02:28:23 2010 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 8B449106564A for ; Sat, 13 Mar 2010 02:28:23 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14C788FC13 for ; Sat, 13 Mar 2010 02:28:22 +0000 (UTC) Received: by wwb24 with SMTP id 24so664715wwb.13 for ; Fri, 12 Mar 2010 18:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=EtOd2fcwFN5WLhdqQUmJaCyafPhKWzL04sPVax21Res=; b=knC/L99B7fZ1a1HTYcF++1kUds0TAeS6IidT0ws7HvI2bm1hIcHpb2t7VJS5XpuxzJ 4Aw1rLgFVu3NLo6TiRpWmOfK8NkMkSGyqdG8XUc7avnHyaoc4U6DmmtQGunZTZA78tmb /dZMeyzgIlYpix3cNJIyspFSIt45twUYGstIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; b=Tk40fKHpRqPacyvbCXSb02F6AqK7NZfKrO2jdzyMeMj2u10W9G3ZL5Y0r2ub2ded0v Ac+QtagL70uPsnS7HtSU8d6DY3UuvIYuMtoz7p3XtV5rrqkS4ygGUmwipKVuZPWRQe6R 5vq/8pvZX0t3Pp763Yfd1TKJJ8vb4aCzbai4A= Received: by 10.216.155.208 with SMTP id j58mr99104wek.228.1268447301730; Fri, 12 Mar 2010 18:28:21 -0800 (PST) Received: from viper.internal.network (dsl78-143-199-168.in-addr.fast.co.uk [78.143.199.168]) by mx.google.com with ESMTPS id m5sm7392673gve.12.2010.03.12.18.28.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Mar 2010 18:28:20 -0800 (PST) Received: from viper.internal.network (localhost [127.0.0.1]) by viper.internal.network (Postfix) with ESMTP id C619D4AC09 for ; Sat, 13 Mar 2010 02:28:18 +0000 (UTC) Received: (from m0@localhost) by viper.internal.network (8.14.3/8.14.3/Submit) id o2D2SI19098618 for freebsd-hackers@FreeBSD.org; Sat, 13 Mar 2010 02:28:18 GMT (envelope-from xorquewasp@googlemail.com) X-Authentication-Warning: viper.internal.network: m0 set sender to xorquewasp@googlemail.com using -f Date: Sat, 13 Mar 2010 02:28:18 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@FreeBSD.org Message-ID: <20100313022817.GA40872@logik.internal.network> References: <20100226163227.GA15162@logik.internal.network> <4B88074E.7050007@FreeBSD.org> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867hpr56ek.fsf@ds4.des.no> Cc: Subject: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 02:28:23 -0000 This is a complete lot of how to reproduce the various errors I've seen with 'make package-recursive'. I've checked the pointyhat logs and there are no errors logged for the packages involved here. There seems to be a bug somewhere in ports. I've used inkscape as a scapegoat here but the errors occur with many, many ports. There is no ZFS or nullfs involved here (apart from the read-only nullfs mount that ezjail uses to share /usr/bin and the like). I've used ezjail-admin to create jails. $ sudo ezjail-admin create 8.0-amd64-pkg_viper-2 127.1.0.11 $ sudo ezjail-admin onestart 8.0-amd64-pkg_viper-2 $ sudo jexec `jls | grep pkg_viper-2 | awk '{print $1}'` sh jail# mkdir /var/ports/work jail# mkdir /var/ports/tree jail# mkdir /var/ports/packages jail# mkdir /var/ports/distfiles jail# vi /etc/make.conf DISTDIR= /var/ports/distfiles PACKAGES= /var/ports/packages WRKDIRPREFIX= /var/ports/work PORTSDIR= /var/ports/tree jail# vi /etc/profile FTP_PASSIVE_MODE=yes HTTP_PROXY=10.1.3.3:8080 export FTP_PASSIVE_MODE export HTTP_PROXY jail# . /etc/profile jail# portsnap -p /var/ports/tree fetch extract Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from portsnap2.FreeBSD.org... done. Fetching snapshot tag from portsnap2.FreeBSD.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Fri Mar 12 00:22:12 UTC 2010: d67bd7a10044c70dc705b2c5b05db32b07ab8bd2262c3e 1% of 61 MB 161 kBps ... jail# cd /var/ports/tree/graphics/inkscape jail# make config-recursive jail# make fetch-recursive jail# make package-recursive 2>&1 | tee /tmp/inkscape.log Of course, at the end of inkscape.log: Creating package /var/ports/packages/All/docbook-4.1_4.tbz Registering depends: iso8879-1986_2 xmlcatmgr-2.2. Creating bzip'd tar ball in '/var/ports/packages/All/docbook-4.1_4.tbz' rmdir: /var/ports/work/var/ports/tree/textproc/docbook-410/work: Directory not empty *** Error code 1 (ignored) Creating package /var/ports/packages/All/eggdbus-0.6.tbz Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3 glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1 libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4 libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4 gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3. Creating bzip'd tar ball in '/var/ports/packages/All/eggdbus-0.6.tbz' rmdir: /var/ports/work/var/ports/tree/devel/eggdbus/work: Directory not empty *** Error code 1 (ignored) ===> Generating temporary packing list tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /var/ports/packages/All/docbook-4.2.tbz Registering depends: iso8879-1986_2 xmlcatmgr-2.2. Creating bzip'd tar ball in '/var/ports/packages/All/docbook-4.2.tbz' *** Error code 1 Stop in /var/ports/tree/textproc/docbook-420. *** Error code 1 Stop in /var/ports/tree/textproc/docbook-420. *** Error code 1 Stop in /var/ports/tree/graphics/inkscape. The full log is here: http://coreland.ath.cx/tmp/inkscape.log xw From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 03:02:48 2010 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 B3D3A106564A for ; Sat, 13 Mar 2010 03:02:48 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 4826D8FC12 for ; Sat, 13 Mar 2010 03:02:47 +0000 (UTC) Received: (qmail 1897 invoked from network); 13 Mar 2010 02:35:47 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with RC4-MD5 encrypted SMTP; 13 Mar 2010 02:35:47 -0000 MIME-Version: 1.0 content-class: From: Dirk Engling Date: Sat, 13 Mar 2010 03:36:05 +0100 Importance: normal X-Priority: 3 To: Juergen Lock , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20100313030248.B3D3A106564A@hub.freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: RE: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 03:02:48 -0000 Sent from my HTC= From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 03:37:00 2010 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 41E96106566C for ; Sat, 13 Mar 2010 03:37:00 +0000 (UTC) (envelope-from glarkin@FreeBSD.org) Received: from mail1.sourcehosting.net (113901-app1.sourcehosting.net [72.32.213.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1B75D8FC0A for ; Sat, 13 Mar 2010 03:36:59 +0000 (UTC) Received: from 68-189-245-235.dhcp.oxfr.ma.charter.com ([68.189.245.235] helo=cube.entropy.prv) by mail1.sourcehosting.net with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NqI9l-000JdK-EH; Fri, 12 Mar 2010 22:36:59 -0500 Received: from [127.0.0.1] (fireball.entropy.prv [192.168.1.12]) by cube.entropy.prv (Postfix) with ESMTP id 48D2F3CC929B; Fri, 12 Mar 2010 22:36:53 -0500 (EST) Message-ID: <4B9B0856.4090301@FreeBSD.org> Date: Fri, 12 Mar 2010 22:36:54 -0500 From: Greg Larkin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: xorquewasp@googlemail.com References: <20100226163227.GA15162@logik.internal.network> <4B88074E.7050007@FreeBSD.org> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> <20100313022817.GA40872@logik.internal.network> In-Reply-To: <20100313022817.GA40872@logik.internal.network> X-Enigmail-Version: 0.96.0 OpenPGP: id=1C940290 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.3 (/) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: glarkin@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 03:37:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 xorquewasp@googlemail.com wrote: [...] > DISTDIR= /var/ports/distfiles > PACKAGES= /var/ports/packages > WRKDIRPREFIX= /var/ports/work > PORTSDIR= /var/ports/tree > > jail# vi /etc/profile > FTP_PASSIVE_MODE=yes > HTTP_PROXY=10.1.3.3:8080 > export FTP_PASSIVE_MODE > export HTTP_PROXY > jail# . /etc/profile > > jail# portsnap -p /var/ports/tree fetch extract > Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. > Fetching public key from portsnap2.FreeBSD.org... done. > Fetching snapshot tag from portsnap2.FreeBSD.org... done. > Fetching snapshot metadata... done. > Fetching snapshot generated at Fri Mar 12 00:22:12 UTC 2010: > d67bd7a10044c70dc705b2c5b05db32b07ab8bd2262c3e 1% of 61 MB 161 kBps > ... > > jail# cd /var/ports/tree/graphics/inkscape > jail# make config-recursive > jail# make fetch-recursive > jail# make package-recursive 2>&1 | tee /tmp/inkscape.log > > Of course, at the end of inkscape.log: > [...] > rmdir: /var/ports/work/var/ports/tree/devel/eggdbus/work: Directory not empty > *** Error code 1 (ignored) [...] Hi xw, I noticed something strange here. How is WRKDIR (in this case "/var/ports/work/var/ports/tree/devel/eggdbus/work") defined? It looks like bsd.port.mk combined your WRKDIRPREFIX and PORTSDIR to create that path, but skimming the code, I can't figure out how it's doing that. How many levels of that directory tree exist on your system? If you look at the package-noinstall target in bsd.port.mk, you'll see the line: -@${RMDIR} ${WRKDIR} and I believe that's the one that throws the "Directory not empty" error. Have you tried just setting PORTSDIR and letting bsd.port.mk set the rest of the paths with their defaults that are relative to PORTSDIR? If that works, then we can start hunting for places that are not handling absolute vs. relative paths correctly in bsd.port.mk. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLmwhW0sRouByUApARArf3AJ41IkBVHYDmWcDH+JIMSpf15HrvogCgg10O igt2EmedReaASRFsCyn1a3A= =EgS8 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 03:52:28 2010 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 6AA3B106564A; Sat, 13 Mar 2010 03:52:28 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id C14068FC0A; Sat, 13 Mar 2010 03:52:27 +0000 (UTC) Received: by wwb24 with SMTP id 24so690399wwb.13 for ; Fri, 12 Mar 2010 19:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=ihZA/hSsOJEPJfoqcLgWVYyi73eYnr/5NN4zuJQOnEA=; b=nvtSkxIkLslyJm0gd+o3NLa8ky/I/sW+eCUIQxfNxFR7LmPrxSo9nd+58DBpm1PP/V hiV0LwPhLW3xuUXpVuHm0b6Lj1GHhdc63K3VO9xzardDdBcuaBG973f3PPqmjIbyrr6L vaCQ80tM08kW4rZBglcWHFFn5irAfaIi7TNEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; b=rRqDdbO6kp8ALpTb3SfyxTLe91xpu25ezYOu17nKf4Z2+EQQIPGcGsanFAIicFUiVB b8Q2t8hTgEmF3iwBO+PL+TC1sTnuyao5bXeBm1q7Pa8GcDKnlNwZbQzR8PAWkncVKTrN Wx4TWFYQ6mkKwIxit/qwq/4Py9J7MlAdlh60Y= Received: by 10.216.88.83 with SMTP id z61mr615990wee.14.1268452346586; Fri, 12 Mar 2010 19:52:26 -0800 (PST) Received: from viper.internal.network (dsl78-143-199-168.in-addr.fast.co.uk [78.143.199.168]) by mx.google.com with ESMTPS id i35sm7562177gve.11.2010.03.12.19.52.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Mar 2010 19:52:26 -0800 (PST) Received: from viper.internal.network (localhost [127.0.0.1]) by viper.internal.network (Postfix) with ESMTP id 773324AC01; Sat, 13 Mar 2010 03:52:24 +0000 (UTC) Received: (from m0@localhost) by viper.internal.network (8.14.3/8.14.3/Submit) id o2D3qNKg065584; Sat, 13 Mar 2010 03:52:23 GMT (envelope-from xorquewasp@googlemail.com) X-Authentication-Warning: viper.internal.network: m0 set sender to xorquewasp@googlemail.com using -f Date: Sat, 13 Mar 2010 03:52:23 +0000 From: xorquewasp@googlemail.com To: Greg Larkin Message-ID: <20100313035223.GA63186@logik.internal.network> References: <20100226163227.GA15162@logik.internal.network> <4B88074E.7050007@FreeBSD.org> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> <20100313022817.GA40872@logik.internal.network> <4B9B0856.4090301@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9B0856.4090301@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 03:52:28 -0000 On 2010-03-12 22:36:54, Greg Larkin wrote: > Hi xw, > > I noticed something strange here. How is WRKDIR (in this case > "/var/ports/work/var/ports/tree/devel/eggdbus/work") defined? It looks > like bsd.port.mk combined your WRKDIRPREFIX and PORTSDIR to create that > path, but skimming the code, I can't figure out how it's doing that. > How many levels of that directory tree exist on your system? 'Lo. Not sure I understand what you're asking me to check, but things have basically laid themselves out like this: # ls /var/ports/work/var/ports/tree/devel/eggdbus/work/eggdbus-0.6/ AUTHORS Makefile README config.h.in configure.ac eggdbus-1.pc.in missing COPYING Makefile.am aclocal.m4 config.log configure.bak gtk-doc.make src ChangeLog Makefile.in compile config.status depcomp install-sh stamp-h1 HACKING Makefile.in.bak config.guess config.sub docs libtool INSTALL NEWS config.h configure eggdbus-1.pc ltmain.sh > Have you tried just setting PORTSDIR and letting bsd.port.mk set the > rest of the paths with their defaults that are relative to PORTSDIR? If > that works, then we can start hunting for places that are not handling > absolute vs. relative paths correctly in bsd.port.mk. Will try that now. In the original setup, I did specifically want to keep these directories separate (as PORTSDIR was a read-only nullfs mount), but that's obviously not the case for this example setup. xw From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 07:52:54 2010 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 C48331065670; Sat, 13 Mar 2010 07:52:54 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2883C8FC1F; Sat, 13 Mar 2010 07:52:53 +0000 (UTC) Received: by wwb24 with SMTP id 24so751243wwb.13 for ; Fri, 12 Mar 2010 23:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=gVeKOAQOhCTfkSnFaV9TmBFbh7kPnKiY8+zyBW8O+bA=; b=FYi6YCgQKb9lPPPlLayKnbx8K6XTQwlAli6bou8AAhoBEyJf+BQ94CUphHTV2SPvuG J5v8Y/LktgQPpkPrZ2jN+WdOoLNGU/6j8K9W3EYk13jb1l9eQWFFmnQwb0v1w7RaJ9ac XoTgWGSScJcgSni5QYZFJtzDhD/l79qro9nIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; b=H56myzDnX/pfquEkIMaRwD085SAsbP4zHj2CcsJzaWJJFFp38hDmCs3G6uQbP5NpsG Ty1Id9QdthcdSLyNm0fgeKyqqfqCuIWBUEVYdSk2ob1KYlaTpvpvM+g6H1JoFOG0Pp/+ YhGhRwmynE0CIAlzCbq/2LS+84t2DqC9ItWlY= Received: by 10.216.91.81 with SMTP id g59mr301507wef.128.1268466772977; Fri, 12 Mar 2010 23:52:52 -0800 (PST) Received: from viper.internal.network (dsl78-143-199-168.in-addr.fast.co.uk [78.143.199.168]) by mx.google.com with ESMTPS id p10sm7716813gvf.22.2010.03.12.23.52.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Mar 2010 23:52:52 -0800 (PST) Received: from viper.internal.network (localhost [127.0.0.1]) by viper.internal.network (Postfix) with ESMTP id BF9114AC01; Sat, 13 Mar 2010 07:52:50 +0000 (UTC) Received: (from m0@localhost) by viper.internal.network (8.14.3/8.14.3/Submit) id o2D7qoXH023424; Sat, 13 Mar 2010 07:52:50 GMT (envelope-from xorquewasp@googlemail.com) X-Authentication-Warning: viper.internal.network: m0 set sender to xorquewasp@googlemail.com using -f Date: Sat, 13 Mar 2010 07:52:50 +0000 From: xorquewasp@googlemail.com To: Greg Larkin Message-ID: <20100313075249.GA92690@logik.internal.network> References: <20100226163227.GA15162@logik.internal.network> <4B88074E.7050007@FreeBSD.org> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> <20100313022817.GA40872@logik.internal.network> <4B9B0856.4090301@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9B0856.4090301@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 07:52:54 -0000 > Have you tried just setting PORTSDIR and letting bsd.port.mk set the > rest of the paths with their defaults that are relative to PORTSDIR? If > that works, then we can start hunting for places that are not handling > absolute vs. relative paths correctly in bsd.port.mk. Now, with only: PORTSDIR=/var/ports/tree .. in make.conf, the error is: Creating package /var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3 glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1 libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4 libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4 gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3. Creating bzip'd tar ball in '/var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz' rmdir: /var/ports/tree/devel/eggdbus/work: Directory not empty *** Error code 1 (ignored) ===> Generating temporary packing list Creating package /var/ports/tree/textproc/docbook-420/docbook-4.2.tbz Registering depends: iso8879-1986_2 xmlcatmgr-2.2. Creating bzip'd tar ball in '/var/ports/tree/textproc/docbook-420/docbook-4.2.tbz' tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /var/ports/tree/textproc/docbook-420. *** Error code 1 Stop in /var/ports/tree/textproc/docbook-420. *** Error code 1 Stop in /var/ports/tree/graphics/inkscape. Regards, xw From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 13:35:30 2010 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 16ED71065679 for ; Sat, 13 Mar 2010 13:35:30 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7C2408FC1C for ; Sat, 13 Mar 2010 13:35:29 +0000 (UTC) Received: (qmail invoked by alias); 13 Mar 2010 13:35:27 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp054) with SMTP; 13 Mar 2010 14:35:27 +0100 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX1/MxgIoSgDMbqzNums/uuYaaSeyiCk+6asKK4sZwW KCHqUB5dAZmXdI Date: Sat, 13 Mar 2010 14:37:34 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org References: <201003122101.o2CL1I7s028001@triton8.kn-bremen.de> In-Reply-To: <201003122101.o2CL1I7s028001@triton8.kn-bremen.de> Message-Id: <106107651416886@192.168.2.69> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 13:35:30 -0000 Hi, Juergen Lock gave me a lot to read about > ahci(4) on FreeBSD >= 8.0 The proposed solution points me to a third way how a contemporary burner can be driven by FreeBSD. The purpose of my FreeBSD installation is to improve libburn on FreeBSD and to provide support for FreeBSD users. I.e. i want to run a contemporary production system with all possible variations of drive attachment. My idea was to use the same burner via USB and via eSATA alternatively. So even if i get ahci running i would still need a solution for ata. (If there is none, then i will have to put the drive into the computer and use SATA without "e". No easy switch to USB then.) ------------------------------------------------ I will nevertheless try to get my fstab ready for ahci and to learn how to boot with that. After all, it seems to be the upcomming driver for SATA. Not being a skilled sysadmin i wonder whether this hint by Juergen announces trouble: > (you still have to take care of swap manually then tho, and dumpdev in > rc.conf if you have it set explicitly.) The machine is generously equipped with RAM. Vanilla installation from 8.0-RELEASE-amd64-dvd1.iso.gz plus some ports around CD/DVD/BD burning. Installation was easy. :) Can it be that it doesn't have any swap ? # swapinfo Device 1K-blocks Used Avail Capacity # vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad4 cd0 in sy cs us sy id 0 0 0 435M 3711M 64 0 0 0 56 0 0 0 2 94 448 0 0 100 Nothing gets found by # fgrep dump /etc/rc.conf Is that a good sign ? > HTH, :) It helped to expand my todo list, in any case. I was not aware of those aspects at all. Many thanks for your advise. Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 13:52:29 2010 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 D521A1065673 for ; Sat, 13 Mar 2010 13:52:29 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id BB6FA8FC1A for ; Sat, 13 Mar 2010 13:52:28 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,632,1262559600"; d="txt'?scan'208";a="239032581" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 13 Mar 2010 14:52:27 +0100 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 406071B07E7; Sat, 13 Mar 2010 14:52:27 +0100 (CET) Date: Sat, 13 Mar 2010 14:52:19 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100313135219f7e55a9d00006340-a_best01+ Cc: Subject: [patch] small fix to stop gcc warning for lib/libstand/assert.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 13:52:29 -0000 This is a MIME encoded multipart message. --+permail-20100313135219f7e55a9d00006340-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hello, this patch fixes the following gcc warning: /usr/src/lib/libstand/assert.c:43: warning: implicit declaration of function 'exit' by using abort() instead of exit() (which is illegal anyway). looking at lib/libc/gen/assert.c abort() seems save to use instead of exit(). cheers. alex --+permail-20100313135219f7e55a9d00006340-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="libstand.patch.txt" SW5kZXg6IGxpYi9saWJzdGFuZC9hc3NlcnQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBsaWIvbGlic3RhbmQv YXNzZXJ0LmMJKHJldmlzaW9uIDIwNTEyMSkKKysrIGxpYi9saWJzdGFuZC9hc3NlcnQuYwkod29y a2luZyBjb3B5KQpAQCAtNDAsNSArNDAsNSBAQAogCWVsc2UKIAkJcHJpbnRmKCJBc3NlcnRpb24g ZmFpbGVkOiAoJXMpLCBmdW5jdGlvbiAlcywgZmlsZSAlcywgbGluZSAiCiAJCSAgICAiJWQuXG4i LCBleHByZXNzaW9uLCBmdW5jLCBmaWxlLCBsaW5lKTsKLQlleGl0KCk7CisJYWJvcnQoKTsKIH0K SW5kZXg6IGxpYi9saWJzdGFuZC9zdGFuZC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpYi9saWJzdGFuZC9z dGFuZC5oCShyZXZpc2lvbiAyMDUxMjEpCisrKyBsaWIvbGlic3RhbmQvc3RhbmQuaAkod29ya2lu ZyBjb3B5KQpAQCAtMjY1LDYgKzI2NSw3IEBACiBleHRlcm4gY2hhcgkqb3B0YXJnOwkJCS8qIGdl dG9wdCgzKSBleHRlcm5hbCB2YXJpYWJsZXMgKi8KIGV4dGVybiBpbnQJb3B0aW5kLCBvcHRlcnIs IG9wdG9wdCwgb3B0cmVzZXQ7CiBleHRlcm4gaW50CWdldG9wdChpbnQsIGNoYXIgKiBjb25zdCBb XSwgY29uc3QgY2hhciAqKTsKK2V4dGVybiB2b2lkCWFib3J0KHZvaWQpOwogCiAvKiBwYWdlci5j ICovCiBleHRlcm4gdm9pZAlwYWdlcl9vcGVuKHZvaWQpOwo= --+permail-20100313135219f7e55a9d00006340-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 15:55:49 2010 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 AA25A106566B for ; Sat, 13 Mar 2010 15:55:49 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 45CB38FC08 for ; Sat, 13 Mar 2010 15:55:49 +0000 (UTC) Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NqTgq-0006n9-0H; Sat, 13 Mar 2010 16:55:48 +0100 Received: from p57ae1fdc.dip0.t-ipconnect.de ([87.174.31.220]:25324 helo=ernst.jennejohn.org) by 7.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #2) id 1NqTgp-0006sA-Nv; Sat, 13 Mar 2010 16:55:47 +0100 Date: Sat, 13 Mar 2010 16:55:46 +0100 From: Gary Jennejohn To: "Thomas Schmitt" Message-ID: <20100313165546.34553f7d@ernst.jennejohn.org> In-Reply-To: <106107651416886@192.168.2.69> References: <201003122101.o2CL1I7s028001@triton8.kn-bremen.de> <106107651416886@192.168.2.69> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 15:55:49 -0000 On Sat, 13 Mar 2010 14:37:34 +0100 "Thomas Schmitt" wrote: > So even if i get ahci running i would still > need a solution for ata. > (If there is none, then i will have to put > the drive into the computer and use SATA > without "e". No easy switch to USB then.) > I'm using ahci with two ATA/IDE DVD drives and they work as long as I have "device ata" in my kernel config. That's all I need. They appear as /dev/cd0 and /dev/cd1. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 19:51:15 2010 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 13FE0106566C for ; Sat, 13 Mar 2010 19:51:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f196.google.com (mail-pz0-f196.google.com [209.85.222.196]) by mx1.freebsd.org (Postfix) with ESMTP id D0B7D8FC15 for ; Sat, 13 Mar 2010 19:51:14 +0000 (UTC) Received: by pzk34 with SMTP id 34so1314057pzk.3 for ; Sat, 13 Mar 2010 11:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XHgIGFe3qTs0scr3m4DetSJW6BWy/bTNhGqk8dtG/aw=; b=fvJ5mpMK+WZzp99VelM8wwmdRknneIl8/z/90LuVYjjlX3xf61AUpo1FfGGt0jAwWn 8I3eRGvTn13iWvkZrDCjQ3pgRrFpkARIrWLb/vk1cDbXYOE+mMNNG5KjXTHZ3vdizAiB t7QLGOG1oESbpiH6bkmOqYqlitrx19wQMGcC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NosFJw9OAcga2rgxGUGB2vvREStPWHqXpRa3E09izSYlz1v9WVNlQjgkaTSFww3KnR ZGHHx6X1zN28GI5Tiu+zIYO+Uv2PG2iaW/A+gt1ZzQn2l4iJ2BH6O4XWYnwTyV/dpSA9 1R2VJUg2SsZyJMxodlVfyhdiLEN2p2nMwS2u8= MIME-Version: 1.0 Received: by 10.142.151.31 with SMTP id y31mr2059686wfd.107.1268509874185; Sat, 13 Mar 2010 11:51:14 -0800 (PST) In-Reply-To: <20100313075249.GA92690@logik.internal.network> References: <20100226163227.GA15162@logik.internal.network> <20100226222113.GA14592@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> <20100313022817.GA40872@logik.internal.network> <4B9B0856.4090301@FreeBSD.org> <20100313075249.GA92690@logik.internal.network> Date: Sat, 13 Mar 2010 11:51:14 -0800 Message-ID: <7d6fde3d1003131151x1909f475m7cd2633abaf436ce@mail.gmail.com> From: Garrett Cooper To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 19:51:15 -0000 On Fri, Mar 12, 2010 at 11:52 PM, wrote: >> Have you tried just setting PORTSDIR and letting bsd.port.mk set the >> rest of the paths with their defaults that are relative to PORTSDIR? =A0= If >> that works, then we can start hunting for places that are not handling >> absolute vs. relative paths correctly in bsd.port.mk. > > Now, with only: > > =A0PORTSDIR=3D/var/ports/tree > > .. in make.conf, the error is: > > Creating package /var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz > Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3= glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1= libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4 = libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4= gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3. > Creating bzip'd tar ball in '/var/ports/tree/devel/eggdbus/eggdbus-0.6.tb= z' > rmdir: /var/ports/tree/devel/eggdbus/work: Directory not empty > *** Error code 1 (ignored) > =3D=3D=3D> =A0 Generating temporary packing list > Creating package /var/ports/tree/textproc/docbook-420/docbook-4.2.tbz > Registering depends: iso8879-1986_2 xmlcatmgr-2.2. > Creating bzip'd tar ball in '/var/ports/tree/textproc/docbook-420/docbook= -4.2.tbz' > tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or direc= tory > tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directo= ry > tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or director= y > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > *** Error code 1 Note: all packages being created via package-recursive are created via package-noinstall, and because the pkg-plist is referring to files and directories which don't exist when install is run, the call will always fail: [gcooper@bayonetta ~]$ sudo make -C /usr/ports/textproc/docbook-420/ package-noinstall Password: =3D=3D=3D> Generating temporary packing list Creating package /usr/ports/packages/All/docbook-4.2.tbz Registering depends: iso8879-1986_2 xmlcatmgr-2.2. Creating bzip'd tar ball in '/usr/ports/packages/All/docbook-4.2.tbz' tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directo= ry tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or dire= ctory tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or dire= ctory tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or direc= tory tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or dire= ctory tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or dire= ctory tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /usr/ports/textproc/docbook-420. *** Error code 1 Stop in /usr/ports/textproc/docbook-420. [gcooper@bayonetta ~]$ cat /usr/ports/textproc/docbook-420/pkg-plist share/sgml/docbook/4.2/ChangeLog share/sgml/docbook/4.2/calstblx.dtd @unexec %%XMLCATMGR%% -sc %%CATALOG_PORTS_SGML%% remove %%DTD_NAME%%/%%DTD_VERSION%%/catalog share/sgml/docbook/4.2/catalog share/sgml/docbook/4.2/catalog.xml @exec %%XMLCATMGR%% -sc %%CATALOG_PORTS_SGML%% add CATALOG %%DTD_NAME%%/%%DTD_VERSION%%/catalog share/sgml/docbook/4.2/dbcentx.mod share/sgml/docbook/4.2/dbgenent.mod share/sgml/docbook/4.2/dbhierx.mod share/sgml/docbook/4.2/dbnotnx.mod share/sgml/docbook/4.2/dbpoolx.mod share/sgml/docbook/4.2/docbook.cat share/sgml/docbook/4.2/docbook.dcl share/sgml/docbook/4.2/docbook.dtd share/sgml/docbook/4.2/docbookx.dtd share/sgml/docbook/4.2/soextblx.dtd share/sgml/docbook/4.2/README @dirrm share/sgml/docbook/4.2 @dirrmtry share/sgml/docbook [gcooper@bayonetta /usr/ports/textproc/docbook-420]$ ls -a work/ . .. .PLIST.mktmp There's some sort of strange interaction with these ports (textproc/docbook*) that I'm currently looking at. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 19:52:49 2010 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 0CEF21065673 for ; Sat, 13 Mar 2010 19:52:49 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C8B5D8FC20 for ; Sat, 13 Mar 2010 19:52:48 +0000 (UTC) Received: by pwj4 with SMTP id 4so1457340pwj.13 for ; Sat, 13 Mar 2010 11:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6SzauUK8edIFAGJ1jFMj9Fr2liVk2GhoiW0EZyKQNDU=; b=a1zLbSXQIWp6f0oesZjfgsa2TZEUfPRFMvHafGqcvFpqJw12jCXVb7CoDxSQEBrGkg ZOlv4meqGoAF08tUtuT7tr2tyfspJbgwVllYqXxafXOW4pyPUJlzWTTdiWEIb2t9T0tQ tTXWhsFl+ClB0IDee+qRsjLAPrZUoOYuwxTxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CGsoHcuDHzE/Y4YPfBNYZWJNxmV8ai8Yt8zP58+DxpSUQBefUIZY3wf5w5AKY9lFYY IVvofppvzFM3tXIvc9A7z2wGqejeI7xCvhG5RLTqycC7hRDoTQVPP0y7/I6X4DhkoXeS QoymiW+Cq9rY5HUWUNHScJa7HHzp5/tBKiWQY= MIME-Version: 1.0 Received: by 10.142.62.15 with SMTP id k15mr199561wfa.139.1268509968292; Sat, 13 Mar 2010 11:52:48 -0800 (PST) In-Reply-To: <7d6fde3d1003131151x1909f475m7cd2633abaf436ce@mail.gmail.com> References: <20100226163227.GA15162@logik.internal.network> <4B884D48.90509@FreeBSD.org> <20100227093409.GA40858@logik.internal.network> <864ol0w4g5.fsf@ds4.des.no> <20100304175819.GC31036@logik.internal.network> <867hpr56ek.fsf@ds4.des.no> <20100313022817.GA40872@logik.internal.network> <4B9B0856.4090301@FreeBSD.org> <20100313075249.GA92690@logik.internal.network> <7d6fde3d1003131151x1909f475m7cd2633abaf436ce@mail.gmail.com> Date: Sat, 13 Mar 2010 11:52:48 -0800 Message-ID: <7d6fde3d1003131152v6d6374fdsc2f1754306b5bbac@mail.gmail.com> From: Garrett Cooper To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Something rotten in ports (was Re: package building failure irritation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 19:52:49 -0000 On Sat, Mar 13, 2010 at 11:51 AM, Garrett Cooper wrote= : > On Fri, Mar 12, 2010 at 11:52 PM, =A0 wrote: >>> Have you tried just setting PORTSDIR and letting bsd.port.mk set the >>> rest of the paths with their defaults that are relative to PORTSDIR? = =A0If >>> that works, then we can start hunting for places that are not handling >>> absolute vs. relative paths correctly in bsd.port.mk. >> >> Now, with only: >> >> =A0PORTSDIR=3D/var/ports/tree >> >> .. in make.conf, the error is: >> >> Creating package /var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz >> Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_= 3 glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_= 1 libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4= libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.= 4 gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3. >> Creating bzip'd tar ball in '/var/ports/tree/devel/eggdbus/eggdbus-0.6.t= bz' >> rmdir: /var/ports/tree/devel/eggdbus/work: Directory not empty >> *** Error code 1 (ignored) >> =3D=3D=3D> =A0 Generating temporary packing list >> Creating package /var/ports/tree/textproc/docbook-420/docbook-4.2.tbz >> Registering depends: iso8879-1986_2 xmlcatmgr-2.2. >> Creating bzip'd tar ball in '/var/ports/tree/textproc/docbook-420/docboo= k-4.2.tbz' >> tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or dire= ctory >> tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or d= irectory >> tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or direct= ory >> tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or d= irectory >> tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or di= rectory >> tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or d= irectory >> tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or d= irectory >> tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directo= ry >> tar: Error exit delayed from previous errors. >> pkg_create: make_dist: tar command failed with code 256 >> *** Error code 1 > > Note: all packages being created via package-recursive are created via > package-noinstall, and because the pkg-plist is referring to files and > directories which don't exist when install is run, the call will > always fail: Before a few folks correct me on this claim... all DEPENDENT packages are created via package-noinstall. The top-level package created with package-recursive is actually created via package. > [gcooper@bayonetta ~]$ sudo make -C /usr/ports/textproc/docbook-420/ > package-noinstall > Password: > =3D=3D=3D> =A0 Generating temporary packing list > Creating package /usr/ports/packages/All/docbook-4.2.tbz > Registering depends: iso8879-1986_2 xmlcatmgr-2.2. > Creating bzip'd tar ball in '/usr/ports/packages/All/docbook-4.2.tbz' > tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or direc= tory > tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directo= ry > tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or dir= ectory > tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or di= rectory > tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or director= y > tar: Error exit delayed from previous errors. > pkg_create: make_dist: tar command failed with code 256 > *** Error code 1 > > Stop in /usr/ports/textproc/docbook-420. > *** Error code 1 > > Stop in /usr/ports/textproc/docbook-420. > [gcooper@bayonetta ~]$ cat /usr/ports/textproc/docbook-420/pkg-plist > share/sgml/docbook/4.2/ChangeLog > share/sgml/docbook/4.2/calstblx.dtd > @unexec %%XMLCATMGR%% -sc %%CATALOG_PORTS_SGML%% remove > %%DTD_NAME%%/%%DTD_VERSION%%/catalog > share/sgml/docbook/4.2/catalog > share/sgml/docbook/4.2/catalog.xml > @exec %%XMLCATMGR%% -sc %%CATALOG_PORTS_SGML%% add CATALOG > %%DTD_NAME%%/%%DTD_VERSION%%/catalog > share/sgml/docbook/4.2/dbcentx.mod > share/sgml/docbook/4.2/dbgenent.mod > share/sgml/docbook/4.2/dbhierx.mod > share/sgml/docbook/4.2/dbnotnx.mod > share/sgml/docbook/4.2/dbpoolx.mod > share/sgml/docbook/4.2/docbook.cat > share/sgml/docbook/4.2/docbook.dcl > share/sgml/docbook/4.2/docbook.dtd > share/sgml/docbook/4.2/docbookx.dtd > share/sgml/docbook/4.2/soextblx.dtd > share/sgml/docbook/4.2/README > @dirrm share/sgml/docbook/4.2 > @dirrmtry share/sgml/docbook > [gcooper@bayonetta /usr/ports/textproc/docbook-420]$ ls -a work/ > . =A0 =A0 =A0 =A0 =A0 =A0 =A0 .. =A0 =A0 =A0 =A0 =A0 =A0 =A0.PLIST.mktmp > > =A0 =A0There's some sort of strange interaction with these ports > (textproc/docbook*) that I'm currently looking at. > Thanks, > -Garrett > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 21:03:20 2010 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 976DC106566C for ; Sat, 13 Mar 2010 21:03:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id 686DF8FC13 for ; Sat, 13 Mar 2010 21:03:20 +0000 (UTC) Received: by pxi38 with SMTP id 38so177554pxi.27 for ; Sat, 13 Mar 2010 13:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5UdTvw6y6lQ6WsQoLBkC6dBLyVNrzc4RRCsx7k3BV9g=; b=CBL4eJG6EUXrY7TnWSympBQ/sbRBFbBNjQhA0aaXvXnlTyVtqPa8096qft5J0UrW/a cA5lZYN9VurOobiN6X8XMVxLhtjnJeMAmZ2Pt3AFgA1uNkc5xXtG8gY7mT5fSPe0erLs c6LNl0wrg55dJgjruRh3fDo7MNvu7u+y8y/Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q+h+D38qvi2GJ4TbAFNSm+Ej4acNR+hVcCi3WNYHWi0nKnuRZGeYC0m8YcMx94CKtK 0LYL1XTiJx+K6YbY0W73m3+Lq5w2WpZWskoq6464mk/Sm6tNAik2hZN3loexs1tncwpH 6jlAWmVUNP2RTjZjH3OJ02hy2aCPsWavMXUtU= MIME-Version: 1.0 Received: by 10.142.66.23 with SMTP id o23mr519565wfa.327.1268514199939; Sat, 13 Mar 2010 13:03:19 -0800 (PST) Date: Sat, 13 Mar 2010 13:03:19 -0800 Message-ID: <7d6fde3d1003131303q4be87b46ic63fdd91ccee341d@mail.gmail.com> From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Hackers Subject: bin/144644 review [was Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Mar 2010 21:03:20 -0000 On Thu, Mar 11, 2010 at 8:24 PM, Garrett Cooper wrote: > > =A0 =A0I can haz PR review then? Here's an easy one :)... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D144644 I've modified the patch attached to the PR to conform to style(9). Thanks to Gary Jennenjohn, Ulrich Sp=F6rlein, Julian Elischer, and Mark Peek for the review comments. I'll see if I can track down someone interesting in giving it a final review [if necessary] and a commit. Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 21:56:35 2010 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 8A11F1065670 for ; Sat, 13 Mar 2010 21:56:35 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id EFF088FC20 for ; Sat, 13 Mar 2010 21:56:34 +0000 (UTC) Received: (qmail invoked by alias); 13 Mar 2010 21:56:33 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp072) with SMTP; 13 Mar 2010 22:56:33 +0100 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX18IsnZq5MEIHm0qp8FkCPA1CE7jpGxBjZngvKbd4R kMu1utaoMwF0Fv Date: Sat, 13 Mar 2010 22:58:40 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org References: <201003132009.o2DK9nBg061996@triton8.kn-bremen.de> In-Reply-To: <201003132009.o2DK9nBg061996@triton8.kn-bremen.de> Message-Id: <106070878026016@192.168.2.69> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 21:56:35 -0000 Hi, Gary Jennejohn wrote: > I'm using ahci with two ATA/IDE DVD drives and they work as long as I > have "device ata" in my kernel config. That's all I need. So i will probably need that for the IDE DVD-ROM drive that is built in too. Juergen Lock wrote: > thanks for trying to help improving libburn! :) Well, i am its active developer since a while. Any problems with it are probably my fault. Nevertheless, its FreeBSD SCSI transport is not originally by me. So i lack specific knowledge. (There are two alternative transport adapters: sg-freebsd originally by Alexander Nedotsukov, sg-libcdio for upcomming libcdio-0.83 .) > http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 I will test. This was BD-R, not BD-RE, i assume ? A leadout track. Sounds very CD-ish. With DVD and BD one should rather go for READ DISC INFORMATION and READ TRACK INFORMATION. > Well if you didn't create a swap partition during install then you > don't have one. :) Not to have one seems to be an advantage now. I don't remember to have been asked. But with 4 GB of RAM i might simply have answered 'no'. > the saved state of a panic'd kernel, I assume for reporting my kernel panics i have to install a development kernel ? (Switching off-and-on a stuck USB drive is obviously not a healthy thing to do.) Well, i plan to install another FreeBSD from scratch to try reproducing drive concurrency problems which i experienced first and which vanished after installing the ports of xfburn and xorriso. First drives got stuck when disturbed while burning CD. Now the offender gets blocked until the vulnerable drive state ends. Those ports triggered a cascade of other ports. So i have no idea which one might have tweaked the configuration (or whathever happened). > Btw there also is siis(4) [...] for > SiliconImage sata controllers. > [...] sas controllers If somebody has such hardware then i would be interested to hear whether it works with libburn. Anybody is invited to ask for support. Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 13 20:15:58 2010 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 86AA71065676 for ; Sat, 13 Mar 2010 20:15:58 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 15D7B8FC2B for ; Sat, 13 Mar 2010 20:15:57 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 137951E0016B; Sat, 13 Mar 2010 21:15:57 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o2DK9nnx061997; Sat, 13 Mar 2010 21:09:49 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o2DK9nBg061996; Sat, 13 Mar 2010 21:09:49 +0100 (CET) (envelope-from nox) Date: Sat, 13 Mar 2010 21:09:49 +0100 (CET) From: Juergen Lock Message-Id: <201003132009.o2DK9nBg061996@triton8.kn-bremen.de> To: scdbackup@gmx.net X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <106107651416886@192.168.2.69> References: <201003122101.o2CL1I7s028001@triton8.kn-bremen.de> Organization: home X-Mailman-Approved-At: Sat, 13 Mar 2010 23:29:13 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: How to slow down SATA to 1.5 GBit/s ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 20:15:58 -0000 In article <106107651416886@192.168.2.69> you write: >Hi, Hi! > >Juergen Lock gave me a lot to read about >> ahci(4) on FreeBSD >= 8.0 > >The proposed solution points me to a third way >how a contemporary burner can be driven by >FreeBSD. > >The purpose of my FreeBSD installation is to >improve libburn on FreeBSD and to provide >support for FreeBSD users. I.e. i want to run >a contemporary production system with all >possible variations of drive attachment. >My idea was to use the same burner via USB and >via eSATA alternatively. > >So even if i get ahci running i would still >need a solution for ata. >(If there is none, then i will have to put > the drive into the computer and use SATA > without "e". No easy switch to USB then.) > Ah ok, I see... And thanks for trying to help improving libburn! :) Btw there also is siis(4) which works pretty much the same as ahci(4), only its for SiliconImage sata controllers. (And then you can also connect sata drives on sas controllers although I'm not sure if anyone tested burning there yet... I do know of someone who was able to boot and install FreeBSD from an optical drive connected that way tho.) And if you are also testing bluray you might need another patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=138789 (Actually the patch also was needed for an external optical drive connected on usb to read `pressed' dvds for one guy, but since you use a `normal' sata drive with an usb interface your drive probably isn't affected - unless it is bluray.) >------------------------------------------------ > >I will nevertheless try to get my fstab ready >for ahci and to learn how to boot with that. >After all, it seems to be the upcomming driver >for SATA. > >Not being a skilled sysadmin i wonder whether >this hint by Juergen announces trouble: > >> (you still have to take care of swap manually then tho, and dumpdev in >> rc.conf if you have it set explicitly.) > >The machine is generously equipped with RAM. >Vanilla installation from 8.0-RELEASE-amd64-dvd1.iso.gz >plus some ports around CD/DVD/BD burning. >Installation was easy. :) > >Can it be that it doesn't have any swap ? > > # swapinfo > Device 1K-blocks Used Avail Capacity > # vmstat > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad4 cd0 in sy cs us sy id > 0 0 0 435M 3711M 64 0 0 0 56 0 0 0 2 94 448 0 0 100 > >Nothing gets found by > # fgrep dump /etc/rc.conf >Is that a good sign ? > Well if you didn't create a swap partition during install then you don't have one. :) A swap partition has another use besides, well, swapping if you are low on ram: Taking a crashdump in case of a kernel panic etc. (that is what dumpdev configures), in order to get a full kernel backtrace or otherwise look at the saved state of a panic'd kernel, i.e. it is to help debugging... But btw there has been code added recently to allow dumping onto an usb key/disk too so if all else fails and your FreeBSD is new enough you might still be able to get a backtrace that way. I don't remember if that code is in 8.0 already so you might need stable/8 or head tho; it is not in 6.x or 7.x because it needs the new usb stack. Anyway, good luck! Juergen