From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 02:52:57 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74C7A322 for ; Sun, 8 Feb 2015 02:52:57 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id E2B98A6D for ; Sun, 8 Feb 2015 02:52:55 +0000 (UTC) Received: from ppp121-45-218-9.lns20.cbr1.internode.on.net (HELO bullseye.apana.org.au) ([121.45.218.9]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Feb 2015 13:22:48 +1030 Received: from [127.0.0.1] ([192.168.63.14]) by bullseye.apana.org.au (8.14.2/8.14.2) with ESMTP id t182qlpL081313 for ; Sun, 8 Feb 2015 13:52:47 +1100 (EST) (envelope-from andymac@bullseye.apana.org.au) Message-ID: <54D6CF7E.3000506@bullseye.apana.org.au> Date: Sun, 08 Feb 2015 13:52:46 +1100 From: Andrew MacIntyre User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Coding Structure and Documentation References: <54D64D07.5080509@acustat.org> In-Reply-To: <54D64D07.5080509@acustat.org> X-Antivirus: avast! (VPS 150205-1, 05/02/2015), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 02:52:57 -0000 On 8/02/2015 4:36 AM, Benjamin Adams wrote: > I'm going to be starting a new coding project that will be built on > FreeBSD. Before starting, I would like to review any coding > documentation on structure and layout of comments, spacing vs tabs, > etc. Or just go by the structure set by the language. > (http://legacy.python.org/dev/peps/pep-0008/) > > Language I will be coding in is Python. I will be building the > project on FreeBSD 11 with the idea of releasing it shortly after > FreeBSD 11 is moved to STABLE. As a Python user, I would advise sticking closely to PEP 8. > Lastly what version of Python will be the primary version on 11? Unless you need to rely on a Python package still only supported on Python 2, I would suggest that you use Python 3. The default version of Python for the Python 3 meta-port looks like it was recently changed to v3.4 which would be a good choice - even if v3.5 is released and adopted as the default for the Python 3 meta-port by the time FreeBSD 11 is released, forward compatibility from 3.4 to 3.5 should be very good. Python 3.4 is already in wide use and therefore could be expected to be supported by the Python developers for some time after 3.5's release. You may find https://wiki.python.org/moin/Python2orPython3 helpful on the Python 2 vs Python 3 issue. Regards, Andrew. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail:andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web:http://www.andymac.org/ | Australia --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 04:28:37 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63FC5DAC for ; Sun, 8 Feb 2015 04:28:37 +0000 (UTC) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id E428E335 for ; Sun, 8 Feb 2015 04:28:36 +0000 (UTC) Received: from ppp118-210-197-72.lns20.adl6.internode.on.net (HELO midget.dons.net.au) ([118.210.197.72]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Feb 2015 14:58:33 +1030 Received: from auxxoconnd1m1.dons.net.au (AUXXOCONND1M1.dons.net.au [10.0.2.104]) (authenticated bits=0) by midget.dons.net.au (8.15.1/8.14.9) with ESMTPSA id t184STdb054140 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2015 14:58:31 +1030 (CST) (envelope-from darius@dons.net.au) Subject: Re: Two drivers sharing a single PCI device Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: "O'Connor, Daniel" In-Reply-To: <54D5AB87.9050309@selasky.org> Date: Sun, 8 Feb 2015 14:58:28 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <643918BB-810C-4FB2-AE1A-C4CDA6C8A661@dons.net.au> <54D4ABA6.805@selasky.org> <54D5AB87.9050309@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2070.6) X-Spam-Score: -2.909 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD,URIBL_BLOCKED X-Scanned-By: MIMEDefang 2.75 on 10.0.2.1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 04:28:37 -0000 > On 7 Feb 2015, at 16:37, Hans Petter Selasky wrote: >>> You possibly want "D_TRACKCLOSE" in d_flags in your cdevsw. >>=20 >>> What's the advantage of using the debug port over the regular EHCI = USB interface? >>=20 >> I don't think that would help. It is supposed to be (largely) = separate from the regular EHCI controller - it has it's own register set = and it can steal the debug port from the regular controller so it = doesn't appear occupied (although there is a bit of messing around on = port reset). >>=20 >> The advantage is that it runs separately to the EHCI interface and it = is quite simple to talk to, there is more information in appendix C of = the USB 2 spec (usb_20.pdf). >>=20 >=20 > Hi, >=20 > You know about "sys/boot/usb" ? If you could integrate the USB debug = port to use the kernel USB stack HOST API, only limited to BULK, CONTROL = and INTERRUPT, then we could easily use it there aswell. The EHCI debug = port functions very much resemble those found in = "sys/dev/usb/controller/dwc_otg*" for example. Hmm I am not really sure what it's for.. Is it for the loader? Basically I would like to be able to run a console and GDB port over = USB, although I think it won't be quite as good as a 'real' serial one = because it will have to start later (when the PCI bus is up). FWIW I did get my driver and EHCI to attach at the same time - I = iterated over pci_devq and allocated my own softc in MOD_LOAD. The next = part is trying to get the EHCI controller from stealing back the debug = port - it gets lost on reset I think so I need to work out how to tell = it not to touch it (if possible). -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 8 16:17:08 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31C7F821 for ; Sun, 8 Feb 2015 16:17:08 +0000 (UTC) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5670ACA for ; Sun, 8 Feb 2015 16:17:07 +0000 (UTC) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 249803803C0; Sun, 8 Feb 2015 11:10:48 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp12.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1F3F53803BB; Sun, 8 Feb 2015 11:10:48 -0500 (EST) Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: ben-AT-acustat.org) with ESMTPSA id A578A3803C0; Sun, 8 Feb 2015 11:10:47 -0500 (EST) X-Sender-Id: ben@acustat.org Received: from [192.168.1.99] (cpe-72-225-8-217.rochester.res.rr.com [72.225.8.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Sun, 08 Feb 2015 16:10:48 GMT Message-ID: <54D78A87.2030207@acustat.org> Date: Sun, 08 Feb 2015 11:10:47 -0500 From: Benjamin Adams User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrew MacIntyre , freebsd-hackers@freebsd.org Subject: Re: Coding Structure and Documentation References: <54D64D07.5080509@acustat.org> <54D6CF7E.3000506@bullseye.apana.org.au> In-Reply-To: <54D6CF7E.3000506@bullseye.apana.org.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 16:17:08 -0000 Andrew, Thank you for the reply. I will code in 3.4, for the past few years I have been using 2.7 but will start using the new version. I see 2.x will be supported until 2020, So 3.4 is the way to go. Next year when this I expect to release this. I will be converting it to ports and can maintain it. Next year because I will be coding in my free time and want to have something stable before sending it out to the BSD world. Thanks for the emails. Ben On 02/07/2015 21:52, Andrew MacIntyre wrote: > On 8/02/2015 4:36 AM, Benjamin Adams wrote: >> I'm going to be starting a new coding project that will be built on >> FreeBSD. Before starting, I would like to review any coding >> documentation on structure and layout of comments, spacing vs tabs, >> etc. Or just go by the structure set by the language. >> (http://legacy.python.org/dev/peps/pep-0008/) >> >> Language I will be coding in is Python. I will be building the >> project on FreeBSD 11 with the idea of releasing it shortly after >> FreeBSD 11 is moved to STABLE. > > As a Python user, I would advise sticking closely to PEP 8. > >> Lastly what version of Python will be the primary version on 11? > > Unless you need to rely on a Python package still only supported on > Python 2, I would suggest that you use Python 3. The default version > of Python for the Python 3 meta-port looks like it was recently > changed to v3.4 which would be a good choice - even if v3.5 is > released and adopted as the default for the Python 3 meta-port by the > time FreeBSD 11 is released, forward compatibility from 3.4 to 3.5 > should be very good. Python 3.4 is already in wide use and therefore > could be expected to be supported by the Python developers for some > time after 3.5's release. > > You may find https://wiki.python.org/moin/Python2orPython3 helpful on > the Python 2 vs Python 3 issue. > > Regards, > Andrew. > > ------------------------------------------------------------------------- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail:andymac@bullseye.apana.org.au > > (pref) | Snail: PO Box 370 > andymac@pcug.org.au > > (alt) | Belconnen ACT 2616 > Web:http://www.andymac.org/ | Australia > > > > > --- > This email has been checked for viruses by Avast antivirus software. > http://www.avast.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" -- --------------- Ben Adams - AcuStat From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 09:26:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0511AFF for ; Mon, 9 Feb 2015 09:26:25 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4642232B for ; Mon, 9 Feb 2015 09:26:24 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t199IZdm073360 for ; Mon, 9 Feb 2015 10:18:36 +0100 (CET) (envelope-from wojtek@puchar.net) Date: Mon, 9 Feb 2015 10:18:34 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: FreeBSD/MIPS32: __sync_sub_and_fetch_4 Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 09 Feb 2015 10:18:36 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 09:26:25 -0000 i'm getting undefined reference from some programs compiled on MIPS under FreeBSD/10 where can i find this procedures? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 14:23:26 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D550728E for ; Mon, 9 Feb 2015 14:23:26 +0000 (UTC) Received: from mail.myota.org (mail.myota.org [85.10.206.105]) by mx1.freebsd.org (Postfix) with ESMTP id 65602930 for ; Mon, 9 Feb 2015 14:23:25 +0000 (UTC) Received: from mobile.client (187stb36.codetel.net.do [64.32.117.187]) (authenticated bits=128) by mail.myota.org (8.14.9/8.14.9) with ESMTP id t19EN0hv009227; Mon, 9 Feb 2015 15:23:08 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: from submit.client ([127.0.0.1]) by schlappy.local (8.14.9/8.14.9) with ESMTP id t19EMgWC008768; Mon, 9 Feb 2015 15:22:43 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Received: (from user@localhost) by schlappy.local (8.14.9/8.14.9/Submit) id t19EMgPR008767; Mon, 9 Feb 2015 15:22:42 +0100 (CET) (envelope-from andre@fbsd.ata.myota.org) Date: Mon, 9 Feb 2015 15:22:42 +0100 From: Andre Albsmeier To: freebsd-hackers@freebsd.org Subject: [unionfs] deadlocking a 9-STABLE machine with two unionfs mounts onto the same mountpoint Message-ID: <20150209142242.GA8734@schlappy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Echelon: V, RSA, Telex, Sears, SWAT X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Not delayed on 85.10.206.105, ACL: AUTH(59), Origin: DO, OS: FreeBSD 9.x or newer X-Virus-Scanned: clamav-milter 0.98.6 at colo X-Virus-Status: Clean Cc: andre@fbsd.ata.myota.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:23:26 -0000 Retrying here as -fs didn't show up any results... ----- Forwarded message ----- I can reliably deadlock a 9.3-STABLE by the following procedure: Let's assume that /tmp is a standard swap-backed file system already. First let's set up what we need: mkdir /tmp/1 /tmp/2 mount -v -t unionfs /tmp/1 /usr/local mount -v -t unionfs /tmp/2 /usr/local No let's lock the system: mkdir /tmp/2/bla while :; do echo go tar -cC /usr/src/etc -f - . | tar -xpC /tmp/2/bla -f - done It survives about 3 or 4 rounds, sometimes more, sometimes only 2. It is important to use tar to copy the stuff. If we replace the tar line by e.g. cp -pR /usr/src/etc/* /tmp/2/bla things are all well. The system doesn't lock up entirely, you can move the mouse and ping it but no fs access is possible anymore. One can switch to the console and enter the debugger but a reboot with ctrl-alt-del doesn't work... The interesting part is that all this worked pretty well on 9-STABLE until approx. 2 months ago. But nothing had been committed to unionfs for a long time so I really have no idea what's going on. It also reminds us of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161511 but this stuff had been merged to 9-STABLE already... Anything I can do to get this fixed? ----- End forwarded message ----- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 14:38:03 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836B95C5 for ; Mon, 9 Feb 2015 14:38:03 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03695A89 for ; Mon, 9 Feb 2015 14:38:03 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id n10so2968346lbv.4 for ; Mon, 09 Feb 2015 06:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cVLjAtTYXZwBfF7tErVdhXF1WZMILk6dYp30pgF4rfw=; b=Omw+21X5oBWW7dZCP7RkIlTbhucNDbmopb5zfaIyEroyCb4JQ0/lkUsrkXvb3TI4cG opctei1xVBeqdBZxXg/9Peb5EQXaFdIo+gjN58VCG/APYeaoJK6mkd9CtNud79l6U9bE LNs4l3oH6z2+u7X8Aqt1e7pcdZkjbFOEqQcoOwK1bOdUPymgPrFj1kY1DfxzZGs0O2RX dsuysRSJ1gx3IXUcVXu/OEvvdngrsUTkkU0ByscPGWT7o7pfx3OZarw1iBeU5eS10KYz mYbm06XFkaGScBilC/aw3a9KXp47EnHvK27RglLjZoXHEv7JizPian7rJzUdutR7yUkj sd+A== MIME-Version: 1.0 X-Received: by 10.112.37.197 with SMTP id a5mr17584363lbk.19.1423492680786; Mon, 09 Feb 2015 06:38:00 -0800 (PST) Received: by 10.152.45.65 with HTTP; Mon, 9 Feb 2015 06:38:00 -0800 (PST) In-Reply-To: <20150209142242.GA8734@schlappy> References: <20150209142242.GA8734@schlappy> Date: Mon, 9 Feb 2015 16:38:00 +0200 Message-ID: Subject: Re: [unionfs] deadlocking a 9-STABLE machine with two unionfs mounts onto the same mountpoint From: Alexander Yerenkow To: Andre Albsmeier Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:38:03 -0000 2015-02-09 16:22 GMT+02:00 Andre Albsmeier : > Retrying here as -fs didn't show up any results... > > ----- Forwarded message ----- > > I can reliably deadlock a 9.3-STABLE by the following procedure: > > Let's assume that /tmp is a standard swap-backed file system > already. First let's set up what we need: > > mkdir /tmp/1 /tmp/2 > mount -v -t unionfs /tmp/1 /usr/local > mount -v -t unionfs /tmp/2 /usr/local > Few years ago case was even simplier mkdir /tmp/1 mount -v -t unionfs /tmp/1 /usr/local #yep, just twice mount mount -v -t unionfs /tmp/1 /usr/local ls /tmp/1 #and the shell hangs. > > No let's lock the system: > > mkdir /tmp/2/bla > while :; do > echo go > tar -cC /usr/src/etc -f - . | tar -xpC /tmp/2/bla -f - > done > > It survives about 3 or 4 rounds, sometimes more, sometimes > only 2. It is important to use tar to copy the stuff. If > we replace the tar line by e.g. > > cp -pR /usr/src/etc/* /tmp/2/bla > > things are all well. > > The system doesn't lock up entirely, you can move the mouse > and ping it but no fs access is possible anymore. One can > switch to the console and enter the debugger but a reboot > with ctrl-alt-del doesn't work... > > The interesting part is that all this worked pretty well on > 9-STABLE until approx. 2 months ago. But nothing had been > committed to unionfs for a long time so I really have no > idea what's going on. > > It also reminds us of > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161511 > > but this stuff had been merged to 9-STABLE already... > > Anything I can do to get this fixed? > > ----- End forwarded message ----- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 15:19:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BC4B131 for ; Mon, 9 Feb 2015 15:19:20 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A6D7EEE for ; Mon, 9 Feb 2015 15:19:19 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 78ADD1941DD for ; Mon, 9 Feb 2015 15:19:12 +0000 (UTC) Message-ID: <54D8CFEF.2050002@ignoranthack.me> Date: Mon, 09 Feb 2015 07:19:11 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD/MIPS32: __sync_sub_and_fetch_4 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:19:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/09/15 01:18, Wojciech Puchar wrote: > i'm getting undefined reference from some programs compiled on > MIPS under FreeBSD/10 > > where can i find this procedures? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To > unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > Its not defined for mips. :-( Stacey Son had made a patch for a couple of ports, e.g. https://people.freebsd.org/~sson/mips/ports/graphics/cairo/files/patch-src_cairo-atomic-private.h Sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU2M/pXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5ks4kH+QHANrkMq7FlX9m5MbBDe7dU UZ6vQmnzHQZlUjI1AbtWNFuMQQCZ/ATGH7cTgNTBCA9HEupmpQC0nTB3xt3sLSq+ ww3sZLaX+XPJXuBIAhgxJUHLW/qHwA/ADq+1akEC7jy1qvciK23VueLKKmv/1GZa pxF9wGAqD1Wru72BPWtYla60Y5x+elTpmw6qJ0En5xyu4mrNOE9OwnzGUgtGlfIX 6iVk8DTA8rijolTjV62zJV+7aRUpOv/y/yQcrtmWE0bynZLNk9kdZMXZeJ/lc9OG D4GDFyHq5mknV1MHp4gLqlc8ogavrhExrXw2IL0YymZxt1nCH6ISKu+NhoJhN3o= =xp35 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 15:50:36 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78D3D77A for ; Mon, 9 Feb 2015 15:50:36 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0077.outbound.protection.outlook.com [65.55.169.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19DE727E for ; Mon, 9 Feb 2015 15:50:34 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 9 Feb 2015 15:50:26 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0075.002; Mon, 9 Feb 2015 15:50:26 +0000 From: "Pokala, Ravi" To: Ryan Stone Subject: Re: Changing the MTU on a lagg device Thread-Topic: Changing the MTU on a lagg device Thread-Index: AQHQQn+0qPs6AFh2xkSO1q7r/b61upzkzTgAgAMn5QA= Date: Mon, 9 Feb 2015 15:50:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0942; x-forefront-prvs: 04825EA361 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377424004)(13464003)(92566002)(122556002)(110136001)(40100003)(2950100001)(86362001)(99286002)(83506001)(106116001)(2900100001)(46102003)(77156002)(62966003)(66066001)(76176999)(50986999)(2656002)(19580405001)(87936001)(102836002)(36756003)(19580395003)(54356999)(1411001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2015 15:50:25.0622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0942 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:50:36 -0000 -----Original Message----- From: Ryan Stone Date: 2015-02-06, Friday at 23:38 To: Ravi Pokala Cc: "freebsd-hackers@freebsd.org" Subject: Re: Changing the MTU on a lagg device >I have a similar patch internally. As best that I can tell, the author >of the code didn't want to go to the effort of implementing the error >cases on the MTU change, and thought that it was better to explicitly >error out if somebody tried to change the MTU rather than causing random >unexpected behaviour. You can put me (rstone@) as a reviewer in >phabricator if you need your patch reviewed. I'm not sure I have phabricator access. If / when it comes to that, I'll be sure to put you down as a reviewer. Thanks Ryan! -Ravi From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 16:10:11 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CB388A; Mon, 9 Feb 2015 16:10:11 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0085.outbound.protection.outlook.com [157.56.111.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5133C751; Mon, 9 Feb 2015 16:10:10 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 9 Feb 2015 16:10:02 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0075.002; Mon, 9 Feb 2015 16:10:02 +0000 From: "Pokala, Ravi" To: Navdeep Parhar Subject: Re: Changing the MTU on a lagg device Thread-Topic: Changing the MTU on a lagg device Thread-Index: AQHQQn+0qPs6AFh2xkSO1q7r/b61upzko7MA//9+dwCAAT+aAIACmNSA Date: Mon, 9 Feb 2015 16:10:01 +0000 Message-ID: References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> In-Reply-To: <20150207163028.GA4965@ox> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0942; x-forefront-prvs: 04825EA361 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(13464003)(377424004)(24454002)(164054003)(51704005)(2656002)(50986999)(19580405001)(66066001)(62966003)(76176999)(93886004)(36756003)(19580395003)(54356999)(87936001)(102836002)(86362001)(2950100001)(40100003)(110136001)(92566002)(122556002)(106116001)(77156002)(2900100001)(46102003)(99286002)(83506001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <542D39F19E912548A87CABE049EA9B71@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2015 16:10:01.8263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0942 Cc: "freebsd-hackers@freebsd.org" , John-Mark Gurney X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:10:12 -0000 -----Original Message----- From: Navdeep Parhar Date: 2015-02-07, Saturday at 08:30 To: Ravi Pokala Cc: John-Mark Gurney , "freebsd-hackers@freebsd.org" Subject: Re: Changing the MTU on a lagg device >On Sat, Feb 07, 2015 at 05:26:36AM +0000, Pokala, Ravi wrote: >> > So, to do it, you'd need to try to change all the ports mtu, and if >>any of them fail, you need to revert all of them back to the original >>mtu... >>=20 >> Which is exactly what our code does. :-) > >And if reverting it fails then you end up with the old MTU on some >interfaces and the new MTU on others. Very unlikely, but possible. >if_lagg may have been written the way it is to avoid dealing with >failures to revert the MTU. Hi Navdeep, That's a fair point, but I'm not sure that's really any different from the way things currently work. With the current code, the case you're describing would look like this: 1) Component interfaces removed from LAGG 2) Attempt to change MTU on one or more component interfaces failed 3) Attempt to revert MTU change on one or more component interfaces also failed 4) LAGG is left in an unusable state, with no component interfaces With the proposed code, it would look like this: 1) Attempt to change MTU on one or more component interfaces failed 2) Attempt to revert MTU change on one or more component interfaces also failed 3) LAGG is left in an unusable state, with non-uniform component interfaces Either way, the LAGG is down. I should also note that I wouldn't change the MTU of the LAGG itself until after all the component interfaces were successfully changed, so that would at least prevent it from trying to send over-sized packets to the component interfaces. Although, now that I think of it, that statement is only true if we were trying to *increase* the MTU; in the case that we're trying to *decrease* it, the old value would be larger. So, how about this - if there's a failure, I set the LAGG MTU to the lowest MTU of any of the components? Does that sound reasonable? Thanks, Ravi >Regards, >Navdeep From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 18:19:13 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBAA8AA3; Mon, 9 Feb 2015 18:19:12 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B557C926; Mon, 9 Feb 2015 18:19:12 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t19IJBnp018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 10:19:11 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t19IJ98m018331; Mon, 9 Feb 2015 10:19:09 -0800 (PST) (envelope-from jmg) Date: Mon, 9 Feb 2015 10:19:09 -0800 From: John-Mark Gurney To: "Pokala, Ravi" Subject: Re: Changing the MTU on a lagg device Message-ID: <20150209181909.GG1953@funkthat.com> References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 09 Feb 2015 10:19:11 -0800 (PST) Cc: "freebsd-hackers@freebsd.org" , Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:19:13 -0000 Ravi Pokala wrote this message on Mon, Feb 09, 2015 at 16:10 +0000: > -----Original Message----- > From: Navdeep Parhar > Date: 2015-02-07, Saturday at 08:30 > To: Ravi Pokala > Cc: John-Mark Gurney , "freebsd-hackers@freebsd.org" > > Subject: Re: Changing the MTU on a lagg device > > >On Sat, Feb 07, 2015 at 05:26:36AM +0000, Pokala, Ravi wrote: > >> > So, to do it, you'd need to try to change all the ports mtu, and if > >>any of them fail, you need to revert all of them back to the original > >>mtu... > >> > >> Which is exactly what our code does. :-) > > > >And if reverting it fails then you end up with the old MTU on some > >interfaces and the new MTU on others. Very unlikely, but possible. > >if_lagg may have been written the way it is to avoid dealing with > >failures to revert the MTU. > > Hi Navdeep, > > That's a fair point, but I'm not sure that's really any different from the > way things currently work. > > With the current code, the case you're describing would look like this: > > 1) Component interfaces removed from LAGG > 2) Attempt to change MTU on one or more component interfaces failed > 3) Attempt to revert MTU change on one or more component interfaces also > failed > 4) LAGG is left in an unusable state, with no component interfaces > > With the proposed code, it would look like this: > > 1) Attempt to change MTU on one or more component interfaces failed > 2) Attempt to revert MTU change on one or more component interfaces also > failed > 3) LAGG is left in an unusable state, with non-uniform component interfaces > > Either way, the LAGG is down. > > I should also note that I wouldn't change the MTU of the LAGG itself until > after all the component interfaces were successfully changed, so that > would at least prevent it from trying to send over-sized packets to the > component interfaces. Although, now that I think of it, that statement is > only true if we were trying to *increase* the MTU; in the case that we're > trying to *decrease* it, the old value would be larger. So, how about this > - if there's a failure, I set the LAGG MTU to the lowest MTU of any of the > components? Does that sound reasonable? Hate to suggest making this more complicated, but we should leave lagg in as consistent state as possible... Which IMO, though very surprising, is kicking out the failed component... Leaving a mixed MTU which could drop packets, but somewhat work seems worse... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 18:33:22 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D80BDE1; Mon, 9 Feb 2015 18:33:22 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0065.outbound.protection.outlook.com [65.55.169.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C14D2AE0; Mon, 9 Feb 2015 18:33:21 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 9 Feb 2015 18:33:13 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0075.002; Mon, 9 Feb 2015 18:33:13 +0000 From: "Pokala, Ravi" To: John-Mark Gurney Subject: Re: Changing the MTU on a lagg device Thread-Topic: Changing the MTU on a lagg device Thread-Index: AQHQQn+0qPs6AFh2xkSO1q7r/b61upzko7MA//9+dwCAAT+aAIACmNSAgACqM4D//33OAA== Date: Mon, 9 Feb 2015 18:33:12 +0000 Message-ID: References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> <20150209181909.GG1953@funkthat.com> In-Reply-To: <20150209181909.GG1953@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: funkthat.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0944; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0944; x-forefront-prvs: 04825EA361 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377424004)(40100003)(87936001)(86362001)(2656002)(76176999)(19580405001)(77156002)(62966003)(122556002)(2900100001)(92566002)(19580395003)(106116001)(110136001)(46102003)(83506001)(99286002)(93886004)(66066001)(54356999)(36756003)(102836002)(50986999)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0944; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2015 18:33:12.3879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0944 Cc: "freebsd-hackers@freebsd.org" , Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:33:22 -0000 -----Original Message----- From: John-Mark Gurney Date: 2015-02-09, Monday at 10:19 To: Ravi Pokala Cc: Navdeep Parhar , "freebsd-hackers@freebsd.org" Subject: Re: Changing the MTU on a lagg device >Hate to suggest making this more complicated, but we should leave lagg in >as consistent state as possible... Which IMO, though very surprising, is >kicking out the failed component... Leaving a mixed MTU which could drop >packets, but somewhat work seems worse... I considered as well, but I figured dropping to the lowest MTU that worked for all the components would be less disruptive than moving to the higher MTU and kicking out the failed components. I'm flexible on this; it seems to be a fairly rare corner-case, in which all options suck, so I'm happy to defer to others as to which option sucks least. :-) -Ravi From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 19:23:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D99E4150 for ; Mon, 9 Feb 2015 19:23:47 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5007C113 for ; Mon, 9 Feb 2015 19:23:46 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t19JNeLO095722 for ; Mon, 9 Feb 2015 20:23:41 +0100 (CET) (envelope-from wojtek@puchar.net) Date: Mon, 9 Feb 2015 20:23:39 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: quirks for ulpt? Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 09 Feb 2015 20:23:42 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:23:47 -0000 i tried to use HP LaserJet P1102, it isn't PCL compatible but foo2zjs supports it. i already used this printer in one place but through USB to TCP bridge (port 5900, TPLINK "print server"). now i try to use it at home. ulpt detect it fine ugen0.2: at usbus0 ulpt0: on usbus0 ulpt0: using bi-directional mode after trying to send fooo2zjs output it just stalls forever. any tricks known (or to be checked) for this printer? seems like pure communication problem From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 19:48:15 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7E4E927 for ; Mon, 9 Feb 2015 19:48:15 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2B23B1 for ; Mon, 9 Feb 2015 19:48:15 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t19JmCsw096593 for ; Mon, 9 Feb 2015 20:48:13 +0100 (CET) (envelope-from wojtek@puchar.net) Date: Mon, 9 Feb 2015 20:48:11 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: Re: quirks for ulpt? - SOLVED In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Mon, 09 Feb 2015 20:48:13 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:48:16 -0000 using /dev/unlpt0 solves the problem. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 00:53:37 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48D27445 for ; Tue, 10 Feb 2015 00:53:37 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFE7A3B1 for ; Tue, 10 Feb 2015 00:53:36 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t1A0rPkN015790; Mon, 9 Feb 2015 16:53:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201502100053.t1A0rPkN015790@gw.catspoiler.org> Date: Mon, 9 Feb 2015 16:53:25 -0800 (PST) From: Don Lewis Subject: Re: quirks for ulpt? To: wojtek@puchar.net In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 00:53:37 -0000 On 9 Feb, Wojciech Puchar wrote: > i tried to use HP LaserJet P1102, it isn't PCL compatible but foo2zjs > supports it. > > i already used this printer in one place but through USB to TCP bridge > (port 5900, TPLINK "print server"). > > now i try to use it at home. > > ulpt detect it fine > > ugen0.2: at usbus0 > ulpt0: on usbus0 > ulpt0: using bi-directional mode > > > after trying to send fooo2zjs output it just stalls forever. > > any tricks known (or to be checked) for this printer? > > seems like pure communication problem I haven't used ulpt in quite a while. I switched to CUPS several years ago to drive my Epson USB-connected printers. It uses libusb to talk to them through the /dev/usb/*. Apps that understand CUPs are nice because they allow access to printing options supported by the printer. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 06:34:10 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E95D98A5; Tue, 10 Feb 2015 06:34:10 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F59BA05; Tue, 10 Feb 2015 06:34:09 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t1A6Y4qT015249; Tue, 10 Feb 2015 07:34:05 +0100 (CET) (envelope-from wojtek@puchar.net) Date: Tue, 10 Feb 2015 07:33:58 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Don Lewis Subject: Re: quirks for ulpt? In-Reply-To: <201502100053.t1A0rPkN015790@gw.catspoiler.org> Message-ID: References: <201502100053.t1A0rPkN015790@gw.catspoiler.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Tue, 10 Feb 2015 07:34:05 +0100 (CET) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 06:34:11 -0000 > ago to drive my Epson USB-connected printers. It uses libusb to talk to > them through the /dev/usb/*. Apps that understand CUPs are nice because > they allow access to printing options supported by the printer. > but CUPS itself is definitely not nice for me. From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 10 07:01:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AFD0D1C; Tue, 10 Feb 2015 07:01:33 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0055.outbound.protection.outlook.com [65.55.169.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3E20D19; Tue, 10 Feb 2015 07:01:32 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0941.namprd08.prod.outlook.com (25.160.131.24) with Microsoft SMTP Server (TLS) id 15.1.81.19; Tue, 10 Feb 2015 06:45:42 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0075.002; Tue, 10 Feb 2015 06:45:42 +0000 From: "Pokala, Ravi" To: Navdeep Parhar , John-Mark Gurney , Ryan Stone , hiren panchasara Subject: Re: Changing the MTU on a lagg device Thread-Topic: Changing the MTU on a lagg device Thread-Index: AQHQQn+0qPs6AFh2xkSO1q7r/b61upzko7MA//9+dwCAAT+aAIACmNSAgAD0qYA= Date: Tue, 10 Feb 2015 06:45:42 +0000 Message-ID: References: <20150207051012.GH58410@funkthat.com> <20150207163028.GA4965@ox> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0941; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0941; x-forefront-prvs: 048396AFA0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(46102003)(92566002)(102836002)(77156002)(62966003)(86362001)(2900100001)(106116001)(2950100001)(83506001)(50986999)(54356999)(76176999)(99936001)(99286002)(2656002)(87936001)(66066001)(40100003)(36756003)(93886004)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0941; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/mixed; boundary="_003_D0FEBBFE12C8F6rpokalapanasascom_" MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2015 06:45:42.1880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0941 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 07:01:33 -0000 --_003_D0FEBBFE12C8F6rpokalapanasascom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <18D72D81863BD149988843769F4DF150@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi folks, The attached patch works, but WITNESS found a LOR that may or may not be strictly related. My test, and the associated messages, are in the attached script. There are actually *two* LOR messages. The first is when adding em1 to the lagg, and it appears even without the patch, so that's because of the patch. Though obviously, we should fix it. :-) It's the *second* LOR that worries me, since it happens when I'm actually calling SIOCSIFMTU on the component interfaces. I must admit ignorance when it comes to deciphering WITNESS warnings; could someone explain what it's trying to tell me? Thanks, Ravi --_003_D0FEBBFE12C8F6rpokalapanasascom_ Content-Type: application/octet-stream; name="lagg_mtu.patch" Content-Description: lagg_mtu.patch Content-Disposition: attachment; filename="lagg_mtu.patch"; size=2521; creation-date="Tue, 10 Feb 2015 06:45:41 GMT"; modification-date="Tue, 10 Feb 2015 06:45:41 GMT" Content-ID: <3ADC0341F78C0C43B8B42B13B9CBD732@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9uZXQvaWZfbGFnZy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXQvaWZfbGFnZy5j CShyZXZpc2lvbiAyNzg0OTMpCisrKyBzeXMvbmV0L2lmX2xhZ2cuYwkod29ya2luZyBjb3B5KQpA QCAtMTMyLDYgKzEzMiw3IEBACiBzdGF0aWMgc3RydWN0IGxhZ2dfcG9ydCAqbGFnZ19saW5rX2Fj dGl2ZShzdHJ1Y3QgbGFnZ19zb2Z0YyAqLAogCSAgICBzdHJ1Y3QgbGFnZ19wb3J0ICopOwogc3Rh dGljIGNvbnN0IHZvaWQgKmxhZ2dfZ2V0aGRyKHN0cnVjdCBtYnVmICosIHVfaW50LCB1X2ludCwg dm9pZCAqKTsKK3N0YXRpYyBpbnQJbGFnZ19jaGFuZ2VfbXR1KHN0cnVjdCBpZm5ldCAqaWZwLCBz dHJ1Y3QgaWZyZXEgKmlmcik7CiAKIC8qIFNpbXBsZSByb3VuZCByb2JpbiAqLwogc3RhdGljIHZv aWQJbGFnZ19ycl9hdHRhY2goc3RydWN0IGxhZ2dfc29mdGMgKik7CkBAIC0xNDc0LDEwICsxNDc1 LDEyIEBACiAJCWJyZWFrOwogCiAJY2FzZSBTSU9DU0lGQ0FQOgotCWNhc2UgU0lPQ1NJRk1UVToK LQkJLyogRG8gbm90IGFsbG93IHRoZSBNVFUgb3IgY2FwcyB0byBiZSBkaXJlY3RseSBjaGFuZ2Vk ICovCisJCS8qIERvIG5vdCBhbGxvdyB0aGUgQ0FQcyB0byBiZSBkaXJlY3RseSBjaGFuZ2VkLiAq LwogCQllcnJvciA9IEVJTlZBTDsKIAkJYnJlYWs7CisJY2FzZSBTSU9DU0lGTVRVOgorCQllcnJv ciA9IGxhZ2dfY2hhbmdlX210dShpZnAsIGlmcik7CisJCWJyZWFrOwogCiAJZGVmYXVsdDoKIAkJ ZXJyb3IgPSBldGhlcl9pb2N0bChpZnAsIGNtZCwgZGF0YSk7CkBAIC0xNzU1LDYgKzE3NTgsNzIg QEAKIAlMQUdHX1dVTkxPQ0soc2MpOwogfQogCitzdGF0aWMgaW50CitsYWdnX2NoYW5nZV9tdHUo c3RydWN0IGlmbmV0ICppZnAsIHN0cnVjdCBpZnJlcSAqaWZyKQoreworCXN0cnVjdCBsYWdnX3Nv ZnRjICpzYyA9IChzdHJ1Y3QgbGFnZ19zb2Z0YyAqKWlmcC0+aWZfc29mdGM7CisJc3RydWN0IGxh Z2dfcG9ydCAqbHA7CisJaW50IG9sZF9tdHUgPSBpZnAtPmlmX210dTsKKwlpbnQgbmV3X210dSA9 IGlmci0+aWZyX210dTsKKwlpbnQgZXJyID0gMCwgZXJyMiA9IDA7CisJc3RydWN0IGlmcmVxIGlm cl9jb3B5OworCXN0cnVjdCBybV9wcmlvdHJhY2tlciB0cmFja2VyOworCisJaWYgKG9sZF9tdHUg PT0gbmV3X210dSkgeworCQlyZXR1cm4gMDsKKwl9CisKKwliY29weShpZnIsICZpZnJfY29weSwg c2l6ZW9mKGlmcl9jb3B5KSk7CisKKwkvKiBUcnkgdG8gY2hhbmdlIHRoZSBNVFUgb24gYWxsIGNv bXBvbmVudCBpbnRlcmZhY2VzOyBpZiB0aGF0IGRvZXNuJ3QKKwkgKiB3b3JrIG9uIGFueSBvZiB0 aGVtLCBmb3IgYW55IHJlYXNvbiwgYmFjayBldmVyeXRoaW5nIG91dC4KKwkgKi8KKwlMQUdHX1JM T0NLKHNjLCAmdHJhY2tlcik7CisJU0xJU1RfRk9SRUFDSChscCwgJnNjLT5zY19wb3J0cywgbHBf ZW50cmllcykgeworCQlpZiAobHAtPmxwX2lvY3RsID09IE5VTEwpIHsKKwkJCWVyciA9IEVPUE5P VFNVUFA7CisJCX0gZWxzZSB7CisJCQliY29weShscC0+bHBfaWZwLT5pZl94bmFtZSwgaWZyX2Nv cHkuaWZyX25hbWUsCisJCQkgICAgSUZOQU1TSVopOworCQkJZXJyID0gbHAtPmxwX2lvY3RsKGxw LT5scF9pZnAsIFNJT0NTSUZNVFUsCisJCQkgICAgKGNhZGRyX3QpJmlmcl9jb3B5KTsKKwkJfQor CQlpZiAoZXJyKSB7CisJCQlpZl9wcmludGYobHAtPmxwX2lmcCwKKwkJCSAgICAiRmFpbHVyZSBj aGFuZ2luZyBNVFUgdG8gJWQgKGVyciAlZClcbiIsCisJCQkgICAgbmV3X210dSwgZXJyKTsKKwkJ CWJyZWFrOworCQl9CisJfQorCisJaWYgKCFlcnIpIHsKKwkJLyogV2UgYXJlIGdvb2QgKi8KKwkJ aWZwLT5pZl9tdHUgPSBuZXdfbXR1OworCQlMQUdHX1JVTkxPQ0soc2MsICZ0cmFja2VyKTsKKwkJ cmV0dXJuIDA7CisJfQorCisJLyogcmVzdG9yZSBtdHUgKi8KKwlpZnJfY29weS5pZnJfbXR1ID0g b2xkX210dTsKKwlTTElTVF9GT1JFQUNIKGxwLCAmc2MtPnNjX3BvcnRzLCBscF9lbnRyaWVzKSB7 CisJCWlmIChscC0+bHBfaW9jdGwgPT0gTlVMTCkgeworCQkJY29udGludWU7CisJCX0gZWxzZSB7 CisJCQliY29weShscC0+bHBfaWZwLT5pZl94bmFtZSwgaWZyX2NvcHkuaWZyX25hbWUsCisJCQkg ICAgSUZOQU1TSVopOworCQkJZXJyMiA9IGxwLT5scF9pb2N0bChscC0+bHBfaWZwLCBTSU9DU0lG TVRVLAorCQkJICAgIChjYWRkcl90KSZpZnJfY29weSk7CisJCX0KKwkJaWYgKGVycjIpIHsKKwkJ CWlmX3ByaW50ZihscC0+bHBfaWZwLAorCQkJICAgICJGYWlsdXJlIHJlc3RvcmluZyBNVFUgdG8g JWQgKGVyciAlZClcbiIsCisJCQkgICAgb2xkX210dSwgZXJyMik7CisJCX0KKwl9CisJTEFHR19S VU5MT0NLKHNjLCAmdHJhY2tlcik7CisJcmV0dXJuIGVycjsKK30KKwogc3RydWN0IGxhZ2dfcG9y dCAqCiBsYWdnX2xpbmtfYWN0aXZlKHN0cnVjdCBsYWdnX3NvZnRjICpzYywgc3RydWN0IGxhZ2df cG9ydCAqbHApCiB7Cg== --_003_D0FEBBFE12C8F6rpokalapanasascom_ Content-Type: application/octet-stream; name="lagg_mtu.sh" Content-Description: lagg_mtu.sh Content-Disposition: attachment; filename="lagg_mtu.sh"; size=8986; creation-date="Tue, 10 Feb 2015 06:45:41 GMT"; modification-date="Tue, 10 Feb 2015 06:45:41 GMT" Content-ID: Content-Transfer-Encoding: base64 IyEvYmluL3NoCgpESUZGX0xFTj0kKCBjZCAvdXNyL3NyYyA7IHN2biBkaWZmIHN5cy9uZXQvaWZf bGFnZy5jIHwgd2MgLWwgKQoKbG9nX2FuZF9ydW4oKQp7CiAgICBjbWQ9IiRAIgogICAgbG9nZ2Vy ICIke2NtZH0iCiAgICAke2NtZH0KICAgIHNsZWVwIDEKfQoKCmlmIFsgJHtESUZGX0xFTn0gLWVx IDAgXSA7IHRoZW4KICAgIGxvZ19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIGNyZWF0ZQogICAgIyBG ZWIgIDkgMjE6NDc6MDEgZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cwIGNyZWF0ZQogICAgbG9n X2FuZF9ydW4gaWZjb25maWcgbGFnZzAgbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAyMTo0Nzow MiBmYnNkLVggcm9vdDogaWZjb25maWcgbGFnZzAgbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAy MTo0NzowMiBmYnNkLVgga2VybmVsOiBsb2NrIG9yZGVyIHJldmVyc2FsOgogICAgIyBGZWIgIDkg MjE6NDc6MDIgZmJzZC1YIGtlcm5lbDogMXN0IDB4ZmZmZmY4MDAwNDk1MGEwOCBpZl9sYWdnIHJt bG9jayAoaWZfbGFnZyBybWxvY2spIEAgL3Vzci9zcmMvc3lzL21vZHVsZXMvaWZfbGFnZy8uLi8u Li9uZXQvaWZfbGFnZy5jOjE0MTQKICAgICMgRmViICA5IDIxOjQ3OjAyIGZic2QtWCBrZXJuZWw6 IDJuZCAweGZmZmZmODAwMDRjYjcxOTAgaWZfYWRkcl9sb2NrIChpZl9hZGRyX2xvY2spIEAgL3Vz ci9zcmMvc3lzL21vZHVsZXMvaWZfbGFnZy8uLi8uLi9uZXQvaWZfbGFnZy5jOjE1MTgKICAgICMg RmViICA5IDIxOjQ3OjAyIGZic2QtWCBrZXJuZWw6IEtEQjogc3RhY2sgYmFja3RyYWNlOgogICAg IyBGZWIgIDkgMjE6NDc6MDIgZmJzZC1YIGtlcm5lbDogZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkg YXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MmIvZnJhbWUgMHhmZmZmZmUwMTIwYTI3NmYwCiAg ICAjIEZlYiAgOSAyMTo0NzowMiBmYnNkLVgga2VybmVsOiB3aXRuZXNzX2NoZWNrb3JkZXIoKSBh dCB3aXRuZXNzX2NoZWNrb3JkZXIrMHhlNDUvZnJhbWUgMHhmZmZmZmUwMTIwYTI3NzgwCiAgICAj IEZlYiAgOSAyMTo0NzowMiBmYnNkLVgga2VybmVsOiBfcndfd2xvY2tfY29va2llKCkgYXQgX3J3 X3dsb2NrX2Nvb2tpZSsweDcxL2ZyYW1lIDB4ZmZmZmZlMDEyMGEyNzdjMAogICAgIyBGZWIgIDkg MjE6NDc6MDIgZmJzZC1YIGtlcm5lbDogbGFnZ19ldGhlcl9jbWRtdWx0aSgpIGF0IGxhZ2dfZXRo ZXJfY21kbXVsdGkrMHg1Yy9mcmFtZSAweGZmZmZmZTAxMjBhMjc4MDAKICAgICMgRmViICA5IDIx OjQ3OjAyIGZic2QtWCBrZXJuZWw6IGxhZ2dfaW9jdGwoKSBhdCBsYWdnX2lvY3RsKzB4MTBmZS9m cmFtZSAweGZmZmZmZTAxMjBhMjc4ZTAKICAgICMgRmViICA5IDIxOjQ3OjAyIGZic2QtWCBrZXJu ZWw6IGlmaW9jdGwoKSBhdCBpZmlvY3RsKzB4YjQ2L2ZyYW1lIDB4ZmZmZmZlMDEyMGEyNzlhMAog ICAgIyBGZWIgIDkgMjE6NDc6MDIgZmJzZC1YIGtlcm5lbDoga2Vybl9pb2N0bCgpIGF0IGtlcm5f aW9jdGwrMHgyYzAvZnJhbWUgMHhmZmZmZmUwMTIwYTI3YTAwCiAgICAjIEZlYiAgOSAyMTo0Nzow MiBmYnNkLVgga2VybmVsOiBzeXNfaW9jdGwoKSBhdCBzeXNfaW9jdGwrMHgxNTMvZnJhbWUgMHhm ZmZmZmUwMTIwYTI3YWUwCiAgICAjIEZlYiAgOSAyMTo0NzowMiBmYnNkLVgga2VybmVsOiBhbWQ2 NF9zeXNjYWxsKCkgYXQgYW1kNjRfc3lzY2FsbCsweDI3Zi9mcmFtZSAweGZmZmZmZTAxMjBhMjdi ZjAKICAgICMgRmViICA5IDIxOjQ3OjAyIGZic2QtWCBrZXJuZWw6IFhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZmIvZnJhbWUgMHhmZmZmZmUwMTIwYTI3YmYwCiAgICAjIEZlYiAg OSAyMTo0NzowMiBmYnNkLVgga2VybmVsOiAtLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQs IHN5c19pb2N0bCksIHJpcCA9IDB4ODAxMWUxYzlhLCByc3AgPSAweDdmZmZmZmZmZTIxOCwgcmJw ID0gMHg3ZmZmZmZmZmUyOTAgLS0tCiAgICAjIEZlYiAgOSAyMTo0NzowMiBmYnNkLVgga2VybmVs OiBsYWdnMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCiAgICBsb2dfYW5kX3J1biBpZmNvbmZp ZyBsYWdnMCBsYWdncG9ydCBlbTIKICAgICMgRmViICA5IDIxOjQ3OjAzIGZic2QtWCByb290OiBp ZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBlbTIKCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBsYWdn MCAtbGFnZ3BvcnQgZW0yCiAgICAjIEZlYiAgOSAyMTo0NzowNCBmYnNkLVggcm9vdDogaWZjb25m aWcgbGFnZzAgLWxhZ2dwb3J0IGVtMgogICAgbG9nX2FuZF9ydW4gaWZjb25maWcgbGFnZzAgLWxh Z2dwb3J0IGVtMQogICAgIyBGZWIgIDkgMjE6NDc6MDUgZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxh Z2cwIC1sYWdncG9ydCBlbTEKICAgICMgRmViICA5IDIxOjQ3OjA1IGZic2QtWCBrZXJuZWw6IGxh Z2cwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgogICAgbG9nX2FuZF9ydW4gaWZjb25maWcg ZW0xIG10dSAxNTAwCiAgICAjIEZlYiAgOSAyMTo0NzowNiBmYnNkLVggcm9vdDogaWZjb25maWcg ZW0xIG10dSAxNTAwCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBlbTIgbXR1IDE1MDAKICAgICMg RmViICA5IDIxOjQ3OjA3IGZic2QtWCByb290OiBpZmNvbmZpZyBlbTIgbXR1IDE1MDAKICAgIGxv Z19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIGxhZ2dwb3J0IGVtMQogICAgIyBGZWIgIDkgMjE6NDc6 MDggZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cwIGxhZ2dwb3J0IGVtMQogICAgIyBGZWIgIDkg MjE6NDc6MDggZmJzZC1YIGtlcm5lbDogbGFnZzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAog ICAgbG9nX2FuZF9ydW4gaWZjb25maWcgbGFnZzAgbGFnZ3BvcnQgZW0yCiAgICAjIEZlYiAgOSAy MTo0NzowOSBmYnNkLVggcm9vdDogaWZjb25maWcgbGFnZzAgbGFnZ3BvcnQgZW0yCgogICAgbG9n X2FuZF9ydW4gaWZjb25maWcgbGFnZzAgLWxhZ2dwb3J0IGVtMgogICAgIyBGZWIgIDkgMjE6NDc6 MTAgZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cwIC1sYWdncG9ydCBlbTIKICAgIGxvZ19hbmRf cnVuIGlmY29uZmlnIGxhZ2cwIC1sYWdncG9ydCBlbTEKICAgICMgRmViICA5IDIxOjQ3OjExIGZi c2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCAtbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAyMTo0 NzoxMSBmYnNkLVgga2VybmVsOiBsYWdnMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KICAg IGxvZ19hbmRfcnVuIGlmY29uZmlnIGVtMSBtdHUgOTAwMAogICAgIyBGZWIgIDkgMjE6NDc6MTMg ZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGVtMSBtdHUgOTAwMAogICAgbG9nX2FuZF9ydW4gaWZjb25m aWcgZW0yIG10dSA5MDAwCiAgICAjIEZlYiAgOSAyMTo0NzoxNCBmYnNkLVggcm9vdDogaWZjb25m aWcgZW0yIG10dSA5MDAwCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBl bTEKICAgICMgRmViICA5IDIxOjQ3OjE1IGZic2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCBsYWdn cG9ydCBlbTEKICAgICMgRmViICA5IDIxOjQ3OjE1IGZic2QtWCBrZXJuZWw6IGxhZ2cwOiBsaW5r IHN0YXRlIGNoYW5nZWQgdG8gVVAKICAgIGxvZ19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIGxhZ2dw b3J0IGVtMgogICAgIyBGZWIgIDkgMjE6NDc6MTYgZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cw IGxhZ2dwb3J0IGVtMgoKICAgIGxvZ19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIC1sYWdncG9ydCBl bTIKICAgICMgRmViICA5IDIxOjQ3OjE3IGZic2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCAtbGFn Z3BvcnQgZW0yCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBsYWdnMCAtbGFnZ3BvcnQgZW0xCiAg ICAjIEZlYiAgOSAyMTo0NzoxOCBmYnNkLVggcm9vdDogaWZjb25maWcgbGFnZzAgLWxhZ2dwb3J0 IGVtMQogICAgIyBGZWIgIDkgMjE6NDc6MTggZmJzZC1YIGtlcm5lbDogbGFnZzA6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBET1dOCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBlbTEgbXR1IDE1MDAK ICAgICMgRmViICA5IDIxOjQ3OjE5IGZic2QtWCByb290OiBpZmNvbmZpZyBlbTEgbXR1IDE1MDAK ICAgIGxvZ19hbmRfcnVuIGlmY29uZmlnIGVtMiBtdHUgMTUwMAogICAgIyBGZWIgIDkgMjE6NDc6 MjAgZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGVtMiBtdHUgMTUwMAogICAgbG9nX2FuZF9ydW4gaWZj b25maWcgbGFnZzAgbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAyMTo0NzoyMSBmYnNkLVggcm9v dDogaWZjb25maWcgbGFnZzAgbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAyMTo0NzoyMSBmYnNk LVgga2VybmVsOiBsYWdnMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCiAgICBsb2dfYW5kX3J1 biBpZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBlbTIKICAgICMgRmViICA5IDIxOjQ3OjIyIGZic2Qt WCByb290OiBpZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBlbTIKCiAgICBsb2dfYW5kX3J1biBpZmNv bmZpZyBsYWdnMCAtbGFnZ3BvcnQgZW0yCiAgICAjIEZlYiAgOSAyMTo0NzoyMyBmYnNkLVggcm9v dDogaWZjb25maWcgbGFnZzAgLWxhZ2dwb3J0IGVtMgogICAgbG9nX2FuZF9ydW4gaWZjb25maWcg bGFnZzAgLWxhZ2dwb3J0IGVtMQogICAgIyBGZWIgIDkgMjE6NDc6MjQgZmJzZC1YIHJvb3Q6IGlm Y29uZmlnIGxhZ2cwIC1sYWdncG9ydCBlbTEKICAgICMgRmViICA5IDIxOjQ3OjI0IGZic2QtWCBr ZXJuZWw6IGxhZ2cwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgogICAgbG9nX2FuZF9ydW4g aWZjb25maWcgbGFnZzAgZGVzdHJveQogICAgIyBGZWIgIDkgMjE6NDc6MjUgZmJzZC1YIHJvb3Q6 IGlmY29uZmlnIGxhZ2cwIGRlc3Ryb3kKZWxzZQogICAgbG9nX2FuZF9ydW4gaWZjb25maWcgbGFn ZzAgY3JlYXRlCiAgICAjIEZlYiAgOSAyMjoxODoyNiBmYnNkLVggcm9vdDogaWZjb25maWcgbGFn ZzAgY3JlYXRlCiAgICBsb2dfYW5kX3J1biBpZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBlbTEKICAg ICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCBsYWdncG9ydCBl bTEKICAgICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCBrZXJuZWw6IGxvY2sgb3JkZXIgcmV2ZXJz YWw6CiAgICAjIEZlYiAgOSAyMjoxODoyNyBmYnNkLVgga2VybmVsOiAxc3QgMHhmZmZmZjgwMDA0 YzliYTA4IGlmX2xhZ2cgcm1sb2NrIChpZl9sYWdnIHJtbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9k dWxlcy9pZl9sYWdnLy4uLy4uL25ldC9pZl9sYWdnLmM6MTQxNQogICAgIyBGZWIgIDkgMjI6MTg6 MjcgZmJzZC1YIGtlcm5lbDogMm5kIDB4ZmZmZmY4MDAwNGM0ZDk5MCBpZl9hZGRyX2xvY2sgKGlm X2FkZHJfbG9jaykgQCAvdXNyL3NyYy9zeXMvbW9kdWxlcy9pZl9sYWdnLy4uLy4uL25ldC9pZl9s YWdnLmM6MTUyMQogICAgIyBGZWIgIDkgMjI6MTg6MjcgZmJzZC1YIGtlcm5lbDogS0RCOiBzdGFj ayBiYWNrdHJhY2U6CiAgICAjIEZlYiAgOSAyMjoxODoyNyBmYnNkLVgga2VybmVsOiBkYl90cmFj ZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9mcmFtZSAweGZm ZmZmZTAxMjBhMzY2OTAKICAgICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCBrZXJuZWw6IHdpdG5l c3NfY2hlY2tvcmRlcigpIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGU0NS9mcmFtZSAweGZmZmZm ZTAxMjBhMzY3MjAKICAgICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCBrZXJuZWw6IF9yd193bG9j a19jb29raWUoKSBhdCBfcndfd2xvY2tfY29va2llKzB4NzEvZnJhbWUgMHhmZmZmZmUwMTIwYTM2 NzYwCiAgICAjIEZlYiAgOSAyMjoxODoyNyBmYnNkLVgga2VybmVsOiBsYWdnX2V0aGVyX2NtZG11 bHRpKCkgYXQgbGFnZ19ldGhlcl9jbWRtdWx0aSsweDVjL2ZyYW1lIDB4ZmZmZmZlMDEyMGEzNjdh MAogICAgIyBGZWIgIDkgMjI6MTg6MjcgZmJzZC1YIGtlcm5lbDogbGFnZ19pb2N0bCgpIGF0IGxh Z2dfaW9jdGwrMHgxMzFhL2ZyYW1lIDB4ZmZmZmZlMDEyMGEzNjhlMAogICAgIyBGZWIgIDkgMjI6 MTg6MjcgZmJzZC1YIGtlcm5lbDogaWZpb2N0bCgpIGF0IGlmaW9jdGwrMHhiNDYvZnJhbWUgMHhm ZmZmZmUwMTIwYTM2OWEwCiAgICAjIEZlYiAgOSAyMjoxODoyNyBmYnNkLVgga2VybmVsOiBrZXJu X2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweDJjMC9mcmFtZSAweGZmZmZmZTAxMjBhMzZhMDAKICAg ICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCBrZXJuZWw6IHN5c19pb2N0bCgpIGF0IHN5c19pb2N0 bCsweDE1My9mcmFtZSAweGZmZmZmZTAxMjBhMzZhZTAKICAgICMgRmViICA5IDIyOjE4OjI3IGZi c2QtWCBrZXJuZWw6IGFtZDY0X3N5c2NhbGwoKSBhdCBhbWQ2NF9zeXNjYWxsKzB4MjdmL2ZyYW1l IDB4ZmZmZmZlMDEyMGEzNmJmMAogICAgIyBGZWIgIDkgMjI6MTg6MjcgZmJzZC1YIGtlcm5lbDog WGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhmYi9mcmFtZSAweGZmZmZmZTAxMjBh MzZiZjAKICAgICMgRmViICA5IDIyOjE4OjI3IGZic2QtWCBrZXJuZWw6IC0tLSBzeXNjYWxsICg1 NCwgRnJlZUJTRCBFTEY2NCwgc3lzX2lvY3RsKSwgcmlwID0gMHg4MDExZTFjOWEsIHJzcCA9IDB4 N2ZmZmZmZmZlMjE4LCByYnAgPSAweDdmZmZmZmZmZTI5MCAtLS0KICAgICMgRmViICA5IDIyOjE4 OjI3IGZic2QtWCBrZXJuZWw6IGxhZ2cwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKICAgIGxv Z19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIGxhZ2dwb3J0IGVtMgogICAgIyBGZWIgIDkgMjI6MTg6 MjggZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cwIGxhZ2dwb3J0IGVtMgogICAgbG9nX2FuZF9y dW4gaWZjb25maWcgbGFnZzAgbXR1IDE1MDAKICAgICMgRmViICA5IDIyOjE4OjI5IGZic2QtWCBy b290OiBpZmNvbmZpZyBsYWdnMCBtdHUgMTUwMAogICAgbG9nX2FuZF9ydW4gaWZjb25maWcgbGFn ZzAgbXR1IDkwMDAKICAgICMgRmViICA5IDIyOjE4OjMwIGZic2QtWCByb290OiBpZmNvbmZpZyBs YWdnMCBtdHUgOTAwMAogICAgIyBGZWIgIDkgMjI6MTg6MzEgZmJzZC1YIGtlcm5lbDogbG9jayBv cmRlciByZXZlcnNhbDoKICAgICMgRmViICA5IDIyOjE4OjMxIGZic2QtWCBrZXJuZWw6IDFzdCAw eGZmZmZmODAwMDRjOWJhMDggaWZfbGFnZyBybWxvY2sgKGlmX2xhZ2cgcm1sb2NrKSBAIC91c3Iv c3JjL3N5cy9tb2R1bGVzL2lmX2xhZ2cvLi4vLi4vbmV0L2lmX2xhZ2cuYzoxNzgxCiAgICAjIEZl YiAgOSAyMjoxODozMSBmYnNkLVgga2VybmVsOiAybmQgMHhmZmZmZmUwMDAwZDQ2NzQ4IGVtMSAo RU0gQ29yZSBMb2NrKSBAIC91c3Ivc3JjL3N5cy9kZXYvZTEwMDAvaWZfbGVtLmM6MTAzNQogICAg IyBGZWIgIDkgMjI6MTg6MzEgZmJzZC1YIGtlcm5lbDogS0RCOiBzdGFjayBiYWNrdHJhY2U6CiAg ICAjIEZlYiAgOSAyMjoxODozMSBmYnNkLVgga2VybmVsOiBkYl90cmFjZV9zZWxmX3dyYXBwZXIo KSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9mcmFtZSAweGZmZmZmZTAxMjBhMGU2ODAK ICAgICMgRmViICA5IDIyOjE4OjMxIGZic2QtWCBrZXJuZWw6IHdpdG5lc3NfY2hlY2tvcmRlcigp IGF0IHdpdG5lc3NfY2hlY2tvcmRlcisweGU0NS9mcmFtZSAweGZmZmZmZTAxMjBhMGU3MTAKICAg ICMgRmViICA5IDIyOjE4OjMxIGZic2QtWCBrZXJuZWw6IF9fbXR4X2xvY2tfZmxhZ3MoKSBhdCBf X210eF9sb2NrX2ZsYWdzKzB4YTgvZnJhbWUgMHhmZmZmZmUwMTIwYTBlNzYwCiAgICAjIEZlYiAg OSAyMjoxODozMSBmYnNkLVgga2VybmVsOiBsZW1faW9jdGwoKSBhdCBsZW1faW9jdGwrMHgzZTgv ZnJhbWUgMHhmZmZmZmUwMTIwYTBlN2EwCiAgICAjIEZlYiAgOSAyMjoxODozMSBmYnNkLVgga2Vy bmVsOiBsYWdnX2lvY3RsKCkgYXQgbGFnZ19pb2N0bCsweGIwOS9mcmFtZSAweGZmZmZmZTAxMjBh MGU4ZTAKICAgICMgRmViICA5IDIyOjE4OjMxIGZic2QtWCBrZXJuZWw6IGlmaW9jdGwoKSBhdCBp ZmlvY3RsKzB4MTAyZS9mcmFtZSAweGZmZmZmZTAxMjBhMGU5YTAKICAgICMgRmViICA5IDIyOjE4 OjMxIGZic2QtWCBrZXJuZWw6IGtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4MmMwL2ZyYW1l IDB4ZmZmZmZlMDEyMGEwZWEwMAogICAgIyBGZWIgIDkgMjI6MTg6MzEgZmJzZC1YIGtlcm5lbDog c3lzX2lvY3RsKCkgYXQgc3lzX2lvY3RsKzB4MTUzL2ZyYW1lIDB4ZmZmZmZlMDEyMGEwZWFlMAog ICAgIyBGZWIgIDkgMjI6MTg6MzEgZmJzZC1YIGtlcm5lbDogYW1kNjRfc3lzY2FsbCgpIGF0IGFt ZDY0X3N5c2NhbGwrMHgyN2YvZnJhbWUgMHhmZmZmZmUwMTIwYTBlYmYwCiAgICAjIEZlYiAgOSAy MjoxODozMSBmYnNkLVgga2VybmVsOiBYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsw eGZiL2ZyYW1lIDB4ZmZmZmZlMDEyMGEwZWJmMAogICAgIyBGZWIgIDkgMjI6MTg6MzEgZmJzZC1Y IGtlcm5lbDogLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0LCBzeXNfaW9jdGwpLCByaXAg PSAweDgwMTFlMWM5YSwgcnNwID0gMHg3ZmZmZmZmZmUyODgsIHJicCA9IDB4N2ZmZmZmZmZlMmEw IC0tLQogICAgbG9nX2FuZF9ydW4gaWZjb25maWcgbGFnZzAgbXR1IDE1MDAKICAgICMgRmViICA5 IDIyOjE4OjMxIGZic2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCBtdHUgMTUwMAogICAgbG9nX2Fu ZF9ydW4gaWZjb25maWcgbGFnZzAgLWxhZ2dwb3J0IGVtMgogICAgIyBGZWIgIDkgMjI6MTg6MzMg ZmJzZC1YIHJvb3Q6IGlmY29uZmlnIGxhZ2cwIC1sYWdncG9ydCBlbTIKICAgIGxvZ19hbmRfcnVu IGlmY29uZmlnIGxhZ2cwIC1sYWdncG9ydCBlbTEKICAgICMgRmViICA5IDIyOjE4OjM0IGZic2Qt WCByb290OiBpZmNvbmZpZyBsYWdnMCAtbGFnZ3BvcnQgZW0xCiAgICAjIEZlYiAgOSAyMjoxODoz NCBmYnNkLVgga2VybmVsOiBsYWdnMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KICAgIGxv Z19hbmRfcnVuIGlmY29uZmlnIGxhZ2cwIGRlc3Ryb3kKICAgICMgRmViICA5IDIyOjE4OjM1IGZi c2QtWCByb290OiBpZmNvbmZpZyBsYWdnMCBkZXN0cm95CmZpCg== --_003_D0FEBBFE12C8F6rpokalapanasascom_-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 10:31:45 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8830F62 for ; Wed, 11 Feb 2015 10:31:45 +0000 (UTC) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86BE1B14 for ; Wed, 11 Feb 2015 10:31:45 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id t1BAUPqY064086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Feb 2015 02:30:25 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id t1BAUPLI064085 for freebsd-hackers@freebsd.org; Wed, 11 Feb 2015 02:30:25 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA03444; Wed, 11 Feb 15 02:29:02 PST Date: Wed, 11 Feb 2015 02:30:07 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-hackers@freebsd.org Subject: RFC: make init(8) aware of /rescue/sh Message-Id: <54db2f2f.gIXyruGSeJuY3FbJ%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 10:31:45 -0000 Seems to me it might be desirable for init(8) to fall back to /rescue/sh for single-user mode if neither the default (kenv:init_shell) nor /bin/sh is usable. Thoughts? (Patch generated against stable/8, but will likely apply to HEAD also -- not much has changed in init.) --- init.c-orig +++ init.c @@ -79,6 +79,9 @@ #include #endif +/* Ideally this value should come from the RESCUE side of paths.h */ +#define _PATH_R_BSHELL "/rescue/sh" + #include "pathnames.h" /* @@ -706,7 +709,8 @@ /* * Fire off a shell. - * If the default one doesn't work, try the Bourne shell. + * If the default one doesn't work, try the Bourne shell; + * if that doesn't work either, try the rescue shell. */ char name[] = "-sh"; @@ -717,6 +721,8 @@ emergency("can't exec %s for single user: %m", shell); execv(_PATH_BSHELL, argv); emergency("can't exec %s for single user: %m", _PATH_BSHELL); + execv(_PATH_R_BSHELL, argv); + emergency("can't exec %s for single user: %m", _PATH_R_BSHELL); sleep(STALL_TIMEOUT); _exit(1); } From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 16:17:30 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBCF9E4E for ; Wed, 11 Feb 2015 16:17:30 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85F306CD for ; Wed, 11 Feb 2015 16:17:30 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id w8so3087591qac.1 for ; Wed, 11 Feb 2015 08:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=25g0GdiBj9OVQC4av1IGJEPQuekte4YivYxrkzotFK8=; b=yHz9FgIsgG+u/Sv+RqycBLvn2zU1NyS8gBShKeaPO6uu/fdLgig7zgSek8uWTNTK+K n4fG4zmnYPX32cXMnF8dIhTxA2yykytRzGku8aHxudrdv8E3qPuu8qnfq8yxUOT1F7Jl go73lPhH/DLEWhQFJLPbINJbecA6AiaVk2ntYX7+ym5wSerAgfELhcciSI1onD6G4A1W WPuQ2kZJaVme/sfyltFSV8cV9nswuZCs2gSYpFdHiDx41GX07704sWBDUfk9KtXATAWD 3TkNkVgVRdbqekcPy+31zBDdWtLEWBit7G3AoiY9eGQOhBq7x44IpYCpVlgw1tGU7Xb1 l9wA== MIME-Version: 1.0 X-Received: by 10.224.54.205 with SMTP id r13mr66855417qag.12.1423671443428; Wed, 11 Feb 2015 08:17:23 -0800 (PST) Received: by 10.140.145.11 with HTTP; Wed, 11 Feb 2015 08:17:23 -0800 (PST) Date: Wed, 11 Feb 2015 11:17:23 -0500 Message-ID: Subject: multiple machines with some shared users and some unique users From: Aryeh Friedman To: FreeBSD Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:17:30 -0000 I have a set of machines that has two types of user accounts: 1) Cluster wide 2) The local machine only The cluster wide accounts have a single home dir but the local ones have one home dir per machine. How do I set this up? I know YP can do item 1 but how do I do the second if I go that route? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 17:40:10 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ABC5C94 for ; Wed, 11 Feb 2015 17:40:10 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE2AFCC for ; Wed, 11 Feb 2015 17:40:09 +0000 (UTC) Received: from x23 (31.147.112.168) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 11 Feb 2015 18:38:52 +0100 Date: Wed, 11 Feb 2015 18:38:48 +0100 From: Marko Zec To: Aryeh Friedman Subject: Re: multiple machines with some shared users and some unique users Message-ID: <20150211183848.145794ee@x23> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.112.168] Cc: FreeBSD Mailing List X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:40:10 -0000 On Wed, 11 Feb 2015 11:17:23 -0500 Aryeh Friedman wrote: > I have a set of machines that has two types of user accounts: > > 1) Cluster wide > 2) The local machine only > > The cluster wide accounts have a single home dir but the local ones > have one home dir per machine. > > How do I set this up? > > I know YP can do item 1 but how do I do the second if I go that route? # fgrep passwd /etc/nsswitch.conf passwd: files nis passwd_compat: nis Let local user's home dirs reside on a local volume, say /home1, and let NIS ones use a different (NFS?) mount, say /home2 - should be as simple as that. > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 11 18:55:38 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D811C445 for ; Wed, 11 Feb 2015 18:55:38 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3881A98 for ; Wed, 11 Feb 2015 18:55:38 +0000 (UTC) Received: from st11p02mm-spool002.mac.com ([17.172.220.247]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTP id <0NJM0050ZF7ROB70@st11p02mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Wed, 11 Feb 2015 18:55:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-11_04:2015-02-11,2015-02-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502110187 MIME-version: 1.0 Received: from localhost ([17.172.220.163]) by st11p02mm-spool002.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTP id <0NJM00IPNF7QD570@st11p02mm-spool002.mac.com>; Wed, 11 Feb 2015 18:55:02 +0000 (GMT) To: perryh@pluto.rain.com From: Rui Paulo Subject: Re: RFC: make init(8) aware of /rescue/sh Date: Wed, 11 Feb 2015 18:55:01 +0000 (GMT) X-Mailer: iCloud MailClient15A99 MailServer14H18.17359 X-Originating-IP: [12.218.212.178] Message-id: <57cd8ba3-e391-45f1-adae-2806800e4a97@me.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:55:38 -0000 On Feb 11, 2015, at 02:31 AM, perryh@pluto.rain.com (Perry Hutchison) wrot= e:=0A=0ASeems to me it might be desirable for init(8) to fall back=0Ato /r= escue/sh for single-user mode if neither the default=0A(kenv:init_shell) n= or /bin/sh is usable. Thoughts?=0A=0A(Patch generated against stable/8, bu= t will likely apply to=0AHEAD also -- not much has changed in init.)=0A=0A= --- init.c-orig=0A+++ init.c=0A@@ -79,6 +79,9 @@=0A#include =0A= #endif=0A=0A+/* Ideally this value should come from the RESCUE side of pat= hs.h */=0A+#define =C2=A0 =C2=A0 =C2=A0 =C2=A0_PATH_R_BSHELL =C2=A0 =C2=A0= "/rescue/sh"=0A+=0A#include "pathnames.h"=0A=0A/*=0A@@ -706,7 +709,8 @@=0A= =0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*=0A=C2=A0 =C2=A0 =C2=A0 * Fire off = a shell.=0A- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * If the default one doesn= 't work, try the Bourne shell.=0A+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= * If the default one doesn't work, try the Bourne shell;=0A+ =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 * if that doesn't work either, try the rescue= shell.=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */=0A=0A=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0char name[] =3D "-sh";=0A@@ -717,6 +721,8 @@=0A=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0emergency("can't exec %s f= or single user: %m", shell);=0A=C2=A0 =C2=A0 =C2=A0execv(_PATH_BSHELL, arg= v);=0A=C2=A0 =C2=A0 =C2=A0emergency("can't exec %s for single user: %m", _= PATH_BSHELL);=0A+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0execv(_PATH_R_B= SHELL, argv);=0A+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0emergency("can't exec = %s for single user: %m", _PATH_R_BSHELL);=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0sleep(STALL_TIMEOUT);=0A=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0_exit(1);=0A=C2=A0 =C2=A0}=0A=C2=A0=0AThis makes sense to me= . :-)= From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 16:07:05 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174B384B; Fri, 13 Feb 2015 16:07:05 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D992822E; Fri, 13 Feb 2015 16:07:01 +0000 (UTC) Received: by ierx19 with SMTP id x19so20608506ier.3; Fri, 13 Feb 2015 08:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ms6Kw84DFNv5/NjGGEqnzy0RFjmQ99Xk+eKUMSi0gAo=; b=cPDdtcaVbuyKXbvtLZrNKD1gKQe+E8UFcr3cLdCRbgT3BpBMH4Vm5++SwT1Cs8mh2e m3nEGFNITw901w/9EbsbpFJjPW6U3F/Fg9sYdKhvhbQYfHH1AjEN2sYbAXPqTieuWt8o 4rV9kzk9SOZr1RInkNemA1QiWTYkjQ2DJkeorT3JyKnzlyGBtz4Qvfgxcqmd1bbjBIQy tlSpEAnXGmZ/8PHj2cuBrYNPYn0WjTl0OpULSyGjZH5R1VBnTUAdEFrRo5TYpV/q+DtL +aCUKg8QEfaGmSKqeSgGXY6egrzN6HXpaG+t+GnAGAy6yLC9aoS/sfV4yI5llghPPGic +o2A== X-Received: by 10.42.152.201 with SMTP id j9mr10678289icw.25.1423843620772; Fri, 13 Feb 2015 08:07:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.107.138 with HTTP; Fri, 13 Feb 2015 08:06:40 -0800 (PST) From: Luca Pizzamiglio Date: Fri, 13 Feb 2015 17:06:40 +0100 Message-ID: Subject: pcie Realtek 8168G issues (re driver) To: FreeBSD Current , FreeBSD Hackers , freebsd-hardware@freebsd.org, freebsd-network@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 16:07:05 -0000 Hi, I'm Luca, I've some issues using a PCIe Realtek Ethernet board: re0@pci0:3:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0x90500000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0x90400000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 01000000684ce000 ecap 0018[170] = LTR 1 Rx and Tx don't work. After some minutes the interface is activated I get kernel panic. I've already tried to disable MSIx and MSI. It seems a DMA problem, rx fill the 256 descriptors and the nothing else until the panic. netstat -s shows now new packets. I filled a bug report with more infos: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 could someone kindly pointing some ideas? Best regards, Luca From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 18:34:56 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DE1CBD1; Fri, 13 Feb 2015 18:34:56 +0000 (UTC) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C7318F1; Fri, 13 Feb 2015 18:34:56 +0000 (UTC) Received: by pdjz10 with SMTP id z10so20969974pdj.12; Fri, 13 Feb 2015 10:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=K3/M51oLDngo5JZ1AI+zcHFYA+08bbHJbl6aiusDeA8=; b=w35uSnBL/y0QwQiJAGsRmAyvT4RK69tyMULA2gMG0rhrkVvHLBS69g4JcS511EQgoX qf9e5niGZEOjJeivJMkn3aoGvwLe44NOt9IHV0J1OzwQKQQ1m94MunrY27uESDzNlIGZ zOhqtZ8VHYkITXObn8RNXq1l0zLjTuJNU2VcSeZaZsBIiznJVF7QmMNsvOv6DFlnbuAA /JRepC8xqXm0nCqh4Jyo3GSlymYHYSvAsUVvUqroUAGRTjYFaSs6GU2U8jbyh7RCqDgZ Fs1IwPGI57aHafn0pgC3mstIB9g9seC299ndfVdoVTPxRyht1HgpsgWGlwnXkg+GOJ6V 0vyA== X-Received: by 10.68.253.101 with SMTP id zz5mr17473240pbc.50.1423852490562; Fri, 13 Feb 2015 10:34:50 -0800 (PST) Received: from [10.0.37.153] (tessier.creepingfur.is. [70.36.196.188]) by mx.google.com with ESMTPSA id du13sm986749pdb.65.2015.02.13.10.34.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 10:34:49 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4E4BF84E-F6FD-4D25-8B2C-2B443894697B@gmail.com> X-Mailer: iPad Mail (12B435) From: Ben Perrault Subject: Re: pcie Realtek 8168G issues (re driver) Date: Fri, 13 Feb 2015 10:34:49 -0800 To: Luca Pizzamiglio X-Mailman-Approved-At: Fri, 13 Feb 2015 18:42:07 +0000 Cc: FreeBSD Hackers , "freebsd-network@freebsd.org" , FreeBSD Current , "freebsd-hardware@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:34:56 -0000 Luca, I've had the same issue with this interface on both PCIe boards and embedded= in a handful of Lenovo products. The one, fairly ugly workaround I've found= that makes it work well enough is disable tso ( i.e. ifconfig re0 down && i= fconfig re0 -tso && ifconfig re0 up ). This also seems to stop the panics un= der current. I'm not sure it will work for you - but it has on everyone of those interfac= es I've dealt with.=20 Good luck, -bp > On Feb 13, 2015, at 8:06 AM, Luca Pizzamiglio = wrote: >=20 > Hi, I'm Luca, >=20 > I've some issues using a PCIe Realtek Ethernet board: > re0@pci0:3:0:0: class=3D0x020000 card=3D0x012310ec chip=3D0x816810ec rev=3D= 0x0c hdr=3D0x00 > vendor =3D 'Realtek Semiconductor Co., Ltd.' > device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class =3D network > subclass =3D ethernet > bar [10] =3D type I/O Port, range 32, base 0x1000, size 256, enabled > bar [18] =3D type Memory, range 64, base 0x90500000, size 4096, enabl= ed > bar [20] =3D type Prefetchable Memory, range 64, base 0x90400000, > size 16384, enabled > cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] =3D MSI supports 1 message, 64 bit > cap 10[70] =3D PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x= 1) > speed 2.5(2.5) ASPM disabled(L0s/L1) > cap 11[b0] =3D MSI-X supports 4 messages > Table in map 0x20[0x0], PBA in map 0x20[0x800] > cap 03[d0] =3D VPD > ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0002[140] =3D VC 1 max VC0 > ecap 0003[160] =3D Serial 1 01000000684ce000 > ecap 0018[170] =3D LTR 1 >=20 > Rx and Tx don't work. After some minutes the interface is activated I > get kernel panic. > I've already tried to disable MSIx and MSI. > It seems a DMA problem, rx fill the 256 descriptors and the nothing > else until the panic. netstat -s shows now new packets. >=20 > I filled a bug report with more infos: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197535 >=20 > could someone kindly pointing some ideas? >=20 > Best regards, > Luca > _______________________________________________ > 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-hackers@FreeBSD.ORG Sat Feb 14 23:20:58 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87A78CFA for ; Sat, 14 Feb 2015 23:20:58 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40DCE2D7 for ; Sat, 14 Feb 2015 23:20:58 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id i13so17438687qae.10 for ; Sat, 14 Feb 2015 15:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1D95QvuynjsZS0B3mkVSUW3acY1J9J+lVYf6vj/cwM4=; b=wlX08IlaeCN7TL6yYOmUD4OjmdgswpU/KU0HJCjhcts6rPAydLkRDVC/s9JvJvKjB3 HWgytczlFvpDzpRK+lvCgXCPnhAGYP7YUcO1C6EB5ehbaNrkdy2q4SgSoK48OcdDRLw9 y/CcXa0ClMWWHJ+DfMZ5rfNcg5Bwd4+ECcfdtWWWXzkX9U5y++qexAibpegDPxoT5RLT MjldCYvr9F3E7EwXbqRjLUgB4OhGgJs955+2Yc++H0pV4em52zsHV3dqbuOTVzS42M/p /ZxMaXg2yp2BUthjXZtTC7bJ6z8jgELDvt2Anhh9N6cxAmPdhdOVa4O+Q+VzIgSquqGG sttA== MIME-Version: 1.0 X-Received: by 10.140.133.21 with SMTP id 21mr11897259qhf.40.1423956057359; Sat, 14 Feb 2015 15:20:57 -0800 (PST) Received: by 10.229.34.134 with HTTP; Sat, 14 Feb 2015 15:20:57 -0800 (PST) Date: Sat, 14 Feb 2015 15:20:57 -0800 Message-ID: Subject: sendfile() from pipe From: Ivan Krivonos To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:20:58 -0000 Hi guys, Are there any special reasons why pipe (writing end) is not supported as sendfile() source ? I`m thinking about implementing fast ZFS replication tool and having ability to zfs_send() to the one end of pipe and sendfile() from the other would be really nice From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 14 23:49:46 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50DB1720 for ; Sat, 14 Feb 2015 23:49:46 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 151117A9 for ; Sat, 14 Feb 2015 23:49:46 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 687E5B8056; Sun, 15 Feb 2015 00:49:43 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 533B228494; Sun, 15 Feb 2015 00:49:43 +0100 (CET) Date: Sun, 15 Feb 2015 00:49:43 +0100 From: Jilles Tjoelker To: Perry Hutchison Subject: Re: RFC: make init(8) aware of /rescue/sh Message-ID: <20150214234943.GB1360@stack.nl> References: <54db2f2f.gIXyruGSeJuY3FbJ%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54db2f2f.gIXyruGSeJuY3FbJ%perryh@pluto.rain.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 23:49:46 -0000 On Wed, Feb 11, 2015 at 02:30:07AM -0800, Perry Hutchison wrote: > Seems to me it might be desirable for init(8) to fall back > to /rescue/sh for single-user mode if neither the default > (kenv:init_shell) nor /bin/sh is usable. Thoughts? > (Patch generated against stable/8, but will likely apply to > HEAD also -- not much has changed in init.) > --- init.c-orig > +++ init.c > @@ -79,6 +79,9 @@ > #include > #endif > > +/* Ideally this value should come from the RESCUE side of paths.h */ > +#define _PATH_R_BSHELL "/rescue/sh" > + > #include "pathnames.h" > > /* > @@ -706,7 +709,8 @@ > > /* > * Fire off a shell. > - * If the default one doesn't work, try the Bourne shell. > + * If the default one doesn't work, try the Bourne shell; > + * if that doesn't work either, try the rescue shell. > */ > > char name[] = "-sh"; > @@ -717,6 +721,8 @@ > emergency("can't exec %s for single user: %m", shell); > execv(_PATH_BSHELL, argv); > emergency("can't exec %s for single user: %m", _PATH_BSHELL); > + execv(_PATH_R_BSHELL, argv); > + emergency("can't exec %s for single user: %m", _PATH_R_BSHELL); > sleep(STALL_TIMEOUT); > _exit(1); > } It is already possible to type "/rescue/sh" at the prompt (the Makefile always compiles with -DDEBUGSHELL). This must be done manually but also covers the case where /bin/sh exists but rtld or shared libraries are missing or broken. I'm not really sure this is worth the extra code. -- Jilles Tjoelker