From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 00:43:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84BCA106567B for ; Sun, 28 Mar 2010 00:43:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 25C0E8FC1E for ; Sun, 28 Mar 2010 00:42:59 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id yQgh1d0021vXlb85DQj0LS; Sun, 28 Mar 2010 00:43:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id yQmy1d00A3S48mS3dQmygA; Sun, 28 Mar 2010 00:46:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3A1FA9B436; Sat, 27 Mar 2010 17:42:57 -0700 (PDT) Date: Sat, 27 Mar 2010 17:42:57 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100328004257.GA52623@icarus.home.lan> References: <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 00:43:00 -0000 On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote: > At 02:14 AM 3/26/2010, Jeremy Chadwick wrote: > >I'm willing to make an exception here. If you can get the following > >information from the motherboard manufacturer, I'd be willing to add > >support for your board to bsdhwmon. What I need: > > {snip} > > >3) What the SMBus slave address is they chose for the H/W IC > > % dmesg | grep -i smbus > pci0: at device 31.3 (no driver attached) All this means is that there's a SMBus-class device sitting on the PCI bus which has no driver attached to it. Run "pciconf -lvc" and find the device in question, and the output relevant to it. Given the topic of discussion, I'd say your northbridge is Intel-based, which means you need the smb, smbus, and ichsmb drivers loaded. You can load these as kernel modules as well. When loading them, do not specify the trailing ".ko". See the ichsmb(4) man page for some terse details. Even if you get a driver attached to the SMBus piece of the northbridge, like I said, there's no guarantee there's a H/W monitoring IC that's wired to the SMBus. As stated, I don't believe in probing slave addresses on the SMBus, so the slave address would have to come from Gigabyte, or... There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which does do probing and can/does support SMBus. I have no idea if it works on Windows 7 or not: http://www.almico.com/speedfan.php If SpeedFan shows you all the data you expect/want, and indicates it's talking to a H/W IC over SMBus, then I could add support for your board to bsdhwmon (since your motherboard does provide acceptable SMBIOS tables for identification). I'd still need to know what slave address the chip had, and what exact model of H/W IC it was. SpeedFan might provide that. It would also help (me at least) if you could reboot your system, go into your BIOS and find whatever menu item is associated with Hardware Monitoring and write down all of the shown attributes and their values. What the BIOS shows is what should be accurate above all else. > >> It jumped up in vcore a little there with powerd. C1E and C2E which > >> include P-states are what I am really after and I think that the > >> bios by itself provides those changes better than any other changes > >> in these settings. > > > >...and this would fall under the est(4) subset driver for cpufreq(4). > > This repeated clue got me to the next step and I thank you for that. > The key, as I see it, is to get est working either by getting the > msr tables updated somehow or getting the acpi working better so est > could fall back on it therefore powerd would have a better set of > signals to use rather than thermal. Like I have mentioned elsewhere, > it looks like est has not really been updated nor worked on much for > about 5 years and is missing the proper tables for the mbds since. > That is a big and near impossible job unless it can be modded to a > sort of wildcard detection if there is some commonality to newer > mbds. I can point you to numerous present-day motherboards that work just fine with cpufreq(4) and est under RELENG_8, and also work when using acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 boards. I'm sure there are many others. In all of these are Core2Duo or Core2Quad CPUs. An example from the X7SBA system, running powerd: CPU1 Temperature 41 C System Temperature 36 C FAN1 0 RPM FAN2 0 RPM FAN3 0 RPM FAN4 1988 RPM FAN5 1532 RPM FAN6 1809 RPM VcoreA 1.220 V MCH Core 1.514 V -12V -11.904 V V_DIMM 1.712 V +3.3V 3.360 V +12V 12.000 V 5Vsb 5.118 V 5VDD 5.022 V P_VTT 1.140 V Vbat 3.312 V And relevant sysctls: debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 41.0C dev.cpu.0.freq: 2000 dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2000/16000 dev.cpu.0.cx_supported: C1/0 C2/85 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 49.99% 50.00% last 286us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 41.0C dev.cpu.1.cx_supported: C1/0 C2/85 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 49.99% 50.00% last 286us dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000 dev.est.1.%desc: Enhanced SpeedStep Frequency Control dev.est.1.%driver: est dev.est.1.%parent: cpu1 dev.est.1.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000 The temperatures you see above are accurate, since it's a system I have at home where I prefer quiet, low-speed fans. :-) I should note that the device attachment error (error 6) is something I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced Mode were disabled in the BIOS. FreeBSD would report that SpeedStep existed but that it wasn't able to attach. I *explicitly* disabled those features in the BIOS since I saw some bizarre process behaviour ("calcru: runtime went backwards ... for pid X"). Since upgrading those boxes to RELENG_8, I've been able to re-enable both BIOS options and use cpufreq(4) with est + powerd without any sign of what I witnessed on RELENG_7. Of course, I did that only a few days ago, so it may be too soon to tell. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 01:54:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775B0106566C; Sun, 28 Mar 2010 01:54:52 +0000 (UTC) (envelope-from fbsd2@sstec.com) Received: from star.sstec.com (adsl-216-102-148-67.dsl.lsan03.pacbell.net [216.102.148.67]) by mx1.freebsd.org (Postfix) with ESMTP id 326BE8FC13; Sun, 28 Mar 2010 01:54:51 +0000 (UTC) Received: from main.sstec.com (main.sstec.com [192.168.74.8]) by star.sstec.com (8.13.8/8.13.8) with ESMTP id o2S1sgYv083127; Sat, 27 Mar 2010 18:54:46 -0700 (PDT) (envelope-from fbsd2@sstec.com) Message-Id: <5.2.1.1.2.20100327165629.032357b0@mail.sstec.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 27 Mar 2010 18:53:21 -0700 To: Ian Smith , Jeremy Chadwick From: John Long In-Reply-To: <20100327153102.X30338@sola.nimnet.asn.au> References: <20100326091447.GA91547@icarus.home.lan> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <20100326091447.GA91547@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Motin , FreeBSD-STABLE Mailing List Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 01:54:52 -0000 At 10:35 PM 3/26/2010, Ian Smith wrote: >On Fri, 26 Mar 2010, Jeremy Chadwick wrote: > >[ leaving the MB monitoring stuff alone for your expert attention :-] > > > > It jumped up in vcore a little there with powerd. C1E and C2E which > > > include P-states are what I am really after and I think that the > > > bios by itself provides those changes better than any other changes > > > in these settings. > > > > ...and this would fall under the est(4) subset driver for cpufreq(4). > >Just checking, I know nothing about these so far, but are you suggesting >that John having C1E and C2E enabled in BIOS may be affecting ACPI/EST >detection, and that things may be different were these disabled? No sir. Detection appears to be a function of the signals that are provided by the mbd regardless of bios settings. As per earlier msgs, I originally found out that powerd actually increased the TDP of the system at the wall by about 3 watts. That turning off the bios settings for c1e, c2e and eist raised the power a little and with powerd it was still higher than with just bios factors on and no powerd. All the rest is just discovery as to why this anomaly was so. It seems that ACPI is just not fully functional for this motherboard and if est does work on other recent mbds then that would be because of the acpi working better for them as the hard coded est tables are a bit old. From what I see, est takes tables primary and acpi fallback. powerd takes est primary and thermal fallback (acpi may be in there too, forgot now). powerd and thermal is not viable for lowering power usage at very low cpu rates. It merely provides a phantom crutch until one does realize it does not truly work, in my case anyway. We need to use the P-states which lower voltage and true freq, in order to lower tdp sucessfully, from what I see. > >If that's not what you meant, could you expand a little? > >John: you may want to explore where this comes together in kern_cpu.c >where you'll see those cpufreq debugging messages you quoted. kern_cpu.c looks to be the mech for reading or setting the freq. In there they mention that using an absolute freq is preferable to the artificial freq with lengthened clocks because then the voltage is often changed relative thereto. Where the voltage is changed is my quest. No where in there nor src/sys/kern do I see a ref for p-states and only in that file is voltage referenced. Therefore the change in voltage as a function of frequency must be auto determinant in another place and probably the bios as my guess so far. Further looking I see ichss.c in /usr/src/sys/dev/cpufreq (dev not i386 dir) where voltage is referenced. No other refs of votage I notice other than batt etc and no ref to pstate nor p-state at all in src/sys. Personally, I deem p-states to be key therefore I may assume that they are left to lower level bios routines relative to freq unless I am missing something here. Considering the absolute freq is preferred over the artificial freq, that is a remnant of powerd (when it falls back to just thermal), and appears to be a requisite for the lower level routines in order to change p-states, leads me back to getting est to load proper. Therefore I should pursue the tables part of its detection, if I continue digging into things that are over my head.. Some of >the more gritty documentation may be found browsing with something like: >% less /sys/{sys,kern,amd64/include}/*cpu*.[ch] Things that should be left to the pros that have been wading this ocean of code for years.. :-) thanks again, John > >cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 07:16:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8CE106564A; Sun, 28 Mar 2010 07:16:41 +0000 (UTC) (envelope-from fbsd2@sstec.com) Received: from star.sstec.com (adsl-216-102-148-67.dsl.lsan03.pacbell.net [216.102.148.67]) by mx1.freebsd.org (Postfix) with ESMTP id D69648FC18; Sun, 28 Mar 2010 07:16:40 +0000 (UTC) Received: from main.sstec.com (main.sstec.com [192.168.74.8]) by star.sstec.com (8.13.8/8.13.8) with ESMTP id o2S7GUho087731; Sun, 28 Mar 2010 00:16:33 -0700 (PDT) (envelope-from fbsd2@sstec.com) Message-Id: <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sun, 28 Mar 2010 00:16:27 -0700 To: Jeremy Chadwick From: John Long In-Reply-To: <20100328004257.GA52623@icarus.home.lan> References: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 07:16:41 -0000 At 05:42 PM 3/27/2010, Jeremy Chadwick wrote: >On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote: >> At 02:14 AM 3/26/2010, Jeremy Chadwick wrote: >> % dmesg | grep -i smbus >> pci0: at device 31.3 (no driver attached) > >All this means is that there's a SMBus-class device sitting on the PCI >bus which has no driver attached to it. Run "pciconf -lvc" and find the >device in question, and the output relevant to it. none1@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus put this in # Intel Core/Core2Duo CPU temperature monitoring driver device coretemp # SMBus support, needed for bsdhwmon device smbus device smb device ichsmb now get this ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus %smbmsg -p Probing for devices on /dev/smb0: Device @0x10: w Does not look to be much there if I am doing this right.. >Given the topic of discussion, I'd say your northbridge is Intel-based, >which means you need the smb, smbus, and ichsmb drivers loaded. You can >load these as kernel modules as well. When loading them, do not specify >the trailing ".ko". See the ichsmb(4) man page for some terse details. > >Even if you get a driver attached to the SMBus piece of the northbridge, >like I said, there's no guarantee there's a H/W monitoring IC that's >wired to the SMBus. As stated, I don't believe in probing slave >addresses on the SMBus, so the slave address would have to come from >Gigabyte, or... > >There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which >does do probing and can/does support SMBus. I have no idea if it works >on Windows 7 or not: > >http://www.almico.com/speedfan.php > >If SpeedFan shows you all the data you expect/want, and indicates it's >talking to a H/W IC over SMBus, then I could add support for your board >to bsdhwmon (since your motherboard does provide acceptable SMBIOS >tables for identification). I'd still need to know what slave address >the chip had, and what exact model of H/W IC it was. SpeedFan might >provide that. I have a feeling that my smbus is just not hooked up, nothing there.. speedfan looks cool tho. > >It would also help (me at least) if you could reboot your system, go >into your BIOS and find whatever menu item is associated with Hardware >Monitoring and write down all of the shown attributes and their values. >What the BIOS shows is what should be accurate above all else. >I can point you to numerous present-day motherboards that work just fine >with cpufreq(4) and est under RELENG_8, and also work when using >acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 >boards. I'm sure there are many others. In all of these are Core2Duo >or Core2Quad CPUs. An example from the X7SBA system, running powerd: It looks good, all working.. > >I should note that the device attachment error (error 6) is something >I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced >Mode were disabled in the BIOS. FreeBSD would report that SpeedStep >existed but that it wasn't able to attach. > >I *explicitly* disabled those features in the BIOS since I saw some >bizarre process behaviour ("calcru: runtime went backwards ... for pid >X"). Have you tried to measure the wall power with a kill-a-watt yet or can you? I am curious that things are actually working and tdp goes down when powerd is running vs not. About 20.00 - lowes, costco etc http://www.google.com/search?q=kill-a-watt very handy to check everything out. My system takes about 15 secs to lower freq to min and the power goes up a watt each 5 secs or so. Yes, it looks like it is working but the power meter tells the truth. John >-- >| Jeremy Chadwick jdc@parodius.com | >| Parodius Networking http://www.parodius.com/ | >| UNIX Systems Administrator Mountain View, CA, USA | >| Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 11:16:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44803106564A for ; Sun, 28 Mar 2010 11:16:18 +0000 (UTC) (envelope-from masoom.shaikh@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 13F838FC08 for ; Sun, 28 Mar 2010 11:16:17 +0000 (UTC) Received: by pzk34 with SMTP id 34so3612437pzk.3 for ; Sun, 28 Mar 2010 04:16:17 -0700 (PDT) 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:received:message-id:subject:from:to:content-type; bh=m1y1M8Pp8aaRHDHMdrtkzm4o6zkrE1sljUiDVt0FvqA=; b=u+vIn/uLHOszCtZZ0K58ZS/IqufPRHDObd23ylXL6cAPUIqM+esgGbN1mjimx6EitQ uYuUADJW4BpHiyOyorm6MGkLRP3IVJ2iSNL1rSVqKWFLFlm+YC7O4tpHW2leOA4I78W1 yMyXmyhWFQoMqzEpiLUtfzohfnlnyGyz+zgnk= 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=FhLc5vnJ3vXsrPYnun2gXufSzh52imv/XMJy/Gtdy4yy70vp2hNsM2GtmypnOzkJnR Bq0He/j+Ys19rxJGq8PaFzcrUfM76CCCK0Ovl0S5Q+jQKa51keUmz0Hyv78/SyRjyjZ8 AX7mQJ5bNTijUHfC0JFOYtZdyQkBVufJ873xY= MIME-Version: 1.0 Received: by 10.114.191.6 with HTTP; Sun, 28 Mar 2010 04:16:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Mar 2010 11:16:17 +0000 Received: by 10.115.64.21 with SMTP id r21mr3747629wak.23.1269774977361; Sun, 28 Mar 2010 04:16:17 -0700 (PDT) Message-ID: From: Masoom Shaikh To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=0016e64cc3bc78672a0482da8647 Subject: Fwd: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 11:16:18 -0000 --0016e64cc3bc78672a0482da8647 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Masoom Shaikh Date: Sun, Mar 28, 2010 at 8:28 AM Subject: random FreeBSD panics To: freebsd-hackers@freebsd.org, freebsd-questions Hello List, I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since then, system randomly just freezes, and there is no option other than hard boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( Many times I get vmcore files, not always. I have dumpdev set to AUTO in my rc.conf. Almost every time it just fsck's the file-system on reboot. I have not lost any files though. This is a Dell Inspiron 1525 Laptop with 1GB ram, Intel Core2 Duo T5500 with ATI Radeon X1400 card. The installation in question is KDE4 from ports, with radeon/ati driver. I felt the problem is with wpi driver, then suspected dri driver of X. Then I observed system freezes even if none of this is installed. e.g. if it is under some load, like building a port and simultaneously fetching something over network it hangs, and hangs hard. This persuaded me to think something is wrong in kernel scheduling itself. May be it is lost in some deadlock, etc... Thus last weekend I thought I would see how immediate previous version i.e. FreeBSD-7.3-RELEASE would behave. I reinstalled FreeBSD7.1 from iso images, svn up'ed FreeBSD7.3 source, did the normal buildworld, buildkernel, installkernel, installworld cycle. Unfortunatly this kernel is naughty as well ;-), it also freezes with same stubbornness. But difference is this time I happen to catch something interesting. It panics on NMI, fatal trap 19 while in kernel mode. Loaded the vmcore file in kgdb and got the backtrace. I obtained vmcore files on two occasions. I have attached both the back traces. This error most likely suggests hardware error in RAM, but Windox7 and XP boot just fine and never caused any errors. To verify if I have errors in my RAM I let run sysutils/memtest86+ overnight, to double verify I also executed Windows Memory Diagnostic test for four times. None of them reported errors. Can anyone here suggest any solution. Masoom Shaikh forwarding to stable@ with respect to a generous suggestion --0016e64cc3bc78672a0482da8647 Content-Type: application/octet-stream; name="vmcore0.log" Content-Disposition: attachment; filename="vmcore0.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g7bl83j20 R05VIGdkYiA2LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCBJbmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5k L29yIGRpc3RyaWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlw ZSAic2hvdyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRl bHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxz LgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2QiLi4uCgpV bnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOgo8PDIyPj5OTk1JIElN U0FJICBJU0EgYTBhLDAsICBFRUlJU1NBIEFmIGZmCmY8CjI8PjJSPkEKTTwyCj48UjI+QSBNcCBh cHJhaXJ0aXl0IHllIHJlcnJvcnJvLHIgLGwgaWxraWVrbGV5bCB5aCBhaHJhZHJ3ZGF3cmFlciBl ZiBhZmlhbGl1bHJ1ZXIuZS4KCgoKRkZhYXR0YWFsbCAgdHRycmFhcHAgIDExOTk6OiAgbm5vb25u LS1tbWFhc3Nra2FhYmJsbGVlICBpaW5udHRlZXJycnJ1dXBwdHQgIHR0cnJhYXBwICB3d2hoaWls bGVlICBpaW5uICBra2VlcnJubmVlbGwgIG1tb29kZGVlCgpjY3BwdXVpaWRkICA9PSAgMTA7OyAg YWFwcGlpY2MgIGlpZGQgID09ICAwMDEwCgppaW5uc3N0dHJydXVjY3R0aWlvb25uICBwcG9vaWlu bnR0ZWVycgkJPT0gIDAweHg4ODo6MDB4eGZmZmZmZmZmZmZmZmZmZjhmMDg1MDU4ZjJlYzUwOWFk CnMKdHNhdGNha2Mga3Agb3Bpb25pdG5ldHJlCXIgCSAgICAgICAgICAgICAgPSAgPTAgeDAxeDAx OjAwOngwZnhmZmZmZmZmZmY4ZjBmMGYwZjA4MDA4Y2YwZWMwMzAKMGZyCmFmbXJlYSBtcGVvIGlw bm90aWVucnQJZSByIAkgICAgICAgICAgICA9ICAgMD14IDEwMHg6MTAweDpmMGZ4ZjBmZgpmYzBv MGQwZWUgN3MwZTBnYW1lZTBudAoJYwlvPWQgZWIgYXNzZWVnIG0wZXhuMHQsCSAJbD1pIG1iaWF0 cyBlMCB4MGZ4ZjBmLGYgZmwsaSBtdGl5dHAgZTAgeDBmeGYxZmJmCmYJLAkgCXQ9eSBwRGVQIEww IHgwMSxiIApwCXIJZQlzPSAgMUQsUCBMbCBvMG4sZyAgcDFyLGUgc2QgZTFmLDMgMmwgbzBuLGcg IGcxcixhIG5kIGUxZgozcDJyIG8wYyxlIHNnc3JvYXJuICBlMWYKbHBhcmdvc2MJZT1zIHNpb25y dCBlZXJmcmx1YXBndHMgCWU9biBhaWJubHRlZWRyLHIgdUlwT3RQIExlIG49YSBiMGwKZWNkdSxy IHJJZU9uUHRMICBwPXIgbzBjCmVjc3VzcglyCWU9biB0MSAxcDhyNm8yYyBlKHNhc3MJKQkKPXQg cjFhMXA4IDZuMXUgbShiY2VjcjEJcAlsPXUgczEpOQoKdHJwYWFwbiBpbmN1Om0gYm5lb3JuCS0J bT1hIHMxazlhYgpsZSBpbnRlcnJ1cHQgdHJhcApjcHVpZCA9IDAKVXB0aW1lOiAyNm0yMHMKUGh5 c2ljYWwgbWVtb3J5OiAxMDA5IE1CCkR1bXBpbmcgMTI2NyBNQjogMTI1MiAxMjM2IDEyMjAgMTIw NCAxMTg4IDExNzIgMTE1NiAxMTQwIDExMjQgMTEwOCAxMDkyIDEwNzYgMTA2MCAxMDQ0IDEwMjgg MTAxMiA5OTYgOTgwIDk2NCA5NDggOTMyIDkxNiA5MDAgODg0IDg2OCA4NTIgODM2IDgyMCA4MDQg Nzg4IDc3MiA3NTYgNzQwIDcyNCA3MDggNjkyIDY3NiA2NjAgNjQ0IDYyOCA2MTIgNTk2IDU4MCA1 NjQgNTQ4IDUzMiA1MTYgNTAwIDQ4NCA0NjggNDUyIDQzNiA0MjAgNDA0IDM4OCAzNzIgMzU2IDM0 MCAzMjQgMzA4IDI5MiAyNzYgMjYwIDI0NCAyMjggMjEyIDE5NiAxODAgMTY0IDE0OCAxMzIgMTE2 IDEwMCA4NCA2OCA1MiAzNiAyMCA0CgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwv bnRmcy5rby4uLlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9udGZzLmtvLnN5bWJv bHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL250ZnMua28K UmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3dwaWZ3LmtvLi4uUmVhZGluZyBzeW1i b2xzIGZyb20gL2Jvb3Qva2VybmVsL3dwaWZ3LmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2Fk ZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3dwaWZ3LmtvClJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L2tlcm5lbC9yYWRlb24ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvcmFkZW9uLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jv b3Qva2VybmVsL3JhZGVvbi5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZHJt LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2RybS5rby5zeW1ib2xzLi4u ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9kcm0ua28KIzAgIGRv YWR1bXAgKCkgYXQgcGNwdS5oOjE5NQoxOTUJcGNwdS5oOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5LgoJaW4gcGNwdS5oCihrZ2RiKSBidAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk1CiMx ICAweDAwMDAwMDAwMDAwMDAwMDQgaW4gPz8gKCkKIzIgIDB4ZmZmZmZmZmY4MDU2ZGQ1OSBpbiBi b290IChob3d0bz0yNjApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6 NDE4CiMzICAweGZmZmZmZmZmODA1NmUxNjIgaW4gcGFuaWMgKGZtdD0weDEwNCA8QWRkcmVzcyAw eDEwNCBvdXQgb2YgYm91bmRzPikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRv d24uYzo1NzQKIzQgIDB4ZmZmZmZmZmY4MDgzMWYzMyBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGZm ZmZmZjAwMjVhMTc3NDAsIGV2YT1WYXJpYWJsZSAiZXZhIiBpcyBub3QgYXZhaWxhYmxlLgopCiAg ICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjc3NwojNSAgMHhmZmZmZmZmZjgw ODMyYjdiIGluIHRyYXAgKGZyYW1lPTB4ZmZmZmZmZmY4MGMwYzI1MCkKICAgIGF0IC91c3Ivc3Jj L3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NTc4CiM2ICAweGZmZmZmZmZmODA4MWJiY2YgaW4gbm1p X2NhbGx0cmFwICgpCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6 NDUxCiM3ICAweGZmZmZmZmZmODA4MmMwYWQgaW4gcG1hcF9yZW1vdmVfcGFnZXMgKHBtYXA9MHhm ZmZmZmYwMDAxOTUzZTM4KQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3BtYXAuYzoz ODUzClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQo= --0016e64cc3bc78672a0482da8647 Content-Type: application/octet-stream; name="vmcore1.log" Content-Disposition: attachment; filename="vmcore1.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g7bl8isl1 R05VIGdkYiA2LjEuMSBbRnJlZUJTRF0NCkNvcHlyaWdodCAyMDA0IEZyZWUgU29mdHdhcmUgRm91 bmRhdGlvbiwgSW5jLg0KR0RCIGlzIGZyZWUgc29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdOVSBH ZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBhbmQgeW91IGFyZQ0Kd2VsY29tZSB0byBjaGFuZ2UgaXQg YW5kL29yIGRpc3RyaWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4N ClR5cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25zLg0KVGhlcmUgaXMgYWJz b2x1dGVseSBubyB3YXJyYW50eSBmb3IgR0RCLiAgVHlwZSAic2hvdyB3YXJyYW50eSIgZm9yIGRl dGFpbHMuDQpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2Qi Li4uDQoNClVucmVhZCBwb3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6DQo8PDIy Pj5OTk1JTSBJSSBTSUFTIEEgYjAsYiAwRSxJIFNFQUkgU2ZBZiANCmY8DQoyPD4yUj5BZk0NCiA8 DQoyPD4yUj5BcE1hIHJwaWF0cnlpIGV0cnlyIG9lcnIscm8gcmwsaSBrbGVpbGt5ZSBsaHlhIHJo ZGF3cmFkcndlYSByZmVhIGlmbGF1aXJsZXUucmUuDQoNCg0KDQpGRmFhdHRhYWxsICB0dHJyYWFw cCAgMTE5OTo6ICBub25uby1ubS1hbXNha3Nha2JhbGJlbCBlaSBuaXRuZXRyZXJydXJwdXRwIHR0 IHJ0YXJwYSBwdyBod2lobGllbCBlaSBuaSBuayBla3JlbnJlbmxlIGxtIG9tZG9lZGUNCg0KY2Nw cHV1aWlkZCAgPT0gIDAxOzsgIGFhcHBpaWNjICBpaWRkICA9PSAgMDAwMQ0KDQppaW5uc3N0dHJy dXVjY3R0aWlvb25uICBwcG9vaWlubnR0ZWVycgkJPT0gIDAweHg4ODo6MDB4eGZmZmZmZmZmZmZm ZmZmZjhmMDg4MDI1YjVkZjNlNzczDQpzDQp0c2F0Y2FrYyBrcCBvcGlvbml0bmV0cmUJciAJICAg ICAgICAgICAgICA9ICA9MCB4MDF4MDE6MDA6eDBmeGZmZmZmZmZmZmZmZmY4ODAwYzAwMGMwMzAw ODBmZQ0KMGZyDQphZm1yZWEgbXBlbyBpcG5vdGllbnJ0CWUgciAJICAgICAgICAgICAgPSAgIDA9 eCAxMDB4OjEwMHg6MDANCnhjZm9mZGZlZiBmc2ZlMGcwbTJlYm5mdGUJZgkwPTAgMGINCmFjc29l ZCBlMCB4czBlLGcgbWxlaW5tdGkJdAkgPTAgeGJmYWZzZmVmIGYwLHggMHQseSBwbGVpIG0waXh0 MSBiMA0KeAlmCWYJZj1mIGZELFAgTHQgeTBwLGUgIHAwcnhlMXNiIA0KMQksCSAJbD1vIG5EZ1Ag TDEgLDAgLGQgZXBmcjNlMnMgIDAxLCwgIGdscm9hbm5nICAxMQ0KLHAgcmRvZWNmZTNzMnMgbzBy LCAgZWdmcmxhYW5nIHMxCQ0KPXAgcmlvbmN0ZWVzcnNyb3VycCB0ZSBmZWxuYWFnYnNsCWU9ZCAs aSBuSXRPZVByTHIgdT1wIHQwIA0KZWNudWFyYnJsZWVuZHQsICBwSXJPb1BjTGUgcz1zIAkwCQ0K PWMgdTZyMHIwZTFuMnQgIChwc3JobyljDQpldHNyc2EJcAkgPW4gdTZtMGIwZTByMQkgCSg9YyBj MTE5cGwNCnVzcClhbg0KaXRjcjphIHBuIG9ubnUtbW1iYWVzcmsJYQliPWwgZTEgOWluDQp0ZXJy dXB0IHRyYXANCmNwdWlkID0gMA0KVXB0aW1lOiAyMG0xMnMNClBoeXNpY2FsIG1lbW9yeTogMTAw OSBNQg0KRHVtcGluZyAxMjM1IE1COiAxMjIwIDEyMDQgMTE4OCAxMTcyIDExNTYgMTE0MCAxMTI0 IDExMDggMTA5MiAxMDc2IDEwNjAgMTA0NCAxMDI4IDEwMTIgOTk2IDk4MCA5NjQgOTQ4IDkzMiA5 MTYgOTAwIDg4NCA4NjggODUyIDgzNiA4MjAgODA0IDc4OCA3NzIgNzU2IDc0MCA3MjQgNzA4IDY5 MiA2NzYgNjYwIDY0NCA2MjggNjEyIDU5NiA1ODAgNTY0IDU0OCA1MzIgNTE2IDUwMCA0ODQgNDY4 IDQ1MiA0MzYgNDIwIDQwNCAzODggMzcyIDM1NiAzNDAgMzI0IDMwOCAyOTIgMjc2IDI2MCAyNDQg MjI4IDIxMiAxOTYgMTgwIDE2NCAxNDggMTMyIDExNiAxMDAgODQgNjggNTIgMzYgMjAgNA0KDQpS ZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbnRmcy5rby4uLlJlYWRpbmcgc3ltYm9s cyBmcm9tIC9ib290L2tlcm5lbC9udGZzLmtvLnN5bWJvbHMuLi5kb25lLg0KZG9uZS4NCkxvYWRl ZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbnRmcy5rbw0KUmVhZGluZyBzeW1ib2xzIGZyb20g L2Jvb3Qva2VybmVsL3dwaWZ3LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVs L3dwaWZ3LmtvLnN5bWJvbHMuLi5kb25lLg0KZG9uZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9v dC9rZXJuZWwvd3BpZncua28NClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9yYWRl b24ua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvcmFkZW9uLmtvLnN5bWJv bHMuLi5kb25lLg0KZG9uZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvcmFkZW9u LmtvDQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZHJtLmtvLi4uUmVhZGluZyBz eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2RybS5rby5zeW1ib2xzLi4uZG9uZS4NCmRvbmUuDQpM b2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2RybS5rbw0KIzAgIGRvYWR1bXAgKCkgYXQg cGNwdS5oOjE5NQ0KMTk1CXBjcHUuaDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeS4NCglpbiBw Y3B1LmgNCihrZ2RiKSBidA0KIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5NQ0KIzEgIDB4MDAw MDAwMDAwMDAwMDAwNCBpbiA/PyAoKQ0KIzIgIDB4ZmZmZmZmZmY4MDU2ZGQ1OSBpbiBib290ICho b3d0bz0yNjApDQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQxOA0K IzMgIDB4ZmZmZmZmZmY4MDU2ZTE2MiBpbiBwYW5pYyAoZm10PTB4MTA0IDxBZGRyZXNzIDB4MTA0 IG91dCBvZiBib3VuZHM+KQ0KICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24u Yzo1NzQNCiM0ICAweGZmZmZmZmZmODA4MzFmMzMgaW4gdHJhcF9mYXRhbCAoZnJhbWU9MHhmZmZm ZmYwMDFhNGM5YWUwLCBldmE9VmFyaWFibGUgImV2YSIgaXMgbm90IGF2YWlsYWJsZS4NCikNCiAg ICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQvdHJhcC5jOjc3Nw0KIzUgIDB4ZmZmZmZmZmY4 MDgzMmI3YiBpbiB0cmFwIChmcmFtZT0weGZmZmZmZmZmODBjMGMyNTApDQogICAgYXQgL3Vzci9z cmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo1NzgNCiM2ICAweGZmZmZmZmZmODA4MWJiY2YgaW4g bm1pX2NhbGx0cmFwICgpDQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlv bi5TOjQ1MQ0KIzcgIDB4ZmZmZmZmZmY4MDgyYmQzNyBpbiBwbWFwX3JlbW92ZV9wYWdlcyAocG1h cD0weGZmZmZmZjAwMWExNzE3OTgpDQogICAgYXQgdm1fcGFnZS5oOjI2Ng0KUHJldmlvdXMgZnJh bWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pDQo= --0016e64cc3bc78672a0482da8647-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 11:30:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16D841065670; Sun, 28 Mar 2010 11:30:35 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB498FC08; Sun, 28 Mar 2010 11:30:33 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100328112001.DPGD8828.viefep15-int.chello.at@edge04.upcmail.net>; Sun, 28 Mar 2010 13:20:01 +0200 Received: from pinky ([212.83.93.41]) by edge04.upcmail.net with edge id ybKy1d02a0tYspQ04bKzYX; Sun, 28 Mar 2010 13:20:01 +0200 X-SourceIP: 212.83.93.41 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Giulio Ferro" , "Chuck Swiger" References: <4BAC879A.2040301@zirakzigil.org> <4931283F-5B5B-4368-BB40-20B5FEBF4E17@mac.com> Date: Sun, 28 Mar 2010 13:19:59 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4931283F-5B5B-4368-BB40-20B5FEBF4E17@mac.com> User-Agent: Opera Mail/10.51 (Win32) X-Cloudmark-Analysis: v=1.1 cv=6UHAxsHwKCW0savQ7OVzrMBW5xvCzGO/qK2+m6qSwq4= c=1 sm=0 a=-e8MBd7zOhoA:10 a=kj9zAlcOel0A:10 a=n-kJSqksAAAA:8 a=lUbXG0buiymqHcHedUYA:9 a=Om1vfgKt87qTD6KXlAZmlubsl5sA:4 a=CjuIK1q_8ugA:10 a=98jSFH7WqmUA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Subject: Re: NFS lockd problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 11:30:35 -0000 On Sat, 27 Mar 2010 20:50:17 +0200, Chuck Swiger wrote: > On Mar 26, 2010, at 3:08 AM, Giulio Ferro wrote: >> Outset: >> 1 NFS server (with lockd) >> 2 NFS client (with lockd) >> >> The clients serve several jails with apache, whose data (www) resides >> on the server > > If you need file locking to work reliably, you pretty much have to give > up on using NFS + rpc.lockd and run against a local UFS filesystem. I don't have this experience. I use NFS locking between FreeBSD, Linux, NetApp and SUN stuff. Older versions of FreeBSD had some troubles, but more recent ones work very well. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 11:30:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04AEE106564A; Sun, 28 Mar 2010 11:30:40 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFD18FC13; Sun, 28 Mar 2010 11:30:38 +0000 (UTC) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100328112425.OFME17946.viefep12-int.chello.at@edge03.upcmail.net>; Sun, 28 Mar 2010 13:24:25 +0200 Received: from pinky ([212.83.93.41]) by edge03.upcmail.net with edge id ybQN1d06L0tYspQ03bQPFk; Sun, 28 Mar 2010 13:24:24 +0200 X-SourceIP: 212.83.93.41 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org, "Giulio Ferro" References: <4BAC879A.2040301@zirakzigil.org> Date: Sun, 28 Mar 2010 13:24:23 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4BAC879A.2040301@zirakzigil.org> User-Agent: Opera Mail/10.51 (Win32) X-Cloudmark-Analysis: v=1.1 cv=SLkC287PFWo6d7eSEiSBB9255DBOWQ3bwOwHXJiyZoo= c=1 sm=0 a=-e8MBd7zOhoA:10 a=kj9zAlcOel0A:10 a=l8ef2foaAAAA:8 a=mtW-92RVqkP2JGzkdr8A:9 a=DL6ePqbOOW1Upxrsm2MBjmT4gmsA:4 a=CjuIK1q_8ugA:10 a=0beJD6anORYA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Subject: Re: NFS lockd problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 11:30:40 -0000 On Fri, 26 Mar 2010 12:08:26 +0200, Giulio Ferro wrote: > Outset: > 1 NFS server (with lockd) > 2 NFS client (with lockd) > > The clients serve several jails with apache, whose data (www) resides on > the server > > From time to time everything seem to freeze. Then, after one minute or > so, the system > works again as nothing had happened. > > In these occasions I get this in the logs on the client madchines: > Mar 26 10:29:38 virt1 kernel: nfs server > 192.168.40.121:/data/mount_servers/wwwsec/www: lockd not responding > > followed shortly after by: > > Mar 26 10:29:38 virt1 kernel: nfs server > 192.168.40.121:/data/mount_servers/wwwsec/www: lockd is alive again > > > On the server I only get this: > Mar 26 10:29:31 data1 kernel: NLM: failed to contact remote rpcbind, > stat = 5, port = 28416 > > I don't think it's a network problem, since all connections are local > and high speed (1Gb/s) > > I must admit that, with the other nfs problem I reported weeks ago, this > kind of freebsd system seems > less than stable to me, and this is very disappointing... > > Anyway I'd appreciate any pointer on this issue... I'm no NFS expert, so I don't know if I can help, but regularly people want to know your FreeBSD version(s), your used NFS version, if you are running NFS over TCP or UDP. Does it help to switch between UDP/TCP? Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 13:58:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82D20106566B; Sun, 28 Mar 2010 13:58:18 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id E48CD8FC1A; Sun, 28 Mar 2010 13:58:17 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 7E69A22C50BC; Sun, 28 Mar 2010 16:38:38 +0300 (EEST) Date: Sun, 28 Mar 2010 16:38:28 +0300 From: Ion-Mihai Tetcu To: freebsd-ports@freebsd.org, questions@freebsd.org, stable@freebsd.org Message-ID: <20100328163828.1f34e0e7@it.buh.tecnik93.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/74Ra1.jJNXiFp.p8bx4alBN"; protocol="application/pgp-signature" Cc: Subject: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 13:58:18 -0000 --Sig_/74Ra1.jJNXiFp.p8bx4alBN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April.=20 The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. Before reporting failures, please take a look at ports@ list, and http://qat.tecnik93.com/index.php?action=3Dfailed_buildports&sort=3Dlast_bu= ilt to find out if the problem hasn't already been reported or even fixed. We also have two incremental builds on Pointy to catch the problems. Thank you, With hat: portmgr@ --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/74Ra1.jJNXiFp.p8bx4alBN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuvW94ACgkQJ7GIuiH/oeV2aQCgmY0PB4dxDhQk+dLEyZUeu7oB +T4AoLDd/1dOPcY3oY/k1rMSvwqZ6wXH =n99+ -----END PGP SIGNATURE----- --Sig_/74Ra1.jJNXiFp.p8bx4alBN-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 14:42:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C226B106564A; Sun, 28 Mar 2010 14:42:20 +0000 (UTC) (envelope-from masoom.shaikh@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 818FD8FC13; Sun, 28 Mar 2010 14:42:20 +0000 (UTC) Received: by pwj4 with SMTP id 4so7839516pwj.13 for ; Sun, 28 Mar 2010 07:42:20 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=Nmxd/t/qIc9Ik4ZBkwIHTWqHbRpQR29IEtMEt46joxg=; b=awQl/Ijs4Qn9DH/PXD05jQ6Gx/epkjSAtpZ7Nu9ToUSx+bOcylil4Wj0WS68XEpGeH erc60nZ4bSM+KqC8otwT9nUx250BPXc8mW8ztgEqzk184j6lPHrdk8JQF8tf9tzSHcTS 42qiFMJJX6r9OQ8s22PHC8TrIX8ramT/AW+2E= 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=BYn3Lal9Ao/42NIWCsPdP0a2O3W3M2Cj1paVJsjRLXJKmkBbA42RvYysFQ93CUfjd2 8oIGEgo7Azd7jnuSS/6ge4nf/XoSHGXzJaGSsAZYOrPWacgpkdWd2W+LkqD66MDyaBeX NlsnQv5O3Z5PE63AmClVskwxPVbj/8VXUip9A= MIME-Version: 1.0 Received: by 10.114.191.6 with HTTP; Sun, 28 Mar 2010 07:42:19 -0700 (PDT) In-Reply-To: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> Date: Sun, 28 Mar 2010 14:42:19 +0000 Received: by 10.115.39.40 with SMTP id r40mr1793803waj.183.1269787339978; Sun, 28 Mar 2010 07:42:19 -0700 (PDT) Message-ID: From: Masoom Shaikh To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 14:42:20 -0000 On Sun, Mar 28, 2010 at 12:03 PM, Ivan Voras wrote: > On 28 March 2010 13:18, Masoom Shaikh wrote: >> On Sun, Mar 28, 2010 at 10:32 AM, Ivan Voras wrote: >>> Masoom Shaikh wrote: >>>> >>>> Hello List, >>>> >>>> I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since >>>> then, system randomly just freezes, and there is no option other than hard >>>> boot. I guessed this will get solved in 8.0-RELEASE, but it was not :( >>> >>> I wild shot - did you try disabling superpages? >> >> umm, how do I do that ? > > Set > > vm.pmap.pg_ps_enabled=0 > > in /boot/loader.conf and reboot. Report back if it helps or not. > nopes, this didn't help too, machine freezed again after using for 30 minutes or so all it was doing is playing amarok, fetching sources from svn repos, and using firefox lets assume if this is h/w problem, then how can other OSes overcome this ? is there a way to make FreeBSD ignore this as well, let it result in reasonable performance penalty. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 16:39:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AF56106566C for ; Sun, 28 Mar 2010 16:39:31 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from backup.socket.ch (secure.socket.ch [91.199.228.84]) by mx1.freebsd.org (Postfix) with ESMTP id 65BD98FC0A for ; Sun, 28 Mar 2010 16:39:30 +0000 (UTC) Received: from adsl-84-226-148-116.adslplus.ch ([84.226.148.116] helo=spore.fsck.ch) by backup.socket.ch with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nvuqp-0006wE-Qy for freebsd-stable@freebsd.org; Sun, 28 Mar 2010 17:56:37 +0200 Message-ID: <4BAF7C32.8020905@fsck.ch> Date: Sun, 28 Mar 2010 17:56:34 +0200 From: Tobias Roth User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> In-Reply-To: <20100328163828.1f34e0e7@it.buh.tecnik93.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "backup.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: > Hi, > > > As announced before, a few big commits, that touch some thousands ports > are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 > April. > > The first one was done, update of graphics/png (including a shared lib > version bump), with about 5000 ports affected. > > We do _NOT_ recommend updating ports until this commits are all done, > and the problems are fixed, except if you want to help testing / fixing. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 84.226.148.116 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on backup.socket.ch); SAEximRunCond expanded to false Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 16:39:31 -0000 On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: > Hi, > > > As announced before, a few big commits, that touch some thousands ports > are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 > April. > > The first one was done, update of graphics/png (including a shared lib > version bump), with about 5000 ports affected. > > We do _NOT_ recommend updating ports until this commits are all done, > and the problems are fixed, except if you want to help testing / fixing. What does that mean, the first one was done? The port was updated before this warning? I have updated png this morning, will I now be negatively affected? Thanks, Tobias From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 17:34:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B836C106566B; Sun, 28 Mar 2010 17:34:03 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3948FC16; Sun, 28 Mar 2010 17:34:02 +0000 (UTC) Received: by qyk38 with SMTP id 38so3378867qyk.9 for ; Sun, 28 Mar 2010 10:34:02 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=ETkUSyIePGIa0TxOmJFxhaxSNd+HD9btq2prVRzdLpE=; b=NE9T0fEicGvaI8+peSoViaOgHsgbejV9DaqDctwZUkksmZXO2S4/5E/Ac9+qgG9t2G EcDcnDr1EBBEsigY+Iu8EV/XvlZSWLtSyMyIx79mOS/ZOXim6EG0X7GrOY9kKp+d2yG/ kXtS0RQ/ifxSZIdOqPcN9AAI9JNXlTW2obLpk= 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=e7A++bRAJYnCq5PwQji2NBBZxmTdK358b5SkKBJV5IBOfjaKp3q1Bz8fqPpe7U1idc pi3a1aPiIbWX3Y8EF5edcj4ydaP2S+WimhNHe16zo0pHjKAAB45dsf40wPwK4RXqvYpK 1X3fSPcVCivb0iTM6yHBpVMcSAktJGtBIJ4ak= MIME-Version: 1.0 Received: by 10.229.82.14 with HTTP; Sun, 28 Mar 2010 10:34:02 -0700 (PDT) In-Reply-To: References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> Date: Sun, 28 Mar 2010 11:34:02 -0600 Received: by 10.229.130.206 with SMTP id u14mr104624qcs.74.1269797642207; Sun, 28 Mar 2010 10:34:02 -0700 (PDT) Message-ID: <6201873e1003281034s52636444h113cc8760a007490@mail.gmail.com> From: Adam Vande More To: Masoom Shaikh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras , freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:34:03 -0000 On Sun, Mar 28, 2010 at 8:42 AM, Masoom Shaikh wrote: > nopes, this didn't help too, machine freezed again after using for 30 > minutes or so > all it was doing is playing amarok, fetching sources from svn repos, > and using firefox > > lets assume if this is h/w problem, then how can other OSes overcome > this ? is there a way to make FreeBSD ignore this as well, let it > result in reasonable performance penalty. > They would remove or replace the bad hardware. I've seen more that one DIMM which passed every memory checker I could find in it's most extensive testing mode. Only consistently effective option is to replace with a known good piece of memory. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 17:39:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5399A106566B; Sun, 28 Mar 2010 17:39:20 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 500F18FC08; Sun, 28 Mar 2010 17:39:18 +0000 (UTC) Received: by wyb33 with SMTP id 33so4857595wyb.13 for ; Sun, 28 Mar 2010 10:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=fQ54Xo/fc+UNlJbe/en92S7lyeW7M3gooHqpvuqMBrE=; b=E2pP1eEg/Mle9jTgjbQVWjGLVaa4DluUmMY90O4+D+WpUA32jnVQNFYXm03PRREJpL u06VCZfABCDD8dWPr+lKFU9D7aHlXES94nkm0a03gDrdJX3zTkfTkrEqq3E3qaKsrg4T RG+HyPIo9QgoIL4j6Wbtps1i8de4HLKHh8Jeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=v1nUYwxiO7H9j0/A82Fc0AwGE/Cse/8LUsdEtqV0fjR1ZWQ65gd9+lWRwEavgS/r44 /PwWhIF8sbJ3xDXc0TYMjS0C2aUeIjKAlsn0Yr3eYFZ1uol7tttSGp3i7XJCxO/ps4hm mMMNKCPtdMd1wDYfx+O2aXqw4DE+DTi7VQzNw= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.90.139 with HTTP; Sun, 28 Mar 2010 10:38:58 -0700 (PDT) In-Reply-To: References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> From: Ivan Voras Date: Sun, 28 Mar 2010 19:38:58 +0200 X-Google-Sender-Auth: 0b66a2c1006f0b82 Received: by 10.216.91.16 with SMTP id g16mr2418562wef.102.1269797958118; Sun, 28 Mar 2010 10:39:18 -0700 (PDT) Message-ID: <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> To: Masoom Shaikh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:39:20 -0000 On 28 March 2010 16:42, Masoom Shaikh wrote: > lets assume if this is h/w problem, then how can other OSes overcome > this ? is there a way to make FreeBSD ignore this as well, let it > result in reasonable performance penalty. Very probably, if only we could detect where the problem is. Try adding "options PRINTF_BUFR_SIZE=128" to the kernel configuration file if you can, to see if you can get a less mangled log outout. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 17:43:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 319DC10656AA for ; Sun, 28 Mar 2010 17:43:18 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9A98FC14 for ; Sun, 28 Mar 2010 17:43:17 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 18DB322C50C1; Sun, 28 Mar 2010 20:27:53 +0300 (EEST) Date: Sun, 28 Mar 2010 20:27:52 +0300 From: Ion-Mihai Tetcu To: Tobias Roth Message-ID: <20100328202752.0a991679@it.buh.tecnik93.com> In-Reply-To: <4BAF7C32.8020905@fsck.ch> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAF7C32.8020905@fsck.ch> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/8JF1pfum5BFDjIVov.WkTym"; protocol="application/pgp-signature" Cc: freebsd-stable@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:43:18 -0000 --Sig_/8JF1pfum5BFDjIVov.WkTym Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 28 Mar 2010 17:56:34 +0200 Tobias Roth wrote: > On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: > > Hi, > >=20 > >=20 > > As announced before, a few big commits, that touch some thousands > > ports are being done: png, curl, x11, gnome, kde4. The target ETA > > is 6-7 April.=20 > >=20 > > The first one was done, update of graphics/png (including a shared > > lib version bump), with about 5000 ports affected. > >=20 > > We do _NOT_ recommend updating ports until this commits are all > > done, and the problems are fixed, except if you want to help > > testing / fixing. >=20 >=20 > What does that mean, the first one was done? The port was updated > before this warning? >=20 > I have updated png this morning, will I now be negatively affected? PNG update was committed this morning at 06:47:48 UTC. If you have updated png (not just csup your ports tree) then you'll probably have to update the rest of your ports, since they won't find the old png shared lib. (you could try to map the new lib to the old one, it might or not work) --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/8JF1pfum5BFDjIVov.WkTym Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuvkZgACgkQJ7GIuiH/oeV3rACfVhPHcRBjm1MhawijJd0CGue9 FxwAn1xyhj5GJSkVC7he3dXtTkKL13y/ =F0tT -----END PGP SIGNATURE----- --Sig_/8JF1pfum5BFDjIVov.WkTym-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 19:20:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B5410656C1 for ; Sun, 28 Mar 2010 19:20:39 +0000 (UTC) (envelope-from jamesoff@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 118B78FC1D for ; Sun, 28 Mar 2010 19:20:37 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so628771fgb.13 for ; Sun, 28 Mar 2010 12:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=FsCEIrjjrjI8kxBoxrnLZ7Y3TbYjeSMif94wULPWga8=; b=Qi+seI9d8HR95lHt+cmaK+7W7cnUeE7KxCTQV1QjHfL95MxivIt8xqT1TOGzinbiss +rP0RhItzfK0ZLR5RNyI7tfjl/N/75qGDdD72Udp+1gSLReCQbQiVwmD1nOmpyPDfjX6 4fggDM4hIFrFBa+5sDwkUhb2H9TNZ2W3fxlFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=uXi+yPpikWTZUaUELv514BQXOso8RjCWLh9NY4C2++mDDBVUFJ/Oq8pssKy76VO4t8 OBHv+QdjfLEi+V+ro0HzG88OTCha7DOA0pu4TP6II74FG87mDYRhRRk2COdzuCVrHHQG RwP6gt32ZLsZUXoomyN+9YMzstRM/hMEdfxRY= MIME-Version: 1.0 Received: by 10.239.153.139 with HTTP; Sun, 28 Mar 2010 11:58:02 -0700 (PDT) From: James Seward Date: Sun, 28 Mar 2010 19:58:02 +0100 Received: by 10.239.188.148 with SMTP id p20mr342322hbh.7.1269802702113; Sun, 28 Mar 2010 11:58:22 -0700 (PDT) Message-ID: <720051dc1003281158l7b7cab97xa41606ac23087ddc@mail.gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: USB UPS detached and cannot reattach ("could not allocate new device") X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 19:20:39 -0000 Hello, On my 8.0-RELEASE machine running GENERIC this happened this afternoon: Mar 28 17:48:13 yomi apcupsd[969]: UPS Self Test switch to battery. Mar 28 17:48:17 yomi kernel: ugen0.2: at usbus0 (disconnected) Mar 28 17:48:18 yomi kernel: usb_alloc_device:1586: set address 2 failed (USB_ERR_STALLED, ignored) Mar 28 17:48:18 yomi kernel: usb_alloc_device:1624: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:19 yomi kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_STALLED, ignored) Mar 28 17:48:19 yomi kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:20 yomi kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_STALLED, ignored) Mar 28 17:48:20 yomi kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_STALLED! Mar 28 17:48:20 yomi kernel: ugen0.2: <(null)> at usbus0 (disconnected) Mar 28 17:48:20 yomi kernel: uhub_reattach_port:435: could not allocate new device! Mar 28 17:48:27 yomi apcupsd[969]: Communications with UPS lost. Unplugging the UPS and replugging it doesn't seem to help, even in a different port. My UPS is a Smart-UPS 750 and my apcupsd is "3.14.5 (10 January 2009) freebsd". ugen0.1: at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON dev.usbus.0.%desc: VIA 83C572 USB controller dev.usbus.1.%desc: VIA 83C572 USB controller I'm happy to provide more info if someone sufficiently clueful can tell me where to look :) Thanks, James From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 19:42:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409CB1065689 for ; Sun, 28 Mar 2010 19:42:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 20BAB8FC1B for ; Sun, 28 Mar 2010 19:42:03 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta06.emeryville.ca.mail.comcast.net with comcast id yen01d0020S2fkCA6ji4mK; Sun, 28 Mar 2010 19:42:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta09.emeryville.ca.mail.comcast.net with comcast id yji31d00B3S48mS8Vji30i; Sun, 28 Mar 2010 19:42:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D1279B436; Sun, 28 Mar 2010 12:42:02 -0700 (PDT) Date: Sun, 28 Mar 2010 12:42:02 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100328194202.GA76443@icarus.home.lan> References: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 19:42:04 -0000 On Sun, Mar 28, 2010 at 12:16:27AM -0700, John Long wrote: > At 05:42 PM 3/27/2010, Jeremy Chadwick wrote: > > put this in > # Intel Core/Core2Duo CPU temperature monitoring driver > device coretemp coretemp(4) will get you the temperatures of each processor core, provided via the dev.cpu.X.temperature sysctls. > %smbmsg -p > Probing for devices on /dev/smb0: > Device @0x10: w > > Does not look to be much there if I am doing this right.. smbmsg -p won't help here -- I've never seen it detect H/W ICs that sit on SMBus. In fact, on all my systems, it doesn't report anything exists on the slave address tied to the boards' Winbond chips. I have no idea what "probe modus" means (see smbmsg(8) man page) nor how the probe actually works behind the scenes. So, it's an ineffective way to get an answer to your dilemma. It would make more sense to run SpeedFan on Windows, see if it's able to find a chip via SMBus, and provide those details. Another alternative would be to try using lm-sensors on Linux, although I'm pretty sure lm-sensors prefers LPC/ISA mode (claiming "it's more stable and more reliable" -- whatever). I have no experience with this software, aside from occasionally having to dig through their spaghetti code to try and find details about chip quirks. > >There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which > >does do probing and can/does support SMBus. I have no idea if it works > >on Windows 7 or not: > > > >http://www.almico.com/speedfan.php > > > >If SpeedFan shows you all the data you expect/want, and indicates it's > >talking to a H/W IC over SMBus, then I could add support for your board > >to bsdhwmon (since your motherboard does provide acceptable SMBIOS > >tables for identification). I'd still need to know what slave address > >the chip had, and what exact model of H/W IC it was. SpeedFan might > >provide that. > > I have a feeling that my smbus is just not hooked up, nothing > there.. speedfan looks cool tho. I don't know what you mean by "my smbus is just not hooked up". Your above 'device' additions to your kernel shows that FreeBSD is now able to talk to the SMBus interface on your northbridge. As stated, smbmsg isn't going to help determine what H/W IC is on your board (if any). I'll see if I can find a very high resolution photo of your motherboard and try to work out if any ASICs are used for H/W monitoring (these days such chips also often provide Super I/O support (floppy, LPT, COM, LPC/ISA, etc.)). I'll probably have to review the user manual. I'll report back once I do that. > >It would also help (me at least) if you could reboot your system, go > >into your BIOS and find whatever menu item is associated with Hardware > >Monitoring and write down all of the shown attributes and their values. > >What the BIOS shows is what should be accurate above all else. > > >I can point you to numerous present-day motherboards that work just fine > >with cpufreq(4) and est under RELENG_8, and also work when using > >acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 > >boards. I'm sure there are many others. In all of these are Core2Duo > >or Core2Quad CPUs. An example from the X7SBA system, running powerd: > > It looks good, all working.. Okay, but that doesn't help me any. :-) Can you please write down all the H/W monitoring attributes + values shown in the BIOS and provide them here? > >I should note that the device attachment error (error 6) is something > >I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced > >Mode were disabled in the BIOS. FreeBSD would report that SpeedStep > >existed but that it wasn't able to attach. > > > >I *explicitly* disabled those features in the BIOS since I saw some > >bizarre process behaviour ("calcru: runtime went backwards ... for pid > >X"). > > Have you tried to measure the wall power with a kill-a-watt yet or > can you? I have a couple Kill-a-Watt devices, but I tend to not bother with them for tests of this nature since they don't provide enough granularity on the LCD (only 1 or 2 digits past the decimal point). I also find them to be finicky/unreliable -- for example, I hooked a residential home toaster up to a RackPDU (which provides amps and watts used via web + SNMP). Powering on the toaster showed an increase from 0.00 amps to 1.1 amps. Hooking the same toaster up to 2 separate Kill-a-Watt units returned the same result: 0.4 amps. I performed the same tests with a standard household fan (3-speed), and I saw similar readings (the Kill-a-Watt always appearing off by a pretty large amount). WRT all the systems I've applied cpufreq(4) + est + powerd to: they're all production. I'm not willing to power them down, go to the co-lo, hook up a Kill-a-Watt device, power them on, wait around for 30 minutes, etc.. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 21:14:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E171065672 for ; Sun, 28 Mar 2010 21:14:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 07B478FC0C for ; Sun, 28 Mar 2010 21:14:00 +0000 (UTC) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id ykuU1d0051HzFnQ59lE1o4; Sun, 28 Mar 2010 21:14:01 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta14.westchester.pa.mail.comcast.net with comcast id ylDz1d00B3S48mS3alE06q; Sun, 28 Mar 2010 21:14:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 45A969B436; Sun, 28 Mar 2010 14:13:58 -0700 (PDT) Date: Sun, 28 Mar 2010 14:13:58 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100328211358.GA79019@icarus.home.lan> References: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> <20100328194202.GA76443@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100328194202.GA76443@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith Subject: Re: Powerd and est / eist functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 21:14:01 -0000 On Sun, Mar 28, 2010 at 12:42:02PM -0700, Jeremy Chadwick wrote: > I'll see if I can find a very high resolution photo of your motherboard > and try to work out if any ASICs are used for H/W monitoring (these days > such chips also often provide Super I/O support (floppy, LPT, COM, > LPC/ISA, etc.)). I'll probably have to review the user manual. > > I'll report back once I do that. Success -- the Gigabyte GA-G41M-ES2L board uses an ITE IT8718 Super I/O chip, which also drives H/W monitoring support. Verified both visually and in the user manual. The official datasheets for the IT8718 are here: http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=5,68 Regardless of chip subrevision (J vs. K), neither supports SMBus; the chips appear to be entirely LPC/ISA-based. mbmon could be extended/enhanced to support this chip (mbmon -I would be required), but you'd still need to know what I/O ports are that Gigabyte tie to the chip. That's where Linux lm-sensors comes into play. Based on some Google results, the base I/O port is probably 0x290 (I'm assuming 0x290 = read, 0x291 = write) -- but I'm basing that on some ambiguous output here: http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025222.html http://www.lm-sensors.org/wiki/Configurations/Gigabyte There's also this, which is pretty disheartening: http://lists.lm-sensors.org/pipermail/lm-sensors/2006-August/017423.html "The IT8718F also features VID inputs (up to 8 pins) but the value is stored in the Super-I/O configuration space. Due to technical limitations, this value can currently only be read once at initialization time, so the driver won't notice and report changes in the VID value. The two upper VID bits share their pins with voltage inputs (in5 and in6) so you can't have both on a given board." If someone feels like contacting the mbmon author to get this added, be my guest. Or if someone feels like adding it to mbmon, that's cool too. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 01:17:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4DD106568C for ; Mon, 29 Mar 2010 01:17:03 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 7B04A8FC0C for ; Mon, 29 Mar 2010 01:17:03 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:56644) by fish.ish.com.au with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Nw3PT-0002ym-2y; Mon, 29 Mar 2010 12:04:55 +1100 Message-ID: <4BAFFCB7.6080501@ish.com.au> Date: Mon, 29 Mar 2010 12:04:55 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Ion-Mihai Tetcu References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> In-Reply-To: <20100328163828.1f34e0e7@it.buh.tecnik93.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 01:17:03 -0000 On 29/03/10 12:38 AM, Ion-Mihai Tetcu wrote: > The first one was done, update of graphics/png (including a shared lib > version bump), with about 5000 ports affected. The UPDATING entry for the png update looks very wrong. Wrong date, wrong text, wrong instructions for portmaster. 20090328: AFFECTS: users of graphics/png AUTHOR: dinoex@FreeBSD.org The png library has been updated to version 1.4.1. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r jpeg- If you use portupgrade: portupgrade -fr graphics/jpeg -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 02:15:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987A61065673; Mon, 29 Mar 2010 02:15:07 +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 507A58FC0C; Mon, 29 Mar 2010 02:15:07 +0000 (UTC) Received: by pwj4 with SMTP id 4so8063692pwj.13 for ; Sun, 28 Mar 2010 19:15:06 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E6kyuuXTwx5xWIaixydFmxAsRzYitOknSTG5TbfVIsw=; b=P+GpZgRs7L2ZDgQ7KRTeIVwLNeMmcDSUtYbfeqNBgot7QRTA5Bh7prsh4Ovc3ZU1WS iMSeR4qUErajO5MIUc79L8xM3LWuFs7Rh9vAenbyumptZrYp8BMZwgN7w346F9LqpSGl 9HjplQKYyNwZnmEHjZK/gDEaoT92tsJhfT7ys= 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=djMNnhRwIyw0JbZqkuNgR/a9vFirM52wMogOopzlgAlwEm8Z5z5GDbL60c7MT/K4/3 Hkme1oka3+70Lk+cNBMtKoumBwM7BF2gsBsLMyCpceyT4TrUV6j8FbkacdTalt+03qfk +wBE/5emPTPORwlvU5i7AGG9drVpV4gcP9028= MIME-Version: 1.0 Received: by 10.143.8.14 with HTTP; Sun, 28 Mar 2010 19:15:06 -0700 (PDT) In-Reply-To: <4BAFFCB7.6080501@ish.com.au> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> Date: Sun, 28 Mar 2010 19:15:06 -0700 Received: by 10.142.55.18 with SMTP id d18mr1763630wfa.170.1269828906472; Sun, 28 Mar 2010 19:15:06 -0700 (PDT) Message-ID: <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> From: Garrett Cooper To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 02:15:07 -0000 On Sun, Mar 28, 2010 at 6:04 PM, Aristedes Maniatis wrote: > On 29/03/10 12:38 AM, Ion-Mihai Tetcu wrote: >> >> The first one was done, update of graphics/png (including a shared lib >> version bump), with about 5000 ports affected. > > The UPDATING entry for the png update looks very wrong. Wrong date, wrong > text, wrong instructions for portmaster. > > > > 20090328: > =A0AFFECTS: users of graphics/png > =A0AUTHOR: dinoex@FreeBSD.org > > =A0The png library has been updated to version 1.4.1. =A0Please rebuild a= ll > =A0ports that depend on it. > > =A0If you use portmaster: > > =A0 =A0 =A0 =A0portmaster -r jpeg- > > =A0If you use portupgrade: > > =A0 =A0 =A0 =A0portupgrade -fr graphics/jpeg The text has been updated: 20100328: AFFECTS: users of graphics/png AUTHOR: dinoex@FreeBSD.org The png library has been updated to version 1.4.1. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r png- If you use portupgrade: portupgrade -fr graphics/png Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 02:17:18 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 843DA106567D for ; Mon, 29 Mar 2010 02:17:18 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE428FC26 for ; Mon, 29 Mar 2010 02:17:16 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:57350) by fish.ish.com.au with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Nw4XR-0005EB-1A; Mon, 29 Mar 2010 13:17:13 +1100 Message-ID: <4BB00DA9.3070105@ish.com.au> Date: Mon, 29 Mar 2010 13:17:13 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Garrett Cooper References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> In-Reply-To: <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 02:17:18 -0000 On 29/03/10 1:15 PM, Garrett Cooper wrote: > portmaster -r png- Is that correct? I haven't seen that notation before (although I might just have missed it in the docs). I would have used portmaster -r graphics/png Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 02:34:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77621106564A; Mon, 29 Mar 2010 02:34:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 026F98FC13; Mon, 29 Mar 2010 02:34:32 +0000 (UTC) Received: by pzk35 with SMTP id 35so192788pzk.3 for ; Sun, 28 Mar 2010 19:34:32 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PSH8KxmaVFbMZC92Ezueqs4sRhvC67DK8T22iNzyyF0=; b=mSGOrKa8CoBaYx8tA1AnrHVKERECxvkjjWz/7JH8sW3DzC4bnWVVWNqIErR76sScGH dOcUO1xDvFw/wpAmxSS1V0r8Gz+kbCnkMIzU00Z6p6LK8QW/Ct7xGs/TDFAVEcHgXCZG 1JkO2/lpMfkxqZlAxIit87N9gmlODiM3EjTj8= 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=bUIArS0+A4wgAP+aDNP5qaSGGA7FqbVks3dcEf1FZ3ZDvRLIRVwi5oyF4Oxc78mn9f kYySsLoT+rsTs2rqzEaORZE7HkdGqJclTZv313JOs3OmhVdMb0PxOS9gq5YMBjMj2lpt lPfxjeqjB8nlM4XNQrOYR+qfNQ/h7gGrDtVWk= MIME-Version: 1.0 Received: by 10.143.8.14 with HTTP; Sun, 28 Mar 2010 19:34:32 -0700 (PDT) In-Reply-To: <4BB00DA9.3070105@ish.com.au> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> Date: Sun, 28 Mar 2010 19:34:32 -0700 Received: by 10.143.154.21 with SMTP id g21mr1674884wfo.150.1269830072401; Sun, 28 Mar 2010 19:34:32 -0700 (PDT) Message-ID: <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> From: Garrett Cooper To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 02:34:33 -0000 On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis wrote: > On 29/03/10 1:15 PM, Garrett Cooper wrote: >> >> portmaster -r png- > > Is that correct? I haven't seen that notation before (although I might ju= st > have missed it in the docs). > > I would have used > > =A0portmaster -r graphics/png And yes, the directions are still wrong; it should be: portmaster -r 'png-*' Similarly since this was just a copy-paste of the jpeg instructions, those ones are wrong as well. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 07:54:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAAA6106564A; Mon, 29 Mar 2010 07:54:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 968E08FC24; Mon, 29 Mar 2010 07:54:17 +0000 (UTC) Received: by pvc7 with SMTP id 7so4620570pvc.13 for ; Mon, 29 Mar 2010 00:54:17 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JZUwrvZHmY1G9ZZukKVob51E2CnKOU2DZ2FIxhi5Hm4=; b=Un9btNPP4h0HbS4CIMHNFK7BR6Sigh+wRxoFzo+v5sCy6/p0zl1Hd+d39cxWIR8m8G 6iAvzZoq+fahGlDxGxzE7x4e8IJHKMRf6AsD9uOjrzK8uKr5OQSMkhK+1a5P/hqLFnDJ yKqHZQiR8posl8u94LjsERWJjI9iFgiI5964k= 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=Eq0kXMI0l6OECFty1pQeCpd/vEnUISWuZNeviP3oJHYqs65RDZKN+lcinYAVVGakTv PrIPiJb64qgmD1M3dLPnU+N1LWt30GxgX0StFnHqs738KUAxoF8wtmwjp5ZIuzrdeVg4 TRY0UKaXtuyp5OQme6hpoXIZM/mNFyIBMm3po= MIME-Version: 1.0 Received: by 10.143.8.14 with HTTP; Mon, 29 Mar 2010 00:54:16 -0700 (PDT) In-Reply-To: References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> Date: Mon, 29 Mar 2010 00:54:16 -0700 Received: by 10.143.25.9 with SMTP id c9mr1847685wfj.45.1269849257090; Mon, 29 Mar 2010 00:54:17 -0700 (PDT) Message-ID: <7d6fde3d1003290054j15d88cdcx2c5ab54926e6f3f9@mail.gmail.com> From: Garrett Cooper To: Rene Ladan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 07:54:18 -0000 On Mon, Mar 29, 2010 at 12:52 AM, Rene Ladan wrote: > 2010/3/29 Garrett Cooper : >> On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis wro= te: >>> On 29/03/10 1:15 PM, Garrett Cooper wrote: >>>> >>>> portmaster -r png- >>> >>> Is that correct? I haven't seen that notation before (although I might = just >>> have missed it in the docs). >>> >>> I would have used >>> >>> =A0portmaster -r graphics/png >> >> =A0 =A0And yes, the directions are still wrong; it should be: >> >> portmaster -r 'png-*' >> >> =A0 =A0Similarly since this was just a copy-paste of the jpeg >> instructions, those ones are wrong as well. > > Given that the PORTREVISION of all dependent ports are bumped, a simple > 'portupgrade -a' or 'portmaster -a' should suffice. Or am I missing somet= hing? You're absolutely correct, but I think that these directions were written with the intent that they would be simple one-off directions for upgrading just graphics/png dependent libs. HTH, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 08:04:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B086106566B for ; Mon, 29 Mar 2010 08:04:32 +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 40D308FC24 for ; Mon, 29 Mar 2010 08:04:31 +0000 (UTC) Received: (qmail 29909 invoked by uid 399); 29 Mar 2010 08:04:31 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Mar 2010 08:04:31 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB05F0C.6090807@FreeBSD.org> Date: Mon, 29 Mar 2010 01:04:28 -0700 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: Garrett Cooper References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> In-Reply-To: <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:04:32 -0000 On 03/28/10 19:34, Garrett Cooper wrote: > On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis wrote: >> On 29/03/10 1:15 PM, Garrett Cooper wrote: >>> >>> portmaster -r png- >> >> Is that correct? I haven't seen that notation before (although I might just >> have missed it in the docs). >> >> I would have used >> >> portmaster -r graphics/png That won't work, the man page clearly says that it has to be a port directory or glob pattern from /var/db/pkg. The "glob pattern" bit of that was (unfortunately) broken up till version 2.20, which I just committed. > And yes, the directions are still wrong; it should be: > > portmaster -r 'png-*' The * at the end of that is not necessary. In fact, portmaster strips it off before creating the actual pattern to feed to find. The current version of the instructions are correct. The - at the end of png is not strictly necessary, but it will serve to disambiguate the port name if there exists a pngfoo-1.23. 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-stable@FreeBSD.ORG Mon Mar 29 08:17:55 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9117A1065677; Mon, 29 Mar 2010 08:17:55 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id EC8B68FC1B; Mon, 29 Mar 2010 08:17:54 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so736369fgb.13 for ; Mon, 29 Mar 2010 01:17:53 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nz3ETZqpzXNFroaliuDdCahuVpJx4M+0PBm9hY/bIVY=; b=A6T5DZlxQqrsdAfv8KjBf2Y0Yg/a+fb6YvVc7ESCd7zwRlkyH4mbnIBDucje4e1btP n5LSCTCEtnL5wzUemtnJ8rhBgJy5380EwCOqKolE6IpyvjB8BbHe2xFeUkzQhCW9g40U YJSMS02c0b1mkrLH55BdoE/MIWMqcq+JZJ3xw= 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=cYnPf/BRuwpRvPpsGSlOQGGidqsWfL39zR96AmYa63NHnuCNZWJh+IpYuCthw6lMX7 Z+Tw7te3OJoef0JTGf1ugxEYiCSLhlYDxvilX0ZEFslQ1Epb/J6AbLatDZzwbjK7re5X 26Si0Tp9YdD555voB4LpV6RkRgVzM5B+m2Wik= MIME-Version: 1.0 Received: by 10.239.167.14 with HTTP; Mon, 29 Mar 2010 00:52:29 -0700 (PDT) In-Reply-To: <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> Date: Mon, 29 Mar 2010 09:52:29 +0200 Received: by 10.239.147.11 with SMTP id y11mr442413hba.78.1269849149226; Mon, 29 Mar 2010 00:52:29 -0700 (PDT) Message-ID: From: Rene Ladan To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:17:55 -0000 2010/3/29 Garrett Cooper : > On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis wrot= e: >> On 29/03/10 1:15 PM, Garrett Cooper wrote: >>> >>> portmaster -r png- >> >> Is that correct? I haven't seen that notation before (although I might j= ust >> have missed it in the docs). >> >> I would have used >> >> =A0portmaster -r graphics/png > > =A0 =A0And yes, the directions are still wrong; it should be: > > portmaster -r 'png-*' > > =A0 =A0Similarly since this was just a copy-paste of the jpeg > instructions, those ones are wrong as well. Given that the PORTREVISION of all dependent ports are bumped, a simple 'portupgrade -a' or 'portmaster -a' should suffice. Or am I missing somethi= ng? Rene From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 08:41:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22921065672 for ; Mon, 29 Mar 2010 08:41:28 +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 300858FC1D for ; Mon, 29 Mar 2010 08:41:27 +0000 (UTC) Received: (qmail invoked by alias); 29 Mar 2010 08:14:47 -0000 Received: from g229209220.adsl.alicedsl.de (EHLO mandree.no-ip.org) [92.229.209.220] by mail.gmx.net (mp025) with SMTP; 29 Mar 2010 10:14:47 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19njVQNAnVnybEQyfgzCqdEyNOHtckiupo0xEDtq1 Ln+VBOlV1Di3vg Received: from merlin.emma.line.org (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id EEEF994345; Mon, 29 Mar 2010 10:14:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Thomas Krause" , freebsd-stable References: <4BAE2808.4010809@chef-ingenieur.de> Date: Mon, 29 Mar 2010 10:14:45 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Matthias Andree" Organization: Message-ID: In-Reply-To: <4BAE2808.4010809@chef-ingenieur.de> User-Agent: Opera Mail/10.10 (Linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: Subject: Re: freebsd-update 7.2->7.3 manul merging of all files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:41:29 -0000 Am 27.03.2010, 16:45 Uhr, schrieb Thomas Krause: > Hi, > I want to upgrade a 7.2-RELEASE-p4 to 7.3-RELEASE with the command > > # freebsd-update upgrade -r 7.3-RELEASE > > After fetching and patching I get > > Attempting to automatically merge changes in files... done. > > The following file could not be merged automatically: /boot/device.hints > Press Enter to edit this file in vi and resolve the conflicts > manually... > > this goes on with *every* file in the /etc directory. What's wrong here? I got this once when updating from a self-built foo-STABLE to a -RELEASE later, because the $FreeBSD: ... tags were all wrong (and it was a nightmare that affected some 200 files). Did you installed your prior 7.2 system from a RELENG_7_2 cvsup/csup checkout, or was it a binary install? What triggers the conflicts for you - are there files where you only need to change the $FreeBSD: ... line but no others? I'm wondering if the etcmerge stuff should just ignore conflicts on the $FreeBSD$ line. -- Matthias Andree From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 09:27:25 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE5F1065674 for ; Mon, 29 Mar 2010 09:27:25 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 66CAB8FC1F for ; Mon, 29 Mar 2010 09:27:25 +0000 (UTC) Received: from [10.29.62.2] (port=60254 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NwBFi-0001LN-0K; Mon, 29 Mar 2010 20:27:22 +1100 Message-ID: <4BB07278.7030600@ish.com.au> Date: Mon, 29 Mar 2010 20:27:20 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Doug Barton References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> In-Reply-To: <4BB05F0C.6090807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 09:27:26 -0000 On 29/03/10 7:04 PM, Doug Barton wrote: >>> portmaster -r graphics/png > That won't work, the man page clearly says that it has to be a port > directory or glob pattern from /var/db/pkg. The "glob pattern" bit of > that was (unfortunately) broken up till version 2.20, which I just > committed. I'm confused. The manual actually says: [-R] -r name/glob of port in /var/db/pkg When I try your suggestion I get this: # portmaster -r png- ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help And this doesn't work either: # portmaster -r graphics/png ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help So, as you say the pkg pattern is broken, but also 'port directory' doesn't work either unlike your suggestions above. It would be nice for both pkg and directory patterns to be more consistently available, but in the meantime readers of UPDATING are going to be confused. Ari Maniatis -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 09:53:49 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01ABB106566B; Mon, 29 Mar 2010 09:53:49 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B17CE8FC12; Mon, 29 Mar 2010 09:53:48 +0000 (UTC) Received: by pvc7 with SMTP id 7so4654595pvc.13 for ; Mon, 29 Mar 2010 02:53:48 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SqgQ1BikFz6pX2YBjPSf8DvyeZoIM2sKEnoyuP+xxh4=; b=DJQkM5rhtfKdODtcoOj7ZxcfYERQx0sW6vxDgcLhpFgkfAXNVhLEmiZVaN/7qYUo7w 347xkcfXENXKJX3ZsRXvG75+EyUTqE8kydMoN9XwQhrRHuWb5dF8bDQV5iD5kfV9CcCm hZ7EgelCiuMclLcD/4o77s2fjPzPP3Jul0PQM= 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=OReOuxD9wMj8RPFbXl8j1n4WS5Ax0CZI3a41wybr3wJmNlNYOY8Tdq01znDePB+gj7 GyvYSayUxurGDVE6qVgik2b0vSeZACFC4KWIoCqCnF92FEEVwNQK4cRLvoa7prcxTuDY 48gK4Gw1/l/dyWUPkDtV3whBVXsoD3r2SOLCY= MIME-Version: 1.0 Received: by 10.143.8.14 with HTTP; Mon, 29 Mar 2010 02:53:47 -0700 (PDT) In-Reply-To: <4BB07278.7030600@ish.com.au> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> <4BB07278.7030600@ish.com.au> Date: Mon, 29 Mar 2010 02:53:47 -0700 Received: by 10.143.137.1 with SMTP id p1mr1941289wfn.281.1269856428169; Mon, 29 Mar 2010 02:53:48 -0700 (PDT) Message-ID: <7d6fde3d1003290253n65902d29i39cdd30a2f991a46@mail.gmail.com> From: Garrett Cooper To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, Doug Barton , questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 09:53:49 -0000 On Mon, Mar 29, 2010 at 2:27 AM, Aristedes Maniatis wrote: > On 29/03/10 7:04 PM, Doug Barton wrote: >>>> >>>> =A0portmaster -r graphics/png >> >> That won't work, the man page clearly says that it has to be a port >> directory or glob pattern from /var/db/pkg. The "glob pattern" bit of >> that was (unfortunately) broken up till version 2.20, which I just >> committed. > > I'm confused. The manual actually says: > > =A0[-R] -r name/glob of port in /var/db/pkg > > > When I try your suggestion I get this: > > # portmaster -r png- > > =3D=3D=3D>>> No valid installed port, or port directory given > =3D=3D=3D>>> Try portmaster --help > > > And this doesn't work either: > > # portmaster -r graphics/png > > =3D=3D=3D>>> No valid installed port, or port directory given > =3D=3D=3D>>> Try portmaster --help > > > So, as you say the pkg pattern is broken, but also 'port directory' doesn= 't > work either unlike your suggestions above. It would be nice for both pkg = and > directory patterns to be more consistently available, but in the meantime > readers of UPDATING are going to be confused. Besides, when I read `glob' I don't think `regular expression'. A glob is a simplified extension of regular expressions, made available via fnmatch(3) and glob(3) ... The previous method I described works, and works well: portmaster -r 'png-*' Not sure why graphics/png doesn't work though; hrrm... Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 10:07:54 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5123A1065673; Mon, 29 Mar 2010 10:07:54 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id C402E8FC1F; Mon, 29 Mar 2010 10:07:53 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o2TA7q7u039463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2010 12:07:52 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4BB07BF7.6070602@omnilan.de> Date: Mon, 29 Mar 2010 12:07:51 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B8E1489.2070306@omnilan.de> <4B8E1B3D.306@FreeBSD.org> In-Reply-To: <4B8E1B3D.306@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26AD72712BB118B571B26734" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 10:07:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26AD72712BB118B571B26734 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 03.03.2010 09:18 (localtime): > Harald Schmalzbauer wrote: >> Alexander Motin schrieb am 23.02.2010 16:10 (localtime): >>> Harald Schmalzbauer wrote: >>>> I'm frequently getting my machine locked with ahcichX timeouts: >>>> ahcich2: Timeout on slot 0 >>>> ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr= >>>> 00000000 >>>> ahcich2: Timeout on slot 8 >>>> ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr= >>>> 00000000 >>>> ahcich2: Timeout on slot 8 >>>> ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr= >>>> 00000000 >>>> ... >>> Looking that is (Interrupt status) is zero and `rs =3D=3D cs | ss` (r= unning >>> command bitmasks in driver and hardware), controller doesn't report >>> command completion. Looking on TFD status 0xc0 with BUSY bit set, I >>> would suppose that either disk stuck in command processing for some >>> reason, or controller missed command completion status. >>> >>> Have you noticed 30 second (default ATA timeout) pause before timeout= >>> message printed? Just want to be sure that driver waited enough befor= e >>> give up. >>> >>>> This happens when backup over GbE overloads ZFS/HDD capabilities. >>>> I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locki= ng >>>> up almost immediately, but from it still happens. >>>> When I don't use ahci but ataahci (the old driver if I understand th= ings >>>> correct) I also see the ZFS burst write congestion, but this doesn't= >>>> lead to controller timeouts, thus blocking the machine. >>>> >>>> Sometimes the machine recovers from the disk lock, but most often I = have >>>> to reboot. >>> How it looks when it doesn't? Can you send me full log messages? >> Hello, this morning I had a stall, but the machine recovered after abo= ut >> one Minute. Here's what I got from the kernel: >> ahcich2: Timeout on slot 29 >> ahcich2: is 00000000 cs 00000003 ss e0000003 rs e0000003 tfd c0 serr >> 00000000 >> em1: watchdog timeout -- resetting >> em1: watchdog timeout -- resetting >> ahcich2: Timeout on slot 10 >> ahcich2: is 00000000 cs 00006000 ss 00007c00 rs 00007c00 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 18 >> ahcich2: is 00000000 cs 00040000 ss 00000000 rs 00040000 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 2 >> ahcich2: is 00000000 cs 00000004 ss 00000000 rs 00000004 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 2 >> ahcich2: is 00000000 cs 00000000 ss 0000000c rs 0000000c tfd 40 serr >> 00000000 >> >> Does this tell you something useful? >=20 > It doesn't. Looking on logged register content - commands are indeed > still running and no interrupts requested. Interesting to see em1 > watchdog timeout there. Aren't they related somehow? I have the drives now running in another server, ich7 chipset. Using UFS, the complete machine locks up for ~30 secs with disk load of=20 3.5MB/s. But I don't get any timeout messages and the machine always=20 recovered. Changing to the old ata driver solves the problem. Any chance to get this problem fixed? I couldn't see lockups on another=20 OS with NCQ in AHCI mode enabled. I'd ship such a disk to anyone who is=20 willing to debug. Thanks, -Harry --------------enig26AD72712BB118B571B26734 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuwe/gACgkQLDqVQ9VXb8jVJgCgslySg8t/r8/CTXmC+a8ETW+8 7m4AoNBouWumrT4qwXBsEBPbvFvNNW31 =mo2w -----END PGP SIGNATURE----- --------------enig26AD72712BB118B571B26734-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 10:30:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47324106564A for ; Mon, 29 Mar 2010 10:30:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 1A61A8FC17 for ; Mon, 29 Mar 2010 10:30:53 +0000 (UTC) Received: by pzk35 with SMTP id 35so371824pzk.3 for ; Mon, 29 Mar 2010 03:30:53 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=u06b0WqGVnf7j/Q3IprGUNpoamAkZiHZSOEFTBtNjWs=; b=CmHodh4NgNsTBmt/neYbWMOc2gU9KW7J73nMQQuY8x8GUfhR7itD67Jx3XTFOv6f2C RTeoqB2zXovGu3TvZcOEvaqVGWaufhzkCmHEu2mWZuoW7QiHT7+nMBYbpL0kdKtOXcHD RROPcGD3k/HZv5fv8jEgV41Y9lO3tP7U/dPg8= 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=EG+C7kGj0SsRhv82olojb2g+AYENxVOgxTHEJ6Bgy5g+BTdqKnjc1xAyS4saaqv3ZY RDeu+h58Gfcz+KldTa7peq8EUjg5d2WoIKRBFWceiwGhEK+dA66S/MrmuSc+O+pPVzu4 zeKV4zvPGTebcqrYolYlhyFPRSvQXOIRSQVt0= MIME-Version: 1.0 Received: by 10.143.8.14 with HTTP; Mon, 29 Mar 2010 03:30:53 -0700 (PDT) In-Reply-To: References: <4BAE2808.4010809@chef-ingenieur.de> Date: Mon, 29 Mar 2010 03:30:53 -0700 Received: by 10.142.55.18 with SMTP id d18mr1949151wfa.170.1269858653425; Mon, 29 Mar 2010 03:30:53 -0700 (PDT) Message-ID: <7d6fde3d1003290330v3a2dead4g45650f95409da345@mail.gmail.com> From: Garrett Cooper To: Matthias Andree Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: freebsd-update 7.2->7.3 manul merging of all files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 10:30:54 -0000 On Mon, Mar 29, 2010 at 1:14 AM, Matthias Andree wrote: > Am 27.03.2010, 16:45 Uhr, schrieb Thomas Krause: > >> Hi, >> I want to upgrade a 7.2-RELEASE-p4 to 7.3-RELEASE with the command >> >> # freebsd-update upgrade -r 7.3-RELEASE >> >> After fetching and patching I get >> >> Attempting to automatically merge changes in files... done. >> >> The following file could not be merged automatically: /boot/device.hints >> Press Enter to edit this file in vi and resolve the conflicts >> manually... >> >> this goes on with *every* file in the /etc directory. What's wrong here? > > I got this once when updating from a self-built foo-STABLE to a -RELEASE > later, because the $FreeBSD: ... tags were all wrong (and it was a nightmare > that affected some 200 files). > > Did you installed your prior 7.2 system from a RELENG_7_2 cvsup/csup > checkout, or was it a binary install? > > What triggers the conflicts for you - are there files where you only need to > change the $FreeBSD: ... line but no others? > > I'm wondering if the etcmerge stuff should just ignore conflicts on the > $FreeBSD$ line. Do you perhaps mean mergemaster? There is an option for that, but I'm not sure if it's fully functional (and quite frankly it's a pain in the ass doing a 8-STABLE -> 9-CURRENT upgrade... I can readily confirm that). I just took a peek at freebsd-update and it uses a completely different scheme from mergemaster though which doesn't take the $FreeBSD RCS lines into account. One of the joys I've discovered of installing $FreeBSD based files off CVS/SVN instead of RCS files tagged via csup // cvsup. HTH, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 10:58:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C19106566C for ; Mon, 29 Mar 2010 10:58:05 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 902678FC0A for ; Mon, 29 Mar 2010 10:58:04 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 28E6724562B; Mon, 29 Mar 2010 12:58:03 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 3.5436] X-CRM114-CacheID: sfid-20100329_12580_9FAA87A5 X-CRM114-Status: UNSURE (3.5436) This message is 'unsure'; please train it! Message-ID: <4BB087B7.3030602@fsn.hu> Date: Mon, 29 Mar 2010 12:57:59 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Michael Loftis References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> In-Reply-To: <886B21E1787F0003B89E34B6@[192.168.1.44]> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.094166, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Mar 29 12:58:03 2010 X-DSPAM-Confidence: 0.7601 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb087bb48929048718729 X-DSPAM-Factors: 27, X-Bogosity*Ham+tests=bogofilter, 0.00344, X-Bogosity*Ham, 0.00344, X-Spambayes-Classification*ham+0.00, 0.00399, X-Spambayes-Classification*0.00, 0.00399, X-Spambayes-Classification*ham, 0.00610, >, 0.00613, >, 0.00613, wrote, 0.00883, wrote, 0.00883, >+>, 0.00889, >+>, 0.00889, From*fsn.hu>, 0.99056, Return-Path*fsn.hu>, 0.99056, To*Michael, 0.01000, lock, 0.01000, I+guess, 0.01000, requests, 0.01000, solved, 0.01000, python, 0.01000, X-Stationery*0.4.10, 0.01000, guess, 0.01000, themselves, 0.01000, and+it, 0.01000, hardware, 0.01000, hardware, 0.01000, Message-ID*fsn.hu>, 0.01000, User-Agent*Mozilla/5.0+(X11, 0.01000 Cc: Mailing List FreeBSD Stable Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 10:58:06 -0000 Hi, Michael Loftis wrote: > > > --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy > wrote: > > <...> >> Both unbound and python accepts DNS requests, and it seems when 25% >> interrupt happens, only unbound is in *udp state, where it is 50%, both >> programs are in that state. > > Try turning of hardware TSO/checksum offload if it's availble on your > chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using > nfe chips right now, but w/ the TSO/CSUM on they lock up constantly > under high load. We're pretty sure it's mostly the nfe driver, or the > chips themselves, but have never ruled out some generic 8.x hardware > offload issues. Bingo, this solved the problem. The current uptime nears four days. Previously I couldn't go further than a day. The machine gets very light TCP load (and other machines which get work well), so I guess it's UDP RX or TX checksum related. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 11:25:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44BC4106566B for ; Mon, 29 Mar 2010 11:25:23 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 823218FC1A for ; Mon, 29 Mar 2010 11:25:22 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.3/8.14.3) with ESMTP id o2TB8NEU054758 for ; Mon, 29 Mar 2010 19:08:23 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4BB08A27.2000002@kuzbass.ru> Date: Mon, 29 Mar 2010 18:08:23 +0700 From: Eugene Grosbein User-Agent: Thunderbird 2.0.0.23 (X11/20090918) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: VirtualBox, RAW-disks and boot0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 11:25:23 -0000 Hi! I've built FreeBSD 8.0-STABLE "LiveUSB" image using nanobsd script, it works with real hardware. I'd like to test it with VirtualBox to avoid rebooting too often. So, I've installed virtualbox-ose 3.1.4 from ports and tested it: - it boots Windows XP guest installed to VDI-disk just fine; - it boots FreeBSD "LiveCD" I've built as ISO image fine too; - virtual machine hangs just after reading first 512 bytes from RAW-dist made this way (/dev/da0 is USB flash drive): # VBoxManage internalcommands createrawvmdk \ -filename $HOME/.VirtualBox/HardDisks/usbdisk.vmdk \ -rawdisk /dev/da0 -register I've copied first 512 bytes from VDI image containing WinXP to file 'mbr' and installed it to USB flash drive using 'fdisk -B -b mbr da0' command and now VirtualBox boots and runs this "LiveUSB" with FreeBSD from real USB flash just fine too. nanobsd uses BootEasy as boot0 loader and I use this configuration to build it: NANO_BOOTLOADER="boot/boot0" NANO_BOOT0CFG="-o packet -s 1 -m 3 -t 36" So there is something wrong in BootEasy+VirtualBox+"RAW-disk" triple. How do I debug this? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 11:36:27 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454891065674 for ; Mon, 29 Mar 2010 11:36:27 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 81FE98FC17 for ; Mon, 29 Mar 2010 11:36:26 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.3/8.14.3) with ESMTP id o2TBaOQk082853 for ; Mon, 29 Mar 2010 19:36:24 +0800 (KRAST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4BB090B8.3010801@rdtc.ru> Date: Mon, 29 Mar 2010 18:36:24 +0700 From: Eugene Grosbein User-Agent: Thunderbird 2.0.0.23 (X11/20090918) MIME-Version: 1.0 To: stable@freebsd.org References: <4BB08A27.2000002@kuzbass.ru> In-Reply-To: <4BB08A27.2000002@kuzbass.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: VirtualBox, RAW-disks and boot0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 11:36:27 -0000 Eugene Grosbein wrote: > Hi! > > I've built FreeBSD 8.0-STABLE "LiveUSB" image using nanobsd script, > it works with real hardware. I'd like to test it with VirtualBox > to avoid rebooting too often. So, I've installed > virtualbox-ose 3.1.4 from ports and tested it: > > - it boots Windows XP guest installed to VDI-disk just fine; > - it boots FreeBSD "LiveCD" I've built as ISO image fine too; > - virtual machine hangs just after reading first 512 bytes > from RAW-dist made this way (/dev/da0 is USB flash drive): > > # VBoxManage internalcommands createrawvmdk \ > > -filename $HOME/.VirtualBox/HardDisks/usbdisk.vmdk \ > > -rawdisk /dev/da0 -register > > I've copied first 512 bytes from VDI image containing WinXP Well, not directly from VDI image but from /dev/ad1 while running FreeBSD guest booted from LiveCD with WinXP VDI disk attached as secondary HDD. > to file 'mbr' and installed it to USB flash drive > using 'fdisk -B -b mbr da0' command and now VirtualBox > boots and runs this "LiveUSB" with FreeBSD from real USB flash > just fine too. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 12:04:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F413B106566C for ; Mon, 29 Mar 2010 12:04:40 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id A0A968FC17 for ; Mon, 29 Mar 2010 12:04:40 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id C113C245923; Mon, 29 Mar 2010 14:04:38 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 3.3468] X-CRM114-CacheID: sfid-20100329_14043_1EE1F6FA X-CRM114-Status: UNSURE (3.3468) This message is 'unsure'; please train it! Message-ID: <4BB09754.3050309@fsn.hu> Date: Mon, 29 Mar 2010 14:04:36 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Mike Tancsa References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <201003251548.o2PFmHMH028420@lava.sentex.ca> In-Reply-To: <201003251548.o2PFmHMH028420@lava.sentex.ca> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Mar 29 14:04:38 2010 X-DSPAM-Confidence: 0.7609 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb09756468394100018758 X-DSPAM-Factors: 27, X-Bogosity*Ham, 0.00337, X-Bogosity*Ham+tests=bogofilter, 0.00337, X-Spambayes-Classification*ham+0.00, 0.00388, X-Spambayes-Classification*0.00, 0.00388, X-Bogosity*spamicity=0.000000+version=1.2.1, 0.00533, X-Bogosity*tests=bogofilter+spamicity=0.000000, 0.00533, X-Bogosity*spamicity=0.000000, 0.00533, >, 0.00592, >, 0.00592, Url*freebsd, 0.00690, Url*freebsd, 0.00690, wrote, 0.00856, wrote, 0.00856, >+>, 0.00862, >+>, 0.00862, X-Spambayes-Classification*ham, 0.00891, Return-Path*fsn.hu>, 0.99041, From*fsn.hu>, 0.99041, wrote+>, 0.00985, Nagy+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:04:41 -0000 Mike Tancsa wrote: > At 11:39 AM 3/25/2010, Michael Loftis wrote: >> --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy >> wrote: >> >> <...> >>> Both unbound and python accepts DNS requests, and it seems when 25% >>> interrupt happens, only unbound is in *udp state, where it is 50%, both >>> programs are in that state. >> >> Try turning of hardware TSO/checksum offload if it's availble on your >> chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using >> nfe chips right now, but w/ the TSO/CSUM on they lock up constantly >> under high load. We're pretty sure it's mostly the nfe driver, or >> the chips themselves, but have never ruled out some generic 8.x >> hardware offload issues. > > There were also a bunch of commits last night for the bce driver. If > its the NIC in RELENG_8, perhaps those bug fixes might help > > http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-March/001804.html > > http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-March/001803.html > I saw them, but they didn't seem to be related. I've just tested it, and my assumptions were correct. A fresh 8-STABLE also freezes. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 14:43:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75E661065674 for ; Mon, 29 Mar 2010 14:43:15 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3887E8FC08 for ; Mon, 29 Mar 2010 14:43:15 +0000 (UTC) Received: from barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id 102AF23C2F9 for ; Mon, 29 Mar 2010 09:43:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1269873794; bh=1k+tD91BjWktDgjOId4dJENReXtJgSaJ/6KaU1kyjKQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=R814sFmIhJMH 8yvKpGId5wFXmgv7trMHm0286+HO6C+aWD1kNPKJJWO5YrU62IeKFDE56PDKrTehhug KP8gbgvaf7AnRR4ZOTJOvOG3T3YlO9mm8fTfgqCWhbuNdksWjar2fV1S6W3GSqHM7y2 zkV7TSu+XwPF9KIKtRcS+qQiY= Received: from octane.med.und.nodak.edu ([134.129.166.23]) by barryp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1NwGBK-000KDF-8r; Mon, 29 Mar 2010 09:43:10 -0500 Message-ID: <4BB0BC7C.3000801@barryp.org> Date: Mon, 29 Mar 2010 09:43:08 -0500 From: Barry Pederson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: jhell References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 14:43:15 -0000 I've been using the arc_summary.pl script from here: http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl and noticed some odd numbers, with the ARC Current Size being larger than the Max Size, and the breakdown adding up to less than the current size as shown below -------- ARC Size: Current Size: 992.71M (arcsize) Target Size: (Adaptive) 512.00M (c) Min Size (Hard Limit): 81.82M (arc_min) Max Size (Hard Limit): 512.00M (arc_max) ARC Size Breakdown: Recently Used Cache Size: 99.84% 511.18M (p) Frequently Used Cache Size: 0.16% 0.82M (c-p) -------- From another thread I saw, it sounds like arc_max isn't really a "Hard Limit" but rather some kind of high water mark. If that's the case then I wonder if this might make more sense.... --------- --- arc_summary.pl.original 2010-02-25 19:23:13.000000000 -0600 +++ arc_summary.pl 2010-03-29 09:32:28.000000000 -0500 @@ -121,20 +121,20 @@ my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size}; my $arc_size_MiB = ($arc_size / 1048576); -my $mfu_size = $target_size - $mru_size; +my $mfu_size = $arc_size - $mru_size; my $mfu_size_MiB = ($mfu_size / 1048576); -my $mru_perc = 100*($mru_size / $target_size); -my $mfu_perc = 100*($mfu_size / $target_size); +my $mru_perc = 100*($mru_size / $arc_size); +my $mfu_perc = 100*($mfu_size / $arc_size); print "ARC Size:\n"; printf("\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n", $arc_size_MiB); printf("\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n", $target_size_MiB); printf("\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n", $arc_min_size_MiB); -printf("\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n", $arc_max_size_MiB); +printf("\tMax Size :\t\t\t%0.2fM (arc_max)\n", $arc_max_size_MiB); print "\nARC Size Breakdown:\n"; printf("\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n", $mru_perc, $mru_size_MiB); -printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n", $mfu_perc, $mfu_size_MiB); +printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n", $mfu_perc, $mfu_size_MiB); print "\n"; ### ARC Efficency ### ----------- Giving something like this... -------- ARC Size: Current Size: 992.88M (arcsize) Target Size: (Adaptive) 512.00M (c) Min Size (Hard Limit): 81.82M (arc_min) Max Size : 512.00M (arc_max) ARC Size Breakdown: Recently Used Cache Size: 51.48% 511.18M (p) Frequently Used Cache Size: 48.52% 481.70M (arcsize-p) -------- Barry From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 15:29:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2072C106564A for ; Mon, 29 Mar 2010 15:29:04 +0000 (UTC) (envelope-from a.j.werven@student.utwente.nl) Received: from satellite.xs4all.nl (zoefsam.xs4all.nl [82.95.125.145]) by mx1.freebsd.org (Postfix) with ESMTP id A0B918FC1B for ; Mon, 29 Mar 2010 15:29:03 +0000 (UTC) Received: from satellite.xs4all.nl (localhost [127.0.0.1]) by satellite.xs4all.nl (8.14.4/8.14.4) with ESMTP id o2TF0JuV001478 for ; Mon, 29 Mar 2010 17:00:19 +0200 (CEST) (envelope-from fonz@satellite.xs4all.nl) Received: (from fonz@localhost) by satellite.xs4all.nl (8.14.4/8.14.4/Submit) id o2TF0JwS001477 for freebsd-stable@freebsd.org; Mon, 29 Mar 2010 17:00:19 +0200 (CEST) (envelope-from fonz) From: "A.J. \"Fonz\" van Werven" Message-Id: <201003291500.o2TF0JwS001477@satellite.xs4all.nl> To: freebsd-stable@freebsd.org Date: Mon, 29 Mar 2010 17:00:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL124c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Subject: [if_re] Dropping connectivity X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:29:04 -0000 It seems like recent commits may have broken if_re. After I updated last weekend (and again this morning), everything appears to be fine initially: I can ping hosts, browse the Web with Lynx, etc. But as soon as a certain amount of data has been transferred (e.g. when I start a graphical browser like Opera or Seamonkey, or I (try to) run port- snap) suddenly all connectivity vanishes: resolving no longer works, I can't even ping my modem/router. Running /etc/rc.d/netif restart doesn't help. I do get lots of watchdog timeout messages on the console. Fortunately I still have a USB WiFi adapter I can use (if_rum still works like a charm) so I'm not entirely cut off, but *some*thing appears to have happened to if_re. Any thoughts? Thanks in advance, Alphons P.S. In case it matters: $ uname -a FreeBSD satellite.xs4all.nl 7.3-STABLE FreeBSD 7.3-STABLE #32: Mon Mar 29 14:33:23 CEST 2010 toor@satellite.xs4all.nl:/usr/obj/usr/src/sys/GENERIC i386 $ dmesg|grep re0 re0: port 0x5000-0x50ff mem 0xda000000-0xda000fff irq 18 at device 0.0 on pci5 re0: Using 1 MSI messages re0: Chip rev. 0x34000000 re0: MAC rev. 0x00000000 miibus0: on re0 re0: Ethernet address: ***** re0: [FILTER] -- ... And once you have tasted flight you will walk the earth with your eyes turned skywards, for there you have been and there you long to return... -- Leonardo da Vinci From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 16:11:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F00106566C for ; Mon, 29 Mar 2010 16:11:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0D74D8FC0C for ; Mon, 29 Mar 2010 16:11:21 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id yzv11d0061swQuc5A4BMdb; Mon, 29 Mar 2010 16:11:22 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.westchester.pa.mail.comcast.net with comcast id z4FX1d00E3S48mS3b4FX6i; Mon, 29 Mar 2010 16:15:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4B3739B419; Mon, 29 Mar 2010 09:11:19 -0700 (PDT) Date: Mon, 29 Mar 2010 09:11:19 -0700 From: Jeremy Chadwick To: Barry Pederson Message-ID: <20100329161119.GA2421@icarus.home.lan> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB0BC7C.3000801@barryp.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jhell , FreeBSD Stable Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:11:22 -0000 On Mon, Mar 29, 2010 at 09:43:08AM -0500, Barry Pederson wrote: > From another thread I saw, it sounds like arc_max isn't really > a "Hard Limit" but rather some kind of high water mark. If that's > the case then I wonder if this might make more sense.... It became a hard limit in a semi-recent commit somewhere. I've lost count of the modifications at this point. So, the perl script would have to read __FreeBSD_version in /usr/include/osreldate.h and adjust its output accordingly. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 16:28:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C491065673 for ; Mon, 29 Mar 2010 16:28:04 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 84FAE8FC0A for ; Mon, 29 Mar 2010 16:28:04 +0000 (UTC) Received: from [192.168.1.116] (portal.theptrgroup.com [71.178.251.28]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id o2TGRT1f023065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Mar 2010 16:27:34 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4BB0BC7C.3000801@barryp.org> Date: Mon, 29 Mar 2010 12:27:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6823460E-4878-4936-A827-75BBA97F2304@wanderview.com> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> To: Barry Pederson X-Mailer: Apple Mail (2.1077) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: jhell , FreeBSD Stable Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:28:05 -0000 On Mar 29, 2010, at 10:43 AM, Barry Pederson wrote: > I've been using the arc_summary.pl script from here: >=20 > = http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summ= ary.pl >=20 > and noticed some odd numbers, with the ARC Current Size being larger = than the Max Size, and the breakdown adding up to less than the current = size as shown below I believe the current size can be larger than the max if your working = data set is large enough. The ARC can't evict data that is still being = referenced. When I last looked (over a year ago) there was no mechanism = to provide back pressure from the ARC to the VM layer to request that = more nodes be released to help deal with this situation. I don't know if that really helps at all, but I just thought I would add = the data point from my previous debugging sessions with zfs. - Ben= From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 16:56:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7C14106564A for ; Mon, 29 Mar 2010 16:56:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 88FF28FC0A for ; Mon, 29 Mar 2010 16:56:49 +0000 (UTC) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id yz4G1d0041HzFnQ5D4wpLk; Mon, 29 Mar 2010 16:56:49 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta14.westchester.pa.mail.comcast.net with comcast id z4wo1d00P3S48mS3a4wpT7; Mon, 29 Mar 2010 16:56:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8CF989B419; Mon, 29 Mar 2010 09:56:47 -0700 (PDT) Date: Mon, 29 Mar 2010 09:56:47 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100329165647.GA3796@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Strange NFS-related messages (related to lockd/statd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:56:49 -0000 I recently brought up rpc.lockd and rpc.statd on all of our NFS clients (mixed RELENG_6, RELENG_7, and RELENG_8), and our NFS server (RELENG_8). All clients had nfs_client_enable="yes" in rc.conf prior to their last reboot, but lacked rpcbind_enable="yes", rpc_lockd_enable="yes", and rpc_statd_enable="yes" prior to the below. The 8.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: NLM: failed to contact remote rpcbind, stat = 0, port = 0 Can't start NLM - unable to contact NSM The 7.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: Can't start NLM - unable to contact NSM One of the 7.x clients also kernel panic'd when starting rpc.lockd, in some nlm_* kernel functions. Looking at commits showed that the bug that caused the panic was fixed in a later 7.x release. The 7.x clients started rpcbind, rpc.lockd, rpc.statd -- and said nothing. The above daemons were all started in that order, per the FreeBSD Handbook. I can't find a definition of what the acronyms NLM and NSM stand for, nor does Googling the error messages return relevant results (except one FreeBSD committer reporting similar, but nobody replied). I don't know the implications of these messages. The only thing I can think might cause such errors would be the fact that these machines all have dual NICs with firewall rules applied only to their primary (WAN-side) interface. The NFS server exists only on the private (LAN-side) interface. I'm thinking rpcbind may have tried to "do stuff" on the WAN interface, since no -h option was applied. I haven't tried making use of -h yet, nor have I tried restarting the daemons to see if the errors recur (or if it was just a one-time thing). Any information/tips/advice would be appreciated. Danke! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 17:01:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B873A106566B; Mon, 29 Mar 2010 17:01:04 +0000 (UTC) (envelope-from masoom.shaikh@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 33EEA8FC1B; Mon, 29 Mar 2010 17:01:03 +0000 (UTC) Received: by gxk3 with SMTP id 3so1075105gxk.13 for ; Mon, 29 Mar 2010 10:01:03 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CD6i0+opt2RhnPHLhkeEx9Koe0pwf8+B+7V4yl3NiBE=; b=e29TCAWPWQtS9Mu0SgATxAn1xAc8a1CWhtVyAfyhvpOOBcypMeoyFWuzWIMLDmGytw QTCj2OgYdBQWgks9C7ObJAyUwOXKqpLIz/clZqi+ECf3HUUuzXATldDwIzBQf8qzf923 xpLYf2w2nUXkXADECRDKviBCeJNYYY/2q54WY= 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=vktVH0H0yK9wnIbdHj5DFUrJadn6cGLlqh2aRLGh9rgkClPQgAoLxmmlIPdUGpSifD NnrSFrnTdTR2rS1d7vdWm9V5uebs9M1zvIzlyguzR6Kgdv2ZHKcd5AUifYhgt3kx1/sa qZvMCc0buUd6O+tB61D7O9WA4MSytDwjWLyec= MIME-Version: 1.0 Received: by 10.114.137.14 with HTTP; Mon, 29 Mar 2010 10:01:02 -0700 (PDT) In-Reply-To: <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> Date: Mon, 29 Mar 2010 17:01:02 +0000 Received: by 10.114.214.36 with SMTP id m36mr1629922wag.222.1269882062707; Mon, 29 Mar 2010 10:01:02 -0700 (PDT) Message-ID: From: Masoom Shaikh To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 17:01:04 -0000 On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > On 28 March 2010 16:42, Masoom Shaikh wrote: > >> lets assume if this is h/w problem, then how can other OSes overcome >> this ? is there a way to make FreeBSD ignore this as well, let it >> result in reasonable performance penalty. > > Very probably, if only we could detect where the problem is. > Try adding "options =A0 =A0 PRINTF_BUFR_SIZE=3D128" to the kernel this option is already there > configuration file if you can, to see if you can get a less mangled > log outout. > From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 17:23:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10A291065673 for ; Mon, 29 Mar 2010 17:23:39 +0000 (UTC) (envelope-from pyunyh@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 8D5278FC12 for ; Mon, 29 Mar 2010 17:23:38 +0000 (UTC) Received: by bwz8 with SMTP id 8so4973620bwz.3 for ; Mon, 29 Mar 2010 10:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=dN+MyRhDGanX/XGmAXivRC4BVFiSgAMagf39WP3GuFQ=; b=MKEXPm6rGaIl2N6u5ubhawEIn2TafDfZw6NA1KCQHKkiVEgkl8RMODstRCag00AUNA Zq1xMXVso5ksQowTHR5Ng2DN04h5401auQ5ohrH+rAo5itaFeWpkJs+qlZHx7pyn83VG 0eGxieaTUQHrODeq/jptf53I025Ao8DlUbHn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=P9Iyaf3HC53lgG+BP2hePm6t9Bte3VLzcqArqMBAxttJF0VU1vd8hX53Q7KVxvyCno 4uFwZbE0v/6bciCVZRofHj9RnAznafZ/LBFBcK9T/S3y5x5mGFwUoWlHytytWWm6j4Rh bvrmKFPFwdiOAlErJL8CgvopiF2Tkel8qg6MI= Received: by 10.204.8.5 with SMTP id f5mr3400012bkf.59.1269883417138; Mon, 29 Mar 2010 10:23:37 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l1sm39822895bkl.2.2010.03.29.10.23.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 10:23:36 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 29 Mar 2010 10:22:39 -0700 From: Pyun YongHyeon Date: Mon, 29 Mar 2010 10:22:39 -0700 To: "A.J. Fonz van Werven" Message-ID: <20100329172239.GC1473@michelle.cdnetworks.com> References: <201003291500.o2TF0JwS001477@satellite.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003291500.o2TF0JwS001477@satellite.xs4all.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: [if_re] Dropping connectivity X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 17:23:39 -0000 On Mon, Mar 29, 2010 at 05:00:19PM +0200, A.J. Fonz van Werven wrote: > It seems like recent commits may have broken if_re. > > After I updated last weekend (and again this morning), everything appears > to be fine initially: I can ping hosts, browse the Web with Lynx, etc. But > as soon as a certain amount of data has been transferred (e.g. when I > start a graphical browser like Opera or Seamonkey, or I (try to) run port- > snap) suddenly all connectivity vanishes: resolving no longer works, I > can't even ping my modem/router. Running /etc/rc.d/netif restart doesn't > help. I do get lots of watchdog timeout messages on the console. > > Fortunately I still have a USB WiFi adapter I can use (if_rum still works > like a charm) so I'm not entirely cut off, but *some*thing appears to have > happened to if_re. > > Any thoughts? Thanks in advance, > What is last known working revision of re(4)? > Alphons > > P.S. In case it matters: > > $ uname -a > FreeBSD satellite.xs4all.nl 7.3-STABLE FreeBSD 7.3-STABLE #32: Mon Mar 29 14:33:23 CEST 2010 toor@satellite.xs4all.nl:/usr/obj/usr/src/sys/GENERIC i386 > $ dmesg|grep re0 > re0: port 0x5000-0x50ff mem 0xda000000-0xda000fff irq 18 at device 0.0 on pci5 > re0: Using 1 MSI messages > re0: Chip rev. 0x34000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > re0: Ethernet address: ***** > re0: [FILTER] From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 17:30:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60542106566C for ; Mon, 29 Mar 2010 17:30:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 41BE88FC17 for ; Mon, 29 Mar 2010 17:30:39 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta14.emeryville.ca.mail.comcast.net with comcast id z1s91d0060b6N64AE5Wg1z; Mon, 29 Mar 2010 17:30:40 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id z5Wf1d00M3S48mS8P5Wgke; Mon, 29 Mar 2010 17:30:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CBCEA9B419; Mon, 29 Mar 2010 10:30:38 -0700 (PDT) Date: Mon, 29 Mar 2010 10:30:38 -0700 From: Jeremy Chadwick To: Masoom Shaikh Message-ID: <20100329173038.GA4969@icarus.home.lan> References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras , freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 17:30:40 -0000 On Mon, Mar 29, 2010 at 05:01:02PM +0000, Masoom Shaikh wrote: > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > >> lets assume if this is h/w problem, then how can other OSes overcome > >> this ? is there a way to make FreeBSD ignore this as well, let it > >> result in reasonable performance penalty. > > > > Very probably, if only we could detect where the problem is. > > Try adding "options     PRINTF_BUFR_SIZE=128" to the kernel > > this option is already there The key word in Ivan's phrase is "less mangled". Neither use of or increasing PRINTF_BUFR_SIZE solves the problem of interspersed console output. I've been ranting/raving about this problem for years now; it truly looks like a mutex lock issue (or lack of such lock), but I've been told numerous times that isn't the case. To developers: what incentives would help get this issue well-needed attention? This problem makes kernel debugging, panic analysis, and other console-oriented viewing basically impossible. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 18:28:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FE71065676; Mon, 29 Mar 2010 18:28:53 +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 4455D8FC0A; Mon, 29 Mar 2010 18:28:53 +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 D5ED446B8C; Mon, 29 Mar 2010 14:28:52 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 310358A01F; Mon, 29 Mar 2010 14:28:52 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 29 Mar 2010 14:27:34 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100329173038.GA4969@icarus.home.lan> In-Reply-To: <20100329173038.GA4969@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003291427.34641.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 29 Mar 2010 14:28:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 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, Masoom Shaikh , Ivan Voras , Jeremy Chadwick , freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:28:53 -0000 On Monday 29 March 2010 1:30:38 pm Jeremy Chadwick wrote: > On Mon, Mar 29, 2010 at 05:01:02PM +0000, Masoom Shaikh wrote: > > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > > > >> lets assume if this is h/w problem, then how can other OSes overcome > > >> this ? is there a way to make FreeBSD ignore this as well, let it > > >> result in reasonable performance penalty. > > > > > > Very probably, if only we could detect where the problem is. > > > Try adding "options PRINTF_BUFR_SIZE=128" to the kernel > > > > this option is already there > > The key word in Ivan's phrase is "less mangled". Neither use of or > increasing PRINTF_BUFR_SIZE solves the problem of interspersed console > output. I've been ranting/raving about this problem for years now; it > truly looks like a mutex lock issue (or lack of such lock), but I've > been told numerous times that isn't the case. > > To developers: what incentives would help get this issue well-needed > attention? This problem makes kernel debugging, panic analysis, and > other console-oriented viewing basically impossible. I was recently going to look at it. The somewhat drastic approach I was going to take was to add a simple serializing lock around trap_fatal() and a few other places that do similar block prints (e.g. mca_log()). One of the issues with fixing this in printf itself is that you'd want probably want to serialize complete lines of text on a per-thread basis. You would want to be able to accumulate this line of text across multiple calls to printf (think of it as line-buffering ala stdio). However, some folks may be nervous about printf not printing things immediately. The other issue is that lots of code assumes it can call printf from anywhere and everywhere. Mostly this just means that if you add locking and line- buffering to printf(9) you have to be very careful to make sure it works in odd places. Probably a lot of this could be solved by deferring things like trap_fatal() until panic() has already been called (which is bde's preferred solution I think). -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 18:39:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21C61065672 for ; Mon, 29 Mar 2010 18:39:47 +0000 (UTC) (envelope-from pyunyh@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 38B178FC1B for ; Mon, 29 Mar 2010 18:39:46 +0000 (UTC) Received: by bwz8 with SMTP id 8so5030158bwz.3 for ; Mon, 29 Mar 2010 11:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=U/MGs2AH+9LBtrngmyO2kom05j8cBGtMuccpGMGi5eY=; b=HqSuNMAQd6d2m0b/eCccL5Ysw9wlgGi4L9Lex3I4l0FuMWX3DFdttq7YVB04qBuoaZ iGV3dLUBrTBCrWBjMGfOhniZPrQj5eC93vR+nYH+fCUdHaQhGfuWuWSdgI4Rn3ZSsifF Z2opvWVkxwr0e40rzyL6DjO+CX1rxjNe+phAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=JxP6jIjlGO+W2muPSLXEbJS+uTshR69jPVAgY+5O85YrcVKQ66u3ysXAsidY7+7C/Y Q9yoaVmAzT6vPlvX/GA0kJzwH6UwlYSPZRqV8CPJoXs5MMndaA9e5L0msea1v8Z+CQhJ gJd8tISPCuWbyHZzyW6Bg8uuyPHW+E9XJg2FI= Received: by 10.204.73.165 with SMTP id q37mr1917528bkj.100.1269887985764; Mon, 29 Mar 2010 11:39:45 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d5sm40284313bkd.13.2010.03.29.11.39.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 11:39:44 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 29 Mar 2010 11:38:48 -0700 From: Pyun YongHyeon Date: Mon, 29 Mar 2010 11:38:48 -0700 To: Attila Nagy Message-ID: <20100329183848.GE1473@michelle.cdnetworks.com> References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB087B7.3030602@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:39:47 -0000 On Mon, Mar 29, 2010 at 12:57:59PM +0200, Attila Nagy wrote: > Hi, > > Michael Loftis wrote: > > > > > > --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy > > wrote: > > > > <...> > >> Both unbound and python accepts DNS requests, and it seems when 25% > >> interrupt happens, only unbound is in *udp state, where it is 50%, both > >> programs are in that state. > > > > Try turning of hardware TSO/checksum offload if it's availble on your > > chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using > > nfe chips right now, but w/ the TSO/CSUM on they lock up constantly > > under high load. We're pretty sure it's mostly the nfe driver, or the > > chips themselves, but have never ruled out some generic 8.x hardware > > offload issues. > Bingo, this solved the problem. The current uptime nears four days. > Previously I couldn't go further than a day. > > The machine gets very light TCP load (and other machines which get work > well), so I guess it's UDP RX or TX checksum related. > Hmm, this is unexpected result. Since you're using UDP, TSO is not involved in this issue. Because you disabled RX/TX checksum offloading could you check how many number of 'bad checksum' and and 'no checksum' you have from netstat(1)? To narrow down which side of checksum offloading causes the issue, would you just disable one side in a time? For instance, disable TX checksum offloading with RX checksum offloading enabled and see how bce(4) works. #ifconfig bce0 -txcsum rxcsum If that shows the same issue, try disabling RX checksum offloading but enabling TX checksum offloading. #ifconfig bce0 txcsum -rxcsum From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 19:09:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD63106566C for ; Mon, 29 Mar 2010 19:09:59 +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 4842D8FC13 for ; Mon, 29 Mar 2010 19:09:59 +0000 (UTC) Received: (qmail 31594 invoked by uid 399); 29 Mar 2010 19:09:58 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Mar 2010 19:09:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB0FB05.9050802@FreeBSD.org> Date: Mon, 29 Mar 2010 12:09:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 MIME-Version: 1.0 To: Aristedes Maniatis References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> <4BB07278.7030600@ish.com.au> In-Reply-To: <4BB07278.7030600@ish.com.au> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:09:59 -0000 On 03/29/10 02:27, Aristedes Maniatis wrote: > On 29/03/10 7:04 PM, Doug Barton wrote: >>>> portmaster -r graphics/png >> That won't work, the man page clearly says that it has to be a port >> directory or glob pattern from /var/db/pkg. The "glob pattern" bit of >> that was (unfortunately) broken up till version 2.20, which I just >> committed. > > I'm confused. The manual actually says: > > [-R] -r name/glob of port in /var/db/pkg > > > When I try your suggestion I get this: > > # portmaster -r png- > > ===>>> No valid installed port, or port directory given > ===>>> Try portmaster --help Are you using portmaster version 2.20? -- ... 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-stable@FreeBSD.ORG Mon Mar 29 19:12:00 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7960010656B4 for ; Mon, 29 Mar 2010 19:12:00 +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 F2EC48FC0C for ; Mon, 29 Mar 2010 19:11:59 +0000 (UTC) Received: (qmail 9919 invoked by uid 399); 29 Mar 2010 19:11:59 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Mar 2010 19:11:59 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB0FB7E.2050508@FreeBSD.org> Date: Mon, 29 Mar 2010 12:11:58 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 MIME-Version: 1.0 To: Garrett Cooper References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> <4BB07278.7030600@ish.com.au> <7d6fde3d1003290253n65902d29i39cdd30a2f991a46@mail.gmail.com> In-Reply-To: <7d6fde3d1003290253n65902d29i39cdd30a2f991a46@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:12:00 -0000 On 03/29/10 02:53, Garrett Cooper wrote: > Besides, when I read `glob' I don't think `regular expression'. A > glob is a simplified extension of regular expressions, I wasn't going for a rigorous definition here. :) However, "simplified" is the correct idea. > The previous method I described works, and works well: > > portmaster -r 'png-*' Right, that will work, but the * isn't necessary. Portmaster will strip it internally in any case. > Not sure why graphics/png doesn't work though; hrrm... The -r option is only relevant to an installed port. 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-stable@FreeBSD.ORG Mon Mar 29 19:21:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25D971065674; Mon, 29 Mar 2010 19:21:44 +0000 (UTC) (envelope-from amvandemore@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 8419B8FC28; Mon, 29 Mar 2010 19:21:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so379892qwe.7 for ; Mon, 29 Mar 2010 12:21:42 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=c0obdGD2cAllKUSxIXLuEJyqVa3Fqwmp23SO7LdKvI8=; b=ALFwr3DBvm4BJ93+TsGax9lUtVEepwO/0LgJfbFBAQKbVd65IO/srkzz+n9BxwVQj6 u4sd2c8f6rKSEpOfuMumj1F7ZWKZuWzXqH9va8c5RVPsiEETyTwEFUmLf5/0OxixXMYR OpyrxAbtKgyZS/GwgEH/wkp29sYldXAUYhqRM= 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=qIEh8mc5yq9a1YwCk2aBsx1Gnolx5IJ2nG8O8xRwMqf9ZfXb8Tre+5tWh1/QtJWZmV sANQv0o8eFzXnxah/kGMT9YXIW5v2gV2BXcZHkXFvUFh59t5HwgA1U4ws+TrEztu623Z ue2OdYxNFtyup9AKpVpvU+NjoxM1eyJEqoiSs= MIME-Version: 1.0 Received: by 10.229.82.14 with HTTP; Mon, 29 Mar 2010 12:21:42 -0700 (PDT) In-Reply-To: <4BB0FB7E.2050508@FreeBSD.org> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> <4BB07278.7030600@ish.com.au> <7d6fde3d1003290253n65902d29i39cdd30a2f991a46@mail.gmail.com> <4BB0FB7E.2050508@FreeBSD.org> Date: Mon, 29 Mar 2010 13:21:42 -0600 Received: by 10.229.223.201 with SMTP id il9mr3963503qcb.104.1269890502683; Mon, 29 Mar 2010 12:21:42 -0700 (PDT) Message-ID: <6201873e1003291221t1430623dt40edb532ed207426@mail.gmail.com> From: Adam Vande More To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:21:44 -0000 On Mon, Mar 29, 2010 at 1:11 PM, Doug Barton wrote: > Right, that will work, but the * isn't necessary. Portmaster will strip > it internally in any case. > Those type of examples in the man pages and UPDATING have never worked for me in tcsh, I've always had to glob it like Garret stated. > pkg_info |grep png linux-f10-png-1.2.37 RPM of the PNG lib (Linux Fedora 10) png-1.2.42 Library for manipulating PNG images scr2png-1.2_3 Converts the output of "vidcontrol -p" to PNG > portmaster -r png- ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help > portmaster -r 'png-*' ===>>> Currently installed version: png-1.2.42 ===>>> Port directory: /usr/ports/graphics/png ===>>> Gathering distinfo list for installed ports ===>>> Launching 'make checksum' for graphics/png in background ===>>> Gathering dependency list for graphics/png from ports ===>>> No dependencies for graphics/png ===>>> Checking ports that depend on png-1.2.42 ===>>> Launching child to update akonadi-1.2.1_1 ^C ===>>> Build/Install for graphics/png exiting due to signal -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 19:21:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876401065673 for ; Mon, 29 Mar 2010 19:21:47 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 08E4C8FC3D for ; Mon, 29 Mar 2010 19:21:46 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id DA2EF245FD1; Mon, 29 Mar 2010 21:21:44 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 6.8843] X-CRM114-CacheID: sfid-20100329_21214_A649CC00 X-CRM114-Status: Good ( pR: 6.8843 ) Message-ID: <4BB0FDC6.7050105@fsn.hu> Date: Mon, 29 Mar 2010 21:21:42 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> In-Reply-To: <20100329183848.GE1473@michelle.cdnetworks.com> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Mar 29 21:21:44 2010 X-DSPAM-Confidence: 0.9925 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb0fdc83211351825687 X-DSPAM-Factors: 27, X-Bogosity*Ham+tests=bogofilter, 0.00298, X-Bogosity*Ham, 0.00298, X-Spambayes-Classification*ham+0.00, 0.00343, X-Spambayes-Classification*0.00, 0.00343, X-CRM114-Status*Good, 0.00382, X-CRM114-Status*Good+(, 0.00382, X-Bogosity*spamicity=0.000000, 0.00470, X-Bogosity*tests=bogofilter+spamicity=0.000000, 0.00470, X-Bogosity*spamicity=0.000000+version=1.2.1, 0.00470, >+>, 0.00754, wrote, 0.00759, wrote, 0.00759, wrote+>, 0.00871, wrote+>, 0.00871, Nagy+>+Hi, 0.01000, guess, 0.01000, high+load, 0.01000, not+>, 0.01000 Cc: Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:21:47 -0000 Pyun YongHyeon wrote: > On Mon, Mar 29, 2010 at 12:57:59PM +0200, Attila Nagy wrote: > >> Hi, >> >> Michael Loftis wrote: >> >>> --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy >>> wrote: >>> >>> <...> >>> >>>> Both unbound and python accepts DNS requests, and it seems when 25% >>>> interrupt happens, only unbound is in *udp state, where it is 50%, both >>>> programs are in that state. >>>> >>> Try turning of hardware TSO/checksum offload if it's availble on your >>> chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using >>> nfe chips right now, but w/ the TSO/CSUM on they lock up constantly >>> under high load. We're pretty sure it's mostly the nfe driver, or the >>> chips themselves, but have never ruled out some generic 8.x hardware >>> offload issues. >>> >> Bingo, this solved the problem. The current uptime nears four days. >> Previously I couldn't go further than a day. >> >> The machine gets very light TCP load (and other machines which get work >> well), so I guess it's UDP RX or TX checksum related. >> >> > > Hmm, this is unexpected result. Since you're using UDP, TSO is not > involved in this issue. Because you disabled RX/TX checksum > offloading could you check how many number of 'bad checksum' and > and 'no checksum' you have from netstat(1)? > To narrow down which side of checksum offloading causes the issue, > would you just disable one side in a time? For instance, disable TX > checksum offloading with RX checksum offloading enabled and see how > bce(4) works. > #ifconfig bce0 -txcsum rxcsum > If that shows the same issue, try disabling RX checksum offloading > but enabling TX checksum offloading. > #ifconfig bce0 txcsum -rxcsum > It's interesting. During the day, I've disabled only HW checksumming and left TSO enabled. It couldn't run more than a few hours. I have disabled tso again to see what happens. BTW, of course there is TCP traffic on that interface (DNS is also available on TCP), maybe this causes the problem. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 19:25:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935F21065670 for ; Mon, 29 Mar 2010 19:25:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0C98A8FC18 for ; Mon, 29 Mar 2010 19:25:32 +0000 (UTC) Received: by fxm25 with SMTP id 25so140475fxm.3 for ; Mon, 29 Mar 2010 12:25:31 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=bPhayVbRMsvn0C5H62VnHzOaYSShTOFtRFmeMIG3HQM=; b=t0bmGYoGgEHe7GharYcndpTZ97QCsFDQy/VwmB+s3RrXizOY9EW54h19MAn1WADl47 xmMkBzxu7hoA7A+r0hO/G2k1RfDT519wgWsPi15jeFGrSzUan1/R9Zpeos0ujFsr9sPE wz0Vc9UPgSDQsLJFvP8sq5QtIuE/LD48JQGGk= 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:x-enigmail-version:content-type :content-transfer-encoding; b=LTvY4U9nZ24evrYSr8lvF/AygmsquZEckKjkmDbVrKJKmj4om0HsTTY8Dh9NtuRg3+ gC0PgYP7ViwlA6dSk4fFyHuI9KMEzLEnaH0U4KcazIsHXS78+xfwRIyPtlKqWua26CDX D/rSmsb57E4z7anXtSbkrEpSvLrOWME3opLTA= Received: by 10.223.6.150 with SMTP id 22mr1565408faz.12.1269890731758; Mon, 29 Mar 2010 12:25:31 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm3287148fxm.0.2010.03.29.12.25.30 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 12:25:30 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BB0FEA9.5000104@FreeBSD.org> Date: Mon, 29 Mar 2010 22:25:29 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B8E1489.2070306@omnilan.de> <4B8E1B3D.306@FreeBSD.org> <4BB07BF7.6070602@omnilan.de> In-Reply-To: <4BB07BF7.6070602@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:25:33 -0000 Harald Schmalzbauer wrote: > I have the drives now running in another server, ich7 chipset. > Using UFS, the complete machine locks up for ~30 secs with disk load of > 3.5MB/s. But I don't get any timeout messages and the machine always > recovered. Most of ICH7's do not support AHCI. What's about your's? > Changing to the old ata driver solves the problem. Did I get right that you have switched from ahci(4) to ataahci? > Any chance to get this problem fixed? I couldn't see lockups on another > OS with NCQ in AHCI mode enabled. I'd ship such a disk to anyone who is > willing to debug. It's difficult to fix something, until problem could be reproduced. If you wish to send drive - my address is: Topol-2, b34, f150, Dnepropetrovsk, 49040, Ukraine. Phone: +380503622312. Do not use courier services, only regular mail. Ask for tracking number. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 19:32:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 960C81065675 for ; Mon, 29 Mar 2010 19:32:39 +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 1F6A58FC12 for ; Mon, 29 Mar 2010 19:32:38 +0000 (UTC) Received: (qmail 9403 invoked by uid 399); 29 Mar 2010 19:32:38 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Mar 2010 19:32:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB10054.5070705@FreeBSD.org> Date: Mon, 29 Mar 2010 12:32:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 MIME-Version: 1.0 To: Adam Vande More References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <4BAFFCB7.6080501@ish.com.au> <7d6fde3d1003281915s3a81e132q81db6bba1ccff697@mail.gmail.com> <4BB00DA9.3070105@ish.com.au> <7d6fde3d1003281934y2d4cc25cqa90069a1cafc30a@mail.gmail.com> <4BB05F0C.6090807@FreeBSD.org> <4BB07278.7030600@ish.com.au> <7d6fde3d1003290253n65902d29i39cdd30a2f991a46@mail.gmail.com> <4BB0FB7E.2050508@FreeBSD.org> <6201873e1003291221t1430623dt40edb532ed207426@mail.gmail.com> In-Reply-To: <6201873e1003291221t1430623dt40edb532ed207426@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:32:39 -0000 On 03/29/10 12:21, Adam Vande More wrote: > On Mon, Mar 29, 2010 at 1:11 PM, Doug Barton > wrote: > > Right, that will work, but the * isn't necessary. Portmaster will strip > it internally in any case. > > > Those type of examples in the man pages and UPDATING have never worked > for me in tcsh, I've always had to glob it like Garret stated. I'm sorry to repeat myself, but what you're describing is a result of the fact that in the past the glob code for the -r option was broken. As of version 2.20 it is no longer broken, and the * is not necessary (although it won't hurt anything). hope this helps, 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-stable@FreeBSD.ORG Mon Mar 29 19:42:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E571065676 for ; Mon, 29 Mar 2010 19:42:44 +0000 (UTC) (envelope-from pyunyh@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 463A98FC1A for ; Mon, 29 Mar 2010 19:42:43 +0000 (UTC) Received: by bwz8 with SMTP id 8so5077294bwz.3 for ; Mon, 29 Mar 2010 12:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=33WQAg6oteyuRFtG5hz7Tlf7Deh3AQjiESCnJ3PyvZI=; b=GnimeQcuv0xfYKz27Hvn5005+zTYnjBNGXvIC2OE4odF/iBzMl4jk6mX+hctlFdnmY s5tHtBsieMl6oRVTVIq3KNxxpUj1OzvpfR8Uwtw7duAGjBUuaOi4yRmk3fpfquN0nvoI IZLmWoGYmdtTSUKFz/+qRUS5ls8WpDQkq5uHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=iwK9QdORm/+tM+dMLRnqLBw9cWKap1ZDOYTUTnofgdTW7oW/aYfXb2N+wG16qeetkw dybCIcL3GefGuX0puJrIY4nFzDaY6FFQ3KZ1GCma7GKWxHRB0gpN7eLH16hG7RsRtOUS PRBgrUKkZyNJcVUEL5Saj8DWiW0CMPlap9q/A= Received: by 10.204.24.134 with SMTP id v6mr5125800bkb.204.1269891753993; Mon, 29 Mar 2010 12:42:33 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 14sm2345668bwz.2.2010.03.29.12.42.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Mar 2010 12:42:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 29 Mar 2010 12:41:31 -0700 From: Pyun YongHyeon Date: Mon, 29 Mar 2010 12:41:31 -0700 To: Attila Nagy Message-ID: <20100329194131.GG1473@michelle.cdnetworks.com> References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB0FDC6.7050105@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:42:44 -0000 On Mon, Mar 29, 2010 at 09:21:42PM +0200, Attila Nagy wrote: > Pyun YongHyeon wrote: > > On Mon, Mar 29, 2010 at 12:57:59PM +0200, Attila Nagy wrote: > > > >> Hi, > >> > >> Michael Loftis wrote: > >> > >>> --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy > >>> wrote: > >>> > >>> <...> > >>> > >>>> Both unbound and python accepts DNS requests, and it seems when 25% > >>>> interrupt happens, only unbound is in *udp state, where it is 50%, both > >>>> programs are in that state. > >>>> > >>> Try turning of hardware TSO/checksum offload if it's availble on your > >>> chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using > >>> nfe chips right now, but w/ the TSO/CSUM on they lock up constantly > >>> under high load. We're pretty sure it's mostly the nfe driver, or the > >>> chips themselves, but have never ruled out some generic 8.x hardware > >>> offload issues. > >>> > >> Bingo, this solved the problem. The current uptime nears four days. > >> Previously I couldn't go further than a day. > >> > >> The machine gets very light TCP load (and other machines which get work > >> well), so I guess it's UDP RX or TX checksum related. > >> > >> > > > > Hmm, this is unexpected result. Since you're using UDP, TSO is not > > involved in this issue. Because you disabled RX/TX checksum > > offloading could you check how many number of 'bad checksum' and > > and 'no checksum' you have from netstat(1)? > > To narrow down which side of checksum offloading causes the issue, > > would you just disable one side in a time? For instance, disable TX > > checksum offloading with RX checksum offloading enabled and see how > > bce(4) works. > > #ifconfig bce0 -txcsum rxcsum > > If that shows the same issue, try disabling RX checksum offloading > > but enabling TX checksum offloading. > > #ifconfig bce0 txcsum -rxcsum > > > It's interesting. During the day, I've disabled only HW checksumming and > left TSO enabled. It couldn't run more than a few hours. > I have disabled tso again to see what happens. > > BTW, of course there is TCP traffic on that interface (DNS is also > available on TCP), maybe this causes the problem. The only guess I can think of at this moment is incorrect use of bus_dma(9) in TX path. But I'm not sure this is related with the issue you're seeing. Would you try the experimental patch at the following URL? http://people.freebsd.org/~yongari/bce/bce.20100305.diff Please make sure to back up your old bce(4) driver before applying the patch. I didn't see any abnormal things in testing but it wasn't much stressed. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 20:18:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A601065677 for ; Mon, 29 Mar 2010 20:18:37 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 572778FC1F for ; Mon, 29 Mar 2010 20:18:37 +0000 (UTC) Received: by bwz8 with SMTP id 8so5104378bwz.3 for ; Mon, 29 Mar 2010 13:18:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.154.75 with HTTP; Mon, 29 Mar 2010 13:18:35 -0700 (PDT) X-Originating-IP: [93.203.25.218] In-Reply-To: <201003291427.34641.jhb@freebsd.org> References: <20100329173038.GA4969@icarus.home.lan> <201003291427.34641.jhb@freebsd.org> Date: Mon, 29 Mar 2010 22:18:35 +0200 Received: by 10.204.32.214 with SMTP id e22mr4897837bkd.5.1269893915645; Mon, 29 Mar 2010 13:18:35 -0700 (PDT) Message-ID: From: "C. P. Ghost" To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:18:38 -0000 On Mon, Mar 29, 2010 at 8:27 PM, John Baldwin wrote: >> To developers: what incentives would help get this issue well-needed >> attention? =A0This problem makes kernel debugging, panic analysis, and >> other console-oriented viewing basically impossible. > > I was recently going to look at it. =A0The somewhat drastic approach I wa= s going > to take was to add a simple serializing lock around trap_fatal() and a fe= w > other places that do similar block prints (e.g. mca_log()). =A0One of the= issues > with fixing this in printf itself is that you'd want probably want to > serialize complete lines of text on a per-thread basis. =A0You would want= to be > able to accumulate this line of text across multiple calls to printf (thi= nk of > it as line-buffering ala stdio). =A0However, some folks may be nervous ab= out > printf not printing things immediately. > > The other issue is that lots of code assumes it can call printf from anyw= here > and everywhere. =A0Mostly this just means that if you add locking and lin= e- > buffering to printf(9) you have to be very careful to make sure it works = in > odd places. =A0Probably a lot of this could be solved by deferring things= like > trap_fatal() until panic() has already been called (which is bde's prefer= red > solution I think). How about serializing all printf(9) through a dedicated kernel thread? Mayb= e something as flexible as syslogd for kernel space (klogd), that could also redirect output to a file, to a serial console etc...? > John Baldwin -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 20:30:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B6B106567B for ; Mon, 29 Mar 2010 20:30:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD1A8FC25 for ; Mon, 29 Mar 2010 20:30:49 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta08.emeryville.ca.mail.comcast.net with comcast id yzxo1d0040b6N64A88Wqyx; Mon, 29 Mar 2010 20:30:50 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id z8Wp1d00Q3S48mS8P8WpFX; Mon, 29 Mar 2010 20:30:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 50E049B419; Mon, 29 Mar 2010 13:30:48 -0700 (PDT) Date: Mon, 29 Mar 2010 13:30:48 -0700 From: Jeremy Chadwick To: John Baldwin Message-ID: <20100329203048.GA8010@icarus.home.lan> References: <20100329173038.GA4969@icarus.home.lan> <201003291427.34641.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003291427.34641.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-questions@freebsd.org, Masoom Shaikh , freebsd-stable@freebsd.org, Ivan Voras , freebsd-hackers@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:30:50 -0000 On Mon, Mar 29, 2010 at 02:27:34PM -0400, John Baldwin wrote: > On Monday 29 March 2010 1:30:38 pm Jeremy Chadwick wrote: > > On Mon, Mar 29, 2010 at 05:01:02PM +0000, Masoom Shaikh wrote: > > > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > > > > > >> lets assume if this is h/w problem, then how can other OSes overcome > > > >> this ? is there a way to make FreeBSD ignore this as well, let it > > > >> result in reasonable performance penalty. > > > > > > > > Very probably, if only we could detect where the problem is. > > > > Try adding "options PRINTF_BUFR_SIZE=128" to the kernel > > > > > > this option is already there > > > > The key word in Ivan's phrase is "less mangled". Neither use of or > > increasing PRINTF_BUFR_SIZE solves the problem of interspersed console > > output. I've been ranting/raving about this problem for years now; it > > truly looks like a mutex lock issue (or lack of such lock), but I've > > been told numerous times that isn't the case. > > > > To developers: what incentives would help get this issue well-needed > > attention? This problem makes kernel debugging, panic analysis, and > > other console-oriented viewing basically impossible. > > I was recently going to look at it. The somewhat drastic approach I was going > to take was to add a simple serializing lock around trap_fatal() and a few > other places that do similar block prints (e.g. mca_log()). One of the issues > with fixing this in printf itself is that you'd want probably want to > serialize complete lines of text on a per-thread basis. You would want to be > able to accumulate this line of text across multiple calls to printf (think of > it as line-buffering ala stdio). However, some folks may be nervous about > printf not printing things immediately. > > The other issue is that lots of code assumes it can call printf from anywhere > and everywhere. Mostly this just means that if you add locking and line- > buffering to printf(9) you have to be very careful to make sure it works in > odd places. Probably a lot of this could be solved by deferring things like > trap_fatal() until panic() has already been called (which is bde's preferred > solution I think). John, Thanks for the insights, they're greatly appreciated. I went looking this morning to see how Linux addressed this issue (if at all), and it's been discussed a few times in the past. The longest lkml thread I could find that mentioned the problem was circa 2002. Probably not worth reading as there was work done in 2009 to solve the issue. http://lkml.indiana.edu/hypermail/linux/kernel/0204.1/index.html#161 Work done by RedHat in 2009 details how they implemented a lockless version of their kernel ring buffer (similar to our system message buffer, but probably a lot more complex): http://lwn.net/Articles/340400/ http://lwn.net/Articles/340443/ Supposedly having multiple writers to the ring is 100% safe; no interspersed output. Same goes for interrupt-generated stuff. There's some comments in the technical document (2nd link) that imply there's an individual ring buffer for each CPU; possibly per-CPU kernel message buffers would solve our issue? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 21:55:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BABAF1065670 for ; Mon, 29 Mar 2010 21:55:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 45E6D8FC1C for ; Mon, 29 Mar 2010 21:55:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABu+sEuDaFvK/2dsb2JhbACbJ3G/f4UBBA X-IronPort-AV: E=Sophos;i="4.51,330,1267419600"; d="scan'208";a="70401664" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Mar 2010 17:55:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 4D520109C2E3; Mon, 29 Mar 2010 17:55:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV0n4wYpp0UJ; Mon, 29 Mar 2010 17:55:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id E167D109C2E1; Mon, 29 Mar 2010 17:55:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2TM8Jm15195; Mon, 29 Mar 2010 18:08:19 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Mar 2010 18:08:19 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jeremy Chadwick In-Reply-To: <20100329165647.GA3796@icarus.home.lan> Message-ID: References: <20100329165647.GA3796@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Strange NFS-related messages (related to lockd/statd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:55:05 -0000 On Mon, 29 Mar 2010, Jeremy Chadwick wrote: > > I can't find a definition of what the acronyms NLM and NSM stand for, > nor does Googling the error messages return relevant results (except one > FreeBSD committer reporting similar, but nobody replied). I don't know > the implications of these messages. > NLM - Network Lock Manager NSM - Network Status Monitor (I think?) These two protocols (separate from NFS) were what Sun implemented in the 1980s to provide locking on NFS mount points. Imho, these protocols were poorly designed: - The NLM allows blocking locks at the server, which can cause assorted nasty issues when the client crashes or gets network partitioned. - It also depended on the NSM to decide when machines were up/down and the NSM protocol basically did this in a rather poor way. A big part of NFSv4 was the integration of locking, in order to avoid use of the above. (As you might have guessed, lockd and statd implement the above two protocols. rick From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 22:26:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECADB106566C for ; Mon, 29 Mar 2010 22:26:42 +0000 (UTC) (envelope-from maurovale@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 7D4AE8FC12 for ; Mon, 29 Mar 2010 22:26:42 +0000 (UTC) Received: by bwz8 with SMTP id 8so5183891bwz.3 for ; Mon, 29 Mar 2010 15:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=mDXzCGzXmeGtADxBv3oX5JIKT/2o4nRCKl6BNFfxh+Y=; b=x12b9bcI15x19G7FyKFEFuOKJVNeoRY/oBA4rwUEuLcfXEfW6iVwjznRVo3t3EKkdW FFEI78AQjLanQb+VeSitFOKuwaT1YXdWlI5VEFswxsVqqJt8skatC5HTU4yVJODorimu W6m3JBL4wRPZ6ef30Mi8oKi2SxqaYeqzBiH94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KBQWLgQY3jlqBQ9dweJ0Iu82ABfti0d1yskCdEn4Xz55S7swYAA18Z9c+nPR+OHWjo G3xV4USmkf69Dl2eyXwKdYvcdTA8hu9LYdhbWX1w/BDE1wVtaSs9HXP0Rqq/rbmZHuOk AAfludaqKim3GuGaNEbnMd8nxEJlbGtS5ipss= MIME-Version: 1.0 Received: by 10.204.156.210 with HTTP; Mon, 29 Mar 2010 15:26:41 -0700 (PDT) Date: Mon, 29 Mar 2010 23:26:41 +0100 Received: by 10.204.175.9 with SMTP id v9mr2180335bkz.79.1269901601161; Mon, 29 Mar 2010 15:26:41 -0700 (PDT) Message-ID: <85d001331003291526l31b410a5jd1590f70eb3ac70f@mail.gmail.com> From: "M. Vale" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 8 and quotas on root partition error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 22:26:43 -0000 Hi, on FreeBSD 8.0 (i386 or AMD64) if we configure to use quotas on root partition. It stops on boot with the following message: Trying to mount root from ufs:/dev/ad0s1a mount option is unknown mount option is unknown ROOT MOUNT ERROR: mount option is unknown If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom=ufs:/dev/ad0s1a vfs.root.mountfrom.options=rw,userquota,groupquota,acls Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a eg. cd9660:/dev/acd0 This is equivalent to: mount -t cd9660 /dev/acd0 / ? List valid disk boot devices Abort manual input mountroot> If i do: ufs:/dev/ad0s1a Then the boot continues and it mount the quotas ok. but if I reboot the same thing happens again. This only occurs on FreeBSD 8. Does anyone have a clue about the problem ? Best Regards From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 09:56:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F9F51065672 for ; Tue, 30 Mar 2010 09:56:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 38E078FC1C for ; Tue, 30 Mar 2010 09:56:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NwWSU-000BDD-KZ for stable@freebsd.org; Tue, 30 Mar 2010 11:05:58 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 2010 11:05:58 +0300 From: Daniel Braniss Message-ID: Cc: Subject: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 09:56:34 -0000 hi, I have a this SBC that boots off a CF card, when it boots, I can select the boot partition via F1 or F2 and all is OK. when I do it via boot0cfg the 'default_selection' changes correctly, but the 'active' partition is not changed, so boot ignores it. I went ahead and changed boot0cfg.c to set the active partition and now I'm baffled: alix-3# ./boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 519: 15:63 63 524097 2 0x80 520: 0: 1 0xa5 1023: 15:63 524160 524160 ------+ 3 0x00 1023:255:63 0xa5 1023: 15:63 1048320 2951424 | | version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) | options=packet,update,nosetdrv | volume serial ID 0000-800f | default_selection=F2 (Slice 2) <--------------------------------------------+ so far so good. alix-3# ./boot0cfg -v -s1 ad0 ... 1 0x80 0: 1: 1 0xa5 519: 15:63 63 524097 ... default_selection=F1 (Slice 1) ok right? but no! ./boot0cfg -v ad0 ... 2 0x80 520: 0: 1 0xa5 1023: 15:63 524160 524160 ... default_selection=F1 (Slice 1) so it seems that someone is preventing changes to the partition table! btw, this problem was not present in older boot0 (1.0) where the active partition flag is ignored. help needed here! danny From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 10:18:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB07106566C for ; Tue, 30 Mar 2010 10:18:01 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id E38298FC1D for ; Tue, 30 Mar 2010 10:18:00 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 9DB0024750A; Tue, 30 Mar 2010 12:17:55 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 8.5113] X-CRM114-CacheID: sfid-20100330_12175_A3BE12FB X-CRM114-Status: Good ( pR: 8.5113 ) Message-ID: <4BB1CFD1.9040602@fsn.hu> Date: Tue, 30 Mar 2010 12:17:53 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> <20100329194131.GG1473@michelle.cdnetworks.com> In-Reply-To: <20100329194131.GG1473@michelle.cdnetworks.com> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Mar 30 12:17:55 2010 X-DSPAM-Confidence: 0.9936 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb1cfd3143412856173044 X-DSPAM-Factors: 27, X-Bogosity*Ham+tests=bogofilter, 0.00231, X-Bogosity*Ham, 0.00231, X-Spambayes-Classification*ham+0.00, 0.00262, X-Spambayes-Classification*0.00, 0.00262, X-CRM114-Status*Good+(, 0.00312, X-CRM114-Status*Good, 0.00312, X-Bogosity*spamicity=0.000000+version=1.2.1, 0.00361, X-Bogosity*tests=bogofilter+spamicity=0.000000, 0.00361, X-Bogosity*spamicity=0.000000, 0.00361, Url*freebsd, 0.00507, wrote, 0.00574, wrote, 0.00574, >+>, 0.00589, >+>, 0.00589, wrote+>, 0.00661, wrote+>, 0.00661, X-Spambayes-Classification*ham, 0.00813, Nagy+, Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 10:18:01 -0000 Pyun YongHyeon wrote: > On Mon, Mar 29, 2010 at 09:21:42PM +0200, Attila Nagy wrote: > >> Pyun YongHyeon wrote: >> >>> On Mon, Mar 29, 2010 at 12:57:59PM +0200, Attila Nagy wrote: >>> >>> >>>> Hi, >>>> >>>> Michael Loftis wrote: >>>> >>>> >>>>> --On Thursday, March 25, 2010 3:22 PM +0100 Attila Nagy >>>>> wrote: >>>>> >>>>> <...> >>>>> >>>>> >>>>>> Both unbound and python accepts DNS requests, and it seems when 25% >>>>>> interrupt happens, only unbound is in *udp state, where it is 50%, both >>>>>> programs are in that state. >>>>>> >>>>>> >>>>> Try turning of hardware TSO/checksum offload if it's availble on your >>>>> chipset? ifconfig -rxcsum -txcsum -tso -- I'm only using >>>>> nfe chips right now, but w/ the TSO/CSUM on they lock up constantly >>>>> under high load. We're pretty sure it's mostly the nfe driver, or the >>>>> chips themselves, but have never ruled out some generic 8.x hardware >>>>> offload issues. >>>>> >>>>> >>>> Bingo, this solved the problem. The current uptime nears four days. >>>> Previously I couldn't go further than a day. >>>> >>>> The machine gets very light TCP load (and other machines which get work >>>> well), so I guess it's UDP RX or TX checksum related. >>>> >>>> >>>> >>> Hmm, this is unexpected result. Since you're using UDP, TSO is not >>> involved in this issue. Because you disabled RX/TX checksum >>> offloading could you check how many number of 'bad checksum' and >>> and 'no checksum' you have from netstat(1)? >>> To narrow down which side of checksum offloading causes the issue, >>> would you just disable one side in a time? For instance, disable TX >>> checksum offloading with RX checksum offloading enabled and see how >>> bce(4) works. >>> #ifconfig bce0 -txcsum rxcsum >>> If that shows the same issue, try disabling RX checksum offloading >>> but enabling TX checksum offloading. >>> #ifconfig bce0 txcsum -rxcsum >>> >>> >> It's interesting. During the day, I've disabled only HW checksumming and >> left TSO enabled. It couldn't run more than a few hours. >> I have disabled tso again to see what happens. >> >> BTW, of course there is TCP traffic on that interface (DNS is also >> available on TCP), maybe this causes the problem. >> > > The only guess I can think of at this moment is incorrect use of > bus_dma(9) in TX path. But I'm not sure this is related with the > issue you're seeing. Would you try the experimental patch at the > following URL? > http://people.freebsd.org/~yongari/bce/bce.20100305.diff > Please make sure to back up your old bce(4) driver before applying > the patch. I didn't see any abnormal things in testing but it > wasn't much stressed. > With the default settings (rx, tx csum, tso) it froze in about an hour: CPU: 0.0% user, 0.0% nice, 0.0% system, 25.0% interrupt, 75.0% idle 714 bind 4 102 0 1200M 1182M *lle 3 17:24 0.00% unbound From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 10:25:13 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78C53106566B for ; Tue, 30 Mar 2010 10:25:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id 273BC8FC19 for ; Tue, 30 Mar 2010 10:25:12 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 37C8A6AD82BA; Tue, 30 Mar 2010 14:12:42 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1269943962; bh=pkDszKFTWfgRi0oK1eiQdj11tOspeoElqsV34FhnQJ0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rTMG+T6itEqu+sCknNh7Amsn/wi0jvJskuYOwGvYYWy7BHH7kfdv23/fgQNYGxDrZ PRgINwAjkQxveZgcFP8sOr17HtuK25CdWC00xWt58VKVCUXjs0Ro9u5/5uh0qKPpkF XfRwrNX8805qwc/sSoJjGkBpIB1hBhvHceUssDJU= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 452E5D18222; Tue, 30 Mar 2010 14:12:41 +0400 (MSD) Message-ID: <4BB1CE95.2090502@yandex.ru> Date: Tue, 30 Mar 2010 14:12:37 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Daniel Braniss References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1269943962 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.mail.yandex.net Cc: stable@freebsd.org Subject: Re: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 10:25:13 -0000 On 30.03.2010 12:05, Daniel Braniss wrote: > so it seems that someone is preventing changes to the partition table! > btw, this problem was not present in older boot0 (1.0) where the active > partition flag is ignored. You can change active partition via gpart(8). -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 11:03:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDA6D1065674 for ; Tue, 30 Mar 2010 11:03:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF4F8FC15 for ; Tue, 30 Mar 2010 11:03:42 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NwZER-000DPW-Mc; Tue, 30 Mar 2010 14:03:39 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Andrey V. Elsukov" In-reply-to: <4BB1CE95.2090502@yandex.ru> References: <4BB1CE95.2090502@yandex.ru> Comments: In-reply-to "Andrey V. Elsukov" message dated "Tue, 30 Mar 2010 14:12:37 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 2010 14:03:39 +0300 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org Subject: Re: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 11:03:42 -0000 > On 30.03.2010 12:05, Daniel Braniss wrote: > > so it seems that someone is preventing changes to the partition table! > > btw, this problem was not present in older boot0 (1.0) where the active > > partition flag is ignored. > > You can change active partition via gpart(8). > Hi Andrey, I'm sorry, I've reread the manual, and can't find the write magic. btw, boot0cfg does call geom but something seems to be broken. cheers, danny From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 12:39:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52E22106566B; Tue, 30 Mar 2010 12:39:54 +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 6360E8FC14; Tue, 30 Mar 2010 12:39:53 +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 PAA25516; Tue, 30 Mar 2010 15:39:50 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BB1F115.4020903@icyb.net.ua> Date: Tue, 30 Mar 2010 15:39:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: "M. Vale" References: <85d001331003291526l31b410a5jd1590f70eb3ac70f@mail.gmail.com> In-Reply-To: <85d001331003291526l31b410a5jd1590f70eb3ac70f@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-stable@freebsd.org Subject: Re: FreeBSD 8 and quotas on root partition error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 12:39:54 -0000 on 30/03/2010 01:26 M. Vale said the following: > Hi, on FreeBSD 8.0 (i386 or AMD64) if we configure to use quotas on root > partition. > > It stops on boot with the following message: > > Trying to mount root from ufs:/dev/ad0s1a > mount option is unknown > mount option is unknown > ROOT MOUNT ERROR: mount option is unknown > If you have invalid mount options, reboot, and first try the following from > > the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/ad0s1a > vfs.root.mountfrom.options=rw,userquota,groupquota,acls > > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:/dev/da0s1a > eg. cd9660:/dev/acd0 > > This is equivalent to: mount -t cd9660 /dev/acd0 / > > ? List valid disk boot devices > Abort manual input > > mountroot> > > > If i do: > > ufs:/dev/ad0s1a > > Then the boot continues and it mount the quotas ok. but if I reboot the same > thing happens again. > > This only occurs on FreeBSD 8. > > Does anyone have a clue about the problem ? Yes, it's a known problem. It is caused by you having userquota/groupquota options for root filesystem in your fstab. Previously it was OK, but it got broken when a new feature was implemented in r193192. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 14:30:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5752D1065673 for ; Tue, 30 Mar 2010 14:30:29 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-pz0-f199.google.com (mail-pz0-f199.google.com [209.85.222.199]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9FA8FC08 for ; Tue, 30 Mar 2010 14:30:28 +0000 (UTC) Received: by pzk37 with SMTP id 37so1438512pzk.7 for ; Tue, 30 Mar 2010 07:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GzNXMMPlZOt+Gwrq/HIT3qdiONRiSdoHPqJLNqg4qvQ=; b=Vq4F/6GS52rksbO77OBSYQp1YuoVpUIyxP2HMrn7yt9MZd7uISa6dHt8ofG+p6Cbni nfs8L/0Ud8JRmQBiqtWIBBrUr7JPTXx86nb1i3OcvFld9SQWzWRzJNoOVOholQMPYjD+ MbhgIUZuKVooFhZZjWUeP6gCf9Wp1zDqLDx9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=eoCDdoLBRk7S0FuHLNgfJX7IsGsiq07KcNSgVyfjdBmFaL3GnR8gYG/j5MWcW6jV// TmmOja/0OSWT8L73XHuxmlIuxzPwQlI6uM6jZttlhR2cP8yW5JYx5N1Vy4LnaX6BjUs/ Dug5zzh3biXHOZrVQX75EyvDj2KmQel5AQAqg= Received: by 10.142.1.2 with SMTP id 2mr474502wfa.73.1269959428447; Tue, 30 Mar 2010 07:30:28 -0700 (PDT) Received: from centel.dataix.local (adsl-99-109-124-168.dsl.klmzmi.sbcglobal.net [99.109.124.168]) by mx.google.com with ESMTPS id 23sm5148662iwn.14.2010.03.30.07.30.26 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 07:30:26 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BB20AED.70802@dataix.net> Date: Tue, 30 Mar 2010 10:30:05 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> In-Reply-To: <4BB0BC7C.3000801@barryp.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:30:29 -0000 On 03/29/2010 10:43, Barry Pederson wrote: > I've been using the arc_summary.pl script from here: > > http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl > > > and noticed some odd numbers, with the ARC Current Size being larger > than the Max Size, and the breakdown adding up to less than the current > size as shown below > > -------- > ARC Size: > Current Size: 992.71M (arcsize) > Target Size: (Adaptive) 512.00M (c) > Min Size (Hard Limit): 81.82M (arc_min) > Max Size (Hard Limit): 512.00M (arc_max) > > ARC Size Breakdown: > Recently Used Cache Size: 99.84% 511.18M (p) > Frequently Used Cache Size: 0.16% 0.82M (c-p) > -------- > > > From another thread I saw, it sounds like arc_max isn't really > a "Hard Limit" but rather some kind of high water mark. If that's > the case then I wonder if this might make more sense.... > > > > --------- > --- arc_summary.pl.original 2010-02-25 19:23:13.000000000 -0600 > +++ arc_summary.pl 2010-03-29 09:32:28.000000000 -0500 > @@ -121,20 +121,20 @@ > > my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size}; > my $arc_size_MiB = ($arc_size / 1048576); > -my $mfu_size = $target_size - $mru_size; > +my $mfu_size = $arc_size - $mru_size; > my $mfu_size_MiB = ($mfu_size / 1048576); > -my $mru_perc = 100*($mru_size / $target_size); > -my $mfu_perc = 100*($mfu_size / $target_size); > +my $mru_perc = 100*($mru_size / $arc_size); > +my $mfu_perc = 100*($mfu_size / $arc_size); > > print "ARC Size:\n"; > printf("\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n", $arc_size_MiB); > printf("\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n", $target_size_MiB); > printf("\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n", > $arc_min_size_MiB); > -printf("\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n", > $arc_max_size_MiB); > +printf("\tMax Size :\t\t\t%0.2fM (arc_max)\n", > $arc_max_size_MiB); > > print "\nARC Size Breakdown:\n"; > printf("\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n", $mru_perc, > $mru_size_MiB); > -printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n", > $mfu_perc, $mfu_size_MiB); > +printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n", > $mfu_perc, $mfu_size_MiB); > print "\n"; > > ### ARC Efficency ### > > ----------- > > > Giving something like this... > > -------- > ARC Size: > Current Size: 992.88M (arcsize) > Target Size: (Adaptive) 512.00M (c) > Min Size (Hard Limit): 81.82M (arc_min) > Max Size : 512.00M (arc_max) > > ARC Size Breakdown: > Recently Used Cache Size: 51.48% 511.18M (p) > Frequently Used Cache Size: 48.52% 481.70M (arcsize-p) > -------- > > Barry > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Ill mark this up on my todo. Thanks for the feedback & I should have something committed back within the next couple days, possibly even tonight. I never recalculated for this difference as that area of the code was just a formatting fix. But as Jeremy has pointed out, it would have to verify against __FreeBSD_version but since I already pull in the sysctl MIB kern.osreldate I should be able to compare to that and say 700000 or higher make the above correction. As this is mainly ZFS v13 dependent now I don't feel to bad doing what I have stated above. Thanks again, Regards, -- jhell From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 14:31:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89ADE106567B for ; Tue, 30 Mar 2010 14:31:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA078FC18 for ; Tue, 30 Mar 2010 14:31:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHyosUuDaFvH/2dsb2JhbACbLnG/VoUABA X-IronPort-AV: E=Sophos;i="4.51,334,1267419600"; d="scan'208";a="70496129" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Mar 2010 10:31:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 83DF810845DB; Tue, 30 Mar 2010 10:31:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T8CCA1ZYBCh; Tue, 30 Mar 2010 10:31:52 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 0445A10845D6; Tue, 30 Mar 2010 10:31:52 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2UEj9J23159; Tue, 30 Mar 2010 10:45:09 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 30 Mar 2010 10:45:09 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jeremy Chadwick In-Reply-To: <20100329165647.GA3796@icarus.home.lan> Message-ID: References: <20100329165647.GA3796@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Strange NFS-related messages (related to lockd/statd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 14:31:54 -0000 On Mon, 29 Mar 2010, Jeremy Chadwick wrote: > I recently brought up rpc.lockd and rpc.statd on all of our NFS clients > (mixed RELENG_6, RELENG_7, and RELENG_8), and our NFS server (RELENG_8). > > All clients had nfs_client_enable="yes" in rc.conf prior to their last > reboot, but lacked rpcbind_enable="yes", rpc_lockd_enable="yes", and > rpc_statd_enable="yes" prior to the below. > > The 8.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > NLM: failed to contact remote rpcbind, stat = 0, port = 0 > Can't start NLM - unable to contact NSM > > The 7.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > Can't start NLM - unable to contact NSM > Oh, I forgot to mention..I can't help much, but these protocols/daemons are SunRPC, so they will be using portmapper (now called rpcbind) to get port #s assigned dynamically. I also believe (not sure, don't know much about it) that the NSM will poll for other machines, so it needs to be able to talk to all clients and server(s), including doing IP broadcast that gets to them all. (These were designed in the 1980s for a LAN, which was just a chunk of coax in those days:-) Hope this helps, rick From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:21:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49C9C106564A for ; Tue, 30 Mar 2010 15:21:50 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5F68FC15 for ; Tue, 30 Mar 2010 15:21:49 +0000 (UTC) Received: from barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id 81A7523C2FD for ; Tue, 30 Mar 2010 10:21:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1269962508; bh=1afWAuV1T9tE740KphXe+8HiDdUGiGiX7r7ggSFGP7A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KnXwt2h/OreD sIpDL5BRNPIWhHlgEAMAC+ESM0ACyVh1S51holgU6ogb38CMY4N3fM5lfAFGsx/Sis6 BelgoXoJzaRQGQNIThiC6EneIDkqhS4Z+dzj59SXEwQGTnv+KH7l7jBjsaN3b1B46KN Cw24dySODhRcq3aA1hcvkY7/M= Received: from macbook.home ([10.66.1.10]) by barryp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1NwdGD-0006jV-PZ; Tue, 30 Mar 2010 10:21:46 -0500 Message-ID: <4BB21709.1070101@barryp.org> Date: Tue, 30 Mar 2010 10:21:45 -0500 From: Barry Pederson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: jhell References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> <4BB20AED.70802@dataix.net> In-Reply-To: <4BB20AED.70802@dataix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:21:50 -0000 On 3/30/10 9:30 AM, jhell wrote: > Ill mark this up on my todo. Thanks for the feedback& I should have > something committed back within the next couple days, possibly even tonight. > > I never recalculated for this difference as that area of the code was > just a formatting fix. > > But as Jeremy has pointed out, it would have to verify against > __FreeBSD_version but since I already pull in the sysctl MIB > kern.osreldate I should be able to compare to that and say 700000 or > higher make the above correction. > > As this is mainly ZFS v13 dependent now I don't feel to bad doing what I > have stated above. > > Thanks again, > > Regards, Shouldn't the "ARC Size Breakdown" be based on the current size (instead of the target size) no matter what? If the current size was *less* than arc_max, you'd also get an nonsensical breakdown - in that case with the "recently used" and "frequently used" adding up to *more* than the current size. It seems to me that the only thing that would be different between newer and older FreeBSD version would be whether arc_max would be described as a "Hard Limit" or not - which is maybe not that important to show. If that's all true, then the patch should work for both older and newer versions of FreeBSD. Barry From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:38:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DAC1065674 for ; Tue, 30 Mar 2010 15:38:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 7130E8FC1A for ; Tue, 30 Mar 2010 15:38:42 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id zNnY1d0031swQuc55Teils; Tue, 30 Mar 2010 15:38:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.westchester.pa.mail.comcast.net with comcast id zTiv1d00L3S48mS3bTiwrr; Tue, 30 Mar 2010 15:42:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F2E089B419; Tue, 30 Mar 2010 08:38:39 -0700 (PDT) Date: Tue, 30 Mar 2010 08:38:39 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20100330153839.GA32700@icarus.home.lan> References: <20100329165647.GA3796@icarus.home.lan> 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-stable@freebsd.org Subject: Re: Strange NFS-related messages (related to lockd/statd) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:38:42 -0000 On Tue, Mar 30, 2010 at 10:45:09AM -0400, Rick Macklem wrote: > > > On Mon, 29 Mar 2010, Jeremy Chadwick wrote: > > >I recently brought up rpc.lockd and rpc.statd on all of our NFS clients > >(mixed RELENG_6, RELENG_7, and RELENG_8), and our NFS server (RELENG_8). > > > >All clients had nfs_client_enable="yes" in rc.conf prior to their last > >reboot, but lacked rpcbind_enable="yes", rpc_lockd_enable="yes", and > >rpc_statd_enable="yes" prior to the below. > > > >The 8.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > > >NLM: failed to contact remote rpcbind, stat = 0, port = 0 > >Can't start NLM - unable to contact NSM > > > >The 7.x clients started rpcbind, rpc.lockd, rpc.statd -- then said: > > > >Can't start NLM - unable to contact NSM > > > Oh, I forgot to mention..I can't help much, but these protocols/daemons > are SunRPC, so they will be using portmapper (now called rpcbind) to get > port #s assigned dynamically. I also believe (not sure, don't know much > about it) that the NSM will poll for other machines, so it needs to be > able to talk to all clients and server(s), including doing IP broadcast > that gets to them all. (These were designed in the 1980s for a LAN, which > was just a chunk of coax in those days:-) > > Hope this helps, rick In fact it did! Your hint lead me to try my earlier idea: using the -h flag to rpcbind. Turns out lockd wasn't running on any of the systems (rpcinfo didn't show it, and ps didn't show it). I ended up modifying all of the boxes to use: rpcbind_flags="-h " (Where em1=LAN, em0=WAN. em0 contains the default route as well) Restarted rpcbind + statd + lockd (in that order). Voila, everything started up, and no messages. rpcinfo shows all correct services. So my guess is that by binding to INADDR_ANY by default, packets were going out the primary interface (em0) or going to broadcast on em0 -- which would return nothing, since pf blocked such packets. Makes sense to me anyway. Thanks! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:45:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A72FD106564A for ; Tue, 30 Mar 2010 15:45:38 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward9.mail.yandex.net (forward9.mail.yandex.net [77.88.61.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5305F8FC15 for ; Tue, 30 Mar 2010 15:45:38 +0000 (UTC) Received: from web103.yandex.ru (web103.yandex.ru [77.88.61.4]) by forward9.mail.yandex.net (Yandex) with ESMTP id 4BFF11900059; Tue, 30 Mar 2010 19:44:11 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1269963851; bh=/DTGzhUsKnoznFP3rxe19Bx3VEDXEw7G0aYPI/Cs28Y=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=cit95XLpTohXPfZ17zthf8votW3BUFDxlO0+DF1OcV+5heG5hUj1WqMfwcSBT69Sj uyG4+FgemX+dXJK/8VDsKCuT1oFQzKlG8BCWfSAQ99kRm8gZ9bpx51qSerJbbEuASP g7kwY5+S2REG2fSpywsj5rmL7Sg8Vf85ISMh7T1Y= Received: from localhost (localhost.localdomain [127.0.0.1]) by web103.yandex.ru (Yandex) with ESMTP id 3F5D01D5808C; Tue, 30 Mar 2010 19:44:11 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web103.yandex.ru X-Yandex-TimeMark: 1269963851 Received: from ns.heavennet.ru (ns.heavennet.ru [77.72.136.193]) by mail.yandex.ru with HTTP; Tue, 30 Mar 2010 19:44:10 +0400 From: Andrey V. Elsukov To: Daniel Braniss In-Reply-To: References: <4BB1CE95.2090502@yandex.ru> MIME-Version: 1.0 Message-Id: <73161269963850@web103.yandex.ru> Date: Tue, 30 Mar 2010 19:44:10 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-stable@freebsd.org Subject: Re: Re: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:45:38 -0000 30.03.10, 14:03, "Daniel Braniss" : > > On 30.03.2010 12:05, Daniel Braniss wrote: > > > so it seems that someone is preventing changes to the partition table! > > > btw, this problem was not present in older boot0 (1.0) where the active > > > partition flag is ignored. > > > > You can change active partition via gpart(8). > > > Hi Andrey, > I'm sorry, I've reread the manual, and can't find the write magic. Yes, i also doesn't remember where it can be read. Only in g_part_mbr.c :) Try this: # gpart set -a active -i 1 ada2 This will set active first partition on ada2: # gpart show ada2 => 63 1250263665 ada2 MBR (596G) 63 40965687 1 !7 [active] (20G) 40965750 1209292875 2 !7 (577G) 1250258625 5103 - free - (2.5M) > btw, boot0cfg does call geom but something seems to be broken. I'll look boot0cfg code today and probably made a patch. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:50:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A20106566C for ; Tue, 30 Mar 2010 15:50:33 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with SMTP id 095418FC0C for ; Tue, 30 Mar 2010 15:50:32 +0000 (UTC) Received: (qmail 45130 invoked from network); 30 Mar 2010 15:50:31 -0000 Received: from unknown (HELO oberon.njm.me.uk) (86.140.74.12) by smtp004.apm-internet.net with SMTP; 30 Mar 2010 15:50:31 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.4/8.14.4) with ESMTP id o2UFoUx7038884; Tue, 30 Mar 2010 16:50:30 +0100 (BST) (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.4/8.14.4) with ESMTP id o2UFoUh3033559; Tue, 30 Mar 2010 16:50:30 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.4/8.14.4/Submit) id o2UFoUH9033552; Tue, 30 Mar 2010 16:50:30 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Tue, 30 Mar 2010 16:50:30 +0100 From: "N.J. Mann" To: "Andrey V. Elsukov" Message-ID: <20100330155030.GA6139@titania.njm.me.uk> Mail-Followup-To: "Andrey V. Elsukov" , Daniel Braniss , freebsd-stable@freebsd.org References: <4BB1CE95.2090502@yandex.ru> <73161269963850@web103.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73161269963850@web103.yandex.ru> X-Operating-System: FreeBSD 7.3-STABLE User-Agent: mutt-NJM (2009-12-30) Cc: freebsd-stable@freebsd.org Subject: Re: Re: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:50:33 -0000 In message <73161269963850@web103.yandex.ru>, Andrey V. Elsukov (bu7cher@yandex.ru) wrote: > 30.03.10, 14:03, "Daniel Braniss" : > > > > On 30.03.2010 12:05, Daniel Braniss wrote: > > > > so it seems that someone is preventing changes to the partition table! > > > > btw, this problem was not present in older boot0 (1.0) where the active > > > > partition flag is ignored. > > > > > > You can change active partition via gpart(8). > > > > > Hi Andrey, > > I'm sorry, I've reread the manual, and can't find the write magic. > > Yes, i also doesn't remember where it can be read. Only in g_part_mbr.c :) > Try this: > # gpart set -a active -i 1 ada2 > This will set active first partition on ada2: > # gpart show ada2 > => 63 1250263665 ada2 MBR (596G) > 63 40965687 1 !7 [active] (20G) > 40965750 1209292875 2 !7 (577G) > 1250258625 5103 - free - (2.5M) > > > btw, boot0cfg does call geom but something seems to be broken. > I'll look boot0cfg code today and probably made a patch. Do you need to disable the geom anti-foot-shooting feature? I seem to remember it is something like: sysctl kern.geom.debugflags=16 Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 15:57:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5914A106568A for ; Tue, 30 Mar 2010 15:57:51 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 189F38FC17 for ; Tue, 30 Mar 2010 15:57:49 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 7E230247650; Tue, 30 Mar 2010 17:57:47 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 5.2461] X-CRM114-CacheID: sfid-20100330_17574_A761ED52 X-CRM114-Status: Good ( pR: 5.2461 ) Message-ID: <4BB21F79.5060807@fsn.hu> Date: Tue, 30 Mar 2010 17:57:45 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jonathan Feally References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> <20100329194131.GG1473@michelle.cdnetworks.com> <4BB1CFD1.9040602@fsn.hu> <4BB21EA7.4080107@netvulture.com> In-Reply-To: <4BB21EA7.4080107@netvulture.com> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Mar 30 17:57:47 2010 X-DSPAM-Confidence: 0.9929 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb21f7b978751840297497 X-DSPAM-Factors: 27, X-Bogosity*Ham+tests=bogofilter, 0.00231, X-Bogosity*Ham, 0.00231, X-Spambayes-Classification*ham+0.00, 0.00262, X-Spambayes-Classification*0.00, 0.00262, X-CRM114-Status*Good+(, 0.00312, X-CRM114-Status*Good, 0.00312, X-Bogosity*spamicity=0.000000+version=1.2.1, 0.00361, X-Bogosity*tests=bogofilter+spamicity=0.000000, 0.00361, X-Bogosity*spamicity=0.000000, 0.00361, wrote, 0.00574, wrote, 0.00574, wrote+>, 0.00661, X-Spambayes-Classification*ham, 0.00813, I+remember, 0.01000, in+3, 0.01000, lock, 0.01000, I+guess, 0.01000, a+short, 0.01000, solved, 0.01000, X-Stationery*0.4.10, 0.01000, I've+had, 0.01000, >+I, 0.01000, see+if, 0.01000, guess, 0.01000, I+haven't, 0.01000, haven't, 0.01000, Well, 0.01000 Cc: pyunyh@gmail.com, Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:57:51 -0000 Jonathan Feally wrote: > Attila Nagy wrote: >>>>>> Bingo, this solved the problem. The current uptime nears four days. >>>>>> Previously I couldn't go further than a day. >>>>>> >>>>>> The machine gets very light TCP load (and other machines which >>>>>> get work >>>>>> well), so I guess it's UDP RX or TX checksum related >>>>>> > I also have had my network go dead on a recent 8.0-STABLE on bge > system. Console is alive, but network just stops. I am running it as a > router with untagged on bge0 and nat of traffic on vlan201 tagged on > top of bge1. I haven't had it lock up in 3 days, but I will try the > -txcsum and -rxcsum on both interfaces to see if the problem still > persists or not. I do have a lot of tcp traffic, but there is also > unsolicited udp flying in as well. Well, it's a short time to judge from, but with rx,txcsum disabled, the machine froze nearly instantly (less than one hour of uptime), while with tso disabled, it still works. So for now I think tso causes the problems. BTW, now that we are talking about that, I remember that I've disabled it on a lot of machines previously, because I've had strange issues. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 16:09:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF69F106564A for ; Tue, 30 Mar 2010 16:09:36 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (mail.consult-scs.com [173.164.138.150]) by mx1.freebsd.org (Postfix) with ESMTP id 906948FC0C for ; Tue, 30 Mar 2010 16:09:36 +0000 (UTC) Received: from [127.0.0.1] (coolman.netvulture.com [173.164.138.145]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPSA id 87BE62F2B304; Tue, 30 Mar 2010 08:54:15 -0700 (PDT) Message-ID: <4BB21EA7.4080107@netvulture.com> Date: Tue, 30 Mar 2010 08:54:15 -0700 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Attila Nagy References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> <20100329194131.GG1473@michelle.cdnetworks.com> <4BB1CFD1.9040602@fsn.hu> In-Reply-To: <4BB1CFD1.9040602@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 87BE62F2B304.5238B X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-201.211, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, FH_DATE_PAST_20XX 3.19, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: pyunyh@gmail.com, Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:09:36 -0000 Attila Nagy wrote: >>>>> Bingo, this solved the problem. The current uptime nears four days. >>>>> Previously I couldn't go further than a day. >>>>> >>>>> The machine gets very light TCP load (and other machines which get work >>>>> well), so I guess it's UDP RX or TX checksum related >>>>> I also have had my network go dead on a recent 8.0-STABLE on bge system. Console is alive, but network just stops. I am running it as a router with untagged on bge0 and nat of traffic on vlan201 tagged on top of bge1. I haven't had it lock up in 3 days, but I will try the -txcsum and -rxcsum on both interfaces to see if the problem still persists or not. I do have a lot of tcp traffic, but there is also unsolicited udp flying in as well. -Jon -- Scanned for viruses and dangerous content by MailScanner From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 16:48:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D09F1065670 for ; Tue, 30 Mar 2010 16:48:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 48E548FC15 for ; Tue, 30 Mar 2010 16:48:54 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NwecW-000G8V-SC; Tue, 30 Mar 2010 19:48:52 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Andrey V. Elsukov" In-reply-to: <73161269963850@web103.yandex.ru> References: <4BB1CE95.2090502@yandex.ru> <73161269963850@web103.yandex.ru> Comments: In-reply-to Andrey V. Elsukov message dated "Tue, 30 Mar 2010 19:44:10 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 2010 19:48:52 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: boot and boot0cfg problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:48:54 -0000 > 30.03.10, 14:03, "Daniel Braniss" : > > > > On 30.03.2010 12:05, Daniel Braniss wrote: > > > > so it seems that someone is preventing changes to the partition table! > > > > btw, this problem was not present in older boot0 (1.0) where the active > > > > partition flag is ignored. > > > > > > You can change active partition via gpart(8). > > > > > Hi Andrey, > > I'm sorry, I've reread the manual, and can't find the write magic. > > Yes, i also doesn't remember where it can be read. Only in g_part_mbr.c :) > Try this: > # gpart set -a active -i 1 ada2 > This will set active first partition on ada2: > # gpart show ada2 > => 63 1250263665 ada2 MBR (596G) > 63 40965687 1 !7 [active] (20G) > 40965750 1209292875 2 !7 (577G) > 1250258625 5103 - free - (2.5M) > > > btw, boot0cfg does call geom but something seems to be broken. > I'll look boot0cfg code today and probably made a patch. ok, that worked! now if you can get boot0cfg to work that would realy be nice. thanks, danny From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 18:08:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ABF7106566C for ; Tue, 30 Mar 2010 18:08:13 +0000 (UTC) (envelope-from pyunyh@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 C34EB8FC18 for ; Tue, 30 Mar 2010 18:08:12 +0000 (UTC) Received: by bwz8 with SMTP id 8so5859982bwz.3 for ; Tue, 30 Mar 2010 11:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=p+ObYbxLOCKlgPmBU+7cphQbmcmpixen7wOi5G/gbtE=; b=Kjp/9cDZvSpoDzxx45fCAO7i5VGfhOrLf/YT+meHL8DuiXSKjb/0g8ReKcOKIgcqSS C+395thPEMPwS1w2qcHbaMR1+Qh347g3/uqWAhCJf0KWvIw8cY7JyNjZI0chu6ob9uEM veVvkrnHQKTF6u/eXr7WBh7iR8ZHyfqw8/L1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=R0CHv2Dv9Aea/pxXD2omxDpgO6O82hbhIxLhYtO5Rf/bVEwsUcdEu59crCN0wum42j eowmwB0paz/WRwK6kJ7h9kO+fNKkgwzZqViZT0XsAgSDBJWIRT6KJQZFdCVYjkzDolPq Tl6oLhY0A5ZrLCEldQphp7isTcxMrbdI2Z8ho= Received: by 10.204.136.208 with SMTP id s16mr2183046bkt.20.1269972491123; Tue, 30 Mar 2010 11:08:11 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 16sm2967539bwz.13.2010.03.30.11.08.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 11:08:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 30 Mar 2010 11:07:10 -0700 From: Pyun YongHyeon Date: Tue, 30 Mar 2010 11:07:10 -0700 To: Attila Nagy Message-ID: <20100330180710.GM1473@michelle.cdnetworks.com> References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> <20100329194131.GG1473@michelle.cdnetworks.com> <4BB1CFD1.9040602@fsn.hu> <4BB21EA7.4080107@netvulture.com> <4BB21F79.5060807@fsn.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB21F79.5060807@fsn.hu> User-Agent: Mutt/1.4.2.3i Cc: Jonathan Feally , Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 18:08:13 -0000 On Tue, Mar 30, 2010 at 05:57:45PM +0200, Attila Nagy wrote: > Jonathan Feally wrote: > > Attila Nagy wrote: > >>>>>> Bingo, this solved the problem. The current uptime nears four days. > >>>>>> Previously I couldn't go further than a day. > >>>>>> > >>>>>> The machine gets very light TCP load (and other machines which > >>>>>> get work > >>>>>> well), so I guess it's UDP RX or TX checksum related > >>>>>> > > I also have had my network go dead on a recent 8.0-STABLE on bge > > system. Console is alive, but network just stops. I am running it as a > > router with untagged on bge0 and nat of traffic on vlan201 tagged on > > top of bge1. I haven't had it lock up in 3 days, but I will try the > > -txcsum and -rxcsum on both interfaces to see if the problem still > > persists or not. I do have a lot of tcp traffic, but there is also > > unsolicited udp flying in as well. > Well, it's a short time to judge from, but with rx,txcsum disabled, the > machine froze nearly instantly (less than one hour of uptime), while > with tso disabled, it still works. > So for now I think tso causes the problems. > BTW, now that we are talking about that, I remember that I've disabled > it on a lot of machines previously, because I've had strange issues. Would you show me the dmesg output(only bce(4) part)? From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 20:13:36 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14B861065689; Tue, 30 Mar 2010 20:13:36 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 742C48FC0C; Tue, 30 Mar 2010 20:13:35 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o2UKDXBh069250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 22:13:34 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4BB25B53.80303@omnilan.de> Date: Tue, 30 Mar 2010 22:13:07 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B8E1489.2070306@omnilan.de> <4B8E1B3D.306@FreeBSD.org> <4BB07BF7.6070602@omnilan.de> <4BB0FEA9.5000104@FreeBSD.org> In-Reply-To: <4BB0FEA9.5000104@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA21F5388F7B746D8618C51B3" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 20:13:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA21F5388F7B746D8618C51B3 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 29.03.2010 21:25 (localtime): > Harald Schmalzbauer wrote: >> I have the drives now running in another server, ich7 chipset. >> Using UFS, the complete machine locks up for ~30 secs with disk load o= f >> 3.5MB/s. But I don't get any timeout messages and the machine always >> recovered. >=20 > Most of ICH7's do not support AHCI. What's about your's? It does, it's a FujitsuSiemens Server and has ERST-II (LSI Software=20 RAID) along with AHCI. >> Changing to the old ata driver solves the problem. =2E.. >> Any chance to get this problem fixed? I couldn't see lockups on anothe= r >> OS with NCQ in AHCI mode enabled. I'd ship such a disk to anyone who i= s >> willing to debug. >=20 > It's difficult to fix something, until problem could be reproduced. I understand! The machine lock @3.5MB/s was wrong, sorry. Not the HD was the culprit=20 but an intermediate router... But still there is the problem that ZFS stalls if I use these drives=20 with ahci, not with ataahci. > If you wish to send drive - my address is: > Topol-2, b34, f150, Dnepropetrovsk, 49040, Ukraine. > Phone: +380503622312. > Do not use courier services, only regular mail. Ask for tracking number= =2E Can you use such a drive? I mean for yourself. If yes, then I'll ship=20 it, but if you say "na, thanks, no such crap" then I don't want to waste = your time and highly appreciated skills to bother with vendor-specific=20 problems. Thnaks, -Harry --=20 OmniLAN - UNIX & Windows Netze + Systeme Harald Schmalzbauer Flintsbacher Str. 3 80686 M=FCnchen +49 (0) 89 18947781 +49 (0) 160 93860101 USt-IdNr.: DE253184753 http:/www.omnilan.de/ --------------enigA21F5388F7B746D8618C51B3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuyW20ACgkQLDqVQ9VXb8iAhwCgw9UG9ZOz4JeJQPjvZWPAk2Bb OnQAoLAJIrmCSL4b4cF1J5yN57XcaOcM =NbmU -----END PGP SIGNATURE----- --------------enigA21F5388F7B746D8618C51B3-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 30 21:04:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB7F81065702 for ; Tue, 30 Mar 2010 21:04:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 457B78FC27 for ; Tue, 30 Mar 2010 21:04:16 +0000 (UTC) Received: by fxm25 with SMTP id 25so203446fxm.3 for ; Tue, 30 Mar 2010 14:04:16 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=horwjj7bSrpNIn2COW3dmjYr93/fBQ+vKZsY/zN1Juk=; b=hWdiFPiWocSFcGDA6AOdJ/sl/n2R/0QvPmgpXggjYtUG8iUmxWHXjRnTnAeLbwnNzf tFA9wteM/1jxd6ivNN7NN2og2YbR+PXf7PEXYR8ijHM1lUwLKv9UczqaYl+tgRGXG1O8 JbtBlIpR1MoSK0eYsdF93J+93NUD+dMO9IHss= 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:x-enigmail-version:content-type :content-transfer-encoding; b=wpp13Ag5mBzA37GDHb0WfUN0LXkZJLfXtht/paqVt41leS5nFZD4Z3cz0wgtomkknU GlHIL5ca1D1VSjwV4pYw+nZadKDOk81teYCgWDmRt20xkQWNTl6sTql9P8uq+JsuJBhe OLbrrdFRcb0Pqo7RUL+v8pnFtEWptIyyiHHn8= Received: by 10.87.50.37 with SMTP id c37mr1712624fgk.68.1269983056041; Tue, 30 Mar 2010 14:04:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm4317710fxm.13.2010.03.30.14.04.14 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 14:04:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BB2674D.8090904@FreeBSD.org> Date: Wed, 31 Mar 2010 00:04:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B8E1489.2070306@omnilan.de> <4B8E1B3D.306@FreeBSD.org> <4BB07BF7.6070602@omnilan.de> <4BB0FEA9.5000104@FreeBSD.org> <4BB25B53.80303@omnilan.de> In-Reply-To: <4BB25B53.80303@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 21:04:17 -0000 Harald Schmalzbauer wrote: > Alexander Motin schrieb am 29.03.2010 21:25 (localtime): >> If you wish to send drive - my address is: > > Can you use such a drive? I mean for yourself. If yes, then I'll ship > it, but if you say "na, thanks, no such crap" then I don't want to waste > your time and highly appreciated skills to bother with vendor-specific > problems. I have enough drives, so I don't really need one more. If it is really vendor-specific problem (looking on messages I don't have much doubts) then I am not sure I can do much to it, except just making sure that error recovery code handles situation well and writing some quirks to somehow workaround problem for this particular drive, if it is possible. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 31 08:40:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A031106564A for ; Wed, 31 Mar 2010 08:40:55 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id AE19E8FC0A for ; Wed, 31 Mar 2010 08:40:54 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id B50FC2495BE; Wed, 31 Mar 2010 10:40:52 +0200 (CEST) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 5.2988] X-CRM114-CacheID: sfid-20100331_10405_744F7D04 X-CRM114-Status: Good ( pR: 5.2988 ) Message-ID: <4BB30A90.1030605@fsn.hu> Date: Wed, 31 Mar 2010 10:40:48 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4BAB718C.3090001@fsn.hu> <886B21E1787F0003B89E34B6@[192.168.1.44]> <4BB087B7.3030602@fsn.hu> <20100329183848.GE1473@michelle.cdnetworks.com> <4BB0FDC6.7050105@fsn.hu> <20100329194131.GG1473@michelle.cdnetworks.com> <4BB1CFD1.9040602@fsn.hu> <4BB21EA7.4080107@netvulture.com> <4BB21F79.5060807@fsn.hu> <20100330180710.GM1473@michelle.cdnetworks.com> In-Reply-To: <20100330180710.GM1473@michelle.cdnetworks.com> X-Stationery: 0.4.10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.1 X-Spambayes-Classification: ham; 0.00 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Mar 31 10:40:52 2010 X-DSPAM-Confidence: 0.9936 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4bb30a94207551815818377 X-DSPAM-Factors: 27, X-Bogosity*Ham+tests=bogofilter, 0.00199, X-Bogosity*Ham, 0.00199, X-Spambayes-Classification*ham+0.00, 0.00225, X-Spambayes-Classification*0.00, 0.00225, X-CRM114-Status*Good, 0.00270, X-CRM114-Status*Good+(, 0.00270, X-Bogosity*spamicity=0.000000+version=1.2.1, 0.00311, X-Bogosity*tests=bogofilter+spamicity=0.000000, 0.00311, X-Bogosity*spamicity=0.000000, 0.00311, wrote, 0.00488, wrote, 0.00488, >+>, 0.00500, wrote+>, 0.00559, wrote+>, 0.00559, X-Spambayes-Classification*ham, 0.00699, 2010+at, 0.00906, I+remember, 0.01000, in+3, 0.01000, lock, 0.01000, I+guess, 0.01000, Ethernet, 0.01000, Ethernet, 0.01000, a+short, 0.01000, solved, 0.01000, dmesg, 0.01000, X-Stationery*0.4.10, 0.01000, I've+had, 0.01000 Cc: Jonathan Feally , Mailing List FreeBSD Stable , Michael Loftis Subject: Re: 8-STABLE freezes on UDP traffic (DNS), 7.x doesn't X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 08:40:55 -0000 Pyun YongHyeon wrote: > On Tue, Mar 30, 2010 at 05:57:45PM +0200, Attila Nagy wrote: > >> Jonathan Feally wrote: >> >>> Attila Nagy wrote: >>> >>>>>>>> Bingo, this solved the problem. The current uptime nears four days. >>>>>>>> Previously I couldn't go further than a day. >>>>>>>> >>>>>>>> The machine gets very light TCP load (and other machines which >>>>>>>> get work >>>>>>>> well), so I guess it's UDP RX or TX checksum related >>>>>>>> >>>>>>>> >>> I also have had my network go dead on a recent 8.0-STABLE on bge >>> system. Console is alive, but network just stops. I am running it as a >>> router with untagged on bge0 and nat of traffic on vlan201 tagged on >>> top of bge1. I haven't had it lock up in 3 days, but I will try the >>> -txcsum and -rxcsum on both interfaces to see if the problem still >>> persists or not. I do have a lot of tcp traffic, but there is also >>> unsolicited udp flying in as well. >>> >> Well, it's a short time to judge from, but with rx,txcsum disabled, the >> machine froze nearly instantly (less than one hour of uptime), while >> with tso disabled, it still works. >> So for now I think tso causes the problems. >> BTW, now that we are talking about that, I remember that I've disabled >> it on a lot of machines previously, because I've had strange issues. >> > > Would you show me the dmesg output(only bce(4) part)? > Sure: bce0: mem 0xfa000000-0xfbffffff irq 16 at device 0.0 on pci7 miibus0: on bce0 brgphy0: PHY 2 on miibus0 brgphy0: 1000baseSX-FDX, 2500baseSX-FDX, auto bce0: Ethernet address: 00:1b:78:75:f0:34 bce0: [ITHREAD] bce0: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.4.1); Flags (MSI|2.5G) bce1: mem 0xf6000000-0xf7ffffff irq 16 at device 0.0 on pci3 miibus1: on bce1 brgphy1: PHY 2 on miibus1 brgphy1: 1000baseSX-FDX, 2500baseSX-FDX, auto bce1: Ethernet address: 00:1b:78:75:f0:38 bce1: [ITHREAD] bce1: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.4.1); Flags (MSI|2.5G) The NIC's firmware is up to date (latest available on HP firmware update CD). From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 04:30:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D1DE01065677 for ; Thu, 1 Apr 2010 04:30:21 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id BFE5C14E7D0 for ; Thu, 1 Apr 2010 04:30:20 +0000 (UTC) Received: (qmail 23232 invoked from network); 1 Apr 2010 04:30:20 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 1 Apr 2010 04:30:20 -0000 Message-ID: <4BB4215C.5080600@freebsd.org> Date: Wed, 31 Mar 2010 21:30:20 -0700 From: FreeBSD Security Officer Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: freebsd security , FreeBSD Stable X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: HEADS UP: FreeBSD 7.2 EoL coming soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 04:30:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On June 30th, FreeBSD 7.2 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of this release are strongly encouraged to upgrade to FreeBSD 7.3 before that date; FreeBSD 7.3 will be supported until the end of March 2012. Please note that since FreeBSD 7.1 has been designated for 'Extended' support, it will continue to be supported until the end of January 2011, i.e., FreeBSD 7.1 will be supported longer than FreeBSD 7.2. The End of Life date for FreeBSD 7.2 was originally announced as May 31, but was delayed by one month in accordance with Security Team policy in order to allow a 3 month window between the release of FreeBSD 7.3 and the End of Life of FreeBSD 7.2 to allow time for systems to be upgraded. The freebsd-update(8) utility can be used to upgrade i386 and amd64 systems from 7.2-RELEASE (or 7.2-RELEASE-pX for some X) to 7.3-RELEASE using binary updates (i.e., without compiling from source) as described in the 7.3-RELEASE announcement; given an adequate internet connection, this process usually takes 15 minutes or less. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |June 30, 2010 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |-----------+------------+--------+-----------------+-----------------| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_8_1 |8.1-RELEASE |Extended|not yet |release + 2 years| +---------------------------------------------------------------------+ For clarity, this is NOT an April Fool's joke. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku0IVsACgkQFdaIBMps37LAGACdEQ5AqnrYOV4/6mLp+F3DB/Fo HIEAniOFbb+YCYdJVT2G1CdGpmpHA1gE =ssY3 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 15:07:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00F1106566B for ; Thu, 1 Apr 2010 15:07:44 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from mxsf02.insightbb.com (mxsf02.insightbb.com [74.128.0.63]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4F28FC1A for ; Thu, 1 Apr 2010 15:07:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,348,1267419600"; d="scan'208";a="745467891" Received: from unknown (HELO asav01.insightbb.com) ([172.31.249.123]) by mxsf02.insightbb.com with ESMTP; 01 Apr 2010 11:07:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFADdTtEtKgYlR/2dsb2JhbACIbIZfi3JytX0NhHQE X-IronPort-AV: E=Sophos;i="4.51,348,1267419600"; d="scan'208";a="252596067" Received: from 74-129-137-81.dhcp.insightbb.com (HELO sneezy) ([74.129.137.81]) by asav01.insightbb.com with SMTP; 01 Apr 2010 11:07:43 -0400 From: "David Boyd" To: Date: Thu, 1 Apr 2010 11:07:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: 6.4-RELEASE missing from mirrors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:07:44 -0000 The link (actually file) called "6.4 moved to ftp-archive" is missing from most/all mirrors. We have been using these files to "follow" the releases when they move. It works as long as the "6.4 moved to ftp-archive" file is present. Please help. Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 17:17:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72091065673 for ; Thu, 1 Apr 2010 17:17:48 +0000 (UTC) (envelope-from office@rentbeo.com) Received: from e11mailgw05.isp.nadlanu.com (e11mailgw05.isp.nadlanu.com [212.200.12.198]) by mx1.freebsd.org (Postfix) with ESMTP id 26D4B8FC12 for ; Thu, 1 Apr 2010 17:17:43 +0000 (UTC) Message-Id: <85jssn$hv5ng@e12mailgw05.isp.nadlanu.com> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIMAKtqtEtPZfHe/2dsb2JhbABvT4QKiXaJZIFJBwVGcogasm4E X-IronPort-AV: E=McAfee;i="5400,1158,5937"; a="18847472" Received: from 79-101-241-222.dynamic.isp.telekom.rs (HELO ougb2) ([79.101.241.222]) by e12mailgw05.isp.nadlanu.com with ESMTP; 01 Apr 2010 18:47:06 +0200 From: "RentBEO Apartments in Belgrade" To: freebsd-stable@freebsd.org Content-Type: multipart/related; type="multipart/alternative"; boundary="=_NextPart_2relrfksadvnqindyw3nerasdf"; charset="iso-8859-1" MIME-Version: 1.0 Date: Thu, 1 Apr 2010 18:47:18 +0200 X-Priority: 3 X-Antivirus: avast! (VPS 100401-0, 04/01/2010), Outbound message X-Antivirus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Rent in Belgrade // Short term accommodation X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: office@rentbeo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 17:17:48 -0000 This is a multi-part message in MIME format --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="logo_beorent.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="logo_beorent.jpg" Content-Id: <33997-212384848823204@3024174> /9j/4AAQSkZJRgABAQEASABIAAD/4TIdaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBt ZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA0LjEt YzAzNCA0Ni4yNzI5NzYsIFNhdCBKYW4gMjcgMjAwNyAyMjozNzozNyAgICAgICAgIj4KICAgPHJk ZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1s bnM6eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVh dG9yVG9vbD5BZG9iZSBGaXJld29ya3MgQ1MzPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4 YXA6Q3JlYXRlRGF0ZT4yMDA5LTEwLTI0VDE3OjQyOjE5WjwveGFwOkNyZWF0ZURhdGU+CiAgICAg ICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA5LTEwLTI0VDE3OjQyOjQ0WjwveGFwOk1vZGlmeURhdGU+ CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEu MS8iPgogICAgICAgICA8ZGM6Zm9ybWF0PmltYWdlL2pwZWc8L2RjOmZvcm1hdD4KICAgICAgPC9y ZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz7/2wBDAAwICAgJCAwJCQwRDAoMERQPDAwPFBgSEhMS EhgZExUVFRUTGRcbHB0cGxcjIyYmIyMwLy8vMDIyMjIyMjIyMjL/2wBDAQ0MDBAQEBcRERcYExMT GB4bGxsbHiQeHh4eHiQpIyAgICAjKScoJCQkKCcsLCkpLCwyMjEyMjIyMjIyMjIyMjL/wAARCACK AI8DAREAAhEBAxEB/8QAGwABAAIDAQEAAAAAAAAAAAAAAAYHAwQFAgH/xABMEAAABQICBAQRCgUD BQAAAAAAAQIDBAURBhITITFRBxZBcSIyNkJSVFVhc4GSk6Oys9LTFBUXIzQ1cnSRwSQ3U6GxYqLR JzNDgvD/xAAaAQEAAgMBAAAAAAAAAAAAAAAAAwQCBQYB/8QAPxEAAgECAQYJCgUEAwEAAAAAAAEC AwQRBRITITFRFDJBUlNxkbHRFSIzNGFygZKiwSNCc7LhNYKh8SRi8CX/2gAMAwEAAhEDEQA/AImN Wd2AAAAAAAAAAAAAAAAAAAAAAAAAAAAGaNDly3DaisuPuEWY0NpNarbL2TfeMkm9iMJ1IU9c5KPW 8Da4vV/ubL8w57oy0cua+wi4Xb9LT+ZeI4vV/ubL8w57oaOXNfYOF2/S0/mXiaj8SXFVkkMrZX2L iTQf+6wxaa2olhUjNYwkpL2azEMTM3kUOtOIJxuBJW2oiUlaWVqJRHrIyMk6yMZ5ktzIHdUE2tJD 5keuL1f7my/MOe6PdHLmvsPOF2/S0/mXiOL1f7my/MOe6GjlzX2Dhdv0tP5l4mtKgzYaiTLYcYUo rpS6hSDMu9msMWmtqJIVYVNcJKfU8T3GpdTmI0kWG++2R5TW02pZX3XSRkCi3sR5OvSg8JTjF+1p GqMSUADZYptSktKejRXnmknZTjbalpIyK53NJGRWIxkovakyKdelCWbKcYvc2kzxGhy5bmiisuPu EWY0NJNarb7JuYJN7EZTqRprGclFe3UbXF6v9zZfmHPdGWjlzX2EXC7fpafzLxHF6v8Ac2X5hz3Q 0cua+wcLt+lp/MvEcXq/3Nl+Yc90NHLmvsHC7fpafzLxNN+M/GdNmQ0pp1O1DiTSor6y1HYxjg1y EsakJRzoyTW/kJXwX9UEj8ov2jQmtuM+o1mW/V4/qLuZ0sRY8q9KrMmBHajqbZNOVTiVmrokJVry uJLaYzqV5Rk0kirZ5KpVqMakpTxluww29RzfpQxB2vE8hz4ow4TLci15Et+dU7V4Ejw9iWJipp6n T4qdKScym+mQpF7XK+sjK/8AwJqdTSYqSNbd2U7NxqU5vDHbyor3EFM+aqxJgkd0tK6Az7FRZ0/2 MVJxzZNHQWlfTUY1OVrX1raWQ/VJFJwNEnxiSpxqLFypWRmnoiQnkNJ8ouZ2bTTW5HORoRrX06cm 0nOps9mJFvpQxB2vE8hz4og4TLcja+RLfnVO1eA+lDEHa8TyHPihwmW5DyJb86p2rwOJXsQTa680 /MQ2hTSciSaJRFa99eY1COdRzesuWtnC2TUG9bx1/wCidcGq0ow48tZ2SmS4ajPkLIgWbfiM0eWV /wAiK/6LvZw+EDDZRX/niGn+GkH9eSdiXD67mX/nnEVeng85bGXsk3eetDPjx2e1fwQ0VzcFk8Hn UnP8O97FsXKHo2c7lb1un7sf3Mg9ErkuiS1S4iW1OKQbZk6RmmxmR9apJ31bxWhNweKNzdWsbiGZ NtLHHUd76UMQdrxPIc+KJeEy3IpeRLfnVO1eBLZtfmsYPTXEpbOSbTTmQyPR3cWlJ6r5uu3idzej zjUU7SErx0G3m4yXt1J+wiX0oYg7XieQ58UQcJluRt/IlvzqnavAjtWqj9WnOT5RJS65lzE2Rkno UknVc1HybxFKbcsS/b0I0aappvCPbrJFwX9UEj8ov2jQltuM+ooZb9Xj+ou5mbFWEsQVGvypkOJp GHDRkXpG03yoSk9Slke0h7VpTcm0tRHY5QtqdvCE54SWPI9/sRyuIOLO0fTNfEGGhqbi35VtOk+m XgS3CGFXMPG/Uqm62lzRmmxK6BCLkpRqUdi5CE9KlmYuRqMoXyuc2lSTwxx631EGxNUkVWtyprX/ AGlGSW79igiQR+O1xWqSzpNo3dlQdGhCEtvL1ssCfBl1DAMWHEb0j64sTKi5J6Um1HrUZFsIWnFu kktyNDSqwpZQnOo8IqdT77iFcQsW9o+ma+IK+hqbjdeVbTpPpl4DiFi3tH0zXxA0NTcPKtp0n0y8 DkT4Euny1xJaMkhFs6Lkq2YiMtZGZbDEcotPBlujWjViqlN4xf8ArlLAwH1HT/xv+zSLVH0bNDlT 12n1R/czBgetsVWC5hypdGejNLObr2uVHOjk73MPKM1JZkjLKds6NRXNLVr1+x7/AIkRxDRH6LUn Ibl1I6ZhzskHsPn5D74gqQzHgba0uVcU1NbeVbmTbg86k5/h3vYtixQ9GzT5W9bp+7H9zK2FM6IA Cyqr/LBH5eN7RsXJeh+COcof1R+/PuZWopnRgAS/gv6oJH5RftGhYtuM+o1OW/V4/qLuZmxVi3EF Or8qHDl6Nhs0ZEaNtVsyEqPWpBntMe1as1JpPUR2OT7apbwnOGMnjyvf7Ge8N8IMv5UmPWlJWys7 FIyklSDPsstit4h7Cu8cJGN5kiGa5UFg1+Xbj1e094/pNYQn5amW9Jp5n0bKj1Nmew8qbJNJ77ag rxltxxR5km4ot5jhGNTke8ggqm9LUnzpdPwDFmRHNG+iLEyrsSumJtJ6lEZbDF5yapJrcjlqVKFX KE4VFjFzqffcQrj7i3t70LXwxX01TebryVadH9UvEcfcW9veha+GGmqbx5KtOj+qXicifPl1CWuX LXnkLtnXYk3ykRFqIiLYQjlJt4st0aMaUVTprCK/3ylgYD6jp/43/ZpFqj6Nmhyp67T6o/uZXcaS /FfRJYUaHW1EpCi5DIVE2nijoJwU4uElintLKktxccYbS81lRUGeS/SO26JB/wClXJ4hcf4sNW05 yEpZPuXGWunLu39aMeAW1t4YqLbiTStEh9KkntIyabuRhQ4j6z3KrUrmm1rThH9zK1FI6QACyqr/ ACwR+Xje0bFyXofgjnKH9Ufvz7mVqKZ0YAEv4L+qCR+UX7RoWLbjPqNTlv1eP6i7mc7HXVXP52/Z IEdbjssZM9Vp/HvZwRGXiyMC1xqq05dDqFlraRlQSuvY2Zf/AF2cwuUZ5yzGc5lS1dGoq9PUm+Tk l/JDcS0N2h1NyMdzZV0TC+yQf7lsMV6kMx4G4srpXFJT5dkl7SfT4MuoYBiw4jekfXFiZUXJPSk2 o9ajIthC04t0kluRoaVWFLKE51HhFTqffcQriFi3tH0zXxBX0NTcbryradJ9MvAcQsW9o+ma+IGh qbh5VtOk+mXgaNUoFXpBNqqLGhJy5I6NCr229IpW8YShKO1E1C7pV21TlnYbdTXeib4D6jp/43/Z pFmj6Nmmyp67T6o/uZW4pnRHawrX3KHUydO5xnLIkI3l2XOkSU55jxKV9aK4ptfmWuL9v8lq6OJ8 hkyI1sstKnzWnYo1NkkleNKSF7kbXKctjLSQjPbB5v8AkpAa07YACyqr/LBH5eN7RsXJeh+COcof 1R+/PuZWopnRgAdrC6MRnJecw+X8QlGV1X1epCjI/wDzatqRLTz8fMKV87bNSueLjq4234G7Owjj WoSly5cTO+5bOvSMpvYrFqSsi2EMnSqt4tdxDSv7GlFQhPCK9kvA1+IWLe0fTNfEHmhqbiTyradJ 9MvAzw8H40hSG5MaKbbzZ3SonWdX6rsY9VKonil3GFTKFjUi4TnjF7fNl4GviSRitxLbdfQuyDM2 1LabSV+XKttJX5rjGo5/mM7OFom3btY8vnN/4Z5YxpiWMy2wxLyMtJJDadE2dkpKxFc0X2ECrT2Y nrybayblKGuTxfnS2v4nVpdZ4RKs2p2nvaZCDyrPLGTY9vXpSM4yqy1p9xUr2+TaLUakc1v333G9 /wBWv/vkYy/H/wDYEX/yf/aQ59VofCFVybKosaUmrmjo46bX/ApO4YyhVltXcTUbnJ1Bt05ZuO3j /c9QaNwh0+KqHDZ0cdwzNaM0ZVzUWU9alGewgUKqWCXceVLjJtSaqTljJcvn8hyn8F4ljMuPvxMj LSTW4rStnZKSuZ2Jd9hDB0Z7cC2spWsmoxnrk8F5str+BwxEXjrwcTYhjRk0+FIPQndKGsiFnr5C zJNXKJFUnhhiU6tjbTk6lSKx34tbPibUPAeJJSSV8nJhB2sb6iQfjTrUVuYZKhN8mBHVyrbQ1Z2c /wDrr/zsN1XBjXySZ6aKduQlua/1bIhlwaW9EPlu35tTsXiY6vFxvDpXzdNSa6YlKU/VpbWkkoMl JupCc5WMuUeSVRRwfFPaE7CpV0sH+Ljytp4v2PURUQG1AAnPBX9sn+Db9YxZttrNJlziU+tlji2c +AAAGCTGYlMLjyEE4yssq0K2GQNY6j2E3BqUXg1ylL4gppUqsyYJHdDaugM+xURLT/Yxrqkc2TR2 NpW01GFR8u3rWpk34Lfu2Z4cvVFm22M0uW/Sw937k4Fg04AAAc7EX3BU/wAo/wCzUMZ8V9TJ7T1i l+pHvRSKELcWSEEalqMkpSW0zPYQ1x2baSbepItvCuFI1EjpddSS6gsvrXduW/Wp7xb+UX6VLMXt OTvr+VxJpPCnyLf7WSJSkpSalHZJazMxIUTTaq1Kfd0LM1hx7+mhxClbthHcYqS2JkkqFWKxlCSW 9xeBvDIjK/x3hFlLCqvTmyQaNcppOojT2ZFvLl/UVq9LVnL4m8yXlB4qjUeOPFf2K/FQ35OeCv7Z P8G36xizbbWaTLnEp9bLHFs58r/EGAqvU6xInsOx0tvKI0ktSyVqSSddm1FyCtUoSlJtNG8tMq0a NGNOUZ4x3YYbes6eDsK1KhvOOSpSVNrTYo7RqNF73zHmJOvxcozpUnDaytlC+pXCShBrB8Z4Y9Wo k0mSxFYW/IWTbKCutatREQmbS1s1sISm1GKxbKXxDUiqtYkzi1IcV0BH2CSJBf2Ia6pLOk2djZ0d DRhTe1bet62Tfgt+7Znhy9UWbbYzS5b9LD3fuTgWDTlaTODeuSJbz6XopJccWsiNa72UZnyNio7e Wt4o6KnlmhGEYuM9Sw2LxMP0X4g7YieW58IecGlvRn5bt+bU7F4nPrWCqpRIXyyU6wpvMSLNKWar q/EhJDGdFxWLwJrbKVKvPRwUscMdeHiZeD+EmViNpa+ljIU9bvpslP6Gq49oLz+oxytUzLZpfmai W4LpyxW3CTWXzmopDajSw2glukXXLVsJXeIv8ipcTeOadBke3jmOtJYybwXwIORmR3LaKxuy2MA1 l+qUhTcpWd+KrRms9qkGV0Gff2l4heoTzo6+Q5XKtsqNbGKwjNY4d5JXWkPNLacLMhZGlSe8eoxM a5PDBraiiZ8c4k2RG5WXVt+Qo0/sNa1g8DuKU86EZ85J9qJnwV/bJ/g2/WMT221mny5xKfWyxxbO fNB6s0hhZsvzo7bqemQt5CVFzkarjFzitTaJY29aSzo05tb1FtGSLUqfMMyiSmXzLaTTiV28kzBS T2NMwnSqQ48JR600YKxQ6dWWSZnINVulUkzSpJnylYJwUtTJLe5q0HnU3hvKlxHQnqHUFRVqzNqL Oy5vQf7lyijUhmPA6uzulcUs9ansa3MmnBb92zPDl6osW2xmmy36WHu/cnAsGnOcqv0IjNKqjFJR HZRG8gjI+/0Qxz470TK2rvXo5/Kxxiw/3Si+fb94M+O9dp7wS46Kp8rI1j6q0uXQDajTGHnNKg8j TqFqsV+RJmIa8k46mtpsMlUKsLjGcJRWa9bi0cfguMvnmUXL8m1eWgR23GfUXMt+hh7/ANmWcLhz hT+PiPjVN3HoreaR+4oVfSM6vJXqkP7v3Mj4iNgWDwVEeWpK5DNgi8Wk/wCRbt/zGgy7tpf3fYn4 smjKRxMd8Q1E09su+sY11TjPrOys/V6XuR7iT8Ff2yf4Nv1jE1ttZrcucSn1sscWznyp8W0erycR zXo8GQ60pScq22lqSfQJI7GSbClVhLPbSZ1GT7ijG2hGVSCaWxyS5WesJYer6K3GknHditMrzOrd SbfQ9cmyrGeYtQ9pU5ZyeGBjf3du6EoZ0ZuS1JPHXvLWFw5krzhV0d6b/U+uvzfV/uKtx+U3uQ8f xd3m/c2+C37tmeHL1RlbbGRZb9LD3fuTgWDTlL1ChVtc+StFPlKQp5w0qSwsyMjUdutFCUJYvU+w 6+ldUFTgnUhxV+ZbjX4vV/ubL8w57o80cua+wk4Xb9LT+ZeJ8PD9eSV1U+URbTM2HPdDRy5r7D3h VDYqtP5kdHA1QTBxFHNZ2bfI46j/AB9L/uIh7QeE0V8qUdJbSw2x87s/guAXzkyA8IOG5cl5NVhN m7ZGR9CNZllvZREWs9R2MVq9Nt5yN3km8hBOjN5uvGLfcQFqLJfe0DTS1vXto0pM1X5toq4YvBG+ lUjFZ0mkt/IW1gqhOUak5JBWkvq0jiex1ERJ8REL1GGate05TKN0q9XGPEisEduXJaixnJDp2aaS a1n3klcSt4aynCDnJRW2TwKKkvrkyHX1dM6tSz51HcxrW9eJ20YpRzeRJLsJrwV/bJ/g2/WMT221 mny5xKfWyxxbOfAAADUnVGFT2TemPJZbLlUe3mLafiHjaSxbM6dKdR5sIuTKixTXVVypnITco6Cy MIPblLlMt5mKNSee8Tq7G14PSUXxnrl1kw4Lfu2Z4cvVE9tsZqct+lh7v3JwLBpwAAA15v2J/wAG v1THj2Myp8ePWihxrDuSz8I41jT2EQ6i4Tc5BEklrOyXe/fZm3l+gu0qyep7TmMoZOlSbqU1jT3L 8v8ABMROasADG442y2bjqiQ2nWpSjsRF3zMAljqSK2xrjJuoJVTKaq8W/wBe9/UMutT/AKe/y/5p 1quPmrYdDk3Jzp/i1V5/It38kMFc3Rniz50M1KhyHWDPUo2lqRfnymVxkm1sZHOlCpx4xnhvWJs8 Ya/3Sl+fc94ZaSXOfaR8Et+ip/KvAcYa/wB0pfn3PeDSS5z7RwS36Kn8q8DyuvVtZGldQlKTypN9 Zl6w8z5PlZ6rWgniqcF/ajTcccdVmcUaldko7mMSZJJYJHkeHpsxanUoaTTDlPR0qO6ktOKQRn38 pkMlJrY2RToUqjxnCMn7UmZ+MNf7pS/Pue8MtJLnPtMOCW/RU/lXgOMNf7pS/Pue8Gklzn2jglv0 VP5V4DjDX+6Uvz7nvBpJc59o4Jb9FT+VeB8PEFeUVlVCUZbDI33PeDSS5z7T3gtDaqVP5UaAjJwA OlCxHXISSTGmOpQm1kGrMkrbkruQkjUktjK1WzoVNc6a69j7TdPHuLDL7d6Jn4Y90095D5LtOj+q XicydV6nUPtkl14i2JWozSXMnYMZTb2ss07elT9HBR6jTGBMAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAB7sW4ZgWLcAFi3ABYtwAWLcAFi3ABYtwAWLcAFi3ABYtwAWLcAFi3ABYtwA WLcAFi3ABYtwAWLcAFi3AD//2Q== --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_200912271810030.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_200912271810030.jpg" Content-Id: <63406-975732731481603@6129959> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 6Jbb0NSCFh6GrCrUgWs+ZiKoUr1BFOzVrbTGjU9hRzDIN1G6nNCOxxUTRsPQ0cyKH7qTNUprpojj a35VHHfqx5pO9i42NHdmkIp9qguMBDk1rx6NKU3MMKOpNclTERi7M6Y0tLmIVNNwRWxNYpEOWBqk 8XoKiNdS2KdKxVupmuZ2lcKGbrtUAdMdBVRuuACfpWgbYnqPzqrcxYyMngduK2g7mMnYpuP7zBfY cmotvIwhDZxlsGrZhXCADvzTQuZMEdBmuhRMWzOlQtsLHJ3YqJkJtgehJq4y/u0z/eY/pUL48lVP UqjfqKtElB4Q2Tjl0z+hrg9Q8Q3l+u1T5MJ/gQ8n6mvRoRvZPePP6mvJZVxI65wAxH60xEXHtRRj 3opBofRyipAKrpKfQVJ5p9Kw9rESRLimkU3zR6UGQe9HtI9yhGFRuPlp5kX1pjEMpxSUk9h2Oc8O EyahrJclsXRAzzgc1pPEhc5QcHuKqWdnPptxfPGY3+0ymTnI29fz61Gbe+MhZZMkn+JQR+mDVzkr F04u50el30dk/NurZ/iB5Fdavl31rOtzOEhMZI2ntjk/hXAafY6nLIA0YZB1Zc/yI/rXa2f2K30u SO8LlUhwxJyTxz+NeVNU3VTi0/U62pcupVNqo5PNV5VVRxiuL+IXia70qVotP1Z4JgFzAqIeCOvK 59O9eYTeOPEkhO7V5/w2j+Qq8NRlUXMFWooaM94bFULkffrzTwL4g1a/8SiK81CeeLyXOx3yM8dq 9Hd97TD+7g/pXbGDg7HNzcw3GFY/3f8A69QqP3xH+xn+dWXX9zIfUj+dMZcXR/3D/OtkzOxnyL8s f1c/+OmoZE+Yj0gX+f8A9arrplUH+9/KoSuZ24/5Y/1NUSVLRP3ML/8ATIV5Dcg/aZsA/wCsb+de yWy4tIh6RAfzrmf+EDtndnbUXyxJOEH+NWkS2ed4PpRXov8AwgNn/wBBCT/vgUVVmK6PQlp9NVWx 90/lTiGBwVOTXncj7DCkJpdrelHlP1xSdOXYpEZpyfdpTA+M8Uqoyqc04QaepaImQHrT4IRvHFGR mnxSLkncoAOOTTqRbWhrBpPU3LN1iTjilGp2dpY3huofNDDAHrnjHtWZ9qjCkCVQenPSsy9uY5YC hkUgyr0PvXnYehOFS9jqqSi47nCfE2a2k1KZFtybkKhaXA6ba8yPr2PQ179qh0i5neO+i0+SXaMC dUL+3Xmsd/Dmjm4jB0mzwxwf3Qr1MPaELHHXnzSOF+HYz4n47QN/MV6uvE9yP9kfyqrpWjWNmI3t rO3hcqAWjjCn6ZFXMYuZPcYrRu8iI6D5D8nsStMc5uW/3TSk5jA9xQRmdvof6U0JsgfrCPViP0qG P5mJ9Y2H6mrDr80R9HP8qjii2kf8DH61TYkVLXmCP/dI/U1pGNAMbR+VZ1mv7uId8/1NahpzJRDs X0FFOJ5oqdRmyoGKbKPmQ+9PUfKKSUfKD6HNaEiNGKUKDTyKQDFSy0MAwcYrB1vWZNKuYlMKvDKD 3wQRXQHg1yPjVM29vJ2ViKlK7KuSL4gtZE5DofpmrP8AbFk6AvMM4x90+n0riI26DvVpSSRgjNO1 tgsm7ncMVHPFZMuGuJEPIJT5ccHlalabfYxvgt8gJAHOcVnSS+ZNvEu0fJux2571n1GzdfT4JsF7 SNsdzGD/AEqb7JDGFZYlRgRghQO9Zkt08Ea3EVwSAdjFh0B+mO+KvLdXTRR5l5Yrn92eO/rSSvsS +5T1Gz1WaQDT9SWziRiHJiDkk4OefrWBfWPiOzdHXxCZRvw4Nui8Z+tdbHP5lrOdxLBmByMd+P0x VTX1T+ziWAOXAGfWhSaKtceuowGIu1vMihgMlT/iacdQgYu0cUpY8r+7b29qzDZ2uw+VeRXIiZTJ Ex3Ed8EqQR0q/HpJjfdGVAx90ZGM/iavnt0J5fMF1C3UbrhZkG7gmNuuPpSm/swVKtN8x4/ctz09 qqXun3MVs7mRNoGcKzj+tZkC3ck1uTMuxnbbgEkY9cmmmmK1jYtSpZNucZ/iGPeszTtd1a51FbW4 0oKhPzSoxKoOxz71dkkKQzODgrGxB/CpNCZn0zzH5d5ZMn1w5A/QCqZJfI560U2ikBupinOuUIqJ DxUm7irEhV5QH2oxUAuY1ymckHoKXzXYZSNiPU8UmUh71zHi3D6Ue5Vgf1rodk8hOdqD2yaztR0C TUYGjFxtLEffH+FJWDU8+h9KmB25NddF4JVSA94WHfYgH881oQ+CLEkbmncf7TgfyFDkkUrnLQav FBbJFKDxnBFUgTPeu5I8ksG4AzmvRv8AhB9B8r9/EwA7mVs/zrl/Enh/TdJtGudOnuD8wBR8EHPo eDWV1J6GnL3K9xPbS6ZLAJS2xdxXHUA10KsCK8/+2tbB3GS8ieWpB5Unoa3YvFdiyqGjnjPclQR/ Oh2juJwb2Nu6YJZmYEqQo6d/Y1ia2NQexYXRj2ghgIuRkEdc4PepLjXNOuLMxrORuKjlCO4z2qlq C2Dw5hureV8cM6LvzuXvx71DcX1LhzR6Ey3OruHDRKccHlRn7w7H/ZP6V0enzzXGnxTzIiSSc4Q5 GK5iPTnuDgTWa7jnMcR9W9H9/wCVaunWd6tnCyagArR/KnlZVT+J/liml5kzemxe1VxDpkknlvJn Awo965D+1xFNFLHbABM5BfO7/Cty8GrQ2j/aJXcAjDQBCp57gjI/DNZ2mWkgYyPKPLxtCvbbwO/b 60Ju+4K1tUVJvENu9pcRNG6PIm0HggfrW/oDq2iQMOjF2/NiazNT8hIygSzkznj7OVPQ455rYsD/ AMS+P5dvB49Oa1vczlboWaKZu96KZJpxyyOOgX68mp0gdzy7H2HFLEnA2oRVuOFif4q0sQmMEO3u B7VIsakcKSasrbY5PB+tSCNQOTmixVyssR7HFP8AJ9f1qY8HjgUxm79cUrDuR5VTjGaa1wwB2/LS MeayNR17TtOys04aUceXH8zf/W/GoaLiXpJGc8sSfeuT8Yy4sIkWQbjJkpnkjB5rO1Hxfe3OUtU+ zxn+Lq5/HtXOyTZkJlctIxJLMck/U0lHW5TehIWfzI9gTO5SN2cdfaowJpF2FYVHcrHz+ZpzsNw5 IPbFWUgLgAY5rixNdxlY7cPRU1zWK32GUp99tqglVOahSCRZPmLHB79q37eORGVUBx34zn8Kti1W 4bccnA+6Fx+lcCxXK9UdvsLqyZywN0q5i2MBkHP0/wDrGpk1K5juCYy6oCdu0kEc1vvp9uEOQysc 9Dz3/wAaYdKzJ52NxJJOcGtXi6TjYy+rVL6lT+1bySFkaWUhhwGbPv3oj12TT3MRcgg4+6DVjyh5 ygxBWJwCB+HSqV2peBS20EkkjHStKNS8ea5nUoq/LYmuPEIuk8tirZ4+6R14qzD4hjjjEbeXlRjG 7Fcx9kd7ldgQnPGeMU14nZmcp94k8Nmu2E7q6ZxzppOzR1n9vxei/wDfz/61FcaYBn/Vt+dFaczM /ZxPfIwicAVMJBVJXOOePrUquM8811HIi1vzzTWbA5wKp3OoW9qm64mSJR/ebGa5nUPGsabksYTI w/5aScL+XU/pUlI615FRCzEADuTxWBqPiywtMrC/2mTphD8v5/4Zri9R1i81DH2iZmH9zoo/Cs8s GJ9qCkbF/wCJ9Q1AlA/kxHjZFx+Z61jvjcp4HrVG51S3tRsBMs3/ADzTqPr6VUWG+1V8zt5MH/PN e496wq14UleTOilQnUeiJbrVIxIYbZTcS/3U6D6mn2Wn3lxMJbmUjPSKMDA/MGtXTraygAiiROOp StuC0yMoFPtnFeFis0ntBWPXoYGnFXnqylZaRaRuWaGV5D1dySa3dN0aW7uBHbQZ9Seg+pq/omjX V7JvkzFbqeWP8XsK7y0ggtIRHCgRR19/rXHThVrPmm9C6+IhRXJBambp3h+105BI4Rp8cyYxj6VP LFZuRmOOQepAq3LcA/Kh47n1qsEiUDbGgx0wKuc1FcsDgTlJ80irNpmm3C4ktwB7DH8qzbnw1pkh G0SKBz8rf41uFhUbYNZqp5GsZSWzZy9x4fgRuJ8HGRvTGAPf8K5698LXiyM9uYSv+yxBNelG0jlh IlXIbBxn0rI1iWDR9JmmUcjO3PJZjXZTVorSw1Wk3ZO7PJpo5be6KTYVl7gg/wAqqSKo4En4VdeR biVyQ2V5JIqrcwqieZFuzn0roo1ehrVplIkg9TRUgkOOXOfrRXX7RnL7I9OvvE2n6flZZw0g/wCW cfLf/W/GuevPGl5cBvsii3jP8R+Zj/QVxsf3zU4P7tvwr1DyEi+L2S4kd5ZHkkPVmOT+dNMoA96p RH5WqO7dlsJmViGCHBB5qWyia81S3tWIkYmTsi8msuS7u71yWb7NCey/eP41l2fMu48nPWtMcvXD XryT5UejQw8Xqx9tBCpI249CeprXtwQu0ZYemc1mIKu25O4c15dW89z0YrlWhs26IzpGqEuxwAFy a67TtJhtWWS8YuwwfK7KPVjWX4SVTLcMVBYAYJHIrZj4+znud2ffGcU6WGg0pM56uIndxR01pqCO Sm3ZsA49BUsl9v8AlU4X+dYNgx/syEZPVh19zVoE+tGJ92XIjCkuZczNITe9O8/is3J45NOyfWuF o2L/AJ1KjhnGTgdzWeSc9aa7MEjwSMvg8+1VSgpSsxSdkbbTqBgGuI8Y38VxLHZmUKE+cg+p6fp/ Oty1ZjYxEsSSvXNeb+IWY61cZJPznvXXXVo2QYRXnfsQzRtz5ZVgeuKyZbhOV2AkEgkHBqTJBJBI NULj7xqKEdTtqO+403C5/j/76oqrRXfZHLof/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_201001211425500.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_201001211425500.jpg" Content-Id: <27480-543658092160512@4830203> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 7OFMop9qtImKjtlzDGf9kVcROK8qm7xTG9GIqVDdJzF/10X+Yq6q1BdrxGfR1/mK0ew47nN6pqep WniO5jivWjgXbtjIBH3RnqK3dB1S61GG789w4ULtOADyfauT8Thk8VXDc7TswP8AgIra8FFiNQDZ +6p/WumSnKTfMrJbf117midNU1pq/wBDqgvNO204DFFczRmMK8gVV1BR8mfSrnVhVfUB9z6VEloN blnRkxYypjuBXRRDCfiaw9IH7hx/tD+ZrdT7grsobBPcU4zUaEBfwp/cVGv3QK3JRJu4zQxyuaTH y/jTXOISfai4DbfoT6gVPUNt9ypqFsJiN0NcFqQ3OnqEH9a7yT/Vt9DXDXg3Tt/ur/Ks6uw0ZBj5 oq1s5ormET2Yzbx/7oq6oqnp242URbBbHOPWryiuXDO9KLXZFz0kxyiobwfu1J7MD+tWAKftz1Fd DJT1M680PR9RvTdTTYlbGSkoAOBgVZsNL07S1nNrOWaVQCGkB6dMVaCL6CnbVHOBV8/WxXNol2H1 HI+2lJqvK1ZsRPE25qjv23CIlSD0waS3bFJqDMFi8zG7BOQe1L7LGty/ov8Ax7Mfx/U1uR/crndD b/Rn+i/rmuhiP7uuqhsE9x3cfSolPQe9SA/vCPQVVWT51AGetbNkos5+Wmyn/RzSFjt6etMnf/Rs njNK47Elt/qvxqeq9ocwD6mp+1UthPchuCRC59j/ACrjJhmd/ZV/rXYXQbyJDnjFce3/AB8TfRf6 1jVDoV9tFSYorEkTTiDaLg9zV5aztMYNanGfvdxV/wAxFKhmALHABPWvPwDvh4PyRtUXvslFPFMB p2a7TMfmgmo2cKpJIAHc1Vm1Wwtx++vraP8A35VH8zQMts1VpmrMbxXobXUdsmpQyTSMFURktkn3 HFX5XGKTXcCSGTGc1Fqj+XAo35AQtz71B523NZ+v3oW0i5+8Av6ml0ZUd0dDpNwqQsCf+eY/Q10M F3H9nBLYNeULrMsLAI/U9Ppmtq38RMsTK5Xg8DFaU6nKXKFzv/OR2LBlxjFVVuIklXcwGQf6VgWm qSsG3RDAwOD9B61TuNSZJV3bhhcgH/eH+FaOoKMNTtvtMO3PmL+dQXEq/Zkw2ct6+9cm2qL5cYLd V/xqaXUwII8NwcH+dHtbhyWOusWBtAc+tWq5Sy1Qi1X5uMHvVxNTb5vm7nHI961jUVjNo1r5ttnI a4/jz5P91f61pXGovJCQScH2rHtnMjyseuF/rUTknsJ6IlxRRRUEFTSnHlyKDna3NNm8i48Q28Us IZ7eFpo2J6EkA/oKTSl5kAwM4JpHdIfE6kgFnt9oJPbJP9K8jLG5YWFv61Oiq3GbsarzBFzXn3xK ubhtFhlhnZfKnBZVbHBBGfzx+da3jpLu/wDD7Q6fvaVZFYrG2MqM5rxb7W+75trj/aGa9enC+pkj rdEsbbWLCOW8uLmRyTkeZwMH6VuxeHNIiIP2befWRyf61wllrUllxEPLGckKBjP0rci8XSsql7Vp QvJZAR+fWtmWlfY7K3jtbDHkQRRA/wBxQM1l6x8QpdI1iSxltEkjRVKuCQSCAatG8iltIpQMZUOu eoyM1wXi6P7VeRXMIMjgbHCjJx2/rS5VJ2YM7OH4jadN/rI3jJ9Dn/Cnaj4n0y+todlyBtYE7vxr yYblOCCD6GtDT22rM6hS4QYJUHBLAd/rUTpRSHDWR3CXoknt8MCGGR9DVtrkh8Busir/AJ/OuftH K38UQO7y1Vc49BWgkmXiYjrcD/0L/wCtWPLZmlzore7cxH5zjAPX6VW1bVWtShbznXGCIuW6n1qO 0c+Uc9QuKo6xJ++4J+70/Fq3ZMSW91fXnliEcdrAhUbBJIXOOnJAxW1Jqdz9htBIFMpQbtg6napO PzrmNQlf7JAVG5/s4x3ycmrmpy3AsbX7LN5UwXhsZ/hXt+FKyYru51tveTpDHuXHTv7mrUepuI8s DnJPXNcNa674hSJQ1laXsYP34zhjj8f6Vo2fid5VEdzo9xACPvqdw7ew/nS5GZuR1MWpMSi7H784 461e026icSAspOF4z9a5OLWLee9MFvBOzbN2cAD6dferkN6qRkfYpHYsccrkYAPr7iny20IbOs3R Z+7+tFc2NQ4+7br/ALLSsCPYjbRVWJuTQXP2fLbtoIxkms+7vIf7XtZGkBkb5QQ3A69at274cfSs G9ub8yXN3Faq9usw/e7hlPLOOh98/nXgZM74f0bOuvdTujY1F7iW0kS1Z/M/hK/49K8MmVo55Efh lYqR9DXswGvPID58Ua5Gd4B478D/AOt9a8h1pPK13UE/u3Eg/wDHjXu0TnRUDEd609MnlaXyGc+X sf5e3Q1lA1e0piL+P3yP0NXVV4M2otqoj0SxsEn0q1kkQuGhQ8sSOg7VP/ZihcKigegGKz/D1866 XbDnaIwMH2rVkvWI4Y+2BSadybohbR4H/wBbGhHfcuap3Gg6OEbbH5TsMExHHcHp07U291aC3B86 4RD6E5P5Vg3PiiLO2GN5Mnq3yijlYX7DGm+xanLk7gWOG6cZ9KvrqVqRFtfAWRSQRjAzS/Y1LE7R n1qGbTk25Aw3rXN7WLZ0ezOit54HaTynVlOcEHPvWfrLD7UFHdB/6EawDZTxf6tyc/hilaa4WEiV 3eQdCxyQK25lLYjlaO507SbO+tbaY3imQJgRqwB6+h5q3deGzJGoDyrsXAyM154JlmQJ83yk8Mxw Mn/PapZ7o+adsmQVwNpOCPxo5fMzN62hFtbRI2Gbc3I69DWoqhLMyLLKCI88yEjPHYnFcvazPHbx IXCt98Z75xV1b65KCIldhG08dqHFoVtDdtoj9ljdp5VOASFIHbPpVyCxT7XHFJLMw6sC5HdQen41 h2WrgzQxTxkJvGSnJI9MVuLeKb53eGWNTu+dsDHzufX2/ShJ3Ilsbw0+wAA+yQceqCisoXduQCL+ Ln1kNFVZkWQ2W5FrbPOV3eWucA4zXIP4hmbSpLVVjWOQPuJySdxJP866i7IewnTH3o2H6V5/b6ey zzFjvVmyoGQFFfN5LK1Oafc760b2sXZdev7lP3kzhMfMS+0fpgVydzYtPJJNC+8MxPzdTXUm2umu AxZBAEChQvNCaYkeSiEZOST617qqRg7xMlCT0ZxDRyRNtkUqfcVb01guoQkkAbuc11zabHMpSRVK +4qg/hVXkHkyOq9xjP5Vf1iEk1LQapyjJNE8OoSad4bgnhCM27Z83Tqf8Kw7rW9Ruhh7hlX+6nyj 9K6g6Cx0sWRl+RTnOMnr/wDXpsPh2ytF3y7Tj+KQ1X1iHQn2UjjYrS4uW/dxu/qa1rLw9I8itOwC g5KituW+srf5IVMzDsowKrvcXlxlWYW6dwgycfzoc6ktlYfLCO+pqSz21oP3rjcO3U0sNxbXW0JI OT3rIWzjTJdST/ebkg09rQYBZ/KTpgnvWX1eNty/bM22tIyCVIaqctjG8ihkOMjpVENdRAGPdjOA T/8AXq1DrMtu6GVVdlIPA5zUexkndD9omVJNOHzeWce/rVZ7BggJGFXoR3/zg1updQTMS5C7h/F0 FLcQQCDdE5kYAk4PA4z/AI1cZSW5DUehjGDbHuGHyAc7cYP4/WnBJEhTIQryeVrXt4d1kilSVKgk D86WWI4RAGWNc4QnpV+0IsQaVN9muI7iNYxKvzLu+b2rW+3GeJ3ZdpJXIHOcAnofdqrxW6rGHRAO SOlO+yFE3jHTnNVFtu5ErF3+2Xj/AHahcLwOD2orNKkEjFFacxNkTfa5puDIxB7DgfpTxZKRljVy SyA+eEADuv8AhQiDb8xrx44f2L5bWOxTUldEKwIFA646YFDWob+D8TU0t1a2q5lmRPYnJ/KsW78T QiTZboXJ6M3+AraNKUtkPmSNQW6qOFB+tV57+ytP9ZKC3ZE5rBnvNQuhunm8mPPTsfwqHykjDkoW bghnPB/Wt4YX+ZkOr2NCfXLmclLOAImeWI5H9KovBNO5a4meVgeVHHH40CVzIY2XIZeFx8uas7UB QTSBCy48oEc/jXTGEY7Ixc2yKKGOD5VA3A8qg5I96nEewEu21V7LliQf5Uo3ui/L5KfdbcefwOaS PbGflTzJE6s45x7cVRJIEIXdGoRcf6xxkkfWmlVXlQZGx99iOR+FIZBvwTvkB+XsaUsQR5kmAeVU HDfTrQAioZG7yMfXoR/LNJIsUeN/zv2UDr/9enB3mBCL5KZ54wwP8qblIiyQqCxHzHGM++MYoAqv bowLu4B7L/k0hNxEv7vhTxz2qXCxuWYBpG/DP9KZJIIlBkcuT0U8fnQF2SwX09sqgk8DpirUGoef Md8Zyf5/5NZaRTXjgFDjPC//AFq6bT9LS2hLMA0hGM9lrOfKtylcsLADDEVJDseRn8qUW+EZHYkZ yMcelTjaoH+zULybmJNZxkDRXMfPWipN3saKq5JoxSgqKoa1ZXdzbF7CXZKBynTf+PrUkB/dirsZ Py10OKe5CbPN1jfzpBcM4kHBjJxz+NSRW6oY9h2HrtwCTWl40VV1W2IUAtF8xA68nrWVGB50BwM4 FJot7XLMTM0T+UmDu5D5qUtD5r5YytjmItnn2qreuwthhiPnPeprMBn3sMttHJ69KRJOrO3lHasM fKmMr1ohdFVhAuShyRLn9KpXQyqE8nn+dEjuonwzDHTBoGaLEbmWRs7xkIxHH0pw5VXYbF+6ysP6 1WtfnjiZ/mO7qeabfDdDKDyAwxntQBMJeTDAhEqnOXBwR7GnNHDCcynLOMhWOQD+VV7UkQJgn7p/ mar27MWZSxI9M+9AF9pmdTuAVRjKcEEf0pgcsNsRKgfdbGR9OtBJMsYJJBUZplyAlodoxk84+lAd bEc1wsEeIwWY/UgH2ptjazahcrGqb2PUdhWcGOep5Arv/DKqNNDBRuLcnHJqZy5VctLWyFstNisl 2t949SauSFUXjgVacAyjIFULrrXHq9Wa+RCZNxJ6CoJJOOtK/wB2qk3U1USGIZufvH86Kz2J3Hk9 aK1M7n//2Q== --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_201001190915070.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_201001190915070.jpg" Content-Id: <40350-107696198780047@3685684> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 525+Hy4LWt4V9FlXP6j/AArHuvCGsWmT9m85f70J3fp1/SvVmhLJgDPI/nUjwskZaOJZG/uj5Sfz ptI6IV5o8Pkt5YH2SxvG4/hdSD+tIFr2/wCxR3UAFzajHdJCrf1IrOu/BOjXeSLcwMf4oWx+nT9K m3Y3jikviR5Dspwjrvb34cyoC1neqw7LKuP1H+FYF34U1myyXsndf70Xzj9OaVmbxq05bMw9lLtq YxMjFXUqR1BGK3tB8KXutMJMGG1zzKw6/wC6O9BcpRirsw4rKe9uxDbRNJI2MKo9q7jQ/A8NrtuN SAmm6iPqi/X1P6V1+m6LZ6TbeXbRAEjDSHlmx6mrxjGKpKx51XEuWkdEZhhAXC8AdMVTlM8bHy5C OfrWxJED2rPmhG7I9aZzIIHuOMyfpWxHCHs1Lsu8k84wap2sOSCeg5q9EuFZsHA9TUsZmT2UlzDJ AjPudSow2Dkj17V45qyanZahPZ31xL50TYceYSPw9q9udSV+V2Rh0ZTgiuB8f6SSkOqJlmH7uYnq fQn+X4ik1dHThppSs+p524LHLEk+9RlKsFaYRSO9ogK0wrU+3JAHU0hjcvsCktnGAOaZDK+0elFX f7MvjyLO4/79N/hRTsyND2EaD4hiHyarc4H/AD0tkP8AQUGDxJb/APL3ay84w9sQf0avWY/E+lOB /pBB/wBw1L/b2lOP+PlT9Ub/AAqzzuZnkyT+I1HzW9hJ7Auv9DUg1LWk+/oqN7x3Q/8AZlFeqG+0 eQctAfrH/wDWrm/EhtcFrHYoEWSYuOc+1SO/kcVd+JnsIGlv9IvIYhjLqUcDJx2arUXiK2eNXNnf qrAEH7MzDH/Ac1m69vn8K6n5ru5VEI3MTj5//rVeX5DAoJAKR9P91anm0uU0uW9hbjUvD13gXYjJ H/PxbsuP++lq/b6xpDqEh1C0wBgKsq8fhmpGIi0+ORPvEjJPf5f/AK1TW0FvcW7yTW0MpGBh0z/d /wAafMiWxySxyI2yRWGeMHNS4BFcx4r0iyktrKWOzhhkNxFGWjXBK5xj8hW7/wAI7YYCxJNA2VGY p3XqfY0lJMUopJMldBnFUrmCJXUQeZsLZ+frknJrUXwiA6tFq16M8ctux/31msTW4b/QtU0xBeNd xXE2x/NiUFfcFQPWquJa7GpDFsRgetSv8tuqAjnk09YGl3Kkh38cbOvIHr70250+8t4xJNlVDBeQ Oev+FTe+oFGeWKCPdLIqL6scCsvUJ9NvrGa1luoWSVCpwwOPep9ZCSaXe5zujgkZWODghSRxj1Aq rpMdzJo1rO1tJNJJErFkUKMkey0KStdFJW1PPY/Cjs5E1/Ai56qrN/Sr8PhPSlx513dTH0jiKj+R r0/TtGk1CVYmEkMhDHDE9AcZqfUfC5sbN53nY4wAMnqT9apRuayxMnpc87t9F0W1YNHpVzIw/idC 38zV1ZIoV22+lTIPQRBas3FyYZWRYo2wxGWz249axPFe2ez0qMRojy35XKZGVG0f+zURd3Yzu5PU 1vts3/QPk/OitRNPg2L+67DsKKvlZnzxPRbXQNPkhVyh+YA43H0oudEsrSe0kjjyGnVWVuQQc+tW vD9zFdaTA0SuMINyyAgrkZxzU+qcR2xI6XCGlfUET/2dZDpawj6IBWJqtlb/AGG3dYU+eRYyGGQe v+FdDubdjacetZF4d9jb5ABS6QHH1/8Ar1I23Y5HXrGFdOvYDZW6AREnanX61zaEmO1bPWOP/wBB WvQ/F9r/AMS+4nUcGIg1wlvD5un2L+sUZ/8AHFrKeiKje2posC2lxDB6Kf8Ax2rOnErasCOpA/8A Qas6Zaie0MZGdqJ/6DT5Lb7Kqg9Ce/4Unv8AIm5ieIgRBpw4/wCP6ED/AL6rvNUQ+QHJXh04BPPI rhtdCuulD11CAf8Aj4rutY+Wzz/tr/Oqp/CVU+GJDaMCAff+lcp4yw+t6HCOrTt/7Kf6V0mkuZ3C AZ7/AKVgeJrfb8QfDURfgvI5/IU46mdPR/ebFnbtHdR7l4MgGfXkH+lXPFbBLCP/AH8/oa17hABa KuMecP5E1ieM8m2tkHVmb+n+NVaysCOB1Vt+l6lyP9Q/X6EVtaNpEcnhuxkKuWMK8A46D6VzPiAv BoN+5P3k2/myj+tej6Ta7dAs4wMHyV/lUU1eOpc37qsJ4bt1j1FgFICwngnPVzVrxWwXS1AAy0qj +ZqDTJIrLUbvzBIAFUDbGze/YHFQeIbyG7jt4oSxPmZIKkdvetkZpnnN1bOZvXJPP4msjWl8zVPD cGOTNLMR+I/+JNd9cabgjEbcYri9TjLfEHS7fH+ptC2PQkt/iKzp7suDuzrhIUAUDgcUVmyXsokY A8AnFFbcyM7Hf6b4gWLTraM2k4OwDcykL09en61Yu9RluEj3WxjVZEbcTn+IV5VD4zutK03yoZ/3 2FKwDPAbnPsMc/jVyw8a3F0FWefzmlVcQAkEHdyOfTjn61y+01NU4nsnnHbnypD+Q/rWXdOv2LfK hVftEb8H1YAUzRNYXVhIr2/kyx/eXOR94r1/DP0IpLiNW0xioAG+Mfk//wBeth6WH+K1z4bvMdQv 9RXM6JpazeGtJlKj5rWI/wDjgrqfE4z4cvR/0z/qK8d/tm+stGs0tyPKW1hPTJ/1ak/rUTaS1KhB zVkel6TLZ2N3dxXUqRgLGq578VW1u8s57mEWsyuqg7j0wc+9eMN46vvM3FUIBztKgZ+vFJN8QNWY kRrBGCeAsY4pc0Tf6lUPQfEE8S/2TmRMDULcsQeg8wV1+ua3ZS2gjilLHepJAr58vPEuqXzxi4n3 LGwdBtGAR0Nasd9b3KK4uYtxwWXfyKSkkTWw84xR6aPFWneFon1G4M80MeMxxhd5zwMAsM9RXJav 8WtFv/G2j6ullqC2tkrB1ZE3knPQbsfrWJq9jJfaeqRyptZYyT1HAUn+RFcO+lu90YzKo4zkL7+l aRascsU72R9N6R8QNH8TWcF9ZR3aRQ3BV1ljAbITrwTx8wqfVtSstUvrJYpgVQOW3AjB4x1rybw3 DbeFdKay1C/td7SmXO7HBAHf6Umv+K9jRLpV7Ew27pHQ7gT6fp/KnJpIuFKc3ZHUePoY4fD7bOks 8afrn+lej6bHv0y2VGXiJe/tXzTfeKL7ULWOO6WJlSVZAQCCSv8A+uus8P8AjSfUrpbMI0ThC24O WHH8qmMovQ0nhqkIXfQ9m0kSfb9ROA2JQh/AVT1mQXOvadbKCpRiScf59K5W0v7yJmZLmSMsdxKt nJ9xip/7YvjfQ3crl3hGFLRjGPwrWxzHWz2jhvlBceu2vKDGLr4v3qzFQkMccWc42j5f/r13LeMr tTykXTspX+YrgZJmm1fUtQ8tVuJrqTcwAzgHGM+nFKyjqOHU9V/4Rnw4ecx8/wDTf/69FeXfb7v+ +35Cip5kVyM8/lu1uA8KIq43ENk7mGCcE9Oo+vNa+lyTSeJoHiKeaskZbau4E/Lu4+v8qq+ELaw1 OaePUyYoNmPNjYAh+q9eMcV3Wg6VolvMk1vHczzpJIyttPXcoVuM/wAKknnq1c/I47hCDlY9N0C0 uLZrieS0ZTKVKEFQNu0ds8dK1XjdbUCRFXDISFOe4p1rNcS28ZNsI/lH3m/wqeRGkiKuVGfSt73L vZmf4kG7w/ej1iPFeKW17pN7oVpYwXpXUFt18wFRgYUAjr1/CvctWgkuNKuIY0LyOhUAEdfxrwK4 +HWraXdtPa28jSYICvJGev0NY1ZwStI6cJa92YOp6RZ2Ng9wC8rB8Z3YGDWGqIYzI0i8DO1Bzjgd +BXW6loutReHLtbzTZkKkOCvzg8jOMVxsI8mF0eHbI4+82cgA/8A1qypzunZns1HTbjyvoSFbV8b 2mx3ww/wpk0EbOIra0kdsZyhLE/WoD1q/p999gMsv8ZI2EMRj8jVxfcirC0bw3Gw6JqFxG87LhY+ GRzyuenGc0xtFlQhnZg3Y9qfca7eXM4aWeQx7gWXPUVdl1+3YbIdPBXPDOcEfl/jWqUpbM8nEOVK SurtmPcq1rMYbhjNgA/f/rTBJbk5QND9CSKmuZ/tMoknKHI4ypBA9M//AF6gNqGG4IyfiMfrzScJ bs0hio6JoeZlUEFw4A4wKv6Fq0djq8Mu9YUYhJGIJ+XPNZAhcnCspB9eDU8OkyzMPmU57KaSfI9T SdSE42TPZbHVbO7UfZ7uGXjJCuMj8K0Q5Irw/wDsq5gbMbOp9RkfrV621bWbCN9t1PxjABBB+veu pVKb6nDLDvozt/H2tXej6HDNZS+XM9wqZ2hvl2sSMH6CvOofGuoKxM0VvJkks20gknnsab4k8R6j rNtb297txGxYbVxk4xXO0SfYycOV2Z2P/Cdv/wA+h/7/ALf4UVxuaKm4WO60TxEPD0c6WtvFM0uC XnXdtx6DpXV+F/HGuT6/At3Iq6fJlJFWFUUDBweB64rnYbeGBT5kag56EAH9KtxTJJIEjhYgcdN3 8uKOVPcadtj6aspFlsYJFIKtGCCPpTb9ilo7L1FeY+CPFs+lgWOowSrZH7jsQTGfoO1ej3txHNpr SRMsiMuVZTkGhxI5rHK6v4yv7CUwGyWEHhJWYsG/HjBrlNS8WXt5J/pDpbgDibkj9Bmuzv44bvTn SeNXUr3Ga871HSnQf6JtKc5Riefof6frWH7ty95Gkea3usxLrUrm4uXH28yjogJ2hm54yxrltbeZ mjmkjA2qUJQ7h/M1sXkLtmEM0bRkgxNkYqjLJbC3MVwJsgdDjaPUj0rpcISjaK/zCnVnTnzHNiRW PBodsLWnLbW92ihBBE4GT1JYfXnmobjRmgiWRjkE5wJM8euKxlRs9zvhmN46xM6Bg0yk/dByTWk0 SiNsElD0c8AH/Oaj+zslvnjbnuw6elTos3kHYrbM+2Me3tVpKJxVarqu7BImljZP3TFRn5Rz/LNR bYgmQQGVvXkipX3RoWnADHkBQBuH0Bo/eTEFYhG2MMeufzquVLUyuMkDyJ5qIuQMFvu/1qvt8ohQ JHc84Rh8v860oNOkm+SPfL64OFFbFp4ejC7riTJ/uR8D8T3/AErOVSK0LUJPUw7W51EMqq5ZuyY3 HFb9kJZU2X9tbAe4wfx//XW2ml20MAEKqnHOB/Wqn2cyoSAcZ7VnJu+iNIpW1Zh3/h+1kXABORjP X8qw7jwxgny3/A1u3okiuSFZx24NQfabhVyfnHoy/wCFQquthulfU5J7YRuyNBkqcE7jziit2RQ8 jOYVBYk/6wUVrzojkNqS4so5Ukd4/MZR5mV5J9auRa/awH5MsfQD/E1kGyXzC8hSJOPvHBPFSQ2N rKx2ys5B7LgVrzMjlL8via5mysKLGD0PWrmhavqcWs2DG4lKmUKULHbtJwRis9YYraKQKi8dC3NX tKaT7VbyGQHEinA6YyO1HMx8p6tc3irbFQ3auXluSGPp/OrN5eFV244rFkm+Y8ZNcFV6nRSgNu4I L2PFwuWH3XThk+h/oeK56/0u4hTc4FxB18xByv8AvDqPr0+lb+/v29hQskkfzIxBP8SmphiXHR6o uVBSOHuraWTa4kMoUYVTg/SljEMkBFxNJuAA8srlQfb0/CuvutPtbva8ZFrcAAYC/u3/AA7H3H61 iXVhLHe+S9mzSr0IXgj1z0x+Nd8MRGUd9DklRlF7GEITIirBbJ14kOcsPQ81YEDiPy5JFVG6Ii8k /Xqa3I9LmcfvpBGv91OT+f8A9ar9tZw2ozDGpboWPLfnWNXGR6GkMNLqc/BoksxBSIRD+/L1/Adf 5VorodrbjdIWlP8At9Py/wD11qhpN27oaViSCSOf9muSdeUjpjRjEoKEDgLgAcAAcVLnae4PtQ7D eQFAp2DjODipjLUqUdCQzYTqRxVYz7BgHBpZG5JHJqs8oPB5rfnMeQhuUWZslvmNRnT5AmRyKeCP MUlcDsO9b3no9hsAG4rtHHc8V0UYRle5lVk42SORNucnCcf7tFdYILUAAI2BRXT7CPcw9tLscaVx iN1AOeW7mpVZ4XZVXGaVSSYyTzQpJuyM8VjN8qubRV9CwxecAbQo/Wrdk620sW5C4BGTu5FQZORy eBVheIwR3PNcU8TPodMaMep0xm83PJNRHb2XmgcIoHtSS8JxxWdR3KihrFmUle3UdxTF9MgD1FPJ wUI60vTzCOoPWuc1GMEXgqSfU0Lj+LJAoblR/u5phJ2Hmlcqw92AGAAo96ZjOOcY6mp2A8hOBVc/ dNNCBxt5HJ9ajG8gk/e/WpF5K59aZN0z3zTArylj8x/TrRHMwOCMipbj/V571GAPLXj1ppiaGTuC pOMepqqHJ/hG33q43aq033gO2OlapmdiItnAAJ9BUn2hoVAZgOegp2MxqT1xVO56iumnJmU4okbU wGI+frRVI9TRWntZEeyR/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_200912271743380.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_200912271743380.jpg" Content-Id: <61767-572784775480366@4785903> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 71PDezV41QHYcFjjtkj+lTav4ZSKaGRNxAAHSu1iiUSF8c4I/UmpWUOMMAR71j7JdB8zONk0J45r ZVjz8pBwPcmrsWhNLIQX2YUYyM102PajHOe9P2StZjUmncxItBZG+aXcPSpptOSG3CoOsmf0/wDr VrVFMMhAf7wpxpRi7ocpyluUP7LQ9Y1NZGqaM5iLIn8fAFdXSFQwwQDUewindA5t7nmWtWEsaklO Nvcf7VY1hAUuCSQSQc4r1rULKG6tZFkQfdPIrzBLcxXp+UgbTj86zceWViou4Sr+9FXoE4FVGGZR WnbpkCqGxwTimthRyQPrVrZxURtvtEqJ35I+uKettBFRp4h1dfzqL7TCzhQ4LHoKiuLG8lu7qC3G 94pNiqF69f8ACoIrS4gnh+0xsjktwwx0pSU42bsKMoydkXXXiqE27ew3FQMVpOOKzrgf6wnsR/Kn IaKUoUAlpD/31VVkicNg7iPc1g61d3c7bYROgbAjVAQTz1rX0yCWKwxOxeUINzH15rLmT2NJQcVq yuEcgHJoq6sfyD6UVoloQ5HtAvFS4CN0JbmrbypHHvY4WsS8Kx3MbNyCWHFT3rM2lQuGAyBXQ1Yw uaysGUMDkHkUtUbOXbYxE88Y/XFWI5d+OaYXJqjmONn++KcGDKCAefUVDeNthVvRhQMs0VGkiMuQ wx35pxPy8GgCK6lSK2lLMBhCTmvLXn3XzjOQF4/Ou01mSTZdZBIEeMevzV5+JSbt0IGQDk/jWE03 K5cWWlfdMK27UZArnY2/fD610NmwwKTLLuzIqIP9nuUk9M5/KrSYK1WuoyXVVAyVbGfwp9iXtoFn qcEU8kzZDGXJ46dSP51Drd1DeX1k0LbsI5b6kisya1uEaULGWyecMORS20eLmFcEbYzwe3SnVcW1 y9yKSkviJpBwaz5sDeSQMt3+la0kfFZdzA0qlVIHzk81MzRHLXN0X1VyVx5Y2KPUZ5rRh5tZGHcc flSXehPPMJA6g5+Y+1WhbmG2KHHXtWclfUaXvEIj4FFWgnAorYDurpmeSFh13n+lP1Ig6DFyQFHO exzVW8uAsEEi4H7zGc9eKkuLpW0AhlVipPU+hrpaORMuaRJu0pGJ6Eg8/wC1WpbujHjOelcrp915 mkPs+X95jAP0rfsSVGXbChiaXQrqaeMEds1W1M4sifQih722XGZ8Y9Aao6hqdtLaNFGxLHoSKmxZ dt42Nt93lsHmpyGWNRjkEVTs9RiaCOMLISqgEkUtzeInzbsKGGTnp0qtWTojl9cumEt385C4K59P mFce0i/a3xnOD/OtzxDqqma5UbCHJ2/mDXMLIrXRYEFnB6etYzLhuW0k/eiugs5elcuG2ygHgjse tblpJ0rPc02Oihk4qYqkgG7t6HFZ8EnFW0er5SbivZxHP3uf9o1XFjHHL5o3bsY5NXQc0pGRS5Uu gXZRZKpSWiEkgsMnPBrUeOoHGOtNpME7GU1p6SP+lQyWhI5kJHuBWsyZ6VDIlLlQ+Zmb5IHH9KKt 7PaimIjmv/MsgSzhBIDgnpx6UjarG2nSxo479T3rkJb9/IaMtzuFZU19IoKkkZyAM9a6JSOdRO3s dWjt9OljdgGZ1Yc9627fXrZ49320KrdQFJ/pXk8N4Thc5jAOfrWtZznyhzWUpuOxrGCe56G2s6aP vXd2x/2FUD+lVptcstpEMc8jAE/vZGA4GezVySykmkM4jkUuSEP3iPSs1VbZryKx0R110fCQQLg4 5Td3I7/Slu/Fk4snX5A2ONqgc1VtNLt9Zh87SdSguGIz5UnyP3P9a57W7S80tJkvLS4i3DG4r8p+ h6GttVuYtJlS51r7SJWfdu3fMc9cn/69Os282TcScEHAJrm1eNjMpfjOcGtXTJT5ww4ZSp59aykz SKLtrKyam4aSMxs21M9c4yVH6ce1dVay4xXJXfkW7C8eJXaMFxxyDjHH4VVu/G0dgmDA6Of4WUk/ 0rDDVFXTcejsXPTc9Nt7gEdalv8AV7XSbB7y8kMcCkKWClsEnA4H1rxG6+I2otkW7NGD6YH9P61m DxDqOru63l1JIgGQrOSM/ia7FHuZNnvtnrEd7Gs1tcrLE3RlIIq3/aTL2Br51t9QvNNlMlpdSwMT z5bEZ+vrWrH8Q9ej2xiWKds4AkjGT+WKlwY1I97tb1r25eCNASigsd3TOcD9KszQOn3go/4EK8Eg 8Z67p+ozTpdBXmx5kRXKAj0zyPzrpbP4i6nKubm1t5h1JSQp/PNTySHdHpZBHTn6c0xxkcjH1rhZ PiXb28Y+02UyH0V1I/pWja6wl7brfrvjVwCobgjPPPNRJuO6GknsdFs5orL/ALSfH3hRV3Cxwskg WJsNnkGsqa5xIcjfhvyFWJWzG+OB6e1Z0o3udhUN3JNaGaCC/e3uiyAbf7p5BrttFutI1ZRC5+y3 J9+Cf5GvPzbzPchYIZJcjhUUk/pVqW1vLJUNzbyw7x8u9SM0LzRR3Oo240uXDXEMinoUcZ/EdRWd LOblNsMUkp/2ELfyqn4Smg/4SO1F0qmFt27cOnynH64r1L+3dJtUwilsf3VrN043vexSk7WPJLMX unSZkgngw3ysylfyNdTL421e304wiaOUMMEzIHx+fX8a37zxraj90lkjA8fvMGuJ8Q3ME4WSG2hh Jf5hGu0Ywe3Sr50tEyeV9TmbuRpr6SUiNTIMkRqEA+gHApbW/jt5I/MmRQhyQOc+3FVrnTGuZjMN xyMYFPg0eVzgQn64xXLOtHmsdUKDcbs6B7iG5iQylfJkQZ3HAIIrgdYOfI54w2PpuNdg+j6ji1gm hK27EAMQeVr0XTrTw7bQiBtHtECjG9ovMb82yf1rLAU3TjJPvczrJKx8+RWV1cf6m3kcHuFOPzpw iubCT97DInuV4r6Lk8OaJduWtgQccqhAH5dqzp/CdsHOSgjx1+8f8K7nJroY2R4U8/mR5BqXR4hJ eiV/up0+tetXXw+0m+3qlq6yd5Yvkx/Q/kaor8N7G2sfJ/tFobgn77oCfy4pud0JI86vZd9w7A8F iR9KZDPIpG0n6Cuvv/hvrESeZDPBMnYMDGxH05/nXV/DWztdEu47fUdEtZr92kkM0zgtEihcFeq8 knnj603KKVxWbeh55o/hnVfE18I4PLVAw3GeZYwB7bjz+Ga7vVfAvibTrZZIGtPJiG4u0hC/mQB+ td58QvFFho2ipO+h2t1dzOERbqNWVQQTuyOvTsRXz/e6rc3Ty7pWSKVtxhjJWMfRelF4yV0NJo2G 8QanG7IZdPJU4OJMjj33UVy2/wBqKLoZ6Ix09V+ZZZc+p2g1F9stYD+4063Bz96Qbj+ZqmZB/n8P 8KhaTjPfH9P/AK9WSjUbWr4jCz+WvYIAvas/U55ZrV/MldyOfmYnpj/69NjWWQ4SNiPXoP8ACtK3 8P3epW8qK0cZKnbuJwT/AEqG+hRnac4MsDDpx+FdI74j5asCz0PV0lSNrNlMb/MzMoHB9c8/hW1c 2FxHas32y0jmx8quSQfrjp+tZThKTui4ySKYeI3sfm7jHn5tp5x7V3Vjo3g7V1jit75prkMC9tcP scfgMcc9ckV4zeT6kLl4p5/LZTyIR/WsqV54r0SRzyLMuGWQyHcD65pwt1QTjdaM9puNHhsjIqRw qofACsDgZNZoSNmYkgn27Vx1t4mvUsWhvrwXMm8btuQ649T37/41Yh1Vr1GAuCyj+HOMfhUypJu5 MajWh0tpdTXJkSQqRbyEIdvJH+QKnttSkCq1xFuUj76HpXORSMlxuWTcG+YFTgj2rRhYYBjfaadu VsTldG+kqSjdBOGY44PBqxbahdwO24bsHjzPT61zzPzl0/4EnFPtdVdZCjS74enI3H8utO6BHTjW I593nM8YHXb3qSGSCaR2hSNi42nJycfj0rDjlsbpCBdxRMSAQSf5Ee1Mw0bnZKjE8ZVsGkO5tHSM Xn2mbULraBgRmdmUD0AY4Fec+KNY+x+KrqSyfMUdusTckhgTkj8a7S3uJpplics0e0sQef8APWvJ vEV2bjWNXmC7Q04j25z93j+lTu7Fx01L+teLtS8RWVvBe+TshZnUxoFJzjqR1xg/mawSaaOFA9KQ tWxmPCMRnaaK7zT9CtZdNtZGkjDNCjEEjqQKKLom7LEuj7p2ZXxETkZOMZ7VNHYWUHMkoz7D+tUm uXcgM7Nzz/I8CmCQn0yevvwR7mrauCNYXNnEP3duZPQseP8ACg6vPjEYVF/2Rn/63esrzcnOcnrn P0Oe/vSFuCM9OPXHUe/tQkkUXJL2eUZeV2HseP0+h71FvIOQefX/AOv+HrURfOSe+f6/4+tIWJye 5B/r/jQBlanNaQz5mYK2Oi8sR9K5q6ljubtpI8quAAG6/pXodv4GPiNZL5ZEABMYBkK8j6KfX/61 cbrvhy+0K6MU8MgHUcZyPUHoR9PxxS5dLgp62Osj8CXF/Yo+ovBFdqBtkt8gsPR+2fcD65pl58Pb iCDzbG9DzrzsYbR+Bz1rW/4WBpHkJ9mW6uJyOIUi+bPvnj8s1RudY8Q6qCFaLSoD/d+eUj69B+GD VtIjVnKpfXemXj2uoQsJEOGB4Yf411nh6a21S7WEOGyrHBO0jAzz+Vcnqnhq8TdcwXDXTnl933z/ AI1T0uK6e2vrpHjR7NAWUsVk5OMqMdu/TFZuIz0C9SWwm8qUqeMghgeKwJbgS3O2FJHlK/di5P1x Wfaahqd/aySRmO8kt4jJNHLuDbPUMCMgfUH61jT6zd3o8gNsiY4EEC7VJ9wOp+uTSUOrB3WhcvtX ulu2hTbvQ7fMDBj+lV/7QnF88sGozQ3G7B3t8px7+lZxgljvDHJGyurYZSOR9a6PU/Bmq2CCWaz8 +IjIltzk/iB1/L8anl7Gl1bU6HwZr9/eanPZXqxOY4S/mjjuPTjvXAXkvntNITkzXTOf8/jW74bv k0Zr1o2V55ovLVZPlK/h3PsKwG0+SOYHcCAe/FZ3ipu5ajJx0QtKkZdsHj+tSCMqeo3dqer4dcjv SlU7FxpdWXgGAA2nj3opPPT1/n/hRWOptY2zPkH8ev504Tc47Z4B7cg/19KodFXHHTpT2JBIB425 x+Ar0Dz0XhJkY/T06iniTJ5PGev4jP8AP1FVV/1sg7B+B6c0Any8559fwpXKLaycjPXj+n/16VX7 ce/6f/XqAf6xR2K5I/KlUnGc8huKQHovgiUf2PKPSc/+grVvxHEl3aeTJbJNbtnezDO09j7d+ayf BJ/4lkw7eYP/AEEV00v3RWq+Eye55Zc6Q2kM9xZbWQn5434J+jdfzqOK/XUbBpLWQq2dvPVT3FVf HcsiXDRrIyp57LtBwMZ6Yp9kix20aooVcdFGBWZoii0k0Uv/AC0EnqSST/jVXWWiaz86ZEW7xgMO C3bn14rZuOlcDfOz6lNuYthiBk5oY0belWmo6zC1pHeNBYRkb1DcZxnkd/xrt9F07SND2vbwLPcd 5ZOf8/pXGaRI8ejrsdlzqCg4OMjZ0rqoeopXE9WclqlneTeKLieW3fZNcM4YL8pUtXrMN40cQaKT j65BrlbofujVVJHJtIS7GJ7qNHTPDKTyCO4oW43qje1yw0PXNGuby8Edl5Y+W/VRtZvQDq34fhzX lMGozwnZuEiejjP/ANcV03xJlk/4SJbfzH8iOFdke47V+g6Cub0RQ2t2asAQZRkGlKKloxRk46o6 Oz0TUNSsPtcemzpH2Jx830HU1mzafLE+DGykHkEciva34AA4AHSuB8bcahp+O6Pn36Vy1KSiuaLO mlXc3yyRx2yT+4fyoq6etFc/MdPKj//Z --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_201003161746350.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_201003161746350.jpg" Content-Id: <48692-9128315229495@896960> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 9Ht9DMaiJJ5cLwGLZP61HeWV7bqnlEMRw28Zz+WK6C3k+VjtPapZB9pUMF6HBrznE3TOUubKdrZT cWUE4I+dCOn4HNYk0mm2d29udNuLZlIG60fywen91l9a9HdEDkYGcVyWv2gbUInVf+WZP60noPmM 6HUoQQsOs6hAc/clXf3x1ZSf1rRt9a1AqGh1WxuF7BkKk/iG/pV6y0a2unlmeMEqu5frVmfw/ZJI sYhAQrwPwP8AhS1BtFeLXtVUjzrGN1PeGfd+hAqwniaJ22kEN6YrD1vRxbC0uYCysFx8pxn5h/n8 aWCAGdWA60uZlJJnTtMt1AlwhyDkH2IqHt/9aqVrMbZzGRuik6j0PqKsNHKzYjUsD0Ipt32Lj2YE 5bA6k8VpBABUNrZFD5knLDoPSrZWmhSZCRUbCp2FRMKoSIiKMc04ijHNIZRYcmo3HFSt1qNqkors KhYVYaoHpAQ7aKdRTuKx28FmsSAHkkc1KkCoMCpaK9D2cTjuyFrdWYk96zL3SPtF1GQBtCFSa2aS plRixqTRm6XZiK1G7qy4NXJLZZGRj1WpVGBS0oUo8quDk73MbWNO82xwvPloT+oP9KwIItrkf3eK 7aVQ8Tqe6kVyir80repzXPWpqL0NaTuRlf3i1sWyfIKyf+Wi/Wtfz47OzNxLnYuM4GTycf1rJGsi 2EwKRlqla67Z3jRLAHdZGwrgDH86XUdTFixBgeTAz8vNPmRCTuTMKiYVS0nW49YLGKFkQDOWPPXH TFZ+t+IJdLa52WwkWBVYnPJz2A9aL3LsbRHNJ3rmtK8S3eo6lBbyW6RJIu4gghgMZHeuloGUmqJq laompDRC1QtU7VC1ICOijFFAHf0UUleocItFFJQAClpKWgArmBHgXg/uNiumrCkXbLqa/RvzFc2I WxpTepmZ/eJ9a0tRwdDmz0+X/wBCFZTNiRPrW9CkdxbGKVQyN1B71ypXTR0SdtTnNDWOOW1iQABZ MYH41f164MN6EUnc8WAo7nPFbEWmWMMiyxwKrqcgiku9PtbuVZZog0ijAY9qfK3uQpq5znhmFoJZ o3RVYL/CeuTmqHiKVo7yfZEHzJGGz2+Tr+HFdVb6fbWTu0CkFuuTnvmqN9olpezSSymTMgAYBuDj 2qotp3Zej0OU0O5hufEqeVv+RcHf16NjNduaybDw3YaZdi5thIr4xy2Qf85qbV9QOnLbvkBHmCyE jOF7mh6tsNhz1E1SkhhkHIPQioXOKhlIY1QNUjNUDPSAKKZv96KQHoNFZj63axRvJISFQjOPpmqc /izToZNm4kbS27oMAf8A6q9H2sO5x8rNS61Owsc/a762t8cnzZVT+ZrFuPiB4StmKyeIdPyP7kwf /wBBzXgHxj1W31TxrFdWrho2s4x+PJ/rXDeaqxjIzVkn2Vomv6X4js3u9Ju1uYEkMTOoIwwAOOR6 EVpV8/8AwZ8SmwsNUtS2EMyuPqVx/wCy16Ze+LMJDsfHzfNjuKxnXUW1YtQbOxklWOMszADFc3Nq MEl5fKpZTJCG+cYHHHH51j32vNLBF+8PKDv7Vz11qYiuLWcsCHBgYEnv046dRXPUquZpGNjekv4R Oib1J46HPeuktZwsYbnHtXmz3y/bTnhQBz24z/iK7LSbvzbNXY/n2rPY13OlS8hbjfg9eeKQXdvK WCTxsVOCAwOK4LWNeu4GnRNiqfljXndn/Pt+NJoniHS10WJZ7vZNH/rfOBXLnk4z1HNU+ZbonkR3 rHPINQvXFt4tthC0tncmdMkAoCRmpbDWLi+0qC/Mp3yFxweMBiOn4UnLyK5Tqyaydc0z+0oI18/y wr5+7nOcD1qtFqs4A3kN68Uv9tLPcJbbPmdxzn0Of6UKaCzLVvCba1igLl/LULuIxnFNkNTMaryG kykRNVeSpyajfBpWGVuaKkwKKBHM3Ovl4rhGfh1/oa5m51N3hZUWVvkwABkkHPpWc+rGx1BGWNJF wQyOOD9PQ0reMlWY+TpkYbpl37fgBWmq2RKgn1OA1e6nlnRZy26IGMBuwBPH61RFwQMflxmuq1QQ 6pcm4ntoFc8nZuGf1qtBBbxn5Y1XHcKM/nXQq6tsZ/V3fc0vBUtzbpK3kyBZpFVXAAXjPU9uvU12 VxfttClskcHBzXnszgkBcnHqa6C0mZ7WPAz2/LisZe+7mnIoqx1bakzpHgn7oohim1VfssNzBBKB lXnJ2gjp0Brm1uzECJG2BerE8AVastQgk1JBFKryLGd3lnpyOv5UnHS5K3sei2vgKeZzK2oJJuOd sK5yMDuT7elWrvT9Q0XaIILieEjDHHKe4GOa56w1m4tmVoZ2Qjrzg12mmeK2eMC5cEHGd/8Aj0qI tX1Kaa2PM9RvUm8RFTIypbxmUhxjnoBg9Dk5/Cue1q6IgGHBXBIVV4GeSa91vbHw3rYLahYRlmGC 65Un8VIJrDk+Fnhi4BFteXceTkL5wbH5jOK2utyObocnpEZ8PeEYfO+adh5sgB6FucfhwPrXKXOt Xd7qMMK3DKhfOEOMDvXpWsfD/VxatDZXSXQJyvmfIV/z9K4V/hlr9tqJmEiRuAMLjcD703KNncF5 HYQag/2VQ3LY603SJjJrtuG67jWTBpuu2IAuIY5FXqUfB/I/40/Tbgw67GSWjZFeTJ6ABSSD2rlS 1Nr6Ho7sBVaRutOeTmqskig4LAH0zVMQ8tUTvUck6xrudgBkDJ9zgVXN3G8jIrqzLwwB6UITLG+i q3mUUxHh9/IftURz1WqO4eeTnkrUN9cv9ntWXmVVAcEdMCoJ7oRIku0ksOBXTyXJjNLc1CflOBUC Sfe+tZLahezcRptB9qfHp1/cn53ceuKSpW+JlOtfZGzZWg1G9W3F1DASMl5SQqj3IBx9TxXsuhfC cx6ck9zqRmVl3BYUAGD6Ek5rw1dKawhklLHdtIrvvDfi3WvCqoLO732h5ktZwWT3IHb8MVMku+g0 3JeZ6ynw90ODSjJJYpNLtyTNlv0PFcFe+HNGsb6We3jWyYp8xXhDz6dvwrL1b4t+LNUtZxa/ZrC0 QEH7PHubH+82f0ArmI7KbVgl1qGoSzlwGAdix5+vSsKtFtpxlY2pVFFNTSZ0q6pZi5FvHfW8z9tr ZB+latrqDwTLIjkEVwdtplu+p3dsq/u0UYDciripf2JJtbljGMYjl+YH2HcUtFpcbg2rpHqdrfwT 2xe3R1kIGfLOOe5x0/MU2a7nhIZZQx6nPysP8f0rz7T/ABR9jKreQSWxHG8DdGfxHT8RXYR39vqF us0UqyBhwVbI/MU2jO2pt23iW9tyC0rf7r9Pzqa+8fXFrZPIsEbPnCnPFcyRJkmNsgdjWXrPNk24 YbcM44z+VJNhyog1bxTf6lKTPPyf4UXH8qx9HuzceIjDL80ckLqyluqngjj1Gaqyy7UIHAqnoEuf EzHPSM4/MVtGOjZnJ7I9tt9SjuVHOG7isfxGZ/s7yQsd8f7xDzwR2H15rOhmZQCDzV1LsyoY5CSC OvpWNy7GXq/iWJ9JsZBy0jxs23ICspBI9xwfyrCsPE/2S+1h2TeXlLpz3LYA/wA+lTajHsuVhNvi BGaVSo6nH8sbjjtWTb6Xm7ldMNJneqn+9g7c+wzVxsJnexX7eSnmSK0m0biOhPeiuV/4RxDzJudz 95jM3J7npRTsiTm7nTA4DCFye4x1quumpuUtCCB2NdbHbBlG6Bh+Bp76fGD5gRioH3Nvf3rBVmjs 9lFmDb6XGy7o0AX1xirCWiRsAGwe5FXPKkDGVfkz1yM5qVVR4/kUlh1BraNTmOedJwMHVYC9t5cf JJ6etDyfKylSPlPatWSGPaGYNu9M1Vntw4bCk8dBWiasZO5iWkqLBMjHqx4qza3hgG0E47fSqq2M 0IKyISS2cjpUotypzk1eliW23cuWlxjWJpCCBIi4P0rdQRN94Jn2PP5VzkcRY9cY6Y4q/BLglc4x xkms5xTNIza2NVoLeSPyyevVc1B/wjtxFKLnT5pLdySS8XA/EdD+IpIyzZC8j/Zpx1GOybDOXftG g3MT+FYOnJfAzoVZS0mrlldY1XS5Smo2ouowcedB8rfl0P4EfSn6jr+m3ukXHk3SBl27o5PkZeR1 BottWlcN5tvs47EBiPfAxVa+sdHvoW3Rqso6ZABz/L+VZqq07TX3Gzw6krwf3nG3msGUMtqpYd5G HAqxoVvc2ryagu+RyMYaM4P0IrVPhotB5tuVcZwUB5/+v+FZrxXdmxg86eJVONm5lA/CuuFeEtEc c8NUi7s6Wz8UWpcxXW63kHB3DI/Ot2K6imjDxSLIp7qc15z5Q5IUN65JyaWCG4STNqzxt1+RsUmo vYLNbnoGqaTfXOh3Oq25iEEHyOGcBiSMHbnrwRxWZ4feOWKW43AkyEbe4x61jXOvXw8P/wBmXMhf bKZN3qCBwfyqnomtwWJlS4LqrsMPtyKtU9DFz1seieaKKwBrtiQD9sh/77FFLlY7m5FZtEUUsSPX Fbmn6TNOdqx71I/CrWmIrCLKg5Pce5rvtNijEMZEajg9q4YpSdmds6jirnk3iHw1LprpK+1Y252A 9DWGtn5rqgzGO7D+VeseNlUWfCjqO1eeKALYEDBJNRJ8r0NaT54amHOipNsc4C9GUHBp8djK6eYi ZiBGWIwK0kRXsJ9yhvkduRnnHWk8Nu73qxuxZMZ2k5H5V005uSOWrBRehGNFtrm28yFt5/vcKuf5 /wAqxtQ0Oeyb54+W6bQSprsLweXrdssfyKduQvAPNbN2iPHcqyqVC8AjgdKtSaMrHk3kMGy5bd0A 6U5hDAAWYEnooGSf8at6mStpMVOCHA4+pqHRlVtPllZQZMkbyOcfWqlK0blQhzSsENvdXWODbwn+ 7y7f4VftdOtraKYRrsY4wzHJP4mkQkJDg/xVdHzZzzx3rlnUcjthSjDYoz280USyjeynuMcfWqUr l2OYiAT1z0rdQlQoUkfT61S1dEW6faij6D2rNS1sbOOlykbuS2IUSO0TDoWzV1Li2vUAm2ZA43nI /wARWbIo2rwKbaf68jtg1bgnqQqjWhtf2FY3aARuqSsONj7lJ/mPyrGutJvNKnVlQOpHBByGHpUk DskgZWKkHgg4roLh2+wW0m4+YX5bPP51HPKnLe43TjUWxxV+LW6H7wPBIKoLBDbwviQyL3wM12Hi KGLz2/dpyOflHtXL2yqJSABgk5GK7adZyjc8+pQUZWMn7ODzsH5UV0wijx/q1/Kir9u+wvYo/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_201001221956000.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_201001221956000.jpg" Content-Id: <30646-129308067160212@8309257> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 7rZ7UFR6VJSVBBHso2+1SYoxRcZGV4pjLU+KaRSuNFG6iMkEigDcVIUn1qS+v47qSweS2eOOJgJQ QDx68dqldc0xF+ejmaKKk+naZqGrXxkRFRIg8ZztyTn6en61nDQ7mC3sHs5BL9rYhY5RkIMEjnOe gqTXwY4JpE4cYwfTiub03UdZQfaLe5keWKR/KV/mUDdg8fTNUncLGm19LF5qNDCskcnln5VODk56 j2qL+1boGTDquPu7RjBx7e9ZlxDcSefM7NuYlmPqxBNRR2U0qQOu4gqc/jinqVZHTi8kYRl7nOQP vHI6j19s1qaRDFcyzyEJJtwFOAcetcTHolw0KRFjzLu/MV1/ghSulsD1Jz+pFJqxL2LPiJWFpb7W KnzgePQA1lXlzD5kUMlyd2QSpc5xnk/pWx4jyxtox6lv1A/rXGXkPneJin/TPH0/zmhAti99vsmu jJ9pQoXVOvH8X9ay9UvbK5mZ4ZQ6lSAR3OMfzp0WiKIhDk/fD5z6ZNVf7GWCIRqThWz1/wA+lVYV zQTV7C1tfs8sgEhHA29un9KjutesGZJEZiiN82F74rJfThd69KjA7UBxj/eNXf7AiVPKw2Cdx59q OUL2EPiWwBIKSZH+zRSHw3b5OVOe/NFLkQuYwF8beII5BHHqE0j/ANwIGP8AKr8Pj7xAhCzTKG9J IQM1Qs7RLSEIg+Y/ebux9adeW4ubV0/iAyh9D2rh+srmtbQ9X+yX7K/N7xux/EHWUPzpauPXyzz+ Rq4nxDvsfNaWx4zxkf1NefQykxI3XI6VPblw0jtJvBGNhHAFdDTPFuz2bw3rTa9pj3TwrEVlMe1W z0AOf1rYrkvh4R/wj8uOn2lv/QVrretUaoYwpij5xUpFMAw1JlIxfES/6FcH/Zz+lZWjW/lxPkc5 b8MnNbWvRl7G5/3Cf0qPT7bMbkjG6QD+Yq4ldDOvIMQS4Hcjr+FFhCBp9vkZygq/ewkWkrY9/wBa lt7bbZQJjkKP5mqQiOKINJGuBgEEfkat+E0EVpsx0X/2Y06O3/eqcf49D+FWNDj8oMB/cH880SER aynmajCOyoB+bf8A1q5qODf4ouWA+6gP6A11d8u6+z6so/IE/wDs1Yun25bXdRbHTC/pj+lJB0Fi tTjdgdDVaaz3MnA+Z/8ACujhsyI/unpUM1mQ8Pynhyf1H+FVchHHWNvv1m8YgcKp/Pn+tbDW3zg4 HQ/zp+m2DNd3b7P4lH5LWrJZsJeEOAKYPcwzFgn7v5f/AFqK0jA4JG39KKYjx2z1aLy1S6JSReNx HDe+aluNUi8tktyZJCMAgcD3zWvD8OtZbG57VPq5/oKvxfDW9OPMv4F7/Khb/CuJ4aHNc9BZlX5O XT1OIWSGCPZI4GBjrzSpdnnyYWOe7cCvQI/hfCCGkv8AJ77YRn881dT4c6eo/eXdy302j+lb2R5v KS/Dd2Ph+ff1+0nP/fK12QPNZGjaPbaFaPb2pkKO+872yc4A/pV8Sc9aTNVoWsZpnAY84x1qG8uH t9NuriMAtFC7jPTIBNeazePta37khsyCO6t/jQouWw20j0u4tDdQTLtPII/Ra1bLSAsQGw/6wnpX ktt8TdctixeysHB6gq3qPf2r6IhUCIcDkZqlFrcd0cZqGlA6fLhOcen0qxHpAaJfk7V1M8aNCynH zcfrUqIoQDAp2C5yZ0gIwbbwAc/lWbp8ezeO+1P5V3zopQggdK5N4BFM4A9B+lDBGS8Zmv2x25/H p/hV3QtFeSa9nK8PK2Pzp+lwiW7mc8/Pj+VdVYQLDbAKMZJJ/OkgexRXSsJjFVZ9KOCdvQV0VNZc qaok5HTdHYfaGKHDTsRx2FXzphDE4reiTYgH40/FAM5Q6WSSdn6UV1ePaigVjzkCnhSexrMk8VaV F913f/dQ/wBaqy+NYF/1Vq7f7zAfyzU2Eb3lsegpDC9cfdePnjB/49ov95sn+dYV58SACQdRHuIl osB6U0JA5YCmRxoXwCTXj8/jwXBIVrmbjPzPgfqaonx7qttIy2zeXtOP9YWH88Ucoz3DVZbaPw9q IMq7vs0g/wDHTXgP26OIsrMBhj/OtjxLrGqRw21408hN7bxM7sq7XzGNwxjHGcevSuT3WctyqhZI kI53yBufqAKqPuq4NXdi++oRu21W6kCvrG116zmt43WVcMOOa+ProWkMg+zsXYHIOciu48FapqH2 SeO5lmIQjyw+eBg9Pzpyd1dFKNnY+knvYX2rvBIIPFLcalDaxB3bjjivLYtUl3SMJTnI6H2qzdan NPApZ2ONg/8AHRWd2VynoR1mGQTbCMImc+9YouBNvfsP8K56K5Yo2G6tz/30K0omMemO7cEoT+Qx /Si7YWsTaJdJHE8hySzlsDqa7C1nR4U2tngfyrzPS5iF3+iE4/E/4VvaXqrRBVZuATn+VNSsJo7f NJnisqPV7di48wZUDip0v4XUYdT071VxWLwPFLmqouk3KAw5GaZJfRowGexNF0Iu5orD/txfQUUc yHY+RZfFOpScK6IP9laqNq1zMB9ouZ3O7kB9o2/41nkmkwMdTVWRI+SQu2SSfTJzTM0YpKYXHq5F TLKMc1VpQaAPX9QkVvh5YEqpxBCRkdPlArzC2uvs9+ty0McoVifLdcqfwrcuvE8snh+200W6BY40 G8sSTgY/Ckln8Pf2RtzO915OAAvAfHr9ai9uhSRjWf77VLfPyh5l4Xtz2r1O2lE0qHoFBJHphRn+ VeRwsyzRuAcqQa7rRtVE9vIu0qWXYAPXIyfyzTkETt7VwLdPX/65FTPIW2KG53KNuP8AZXn9K561 1crDgoGxwMH3zU8eplWSQphlO4qx4x0rOxqbE2rtaJkIcH+Nvu/eP+FUb/xbIEhAuNu2LGIwCM1l +JJlbToIg+UlniTIbBwW56dOpqKGxS38Ha/dw3M8ccN48aQ/KyMqhQM7gT+IIo5bkt2Ot07WcWbK 6ctGoBRw2Mgdu3JrRjuiLeSRT1IArzzwu7G71CJCfnELEE99pJ/mK7qbbBaImecjP4daGhF/7cyG Rg2M4/mBUkGpvgqW6kf+gmufu7jy435xjA/mf6U4T7XYZ+7n9No/xpILHQf2nI0nnCRhhAoGfU5p yawzxs3mElRtPPtWAtyiRMZX2LkYPrxWdHqECyTxxS7kzuPJJGR/9as3OzsUoXOh/tFxx5tFcNLr BErhYpSu44O4UU7svkR5ITRmkwacsbP91S30FdRzWG8mnbD3GKvQaXPJgt8oPpya0oNKij+Z1Lcd WrOVSKNY0ZMw0tpH+6pb6Vch0iZ8F8KPStxZrO3J+QOfRelV5Lt3JEaiNfbk1PNOWysXy04/E7li XTrVbOAykAqoHJ61WZLNBiKEsfU8Co8Fjkkk+pq/aaZcXWCqbVP8TcD8PWhQtuxOpf4UZxj3dgPY CpYBOjYiY8dq6ZPDiRgo7Eyjk5OOPUDv+dPutNt0ZVhm27htY3GELkenb9TVXWxF3vcwor64tXDm EBgchhxzVpNZDkh2KZ6/IP6VZawkhIJQbVJXgjBPuec1VuLWCKIBcGXOSCP6VNlsaKUrXH3kz39p EkE0e6FxLksB0PGajuL3U20iewie48u5bdIoYMjscEnkZ7dqoNb5JIUAelSRPPAcxyOuOgBp8rWz JcovdG3pNybFPtDSuJZjuOFGBg4Hrnp6VvJrk90sfzBxhiPlxkgeg+n61g6LZ3V1h5VRbf8AvMvL fSt+x01IboTqq7x9wdh71i61pcrNlSTjdEF9qmvaddvINMBgcKSrw7x09fzpLPxYt1dpb3WlRguc syOUx3JxXQzXzrbkyGQ44yi7j/WmWukzamqrdyARKeXK7WYf3R/jS5hWsjn7y93hp3O2JPurVW1c wabJcSAGS5OcH+72rp9dW2s9OlijiWOIqUwByciuTuFkuURopIQAvyxNxx9elJLoC11KxkGfvGio zFdgnNpJ+AorQZzraKLSXy7hHDjqHBFWB9miXaQuP7uK9Rm0201CMx3MKyKeOeo+h7Vy2qeAZU3S 6ZL5q9fJkOG/A9D+OKSak/eZDfKvdRyzXuOI4wPdqhaSSXl2J9u1LPbTWkzQ3ETxSL1V1wRQgBOC ePat4witjGVSUt2IF59TVuGyd8ZGwHPJHp7U5I1A/djnjk9B657VsKtlCgNxckyEj5I+Tj6njOKG 30CNupQtrQwskm0M+MkMoYD2we9X01G5WWPcqLsb7xwMn6VXWXI5cH15p7oeN56jqccj6g81nzO+ pryprQ0P7Tu3uZZCqOwGFJ+7io18RSWepxXBgSURggxHcBn1B/yKx3uYY2BgALdztP8AU0xpDO25 8k1aV9WZvTQ2tT8Q/wBqoqJaLAQ24uWy2fQEAYHPSsvb69ajXaKsW0Ut1OkFvG0sshCqijJJqrWE Mxiug0zw1M6rcXkeE6qjHBP1rqLfwJ/YFvBc6i6S30i7hEvKxfj3P+fesjU9TxI1vA3zd3H8q5K1 SV+WJ00aa+JjpikSKkSBWHVlXp7UQyNCu4AygD7ves1ZlxiVjx7n+VNZRMVa2vimOq461lGKRtKV zc0ycX92pie4j4+aNxxjPXkZrpNqrATu2Mpxis/QbV4Ih5zF5D94k/pSa5qkVrC8jNwo7dSfSq3d jBs5vxLdi4vEtS3yfeasrZkEqMgd6qS3BuHa5flnOevQVFc3ZitxEh5fg+vvV2bZatGJA93NvbBf GeKKr+Yv+1+dFa2M+ZnqkTY6VbQ5AzVOL/VCrkPKLmsLjI7zSrHVovKvbdJR/CSMMv0PUVxer/D6 5t902lSG4j/55PgOPp2P6V6CnUHvmrEVXGbjsQ4pnhTCa0mMcqPFKpwVYYI/A1LHcY4K4GOo659T 616T4/t4W0EzNFGZVcBXKjcB7GvLO9dMXzK5i1Z2NBpUUq27oc8Hn6ewqvJLJIuwH93ksF7CoO9S LVWFcaFPTmpFVcHLfnT06ih+tMCayspr+4EUC5J6k9B7mvU/CkWm+FYmnZY3uiuGmcE/gvpWJ4Ui jGixMEUMzHJxyeat+ICV00lTjlen1rgqV5c/Kuh2U6UeW76kfifxlda3dja6RQqNoRByR71zxO45 IB9eaq/efJ5OOppi/wCt/GldvU15UlZGnG0fO5QR7irWmWUM99EiR4VTvIAqgPvD8KdI7ISVYqcd QcUria0OxvdSg02AzO6qF65rzjVNcfVrooBtiLfL9Kr61PNLND5krv8AJn5mJ9ap2w/fE/7NbRjZ XMOpbEuNw7dKgiD3l6yRI8uxCcIuTgdT+WfyqOQnB5q94E58S3OecWrEe3K1cI3CpKxH9kuf+feb /vg0V9GWUEJsLf8AdR/6pf4R6Cir5DL2h//Z --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="mid_201001222004040.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mid_201001222004040.jpg" Content-Id: <53467-607497673692392@6335482> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAegCi AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 6K31vT5cZkZD6Ov+FacNzazf6ueNvYMM1ylxpTWieZPbSxqOrDkfpUCx25Py3GPZuK85Si3o0/mb uLtezO8CCnCOuOgFzEMw3LYH91yK6LRJ57iOTzpC+3GMgVVmtxI0dntSFBU+KQrRcCAx00pU5WkK 0XArFKYUqyVppWncLFUpx0pQlTFaAtJsBgSniMelPVakC0rjIJHigAMjBc9O+arvqMY/1cTN7n5R TtRXmL8f6VSCV4ePzOrRqunCx0U6UXG7JHvrh/ulYx/sjJ/Wqz75eZHZ/wDeOR+VSsnGKTAIrx6m NrVPikzZQitkRhABgcVIqUoWlC7WY5PP6Vzc7GN2e1FP59KKLsLljX4TFpTAsSWYDqf6k1yPOAM9 u4rs/E5/0BB6uP5GuLI+f8K9XEa1Wjqw2lI1NGgRo5nKDOD2rc0JcQy/7wrL0cYtZ/ZTWxogxbuf 9qvdwb/cxPNxH8SRp4pGwoJPQdadTJv9U/8Aun+VdT2MEZKeJ9DeRo/7UtldSVKu+0g/jV2K8tbg ZguYZB/sODXz1qTbtSuSDyZWP6mqis6nIYg+orRU79TP2h9K4ppFeB6RqGrXGowWlvq89t5jBQzT MFH15r0vwFqGoXq6nFf3v2s20wiV8gg4zkg9waTi0VGSZ1xFAFPI4po61DZdhwFSKKaoqQCgLFDU hzF+P9KpDAPSr2pD5ovof6VT4r5DNn/tUvl+R20fgQ0gk9Kbg7zwPzogiMCFTLJJliQXOSM9qc7r FG8j52qMnFcMIOpUVOGreiLm1FNsp32oQaeg805dvuqO9c5eeI7oufKYRgdgO/1rO1e/M928u45Y 8ew7Vn+YWjzyTX6hleQ4bC005xUp9W9fuPn6+LqVJaOyNI+JNSz/AMfDfnRWRhvSivZ9hT/lRz8z 7nrXiZ82sf8AvH+VciTlj9K6XxJJm1QYP3uvbpXK7vmb6Cvy6tH962fYUP4SOh0f/j1uz/s/41ta L/x6t/vViaMc2N2fb/GtvRv+PRv96vcwqtSh6Hm1/jl6mgC28gj5expJv9S/+6f5U+o5v9TJ/umu mWxitz5tvMG+ld0IVpGORzxuNQsUMojiV3YMRwM5HbFeylI0LKsaKCegGKsWUNuZ8zbVXr6Z/SuC Ga80uVR/H/gGzwiSvc5LwVpOmWun6nqOtwKj25Cnz1x5Yx1Ge5PH4cVp/CjYdO1Ix5KeeMZ64xW/ qFvp02nuihJAXDFJFznqB19Mmp/DUEUENwsUaINw+6AM8VvDGc81Ta1fZ6E+x5VzI2yKaBzTz0po rZkDxUgqNetSimgKGpffjHsaoc56jGOmKu6mf3kf0qkDntXyGa64qXy/I7aXwIZcXEVrbvPcSLHF GNzOxwAKwL+9vb3SjdLutbSU4jQoN8i+rZ+6D2GM+46VDfuuveLodGJJsbFBc3S9pH42IfYZBrW8 RSBdMwRwWHau/JKEY42ipq8nr6Kzt83uc+Kk/ZSsee3DZc565zTd21cDqakmZS5wO9R7ACM96/Uk eAHmN/eooKjPSimKyPSPEkh+yR/7/wDSuaBOW/CpdV8TWmoIkcSzKA2dxjP0+tZg1Rdpz5nX/nk3 +FfmlTDz52+U+to1I+zSudhoh/4lt0fUVvaN/wAeZ/3jXNeHZxNoty4zj3BFdFo5/wBBH+8a9ShG 0Ip9jhrO85NdzUzSMu9Sp6EY4phbFZV1rZt7uSBYgQgHJPWtnoZJXLR0i2JyVNNOj23ow/Kqa+IW ZseUuPrSvr21ciJTn/arFxpfyr7jT3+5YOjW5/vVPa2cdmrCPOGOTmsw+ITjPkrz/tVH/wAJCWXP kj/vqiMaad0l9wPmejZuk8U0Hmq63AeBX6bgDihZs1pYgtqalFVkfNTqaYFDUv8AWp/u1kQ3sj6l cWrWkqRxIrLcMPkcnqB9K1NTb9+g/wBn+prOk3GGTb12kD8q+RzG31qaa7fodtP4Ecp8PXN9ca7q zj/j5u9qn0Aycfkwre8TrI2lDYMqsnze3FYfwxdf+ESYDqLlwfrgf/WrrbiL7TaSwtgb1IHt6V6F HERw+bqpLZO3ytY5qkHOg0jyyTJk4oZuc9+laUumzC78nyWEufu45ps2nyxDEsbL9Riv01Si+p4L dilu+tFT+UMdKKsi5jXuvzlhai3lEUbkbkbOfzH9ay5NUvzKwWJ2jUg5xyvpnj2q54nvoJtNs4om k8yKT5wQMfn1rIhvpkkvNhC+ZMjHPOMOSK+TjCk1zcup7t6q925674JuJLjwtNJKCHJOcjB611+k tiwX6muP8G3Mlz4auJpWDOTyR9cV1WmnFgv1NZJLm0CV7O+5zviT4jWvh/V3057KWZ0VWLhwByM1 w+s+OI9WhujFHLbzSFWjIcHBBB9vSrfxWsoY7i3vFjAmlO1n9QBXmu4iuuNOLSZhzM7Oz8d39sVW 5ijnTPzMOGx+HH6V3sN/Fe2UNzA+6ORcqa8biZZLGfMaBowuGC8nn1roPBuryRTjTWYGOY5i3H7r en41lUpJptLY1jOzSfU9GllxGOnbr9KxtW1yPTLN5WOW6Iv941pS211KODEB7sf8K4jXfDGv3NwZ 9sVwg4VIn5UfjisKfK37zNZ3S0G6d8RNbsQ6O6XMbMWCzA/L7Ag8D2ratviyyOq3GlgjuUm/oR/W uH/sLVvPEH9nXAkIzgocY+vSpn8H69EN5sHcdfkYE/lmutql1aOf3j2Xwv4ztfEc0scNtPC0ahiZ MYIPoc116PkV5Z4BsWtJ7hpIGilZsNuUgkDGOv416ZA3ArCcUtik9ypqTf6UP9wfzNUYpUkXdG6s ucZU5Fcf8XdTu7S3tbW3do4rjcJWU4JAAwv0Of0rlPhrrE1trh00sxt7pWIXPCuozkfgCPyr5/GZ XKpGpiU/l5Lc64VkmoWOt+Hzi1ute0o8G3vC4HqDkf8Aso/Ou3zgVwsudA+I0V03Fpq8flM3ZZBj H54H/fRruM152PXPUVVbSSfz2f4lQ0XL2A7S6uUUsvQkcioriGC5IM0Kvj1zWD4v8RahoVvavp+n /aTI5EhKsQoGOOO5z+lYPjLxnqukS6elnAIBPAszmVNxyeqfh3+tdeD+vtQVKdk7217GVSNLVyR2 v9n2P/PpHRTNOvXvNMtLp42R5oUkZQOhKg4/Wih5nj07Ooyfq9H+U8aeEXTMWg3IzEnAOauLo9l9 nMhuxGWbcSy4I5zjBNVryxmuI0WW4VQD15JpkekQhmLXMhGeQqY/ma+hbX81jZpy2iemeEFRPDt0 kcokUEfMPrXV6d/x4J9TXn/hu6Ww06WCBy8DHLbx83Xtiuws9asILFBJcIDzwASf5UU5x5tzGrTk r6HIfFtB/Ztg/wD02I/SvJT1r1L4lalb6ppNtHaFnaOfcflI42mvLDnOCMGu+m01ocri1uXrI4jl PGAUyD3+avWra10aRYp3061Euch1UA5HcHqK8ksOUm/4B/6EK7m+8TDTLg2i6b9qlCg7w2MA/gay qQ5nb+uhrF2S/rudq+oWqhcFASO7VXbVIs5H57SRXAS+LdUk5i061iXoDIc4/UVTl8Tawwwb+0gG c4jUE/yNZexiXzSPRn1R8ny0cjthf8aje/uFB3/IPV3AxXls2sXMo/faxdvnqseVH8xVJ54pWyI5 5z6yPn+VP2KDmZ7doVwLmSSTzFcAgZVtw/OuqiLGMhTg44NeSeDNXl02xEL2ymLcTgNyOfevQ7Hx JYSYDs8R/wBtf6jNE5QWiJUJ7tCeINNsdWDWupQLLGQGGcjBx1B7d6xNE8D6Po2ofb7Vp5JQCE8y QEJkYOMAdvWu4hmtrtNyPHKPVSDSNp1rJzsCn1HWvMrYGc+b2dVpS3XQ0VRK11sc9rGi22tae9pc g7Tyrr95GHRh71lRXniHSYRBd6d/aaRjC3NtIFdh/tI3f6GuwbS2X/VzsPZuf51XltLxFO1Uc9sc Vwf2biqceSynH+vQv2sG77HJP42hhB+1aNrEDDs1rkfnmqV14vN6qrb+F9SvFByPOt8Ln8jWrrEd 1LLGRNJbbTyrZGaz77UL2G8Gxm2HG0DoaulhIaXhZ9rv+vxE5PuRf8JP4lPTwnIB2zN/9aitr7S3 cmil7OH/AD7X3y/zFd9zz+WMK/qTzTfI3HI2/jV1baWTAVGOOmBUi2TI37xQuRk72C8V23b2PQvF bsnslEdo/VTVyFg0QVs5qC2a0RWSW4C+m0FqnzDEv3JiM8dFP5cmrjSqt3sc88RSV/eMvWo90CKB /F1rn5tMinHzrz/fBrtpFacrss8gf32J/PpTvsLKioY4Y1znAQZ/Pk10Rp1Frexk8TSatytnn8Ph u784NGS6hgeFJzWlrOi6pfXr3cKCFPLCuGkCnjjA6E12osXmG6S4kcdxk/8A1qb/AGTag7mWRj2B cj9BXSpTv70vwOdyi/hjb5nnieFpWK+dfQoW7ck/pmkl0FLSIyNHNc46lB8oH55/SvSLaytLdSBG CSc5dRn+VXo0QrtULj0xTc3bqTrfp/XqeU29tptyu2PET+jAZq9DYtEu3aJV7HaK7TU/DWnamSzW yJJ3kj+Vv8D+IrmLrw3q2mAvY3AuYh/yzfhh+B4/WsJQctn951wrqO8fuLFlHHGF3oyndxgcVpeZ 5a8Z/Kudtdehik8jUraS3k9dpOPwPNb9u8N2qSW0ySYxyGyfoRXPOE4/EjeM4T+FkyXwjcEMVb+8 pwRWva+I7+BRtuzKo7Sjd+vWuevS4lzErYLdAKaDtIGSM+4A/lWKq21KdJPc7e28a44urZf96F/6 H/Gte18TaZc9J/LPpIuP16V5kZljIyVOOoNNN7GpBC8k4OB0rohXb2OeeGR6F4yWPUfBmpeQ6uUh 81WRs8oQ3UfSnafZWeqaRaXgTa08KOdpxgkAmvOpbjdFIscrKXUqdrYyDVjwz4o1Kz0iG3SRHWDK bHXOMfrW/NGa95HPKjKLsmd8fD0Gf9bJ+lFc7/wnF13soc+zGip5aPYj2dU5LWLeS6sCkEzJIp3D Bxu9jXF291La3KyrywPIPcehrv3GQK4TUwF1S4AAA3ngUsBUbvBm+NppJS7noumLYX9jHdwRod3B V+dp9DmtZEQLtCAH/ZFcR4EZvtl0m47dgO3PGc9a7MkgHB71s01JxuYaNJ2HHcHwcD6d6Ux7sEkn +dNPSpISSTkk1VhCnjABb8aaSCCS+QKVfuyCkIGxeB1osK4m6NgBls+/anhxs+Q5YcDFJOB5Q471 X6S4FOwXLaTyrH13HOPeomR5PvMeexNCfdNPU5C59adhNlO+0y0uwIrpVlHYFRkfjXJ6t4aTTZVm 067nhY8gFSwH/AhyPxFd1MAFY4521QJJUZNOKtsNu+5w899relMP7QtmdP75Xj8xxV+z12yu0CSO sb9g6gfrXV3ABlVSBgjBHrXm/ieGKDXZ0hjSNBjCooA/SspYWnU6WfkaxxNSC3ujp3VHX/WIcDgm oZpBHz8uO9c1osjm62b22Y+7niunADDkZ+tcFSn7OXLe53wqc8eYrGQEBhwD3Hasi8nbTbk3EL5i lPzqema1roBAAo2j24rH1Dm2fPOBxn61tQ0kRWV437Cf8JEpPRvzNFc84HmNx3NFd3sYHB7aZ//Z --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="rentbeo_10.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rentbeo_10.jpg" Content-Id: <76993-415308177175082@4878313> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAXwAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgEBAQEBAgICAgICAgICAgICAwICAgMDAwMDAwUFBQUF BQUFBQUFBQUFBQEBAQECAQIDAgIDBAQDBAQFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUFBQUF/8AAEQgAawBeAwERAAIRAQMRAf/EAK4AAAICAgMBAQAAAAAAAAAA AAAIBwkEBgIFCgEDAQACAgMBAQEAAAAAAAAAAAAABwYIAwQFAQIJEAAABgEDAwMBBgQFBQAAAAAB AgMEBQYHABEIEhMJITEUFUFhgSIyI1FCMxZxkbE0CtFSYjUXEQACAQMDAgMGAwUGAwkAAAABAgMA EQQhEgUxBkETB1FhcSIyFIGRQqFigiMVwVIzQzQWcpLC8LHRorKjlCUI/9oADAMBAAIRAxEAPwCo TX6aV+HFGiijRRRooo0UUaKKNFFGiijRRRooo0UUaKKNFFGiijRRX0Nth3EQHb8uwbgI7h7+obem iva+aK8o0UUaKKNFFGiijRRRooo0UVzIQ6pyJJEMoooYpE0yFE5znOOwAAB6iIj6AAaCbamvQCxs KmPHuA8n5GuSlKja64r76Pgl7bZZW6EUqsBTKUzUSRXmpVy5TKLZokqumkUwEMdRU6aKJFF1E0z8 jkOdxuOh85nDAttUL8xZuoVQOpsCfYACSQASJFxHaudzOT9tHGVYLvYvdFRAQC7kjRQSB0JJIVQW IBk3l3hbCXGhfHNAreZLDkvNUpFu5zK9ae4+PQojHDZ4KYxTMyLx4rLkeO0utydu9bILJomRMqii ooKRI5213bNzskrSQrHCCBGQ+8v/AHjoAth0upYE3sSBczPvb09xu1IoEhyXmyCC0oMflrGDbaLM S+4i5IZVYLtLKpO0KYA7gA/xAB/z1Ogb0qiLVZ9aOFeD6/jZzQEct3Z1zhh+MKXMSZx2pXmSGHFM ZDFtrIvWGcgZYsuvPs6c4NNKHKkZsJUlEA/OHXpUD1CyBl72hQYJnMAbcfM3AlN5H0iMuNgH1ahu mlWAPo7iNx/lLkSnlRijKZNq+R5ZUSeUGvvMwiPmE22aFRrrVXLVyk7RIukYDEOACAh9+mnFIJRu HSkJPC2OxVuorI1krDRooo0UUaKKNFFGiip0wByTuXF24Pr/AEmsU+0Sb+Dd1522tLV6i7bRb46R 1jxUtEvoucgnRypdsHsc8SVAgmJ1CQ5ijGu6eDTnsbynZhY7httYkXtuVgysP3WBF9etqm/YXdMn aWb9xGkbbl2ncDcAkXKOrK8baW3Iyta4vYkG9yY8osng/wAfSXI13j+8QznO8WEPR4fIPK+75Lyl bMiV+8Eh5SNo9gnDvJmuR0PAQLuakniYqJpOV4tv+4oY4jVvk+33k5I4t0JiOu2GNFAKXBdUAViS wUA62DHSr58F3dFDwi54EgE6/KZMiaVyyybWETyEuiqELsQbBig1NefDkpyKw1ycyLVcg41492bD 9qUi5I+WbdbMhsbtYMw2+RcAuEw/bw9aqsIydEKJyOF2jEhnRh7y/UuJ1FHJ2DxmVxxK5L7102AK QEA8ASzEj2AnToNNKrX6uc5g8yA+FF5b2PmMWDGRifqIVUUH2kC7dTrcmeuNOJcUS9GzjyK5AK2t 5hTjtGUcstSqFItoW55NyBk545ZV6BbyLtF0jEtlfgPHL998dU5EUTFSTMocolmfdfOz8e0GHh7R POWszglURAC7FQQWOqhVuASdTYGln2D2picxHl8jyO84uKEukZCvLJKxEcYYghF+Vmd7MQq2AuRa yHBd5xxmqtP/ACESELxMwvYaxS5fx74LwLyLzfJ4/wAY5Dx/E1VrHTszZ7VNPRkLSvG02zJwZGbH 45ukUVVVgFMhFELzqSYMx48tNIrP9w8iICysXJAVFFkBdS9zfxAGultu1JIeUxxzCpjQusf2cUMs rKjIsYVmkkY7pCsTiOw26bSToAdux9RJqRsj6m4wpH/HRt1kXCVXLT65dLvl2Sj42tN13TpdQ5X8 ok2QaNkTnXeCZNL0DrOAiUNff+4GhiDSzcsqi2o2INdPYLk+A1PsrD/s9MnIZYMbt93N/lIllYAA kn6mAAHU6D2+FR+7xrHv4k11yZ4oMY59x8LhQZXM/iy5NSl2hohFNMgrd+vx05dUWxm5DAcxHKDQ u/8ANt1a7EPduTEfLg5SSN/BMuJbn+IrGfyLVG8n08wcgeblcDDNH4y8fPJYfFA8oFvYQnxpTXnF nj3yQmJlHgFmCxS99YFcuXXD7k9FtMW8kkgbEFRVCvPCq/25cFUwKYQZt1kXYFD0RUEQEZtxvqLP x4UcxCqqf8+G7RfFl+tB79V94pYc16NYnLszdt5LNINftcgBJ/hGw/lyn90FX9xqvB8yexb9/FSj J5GSsU9dxkrFyLVRjJRkkwUMku3cIKlIqgqiqQxFEzlASmAQEAENNaGdMhQ6EFSLgjUEHoQaQGTi yYbtFKpV1JBBFiCNCCDqCD1FY2sta9GiijRRQIAPoPqGi1696V0l0SsV4QqUTYbFNzFforJ/GU6E lJVd/E1WNlXar9y3jm6qhkmSbl84VcKkRKUDKGMcdzCI6jmV2/DPMZQigsbsQACxAABPtsABr4VM 8DvDIxMZcdpGZUBCAkkKCSSFB0AJJJA8TesxrGs2hCFSQTKJAAAMBdh9NdyLGSICwqLT5smQSWY6 1OWJeSeU+PSF3a0aPoVxqGS4NlXcmYsyxSWeQ8Z5AiYlyV4yLIxjwv8AVYOy95q5bqJrJG3Eihdx 3jHdnbUXcEcZbcskZJRkYqykixsR4EaEG4PiKnPp73tP2fLKqBGimULJHIodHAN1up8VOoIII8DU j4ssp+e/JXDWP+T7/F2MsF0eLvalFxPWFY/jtgiFdMIt3LoQKTtsUEoElrmGLZrIzCnfeGA4CBlV SolBe8pwb8BgSywI7yEruc3kkNyF3W/VsUkqui6eAvTj4LuqLu3lsfHypIo4Qr7IxtghUhS4S40T zGAVpDuc38SAKsD8l/GjAfEDiXkyKxY3Y4BtuR8sY2ws8qcc/cuLFnWl4rI9f9Z0HD9+4aMnRH7S Rl9lyG+SyjxfNUXTsqSK87X5V+azollPmKFZgfBGaw9guRYhdOjNtJAuXF33wEXbPFzvjjynaREK gm8qpc+JJANwzag7kTeoZrLQrQGVzx3IRtvxxeLTR7WwMVzG2On2B3WJ1gsHqBkXbJZBwkIfxKcN Pw9qx5UO1wGBHRgCPyOlVJHf0/H5O+JmRlOjKSpHwIsasnoGfZfm3YqpgnmjZIoMtvRawXGjnGs0 /t7LeN8pJikFdjLrNxqaa9jgZB+kk1O9fkUdx51AdJOCpkVIZfct2q/aatlYSHyRrJD1Rl/UUB+l wNbCytaxF7U4O3+/4vUF0weTkAyDpDknSRJP0LIw1eNjYFmuyE7g1gRW1coGFyzbgyyZ/wAo1NWs 8wOJ2XojjJzkQTYps1L43myPW9PvciRApUAkjPYd3Cy7kgmBycGi4bdw2+x2dyy8HlphRvuw50Mk Gv02sXjH7tiGUeHzCtL1J7fburj5OTmi2cjiSiDK0A3g3EcrW033Uo5/V8pqulM5VCFOUdynADB/ gOnep3C9VbdShINcte180aKKkvD+LZ/NWSqnjCsuothL2t8u2TkptdRvERTFg3WePHjgUU13ByNG bdVYyaCR1T9PQkmdQxSDzuW5OPh8d8mUEqo6DqSTYAXsNSQLkgDqSBrXZ7f4SXuPMiwoCoeQ2u3Q AAsxNgTYKCbAFjawBJAq6/kvwAx3jngnUb2yrIxUw1wtN5Mp2WHuM7BRJqXn6G+kZSyN744ev3TW ILZ66dujVWDpoRU7pEESKk7hk1UTxvqVO3MPG73Qy7GTerKAwATy7AXKNcyMCRY3sbAi13NeiGKn bkc0cYEogMiSmN43ZlZmk87cxCiSPaIUKghltcXIPn7ZO03rZNwmO5VCgYPx1YKCUTKGFVAycc4z lG6isrWWtes1hVJm3nViIGDlp14dE6hmULGLSjsEi+5u2gQ59g+0dtauY0aIfMYKD4kgD9tb/HpP JKPIRnYa2UEn8hWhXqqZEstrilcp2+/WaSpkW2rEKwyDOyMzIVSBYmOojGtU5JVRRi3SMoYxG6YF IUTCIFDcdQvD7Px4pfOh27Sb/LaxPt060zeT9R82eD7bJL71G2zk3A9ljqB7q2tBEqCKaJf0plAo fhqeRpsAApTyyGVix8a4OkCuETEHcDbbkMUdjkOHqAgPuAgPsOviaITKVIrJjZDYzh1NiDV8F0mn Gaco8hYmeTRb2HmT4QqJnW7KnE6sXI5twCxjp1pKKAQoKFM4bUxT85hMJVFREesB2Grbw/0cRBPp xuRaNfaEclSP/P8AkKvnHkjuQzmSwfN4aOV/YZI1Vw34iP8AM+NUDVd4LyIbqCO4gUAEd/u1ZnjJ vOiBqjnOY/22QwrYddCuPRoorIaP5SLdtJSEkn8NMRrpvIRctFvFI+SjZBmcFEV0F0jEVRUSUKBi HIYBAQAQHfWHIhXIRkYAgixB1BB8CK2cPJbDlWVCQykEEGxBHQgjUEeBp3M+cgcxZh8bEixzMWqv ok2ecL4jw0DFR2hZpOdxfAvX9vtsh8xw8M7cfSTV2MWOgZJETuFVhRFdZVQ1esrtJOO5wCAn6Gkb pYBmsqi1rC+8jqbC17AVcbj/AFDk5ntYtlBf8RYo+t2aNNzubk3IUxqSLC7E2uSaQGvNvixLRLcR 2SJvv9waf/Hx+VEo91VD5ibz8h299TNhjHL7MGX8W4njF0Gsjk3IlLoLJ05V7LZs5t8i3YEUUMBT CUqYuOoRAB9vYfbWLmOQHE4k2U2ojjZz/CCf7Kzdu8O3cHIY2AhAaaVIwT0G9gt/wvXrYyU7r3AP x4Zzy9wXhiYcmoSbqdJxLIStUHK925D5GWnY+uPUJbsO3IST99IuHMfGskCimzMi6cFbgBydumvJ cxN3NyUaco3m6EsAdqxggsAgsLACxYnVrqCdNf0q4TtzG7I4WaTgU+31AViPMkmYEKxkNzuYm6oo +VCGYKLiyRVolE8gnNZ7g7MuI3mYeUGL2VNsC0ga8qs8IYzpt2rMJI2+m5KsMYBLDP8A/wAuyA+k YmBTYuPkOVXKLFy87KBzkkWDzeZ2hx/m48vlY8l9AoLlgSFeJW+RTIgBckWABYLc6w/le1uN9ReW +3zIPPzIrG5ciNUZVLxzutpHEMhZYwrBiWCM+0G0DXDHfjq5Kv4zF2BsRXPBeRrfyDvvEKjX5V7I NoZjyQorRq9YNpqEfWy4tXUDZzOzNAftHqbtmoQhjN3CZ9wknGd+8xxTeblTCaJUEjKQt/LOh2sq RkOtr2IKt7VNQnnPSXtzn0GPgYzY07ytCjhnsJlAKh0aWUGOS9tysHQgGzCqNTt3jeQfwzxqohMR Um8hpFgGyqzeTYKmQVR2J1AYxFSCX09/s1YnDzkzYxKh+Ui/4dappyXFy8XO0Eg+ZWIt7wbWr0AL GLh/lnzdlylauI3gh4bYjCKD16X9mPynP0usxSTVMh2+wKuJ+bkCKFWIIdXdAQ2EACsGfL/U8TGP jlZ7SfFPMdr9em1Vtb3VevioDwfIZq/pweISG58JPJjW3TqXZ738b15v8eioMIQT77CIbb6sd2/c wC9Uu7vsMo2rfNd2onRooo0UVPnJt5LPMG8GK02XXNR2mM8tWVs3UQSRSDIk5kCws51XdP8AMoY8 dEwyYmU/N0Jph+kC6XWLCs3J5pP1+ZGP4BEhUfmznTxJpzZ2S2PwfGKpPliGVh0/xGnkDn3/ACrG NdbAUv6KYJJJph7EIBf8tMNF2gCk7I/mMT7a22kXa0Y0udSyNSZH6RcaDZ4G6VWUBErj6fYqw6Se sl+2cBIoCThEhhKYNh9h1p8nhpyOPJjyC6OpUj2hhYj8q6HCcnLwuZBmQttkikV1PsZSCD+Yr0e3 9ld3fjx5Mcw7Uw5WcJJCt1GQyXVMC4ZyxXXsae652X+O9tEQhPU1zdsfQFksDor95GM7CVYySjhZ IiSShFF6a52LHj8rHhq8c43bTIynon6SVba7KBa+21wAdQQP0r4vNmy+Bm5J4psRtm8RKy/VJ1dQ yb40dju2772JIsCCYCi+cab3lhmK0cM5Kjchpe/8cMW4GiqMncGGDczTb28S0hb4yQx5KSMO5hpO TxWaRYVtk2cN1HfW1bqJN102xtuseELYEaZgaMLIz7rF0FgFIcA3CyWLkiy6m5F6j47oVOVll45k mZ4Ui2bhHIdzGQGIkbWaG6xgEFvlBAIWk6ttxQ4LGjH9mYY9xvmnCjbIbfjDxEoWRks6XXDmeMlo pMLBlLMNsbh9LdWOPZIpHj2KI9YOEWZRZs2rU5V5DxXGf11NihmjkK+ZKy7A6LqscSnXaT9R6WLa sSLQ/n+c/wBqSiSQok0QYQ46v5jRyvo02Q4+Xeo+lRruC/KqqdykePzGzzL3K7BVZs7xZeOsWWq7 ZL3KvnfbUQp1ed/W7G/WXUIqUBQiWbpcxzlEPTcd9N3k5m4LhsmUdREwQfvMNqD8WIFV14TFTuvu XBx2N1adWkP7iHfIxOvRFY0+EjmE1p4EeZbmBZGSiavNrlbibD2N0nYmTSByysL67PmqY7/uDHQi qAFAP09Ib+g6UuVg/bcjxuCh/wBPCzN/yiMH8WvVhcDlPvuF5vlZB/rMlES//G0pH8KkflVPVOR7 ME0DbpExAEQ/DVi+HTZAtUy7jl8zKeto1064VGiimiwXH8Hv7cn5rlblfP1QmWb86UDU8L4wiLUM tGAimYFzyctMs0UVTLCcnYM3ANgA3d/NsEO7m5PlcFlGBDAyEatI7LY+zaqnS3jf8KZHY/B8ByyO eWycpJAflSGJGuLDUu7gA3uLbffepZsebPEy/gqLQ5W0+S7IFFx9I26cqcIWGxfR2ldkr0LIZUqR hUmHSoPDxjZQ3UsBQEo9BCmMcxl595zZnfJVMJJHChiPOa4W+3+70ufD4+FOQcb2uuJHhPJyckMZ YqCMZNpe2631nXaD1t7ALk10LjJ3h0VACtIDyRtDbFDdaaxo8D0HcfQGCXuX09/T39fbXXTn+4h1 OCf4Zh/1VHZe0uzT9K8oP48Y/wDQKtK8YHH3xk8o89/M45SPKm2ZEwvCxORVqTyUqtTb4+dgtIx8 UWUEINwuL00I6fg+SYuDFTVORMqnWkChTwfvjvrnOOxDFlDHVJSV3QmTeBYm3zdNwG0sNQCSLGxD S9LfSrtbmeRWfAbMeWAB9mQIfLJuFDfJe+wneFOjEAG63BYz/kV85KxgzjUx4aQsZKucocg5ikOp Rq7vbhW4xVAoE19ZeSb8EAclSCSUbRzdBYVimWFZwUNxZKACe7O4+TkcxZRay36DS5FrD4a/9jVj /UjmIuF414De7AdWJaym9ydeumvjc+yvOh48q8wjeSVAzXLwCZKlx7Wl+TF8RZtyNoqOrGHkFJtN oc3QYiBZOQbtYpv+URMs4SIUBOYoDaHuHjkh4doRpLMBEvtLOdt/4Rdz7lJ6CqJdnczJk9xpkkXg xy2RJboEiBax9m5gsY9rMANTW9yFH8fGZbpeMvZV8jOS43K+QrDP328lmuFck7rry829ys/elYuo +3unAtk3axilUVbJmEuxgSL+gIzxeXyPD7YkwEaNLKv88AhRoL3S17e/8anHO8dw3ce6eXlpEmkJ Zz9qzAuxJNist7XPiPw8Kap7XcCeP/izeOTmP+Q1Z5DW7lfjvIvHHit/btKnsbv4KOmiDFZBtrtn Psm7tE8I0P8ASmZkDGIdVybY49Juj75HuObu7Jj498cwJA6yy3ZX3EaxICptYn5mvqAo/HFw3ZeN 6eYc/LxZi5UmVE8GPtSSMoG+WeVg4BBUfy1tcEuddNNtzTxTtVu8bvj44zUvN3ErGsg8hpzl5lCi Zr5GwOIMl3O5ZnUVGtrtImaXbdSDGrH6CLnUIVTqHp36fWIY3NRxcvl5UsUzDcIlKRs6hU+rUeJf w8KY+b2zLP25x+Djz4yHY2Q6yTLG7NLfyzZraCPoTa/hS6Rvie5wuq4pL0bF1VyvDRphRO8w1mil ZWVWTKY5O8m1g7A9enJ1kEu/ZAQH0EAH004cb1N4WALFLO0bW/zI5E/ayAftquGd6Hdz5ReeDFWZ b9YZoZT8bJIWt+FLFlzjVyEwIZIM1YTyji1By5FmzkLxSJCvREg5Dr/I1euG5GjoRBMwh2lDbgG4 empbxfceBzf+kyIpD1srAkfEA3H4il5z3ZnL9r2/qOHPCCbAvGyqT7mI2n8CahHXZqM1hPI9s/J2 3JOsv8NYZsdZxZhW1jZb4huhsa61OsQyf6WhPx1rDjYV/TW63OZL9Xq1nhj4d8vcvsaHzg3kq/Qs QjOua1GSh2p7XeLbONFkW528TCoKtUjfvq9sFHz5sQTB+rp/Npa93eoPGdqZH2ZjLz2uR9KqDrdm IJ6eCqxp2+nXpBznqBh/1JZlixdxUG293YEAhEBA6m13dBfxtrTJSmYcq+NKmvsDePfiJMWfMWcZ 93VV+Sd3morL9vyu8gEAOq0qtWqqrhm4jYDvrJOFUXT1km6FVNdVwdIogr+Zii7zb7nMyVCItxEq sipfxd3sdzaEXCttsQBcint23NkemifY8dhO0krWaeRlkeUgdI44rgIlyDZnUNcFmIBpRJrx8Uas p5U5f+VTmLertyRXq2OsuZOw1iGvsbpkmOSyu4atK1GSlnkHKNYinbtiqkq1jmbdVJBokcyQCmiR M2Ht3JkwpUjwMdNhZlWSQkJ8gO4hR87AHQm4uxA8b1sd5YUXJ48svLZcgkWNHeGFQ0lpCAgaRj5a swNwAGsoJ8AComT+UjO2Y7d4H49Y7LhXBkxKQs1b41SdNcMh5Wm66USsXdqsJ2rEXiTM5jrNYxo2 bs0VDCoCJlv3dOjC418qVcmd/NmAIU22pGp6iNLm1+hYlnI0vbSqz8nzUWBjthYkQx8YsGdd2+SV l+kyyWXcF1KxqqxqTfaW+apM4jcJq3lxjZMy52n3WJeJWIEhlMwZeWbFKvKO0AIojU6wVcATk56Z 6yptm5OrtgbuqAIdBFMfc/KRcGiY2OglzZfoT2Dxkf8Auxr4nx6DxIy9icHP3TLJm5chg4yDWWW3 U+EMV9GlfoB+kfMfAGH+VuTLPypyZTsiM8ZyGJuO9chBxRxiojONdpUKp43oKpUxjo56sXsyb0HL v5U06Icx1HSxjn6eohQ5XbHb8WKzJ5nmSg75W03MzeJHgNLIPBRYeNSDvru/IzkSXyfJgI8uBBfa saabQx+ptbyHqWYk2uBTCeZmjpNvJBfscGUInG4rxTxpx/ApodQpoxVdx3WCkKBjD3TgKhzmKZQR NsIAI+muH6c4i8xhRyHqzysfiZXqUetHIv25yU0K9EjgQfBYIx/33661Xyyq83ArGeVufkYd92xS TfRz1Rk+RIIlEe2sQxVE+rp2ESiG4bh7COmjkdueYLbtKROJ3qYG3bbH2jr+YqZXvIfmDJ0Gw4ks fI7MVuxVbTw5rFQ7bf5K1Vl8aBeoyLQxWr9w5TQMi9bpqgZECiIlDcRD01xsbsuLCyUyY4oxIt7M FAIuLHUAeBIqSZnqZPyWHJgyzytC9tyM7Mp2kMNGJAsQDp7K00COPgiTf9/t7AP/AJantm2W8bUp Nyebf9N6zdZ61akTEl+PizKOPckEi6xNmo9xr1n+lXOuhbaq9LEOk1hI/jO6h85HYoidEFCib2Ax R2EOZzWJ9/iTQXYb0YXU7W1Hg3gffXc7a5H+kchjZRVG8uVWs670NiD8y3G4e64v7a9KFl8wnEjC 94nYu1WOuZCoc/NtKJSbe3ytbeRNgYsp2SQZSl2CnKgEFj2FhK05kDt4dI7iWdHVSbAKaSa3TTjP 7Zz8gACMo4F2GxY+gvtLjWRiQLsbLpfqa/Sfie+OJw2JMqyRsbKxleXQmxcRsSsKBSbILubhegNU yy3JHkJ5NOUeS8U8L45HAOFbwmmzt1ktUqxpNis2LoZ0yimT2+WFqkRRjDsyLMGEXVIvZg1T+O1Q bOHJlF15nwPHx9uY65WeC7IflFi3zWJsi9CxsSXOvUkgDRad2cxN3pmPgcUwjSQfOSQl0BCgyuNQ guqrGvyjRQpY3Lk8zvHxyhyjEZEquHac1yateeUuN0FkqnMxjMkZxtwZjZpX8V2CTODlCNjImSjn squdwuoQiRioiv21FUy6xcH3BgxSxvlyFAsTHUE/zHkLSqNCSwO0WAN9bXArP3V2hyk+PNHx8IkZ 8hQNpUWhihCQOTcKqFSxuSANN1iRUYcb/Hjx9rlgfNc1ZrqGbZ2iRJbTe8Xca7o2VxtjSvsjCdeS yZl1+2/tCpRbYEjFckYHdu1PVNsUVwAgz3l+/psbHAwYDCraLJMvzMfZDADvdvYW2KOraUpO3/SP GzstjymWuQ6fM0OM/wDLQe3IymHlRIP1CPzHPRfm0qduQMZgfnbC8GqXi7ILufwnM8tMl4dtx6Cy e4iwnhXHWCqvGWyzsaBUFklV5QZOBlnLpSzzxAkHS6CfUkggr2iL3C5nJ4iTLeRbSGINdiHkkZ2K qZH8LEACNPkUE2uRcuLk+2sLuOHj44nvAMhksgMUMMcaB3EMWtyykkzSfzXYC4UHaFryNyYacvOL fIGdiqxE0vCPGfmLxDhuNmJo1iWPhcQ4Iu7K7QTmOZmITdVaaGNYPJU6hjGVclMsPuAakHG4z9s5 0KqxaWXHl81/F3BRrn3LchfYNKiPNZkffPF5LSKFgx8zH8iIaCKJhIm0e97Kz36sL0vflvWXd+Wj mIo4XUXFtdaqzQ7igqdpoyrMImimXcR6SpJlApSh6AAAAak3pEv/ANfj/wDCf/U1Qb/9FOf6vmA/ 3x+WxbUlunXVYKNFFGiiuQiAgUALsIAIGHffqHcfX7vT015XtcBADAJR9hAQH/AdekXoBtrTIcMV uJNGzLNW7ljFRr6mExxcmdRWncbOcuVSJybIFbpRb+YrjOWhHEs1ZpGcKCgR4TdQE9x23EFz31w2 TJihsAfzN6lrMEYoL7grFWAJ01sdL05/SjuTCgzzHyp/leUwS6GRRKbBS6B0LKBuNtw1tVqGHedH g1wDIOrmxi8mBk+WgWUdNSmGsD2LHGM5MjaQYSybV/V5bJk4bZOSimyqpGD5AhigKZT9JhAEdyy8 9lp5F18oEkB2R3BsVuHWJfBiNQfbVpu337T4+X7qznIZQCY0kjjI3K1mjaeT9Sgnay+zoaWfOnkp 4RZgj29Rlsh+RPKeDKgmzjKTw9osDRuGvGd1GxYdKbWTc12SsdhkmY9Idr5aR3JAH+uA+msXE9uc gJPNRYUlJuZG3SPc+IuAL/DT3Vtdw958OYft5HyZIFFlhXy4YrDwO0sxHxBPvqvvPHM7JefsfNeP WMcdUXjBxUYzbafQwNh9o4TYWOaY+jeSttgkFXE/cHyIAXpWkHAplEpDJokMUogy+G7NJl+4lZ5Z yLGR/AexVHyoPcB+NJDuX1KUY5xMeOPHxQbiKPoT4NIxu0je9jbpYCrMvGLFr1Km8XWqD5Ns1Hmf yfSRKJgBYqljwE5YSJCbh0lK8bGRRVAR3PsQC+w64PqDxSYUkwA1GNEf/f0/KpX6Qdwy8nDjMx+U 5uQo/wDia/ncD30i2N5Q9A8UeZXyiiDN7m/mZgKpwAnbAR8+Z4Qr9lnZdduoJimUKwcWCKKoJAMB BWIBtu4UddfKi+75OBR/l40hPxkdFW/xCt8be6o7gznj+DymJt52bCq+20UcjsR8C6X9lx7alXy6 RqUb5V+UjhJ2m8QsbrFlvarppikBm1upNckCB6iPUJQcbCcB2EfX7dbvo+1+PhB6gMPydh/ZXM// AEam3l8kg3BKN/zRof7aR7TrqsFGiijRRRooo0UV+Lhuk6SMisUDEMAgID9+viSMSix6VlhmaBty nWtYPSa+oYTKMkjiI7+qYf8ATXMPC47dVFdxe58xBYOfzrKQqkG327TJMu32AAAH+msqcVBH0UVg l5/Km+pzXeINW7YoFRSImAf9pdtbqRLHoBXLlneY3Yk02kBzBXwjx8wnAYvGXjuQWGeZNm5D1+Vk a+zl8fPqnZKnCQZ2TvuuBcLqKLxB0l2wodB0FTbKAb0BY92dtPymdLJJYwSYyxEAkNuV3a/S1rNo b3uOlPT0/wC9o+B4qGKEkZUOa84JAKFWijSx1uTdDcWttPW9LzyA5EXLkrI0OALjjHuEsP4piZeO xnhfE0c8jqDUVrO5+dMvifUHj9+7eTD0CqOXLhwYwlIkkXpTSIUPjtztd+NZtzM7uQWd7bjYWUaA ABR0AHiT1JrL3p33Hzax7EjijjBCRRghV3G7nUklmPUknQAdABTEeSXMFCzjzMY5Bx1Zo+0xjrj5 xvhrA6iu4rGRdzgKfFtZSNSXUKQrkWDhPtKHTDpA4HL7lNrR9OONm4hWhmUqRLJa/ipdrH8Rr8K6 nrTzeN3G6ZONIHBghBt0DCJQyg+NjoT7b+ylQ046rZRooo0UV2k31/WJPufK7nzXHX8zt/K6uod+ 52v299/fp9P4emsMH0j4Vnyf8Rr36+PX9mn5V1es1YKNFFGiijRRRoorqZDp7ie/xPcP9x1dX4ba 1MjqOn410cO9j9X4WrLS/SH+3/T/ACb76yx/hWtJ1/VWpM+j66p/6zq9P6Xc+T9vv/Lrkw288/T+ 29SHJv8Aaj6/2W/8a3jXcqLUaKKNFFf/2Q== --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="eng.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="eng.jpg" Content-Id: <11023-610016649402@6783521> /9j/4AAQSkZJRgABAgEASABIAAD/4QSHRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MTA6MTggMjI6NTE6NDIAAAAAA6ABAAMAAAAB//8AAKACAAQAAAABAAAAGqADAAQAAAAB AAAADAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAANRAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAC/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgADAAaAwEiAAIRAQMRAf/dAAQAAv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8AnT6xxxi9RxMvqGO0eyuzBjbOn6N7MkPx/wD0G+z/APCeqq7v seDkYNGJhZ1dAvyLfSvYPUd6zKKfTxhp6np+grdXqfYn/wDNb6e33+pv+2R+f6m73/8AuP8A0P8A plV6d+046b9t9T7T9rzNnjHo4kels/l+p9D/AAu9PyxycBInePigK4aHFxaS9H6t0eWy4PejxYKz HHlJ/WTlIR9nJxRye5+t4pf10mBg9OwGOfT0zNsyQZqtuxi5oj9+tt1T3O/qX11/8Cifa+t/92Of /Kmn6H/cf+d/mf5H/gingftP7Mf+duz7Pt03f0zj9Hv/AMF/7kP0/wDolj/9jn/Dfz3/AA38z/5P /pqT283HXu+vi34Txf8Aqz/1Gwe9yvBf3YcHD8vueji/9I/8/wB5/9n/7QmaUGhvdG9zaG9wIDMu MAA4QklNBAQAAAAAAAccAgAAAsUIADhCSU0EJQAAAAAAEFVfGddtEZikQr2zkBBABH04QklNBC8A AAAAAEo7AwEASAAAAEgAAAAAAAAAAAAAANACAABAAgAAAAAAAAAAAAAYAwAAZAIAAAABwAMAALAE AAABAA8nAQAuAGoAcABnAAAAAAAAAThCSU0D7QAAAAAAEABIAAAAAQABAEgAAAABAAE4QklNBCYA AAAAAA4AAAAAAAAAAAAAP4AAADhCSU0EDQAAAAAABAAAAB44QklNBBkAAAAAAAQAAAAeOEJJTQPz AAAAAAAJAAAAAAAAAAABADhCSU0ECgAAAAAAAQAAOEJJTScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D 9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAABgAA AAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////////// /wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAAAkAA AAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADRQAAAAYAAAAAAAAAAAAAAAwAAAAaAAAACABp AG4AZABlAHgAXwAwADMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAABoAAAAMAAAA AAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZi b3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAA AAAAAAAAQnRvbWxvbmcAAAAMAAAAAFJnaHRsb25nAAAAGgAAAAZzbGljZXNWbExzAAAAAU9iamMA AAABAAAAAAAFc2xpY2UAAAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAA AAAGb3JpZ2luZW51bQAAAAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51 bQAAAApFU2xpY2VUeXBlAAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAA AABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAADAAAAABSZ2h0bG9u ZwAAABoAAAADdXJsVEVYVAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEA AAAAAAZhbHRUYWdURVhUAAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRU RVhUAAAAAQAAAAAACWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQA AAAJdmVydEFsaWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9y VHlwZWVudW0AAAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAA AAAAAApsZWZ0T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRP dXRzZXRsb25nAAAAAAA4QklNBCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0E FAAAAAAABAAAAAE4QklNBAwAAAAAA20AAAABAAAAGgAAAAwAAABQAAADwAAAA1EAGAAB/9j/4AAQ SkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJ CQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwB DQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDP/AABEIAAwAGgMBIgACEQEDEQH/3QAEAAL/xAE/AAABBQEBAQEBAQAAAAAAAAADAAEC BAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQAC EQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2 F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQAC AgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2 JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AJ0+sccYvUcTL6hjtHsrswY2zp+jezJD8f8A9Bvs/wDw nqqu77Hg5GDRiYWdXQL8i30r2D1Hesyin08Yaep6foK3V6n2J/8AzW+nt9/qb/tkfn+pu9//ALj/ AND/AKZVenftOOm/bfU+0/a8zZ4x6OJHpbP5fqfQ/wALvT8scnASJ3j4oCuGhxcWkvR+rdHlsuD3 o8WCsxx5Sf1k5SEfZycUcnufreKX9dJgYPTsBjn09MzbMkGarbsYuaI/frbdU9zv6l9df/Aon2vr f/djn/ypp+h/3H/nf5n+R/4Ip4H7T+zH/nbs+z7dN39M4/R7/wDBf+5D9P8A6JY//Y5/w389/wAN /M/+T/6ak9vNx17vr4t+E8X/AKs/9RsHvcrwX92HBw/L7no4v/SP/P8Aef/ZADhCSU0EIQAAAAAA VQAAAAEBAAAADwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAAABMAQQBkAG8AYgBlACAA UABoAG8AdABvAHMAaABvAHAAIABDAFMAMwAAAAEAOEJJTQQGAAAAAAAHAAgAAAABAQD/4Q6VaHR0 cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBN cENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEv IiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkg MjAwNyAyMjo0MDowOCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3Lncz Lm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9IiIgeG1sbnM6eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0i aHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDov L25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8x LjAvIiB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyIgeGFwOkNyZWF0 ZURhdGU9IjIwMDgtMTAtMThUMjI6NTA6MzYrMDI6MDAiIHhhcDpNb2RpZnlEYXRlPSIyMDA4LTEw LTE4VDIyOjUxOjQyKzAyOjAwIiB4YXA6TWV0YWRhdGFEYXRlPSIyMDA4LTEwLTE4VDIyOjUxOjQy KzAyOjAwIiB4YXA6Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDUzMgV2luZG93cyIgZGM6 Zm9ybWF0PSJpbWFnZS9qcGVnIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SGlz dG9yeT0iIiB4YXBNTTpJbnN0YW5jZUlEPSJ1dWlkOjMyOEE5Nzc2NTY5REREMTE5QTA2RjBENjlG RENFQjY5IiB0aWZmOk9yaWVudGF0aW9uPSIxIiB0aWZmOlhSZXNvbHV0aW9uPSI3MjAwMDAvMTAw MDAiIHRpZmY6WVJlc29sdXRpb249IjcyMDAwMC8xMDAwMCIgdGlmZjpSZXNvbHV0aW9uVW5pdD0i MiIgdGlmZjpOYXRpdmVEaWdlc3Q9IjI1NiwyNTcsMjU4LDI1OSwyNjIsMjc0LDI3NywyODQsNTMw LDUzMSwyODIsMjgzLDI5NiwzMDEsMzE4LDMxOSw1MjksNTMyLDMwNiwyNzAsMjcxLDI3MiwzMDUs MzE1LDMzNDMyOzZBMkFDNEVEQTRFNTRCRTA5NzU2Q0Y3MUJFMERBMTkwIiBleGlmOlBpeGVsWERp bWVuc2lvbj0iMjYiIGV4aWY6UGl4ZWxZRGltZW5zaW9uPSIxMiIgZXhpZjpDb2xvclNwYWNlPSIt MSIgZXhpZjpOYXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYy LDQwOTYzLDM3NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0 ODU1LDM0ODU2LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0 LDM3Mzg1LDM3Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQx NDkzLDQxNDk1LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5 LDQxOTkwLDQxOTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUs Niw3LDgsOSwxMCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywy OCwzMDsyQjA2MDg3NjE0MTcwMDk2QTk3RUU1Mjc0QkFDOERCRiIvPiA8L3JkZjpSREY+IDwveDp4 bXBtZXRhPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDw/eHBhY2tldCBlbmQ9InciPz7/7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEB AQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwP/wAARCAAMABoDAREAAhEBAxEB/90ABAAE/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoC AQALAQAABgMBAQEAAAAAAAAAAAAGBQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIG IQcTIgAIMRRBMiMVCVFCFmEkMxdScYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhV VlcassLS4vJkg3SThGWjs8PT4yk4ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSl pqeoqaq0tba3uLm6xMXGx8jJytTV1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVt AQIDEQQhEgUxBgAiE0FRBzJhFHEIQoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2 RWQnCnODk0Z0wtLi8lVldVY3hIWjs8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZn d4eXp7fH1+f3SFhoeIiYqLjI2Oj4OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIR AxEAPwBU7Rk3hV9fUnUnyb+PXy9+WPWWKpZIsDs7fX8tZcN/ds1bR0KLs7P7e+TGP3J1FUfZQg0c 2yY9nh1UfxAZQataiX3kj5Wv/reQeU982R4iQ8hu/FsywqGYw1/TWtSI+CCi5p10Qu/ugx+4ezTf 6633j/avmueQaotxa6O1bsisdStNOi+Fd1WniCayunclibiNiWAPZNOneg9+/Fzr3p740fOvaXXN H3h8n+zf7j9ybDwq9m7jn7q6w6G67m2j0xQ00FAu7/7l03V/3Q+8VZwK4GT1ewZ7j+8++c+86+2H Pl9bK247YdIoKLdGMU8VR5CUguB6H5dTR93P7nW3e2PsL97jkLb/AH35H3LbuarO0H1VpeBottUJ clVvSpKlnBpGVJB8iQAelv0R0n8efjphcll9k/Bb5y7v7boqpKrZG/O2/hzlt2YLDPQR2p6rcW1c H3dsDcWazH2zXl+w3RhcNVykmXD1ER9jzmf7xG/c7bnFJzXtu7y7Kp/3DRfAQrX4Fk1T6gBhW8Na jOkcBBXLH3F+XPb7a2T2196fbO25vZQZNz3PclvbuKWg1m1idbaG0TXXQy28s6LT/G3ZfEZa/wCl j5s/0+R3/Fw0f9uOPj1/x4P/AD6D/mbv/MvP+rZ/mP8Aq5e139evbL/wgd7/ALieJ/bD+x9f7H/c j/h/H/hHRV/wJvvT/wDNC+Wv+Sl9V/yUp/8Akpf7+/tf9wf+kh/a/wDDuv/QErav94f9Cu5/+GkP t/41/A6b+9H99v8ASh/s838E+0oP7wf3v/jP+/l+9+51eT/Q5/v2bav4v6b+8guc/wCtv9b7f/Xp 8X+oXjH/AJI30/heHrGj6jw/8Y8SlNXifraq6+6vRx7R/wCt3/Urbv8AWr/cn+vb9LHq/f3ieH43 h9/7r+r/AN03i6q/8lTt+H6Ty6AX49f7M39n8Iv9O/8ApA/0sf7Nv8/v7ua/uv459p/stfxB/hv9 yP7uf7jtP96P4r4/4V6P4797b977n3Efu9/rd/68fsH/AFF8H/W/8d9GnT4Oipr9bTHj0p4/i9+q uvNesvvu2/67n/A3/wB4b/rtfvT/AFx/3fY6tfg14to8Pwezw/8AfP0v6en4vPoxPRH+zN/6Nsj/ AMPI/wByv9GX92qX7f8AvJ9p/s8P3P8ADav+6X8ft/xj77/7rV9p/pf/AN/T4L/wv9/3M/uD/rX/ ANZrf/Wm+u/rx4o0/u+n7vrUatVf0NNK6adnDrDP2z/14P6o3H+un/Vz/Wk8NvG/f+n6nRpOj93/ AEv+7PxeHi/uzu1V8bz6ra/7F1f9/e/5nN/4ET/zJX/7I/8A1qe5W/5jh/wr/lWP+Xb/AJLX/Wr/ ALNug3/4BP8A9Jz/AJKH/L7/ALgf96L/ALrPX//Z --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="200810191904530.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="200810191904530.jpg" Content-Id: <34415-42940638566206@9580840> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgADAAZ AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 8481v+eZP4GjzW/55n8q+uE0zTyoJsbb/vyv+FO/svT/APnwtf8Avyv+FX7PBf8APr8Wd6zrNP8A n9/5Kv8AI+RfNb/nkfyNJ5rf3T+VfXR0vTz/AMuNt/35X/Cmf2bY/wDPnb/9+xTVLBP/AJd/iyZZ 3mi/5e/+Sr/I/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="201001131425520.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="201001131425520.jpg" Content-Id: <8800-863189979237135@147341> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgADQAa AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 1B+0FYgY/wCEen/8CF/+Jpf+GgrH/oXZ/wDwIX/4mvNPs8X/ADyT/vkUfZ4v+eaf98iuz+3Mn/6B Zf8AgbPrf9TMR/z/AF93/BPS/wDhoKx/6F2f/wACF/8Aiaafj/Yk5/4R6f8A8CF/+Jrzb7PF/wA8 0/75FKLeHH+qT/vkUf25k/8A0Cy/8DYf6mYj/n+vu/4J/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="200912051454130.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="200912051454130.jpg" Content-Id: <75062-465006598224087@8931731> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgADQAa AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 8lPhRs/8fg/74/8Ar0n/AAibf8/g/wC+P/r19Lf2dY/8+dv/AN+l/wAKP7Osf+fO3/79L/hXxP8A rPP+X8v8j6/2eV/8+H/4Ez5p/wCETb/n8H/fH/16d/wijf8AP4P++P8A69fSn9nWP/Pnb/8Afpf8 KX+zrL/nzt/+/S/4Uf6zz/l/L/IPZ5X/AM+H/wCBM//Z --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="201001131428000.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="201001131428000.jpg" Content-Id: <70075-77312769540469@8310343> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgADQAa AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 8nyfWvsPw7/yLGlf9ecP/oAr48r7B8Ot/wAUxpX/AF5w/wDoArtxeyOLCLVnhHi8/wDFY6t/18v/ ADrE3e1bXi7nxjq3/Xy/86xK8Z7s/V8L/Ah6L8j/2Q== --=_NextPart_2relrfksadvnqindyw3nerasdf Content-Type: application/octet-stream; name="201002131706420.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="201002131706420.jpg" Content-Id: <87257-73936166751131@2245960> /9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcg SlBFRyB2NjIpLCBxdWFsaXR5ID0gNzUK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0a Hx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgADQAa AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A 86r6Y0T/AJAOnf8AXrF/6CK+Z6+mNE/5AOnf9esX/oIrxvEf+Bh/WX5I58p+KR4f4p/5GvVf+vp/ 51iHqa2/FP8AyNWq/wDX1J/OsQ9TXn4b+FH0R+10f93p+i/I/9k= --=_NextPart_2relrfksadvnqindyw3nerasdf-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 18:41:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA06106564A for ; Thu, 1 Apr 2010 18:41:01 +0000 (UTC) (envelope-from oleg.lomaka@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 07F458FC1B for ; Thu, 1 Apr 2010 18:41:00 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so422053fga.13 for ; Thu, 01 Apr 2010 11:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:message-id:to:mime-version:x-mailer; bh=fMEosRaxSx6ESufUvjCE+zW0wDhZaiZRKx5z9oe2sZ8=; b=SAi74eWN62I5qp3tb/VTH/wEq2nujaZfM1tGP1uOZn2xXYwfF0L2E6RZwengTu9SBY BP2sDKLsJZlymhK+tMMF8/1I1wTtwXCUYsyNpsFdoVaZgFWzUlR/or6NpkG495r/T9mq yYtfeVAAOsnmlugym3PEpoqNARvzJds8+ggms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; b=k0q/3i6l2YwOs0annbWYe1luo8rkRTW0hYmUjXADMFT6oYOfN8I/CUO4wAp2gIrHyH WAr5UsVCzMqMX3m3ERDFevD5LP27kmxpdg2REBw2Y2RQ886jE6mU+DnEN/9ZFVaPlWLl Py1nwnvau2nh6jBjlgv39oEyYddSIrM914rJ4= Received: by 10.87.65.14 with SMTP id s14mr364354fgk.61.1270145902101; Thu, 01 Apr 2010 11:18:22 -0700 (PDT) Received: from [172.16.224.129] ([92.249.104.41]) by mx.google.com with ESMTPS id e3sm7241511fga.9.2010.04.01.11.18.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 11:18:21 -0700 (PDT) From: Oleg Lomaka Content-Type: multipart/signed; boundary=Apple-Mail-1--219075808; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 1 Apr 2010 21:18:20 +0300 Message-Id: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:41:01 -0000 --Apple-Mail-1--219075808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have a kernel panic when connect to postgresql8.4 server installed in = one of jails from another jail. It's 100% reproducible. Also I have tried to connect from host machine to jailed pg server. That = way it works fine without crash. Server configuration uses geli and zfs. Four disks encrypted using geli. = And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All = jails located at this raidz2 pool. Also I use ezjail for jails management. And it uses NFS to mount = directories with base system. atal double fault rip =3D 0xffffffff8063510a rsp =3D 0xffffff80eaec5f50 rbp =3D 0xffffff80eaec6040 cpuid =3D 1; apic id =3D 02 panic: double fault cpuid =3D 1 Uptime: 7m11s Physical memory: 8169 MB uname -a FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: = Thu Apr 1 13:43:57 EEST 2010 = root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 Link to dmesg.boot: = http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTli= ZDctZjU3N2YwNmMxNjZl&hl=3Den Link to kernel core backtrace: = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&h= l=3Den Can I help to spot this trouble by providing additional info? Thanks.= --Apple-Mail-1--219075808-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 22:17:03 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027DE1065674 for ; Thu, 1 Apr 2010 22:17:03 +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 53ECF8FC1B for ; Thu, 1 Apr 2010 22:17:01 +0000 (UTC) Received: (qmail 13426 invoked by uid 399); 1 Apr 2010 22:17:01 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Apr 2010 22:17:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB51B5B.1050606@FreeBSD.org> Date: Thu, 01 Apr 2010 15:16:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:17:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Greetings, SUMMARY On February 21 I sent a message to freebsd-arch@FreeBSD.org detailing the current state of BIND on FreeBSD, and plans for the future. You can see that message here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html In that message I asked for feedback on my plans for dealing with BIND in the base. There wasn't much response on the lists, however I did receive a great deal of response privately, all more or less to the effect of, "Do we really need to continue having BIND in the base at all?" After careful consideration and private discussion about this issue the conclusion has been reached that the answer to this question is, "No." Therefore we will be removing BIND from the FreeBSD base. BACKGROUND "Back in the day" when the FreeBSD project started there was really only one show in the DNS town, BIND. In the last 10 years several truly viable, first-class DNS options have been developed, in both the authoritative and resolving server spaces. There are ports available for each of these options, and many FreeBSD users take advantage of them. There are of course also ports available for all supported BIND versions, as well as dns/bind9 for BIND version 9.3 which has been EOL'ed by ISC but is still in FreeBSD version 6. This also leads to the issue mentioned in the post above, the desynchronization between FreeBSD and ISC release schedules. While FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND version 9.3.6-P1, which has long been EOL. There are a number of problems related to upgrading the version of BIND in a release branch of FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with the ports tree, and given the characteristics of the vulnerabilities that have come to light with BIND 9.3.x to date, this hasn't been a problem. There is no guarantee that this will continue to be the case. This problem will reappear again in FreeBSD version 7 with BIND 9.4, and FreeBSD version 8 with BIND 9.6. PROS This change will have several advantages. 1) Users of all FreeBSD versions will be able to have easy access to the latest versions of BIND, and an easy upgrade path that does not involve a full OS upgrade. 2) The release synchronization problem mentioned above will no longer be a problem. 3) Users of other DNS solutions will no longer need to customize their build using the various WITH/WITHOUT_BIND* knobs. CONS Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. IMPLEMENTATION TIMELINE I will be removing BIND from HEAD today. Removal from the other branches will occur far enough in advance of their upcoming releases to ensure that the users have a chance to shake things out first. I'll also be committing the bind-tools and bind-config ports today so that users will continue to have easy access to the work I've done on named.conf, rc.d/named, etc. I have been maintaining BIND in the base for almost 8 years now, and while it's been challenging in a lot of ways, it's also been a great privilege to be able to help the FreeBSD community in this way. I can't say that I'll miss the drama of src updates though. :) Many happy returns of the day, 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku1G1sACgkQyIakK9Wy8PuPgQCfdrhgscMQ+KPLcoRXx66f4f6M T8wAniZqULdwM+4oRsbOkFSDZIceWn0u =Syor -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 1 22:57:00 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D119D106566B for ; Thu, 1 Apr 2010 22:57:00 +0000 (UTC) (envelope-from peter.thoenen@yahoo.com) Received: from web111402.mail.gq1.yahoo.com (web111402.mail.gq1.yahoo.com [67.195.15.138]) by mx1.freebsd.org (Postfix) with SMTP id 82CFC8FC1F for ; Thu, 1 Apr 2010 22:57:00 +0000 (UTC) Received: (qmail 28762 invoked by uid 60001); 1 Apr 2010 22:30:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270161020; bh=ft+a1KCdZIWgKEX1ROlb97tzeOFJ+/rZff2vCH7aXHE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=beZgE3kalXA/J1QyC7dPII3e1+k/6yoEVzQ3WXD3+TTA7AWkDCPolpoD72F6adFNxTUAtT1jkp/jrdhr1yT5UNu+lGjbIC97Dj51/YP6Kb7MAldJaeNJ4CZm/l6w/zVUOOc7EInuRJIgtvt/xRxYp4bA6w5g/OUvVnOcxa1cYXY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dUmpew0tmEXPzRsm52AmhRc2OwD1HsSjQTYjKpaLwMpjRdrBsCpiN2FO4MU+dX6QgKtCfaokufhZ7ItHiGBFMYh/4HF9as07q9cyHjlLDsSud2c0pWJ0TZRtWB0CdzaSPHjfAXEF5T0pn9RZEaB6UG2d0UU8rg2JEVA9JHKC75I=; Message-ID: <328862.28246.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 4qxas0wVM1lJq9WpN3Ztg8xbTKaxpQe3H7ifpCqKg1PPqc_ rvupGziQkTT8LC.TfbpDFZnyUS_4.pDxSL1rddcWVv7MqQzolfVXPDzPEmI9 NYmMdw5VjP4Sfzpaaa9UaeS0vI2bjqvpWNQpe52gkEei4KMhR0Wm_kcKtKZc ghJvL72co_69N4eoL9LRSB9thrkajibCeAZ_KKpnPCDQO3i3HpZRyWxmaaK9 j1Hr4nEvsIPZk13JEW5A47zdL9zWGqYlv03yHsg10VLPsLswRbXyKUuOAfj1 H3NFuAopXf8cV_rwXkyp8EOZBXapmVhqbHlFOnwk- Received: from [140.90.201.103] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 01 Apr 2010 15:30:20 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Thu, 1 Apr 2010 15:30:20 -0700 (PDT) From: Peter Thoenen To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Doug Barton In-Reply-To: <4BB51B5B.1050606@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 22:57:00 -0000 May I only hope this is legit and not a April Fool's joke :) From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 01:52:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D5A11065670 for ; Fri, 2 Apr 2010 01:52:58 +0000 (UTC) (envelope-from pluknet@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 AE7AE8FC13 for ; Fri, 2 Apr 2010 01:52:57 +0000 (UTC) Received: by bwz8 with SMTP id 8so1329187bwz.3 for ; Thu, 01 Apr 2010 18:52:56 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7t1kQc8KT9h3IhX51axz73eV2ByxGVH7LCIO8atWQWk=; b=MrO3kumOuGOmUkP5+qPm6x6fKT6RxTGHJZrN2F98FXeMxlXIovsWGc68ZwEvkoy4N0 8Fv+Lmdvjl3CJvQ6BokgoXow+OFgCW+5hkVXDpuf39l2353340Sh6J8hmQJ5wI6tSepm euzxJC9ggHim67/vpWgUfyPM5zH2VW5TFUzdA= 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=H8dpZBPtv0F4r6CazSx8LHYJDdAnZjFGimfs3bJZUqPTYNNr1nHgCcyk/LQiiqZ51E 1amUxwJOfVC8H4+o58a0/i7dM6iv024YJgK/HIxq/CoeQIoWT4BosSyYsqlcPMl97ppL nJma9AnsQoCaEnm3S6rLJ4OAZ5L9CUx72MA48= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Thu, 1 Apr 2010 18:52:54 -0700 (PDT) In-Reply-To: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> Date: Fri, 2 Apr 2010 05:52:54 +0400 Received: by 10.204.138.219 with SMTP id b27mr2157463bku.139.1270173174703; Thu, 01 Apr 2010 18:52:54 -0700 (PDT) Message-ID: From: pluknet To: Oleg Lomaka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 01:52:58 -0000 On 1 April 2010 22:18, Oleg Lomaka wrote: > Hello, > > I have a kernel panic when connect to postgresql8.4 server installed in o= ne of jails from another jail. It's 100% reproducible. > Also I have tried to connect from host machine to jailed pg server. That = way it works fine without crash. > > Server configuration uses geli and zfs. Four disks encrypted using geli. = And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All ja= ils located at this raidz2 pool. > > Also I use ezjail for jails management. And it uses NFS to mount director= ies with base system. > > atal double fault > rip =3D 0xffffffff8063510a > rsp =3D 0xffffff80eaec5f50 > rbp =3D 0xffffff80eaec6040 > cpuid =3D 1; apic id =3D 02 > panic: double fault > cpuid =3D 1 > Uptime: 7m11s > Physical memory: 8169 MB > > uname -a > FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Th= u Apr =A01 13:43:57 EEST 2010 =A0 =A0 root@cerberus.regredi.com:/usr/obj/us= r/src/sys/GENERIC =A0amd64 > > Link to dmesg.boot: > http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTl= iZDctZjU3N2YwNmMxNjZl&hl=3Den > > Link to kernel core backtrace: > http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&= hl=3Den Looking at backtrace, I wonder whether tp->t_maxseg changes in tcp_mtudisc() at all. You should be able to extract its value on each 2*n frame in that big recursive call. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 03:48:42 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3972106564A; Fri, 2 Apr 2010 03:48:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id AB7108FC08; Fri, 2 Apr 2010 03:48:42 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxXs8-000PsQ-Bp; Fri, 02 Apr 2010 03:48:40 +0000 Date: Fri, 02 Apr 2010 12:48:36 +0900 Message-ID: From: Randy Bush To: Peter Thoenen In-Reply-To: <328862.28246.qm@web111402.mail.gq1.yahoo.com> References: <4BB51B5B.1050606@FreeBSD.org> <328862.28246.qm@web111402.mail.gq1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Doug Barton , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 03:48:42 -0000 > May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 04:28:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654CF106566C; Fri, 2 Apr 2010 04:28:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B68018FC17; Fri, 2 Apr 2010 04:28:34 +0000 (UTC) Received: by gwaa20 with SMTP id a20so414236gwa.13 for ; Thu, 01 Apr 2010 21:28:34 -0700 (PDT) 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 :x-enigmail-version:content-type:content-transfer-encoding; bh=cOkDSYpQKgb3Y35jZiCv3qFqOnUI6zT5VXY4qxkQ2hI=; b=NbkLBz7+2Hq4UkYV7JbNHvZ4e/ZLxqTEAPORRz3UyC36m/YLqYtEuprnWW58G/Pq3U D50AzolTQ5EvaMaYNDDn86ngmvMNKpnJO/2J9ZpeNJ9KYEXU+I0HQvBP/pkfObq3SFr9 XkfGFVmnnfyEkwMeISAP9H2KGVpcnPDw0149c= 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:x-enigmail-version:content-type :content-transfer-encoding; b=g6DRsp3Xsf7u37im0kNtAoNa5PcSSFvop0rhQEwf5MUfojPCEBeMuke46vFaEngrAv HHjMrvygBEdsY55yyw8GRMsNwj/6m1C7aE/FV5HO5VF5YluDhmT+rGopdS+mBfdB9nVP 05vevPJX/Dj3Q4uY5tcDyLLJ15ZOEnXUgHwuA= Received: by 10.150.128.39 with SMTP id a39mr2099971ybd.257.1270182514035; Thu, 01 Apr 2010 21:28:34 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-143-247.dsl.klmzmi.sbcglobal.net [99.181.143.247]) by mx.google.com with ESMTPS id 21sm1437950iwn.11.2010.04.01.21.28.28 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 21:28:32 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BB5724D.7080906@dataix.net> Date: Fri, 02 Apr 2010 00:27:57 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Randy Bush References: <4BB51B5B.1050606@FreeBSD.org> <328862.28246.qm@web111402.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Thoenen , freebsd-arch@freebsd.org, Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 04:28:35 -0000 On 04/01/2010 23:48, Randy Bush wrote: >> May I only hope this is legit and not a April Fool's joke :) > > actually, as an unbound user, i would be quite happy to have bind > removed. bloated, ever-buggy, config religion, ... > > randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 05:24:13 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6465106566B; Fri, 2 Apr 2010 05:24:13 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 356828FC08; Fri, 2 Apr 2010 05:24:13 +0000 (UTC) Received: from orion.SpringDaemons.com (unknown [99.48.191.9]) by mx0.deglitch.com (Postfix) with ESMTPA id 15E638FC4E; Fri, 2 Apr 2010 09:24:11 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id C8D423985D; Thu, 1 Apr 2010 22:24:09 -0700 (PDT) Date: Thu, 1 Apr 2010 22:24:04 -0700 From: Stanislav Sedov To: Doug Barton Message-Id: <20100401222404.77a14a02.stas@FreeBSD.org> In-Reply-To: <4BB51B5B.1050606@FreeBSD.org> References: <4BB51B5B.1050606@FreeBSD.org> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP" Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 05:24:13 -0000 --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton mentioned: >=20 > Of course this change will have some costs. Users of named who rely on > the current defaults will have some change management to deal with, > however the costs will be minimal. The one area that has come up > repeatedly in previous discussions about this topic is that users like > having access to the command line tools dig, host, and nslookup. To deal > with that issue I will be creating a bind-tools port so that those who > want just those tools can easily add them, without the overhead of the > rest of the BIND suite. If anyone has suggestions for other BIND tools > that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the=20 critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJLtX95AAoJEL8lojEJL9nwbJgQALOXVTF3xaj0lDVAsXtgFSWJ nYYts36/Msoe9AE8lTWoFnXsXfkLPaaqkcLOu7mGwBOIbbJ7ZfSY/KgTiUdEuha+ dXglF6dWmPfVO+ROZNtwE3MgCKdWR4o8/X/iAfyTKEf7L1exoRHdObLBUXQuYtmn 5mzORU84C6PkAyuJ6NIAs2A56yCmQv7L5fd3shDErkj5yMmF43dobnXBIeFPg8h2 Jo61HA6EhnZ4fvxcgPe9pkEAk2k2XQQYwY+aXVXGLHzuBI1P2WSFG48eB1eNG8cp 6rWMSirJrhKG7PzHSzVgUZ0PDWfQl9syRCJupNyAXHmP+f3dFguecvCmDADtnn3W js79ZkftYSHo++okUC1nXImh4ow8Z0RZ5xYAl4NYbgkAq7Pe3rMr5UADD/GwTM5w O/QRPRU4cPjBMAAANPyZXXSliuIk21CDbSL1Li/jI44Z+PJK/qSCGQxvZRsjgEnC C6HC4/dXT90NzHkNYUATlD9JjqCP92B89qikBA7nbbiq4uhcTUuvOMTcI8apAhj6 xT/Rr14BzCXTj1Ojr2HA4aCYc1PNdH4nVWDogiy9yIfopwEtTcUnz76UJRZXq8RA 2pWekU5uHjtk6IDfxfGXnDTM1HPKDk3mmiZU3nmojEnuG/0lvPHZ6suzEIE3X6fa 6A4HEP9NuTKm+ckCl+rj =J0FH -----END PGP SIGNATURE----- --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 05:46:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15520106564A for ; Fri, 2 Apr 2010 05:46:34 +0000 (UTC) (envelope-from oleg.lomaka@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 8A77A8FC12 for ; Fri, 2 Apr 2010 05:46:33 +0000 (UTC) Received: by bwz8 with SMTP id 8so1382894bwz.3 for ; Thu, 01 Apr 2010 22:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=zZ8fLcXoxWFMyHT7InugiwkBUs/u4g7BiDhNVsOizWA=; b=HcqNle0I4ft2lRnkVfTomtC6mXqW1qdnhHSpK/dj/EBjTad47qqUc02sXTICXamguO g86jAfLctsCREkKKgZM2G3dqtAQ01Fl7AAr0Vm4+Inn/DuXgIi9kpok1YRlwNvuApdJU MjhXLzIgT5+GfSi0s3n9RQMSINMik611zACmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=tWf+06juy2po/kTDh4MZmgrjQiy4OQgHIdLiTHxjld9Pkg9Q837a6YD1wJNSkln+t9 DvQA+z6WWJbaGuYkiei8kqy/YcLH6zuBCqKFP7Yf2Ep7DVJg37rN5fX47ksnO6aYnTgS 1mbMPkt/2fWXDDQPGh+FkZh1Snaz3byVZndZc= Received: by 10.204.136.156 with SMTP id r28mr2349504bkt.112.1270187191887; Thu, 01 Apr 2010 22:46:31 -0700 (PDT) Received: from [192.168.0.41] (82.193.113.15.ipnet.kiev.ua [82.193.113.15]) by mx.google.com with ESMTPS id 15sm4614877bwz.8.2010.04.01.22.46.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 22:46:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-3--177786261; protocol="application/pkcs7-signature"; micalg=sha1 From: Oleg Lomaka In-Reply-To: Date: Fri, 2 Apr 2010 08:46:29 +0300 Message-Id: <67FC0BD4-E06F-4DA1-AED3-B0D3B3D5A640@gmail.com> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> To: pluknet X-Mailer: Apple Mail (2.1078) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 05:46:34 -0000 --Apple-Mail-3--177786261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2010, at 4:52 AM, pluknet wrote: > On 1 April 2010 22:18, Oleg Lomaka wrote: >>=20 >>=20 >> I have a kernel panic when connect to postgresql8.4 server installed = in one of jails from another jail. It's 100% reproducible. >> Also I have tried to connect from host machine to jailed pg server. = That way it works fine without crash. >>=20 >> Server configuration uses geli and zfs. Four disks encrypted using = geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli = providers. All jails located at this raidz2 pool. >>=20 >> Also I use ezjail for jails management. And it uses NFS to mount = directories with base system. >>=20 >> atal double fault >> rip =3D 0xffffffff8063510a >> rsp =3D 0xffffff80eaec5f50 >> rbp =3D 0xffffff80eaec6040 >> cpuid =3D 1; apic id =3D 02 >> panic: double fault >> cpuid =3D 1 >> Uptime: 7m11s >> Physical memory: 8169 MB >>=20 >> uname -a >> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 = r206031: Thu Apr 1 13:43:57 EEST 2010 = root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 >>=20 >> Link to dmesg.boot: >> = http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTli= ZDctZjU3N2YwNmMxNjZl&hl=3Den >>=20 >> Link to kernel core backtrace: >> = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&h= l=3Den >=20 > Looking at backtrace, I wonder whether tp->t_maxseg changes in > tcp_mtudisc() at all. > You should be able to extract its value on each 2*n frame in that big > recursive call. You are right, pt->t_maxseg doesn't change (kgdb) frame 9 #9 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $1 =3D 14336 (kgdb) frame 11 #11 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $2 =3D 14336 ... (full log at = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfNGQ4cWpia2dz&h= l=3Den ) (kgdb) frame 81 #81 0xffffffff807097e8 in tcp_mtudisc (inp=3D0xffffff00193c53f0, = errno=3DVariable "errno" is not available. ) at tcp_offload.h:282 282 return (tcp_output(tp)); (kgdb) p tp->t_maxseg $37 =3D 14336 (kgdb)=20= --Apple-Mail-3--177786261-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 06:11:54 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BF8A106564A; Fri, 2 Apr 2010 06:11:54 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id 544428FC18; Fri, 2 Apr 2010 06:11:53 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward4.mail.yandex.net (Yandex) with ESMTP id 586F36AD8D06; Fri, 2 Apr 2010 10:11:51 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270188711; bh=38x1M9+CLJ3qnCE+MxigENr+80WlFwQlNSbQbiXm/00=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rTaZxsKudMWs2bwQLDbjXD8HjKhmnvO5D+Yk5kyMT/WBstL6FDfl2Av4rTpa6IDAY 3MWKZQR3lcSKwMnzEfxZk5OFX8ZIr7RMWDQwGQz/JwQIDQj8ncL2Xq9SO15JtMLP0E yvJjmjSdxY7sjIwczWxuW0IS7hHdTHM2M/s1yuYY= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 1002AE6006E; Fri, 2 Apr 2010 10:11:51 +0400 (MSD) Message-ID: <4BB58AA6.1040600@yandex.ru> Date: Fri, 02 Apr 2010 10:11:50 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Stanislav Sedov References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> In-Reply-To: <20100401222404.77a14a02.stas@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270188711 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:11:54 -0000 On 02.04.2010 9:24, Stanislav Sedov wrote: > While it certainly might make sense to drop BIND out of the base, I'm not > sure dropping bind tools as well from it is the best decision. How hard > it will be to continue maintaining bind tools inside the base (so the > critical ones like dig and nslookup still will be available), while moving > the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base, It is very useful to still having them in base system. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 08:26:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9FC106566C; Fri, 2 Apr 2010 08:26:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BE06F8FC16; Fri, 2 Apr 2010 08:26:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxcCk-0000YN-Gq; Fri, 02 Apr 2010 08:26:14 +0000 Date: Fri, 02 Apr 2010 17:26:13 +0900 Message-ID: From: Randy Bush To: Stanislav Sedov In-Reply-To: <20100401222404.77a14a02.stas@FreeBSD.org> References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:26:15 -0000 > While it certainly might make sense to drop BIND out of the base, I'm not > sure dropping bind tools as well from it is the best decision. How hard > it will be to continue maintaining bind tools inside the base (so the > critical ones like dig and nslookup still will be available), while moving > the rest of it (the server itself and supporting tools) to the port? i don't mind if dig, doc, et alia are not in base, as long as they are a separate port from the bind hippo. randy From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 08:32:30 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF811065717; Fri, 2 Apr 2010 08:32:30 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 886228FC1D; Fri, 2 Apr 2010 08:32:29 +0000 (UTC) Received: from sputnik.SpringDaemons.com (c-67-188-12-68.hsd1.ca.comcast.net [67.188.12.68]) by mx0.deglitch.com (Postfix) with ESMTPA id 7F7708FC4E; Fri, 2 Apr 2010 12:32:26 +0400 (MSD) Received: from sputnik.SpringDaemons.com (localhost [127.0.0.1]) by sputnik.SpringDaemons.com (Postfix) with SMTP id 53E76B874; Fri, 2 Apr 2010 01:33:54 -0700 (PDT) Date: Fri, 2 Apr 2010 01:33:53 -0700 From: Stanislav Sedov To: Randy Bush Message-Id: <20100402013353.f544e8ad.stas@FreeBSD.org> In-Reply-To: References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprin: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:32:30 -0000 On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush mentioned: > > i don't mind if dig, doc, et alia are not in base, as long as they are a > separate port from the bind hippo. > The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 09:14:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBFF8106566B for ; Fri, 2 Apr 2010 09:14:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2A48FC0C for ; Fri, 2 Apr 2010 09:14:14 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C5C28647F; Fri, 2 Apr 2010 08:55:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o328t7dA011352; Fri, 2 Apr 2010 08:55:07 GMT (envelope-from phk@critter.freebsd.dk) To: Stanislav Sedov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Apr 2010 01:33:53 MST." <20100402013353.f544e8ad.stas@FreeBSD.org> Date: Fri, 02 Apr 2010 08:55:07 +0000 Message-ID: <11351.1270198507@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Randy Bush , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 09:14:14 -0000 In message <20100402013353.f544e8ad.stas@FreeBSD.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 17:26:13 +0900 >Randy Bush mentioned: >Ports doesn't support cross-compilation yet, >and it would be a pity to find yourself >bootstrapping another tiny arm platform and >having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make "a usable system", so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 09:15:50 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 905391065674; Fri, 2 Apr 2010 09:15:50 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 42CDC8FC0C; Fri, 2 Apr 2010 09:15:50 +0000 (UTC) Received: from sputnik.SpringDaemons.com (c-67-188-12-68.hsd1.ca.comcast.net [67.188.12.68]) by mx0.deglitch.com (Postfix) with ESMTPA id 639EF8FC4E; Fri, 2 Apr 2010 13:15:48 +0400 (MSD) Received: from sputnik.SpringDaemons.com (localhost [127.0.0.1]) by sputnik.SpringDaemons.com (Postfix) with SMTP id 0FE17B874; Fri, 2 Apr 2010 02:17:16 -0700 (PDT) Date: Fri, 2 Apr 2010 02:17:15 -0700 From: Stanislav Sedov To: "Poul-Henning Kamp" Message-Id: <20100402021715.669838e0.stas@FreeBSD.org> In-Reply-To: <11351.1270198507@critter.freebsd.dk> References: <20100402013353.f544e8ad.stas@FreeBSD.org> <11351.1270198507@critter.freebsd.dk> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprin: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Randy Bush , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 09:15:50 -0000 On Fri, 02 Apr 2010 08:55:07 +0000 "Poul-Henning Kamp" mentioned: > In message <20100402013353.f544e8ad.stas@FreeBSD.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 17:26:13 +0900 > >Randy Bush mentioned: > > >Ports doesn't support cross-compilation yet, > >and it would be a pity to find yourself > >bootstrapping another tiny arm platform and > >having to use ports to have a usable system. > > The result of the RFC was that bind is not a mandatory component > to make "a usable system", so you argument suffers from bad logic. > > The fact that you want BIND on your arm, is no different from > somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 09:24:53 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5668106566B; Fri, 2 Apr 2010 09:24:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 91DF48FC19; Fri, 2 Apr 2010 09:24:53 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 57D5C6445; Fri, 2 Apr 2010 09:24:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o329OpiN011598; Fri, 2 Apr 2010 09:24:52 GMT (envelope-from phk@critter.freebsd.dk) To: Stanislav Sedov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Apr 2010 02:17:15 MST." <20100402021715.669838e0.stas@FreeBSD.org> Date: Fri, 02 Apr 2010 09:24:51 +0000 Message-ID: <11597.1270200291@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Randy Bush , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 09:24:53 -0000 In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 08:55:07 +0000 >"Poul-Henning Kamp" mentioned: >Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 10:14:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47863106564A for ; Fri, 2 Apr 2010 10:14:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7D68FC1A for ; Fri, 2 Apr 2010 10:14:55 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 0aEw1e00616AWCUA3aEwl3; Fri, 02 Apr 2010 10:14:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta06.emeryville.ca.mail.comcast.net with comcast id 0aEv1e0013S48mS8SaEvne; Fri, 02 Apr 2010 10:14:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5436B9B419; Fri, 2 Apr 2010 03:14:54 -0700 (PDT) Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick To: Poul-Henning Kamp Message-ID: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11597.1270200291@critter.freebsd.dk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Randy Bush , Doug Barton , freebsd-stable@FreeBSD.org, Stanislav Sedov , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:14:56 -0000 On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote: > In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 08:55:07 +0000 > >"Poul-Henning Kamp" mentioned: > > >Sorry, I think I was not clear enough. > > Sorry for misunderstanding. > > Yes, the case can certainly be made that DNS query tool belongs in the > base system. I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) [1]: FreeBSD really needs to move away from the "base system" as a concept, as I've ranted about in the past. Or if it cannot, the "base system" needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: "I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32". Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 10:28:38 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD43C1065676 for ; Fri, 2 Apr 2010 10:28:38 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 10B2F8FC1B for ; Fri, 2 Apr 2010 10:28:37 +0000 (UTC) Received: (qmail 8369 invoked from network); 2 Apr 2010 10:28:36 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 2 Apr 2010 10:28:36 -0000 Date: Fri, 02 Apr 2010 12:28:36 +0200 (CEST) Message-Id: <20100402.122836.41723967.sthaug@nethelp.no> To: freebsd@jdc.parodius.com From: sthaug@nethelp.no In-Reply-To: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@FreeBSD.org, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org, randy@psg.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:28:38 -0000 > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Strongly disagree. > Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 10:45:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A0B2106564A for ; Fri, 2 Apr 2010 10:45:02 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:20c:29ff:fece:79f3]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCF98FC08 for ; Fri, 2 Apr 2010 10:45:01 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:a033:8846:655f:a7cb] (unknown [IPv6:2002:51af:3dc3:0:a033:8846:655f:a7cb]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 6C5267B for ; Fri, 2 Apr 2010 12:44:59 +0200 (CEST) Message-ID: <4BB5CAA7.5030108@stillbilde.net> Date: Fri, 02 Apr 2010 12:44:55 +0200 From: "Svein Skogen (Listmail Account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> In-Reply-To: <20100402.122836.41723967.sthaug@nethelp.no> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE2F259D20C618CF99219C088" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:45:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE2F259D20C618CF99219C088 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02.04.2010 12:28, sthaug@nethelp.no wrote: >> [1]: FreeBSD really needs to move away from the "base system" as a >> concept, as I've ranted about in the past. >=20 > Strongly disagree. >=20 >> Or if it cannot, the "base >> system" needs to start using pkg_* (somehow) for use, and src.conf >> WITHOUT_xxx (where xxx =3D some software) removed. Concept being: "I >> don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; >> pkg_delete base-lib32". Beautiful concept, hard to implement due to >> libraries being yanked out from underneathe binaries that are linked t= o >> them. But you get the idea. >=20 > This *might* be workable. However, in general - a large part of the > reason why I use FreeBSD is that the FreeBSD base system gives me > most of what I want, in *one* well defined chunk, *without* having > to install a zillion extra packages, and without umpteen different > versions of config files and locations for the important information. >=20 > So please don't destroy this. With the risk of sounding like a me-too-ist: "me too!" I can see the point some have in wanting to run a version from ports over running the base system one. This is doable in the current setup. However the bundled versions of bind (and the other base system packages) are rock stable and there for a reason. Following the "I want this slimmed down and moved to the ports/packages section", further, you could argue that ls, dd, and basically most of /usr/bin could go the same way. Giving FreeBSD the same "distribution nightmare" that some of the ... other unix-like os'es have. Is this really where the users of the OS want it to go? We'll end up spending more time updating tidbits of the system now moved to packages, than actually using it. But why stop there? We could do the same to the src/sys/dev subdirectories as well... Let's not do that, please? //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =D8stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enigE2F259D20C618CF99219C088 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iEYEARECAAYFAku1yqsACgkQODUnwSLUlKTjkACgmwnCzAQDo/pvDVy3r0nYAAVm TP0AoKAuXnr49r157LrkgFeNI8A9v1Qt =9yTv -----END PGP SIGNATURE----- --------------enigE2F259D20C618CF99219C088-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 10:52:21 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE2C10656C1; Fri, 2 Apr 2010 10:52:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EBBBD8FC13; Fri, 2 Apr 2010 10:52:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 857C646B2C; Fri, 2 Apr 2010 06:52:20 -0400 (EDT) Date: Fri, 2 Apr 2010 11:52:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <11351.1270198507@critter.freebsd.dk> Message-ID: References: <11351.1270198507@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Doug Barton , freebsd-stable@FreeBSD.org, Stanislav Sedov , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 10:52:21 -0000 On Fri, 2 Apr 2010, Poul-Henning Kamp wrote: > The result of the RFC was that bind is not a mandatory component to make "a > usable system", so you argument suffers from bad logic. With an eye on the date of Doug's suggestive e-mail, I actually am concerned that we maintain support for DNSSEC validation in the base system. If this can be accomplished by keeping DNS debugging tools and the lightweight resolver in the base, then I'm fine with that world view. However, if we can't do DNSSEC record validation without installing the BIND package, then that worries me. As we go forward, DNSSEC is going to become increasingly important, and being unable to bootstrap a system will be a problem, and it will become an increasingly critical part of the security bootstrap process for networked systems. While some DNSSEC folk consider it anathema ("DNS is not a directory service!"), the ability to securely distribute keying material via an existing network service has enourmous value: for example, early DNSSEC prototypes in the late 1990's/early 2000's included SSH key distribution via cert records in DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to DNSSEC expand, any decision to require a package to do DNSSEC would mean any component depending on that also has to be outside our base. If all requirements along these lines are met by the lightweight resolver, then this is less of a concern. Robert From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 11:14:53 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC65C1065678 for ; Fri, 2 Apr 2010 11:14:53 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 608818FC13 for ; Fri, 2 Apr 2010 11:14:53 +0000 (UTC) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:57555 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Nxepb-0005nt-7m for freebsd-stable@FreeBSD.org; Fri, 02 Apr 2010 13:14:33 +0200 Received: (qmail 54992 invoked from network); 2 Apr 2010 13:14:30 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 Apr 2010 13:14:30 +0200 Received: (qmail 1743 invoked by uid 1001); 2 Apr 2010 13:14:30 +0200 Date: Fri, 2 Apr 2010 13:14:30 +0200 From: Erik Trulsson To: Jeremy Chadwick Message-ID: <20100402111430.GA1706@owl.midgard.homeip.net> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100402101454.GA62089@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1Nxepb-0005nt-7m. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Nxepb-0005nt-7m 75f9d3a1c91665687c65283352b581df Cc: Stanislav Sedov , Doug Barton , freebsd-stable@FreeBSD.org, Randy Bush , Poul-Henning Kamp , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:14:53 -0000 On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) No, it does not need to do that. It might be a good idea (but I am far from convinced of it), but there most certainly is no *need* to move in that direction. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 11:16:57 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F5F1065677; Fri, 2 Apr 2010 11:16:57 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id E95B98FC29; Fri, 2 Apr 2010 11:16:56 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id B4FC11CC60; Fri, 2 Apr 2010 14:01:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by localhost (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TOrv0FCxeh39; Fri, 2 Apr 2010 14:01:46 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 256391CC5D; Fri, 2 Apr 2010 14:01:44 +0300 (EEST) Message-ID: From: "Reko Turja" To: References: <20100402021715.669838e0.stas@FreeBSD.org><11597.1270200291@critter.freebsd.dk><20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> In-Reply-To: <20100402.122836.41723967.sthaug@nethelp.no> Date: Fri, 2 Apr 2010 14:01:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-7"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:16:57 -0000 +AD4- Strongly disagree. +AD4- +AD4APg- Or if it cannot, the +ACI-base +AD4APg- system+ACI- needs to start using pkg+AF8AKg- (somehow) for use, = and src.conf +AD4APg- WITHOUT+AF8-xxx (where xxx +AD0- some software) removed. = Concept being: +ACI-I +AD4APg- don't need Kerberos+ADs- pkg+AF8-delete base-krb5. I also = don't need=20 +AD4APg- lib32+ADs- +AD4APg- pkg+AF8-delete base-lib32+ACI-. Beautiful concept, hard to = implement due=20 +AD4APg- to +AD4APg- libraries being yanked out from underneathe binaries that are=20 +AD4APg- linked to +AD4APg- them. But you get the idea. +AD4- +AD4- This +ACo-might+ACo- be workable. However, in general - a large = part of the +AD4- reason why I use FreeBSD is that the FreeBSD base system gives me +AD4- most of what I want, in +ACo-one+ACo- well defined chunk, = +ACo-without+ACo- having +AD4- to install a zillion extra packages, and without umpteen different +AD4- versions of config files and locations for the important=20 +AD4- information. me +-1 If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed=20 either thank you. Funny though that BIND which is pretty=20 straightforward as configuration goes and as much essential system=20 component as Sendmail is getting the axe. I thought one of the main=20 philosophies in FreeBSD always was being a system in itself, rather=20 than kernel with some haphazardly thrown in components added. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 11:45:48 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF94106564A; Fri, 2 Apr 2010 11:45:48 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 483628FC16; Fri, 2 Apr 2010 11:45:48 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id 0BD964B7826; Fri, 2 Apr 2010 19:27:37 +0800 (CST) Date: Fri, 2 Apr 2010 19:27:36 +0800 From: Denny Lin To: "Andrey V. Elsukov" Message-ID: <20100402112736.GB4611@mail.hs.ntnu.edu.tw> References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> <4BB58AA6.1040600@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4BB58AA6.1040600@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: dougb@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:45:48 -0000 On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: > On 02.04.2010 9:24, Stanislav Sedov wrote: > >While it certainly might make sense to drop BIND out of the base, I'm not > >sure dropping bind tools as well from it is the best decision. How hard > >it will be to continue maintaining bind tools inside the base (so the > >critical ones like dig and nslookup still will be available), while moving > >the rest of it (the server itself and supporting tools) to the port? > > Hi, All. > > I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the > base, > It is very useful to still having them in base system. +1 here. Dig and some of the other tools are extremely useful and important, so it would be nice if they were in the base system instead of a separate port. -- Denny Lin From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 12:05:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5F8B1065675 for ; Fri, 2 Apr 2010 12:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6C43A8FC1C for ; Fri, 2 Apr 2010 12:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7721641C756; Fri, 2 Apr 2010 14:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Q1E5GhFLNb5A; Fri, 2 Apr 2010 14:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D3EE041C75D; Fri, 2 Apr 2010 14:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 464404448EC; Fri, 2 Apr 2010 12:02:47 +0000 (UTC) Date: Fri, 2 Apr 2010 12:02:47 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Oleg Lomaka In-Reply-To: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> Message-ID: <20100402120137.E40281@maildrop.int.zabbadoz.net> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:05:07 -0000 On Thu, 1 Apr 2010, Oleg Lomaka wrote: Hi, > I have a kernel panic when connect to postgresql8.4 server installed in one of jails from another jail. It's 100% reproducible. > Also I have tried to connect from host machine to jailed pg server. That way it works fine without crash. > > Server configuration uses geli and zfs. Four disks encrypted using geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli providers. All jails located at this raidz2 pool. > > Also I use ezjail for jails management. And it uses NFS to mount directories with base system. > > atal double fault > rip = 0xffffffff8063510a > rsp = 0xffffff80eaec5f50 > rbp = 0xffffff80eaec6040 > cpuid = 1; apic id = 02 > panic: double fault > cpuid = 1 > Uptime: 7m11s > Physical memory: 8169 MB > > uname -a > FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 > > Link to dmesg.boot: > http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en > > Link to kernel core backtrace: > http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en > > Can I help to spot this trouble by providing additional info? Looking at the info I doubt it's related to jails or Pg in first place. Have you been running that same setup already before your Apr 1st, r206031, kernel? If so, from when was your last kernel? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 12:15:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776C41065673 for ; Fri, 2 Apr 2010 12:15:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8E58FC26 for ; Fri, 2 Apr 2010 12:15:28 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 0br71e0031bwxycA7cFVbr; Fri, 02 Apr 2010 12:15:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id 0cKg1e0043S48mS8ecKgYw; Fri, 02 Apr 2010 12:19:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6FF319B419; Fri, 2 Apr 2010 05:15:26 -0700 (PDT) Date: Fri, 2 Apr 2010 05:15:26 -0700 From: Jeremy Chadwick To: "Svein Skogen (Listmail Account)" Message-ID: <20100402121526.GA64746@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> <4BB5CAA7.5030108@stillbilde.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB5CAA7.5030108@stillbilde.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:15:28 -0000 On Fri, Apr 02, 2010 at 12:44:55PM +0200, Svein Skogen (Listmail Account) wrote: > On 02.04.2010 12:28, sthaug@nethelp.no wrote: > >> [1]: FreeBSD really needs to move away from the "base system" as a > >> concept, as I've ranted about in the past. > > > > Strongly disagree. > > > >> Or if it cannot, the "base > >> system" needs to start using pkg_* (somehow) for use, and src.conf > >> WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > >> don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > >> pkg_delete base-lib32". Beautiful concept, hard to implement due to > >> libraries being yanked out from underneathe binaries that are linked to > >> them. But you get the idea. > > > > This *might* be workable. However, in general - a large part of the > > reason why I use FreeBSD is that the FreeBSD base system gives me > > most of what I want, in *one* well defined chunk, *without* having > > to install a zillion extra packages, and without umpteen different > > versions of config files and locations for the important information. > > > > So please don't destroy this. > > With the risk of sounding like a me-too-ist: "me too!" Since I made a bikeshed reference I don't want to continue arguing my point -- I've said my piece, and that's that. But I'm just one man, with one opinion (that IS in fact shared by others), but I hold high respect for others' views despite being different from my own. However, I want to make some things perfectly clear, because there's some misconceptions (IMHO), addressed below. I won't respond to this thread past this point. > I can see the point some have in wanting to run a version from ports > over running the base system one. This is doable in the current setup. > However the bundled versions of bind (and the other base system > packages) are rock stable and there for a reason. 1) In most scenarios (historically speaking), what gets updated quicker: base or ports? Answer: ports. For **security issues only**, the base system gets updated quickly. Of course, in some cases (depending on the software), this requires an **entire world rebuild**. Why not just rebuild only what's dependent upon what got fixed? "OpenSSL security hole fixed, gotta rebuild.... uh, world?" Yes, there are sometimes exceptions to this rule, but depending upon what the software is, world is usually what you have to resort to. 2) What has proper infrastructure for dependencies and tracking of installed files as part of a software package? Answer: ports. The base system has src/ObsoluteFiles.inc which has been stated *by developers* as "being regularly neglected" and "is a hack, not fully effective". This is what "make delete-old" and "make delete-old-libs" uses, and where WITHOUT_xxx comes into play. Ponder this for a while. 3) How often do you see people posting problems with key pieces of FreeBSD infrastructure (device support/reliability or storage-related subsystems), followed by a response from a developer stating "this has been fixed in -STABLE" or "can you try the code from HEAD?" Answer: often. What all this means: change is happening much more rapidly than in the past. The days of "I installed FreeBSD on a box and didn't touch it for 60,000 years" are long gone -- assuming you care about true reliability and security. > Following the "I want this slimmed down and moved to the ports/packages > section", further, you could argue that ls, dd, and basically most of > /usr/bin could go the same way. Yes, and it should be, IMHO. Have you ever looked in src/contrib? A lot of FreeBSD's software these days -- the stuff you've come to rely upon -- is in src/contrib. Let me know if you don't use any of the software in there. :-) > Giving FreeBSD the same "distribution nightmare" that some of the ... > other unix-like os'es have. Is this really where the users of the OS > want it to go? We'll end up spending more time updating tidbits of the > system now moved to packages, than actually using it. Nothing *forces* you to update a package/port. If you want to run some old crusty version of some software (maybe there's legitimate reason for it, maybe the newer stuff is buggy), you can do this with ports. You could do this with the base system being package-ised or port-ised like I describe as well. But you cannot easily do this with the base -- the instant you csup to update base (for something else), you've now updated everything. And it's been stated many times by developers that your supfiles should use src-all and NOT select src-xxx pieces -- because world/kernel WILL break during build. To this day there are still "I tried to build world but it didn't work" "Show us your supfile" "" reports coming in. > But why stop > there? We could do the same to the src/sys/dev subdirectories as > well... That probably should happen too, *especially* for the networking and storage subsystems, which are being constantly updated to fix bugs. Not just improvements, but downright bugs. Do I really need to point you to all the mails about bce(4), bge(4), re(4), em(4), fxp(4), msk(4), ata(4), ahci(4), ZFS, blah blah blah... Again, see my point above, re: how often people report bugs with maintainers of these pieces telling folks to update things. Welcome to 2010. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 12:16:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB0391065677 for ; Fri, 2 Apr 2010 12:16:09 +0000 (UTC) (envelope-from oleg.lomaka@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 372038FC28 for ; Fri, 2 Apr 2010 12:16:08 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so570745fga.13 for ; Fri, 02 Apr 2010 05:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=VqzXwCFkPxCwE10eZlVyiZmwBj8DxWdkLQ6hZxDh/Xc=; b=Jki+Ylz6+oBhouYv9q1vejinDTM/fGUZCMxDy20pkxn6s/Kb35jsWHzKQrbudVNbBn XWueXa5TTfU3vAyLOBWlxV1NCwpQi6E621oaaSGtoMDignMQ5IUnsJRavhvsQfKn5DFv rKmPNxrvs1eDPBm62zOOdYuFZcsBJzP5VoG9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ReZNfd1p/y8ey4JsgFfdD+IZVebpPIPNhEmUa9MhiXROFGr8F0RF1IPdFNNwTN+Dzy WLxxxdpUWFO0vOAI2DcVxg6YHhDcMnzq6rfrqxSqmPftKSoLNNNPI5dJaPJ7EmknblSn /56Qc4vrQ+5cjNM+SXiY3Y5daxLI1uFmRIPHM= Received: by 10.87.67.25 with SMTP id u25mr3739518fgk.32.1270210567409; Fri, 02 Apr 2010 05:16:07 -0700 (PDT) Received: from [172.16.224.129] ([92.249.104.41]) by mx.google.com with ESMTPS id 3sm2179883fge.20.2010.04.02.05.16.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 05:16:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Oleg Lomaka In-Reply-To: <20100402120137.E40281@maildrop.int.zabbadoz.net> Date: Fri, 2 Apr 2010 15:16:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <363ECEF2-62D3-4F97-A21D-9E10358A1065@gmail.com> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> <20100402120137.E40281@maildrop.int.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:16:09 -0000 On Apr 2, 2010, at 3:02 PM, Bjoern A. Zeeb wrote: > On Thu, 1 Apr 2010, Oleg Lomaka wrote: >> I have a kernel panic when connect to postgresql8.4 server installed = in one of jails from another jail. It's 100% reproducible. >> Also I have tried to connect from host machine to jailed pg server. = That way it works fine without crash. >>=20 >> Server configuration uses geli and zfs. Four disks encrypted using = geli. And raidz2 is using ad8.eli, ad10.eli, ad12.eli, ad14.eli = providers. All jails located at this raidz2 pool. >>=20 >> Also I use ezjail for jails management. And it uses NFS to mount = directories with base system. >>=20 >> atal double fault >> rip =3D 0xffffffff8063510a >> rsp =3D 0xffffff80eaec5f50 >> rbp =3D 0xffffff80eaec6040 >> cpuid =3D 1; apic id =3D 02 >> panic: double fault >> cpuid =3D 1 >> Uptime: 7m11s >> Physical memory: 8169 MB >>=20 >> uname -a >> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 = r206031: Thu Apr 1 13:43:57 EEST 2010 = root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 >>=20 >> Link to dmesg.boot: >> = http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTli= ZDctZjU3N2YwNmMxNjZl&hl=3Den >>=20 >> Link to kernel core backtrace: >> = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&h= l=3Den >>=20 >> Can I help to spot this trouble by providing additional info? >=20 > Looking at the info I doubt it's related to jails or Pg in first > place. Have you been running that same setup already before your Apr > 1st, r206031, kernel? If so, from when was your last kernel? Yes, this configuration works on another server fine (8.0-STABLE FreeBSD = 8.0-STABLE #3 r205202) Made few more tests. All tests I make using psql command (as it is 100% = reproducible, may be now try spot it using telnet/netcat, without = involving pg). psql accomplish login operation fine, panic appears after = i run any command like \d, so I think it depends on packet size. Current picture is: 1. When connect from host machine - works fine. 2. When I connect from other server - works fine. 3. When connect from another jail on the same box as db's jail (tried = from few jails) - kernel fault.=20 Also tried security.jail.allow_raw_sockets on/off - nothing changes.=20 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 12:46:44 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9458C106564A; Fri, 2 Apr 2010 12:46:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 20A2A8FC0C; Fri, 2 Apr 2010 12:46:42 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 80A871524; Fri, 2 Apr 2010 14:46:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1270212394; x= 1272026794; bh=dX7cSJqfY7+OzHOJQOzznR5L2UkzMdbZWA7UpZYArGU=; b=S BywgMh8jE8vZ/9iopC41z9cdmovbmfGTKHLYyl4iNTqD5F/xTZMZNwagZeM9NhHu Fhw9sNjiIoCfs5JUNxMe3FjJfezMM06xJWNiug/6p8Lpruf1M+GDpHQuocZVTZ4J PLaoJW17b/Cwc7T0mge0PdbtvKbJNTQ0ciGN5l45AI= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sU75wPeBSBud; Fri, 2 Apr 2010 14:46:34 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 35A52151C; Fri, 2 Apr 2010 14:46:34 +0200 (CEST) Date: Fri, 2 Apr 2010 14:46:34 +0200 From: Guido Falsi To: sthaug@nethelp.no Message-ID: <20100402124633.GC33426@megatron.madpilot.net> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100402.122836.41723967.sthaug@nethelp.no> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: randy@psg.com, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org, stas@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:46:44 -0000 On Fri, Apr 02, 2010 at 12:28:36PM +0200, sthaug@nethelp.no wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > > concept, as I've ranted about in the past. > > Strongly disagree. I'm with you! > > > Or if it cannot, the "base > > system" needs to start using pkg_* (somehow) for use, and src.conf > > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > > pkg_delete base-lib32". Beautiful concept, hard to implement due to > > libraries being yanked out from underneathe binaries that are linked to > > them. But you get the idea. > > This *might* be workable. However, in general - a large part of the > reason why I use FreeBSD is that the FreeBSD base system gives me > most of what I want, in *one* well defined chunk, *without* having > to install a zillion extra packages, and without umpteen different > versions of config files and locations for the important information. > Also, more than that, won't splitting the "base system" in many smaller pieces moving around by themselves make every single part of freeBSD a moving target? What I mean is that what may look like a way to simplify things could make matters worse with incompatibilities in between the base packages. having everythign in the base system guarantees much more control. I'm also thinking about the nightmares this kind of splitting could cause to release engineering. This is not pure speculation. Such problems do appear in many other known open source OSes with such a split base system. In fact, if I wanted such a thing I'd install that other open source OS. I did in fact, and observed many annoying things about not having a rich base system like ours(like wasting time figuring which packet contained commands I'm used to see in the base system on any unix. > So please don't destroy this. I hope not. Another good reason not to destroy this is again that there are already many alternative OSes doing it, and I think FreebSD has a strong point in being different, not a weak spot. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 13:15:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC09106568E for ; Fri, 2 Apr 2010 13:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECD18FC15 for ; Fri, 2 Apr 2010 13:15:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7EAEC41C798; Fri, 2 Apr 2010 15:15:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id IBJHLyjMYPK6; Fri, 2 Apr 2010 15:15:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id AFA7B41C796; Fri, 2 Apr 2010 15:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D071E4448EC; Fri, 2 Apr 2010 13:12:40 +0000 (UTC) Date: Fri, 2 Apr 2010 13:12:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Oleg Lomaka In-Reply-To: <363ECEF2-62D3-4F97-A21D-9E10358A1065@gmail.com> Message-ID: <20100402131114.T40281@maildrop.int.zabbadoz.net> References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> <20100402120137.E40281@maildrop.int.zabbadoz.net> <363ECEF2-62D3-4F97-A21D-9E10358A1065@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:15:08 -0000 On Fri, 2 Apr 2010, Oleg Lomaka wrote: Hey, >>> uname -a >>> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 r206031: Thu Apr 1 13:43:57 EEST 2010 root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> Link to dmesg.boot: >>> http://docs.google.com/leaf?id=0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTliZDctZjU3N2YwNmMxNjZl&hl=en >>> >>> Link to kernel core backtrace: >>> http://docs.google.com/Doc?docid=0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&hl=en >>> >>> Can I help to spot this trouble by providing additional info? >> >> Looking at the info I doubt it's related to jails or Pg in first >> place. Have you been running that same setup already before your Apr >> 1st, r206031, kernel? If so, from when was your last kernel? > > Yes, this configuration works on another server fine (8.0-STABLE FreeBSD 8.0-STABLE #3 r205202) > > Made few more tests. All tests I make using psql command (as it is 100% reproducible, may be now try spot it using telnet/netcat, without involving pg). psql accomplish login operation fine, panic appears after i run any command like \d, so I think it depends on packet size. > > Current picture is: > 1. When connect from host machine - works fine. > 2. When I connect from other server - works fine. > 3. When connect from another jail on the same box as db's jail (tried from few jails) - kernel fault. > > Also tried security.jail.allow_raw_sockets on/off - nothing changes. In addition to the private mail I have just sent you, the first thing you might try it to updat again; I hadn't realized before that your r206031 seems to be in the middle of a multi-commit merge from two people. It would be worth to update to the latest stable/8 and try again first. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 14:53:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE201065670 for ; Fri, 2 Apr 2010 14:53:23 +0000 (UTC) (envelope-from oleg.lomaka@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2948FC12 for ; Fri, 2 Apr 2010 14:53:22 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so100068fgb.13 for ; Fri, 02 Apr 2010 07:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=HX5CZUGv+ShbPvwF72zBRKtuCCwOjZpYusAodAM86dE=; b=tF9aOZ7gVloH5HRelSdcLIlgzGLbVUYgiTD9wLdQ8NQJVD8jsyiLSwa0akj5Fn/q0i lpyx9PUuakFn+hC6f7CGf6pN4/2aQY0u7fl0hqKQC1ipwJOjVf6xXpvsTclQmoDqCE1N aqFjkUklIYGxtjQ+dgvjA0th/BsYohI3883J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=BQOmevsdmL4CLZBzKfbpPDtbt15Sa41nzTkiK28Q13DVlpNS7iZD9YU7suiGRpkYIS gDorOykFyLugBu0sRYlG2QsJly5W7cK6DwrICA43jHfcKeBWBgeceen/+6JC7i+1n/Do gNhCk6Vl0dty56qE5jwEHz8623GZ/R3QUI/nc= Received: by 10.87.47.3 with SMTP id z3mr893165fgj.74.1270220000716; Fri, 02 Apr 2010 07:53:20 -0700 (PDT) Received: from [172.16.224.129] ([92.249.104.41]) by mx.google.com with ESMTPS id e3sm8183666fga.9.2010.04.02.07.53.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 07:53:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Oleg Lomaka In-Reply-To: <20100402131114.T40281@maildrop.int.zabbadoz.net> Date: Fri, 2 Apr 2010 17:53:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44FD9C14-7114-4270-A7B6-F029995BA282@gmail.com> <20100402120137.E40281@maildrop.int.zabbadoz.net> <363ECEF2-62D3-4F97-A21D-9E10358A1065@gmail.com> <20100402131114.T40281@maildrop.int.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: panic during work with jailed postgresql8.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:53:23 -0000 On Apr 2, 2010, at 4:12 PM, Bjoern A. Zeeb wrote: > On Fri, 2 Apr 2010, Oleg Lomaka wrote: >=20 >>>> uname -a >>>> FreeBSD cerberus.regredi.com 8.0-STABLE FreeBSD 8.0-STABLE #7 = r206031: Thu Apr 1 13:43:57 EEST 2010 = root@cerberus.regredi.com:/usr/obj/usr/src/sys/GENERIC amd64 >>>>=20 >>>> Link to dmesg.boot: >>>> = http://docs.google.com/leaf?id=3D0B-irbkAqk9i7OGY2ZWJiODgtOWJmMy00NDQ1LTli= ZDctZjU3N2YwNmMxNjZl&hl=3Den >>>>=20 >>>> Link to kernel core backtrace: >>>> = http://docs.google.com/Doc?docid=3D0AeirbkAqk9i7ZGc5Yzc2ZndfM2M4NzYydmRw&h= l=3Den >>>>=20 >>>> Can I help to spot this trouble by providing additional info? >>>=20 >>> Looking at the info I doubt it's related to jails or Pg in first >>> place. Have you been running that same setup already before your = Apr >>> 1st, r206031, kernel? If so, from when was your last kernel? >>=20 >> Yes, this configuration works on another server fine (8.0-STABLE = FreeBSD 8.0-STABLE #3 r205202) >>=20 >> Made few more tests. All tests I make using psql command (as it is = 100% reproducible, may be now try spot it using telnet/netcat, without = involving pg). psql accomplish login operation fine, panic appears after = i run any command like \d, so I think it depends on packet size. >>=20 >> Current picture is: >> 1. When connect from host machine - works fine. >> 2. When I connect from other server - works fine. >> 3. When connect from another jail on the same box as db's jail (tried = from few jails) - kernel fault. >>=20 >> Also tried security.jail.allow_raw_sockets on/off - nothing changes. >=20 > In addition to the private mail I have just sent you, the first thing > you might try it to updat again; I hadn't realized before that your > r206031 seems to be in the middle of a multi-commit merge from two > people. >=20 > It would be worth to update to the latest stable/8 and try again > first. That's it. r206088 works fine. Thank you for help. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 16:50:07 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852D11065692; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25BB98FC0C; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o32Go28M009288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Apr 2010 09:50:02 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 71A8B1CC09; Fri, 2 Apr 2010 09:50:02 -0700 (PDT) To: Jeremy Chadwick In-reply-to: Your message of "Fri, 02 Apr 2010 03:14:54 PDT." <20100402101454.GA62089@icarus.home.lan> Date: Fri, 02 Apr 2010 09:50:02 -0700 From: "Kevin Oberman" Message-Id: <20100402165002.71A8B1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_11:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 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-1004020135 Cc: Stanislav Sedov , Doug Barton , freebsd-stable@FreeBSD.org, Randy Bush , Poul-Henning Kamp , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 16:50:08 -0000 > Date: Fri, 2 Apr 2010 03:14:54 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote: > > In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: > > >On Fri, 02 Apr 2010 08:55:07 +0000 > > >"Poul-Henning Kamp" mentioned: > > > > >Sorry, I think I was not clear enough. > > > > Sorry for misunderstanding. > > > > Yes, the case can certainly be made that DNS query tool belongs in the > > base system. > > I disagree (so what else is new?) It should be kept out of the base > system. KISS: > > Doug pulling BIND out of the base system / going ports-only = excellent. > > Doug making a separate port for BIND-esque DNS query/maintenance tools = > excellent. > > Both of the above can be made into packages. Vendors who use FreeBSD > can incorporate said package(s) into their build infrastructure. Folks > who do not have Internet connections (yet for some reason want said DNS > tools) can install the package(s) from CD/DVD/USB. > > I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I have seen suggestions that some tools be kept in the base system. nslookup (an evil tool that I think should be put out of its misery) and dig (a good tool that not enough people understand how to use) have been explicitly mentioned. The problem is that dig needs to be in reasonable feature sync with the resolver or it can have problems. Finally, what about a stub resolver? This really MUST be in the base system and, it should understand DNSSEC soon, which just complicates things. I prefer my bikeshed in green. Black is too goth and too hot for my tastes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 17:22:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9581D1065672; Fri, 2 Apr 2010 17:22:14 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id 476108FC17; Fri, 2 Apr 2010 17:22:14 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 4256F1CC60; Fri, 2 Apr 2010 20:22:06 +0300 (EEST) X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by localhost (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yZsC45uKhR7e; Fri, 2 Apr 2010 20:22:04 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 86B101CC5D; Fri, 2 Apr 2010 20:22:04 +0300 (EEST) Message-ID: <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> From: "Reko Turja" To: "freebsd-current+AEA-FreeBSD.ORG" References: <20100402165002.71A8B1CC09@ptavv.es.net> In-Reply-To: <20100402165002.71A8B1CC09@ptavv.es.net> Date: Fri, 2 Apr 2010 20:22:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-7"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 17:22:14 -0000 Based on the inspection of the source tree, I want my bikeshed mauve.=20 I've not been had by AFD jokes in a while but Doug pulled this one=20 off... -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 17:39:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770BA106564A for ; Fri, 2 Apr 2010 17:39:55 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.ORG [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id 50B8C8FC08 for ; Fri, 2 Apr 2010 17:39:55 +0000 (UTC) Received: from [10.0.1.4] (pool-71-109-144-133.lsanca.dsl-w.verizon.net [71.109.144.133]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id o32HdrCG096893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 10:39:54 -0700 (PDT) (envelope-from bc979@lafn.org) References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> <4BB58AA6.1040600@yandex.ru> <20100402112736.GB4611@mail.hs.ntnu.edu.tw> In-Reply-To: <20100402112736.GB4611@mail.hs.ntnu.edu.tw> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <6E191581-F8EB-4B85-9F1D-8D2FE6DAAF10@lafn.org> Content-Transfer-Encoding: quoted-printable From: Doug Hardie Date: Fri, 2 Apr 2010 10:39:53 -0700 To: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: clamav-milter 0.95.3 at zoom.lafn.org X-Virus-Status: Clean Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 17:39:55 -0000 On 2 April 2010, at 04:27, Denny Lin wrote: > On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: >> On 02.04.2010 9:24, Stanislav Sedov wrote: >>> While it certainly might make sense to drop BIND out of the base, = I'm not >>> sure dropping bind tools as well from it is the best decision. How = hard >>> it will be to continue maintaining bind tools inside the base (so = the >>> critical ones like dig and nslookup still will be available), while = moving >>> the rest of it (the server itself and supporting tools) to the port? >>=20 >> Hi, All. >>=20 >> I'm agree with Stas. If it is not so hard to maintain "bind-tools" in = the=20 >> base, >> It is very useful to still having them in base system. >=20 > +1 here. Dig and some of the other tools are extremely useful and > important, so it would be nice if they were in the base system instead > of a separate port. The reason dig and nslookup are used is because you have a problem with = the internet connection. Thats a bit late to say "you need to install = the DNS tools". If you could, you wouldn't need them. Not everyone = will create a ports CD. =20= From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 18:08:40 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91557106564A for ; Fri, 2 Apr 2010 18:08:40 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA948FC29 for ; Fri, 2 Apr 2010 18:08:39 +0000 (UTC) Received: (qmail 28759 invoked by uid 0); 2 Apr 2010 18:08:38 -0000 Received: from unknown (HELO ?10.82.15.178?) (spork@166.198.238.83) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 2 Apr 2010 18:08:38 -0000 References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> Message-Id: <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> From: Charles Sprickman To: Reko Turja In-Reply-To: <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 2 Apr 2010 14:08:27 -0400 Cc: "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:08:40 -0000 Can we do sendmail next April 1? Sent from a device with a tiny keyboard On Apr 2, 2010, at 1:22 PM, "Reko Turja" wrote: > Based on the inspection of the source tree, I want my bikeshed > mauve. I've not been had by AFD jokes in a while but Doug pulled > this one off... > > -Reko > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 18:29:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385D1106564A; Fri, 2 Apr 2010 18:29:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CA1D68FC0A; Fri, 2 Apr 2010 18:29:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o32ITQQg013377; Fri, 2 Apr 2010 14:29:26 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Fri, 02 Apr 2010 14:29:27 -0400 (EDT) Date: Fri, 2 Apr 2010 14:29:26 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kevin Oberman In-Reply-To: <20100402165002.71A8B1CC09@ptavv.es.net> Message-ID: References: <20100402165002.71A8B1CC09@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Doug Barton , freebsd-stable@freebsd.org, Stanislav Sedov , Poul-Henning Kamp , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Jeremy Chadwick Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:29:32 -0000 On Fri, 2 Apr 2010, Kevin Oberman wrote: >> Date: Fri, 2 Apr 2010 03:14:54 -0700 >> From: Jeremy Chadwick >> Sender: owner-freebsd-stable@freebsd.org >> >> I disagree (so what else is new?) It should be kept out of the base >> system. KISS: >> >> Doug pulling BIND out of the base system / going ports-only = excellent. >> >> Doug making a separate port for BIND-esque DNS query/maintenance tools = >> excellent. >> >> Both of the above can be made into packages. Vendors who use FreeBSD >> can incorporate said package(s) into their build infrastructure. Folks >> who do not have Internet connections (yet for some reason want said DNS >> tools) can install the package(s) from CD/DVD/USB. >> >> I want the bikeshed to be black. :-) > > I have very mixed feelings on this. I agree with arguments I have seen > on both sides. I like being able to install FreeBSD and have a well > integrated system with all of the basic tools installed for basic > use. Things play together well. > > I don't use many of the base system tools. I use cups, postfix, > customized ssh, and the ports version of BIND. I don't build the stuff I > don't need (src.conf) and I don't mind them being there. > > On the other hand, for complex, heavy duty ports, keeping up to date > with externally maintains tools (contrib) is a pain and the base system > can get stuck with rather out of date tools as a result. (Remember > perl?) Unless there is very strong support for a contributed tools, it's > hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, > it's still hopeless. I really dread having to update my ports. I hate all the bloated dependencies that a lot of ports have. It's sometimes a hit or miss situtation; you never know whether your ports are going to build (update) fully or not. And it takes forever. Our ports team does a fantastic job, so no diss intended. But I am concerned about moving BIND into ports, even if there is a tools-only port. With BIND in base, I don't have to worry about updating or when to update - someone else decides when to update/patch the base BIND and I am happy with that. All I have to do is buildworld, which I do much more often than update ports. If there is already a WITHOUT_BIND knob, then I really don't see what advantage there is in moving BIND out of base. Anyone that wants to use a different resolver can already do that, with the only limitation that they have to buildworld to remove the base bind. -- DE From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 19:07:55 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E567106566C for ; Fri, 2 Apr 2010 19:07:55 +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 06F218FC19 for ; Fri, 2 Apr 2010 19:07:54 +0000 (UTC) Received: (qmail 29978 invoked by uid 399); 2 Apr 2010 19:07:54 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Apr 2010 19:07:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB64088.8030003@FreeBSD.org> Date: Fri, 02 Apr 2010 12:07:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <11351.1270198507@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:07:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 So first of all, yes Virginia, this was an April Fool's Day joke. To both those for whom this post created a false sense of despair, and (perhaps more importantly) to those for whom it created a false sense of joy, my apologies. :) And for the record, everything from here on is "just the facts." I have always said that I will remove BIND from the base when there is clear community consensus to do so, and I stand by that. However the discussion always seems to go along the lines that this thread did. A vocal group who say, "YES!" and then a lot of people who want the resolution tools (dig, host, nslookup) to stay, and the other end of the bell-shaped curve with those who like having the whole thing in the base. Toss in a few choruses of "The whole base should be more modular," (a viewpoint with which I have a great deal of sympathy btw) and the soup is pretty well complete. In regard to the tools issue, the problem is that you need a pretty good majority of the code in order to build them. They require the libraries to be built, and once you've done that, you might as well do the rest. :) Total size of code in: contrib/bind9: 14.0M contrib/bind9/lib: 7.6M contrib/bind9/bin: 2.5M contrib/bind9/bin/dig: 0.4M The last is the directory that has the code for all 3 resolution tools, FYI. Therefore I think that the status quo of having it all in there, and knobs to turn off the bits you don't want is a good one since it seems to please the majority of our users. I will continue to maintain the bind-tools port though, that's something that's been requested often, and I think it's a good thing to have for those who want a different DNS solution but still want access to those tools in a fairly painless manner. And of course the ability to easily change/upgrade/manage what version of BIND you use via the ports will continue to be a key component of how we deal with this going forward. Of course, the release synchronization problems I described in both the original post and the AFD post are real, so stay tuned. :) Answers to DNSSEC concerns below. On 4/2/2010 3:52 AM, Robert Watson wrote: > With an eye on the date of Doug's suggestive e-mail, I actually am concerned > that we maintain support for DNSSEC validation in the base system. If this > can be accomplished by keeping DNS debugging tools and the lightweight > resolver in the base, then I'm fine with that world view. However, if we > can't do DNSSEC record validation without installing the BIND package, then > that worries me. Unfortunately this answer is more complicated than I'd like it to be. In general, DNS resolution requires 4 components (and yes, this is pretty well simplified, but I think the illustration serves to clarify my point): 1. An end-user application that makes a request 2. A stub resolver located on the local system 3. A resolving name server 4. An authoritative name server At this time the DNSSEC protocol only clearly addresses the behavior of 4, and partially addresses the behavior of 3. There is no protocol specification for 1 or 2. So in general if you want to be able to validate DNSSEC signatures on the local system the only option available to you is to run a local validating resolver. It doesn't have to be BIND, unbound is also a good candidate, but you have to run something locally to be sure that the response(s) you've received are valid. Now that said, if you have a special purpose in mind to validate records in a specific domain (or specific few domains) for which you are prepared to individually manage trust anchors (the generic term of art for DNSSEC keys) then you could do that using dig alone. However that solution would not scale well, and I wouldn't recommend it for a critical piece of the base or ports. > As we go forward, DNSSEC is going to become increasingly important, and being > unable to bootstrap a system will be a problem, and it will become an > increasingly critical part of the security bootstrap process for networked > systems. Since your description above is generic, I will generically agree with you. :) I think as time goes on and more intelligence about DNSSEC is pushed to the edges I think it will be possible to have a validating stub resolver, and on a trusted network reasonable to rely on an external validating resolving name server. However there's an awful lot of supposition there, and as I said above, the spec doesn't even exist yet, never mind the code. > While some DNSSEC folk consider it anathema ("DNS is not a directory > service!"), the ability to securely distribute keying material via an existing > network service has enourmous value: for example, early DNSSEC prototypes in > the late 1990's/early 2000's included SSH key distribution via cert records in > DNSSEC. The CERT record still exists, although not for ssh. See http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always TXT records. :) Now all THAT said, there is an element of DNSSEC that I am rather strongly leaning toward putting in the ports, trust anchor configuration. Currently you have essentially 2 choices for DNSSEC validation, manually configure trust anchors, or use a DNS Lookaside Validation (DLV) service, of which the most popular is ISC's. Both options have their benefits and their drawbacks, which are outside the scope of this post. OTOH, if things continue going according to plan the root zone will be signed with real DNSSEC keys in July. That will make it possible to do "regular" DNSSEC validation for those zones that are signed from the root down by only configuring one trust anchor, the root zone key. (If you need to validate something on a "secure island," i.e., one or more parent zones is not signed, you are back to the first 2 choices, but once again, out of scope.) In the ideal world the root zone trust anchor would function like the root.hints file does now. It is stable (not updated often) and failure to update it in a timely manner would not be catastrophic. Unfortunately, the first is not guaranteed, and the latter is the opposite of the truth. There has already been on incident where an OS distribution had shipped with trust anchors manually configured and when they became outdated hilarity ensued. I would like to avoid that for our users. At this time my plan is to add hooks for "easy" incorporation of DNSSEC validation into the base named.conf, with instructions for how to install the port/package, the importance of keeping it up to date, etc. Before I make any changes I'll be seeking input from experts in the DNSSEC community and posting something a little more focused on -arch at least. If the release engineer or security officer teams have "something" in mind for FreeBSD that will require DNSSEC, we'll have to coordinate efforts on this, but I don't imagine it will be too difficult even with a bind-dnssec-config port. 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 788AoPf53oxsgutXPriuLOszcp2DBKc1 =hUnq -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 19:08:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3C21065887 for ; Fri, 2 Apr 2010 19:08:18 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmailA.acsu.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE968FC1A for ; Fri, 2 Apr 2010 19:08:18 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B347BB77A; Fri, 2 Apr 2010 15:08:17 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 2656CB77B; Fri, 2 Apr 2010 15:08:17 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 20356B77A; Fri, 2 Apr 2010 15:08:17 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id 0D249203C0; Fri, 2 Apr 2010 15:08:17 -0400 (EDT) From: Ken Smith To: David Boyd In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DPgkABSNsjNUVxaJ+3vI" Date: Fri, 02 Apr 2010 15:08:16 -0400 Message-ID: <1270235296.61394.41.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-stable@freebsd.org Subject: Re: 6.4-RELEASE missing from mirrors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:08:18 -0000 --=-DPgkABSNsjNUVxaJ+3vI Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2010-04-01 at 11:07 -0400, David Boyd wrote: > The link (actually file) called "6.4 moved to ftp-archive" is missing fro= m > most/all mirrors. >=20 > We have been using these files to "follow" the releases when they move. >=20 > It works as long as the "6.4 moved to ftp-archive" file is present. >=20 > Please help. >=20 > Thanks. >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 >=20 Sorry about that, it should be fixed on ftp-master now and will propagate out to the mirrors as they do their next sync. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-DPgkABSNsjNUVxaJ+3vI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAku2QKAACgkQ/G14VSmup/YAYQCglYbddhQUmv8d95VbiBII4fRd unYAoIQArLXj3edqnhUp3OpidMjNhM8B =uPrS -----END PGP SIGNATURE----- --=-DPgkABSNsjNUVxaJ+3vI-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 21:08:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41052106564A; Fri, 2 Apr 2010 21:08:26 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id BB63D8FC17; Fri, 2 Apr 2010 21:08:25 +0000 (UTC) Received: by gxk2 with SMTP id 2so1824846gxk.3 for ; Fri, 02 Apr 2010 14:08:25 -0700 (PDT) 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:received:message-id:subject:from:to:content-type; bh=NQEnIzp56YO99tH7XEY7pwcAu4XgAWsVZnfYCnnkDiY=; b=JX+TuD9wADavAaF+G+2By5Z2jFC/HTEWJC3jiW94wCz4EjMtpL2Kelo4kScETyXZNN aMVnubIKDGtmpaqDnBujfiwXMVFUbSrA/mDvSn4B1G7AzrtfQXpJ5dLMeH22sNHQczCy gUh/ghmwoKCRi9kyMIOQfuoAL4xeQXIfpCWTE= 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=Mhhbz6Mq9Hz7eIpHBjSFi5BOi0FGt8l+jKFvv9Nay7ZXV8zCM6WtkNiDu1j7KCYEmW aQzVllVP7HNtqAXgxX8Ic/XPXyRMoxS30tf4MQgnr4bYPUPtCepCbcAYQcf7X7fJDyI0 ToShjH1qecj+yKNc9AGlj298nldsbjVofdsuQ= MIME-Version: 1.0 Received: by 10.231.35.203 with HTTP; Fri, 2 Apr 2010 14:08:24 -0700 (PDT) In-Reply-To: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> Date: Fri, 2 Apr 2010 14:08:24 -0700 Received: by 10.100.26.37 with SMTP id 37mr4633359anz.72.1270242504924; Fri, 02 Apr 2010 14:08:24 -0700 (PDT) Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:08:26 -0000 On Fri, Apr 2, 2010 at 3:14 AM, Jeremy Chadwick wrote: > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... No, no, no, definitely no, no, and no!! The greatest thing about FreeBSD is that there is a clear separation between the "base OS" and everything else (ports, local installs, etc). You get a nice, clearly defined, base to build on. You get a stable base that changes infrequently, that you can add software to on whatever schedule you want. The worst thing about Linux distros is the lack of this clear separation between the base and third-party apps. If you want to install an updated version of Apache, you either have to update the whole damned distro, go searching for some unsupported backports repos, or compile everything by hand defeating the whole point of binary packages. Making the tools do deal with the base could be interesting, but please, please, please don't shove everything into the pkg_tools and turning FreeBSD into "just a random collection of packages that kind of work together". IOW, don't go down the distro path. Keep the base OS separate from third-party apps. Keep the tools to deal with them separate. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 21:49:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73372106566C; Fri, 2 Apr 2010 21:49:58 +0000 (UTC) (envelope-from amvandemore@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 F332C8FC08; Fri, 2 Apr 2010 21:49:57 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so821674qwe.7 for ; Fri, 02 Apr 2010 14:49:57 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type; bh=Lt5IxyS8Yi6cSAa0aNmVyRM1OdzSbhUc8ODjPKd0mjE=; b=TrYOSVjZIP3ob36/D8VRfRdrlWix16YNCgIceSN5RXZIXJW7n90SDsHtkFvuPJdMVA 3DReMmaZSSIW39OX6u807QzX53BpNQnpqdAFg2OJ9Ps9oSb0454SH5OtO7oRMsZnGSKW XxcSrQ7G4/ZIkAzw7g/YEusxUiO+NompZBqQ0= 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=W4oa7QWQGUgyemE+Kj1EAvmFLrQN2fV/zLWt1uZuNSjmLLk95xuRaULjgUyEwyqLEz dVIelCLrQTBcSC6QL7rjElA2wZhlTst46ER4AA8wDDbshfbJ+D7SJwvtsJ5J7smpt4dm aYrYSPsbQfNGf3QX9H7EgMMb7lSquUKsEfuIE= MIME-Version: 1.0 Received: by 10.229.82.14 with HTTP; Fri, 2 Apr 2010 14:49:54 -0700 (PDT) In-Reply-To: References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> Date: Fri, 2 Apr 2010 15:49:54 -0600 Received: by 10.229.215.11 with SMTP id hc11mr4410504qcb.45.1270244994361; Fri, 02 Apr 2010 14:49:54 -0700 (PDT) Message-ID: From: Adam Vande More To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:49:58 -0000 On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash wrote: > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... > > No, no, no, definitely no, no, and no!! > > The greatest thing about FreeBSD is that there is a clear separation > between > the "base OS" and everything else (ports, local installs, etc). You get a > nice, clearly defined, base to build on. You get a stable base that > changes > infrequently, that you can add software to on whatever schedule you want. > > The worst thing about Linux distros is the lack of this clear separation > between the base and third-party apps. If you want to install an updated > version of Apache, you either have to update the whole damned distro, go > searching for some unsupported backports repos, or compile everything by > hand defeating the whole point of binary packages. > > Making the tools do deal with the base could be interesting, but please, > please, please don't shove everything into the pkg_tools and turning > FreeBSD > into "just a random collection of packages that kind of work together". > IOW, don't go down the distro path. > > Keep the base OS separate from third-party apps. Keep the tools to deal > with them separate. > True word, brother! If we wanted to run linux there are options for it. debs suck, rpms really suck. Those types of systems are sometimes faster to get up and rolling as long as you want vanilla apps, but they are a major PITA for many types of customizations which are a breeze with the ports tree. You'd be killing of one of the more elegant approaches in FreeBSD. Sure there are problem with it, but IMO adopting more severe problems isn't a good answer. Maybe that was a 4/1 too though. If so, good work. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 22:32:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3AD106564A; Fri, 2 Apr 2010 22:32:12 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id BD4358FC08; Fri, 2 Apr 2010 22:32:11 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o32MW8oc000508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Apr 2010 09:32:09 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o32MW27M039461; Sat, 3 Apr 2010 09:32:02 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o32MW2fw039460; Sat, 3 Apr 2010 09:32:02 +1100 (EST) (envelope-from peter) Date: Sat, 3 Apr 2010 09:32:02 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20100402223202.GD86236@server.vk2pj.dyndns.org> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> <4BB5CAA7.5030108@stillbilde.net> <20100402121526.GA64746@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pZs/OQEoSSbxGlYw" Content-Disposition: inline In-Reply-To: <20100402121526.GA64746@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-CMAE-Score: 0 Cc: freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 22:32:12 -0000 --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Firstly, congratualtions to doubg@. On 2010-Apr-02 05:15:26 -0700, Jeremy Chadwick w= rote: >1) In most scenarios (historically speaking), what gets updated quicker: >base or ports? Answer: ports. In some ways this is a problem. On the downside, it means that a -RELEASE will never have bleeding edge features. On the upside, it means that a -RELEASE will never have bleeding edge bugs. >2) What has proper infrastructure for dependencies and tracking of >installed files as part of a software package? Answer: ports. I agree that this is a deficiency in the base system. I have often wished that there was some way of tracking exactly what part of installworld had installed what file - but I accept that this is a "difficult" problem. It might be useful if there was a target as part of install{world,kernel} that built a mtree database of what was installed. >3) How often do you see people posting problems with key pieces of >FreeBSD infrastructure (device support/reliability or storage-related >subsystems), followed by a response from a developer stating "this has >been fixed in -STABLE" or "can you try the code from HEAD?" Answer: >often. That's true of any non-trivial piece of software that has distinct "developer" and "end-user" branches. Moving to ports won't really resolve the problem - the answer will still be "you need to update to a newer version of that code". Whilst I'd occasionally like to see less "bloat" (ie anything that I don't use) in base, there is one significant benefit that I don't recall seeing discussed in this thread - integration testing. The base system it built and tested as a whole. This isn't practical for the ports system. Without the integration testing, you wind up in the situation where port A and port B work in isolation but don't work together - the port A maintainer says that the problem is port B and the port B maintainer says that port A is relying on an optional part of port B that they don't have the time/interest/expertise to maintain. --=20 Peter Jeremy --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku2cGIACgkQ/opHv/APuIeMgQCggvdT7V76Zm2JuS/1z31DB6HK WG0An35J/TIm1aiTSJCzOx3GpPC6yhxM =gusw -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 03:57:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6DF1065673; Sat, 3 Apr 2010 03:57:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id B810A8FC12; Sat, 3 Apr 2010 03:57:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o333vIQW064868; Sat, 3 Apr 2010 14:57:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Apr 2010 14:57:18 +1100 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> Message-ID: <20100403143804.M35463@sola.nimnet.asn.au> References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 03:57:21 -0000 On Fri, 2 Apr 2010, Doug Barton wrote: > So first of all, yes Virginia, this was an April Fool's Day joke. To > both those for whom this post created a false sense of despair, and > (perhaps more importantly) to those for whom it created a false sense of > joy, my apologies. :) And for the record, everything from here on is > "just the facts." You're a proper bastard, Doug - in the strictly affectionate Aussie sense of the term. Talk about stirring the possum! Had me fired up to figure out how to add a choice menu to sysinstall .. Good to hear the DNSSEC stuff is coming along, however ponderously. KUTGW, Ian From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 06:54:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F88F106564A; Sat, 3 Apr 2010 06:54:49 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id A7A1D8FC08; Sat, 3 Apr 2010 06:54:48 +0000 (UTC) Received: by qyk11 with SMTP id 11so2676644qyk.13 for ; Fri, 02 Apr 2010 23:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=ulJG/R22WjaY0f5rjSU15JsA2bUEeuaKjpX99z4/ZAg=; b=Pta3Dklre2x8oFIWDzEEhYR3+ZxZ+ZKUW+G0gi1C3C7oxnZRypElO/6mUXObQ0N8q9 SFpdZV/NqAxIulNFmgj2OQqwwHrBQf55T0q17+dHIxb7Fv+pZHnZo36K/yVjbTSm5QRT jLgPu760rZe78kZe+nKaoLAysIpIEg2Lp35tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=azEpEqvkmnJcy9PODwjpqCE8fLA6TdTW5bNBQ4uzQaQrT8h6ZIfFdaPuSqD7iZQAdi ThTeIfBPPtB6vUf/dXor74V0nuXPPf3A6+ANKEAMV03ZimuagUzY+3zXlxAU74yLVkpo rbWTUUZeiFvT2/Xokfjamhmbhq+/6qOdTXUVM= Received: by 10.224.55.65 with SMTP id t1mr1029004qag.313.1270277687954; Fri, 02 Apr 2010 23:54:47 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.33]) by mx.google.com with ESMTPS id 6sm10714940qwd.27.2010.04.02.23.54.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 23:54:46 -0700 (PDT) From: Arseny Nasokin To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> X-Mailer: iPhone Mail (7D11) References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> Message-Id: <741A5195-385B-42A1-90FE-3B6EBC6956A3@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 10:54:44 +0400 Cc: "freebsd-current@FreeBSD.org" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 06:54:49 -0000 On 2 Apr 2010, at 23:07, Doug Barton wrote: > > Therefore I think that the status quo of having it all in there, and > knobs to turn off the bits you don't want is a good one since it seems > to please the majority of our users. I will continue to maintain the > bind-tools port though, that's something that's been requested often, > and I think it's a good thing to have for those who want a different > DNS > solution but still want access to those tools in a fairly painless > manner. And of course the ability to easily change/upgrade/manage what > version of BIND you use via the ports will continue to be a key > component of how we deal with this going forward. > > Of course, the release synchronization problems I described in both > the > original post and the AFD post are real, so stay tuned. :) > Some about BIND and XML support via port. As I know, world is enough to build everything in it, but support build something in world, which depends on some port is not good idea. Yes, it useful option, but I think it should be in port(which has much more flexibility), not in world. > > 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/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 > 788AoPf53oxsgutXPriuLOszcp2DBKc1 > =hUnq > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 07:08:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82EEF106566B; Sat, 3 Apr 2010 07:08:43 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDDF8FC37; Sat, 3 Apr 2010 07:08:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so914054qwe.7 for ; Sat, 03 Apr 2010 00:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=0/zXFXIwFGd/89S946cC8du1WDsVaxpLCMP44n3djfg=; b=FM3lONotc0ScvWRqCYXr4EyoS1H0pPQAPROzqTETEEjG6EwiLsnNH5ofuxVO3kp7KK upbCO9nclJbFuJnMwO5zZ/WIGU3/lDyKYfUMBxX0ZG5vukRQBFk2rj6dTCKyc1eD5qbg tryHC0IKk1x9CVyAry8DKi6JFem609M2Yk58o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=dtmRjvNZGfDJaZzX5Q6HzYT0Gi/ksOGch/eDTtkIAqBh4kVM7pAmfIkGvTYF6R0z3Y wK+aNqACMK5/LYh1tdN8TQYs3IroRIGnE/dKEuf0xlp8J/+RgG6Cdr9qFaJU/QLAHjTV 3hm5igiuXI+tSF1e75D8TjKJWk13mtS9qYaiI= Received: by 10.224.71.130 with SMTP id h2mr1025528qaj.246.1270276966765; Fri, 02 Apr 2010 23:42:46 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.40]) by mx.google.com with ESMTPS id 7sm901679qwf.44.2010.04.02.23.42.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 23:42:45 -0700 (PDT) From: Arseny Nasokin To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> X-Mailer: iPhone Mail (7D11) References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> Message-Id: <22D22D6D-8976-4EBD-9351-965A33544013@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 10:42:40 +0400 Cc: "freebsd-current@FreeBSD.org" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 07:08:43 -0000 On 2 Apr 2010, at 23:07, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > So first of all, yes Virginia, this was an April Fool's Day joke. To > both those for whom this post created a false sense of despair, and > (perhaps more importantly) to those for whom it created a false > sense of > joy, my apologies. :) And for the record, everything from here on is > "just the facts." > > I have always said that I will remove BIND from the base when there is > clear community consensus to do so, and I stand by that. However the > discussion always seems to go along the lines that this thread did. A > vocal group who say, "YES!" and then a lot of people who want the > resolution tools (dig, host, nslookup) to stay, and the other end of > the > bell-shaped curve with those who like having the whole thing in the > base. Toss in a few choruses of "The whole base should be more > modular," > (a viewpoint with which I have a great deal of sympathy btw) and the > soup is pretty well complete. > > In regard to the tools issue, the problem is that you need a pretty > good > majority of the code in order to build them. They require the > libraries > to be built, and once you've done that, you might as well do the > rest. :) > > Total size of code in: > contrib/bind9: 14.0M > contrib/bind9/lib: 7.6M > contrib/bind9/bin: 2.5M > contrib/bind9/bin/dig: 0.4M > > The last is the directory that has the code for all 3 resolution > tools, > FYI. > > Therefore I think that the status quo of having it all in there, and > knobs to turn off the bits you don't want is a good one since it seems > to please the majority of our users. I will continue to maintain the > bind-tools port though, that's something that's been requested often, > and I think it's a good thing to have for those who want a different > DNS > solution but still want access to those tools in a fairly painless > manner. And of course the ability to easily change/upgrade/manage what > version of BIND you use via the ports will continue to be a key > component of how we deal with this going forward. > > Of course, the release synchronization problems I described in both > the > original post and the AFD post are real, so stay tuned. :) > > Answers to DNSSEC concerns below. > > On 4/2/2010 3:52 AM, Robert Watson wrote: >> With an eye on the date of Doug's suggestive e-mail, I actually am >> concerned >> that we maintain support for DNSSEC validation in the base system. >> If this >> can be accomplished by keeping DNS debugging tools and the >> lightweight >> resolver in the base, then I'm fine with that world view. However, >> if we >> can't do DNSSEC record validation without installing the BIND >> package, then >> that worries me. > > Unfortunately this answer is more complicated than I'd like it to > be. In > general, DNS resolution requires 4 components (and yes, this is pretty > well simplified, but I think the illustration serves to clarify my > point): > 1. An end-user application that makes a request > 2. A stub resolver located on the local system > 3. A resolving name server > 4. An authoritative name server > > At this time the DNSSEC protocol only clearly addresses the behavior > of > 4, and partially addresses the behavior of 3. There is no protocol > specification for 1 or 2. So in general if you want to be able to > validate DNSSEC signatures on the local system the only option > available > to you is to run a local validating resolver. It doesn't have to be > BIND, unbound is also a good candidate, but you have to run something > locally to be sure that the response(s) you've received are valid. > > Now that said, if you have a special purpose in mind to validate > records > in a specific domain (or specific few domains) for which you are > prepared to individually manage trust anchors (the generic term of art > for DNSSEC keys) then you could do that using dig alone. However that > solution would not scale well, and I wouldn't recommend it for a > critical piece of the base or ports. > >> As we go forward, DNSSEC is going to become increasingly important, >> and being >> unable to bootstrap a system will be a problem, and it will become an >> increasingly critical part of the security bootstrap process for >> networked >> systems. > > Since your description above is generic, I will generically agree with > you. :) I think as time goes on and more intelligence about DNSSEC is > pushed to the edges I think it will be possible to have a validating > stub resolver, and on a trusted network reasonable to rely on an > external validating resolving name server. However there's an awful > lot > of supposition there, and as I said above, the spec doesn't even exist > yet, never mind the code. > >> While some DNSSEC folk consider it anathema ("DNS is not a directory >> service!"), the ability to securely distribute keying material via >> an existing >> network service has enourmous value: for example, early DNSSEC >> prototypes in >> the late 1990's/early 2000's included SSH key distribution via cert >> records in >> DNSSEC. > > The CERT record still exists, although not for ssh. See > http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the > SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always > TXT records. :) > > Now all THAT said, there is an element of DNSSEC that I am rather > strongly leaning toward putting in the ports, trust anchor > configuration. Currently you have essentially 2 choices for DNSSEC > validation, manually configure trust anchors, or use a DNS Lookaside > Validation (DLV) service, of which the most popular is ISC's. Both > options have their benefits and their drawbacks, which are outside the > scope of this post. OTOH, if things continue going according to plan > the > root zone will be signed with real DNSSEC keys in July. That will make > it possible to do "regular" DNSSEC validation for those zones that are > signed from the root down by only configuring one trust anchor, the > root > zone key. (If you need to validate something on a "secure island," > i.e., > one or more parent zones is not signed, you are back to the first 2 > choices, but once again, out of scope.) > > In the ideal world the root zone trust anchor would function like the > root.hints file does now. It is stable (not updated often) and failure > to update it in a timely manner would not be catastrophic. > Unfortunately, the first is not guaranteed, and the latter is the > opposite of the truth. There has already been on incident where an OS > distribution had shipped with trust anchors manually configured and > when > they became outdated hilarity ensued. I would like to avoid that for > our > users. > > At this time my plan is to add hooks for "easy" incorporation of > DNSSEC > validation into the base named.conf, with instructions for how to > install the port/package, the importance of keeping it up to date, > etc. > Before I make any changes I'll be seeking input from experts in the > DNSSEC community and posting something a little more focused on - > arch at > least. If the release engineer or security officer teams have > "something" in mind for FreeBSD that will require DNSSEC, we'll have > to > coordinate efforts on this, but I don't imagine it will be too > difficult > even with a bind-dnssec-config port. > > > 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/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 > 788AoPf53oxsgutXPriuLOszcp2DBKc1 > =hUnq > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 12:51:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 066BE1065672; Sat, 3 Apr 2010 12:51:47 +0000 (UTC) (envelope-from masoom.shaikh@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 B1FD18FC08; Sat, 3 Apr 2010 12:51:46 +0000 (UTC) Received: by pwi9 with SMTP id 9so2319611pwi.13 for ; Sat, 03 Apr 2010 05:51:46 -0700 (PDT) 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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Iw3dPn9RiOXpeB/CBropiE0tCOkCrt36kbNfUr6LRzw=; b=oB3vor3SCV0xjYVxdtFmb+67kutRuh1IlB3Gqd0ByTaT39GcxVj9tLOFblcopMlPOe HftM7x6ol8WSc9fvyGCCcPsxEUzIhwGNNrnrmRAM/AQYLqaBc99cU8VJD5aU9VYezxM+ 9XqfhGq9s0Z/21EhWWwyh7Vs+wCj1iqI6o37U= 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=CaYbUpSERD0sreKwIDDVupRfy696pdTwWhBJRzEVjBXi87yi+//Dipf6WfK3fB0CpX GLWV2DjWZQFh0A0ILl5iAW3AKZ4+8o9ZAXh1XXFTNFAC1na/f1BO6Ks+tvZJvYrTCjta 9Ukq8jkzTBUl0h2rj5LvuJwoG+Fiuex+TzTZ8= MIME-Version: 1.0 Received: by 10.114.137.14 with HTTP; Sat, 3 Apr 2010 05:51:46 -0700 (PDT) In-Reply-To: <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> Date: Sat, 3 Apr 2010 12:51:46 +0000 Received: by 10.115.133.39 with SMTP id k39mr3184921wan.198.1270299106089; Sat, 03 Apr 2010 05:51:46 -0700 (PDT) Message-ID: From: Masoom Shaikh To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 12:51:47 -0000 On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > On 28 March 2010 16:42, Masoom Shaikh wrote: > >> lets assume if this is h/w problem, then how can other OSes overcome >> this ? is there a way to make FreeBSD ignore this as well, let it >> result in reasonable performance penalty. > > Very probably, if only we could detect where the problem is. > Try adding "options =A0 =A0 PRINTF_BUFR_SIZE=3D128" to the kernel > configuration file if you can, to see if you can get a less mangled > log outout. > ok, after few days of silence I am back with more questions this time system feels little better, it is able to sustain for more time that what 7.3-RELEASE could FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 I am using KDE4, and when OS freezes, well it freezes, means I cannot change to tty0 and see the panic text, if any it might possibly have spit. the stuck frozen GUI keeps staring there. So the question is how to I capture that panic text ? unfortunately I am not getting core files too, so there is nothing I can pick up hints is there some option (KDB, DDB), so that on panic system drop to debugger ? Masoom Shaikh From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 13:54:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493D11065674 for ; Sat, 3 Apr 2010 13:54:24 +0000 (UTC) (envelope-from bsd@nezmer.info) Received: from mail.nezmer.info (nezmer.info [97.107.142.36]) by mx1.freebsd.org (Postfix) with ESMTP id 28E088FC16 for ; Sat, 3 Apr 2010 13:54:23 +0000 (UTC) Date: Sat, 3 Apr 2010 16:54:13 +0300 From: Nezmer To: freebsd-stable@freebsd.org Message-ID: <20100403135413.GA2713@mail> References: <20100325193127.GA80926@mail> <20100326071106.GB32799@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100326071106.GB32799@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 8-STABLE/amd64: kernel panic after a minute of mounting xfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 13:54:24 -0000 On Fri, Mar 26, 2010 at 06:11:06PM +1100, Peter Jeremy wrote: > On 2010-Mar-25 21:32:10 +0200, Nezmer wrote: > >This is the 1st time FreeBSD panics on me. It happened after a > >minute of mounting an XFS partition. I'm not sure It's XFS but It's the > >only part of the OS I try for the 1st time. > > > >kernel: vn_iowait doing nothing on FreeBSD? > > This is part of XFS. I'm not sure how important it is. > > >kernel: Fatal trap 12: page fault while in kernel mode > ... > >kernel: Cannot dump. Device not defined or unavailable. > > Unfortunately, there's not much that can be done given this > information. As a minimum, you need a backtrace. Ideally, you need a > core-dump to investigate the cause. > > See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > -- > Peter Jeremy I got a chance to get a backtrace with revision 206096 today. You can find it with relevant source files here(1). I hope It's enough. (1) https://nezmer.info/public/xfs_report.tar.gz From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 13:57:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483451065674; Sat, 3 Apr 2010 13:57:12 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id C66B38FC1C; Sat, 3 Apr 2010 13:57:11 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o33Dv3kY063317; Sat, 3 Apr 2010 15:57:04 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o33Dv3OW063316; Sat, 3 Apr 2010 15:57:03 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Sat, 3 Apr 2010 15:57:03 +0200 From: Ruben de Groot To: Charles Sprickman Message-ID: <20100403135703.GA63262@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Charles Sprickman , Reko Turja , "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 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 ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Sat, 03 Apr 2010 15:57:08 +0200 (CEST) Cc: Reko Turja , "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 13:57:12 -0000 On Fri, Apr 02, 2010 at 02:08:27PM -0400, Charles Sprickman typed: > Can we do sendmail next April 1? Better yet, defer all questions about moving out of the base system by referring to the Grand Discussion that'll take place *next year* on the first of april. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 14:35:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017611065673; Sat, 3 Apr 2010 14:35:26 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 880968FC15; Sat, 3 Apr 2010 14:35:25 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #3) id 1Ny4RY-0007T1-5y; Sat, 03 Apr 2010 16:35:24 +0200 Received: from p57ae1cdc.dip0.t-ipconnect.de ([87.174.28.220]:54437 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #3) id 1Ny4RX-0001Xs-Tn; Sat, 03 Apr 2010 16:35:24 +0200 Date: Sat, 3 Apr 2010 16:35:23 +0200 From: Gary Jennejohn To: Masoom Shaikh Message-ID: <20100403163523.7d5658f2@ernst.jennejohn.org> In-Reply-To: References: <9bbcef731003280503q4993e5b4ud8d874b8e9c376a9@mail.gmail.com> <9bbcef731003281038x33b8a9atc2a81d22aa26468@mail.gmail.com> 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, freebsd-stable@freebsd.org Subject: Re: random FreeBSD panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 14:35:26 -0000 On Sat, 3 Apr 2010 12:51:46 +0000 Masoom Shaikh wrote: > On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras wrote: > > On 28 March 2010 16:42, Masoom Shaikh wrote: > > > >> lets assume if this is h/w problem, then how can other OSes overcome > >> this ? is there a way to make FreeBSD ignore this as well, let it > >> result in reasonable performance penalty. > > > > Very probably, if only we could detect where the problem is. > > Try adding "options __ __ PRINTF_BUFR_SIZE=128" to the kernel > > configuration file if you can, to see if you can get a less mangled > > log outout. > > > > ok, after few days of silence I am back with more questions > this time system feels little better, it is able to sustain for more > time that what 7.3-RELEASE could > > FreeBSD raptor 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Thu Apr 1 > 01:20:45 UTC 2010 root@:/usr/obj/usr/src/sys/INSPIRON amd64 > > I am using KDE4, and when OS freezes, well it freezes, means I cannot > change to tty0 and see the panic text, if any it might possibly have > spit. the stuck frozen GUI keeps staring there. So the question is how > to I capture that panic text ? unfortunately I am not getting core > files too, so there is nothing I can pick up hints > > is there some option (KDB, DDB), so that on panic system drop to debugger ? > [trimmed Cc - no need to send this to 3 MLs] There's no code in the kernel to switch back out of graphics mode (i.e. what X uses) when a panic happens. You probably can switch to v0, but you won't be able to see it. The only sure-fire way is to hook up a screen (terminal, laptop or another computer) to a serial port. -- Gary Jennejohn From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 20:48:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0528F1065673 for ; Sat, 3 Apr 2010 20:48:51 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id AAC8E8FC0A for ; Sat, 3 Apr 2010 20:48:50 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so1032956qwe.7 for ; Sat, 03 Apr 2010 13:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=kzPbhMu6NglPFz+KdHZeLstt+hSzXBVNROIllF1RoQg=; b=sAOjGftRPcSdMlgbdTDO5IBwT/0K7eCL6TF/c/FnUgrU7+CV6bTtsQ6LTmzuWcixCb uruBCGtp7JqWKlkO7NaYKpYML3gl7tP8XZ3QTfUX4XsRiJKE7lVIcAKO1Gl3sGnrFe7P oMnCxjC5Mj0t0saM6gn4sQO1r+tIaH7r2KRb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; b=A+63dpg12CrYWbxn5RkFmNMVce6IUixYvmwhrvxjY+bRlgkBT9uic9gFC1tJX06OMX hzyFWj4vWenr6Ghm6pZOe2eprQdcVhdsitD2jz0FLGg8DXy7o1lijXCo/zXWsCQxX2od M5q9mQqYj230Hjn1VjiN90kWQzkrT/Fwq+azs= Received: by 10.229.217.206 with SMTP id hn14mr5945553qcb.70.1270327729516; Sat, 03 Apr 2010 13:48:49 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.112.4]) by mx.google.com with ESMTPS id w30sm2870752qce.16.2010.04.03.13.48.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 13:48:48 -0700 (PDT) Sender: Nenhum_de_Nos Received: from elita (unknown [10.1.1.84]) by cygnus.homeunix.com (Postfix) with ESMTP id 07632B8A1D for ; Sat, 3 Apr 2010 17:48:37 -0300 (BRT) Date: Sat, 3 Apr 2010 17:48:12 -0300 From: Nenhum_de_Nos To: freebsd-stable@freebsd.org Message-Id: <20100403174812.59c40c99.matheus@eternamente.info> X-Mailer: Sylpheed 3.0.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: install touching mbr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 20:48:51 -0000 hail, I just installed a 8.0R amd64 from memstick. when asked, I said to leave mbr untouched. when I rebooted, it was freebsd bootloader that was on control. this options is not what I think it should, or there is really a issue here ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 20:58:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627E0106566C for ; Sat, 3 Apr 2010 20:58:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0EE8FC0C for ; Sat, 3 Apr 2010 20:58:57 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 18n61e0061eYJf8A58yyLU; Sat, 03 Apr 2010 20:58:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id 18yy1e0013S48mS018yyqr; Sat, 03 Apr 2010 20:58:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DB1009B419; Sat, 3 Apr 2010 13:58:56 -0700 (PDT) Date: Sat, 3 Apr 2010 13:58:56 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100403205856.GA20454@icarus.home.lan> References: <20100403174812.59c40c99.matheus@eternamente.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100403174812.59c40c99.matheus@eternamente.info> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: install touching mbr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 20:58:58 -0000 On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: > I just installed a 8.0R amd64 from memstick. when asked, I said to > leave mbr untouched. when I rebooted, it was freebsd bootloader that > was on control. this options is not what I think it should, or there > is really a issue here ? I can confirm this behaviour. Someone may have broken something when tinkering around in that part of sysinstall (since the Standard vs. BootMgr options were moved around compared to previous releases). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Apr 3 21:44:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 670B4106566C for ; Sat, 3 Apr 2010 21:44:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 21E268FC12 for ; Sat, 3 Apr 2010 21:44:50 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o33LioeL011953; Sat, 3 Apr 2010 15:44:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o33Liobf011950; Sat, 3 Apr 2010 15:44:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 3 Apr 2010 15:44:50 -0600 (MDT) From: Warren Block To: Jeremy Chadwick In-Reply-To: <20100403205856.GA20454@icarus.home.lan> Message-ID: References: <20100403174812.59c40c99.matheus@eternamente.info> <20100403205856.GA20454@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (wonkity.com [127.0.0.1]); Sat, 03 Apr 2010 15:44:50 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: install touching mbr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 21:44:51 -0000 On Sat, 3 Apr 2010, Jeremy Chadwick wrote: > On Sat, Apr 03, 2010 at 05:48:12PM -0300, Nenhum_de_Nos wrote: >> I just installed a 8.0R amd64 from memstick. when asked, I said to >> leave mbr untouched. when I rebooted, it was freebsd bootloader that >> was on control. this options is not what I think it should, or there >> is really a issue here ? > > I can confirm this behaviour. Someone may have broken something when > tinkering around in that part of sysinstall (since the Standard vs. > BootMgr options were moved around compared to previous releases). Not sure how to repeat the bug, but it's been there at least a few months: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0909262030060.13303 http://docs.freebsd.org/cgi/mid.cgi?58c737d70909262054k7c7b1402w4f9c902fdca2640c -Warren Block * Rapid City, South Dakota USA