From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 01:00:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F122106564A; Sun, 2 Jan 2011 01:00:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-26.mx.aerioconnect.net [216.240.47.86]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4508FC13; Sun, 2 Jan 2011 01:00:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id p020a2md009337; Sat, 1 Jan 2011 16:36:03 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C298A2D6013; Sat, 1 Jan 2011 16:36:00 -0800 (PST) Message-ID: <4D1FC888.8060906@freebsd.org> Date: Sat, 01 Jan 2011 16:36:24 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kostik Belousov References: <4D1F1AE8.5040704@chruetertee.ch> <20110101151008.GA7762@freebsd.org> <4D1F4A48.6080604@chruetertee.ch> <20110101154537.GW90883@deviant.kiev.zoral.com.ua> <4D1F4FB8.3030303@chruetertee.ch> <20110101161254.GX90883@deviant.kiev.zoral.com.ua> <4D1F5992.8030309@chruetertee.ch> <20110101164649.GY90883@deviant.kiev.zoral.com.ua> <4D1F5D5E.8030602@chruetertee.ch> <20110101172635.GZ90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20110101172635.GZ90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Alexander Best , Beat G?tzi , current@freebsd.org Subject: Re: Suddenly slow lstat syscalls on CURRENT from Juli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 01:00:03 -0000 On 1/1/11 9:26 AM, Kostik Belousov wrote: > On Sat, Jan 01, 2011 at 05:59:10PM +0100, Beat G?tzi wrote: >> On 01.01.2011 17:46, Kostik Belousov wrote: >>> On Sat, Jan 01, 2011 at 05:42:58PM +0100, Beat G?tzi wrote: >>>> On 01.01.2011 17:12, Kostik Belousov wrote: >>>>> On Sat, Jan 01, 2011 at 05:00:56PM +0100, Beat G?tzi wrote: >>>>>> On 01.01.2011 16:45, Kostik Belousov wrote: >>>>>>> Check the output of sysctl kern.maxvnodes and vfs.numvnodes. I suspect >>>>>>> they are quite close or equial. If yes, consider increasing maxvnodes. >>>>>>> Another workaround, if you have huge nested directories hierarhy, is >>>>>>> to set vfs.vlru_allow_cache_src to 1. >>>>>> Thanks for the hint. kern.maxvnodes and vfs.numvnodes were equal: >>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>> kern.maxvnodes: 100000 >>>>>> vfs.numvnodes: 100765 >>>>>> >>>>>> I've increased kern.maxvnodes and the problem was gone until >>>>>> vfs.numvnodes reached the value of kern.maxvnodes again: >>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>> kern.maxvnodes: 150000 >>>>>> vfs.numvnodes: 150109 >>>>> The processes should be stuck in "vlruwk" state, that can be >>>>> checked with ps or '^T' on the terminal. >>>> Yes, there are various processes in "vlruwk" state, >>>> >>>>>> As the directory structure is quite huge on this server I've set >>>>>> vfs.vlru_allow_cache_src to one now. >>>>> Did it helped ? >>>> No, it doesn't looks like setting vfs.vlru_allow_cache_src helped. The >>>> problem was gone when I increased kern.maxvnodes until vfs.numvnodes >>>> reached that level. I've stopped all running deamons but numvnodes >>>> doesn't decrease. >>> Stopping the daemons would not decrease the count of cached vnodes. >>> What you can do is to call unmount on the filesystems. Supposedly, the >>> filesystems are busy and unmount shall fail, but it will force freed >>> the vnodes that are unused by any process. >> That freed around 1500 vnodes. At the moment the vfs.numvnodes doesn't >> increase rapidly and the server is usable. I will keep an eye it to see >> if I run into the same problem again. > This is too small amount of vnodes to be freed for the typical system, > and it feels like a real vnode leak. It would be helpful if you tried > to identify the load that causes the situation to occur. > > You are on the UFS, right ? try running sockstat to a file and looking to see what is open.. it could just be a normal leak. From owner-freebsd-current@FreeBSD.ORG Fri Dec 31 23:08:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0618E1065673; Fri, 31 Dec 2010 23:08:14 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa03a.plala.or.jp (msa03.plala.or.jp [58.93.240.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47CBD8FC0C; Fri, 31 Dec 2010 23:08:12 +0000 (UTC) Received: from i220-220-101-75.s02.a026.ap.plala.or.jp ([220.220.101.75]) by msa01b.plala.or.jp with ESMTP id <20101231225219.FVFN24286.msa01b.plala.or.jp@i220-220-101-75.s02.a026.ap.plala.or.jp>; Sat, 1 Jan 2011 07:52:19 +0900 Date: Sat, 01 Jan 2011 07:52:19 +0900 Message-ID: <868vz58sik.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: =?ISO-2022-JP-2?B?UmVuGyQoRCsxGyhC?= Ladan In-Reply-To: References: Mail-Followup-To: =?ISO-2022-JP-2?B?UmVuGyQoRCsxGyhC?= Ladan , current@freebsd.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-VirusScan: Outbound; msa01b; Sat, 1 Jan 2011 07:52:19 +0900 X-Mailman-Approved-At: Sun, 02 Jan 2011 04:40:09 +0000 Cc: current@freebsd.org Subject: Re: userland weirdness between r216351 and r216738 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 23:08:14 -0000 A happy new yaer Ren$(D+1(B, At Fri, 31 Dec 2010 22:35:05 +0100, Ren$(D+1(B Ladan wrote: > somewhere between 9.0-amd64 r216351 and r216738, I've noticed some > userland weirdness. I suppose you've been hit by rtld bug between r216695[*1] and r216728[*2]. It broke certain kind of dynamic linking so weird things might happen. Like unexpected font selected, flash movie malfunctioning in firefox, some port compilation failure[*3], etc, etc. They all have happened on me and already gone. Hope this helps. -- kuro [*1] r216695: http://docs.FreeBSD.org/cgi/mid.cgi?201012250851.oBP8pLLm017014 [*2] r216728: http://docs.FreeBSD.org/cgi/mid.cgi?201012270030.oBR0UTq9004790 [*3] "problem with port gobject-introspection on 9.0-CURRENT" http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.02.1012261329550.8533 and http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.02.1012282053100.28301 (He is my hero.) From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 09:06:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82EFB106566B for ; Sun, 2 Jan 2011 09:06:32 +0000 (UTC) (envelope-from too.much.dudes@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17EBC8FC15 for ; Sun, 2 Jan 2011 09:06:31 +0000 (UTC) Received: by ewy24 with SMTP id 24so5993704ewy.13 for ; Sun, 02 Jan 2011 01:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=9ggYkgrO4oiNB7/5RmJf+xJrCs1BWfp5XZn1hu/1aRc=; b=KACJzhI1wATABwYjcSKJ7HIVApWo832CJI+FBt7GFaYIO8mFZ8cD50wl13zx1XtoYy 6RfUXKLCxV+25dDiOhlYFHVPyrdJpr2GfP1TDGPsKeBYtP+jFeF8OKscZnBEknzyWZUH aGXDIUuH4pYbVYMqEKicbkSifHTvXFVQXdlL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=d7ow1cRrfi40Z2k7drjOe+M4Vyw7r88T3zZVK41iqRhxhl5zL1HgBGO0mdChhJvhw+ P3nVPt84YuDh8dBzaBVfVYXVU5pIaICdq3BGZ01v8P961UxAEWvzeR4obJV+7rv7NJPh 20exn1qYK7npH/kzJGic8OVkcs06hag4k20og= Received: by 10.213.13.133 with SMTP id c5mr16035760eba.8.1293957369041; Sun, 02 Jan 2011 00:36:09 -0800 (PST) Received: from zla ([95.143.221.10]) by mx.google.com with ESMTPS id x54sm13754593eeh.23.2011.01.02.00.36.07 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 00:36:08 -0800 (PST) Date: Sun, 2 Jan 2011 11:36:06 +0300 From: too.much.dudes@gmail.com To: freebsd-current@freebsd.org Message-Id: <20110102113606.aa72b22d.too.much.dudes@gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 09:06:32 -0000 Hello, have problem with A4Tech G7100 wireless combo mouse+keyboard. Mouse works fine, but keyboard not. It's loading: ugen4.2: at usbus4 ukbd1: on usbus4 but pressing any key doesn't have effect. It works only in one way - if i pressing one (any) key and don't releasing it and preessing another key at the same time. For example to make work key "a" i should press "b" (and don't releasing it, use like "shift") and after that pressing key "a". And it works. This problem is only in 8.x branch. At Freebsd 7.3, 7.4 it works ok. I think the problem is in new ukbd-driver, when i press 'q' key, debug says: ukbd_intr_callback:547: actlen=8 bytes ukbd_intr_callback:590: apple_eject=0 apple_fn=0 ukbd_intr_callback:597: [0] = 20 ukbd_put_key:312: 0x14 (20) pressed ukbd_intr_callback:547: actlen=8 bytes ukbd_intr_callback:590: apple_eject=0 apple_fn=0 ukbd_put_key:312: 0x414 (1044) released (this is for usb wire-keyboard that works fine) ukbd_intr_callback:547: actlen=12 bytes ukbd_intr_callback:590: apple_eject=0 apple_fn=0 (and this is for my ATech G7100 keyboard) Could you tell me where the problem is? From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 09:57:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22E0D106566C for ; Sun, 2 Jan 2011 09:57:52 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A9F668FC15 for ; Sun, 2 Jan 2011 09:57:51 +0000 (UTC) Received: by bwz12 with SMTP id 12so5777993bwz.13 for ; Sun, 02 Jan 2011 01:57:50 -0800 (PST) Received: by 10.204.52.134 with SMTP id i6mr15025065bkg.36.1293962269023; Sun, 02 Jan 2011 01:57:49 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-065-056-254.pools.arcor-ip.net [88.65.56.254]) by mx.google.com with ESMTPS id d27sm10864168bkw.14.2011.01.02.01.57.46 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 01:57:47 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Steve Kargl Date: Sun, 2 Jan 2011 10:55:54 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: <20101226195556.GA45505@troutmask.apl.washington.edu> <201012270205.25867.bschmidt@freebsd.org> <20110101184721.GA9383@troutmask.apl.washington.edu> In-Reply-To: <20110101184721.GA9383@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101021055.55583.bschmidt@freebsd.org> Cc: freebsd-current@freebsd.org, Etienne Robillard Subject: Re: wlan/wpi are more broken than 3 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 09:57:52 -0000 On Saturday 01 January 2011 19:47:21 you wrote: > On Mon, Dec 27, 2010 at 02:05:25AM +0100, Bernhard Schmidt wrote: > > On Monday 27 December 2010 01:32:56 Steve Kargl wrote: > > > On Sun, Dec 26, 2010 at 11:25:05PM +0100, Bernhard Schmidt wrote: > > [ .. ] > > If you can get debug output while the UPs/DOWNs happen, that would > > help a lot. > > Sorry about the delay. The laptop has been in Windows land for the > last week. I finally have a log where the interface is going UP/DOWN > and have wlandebug in effect. It's 220KB. You can find it at Thanks > http://troutmask.apl.washington.edu/~kargl/wlan0.msg wlan0: AMRR decreasing rate 48 (txcnt=35 retrycnt=14) wlan0: recv deauthenticate (reason 2) wlan0: ieee80211_new_state_locked: RUN -> AUTH (nrunning 0 nscanning 0) I've seen those before, though, I never figured out if there is a way to bypass that. What's happening here is that the AP detects that you've ben idle (as in not sending frames) for quite a while (the rate decrease does indicate that) and kicks you with a 'auth no longer valid' message. This seems to be a 'feature' of your AP and not an issue with the driver, at least I do not see any connection. As a workaround try to ping something behind the AP. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 11:02:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F712106564A for ; Sun, 2 Jan 2011 11:02:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9877F8FC17 for ; Sun, 2 Jan 2011 11:02:06 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=47jFoQlQiPaXYvJJRPLdRbboc2AFRw6czTf8DabKp4c= c=1 sm=1 a=dq2f58wT9zoA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=AZaa_EyPkbosoRVlS7IA:9 a=DC_b9ChRp529lFQnMhoA:7 a=-o4vs_odO4aUeQjn6O2zT2Yl8lsA:4 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 69337455; Sun, 02 Jan 2011 12:01:57 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 2 Jan 2011 12:02:05 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20110102113606.aa72b22d.too.much.dudes@gmail.com> In-Reply-To: <20110102113606.aa72b22d.too.much.dudes@gmail.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101021202.05356.hselasky@c2i.net> Cc: too.much.dudes@gmail.com Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 11:02:07 -0000 On Sunday 02 January 2011 09:36:06 too.much.dudes@gmail.com wrote: > Hello, have problem with A4Tech G7100 wireless combo mouse+keyboard. > Mouse works fine, but keyboard not. It's loading: > ugen4.2: at usbus4 > ukbd1: on usbus4 > but pressing any key doesn't have effect. It works only in one way - if i > pressing one (any) key and don't releasing it and preessing another key at > the same time. > > For example to make work key "a" i should press "b" (and don't releasing > it, use like "shift") and after that pressing key "a". And it works. > > This problem is only in 8.x branch. At Freebsd 7.3, 7.4 it works ok. > I think the problem is in new ukbd-driver, when i press 'q' key, debug > says: > > ukbd_intr_callback:547: actlen=8 bytes > ukbd_intr_callback:590: apple_eject=0 apple_fn=0 > ukbd_intr_callback:597: [0] = 20 > ukbd_put_key:312: 0x14 (20) pressed > ukbd_intr_callback:547: actlen=8 bytes > ukbd_intr_callback:590: apple_eject=0 apple_fn=0 > ukbd_put_key:312: 0x414 (1044) released > (this is for usb wire-keyboard that works fine) > > ukbd_intr_callback:547: actlen=12 bytes > ukbd_intr_callback:590: apple_eject=0 apple_fn=0 > (and this is for my ATech G7100 keyboard) Could you dump the device and configuration descriptors of your keyboard using the usbconfig utility. usbconfig -d X.Y dump_device_desc dump_curr_config_desc It looks like your keyboard is sending 12 bytes instead of 8, which is expected from UKBD. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 11:05:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04EFD106566B for ; Sun, 2 Jan 2011 11:05:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 83EA58FC17 for ; Sun, 2 Jan 2011 11:05:18 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=jVx+AExU5EFhK37+rVAQq6jxd4lXLYohjT2gqEoUpuc= c=1 sm=1 a=dq2f58wT9zoA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=xxGIs9nFZYLhcMYUm1kA:9 a=aepv-LyPrF2yS4pLFm-kksZqdjUA:4 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 68920559; Sun, 02 Jan 2011 12:05:16 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 2 Jan 2011 12:05:24 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20110102113606.aa72b22d.too.much.dudes@gmail.com> In-Reply-To: <20110102113606.aa72b22d.too.much.dudes@gmail.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101021205.24206.hselasky@c2i.net> Cc: too.much.dudes@gmail.com Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 11:05:19 -0000 On Sunday 02 January 2011 09:36:06 too.much.dudes@gmail.com wrote: > Hello, have problem with A4Tech G7100 wireless combo mouse+keyboard. > Mouse works fine, but keyboard not. It's loading: > ugen4.2: at usbus4 > ukbd1: on usbus4 > but pressing any key doesn't have effect. It works only in one way - if i > pressing one (any) key and don't releasing it and preessing another key at > the same time. > > For example to make work key "a" i should press "b" (and don't releasing > it, use like "shift") and after that pressing key "a". And it works. > > This problem is only in 8.x branch. At Freebsd 7.3, 7.4 it works ok. > I think the problem is in new ukbd-driver, when i press 'q' key, debug In sys/dev/usb/input/ukbd.c, you could try to redefine this variable to 8. #define UKBD_NKEYCODE 6 /* units */ --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 13:53:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5357A106564A; Sun, 2 Jan 2011 13:53:24 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from marvin.chruetertee.ch (marvin.chruetertee.ch [217.150.245.55]) by mx1.freebsd.org (Postfix) with ESMTP id F11228FC15; Sun, 2 Jan 2011 13:53:23 +0000 (UTC) Received: from daedalus.network.local (231-225.77-83.cust.bluewin.ch [83.77.225.231]) (authenticated bits=0) by marvin.chruetertee.ch (8.14.3/8.14.3) with ESMTP id p02DrMIb015906 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO); Sun, 2 Jan 2011 13:53:22 GMT (envelope-from beat@chruetertee.ch) Message-ID: <4D208355.6040404@chruetertee.ch> Date: Sun, 02 Jan 2011 14:53:25 +0100 From: =?ISO-8859-1?Q?Beat_G=E4tzi?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101210 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: Kostik Belousov References: <4D1F1AE8.5040704@chruetertee.ch> <20110101151008.GA7762@freebsd.org> <4D1F4A48.6080604@chruetertee.ch> <20110101154537.GW90883@deviant.kiev.zoral.com.ua> <4D1F4FB8.3030303@chruetertee.ch> <20110101161254.GX90883@deviant.kiev.zoral.com.ua> <4D1F5992.8030309@chruetertee.ch> <20110101164649.GY90883@deviant.kiev.zoral.com.ua> <4D1F5D5E.8030602@chruetertee.ch> <20110101172635.GZ90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20110101172635.GZ90883@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , current@freebsd.org Subject: Re: Suddenly slow lstat syscalls on CURRENT from Juli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 13:53:24 -0000 On 01.01.2011 18:26, Kostik Belousov wrote: > On Sat, Jan 01, 2011 at 05:59:10PM +0100, Beat G?tzi wrote: >> On 01.01.2011 17:46, Kostik Belousov wrote: >>> On Sat, Jan 01, 2011 at 05:42:58PM +0100, Beat G?tzi wrote: >>>> On 01.01.2011 17:12, Kostik Belousov wrote: >>>>> On Sat, Jan 01, 2011 at 05:00:56PM +0100, Beat G?tzi wrote: >>>>>> On 01.01.2011 16:45, Kostik Belousov wrote: >>>>>>> Check the output of sysctl kern.maxvnodes and vfs.numvnodes. I suspect >>>>>>> they are quite close or equial. If yes, consider increasing maxvnodes. >>>>>>> Another workaround, if you have huge nested directories hierarhy, is >>>>>>> to set vfs.vlru_allow_cache_src to 1. >>>>>> >>>>>> Thanks for the hint. kern.maxvnodes and vfs.numvnodes were equal: >>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>> kern.maxvnodes: 100000 >>>>>> vfs.numvnodes: 100765 >>>>>> >>>>>> I've increased kern.maxvnodes and the problem was gone until >>>>>> vfs.numvnodes reached the value of kern.maxvnodes again: >>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>> kern.maxvnodes: 150000 >>>>>> vfs.numvnodes: 150109 >>>>> The processes should be stuck in "vlruwk" state, that can be >>>>> checked with ps or '^T' on the terminal. >>>> >>>> Yes, there are various processes in "vlruwk" state, >>>> >>>>>> As the directory structure is quite huge on this server I've set >>>>>> vfs.vlru_allow_cache_src to one now. >>>>> Did it helped ? >>>> >>>> No, it doesn't looks like setting vfs.vlru_allow_cache_src helped. The >>>> problem was gone when I increased kern.maxvnodes until vfs.numvnodes >>>> reached that level. I've stopped all running deamons but numvnodes >>>> doesn't decrease. >>> Stopping the daemons would not decrease the count of cached vnodes. >>> What you can do is to call unmount on the filesystems. Supposedly, the >>> filesystems are busy and unmount shall fail, but it will force freed >>> the vnodes that are unused by any process. >> >> That freed around 1500 vnodes. At the moment the vfs.numvnodes doesn't >> increase rapidly and the server is usable. I will keep an eye it to see >> if I run into the same problem again. > This is too small amount of vnodes to be freed for the typical system, > and it feels like a real vnode leak. It would be helpful if you tried > to identify the load that causes the situation to occur. >From the data I collect from the server it doesn't look like a constant leak: 2010-12-21/18/00: vfs.numvnodes: 84089 2010-12-22/18/00: vfs.numvnodes: 76599 2010-12-23/18/00: vfs.numvnodes: 22854 2010-12-24/18/00: vfs.numvnodes: 17940 2010-12-25/18/00: vfs.numvnodes: 84999 2010-12-26/18/00: vfs.numvnodes: 84601 2010-12-27/18/00: vfs.numvnodes: 32724 2010-12-28/18/00: vfs.numvnodes: 141104 I checked for the exact point in time when vfs.numvnodes hit the limit: 2010-12-28/01/30: vfs.numvnodes: 71566 2010-12-28/01/35: vfs.numvnodes: 82448 2010-12-28/01/40: vfs.numvnodes: 89826 2010-12-28/01/45: vfs.numvnodes: 79625 2010-12-28/01/50: vfs.numvnodes: 24678 2010-12-28/01/55: vfs.numvnodes: 100045 2010-12-28/02/00: vfs.numvnodes: 100351 2010-12-28/02/05: vfs.numvnodes: 100685 2010-12-28/02/10: vfs.numvnodes: 100989 Every night at 1:02 there is a script running that checks out SVN trunk of VirtualBox and tries to build that in the tinderbox. From the tinderbox logs I see that the build of virtualbox-ose-devel-4.0.1.r35314 on FreeBSD 7 Jail was finished at 2010-12-28 01:47:05. At 01:48:55 the build for FreeBSD 8 started but it looks like something went wrong there as this build never finished. Unfortunately I'm not able to reproduce what of that build caused this problem. There were no changes in the VBox SVN between the 27th and the 28th so on the 27th an identical tinderbox run was successful. > You are on the UFS, right ? Yes, UFS with Softupdates except on /: # mount /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local, multilabel) /dev/da0s1d on /tmp (ufs, local, soft-updates) /dev/da0s1f on /usr (ufs, local, soft-updates) /dev/da0s1e on /var (ufs, local, noexec, nosuid, soft-updates) Beat From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:22:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAC1106566C for ; Sun, 2 Jan 2011 14:22:33 +0000 (UTC) (envelope-from too.much.dudes@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 584358FC13 for ; Sun, 2 Jan 2011 14:22:33 +0000 (UTC) Received: by gxk8 with SMTP id 8so5367178gxk.13 for ; Sun, 02 Jan 2011 06:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=yPVWEeUmmJKKVjV1vENeM4+6JKRp8n7IwfxVvy4mAek=; b=eELQi7c9oQUl8vJeQX5jXq9MOcRtGZ8Ama6S9iUiJpDJXFw23jXknqCpVeExCRoIwS j8AfFyykBkgfLZrSg6XgFxIyxiW5Sebz+jH/LFzRT79MdMbn/RW4anOflX0e24Eg24uv V4v2FKeoBUtI8ziZ1XMNtsfkclAOTTo5bu8j4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=L+/U+UDF8FwW5idnNSgA0+fHsLNXppwm/GLcU0DQn0AcUBqHBFqvmTYlCuT8+jy0BB lSPS1fOGxrCgkOuxHnmYmSTvvp7Oxmt2/KR3rsdo8zeuCN57ghHUHGf9p8aekQssvQxj 1M0tPLnszW5/bKdN8rXPPz/ATwY/Fo/aGKvSI= MIME-Version: 1.0 Received: by 10.236.103.145 with SMTP id f17mr287067yhg.47.1293978152495; Sun, 02 Jan 2011 06:22:32 -0800 (PST) Received: by 10.151.51.21 with HTTP; Sun, 2 Jan 2011 06:22:32 -0800 (PST) Date: Sun, 2 Jan 2011 17:22:32 +0300 Message-ID: From: I Think To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:22:33 -0000 I've tried already to change both UKBD_NMOD and UKBD_NKEYCODE, but where is no result. #define UKBD_NKEYCODE 8 // doesn't work too > usbconfig -u 4 -a 2 dump_device_desc dump_curr_config_desc ugen4.2: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x09da idProduct = 0x054f bcdDevice = 0x0102 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x003b bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0001 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x11 RAW dump: 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x84, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x000c bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0002 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x11 RAW dump: 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x57, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0003 wMaxPacketSize = 0x0008 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 // sorry if i missed the thread, dunno how to reply via gmail correctly From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:30:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CD5B106564A for ; Sun, 2 Jan 2011 14:30:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 610568FC12 for ; Sun, 2 Jan 2011 14:30:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=47jFoQlQiPaXYvJJRPLdRbboc2AFRw6czTf8DabKp4c= c=1 sm=1 a=dq2f58wT9zoA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=TBaf3Pgtm4k5Hk7rcFIA:9 a=2c7uo7Dr7IoX18MA-PEA:7 a=tE5JasSOI6JgVe_iMgH62t1UOWIA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 69377522; Sun, 02 Jan 2011 15:30:19 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 2 Jan 2011 15:30:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101021530.27319.hselasky@c2i.net> Cc: I Think Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:30:22 -0000 On Sunday 02 January 2011 15:22:32 I Think wrote: > I've tried already to change both UKBD_NMOD and UKBD_NKEYCODE, but where is > no result. > #define UKBD_NKEYCODE 8 // doesn't work too > > > usbconfig -u 4 -a 2 dump_device_desc dump_curr_config_desc > > ugen4.2: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0110 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0008 > idVendor = 0x09da > idProduct = 0x054f > bcdDevice = 0x0102 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0000 > bNumConfigurations = 0x0001 > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x003b > bNumInterfaces = 0x0002 > bConfigurationValue = 0x0001 > iConfiguration = 0x0000 > bmAttributes = 0x00a0 > bMaxPower = 0x0032 > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0000 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0001 > bInterfaceClass = 0x0003 > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x0001 > iInterface = 0x0000 > > Additional Descriptor > > bLength = 0x09 > bDescriptorType = 0x21 > bDescriptorSubType = 0x11 > RAW dump: > 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x84, > 0x08 | 0x00 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0081 > bmAttributes = 0x0003 > wMaxPacketSize = 0x000c > bInterval = 0x0001 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > > Interface 1 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0001 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0001 > bInterfaceClass = 0x0003 > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x0002 > iInterface = 0x0000 > > Additional Descriptor > > bLength = 0x09 > bDescriptorType = 0x21 > bDescriptorSubType = 0x11 > RAW dump: > 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x57, > 0x08 | 0x00 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0082 > bmAttributes = 0x0003 > wMaxPacketSize = 0x0008 > bInterval = 0x0001 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > You could maybe try this. Lookup the following code in ukbd.c. Add the lines marked with + if (sc->sc_kbd_id != 0) { /* check and remove HID ID byte */ usbd_copy_out(pc, 0, &id, 1); if (id != sc->sc_kbd_id) { DPRINTF("wrong HID ID\n"); goto tr_setup; } offset = 1; len--; } else { offset = 0; } + if (len == 12) { + offset += 2; + len -= 2; + } + if (len == 11) { + offset += 1; + len -= 1; + } --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:35:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9E8106566B for ; Sun, 2 Jan 2011 14:35:32 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id AED008FC14 for ; Sun, 2 Jan 2011 14:35:31 +0000 (UTC) Received: by eyf6 with SMTP id 6so5797311eyf.13 for ; Sun, 02 Jan 2011 06:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=gRHW+bhpYCHr3JOKbAjnlQ3IpOnnnR5rZQ8F0MoRZYA=; b=n8e7QflMhUHn3OarTKWwctsygltqhafxJrSp9Qmdm5nH0xdxWE0iHneHYFtG8uEw7b UTCazpyNDD1dBv/oABHOcpdD8y0VCXElu8XggYfQwdYAjk5xs4tnQAlLT+0ubJjGto+l KlVn6MWXANtj6BTkFI0haeeKvX/ul4AVNJHzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=AnKtX+6rSuUi6DVByQLVUldhJXNAkO/XoTxhA6Tayx7OnbFBLE3/FlXpCqpgWYGu79 SAci1NVlTkMmPmLyu7L4u2MG72ARx5GYxiYrNHhEX3LPqY5LAaapYjikNcaD/5pkZxdh YCE+RdlFWDWINAzH8aje2y9I/uOszqMziH1V4= Received: by 10.14.119.129 with SMTP id n1mr11637098eeh.13.1293978929432; Sun, 02 Jan 2011 06:35:29 -0800 (PST) Received: from [192.168.1.64] (ip4da3ae31.direct-adsl.nl [77.163.174.49]) by mx.google.com with ESMTPS id x54sm13973843eeh.5.2011.01.02.06.35.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 06:35:28 -0800 (PST) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <4D208D2E.70404@freebsd.org> Date: Sun, 02 Jan 2011 15:35:26 +0100 From: Rene Ladan Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; nl-NL; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Kabaev References: <20101231174351.127b7764@kan.dnsalias.net> In-Reply-To: <20101231174351.127b7764@kan.dnsalias.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: userland weirdness between r216351 and r216738 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:35:32 -0000 Op 31-12-2010 23:43, Alexander Kabaev schreef: > On Fri, 31 Dec 2010 22:35:05 +0100 > René Ladan wrote: > >> Hi, >> >> somewhere between 9.0-amd64 r216351 and r216738, I've noticed some >> userland weirdness. >> Symptoms are: >> - pseudo-random number generator not starting, preventing ssh(d) from >> working >> - fonts in X.org (xfce4) missing or replaced >> - mouse only working when hald is running >> >> I don't know if the above symptoms are somehow related, or what >> causes them. The kernel is GENERIC without (u)lpt and umass and with >> these modules loaded: fdescfs.ko >> if_iwn.ko >> snd_hda.ko >> sound.ko >> umass.ko >> iwn5000fw.ko >> nvidia.ko (256.53) >> linux.ko >> cuse4bsd.ko >> atapicam.ko >> linprocfs.ko >> >> Kernel and world are compiled with >> FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 >> >> Reverting to r216351 (kernel, world, mergemaster) brought things back >> to normal. I can do a binary search if desired. Did someone else also >> see this? >> >> Happy 2011, >> Rene > > Try backing out rtld down to version prior to this commit > http://svn.freebsd.org/changeset/base/216695 . There is an issue with > rtld's use of SSE on amd64 which will be fixed soon. > Backing out src/libexec/rtld-elf to r216694 solved it for now :) Rene -- http://www.rene-ladan.nl/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:42:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1811106566B for ; Sun, 2 Jan 2011 14:42:46 +0000 (UTC) (envelope-from too.much.dudes@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 840A28FC1E for ; Sun, 2 Jan 2011 14:42:46 +0000 (UTC) Received: by eyf6 with SMTP id 6so5798232eyf.13 for ; Sun, 02 Jan 2011 06:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=bU23fvFKyXsBY+1b1/shHoxMASVuuCB/hznbzk3+YT0=; b=fy9VNnvN1dR0r23aJmzTxudr14Geyq1+xxU/7BbzmF5YIbKjv5+AIBfSqVcE1my9K2 aVSNX0yuUOpYtrPgScTzSHzekOQTqGl4QNkGKkoXvcWglGkQXd0TJ3IpvWq4Itz6sl87 wnGBiU1gb/0ASBw+lr+zDVYAKPEzVmcvmhrco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; b=SrGPDURZLtBWXzVWlWOyAmEQpDoemW7CSXJ6J2QXlH4EE0cKl/amzgzal9H7pP6v9P /CG3nnKPE03UZCnPNGdx2x5qonFjbK9qERxD2mtTzq1uWVXhiFllsLbTv19X6rQEJLT3 SyuuxnEGivCodv4RMdpt3PMVrNrLCj6hq3K6g= Received: by 10.213.35.194 with SMTP id q2mr16963960ebd.65.1293979365391; Sun, 02 Jan 2011 06:42:45 -0800 (PST) Received: from zla ([95.143.221.10]) by mx.google.com with ESMTPS id t50sm13972811eeh.18.2011.01.02.06.42.44 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 06:42:44 -0800 (PST) Date: Sun, 2 Jan 2011 17:42:42 +0300 From: too.much.dudes@gmail.com To: freebsd-current@freebsd.org Message-Id: <20110102174242.014ddca5.too.much.dudes@gmail.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: AANLkTi=uMUPvXt4gS+gqPmpQT5LZWLNjt_9d2UfHTULM@mail.gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:42:47 -0000 already tried variants : offset+=4 && len-=4 offset+=0 && len-=4 and yours, but they doesn't have correct effect (yours variant gives some addition lags: for example pressing "o" presses Scroll Lock, "h" - WIN_L and etc) From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:51:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3CBF106566B; Sun, 2 Jan 2011 14:51:08 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from marvin.chruetertee.ch (marvin.chruetertee.ch [217.150.245.55]) by mx1.freebsd.org (Postfix) with ESMTP id 742E88FC0C; Sun, 2 Jan 2011 14:51:08 +0000 (UTC) Received: from daedalus.network.local (231-225.77-83.cust.bluewin.ch [83.77.225.231]) (authenticated bits=0) by marvin.chruetertee.ch (8.14.3/8.14.3) with ESMTP id p02Ep64K062193 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO); Sun, 2 Jan 2011 14:51:06 GMT (envelope-from beat@chruetertee.ch) Message-ID: <4D2090DE.1080706@chruetertee.ch> Date: Sun, 02 Jan 2011 15:51:10 +0100 From: =?ISO-8859-1?Q?Beat_G=E4tzi?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101210 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: Julian Elischer References: <4D1F1AE8.5040704@chruetertee.ch> <20110101151008.GA7762@freebsd.org> <4D1F4A48.6080604@chruetertee.ch> <20110101154537.GW90883@deviant.kiev.zoral.com.ua> <4D1F4FB8.3030303@chruetertee.ch> <20110101161254.GX90883@deviant.kiev.zoral.com.ua> <4D1F5992.8030309@chruetertee.ch> <20110101164649.GY90883@deviant.kiev.zoral.com.ua> <4D1F5D5E.8030602@chruetertee.ch> <20110101172635.GZ90883@deviant.kiev.zoral.com.ua> <4D1FC888.8060906@freebsd.org> In-Reply-To: <4D1FC888.8060906@freebsd.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Best , current@freebsd.org Subject: Re: Suddenly slow lstat syscalls on CURRENT from Juli X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:51:09 -0000 On 02.01.2011 01:36, Julian Elischer wrote: > On 1/1/11 9:26 AM, Kostik Belousov wrote: >> On Sat, Jan 01, 2011 at 05:59:10PM +0100, Beat G?tzi wrote: >>> On 01.01.2011 17:46, Kostik Belousov wrote: >>>> On Sat, Jan 01, 2011 at 05:42:58PM +0100, Beat G?tzi wrote: >>>>> On 01.01.2011 17:12, Kostik Belousov wrote: >>>>>> On Sat, Jan 01, 2011 at 05:00:56PM +0100, Beat G?tzi wrote: >>>>>>> On 01.01.2011 16:45, Kostik Belousov wrote: >>>>>>>> Check the output of sysctl kern.maxvnodes and vfs.numvnodes. I >>>>>>>> suspect >>>>>>>> they are quite close or equial. If yes, consider increasing >>>>>>>> maxvnodes. >>>>>>>> Another workaround, if you have huge nested directories >>>>>>>> hierarhy, is >>>>>>>> to set vfs.vlru_allow_cache_src to 1. >>>>>>> Thanks for the hint. kern.maxvnodes and vfs.numvnodes were equal: >>>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>>> kern.maxvnodes: 100000 >>>>>>> vfs.numvnodes: 100765 >>>>>>> >>>>>>> I've increased kern.maxvnodes and the problem was gone until >>>>>>> vfs.numvnodes reached the value of kern.maxvnodes again: >>>>>>> # sysctl kern.maxvnodes vfs.numvnodes >>>>>>> kern.maxvnodes: 150000 >>>>>>> vfs.numvnodes: 150109 >>>>>> The processes should be stuck in "vlruwk" state, that can be >>>>>> checked with ps or '^T' on the terminal. >>>>> Yes, there are various processes in "vlruwk" state, >>>>> >>>>>>> As the directory structure is quite huge on this server I've set >>>>>>> vfs.vlru_allow_cache_src to one now. >>>>>> Did it helped ? >>>>> No, it doesn't looks like setting vfs.vlru_allow_cache_src helped. The >>>>> problem was gone when I increased kern.maxvnodes until vfs.numvnodes >>>>> reached that level. I've stopped all running deamons but numvnodes >>>>> doesn't decrease. >>>> Stopping the daemons would not decrease the count of cached vnodes. >>>> What you can do is to call unmount on the filesystems. Supposedly, the >>>> filesystems are busy and unmount shall fail, but it will force freed >>>> the vnodes that are unused by any process. >>> That freed around 1500 vnodes. At the moment the vfs.numvnodes doesn't >>> increase rapidly and the server is usable. I will keep an eye it to see >>> if I run into the same problem again. >> This is too small amount of vnodes to be freed for the typical system, >> and it feels like a real vnode leak. It would be helpful if you tried >> to identify the load that causes the situation to occur. >> >> You are on the UFS, right ? > try running sockstat to a file and looking to see what is open.. > it could just be a normal leak. The sockstat output looks normal at least to me: http://tmp.chruetertee.ch/tinderbox-sockstat Thanks, Beat From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 14:56:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 872051065670 for ; Sun, 2 Jan 2011 14:56:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 11AC18FC14 for ; Sun, 2 Jan 2011 14:56:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=jVx+AExU5EFhK37+rVAQq6jxd4lXLYohjT2gqEoUpuc= c=1 sm=1 a=dq2f58wT9zoA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=AsRLeHs3dbwEm_LtRL0A:9 a=FhHTcthYd0vpVmLa3EwA:7 a=-l8rJN9t39f-PTXGT--P2bB8vQwA:4 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 68964089; Sun, 02 Jan 2011 15:56:14 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, AANLkTi=uMUPvXt4gS+gqPmpQT5LZWLNjt_9d2UfHTULM@mail.gmail.com Date: Sun, 2 Jan 2011 15:56:21 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20110102174242.014ddca5.too.much.dudes@gmail.com> In-Reply-To: <20110102174242.014ddca5.too.much.dudes@gmail.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101021556.21645.hselasky@c2i.net> Cc: Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:56:16 -0000 On Sunday 02 January 2011 15:42:42 too.much.dudes@gmail.com wrote: > already tried variants : > offset+=4 && len-=4 > offset+=0 && len-=4 > and yours, but they doesn't have correct effect > (yours variant gives some addition lags: > for example pressing "o" presses Scroll Lock, "h" - WIN_L and etc) Hi, Maybe you can add a printout, to dump the len bytes: uint32_t yy; printf("UKBD data: "); for (yy = 0; yy != len; yy++) { uint8_t temp; usbd_copy_out(pc, offset + yy, &temp, 1); printf("0x%02x ", (int)temp); } printf("\n"); I guess the reason your keyboard doesn't work is that we don't parse any HID descriptors in UKBD. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 15:10:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7407B1065670 for ; Sun, 2 Jan 2011 15:10:29 +0000 (UTC) (envelope-from dsc.fbsd.current@gmail.com) Received: from mail-ew0-f68.google.com (mail-ew0-f68.google.com [209.85.215.68]) by mx1.freebsd.org (Postfix) with ESMTP id A7ABB8FC18 for ; Sun, 2 Jan 2011 15:10:28 +0000 (UTC) Received: by ewy3 with SMTP id 3so2108272ewy.7 for ; Sun, 02 Jan 2011 07:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:keywords :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=AHTjwbsqv+MRtZ61HCE2Ztf2LgOpcdLE7+jpwbRWEQs=; b=SPDYT5DgaYLEMB2YWc+OcQdkohyQZtr9fgv7Kg92NLl/UcNupiVlyrWmdScMYxq88J G79jKjs6Z6ogVtUQH1u2i+RG63lFAQiHyUYGz6cxm5zJErySJiR4P+YzVxzRYn2WGBw7 ssf3qmW70JRYfSdRIQlkyQeeKlAOrLhd5htO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:keywords:message-id:mime-version:content-type :x-mailer:thread-index:content-language; b=I8YdvgBmWbmn5YeYhgyHO1uuvCv6AzYoubfLq9VeJbFW7aWD3bD9Bzb1KvYzDqoc1S EBowh6KS7aUO/IPDx0TzsYelem5RcAGSlppp8niJVJnbvqbc1mrzgWN2vHrKKA/BxYZw W2WAC7KYoUo5WrFaOmMgtjmqQBxpp/wUtDccY= Received: by 10.14.123.68 with SMTP id u44mr12601915eeh.21.1293979988315; Sun, 02 Jan 2011 06:53:08 -0800 (PST) Received: from fscld ([94.176.153.23]) by mx.google.com with ESMTPS id b52sm13984653eei.13.2011.01.02.06.53.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 06:53:07 -0800 (PST) From: "dsc fbsd.current" To: Date: Sun, 2 Jan 2011 16:52:47 +0200 Keywords: BDF1out Message-ID: <003901cbaa8c$bb859bb0$3290d310$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcuqjKOYDhKYSndTQMGqz+KVT+/A0w== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: jailing MYSQL error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:10:29 -0000 Hi. I'm using ezjail standard config file, with a modified fstab file (mount_nullfs ports to jail). Cat /usr/local/etc/ezjail/j009_mysql2 export jail_j009_mysql2_hostname="j009_mysql2" export jail_j009_mysql2_ip="xx.xx.xx.xx" export jail_j009_mysql2_rootdir="/ezjail/j009_mysql2" export jail_j009_mysql2_exec_start="/bin/sh /etc/rc" export jail_j009_mysql2_exec_stop="" export jail_j009_mysql2_mount_enable="YES" export jail_j009_mysql2_devfs_enable="YES" export jail_j009_mysql2_devfs_ruleset="devfsrules_jail" export jail_j009_mysql2_procfs_enable="YES" export jail_j009_mysql2_fdescfs_enable="YES" export jail_j009_mysql2_image="" export jail_j009_mysql2_imagetype="" export jail_j009_mysql2_attachparams="" export jail_j009_mysql2_attachblocking="" export jail_j009_mysql2_forceblocking="" export jail_j009_mysql2_zfs_datasets="" export jail_j009_mysql2_cpuset="" export jail_j009_mysql2_fib="" My steps: 1. Ezjail-admin onestart j009_mysql2 2. Ezjail-admin console j009_mysql2 3. Cd /usr/ports/database/mysql55-server && make install clean 4. cp /usr/local/share/mysql/my-innodb-heavy-4G.cnf /usr/local/etc/my.cnf (modified socket file path to /var/db/mysql/mysql.sock, in both client and server lines) 5. chown -R mysql:mysql ... for ... /tmp /var/tmp /var/db/mysql 6. mysql_enable="YES" in jail rc.conf 7. /usr/local/etc/rc.d/mysql-server start 8. ...and NOTHING ... mysql-server scripts starts /usr/local/bin/mysql_install_db (creates mysql and test folders in /var/db/mysql ... but nothing else ... it's just running) I had to kill everything. After reading lots of webpages and trying all kind of stuff (including http://devel.reinikainen.net/15, but without ssl stuff), I decided to install MySQL on the host. I've made the same steps (3-5 and 7 with "onestart" instead "start") and used the same my-innodb-heavy-4G.cnf file Everything went well. Mysqld started, creating socket file and pid file; mysql_install_db had no errors. The log file says: 110102 18:07:06 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql 110102 18:07:06 [Note] Plugin 'FEDERATED' is disabled. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Compressed tables use zlib 1.2.5 110102 18:07:06 InnoDB: Initializing buffer pool, size = 2.0G 110102 18:07:07 InnoDB: Completed initialization of buffer pool 110102 18:07:07 InnoDB: highest supported file format is Barracuda. 110102 18:07:07 InnoDB: 1.1.3 started; log sequence number 1595675 110102 18:07:07 [Note] Event Scheduler: Loaded 0 events 110102 18:07:07 [Note] /usr/local/libexec/mysqld: ready for connections. Version: '5.5.7-rc-log' socket: '/var/db/mysql/mysql.sock' port: 3306 FreeBSD port: mysql-server-5.5.7 I didn't give up ... so I did: 9. Rm -rf /var/db/mysql/* (in jail) 10. Cp /var/db/mysql/mysql/* /ezjail/j009_mysql2/var/db/mysql/mysql (from host to jail) 11. Cp /var/db/mysql/performance_schema/* /ezjail/j009_mysql2/var/db/mysql/performance_schema (from host to jail) 12. Starting and entering the jail again 13. usr/local/etc/rc.d/mysql-server start was started upon entering the jail (did not create pid and socket file) but generated this log: 110102 17:03:05 [Note] Plugin 'FEDERATED' is disabled. /usr/local/libexec/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13) 110102 17:03:05 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Compressed tables use zlib 1.2.5 110102 17:03:05 InnoDB: Initializing buffer pool, size = 2.0G 110102 17:03:06 InnoDB: Completed initialization of buffer pool InnoDB: The first specified data file /innodb/ibdata1 did not exist: InnoDB: a new database to be created! 110102 17:03:06 InnoDB: Setting file /innodb/ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 110102 17:03:06 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 110102 17:03:08 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 110102 17:03:10 InnoDB: Log file ./ib_logfile2 did not exist: new to be created InnoDB: Setting log file ./ib_logfile2 size to 256 MB InnoDB: Database physically writes the file full: wait... InnoDB: Progress in MB: 100 200 14. usr/local/etc/rc.d/mysql-server stop ... doesn't work because of missing pid file (the same with "mysql_upgrade" suggested by the log file) 15. './mysql/plugin.frm' file exists 16. kill everything and run again usr/local/etc/rc.d/mysql-server start with this result: 110102 17:07:40 [Note] Plugin 'FEDERATED' is disabled. /usr/local/libexec/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13) 110102 17:07:40 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Compressed tables use zlib 1.2.5 110102 17:07:40 InnoDB: Initializing buffer pool, size = 2.0G 110102 17:07:40 InnoDB: Completed initialization of buffer pool 110102 17:07:40 InnoDB: highest supported file format is Barracuda. InnoDB: No valid checkpoint found. InnoDB: If this error appears when you are creating an InnoDB database, InnoDB: the problem may be that during an earlier attempt you managed InnoDB: to create the InnoDB data files, but log file creation failed. InnoDB: If that is the case, please refer to InnoDB: http://dev.mysql.com/doc/refman/5.1/en/error-creating-innodb.html 110102 17:07:40 [ERROR] Plugin 'InnoDB' init function returned error. 110102 17:07:40 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 17. But i have a pid and socket file 18. "mysql_upgrade" doesn't work (hangs up) 19. Also "mysql -u root" doesn't work (hangs up) I've read http://dev.mysql.com/doc/refman/5.1/en/error-creating-innodb.html and other related webpages. I think is something related with permissions in jail, but I can't figure it out. So, my final hope is this email. Anyone has any idea? Thanks in advance! Lulu PS: I'm using: - FreeBSD Current (amd64) - Geli encryption - ZFS v28 with world and kernel build with src r215329 (patched with head-v28-v2.patch from Martin Matuska)(the patch doesn't work on the latest src) - Ports updated one week ago - Ezjail installed one week ago (buildworld with src updated one week ago) From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 15:13:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFF561065673 for ; Sun, 2 Jan 2011 15:13:23 +0000 (UTC) (envelope-from too.much.dudes@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE1C8FC13 for ; Sun, 2 Jan 2011 15:13:23 +0000 (UTC) Received: by eyf6 with SMTP id 6so5804800eyf.13 for ; Sun, 02 Jan 2011 07:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=FfL1pZFQkOyTCNF37uA+XA9gYZFyNJB6oPcCPWm6w2c=; b=wTymngJ16ns0kBwDdmcP+Py/x78kuylRWDgoOnh0OSrpliRsvvOoREPNbHZVjoSF1q danrkawR6yJRXdgSOH6kbKCJWTkEhPPODKmXKjN69CZUoG/J6m82dyaALveVVApkeaGv DmAhWqPbN+nmGYXkMsIgCJ4Y23k87BHVyvfGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=mYPW1m8ooMOlDBIZTax4bnirOhKGTG4WezDKdgpSmUSCljdLvCVr1xMU6O/Wp7QP4k 8Mv86knrV4nbGNIkRxX2peXPywKiLZHdoADMdUWrFe3ivopPbypJLkDvac8+TKvjrDkl ZEiI59sMx6xV111WFEZvq80fJcUESExKaikCk= Received: by 10.213.113.210 with SMTP id b18mr2487087ebq.49.1293981202296; Sun, 02 Jan 2011 07:13:22 -0800 (PST) Received: from zla ([95.143.221.10]) by mx.google.com with ESMTPS id q58sm13998916eeh.21.2011.01.02.07.13.20 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 07:13:21 -0800 (PST) Date: Sun, 2 Jan 2011 18:13:19 +0300 From: too.much.dudes@gmail.com To: freebsd-current@freebsd.org Message-Id: <20110102181319.328d2605.too.much.dudes@gmail.com> In-Reply-To: <201101021557.42677.hselasky@c2i.net> References: <201101021557.42677.hselasky@c2i.net> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:13:24 -0000 ukbd_intr_callback:547: actlen=12 bytes ukbd_intr_callback:568: UKBD data: ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x14 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:575: 0x00 ukbd_intr_callback:578: ukbd_intr_callback:603: apple_eject=0 apple_fn=0 i tried debug "sc_odata.keycode[i]" "sc_ndata.keycode[i]" at function "ukbd_interrupt()", they are empty, but for another keyboard they are not. > I guess the reason your keyboard doesn't work is that we don't parse any HID > descriptors in UKBD. So why is it working in freebsd 7.x then? From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 22:23:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D221065679 for ; Sun, 2 Jan 2011 22:23:37 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA6E8FC2F for ; Sun, 2 Jan 2011 22:23:37 +0000 (UTC) Received: by gxk8 with SMTP id 8so5436370gxk.13 for ; Sun, 02 Jan 2011 14:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xP2b8sl4uxbaXtyIXPeBF0BgZTxLlxfTh7aUGp5W+II=; b=aZc38wINFEhWHDc0TUFIwMQ0pRyV7l7Y2kS1+6238mMcW/s24gU+Hv9fu2V6sxevdm ta2QsiyPNz4zONYW2si327y+sUa0v2QxRlckldQ/TMv6UM7LJJdw0FvLeZ/rv/y481l9 Jo4G6+hNxGogdOCWpU+qzsk0VnQB7DYfWYrY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=C0jAxsthkf6NjCez70FCSF81nC+srcmwQSx25a97lvY8luCzlM51IgYzaIAshxmly2 30AefPo0nv1Nwo3b7a587OW+xA9ofw4suiOCtxKNFcO2PzLUQell/rA6kSWp+ni9MIN+ YTREqxZ3mH1Q2Jb0ExWgZxAnrqj4hJrNUM1zY= Received: by 10.90.118.2 with SMTP id q2mr11591005agc.11.1294007016797; Sun, 02 Jan 2011 14:23:36 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-155-97.dsl.klmzmi.sbcglobal.net [99.181.155.97]) by mx.google.com with ESMTPS id 8sm11737388yhx.3.2011.01.02.14.23.34 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 14:23:35 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4D20FAE4.1070608@DataIX.net> Date: Sun, 02 Jan 2011 17:23:32 -0500 From: "J. Hellenthal" Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101230 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: "dsc fbsd.current" References: <003901cbaa8c$bb859bb0$3290d310$@gmail.com> In-Reply-To: <003901cbaa8c$bb859bb0$3290d310$@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: jailing MYSQL error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:23:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Just to be sure as the long detailed information that you laid before can lead to confusion, lets take this one step at a time. Assuming all your bases are covered and it sinks down to a permissions issue try this: chown root:wheel /path/to/jail/tmp /path/to/jail/var/tmp chmod 1777 /path/to/jail/tmp /path/to/jail/var/tmp rm -rf /path/to/jail/var/db/mysql - -Login to the jail here- make sure that rc.conf* only contains mysql_enable="YES" service mysql-server start ls -ld /var/db/mysql should convey mode 700 or drwx------ and uid/88 gid/88 mysql/mysql At this point your mysql server should be running and fully working. Another thing to make sure you eliminate just in case... would be any my.cnf files in /etc or /usr/local/etc Good luck - -- Regards, jhell,v JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNIPrkAAoJEJBXh4mJ2FR+fLEH/0N91782PKGna/DZNoRF4hWJ 8tTh9bPFaHGjRu2ITC08gFJBLaAK8hE5oh9Tg5k6eysyzjE1EEHXUAJaL6B8Rg+N w5m66OGtvunX8JQqwu8d6ulDLk4EHex7Aaf0G2wfpW2OBDP4oCbeXxaakDJp+dzB GGf4a4ezODgQsr8Hxva71bgesfQ6a1BEirf/pwGcaQs9y1lCgoRK6M+iKDKqruLM Vyp4oNCHX52GTKa/cpx2VveZG/F21RabYtCVrBhU3Xq0EbDeDkiP2JjZt0xNPJVA dnCfCtTRECeruqlFHekH7MayF7uZ5nZIjJ3SEA6xHTCyt3PVC7oxr1NCmaETWJQ= =HFv4 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jan 2 23:27:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A664F106566B for ; Sun, 2 Jan 2011 23:27:25 +0000 (UTC) (envelope-from deboomerang@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFDF8FC0A for ; Sun, 2 Jan 2011 23:27:24 +0000 (UTC) Received: by iwn39 with SMTP id 39so13237159iwn.13 for ; Sun, 02 Jan 2011 15:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=s28LlwGh/MdomxFhJaWwEpYSTpIyjhLJywGrXm/OWb0=; b=NHFnWa3q/eYqjB3lLOJ21+z8GGVdhM98II6YrlIzBNI5XRx5Oj+MPvYab25esh28V9 RczXMGryL+FCuuJF+YkZeR97/qB8cxcXcRU/FdHHzJFc9982k9D2Axl2HZLv6P49KFjK MCpqvBs+AtrgzLSo46NBvWPT/73zkHwtf32/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=V3jKVKcKAUIqm4AcB7Q5mv6leYpjOplIvkh9ItGWVJasD1gko2Crta/CmZb57G461T d73/DpsFHAC4sphskSn29nRW4Flsn8wRRuu9VdToARrlTvsQbhvcWckcwQ337hOoMB3A SCGuMwPR44DDg4B4aqvNFBn30PrgN+w5h84tM= Received: by 10.42.229.198 with SMTP id jj6mr20384445icb.292.1294009361215; Sun, 02 Jan 2011 15:02:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.171.72 with HTTP; Sun, 2 Jan 2011 15:02:21 -0800 (PST) From: bv Date: Sun, 2 Jan 2011 17:02:21 -0600 Message-ID: To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=20cf30549f434fb2120498e508cb Subject: [Call for testers] FreeBSD VirtIO Network Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 23:27:25 -0000 --20cf30549f434fb2120498e508cb Content-Type: text/plain; charset=ISO-8859-1 Hi. I'd like to present the network VirtIO driver I've been working on for the last few months in my spare time. It is not based on the NetBSD code that is floating around. The attached patch should apply to both recent -current and -stable. Early development was done on VirtualBox, but most has been done on KVM/QEMU. While still a work in progress, the network is mostly feature complete with checksum offloading, TSO, etc, with a couple of caveats: - The VirtIO checksum offload interface doesn't map well to FreeBSD's offloading interface. The network driver is forced to peek inside the incoming/outgoing frames to set the appropriate flags. This could be make more robust with regards to IPv6. - Per Rx/Tx locking needs to be implemented before LRO can happen. - Tx completion interrupts could be basically eliminated when the host supports a certain virtqueue feature. I have a patch that does just that, but haven't had a chance to really test it. I haven't done any real performance testing yet, but here's some informal iperf results between the emulated e1000 device and the VirtIO device on FreeBSD. The host is Fedora 14 running 2.6.35.10-72.fc14.x86_64/qemu-kvm-0.13.0-1.fc14.x86_64. The Linux guest is debain-testing (2.6.32-5-amd64) with a VirtIO network device. The FreeBSD guest is amd64 8-STABLE with both an e1000 and VirtIO network interfaces. Both guests are running on the same host, and the MTU of all interfaces was 1500. Measurements are in Mbits/sec. FreeBSD --> Linux x e1000 + vtnet N Min Max Median Avg Stddev x 6 340 358 348 347.66667 6.2822501 + 6 1529 1540 1538 1535.3333 4.3665394 Difference at 95.0% confidence 1187.67 +/- 6.95891 341.611% +/- 2.0016% (Student's t, pooled s = 5.40987) Linux --> FreeBSD x e1000 + vtnet N Min Max Median Avg Stddev x 11 437 456 449 447.36364 6.4385204 + 11 669 679 671 673.27273 3.5802488 Difference at 95.0% confidence 225.909 +/- 4.6335 50.4979% +/- 1.03573% (Student's t, pooled s = 5.20926) I imagine the lack of LRO makes the FreeBSD receiving results less impressive. Performance is not up to where Linux <--> Linux is at. To use, after applying the patch and compiling, you'll need to load the virtio, virtio_pci, and if_vtnet kernel modules. The virtio module contains the virtqueue transport and a bit of glue code. The virtio_pci module implements the VirtIO PCI interface for device probing and communication with the host. The if_vtnet module contains the network driver. I have a partially complete VirtIO block driver. Hopefully it will be ready for wider testing in a couple of weeks. I'm going to be away from my computer for the next couple of days, I'll get to any email after then. --20cf30549f434fb2120498e508cb Content-Type: application/octet-stream; name="FreeBSD-VirtIO.patch" Content-Disposition: attachment; filename="FreeBSD-VirtIO.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gigirf2l0 ZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmFtZDY0IGIvc3lzL2NvbmYvZmlsZXMuYW1kNjQK LS0tIGEvc3lzL2NvbmYvZmlsZXMuYW1kNjQKKysrIGIvc3lzL2NvbmYvZmlsZXMuYW1kNjQKQEAg LTIyNSw2ICsyMjUsMTIgQEAKIGRldi90cG0vdHBtX2FjcGkuYwkJb3B0aW9uYWwJdHBtIGFjcGkK IGRldi90cG0vdHBtX2lzYS5jCQlvcHRpb25hbAl0cG0gaXNhCiBkZXYvdWFydC91YXJ0X2NwdV9h bWQ2NC5jCW9wdGlvbmFsCXVhcnQKK2Rldi92aXJ0aW8vdmlydGlvLmMgICAgICAgICAgICAgb3B0 aW9uYWwJdmlydGlvCitkZXYvdmlydGlvL3ZpcnRpb19pZi5tICAgICAgICAgIG9wdGlvbmFsIAl2 aXJ0aW8KK2Rldi92aXJ0aW8vdmlydGlvX2J1c19pZi5tICAgICAgb3B0aW9uYWwJdmlydGlvCitk ZXYvdmlydGlvL3ZpcnRxdWV1ZS5jICAgICAgICAgIG9wdGlvbmFsCXZpcnRpbworZGV2L3ZpcnRp by9wY2kvdmlydGlvX3BjaS5jICAgICBvcHRpb25hbAl2aXJ0aW9fcGNpIHBjaQorZGV2L3ZpcnRp by9uZXR3b3JrL2lmX3Z0bmV0LmMgICBvcHRpb25hbAl2dG5ldAogZGV2L3dwaS9pZl93cGkuYwkJ b3B0aW9uYWwJd3BpCiBpc2Evc3lzY29uc19pc2EuYwkJb3B0aW9uYWwJc2MKIGlzYS92Z2FfaXNh LmMJCQlvcHRpb25hbAl2Z2EKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmkzODYgYi9zeXMv Y29uZi9maWxlcy5pMzg2Ci0tLSBhL3N5cy9jb25mL2ZpbGVzLmkzODYKKysrIGIvc3lzL2NvbmYv ZmlsZXMuaTM4NgpAQCAtMjM1LDYgKzIzNSwxMiBAQAogZGV2L3RwbS90cG1fYWNwaS5jCQlvcHRp b25hbCB0cG0gYWNwaQogZGV2L3RwbS90cG1faXNhLmMJCW9wdGlvbmFsIHRwbSBpc2EKIGRldi91 YXJ0L3VhcnRfY3B1X2kzODYuYwlvcHRpb25hbCB1YXJ0CitkZXYvdmlydGlvL3ZpcnRpby5jICAg ICAgICAgICAgIG9wdGlvbmFsIHZpcnRpbworZGV2L3ZpcnRpby92aXJ0aW9faWYubSAgICAgICAg ICBvcHRpb25hbCB2aXJ0aW8KK2Rldi92aXJ0aW8vdmlydGlvX2J1c19pZi5tICAgICAgb3B0aW9u YWwgdmlydGlvCitkZXYvdmlydGlvL3ZpcnRxdWV1ZS5jICAgICAgICAgIG9wdGlvbmFsIHZpcnRp bworZGV2L3ZpcnRpby9wY2kvdmlydGlvX3BjaS5jICAgICBvcHRpb25hbCB2aXJ0aW9fcGNpIHBj aQorZGV2L3ZpcnRpby9uZXR3b3JrL2lmX3Z0bmV0LmMgICBvcHRpb25hbCB2dG5ldAogZGV2L2Fj cGljYS9hY3BpX2lmLm0JCXN0YW5kYXJkCiBkZXYvYWNwaV9zdXBwb3J0L2FjcGlfd21pX2lmLm0J c3RhbmRhcmQKIGRldi93cGkvaWZfd3BpLmMJCW9wdGlvbmFsIHdwaQpkaWZmIC0tZ2l0IGEvc3lz L2NvbmYva21vZC5tayBiL3N5cy9jb25mL2ttb2QubWsKLS0tIGEvc3lzL2NvbmYva21vZC5tawor KysgYi9zeXMvY29uZi9rbW9kLm1rCkBAIC0zNjEsNiArMzYxLDcgQEAKIAlkZXYvc291bmQvcGNt L2ZlZWRlcl9pZi5tIGRldi9zb3VuZC9wY20vbWl4ZXJfaWYubSBcCiAJZGV2L3NvdW5kL21pZGkv bXB1X2lmLm0gZGV2L3NvdW5kL21pZGkvbXB1Zm9pX2lmLm0gXAogCWRldi9zb3VuZC9taWRpL3N5 bnRoX2lmLm0gZGV2L3VzYi91c2JfaWYubSBpc2EvaXNhX2lmLm0gXAorCWRldi92aXJ0aW8vdmly dGlvX2J1c19pZi5tIGRldi92aXJ0aW8vdmlydGlvX2lmLm0gXAogCWtlcm4vYnVzX2lmLm0ga2Vy bi9jbG9ja19pZi5tIFwKIAlrZXJuL2NwdWZyZXFfaWYubSBrZXJuL2RldmljZV9pZi5tIGtlcm4v c2VyZGV2X2lmLm0gXAogCWxpYmtlcm4vaWNvbnZfY29udmVydGVyX2lmLm0gb3BlbmNyeXB0by9j cnlwdG9kZXZfaWYubSBcCmRpZmYgLS1naXQgYS9zeXMvZGV2L3ZpcnRpby9uZXR3b3JrL2lmX3Z0 bmV0LmMgYi9zeXMvZGV2L3ZpcnRpby9uZXR3b3JrL2lmX3Z0bmV0LmMKbmV3IGZpbGUgbW9kZSAx MDA2NDQKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMvZGV2L3ZpcnRpby9uZXR3b3JrL2lmX3Z0bmV0 LmMKQEAgLTAsMCArMSwyNzU4IEBACisvKiBEcml2ZXIgZm9yIFZpcnRJTyBuZXR3b3JrIGRldmlj ZXMuICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KKworI2lmZGVmIEhBVkVfS0VSTkVMX09Q VElPTl9IRUFERVJTCisjaW5jbHVkZSAib3B0X2RldmljZV9wb2xsaW5nLmgiCisjZW5kaWYKKwor I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1ZGUg PHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvc29ja2lvLmg+CisjaW5jbHVkZSA8c3lzL21i dWYuaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgor I2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRl IDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lzL3Rhc2txdWV1ZS5oPgorI2luY2x1ZGUgPHN5 cy9yYW5kb20uaD4KKyNpbmNsdWRlIDxzeXMvc2dsaXN0Lmg+CisjaW5jbHVkZSA8c3lzL2xvY2su aD4KKyNpbmNsdWRlIDxzeXMvbXV0ZXguaD4KKworI2luY2x1ZGUgPG5ldC9pZi5oPgorI2luY2x1 ZGUgPG5ldC9pZl9hcnAuaD4KKyNpbmNsdWRlIDxuZXQvZXRoZXJuZXQuaD4KKyNpbmNsdWRlIDxu ZXQvaWZfZGwuaD4KKyNpbmNsdWRlIDxuZXQvaWZfdHlwZXMuaD4KKyNpbmNsdWRlIDxuZXQvaWZf dmxhbl92YXIuaD4KKworI2luY2x1ZGUgPG5ldC9icGYuaD4KKworI2luY2x1ZGUgPG5ldGluZXQv aW5fc3lzdG0uaD4KKyNpbmNsdWRlIDxuZXRpbmV0L2luLmg+CisjaW5jbHVkZSA8bmV0aW5ldC9p cC5oPgorI2luY2x1ZGUgPG5ldGluZXQvaXA2Lmg+CisjaW5jbHVkZSA8bmV0aW5ldC91ZHAuaD4K KyNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgorI2luY2x1ZGUgPG5ldGluZXQvc2N0cC5oPgorCisj aW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL2luX2Nrc3VtLmg+Cisj aW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgorI2luY2x1ZGUgPHN5cy9idXMuaD4KKyNpbmNs dWRlIDxzeXMvcm1hbi5oPgorCisjaW5jbHVkZSA8ZGV2L3ZpcnRpby92aXJ0aW8uaD4KKyNpbmNs dWRlIDxkZXYvdmlydGlvL3ZpcnRxdWV1ZS5oPgorI2luY2x1ZGUgPGRldi92aXJ0aW8vbmV0d29y ay92aXJ0aW9fbmV0X3JlZy5oPgorCisjaW5jbHVkZSAidmlydGlvX2J1c19pZi5oIgorI2luY2x1 ZGUgInZpcnRpb19pZi5oIgorCitzdHJ1Y3QgdnRuZXRfc3RhdGlzdGljcyB7CisJdW5zaWduZWQg bG9uZwltYnVmX2FsbG9jX2ZhaWxlZDsKKworCS8qIFJ4IHN0YXRpc3RpY3MuICovCisJdW5zaWdu ZWQgbG9uZwlyeF9tZXJnZWFibGVfZmFpbGVkOworCXVuc2lnbmVkIGxvbmcJcnhfY3N1bV9vZmZs b2FkZWQ7CisJdW5zaWduZWQgbG9uZwlyeF9jc3VtX3Vua25vd25fZXR5cGU7CisJdW5zaWduZWQg bG9uZwlyeF9jc3VtX2JhZF9zdGFydDsKKwl1bnNpZ25lZCBsb25nCXJ4X2NzdW1fdW5rbm93bl9p cHByb3RvOworCXVuc2lnbmVkIGxvbmcJcnhfY3N1bV9iYWRfb2Zmc2V0OworCisJLyogVHggc3Rh dGlzdGljcy4gKi8KKwl1bnNpZ25lZCBsb25nCXR4X2VucXVldWVfZmFpbGVkOworCXVuc2lnbmVk IGxvbmcJdHhfY3N1bV9vZmZsb2FkZWQ7CisJdW5zaWduZWQgbG9uZwl0eF9jc3VtX3Vua25vd25f ZXR5cGU7CisJdW5zaWduZWQgbG9uZwl0eF90c29fdW5rbm93bl9ldHlwZTsKK307CisKK3N0cnVj dCB2dG5ldF9zb2Z0YyB7CisJZGV2aWNlX3QJCSB2dG5ldF9kZXY7CisJc3RydWN0IGlmbmV0CQkq dnRuZXRfaWZwOworCXN0cnVjdCBtdHgJCSB2dG5ldF9tdHg7CisKKwl1aW50MzJfdAkJIHZ0bmV0 X2ZsYWdzOworI2RlZmluZSBWVE5FVF9GTEFHX0xJTksJCSAweDAwMDEKKyNkZWZpbmUgVlRORVRf RkxBR19TVVNQRU5ERUQJIDB4MDAwMgorI2RlZmluZSBWVE5FVF9GTEFHX0NUUkxfVlEJIDB4MDAw NAorI2RlZmluZSBWVE5FVF9GTEFHX0NUUkxfUlgJIDB4MDAwOAorI2RlZmluZSBWVE5FVF9GTEFH X1ZMQU5fRklMVEVSCSAweDAwMTAKKyNkZWZpbmUgVlRORVRfRkxBR19IV19DU1VNCSAweDAwMjAK KyNkZWZpbmUgVlRORVRfRkxBR19UU09fRUNOCSAweDAwNDAKKyNkZWZpbmUgVlRORVRfRkxBR19N UkdfUlhCVUZTCSAweDAwODAKKworCXN0cnVjdCB2aXJ0cXVldWUJKnZ0bmV0X3J4X3ZxOworCXN0 cnVjdCB2aXJ0cXVldWUJKnZ0bmV0X3R4X3ZxOworCXN0cnVjdCB2aXJ0cXVldWUJKnZ0bmV0X2N0 cmxfdnE7CisKKwlpbnQJCQkgdnRuZXRfaGRyX3NpemU7CisJaW50CQkJIHZ0bmV0X3J4X3NpemU7 CisJaW50CQkJIHZ0bmV0X3J4X3Byb2Nlc3NfbGltaXQ7CisJaW50CQkJIHZ0bmV0X3J4X21idWZf c2l6ZTsKKwlpbnQJCQkgdnRuZXRfdHhfc2l6ZTsKKwlpbnQJCQkgdnRuZXRfdHhfaGl3YXQ7CisJ aW50CQkgCSB2dG5ldF9pZl9mbGFnczsKKwlpbnQJCQkgdnRuZXRfd2F0Y2hkb2dfdGltZXI7CisJ dWludDMyX3QJCSB2dG5ldF9mZWF0dXJlczsKKworCXN0cnVjdCB0YXNrcXVldWUJKnZ0bmV0X3Rx OworCXN0cnVjdCB0YXNrCQkgdnRuZXRfcnhfaW50cl90YXNrOworCXN0cnVjdCB0YXNrCQkgdnRu ZXRfdHhfaW50cl90YXNrOworCXN0cnVjdCB0YXNrCQkgdnRuZXRfdHhfdGFzazsKKwlzdHJ1Y3Qg dGFzawkJIHZ0bmV0X2NmZ2NoZ190YXNrOworCisJc3RydWN0IHZ0bmV0X3N0YXRpc3RpY3MJIHZ0 bmV0X3N0YXRzOworCisJc3RydWN0IGNhbGxvdXQJCSB2dG5ldF90aWNrX2NoOworCisJZXZlbnRo YW5kbGVyX3RhZwkgdnRuZXRfdmxhbl9hdHRhY2g7CisJZXZlbnRoYW5kbGVyX3RhZwkgdnRuZXRf dmxhbl9kZXRhY2g7CisKKwljaGFyCQkJIHZ0bmV0X2h3YWRkcltFVEhFUl9BRERSX0xFTl07CisK KwkvKgorCSAqIE9uIHJlc2V0LCBWTEFOJ3MgcmVnaXN0ZXJlZCB3aXRoIGhvc3QgYXJlIGxvc3Qu IFVzZQorCSAqIHRoaXMgdGFibGUgdG8gcmVtZW1iZXIgd2hhdCBWTEFOcyB3ZSdyZSBmaWx0ZXJp bmcuCisJICoKKwkgKiA0MDk2IFZMQU5zIC8gMzIgPSAxMjggZW50cmllcyBuZWVkZWQuCisJICov CisjZGVmaW5lIFZUTkVUX1ZMQU5fVEFCTEVfU1oJIDEyOAorCWludAkJCSB2dG5ldF9udmxhbnM7 CisJdWludDMyX3QJCSB2dG5ldF92bGFuX3RhYmxlW1ZUTkVUX1ZMQU5fVEFCTEVfU1pdOworfTsK KworLyoKKyAqIERhdGEgc3RydWN0dXJlIHByZXBlbmRlZCB0byBlYWNoIFJ4IG1idWYncyBkYXRh IGFyZWEgd2hlbgorICogbm90IHVzaW5nIG1lcmdlYWJsZSBSeCBidWZmZXJzLiBXaGVuIHVzaW5n IG1lcmdlYWJsZSBSeAorICogYnVmZmVycywgdGhlIGhlYWRlciBpcyBpbmxpbmUgd2l0aCB0aGUg bGVhZGluZyBtYnVmJ3MgZGF0YS4KKyAqCisgKiBQYWQgd2l0aCA0IGJ5dGVzIHRvIGtlZXAgdGhl IGhlYWRlciBhbmQgZGF0YSBhcmVhcyBub24tCisgKiBjb250aWd1b3VzIGFuZCB0aGUgZnJhbWUg cGF5bG9hZCBzdGFydGluZyBvbiBhIDQgYnl0ZQorICogYm91bmRhcnk6ICgxMCArIDQgKyAxNCkg JSA0ID09IDAuCisgKi8KKyNkZWZpbmUgVlRORVRfUlhfTUJVRl9IRUFERVJfUEFECTQKK3N0cnVj dCB2dG5ldF9yeF9tYnVmX2hlYWRlciB7CisJc3RydWN0IHZpcnRpb19uZXRfaGRyCXZyaF9oZHI7 CisJY2hhcgkJCXZyaF9wYWRbVlRORVRfUlhfTUJVRl9IRUFERVJfUEFEXTsKK30gX19wYWNrZWQ7 CisKKy8qCisgKiBTdHJ1Y3R1cmUgcHJlcGVuZGVkIHRvIGVhY2ggVHggbWJ1ZidzIGRhdGEgYXJl YSwgcmVnYXJkbGVzcyBpZgorICogbWVyZ2VhYmxlIGJ1ZmZlcnMgaGF2ZSBiZWVuIG5lZ290aWF0 ZWQuIFdoZW4gdXNpbmcgbWVyZ2VhYmxlCisgKiBidWZmZXJzLCB0aGUgYG51bV9idWZmZXJzYCBv ZiB0aGUgbWVyZ2VhYmxlIGhlYWRlciBtdXN0IGJlIHplcm8uCisgKiBUbyBtYWtlIHRoaW5ncyBl YXNpZXIsIHdlIHByZXBlbmQgdGhlIHNhbWUgc3RydWN0dXJlIHJlZ2FyZGxlc3MsCisgKiBhbmQg dXNlIGB2dG5ldF9oZHJfc2l6ZWAgYXMgdGhlIGhlYWRlciBzaXplIHdlIHRlbGwgdGhlIGhvc3Qu CisgKi8KK3N0cnVjdCB2dG5ldF90eF9tYnVmX2hlYWRlciB7CisJdW5pb24geworCQlzdHJ1Y3Qg dmlydGlvX25ldF9oZHIJCWhkcjsKKwkJc3RydWN0IHZpcnRpb19uZXRfaGRyX21yZ19yeGJ1Zglt aGRyOworCX0gdnRoX3VoZHI7CisKKwkvKiBNYWtlIGhlYWRlciBhbmQgZGF0YSBub24tY29udGln dW91cy4gKi8KKwljaGFyCQkJCQl2dGhfcGFkWzJdOworfSBfX3BhY2tlZDsKKworLyoKKyAqIEZv ciBNQUMgYWRkcmVzcyBmaWx0ZXJpbmcsIHdlJ3JlIHN1cHBvc2UgdG8gYXNzdW1lIGFuIGluZmlu aXRlIGxpbWl0LgorICogSW4gcHJhY3RpY2UsIHdlJ3JlIGxpbWl0ZWQgYnkgdGhlIGhvc3QncyBh dmFpbGFibGUgcmVzb3VyY2VzLiBJdCBtYWtlcworICogdGhpbmdzIGVhc2llciBpZiB3ZSBpbXBv c2UgYSByZWFzb25hYmxlIGxpbWl0IG9uIG91cnNlbHZlcywgZW5zdXJpbmcKKyAqIHRoZSByZXN1 bHRpbmcgdW5pY2FzdCBhbmQgbXVsdGljYXN0IHRhYmxlcyBmaXQgaW4gb25lIHBhZ2UuCisgKi8K KyNkZWZpbmUgVlRORVRfTUFYX01BQ19FTlRSSUVTCTI1Ngorc3RydWN0IHZ0bmV0X21hY190YWJs ZSB7CisJdWludDMyX3QJbmVudHJpZXM7CisJdWludDhfdCAJbWFjc1tWVE5FVF9NQVhfTUFDX0VO VFJJRVNdW0VUSEVSX0FERFJfTEVOXTsKK30gX19wYWNrZWQ7CisKK3N0cnVjdCB2dG5ldF9tYWNf ZmlsdGVyIHsKKwlzdHJ1Y3QgdnRuZXRfbWFjX3RhYmxlCXZtZl91bmk7CisKKwkvKiBQYWQgdG8g bWFrZSB0aGUgdW5pY2FzdCBhbmQgbXVsdGljYXN0IHRhYmxlcyBub24tY29udGlndW91cy4gKi8K Kwl1aW50MTZfdAkJdm1mX3BhZDsKKworCXN0cnVjdCB2dG5ldF9tYWNfdGFibGUJdm1mX211bDsK K307CitDVEFTU0VSVChzaXplb2Yoc3RydWN0IHZ0bmV0X21hY19maWx0ZXIpIDw9IFBBR0VfU0la RSk7CisKK3N0YXRpYyBzdHJ1Y3QgdmlydGlvX2ZlYXR1cmVfZGVzYyB2dG5ldF9mZWF0dXJlX2Rl c2NbXSA9IHsKKwl7IFZJUlRJT19ORVRfRl9DU1VNLAkJIlR4Q2hlY2tzdW0iCX0sCisJeyBWSVJU SU9fTkVUX0ZfR1VFU1RfQ1NVTSwJIlJ4Q2hlY2tzdW0iCX0sCisJeyBWSVJUSU9fTkVUX0ZfTUFD LAkJIk1hY0FkZHJlc3MiCX0sCisJeyBWSVJUSU9fTkVUX0ZfR1NPLAkJIlR4QWxsR1NPIgl9LAor CXsgVklSVElPX05FVF9GX0dVRVNUX1RTTzQsCSJSeFRTT3Y0Igl9LAorCXsgVklSVElPX05FVF9G X0dVRVNUX1RTTzYsCSJSeFRTT3Y2Igl9LAorCXsgVklSVElPX05FVF9GX0dVRVNUX0VDTiwJIlJ4 RUNOIgkJfSwKKwl7IFZJUlRJT19ORVRfRl9HVUVTVF9VRk8sCSJSeFVGTyIJCX0sCisJeyBWSVJU SU9fTkVUX0ZfSE9TVF9UU080LAkiVHhUU092NCIJfSwKKwl7IFZJUlRJT19ORVRfRl9IT1NUX1RT TzYsCSJUeFRTT3Y2Igl9LAorCXsgVklSVElPX05FVF9GX0hPU1RfRUNOLAkiVHhUU09FQ04iCX0s CisJeyBWSVJUSU9fTkVUX0ZfSE9TVF9VRk8sCSJUeFVGTyIJCX0sCisJeyBWSVJUSU9fTkVUX0Zf TVJHX1JYQlVGLAkiTXJnUnhCdWYiCX0sCisJeyBWSVJUSU9fTkVUX0ZfU1RBVFVTLAkJIlN0YXR1 cyIJfSwKKwl7IFZJUlRJT19ORVRfRl9DVFJMX1ZRLAkJIkNvbnRyb2xWcSIJfSwKKwl7IFZJUlRJ T19ORVRfRl9DVFJMX1JYLAkJIlJ4TW9kZSIJfSwKKwl7IFZJUlRJT19ORVRfRl9DVFJMX1ZMQU4s CSJWTGFuRmlsdGVyIgl9LAorCXsgVklSVElPX05FVF9GX0NUUkxfUlhfRVhUUkEsCSJSeE1vZGVF eHRyYSIJfSwKKworCXsgMCwgTlVMTCB9Cit9OworCitzdGF0aWMgaW50CXZ0bmV0X3Byb2JlKGRl dmljZV90KTsKK3N0YXRpYyBpbnQJdnRuZXRfYXR0YWNoKGRldmljZV90KTsKK3N0YXRpYyBpbnQg CXZ0bmV0X2RldGFjaChkZXZpY2VfdCk7CitzdGF0aWMgaW50CXZ0bmV0X3N1c3BlbmQoZGV2aWNl X3QpOworc3RhdGljIGludAl2dG5ldF9yZXN1bWUoZGV2aWNlX3QpOworc3RhdGljIGludAl2dG5l dF9zaHV0ZG93bihkZXZpY2VfdCk7CitzdGF0aWMgaW50CXZ0bmV0X2NvbmZpZ19jaGFuZ2UoZGV2 aWNlX3QpOworCitzdGF0aWMgdm9pZAl2dG5ldF9uZWdvdGlhdGVfZmVhdHVyZXMoc3RydWN0IHZ0 bmV0X3NvZnRjICopOworc3RhdGljIGludAl2dG5ldF9hbGxvY192aXJ0cXVldWVzKHN0cnVjdCB2 dG5ldF9zb2Z0YyAqKTsKK3N0YXRpYyB2b2lkCXZ0bmV0X2dldF9od2FkZHIoc3RydWN0IHZ0bmV0 X3NvZnRjICopOworc3RhdGljIHZvaWQJdnRuZXRfc2V0X2h3YWRkcihzdHJ1Y3QgdnRuZXRfc29m dGMgKik7CitzdGF0aWMgdm9pZAl2dG5ldF91cGRhdGVfbGlua19zdGF0dXMoc3RydWN0IHZ0bmV0 X3NvZnRjICopOworc3RhdGljIHZvaWQJdnRuZXRfd2F0Y2hkb2coc3RydWN0IHZ0bmV0X3NvZnRj ICopOworc3RhdGljIHZvaWQJdnRuZXRfY29uZmlnX2NoYW5nZV90YXNrKHZvaWQgKiwgaW50KTsK K3N0YXRpYyBpbnQJdnRuZXRfY2hhbmdlX210dShzdHJ1Y3QgdnRuZXRfc29mdGMgKiwgaW50KTsK K3N0YXRpYyBpbnQJdnRuZXRfaW9jdGwoc3RydWN0IGlmbmV0ICosIHVfbG9uZywgY2FkZHJfdCk7 CisKK3N0YXRpYyBpbnQJdnRuZXRfaW5pdF9yeF92cShzdHJ1Y3QgdnRuZXRfc29mdGMgKik7Citz dGF0aWMgdm9pZAl2dG5ldF9mcmVlX3J4X21idWZzKHN0cnVjdCB2dG5ldF9zb2Z0YyAqKTsKK3N0 YXRpYyB2b2lkCXZ0bmV0X2ZyZWVfdHhfbWJ1ZnMoc3RydWN0IHZ0bmV0X3NvZnRjICopOworc3Rh dGljIHZvaWQJdnRuZXRfZnJlZV9jdHJsX3ZxKHN0cnVjdCB2dG5ldF9zb2Z0YyAqKTsKKworI2lm ZGVmIERFVklDRV9QT0xMSU5HCitzdGF0aWMgcG9sbF9oYW5kbGVyX3QgdnRuZXRfcG9sbDsKKyNl bmRpZgorCitzdGF0aWMgaW50CXZ0bmV0X25ld2J1ZihzdHJ1Y3QgdnRuZXRfc29mdGMgKik7Citz dGF0aWMgdm9pZAl2dG5ldF9kaXNjYXJkX21lcmdlZF9yeGJ1ZihzdHJ1Y3QgdnRuZXRfc29mdGMg KiwgaW50KTsKK3N0YXRpYyB2b2lkCXZ0bmV0X2Rpc2NhcmRfcnhidWYoc3RydWN0IHZ0bmV0X3Nv ZnRjICosIHN0cnVjdCBtYnVmICopOworc3RhdGljIGludAl2dG5ldF9lbnF1ZXVlX3J4YnVmKHN0 cnVjdCB2dG5ldF9zb2Z0YyAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKK3N0YXRpYyB2b2lkCXZ0bmV0X3Zs YW5fdGFnX3JlbW92ZShzdHJ1Y3QgbWJ1ZiAqKTsKK3N0YXRpYyBpbnQJdnRuZXRfcnhfY3N1bShz dHJ1Y3QgdnRuZXRfc29mdGMgKiwgc3RydWN0IG1idWYgKiwKKwkJICAgIHN0cnVjdCB2aXJ0aW9f bmV0X2hkciAqKTsKK3N0YXRpYyBpbnQJdnRuZXRfcnhlb2ZfbWVyZ2VkKHN0cnVjdCB2dG5ldF9z b2Z0YyAqLCBzdHJ1Y3QgbWJ1ZiAqLAorCQkgICAgaW50KTsKK3N0YXRpYyBpbnQJdnRuZXRfcnhl b2Yoc3RydWN0IHZ0bmV0X3NvZnRjICosIGludCwgaW50ICopOworc3RhdGljIHZvaWQJdnRuZXRf cnhfaW50cl90YXNrKHZvaWQgKiwgaW50KTsKK3N0YXRpYyBpbnQJdnRuZXRfcnhfdnFfaW50cih2 b2lkICopOworCitzdGF0aWMgdm9pZAl2dG5ldF90eGVvZihzdHJ1Y3QgdnRuZXRfc29mdGMgKik7 CitzdGF0aWMgc3RydWN0IG1idWYgKiB2dG5ldF92bGFuX3RhZ19pbnNlcnQoc3RydWN0IG1idWYg Kik7CitzdGF0aWMgc3RydWN0IG1idWYgKiB2dG5ldF9nZXRfZnJhbWVfdHlwZShzdHJ1Y3QgbWJ1 ZiAqLCB1aW50MTZfdCAqLCBpbnQgKik7CitzdGF0aWMgc3RydWN0IG1idWYgKiB2dG5ldF9zZXR1 cF90c28oc3RydWN0IHZ0bmV0X3NvZnRjICosIHN0cnVjdCBtYnVmICosCisJCSAgICBzdHJ1Y3Qg dmlydGlvX25ldF9oZHIgKiwgdWludDE2X3QsIGludCk7CitzdGF0aWMgc3RydWN0IG1idWYgKiB2 dG5ldF90eF9jc3VtKHN0cnVjdCB2dG5ldF9zb2Z0YyAqLCBzdHJ1Y3QgbWJ1ZiAqLAorCQkgICAg c3RydWN0IHZpcnRpb19uZXRfaGRyICosIHVpbnQxNl90LCBpbnQpOworc3RhdGljIGludAl2dG5l dF9lbnF1ZXVlX3R4YnVmKHN0cnVjdCB2dG5ldF9zb2Z0YyAqLCBzdHJ1Y3QgbWJ1ZiAqKiwKKwkJ ICAgIHN0cnVjdCB2dG5ldF90eF9tYnVmX2hlYWRlciAqKTsKK3N0YXRpYyBpbnQJdnRuZXRfZW5j YXAoc3RydWN0IHZ0bmV0X3NvZnRjICosIHN0cnVjdCBtYnVmICoqKTsKK3N0YXRpYyB2b2lkCXZ0 bmV0X3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKik7CitzdGF0aWMgdm9pZAl2dG5ldF9zdGFy dChzdHJ1Y3QgaWZuZXQgKik7CitzdGF0aWMgdm9pZAl2dG5ldF90eF90YXNrKHZvaWQgKiwgaW50 KTsKK3N0YXRpYyB2b2lkCXZ0bmV0X3RpY2sodm9pZCAqKTsKK3N0YXRpYyB2b2lkCXZ0bmV0X3R4 X2ludHJfdGFzayh2b2lkICosIGludCk7CitzdGF0aWMgaW50CXZ0bmV0X3R4X3ZxX2ludHIodm9p ZCAqKTsKKworc3RhdGljIHZvaWQJdnRuZXRfc3RvcChzdHJ1Y3QgdnRuZXRfc29mdGMgKik7Citz dGF0aWMgaW50CXZ0bmV0X3JlaW5pdChzdHJ1Y3QgdnRuZXRfc29mdGMgKik7CitzdGF0aWMgdm9p ZAl2dG5ldF9pbml0X2xvY2tlZChzdHJ1Y3QgdnRuZXRfc29mdGMgKik7CitzdGF0aWMgdm9pZAl2 dG5ldF9pbml0KHZvaWQgKik7CisKK3N0YXRpYyB2b2lkCXZ0bmV0X2V4ZWNfY3RybF9jbWQoc3Ry dWN0IHZ0bmV0X3NvZnRjICosIHZvaWQgKiwKKwkJICAgIHN0cnVjdCBzZ2xpc3QgKiwgaW50LCBp bnQpOworCitzdGF0aWMgdm9pZAl2dG5ldF9yeF9maWx0ZXIoc3RydWN0IHZ0bmV0X3NvZnRjICpz Yyk7CitzdGF0aWMgaW50CXZ0bmV0X2N0cmxfcnhfY21kKHN0cnVjdCB2dG5ldF9zb2Z0YyAqLCBp bnQsIGludCk7CitzdGF0aWMgaW50CXZ0bmV0X3NldF9wcm9taXNjKHN0cnVjdCB2dG5ldF9zb2Z0 YyAqLCBpbnQpOworc3RhdGljIGludAl2dG5ldF9zZXRfYWxsbXVsdGkoc3RydWN0IHZ0bmV0X3Nv ZnRjICosIGludCk7CitzdGF0aWMgdm9pZAl2dG5ldF9yeF9maWx0ZXJfbWFjKHN0cnVjdCB2dG5l dF9zb2Z0YyAqKTsKKworc3RhdGljIGludAl2dG5ldF9leGVjX3ZsYW5fZmlsdGVyKHN0cnVjdCB2 dG5ldF9zb2Z0YyAqLCBpbnQsIHVpbnQxNl90KTsKK3N0YXRpYyB2b2lkCXZ0bmV0X3J4X2ZpbHRl cl92bGFuKHN0cnVjdCB2dG5ldF9zb2Z0YyAqKTsKK3N0YXRpYyB2b2lkCXZ0bmV0X3NldF92bGFu X2ZpbHRlcihzdHJ1Y3QgdnRuZXRfc29mdGMgKiwgaW50LCB1aW50MTZfdCk7CitzdGF0aWMgdm9p ZAl2dG5ldF9yZWdpc3Rlcl92bGFuKHZvaWQgKiwgc3RydWN0IGlmbmV0ICosIHVpbnQxNl90KTsK K3N0YXRpYyB2b2lkCXZ0bmV0X3VucmVnaXN0ZXJfdmxhbih2b2lkICosIHN0cnVjdCBpZm5ldCAq LCB1aW50MTZfdCk7CisKK3N0YXRpYyB2b2lkCXZ0bmV0X2FkZF9zdGF0aXN0aWNzKHN0cnVjdCB2 dG5ldF9zb2Z0YyAqKTsKKworc3RhdGljIGludAl2dG5ldF9lbmFibGVfcnhfaW50cihzdHJ1Y3Qg dnRuZXRfc29mdGMgKik7CitzdGF0aWMgaW50CXZ0bmV0X2VuYWJsZV90eF9pbnRyKHN0cnVjdCB2 dG5ldF9zb2Z0YyAqKTsKK3N0YXRpYyB2b2lkCXZ0bmV0X2Rpc2FibGVfcnhfaW50cihzdHJ1Y3Qg dnRuZXRfc29mdGMgKik7CitzdGF0aWMgdm9pZAl2dG5ldF9kaXNhYmxlX3R4X2ludHIoc3RydWN0 IHZ0bmV0X3NvZnRjICopOworc3RhdGljIHZvaWQJdnRuZXRfZGlzYWJsZV9jdHJsX2ludHIoc3Ry dWN0IHZ0bmV0X3NvZnRjICopOworCisvKiBGZWF0dXJlcyBkZXNpcmVkL2ltcGxlbWVudGVkIGJ5 IHRoaXMgZHJpdmVyLiAqLworI2RlZmluZSBWVE5FVF9JTVBMX0ZFQVRVUkVTIFwKKyAgICAoVklS VElPX05FVF9GX01BQyB8IFZJUlRJT19ORVRfRl9TVEFUVVMgfCBWSVJUSU9fTkVUX0ZfQ1RSTF9W UQl8IFwKKyAgICAgVklSVElPX05FVF9GX0NUUkxfUlggfCBWSVJUSU9fTkVUX0ZfQ1RSTF9WTEFO CQkJfCBcCisgICAgIFZJUlRJT19ORVRfRl9DU1VNIHwgVklSVElPX05FVF9GX0hPU1RfVFNPNCB8 IFZJUlRJT19ORVRfRl9IT1NUX0VDTgl8IFwKKyAgICAgVklSVElPX05FVF9GX0dVRVNUX0NTVU0g fCBWSVJUSU9fTkVUX0ZfTVJHX1JYQlVGCQkJfCBcCisgICAgIFZJUlRJT19GX05PVElGWV9PTl9F TVBUWSB8IFZJUlRJT19GX1JJTkdfSU5ESVJFQ1RfREVTQykKKworLyogRmVhdHVyZXMgb25seSBh dmFpbGFibGUgd2l0aCBWSVJUSU9fTkVUX0ZfQ1NVTSAoVHgpLiAqLworI2RlZmluZSBWVE5FVF9I T1NUX0NTVU1fRkVBVFVSRVMgXAorICAgIChWSVJUSU9fTkVUX0ZfSE9TVF9UU080IHwgVklSVElP X05FVF9GX0hPU1RfVFNPNiB8IFwKKyAgICAgVklSVElPX05FVF9GX0hPU1RfRUNOIHwgVklSVElP X05FVF9GX0hPU1RfVUZPKQorCisvKiBGZWF0dXJlcyBvbmx5IGF2YWlsYWJsZSB3aXRoIFZJUlRJ T19ORVRfRl9HVUVTVF9DU1VNIChSeCkuICovCisjZGVmaW5lIFZUTkVUX0dVRVNUX0NTVU1fRkVB VFVSRVMgXAorICAgIChWSVJUSU9fTkVUX0ZfR1VFU1RfVFNPNCB8IFZJUlRJT19ORVRfRl9HVUVT VF9UU082IHwgXAorICAgICBWSVJUSU9fTkVUX0ZfR1VFU1RfRUNOIHwgVklSVElPX05FVF9GX0dV RVNUX1VGTykKKworLyoKKyAqIFVzZWQgdG8gcHJlYWxsb2NhdGUgdGhlIFZxIGluZGlyZWN0IGRl c2NyaXB0b3JzLiBPbmUgc2VnbWVudAorICogaXMgcmVzZXJ2ZWQgZm9yIHRoZSBoZWFkZXIuCisg Ki8KKyNkZWZpbmUgVlRORVRfTUFYX1JYX1NFR1MJMgorI2RlZmluZSBWVE5FVF9NQVhfVFhfU0VH UwkzMworCisjZGVmaW5lIFZUTkVUX01BWF9NVFUJCTY1NTM2CisKKy8qIEFzc2VydCB3ZSBjYW4g dHJhbnNtaXQgTUFYX01UVSB3aXRoIHJlZ3VsYXIgc2l6ZSBjbHVzdGVycy4gKi8KK0NUQVNTRVJU KCgoVlRORVRfTUFYX1RYX1NFR1MgLSAxKSAqIE1DTEJZVEVTKSA+PSBWVE5FVF9NQVhfTVRVKTsK KworI2RlZmluZSBWVE5FVF9DU1VNX0ZFQVRVUkVTCShDU1VNX1RDUCB8IENTVU1fVURQKQorCisj ZGVmaW5lIFZUTkVUX1dBVENIRE9HX1RJTUVPVVQJNQorCisjZGVmaW5lIFZUTkVUX01UWChfc2Mp CQkmKF9zYyktPnZ0bmV0X210eAorI2RlZmluZSBWVE5FVF9MT0NLX0lOSVQoX3NjLCBfbmFtZSkg XAorCQkJCW10eF9pbml0KFZUTkVUX01UWCgoX3NjKSksIF9uYW1lLCBcCisJCQkJICAgICJWVE5F VCBMb2NrIiwgTVRYX0RFRikKKyNkZWZpbmUgVlRORVRfTE9DSyhfc2MpCQltdHhfbG9jayhWVE5F VF9NVFgoKF9zYykpKQorI2RlZmluZSBWVE5FVF9VTkxPQ0soX3NjKQltdHhfdW5sb2NrKFZUTkVU X01UWCgoX3NjKSkpCisjZGVmaW5lIFZUTkVUX0xPQ0tfREVTVFJPWShfc2MpCW10eF9kZXN0cm95 KFZUTkVUX01UWCgoX3NjKSkpCisjZGVmaW5lIFZUTkVUX0xPQ0tfQVNTRVJUKF9zYykJbXR4X2Fz c2VydChWVE5FVF9NVFgoKF9zYykpLCBNQV9PV05FRCkKKyNkZWZpbmUgVlRORVRfTE9DS19BU1NF UlRfTk9UT1dORUQoX3NjKSBcCisgICAgCQkJCW10eF9hc3NlcnQoVlRORVRfTVRYKChfc2MpKSwg TUFfTk9UT1dORUQpCisKKy8qIFR1bmFibGVzLiAqLworc3RhdGljIGludCB2dG5ldF9jc3VtX2Rp c2FibGUgPSAwOworVFVOQUJMRV9JTlQoImh3LnZ0bmV0LmNzdW1fZGlzYWJsZSIsICZ2dG5ldF9j c3VtX2Rpc2FibGUpOworc3RhdGljIGludCB2dG5ldF90c29fZGlzYWJsZSA9IDA7CitUVU5BQkxF X0lOVCgiaHcudnRuZXQudHNvX2Rpc2FibGUiLCAmdnRuZXRfdHNvX2Rpc2FibGUpOworc3RhdGlj IGludCB2dG5ldF9scm9fZGlzYWJsZSA9IDE7CitUVU5BQkxFX0lOVCgiaHcudnRuZXQubHJvX2Rp c2FibGUiLCAmdnRuZXRfbHJvX2Rpc2FibGUpOworCitzdGF0aWMgZGV2aWNlX21ldGhvZF90IHZ0 bmV0X21ldGhvZHNbXSA9IHsKKwkvKiBEZXZpY2UgbWV0aG9kcy4gKi8KKwlERVZNRVRIT0QoZGV2 aWNlX3Byb2JlLAkJdnRuZXRfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLAl2dG5l dF9hdHRhY2gpLAorCURFVk1FVEhPRChkZXZpY2VfZGV0YWNoLAl2dG5ldF9kZXRhY2gpLAorCURF Vk1FVEhPRChkZXZpY2Vfc3VzcGVuZCwJdnRuZXRfc3VzcGVuZCksCisJREVWTUVUSE9EKGRldmlj ZV9yZXN1bWUsCXZ0bmV0X3Jlc3VtZSksCisJREVWTUVUSE9EKGRldmljZV9zaHV0ZG93biwJdnRu ZXRfc2h1dGRvd24pLAorCisJLyogVmlydElPIG1ldGhvZHMuICovCisJREVWTUVUSE9EKHZpcnRp b19jb25maWdfY2hhbmdlLCB2dG5ldF9jb25maWdfY2hhbmdlKSwKKworCXsgMCwgMCB9Cit9Owor CitzdGF0aWMgZHJpdmVyX3QgdnRuZXRfZHJpdmVyID0geworCSJ2dG5ldCIsCisJdnRuZXRfbWV0 aG9kcywKKwlzaXplb2Yoc3RydWN0IHZ0bmV0X3NvZnRjKQorfTsKK3N0YXRpYyBkZXZjbGFzc190 IHZ0bmV0X2RldmNsYXNzOworCitEUklWRVJfTU9EVUxFKHZ0bmV0LCB2aXJ0aW9fcGNpLCB2dG5l dF9kcml2ZXIsIHZ0bmV0X2RldmNsYXNzLCAwLCAwKTsKK01PRFVMRV9WRVJTSU9OKHZ0bmV0LCAx KTsKK01PRFVMRV9ERVBFTkQodnRuZXQsIHZpcnRpbywgMSwgMSwgMSk7CisKK3N0YXRpYyBpbnQK K3Z0bmV0X3Byb2JlKGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3QgdmlydGlvX2l2YXJzICppdmFy czsKKworCWl2YXJzID0gZGV2aWNlX2dldF9pdmFycyhkZXYpOworCWlmIChpdmFycyA9PSBOVUxM KQorCQlyZXR1cm4gKEVOWElPKTsKKworCWlmIChpdmFycy0+dnRpdmFyX2RldnR5cGUgIT0gVklS VElPX0lEX05FVFdPUkspCisJCXJldHVybiAoRU5YSU8pOworCisJZGV2aWNlX3NldF9kZXNjKGRl diwgIlZpcnRJTyBOZXR3b3JraW5nIEFkYXB0ZXIiKTsKKworCXJldHVybiAoQlVTX1BST0JFX0RF RkFVTFQpOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9hdHRhY2goZGV2aWNlX3QgZGV2KQorewor CXN0cnVjdCB2dG5ldF9zb2Z0YyAqc2M7CisJc3RydWN0IHZpcnRpb19pdmFycyAqaXZhcnM7CisJ c3RydWN0IGlmbmV0ICppZnA7CisJaW50IHR4X3NpemU7CisJaW50IGVycm9yOworCisJc2MgPSBk ZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnZ0bmV0X2RldiA9IGRldjsKKworCVZUTkVUX0xP Q0tfSU5JVChzYywgZGV2aWNlX2dldF9uYW1ldW5pdChkZXYpKTsKKwljYWxsb3V0X2luaXRfbXR4 KCZzYy0+dnRuZXRfdGlja19jaCwgVlRORVRfTVRYKHNjKSwgMCk7CisKKwkvKiBBdHRhY2ggc3Rh dGlzdGljcyBzeXNjdGwuICovCisJdnRuZXRfYWRkX3N0YXRpc3RpY3Moc2MpOworCisJaXZhcnMg PSBkZXZpY2VfZ2V0X2l2YXJzKGRldik7CisJaXZhcnMtPnZ0aXZhcl9mZWF0dXJlcyA9IHZ0bmV0 X2ZlYXR1cmVfZGVzYzsKKworCXZ0bmV0X25lZ290aWF0ZV9mZWF0dXJlcyhzYyk7CisKKwlpZiAo dmlydGlvX3dpdGhfZmVhdHVyZShkZXYsIFZJUlRJT19ORVRfRl9NUkdfUlhCVUYpKSB7CisJCXNj LT52dG5ldF9mbGFncyB8PSBWVE5FVF9GTEFHX01SR19SWEJVRlM7CisJCXNjLT52dG5ldF9oZHJf c2l6ZSA9IHNpemVvZihzdHJ1Y3QgdmlydGlvX25ldF9oZHJfbXJnX3J4YnVmKTsKKwl9IGVsc2UK KwkJc2MtPnZ0bmV0X2hkcl9zaXplID0gc2l6ZW9mKHN0cnVjdCB2aXJ0aW9fbmV0X2hkcik7CisK KwlzYy0+dnRuZXRfcnhfbWJ1Zl9zaXplID0gTUNMQllURVM7CisKKwlpZiAodmlydGlvX3dpdGhf ZmVhdHVyZShkZXYsIFZJUlRJT19ORVRfRl9DVFJMX1ZRKSkgeworCQlzYy0+dnRuZXRfZmxhZ3Mg fD0gVlRORVRfRkxBR19DVFJMX1ZROworCisJCWlmICh2aXJ0aW9fd2l0aF9mZWF0dXJlKGRldiwg VklSVElPX05FVF9GX0NUUkxfUlgpKQorCQkJc2MtPnZ0bmV0X2ZsYWdzIHw9IFZUTkVUX0ZMQUdf Q1RSTF9SWDsKKwkJaWYgKHZpcnRpb193aXRoX2ZlYXR1cmUoZGV2LCBWSVJUSU9fTkVUX0ZfQ1RS TF9WTEFOKSkKKwkJCXNjLT52dG5ldF9mbGFncyB8PSBWVE5FVF9GTEFHX1ZMQU5fRklMVEVSOwor CX0KKworCXZ0bmV0X2dldF9od2FkZHIoc2MpOworCisJZXJyb3IgPSB2dG5ldF9hbGxvY192aXJ0 cXVldWVzKHNjKTsKKwlpZiAoZXJyb3IpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJjYW5ub3Qg YWxsb2NhdGUgdmlydHF1ZXVlc1xuIik7CisJCWdvdG8gZmFpbDsKKwl9CisKKwlpZnAgPSBzYy0+ dnRuZXRfaWZwID0gaWZfYWxsb2MoSUZUX0VUSEVSKTsKKwlpZiAoaWZwID09IE5VTEwpIHsKKwkJ ZGV2aWNlX3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgaWZuZXQgc3RydWN0dXJlXG4iKTsK KwkJZXJyb3IgPSBFTk9TUEM7CisJCWdvdG8gZmFpbDsKKwl9CisKKwlpZnAtPmlmX3NvZnRjID0g c2M7CisJaWZfaW5pdG5hbWUoaWZwLCBkZXZpY2VfZ2V0X25hbWUoZGV2KSwgZGV2aWNlX2dldF91 bml0KGRldikpOworCWlmcC0+aWZfZmxhZ3MgPSBJRkZfQlJPQURDQVNUIHwgSUZGX1NJTVBMRVgg fCBJRkZfTVVMVElDQVNUOworCWlmcC0+aWZfaW5pdCA9IHZ0bmV0X2luaXQ7CisJaWZwLT5pZl9z dGFydCA9IHZ0bmV0X3N0YXJ0OworCWlmcC0+aWZfaW9jdGwgPSB2dG5ldF9pb2N0bDsKKworCXNj LT52dG5ldF9yeF9zaXplID0gdmlydHF1ZXVlX3NpemUoc2MtPnZ0bmV0X3J4X3ZxKTsKKwlzYy0+ dnRuZXRfcnhfcHJvY2Vzc19saW1pdCA9IChzYy0+dnRuZXRfcnhfc2l6ZSAqIDMpIC8gNDsKKwor CXR4X3NpemUgPSB2aXJ0cXVldWVfc2l6ZShzYy0+dnRuZXRfdHhfdnEpOworCXNjLT52dG5ldF90 eF9zaXplID0gdHhfc2l6ZTsKKwlzYy0+dnRuZXRfdHhfaGl3YXQgPSB0eF9zaXplIC0gKCh0eF9z aXplICogMikgLyAxMCk7CisKKwlJRlFfU0VUX01BWExFTigmaWZwLT5pZl9zbmQsIHR4X3NpemUg LSAxKTsKKwlpZnAtPmlmX3NuZC5pZnFfZHJ2X21heGxlbiA9IHR4X3NpemUgLSAxOworCUlGUV9T RVRfUkVBRFkoJmlmcC0+aWZfc25kKTsKKworCWV0aGVyX2lmYXR0YWNoKGlmcCwgc2MtPnZ0bmV0 X2h3YWRkcik7CisKKwlpZiAodmlydGlvX3dpdGhfZmVhdHVyZShkZXYsIFZJUlRJT19ORVRfRl9T VEFUVVMpKQorCQlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJRkNBUF9MSU5LU1RBVEU7CisKKwkv KiBUZWxsIHRoZSB1cHBlciBsYXllcihzKSB3ZSBzdXBwb3J0IGxvbmcgZnJhbWVzLiAqLworCWlm cC0+aWZfZGF0YS5pZmlfaGRybGVuID0gc2l6ZW9mKHN0cnVjdCBldGhlcl92bGFuX2hlYWRlcik7 CisJaWZwLT5pZl9jYXBhYmlsaXRpZXMgfD0gSUZDQVBfSlVNQk9fTVRVIHwgSUZDQVBfVkxBTl9N VFU7CisKKwlpZiAodmlydGlvX3dpdGhfZmVhdHVyZShkZXYsIFZJUlRJT19ORVRfRl9DU1VNKSkg eworCQlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJRkNBUF9UWENTVU07CisKKwkJaWYgKHZpcnRp b193aXRoX2ZlYXR1cmUoZGV2LCBWSVJUSU9fTkVUX0ZfSE9TVF9UU080KSkKKwkJCWlmcC0+aWZf Y2FwYWJpbGl0aWVzIHw9IElGQ0FQX1RTTzQ7CisJCWlmICh2aXJ0aW9fd2l0aF9mZWF0dXJlKGRl diwgVklSVElPX05FVF9GX0hPU1RfVFNPNikpCisJCQlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJ RkNBUF9UU082OworCisJCWlmICh2aXJ0aW9fd2l0aF9mZWF0dXJlKGRldiwgVklSVElPX05FVF9G X0hPU1RfRUNOKSkKKwkJCXNjLT52dG5ldF9mbGFncyB8PSBWVE5FVF9GTEFHX1RTT19FQ047CisK KwkJaWYgKGlmcC0+aWZfY2FwYWJpbGl0aWVzICYgSUZDQVBfVFNPKQorCQkJaWZwLT5pZl9jYXBh YmlsaXRpZXMgfD0gSUZDQVBfVkxBTl9IV1RTTzsKKwl9CisKKwlpZiAodmlydGlvX3dpdGhfZmVh dHVyZShkZXYsIFZJUlRJT19ORVRfRl9HVUVTVF9DU1VNKSkgeworCQlpZnAtPmlmX2NhcGFiaWxp dGllcyB8PSBJRkNBUF9SWENTVU07CisKKwkJaWYgKHZpcnRpb193aXRoX2ZlYXR1cmUoZGV2LCBW SVJUSU9fTkVUX0ZfR1VFU1RfVFNPNCkgfHwKKwkJICAgIHZpcnRpb193aXRoX2ZlYXR1cmUoZGV2 LCBWSVJUSU9fTkVUX0ZfR1VFU1RfVFNPNikpCisJCQlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJ RkNBUF9MUk87CisJfQorCisJaWYgKGlmcC0+aWZfY2FwYWJpbGl0aWVzICYgSUZDQVBfSFdDU1VN KSB7CisJCS8qCisJCSAqIFZpcnRJTyBkb2VzIG5vdCBzdXBwb3J0IGBoYXJkd2FyZWAgVkxBTiB0 YWdnaW5nLiBJbnN0ZWFkCisJCSAqIHdlIGVtdWxhdGUgaXQgZHVyaW5nIHJlY2VpdmUgYW5kIHRy YW5zbWl0LCBhbmQgd2UncmUgdGhlbgorCQkgKiBhYmxlIHRvIHN1cHBvcnQgY2hlY2tzdW0gb2Zm bG9hZGluZyBvZiBWTEFOIGZyYW1lcy4KKwkJICovCisJCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9 CisJCSAgICBJRkNBUF9WTEFOX0hXVEFHR0lORyB8IElGQ0FQX1ZMQU5fSFdDU1VNOworCX0KKwor CWlmcC0+aWZfY2FwZW5hYmxlID0gaWZwLT5pZl9jYXBhYmlsaXRpZXM7CisKKwkvKgorCSAqIENh cGFiaWxpdGllcyBhZnRlciB0aGlzIGFyZSBub3QgZW5hYmxlZCBieSBkZWZhdWx0LgorCSAqLwor CisJaWYgKHNjLT52dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdfVkxBTl9GSUxURVIpIHsKKwkJaWZw LT5pZl9jYXBhYmlsaXRpZXMgfD0gSUZDQVBfVkxBTl9IV0ZJTFRFUjsKKworCQlzYy0+dnRuZXRf dmxhbl9hdHRhY2ggPSBFVkVOVEhBTkRMRVJfUkVHSVNURVIodmxhbl9jb25maWcsCisJCSAgICB2 dG5ldF9yZWdpc3Rlcl92bGFuLCBzYywgRVZFTlRIQU5ETEVSX1BSSV9GSVJTVCk7CisJCXNjLT52 dG5ldF92bGFuX2RldGFjaCA9IEVWRU5USEFORExFUl9SRUdJU1RFUih2bGFuX3VuY29uZmlnLAor CQkgICAgdnRuZXRfdW5yZWdpc3Rlcl92bGFuLCBzYywgRVZFTlRIQU5ETEVSX1BSSV9GSVJTVCk7 CisJfQorCisjaWZkZWYgREVWSUNFX1BPTExJTkcKKwlpZnAtPmlmX2NhcGFiaWxpdGllcyB8PSBJ RkNBUF9QT0xMSU5HOworI2VuZGlmCisKKwlUQVNLX0lOSVQoJnNjLT52dG5ldF90eF90YXNrLCAx LCB2dG5ldF90eF90YXNrLCBpZnApOworCVRBU0tfSU5JVCgmc2MtPnZ0bmV0X2NmZ2NoZ190YXNr LCAwLCB2dG5ldF9jb25maWdfY2hhbmdlX3Rhc2ssIHNjKTsKKworCVRBU0tfSU5JVCgmc2MtPnZ0 bmV0X3J4X2ludHJfdGFzaywgMCwgdnRuZXRfcnhfaW50cl90YXNrLCBzYyk7CisJVEFTS19JTklU KCZzYy0+dnRuZXRfdHhfaW50cl90YXNrLCAwLCB2dG5ldF90eF9pbnRyX3Rhc2ssIHNjKTsKKwor CXNjLT52dG5ldF90cSA9IHRhc2txdWV1ZV9jcmVhdGVfZmFzdCgidnRuZXRfdGFza3EiLCBNX1dB SVRPSywKKwkgICAgdGFza3F1ZXVlX3RocmVhZF9lbnF1ZXVlLCAmc2MtPnZ0bmV0X3RxKTsKKwlp ZiAoc2MtPnZ0bmV0X3RxID09IE5VTEwpIHsKKwkJZXJyb3IgPSBFTk9NRU07CisJCWRldmljZV9w cmludGYoZGV2LCAiY2Fubm90IGFsbG9jYXRlIHRhc2txdWV1ZVxuIik7CisJCWV0aGVyX2lmZGV0 YWNoKGlmcCk7CisJCWdvdG8gZmFpbDsKKwl9CisJdGFza3F1ZXVlX3N0YXJ0X3RocmVhZHMoJnNj LT52dG5ldF90cSwgMSwgUElfTkVULCAiJXMgdGFza3EiLAorCSAgICBkZXZpY2VfZ2V0X25hbWV1 bml0KGRldikpOworCisJZXJyb3IgPSB2aXJ0aW9fc2V0dXBfaW50cihkZXYsIElOVFJfVFlQRV9O RVQpOworCWlmIChlcnJvcikgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCBzZXR1cCB2 aXJ0cXVldWUgaW50ZXJydXB0c1xuIik7CisJCXRhc2txdWV1ZV9mcmVlKHNjLT52dG5ldF90cSk7 CisJCXNjLT52dG5ldF90cSA9IE5VTEw7CisJCWV0aGVyX2lmZGV0YWNoKGlmcCk7CisJCWdvdG8g ZmFpbDsKKwl9CisKKwkvKgorCSAqIEhvc3QgZGVmYXVsdHMgdG8gcHJvbWlzY3VvdXMgbW9kZSBm b3IgYmFja3dhcmRzCisJICogY29tcGF0aWJpbGl0eS4gVHVybiBpdCBvZmYgaWYgcG9zc2libGUu CisJICovCisJaWYgKHNjLT52dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdfQ1RSTF9SWCkgeworCQlW VE5FVF9MT0NLKHNjKTsKKwkJaWYgKHZ0bmV0X3NldF9wcm9taXNjKHNjLCAwKSAhPSAwKSB7CisJ CQkvKiBVbmFibGUgdG8gZGlzYWJsZSwgaW5mb3JtIHN0YWNrLiAqLworCQkJaWZwLT5pZl9mbGFn cyB8PSBJRkZfUFJPTUlTQzsKKwkJCWRldmljZV9wcmludGYoZGV2LAorCQkJICAgICJjYW5ub3Qg ZGlzYWJsZSBwcm9taXNjdW91cyBtb2RlXG4iKTsKKwkJfQorCQlWVE5FVF9VTkxPQ0soc2MpOwor CX0gZWxzZQorCQlpZnAtPmlmX2ZsYWdzIHw9IElGRl9QUk9NSVNDOworCitmYWlsOgorCWlmIChl cnJvcikKKwkJdnRuZXRfZGV0YWNoKGRldik7CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3Rh dGljIGludAordnRuZXRfZGV0YWNoKGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3QgdnRuZXRfc29m dGMgKnNjOworCXN0cnVjdCBpZm5ldCAqaWZwOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7CisJaWZwID0gc2MtPnZ0bmV0X2lmcDsKKworCUtBU1NFUlQobXR4X2luaXRpYWxpemVkKFZU TkVUX01UWChzYykpLAorCSAgICAoInZ0bmV0IG11dGV4IG5vdCBpbml0aWFsaXplZCIpKTsKKwor I2lmZGVmIERFVklDRV9QT0xMSU5HCisJaWYgKGlmcCAhPSBOVUxMICYmIGlmcC0+aWZfY2FwZW5h YmxlICYgSUZDQVBfUE9MTElORykKKwkJZXRoZXJfcG9sbF9kZXJlZ2lzdGVyKGlmcCk7CisjZW5k aWYKKworCWlmIChkZXZpY2VfaXNfYXR0YWNoZWQoZGV2KSkgeworCQlWVE5FVF9MT0NLKHNjKTsK KwkJdnRuZXRfc3RvcChzYyk7CisJCWlmcC0+aWZfZmxhZ3MgJj0gfklGRl9VUDsKKwkJVlRORVRf VU5MT0NLKHNjKTsKKworCQljYWxsb3V0X2RyYWluKCZzYy0+dnRuZXRfdGlja19jaCk7CisJCXRh c2txdWV1ZV9kcmFpbih0YXNrcXVldWVfZmFzdCwgJnNjLT52dG5ldF9jZmdjaGdfdGFzayk7CisJ CXRhc2txdWV1ZV9kcmFpbih0YXNrcXVldWVfZmFzdCwgJnNjLT52dG5ldF90eF90YXNrKTsKKwor CQlldGhlcl9pZmRldGFjaChpZnApOworCX0KKworCWlmIChzYy0+dnRuZXRfdHEgIT0gTlVMTCkg eworCQl0YXNrcXVldWVfZHJhaW4oc2MtPnZ0bmV0X3RxLCAmc2MtPnZ0bmV0X3J4X2ludHJfdGFz ayk7CisJCXRhc2txdWV1ZV9kcmFpbihzYy0+dnRuZXRfdHEsICZzYy0+dnRuZXRfdHhfaW50cl90 YXNrKTsKKwkJdGFza3F1ZXVlX2ZyZWUoc2MtPnZ0bmV0X3RxKTsKKwkJc2MtPnZ0bmV0X3RxID0g TlVMTDsKKwl9CisKKwlpZiAoc2MtPnZ0bmV0X3ZsYW5fYXR0YWNoICE9IE5VTEwpIHsKKwkJRVZF TlRIQU5ETEVSX0RFUkVHSVNURVIodmxhbl9jb25maWcsIHNjLT52dG5ldF92bGFuX2F0dGFjaCk7 CisJCXNjLT52dG5ldF92bGFuX2F0dGFjaCA9IE5VTEw7CisJfQorCWlmIChzYy0+dnRuZXRfdmxh bl9kZXRhY2ggIT0gTlVMTCkgeworCQlFVkVOVEhBTkRMRVJfREVSRUdJU1RFUih2bGFuX3VuY29u ZmcsIHNjLT52dG5ldF92bGFuX2RldGFjaCk7CisJCXNjLT52dG5ldF92bGFuX2RldGFjaCA9IE5V TEw7CisJfQorCisJaWYgKGlmcCkgeworCQlpZl9mcmVlKGlmcCk7CisJCXNjLT52dG5ldF9pZnAg PSBOVUxMOworCX0KKworCWlmIChzYy0+dnRuZXRfcnhfdnEgIT0gTlVMTCkKKwkJdnRuZXRfZnJl ZV9yeF9tYnVmcyhzYyk7CisJaWYgKHNjLT52dG5ldF90eF92cSAhPSBOVUxMKQorCQl2dG5ldF9m cmVlX3R4X21idWZzKHNjKTsKKwlpZiAoc2MtPnZ0bmV0X2N0cmxfdnEgIT0gTlVMTCkKKwkJdnRu ZXRfZnJlZV9jdHJsX3ZxKHNjKTsKKworCVZUTkVUX0xPQ0tfREVTVFJPWShzYyk7CisKKwlyZXR1 cm4gKDApOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9zdXNwZW5kKGRldmljZV90IGRldikKK3sK KwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CisKKwlWVE5FVF9MT0NLKHNjKTsKKwl2dG5ldF9zdG9wKHNjKTsKKwlzYy0+dnRuZXRfZmxhZ3Mg fD0gVlRORVRfRkxBR19TVVNQRU5ERUQ7CisJVlRORVRfVU5MT0NLKHNjKTsKKworCXJldHVybiAo MCk7Cit9CisKK3N0YXRpYyBpbnQKK3Z0bmV0X3Jlc3VtZShkZXZpY2VfdCBkZXYpCit7CisJc3Ry dWN0IHZ0bmV0X3NvZnRjICpzYzsKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKworCXNjID0gZGV2aWNl X2dldF9zb2Z0YyhkZXYpOworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisKKwlWVE5FVF9MT0NLKHNj KTsKKwlpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkKKwkJdnRuZXRfaW5pdF9sb2NrZWQoc2Mp OworCXNjLT52dG5ldF9mbGFncyAmPSB+VlRORVRfRkxBR19TVVNQRU5ERUQ7CisJVlRORVRfVU5M T0NLKHNjKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK3Z0bmV0X3NodXRkb3du KGRldmljZV90IGRldikKK3sKKworCS8qCisJICogU3VzcGVuZCBpcyBhbGwgd2UgbmVlZCB0byBk byBoZXJlLCB3ZSBqdXN0CisJICogbmV2ZXIgZXhwZWN0IHRvIGJlIHJlc3VtZWQuCisJICovCisJ cmV0dXJuICh2dG5ldF9zdXNwZW5kKGRldikpOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9jb25m aWdfY2hhbmdlKGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjOworCisJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHRh c2txdWV1ZV9mYXN0LCAmc2MtPnZ0bmV0X2NmZ2NoZ190YXNrKTsKKworCXJldHVybiAoMSk7Cit9 CisKK3N0YXRpYyB2b2lkCit2dG5ldF9uZWdvdGlhdGVfZmVhdHVyZXMoc3RydWN0IHZ0bmV0X3Nv ZnRjICpzYykKK3sKKwlkZXZpY2VfdCBkZXY7CisJdWludDMyX3QgbmV3X2ZlYXR1cmVzOworCisJ ZGV2ID0gc2MtPnZ0bmV0X2RldjsKKwluZXdfZmVhdHVyZXMgPSBWVE5FVF9JTVBMX0ZFQVRVUkVT OworCisJaWYgKHZ0bmV0X2NzdW1fZGlzYWJsZSkKKwkJbmV3X2ZlYXR1cmVzICY9CisJCSAgICB+ KFZJUlRJT19ORVRfRl9DU1VNIHwgVlRORVRfSE9TVF9DU1VNX0ZFQVRVUkVTIHwKKwkJICAgICAg VklSVElPX05FVF9GX0dVRVNUX0NTVU0gfCBWVE5FVF9HVUVTVF9DU1VNX0ZFQVRVUkVTKTsKKwor CWlmICh2dG5ldF90c29fZGlzYWJsZSkKKwkJbmV3X2ZlYXR1cmVzICY9CisJCSAgICB+KFZJUlRJ T19ORVRfRl9IT1NUX1RTTzQgfCBWSVJUSU9fTkVUX0ZfSE9TVF9UU082IHwKKwkJICAgICAgVklS VElPX05FVF9GX0hPU1RfVUZPKTsKKworCWlmICh2dG5ldF9scm9fZGlzYWJsZSkKKwkJbmV3X2Zl YXR1cmVzICY9CisJCSAgICB+KFZJUlRJT19ORVRfRl9HVUVTVF9UU080IHwgVklSVElPX05FVF9G X0dVRVNUX1RTTzYgfAorCQkgICAgICBWSVJUSU9fTkVUX0ZfR1VFU1RfVUZPKTsKKworCXNjLT52 dG5ldF9mZWF0dXJlcyA9IHZpcnRpb19uZWdvdGlhdGVfZmVhdHVyZXMoZGV2LCBuZXdfZmVhdHVy ZXMpOworCisJaWYgKHZpcnRpb193aXRoX2ZlYXR1cmUoZGV2LCBWSVJUSU9fTkVUX0ZfTVJHX1JY QlVGKSA9PSAwICYmCisJICAgKHZpcnRpb193aXRoX2ZlYXR1cmUoZGV2LCBWSVJUSU9fTkVUX0Zf R1VFU1RfVFNPNCkgfHwKKwkgICAgdmlydGlvX3dpdGhfZmVhdHVyZShkZXYsIFZJUlRJT19ORVRf Rl9HVUVTVF9UU082KSB8fAorCSAgICB2aXJ0aW9fd2l0aF9mZWF0dXJlKGRldiwgVklSVElPX05F VF9GX0dVRVNUX1VGTykpKSB7CisJCS8qCisJCSAqIFdlIGN1cnJlbnRseSBvbmx5IHN1cHBvcnQg VFNPIHJlY2VpdmUgKExSTykgd2hlbiBwYWlyZWQKKwkJICogd2l0aCBtZXJnZWFibGUgYnVmZmVy cy4gT3RoZXJ3aXNlLCBlYWNoIFJ4IGJ1ZmZlciBtdXN0CisJCSAqIGJlIGF0IGxlYXN0IDY1NTUw IGJ5dGVzIGJpZywgd2hpY2ggaXMgYSBsb3Qgb2YgbWVtb3J5IHRvCisJCSAqIGhvbGQgdXAgaW4g dGhlIHZpcnRxdWV1ZS4KKwkJICoKKwkJICogTi5CLiBXZSBkb24ndCBzdXBwb3J0IGFueSBvZiB0 aGlzIHlldCBhbnl3YXlzLgorCQkgKi8KKwkJbmV3X2ZlYXR1cmVzICY9CisJCSAgICB+KFZJUlRJ T19ORVRfRl9HVUVTVF9UU080IHwgVklSVElPX05FVF9GX0dVRVNUX1RTTzYgfAorCQkgICAgICBW SVJUSU9fTkVUX0ZfR1VFU1RfVUZPKTsKKworCQlzYy0+dnRuZXRfZmVhdHVyZXMgPSB2aXJ0aW9f bmVnb3RpYXRlX2ZlYXR1cmVzKGRldiwKKwkJICAgIG5ld19mZWF0dXJlcyk7CisJfQorfQorCitz dGF0aWMgaW50Cit2dG5ldF9hbGxvY192aXJ0cXVldWVzKHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2Mp Cit7CisJZGV2aWNlX3QgZGV2OworCXN0cnVjdCB2cV9hbGxvY19pbmZvIHZxX2luZm9bM107CisJ aW50IG52cXMsIHJ4c2VnczsKKworCWRldiA9IHNjLT52dG5ldF9kZXY7CisJbnZxcyA9IDI7CisK KwkvKgorCSAqIEluZGlyZWN0IGRlc2NyaXB0b3JzIGFyZSBub3QgbmVlZGVkIGZvciB0aGUgUngK KwkgKiB2aXJ0cXVldWUgd2hlbiBtZXJnZWFibGUgYnVmZmVycyBhcmUgbmVnb3RpYXRlZC4KKwkg KiBUaGUgaGVhZGVyIGlzIHBsYWNlZCBpbmxpbmUgd2l0aCB0aGUgZGF0YSwgbm90CisJICogaW4g YSBzZXBhcmF0ZSBkZXNjcmlwdG9yLCBhbmQgbWJ1ZiBjbHVzdGVycyBhcmUKKwkgKiBhbHdheXMg cGh5c2ljYWxseSBjb250aWd1b3VzLgorCSAqLworCXJ4c2VncyA9IHNjLT52dG5ldF9mbGFncyAm IFZUTkVUX0ZMQUdfTVJHX1JYQlVGUyA/IDAgOgorCSAgICBWVE5FVF9NQVhfUlhfU0VHUzsKKwor CVZRX0FMTE9DX0lORk9fSU5JVCgmdnFfaW5mb1swXSwgcnhzZWdzLAorCSAgICB2dG5ldF9yeF92 cV9pbnRyLCBzYywgJnNjLT52dG5ldF9yeF92cSwKKwkgICAgIiVzIHJlY2VpdmUiLCBkZXZpY2Vf Z2V0X25hbWV1bml0KGRldikpOworCisJVlFfQUxMT0NfSU5GT19JTklUKCZ2cV9pbmZvWzFdLCBW VE5FVF9NQVhfVFhfU0VHUywKKwkgICAgdnRuZXRfdHhfdnFfaW50ciwgc2MsICZzYy0+dnRuZXRf dHhfdnEsCisJICAgICIlcyB0cmFuc21pdCIsIGRldmljZV9nZXRfbmFtZXVuaXQoZGV2KSk7CisK KwlpZiAoc2MtPnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19DVFJMX1ZRKSB7CisJCW52cXMrKzsK KworCQlWUV9BTExPQ19JTkZPX0lOSVQoJnZxX2luZm9bMl0sIDAsIE5VTEwsIE5VTEwsCisJCSAg ICAmc2MtPnZ0bmV0X2N0cmxfdnEsICIlcyBjb250cm9sIiwKKwkJICAgIGRldmljZV9nZXRfbmFt ZXVuaXQoZGV2KSk7CisJfQorCisJcmV0dXJuICh2aXJ0aW9fYWxsb2NfdnFzKGRldiwgMCwgbnZx cywgdnFfaW5mbykpOworfQorCitzdGF0aWMgdm9pZAordnRuZXRfZ2V0X2h3YWRkcihzdHJ1Y3Qg dnRuZXRfc29mdGMgKnNjKQoreworCWRldmljZV90IGRldjsKKworCWRldiA9IHNjLT52dG5ldF9k ZXY7CisKKwlpZiAodmlydGlvX3dpdGhfZmVhdHVyZShkZXYsIFZJUlRJT19ORVRfRl9NQUMpID09 IDApIHsKKwkJLyogTWFrZSByYW5kb20sIGxvY2FsbHkgYWRtaW5pc3RlcmVkLCB1bmljYXN0IGFk ZHJlc3MuICovCisJCXNjLT52dG5ldF9od2FkZHJbMF0gPSAweGIyOworCQlyZWFkX3JhbmRvbSgm c2MtPnZ0bmV0X2h3YWRkclsxXSwgRVRIRVJfQUREUl9MRU4gLSAxKTsKKwkJdnRuZXRfc2V0X2h3 YWRkcihzYyk7CisJfSBlbHNlIHsKKwkJdmlydGlvX3JlYWRfZGV2aWNlX2NvbmZpZyhkZXYsCisJ CSAgICBvZmZzZXRvZihzdHJ1Y3QgdmlydGlvX25ldF9jb25maWcsIG1hYyksCisJCSAgICBzYy0+ dnRuZXRfaHdhZGRyLCBFVEhFUl9BRERSX0xFTik7CisJfQorfQorCitzdGF0aWMgdm9pZAordnRu ZXRfc2V0X2h3YWRkcihzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjKQoreworCWRldmljZV90IGRldjsK KworCWRldiA9IHNjLT52dG5ldF9kZXY7CisKKwl2aXJ0aW9fd3JpdGVfZGV2aWNlX2NvbmZpZyhk ZXYsCisJICAgIG9mZnNldG9mKHN0cnVjdCB2aXJ0aW9fbmV0X2NvbmZpZywgbWFjKSwKKwkgICAg c2MtPnZ0bmV0X2h3YWRkciwgRVRIRVJfQUREUl9MRU4pOworfQorCitzdGF0aWMgdm9pZAordnRu ZXRfdXBkYXRlX2xpbmtfc3RhdHVzKHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MpCit7CisJZGV2aWNl X3QgZGV2OworCXN0cnVjdCBpZm5ldCAqaWZwOworCWludCBsaW5rOworCXVpbnQxNl90IHN0YXR1 czsKKworCWRldiA9IHNjLT52dG5ldF9kZXY7CisJaWZwID0gc2MtPnZ0bmV0X2lmcDsKKworCVZU TkVUX0xPQ0tfQVNTRVJUKHNjKTsKKworCWlmIChpZnAtPmlmX2NhcGFiaWxpdGllcyAmIElGQ0FQ X0xJTktTVEFURSkgeworCQlzdGF0dXMgPSB2aXJ0aW9fcmVhZF9kZXZfY29uZmlnXzIoZGV2LAor CQkgICAgb2Zmc2V0b2Yoc3RydWN0IHZpcnRpb19uZXRfY29uZmlnLCBzdGF0dXMpKTsKKwkJaWYg KHN0YXR1cyAmIFZJUlRJT19ORVRfU19MSU5LX1VQKQorCQkJbGluayA9IDE7CisJCWVsc2UKKwkJ CWxpbmsgPSAwOworCX0gZWxzZQorCQlsaW5rID0gMTsKKworCWlmIChsaW5rICYmICgoc2MtPnZ0 bmV0X2ZsYWdzICYgVlRORVRfRkxBR19MSU5LKSA9PSAwKSkgeworCQlzYy0+dnRuZXRfZmxhZ3Mg fD0gVlRORVRfRkxBR19MSU5LOworCQlpZiAoYm9vdHZlcmJvc2UpCisJCQlkZXZpY2VfcHJpbnRm KGRldiwgIkxpbmsgaXMgdXBcbiIpOworCisJCWlmX2xpbmtfc3RhdGVfY2hhbmdlKGlmcCwgTElO S19TVEFURV9VUCk7CisJCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQkJ dnRuZXRfc3RhcnRfbG9ja2VkKGlmcCk7CisJfSBlbHNlIGlmICghbGluayAmJiAoc2MtPnZ0bmV0 X2ZsYWdzICYgVlRORVRfRkxBR19MSU5LKSkgeworCQlzYy0+dnRuZXRfZmxhZ3MgJj0gflZUTkVU X0ZMQUdfTElOSzsKKwkJaWYgKGJvb3R2ZXJib3NlKQorCQkJZGV2aWNlX3ByaW50ZihkZXYsICJM aW5rIGlzIGRvd25cbiIpOworCisJCWlmX2xpbmtfc3RhdGVfY2hhbmdlKGlmcCwgTElOS19TVEFU RV9ET1dOKTsKKwl9Cit9CisKK3N0YXRpYyB2b2lkCit2dG5ldF93YXRjaGRvZyhzdHJ1Y3QgdnRu ZXRfc29mdGMgKnNjKQoreworCXN0cnVjdCBpZm5ldCAqaWZwOworCisJaWZwID0gc2MtPnZ0bmV0 X2lmcDsKKworCVZUTkVUX0xPQ0tfQVNTRVJUKHNjKTsKKworCWlmIChzYy0+dnRuZXRfd2F0Y2hk b2dfdGltZXIgPT0gMCB8fCAtLXNjLT52dG5ldF93YXRjaGRvZ190aW1lcikKKwkJcmV0dXJuOwor CisJLyogQ29tcGxldGUgYW55IGFscmVhZHkgcmVjZWl2ZWQgZnJhbWVzLiAqLworCXZ0bmV0X3J4 ZW9mKHNjLCBzYy0+dnRuZXRfcnhfc2l6ZSwgTlVMTCk7CisKKwlpZl9wcmludGYoaWZwLCAid2F0 Y2hkb2cgdGltZW91dCAtLSByZXNldHRpbmdcbiIpOworCWlmcC0+aWZfb2Vycm9ycysrOworCWlm cC0+aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX1JVTk5JTkc7CisJdnRuZXRfaW5pdF9sb2NrZWQo c2MpOworCisJaWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkpCisJCXRhc2txdWV1 ZV9lbnF1ZXVlX2Zhc3Qoc2MtPnZ0bmV0X3RxLAorCQkgICAgJnNjLT52dG5ldF90eF90YXNrKTsK K30KKworc3RhdGljIHZvaWQKK3Z0bmV0X2NvbmZpZ19jaGFuZ2VfdGFzayh2b2lkICphcmcsIGlu dCBwZW5kaW5nKQoreworCXN0cnVjdCB2dG5ldF9zb2Z0YyAqc2M7CisKKwlzYyA9IGFyZzsKKwor CVZUTkVUX0xPQ0soc2MpOworCXZ0bmV0X3VwZGF0ZV9saW5rX3N0YXR1cyhzYyk7CisJVlRORVRf VU5MT0NLKHNjKTsKK30KKworc3RhdGljIGludAordnRuZXRfaW9jdGwoc3RydWN0IGlmbmV0ICpp ZnAsIHVfbG9uZyBjbWQsIGNhZGRyX3QgZGF0YSkKK3sKKwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNj OworCXN0cnVjdCBpZnJlcSAqaWZyOworCWludCBlcnJvcjsKKworCXNjID0gaWZwLT5pZl9zb2Z0 YzsKKwlpZnIgPSAoc3RydWN0IGlmcmVxICopIGRhdGE7CisJZXJyb3IgPSAwOworCisJc3dpdGNo IChjbWQpIHsKKwljYXNlIFNJT0NTSUZNVFU6CisJCWlmIChpZnItPmlmcl9tdHUgPCBFVEhFUk1J TiB8fCBpZnItPmlmcl9tdHUgPiBWVE5FVF9NQVhfTVRVKQorCQkJZXJyb3IgPSBFSU5WQUw7CisJ CWVsc2UgaWYgKGlmcC0+aWZfbXR1ICE9IGlmci0+aWZyX210dSkgeworCQkJVlRORVRfTE9DSyhz Yyk7CisJCQllcnJvciA9IHZ0bmV0X2NoYW5nZV9tdHUoc2MsIGlmci0+aWZyX210dSk7CisJCQlW VE5FVF9VTkxPQ0soc2MpOworCQl9CisJCWJyZWFrOworCisJY2FzZSBTSU9DU0lGRkxBR1M6CisJ CVZUTkVUX0xPQ0soc2MpOworCQlpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkgeworCQkJaWYg KGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSB7CisJCQkJaWYgKCgoaWZwLT5p Zl9mbGFncyBeIHNjLT52dG5ldF9pZl9mbGFncykgJgorCQkJCSAgICAoSUZGX1BST01JU0MgfCBJ RkZfQUxMTVVMVEkpKSAhPSAwKSB7CisJCQkJCS8qIENhbm5vdCBjaGFuZ2Ugd2l0aG91dCBDVFJM X1JYLiAqLworCQkJCQlpZiAoc2MtPnZ0bmV0X2ZsYWdzICYKKwkJCQkJICAgIFZUTkVUX0ZMQUdf Q1RSTF9SWCkKKwkJCQkJCXZ0bmV0X3J4X2ZpbHRlcihzYyk7CisJCQkJCWVsc2UKKwkJCQkJCWVy cm9yID0gRU5PVFNVUDsKKwkJCQl9CisJCQl9IGVsc2UKKwkJCQl2dG5ldF9pbml0X2xvY2tlZChz Yyk7CisJCX0gZWxzZSB7CisJCQlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5J TkcpCisJCQkJdnRuZXRfc3RvcChzYyk7CisJCX0KKworCQlpZiAoZXJyb3IgPT0gMCkKKwkJCXNj LT52dG5ldF9pZl9mbGFncyA9IGlmcC0+aWZfZmxhZ3M7CisJCVZUTkVUX1VOTE9DSyhzYyk7CisJ CWJyZWFrOworCisJY2FzZSBTSU9DQURETVVMVEk6CisJY2FzZSBTSU9DREVMTVVMVEk6CisJCVZU TkVUX0xPQ0soc2MpOworCQlpZiAoc2MtPnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19DVFJMX1JY KSB7CisJCQlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpCisJCQkJdnRu ZXRfcnhfZmlsdGVyX21hYyhzYyk7CisJCX0KKwkJVlRORVRfVU5MT0NLKHNjKTsKKwkJYnJlYWs7 CisKKwljYXNlIFNJT0NTSUZDQVA6CisJICAgIHsKKwkJaW50IHJlaW5pdCwgbWFzazsKKworCQly ZWluaXQgPSAwOworCQltYXNrID0gaWZyLT5pZnJfcmVxY2FwIF4gaWZwLT5pZl9jYXBlbmFibGU7 CisKKyNpZmRlZiBERVZJQ0VfUE9MTElORworCQlpZiAobWFzayAmIElGQ0FQX1BPTExJTkcpIHsK KwkJCWlmIChpZnItPmlmcl9yZXFjYXAgJiBJRkNBUF9QT0xMSU5HKSB7CisJCQkJZXJyb3IgPSBl dGhlcl9wb2xsX3JlZ2lzdGVyKHZ0bmV0X3BvbGwsIGlmcCk7CisJCQkJaWYgKGVycm9yKQorCQkJ CQlicmVhazsKKworCQkJCVZUTkVUX0xPQ0soc2MpOworCQkJCXZ0bmV0X2Rpc2FibGVfcnhfaW50 cihzYyk7CisJCQkJdnRuZXRfZGlzYWJsZV90eF9pbnRyKHNjKTsKKwkJCQlpZnAtPmlmX2NhcGVu YWJsZSB8PSBJRkNBUF9QT0xMSU5HOworCQkJCVZUTkVUX1VOTE9DSyhzYyk7CisJCQl9IGVsc2Ug eworCQkJCWVycm9yID0gZXRoZXJfcG9sbF9kZXJlZ2lzdGVyKGlmcCk7CisJCQkJLyogRW5hYmxl IGludGVycnVwdHMgZXZlbiBpbiBlcnJvciBjYXNlLiAqLworCQkJCVZUTkVUX0xPQ0soc2MpOwor CQkJCXZ0bmV0X2VuYWJsZV90eF9pbnRyKHNjKTsKKwkJCQl2dG5ldF9lbmFibGVfcnhfaW50cihz Yyk7CisJCQkJaWZwLT5pZl9jYXBlbmFibGUgJj0gfklGQ0FQX1BPTExJTkc7CisJCQkJVlRORVRf VU5MT0NLKHNjKTsKKwkJCX0KKwkJfQorI2VuZGlmCisJCVZUTkVUX0xPQ0soc2MpOworCisJCWlm IChtYXNrICYgSUZDQVBfVFhDU1VNICYmCisJCSAgICBpZnAtPmlmX2NhcGFiaWxpdGllcyAmIElG Q0FQX1RYQ1NVTSkgeworCQkJaWYgKGlmcC0+aWZfY2FwZW5hYmxlICYgSUZDQVBfVFhDU1VNKSB7 CisJCQkJLyogVFNPIHJlcXVpcmVzIFRYIGNoZWNrc3VtIG9mZmxvYWQuICovCisJCQkJaWZwLT5p Zl9jYXBlbmFibGUgJj0KKwkJCQkgICAgfihJRkNBUF9UWENTVU0gfCBJRkNBUF9UU08pOworCQkJ CWlmcC0+aWZfaHdhc3Npc3QgJj0KKwkJCQkgICAgfihWVE5FVF9DU1VNX0ZFQVRVUkVTIHwgQ1NV TV9UU08pOworCQkJfSBlbHNlIHsKKwkJCQlpZnAtPmlmX2NhcGVuYWJsZSB8PSBJRkNBUF9UWENT VU07CisJCQkJaWZwLT5pZl9od2Fzc2lzdCB8PSBWVE5FVF9DU1VNX0ZFQVRVUkVTOworCQkJfQor CQl9CisKKwkJaWYgKG1hc2sgJiBJRkNBUF9SWENTVU0gJiYKKwkJICAgIGlmcC0+aWZfY2FwYWJp bGl0aWVzICYgSUZDQVBfUlhDU1VNKSB7CisJCQlpZnAtPmlmX2NhcGVuYWJsZSBePSBJRkNBUF9S WENTVU07CisJCQlyZWluaXQgPSAxOworCQl9CisKKwkJaWYgKG1hc2sgJiBJRkNBUF9UU080ICYm CisJCSAgICBpZnAtPmlmX2NhcGFiaWxpdGllcyAmIElGQ0FQX1RTTzQpIHsKKwkJCWlmIChpZnAt PmlmX2NhcGVuYWJsZSAmIElGQ0FQX1RTTzQpIHsKKwkJCQlpZnAtPmlmX2NhcGVuYWJsZSAmPSB+ SUZDQVBfVFNPNDsKKwkJCQlpZnAtPmlmX2h3YXNzaXN0ICY9IH5DU1VNX1RTTzsKKwkJCX0gZWxz ZSBpZiAoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9UWENTVU0pIHsKKwkJCQlpZnAtPmlmX2Nh cGVuYWJsZSB8PSBJRkNBUF9UU080OworCQkJCWlmcC0+aWZfaHdhc3Npc3QgfD0gQ1NVTV9UU087 CisJCQl9IGVsc2UgeworCQkJCWlmX3ByaW50ZihpZnAsCisJCQkJICAgICJUU08gcmVxdWlyZXMg VHggY2hlY2tzdW0gb2ZmbG9hZFxuIik7CisJCQkJZXJyb3IgPSBFSU5WQUw7CisJCQl9CisJCX0K KworCQlpZiAobWFzayAmIElGQ0FQX0xSTyAmJgorCQkgICAgaWZwLT5pZl9jYXBhYmlsaXRpZXMg JiBJRkNBUF9MUk8pIHsKKwkJCWlmcC0+aWZfY2FwZW5hYmxlIF49IElGQ0FQX0xSTzsKKwkJCXJl aW5pdCA9IDE7CisJCX0KKworCQlpZiAobWFzayAmIElGQ0FQX1ZMQU5fSFdGSUxURVIgJiYKKwkJ ICAgIGlmcC0+aWZfY2FwYWJpbGl0aWVzICYgSUZDQVBfVkxBTl9IV0ZJTFRFUikgeworCQkJaWZw LT5pZl9jYXBlbmFibGUgXj0gSUZDQVBfVkxBTl9IV0ZJTFRFUjsKKwkJCXJlaW5pdCA9IDE7CisJ CX0KKworCQlpZiAobWFzayAmIElGQ0FQX1ZMQU5fSFdUU08gJiYKKwkJICAgIGlmcC0+aWZfY2Fw YWJpbGl0aWVzICYgSUZDQVBfVkxBTl9IV1RTTykKKwkJCWlmcC0+aWZfY2FwZW5hYmxlIF49IElG Q0FQX1ZMQU5fSFdUU087CisKKwkJaWYgKG1hc2sgJiBJRkNBUF9WTEFOX0hXVEFHR0lORyAmJgor CQkgICAgaWZwLT5pZl9jYXBhYmlsaXRpZXMgJiBJRkNBUF9WTEFOX0hXVEFHR0lORykKKwkJCWlm cC0+aWZfY2FwZW5hYmxlIF49IElGQ0FQX1ZMQU5fSFdUQUdHSU5HOworCisJCWlmIChyZWluaXQg JiYgaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpIHsKKwkJCWlmcC0+aWZfZHJ2 X2ZsYWdzICY9IH5JRkZfRFJWX1JVTk5JTkc7CisJCQl2dG5ldF9pbml0X2xvY2tlZChzYyk7CisJ CX0KKworCQlWTEFOX0NBUEFCSUxJVElFUyhpZnApOworCQlWVE5FVF9VTkxPQ0soc2MpOworCSAg ICB9CisJICAgIGJyZWFrOworCisJZGVmYXVsdDoKKwkJZXJyb3IgPSBldGhlcl9pb2N0bChpZnAs IGNtZCwgZGF0YSk7CisJCWJyZWFrOworCX0KKworCVZUTkVUX0xPQ0tfQVNTRVJUX05PVE9XTkVE KHNjKTsKKworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9jaGFuZ2Vf bXR1KHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MsIGludCBuZXdfbXR1KQoreworCXN0cnVjdCBpZm5l dCAqaWZwOworCWludCBuZXdfZnJhbWVfc2l6ZSwgY2xzaXplOworCisJaWZwID0gc2MtPnZ0bmV0 X2lmcDsKKworCWlmICgoc2MtPnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19NUkdfUlhCVUZTKSA9 PSAwKSB7CisJCW5ld19mcmFtZV9zaXplID0gc2l6ZW9mKHN0cnVjdCB2dG5ldF9yeF9tYnVmX2hl YWRlcikgKworCQkgICAgc2l6ZW9mKHN0cnVjdCBldGhlcl92bGFuX2hlYWRlcikgKyBuZXdfbXR1 OworCisJCWlmIChuZXdfZnJhbWVfc2l6ZSA+IE1KVU05QllURVMpCisJCQlyZXR1cm4gKEVJTlZB TCk7CisKKwkJaWYgKG5ld19mcmFtZV9zaXplIDw9IE1DTEJZVEVTKQorCQkJY2xzaXplID0gTUNM QllURVM7CisJCWVsc2UKKwkJCWNsc2l6ZSA9IE1KVU05QllURVM7CisKKwl9IGVsc2UgeworCQkv KgorCQkgKiBOT1RFOiBXZSBoYXZlIGFscmVhZHkgY29tcGFyZWQgJ25ld19tdHUnIGFnYWluc3QK KwkJICogVlRORVRfTUFYX01UVSAoaW4gdnRuZXRfaW9jdGwpLCBhbmQgd2UgaGF2ZSBhCisJCSAq IENUQVNTRVJUIGVuc3VyaW5nIFZUTkVUX01BWF9UWF9TRUdTLTEgY2FuIGhvbGQgYXQKKwkJICog bGVhc3QgVlRORVRfTUFYX01UVSB3aXRoIE1DTEJZVEVTIHNpemVkIGNsdXN0ZXJzLgorCQkgKi8K KworCQluZXdfZnJhbWVfc2l6ZSA9IHNpemVvZihzdHJ1Y3QgdmlydGlvX25ldF9oZHJfbXJnX3J4 YnVmKSArCisJCSAgICBzaXplb2Yoc3RydWN0IGV0aGVyX3ZsYW5faGVhZGVyKSArIG5ld19tdHU7 CisKKwkJaWYgKG5ld19mcmFtZV9zaXplIDw9IE1DTEJZVEVTKQorCQkJY2xzaXplID0gTUNMQllU RVM7CisJCWVsc2UKKwkJCWNsc2l6ZSA9IE1KVU1QQUdFU0laRTsKKwl9CisKKwlpZnAtPmlmX210 dSA9IG5ld19tdHU7CisJc2MtPnZ0bmV0X3J4X21idWZfc2l6ZSA9IGNsc2l6ZTsKKworCWlmIChp ZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgeworCQlpZnAtPmlmX2Rydl9mbGFn cyAmPSB+SUZGX0RSVl9SVU5OSU5HOworCQl2dG5ldF9pbml0X2xvY2tlZChzYyk7CisJfQorCisJ cmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAordnRuZXRfaW5pdF9yeF92cShzdHJ1Y3QgdnRu ZXRfc29mdGMgKnNjKQoreworCXN0cnVjdCB2aXJ0cXVldWUgKnZxOworCWludCBpLCBlcnJvcjsK KworCXZxID0gc2MtPnZ0bmV0X3J4X3ZxOworCWVycm9yID0gRU5PU1BDOworCisJZm9yIChpID0g MDsgIXZpcnRxdWV1ZV9mdWxsKHZxKTsgaSsrKSB7CisJCWlmICgoZXJyb3IgPSB2dG5ldF9uZXdi dWYoc2MpKSAhPSAwKQorCQkJYnJlYWs7CisJfQorCisJaWYgKGkgPiAwKSB7CisJCXZxX3Jpbmdf c3luYyh2cSk7CisKKwkJLyoKKwkJICogRU1TR1NJWkUgc2lnbmlmaWVzIHRoZSB2aXJ0cXVldWUg ZGlkIG5vdAorCQkgKiBoYXZlIGVub3VnaCBlbnRyaWVzIGF2YWlsYWJsZSB0byBob2xkIHRoZQor CQkgKiBsYXN0IG1idWYuIFRoaXMgaXMgbm90IGFuIGVycm9yLiBXZSBzaG91bGQKKwkJICogbm90 IGdldCBFTk9TUEMgc2luY2Ugd2UgY2hlY2sgaWYgdGhlIFZxCisJCSAqIGlzIGZ1bGwgYmVmb3Jl IGF0dGVtcHRpbmcgdG8gYWRkIGEgYnVmZmVyLgorCQkgKi8KKwkJaWYgKGVycm9yID09IEVNU0dT SVpFKQorCQkJZXJyb3IgPSAwOworCX0KKworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMg dm9pZAordnRuZXRfZnJlZV9yeF9tYnVmcyhzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjKQoreworCXN0 cnVjdCB2aXJ0cXVldWUgKnZxOworCXN0cnVjdCBtYnVmICptOworCisJdnEgPSBzYy0+dnRuZXRf cnhfdnE7CisKKwl3aGlsZSAoKG0gPSB2aXJ0cXVldWVfZHJhaW4odnEpKSAhPSBOVUxMKQorCQlt X2ZyZWVtKG0pOworCisJS0FTU0VSVCh2aXJ0cXVldWVfZW1wdHkodnEpLCAoIm1idWZzIHJlbWFp bmluZyBpbiBSeCBWcSIpKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X2ZyZWVfdHhfbWJ1ZnMo c3RydWN0IHZ0bmV0X3NvZnRjICpzYykKK3sKKwlzdHJ1Y3QgdmlydHF1ZXVlICp2cTsKKwlzdHJ1 Y3QgbWJ1ZiAqbTsKKworCXZxID0gc2MtPnZ0bmV0X3R4X3ZxOworCisJd2hpbGUgKChtID0gdmly dHF1ZXVlX2RyYWluKHZxKSkgIT0gTlVMTCkKKwkJbV9mcmVlbShtKTsKKworCUtBU1NFUlQodmly dHF1ZXVlX2VtcHR5KHZxKSwgKCJtYnVmcyByZW1haW5pbmcgaW4gVHggVnEiKSk7Cit9CisKK3N0 YXRpYyB2b2lkCit2dG5ldF9mcmVlX2N0cmxfdnEoc3RydWN0IHZ0bmV0X3NvZnRjICpzYykKK3sK KwlzdHJ1Y3QgdmlydHF1ZXVlICp2cTsKKworCXZxID0gc2MtPnZ0bmV0X2N0cmxfdnE7CisKKwkv KgorCSAqIFNpbmNlIHRoZSBjb250cm9sIHZpcnRxdWV1ZSBpcyBhbHdheXMgcG9sbGVkIGZvcgor CSAqIHJlc3BvbnNlcywgaXQgc2hvdWxkIGJlIGVtcHR5LgorCSAqLworCUtBU1NFUlQodmlydHF1 ZXVlX2VtcHR5KHZxKSwgKCJDdHJsIFZxIG5vdCBlbXB0eSIpKTsKK30KKworI2lmZGVmIERFVklD RV9QT0xMSU5HCitzdGF0aWMgaW50Cit2dG5ldF9wb2xsKHN0cnVjdCBpZm5ldCAqaWZwLCBlbnVt IHBvbGxfY21kIGNtZCwgaW50IGNvdW50KQoreworCXN0cnVjdCB2dG5ldF9zb2Z0YyAqc2M7CisJ aW50IHJ4X2RvbmU7CisKKwlzYyA9IGlmcC0+aWZfc29mdGM7CisJcnhfZG9uZSA9IDA7CisKKwlW VE5FVF9MT0NLKHNjKTsKKwlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5H KSA9PSAwKSB7CisJCVZUTkVUX1VOTE9DSyhzYyk7CisJCXJldHVybiAocnhfZG9uZSk7CisJfQor CisJaWYgKGNtZCA9PSBQT0xMX0FORF9DSEVDS19TVEFUVVMpCisJCXZ0bmV0X3VwZGF0ZV9saW5r X3N0YXR1cyhzYyk7CisKKwl2dG5ldF9yeGVvZihzYywgY291bnQsICZyeF9kb25lKTsKKworCXZ0 bmV0X3R4ZW9mKHNjKTsKKwlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJ dGFza3F1ZXVlX2VucXVldWVfZmFzdChzYy0+dnRuZXRfdHEsICZzYy0+dnRuZXRfdHhfdGFzayk7 CisKKwlWVE5FVF9VTkxPQ0soc2MpOworCisJcmV0dXJuIChyeF9kb25lKTsKK30KKyNlbmRpZiAv KiBERVZJQ0VfUE9MTElORyAqLworCitzdGF0aWMgaW50Cit2dG5ldF9uZXdidWYoc3RydWN0IHZ0 bmV0X3NvZnRjICpzYykKK3sKKwlzdHJ1Y3QgbWJ1ZiAqbTsKKwlpbnQgY2xzaXplLCBlcnJvcjsK KworCWNsc2l6ZSA9IHNjLT52dG5ldF9yeF9tYnVmX3NpemU7CisKKwltID0gbV9nZXRqY2woTV9E T05UV0FJVCwgTVRfREFUQSwgTV9QS1RIRFIsIGNsc2l6ZSk7CisJaWYgKG0gPT0gTlVMTCkgewor CQlzYy0+dnRuZXRfc3RhdHMubWJ1Zl9hbGxvY19mYWlsZWQrKzsKKwkJcmV0dXJuIChFTk9CVUZT KTsKKwl9CisKKwltLT5tX2xlbiA9IG0tPm1fcGt0aGRyLmxlbiA9IGNsc2l6ZTsKKworCWVycm9y ID0gdnRuZXRfZW5xdWV1ZV9yeGJ1ZihzYywgbSk7CisJaWYgKGVycm9yKQorCQltX2ZyZWVtKG0p OworCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyB2b2lkCit2dG5ldF9kaXNjYXJkX21l cmdlZF9yeGJ1ZihzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjLCBpbnQgbmJ1ZnMpCit7CisJc3RydWN0 IHZpcnRxdWV1ZSAqdnE7CisJc3RydWN0IG1idWYgKm07CisKKwl2cSA9IHNjLT52dG5ldF9yeF92 cTsKKworCS8qIE5PVEU6IFRoZSBsZWFkaW5nIG1idWYgaGFzIGFscmVhZHkgYmVlbiBkaXNjYXJk ZWQuICovCisKKwl3aGlsZSAoLS1uYnVmcyA+IDApIHsKKwkJaWYgKChtID0gdnFfcmluZ19kZXF1 ZXVlKHZxLCBOVUxMKSkgPT0gTlVMTCkKKwkJCWJyZWFrOworCisJCXZ0bmV0X2Rpc2NhcmRfcnhi dWYoc2MsIG0pOworCX0KK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X2Rpc2NhcmRfcnhidWYoc3Ry dWN0IHZ0bmV0X3NvZnRjICpzYywgc3RydWN0IG1idWYgKm0pCit7CisJaW50IGVycm9yOworCisJ ZXJyb3IgPSB2dG5ldF9lbnF1ZXVlX3J4YnVmKHNjLCBtKTsKKworCS8qCisJICogVGhlIGRpc2Nh cmRlZCBidWZmZXIgc2hvdWxkIGFsd2F5cyBiZSBzdWNjZXNzZnVsbHkgcmVxdWV1ZWQKKwkgKiBz aW5jZSBpdCB3YXMganVzdCBkZXF1ZXVlZCBhbmQgd2Ugc3RpbGwgaG9sZCBWVE5FVF9NVFguCisJ ICovCisJS0FTU0VSVChlcnJvciA9PSAwLCAoImNhbm5vdCByZXF1ZXVlZCBkaXNjYXJkZWQgbWJ1 ZiIpKTsKK30KKworc3RhdGljIGludAordnRuZXRfZW5xdWV1ZV9yeGJ1ZihzdHJ1Y3QgdnRuZXRf c29mdGMgKnNjLCBzdHJ1Y3QgbWJ1ZiAqbSkKK3sKKwlzdHJ1Y3Qgc2dsaXN0IHNnOworCXN0cnVj dCBzZ2xpc3Rfc2VnIHNlZ3NbVlRORVRfTUFYX1JYX1NFR1NdOworCXN0cnVjdCB2dG5ldF9yeF9t YnVmX2hlYWRlciAqcnhoZHI7CisJc3RydWN0IHZpcnRpb19uZXRfaGRyICpoZHI7CisJdWludDhf dCAqbWRhdGE7CisJaW50IG9mZnNldCwgZXJyb3I7CisKKwlWVE5FVF9MT0NLX0FTU0VSVChzYyk7 CisJS0FTU0VSVChtLT5tX25leHQgPT0gTlVMTCwgKCJ1bmV4cGVjdGVkIG1idWYgY2hhaW4iKSk7 CisKKwlzZ2xpc3RfaW5pdCgmc2csIFZUTkVUX01BWF9SWF9TRUdTLCBzZWdzKTsKKworCW1kYXRh ID0gbXRvZChtLCB1aW50OF90ICopOworCW9mZnNldCA9IDA7CisKKwlpZiAoKHNjLT52dG5ldF9m bGFncyAmIFZUTkVUX0ZMQUdfTVJHX1JYQlVGUykgPT0gMCkgeworCQlyeGhkciA9IChzdHJ1Y3Qg dnRuZXRfcnhfbWJ1Zl9oZWFkZXIgKikgbWRhdGE7CisJCWhkciA9ICZyeGhkci0+dnJoX2hkcjsK KwkJb2Zmc2V0ICs9IHNpemVvZihzdHJ1Y3QgdnRuZXRfcnhfbWJ1Zl9oZWFkZXIpOworCisJCWVy cm9yID0gc2dsaXN0X2FwcGVuZCgmc2csIGhkciwgc2MtPnZ0bmV0X2hkcl9zaXplKTsKKwkJS0FT U0VSVChlcnJvciA9PSAwLCAoImNhbm5vdCBhZGQgaGVhZGVyIHRvIHNnbGlzdCIpKTsKKwl9CisK KwllcnJvciA9IHNnbGlzdF9hcHBlbmQoJnNnLCBtZGF0YSArIG9mZnNldCwgbS0+bV9sZW4gLSBv ZmZzZXQpOworCUtBU1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIG1idWYgdG8gc2dsaXN0 IikpOworCisJZXJyb3IgPSB2cV9yaW5nX2VucXVldWUoc2MtPnZ0bmV0X3J4X3ZxLCBtLCAmc2cs IDAsIHNnLnNnX25zZWcpOworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMgdm9pZAordnRu ZXRfdmxhbl90YWdfcmVtb3ZlKHN0cnVjdCBtYnVmICptKQoreworCXN0cnVjdCBldGhlcl92bGFu X2hlYWRlciAqZXZsOworCisJZXZsID0gbXRvZChtLCBzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIg Kik7CisKKwltLT5tX3BrdGhkci5ldGhlcl92dGFnID0gbnRvaHMoZXZsLT5ldmxfdGFnKTsKKwlt LT5tX2ZsYWdzIHw9IE1fVkxBTlRBRzsKKworCS8qIFN0cmlwIHRoZSA4MDIuMVEgaGVhZGVyLiAq LworCWJjb3B5KChjaGFyICopIGV2bCwgKGNoYXIgKikgZXZsICsgRVRIRVJfVkxBTl9FTkNBUF9M RU4sCisJICAgIEVUSEVSX0hEUl9MRU4gLSBFVEhFUl9UWVBFX0xFTik7CisJbV9hZGoobSwgRVRI RVJfVkxBTl9FTkNBUF9MRU4pOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9yeF9jc3VtKHN0cnVj dCB2dG5ldF9zb2Z0YyAqc2MsIHN0cnVjdCBtYnVmICptLAorICAgIHN0cnVjdCB2aXJ0aW9fbmV0 X2hkciAqaGRyKQoreworCXN0cnVjdCBldGhlcl9oZWFkZXIgKmVoOworCXN0cnVjdCBldGhlcl92 bGFuX2hlYWRlciAqZXZoOworCXVpbnQ4X3QgKnByb3RvX2hkcjsKKwlpbnQgY2tfc3RhcnQsIGNr X29mZnNldDsKKwl1aW50MTZfdCBldHlwZTsKKwl1aW50OF90IGlwX3Byb3RvOworCisJLyoKKwkg KiBUcmFuc2xhdGUgVmlydElPJ3MgY2hlY2tzdW0gaW50ZXJmYWNlIHRvIEZyZWVCU0QncyBpbnRl cmZhY2UuCisJICogVGhlIGhvc3Qgb25seSBwcm92aWRlcyB1cyB3aXRoIHRoZSBvZmZzZXQgYXQg d2hpY2ggdG8gc3RhcnQKKwkgKiBjaGVja3N1bW1pbmcsIGFuZCB0aGUgb2Zmc2V0IGZyb20gdGhh dCB0byBwbGFjZSB0aGUgY29tcGxldGUKKwkgKiBjaGVja3N1bS4gV2hpbGUgYXBwYXJlbnRseSBt YXBwaW5nIHdlbGwgdG8gaG93IExpbnV4IGhhbmRsZXMKKwkgKiBjaGVja3N1bSBvZmZsb2FkLCBm b3IgRnJlZUJTRCB3ZSBtdXN0IHBlZWsgaW5zaWRlIHRoZSByZWNlaXZlZAorCSAqIHBhY2tldCBp biBvcmRlciB0byBzZXQgdGhlIGFwcHJvcHJpYXRlIGZsYWdzLgorCSAqCisJICogU2luY2Ugd2Ug b25seSBwb3B1bGF0ZSB0aGUgUnggdmlydHF1ZXVlIHdpdGggTUNMQllURVMgb3IgYmlnZ2VyCisJ ICogY2x1c3RlcnMsIGZpZ3VyZSBzb21ldGhpbmcgaXMgYW1pc3MgaWYgdGhlIGZpcnN0IG1idWYg ZG9lcyBub3QKKwkgKiBjb250YWluIHRoZSBFdGhlcm5ldCBhbmQgcHJvdG9jb2wgaGVhZGVycy4K KwkgKi8KKworCWVoID0gbXRvZChtLCBzdHJ1Y3QgZXRoZXJfaGVhZGVyICopOworCWlmIChlaC0+ ZXRoZXJfdHlwZSA9PSBodG9ucyhFVEhFUlRZUEVfVkxBTikpIHsKKwkJZXZoID0gbXRvZChtLCBz dHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIgKik7CisJCWV0eXBlID0gbnRvaHMoZXZoLT5ldmxfcHJv dG8pOworCQlja19zdGFydCA9IHNpemVvZihzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIpOworCX0g ZWxzZSB7CisJCWV0eXBlID0gbnRvaHMoZWgtPmV0aGVyX3R5cGUpOworCQlja19zdGFydCA9IHNp emVvZihzdHJ1Y3QgZXRoZXJfaGVhZGVyKTsKKwl9CisKKwlwcm90b19oZHIgPSBtdG9kKG0sIHVp bnQ4X3QgKikgKyBja19zdGFydDsKKworCXN3aXRjaCAoZXR5cGUpIHsKKwljYXNlIEVUSEVSVFlQ RV9JUDoKKwkJeworCQkJc3RydWN0IGlwICppcDsKKwkJCWludCBobGVuOworCisJCQlpZiAobS0+ bV9sZW4gPCBja19zdGFydCArIHNpemVvZihzdHJ1Y3QgaXApKQorCQkJCXJldHVybiAoMSk7CisK KwkJCWlwID0gKHN0cnVjdCBpcCAqKSBwcm90b19oZHI7CisKKwkJCSAvKiBTYW50aXkgY2hlY2sg SVAgaGVhZGVyLiAqLworCQkJaWYgKGlwLT5pcF92ICE9IElQVkVSU0lPTikKKwkJCQlyZXR1cm4g KDEpOworCQkJaGxlbiA9IGlwLT5pcF9obCA8PCAyOworCQkJaWYgKGhsZW4gPCBzaXplb2Yoc3Ry dWN0IGlwKSkKKwkJCQlyZXR1cm4gKDEpOworCQkJaWYgKG50b2hzKGlwLT5pcF9sZW4pIDwgaGxl bikKKwkJCQlyZXR1cm4gKDEpOworCQkJaWYgKG50b2hzKGlwLT5pcF9sZW4pICE9IChtLT5tX3Br dGhkci5sZW4gLSBja19zdGFydCkpCisJCQkJcmV0dXJuICgxKTsKKworCQkJaXBfcHJvdG8gPSBp cC0+aXBfcDsKKwkJCWNrX3N0YXJ0ICs9IGhsZW47CisJCX0KKwkJYnJlYWs7CisKKwljYXNlIEVU SEVSVFlQRV9JUFY2OgorCQl7CisJCQlzdHJ1Y3QgaXA2X2hkciAqaXA2OworCisJCQlpZiAobS0+ bV9sZW4gPCBja19zdGFydCArIHNpemVvZihzdHJ1Y3QgaXA2X2hkcikpCisJCQkJcmV0dXJuICgx KTsKKwkJCWlwNiA9IChzdHJ1Y3QgaXA2X2hkciAqKSBwcm90b19oZHI7CisKKwkJCS8qCisJCQkg KiBUT0RPIE5lZWQgdG8gaGFuZGxlIGFueSBleHRlbnNpb24gaGVhZGVycy4KKwkJCSAqLworCisJ CQlpcF9wcm90byA9IGlwNi0+aXA2X254dDsKKwkJCWNrX3N0YXJ0ICs9IHNpemVvZihzdHJ1Y3Qg aXA2X2hkcik7CisJCX0KKwkJYnJlYWs7CisKKwlkZWZhdWx0OgorCQlzYy0+dnRuZXRfc3RhdHMu cnhfY3N1bV91bmtub3duX2V0eXBlKys7CisJCXJldHVybiAoMSk7CisJfQorCisJLyogQXNzdW1l IGNoZWNrc3VtIGJlZ2lucyByaWdodCBhZnRlciB0aGUgSVAgaGVhZGVyIGVuZHMuICovCisJaWYg KGNrX3N0YXJ0ICE9IGhkci0+Y3N1bV9zdGFydCkgeworCQlzYy0+dnRuZXRfc3RhdHMucnhfY3N1 bV9iYWRfc3RhcnQrKzsKKwkJcmV0dXJuICgxKTsKKwl9CisKKwlzd2l0Y2ggKGlwX3Byb3RvKSB7 CisJY2FzZSBJUFBST1RPX1RDUDoKKwkJY2tfb2Zmc2V0ID0gb2Zmc2V0b2Yoc3RydWN0IHRjcGhk ciwgdGhfc3VtKTsKKwkJYnJlYWs7CisKKwljYXNlIElQUFJPVE9fVURQOgorCQlja19vZmZzZXQg PSBvZmZzZXRvZihzdHJ1Y3QgdWRwaGRyLCB1aF9zdW0pOworCQlicmVhazsKKworCWNhc2UgSVBQ Uk9UT19TQ1RQOgorCQlja19vZmZzZXQgPSBvZmZzZXRvZihzdHJ1Y3Qgc2N0cGhkciwgY2hlY2tz dW0pOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCXNjLT52dG5ldF9zdGF0cy5yeF9jc3VtX3Vu a25vd25faXBwcm90bysrOworCQlyZXR1cm4gKDEpOworCX0KKworCWlmIChja19vZmZzZXQgIT0g aGRyLT5jc3VtX29mZnNldCkgeworCQlzYy0+dnRuZXRfc3RhdHMucnhfY3N1bV9iYWRfb2Zmc2V0 Kys7CisJCXJldHVybiAoMSk7CisJfQorCisJLyoKKwkgKiBUaGUgSVAgaGVhZGVyIGNoZWNrc3Vt IGlzIGFsbW9zdCBjZXJ0YWlubHkgdmFsaWQgYnV0IEknbQorCSAqIHVuY2VydGFpbiBpZiB0aGF0 IGlzIGd1YXJhbnRlZWQuCisJICoKKwkgKiBtLT5tX3BrdGhkci5jc3VtX2ZsYWdzIHw9CisJICog ICAgIENTVU1fSVBfQ0hFQ0tFRCB8IENTVU1fSVBfVkFMSUQ7CisJICovCisKKwlzd2l0Y2ggKGlw X3Byb3RvKSB7CisJY2FzZSBJUFBST1RPX1VEUDoKKwkgICAgeworCQlzdHJ1Y3QgdWRwaGRyICp1 ZHA7CisKKwkJaWYgKG0tPm1fbGVuIDwgY2tfc3RhcnQgKyBzaXplb2Yoc3RydWN0IHVkcGhkcikp CisJCQlyZXR1cm4gKDEpOworCisJCXVkcCA9IChzdHJ1Y3QgdWRwaGRyICopKG10b2QobSwgdWlu dDhfdCAqKSArIGNrX3N0YXJ0KTsKKwkJaWYgKHVkcC0+dWhfc3VtID09IDApCisJCQlicmVhazsK KwkgICAgfQorCSAgICAvKiBGQUxMVEhST1VHSCAqLworCisJY2FzZSBJUFBST1RPX1RDUDoKKwkJ bS0+bV9wa3RoZHIuY3N1bV9mbGFncyB8PQorCQkgICAgQ1NVTV9EQVRBX1ZBTElEIHwgQ1NVTV9Q U0VVRE9fSERSOworCQltLT5tX3BrdGhkci5jc3VtX2RhdGEgPSAweEZGRkY7CisJCWJyZWFrOwor CisJY2FzZSBJUFBST1RPX1NDVFA6CisJCW0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgfD0gQ1NVTV9T Q1RQX1ZBTElEOworCQlicmVhazsKKwl9CisKKwlzYy0+dnRuZXRfc3RhdHMucnhfY3N1bV9vZmZs b2FkZWQrKzsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK3Z0bmV0X3J4ZW9mX21l cmdlZChzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjLCBzdHJ1Y3QgbWJ1ZiAqbV9oZWFkLAorICAgIGlu dCBuYnVmcykKK3sKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlzdHJ1Y3QgdmlydHF1ZXVlICp2cTsK KwlzdHJ1Y3QgbWJ1ZiAqbSwgKm1fdGFpbDsKKwlpbnQgbGVuOworCisJaWZwID0gc2MtPnZ0bmV0 X2lmcDsKKwl2cSA9IHNjLT52dG5ldF9yeF92cTsKKwltX3RhaWwgPSBtX2hlYWQ7CisKKwl3aGls ZSAoLS1uYnVmcyA+IDApIHsKKwkJbSA9IHZxX3JpbmdfZGVxdWV1ZSh2cSwgJmxlbik7CisJCWlm IChtID09IE5VTEwpCisJCQlicmVhazsKKworCQlpZiAodnRuZXRfbmV3YnVmKHNjKSAhPSAwKSB7 CisJCQlpZnAtPmlmX2lxZHJvcHMrKzsKKwkJCXZ0bmV0X2Rpc2NhcmRfcnhidWYoc2MsIG0pOwor CQkJaWYgKG5idWZzID4gMSkKKwkJCQl2dG5ldF9kaXNjYXJkX21lcmdlZF9yeGJ1ZihzYywgbmJ1 ZnMpOworCQkJYnJlYWs7CisJCX0KKworCQlpZiAobS0+bV9sZW4gPCBsZW4pCisJCQlsZW4gPSBt LT5tX2xlbjsKKworCQltLT5tX2xlbiA9IGxlbjsKKwkJbS0+bV9mbGFncyAmPSB+TV9QS1RIRFI7 CisKKwkJbV9oZWFkLT5tX3BrdGhkci5sZW4gKz0gbGVuOworCQltX3RhaWwtPm1fbmV4dCA9IG07 CisJCW1fdGFpbCA9IG07CisJfQorCisJaWYgKG5idWZzID4gMCkgeworCQlzYy0+dnRuZXRfc3Rh dHMucnhfbWVyZ2VhYmxlX2ZhaWxlZCsrOworCQltX2ZyZWVtKG1faGVhZCk7CisJCXJldHVybiAo MSk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAordnRuZXRfcnhlb2Yoc3Ry dWN0IHZ0bmV0X3NvZnRjICpzYywgaW50IGNvdW50LCBpbnQgKnJ4X25wa3RzcCkKK3sKKwlzdHJ1 Y3QgdmlydGlvX25ldF9oZHIgbGhkcjsKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlzdHJ1Y3Qgdmly dHF1ZXVlICp2cTsKKwlzdHJ1Y3QgbWJ1ZiAqbTsKKwlzdHJ1Y3QgZXRoZXJfaGVhZGVyICplaDsK KwlzdHJ1Y3QgdmlydGlvX25ldF9oZHIgKmhkcjsKKwlzdHJ1Y3QgdmlydGlvX25ldF9oZHJfbXJn X3J4YnVmICptaGRyOworCWludCBsZW4sIG5kZXEsIG5idWZzLCBhZGpzeiwgcnhfbnBrdHM7CisK KwlpZnAgPSBzYy0+dnRuZXRfaWZwOworCXZxID0gc2MtPnZ0bmV0X3J4X3ZxOworCWhkciA9IE5V TEw7CisJbmRlcSA9IDA7CisJcnhfbnBrdHMgPSAwOworCisJVlRORVRfTE9DS19BU1NFUlQoc2Mp OworCisJd2hpbGUgKC0tY291bnQgPj0gMCkgeworCQltID0gdnFfcmluZ19kZXF1ZXVlKHZxLCAm bGVuKTsKKwkJaWYgKG0gPT0gTlVMTCkKKwkJCWJyZWFrOworCisJCS8qIFZpcnRxdWV1ZSBzeW5j IHJlcXVpcmVkIGxhdGVyLiAqLworCQluZGVxKys7CisKKwkJaWYgKGxlbiA8IHNjLT52dG5ldF9o ZHJfc2l6ZSArIEVUSEVSX0hEUl9MRU4pIHsKKwkJCWlmcC0+aWZfaWVycm9ycysrOworCQkJdnRu ZXRfZGlzY2FyZF9yeGJ1ZihzYywgbSk7CisJCQljb250aW51ZTsKKwkJfQorCisJCWlmICgoc2Mt PnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19NUkdfUlhCVUZTKSA9PSAwKSB7CisJCQluYnVmcyA9 IDE7CisJCQlhZGpzeiA9IHNpemVvZihzdHJ1Y3QgdnRuZXRfcnhfbWJ1Zl9oZWFkZXIpOworCisJ CQkvKgorCQkJICogQWNjb3VudCBmb3Igb3VyIHBhZCBiZXR3ZWVuIHRoZSBoZWFkZXIgYW5kCisJ CQkgKiB0aGUgYWN0dWFsIHN0YXJ0IG9mIHRoZSBmcmFtZS4KKwkJCSAqLworCQkJbGVuICs9IFZU TkVUX1JYX01CVUZfSEVBREVSX1BBRDsKKwkJfSBlbHNlIHsKKwkJCW1oZHIgPSBtdG9kKG0sIHN0 cnVjdCB2aXJ0aW9fbmV0X2hkcl9tcmdfcnhidWYgKik7CisJCQluYnVmcyA9IG1oZHItPm51bV9i dWZmZXJzOworCQkJYWRqc3ogPSBzaXplb2Yoc3RydWN0IHZpcnRpb19uZXRfaGRyX21yZ19yeGJ1 Zik7CisJCX0KKworCQlpZiAodnRuZXRfbmV3YnVmKHNjKSAhPSAwKSB7CisJCQlpZnAtPmlmX2lx ZHJvcHMrKzsKKwkJCXZ0bmV0X2Rpc2NhcmRfcnhidWYoc2MsIG0pOworCQkJaWYgKG5idWZzID4g MSkKKwkJCQl2dG5ldF9kaXNjYXJkX21lcmdlZF9yeGJ1ZihzYywgbmJ1ZnMpOworCQkJY29udGlu dWU7CisJCX0KKworCQltLT5tX2xlbiA9IG0tPm1fcGt0aGRyLmxlbiA9IGxlbjsKKwkJbS0+bV9w a3RoZHIucmN2aWYgPSBpZnA7CisJCW0tPm1fcGt0aGRyLmNzdW1fZmxhZ3MgPSAwOworCisJCWlm IChuYnVmcyA+IDEpIHsKKwkJCWlmICh2dG5ldF9yeGVvZl9tZXJnZWQoc2MsIG0sIG5idWZzKSAh PSAwKQorCQkJCWNvbnRpbnVlOworCQl9CisKKwkJaWZwLT5pZl9pcGFja2V0cysrOworCisJCS8q CisJCSAqIFNhdmUgY29weSBvZiBoZWFkZXIgYmVmb3JlIHdlIHN0cmlwIGl0LiBGb3IgYm90aCBt ZXJnZWFibGUKKwkJICogYW5kIG5vbi1tZXJnZWFibGUsIHRoZSBWaXJ0SU8gaGVhZGVyIGlzIHBs YWNlZCBmaXJzdCBpbiB0aGUKKwkJICogbWJ1ZidzIGRhdGEuIE5vdGUgd2Ugbm8gbG9uZ2VyIG5l ZWQgbnVtX2J1ZmZlcnMsIHNvIGFsd2F5cworCQkgKiB1c2UgdmlydGlvX25ldF9oZHIuCisJCSAq LworCQloZHIgPSAmbGhkcjsKKwkJbWVtY3B5KGhkciwgbXRvZChtLCB2b2lkICopLCBzaXplb2Yo c3RydWN0IHZpcnRpb19uZXRfaGRyKSk7CisKKwkJLyogU3RyaXAgaGVhZGVyLiAqLworCQltX2Fk aihtLCBhZGpzeik7CisKKwkJaWYgKGlmcC0+aWZfY2FwZW5hYmxlICYgSUZDQVBfVkxBTl9IV1RB R0dJTkcpIHsKKwkJCWVoID0gbXRvZChtLCBzdHJ1Y3QgZXRoZXJfaGVhZGVyICopOworCQkJaWYg KGVoLT5ldGhlcl90eXBlID09IGh0b25zKEVUSEVSVFlQRV9WTEFOKSkgeworCQkJCXZ0bmV0X3Zs YW5fdGFnX3JlbW92ZShtKTsKKworCQkJCS8qCisJCQkJICogV2l0aCB0aGUgODAyLjFRIGhlYWRl ciByZW1vdmVkLCB1cGRhdGUgdGhlCisJCQkJICogY2hlY2tzdW0gc3RhcnRpbmcgbG9jYXRpb24g YWNjb3JkaW5nbHkuCisJCQkJICovCisJCQkJaWYgKGhkci0+ZmxhZ3MgJiBWSVJUSU9fTkVUX0hE Ul9GX05FRURTX0NTVU0pCisJCQkJCWhkci0+Y3N1bV9zdGFydCAtPQorCQkJCQkgICAgRVRIRVJf VkxBTl9FTkNBUF9MRU47CisJCQl9CisJCX0KKworCQlpZiAoaWZwLT5pZl9jYXBlbmFibGUgJiBJ RkNBUF9SWENTVU0gJiYKKwkJICAgIGhkci0+ZmxhZ3MgJiBWSVJUSU9fTkVUX0hEUl9GX05FRURT X0NTVU0pCisJCQl2dG5ldF9yeF9jc3VtKHNjLCBtLCBoZHIpOworCisJCVZUTkVUX1VOTE9DSyhz Yyk7CisJCSgqaWZwLT5pZl9pbnB1dCkoaWZwLCBtKTsKKwkJVlRORVRfTE9DSyhzYyk7CisJCXJ4 X25wa3RzKys7CisKKwkJLyoKKwkJICogVGhlIGludGVyZmFjZSBtYXkgaGF2ZSBiZWVuIHN0b3Bw ZWQgd2hpbGUgd2Ugd2VyZQorCQkgKiBwYXNzaW5nIHRoZSBwYWNrZXQgdXAgdGhlIG5ldHdvcmsg c3RhY2suCisJCSAqLworCQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5H KSA9PSAwKQorCQkJYnJlYWs7CisJfQorCisJaWYgKG5kZXEgPiAwKQorCQl2cV9yaW5nX3N5bmMo dnEpOworCisJaWYgKHJ4X25wa3RzcCAhPSBOVUxMKQorCQkqcnhfbnBrdHNwID0gcnhfbnBrdHM7 CisKKwlyZXR1cm4gKGNvdW50ID4gMCA/IDAgOiBFQUdBSU4pOworfQorCitzdGF0aWMgdm9pZAor dnRuZXRfcnhfaW50cl90YXNrKHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCit7CisJc3RydWN0IHZ0 bmV0X3NvZnRjICpzYzsKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlpbnQgZG9tb3JlOworCisJc2Mg PSBhcmc7CisJaWZwID0gc2MtPnZ0bmV0X2lmcDsKKworCVZUTkVUX0xPQ0soc2MpOworCisjaWZk ZWYgREVWSUNFX1BPTExJTkcKKwlpZiAoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9QT0xMSU5H KSB7CisJCVZUTkVUX1VOTE9DSyhzYyk7CisJCXJldHVybjsKKwl9CisjZW5kaWYKKworCWlmICgo aWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpID09IDApIHsKKwkJdnRuZXRfZW5h YmxlX3J4X2ludHIoc2MpOworCQlWVE5FVF9VTkxPQ0soc2MpOworCQlyZXR1cm47CisJfQorCisJ ZG9tb3JlID0gdnRuZXRfcnhlb2Yoc2MsIHNjLT52dG5ldF9yeF9wcm9jZXNzX2xpbWl0LCBOVUxM KTsKKwlpZiAoIWRvbW9yZSAmJiB2dG5ldF9lbmFibGVfcnhfaW50cihzYykgIT0gMCkgeworCQlk b21vcmUgPSAxOworCQl2dG5ldF9kaXNhYmxlX3J4X2ludHIoc2MpOworCX0KKworCVZUTkVUX1VO TE9DSyhzYyk7CisKKwlpZiAoZG9tb3JlKQorCQl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHNjLT52 dG5ldF90cSwKKwkJICAgICZzYy0+dnRuZXRfcnhfaW50cl90YXNrKTsKK30KKworc3RhdGljIGlu dAordnRuZXRfcnhfdnFfaW50cih2b2lkICp4c2MpCit7CisJc3RydWN0IHZ0bmV0X3NvZnRjICpz YzsKKworCXNjID0geHNjOworCisJdnRuZXRfZGlzYWJsZV9yeF9pbnRyKHNjKTsKKwl0YXNrcXVl dWVfZW5xdWV1ZV9mYXN0KHNjLT52dG5ldF90cSwgJnNjLT52dG5ldF9yeF9pbnRyX3Rhc2spOwor CisJcmV0dXJuICgxKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X3R4ZW9mKHN0cnVjdCB2dG5l dF9zb2Z0YyAqc2MpCit7CisJc3RydWN0IHZpcnRxdWV1ZSAqdnE7CisJc3RydWN0IGlmbmV0ICpp ZnA7CisJc3RydWN0IG1idWYgKm07CisJaW50IGRlcTsKKworCXZxID0gc2MtPnZ0bmV0X3R4X3Zx OworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisJZGVxID0gMDsKKworCVZUTkVUX0xPQ0tfQVNTRVJU KHNjKTsKKworCXdoaWxlICgobSA9IHZxX3JpbmdfZGVxdWV1ZSh2cSwgTlVMTCkpICE9IE5VTEwp IHsKKwkJZGVxKys7CisJCWlmcC0+aWZfb3BhY2tldHMrKzsKKwkJbV9mcmVlbShtKTsKKwl9CisK KwlpZiAoZGVxID4gMCkgeworCQlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9PQUNUSVZF OworCQlpZiAodmlydHF1ZXVlX2VtcHR5KHZxKSkKKwkJCXNjLT52dG5ldF93YXRjaGRvZ190aW1l ciA9IDA7CisJfQorfQorCitzdGF0aWMgc3RydWN0IG1idWYgKgordnRuZXRfdmxhbl90YWdfaW5z ZXJ0KHN0cnVjdCBtYnVmICptKQoreworCXN0cnVjdCBtYnVmICpuOworCXN0cnVjdCBldGhlcl92 bGFuX2hlYWRlciAqZXZsOworCisJaWYgKE1fV1JJVEFCTEUobSkgPT0gMCkgeworCQluID0gbV9k dXAobSwgTV9ET05UV0FJVCk7CisJCW1fZnJlZW0obSk7CisJCWlmICgobSA9IG4pID09IE5VTEwp CisJCQlyZXR1cm4gKE5VTEwpOworCX0KKworCU1fUFJFUEVORChtLCBFVEhFUl9WTEFOX0VOQ0FQ X0xFTiwgTV9ET05UV0FJVCk7CisJaWYgKG0gPT0gTlVMTCkKKwkJcmV0dXJuIChOVUxMKTsKKwlp ZiAobS0+bV9sZW4gPCBzaXplb2Yoc3RydWN0IGV0aGVyX3ZsYW5faGVhZGVyKSkgeworCQltID0g bV9wdWxsdXAobSwgc2l6ZW9mKHN0cnVjdCBldGhlcl92bGFuX2hlYWRlcikpOworCQlpZiAobSA9 PSBOVUxMKQorCQkJcmV0dXJuIChOVUxMKTsKKwl9CisKKwkvKiBJbnNlcnQgODAyLjFRIGhlYWRl ciBpbnRvIHRoZSBleGlzdGluZyBFdGhlcm5ldCBoZWFkZXIuICovCisJZXZsID0gbXRvZChtLCBz dHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIgKik7CisJYmNvcHkoKGNoYXIgKikgZXZsICsgRVRIRVJf VkxBTl9FTkNBUF9MRU4sCisJICAgICAgKGNoYXIgKikgZXZsLCBFVEhFUl9IRFJfTEVOIC0gRVRI RVJfVFlQRV9MRU4pOworCWV2bC0+ZXZsX2VuY2FwX3Byb3RvID0gaHRvbnMoRVRIRVJUWVBFX1ZM QU4pOworCWV2bC0+ZXZsX3RhZyA9IGh0b25zKG0tPm1fcGt0aGRyLmV0aGVyX3Z0YWcpOworCW0t Pm1fZmxhZ3MgJj0gfk1fVkxBTlRBRzsKKworCXJldHVybiAobSk7Cit9CisKK3N0YXRpYyBzdHJ1 Y3QgbWJ1ZiAqCit2dG5ldF9nZXRfZnJhbWVfdHlwZShzdHJ1Y3QgbWJ1ZiAqbSwgdWludDE2X3Qg KmV0eXBlLCBpbnQgKmlwX29mZikKK3sKKwlzdHJ1Y3QgZXRoZXJfaGVhZGVyICplaDsKKwlzdHJ1 Y3QgZXRoZXJfdmxhbl9oZWFkZXIgKmV2aDsKKwlpbnQgb2Zmc2V0OworCisJLyoKKwkgKiBEZXRl cm1pbmUgcGF5bG9hZCB0eXBlIC0gSVB2NCwgSVB2NiwgZXRjIC0gb2YgdGhlIGZyYW1lLgorCSAq LworCisJb2Zmc2V0ID0gc2l6ZW9mKHN0cnVjdCBldGhlcl9oZWFkZXIpOworCWlmIChtLT5tX2xl biA8IG9mZnNldCkKKwkJaWYgKChtID0gbV9wdWxsdXAobSwgb2Zmc2V0KSkgPT0gTlVMTCkKKwkJ CXJldHVybiAoTlVMTCk7CisKKwllaCA9IG10b2QobSwgc3RydWN0IGV0aGVyX2hlYWRlciAqKTsK KwlpZiAoZWgtPmV0aGVyX3R5cGUgPT0gaHRvbnMoRVRIRVJUWVBFX1ZMQU4pKSB7CisJCW9mZnNl dCA9IHNpemVvZihzdHJ1Y3QgZXRoZXJfdmxhbl9oZWFkZXIpOworCQlpZiAoKG0gPSBtX3B1bGx1 cChtLCBvZmZzZXQpKSA9PSBOVUxMKQorCQkJcmV0dXJuIChOVUxMKTsKKworCQlldmggPSBtdG9k KG0sIHN0cnVjdCBldGhlcl92bGFuX2hlYWRlciAqKTsKKwkJKmV0eXBlID0gbnRvaHMoZXZoLT5l dmxfcHJvdG8pOworCX0gZWxzZQorCQkqZXR5cGUgPSBudG9ocyhlaC0+ZXRoZXJfdHlwZSk7CisJ KmlwX29mZiA9IG9mZnNldDsKKworCXJldHVybiAobSk7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgbWJ1 ZiAqCit2dG5ldF9zZXR1cF90c28oc3RydWN0IHZ0bmV0X3NvZnRjICpzYywgc3RydWN0IG1idWYg Km0sCisgICAgc3RydWN0IHZpcnRpb19uZXRfaGRyICpoZHIsIHVpbnQxNl90IGV0eXBlLCBpbnQg aXBfb2ZmKQoreworCXN0cnVjdCBpZm5ldCAqaWZwOworCXN0cnVjdCB0Y3BoZHIgKnRjcDsKKwl1 aW50OF90IGdzb190eXBlOworCWludCB0Y3Bfb2ZmOworCisJaWZwID0gc2MtPnZ0bmV0X2lmcDsK KworCXN3aXRjaCAoZXR5cGUpIHsKKwljYXNlIEVUSEVSVFlQRV9JUDoKKwkgICAgeworCQlzdHJ1 Y3QgaXAgKmlwOworCisJCWlmIChtLT5tX2xlbiA8IGlwX29mZiArIHNpemVvZihzdHJ1Y3QgaXAp KSB7CisJCQltID0gbV9wdWxsdXAobSwgaXBfb2ZmICsgc2l6ZW9mKHN0cnVjdCBpcCkpOworCQkJ aWYgKG0gPT0gTlVMTCkKKwkJCQlyZXR1cm4gKE5VTEwpOworCQl9CisJCWlwID0gKHN0cnVjdCBp cCAqKShtdG9kKG0sIHVpbnQ4X3QgKikgKyBpcF9vZmYpOworCisJCWdzb190eXBlID0gVklSVElP X05FVF9IRFJfR1NPX1RDUFY0OworCQl0Y3Bfb2ZmID0gaXBfb2ZmICsgKGlwLT5pcF9obCA8PCAy KTsKKwkgICAgfQorCSAgICBicmVhazsKKworCWNhc2UgRVRIRVJUWVBFX0lQVjY6CisJICAgIHsK KwkJc3RydWN0IGlwNl9oZHIgKmlwNjsKKworCQlpZiAobS0+bV9sZW4gPCBpcF9vZmYgKyBzaXpl b2Yoc3RydWN0IGlwNl9oZHIpKSB7CisJCQltID0gbV9wdWxsdXAobSwgaXBfb2ZmICsgc2l6ZW9m KHN0cnVjdCBpcDZfaGRyKSk7CisJCQlpZiAobSA9PSBOVUxMKQorCQkJCXJldHVybiAoTlVMTCk7 CisJCX0KKworCQlpcDYgPSAoc3RydWN0IGlwNl9oZHIgKikobXRvZChtLCB1aW50OF90ICopICsg aXBfb2ZmKTsKKworCQkvKgorCQkgKiBGcmVlQlNEIGRvZXNuJ3Qgc3VwcG9ydCBUU08gb3ZlciBJ UHY2IHlldC4KKwkJICovCisKKwkJZ3NvX3R5cGUgPSBWSVJUSU9fTkVUX0hEUl9HU09fVENQVjY7 CisJCXRjcF9vZmYgPSAwOworCSAgICB9CisJICAgIC8qIEZBTExUSFJPVUdIICovCisKKwlkZWZh dWx0OgorCQlzYy0+dnRuZXRfc3RhdHMudHhfdHNvX3Vua25vd25fZXR5cGUrKzsKKwkJbV9mcmVl bShtKTsKKwkJcmV0dXJuIChOVUxMKTsKKwl9CisKKwlpZiAobS0+bV9sZW4gPCB0Y3Bfb2ZmICsg c2l6ZW9mKHN0cnVjdCB0Y3BoZHIpKSB7CisJCW0gPSBtX3B1bGx1cChtLCB0Y3Bfb2ZmICsgc2l6 ZW9mKHN0cnVjdCB0Y3BoZHIpKTsKKwkJaWYgKG0gPT0gTlVMTCkKKwkJCXJldHVybiAoTlVMTCk7 CisJfQorCXRjcCA9IChzdHJ1Y3QgdGNwaGRyICopKG10b2QobSwgdWludDhfdCAqKSArIHRjcF9v ZmYpOworCisJaGRyLT5nc29fdHlwZSA9IGdzb190eXBlOworCWhkci0+aGRyX2xlbiA9IHRjcF9v ZmYgKyAodGNwLT50aF9vZmYgPDwgMik7CisJaGRyLT5nc29fc2l6ZSA9IG0tPm1fcGt0aGRyLnRz b19zZWdzejsKKworCWlmICh0Y3AtPnRoX2ZsYWdzICYgVEhfQ1dSKSB7CisJCS8qCisJCSAqIERy b3AgcGFja2V0IGlmIGRpZCBub3QgbmVnb3RpYXRlIFZJUlRJT19ORVRfRl9IT1NUX0VDTi4KKwkJ ICogRnJlZUJTRCBkb2VzIG5vdCBkaXN0aW5ndWlzaCBUU08vRUNOIHN1cHBvcnQgb24gYSBwZXIt CisJCSAqIGludGVyZmFjZSBiYXNpcy4gUmF0aGVyLCBpdCBpcyBjb250cm9sbGVkIGdsb2JhbGx5 IHZpYQorCQkgKiB0aGUgYG5ldC5pbmV0LnRjcC5lY24uZW5hYmxlYCBzeXNjdGwuCisJCSAqLwor CQlpZiAoKHNjLT52dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdfVFNPX0VDTikgPT0gMCkgeworCQkJ aWZfcHJpbnRmKGlmcCwgIlRTTyB3aXRoIEVDTiBub3Qgc3VwcG9ydGVkIGJ5IGhvc3RcbiIpOwor CQkJbV9mcmVlbShtKTsKKwkJCXJldHVybiAoTlVMTCk7CisJCX0KKworCQloZHItPmZsYWdzIHw9 IFZJUlRJT19ORVRfSERSX0dTT19FQ047CisJfQorCisJcmV0dXJuIChtKTsKK30KKworc3RhdGlj IHN0cnVjdCBtYnVmICoKK3Z0bmV0X3R4X2NzdW0oc3RydWN0IHZ0bmV0X3NvZnRjICpzYywgc3Ry dWN0IG1idWYgKm0sCisgICAgc3RydWN0IHZpcnRpb19uZXRfaGRyICpoZHIsIHVpbnQxNl90IGV0 eXBlLCBpbnQgaXBfb2ZmKQoreworCXVpbnQxNl90IGNzdW1fc3RhcnQ7CisKKwlzd2l0Y2ggKGV0 eXBlKSB7CisJY2FzZSBFVEhFUlRZUEVfSVA6CisJICAgIHsKKwkJc3RydWN0IGlwICppcDsKKwor CQlpZiAobS0+bV9sZW4gPCBpcF9vZmYgKyBzaXplb2Yoc3RydWN0IGlwKSkgeworCQkJbSA9IG1f cHVsbHVwKG0sIGlwX29mZiArIHNpemVvZihzdHJ1Y3QgaXApKTsKKwkJCWlmIChtID09IE5VTEwp CisJCQkJcmV0dXJuIChOVUxMKTsKKwkJfQorCisJCWlwID0gKHN0cnVjdCBpcCAqKShtdG9kKG0s IHVpbnQ4X3QgKikgKyBpcF9vZmYpOworCQkvKiBBc3N1bWUgY2hlY2tzdW0gYmVnaW5zIHJpZ2h0 IGFmdGVyIGVuZCBvZiBoZWFkZXIuICovCisJCWNzdW1fc3RhcnQgPSBpcF9vZmYgKyAoaXAtPmlw X2hsIDw8IDIpOworCSAgICB9CisJICAgIGJyZWFrOworCisJICAgIC8qCisJICAgICAqIEZyZWVC U0QgZG9lcyBub3QgZG8gY2hlY2tzdW0gb2ZmbG9hZGluZyBvZiBJUHY2IHlldC4KKwkgICAgICov CisKKwlkZWZhdWx0OgorCQlzYy0+dnRuZXRfc3RhdHMudHhfY3N1bV91bmtub3duX2V0eXBlKys7 CisJCXJldHVybiAobSk7CisJfQorCisJaGRyLT5mbGFncyB8PSBWSVJUSU9fTkVUX0hEUl9GX05F RURTX0NTVU07CisJaGRyLT5jc3VtX3N0YXJ0ID0gY3N1bV9zdGFydDsKKwloZHItPmNzdW1fb2Zm c2V0ID0gbS0+bV9wa3RoZHIuY3N1bV9kYXRhOworCisJc2MtPnZ0bmV0X3N0YXRzLnR4X2NzdW1f b2ZmbG9hZGVkKys7CisKKwlyZXR1cm4gKG0pOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9lbnF1 ZXVlX3R4YnVmKHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MsIHN0cnVjdCBtYnVmICoqbV9oZWFkLAor ICAgIHN0cnVjdCB2dG5ldF90eF9tYnVmX2hlYWRlciAqdHhoZHIpCit7CisJc3RydWN0IHNnbGlz dCBzZzsKKwlzdHJ1Y3Qgc2dsaXN0X3NlZyBzZWdzW1ZUTkVUX01BWF9UWF9TRUdTXTsKKwlzdHJ1 Y3QgdmlydHF1ZXVlICp2cTsKKwlzdHJ1Y3QgbWJ1ZiAqbTsKKwl1aW50OF90ICpkYXRhOworCWlu dCB0eGhkcnN6LCByZXNpZCwgY29sbGFwc2VkLCBlcnJvcjsKKworCXZxID0gc2MtPnZ0bmV0X3R4 X3ZxOworCW0gPSAqbV9oZWFkOworCXR4aGRyc3ogPSBzaXplb2Yoc3RydWN0IHZ0bmV0X3R4X21i dWZfaGVhZGVyKTsKKwljb2xsYXBzZWQgPSAwOworCisJLyoKKwkgKiBFbnN1cmUgdGhlcmUgaXMg c3VmZmljaWVudCBsZWFkaW5nIHNwYWNlIGluIHRoZSBtYnVmCisJICogdG8gaG9sZCBvdXIgaGVh ZGVyLiBJZGVhbGx5LCBvdXIgaGVhZGVyIHdpbGwgZml4IGluCisJICogdGhlIHJlbWFpbmluZyBz cGFjZSBpbiBvZiB0aGUgYG1heF9saW5rZGhyYCByZWdpb24sCisJICogc28gbm8gYWRkaXRpb25h bCBhbGxvY2F0aW9uIHdpbGwgYmUgcmVxdWlyZWQuCisJICovCisJTV9QUkVQRU5EKG0sIHR4aGRy c3osIE1fRE9OVFdBSVQpOworCWlmIChtID09IE5VTEwpCisJCWdvdG8gZmFpbDsKKworCSptX2hl YWQgPSBtOworCithZ2FpbjoKKwlzZ2xpc3RfaW5pdCgmc2csIFZUTkVUX01BWF9UWF9TRUdTLCBz ZWdzKTsKKworCWRhdGEgPSBtdG9kKG0sIHVpbnQ4X3QgKik7CisJbWVtY3B5KGRhdGEsIHR4aGRy LCB0eGhkcnN6KTsKKworCS8qIEFkZCBoZWFkZXIgdG8gc2dsaXN0LiAqLworCWVycm9yID0gc2ds aXN0X2FwcGVuZCgmc2csIGRhdGEsIHNjLT52dG5ldF9oZHJfc2l6ZSk7CisJS0FTU0VSVChlcnJv ciA9PSAwLCAoImNhbm5vdCBhZGQgaGVhZGVyIHRvIHNnbGlzdCIpKTsKKworCS8qIEFkZCByZW1h aW5kZXIgb2YgdGhlIGZpcnN0IG1idWYuICovCisJaWYgKChyZXNpZCA9IG0tPm1fbGVuIC0gdHho ZHJzeikgPiAwKSB7CisJCWVycm9yID0gc2dsaXN0X2FwcGVuZCgmc2csIGRhdGEgKyB0eGhkcnN6 LCByZXNpZCk7CisJCUtBU1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIHJlc3Qgb2YgbWJ1 ZiB0byBzZ2xpc3QiKSk7CisJfQorCisJaWYgKG0tPm1fbmV4dCAhPSBOVUxMKSB7CisJCS8qIEFk ZCB0aGUgcmVzdCBvZiB0aGUgbWJ1ZiBjaGFpbi4gKi8KKwkJZXJyb3IgPSBzZ2xpc3RfYXBwZW5k X21idWYoJnNnLCBtLT5tX25leHQpOworCQlpZiAoZXJyb3IpIHsKKwkJCWlmIChjb2xsYXBzZWQp CisJCQkJZ290byBmYWlsOworCisJCQltID0gbV9jb2xsYXBzZShtLCBNX0RPTlRXQUlULCBWVE5F VF9NQVhfVFhfU0VHUyAtIDEpOworCQkJaWYgKG0gPT0gTlVMTCkKKwkJCQlnb3RvIGZhaWw7CisK KwkJCSptX2hlYWQgPSBtOworCQkJY29sbGFwc2VkID0gMTsKKwkJCWdvdG8gYWdhaW47CisJCX0K Kwl9CisKKwlyZXR1cm4gKHZxX3JpbmdfZW5xdWV1ZSh2cSwgbSwgJnNnLCBzZy5zZ19uc2VnLCAw KSk7CisKK2ZhaWw6CisJc2MtPnZ0bmV0X3N0YXRzLnR4X2VucXVldWVfZmFpbGVkKys7CisJbV9m cmVlbSgqbV9oZWFkKTsKKwkqbV9oZWFkID0gTlVMTDsKKwlyZXR1cm4gKEVOT0JVRlMpOworfQor CitzdGF0aWMgaW50Cit2dG5ldF9lbmNhcChzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjLCBzdHJ1Y3Qg bWJ1ZiAqKm1faGVhZCkKK3sKKwlzdHJ1Y3QgdnRuZXRfdHhfbWJ1Zl9oZWFkZXIgdHhoZHI7CisJ c3RydWN0IHZpcnRpb19uZXRfaGRyICpoZHI7CisJc3RydWN0IG1idWYgKm07CisJaW50IGlwX29m ZjsKKwl1aW50MTZfdCBldHlwZTsKKworCW0gPSAqbV9oZWFkOworCWhkciA9ICZ0eGhkci52dGhf dWhkci5oZHI7CisJYnplcm8oJnR4aGRyLCBzaXplb2Yoc3RydWN0IHZ0bmV0X3R4X21idWZfaGVh ZGVyKSk7CisKKwlpZiAobS0+bV9mbGFncyAmIE1fVkxBTlRBRykgeworCQltID0gdnRuZXRfdmxh bl90YWdfaW5zZXJ0KG0pOworCQlpZiAoKCptX2hlYWQgPSBtKSA9PSBOVUxMKQorCQkJcmV0dXJu IChFTk9CVUZTKTsKKwl9CisKKwlpZiAobS0+bV9wa3RoZHIuY3N1bV9mbGFncyAhPSAwKSB7CisJ CW0gPSB2dG5ldF9nZXRfZnJhbWVfdHlwZShtLCAmZXR5cGUsICZpcF9vZmYpOworCQlpZiAoKCpt X2hlYWQgPSBtKSA9PSBOVUxMKQorCQkgICAgcmV0dXJuIChFTk9CVUZTKTsKKworCQlpZiAobS0+ bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fREVMQVlfREFUQSkgeworCQkJbSA9IHZ0bmV0X3R4 X2NzdW0oc2MsIG0sIGhkciwgZXR5cGUsIGlwX29mZik7CisJCQlpZiAoKCptX2hlYWQgPSBtKSA9 PSBOVUxMKQorCQkJCXJldHVybiAoRU5PQlVGUyk7CisJCX0KKworCQlpZiAobS0+bV9wa3RoZHIu Y3N1bV9mbGFncyAmIENTVU1fVFNPKSB7CisJCQltID0gdnRuZXRfc2V0dXBfdHNvKHNjLCBtLCBo ZHIsIGV0eXBlLCBpcF9vZmYpOworCQkJaWYgKCgqbV9oZWFkID0gbSkgPT0gTlVMTCkKKwkJCQly ZXR1cm4gKEVOT0JVRlMpOworCQl9IGVsc2UKKwkJCWhkci0+Z3NvX3R5cGUgPSBWSVJUSU9fTkVU X0hEUl9HU09fTk9ORTsKKwl9CisKKwlyZXR1cm4gKHZ0bmV0X2VucXVldWVfdHhidWYoc2MsIG1f aGVhZCwgJnR4aGRyKSk7Cit9CisKK3N0YXRpYyB2b2lkCit2dG5ldF9zdGFydChzdHJ1Y3QgaWZu ZXQgKmlmcCkKK3sKKwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjOworCisJc2MgPSBpZnAtPmlmX3Nv ZnRjOworCisJVlRORVRfTE9DSyhzYyk7CisJdnRuZXRfc3RhcnRfbG9ja2VkKGlmcCk7CisJVlRO RVRfVU5MT0NLKHNjKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X3N0YXJ0X2xvY2tlZChzdHJ1 Y3QgaWZuZXQgKmlmcCkKK3sKKwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjOworCXN0cnVjdCB2aXJ0 cXVldWUgKnZxOworCXN0cnVjdCBtYnVmICptMDsKKwlpbnQgZW5xOworCisJc2MgPSBpZnAtPmlm X3NvZnRjOworCXZxID0gc2MtPnZ0bmV0X3R4X3ZxOworCWVucSA9IDA7CisKKwlWVE5FVF9MT0NL X0FTU0VSVChzYyk7CisKKwlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgKElGRl9EUlZfUlVOTklO RyB8IElGRl9EUlZfT0FDVElWRSkpICE9CisJICAgIElGRl9EUlZfUlVOTklORyB8fCAoKHNjLT52 dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdfTElOSykgPT0gMCkpCisJCXJldHVybjsKKworCXdoaWxl ICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKSB7CisJCWlmICh2aXJ0cXVldWVfZnVs bCh2cSkpIHsKKwkJCWlmcC0+aWZfZHJ2X2ZsYWdzIHw9IElGRl9EUlZfT0FDVElWRTsKKwkJCWJy ZWFrOworCQl9CisKKwkJSUZRX0RSVl9ERVFVRVVFKCZpZnAtPmlmX3NuZCwgbTApOworCQlpZiAo bTAgPT0gTlVMTCkKKwkJCWJyZWFrOworCisJCWlmICh2dG5ldF9lbmNhcChzYywgJm0wKSAhPSAw KSB7CisJCQlpZiAobTAgPT0gTlVMTCkKKwkJCQlicmVhazsKKwkJCUlGUV9EUlZfUFJFUEVORCgm aWZwLT5pZl9zbmQsIG0wKTsKKwkJCWlmcC0+aWZfZHJ2X2ZsYWdzIHw9IElGRl9EUlZfT0FDVElW RTsKKwkJCWJyZWFrOworCQl9CisKKwkJZW5xKys7CisJCUVUSEVSX0JQRl9NVEFQKGlmcCwgbTAp OworCX0KKworCWlmIChlbnEgPiAwKSB7CisJCXZxX3Jpbmdfc3luYyh2cSk7CisKKwkJc2MtPnZ0 bmV0X3dhdGNoZG9nX3RpbWVyID0gVlRORVRfV0FUQ0hET0dfVElNRU9VVDsKKwl9Cit9CisKK3N0 YXRpYyB2b2lkCit2dG5ldF90eF90YXNrKHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCit7CisJc3Ry dWN0IGlmbmV0ICppZnA7CisKKwlpZnAgPSBhcmc7CisJdnRuZXRfc3RhcnQoaWZwKTsKK30KKwor c3RhdGljIHZvaWQKK3Z0bmV0X3RpY2sodm9pZCAqeHNjKQoreworCXN0cnVjdCB2dG5ldF9zb2Z0 YyAqc2M7CisJc3RydWN0IGlmbmV0ICppZnA7CisKKwlzYyA9IHhzYzsKKwlpZnAgPSBzYy0+dnRu ZXRfaWZwOworCisJVlRORVRfTE9DS19BU1NFUlQoc2MpOworCisjaWZkZWYgVlRORVRfREVCVUcK Kwl2aXJ0cXVldWVfZHVtcChzYy0+dnRuZXRfcnhfdnEpOworCXZpcnRxdWV1ZV9kdW1wKHNjLT52 dG5ldF90eF92cSk7CisjZW5kaWYKKworI2lmZGVmIERFVklDRV9QT0xMSU5HCisJaWYgKChpZnAt PmlmX2NhcGVuYWJsZSAmIElGQ0FQX1BPTExJTkcpID09IDApCisjZW5kaWYKKwl7CisJLyogSW4g cG9sbGluZyBtb2RlLCB3ZSBwb2xsIGxpbmsgc3RhdGUgaW4gdnRuZXRfcG9sbCgpLiAqLworCXZ0 bmV0X3VwZGF0ZV9saW5rX3N0YXR1cyhzYyk7CisJfQorCisJdnRuZXRfd2F0Y2hkb2coc2MpOwor CWNhbGxvdXRfcmVzZXQoJnNjLT52dG5ldF90aWNrX2NoLCBoeiwgdnRuZXRfdGljaywgc2MpOwor fQorCitzdGF0aWMgdm9pZAordnRuZXRfdHhfaW50cl90YXNrKHZvaWQgKmFyZywgaW50IHBlbmRp bmcpCit7CisJc3RydWN0IHZ0bmV0X3NvZnRjICpzYzsKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwor CXNjID0gYXJnOworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisKKwlWVE5FVF9MT0NLKHNjKTsKKwor I2lmZGVmIERFVklDRV9QT0xMSU5HCisJaWYgKGlmcC0+aWZfY2FwZW5hYmxlICYgSUZDQVBfUE9M TElORykgeworCQlWVE5FVF9VTkxPQ0soc2MpOworCQlyZXR1cm47CisJfQorI2VuZGlmCisKKwlp ZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSA9PSAwKSB7CisJCXZ0bmV0 X2VuYWJsZV90eF9pbnRyKHNjKTsKKwkJVlRORVRfVU5MT0NLKHNjKTsKKwkJcmV0dXJuOworCX0K KworCXZ0bmV0X3R4ZW9mKHNjKTsKKworCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9z bmQpKQorCQl0YXNrcXVldWVfZW5xdWV1ZV9mYXN0KHNjLT52dG5ldF90cSwgJnNjLT52dG5ldF90 eF90YXNrKTsKKworCWlmICh2dG5ldF9lbmFibGVfdHhfaW50cihzYykgIT0gMCkgeworCQl2dG5l dF9kaXNhYmxlX3R4X2ludHIoc2MpOworCQlWVE5FVF9VTkxPQ0soc2MpOworCQl0YXNrcXVldWVf ZW5xdWV1ZV9mYXN0KHNjLT52dG5ldF90cSwgJnNjLT52dG5ldF90eF9pbnRyX3Rhc2spOworCQly ZXR1cm47CisJfQorCisJVlRORVRfVU5MT0NLKHNjKTsKK30KKworc3RhdGljIGludAordnRuZXRf dHhfdnFfaW50cih2b2lkICp4c2MpCit7CisJc3RydWN0IHZ0bmV0X3NvZnRjICpzYzsKKworCXNj ID0geHNjOworCisJdnRuZXRfZGlzYWJsZV90eF9pbnRyKHNjKTsKKwl0YXNrcXVldWVfZW5xdWV1 ZV9mYXN0KHNjLT52dG5ldF90cSwgJnNjLT52dG5ldF90eF9pbnRyX3Rhc2spOworCisJcmV0dXJu ICgxKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X3N0b3Aoc3RydWN0IHZ0bmV0X3NvZnRjICpz YykKK3sKKwlkZXZpY2VfdCBkZXY7CisJc3RydWN0IGlmbmV0ICppZnA7CisKKwlkZXYgPSBzYy0+ dnRuZXRfZGV2OworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisKKwlWVE5FVF9MT0NLX0FTU0VSVChz Yyk7CisKKwlzYy0+dnRuZXRfd2F0Y2hkb2dfdGltZXIgPSAwOworCWlmcC0+aWZfZHJ2X2ZsYWdz ICY9IH4oSUZGX0RSVl9SVU5OSU5HIHwgSUZGX0RSVl9PQUNUSVZFKTsKKworCWNhbGxvdXRfc3Rv cCgmc2MtPnZ0bmV0X3RpY2tfY2gpOworCisJdnRuZXRfZGlzYWJsZV9yeF9pbnRyKHNjKTsKKwl2 dG5ldF9kaXNhYmxlX3R4X2ludHIoc2MpOworCWlmIChzYy0+dnRuZXRfZmxhZ3MgJiBWVE5FVF9G TEFHX0NUUkxfVlEpCisJCXZ0bmV0X2Rpc2FibGVfY3RybF9pbnRyKHNjKTsKKworCS8qCisJICog U3RvcCB0aGUgaG9zdCBWaXJ0SU8gYWRhcHRlci4gTm90ZSB0aGlzIHdpbGwgcmVzZXQgdGhlIGhv c3QKKwkgKiBhZGFwdGVyJ3Mgc3RhdGUgYmFjayB0byB0aGUgcHJlLWluaXRpYWxpemVkIHN0YXRl LCBzbyBpbgorCSAqIG9yZGVyIHRvIG1ha2UgdGhlIGRldmljZSB1c2FibGUgYWdhaW4sIHdlIG11 c3QgZHJpdmUgaXQKKwkgKiB0aHJvdWdoIHZpcnRpb19yZWluaXQgYW5kIHZpcnRpb19yZWluaXRf Y29tcGxldGUuCisJICovCisJdmlydGlvX3N0b3AoZGV2KTsKKworCXNjLT52dG5ldF9mbGFncyAm PSB+VlRORVRfRkxBR19MSU5LOworCisJdnRuZXRfcnhlb2Yoc2MsIHNjLT52dG5ldF9yeF9zaXpl LCBOVUxMKTsKKwl2dG5ldF90eGVvZihzYyk7CisKKwl2dG5ldF9mcmVlX3J4X21idWZzKHNjKTsK Kwl2dG5ldF9mcmVlX3R4X21idWZzKHNjKTsKK30KKworc3RhdGljIGludAordnRuZXRfcmVpbml0 KHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MpCit7CisJc3RydWN0IGlmbmV0ICppZnA7CisJdWludDMy X3QgZmVhdHVyZXM7CisKKwlpZnAgPSBzYy0+dnRuZXRfaWZwOworCWZlYXR1cmVzID0gc2MtPnZ0 bmV0X2ZlYXR1cmVzOworCisJLyoKKwkgKiBSZS1uZWdvdGlhdGUgd2l0aCBob3N0LCBkaXNhYmxp bmcgYW55IFJ4IGZlYXR1cmVzIHdlCisJICogbm8gbG9uZ2VyIHdpc2ggdG8gc3VwcG9ydC4gVHgg ZmVhdHVyZXMgYXJlIGhhbmRsZWQgb24KKwkgKiBvdXIgc2lkZSB2aWEgaWZfY2FwZW5hYmxlIGFu ZCBpZl9od2Fzc2lzdC4KKwkgKi8KKworCWlmIChpZnAtPmlmX2NhcGFiaWxpdGllcyAmIElGQ0FQ X1JYQ1NVTSkgeworCQlpZiAoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9SWENTVU0pCisJCQlm ZWF0dXJlcyB8PSBWSVJUSU9fTkVUX0ZfR1VFU1RfQ1NVTTsKKwkJZWxzZQorCQkJZmVhdHVyZXMg Jj0gfihWSVJUSU9fTkVUX0ZfR1VFU1RfQ1NVTSB8CisJCQkgICAgVlRORVRfR1VFU1RfQ1NVTV9G RUFUVVJFUyk7CisJfQorCisJaWYgKGlmcC0+aWZfY2FwYWJpbGl0aWVzICYgSUZDQVBfTFJPKSB7 CisJCWlmIChpZnAtPmlmX2NhcGVuYWJsZSAmIElGQ0FQX0xSTykKKwkJCWZlYXR1cmVzIHw9IFZJ UlRJT19ORVRfRl9HVUVTVF9UU080IHwKKwkJCSAgICBWSVJUSU9fTkVUX0ZfR1VFU1RfVFNPNjsK KwkJZWxzZQorCQkJZmVhdHVyZXMgJj0gfihWSVJUSU9fTkVUX0ZfR1VFU1RfVFNPNCB8CisJCQkg ICAgVklSVElPX05FVF9GX0dVRVNUX1RTTzYpOworCX0KKworCWlmIChpZnAtPmlmX2NhcGFiaWxp dGllcyAmIElGQ0FQX1ZMQU5fSFdGSUxURVIpIHsKKwkJaWYgKGlmcC0+aWZfY2FwZW5hYmxlICYg SUZDQVBfVkxBTl9IV0ZJTFRFUikKKwkJCWZlYXR1cmVzIHw9IFZJUlRJT19ORVRfRl9DVFJMX1ZM QU47CisJCWVsc2UKKwkJCWZlYXR1cmVzICY9IH5WSVJUSU9fTkVUX0ZfQ1RSTF9WTEFOOworCX0K KworCXJldHVybiAodmlydGlvX3JlaW5pdChzYy0+dnRuZXRfZGV2LCBmZWF0dXJlcykpOworfQor CitzdGF0aWMgdm9pZAordnRuZXRfaW5pdF9sb2NrZWQoc3RydWN0IHZ0bmV0X3NvZnRjICpzYykK K3sKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlpbnQgZXJyb3I7CisKKwlpZnAgPSBzYy0+dnRuZXRf aWZwOworCisJVlRORVRfTE9DS19BU1NFUlQoc2MpOworCisJaWYgKGlmcC0+aWZfZHJ2X2ZsYWdz ICYgSUZGX0RSVl9SVU5OSU5HKQorCQlyZXR1cm47CisKKwkvKiBTdG9wIGhvc3QncyBhZGFwdGVy LCBjYW5jZWwgYW55IHBlbmRpbmcgSS9PLiAqLworCXZ0bmV0X3N0b3Aoc2MpOworCisJLyogUmVp bml0aWFsaXplIHRoZSBob3N0J3MgZGV2aWNlLiAqLworCWVycm9yID0gdnRuZXRfcmVpbml0KHNj KTsKKwlpZiAoZXJyb3IpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+dnRuZXRfZGV2LAorCQkgICAg InJlaW5pdGlhbGl6YXRpb24gZmFpbGVkLCBzdG9wcGluZyBkZXZpY2UuLi5cbiIpOworCQl2dG5l dF9zdG9wKHNjKTsKKwkJcmV0dXJuOworCX0KKworCS8qIEdldCBsYXRlc3QgTUFDIGFkZHJlc3Mg YW5kIHVwZGF0ZSBob3N0LiAqLworCWJjb3B5KElGX0xMQUREUihpZnApLCBzYy0+dnRuZXRfaHdh ZGRyLCBFVEhFUl9BRERSX0xFTik7CisJdnRuZXRfc2V0X2h3YWRkcihzYyk7CisKKwlpZnAtPmlm X2h3YXNzaXN0ID0gMDsKKwlpZiAoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9UWENTVU0pCisJ CWlmcC0+aWZfaHdhc3Npc3QgfD0gVlRORVRfQ1NVTV9GRUFUVVJFUzsKKwlpZiAoaWZwLT5pZl9j YXBlbmFibGUgJiBJRkNBUF9UU080KQorCQlpZnAtPmlmX2h3YXNzaXN0IHw9IENTVU1fVFNPOwor CisJZXJyb3IgPSB2dG5ldF9pbml0X3J4X3ZxKHNjKTsKKwlpZiAoZXJyb3IpIHsKKwkJZGV2aWNl X3ByaW50ZihzYy0+dnRuZXRfZGV2LAorCQkgICAgImNhbm5vdCBhbGxvY2F0ZSBtYnVmcyBmb3Ig UnggdmlydHF1ZXVlXG4iKTsKKwkJdnRuZXRfc3RvcChzYyk7CisJCXJldHVybjsKKwl9CisKKwlp ZiAoc2MtPnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19DVFJMX1ZRKSB7CisJCWlmIChzYy0+dnRu ZXRfZmxhZ3MgJiBWVE5FVF9GTEFHX0NUUkxfUlgpIHsKKwkJCS8qIFJlc3RvcmUgcHJvbWlzY3Vv dXMgYW5kIGFsbC1tdWx0aWNhc3QgbW9kZXMuICovCisJCQl2dG5ldF9yeF9maWx0ZXIoc2MpOwor CisJCQkvKiBSZXN0b3JlIE1BQyBmaWx0ZXJzLiAqLworCQkJdnRuZXRfcnhfZmlsdGVyX21hYyhz Yyk7CisJCX0KKworCQkvKiBSZXN0b3JlIFZMQU4gZmlsdGVycy4gKi8KKwkJaWYgKHNjLT52dG5l dF9mbGFncyAmIFZUTkVUX0ZMQUdfVkxBTl9GSUxURVIpCisJCQl2dG5ldF9yeF9maWx0ZXJfdmxh bihzYyk7CisJfQorCisjaWZkZWYgREVWSUNFX1BPTExJTkcKKwlpZiAoaWZwLT5pZl9jYXBlbmFi bGUgJiBJRkNBUF9QT0xMSU5HKSB7CisJCXZ0bmV0X2Rpc2FibGVfcnhfaW50cihzYyk7CisJCXZ0 bmV0X2Rpc2FibGVfdHhfaW50cihzYyk7CisJfSBlbHNlCisjZW5kaWYKKwl7CisJCXZ0bmV0X2Vu YWJsZV9yeF9pbnRyKHNjKTsKKwkJdnRuZXRfZW5hYmxlX3R4X2ludHIoc2MpOworCX0KKworCWlm cC0+aWZfZHJ2X2ZsYWdzIHw9IElGRl9EUlZfUlVOTklORzsKKwlpZnAtPmlmX2Rydl9mbGFncyAm PSB+SUZGX0RSVl9PQUNUSVZFOworCisJdmlydGlvX3JlaW5pdF9jb21wbGV0ZShzYy0+dnRuZXRf ZGV2KTsKKworCXZ0bmV0X3VwZGF0ZV9saW5rX3N0YXR1cyhzYyk7CisJY2FsbG91dF9yZXNldCgm c2MtPnZ0bmV0X3RpY2tfY2gsIGh6LCB2dG5ldF90aWNrLCBzYyk7Cit9CisKK3N0YXRpYyB2b2lk Cit2dG5ldF9pbml0KHZvaWQgKnhzYykKK3sKKwlzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjOworCisJ c2MgPSB4c2M7CisKKwlWVE5FVF9MT0NLKHNjKTsKKwl2dG5ldF9pbml0X2xvY2tlZChzYyk7CisJ VlRORVRfVU5MT0NLKHNjKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X2V4ZWNfY3RybF9jbWQo c3RydWN0IHZ0bmV0X3NvZnRjICpzYywgdm9pZCAqY29va2llLAorICAgIHN0cnVjdCBzZ2xpc3Qg KnNnLCBpbnQgcmVhZGFibGUsIGludCB3cml0YWJsZSkKK3sKKwlzdHJ1Y3QgdmlydHF1ZXVlICp2 cTsKKwl2b2lkICpjOworCWludCBlcnJvcjsKKworCXZxID0gc2MtPnZ0bmV0X2N0cmxfdnE7CisK KwlWVE5FVF9MT0NLX0FTU0VSVChzYyk7CisJS0FTU0VSVChzYy0+dnRuZXRfZmxhZ3MgJiBWVE5F VF9GTEFHX0NUUkxfVlEsICgibm8gY29udHJvbCB2cSIpKTsKKwkvKiBOb2JvZHkgc2hvdWxkIGJl IHBlbmRpbmcgYmVmb3JlIHVzLiAqLworCUtBU1NFUlQodmlydHF1ZXVlX2VtcHR5KHZxKSwgKCJj dHJsIGNtZCBhbHJlYWR5IGVucXVldWVkIikpOworCisJZXJyb3IgPSB2cV9yaW5nX2VucXVldWUo dnEsIGNvb2tpZSwgc2csIHJlYWRhYmxlLCB3cml0YWJsZSk7CisJS0FTU0VSVChlcnJvciA9PSAw LCAoImNhbm5vdCBlbnF1ZXVlIGN0cmwgY29tbWFuZCIpKTsKKworCXZxX3Jpbmdfc3luYyh2cSk7 CisKKwkvKgorCSAqIFBvbGwgdW50aWwgdGhlIGNvbW1hbmQgaXMgY29tcGxldGUuIFByZXZpb3Vz bHksIHdlIHdvdWxkCisJICogbXR4X3NsZWVwKCkgdW50aWwgdGhlIGludGVycnVwdCBoYW5kbGVy IHdva2UgdXAgdXMsIGJ1dAorCSAqIGRyb3BwaW5nIHRoZSBsb2NrIG9wZW5lZCB1cyB0byBhbGwg c29ydHMgb2Ygc2VyaWFsaXphdGlvbgorCSAqIGlzc3Vlcy4KKwkgKgorCSAqIEFsc28sIEtWTSBv bmx5IGFsbG9jYXRlcyB0aHJlZSBNU0lYIHZlY3RvcnMgLSBwcmVzdW1hYmx5CisJICogb25lIGZv ciB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2VzIGFuZCBvbmUgZWFjaCBmb3IgdGhlIFJ4CisJICog YW5kIFR4IHZpcnRxdWV1ZXMgLSBsZWF2aW5nIG5vbmUgZm9yIHRoZSBjb250cm9sIHZpcnRxdWV1 ZS4KKwkgKi8KKworCXdoaWxlICgoYyA9IHZxX3JpbmdfZGVxdWV1ZSh2cSwgTlVMTCkpID09IE5V TEwpCisJCWNwdV9zcGlud2FpdCgpOworCUtBU1NFUlQoYyA9PSBjb29raWUsICgibm90IG15IGN0 cmwgY21kIHJlc3BvbnNlIikpOworfQorCitzdGF0aWMgdm9pZAordnRuZXRfcnhfZmlsdGVyKHN0 cnVjdCB2dG5ldF9zb2Z0YyAqc2MpCit7CisJc3RydWN0IGlmbmV0ICppZnA7CisKKwlpZnAgPSBz Yy0+dnRuZXRfaWZwOworCisJVlRORVRfTE9DS19BU1NFUlQoc2MpOworCUtBU1NFUlQoc2MtPnZ0 bmV0X2ZsYWdzICYgVlRORVRfRkxBR19DVFJMX1JYLAorCSAgICAoIkNUUkxfUlggbm90IG5lZ290 aWF0ZWQiKSk7CisKKwlpZiAodnRuZXRfc2V0X3Byb21pc2Moc2MsIGlmcC0+aWZfZmxhZ3MgJiBJ RkZfUFJPTUlTQykgIT0gMCkKKwkJZGV2aWNlX3ByaW50ZihzYy0+dnRuZXRfZGV2LAorCQkgICAg ImNhbm5vdCAlcyBwcm9taXNjdW91cyBtb2RlXG4iLAorCQkgICAgaWZwLT5pZl9mbGFncyAmIElG Rl9QUk9NSVNDID8gImVuYWJsZSIgOiAiZGlzYWJsZSIpOworCisJaWYgKHZ0bmV0X3NldF9hbGxt dWx0aShzYywgaWZwLT5pZl9mbGFncyAmIElGRl9BTExNVUxUSSkgIT0gMCkKKwkJZGV2aWNlX3By aW50ZihzYy0+dnRuZXRfZGV2LAorCQkgICAgImNhbm5vdCAlcyBhbGwtbXVsdGljYXN0IG1vZGVc biIsCisJCSAgICBpZnAtPmlmX2ZsYWdzICYgSUZGX0FMTE1VTFRJID8gImVuYWJsZSIgOiAiZGlz YWJsZSIpOworfQorCitzdGF0aWMgaW50Cit2dG5ldF9jdHJsX3J4X2NtZChzdHJ1Y3QgdnRuZXRf c29mdGMgKnNjLCBpbnQgY21kLCBpbnQgb24pCit7CisJc3RydWN0IHZpcnRpb19uZXRfY3RybF9o ZHIgaGRyOworCXN0cnVjdCBzZ2xpc3Qgc2c7CisJc3RydWN0IHNnbGlzdF9zZWcgc2Vnc1szXTsK Kwl1aW50OF90IG9ub2ZmLCBhY2s7CisJaW50IGVycm9yOworCisJaWYgKChzYy0+dnRuZXRfZmxh Z3MgJiBWVE5FVF9GTEFHX0NUUkxfUlgpID09IDApCisJCXJldHVybiAoRU5PVFNVUCk7CisKKwlo ZHIuY2xhc3MgPSBWSVJUSU9fTkVUX0NUUkxfUlg7CisJaGRyLmNtZCA9IGNtZDsKKwlvbm9mZiA9 ICEhb247CisJYWNrID0gVklSVElPX05FVF9FUlI7CisKKwlzZ2xpc3RfaW5pdCgmc2csIDMsIHNl Z3MpOworCisJZXJyb3IgPSBzZ2xpc3RfYXBwZW5kKCZzZywgJmhkciwgc2l6ZW9mKGhkcikpOwor CUtBU1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIGNvbnRyb2wgaGVhZGVyIHRvIHNnbGlz dCIpKTsKKwllcnJvciA9IHNnbGlzdF9hcHBlbmQoJnNnLCAmb25vZmYsIHNpemVvZihvbm9mZikp OworCUtBU1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIG9uL29mZiB0byBzZ2xpc3QiKSk7 CisJZXJyb3IgPSBzZ2xpc3RfYXBwZW5kKCZzZywgJmFjaywgc2l6ZW9mKGFjaykpOworCUtBU1NF UlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIGFjayB0byBzZ2xpc3QiKSk7CisKKwl2dG5ldF9l eGVjX2N0cmxfY21kKHNjLCAmYWNrLCAmc2csIHNnLnNnX25zZWcgLSAxLCAxKTsKKworCXJldHVy biAoYWNrID09IFZJUlRJT19ORVRfT0sgPyAwIDogRUlPKTsKK30KKworc3RhdGljIGludAordnRu ZXRfc2V0X3Byb21pc2Moc3RydWN0IHZ0bmV0X3NvZnRjICpzYywgaW50IG9uKQoreworCWludCBl cnJvcjsKKworCWVycm9yID0gdnRuZXRfY3RybF9yeF9jbWQoc2MsIFZJUlRJT19ORVRfQ1RSTF9S WF9QUk9NSVNDLCBvbik7CisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK3Z0bmV0 X3NldF9hbGxtdWx0aShzdHJ1Y3QgdnRuZXRfc29mdGMgKnNjLCBpbnQgb24pCit7CisJaW50IGVy cm9yOworCisJZXJyb3IgPSB2dG5ldF9jdHJsX3J4X2NtZChzYywgVklSVElPX05FVF9DVFJMX1JY X0FMTE1VTFRJLCBvbik7CisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyB2b2lkCit2dG5l dF9yeF9maWx0ZXJfbWFjKHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MpCit7CisJc3RydWN0IHZpcnRp b19uZXRfY3RybF9oZHIgaGRyOworCXN0cnVjdCB2dG5ldF9tYWNfZmlsdGVyICpmaWx0ZXI7CisJ c3RydWN0IGlmbmV0ICppZnA7CisJc3RydWN0IGlmYWRkciAqaWZhOworCXN0cnVjdCBpZm11bHRp YWRkciAqaWZtYTsKKwlzdHJ1Y3Qgc2dsaXN0IHNnOworCXN0cnVjdCBzZ2xpc3Rfc2VnIHNlZ3Nb NF07CisJaW50IHVjbnQsIG1jbnQ7CisJaW50IHByb21pc2MsIGFsbG11bHRpOworCXVpbnQ4X3Qg YWNrOworCWludCBlcnJvcjsKKworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisJZmlsdGVyID0gTlVM TDsKKwl1Y250ID0gbWNudCA9IDA7CisJcHJvbWlzYyA9IGFsbG11bHRpID0gMDsKKworCVZUTkVU X0xPQ0tfQVNTRVJUKHNjKTsKKwlLQVNTRVJUKHNjLT52dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdf Q1RSTF9SWCwKKwkgICAgKCJDVFJMX1JYIG5vdCBuZWdvdGlhdGVkIikpOworCisJZmlsdGVyID0g Y29udGlnbWFsbG9jKFBBR0VfU0laRSwgTV9ERVZCVUYsIE1fTk9XQUlUIHwgTV9aRVJPLAorCSAg ICAwLCB+MHVsLCBQQUdFX1NJWkUsIDApOworCWlmIChmaWx0ZXIgPT0gTlVMTCkgeworCQlkZXZp Y2VfcHJpbnRmKHNjLT52dG5ldF9kZXYsICJjYW5ub3QgYWxsb2MgYnVmZmVyIGZvciAiCisJCSAg ICAiTUFDIGFkZHJlc3MgZmlsdGVyaW5nXG4iKTsKKwkJcmV0dXJuOworCX0KKworCS8qIFVuaWNh c3QuICovCisJaWZfYWRkcl9ybG9jayhpZnApOworCVRBSUxRX0ZPUkVBQ0goaWZhLCAmaWZwLT5p Zl9hZGRyaGVhZCwgaWZhX2xpbmspIHsKKwkJaWYgKGlmYS0+aWZhX2FkZHItPnNhX2ZhbWlseSAh PSBBRl9MSU5LKQorCQkJY29udGludWU7CisKKwkJaWYgKHVjbnQgPT0gVlRORVRfTUFYX01BQ19F TlRSSUVTKQorCQkJYnJlYWs7CisKKwkJYmNvcHkoTExBRERSKChzdHJ1Y3Qgc29ja2FkZHJfZGwg KilpZmEtPmlmYV9hZGRyKSwKKwkJICAgIGZpbHRlci0+dm1mX3VuaS5tYWNzW3VjbnRdLCBFVEhF Ul9BRERSX0xFTik7CisJCXVjbnQrKzsKKwl9CisJaWZfYWRkcl9ydW5sb2NrKGlmcCk7CisKKwlp ZiAodWNudCA+PSBWVE5FVF9NQVhfTUFDX0VOVFJJRVMpIHsKKwkJaWZfcHJpbnRmKGlmcCwgInRv byBtYW55IHVuaWNhc3QgYWRkcmVzc2VzLCAiCisJCSAgICAiZW5hYmxpbmcgcHJvbWlzY3VvdXMg bW9kZVxuIik7CisJCWZpbHRlci0+dm1mX3VuaS5uZW50cmllcyA9IDA7CisJCXByb21pc2MgPSAx OworCX0gZWxzZQorCQlmaWx0ZXItPnZtZl91bmkubmVudHJpZXMgPSB1Y250OworCisJLyogTXVs dGljYXN0LiAqLworCWlmX21hZGRyX3Jsb2NrKGlmcCk7CisJVEFJTFFfRk9SRUFDSChpZm1hLCAm aWZwLT5pZl9tdWx0aWFkZHJzLCBpZm1hX2xpbmspIHsKKwkJaWYgKGlmbWEtPmlmbWFfYWRkci0+ c2FfZmFtaWx5ICE9IEFGX0xJTkspCisJCQljb250aW51ZTsKKworCQlpZiAobWNudCA9PSBWVE5F VF9NQVhfTUFDX0VOVFJJRVMpCisJCQlicmVhazsKKworCQliY29weShMTEFERFIoKHN0cnVjdCBz b2NrYWRkcl9kbCAqKWlmbWEtPmlmbWFfYWRkciksCisJCSAgICAmZmlsdGVyLT52bWZfbXVsLm1h Y3NbbWNudF0sIEVUSEVSX0FERFJfTEVOKTsKKwkJbWNudCsrOworCX0KKwlpZl9tYWRkcl9ydW5s b2NrKGlmcCk7CisKKwlpZiAobWNudCA+PSBWVE5FVF9NQVhfTUFDX0VOVFJJRVMpIHsKKwkJaWZf cHJpbnRmKGlmcCwgInRvbyBtYW55IG11bHRpY2FzdCBhZGRyZXNzZXMsICIKKwkJICAgICJlbmFi bGluZyBhbGwtbXVsdGljYXN0IG1vZGVcbiIpOworCQlmaWx0ZXItPnZtZl9tdWwubmVudHJpZXMg PSAwOworCQlhbGxtdWx0aSA9IDE7CisJfSBlbHNlCisJCWZpbHRlci0+dm1mX211bC5uZW50cmll cyA9IG1jbnQ7CisKKwlpZiAocHJvbWlzYyAmJiBhbGxtdWx0aSkKKwkJZ290byBvdXQ7CisKKwlo ZHIuY2xhc3MgPSBWSVJUSU9fTkVUX0NUUkxfTUFDOworCWhkci5jbWQgPSBWSVJUSU9fTkVUX0NU UkxfTUFDX1RBQkxFX1NFVDsKKwlhY2sgPSBWSVJUSU9fTkVUX0VSUjsKKworCXNnbGlzdF9pbml0 KCZzZywgNCwgc2Vncyk7CisKKwllcnJvciA9IHNnbGlzdF9hcHBlbmQoJnNnLCAmaGRyLCBzaXpl b2YoaGRyKSk7CisJS0FTU0VSVChlcnJvciA9PSAwLCAoImNhbm5vdCBhZGQgY29udHJvbCBoZWFk ZXIgdG8gc2dsaXN0IikpOworCWVycm9yID0gc2dsaXN0X2FwcGVuZCgmc2csICZmaWx0ZXItPnZt Zl91bmksIHNpemVvZihmaWx0ZXItPnZtZl91bmkpKTsKKwlLQVNTRVJUKGVycm9yID09IDAsICgi Y2Fubm90IGFkZCB1bmljYXN0IG1hY3MgdG8gc2dsaXN0IikpOworCWVycm9yID0gc2dsaXN0X2Fw cGVuZCgmc2csICZmaWx0ZXItPnZtZl9tdWwsIHNpemVvZihmaWx0ZXItPnZtZl9tdWwpKTsKKwlL QVNTRVJUKGVycm9yID09IDAsICgiY2Fubm90IGFkZCBtdWx0aWNhc3QgbWFjcyB0byBzZ2xpc3Qi KSk7CisJZXJyb3IgPSBzZ2xpc3RfYXBwZW5kKCZzZywgJmFjaywgc2l6ZW9mKGFjaykpOworCUtB U1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIGFjayB0byBzZ2xpc3QiKSk7CisKKwl2dG5l dF9leGVjX2N0cmxfY21kKHNjLCAmYWNrLCAmc2csIHNnLnNnX25zZWcgLSAxLCAxKTsKKworCWlm IChhY2sgIT0gVklSVElPX05FVF9PSykgeworCQkvKiBGYWlsdXJlLCBkbyBwcm9taXNjL2FsbG11 bHRpIGluc3RlYWQuICovCisJCWRldmljZV9wcmludGYoc2MtPnZ0bmV0X2RldiwgImNhbm5vdCBz ZXQgbWFjIGFkZHJlc3MgIgorCQkgICAgInRhYmxlLCBmYWxsaW5nIGJhY2sgdG8gcHJvbWlzYy9h bGxtdWx0aVxuIik7CisJCWlmICh1Y250ID4gMSkKKwkJCXByb21pc2MgPSAxOworCQlpZiAobWNu dCA+IDApCisJCQlhbGxtdWx0aSA9IDE7CisJfQorCitvdXQ6CisJaWYgKGZpbHRlciAhPSBOVUxM KQorCQljb250aWdmcmVlKGZpbHRlciwgUEFHRV9TSVpFLCBNX0RFVkJVRik7CisKKwlpZiAocHJv bWlzYykgeworCQlpZiAodnRuZXRfc2V0X3Byb21pc2Moc2MsIDEpICE9IDApCisJCQlpZl9wcmlu dGYoaWZwLCAiY2Fubm90IGVuYWJsZSBwcm9taXNjdW91cyBtb2RlXG4iKTsKKwl9CisKKwlpZiAo YWxsbXVsdGkpIHsKKwkJaWYgKHZ0bmV0X3NldF9hbGxtdWx0aShzYywgMSkgIT0gMCkKKwkJCWlm X3ByaW50ZihpZnAsICJjYW5ub3QgZW5hYmxlIGFsbC1tdWx0aWNhc3QgbW9kZVxuIik7CisJfQor fQorCitzdGF0aWMgaW50Cit2dG5ldF9leGVjX3ZsYW5fZmlsdGVyKHN0cnVjdCB2dG5ldF9zb2Z0 YyAqc2MsIGludCBhZGQsIHVpbnQxNl90IHRhZykKK3sKKwlzdHJ1Y3QgdmlydGlvX25ldF9jdHJs X2hkciBoZHI7CisJc3RydWN0IHNnbGlzdCBzZzsKKwlzdHJ1Y3Qgc2dsaXN0X3NlZyBzZWdzWzNd OworCXVpbnQ4X3QgYWNrOworCWludCBlcnJvcjsKKworCWhkci5jbGFzcyA9IFZJUlRJT19ORVRf Q1RSTF9WTEFOOworCWhkci5jbWQgPSBhZGQgPyBWSVJUSU9fTkVUX0NUUkxfVkxBTl9BREQgOiBW SVJUSU9fTkVUX0NUUkxfVkxBTl9ERUw7CisJYWNrID0gVklSVElPX05FVF9FUlI7CisKKwlWVE5F VF9MT0NLX0FTU0VSVChzYyk7CisJS0FTU0VSVChzYy0+dnRuZXRfZmxhZ3MgJiBWVE5FVF9GTEFH X1ZMQU5fRklMVEVSLAorCSAgICAoIlZMQU5fRklMVEVSIG5vdCBuZWdvdGlhdGVkIikpOworCisJ c2dsaXN0X2luaXQoJnNnLCAzLCBzZWdzKTsKKwllcnJvciA9IHNnbGlzdF9hcHBlbmQoJnNnLCAm aGRyLCBzaXplb2YoaGRyKSk7CisJS0FTU0VSVChlcnJvciA9PSAwLCAoImNhbm5vdCBhZGQgY29u dHJvbCBoZWFkZXIgdG8gc2dsaXN0IikpOworCWVycm9yID0gc2dsaXN0X2FwcGVuZCgmc2csICZ0 YWcsIHNpemVvZih0YWcpKTsKKwlLQVNTRVJUKGVycm9yID09IDAsICgiY2Fubm90IGFkZCB2bGFu IHRhZyB0byBzZ2xpc3QiKSk7CisJZXJyb3IgPSBzZ2xpc3RfYXBwZW5kKCZzZywgJmFjaywgc2l6 ZW9mKGFjaykpOworCUtBU1NFUlQoZXJyb3IgPT0gMCwgKCJjYW5ub3QgYWRkIGFjayB0byBzZ2xp c3QiKSk7CisKKwl2dG5ldF9leGVjX2N0cmxfY21kKHNjLCAmYWNrLCAmc2csIHNnLnNnX25zZWcg LSAxLCAxKTsKKworCXJldHVybiAoYWNrID09IFZJUlRJT19ORVRfT0sgPyAwIDogRUlPKTsKK30K Kworc3RhdGljIHZvaWQKK3Z0bmV0X3J4X2ZpbHRlcl92bGFuKHN0cnVjdCB2dG5ldF9zb2Z0YyAq c2MpCit7CisJc3RydWN0IGlmbmV0ICppZnA7CisJdWludDMyX3QgdzsKKwl1aW50MTZfdCB2bGFu OworCWludCBpLCBqLCBlcnJvcjsKKworCWlmcCA9IHNjLT52dG5ldF9pZnA7CisJZXJyb3IgPSAw OworCisJVlRORVRfTE9DS19BU1NFUlQoc2MpOworCUtBU1NFUlQoc2MtPnZ0bmV0X2ZsYWdzICYg VlRORVRfRkxBR19WTEFOX0ZJTFRFUiwKKwkgICAgKCJWTEFOX0ZJTFRFUiBub3QgbmVnb3RpYXRl ZCIpKTsKKworCWlmICgoaWZwLT5pZl9jYXBlbmFibGUgJiBJRkNBUF9WTEFOX0hXRklMVEVSKSA9 PSAwIHx8CisJICAgIHNjLT52dG5ldF9udmxhbnMgPD0gMCkKKwkJcmV0dXJuOworCisJZm9yIChp ID0gMDsgaSA8IFZUTkVUX1ZMQU5fVEFCTEVfU1o7IGkrKykgeworCQl3ID0gc2MtPnZ0bmV0X3Zs YW5fdGFibGVbaV07CisJCWZvciAoaiA9IDA7IHcgIT0gMDsgaisrKSB7CisJCQlpZiAodyAmICgx IDw8IGopKSB7CisJCQkJdyAmPSB+KDEgPDwgaik7CisJCQkJdmxhbiA9IGkgKiAzMiArIGo7CisJ CQkJZXJyb3IgfD0gdnRuZXRfZXhlY192bGFuX2ZpbHRlcihzYywgMSwgdmxhbik7CisJCQl9CisJ CX0KKwl9CisKKwlpZiAoZXJyb3IpCisJCWRldmljZV9wcmludGYoc2MtPnZ0bmV0X2RldiwKKwkJ ICAgICJjYW5ub3QgcmVzdG9yZSB0aGUgaG9zdCdzIFZMQU4gdGFibGVcbiIpOworfQorCitzdGF0 aWMgdm9pZAordnRuZXRfc2V0X3ZsYW5fZmlsdGVyKHN0cnVjdCB2dG5ldF9zb2Z0YyAqc2MsIGlu dCBhZGQsIHVpbnQxNl90IHRhZykKK3sKKwlzdHJ1Y3QgaWZuZXQgKmlmcDsKKwlpbnQgaWR4LCBi aXQ7CisJaW50IGVycm9yOworCisJaWZwID0gc2MtPnZ0bmV0X2lmcDsKKwllcnJvciA9IDA7CisK KwlpZiAoKHRhZyA9PSAwKSB8fCAodGFnID4gNDA5NSkpCisJCXJldHVybjsKKworCWlkeCA9ICh0 YWcgPj4gNSkgJiAweDdGOworCWJpdCA9IHRhZyAmIDB4MUY7CisKKwlWVE5FVF9MT0NLKHNjKTsK KwlLQVNTRVJUKHNjLT52dG5ldF9mbGFncyAmIFZUTkVUX0ZMQUdfVkxBTl9GSUxURVIsCisJICAg ICgiVkxBTl9GSUxURVIgbm90IG5lZ290aWF0ZWQiKSk7CisKKwkvKiBVcGRhdGUgc2hhZG93IFZM QU4gdGFibGUuICovCisJaWYgKGFkZCkgeworCQlzYy0+dnRuZXRfbnZsYW5zKys7CisJCXNjLT52 dG5ldF92bGFuX3RhYmxlW2lkeF0gfD0gKDEgPDwgYml0KTsKKwl9IGVsc2UgeworCQlzYy0+dnRu ZXRfbnZsYW5zLS07CisJCXNjLT52dG5ldF92bGFuX3RhYmxlW2lkeF0gJj0gfigxIDw8IGJpdCk7 CisJfQorCisJaWYgKGlmcC0+aWZfY2FwZW5hYmxlICYgSUZDQVBfVkxBTl9IV0ZJTFRFUikKKwkJ ZXJyb3IgPSB2dG5ldF9leGVjX3ZsYW5fZmlsdGVyKHNjLCBhZGQsIHRhZyk7CisKKwlWVE5FVF9V TkxPQ0soc2MpOworCisJaWYgKGVycm9yKQorCQlkZXZpY2VfcHJpbnRmKHNjLT52dG5ldF9kZXYs ICJ1bmFibGUgdG8gdXBkYXRlIGhvc3QgIgorCQkgICAgIlZMQU4gdGFibGVcbiIpOworfQorCitz dGF0aWMgdm9pZAordnRuZXRfcmVnaXN0ZXJfdmxhbih2b2lkICphcmcsIHN0cnVjdCBpZm5ldCAq aWZwLCB1aW50MTZfdCB0YWcpCit7CisKKwlpZiAoaWZwLT5pZl9zb2Z0YyAhPSBhcmcpCisJCXJl dHVybjsKKworCXZ0bmV0X3NldF92bGFuX2ZpbHRlcihhcmcsIDEsIHRhZyk7Cit9CisKK3N0YXRp YyB2b2lkCit2dG5ldF91bnJlZ2lzdGVyX3ZsYW4odm9pZCAqYXJnLCBzdHJ1Y3QgaWZuZXQgKmlm cCwgdWludDE2X3QgdGFnKQoreworCisJaWYgKGlmcC0+aWZfc29mdGMgIT0gYXJnKQorCQlyZXR1 cm47CisKKwl2dG5ldF9zZXRfdmxhbl9maWx0ZXIoYXJnLCAwLCB0YWcpOworfQorCitzdGF0aWMg dm9pZAordnRuZXRfYWRkX3N0YXRpc3RpY3Moc3RydWN0IHZ0bmV0X3NvZnRjICpzYykKK3sKKwlk ZXZpY2VfdCBkZXY7CisJc3RydWN0IHZ0bmV0X3N0YXRpc3RpY3MgKnN0YXRzOworICAgICAgICBz dHJ1Y3Qgc3lzY3RsX2N0eF9saXN0ICpjdHg7CisJc3RydWN0IHN5c2N0bF9vaWQgKnRyZWU7CisJ c3RydWN0IHN5c2N0bF9vaWRfbGlzdCAqY2hpbGQ7CisKKwlkZXYgPSBzYy0+dnRuZXRfZGV2Owor CXN0YXRzID0gJnNjLT52dG5ldF9zdGF0czsKKwljdHggPSBkZXZpY2VfZ2V0X3N5c2N0bF9jdHgo ZGV2KTsKKwl0cmVlID0gZGV2aWNlX2dldF9zeXNjdGxfdHJlZShkZXYpOworCWNoaWxkID0gU1lT Q1RMX0NISUxEUkVOKHRyZWUpOworCisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxkLCBPSURf QVVUTywgIm1idWZfYWxsb2NfZmFpbGVkIiwKKwkgICAgQ1RMRkxBR19SRCwgJnN0YXRzLT5tYnVm X2FsbG9jX2ZhaWxlZCwKKwkgICAgIk1idWYgY2x1c3RlciBhbGxvY2F0aW9uIGZhaWx1cmVzIik7 CisKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAicnhfbWVyZ2VhYmxl X2ZhaWxlZCIsCisJICAgIENUTEZMQUdfUkQsICZzdGF0cy0+cnhfbWVyZ2VhYmxlX2ZhaWxlZCwK KwkgICAgIk1lcmdlYWJsZSBidWZmZXJzIHJlY2VpdmUgZmFpbHVyZXMiKTsKKwlTWVNDVExfQURE X1VMT05HKGN0eCwgY2hpbGQsIE9JRF9BVVRPLCAicnhfY3N1bV9vZmZsb2FkZWQiLAorCSAgICBD VExGTEFHX1JELCAmc3RhdHMtPnJ4X2NzdW1fb2ZmbG9hZGVkLAorCSAgICAiUmVjZWl2ZWQgYnVm ZmVyIHdpdGggY2hlY2tzdW0gb2ZmbG9hZGVkIik7CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNo aWxkLCBPSURfQVVUTywgInJ4X2NzdW1fdW5rbm93bl9ldHlwZSIsCisJICAgIENUTEZMQUdfUkQs ICZzdGF0cy0+cnhfY3N1bV91bmtub3duX2V0eXBlLAorCSAgICAiUmVjZWl2ZWQgY2hlY2tzdW0g b2ZmbG9hZGVkIGJ1ZmZlciB3aXRoIHVua25vd24gRXRoZXJuZXQgdHlwZSIpOworCVNZU0NUTF9B RERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJyeF9jc3VtX2JhZF9zdGFydCIsCisJICAg IENUTEZMQUdfUkQsICZzdGF0cy0+cnhfY3N1bV9iYWRfc3RhcnQsCisJICAgICJSZWNlaXZlZCBj aGVja3N1bSBvZmZsb2FkZWQgYnVmZmVyIHdpdGggaW5jb3JyZWN0IHN0YXJ0IG9mZnNldCIpOwor CVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJyeF9jc3VtX3Vua25vd25f aXBwcm90byIsCisJICAgIENUTEZMQUdfUkQsICZzdGF0cy0+cnhfY3N1bV91bmtub3duX2lwcHJv dG8sCisJICAgICJSZWNlaXZlZCBjaGVja3N1bSBvZmZsb2FkZWQgYnVmZmVyIHdpdGggaW5jb3Jy ZWN0IElQIHByb3RvY29sIik7CisJU1lTQ1RMX0FERF9VTE9ORyhjdHgsIGNoaWxkLCBPSURfQVVU TywgInJ4X2NzdW1fYmFkX29mZnNldCIsCisJICAgIENUTEZMQUdfUkQsICZzdGF0cy0+cnhfY3N1 bV9iYWRfb2Zmc2V0LAorCSAgICAiUmVjZWl2ZWQgY2hlY2tzdW0gb2ZmbG9hZGVkIGJ1ZmZlciB3 aXRoIGluY29ycmVjdCBvZmZzZXQiKTsKKworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwg T0lEX0FVVE8sICJ0eF9lbnF1ZXVlX2ZhaWxlZCIsCisJICAgIENUTEZMQUdfUkQsICZzdGF0cy0+ dHhfZW5xdWV1ZV9mYWlsZWQsCisJICAgICJFbnF1ZXVlaW5nIGJ1ZmZlciB0byB0cmFuc21pdCB2 aXJ0cXVldWUgZmFpbHVyZXMiKTsKKwlTWVNDVExfQUREX1VMT05HKGN0eCwgY2hpbGQsIE9JRF9B VVRPLCAidHhfY3N1bV9vZmZsb2FkZWQiLAorCSAgICBDVExGTEFHX1JELCAmc3RhdHMtPnR4X2Nz dW1fb2ZmbG9hZGVkLAorCSAgICAiT2ZmbG9hZGVkIGNoZWNrc3VtIG9mIHRyYW5zbWl0dGVkIGJ1 ZmZlciIpOworCVNZU0NUTF9BRERfVUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJ0eF9jc3Vt X3Vua25vd25fZXR5cGUiLAorCSAgICBDVExGTEFHX1JELCAmc3RhdHMtPnR4X2NzdW1fdW5rbm93 bl9ldHlwZSwKKwkgICAgIkFib3J0ZWQgdHJhbnNtaXQgb2YgY2hlY2tzdW0gb2ZmbG9hZGVkIGJ1 ZmZlciB3aXRoIHVua25vd24gIgorCSAgICAiRXRoZXJuZXQgdHlwZSIpOworCVNZU0NUTF9BRERf VUxPTkcoY3R4LCBjaGlsZCwgT0lEX0FVVE8sICJ0eF90c29fdW5rbm93bl9ldHlwZSIsCisJICAg IENUTEZMQUdfUkQsICZzdGF0cy0+dHhfdHNvX3Vua25vd25fZXR5cGUsCisJICAgICJBYm9ydGVk IHRyYW5zbWl0IG9mIFRTTyBidWZmZXIgd2l0aCB1bmtub3duIEV0aGVybmV0IHR5cGUiKTsKK30K Kworc3RhdGljIGludAordnRuZXRfZW5hYmxlX3J4X2ludHIoc3RydWN0IHZ0bmV0X3NvZnRjICpz YykKK3sKKworCXJldHVybiAodmlydHF1ZXVlX2VuYWJsZV9pbnRyKHNjLT52dG5ldF9yeF92cSkp OworfQorCitzdGF0aWMgdm9pZAordnRuZXRfZGlzYWJsZV9yeF9pbnRyKHN0cnVjdCB2dG5ldF9z b2Z0YyAqc2MpCit7CisKKwl2aXJ0cXVldWVfZGlzYWJsZV9pbnRyKHNjLT52dG5ldF9yeF92cSk7 Cit9CisKK3N0YXRpYyBpbnQKK3Z0bmV0X2VuYWJsZV90eF9pbnRyKHN0cnVjdCB2dG5ldF9zb2Z0 YyAqc2MpCit7CisKKwlyZXR1cm4gKHZpcnRxdWV1ZV9lbmFibGVfaW50cihzYy0+dnRuZXRfdHhf dnEpKTsKK30KKworc3RhdGljIHZvaWQKK3Z0bmV0X2Rpc2FibGVfdHhfaW50cihzdHJ1Y3QgdnRu ZXRfc29mdGMgKnNjKQoreworCisJdmlydHF1ZXVlX2Rpc2FibGVfaW50cihzYy0+dnRuZXRfdHhf dnEpOworfQorCitzdGF0aWMgdm9pZAordnRuZXRfZGlzYWJsZV9jdHJsX2ludHIoc3RydWN0IHZ0 bmV0X3NvZnRjICpzYykKK3sKKworCXZpcnRxdWV1ZV9kaXNhYmxlX2ludHIoc2MtPnZ0bmV0X2N0 cmxfdnEpOworfQpkaWZmIC0tZ2l0IGEvc3lzL2Rldi92aXJ0aW8vbmV0d29yay92aXJ0aW9fbmV0 X3JlZy5oIGIvc3lzL2Rldi92aXJ0aW8vbmV0d29yay92aXJ0aW9fbmV0X3JlZy5oCm5ldyBmaWxl IG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi92aXJ0aW8vbmV0d29yay92 aXJ0aW9fbmV0X3JlZy5oCkBAIC0wLDAgKzEsMTM2IEBACisjaWZuZGVmIF9WSVJUSU9fTkVUX1JF R19ICisjZGVmaW5lIF9WSVJUSU9fTkVUX1JFR19ICisKKy8qCisgKiBUaGlzIGhlYWRlciBpcyBC U0QgbGljZW5zZWQgc28gYW55b25lIGNhbiB1c2UgdGhlIGRlZmluaXRpb25zIHRvIGltcGxlbWVu dAorICogY29tcGF0aWJsZSBkcml2ZXJzL3NlcnZlcnMuCisgKi8KKworI2luY2x1ZGUgPHN5cy90 eXBlcy5oPgorCisvKiBUaGUgZmVhdHVyZSBiaXRtYXAgZm9yIHZpcnRpbyBuZXQgKi8KKyNkZWZp bmUgVklSVElPX05FVF9GX0NTVU0JMHgwMDAwMSAvKiBIb3N0IGhhbmRsZXMgcGt0cyB3LyBwYXJ0 aWFsIGNzdW0gKi8KKyNkZWZpbmUgVklSVElPX05FVF9GX0dVRVNUX0NTVU0gMHgwMDAwMiAvKiBH dWVzdCBoYW5kbGVzIHBrdHMgdy8gcGFydGlhbCBjc3VtKi8KKyNkZWZpbmUgVklSVElPX05FVF9G X01BQwkweDAwMDIwIC8qIEhvc3QgaGFzIGdpdmVuIE1BQyBhZGRyZXNzLiAqLworI2RlZmluZSBW SVJUSU9fTkVUX0ZfR1NPCTB4MDAwNDAgLyogSG9zdCBoYW5kbGVzIHBrdHMgdy8gYW55IEdTTyB0 eXBlICovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9HVUVTVF9UU080CTB4MDAwODAgLyogR3Vlc3Qg Y2FuIGhhbmRsZSBUU092NCBpbi4gKi8KKyNkZWZpbmUgVklSVElPX05FVF9GX0dVRVNUX1RTTzYJ MHgwMDEwMCAvKiBHdWVzdCBjYW4gaGFuZGxlIFRTT3Y2IGluLiAqLworI2RlZmluZSBWSVJUSU9f TkVUX0ZfR1VFU1RfRUNOCTB4MDAyMDAgLyogR3Vlc3QgY2FuIGhhbmRsZSBUU09bNl0gdy8gRUNO IGluLiovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9HVUVTVF9VRk8JMHgwMDQwMCAvKiBHdWVzdCBj YW4gaGFuZGxlIFVGTyBpbi4gKi8KKyNkZWZpbmUgVklSVElPX05FVF9GX0hPU1RfVFNPNAkweDAw ODAwIC8qIEhvc3QgY2FuIGhhbmRsZSBUU092NCBpbi4gKi8KKyNkZWZpbmUgVklSVElPX05FVF9G X0hPU1RfVFNPNgkweDAxMDAwIC8qIEhvc3QgY2FuIGhhbmRsZSBUU092NiBpbi4gKi8KKyNkZWZp bmUgVklSVElPX05FVF9GX0hPU1RfRUNOCTB4MDIwMDAgLyogSG9zdCBjYW4gaGFuZGxlIFRTT1s2 XSB3LyBFQ04gaW4uICovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9IT1NUX1VGTwkweDA0MDAwIC8q IEhvc3QgY2FuIGhhbmRsZSBVRk8gaW4uICovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9NUkdfUlhC VUYJMHgwODAwMCAvKiBIb3N0IGNhbiBtZXJnZSByZWNlaXZlIGJ1ZmZlcnMuICovCisjZGVmaW5l IFZJUlRJT19ORVRfRl9TVEFUVVMJMHgxMDAwMCAvKiB2aXJ0aW9fbmV0X2NvbmZpZy5zdGF0dXMg YXZhaWxhYmxlKi8KKyNkZWZpbmUgVklSVElPX05FVF9GX0NUUkxfVlEJMHgyMDAwMCAvKiBDb250 cm9sIGNoYW5uZWwgYXZhaWxhYmxlICovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9DVFJMX1JYCTB4 NDAwMDAgLyogQ29udHJvbCBjaGFubmVsIFJYIG1vZGUgc3VwcG9ydCAqLworI2RlZmluZSBWSVJU SU9fTkVUX0ZfQ1RSTF9WTEFOCTB4ODAwMDAgLyogQ29udHJvbCBjaGFubmVsIFZMQU4gZmlsdGVy aW5nICovCisjZGVmaW5lIFZJUlRJT19ORVRfRl9DVFJMX1JYX0VYVFJBIDB4MTAwMDAwIC8qIEV4 dHJhIFJYIG1vZGUgY29udHJvbCBzdXBwb3J0ICovCisKKyNkZWZpbmUgVklSVElPX05FVF9TX0xJ TktfVVAJMQkvKiBMaW5rIGlzIHVwICovCisKK3N0cnVjdCB2aXJ0aW9fbmV0X2NvbmZpZyB7CisJ LyogVGhlIGNvbmZpZyBkZWZpbmluZyBtYWMgYWRkcmVzcyAoaWYgVklSVElPX05FVF9GX01BQykg Ki8KKwl1aW50OF90CQltYWNbRVRIRVJfQUREUl9MRU5dOyAKKwkvKiBTZWUgVklSVElPX05FVF9G X1NUQVRVUyBhbmQgVklSVElPX05FVF9TXyogYWJvdmUgKi8KKwl1aW50MTZfdAlzdGF0dXM7Cit9 IF9fcGFja2VkOworCisvKgorICogVGhpcyBpcyB0aGUgZmlyc3QgZWxlbWVudCBvZiB0aGUgc2Nh dHRlci1nYXRoZXIgbGlzdC4gIElmIHlvdSBkb24ndAorICogc3BlY2lmeSBHU08gb3IgQ1NVTSBm ZWF0dXJlcywgeW91IGNhbiBzaW1wbHkgaWdub3JlIHRoZSBoZWFkZXIuCisgKi8KK3N0cnVjdCB2 aXJ0aW9fbmV0X2hkciB7CisjZGVmaW5lIFZJUlRJT19ORVRfSERSX0ZfTkVFRFNfQ1NVTQkxCS8q IFVzZSBjc3VtX3N0YXJ0LGNzdW1fb2Zmc2V0Ki8KKwl1aW50OF90CWZsYWdzOworI2RlZmluZSBW SVJUSU9fTkVUX0hEUl9HU09fTk9ORQkJMAkvKiBOb3QgYSBHU08gZnJhbWUgKi8KKyNkZWZpbmUg VklSVElPX05FVF9IRFJfR1NPX1RDUFY0CTEJLyogR1NPIGZyYW1lLCBJUHY0IFRDUCAoVFNPKSAq LworI2RlZmluZSBWSVJUSU9fTkVUX0hEUl9HU09fVURQCQkzCS8qIEdTTyBmcmFtZSwgSVB2NCBV RFAgKFVGTykgKi8KKyNkZWZpbmUgVklSVElPX05FVF9IRFJfR1NPX1RDUFY2CTQJLyogR1NPIGZy YW1lLCBJUHY2IFRDUCAqLworI2RlZmluZSBWSVJUSU9fTkVUX0hEUl9HU09fRUNOCQkweDgwCS8q IFRDUCBoYXMgRUNOIHNldCAqLworCXVpbnQ4X3QgZ3NvX3R5cGU7CisJdWludDE2X3QgaGRyX2xl bjsJLyogRXRoZXJuZXQgKyBJUCArIHRjcC91ZHAgaGRycyAqLworCXVpbnQxNl90IGdzb19zaXpl OwkvKiBCeXRlcyB0byBhcHBlbmQgdG8gaGRyX2xlbiBwZXIgZnJhbWUgKi8KKwl1aW50MTZfdCBj c3VtX3N0YXJ0OwkvKiBQb3NpdGlvbiB0byBzdGFydCBjaGVja3N1bW1pbmcgZnJvbSAqLworCXVp bnQxNl90IGNzdW1fb2Zmc2V0OwkvKiBPZmZzZXQgYWZ0ZXIgdGhhdCB0byBwbGFjZSBjaGVja3N1 bSAqLworfTsKKworLyoKKyAqIFRoaXMgaXMgdGhlIHZlcnNpb24gb2YgdGhlIGhlYWRlciB0byB1 c2Ugd2hlbiB0aGUgTVJHX1JYQlVGCisgKiBmZWF0dXJlIGhhcyBiZWVuIG5lZ290aWF0ZWQuCisg Ki8KK3N0cnVjdCB2aXJ0aW9fbmV0X2hkcl9tcmdfcnhidWYgeworCXN0cnVjdCB2aXJ0aW9fbmV0 X2hkciBoZHI7CisJdWludDE2X3QgbnVtX2J1ZmZlcnM7CS8qIE51bWJlciBvZiBtZXJnZWQgcngg YnVmZmVycyAqLworfTsKKworLyoKKyAqIENvbnRyb2wgdmlydHF1ZXVlIGRhdGEgc3RydWN0dXJl cworICoKKyAqIFRoZSBjb250cm9sIHZpcnRxdWV1ZSBleHBlY3RzIGEgaGVhZGVyIGluIHRoZSBm aXJzdCBzZyBlbnRyeQorICogYW5kIGFuIGFjay9zdGF0dXMgcmVzcG9uc2UgaW4gdGhlIGxhc3Qg ZW50cnkuICBEYXRhIGZvciB0aGUKKyAqIGNvbW1hbmQgZ29lcyBpbiBiZXR3ZWVuLgorICovCitz dHJ1Y3QgdmlydGlvX25ldF9jdHJsX2hkciB7CisJdWludDhfdCBjbGFzczsKKwl1aW50OF90IGNt ZDsKK30gX19wYWNrZWQ7CisKK3R5cGVkZWYgdWludDhfdCB2aXJ0aW9fbmV0X2N0cmxfYWNrOwor CisjZGVmaW5lIFZJUlRJT19ORVRfT0sJMAorI2RlZmluZSBWSVJUSU9fTkVUX0VSUgkxCisKKy8q CisgKiBDb250cm9sIHRoZSBSWCBtb2RlLCBpZS4gcHJvbWlzY3VvdXMsIGFsbG11bHRpLCBldGMu Li4KKyAqIEFsbCBjb21tYW5kcyByZXF1aXJlIGFuICJvdXQiIHNnIGVudHJ5IGNvbnRhaW5pbmcg YSAxIGJ5dGUKKyAqIHN0YXRlIHZhbHVlLCB6ZXJvID0gZGlzYWJsZSwgbm9uLXplcm8gPSBlbmFi bGUuICBDb21tYW5kcworICogMCBhbmQgMSBhcmUgc3VwcG9ydGVkIHdpdGggdGhlIFZJUlRJT19O RVRfRl9DVFJMX1JYIGZlYXR1cmUuCisgKiBDb21tYW5kcyAyLTUgYXJlIGFkZGVkIHdpdGggVklS VElPX05FVF9GX0NUUkxfUlhfRVhUUkEuCisgKi8KKyNkZWZpbmUgVklSVElPX05FVF9DVFJMX1JY CTAKKyNkZWZpbmUgVklSVElPX05FVF9DVFJMX1JYX1BST01JU0MJMAorI2RlZmluZSBWSVJUSU9f TkVUX0NUUkxfUlhfQUxMTVVMVEkJMQorI2RlZmluZSBWSVJUSU9fTkVUX0NUUkxfUlhfQUxMVU5J CTIKKyNkZWZpbmUgVklSVElPX05FVF9DVFJMX1JYX05PTVVMVEkJMworI2RlZmluZSBWSVJUSU9f TkVUX0NUUkxfUlhfTk9VTkkJNAorI2RlZmluZSBWSVJUSU9fTkVUX0NUUkxfUlhfTk9CQ0FTVAk1 CisKKy8qCisgKiBDb250cm9sIHRoZSBNQUMgZmlsdGVyIHRhYmxlLgorICoKKyAqIFRoZSBNQUMg ZmlsdGVyIHRhYmxlIGlzIG1hbmFnZWQgYnkgdGhlIGh5cGVydmlzb3IsIHRoZSBndWVzdCBzaG91 bGQKKyAqIGFzc3VtZSB0aGUgc2l6ZSBpcyBpbmZpbml0ZS4gIEZpbHRlcmluZyBzaG91bGQgYmUg Y29uc2lkZXJlZAorICogbm9uLXBlcmZlY3QsIGllLiBiYXNlZCBvbiBoeXBlcnZpc29yIHJlc291 cmNlcywgdGhlIGd1ZXN0IG1heQorICogcmVjZWl2ZWQgcGFja2V0cyBmcm9tIHNvdXJjZXMgbm90 IHNwZWNpZmllZCBpbiB0aGUgZmlsdGVyIGxpc3QuCisgKgorICogSW4gYWRkaXRpb24gdG8gdGhl IGNsYXNzL2NtZCBoZWFkZXIsIHRoZSBUQUJMRV9TRVQgY29tbWFuZCByZXF1aXJlcworICogdHdv IG91dCBzY2F0dGVybGlzdHMuICBFYWNoIGNvbnRhaW5zIGEgNCBieXRlIGNvdW50IG9mIGVudHJp ZXMgZm9sbG93ZWQKKyAqIGJ5IGEgY29uY2F0ZW5hdGVkIGJ5dGUgc3RyZWFtIG9mIHRoZSBFVEhf QUxFTiBNQUMgYWRkcmVzc2VzLiAgVGhlCisgKiBmaXJzdCBzZyBsaXN0IGNvbnRhaW5zIHVuaWNh c3QgYWRkcmVzc2VzLCB0aGUgc2Vjb25kIGlzIGZvciBtdWx0aWNhc3QuCisgKiBUaGlzIGZ1bmN0 aW9uYWxpdHkgaXMgcHJlc2VudCBpZiB0aGUgVklSVElPX05FVF9GX0NUUkxfUlggZmVhdHVyZQor ICogaXMgYXZhaWxhYmxlLgorICovCitzdHJ1Y3QgdmlydGlvX25ldF9jdHJsX21hYyB7CisJdWlu dDMyX3QJZW50cmllczsKKwl1aW50OF90CQltYWNzW11bRVRIRVJfQUREUl9MRU5dOworfSBfX3Bh Y2tlZDsKKworI2RlZmluZSBWSVJUSU9fTkVUX0NUUkxfTUFDCTEKKyNkZWZpbmUgVklSVElPX05F VF9DVFJMX01BQ19UQUJMRV9TRVQJMAorCisvKgorICogQ29udHJvbCBWTEFOIGZpbHRlcmluZwor ICoKKyAqIFRoZSBWTEFOIGZpbHRlciB0YWJsZSBpcyBjb250cm9sbGVkIHZpYSBhIHNpbXBsZSBB REQvREVMIGludGVyZmFjZS4KKyAqIFZMQU4gSURzIG5vdCBhZGRlZCBtYXkgYmUgZmlsdGVyZWQg YnkgdGhlIGh5cGVydmlzb3IuICBEZWwgaXMgdGhlCisgKiBvcHBvc2l0ZSBvZiBhZGQuICBCb3Ro IGNvbW1hbmRzIGV4cGVjdCBhbiBvdXQgZW50cnkgY29udGFpbmluZyBhIDIKKyAqIGJ5dGUgVkxB TiBJRC4gIFZMQU4gZmlsdGVyaW5nIGlzIGF2YWlsYWJsZSB3aXRoIHRoZQorICogVklSVElPX05F VF9GX0NUUkxfVkxBTiBmZWF0dXJlIGJpdC4KKyAqLworI2RlZmluZSBWSVJUSU9fTkVUX0NUUkxf VkxBTgkyCisjZGVmaW5lIFZJUlRJT19ORVRfQ1RSTF9WTEFOX0FERAkwCisjZGVmaW5lIFZJUlRJ T19ORVRfQ1RSTF9WTEFOX0RFTAkxCisKKyNlbmRpZiAvKiBfVklSVElPX05FVF9SRUdfSCAqLwpk aWZmIC0tZ2l0IGEvc3lzL2Rldi92aXJ0aW8vcGNpL3ZpcnRpb19wY2kuYyBiL3N5cy9kZXYvdmly dGlvL3BjaS92aXJ0aW9fcGNpLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0tIC9kZXYvbnVsbAor KysgYi9zeXMvZGV2L3ZpcnRpby9wY2kvdmlydGlvX3BjaS5jCkBAIC0wLDAgKzEsOTc2IEBACisv KiBEcml2ZXIgZm9yIHRoZSBWaXJ0SU8gUENJIGludGVyZmFjZS4gKi8KKworI2luY2x1ZGUgPHN5 cy9jZGVmcy5oPgorCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3Rt Lmg+CisjaW5jbHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNs dWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL21hbGxvYy5oPgorCisjaW5jbHVkZSA8 bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+CisjaW5jbHVkZSA8 c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9ybWFuLmg+CisKKyNpbmNsdWRlIDxkZXYvcGNpL3Bj aXZhci5oPgorI2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CisKKyNpbmNsdWRlIDxkZXYvdmly dGlvL3ZpcnRpby5oPgorI2luY2x1ZGUgPGRldi92aXJ0aW8vdmlydHF1ZXVlLmg+CisjaW5jbHVk ZSA8ZGV2L3ZpcnRpby9wY2kvdmlydGlvX3BjaV9yZWcuaD4KKworI2luY2x1ZGUgInZpcnRpb19i dXNfaWYuaCIKKyNpbmNsdWRlICJ2aXJ0aW9faWYuaCIKKworLyoKKyAqIE1heGltdW0gbnVtYmVy IG9mIHZpcnRxdWV1ZXMgcGVyIGRldmljZS4KKyAqLworI2RlZmluZSBWSVJUSU9fUENJX01BWF9W SVJUUVVFVUVTIDgKKworc3RydWN0IHZpcnRpb19wY2lfc29mdGMgeworCWRldmljZV90CQkgdnRw Y2lfZGV2OworCXN0cnVjdCByZXNvdXJjZQkJKnZ0cGNpX2lvcG9ydDsKKwlzdHJ1Y3QgcmVzb3Vy Y2UJCSp2dHBjaV9tc2l4X3RibDsKKwl1aW50MzJfdAkgCSB2dHBjaV9mZWF0dXJlczsKKwl1aW50 MzJfdAkgCSB2dHBjaV9mbGFnczsKKyNkZWZpbmUgVklSVElPX1BDSV9GTEFHX05PX01TSVgJCTB4 MDAwMQorI2RlZmluZSBWSVJUSU9fUENJX0ZMQUdfTVNJWAkJMHgwMDAyCisjZGVmaW5lIFZJUlRJ T19QQ0lfRkxBR19TSEFSRURfTVNJWAkweDAwMDQKKworCS8qIE91ciBsb25lIGNoaWxkIGRldmlj ZS4gKi8KKwlkZXZpY2VfdAkJIHZ0cGNpX2NoaWxkX2RldjsKKwlzdHJ1Y3QgdmlydGlvX2l2YXJz CSB2dHBjaV9jaGlsZF9pdmFyczsKKworCS8qCisJICogSWYgc3VmZmljaWVudCBNU0lYIHZlY3Rv cnMgYXJlIGF2YWlsYWJsZSwgdGhlbiBlYWNoCisJICogdmlydHF1ZXVlIHdpdGggYSBub24tTlVM TCBpbnRlcnJ1cHQgY2FsbGJhY2sgd2lsbAorCSAqIGhhdmUgaXRzIG93biBpbnRlcnJ1cHQgaGFu ZGxlciBhc3NpZ25lZC4gSWYgdGhlcmUKKwkgKiBhcmUgaW5zdWZmaWNpZW50IHZlY3RvcnMgYXZh aWxhYmxlIGZvciB0aGF0LCBidXQgYXQKKwkgKiBsZWFzdCB0d28gYXJlIGF2YWlsYWJsZSwgdGhl biBhbGwgdGhlIHZpcnRxdWV1ZXMKKwkgKiB3aWxsIHNoYXJlIHRoZSBzYW1lIE1TSVggdmVjdG9y LiBOb3RlIHRoYXQgZm9yIE1TSVgsCisJICogdGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdlZCBub3Rp ZmljYXRpb25zIHJlY2VpdmUgdGhlaXIKKwkgKiBvd24gTVNJWCB2ZWN0b3IuIElmIHRoZXJlIGFy ZSBpbnN1ZmZpY2llbnQgdmVjdG9ycworCSAqIGF2YWlsYWJsZSBmb3IgdGhlIHNoYXJlZCBzZXR1 cCwgdGhlbiBldmVyeXRoaW5nIHVzZXMKKwkgKiBvbmUgbGVnYWN5IGludGVycnVwdC4KKwkgKi8K KwlpbnQJCQkgdnRwY2lfbnZxczsKKwlzdHJ1Y3QgdmlydGlvX3BjaV92cXggeworCQlzdHJ1Y3Qg dmlydHF1ZXVlICp2cTsKKwkJLyogSW5kZXggaW50byB2dHBjaV9pcmVzW10gYmVsb3cuIFVudXNl ZCwgdGhlbiAtMS4gKi8KKwkJaW50CQkgaXJlc19pZHg7CisJfSB2dHBjaV92cXhbVklSVElPX1BD SV9NQVhfVklSVFFVRVVFU107CisKKwkvKgorCSAqIFdoZW4gdXNpbmcgbGVnYWN5IGludGVycnVw dHMsIG9ubHkgdGhlIGZpcnN0IGVsZW1lbnQgb2YKKwkgKiB2dHBjaV9pcmVzIGlzIHVzZWQuCisJ ICoKKwkgKiBXaGVuIHVzaW5nIE1TSVggaW50ZXJydXB0cywgdGhlIGZpcnN0IGVsZW1lbnQgb2Yg dnRwY2lfaXJlcworCSAqIGlzIHVzZWQgZm9yIHRoZSBjb25maWd1cmF0aW9uIGNoYW5nZWQgaW50 ZXJydXB0OyB0aGUgcmVtYWluaW5nCisJICogZWxlbWVudHMgYXJlIHVzZWQgZm9yIHRoZSB2aXJ0 cXVldWVzLgorCSAqLworCWludAkJCSB2dHBjaV9uaXJlczsKKwlzdHJ1Y3QgdmlydGlvX3BjaV9p bnRyX3JlcyB7CisJCXN0cnVjdCByZXNvdXJjZQkqaXJxOworCQlpbnQJCSByaWQ7CisJCXZvaWQJ CSppbnRyaGFuZDsKKwl9IHZ0cGNpX2lyZXNbMSArIFZJUlRJT19QQ0lfTUFYX1ZJUlRRVUVVRVNd OworfTsKKworc3RhdGljIGludAl2aXJ0aW9fcGNpX3Byb2JlKGRldmljZV90KTsKK3N0YXRpYyBp bnQJdmlydGlvX3BjaV9hdHRhY2goZGV2aWNlX3QpOworc3RhdGljIGludAl2aXJ0aW9fcGNpX2Rl dGFjaChkZXZpY2VfdCk7CitzdGF0aWMgaW50CXZpcnRpb19wY2lfc3VzcGVuZChkZXZpY2VfdCk7 CitzdGF0aWMgaW50CXZpcnRpb19wY2lfcmVzdW1lKGRldmljZV90KTsKK3N0YXRpYyBpbnQJdmly dGlvX3BjaV9zaHV0ZG93bihkZXZpY2VfdCk7CitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX2RyaXZl cl9hZGRlZChkZXZpY2VfdCwgZHJpdmVyX3QgKik7CitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX2No aWxkX2RldGFjaGVkKGRldmljZV90LCBkZXZpY2VfdCk7CisKK3N0YXRpYyB1aW50MzJfdAl2aXJ0 aW9fcGNpX25lZ290aWF0ZV9mZWF0dXJlcyhkZXZpY2VfdCwgdWludDMyX3QpOworc3RhdGljIGlu dAl2aXJ0aW9fcGNpX3dpdGhfZmVhdHVyZShkZXZpY2VfdCwgdWludDMyX3QpOworc3RhdGljIGlu dAl2aXJ0aW9fcGNpX2FsbG9jX3ZxcyhkZXZpY2VfdCwgaW50LCBpbnQsCisJCSAgICBzdHJ1Y3Qg dnFfYWxsb2NfaW5mbyAqKTsKK3N0YXRpYyBpbnQJdmlydGlvX3BjaV9zZXR1cF9pbnRyKGRldmlj ZV90LCBlbnVtIGludHJfdHlwZSk7CitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX3N0b3AoZGV2aWNl X3QpOworc3RhdGljIGludAl2aXJ0aW9fcGNpX3JlaW5pdChkZXZpY2VfdCwgdWludDMyX3QpOwor c3RhdGljIHZvaWQJdmlydGlvX3BjaV9yZWluaXRfY29tcGxldGUoZGV2aWNlX3QpOworc3RhdGlj IHZvaWQJdmlydGlvX3BjaV9ub3RpZnlfdnEoZGV2aWNlX3QsIHVpbnQxNl90KTsKK3N0YXRpYyB1 aW50OF90CXZpcnRpb19wY2lfZ2V0X3N0YXR1cyhkZXZpY2VfdCk7CitzdGF0aWMgdm9pZAl2aXJ0 aW9fcGNpX3NldF9zdGF0dXMoZGV2aWNlX3QsIHVpbnQ4X3QpOworc3RhdGljIHZvaWQJdmlydGlv X3BjaV9yZWFkX2Rldl9jb25maWcoZGV2aWNlX3QsIGJ1c19zaXplX3QsCisJCSAgICB2b2lkICos IGludCk7CitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX3dyaXRlX2Rldl9jb25maWcoZGV2aWNlX3Qs IGJ1c19zaXplX3QsCisJCSAgICB2b2lkICosIGludCk7CisKK3N0YXRpYyB2b2lkCXZpcnRpb19w Y2lfcHJvYmVfYW5kX2F0dGFjaF9jaGlsZChzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqKTsKKwor c3RhdGljIGludAl2aXJ0aW9fcGNpX2FsbG9jX2ludHIoc3RydWN0IHZpcnRpb19wY2lfc29mdGMg KiwgaW50LCBpbnQsCisJCSAgICBzdHJ1Y3QgdnFfYWxsb2NfaW5mbyAqKTsKK3N0YXRpYyBpbnQJ dmlydGlvX3BjaV9hbGxvY19pbnRyX3JlcyhzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqLCBpbnQs CisJCSAgICBzdHJ1Y3QgdnFfYWxsb2NfaW5mbyAqKTsKK3N0YXRpYyBpbnQJdmlydGlvX3BjaV9h bGxvY19tc2l4KHN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRjICosIGludCk7CitzdGF0aWMgaW50IAl2 aXJ0aW9fcGNpX3JlZ2lzdGVyX21zaXgoc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKiwgaW50LCBp bnQpOworCitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX2ZyZWVfaW50cl9yZXMoc3RydWN0IHZpcnRp b19wY2lfc29mdGMgKik7CitzdGF0aWMgdm9pZAl2aXJ0aW9fcGNpX2ZyZWVfdnFzKHN0cnVjdCB2 aXJ0aW9fcGNpX3NvZnRjICopOworc3RhdGljIHZvaWQJdmlydGlvX3BjaV9yZWxlYXNlX2NoaWxk X3JlcyhzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqKTsKK3N0YXRpYyB2b2lkCXZpcnRpb19wY2lf cmVzZXQoc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKik7CisKK3N0YXRpYyBpbnQJdmlydGlvX3Bj aV9sZWdhY3lfaW50cih2b2lkICopOworc3RhdGljIGludAl2aXJ0aW9fcGNpX3ZxX3NoYXJlZF9p bnRyKHZvaWQgKik7CitzdGF0aWMgaW50CXZpcnRpb19wY2lfdnFfaW50cih2b2lkICopOworc3Rh dGljIGludAl2aXJ0aW9fcGNpX2NvbmZpZ19pbnRyKHZvaWQgKik7CisKKy8qCisgKiBJL08gcG9y dCByZWFkL3dyaXRlIHdyYXBwZXJzLgorICovCisjZGVmaW5lIHZpcnRpb19wY2lfcmVhZF9jb25m aWdfMShzYywgbykgXAorICAgIGJ1c19yZWFkXzEoKHNjKS0+dnRwY2lfaW9wb3J0LCAobykpCisj ZGVmaW5lIHZpcnRpb19wY2lfcmVhZF9jb25maWdfMihzYywgbykgXAorICAgIGJ1c19yZWFkXzIo KHNjKS0+dnRwY2lfaW9wb3J0LCAobykpCisjZGVmaW5lIHZpcnRpb19wY2lfcmVhZF9jb25maWdf NChzYywgbykgXAorICAgIGJ1c19yZWFkXzQoKHNjKS0+dnRwY2lfaW9wb3J0LCAobykpCisjZGVm aW5lIHZpcnRpb19wY2lfd3JpdGVfY29uZmlnXzEoc2MsIG8sIHYpIFwKKyAgICBidXNfd3JpdGVf MSgoc2MpLT52dHBjaV9pb3BvcnQsIChvKSwgKHYpKQorI2RlZmluZSB2aXJ0aW9fcGNpX3dyaXRl X2NvbmZpZ18yKHNjLCBvLCB2KSBcCisgICAgYnVzX3dyaXRlXzIoKHNjKS0+dnRwY2lfaW9wb3J0 LCAobyksICh2KSkKKyNkZWZpbmUgdmlydGlvX3BjaV93cml0ZV9jb25maWdfNChzYywgbywgdikg XAorICAgIGJ1c193cml0ZV80KChzYyktPnZ0cGNpX2lvcG9ydCwgKG8pLCAodikpCisKKy8qIFR1 bmFibGVzLiAqLworc3RhdGljIGludCB2aXJ0aW9fcGNpX2Rpc2FibGVfbXNpeCA9IDA7CitUVU5B QkxFX0lOVCgiaHcudmlydGlvLnBjaS5kaXNhYmxlX21zaXgiLCAmdmlydGlvX3BjaV9kaXNhYmxl X21zaXgpOworCitzdGF0aWMgZGV2aWNlX21ldGhvZF90IHZpcnRpb19wY2lfbWV0aG9kc1tdID0g eworCS8qIERldmljZSBpbnRlcmZhY2UuICovCisJREVWTUVUSE9EKGRldmljZV9wcm9iZSwJCXZp cnRpb19wY2lfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLAl2aXJ0aW9fcGNpX2F0 dGFjaCksCisJREVWTUVUSE9EKGRldmljZV9kZXRhY2gsCXZpcnRpb19wY2lfZGV0YWNoKSwKKwlE RVZNRVRIT0QoZGV2aWNlX3N1c3BlbmQsCXZpcnRpb19wY2lfc3VzcGVuZCksCisJREVWTUVUSE9E KGRldmljZV9yZXN1bWUsCXZpcnRpb19wY2lfcmVzdW1lKSwKKwlERVZNRVRIT0QoZGV2aWNlX3No dXRkb3duLAl2aXJ0aW9fcGNpX3NodXRkb3duKSwKKworCS8qIEJ1cyBpbnRlcmZhY2UuICovCisJ REVWTUVUSE9EKGJ1c19kcml2ZXJfYWRkZWQsCXZpcnRpb19wY2lfZHJpdmVyX2FkZGVkKSwKKwlE RVZNRVRIT0QoYnVzX2NoaWxkX2RldGFjaGVkLAl2aXJ0aW9fcGNpX2NoaWxkX2RldGFjaGVkKSwK KworCS8qIFZpcnRJTyBidXMgaW50ZXJmYWNlLiAqLworCURFVk1FVEhPRCh2aXJ0aW9fYnVzX25l Z290aWF0ZV9mZWF0dXJlcywgdmlydGlvX3BjaV9uZWdvdGlhdGVfZmVhdHVyZXMpLAorCURFVk1F VEhPRCh2aXJ0aW9fYnVzX3dpdGhfZmVhdHVyZSwJIHZpcnRpb19wY2lfd2l0aF9mZWF0dXJlKSwK KwlERVZNRVRIT0QodmlydGlvX2J1c19hbGxvY192cXMsCQkgdmlydGlvX3BjaV9hbGxvY192cXMp LAorCURFVk1FVEhPRCh2aXJ0aW9fYnVzX3NldHVwX2ludHIsCSB2aXJ0aW9fcGNpX3NldHVwX2lu dHIpLAorCURFVk1FVEhPRCh2aXJ0aW9fYnVzX3N0b3AsCQkgdmlydGlvX3BjaV9zdG9wKSwKKwlE RVZNRVRIT0QodmlydGlvX2J1c19yZWluaXQsCQkgdmlydGlvX3BjaV9yZWluaXQpLAorCURFVk1F VEhPRCh2aXJ0aW9fYnVzX3JlaW5pdF9jb21wbGV0ZSwJIHZpcnRpb19wY2lfcmVpbml0X2NvbXBs ZXRlKSwKKwlERVZNRVRIT0QodmlydGlvX2J1c19ub3RpZnlfdnEsCQkgdmlydGlvX3BjaV9ub3Rp ZnlfdnEpLAorCURFVk1FVEhPRCh2aXJ0aW9fYnVzX3JlYWRfZGV2aWNlX2NvbmZpZywgdmlydGlv X3BjaV9yZWFkX2Rldl9jb25maWcpLAorCURFVk1FVEhPRCh2aXJ0aW9fYnVzX3dyaXRlX2Rldmlj ZV9jb25maWcsIHZpcnRpb19wY2lfd3JpdGVfZGV2X2NvbmZpZyksCisKKwl7IDAsIDAgfQorfTsK Kworc3RhdGljIGRyaXZlcl90IHZpcnRpb19wY2lfZHJpdmVyID0geworCSJ2aXJ0aW9fcGNpIiwK Kwl2aXJ0aW9fcGNpX21ldGhvZHMsCisJc2l6ZW9mKHN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRjKQor fTsKKworZGV2Y2xhc3NfdCB2aXJ0aW9fcGNpX2RldmNsYXNzOworCitEUklWRVJfTU9EVUxFKHZp cnRpb19wY2ksIHBjaSwgdmlydGlvX3BjaV9kcml2ZXIsIHZpcnRpb19wY2lfZGV2Y2xhc3MsIDAs IDApOworTU9EVUxFX1ZFUlNJT04odmlydGlvX3BjaSwgMSk7CitNT0RVTEVfREVQRU5EKHZpcnRp b19wY2ksIHBjaSwgMSwgMSwgMSk7CitNT0RVTEVfREVQRU5EKHZpcnRpb19wY2ksIHZpcnRpbywg MSwgMSwgMSk7CisKK3N0YXRpYyBpbnQKK3ZpcnRpb19wY2lfcHJvYmUoZGV2aWNlX3QgZGV2KQor eworCWNoYXIgZGVzY1szNl07CisJY29uc3QgY2hhciAqbmFtZTsKKworCWlmIChwY2lfZ2V0X3Zl bmRvcihkZXYpICE9IFZJUlRJT19QQ0lfVkVORE9SSUQpCisJCXJldHVybiAoRU5YSU8pOworCisJ aWYgKHBjaV9nZXRfZGV2aWNlKGRldikgPCBWSVJUSU9fUENJX0RFVklDRUlEX01JTiB8fAorCSAg ICBwY2lfZ2V0X2RldmljZShkZXYpID4gVklSVElPX1BDSV9ERVZJQ0VJRF9NQVgpCisJCXJldHVy biAoRU5YSU8pOworCisJaWYgKHBjaV9nZXRfcmV2aWQoZGV2KSAhPSBWSVJUSU9fUENJX0FCSV9W RVJTSU9OKQorCQlyZXR1cm4gKEVOWElPKTsKKworCW5hbWUgPSB2aXJ0aW9fZGV2aWNlX25hbWUo cGNpX2dldF9zdWJkZXZpY2UoZGV2KSk7CisJaWYgKG5hbWUgPT0gTlVMTCkKKwkJbmFtZSA9ICJV bmtub3duIjsKKworCXNucHJpbnRmKGRlc2MsIHNpemVvZihkZXNjKSwgIlZpcnRJTyBQQ0kgJXMg YWRhcHRlciIsIG5hbWUpOworCWRldmljZV9zZXRfZGVzY19jb3B5KGRldiwgZGVzYyk7CisKKwly ZXR1cm4gKEJVU19QUk9CRV9ERUZBVUxUKTsKK30KKworc3RhdGljIGludAordmlydGlvX3BjaV9h dHRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRjICpzYzsKKwlk ZXZpY2VfdCBjaGlsZDsKKwlpbnQgcmlkOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CisJc2MtPnZ0cGNpX2RldiA9IGRldjsKKworCXBjaV9lbmFibGVfYnVzbWFzdGVyKGRldik7CisK KwlyaWQgPSBQQ0lSX0JBUigwKTsKKwlzYy0+dnRwY2lfaW9wb3J0ID0gYnVzX2FsbG9jX3Jlc291 cmNlX2FueShkZXYsIFNZU19SRVNfSU9QT1JULAorCSAgICAmcmlkLCBSRl9BQ1RJVkUpOworCWlm IChzYy0+dnRwY2lfaW9wb3J0ID09IE5VTEwpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJjYW5u b3QgbWFwIEkvTyBzcGFjZVxuIik7CisJCXJldHVybiAoRU5YSU8pOworCX0KKworCWlmIChwY2lf ZmluZF9leHRjYXAoZGV2LCBQQ0lZX01TSVgsIE5VTEwpID09IDApIHsKKwkJcmlkID0gUENJUl9C QVIoMSk7CisJCXNjLT52dHBjaV9tc2l4X3RibCA9IGJ1c19hbGxvY19yZXNvdXJjZV9hbnkoZGV2 LCBTWVNfUkVTX01FTU9SWSwKKwkJICAgICZyaWQsIFJGX0FDVElWRSk7CisJCWlmIChzYy0+dnRw Y2lfbXNpeF90YmwgPT0gTlVMTCkKKwkJCS8qIE5vdCBmYXRhbC4gKi8KKwkJCXNjLT52dHBjaV9m bGFncyB8PSBWSVJUSU9fUENJX0ZMQUdfTk9fTVNJWDsKKwl9IGVsc2UKKwkJc2MtPnZ0cGNpX2Zs YWdzIHw9IFZJUlRJT19QQ0lfRkxBR19OT19NU0lYOworCisJdmlydGlvX3BjaV9yZXNldChzYyk7 CisKKwkvKiBUZWxsIHRoZSBob3N0IHdlJ3ZlIG5vdGljZWQgdGhpcyBkZXZpY2UuICovCisJdmly dGlvX3BjaV9zZXRfc3RhdHVzKGRldiwgVklSVElPX0NPTkZJR19TVEFUVVNfQUNLKTsKKworCWlm ICgoY2hpbGQgPSBkZXZpY2VfYWRkX2NoaWxkKGRldiwgTlVMTCwgLTEpKSA9PSBOVUxMKSB7CisJ CWRldmljZV9wcmludGYoZGV2LCAiY2Fubm90IGNyZWF0ZSBjaGlsZCBkZXZpY2VcbiIpOworCQl2 aXJ0aW9fcGNpX3NldF9zdGF0dXMoZGV2LCBWSVJUSU9fQ09ORklHX1NUQVRVU19GQUlMRUQpOwor CQl2aXJ0aW9fcGNpX2RldGFjaChkZXYpOworCQlyZXR1cm4gKEVOT01FTSk7CisJfQorCisJc2Mt PnZ0cGNpX2NoaWxkX2RldiA9IGNoaWxkOworCXNjLT52dHBjaV9jaGlsZF9pdmFycy52dGl2YXJf ZGV2dHlwZSA9IHBjaV9nZXRfc3ViZGV2aWNlKGRldik7CisJZGV2aWNlX3NldF9pdmFycyhjaGls ZCwgJnNjLT52dHBjaV9jaGlsZF9pdmFycyk7CisKKwl2aXJ0aW9fcGNpX3Byb2JlX2FuZF9hdHRh Y2hfY2hpbGQoc2MpOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAordmlydGlvX3Bj aV9kZXRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRjICpzYzsK KwlkZXZpY2VfdCBjaGlsZDsKKwlpbnQgZXJyb3I7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKKworCWlmICgoY2hpbGQgPSBzYy0+dnRwY2lfY2hpbGRfZGV2KSAhPSBOVUxMKSB7CisJ CWVycm9yID0gZGV2aWNlX2RlbGV0ZV9jaGlsZChkZXYsIGNoaWxkKTsKKwkJaWYgKGVycm9yKQor CQkJcmV0dXJuIChlcnJvcik7CisJCXNjLT52dHBjaV9jaGlsZF9kZXYgPSBOVUxMOworCX0KKwor CS8qIFJlc2V0IHRvIGluaXRpYWwgc3RhdGUuICovCisJdmlydGlvX3BjaV9yZXNldChzYyk7CisK KwlpZiAoc2MtPnZ0cGNpX21zaXhfdGJsICE9IE5VTEwpIHsKKwkJYnVzX3JlbGVhc2VfcmVzb3Vy Y2UoZGV2LCBTWVNfUkVTX01FTU9SWSwKKwkJICAgIFBDSVJfQkFSKDEpLCBzYy0+dnRwY2lfbXNp eF90YmwpOworCQlzYy0+dnRwY2lfbXNpeF90YmwgPSBOVUxMOworCX0KKworCWlmIChzYy0+dnRw Y2lfaW9wb3J0ICE9IE5VTEwpIHsKKwkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVT X0lPUE9SVCwKKwkJICAgIFBDSVJfQkFSKDApLCBzYy0+dnRwY2lfaW9wb3J0KTsKKwkJc2MtPnZ0 cGNpX2lvcG9ydCA9IE5VTEw7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAor dmlydGlvX3BjaV9zdXNwZW5kKGRldmljZV90IGRldikKK3sKKworCXJldHVybiAoYnVzX2dlbmVy aWNfc3VzcGVuZChkZXYpKTsKK30KKworc3RhdGljIGludAordmlydGlvX3BjaV9yZXN1bWUoZGV2 aWNlX3QgZGV2KQoreworCisJcmV0dXJuIChidXNfZ2VuZXJpY19yZXN1bWUoZGV2KSk7Cit9CisK K3N0YXRpYyBpbnQKK3ZpcnRpb19wY2lfc2h1dGRvd24oZGV2aWNlX3QgZGV2KQoreworCisJKHZv aWQpIGJ1c19nZW5lcmljX3NodXRkb3duKGRldik7CisKKwkvKiBGb3JjaWJseSBzdG9wIHRoZSBo b3N0IGRldmljZS4gKi8KKwl2aXJ0aW9fcGNpX3N0b3AoZGV2KTsKKworCXJldHVybiAoMCk7Cit9 CisKK3N0YXRpYyB2b2lkCit2aXJ0aW9fcGNpX2RyaXZlcl9hZGRlZChkZXZpY2VfdCBkZXYsIGRy aXZlcl90ICpkcml2ZXIpCit7CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNjOworCisJc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwl2aXJ0aW9fcGNpX3Byb2JlX2FuZF9hdHRhY2hf Y2hpbGQoc2MpOworfQorCitzdGF0aWMgdm9pZAordmlydGlvX3BjaV9jaGlsZF9kZXRhY2hlZChk ZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkKQoreworCXN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRj ICpzYzsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCisJdmlydGlvX3BjaV9yZXNl dChzYyk7CisJdmlydGlvX3BjaV9yZWxlYXNlX2NoaWxkX3JlcyhzYyk7Cit9CisKK3N0YXRpYyB1 aW50MzJfdAordmlydGlvX3BjaV9uZWdvdGlhdGVfZmVhdHVyZXMoZGV2aWNlX3QgZGV2LCB1aW50 MzJfdCBjaGlsZF9mZWF0dXJlcykKK3sKKwlzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqc2M7CisJ ZGV2aWNlX3QgY2hpbGQ7CisJc3RydWN0IHZpcnRpb19pdmFycyAqaXZhcnM7CisJdWludDMyX3Qg ZmVhdHVyZXM7CisJaW50IHZlcmJvc2U7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsK KwljaGlsZCA9IHNjLT52dHBjaV9jaGlsZF9kZXY7CisJaXZhcnMgPSBkZXZpY2VfZ2V0X2l2YXJz KGNoaWxkKTsKKworCS8qIERvbid0IHByaW50IGRlc2NyaXB0aW9uIGFnYWluIGR1cmluZyByZS1u ZWdvdGlhdGlvbi4gKi8KKwl2ZXJib3NlID0gKGRldmljZV9pc19hdHRhY2hlZChjaGlsZCkgPT0g MCk7CisKKwlmZWF0dXJlcyA9IHZpcnRpb19wY2lfcmVhZF9jb25maWdfNChzYywgVklSVElPX1BD SV9IT1NUX0ZFQVRVUkVTKTsKKworCWlmICh2ZXJib3NlKQorCQl2aXJ0aW9fZGVzY3JpYmUoZGV2 LCAiYXZhaWxhYmxlIiwgZmVhdHVyZXMsCisJCSAgICBpdmFycy0+dnRpdmFyX2ZlYXR1cmVzKTsK KworCWZlYXR1cmVzICY9IGNoaWxkX2ZlYXR1cmVzOworCWZlYXR1cmVzID0gdmlydHF1ZXVlX2Zp bHRlcl9mZWF0dXJlcyhmZWF0dXJlcyk7CisJc2MtPnZ0cGNpX2ZlYXR1cmVzID0gZmVhdHVyZXM7 CisJdmlydGlvX3BjaV93cml0ZV9jb25maWdfNChzYywgVklSVElPX1BDSV9HVUVTVF9GRUFUVVJF UywgZmVhdHVyZXMpOworCisJaWYgKHZlcmJvc2UpCisJCXZpcnRpb19kZXNjcmliZShkZXYsICJu ZWdvdGlhdGVkIiwgZmVhdHVyZXMsCisJCSAgICBpdmFycy0+dnRpdmFyX2ZlYXR1cmVzKTsKKwor CXJldHVybiAoZmVhdHVyZXMpOworfQorCitzdGF0aWMgaW50Cit2aXJ0aW9fcGNpX3dpdGhfZmVh dHVyZShkZXZpY2VfdCBkZXYsIHVpbnQzMl90IGZlYXR1cmUpCit7CisJc3RydWN0IHZpcnRpb19w Y2lfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwlyZXR1cm4g KChzYy0+dnRwY2lfZmVhdHVyZXMgJiBmZWF0dXJlKSA9PSBmZWF0dXJlKTsKK30KKworc3RhdGlj IGludAordmlydGlvX3BjaV9hbGxvY192cXMoZGV2aWNlX3QgZGV2LCBpbnQgZmxhZ3MsIGludCBu dnFzLAorICAgIHN0cnVjdCB2cV9hbGxvY19pbmZvICp2cV9pbmZvKQoreworCXN0cnVjdCB2aXJ0 aW9fcGNpX3NvZnRjICpzYzsKKwlzdHJ1Y3QgdmlydGlvX3BjaV92cXggKnZxeDsKKwlzdHJ1Y3Qg dnFfYWxsb2NfaW5mbyAqaW5mbzsKKwlpbnQgcXVldWUsIGVycm9yOworCXVpbnQxNl90IHNpemU7 CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKworCWlmIChzYy0+dnRwY2lfbnZxcyAh PSAwIHx8CisJICAgIG52cXMgPD0gMCB8fCBudnFzID4gVklSVElPX1BDSV9NQVhfVklSVFFVRVVF UykKKwkJcmV0dXJuIChFSU5WQUwpOworCisJZXJyb3IgPSB2aXJ0aW9fcGNpX2FsbG9jX2ludHIo c2MsIGZsYWdzLCBudnFzLCB2cV9pbmZvKTsKKwlpZiAoZXJyb3IpIHsKKwkJZGV2aWNlX3ByaW50 ZihkZXYsCisJCSAgICAiY2Fubm90IGFsbG9jYXRlIGludGVycnVwdCByZXNvdXJjZXNcbiIpOwor CQlyZXR1cm4gKGVycm9yKTsKKwl9CisKKwlpZiAoc2MtPnZ0cGNpX2ZsYWdzICYgVklSVElPX1BD SV9GTEFHX01TSVgpIHsKKwkJZXJyb3IgPSB2aXJ0aW9fcGNpX3JlZ2lzdGVyX21zaXgoc2MsCisJ CSAgICBWSVJUSU9fTVNJX0NPTkZJR19WRUNUT1IsIDApOworCQlpZiAoZXJyb3IpCisJCQlyZXR1 cm4gKGVycm9yKTsKKwl9CisKKwlmb3IgKHF1ZXVlID0gMDsgcXVldWUgPCBudnFzOyBxdWV1ZSsr KSB7CisJCXZxeCA9ICZzYy0+dnRwY2lfdnF4W3F1ZXVlXTsKKwkJaW5mbyA9ICZ2cV9pbmZvW3F1 ZXVlXTsKKworCQl2aXJ0aW9fcGNpX3dyaXRlX2NvbmZpZ18yKHNjLCBWSVJUSU9fUENJX1FVRVVF X1NFTCwgcXVldWUpOworCQlzaXplID0gdmlydGlvX3BjaV9yZWFkX2NvbmZpZ18yKHNjLCBWSVJU SU9fUENJX1FVRVVFX05VTSk7CisKKwkJZXJyb3IgPSB2aXJ0cXVldWVfYWxsb2MoZGV2LCBxdWV1 ZSwgc2l6ZSwKKwkJICAgIFZJUlRJT19QQ0lfVlJJTkdfQUxJR04sIGluZm8sICZ2cXgtPnZxKTsK KwkJaWYgKGVycm9yKQorCQkJYnJlYWs7CisKKwkJaWYgKHNjLT52dHBjaV9mbGFncyAmIFZJUlRJ T19QQ0lfRkxBR19NU0lYKSB7CisJCQllcnJvciA9IHZpcnRpb19wY2lfcmVnaXN0ZXJfbXNpeChz YywKKwkJCSAgICBWSVJUSU9fTVNJX1FVRVVFX1ZFQ1RPUiwgdnF4LT5pcmVzX2lkeCk7CisJCQlp ZiAoZXJyb3IpCisJCQkJYnJlYWs7CisJCX0KKworCQl2aXJ0aW9fcGNpX3dyaXRlX2NvbmZpZ180 KHNjLCBWSVJUSU9fUENJX1FVRVVFX1BGTiwKKwkJICAgIHZxX3JpbmdfcGFkZHIodnF4LT52cSkg Pj4gVklSVElPX1BDSV9RVUVVRV9BRERSX1NISUZUKTsKKworCQlzYy0+dnRwY2lfbnZxcysrOwor CQkqaW5mby0+dnFhaV92cSA9IHZxeC0+dnE7CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CisK K3N0YXRpYyBpbnQKK3ZpcnRpb19wY2lfc2V0dXBfaW50cihkZXZpY2VfdCBkZXYsIGVudW0gaW50 cl90eXBlIHR5cGUpCit7CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNjOworCXN0cnVjdCB2 aXJ0aW9fcGNpX2ludHJfcmVzICppcmVzOworCXN0cnVjdCB2aXJ0aW9fcGNpX3ZxeCAqdnF4Owor CWludCBpLCBmbGFncywgZXJyb3I7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlm bGFncyA9IHR5cGUgfCBJTlRSX01QU0FGRTsKKwllcnJvciA9IDA7CisKKwlpZiAoKHNjLT52dHBj aV9mbGFncyAmIFZJUlRJT19QQ0lfRkxBR19NU0lYKSA9PSAwKSB7CisJCWlyZXMgPSAmc2MtPnZ0 cGNpX2lyZXNbMF07CisJCWVycm9yID0gYnVzX3NldHVwX2ludHIoZGV2LCBpcmVzLT5pcnEsIGZs YWdzLAorCQkgICAgdmlydGlvX3BjaV9sZWdhY3lfaW50ciwgTlVMTCwgc2MsICZpcmVzLT5pbnRy aGFuZCk7CisKKwkJcmV0dXJuIChlcnJvcik7CisJfQorCisJaXJlcyA9ICZzYy0+dnRwY2lfaXJl c1swXTsKKwllcnJvciA9IGJ1c19zZXR1cF9pbnRyKGRldiwgaXJlcy0+aXJxLCBmbGFncywKKwkg ICAgdmlydGlvX3BjaV9jb25maWdfaW50ciwgTlVMTCwgc2MsICZpcmVzLT5pbnRyaGFuZCk7CisJ aWYgKGVycm9yKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChzYy0+dnRwY2lfZmxhZ3MgJiBW SVJUSU9fUENJX0ZMQUdfU0hBUkVEX01TSVgpIHsKKwkJaXJlcyA9ICZzYy0+dnRwY2lfaXJlc1sx XTsKKwkJZXJyb3IgPSBidXNfc2V0dXBfaW50cihkZXYsIGlyZXMtPmlycSwgZmxhZ3MsCisJCSAg ICB2aXJ0aW9fcGNpX3ZxX3NoYXJlZF9pbnRyLCBOVUxMLCBzYywgJmlyZXMtPmludHJoYW5kKTsK KworCQlyZXR1cm4gKGVycm9yKTsKKwl9CisKKwlmb3IgKGkgPSAwOyBpIDwgc2MtPnZ0cGNpX252 cXM7IGkrKykgeworCQl2cXggPSAmc2MtPnZ0cGNpX3ZxeFtpXTsKKwkJaWYgKHZxeC0+aXJlc19p ZHggPCAxKQorCQkJY29udGludWU7CisKKwkJaXJlcyA9ICZzYy0+dnRwY2lfaXJlc1t2cXgtPmly ZXNfaWR4XTsKKworCQllcnJvciA9IGJ1c19zZXR1cF9pbnRyKGRldiwgaXJlcy0+aXJxLCBmbGFn cywKKwkJICAgIHZpcnRpb19wY2lfdnFfaW50ciwgTlVMTCwgdnF4LT52cSwgJmlyZXMtPmludHJo YW5kKTsKKwkJaWYgKGVycm9yKQorCQkJYnJlYWs7CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9 CisKK3N0YXRpYyB2b2lkCit2aXJ0aW9fcGNpX3N0b3AoZGV2aWNlX3QgZGV2KQoreworCisJdmly dGlvX3BjaV9yZXNldChkZXZpY2VfZ2V0X3NvZnRjKGRldikpOworfQorCitzdGF0aWMgaW50Cit2 aXJ0aW9fcGNpX3JlaW5pdChkZXZpY2VfdCBkZXYsIHVpbnQzMl90IGZlYXR1cmVzKQoreworCXN0 cnVjdCB2aXJ0aW9fcGNpX3NvZnRjICpzYzsKKwlzdHJ1Y3QgdmlydGlvX3BjaV92cXggKnZxeDsK KwlzdHJ1Y3QgdmlydHF1ZXVlICp2cTsKKwl1aW50MTZfdCBzaXplOworCWludCBxdWV1ZSwgcmVz X2lkeCwgZXJyb3I7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwllcnJvciA9IDA7 CisKKwkvKgorCSAqIE5PVEU6IFdlJ3JlIHByZXR0eSBzZW5zaXRpdmUgaGVyZSBpZiB0aGUgaG9z dCdzIGRldmljZQorCSAqIHJhZGljYWxseSBjaGFuZ2VzIGZyb20gd2hhdCB3YXMgb3JpZ2luYWxs eSBuZWdvdGlhdGVkCisJICogZHVyaW5nIGF0dGFjaDsgaS5lLiBNU0lYIGdvZXMgYXdheSwgdmly dHF1ZXVlIHNpemUKKwkgKiBjaGFuZ2VzLCBldGMuCisJICoKKwkgKiBQcmVzZW50bHksIGJvdGgg S1ZNIGFuZCBWaXJ0dWFsQm94IHNlZW0gdG8gcGxheSBuaWNlLAorCSAqIGJ1dCBldmVudHVhbGx5 IHRoaXMgc2hvdWxkIGJlIG1vcmUgcm9idXN0LCBlZmZlY3RpdmVseQorCSAqIHJlLWRyaXZpbmcg dGhlIHdob2xlIGRldmljZSB0aHJvdWdoIGRldmljZV9hdHRhY2goKQorCSAqIHdpdGggdGhlIG5l dyBkZXNpcmVkIGZlYXR1cmVzLgorCSAqLworCWlmICh2aXJ0aW9fcGNpX2dldF9zdGF0dXMoZGV2 KSAhPSBWSVJUSU9fQ09ORklHX1NUQVRVU19SRVNFVCkKKwkJdmlydGlvX3BjaV9zdG9wKGRldik7 CisKKwl2aXJ0aW9fcGNpX3NldF9zdGF0dXMoZGV2LCBWSVJUSU9fQ09ORklHX1NUQVRVU19BQ0sp OworCXZpcnRpb19wY2lfc2V0X3N0YXR1cyhkZXYsIFZJUlRJT19DT05GSUdfU1RBVFVTX0RSSVZF Uik7CisKKwl2aXJ0aW9fcGNpX25lZ290aWF0ZV9mZWF0dXJlcyhkZXYsIGZlYXR1cmVzKTsKKwor CS8qCisJICogUmVpbml0aWFsaXplIHRoZSBob3N0IGRldmljZS4KKwkgKiBYWFggTW9zdGx5IGR1 cGxpY2F0ZWQgZnJvbSB2aXJ0aW9fcGNpX2FsbG9jX3ZxcygpLgorCSAqLworCisJaWYgKHNjLT52 dHBjaV9mbGFncyAmIFZJUlRJT19QQ0lfRkxBR19NU0lYKSB7CisJCWVycm9yID0gdmlydGlvX3Bj aV9yZWdpc3Rlcl9tc2l4KHNjLAorCQkgICAgVklSVElPX01TSV9DT05GSUdfVkVDVE9SLCAwKTsK KwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIChlcnJvcik7CisJfQorCisJZm9yIChxdWV1ZSA9IDA7 IHF1ZXVlIDwgc2MtPnZ0cGNpX252cXM7IHF1ZXVlKyspIHsKKwkJdnF4ID0gJnNjLT52dHBjaV92 cXhbcXVldWVdOworCisJCXZxID0gdnF4LT52cTsKKwkJcmVzX2lkeCA9IHZxeC0+aXJlc19pZHg7 CisKKwkJS0FTU0VSVCh2cSAhPSBOVUxMLAorCQkgICAgKCJ2aXJ0cXVldWUgJWQgbm90IGFsbG9j YXRlZCIsIHF1ZXVlKSk7CisKKwkJdmlydGlvX3BjaV93cml0ZV9jb25maWdfMihzYywgVklSVElP X1BDSV9RVUVVRV9TRUwsIHF1ZXVlKTsKKwkJc2l6ZSA9IHZpcnRpb19wY2lfcmVhZF9jb25maWdf MihzYywgVklSVElPX1BDSV9RVUVVRV9OVU0pOworCisJCWVycm9yID0gdmlydHF1ZXVlX3JlaW5p dCh2cSwgc2l6ZSk7CisJCWlmIChlcnJvcikKKwkJCWJyZWFrOworCisJCWlmIChzYy0+dnRwY2lf ZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfTVNJWCkgeworCQkJZXJyb3IgPSB2aXJ0aW9fcGNpX3Jl Z2lzdGVyX21zaXgoc2MsCisJCQkgICAgVklSVElPX01TSV9RVUVVRV9WRUNUT1IsIHJlc19pZHgp OworCQkJaWYgKGVycm9yKQorCQkJCWJyZWFrOworCQl9CisKKwkJdmlydGlvX3BjaV93cml0ZV9j b25maWdfNChzYywgVklSVElPX1BDSV9RVUVVRV9QRk4sCisJCSAgICB2cV9yaW5nX3BhZGRyKHZx KSA+PiBWSVJUSU9fUENJX1FVRVVFX0FERFJfU0hJRlQpOworCX0KKworCXJldHVybiAoZXJyb3Ip OworfQorCitzdGF0aWMgdm9pZAordmlydGlvX3BjaV9yZWluaXRfY29tcGxldGUoZGV2aWNlX3Qg ZGV2KQoreworCisJdmlydGlvX3BjaV9zZXRfc3RhdHVzKGRldiwgVklSVElPX0NPTkZJR19TVEFU VVNfRFJJVkVSX09LKTsKK30KKworc3RhdGljIHZvaWQKK3ZpcnRpb19wY2lfbm90aWZ5X3ZxKGRl dmljZV90IGRldiwgdWludDE2X3QgcXVldWUpCit7CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMg KnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwl2aXJ0aW9fcGNpX3dyaXRl X2NvbmZpZ18yKHNjLCBWSVJUSU9fUENJX1FVRVVFX05PVElGWSwgcXVldWUpOworfQorCitzdGF0 aWMgdWludDhfdAordmlydGlvX3BjaV9nZXRfc3RhdHVzKGRldmljZV90IGRldikKK3sKKwlzdHJ1 Y3QgdmlydGlvX3BjaV9zb2Z0YyAqc2M7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsK KworCXJldHVybiAodmlydGlvX3BjaV9yZWFkX2NvbmZpZ18xKHNjLCBWSVJUSU9fUENJX1NUQVRV UykpOworfQorCitzdGF0aWMgdm9pZAordmlydGlvX3BjaV9zZXRfc3RhdHVzKGRldmljZV90IGRl diwgdWludDhfdCBzdGF0dXMpCit7CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNjOworCisJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwl2aXJ0aW9fcGNpX3dyaXRlX2NvbmZpZ18x KHNjLCBWSVJUSU9fUENJX1NUQVRVUywgc3RhdHVzKTsKK30KKworc3RhdGljIHZvaWQKK3ZpcnRp b19wY2lfcmVhZF9kZXZfY29uZmlnKGRldmljZV90IGRldiwgYnVzX3NpemVfdCBvZmZzZXQsCisg ICAgdm9pZCAqZHN0LCBpbnQgbGVuKQoreworCXN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRjICpzYzsK KwlidXNfc2l6ZV90IG87CisJdWludDhfdCAqZDsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOworCW8gPSBWSVJUSU9fUENJX0NPTkZJRyhzYykgKyBvZmZzZXQ7CisKKwlmb3IgKGQgPSBk c3Q7IGxlbi0tID4gMDsgZCsrLCBvKyspCisJCSpkID0gdmlydGlvX3BjaV9yZWFkX2NvbmZpZ18x KHNjLCBvKTsKK30KKworc3RhdGljIHZvaWQKK3ZpcnRpb19wY2lfd3JpdGVfZGV2X2NvbmZpZyhk ZXZpY2VfdCBkZXYsIGJ1c19zaXplX3Qgb2Zmc2V0LAorICAgIHZvaWQgKnNyYywgaW50IGxlbikK K3sKKwlzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqc2M7CisJYnVzX3NpemVfdCBvOworCXVpbnQ4 X3QgKnM7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlvID0gVklSVElPX1BDSV9D T05GSUcoc2MpICsgb2Zmc2V0OworCisJZm9yIChzID0gc3JjOyBsZW4tLSA+IDA7IHMrKywgbysr KQorCQl2aXJ0aW9fcGNpX3dyaXRlX2NvbmZpZ18xKHNjLCBvLCAqcyk7Cit9CisKK3N0YXRpYyB2 b2lkCit2aXJ0aW9fcGNpX3Byb2JlX2FuZF9hdHRhY2hfY2hpbGQoc3RydWN0IHZpcnRpb19wY2lf c29mdGMgKnNjKQoreworCWRldmljZV90IGRldiwgY2hpbGQ7CisJaW50IGVycm9yOworCisJZGV2 ID0gc2MtPnZ0cGNpX2RldjsKKwljaGlsZCA9IHNjLT52dHBjaV9jaGlsZF9kZXY7CisKKwlpZiAo Y2hpbGQgPT0gTlVMTCkKKwkJcmV0dXJuOworCisJaWYgKGRldmljZV9nZXRfc3RhdGUoY2hpbGQp ICE9IERTX05PVFBSRVNFTlQpCisJCXJldHVybjsKKworCWVycm9yID0gZGV2aWNlX3Byb2JlKGNo aWxkKTsKKwlpZiAoZXJyb3IgPT0gRU5YSU8pCisJCXJldHVybjsKKwllbHNlIGlmIChlcnJvcikK KwkJZ290byBmYWlsOworCisJdmlydGlvX3BjaV9zZXRfc3RhdHVzKGRldiwgVklSVElPX0NPTkZJ R19TVEFUVVNfRFJJVkVSKTsKKwlpZiAoZGV2aWNlX2F0dGFjaChjaGlsZCkgPT0gMCkgeworCQl2 aXJ0aW9fcGNpX3NldF9zdGF0dXMoZGV2LCBWSVJUSU9fQ09ORklHX1NUQVRVU19EUklWRVJfT0sp OworCQlyZXR1cm47CisJfQorCitmYWlsOgorCXZpcnRpb19wY2lfc2V0X3N0YXR1cyhkZXYsIFZJ UlRJT19DT05GSUdfU1RBVFVTX0ZBSUxFRCk7CisJdmlydGlvX3BjaV9yZXNldChzYyk7CisJdmly dGlvX3BjaV9yZWxlYXNlX2NoaWxkX3JlcyhzYyk7CisKKwkvKiBSZXNldCBmb3IgbGF0ZXIgYXR0 ZW1wdC4gKi8KKwl2aXJ0aW9fcGNpX3NldF9zdGF0dXMoZGV2LCBWSVJUSU9fQ09ORklHX1NUQVRV U19BQ0spOworfQorCitzdGF0aWMgaW50Cit2aXJ0aW9fcGNpX2FsbG9jX2ludHIoc3RydWN0IHZp cnRpb19wY2lfc29mdGMgKnNjLCBpbnQgZmxhZ3MsIGludCBudnFzLAorICAgIHN0cnVjdCB2cV9h bGxvY19pbmZvICp2cV9pbmZvKQoreworCWludCBpLCBudmVjdDsKKworCWZvciAobnZlY3QgPSAw LCBpID0gMDsgaSA8IG52cXM7IGkrKykKKwkJaWYgKHZxX2luZm9baV0udnFhaV9pbnRyICE9IE5V TEwpCisJCQludmVjdCsrOworCisJaWYgKHZpcnRpb19wY2lfZGlzYWJsZV9tc2l4ICE9IDAgfHwK KwkgICAgZmxhZ3MgJiBWSVJUSU9fQUxMT0NfVlFTX0RJU0FCTEVfTVNJWCB8fAorCSAgICBzYy0+ dnRwY2lfZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfTk9fTVNJWCB8fAorCSAgICB2aXJ0aW9fcGNp X2FsbG9jX21zaXgoc2MsIG52ZWN0KSAhPSAwKSB7CisJCS8qIEZhbGwtYmFjayB0byBsZWdhY3kg aW50ZXJydXB0cy4gKi8KKwkJc2MtPnZ0cGNpX25pcmVzID0gMTsKKwl9CisKKwlyZXR1cm4gKHZp cnRpb19wY2lfYWxsb2NfaW50cl9yZXMoc2MsIG52cXMsIHZxX2luZm8pKTsKK30KKworc3RhdGlj IGludAordmlydGlvX3BjaV9hbGxvY19pbnRyX3JlcyhzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAq c2MsIGludCBudnFzLAorICAgIHN0cnVjdCB2cV9hbGxvY19pbmZvICp2cV9pbmZvKQoreworCWRl dmljZV90IGRldjsKKwlzdHJ1Y3QgcmVzb3VyY2UgKmlycTsKKwlzdHJ1Y3QgdmlydGlvX3BjaV92 cXggKnZxeDsKKwlpbnQgaSwgcmlkLCBmbGFncywgcmVzX2lkeDsKKworCWRldiA9IHNjLT52dHBj aV9kZXY7CisKKwlpZiAoc2MtPnZ0cGNpX2ZsYWdzICYgVklSVElPX1BDSV9GTEFHX01TSVgpIHsK KwkJcmlkID0gMTsKKwkJZmxhZ3MgPSBSRl9BQ1RJVkU7CisJfSBlbHNlIHsKKwkJcmlkID0gMDsK KwkJZmxhZ3MgPSBSRl9BQ1RJVkUgfCBSRl9TSEFSRUFCTEU7CisJCUtBU1NFUlQoc2MtPnZ0cGNp X25pcmVzID09IDEsICgidG9vIG1hbnkgbGVnYWN5IGludHIgcmVzIikpOworCX0KKworCWZvciAo aSA9IDA7IGkgPCBzYy0+dnRwY2lfbmlyZXM7IGkrKywgcmlkKyspIHsKKwkJaXJxID0gYnVzX2Fs bG9jX3Jlc291cmNlX2FueShkZXYsIFNZU19SRVNfSVJRLCAmcmlkLCBmbGFncyk7CisJCWlmIChp cnEgPT0gTlVMTCkKKwkJCXJldHVybiAoRU5YSU8pOworCisJCXNjLT52dHBjaV9pcmVzW2ldLmly cSA9IGlycTsKKwkJc2MtPnZ0cGNpX2lyZXNbaV0ucmlkID0gcmlkOworCX0KKworCWZvciAoaSA9 IDAsIHJlc19pZHggPSAxOyBpIDwgbnZxczsgaSsrKSB7CisJCXZxeCA9ICZzYy0+dnRwY2lfdnF4 W2ldOworCisJCWlmIChzYy0+dnRwY2lfZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfTVNJWCkgewor CQkJaWYgKHZxX2luZm9baV0udnFhaV9pbnRyID09IE5VTEwpCisJCQkJdnF4LT5pcmVzX2lkeCA9 IC0xOworCQkJZWxzZSBpZiAoc2MtPnZ0cGNpX2ZsYWdzICYgVklSVElPX1BDSV9GTEFHX1NIQVJF RF9NU0lYKQorCQkJCXZxeC0+aXJlc19pZHggPSByZXNfaWR4OworCQkJZWxzZQorCQkJCXZxeC0+ aXJlc19pZHggPSByZXNfaWR4Kys7CisJCX0gZWxzZQorCQkJdnF4LT5pcmVzX2lkeCA9IC0xOwor CX0KKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK3ZpcnRpb19wY2lfYWxsb2NfbXNp eChzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqc2MsIGludCBudmVjdCkKK3sKKwlkZXZpY2VfdCBk ZXY7CisJaW50IG5tc2l4LCBjbnQsIHJlcXVpcmVkOworCisJZGV2ID0gc2MtPnZ0cGNpX2RldjsK KwlubXNpeCA9IHBjaV9tc2l4X2NvdW50KGRldik7CisKKwlpZiAobm1zaXggPCAxKQorCQlyZXR1 cm4gKDEpOworCisJLyoKKwkgKiBOT1RFOiBOZWVkIGFuIGFkZGl0aW9uYWwgdmVjdG9yIGZvciBj b25maWd1cmF0aW9uCisJICogY2hhbmdlZCBub3RpZmljYXRpb25zLgorCSAqLworCisJY250ID0g cmVxdWlyZWQgPSBudmVjdCArIDE7CisJaWYgKG5tc2l4ID49IHJlcXVpcmVkKSB7CisJCWlmIChw Y2lfYWxsb2NfbXNpeChkZXYsICZjbnQpID09IDAgJiYKKwkJICAgIGNudCA+PSByZXF1aXJlZCkK KwkJCWdvdG8gb3V0OworCQllbHNlCisJCQkvKiBSZWxlYXNlIGFueSBwYXJ0aWFsIGFsbG9jYXRp b24uICovCisJCQlwY2lfcmVsZWFzZV9tc2koZGV2KTsKKwl9CisKKwkvKiBBdHRlbXB0IHNoYXJl ZCBNU0lYIGFsbG9jYXRpb24uICovCisJY250ID0gcmVxdWlyZWQgPSAyOworCWlmIChubXNpeCA8 IHJlcXVpcmVkIHx8CisJICAgIHBjaV9hbGxvY19tc2l4KGRldiwgJmNudCkgIT0gMCB8fAorCSAg ICBjbnQgPCByZXF1aXJlZCkgeworCQlwY2lfcmVsZWFzZV9tc2koZGV2KTsKKwkJcmV0dXJuICgx KTsKKwl9CisKKwlzYy0+dnRwY2lfZmxhZ3MgfD0gVklSVElPX1BDSV9GTEFHX1NIQVJFRF9NU0lY OworCitvdXQ6CisJc2MtPnZ0cGNpX25pcmVzID0gcmVxdWlyZWQ7CisJc2MtPnZ0cGNpX2ZsYWdz IHw9IFZJUlRJT19QQ0lfRkxBR19NU0lYOworCisJaWYgKGJvb3R2ZXJib3NlKSB7CisJCWlmIChz Yy0+dnRwY2lfZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfU0hBUkVEX01TSVgpCisJCQlkZXZpY2Vf cHJpbnRmKGRldiwgInVzaW5nIHNoYXJlZCB2aXJ0cXVldWUgTVNJWFxuIik7CisJCWVsc2UKKwkJ CWRldmljZV9wcmludGYoZGV2LCAidXNpbmcgcGVyIHZpcnRxdWV1ZSBNU0lYXG4iKTsKKwl9CisK KwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50Cit2aXJ0aW9fcGNpX3JlZ2lzdGVyX21zaXgo c3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNjLCBpbnQgb2Zmc2V0LAorICAgIGludCByZXNfaWR4 KQoreworCWRldmljZV90IGRldjsKKwl1aW50MTZfdCB2ZWN0b3IsIGhvc3RfdmVjdG9yOworCisJ ZGV2ID0gc2MtPnZ0cGNpX2RldjsKKworCWlmIChyZXNfaWR4ID09IC0xKQorCQl2ZWN0b3IgPSBW SVJUSU9fTVNJX05PX1ZFQ1RPUjsKKwllbHNlCisJCS8qIE1hcCBmcm9tIHJpZCB0byBob3N0IHZl Y3Rvci4gKi8KKwkJdmVjdG9yID0gc2MtPnZ0cGNpX2lyZXNbcmVzX2lkeF0ucmlkIC0gMTsKKwor CS8qIEVuc3VyZSB0aGUgY29uZmlnIGNoYW5nZSB2ZWN0b3IgaXNuJ3QgYmVpbmcgbWlzdXNlZC4g Ki8KKwlpZiAocmVzX2lkeCA9PSAwKQorCQlLQVNTRVJUKG9mZnNldCA9PSBWSVJUSU9fTVNJX0NP TkZJR19WRUNUT1IgJiYKKwkJICAgIAl2ZWN0b3IgPT0gMCwgKCJyZXVzaW5nIGNvbmZpZyBjaGFu Z2UgdmVjdG9yIikpOworCisJdmlydGlvX3BjaV93cml0ZV9jb25maWdfMihzYywgb2Zmc2V0LCB2 ZWN0b3IpOworCWlmICh2ZWN0b3IgPT0gVklSVElPX01TSV9OT19WRUNUT1IpCisJCXJldHVybiAo MCk7CisKKwlob3N0X3ZlY3RvciA9IHZpcnRpb19wY2lfcmVhZF9jb25maWdfMihzYywgb2Zmc2V0 KTsKKwlpZiAoaG9zdF92ZWN0b3IgPT0gVklSVElPX01TSV9OT19WRUNUT1IpIHsKKwkJZGV2aWNl X3ByaW50ZihkZXYsCisJCSAgICAiaW5zdWZmaWNpZW50IGhvc3QgcmVzb3VyY2VzIGZvciBNU0lY IGludGVycnVwdHNcbiIpOworCQlyZXR1cm4gKEVOT0RFVik7CisJfQorCisJcmV0dXJuICgwKTsK K30KKworc3RhdGljIHZvaWQKK3ZpcnRpb19wY2lfZnJlZV9pbnRyX3JlcyhzdHJ1Y3QgdmlydGlv X3BjaV9zb2Z0YyAqc2MpCit7CisJZGV2aWNlX3QgZGV2OworCXN0cnVjdCB2aXJ0aW9fcGNpX2lu dHJfcmVzICppcmVzOworCWludCBpOworCisJZGV2ID0gc2MtPnZ0cGNpX2RldjsKKwlzYy0+dnRw Y2lfbmlyZXMgPSAwOworCisJZm9yIChpID0gMDsgaSA8IDEgKyBWSVJUSU9fUENJX01BWF9WSVJU UVVFVUVTOyBpKyspIHsKKwkJaXJlcyA9ICZzYy0+dnRwY2lfaXJlc1tpXTsKKworCQlpZiAoaXJl cy0+aW50cmhhbmQgIT0gTlVMTCkgeworCQkJYnVzX3RlYXJkb3duX2ludHIoZGV2LCBpcmVzLT5p cnEsIGlyZXMtPmludHJoYW5kKTsKKwkJCWlyZXMtPmludHJoYW5kID0gTlVMTDsKKwkJfQorCisJ CWlmIChpcmVzLT5pcnEgIT0gTlVMTCkgeworCQkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBT WVNfUkVTX0lSUSwgaXJlcy0+cmlkLAorCQkJICAgIGlyZXMtPmlycSk7CisJCQlpcmVzLT5pcnEg PSBOVUxMOworCQl9CisKKwkJaXJlcy0+cmlkID0gLTE7CisJfQorfQorCitzdGF0aWMgdm9pZAor dmlydGlvX3BjaV9mcmVlX3ZxcyhzdHJ1Y3QgdmlydGlvX3BjaV9zb2Z0YyAqc2MpCit7CisJc3Ry dWN0IHZpcnRpb19wY2lfdnF4ICp2cXg7CisJaW50IGk7CisKKwlzYy0+dnRwY2lfbnZxcyA9IDA7 CisKKwlmb3IgKGkgPSAwOyBpIDwgVklSVElPX1BDSV9NQVhfVklSVFFVRVVFUzsgaSsrKSB7CisJ CXZxeCA9ICZzYy0+dnRwY2lfdnF4W2ldOworCisJCWlmICh2cXgtPnZxICE9IE5VTEwpIHsKKwkJ CXZpcnRxdWV1ZV9mcmVlKHZxeC0+dnEpOworCQkJdnF4LT52cSA9IE5VTEw7CisJCX0KKwl9Cit9 CisKK3N0YXRpYyB2b2lkCit2aXJ0aW9fcGNpX3JlbGVhc2VfY2hpbGRfcmVzKHN0cnVjdCB2aXJ0 aW9fcGNpX3NvZnRjICpzYykKK3sKKwlkZXZpY2VfdCBkZXY7CisKKwlkZXYgPSBzYy0+dnRwY2lf ZGV2OworCisJLyogUmVsZWFzZSBhbnkgcmVzb3VyY2VzIHRoZSBjaGlsZCBtYXkgaGF2ZSBhbGxv Y2F0ZWQuICovCisJdmlydGlvX3BjaV9mcmVlX2ludHJfcmVzKHNjKTsKKwl2aXJ0aW9fcGNpX2Zy ZWVfdnFzKHNjKTsKKworCWlmIChzYy0+dnRwY2lfZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfTVNJ WCkgeworCQlwY2lfcmVsZWFzZV9tc2koZGV2KTsKKwkJc2MtPnZ0cGNpX2ZsYWdzICY9IH4oVklS VElPX1BDSV9GTEFHX01TSVggfAorCQkgICAgCQkgICAgIFZJUlRJT19QQ0lfRkxBR19TSEFSRURf TVNJWCk7CisJfQorfQorCitzdGF0aWMgdm9pZAordmlydGlvX3BjaV9yZXNldChzdHJ1Y3Qgdmly dGlvX3BjaV9zb2Z0YyAqc2MpCit7CisKKwkvKgorCSAqIFNldHRpbmcgdGhlIHN0YXR1cyB0byBS RVNFVCByZXN0b3JlcyB0aGUgaG9zdCdzCisJICogZGV2aWNlIHRvIHRoZSBvcmlnaW5hbCB1bmlu aXRpYWxpemVkIHN0YXRlLgorCSAqLworCXZpcnRpb19wY2lfc2V0X3N0YXR1cyhzYy0+dnRwY2lf ZGV2LCBWSVJUSU9fQ09ORklHX1NUQVRVU19SRVNFVCk7Cit9CisKK3N0YXRpYyBpbnQKK3ZpcnRp b19wY2lfbGVnYWN5X2ludHIodm9pZCAqeHNjKQoreworCXN0cnVjdCB2aXJ0aW9fcGNpX3NvZnRj ICpzYzsKKwlzdHJ1Y3QgdmlydGlvX3BjaV92cXggKnZxeDsKKwlpbnQgaTsKKwl1aW50OF90IGlz cjsKKworCXNjID0geHNjOworCXZxeCA9ICZzYy0+dnRwY2lfdnF4WzBdOworCisJLyogUmVhZGlu ZyB0aGUgSVNSIGFsc28gY2xlYXJzIGl0LiAqLworCWlzciA9IHZpcnRpb19wY2lfcmVhZF9jb25m aWdfMShzYywgVklSVElPX1BDSV9JU1IpOworCisJaWYgKGlzciAmIFZJUlRJT19QQ0lfSVNSX0NP TkZJRykKKwkJdmlydGlvX3BjaV9jb25maWdfaW50cihzYyk7CisKKwlpZiAoaXNyICYgVklSVElP X1BDSV9JU1JfSU5UUikKKwkJZm9yIChpID0gMDsgaSA8IHNjLT52dHBjaV9udnFzOyBpKyssIHZx eCsrKQorCQkJdmlydHF1ZXVlX2ludHIodnF4LT52cSk7CisKKwlyZXR1cm4gKGlzciA/IEZJTFRF Ul9IQU5ETEVEIDogRklMVEVSX1NUUkFZKTsKK30KKworc3RhdGljIGludAordmlydGlvX3BjaV92 cV9zaGFyZWRfaW50cih2b2lkICp4c2MpCit7CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNj OworCXN0cnVjdCB2aXJ0aW9fcGNpX3ZxeCAqdnF4OworCWludCBpLCByYzsKKworCXJjID0gMDsK KwlzYyA9IHhzYzsKKwl2cXggPSAmc2MtPnZ0cGNpX3ZxeFswXTsKKworCWZvciAoaSA9IDA7IGkg PCBzYy0+dnRwY2lfbnZxczsgaSsrLCB2cXgrKykKKwkJcmMgfD0gdmlydHF1ZXVlX2ludHIodnF4 LT52cSk7CisKKwlyZXR1cm4gKHJjID8gRklMVEVSX0hBTkRMRUQgOiBGSUxURVJfU1RSQVkpOwor fQorCitzdGF0aWMgaW50Cit2aXJ0aW9fcGNpX3ZxX2ludHIodm9pZCAqeHZxKQoreworCXN0cnVj dCB2aXJ0cXVldWUgKnZxOworCWludCByYzsKKworCXZxID0geHZxOworCXJjID0gdmlydHF1ZXVl X2ludHIodnEpOworCisJcmV0dXJuIChyYyA/IEZJTFRFUl9IQU5ETEVEIDogRklMVEVSX1NUUkFZ KTsKK30KKworc3RhdGljIGludAordmlydGlvX3BjaV9jb25maWdfaW50cih2b2lkICp4c2MpCit7 CisJc3RydWN0IHZpcnRpb19wY2lfc29mdGMgKnNjOworCWRldmljZV90IGNoaWxkOworCWludCBy YzsKKworCXJjID0gMDsKKwlzYyA9IHhzYzsKKwljaGlsZCA9IHNjLT52dHBjaV9jaGlsZF9kZXY7 CisKKwlpZiAoY2hpbGQgIT0gTlVMTCkKKwkJcmMgPSBWSVJUSU9fQ09ORklHX0NIQU5HRShjaGls ZCk7CisKKwlyZXR1cm4gKHJjID8gRklMVEVSX0hBTkRMRUQgOiBGSUxURVJfU1RSQVkpOworfQpk aWZmIC0tZ2l0IGEvc3lzL2Rldi92aXJ0aW8vcGNpL3ZpcnRpb19wY2lfcmVnLmggYi9zeXMvZGV2 L3ZpcnRpby9wY2kvdmlydGlvX3BjaV9yZWcuaApuZXcgZmlsZSBtb2RlIDEwMDY0NAotLS0gL2Rl di9udWxsCisrKyBiL3N5cy9kZXYvdmlydGlvL3BjaS92aXJ0aW9fcGNpX3JlZy5oCkBAIC0wLDAg KzEsNDggQEAKKyNpZm5kZWYgX1ZJUlRJT19QQ0lfUkVHX0gKKyNkZWZpbmUgX1ZJUlRJT19QQ0lf UkVHX0gKKworLyogVmlydElPIFBDSSB2ZW5kb3IvZGV2aWNlIElELiAqLworI2RlZmluZSBWSVJU SU9fUENJX1ZFTkRPUklECTB4MUFGNAorI2RlZmluZSBWSVJUSU9fUENJX0RFVklDRUlEX01JTgkw eDEwMDAKKyNkZWZpbmUgVklSVElPX1BDSV9ERVZJQ0VJRF9NQVgJMHgxMDNGCisKKy8qIFZpcnRJ TyBBQkkgdmVyc2lvbiwgdGhpcyBtdXN0IG1hdGNoIGV4YWN0bHkuICovCisjZGVmaW5lIFZJUlRJ T19QQ0lfQUJJX1ZFUlNJT04JMAorCisvKgorICogVmlydElPIEhlYWRlciwgbG9jYXRlZCBpbiBC QVIgMC4KKyAqLworI2RlZmluZSBWSVJUSU9fUENJX0hPU1RfRkVBVFVSRVMgIDAgIC8qIGhvc3Qn cyBzdXBwb3J0ZWQgZmVhdHVyZXMgKDMyYml0LCBSTykqLworI2RlZmluZSBWSVJUSU9fUENJX0dV RVNUX0ZFQVRVUkVTIDQgIC8qIGd1ZXN0J3Mgc3VwcG9ydGVkIGZlYXR1cmVzICgzMiwgUlcpICov CisjZGVmaW5lIFZJUlRJT19QQ0lfUVVFVUVfUEZOICAgICAgOCAgLyogcGh5c2ljYWwgYWRkcmVz cyBvZiBWUSAoMzIsIFJXKSAqLworI2RlZmluZSBWSVJUSU9fUENJX1FVRVVFX05VTSAgICAgIDEy IC8qIG51bWJlciBvZiByaW5nIGVudHJpZXMgKDE2LCBSTykgKi8KKyNkZWZpbmUgVklSVElPX1BD SV9RVUVVRV9TRUwgICAgICAxNCAvKiBjdXJyZW50IFZRIHNlbGVjdGlvbiAoMTYsIFJXKSAqLwor I2RlZmluZSBWSVJUSU9fUENJX1FVRVVFX05PVElGWQkgIDE2IC8qIG5vdGlmeSBob3N0IHJlZ2Fy ZGluZyBWUSAoMTYsIFJXKSAqLworI2RlZmluZSBWSVJUSU9fUENJX1NUQVRVUyAgICAgICAgIDE4 IC8qIGRldmljZSBzdGF0dXMgcmVnaXN0ZXIgKDgsIFJXKSAqLworI2RlZmluZSBWSVJUSU9fUENJ X0lTUiAgICAgICAgICAgIDE5IC8qIGludGVycnVwdCBzdGF0dXMgcmVnaXN0ZXIsIHJlYWRpbmcK KwkJCQkgICAgICAqIGFsc28gY2xlYXJzIHRoZSByZWdpc3RlciAoOCwgUk8pICovCisvKiBPbmx5 IGlmIE1TSVggaXMgZW5hYmxlZDogKi8KKyNkZWZpbmUgVklSVElPX01TSV9DT05GSUdfVkVDVE9S ICAyMCAvKiBjb25maWd1cmF0aW9uIGNoYW5nZSB2ZWN0b3IgKDE2LCBSVykgKi8KKyNkZWZpbmUg VklSVElPX01TSV9RVUVVRV9WRUNUT1IgICAyMiAvKiB2ZWN0b3IgZm9yIHNlbGVjdGVkIFZRIG5v dGlmaWNhdGlvbnMKKwkJCQkJKDE2LCBSVykgKi8KKworLyogVGhlIGJpdCBvZiB0aGUgSVNSIHdo aWNoIGluZGljYXRlcyBhIGRldmljZSBoYXMgYW4gaW50ZXJydXB0LiAqLworI2RlZmluZSBWSVJU SU9fUENJX0lTUl9JTlRSCTB4MQorLyogVGhlIGJpdCBvZiB0aGUgSVNSIHdoaWNoIGluZGljYXRl cyBhIGRldmljZSBjb25maWd1cmF0aW9uIGNoYW5nZS4gKi8KKyNkZWZpbmUgVklSVElPX1BDSV9J U1JfQ09ORklHCTB4MgorLyogVmVjdG9yIHZhbHVlIHVzZWQgdG8gZGlzYWJsZSBNU0kgZm9yIHF1 ZXVlLiAqLworI2RlZmluZSBWSVJUSU9fTVNJX05PX1ZFQ1RPUgkweEZGRkYKKworLyogVGhlIHJl bWFpbmluZyBzcGFjZSBpcyBkZWZpbmVkIGJ5IGVhY2ggZHJpdmVyIGFzIHRoZSBwZXItZHJpdmVy CisgKiBjb25maWd1cmF0aW9uIHNwYWNlLiAqLworI2RlZmluZSBWSVJUSU9fUENJX0NPTkZJRyhz YykgXAorICAgICgoKHNjKS0+dnRwY2lfZmxhZ3MgJiBWSVJUSU9fUENJX0ZMQUdfTVNJWCkgPyAy NCA6IDIwKQorCisvKiBIb3cgbWFueSBiaXRzIHRvIHNoaWZ0IHBoeXNpY2FsIHF1ZXVlIGFkZHJl c3Mgd3JpdHRlbiB0byBRVUVVRV9QRk4uCisgKiAxMiBpcyBoaXN0b3JpY2FsLCBhbmQgZHVlIHRv IHg4NiBwYWdlIHNpemUuICovCisjZGVmaW5lIFZJUlRJT19QQ0lfUVVFVUVfQUREUl9TSElGVAkx MgorCisvKiBUaGUgYWxpZ25tZW50IHRvIHVzZSBiZXR3ZWVuIGNvbnN1bWVyIGFuZCBwcm9kdWNl ciBwYXJ0cyBvZiB2cmluZy4gKi8KKyNkZWZpbmUgVklSVElPX1BDSV9WUklOR19BTElHTgk0MDk2 CisKKyNlbmRpZiAvKiBfVklSVElPX1BDSV9SRUdfSCAqLwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi92 aXJ0aW8vdmlydGlvLmMgYi9zeXMvZGV2L3ZpcnRpby92aXJ0aW8uYwpuZXcgZmlsZSBtb2RlIDEw MDY0NAotLS0gL2Rldi9udWxsCisrKyBiL3N5cy9kZXYvdmlydGlvL3ZpcnRpby5jCkBAIC0wLDAg KzEsMjMxIEBACisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0u aD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMva2VybmVsLmg+CisjaW5j bHVkZSA8c3lzL21hbGxvYy5oPgorI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxz eXMvc2J1Zi5oPgorCisjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5l L3Jlc291cmNlLmg+CisjaW5jbHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9ybWFuLmg+ CisKKyNpbmNsdWRlIDxkZXYvdmlydGlvL3ZpcnRpby5oPgorI2luY2x1ZGUgPGRldi92aXJ0aW8v dmlydHF1ZXVlLmg+CisKKyNpbmNsdWRlICJ2aXJ0aW9fYnVzX2lmLmgiCisKK3N0YXRpYyBpbnQg dmlydGlvX21vZGV2ZW50KG1vZHVsZV90LCBpbnQsIHZvaWQgKik7CitzdGF0aWMgY29uc3QgY2hh ciAqdmlydGlvX2ZlYXR1cmVfbmFtZSh1aW50MzJfdCwgc3RydWN0IHZpcnRpb19mZWF0dXJlX2Rl c2MgKik7CisKK3N0YXRpYyBzdHJ1Y3QgdmlydGlvX2lkZW50IHsKKwl1aW50MTZfdCBkZXZpZDsK KwljaGFyCSpuYW1lOworfSB2aXJ0aW9faWRlbnRfdGFibGVbXSA9IHsKKwl7IFZJUlRJT19JRF9O RVRXT1JLLAkiTmV0d29yayIJfSwKKwl7IFZJUlRJT19JRF9CTE9DSywJIkJsb2NrIgkJfSwKKwl7 IFZJUlRJT19JRF9DT05TT0xFLCAJIkNvbnNvbGUiIAl9LAorCXsgVklSVElPX0lEX0VOVFJPUFks CSJFbnRyb3B5IiAJfSwKKwl7IFZJUlRJT19JRF9CQUxMT09OLAkiQmFsbG9vbiIgCX0sCisJeyBW SVJUSU9fSURfOVAsCQkiOVAgVHJhbnNwb3J0Igl9LAorCisJeyAwLCBOVUxMIH0KK307CisKKy8q IERldmljZSBpbmRlcGVuZGVudCBmZWF0dXJlcy4gKi8KK3N0YXRpYyBzdHJ1Y3QgdmlydGlvX2Zl YXR1cmVfZGVzYyB2aXJ0aW9fY29tbW9uX2ZlYXR1cmVfZGVzY1tdID0geworCXsgVklSVElPX0Zf Tk9USUZZX09OX0VNUFRZLAkiTm90aWZ5T25FbXB0eSIJfSwKKwl7IFZJUlRJT19GX1JJTkdfSU5E SVJFQ1RfREVTQywJIlJpbmdJbmRpcmVjdCIJfSwKKwl7IFZJUlRJT19GX0JBRF9GRUFUVVJFLAkJ IkJhZEZlYXR1cmUiCX0sCisKKwl7IDAsIE5VTEwgfQorfTsKKworY29uc3QgY2hhciAqCit2aXJ0 aW9fZGV2aWNlX25hbWUodWludDE2X3QgZGV2aWQpCit7CisJc3RydWN0IHZpcnRpb19pZGVudCAq aWRlbnQ7CisKKwlmb3IgKGlkZW50ID0gdmlydGlvX2lkZW50X3RhYmxlOyBpZGVudC0+bmFtZSAh PSBOVUxMOyBpZGVudCsrKSB7CisJCWlmIChpZGVudC0+ZGV2aWQgPT0gZGV2aWQpCisJCQlyZXR1 cm4gKGlkZW50LT5uYW1lKTsKKwl9CisKKwlyZXR1cm4gKE5VTEwpOworfQorCitzdGF0aWMgY29u c3QgY2hhciAqCit2aXJ0aW9fZmVhdHVyZV9uYW1lKHVpbnQzMl90IHZhbCwgc3RydWN0IHZpcnRp b19mZWF0dXJlX2Rlc2MgKmZlYXR1cmVfZGVzYykKK3sKKwlpbnQgaTsKKworCWZvciAoaSA9IDA7 IGZlYXR1cmVfZGVzY1tpXS52ZmRfdmFsICE9IDA7IGkrKykKKwkJaWYgKHZhbCA9PSBmZWF0dXJl X2Rlc2NbaV0udmZkX3ZhbCkKKwkJCXJldHVybiAoZmVhdHVyZV9kZXNjW2ldLnZmZF9zdHIpOwor CisJcmV0dXJuIChOVUxMKTsKK30KKwordm9pZAordmlydGlvX2Rlc2NyaWJlKGRldmljZV90IGRl diwgY29uc3QgY2hhciAqbXNnLAorICAgIHVpbnQzMl90IGZlYXR1cmVzLCBzdHJ1Y3QgdmlydGlv X2ZlYXR1cmVfZGVzYyAqZmVhdHVyZV9kZXNjKQoreworCXN0cnVjdCBzYnVmIHNiOworCWNoYXIg KmJ1ZjsKKwljb25zdCBjaGFyICpuYW1lOworCXVpbnQzMl90IHZhbDsKKwlpbnQgaSwgbjsKKwor CWlmICgoYnVmID0gbWFsbG9jKDUxMiwgTV9URU1QLCBNX05PV0FJVCkpID09IE5VTEwpCisJCXJl dHVybjsKKworCXNidWZfbmV3KCZzYiwgYnVmLCA1MTIsIFNCVUZfRklYRURMRU4pOworCXNidWZf cHJpbnRmKCZzYiwgIiVzIGZlYXR1cmVzOiAweCV4IiwgbXNnLCBmZWF0dXJlcyk7CisKKwkvKiBE ZWNvZGUgZmVhdHVyZSBiaXRzIGR1cmluZyB2ZXJib3NlIGJvb3RzLiAqLworCWZvciAobiA9IDAs IGkgPSAzMTsgYm9vdHZlcmJvc2UgJiYgaSA+PSAwOyBpLS0pIHsKKwkJdmFsID0gMSA8PCBpOwor CisJCWlmICgoZmVhdHVyZXMgJiB2YWwpID09IDApCisJCQljb250aW51ZTsKKworCQlpZiAobisr ID09IDApCisJCQlzYnVmX2NhdCgmc2IsICIgPCIpOworCQllbHNlCisJCQlzYnVmX2NhdCgmc2Is ICIsIik7CisKKwkJbmFtZSA9IE5VTEw7CisJCWlmIChmZWF0dXJlX2Rlc2MgIT0gTlVMTCkKKwkJ CW5hbWUgPSB2aXJ0aW9fZmVhdHVyZV9uYW1lKHZhbCwgZmVhdHVyZV9kZXNjKTsKKwkJaWYgKG5h bWUgPT0gTlVMTCkKKwkJCW5hbWUgPSB2aXJ0aW9fZmVhdHVyZV9uYW1lKHZhbCwKKwkJCSAgICB2 aXJ0aW9fY29tbW9uX2ZlYXR1cmVfZGVzYyk7CisKKwkJaWYgKG5hbWUgPT0gTlVMTCkKKwkJCXNi dWZfcHJpbnRmKCZzYiwgIjB4JXgiLCB2YWwpOworCQllbHNlCisJCQlzYnVmX2NhdCgmc2IsIG5h bWUpOworCX0KKworCWlmIChuID4gMCkKKwkJc2J1Zl9jYXQoJnNiLCAiPiIpOworCisjaWYgX19G cmVlQlNEX3ZlcnNpb24gPCA5MDAwMjAKKwlzYnVmX2ZpbmlzaCgmc2IpOworCWlmIChzYnVmX292 ZXJmbG93ZWQoJnNiKSA9PSAwKQorI2Vsc2UKKwlpZiAoc2J1Zl9maW5pc2goJnNiKSA9PSAwKQor I2VuZGlmCisJCWRldmljZV9wcmludGYoZGV2LCAiJXNcbiIsIHNidWZfZGF0YSgmc2IpKTsKKwor CXNidWZfZGVsZXRlKCZzYik7CisJZnJlZShidWYsIE1fVEVNUCk7Cit9CisKKy8qCisgKiBWaXJ0 SU8gYnVzIG1ldGhvZCB3cmFwcGVycy4KKyAqLworCit1aW50MzJfdAordmlydGlvX25lZ290aWF0 ZV9mZWF0dXJlcyhkZXZpY2VfdCBkZXYsIHVpbnQzMl90IGNoaWxkX2ZlYXR1cmVzKQoreworCisJ cmV0dXJuIChWSVJUSU9fQlVTX05FR09USUFURV9GRUFUVVJFUyhkZXZpY2VfZ2V0X3BhcmVudChk ZXYpLAorCSAgICBjaGlsZF9mZWF0dXJlcykpOworfQorCitpbnQKK3ZpcnRpb19hbGxvY192cXMo ZGV2aWNlX3QgZGV2LCBpbnQgZmxhZ3MsIGludCBudnFzLAorICAgIHN0cnVjdCB2cV9hbGxvY19p bmZvICppbmZvKQoreworCisJcmV0dXJuIChWSVJUSU9fQlVTX0FMTE9DX1ZRUyhkZXZpY2VfZ2V0 X3BhcmVudChkZXYpLCBmbGFncywgbnZxcywKKwkgICAgaW5mbykpOworfQorCitpbnQKK3ZpcnRp b19zZXR1cF9pbnRyKGRldmljZV90IGRldiwgZW51bSBpbnRyX3R5cGUgdHlwZSkKK3sKKworCXJl dHVybiAoVklSVElPX0JVU19TRVRVUF9JTlRSKGRldmljZV9nZXRfcGFyZW50KGRldiksIHR5cGUp KTsKK30KKworaW50Cit2aXJ0aW9fd2l0aF9mZWF0dXJlKGRldmljZV90IGRldiwgdWludDMyX3Qg ZmVhdHVyZSkKK3sKKworCXJldHVybiAoVklSVElPX0JVU19XSVRIX0ZFQVRVUkUoZGV2aWNlX2dl dF9wYXJlbnQoZGV2KSwgZmVhdHVyZSkpOworfQorCit2b2lkCit2aXJ0aW9fc3RvcChkZXZpY2Vf dCBkZXYpCit7CisKKwlWSVJUSU9fQlVTX1NUT1AoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7Cit9 CisKK2ludAordmlydGlvX3JlaW5pdChkZXZpY2VfdCBkZXYsIHVpbnQzMl90IGZlYXR1cmVzKQor eworCisJcmV0dXJuIChWSVJUSU9fQlVTX1JFSU5JVChkZXZpY2VfZ2V0X3BhcmVudChkZXYpLCBm ZWF0dXJlcykpOworfQorCit2b2lkCit2aXJ0aW9fcmVpbml0X2NvbXBsZXRlKGRldmljZV90IGRl dikKK3sKKworCVZJUlRJT19CVVNfUkVJTklUX0NPTVBMRVRFKGRldmljZV9nZXRfcGFyZW50KGRl dikpOworfQorCit2b2lkCit2aXJ0aW9fcmVhZF9kZXZpY2VfY29uZmlnKGRldmljZV90IGRldiwg YnVzX3NpemVfdCBvZmZzZXQsIHZvaWQgKmRzdCwgaW50IGxlbikKK3sKKwlkZXZpY2VfdCBwYXJl bnQ7CisKKwlwYXJlbnQgPSBkZXZpY2VfZ2V0X3BhcmVudChkZXYpOworCisJVklSVElPX0JVU19S RUFEX0RFVklDRV9DT05GSUcocGFyZW50LCBvZmZzZXQsIGRzdCwgbGVuKTsKK30KKwordm9pZAor dmlydGlvX3dyaXRlX2RldmljZV9jb25maWcoZGV2aWNlX3QgZGV2LCBidXNfc2l6ZV90IG9mZnNl dCwgdm9pZCAqZHN0LCBpbnQgbGVuKQoreworCWRldmljZV90IHBhcmVudDsKKworCXBhcmVudCA9 IGRldmljZV9nZXRfcGFyZW50KGRldik7CisKKwlWSVJUSU9fQlVTX1dSSVRFX0RFVklDRV9DT05G SUcocGFyZW50LCBvZmZzZXQsIGRzdCwgbGVuKTsKK30KKworc3RhdGljIGludAordmlydGlvX21v ZGV2ZW50KG1vZHVsZV90IG1vZCwgaW50IHR5cGUsIHZvaWQgKnVudXNlZCkKK3sKKwlpbnQgZXJy b3I7CisKKwllcnJvciA9IDA7CisKKwlzd2l0Y2ggKHR5cGUpIHsKKwljYXNlIE1PRF9MT0FEOgor CWNhc2UgTU9EX1FVSUVTQ0U6CisJY2FzZSBNT0RfVU5MT0FEOgorCWNhc2UgTU9EX1NIVVRET1dO OgorCQlicmVhazsKKwlkZWZhdWx0OgorCQllcnJvciA9IEVPUE5PVFNVUFA7CisJCWJyZWFrOwor CX0KKworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMgbW9kdWxlZGF0YV90IHZpcnRpb19t b2QgPSB7CisJInZpcnRpbyIsCisJdmlydGlvX21vZGV2ZW50LAorCTAKK307CisKK0RFQ0xBUkVf TU9EVUxFKHZpcnRpbywgdmlydGlvX21vZCwgU0lfU1VCX0RSSVZFUlMsIFNJX09SREVSX0ZJUlNU KTsKK01PRFVMRV9WRVJTSU9OKHZpcnRpbywgMSk7CmRpZmYgLS1naXQgYS9zeXMvZGV2L3ZpcnRp by92aXJ0aW8uaCBiL3N5cy9kZXYvdmlydGlvL3ZpcnRpby5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0 Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi92aXJ0aW8vdmlydGlvLmgKQEAgLTAsMCArMSwx MDMgQEAKKyNpZm5kZWYgX1ZJUlRJT19IXworI2RlZmluZSBfVklSVElPX0hfCisKKyNpbmNsdWRl IDxzeXMvdHlwZXMuaD4KKworc3RydWN0IHZxX2FsbG9jX2luZm87CisKKy8qIFZpcnRJTyBkZXZp Y2UgSURzLiAqLworI2RlZmluZSBWSVJUSU9fSURfTkVUV09SSwkweDAxCisjZGVmaW5lIFZJUlRJ T19JRF9CTE9DSwkJMHgwMgorI2RlZmluZSBWSVJUSU9fSURfQ09OU09MRQkweDAzCisjZGVmaW5l IFZJUlRJT19JRF9FTlRST1BZCTB4MDQKKyNkZWZpbmUgVklSVElPX0lEX0JBTExPT04JMHgwNQor I2RlZmluZSBWSVJUSU9fSURfOVAJCTB4MDkKKworLyogU3RhdHVzIGJ5dGUgZm9yIGd1ZXN0IHRv IHJlcG9ydCBwcm9ncmVzcy4gKi8KKyNkZWZpbmUgVklSVElPX0NPTkZJR19TVEFUVVNfUkVTRVQJ MHgwMAorI2RlZmluZSBWSVJUSU9fQ09ORklHX1NUQVRVU19BQ0sJMHgwMQorI2RlZmluZSBWSVJU SU9fQ09ORklHX1NUQVRVU19EUklWRVIJMHgwMgorI2RlZmluZSBWSVJUSU9fQ09ORklHX1NUQVRV U19EUklWRVJfT0sgCTB4MDQKKyNkZWZpbmUgVklSVElPX0NPTkZJR19TVEFUVVNfRkFJTEVECTB4 ODAKKworLyoKKyAqIEdlbmVyYXRlIGludGVycnVwdCB3aGVuIHRoZSB2aXJ0cXVldWUgcmluZyBp cworICogY29tcGxldGVseSB1c2VkLCBldmVuIGlmIHdlJ3ZlIHN1cHByZXNzZWQgdGhlbS4KKyAq LworI2RlZmluZSBWSVJUSU9fRl9OT1RJRllfT05fRU1QVFkgKDEgPDwgMjQpCisKKy8qCisgKiBU aGUgZ3Vlc3Qgc2hvdWxkIG5ldmVyIG5lZ290aWF0ZSB0aGlzIGZlYXR1cmU7IGl0CisgKiBpcyB1 c2VkIHRvIGRldGVjdCBmYXVsdHkgZHJpdmVycy4KKyAqLworI2RlZmluZSBWSVJUSU9fRl9CQURf RkVBVFVSRSAoMSA8PCAzMCkKKworLyoKKyAqIFNvbWUgVmlydElPIGZlYXR1cmUgYml0cyAoY3Vy cmVudGx5IGJpdHMgMjggdGhyb3VnaCAzMSkgYXJlCisgKiByZXNlcnZlZCBmb3IgdGhlIHRyYW5z cG9ydCBiZWluZyB1c2VkIChlZy4gdmlydGlvX3JpbmcpLCB0aGUKKyAqIHJlc3QgYXJlIHBlci1k ZXZpY2UgZmVhdHVyZSBiaXRzLgorICovCisjZGVmaW5lIFZJUlRJT19UUkFOU1BPUlRfRl9TVEFS VAkyOAorI2RlZmluZSBWSVJUSU9fVFJBTlNQT1JUX0ZfRU5ECQkzMgorCitzdHJ1Y3QgdmlydGlv X2ZlYXR1cmVfZGVzYyB7CisJdWludDMyX3QJIHZmZF92YWw7CisJY2hhcgkJKnZmZF9zdHI7Cit9 OworCitzdHJ1Y3QgdmlydGlvX2l2YXJzIHsKKwl1aW50MTZfdAkJCSB2dGl2YXJfZGV2dHlwZTsK KwlzdHJ1Y3QgdmlydGlvX2ZlYXR1cmVfZGVzYwkqdnRpdmFyX2ZlYXR1cmVzOworfTsKKworY29u c3QgY2hhciAqdmlydGlvX2RldmljZV9uYW1lKHVpbnQxNl90IGRldmlkKTsKKwordm9pZAkgdmly dGlvX2Rlc2NyaWJlKGRldmljZV90IGRldiwgY29uc3QgY2hhciAqbXNnLAorCSAgICAgIHVpbnQz Ml90IGZlYXR1cmVzLAorCSAgICAgIHN0cnVjdCB2aXJ0aW9fZmVhdHVyZV9kZXNjICpmZWF0dXJl X2Rlc2MpOworCisvKgorICogVmlydElPIEJ1cyBNZXRob2RzLgorICovCit1aW50MzJfdCB2aXJ0 aW9fbmVnb3RpYXRlX2ZlYXR1cmVzKGRldmljZV90IGRldiwgdWludDMyX3QgY2hpbGRfZmVhdHVy ZXMpOworaW50CSB2aXJ0aW9fYWxsb2NfdnFzKGRldmljZV90IGRldiwgaW50IGZsYWdzLCBpbnQg bnZxcywKKwkgICAgIHN0cnVjdCB2cV9hbGxvY19pbmZvICppbmZvKTsKK2ludAkgdmlydGlvX3Nl dHVwX2ludHIoZGV2aWNlX3QgZGV2LCBlbnVtIGludHJfdHlwZSB0eXBlKTsKK2ludCAJIHZpcnRp b193aXRoX2ZlYXR1cmUoZGV2aWNlX3QgZGV2LCB1aW50MzJfdCBmZWF0dXJlKTsKK3ZvaWQJIHZp cnRpb19zdG9wKGRldmljZV90IGRldik7CitpbnQJIHZpcnRpb19yZWluaXQoZGV2aWNlX3QgZGV2 LCB1aW50MzJfdCBmZWF0dXJlcyk7Cit2b2lkCSB2aXJ0aW9fcmVpbml0X2NvbXBsZXRlKGRldmlj ZV90IGRldik7CisKKy8qCisgKiBSZWFkL3dyaXRlIGEgdmFyaWFibGUgYW1vdW50IGZyb20gdGhl IGRldmljZSBzcGVjaWZpYyAoaWUsIG5ldHdvcmspCisgKiBjb25maWd1cmF0aW9uIHJlZ2lvbi4g VGhpcyByZWdpb24gbXVzdCBiZSBlbmNvZGVkIGluIHRoZSBzYW1lCisgKiBlbmRpYW5uZXNzIG9m IHRoZSBndWVzdCwgc28gd2UgY2FuIHJlYWQgZmllbGRzIGdyZWF0ZXIgdGhhbiBvbmUgYnl0ZSwK KyAqIG9uZSBieXRlIGF0IGEgdGltZS4KKyAqLwordm9pZAkgdmlydGlvX3JlYWRfZGV2aWNlX2Nv bmZpZyhkZXZpY2VfdCBkZXYsIGJ1c19zaXplX3Qgb2Zmc2V0LAorCSAgICAgdm9pZCAqZHN0LCBp bnQgbGVuKTsKK3ZvaWQJIHZpcnRpb193cml0ZV9kZXZpY2VfY29uZmlnKGRldmljZV90IGRldiwg YnVzX3NpemVfdCBvZmZzZXQsCisJICAgICB2b2lkICpkc3QsIGludCBsZW4pOworCisvKiBQcm92 aWRlIHJlYWQvd3JpdGUgbWFjcm9zIGZvciBjb21tb24gbGVuZ3Rocy4gKi8KKyNkZWZpbmUgVklS VElPX1JEV1JfREVWSUNFX0NPTkZJRyh0eXBlLCBzaXplKSBcCitzdGF0aWMgaW5saW5lIHR5cGUg XAorX19DT05DQVQodmlydGlvX3JlYWRfZGV2X2NvbmZpZ18sc2l6ZSkoZGV2aWNlX3QgZGV2LCBc CisgICAgYnVzX3NpemVfdCBvZmZzZXQpIFwKK3sgXAorCXR5cGUgZDsgXAorCXZpcnRpb19yZWFk X2RldmljZV9jb25maWcoZGV2LCBvZmZzZXQsICZkLCBzaXplb2YodHlwZSkpOyBcCisJcmV0dXJu IChkKTsgXAorfSBcCitzdGF0aWMgaW5saW5lIHZvaWQgXAorX19DT05DQVQodmlydGlvX3dyaXRl X2Rldl9jb25maWdfLHNpemUpKGRldmljZV90IGRldiwgXAorICAgIGJ1c19zaXplX3Qgb2Zmc2V0 LCB0eXBlIHMpIFwKK3sgXAorCXZpcnRpb193cml0ZV9kZXZpY2VfY29uZmlnKGRldiwgb2Zmc2V0 LCAmcywgc2l6ZW9mKHR5cGUpKTsgXAorfQorCitWSVJUSU9fUkRXUl9ERVZJQ0VfQ09ORklHKHVp bnQ4X3QsIDEpOworVklSVElPX1JEV1JfREVWSUNFX0NPTkZJRyh1aW50MTZfdCwgMik7CitWSVJU SU9fUkRXUl9ERVZJQ0VfQ09ORklHKHVpbnQzMl90LCA0KTsKKworI2VuZGlmIC8qIF9WSVJUSU9f SF8gKi8KZGlmZiAtLWdpdCBhL3N5cy9kZXYvdmlydGlvL3ZpcnRpb19idXNfaWYubSBiL3N5cy9k ZXYvdmlydGlvL3ZpcnRpb19idXNfaWYubQpuZXcgZmlsZSBtb2RlIDEwMDY0NAotLS0gL2Rldi9u dWxsCisrKyBiL3N5cy9kZXYvdmlydGlvL3ZpcnRpb19idXNfaWYubQpAQCAtMCwwICsxLDY1IEBA CisjaW5jbHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CisKK0lOVEVS RkFDRSB2aXJ0aW9fYnVzOworCitIRUFERVIgeworc3RydWN0IHZxX2FsbG9jX2luZm87Cit9Owor CitNRVRIT0QgdWludDMyX3QgbmVnb3RpYXRlX2ZlYXR1cmVzIHsKKwlkZXZpY2VfdAlkZXY7CisJ dWludDMyX3QJY2hpbGRfZmVhdHVyZXM7Cit9OworCitNRVRIT0QgaW50IHdpdGhfZmVhdHVyZSB7 CisJZGV2aWNlX3QJZGV2OworCXVpbnQzMl90CWZlYXR1cmU7Cit9OworCitNRVRIT0QgaW50IGFs bG9jX3ZxcyB7CisJZGV2aWNlX3QJZGV2OworCWludAkJZmxhZ3M7CisJaW50CQludnFzOworCXN0 cnVjdCB2cV9hbGxvY19pbmZvICppbmZvOworfTsKK0hFQURFUiB7CisjZGVmaW5lIFZJUlRJT19B TExPQ19WUVNfRElTQUJMRV9NU0lYIDB4MQorfTsKKworTUVUSE9EIGludCBzZXR1cF9pbnRyIHsK KwlkZXZpY2VfdAlkZXY7CisJZW51bSBpbnRyX3R5cGUJdHlwZTsKK307CisKK01FVEhPRCB2b2lk IHN0b3AgeworCWRldmljZV90CWRldjsKK307CisKK01FVEhPRCBpbnQgcmVpbml0IHsKKwlkZXZp Y2VfdAlkZXY7CisJdWludDMyX3QJZmVhdHVyZXM7Cit9OworCitNRVRIT0Qgdm9pZCByZWluaXRf Y29tcGxldGUgeworCWRldmljZV90CWRldjsKK307CisKK01FVEhPRCB2b2lkIG5vdGlmeV92cSB7 CisJZGV2aWNlX3QJZGV2OworCXVpbnQxNl90CXF1ZXVlOworfTsKKworTUVUSE9EIHZvaWQgcmVh ZF9kZXZpY2VfY29uZmlnIHsKKwlkZXZpY2VfdAlkZXY7CisJYnVzX3NpemVfdAlvZmZzZXQ7CisJ dm9pZAkJKmRzdDsKKwlpbnQJCWxlbjsKK307CisKK01FVEhPRCB2b2lkIHdyaXRlX2RldmljZV9j b25maWcgeworCWRldmljZV90CWRldjsKKwlidXNfc2l6ZV90CW9mZnNldDsKKwl2b2lkCQkqc3Jj OworCWludAkJbGVuOworfTsKZGlmZiAtLWdpdCBhL3N5cy9kZXYvdmlydGlvL3ZpcnRpb19pZi5t IGIvc3lzL2Rldi92aXJ0aW8vdmlydGlvX2lmLm0KbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0tIC9k ZXYvbnVsbAorKysgYi9zeXMvZGV2L3ZpcnRpby92aXJ0aW9faWYubQpAQCAtMCwwICsxLDcgQEAK KyNpbmNsdWRlIDxzeXMvYnVzLmg+CisKK0lOVEVSRkFDRSB2aXJ0aW87CisKK01FVEhPRCBpbnQg Y29uZmlnX2NoYW5nZSB7CisJZGV2aWNlX3QJZGV2OworfTsKZGlmZiAtLWdpdCBhL3N5cy9kZXYv dmlydGlvL3ZpcnRpb19yaW5nLmggYi9zeXMvZGV2L3ZpcnRpby92aXJ0aW9fcmluZy5oCm5ldyBm aWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi92aXJ0aW8vdmlydGlv X3JpbmcuaApAQCAtMCwwICsxLDE0NSBAQAorLyogQW4gaW50ZXJmYWNlIGZvciBlZmZpY2llbnQg dmlydGlvIGltcGxlbWVudGF0aW9uLgorICoKKyAqIFRoaXMgaGVhZGVyIGlzIEJTRCBsaWNlbnNl ZCBzbyBhbnlvbmUgY2FuIHVzZSB0aGUgZGVmaW5pdGlvbnMKKyAqIHRvIGltcGxlbWVudCBjb21w YXRpYmxlIGRyaXZlcnMvc2VydmVycy4KKyAqCisgKiBDb3B5cmlnaHQgMjAwNywgMjAwOSwgSUJN IENvcnBvcmF0aW9uCisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0 aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAor ICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJj ZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIu IFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg Y29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg Zm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBv dGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICogMy4gTmVp dGhlciB0aGUgbmFtZSBvZiBJQk0gbm9yIHRoZSBuYW1lcyBvZiBpdHMgY29udHJpYnV0b3JzCisg KiAgICBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgZGVyaXZlZCBm cm9tIHRoaXMgc29mdHdhcmUKKyAqICAgIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBw ZXJtaXNzaW9uLgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hU IEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBP UiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUK KyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNI QUxMIElCTSBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5E SVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAor ICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9G IFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5E IE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QK KyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNF KSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgor ICovCisKKyNpZm5kZWYgVklSVElPX1JJTkdfSAorI2RlZmluZQlWSVJUSU9fUklOR19ICisKKyNp bmNsdWRlIDxzeXMvdHlwZXMuaD4KKworLyogVGhpcyBtYXJrcyBhIGJ1ZmZlciBhcyBjb250aW51 aW5nIHZpYSB0aGUgbmV4dCBmaWVsZC4gKi8KKyNkZWZpbmUgVlJJTkdfREVTQ19GX05FWFQgICAg ICAgMQorLyogVGhpcyBtYXJrcyBhIGJ1ZmZlciBhcyB3cml0ZS1vbmx5IChvdGhlcndpc2UgcmVh ZC1vbmx5KS4gKi8KKyNkZWZpbmUgVlJJTkdfREVTQ19GX1dSSVRFICAgICAgMgorLyogVGhpcyBt ZWFucyB0aGUgYnVmZmVyIGNvbnRhaW5zIGEgbGlzdCBvZiBidWZmZXIgZGVzY3JpcHRvcnMuICov CisjZGVmaW5lIFZSSU5HX0RFU0NfRl9JTkRJUkVDVAk0CisKKy8qIFRoZSBIb3N0IHVzZXMgdGhp cyBpbiB1c2VkLT5mbGFncyB0byBhZHZpc2UgdGhlIEd1ZXN0OiBkb24ndCBraWNrIG1lCisgKiB3 aGVuIHlvdSBhZGQgYSBidWZmZXIuICBJdCdzIHVucmVsaWFibGUsIHNvIGl0J3Mgc2ltcGx5IGFu CisgKiBvcHRpbWl6YXRpb24uICBHdWVzdCB3aWxsIHN0aWxsIGtpY2sgaWYgaXQncyBvdXQgb2Yg YnVmZmVycy4gKi8KKyNkZWZpbmUgVlJJTkdfVVNFRF9GX05PX05PVElGWSAgMQorLyogVGhlIEd1 ZXN0IHVzZXMgdGhpcyBpbiBhdmFpbC0+ZmxhZ3MgdG8gYWR2aXNlIHRoZSBIb3N0OiBkb24ndAor ICogaW50ZXJydXB0IG1lIHdoZW4geW91IGNvbnN1bWUgYSBidWZmZXIuICBJdCdzIHVucmVsaWFi bGUsIHNvIGl0J3MKKyAqIHNpbXBseSBhbiBvcHRpbWl6YXRpb24uICAqLworI2RlZmluZSBWUklO R19BVkFJTF9GX05PX0lOVEVSUlVQVCAgICAgIDEKKworLyogVmlydGlvIHJpbmcgZGVzY3JpcHRv cnM6IDE2IGJ5dGVzLgorICogVGhlc2UgY2FuIGNoYWluIHRvZ2V0aGVyIHZpYSAibmV4dCIuICov CitzdHJ1Y3QgdnJpbmdfZGVzYyB7CisgICAgICAgIC8qIEFkZHJlc3MgKGd1ZXN0LXBoeXNpY2Fs KS4gKi8KKyAgICAgICAgdWludDY0X3QgYWRkcjsKKyAgICAgICAgLyogTGVuZ3RoLiAqLworICAg ICAgICB1aW50MzJfdCBsZW47CisgICAgICAgIC8qIFRoZSBmbGFncyBhcyBpbmRpY2F0ZWQgYWJv dmUuICovCisgICAgICAgIHVpbnQxNl90IGZsYWdzOworICAgICAgICAvKiBXZSBjaGFpbiB1bnVz ZWQgZGVzY3JpcHRvcnMgdmlhIHRoaXMsIHRvby4gKi8KKyAgICAgICAgdWludDE2X3QgbmV4dDsK K307CisKK3N0cnVjdCB2cmluZ19hdmFpbCB7CisgICAgICAgIHVpbnQxNl90IGZsYWdzOworICAg ICAgICB1aW50MTZfdCBpZHg7CisgICAgICAgIHVpbnQxNl90IHJpbmdbMF07Cit9OworCisvKiB1 aW50MzJfdCBpcyB1c2VkIGhlcmUgZm9yIGlkcyBmb3IgcGFkZGluZyByZWFzb25zLiAqLworc3Ry dWN0IHZyaW5nX3VzZWRfZWxlbSB7CisgICAgICAgIC8qIEluZGV4IG9mIHN0YXJ0IG9mIHVzZWQg ZGVzY3JpcHRvciBjaGFpbi4gKi8KKyAgICAgICAgdWludDMyX3QgaWQ7CisgICAgICAgIC8qIFRv dGFsIGxlbmd0aCBvZiB0aGUgZGVzY3JpcHRvciBjaGFpbiB3aGljaCB3YXMgd3JpdHRlbiB0by4g Ki8KKyAgICAgICAgdWludDMyX3QgbGVuOworfTsKKworc3RydWN0IHZyaW5nX3VzZWQgeworICAg ICAgICB1aW50MTZfdCBmbGFnczsKKyAgICAgICAgdWludDE2X3QgaWR4OworICAgICAgICBzdHJ1 Y3QgdnJpbmdfdXNlZF9lbGVtIHJpbmdbMF07Cit9OworCitzdHJ1Y3QgdnJpbmcgeworCXVuc2ln bmVkIGludCBudW07IC8qIHVudXNlZCAqLworCisJc3RydWN0IHZyaW5nX2Rlc2MgKmRlc2M7CisJ c3RydWN0IHZyaW5nX2F2YWlsICphdmFpbDsKKwlzdHJ1Y3QgdnJpbmdfdXNlZCAqdXNlZDsKK307 CisKKy8qIFRoZSBzdGFuZGFyZCBsYXlvdXQgZm9yIHRoZSByaW5nIGlzIGEgY29udGludW91cyBj aHVuayBvZiBtZW1vcnkgd2hpY2gKKyAqIGxvb2tzIGxpa2UgdGhpcy4gIFdlIGFzc3VtZSBudW0g aXMgYSBwb3dlciBvZiAyLgorICoKKyAqIHN0cnVjdCB2cmluZyB7CisgKiAgICAgIC8vIFRoZSBh Y3R1YWwgZGVzY3JpcHRvcnMgKDE2IGJ5dGVzIGVhY2gpCisgKiAgICAgIHN0cnVjdCB2cmluZ19k ZXNjIGRlc2NbbnVtXTsKKyAqCisgKiAgICAgIC8vIEEgcmluZyBvZiBhdmFpbGFibGUgZGVzY3Jp cHRvciBoZWFkcyB3aXRoIGZyZWUtcnVubmluZyBpbmRleC4KKyAqICAgICAgX191MTYgYXZhaWxf ZmxhZ3M7CisgKiAgICAgIF9fdTE2IGF2YWlsX2lkeDsKKyAqICAgICAgX191MTYgYXZhaWxhYmxl W251bV07CisgKgorICogICAgICAvLyBQYWRkaW5nIHRvIHRoZSBuZXh0IGFsaWduIGJvdW5kYXJ5 LgorICogICAgICBjaGFyIHBhZFtdOworICoKKyAqICAgICAgLy8gQSByaW5nIG9mIHVzZWQgZGVz Y3JpcHRvciBoZWFkcyB3aXRoIGZyZWUtcnVubmluZyBpbmRleC4KKyAqICAgICAgX191MTYgdXNl ZF9mbGFnczsKKyAqICAgICAgX191MTYgdXNlZF9pZHg7CisgKiAgICAgIHN0cnVjdCB2cmluZ191 c2VkX2VsZW0gdXNlZFtudW1dOworICogfTsKKyAqCisgKiBOT1RFOiBmb3IgVmlydElPIFBDSSwg YWxpZ24gaXMgNDA5Ni4KKyAqLworCitzdGF0aWMgaW5saW5lIGludAordnJpbmdfc2l6ZSh1bnNp Z25lZCBpbnQgbnVtLCB1bnNpZ25lZCBsb25nIGFsaWduKQoreworCWludCBzaXplOworCisJc2l6 ZSA9IG51bSAqIHNpemVvZihzdHJ1Y3QgdnJpbmdfZGVzYyk7CisJc2l6ZSArPSBzaXplb2Yoc3Ry dWN0IHZyaW5nX2F2YWlsKSArIChudW0gKiBzaXplb2YodWludDE2X3QpKTsKKwlzaXplID0gKHNp emUgKyBhbGlnbiAtIDEpICYgfihhbGlnbiAtIDEpOworCXNpemUgKz0gc2l6ZW9mKHN0cnVjdCB2 cmluZ191c2VkKSArCisJICAgIChudW0gKiBzaXplb2Yoc3RydWN0IHZyaW5nX3VzZWRfZWxlbSkp OworCXJldHVybiAoc2l6ZSk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZAordnJpbmdfaW5pdChz dHJ1Y3QgdnJpbmcgKnZyLCB1bnNpZ25lZCBpbnQgbnVtLCB1aW50OF90ICpwLAorICAgIHVuc2ln bmVkIGxvbmcgYWxpZ24pCit7CisgICAgICAgIHZyLT5udW0gPSBudW07CisgICAgICAgIHZyLT5k ZXNjID0gKHN0cnVjdCB2cmluZ19kZXNjICopIHA7CisgICAgICAgIHZyLT5hdmFpbCA9IChzdHJ1 Y3QgdnJpbmdfYXZhaWwgKikgKHAgKworCSAgICBudW0gKiBzaXplb2Yoc3RydWN0IHZyaW5nX2Rl c2MpKTsKKyAgICAgICAgdnItPnVzZWQgPSAodm9pZCAqKQorCSAgICAoKCh1bnNpZ25lZCBsb25n KSAmdnItPmF2YWlsLT5yaW5nW251bV0gKyBhbGlnbi0xKSAmIH4oYWxpZ24tMSkpOworfQorCisK KyNlbmRpZiAvKiBWSVJUSU9fUklOR19IICovCmRpZmYgLS1naXQgYS9zeXMvZGV2L3ZpcnRpby92 aXJ0cXVldWUuYyBiL3N5cy9kZXYvdmlydGlvL3ZpcnRxdWV1ZS5jCm5ldyBmaWxlIG1vZGUgMTAw NjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi92aXJ0aW8vdmlydHF1ZXVlLmMKQEAgLTAs MCArMSw2NjAgQEAKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KKworI2luY2x1ZGUgPHN5cy9wYXJh bS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNp bmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3NnbGlzdC5oPgorI2luY2x1ZGUg PHZtL3ZtLmg+CisjaW5jbHVkZSA8dm0vcG1hcC5oPgorCisjaW5jbHVkZSA8bWFjaGluZS9idXMu aD4KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+CisjaW5jbHVkZSA8c3lzL2J1cy5oPgor I2luY2x1ZGUgPHN5cy9ybWFuLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2F0b21pYy5oPgorCisj aW5jbHVkZSA8ZGV2L3ZpcnRpby92aXJ0aW8uaD4KKyNpbmNsdWRlIDxkZXYvdmlydGlvL3ZpcnRx dWV1ZS5oPgorI2luY2x1ZGUgPGRldi92aXJ0aW8vdmlydGlvX3JpbmcuaD4KKworI2luY2x1ZGUg InZpcnRpb19idXNfaWYuaCIKKworc3RydWN0IHZpcnRxdWV1ZSB7CisJZGV2aWNlX3QJIAkgdnFf ZGV2OworCWNoYXIJCSAJIHZxX25hbWVbVklSVFFVRVVFX01BWF9OQU1FX1NaXTsKKwl1aW50MTZf dAkgCSB2cV9xdWV1ZV9pbmRleDsKKwl1aW50MTZfdAkgCSB2cV9uZW50cmllczsKKwl1aW50MzJf dAkgCSB2cV9mbGFnczsKKyNkZWZpbmUJVklSVFFVRVVFX0lORElSRUNUCSAweDAwMDEKKworCWlu dAkJCSB2cV9hbGlnbm1lbnQ7CisJaW50CQkgCSB2cV9yaW5nX3NpemU7CisJdm9pZAkJCSp2cV9y aW5nX21lbTsKKwlpbnQJCQkgdnFfbWF4X2luZGlyZWN0X3N6OworCWludAkJCSB2cV9pbmRpcmVj dF9tZW1fc3o7CisJc3RydWN0IHZyaW5nX2Rlc2MJKnZxX2luZGlyZWN0X21lbTsKKwl2aXJ0cXVl dWVfaW50cl90CSp2cV9pbnRyaGFuZDsKKwl2b2lkCQkJKnZxX2ludHJoYW5kX2FyZzsKKworCXN0 cnVjdCB2cmluZwkJIHZxX3ZyaW5nOworCS8qIE51bWJlciBvZiBmcmVlIGRlc2NyaXB0b3JzLiAq LworCXVpbnQxNl90CQkgdnFfZnJlZV9jbnQ7CisJLyogSW5kZXggb2YgZmlyc3QgZnJlZSBkZXNj cmlwdG9yLiAqLworCXVpbnQxNl90CQkgdnFfaGVhZF9pZHg7CisJLyogTnVtYmVyIG9mIGRlc2Ny aXB0b3JzIGF3YWl0aW5nIHZpcnRpb19zeW5jKCkuICovCisJdWludDE2X3QJCSB2cV9xdWV1ZWRf Y250OworCS8qIEluZGV4IG9mIGxhc3QgZGVzY3JpcHRvciB3ZSd2ZSBwcm9jZXNzZWQuICovCisJ dWludDE2X3QJCSB2cV9sYXN0X3VzZWRfaWR4OworCisJLyoKKwkgKiBUT0RPIFRoaXMgZG9lc24n dCBuZWVkIHRvIGJlIGEgc3RydWN0IGFueW1vcmUuIEJhY2sKKwkgKiB3aGVuIHRoZSBpbmRpcmVj dCBkZXNjcmlwdG9ycyB3ZXJlbid0IHByZWFsbG9jYXRlZCwKKwkgKiB0aGUgYWRkcmVzcyB3YXMg YWxzbyBodW5nIG9mZiBoZXJlLgorCSAqLworCXN0cnVjdCB2cV9kZXNjX2V4dHJhIHsKKwkJdm9p ZCAJKmNvb2tpZTsKKwl9IHZxX2Rlc2N4WzBdOworfTsKKworLyoKKyAqIFRoZSBhcmNoaXRlY3Rl ZCBtYXhpbXVtIHZpcnRxdWV1ZSBzaXplIGlzIDJeMTUsIHNvCisgKiB0aGlzIHdpbGwgbmV2ZXIg YmUgYSB2YWxpZCBpbmRleCBpbiB0aGUgZGVzY3JpcHRvcgorICogY2hhaW4uIFdlIHVzZSB0aGlz IHRvIHZlcmlmeSB3ZSBhcmUgbm90IG1pc3MtaGFuZGxpbmcKKyAqIHZxX2ZyZWVfY250LgorICov CisjZGVmaW5lIFZRX1JJTkdfREVTQ19DSEFJTl9FTkQgMzI3NjgKKworI2RlZmluZSBWUUFTU0VS VChfdnEsIF9leHAsIF9tc2csIC4uLikgXAorCUtBU1NFUlQoKF9leHApLCgiJXM6ICVzIC0gIl9t c2csIF9fZnVuY19fLCBcCisJICAgIChfdnEpLT52cV9uYW1lLCAjI19fVkFfQVJHU19fKSkKKwor I2RlZmluZSBWUV9SSU5HX0FTU0VSVF9WQUxJRF9JRFgoX3ZxLCBfaWR4KSBcCisJICAgIFZRQVNT RVJUKChfdnEpLCAoX2lkeCkgPCAoX3ZxKS0+dnFfbmVudHJpZXMsIFwKKwkJImludmFsaWQgcmlu ZyBpbmRleDogJWQsIG1heDogJWQiLCBcCisJCShfaWR4KSwgKF92cSktPnZxX25lbnRyaWVzKQor CisjZGVmaW5lIFZRX1JJTkdfQVNTRVJUX0NIQUlOX1RFUk0oX3ZxKSBcCisgICAgCSAgICBWUUFT U0VSVCgoX3ZxKSwgKF92cSktPnZxX2hlYWRfaWR4ID09IFZRX1JJTkdfREVTQ19DSEFJTl9FTkQs IFwKKwkJImZ1bGwgcmluZyBub3QgdGVybWluYXRlZCBjb3JyZWN0bHkiKQorCitzdGF0aWMgaW50 CXZpcnRxdWV1ZV9pbml0X2luZGlyZWN0KHN0cnVjdCB2aXJ0cXVldWUgKnZxKTsKK3N0YXRpYyB2 b2lkCXZpcnRxdWV1ZV9mcmVlX2luZGlyZWN0KHN0cnVjdCB2aXJ0cXVldWUgKnZxKTsKKworc3Rh dGljIHZvaWQJdnFfcmluZ19pbml0KHN0cnVjdCB2aXJ0cXVldWUgKik7CitzdGF0aWMgaW50CXZx X3JpbmdfZG9faW5kaXJlY3Qoc3RydWN0IHZpcnRxdWV1ZSAqLCBpbnQpOworc3RhdGljIHZvaWQJ dnFfcmluZ19lbnF1ZXVlX2luZGlyZWN0KHN0cnVjdCB2aXJ0cXVldWUgKiwgdm9pZCAqLAorICAg IAkJICAgIHN0cnVjdCBzZ2xpc3QgKiwgaW50LCBpbnQpOworc3RhdGljIHZvaWQJdnFfcmluZ19m cmVlX2NoYWluKHN0cnVjdCB2aXJ0cXVldWUgKiwgaW50KTsKKwordWludDMyX3QKK3ZpcnRxdWV1 ZV9maWx0ZXJfZmVhdHVyZXModWludDMyX3QgZmVhdHVyZXMpCit7CisJdWludDMyX3QgbWFzazsK KworCW1hc2sgPSAoKDEgPDwgVklSVElPX1RSQU5TUE9SVF9GX1NUQVJUKSAtIDEpOworCW1hc2sg fD0gVklSVElPX0ZfUklOR19JTkRJUkVDVF9ERVNDOworCisJcmV0dXJuIChmZWF0dXJlcyAmIG1h c2spOworfQorCitpbnQKK3ZpcnRxdWV1ZV9hbGxvYyhkZXZpY2VfdCBkZXYsIHVpbnQxNl90IHF1 ZXVlLCB1aW50MTZfdCBzaXplLAorICAgIGludCBhbGlnbiwgc3RydWN0IHZxX2FsbG9jX2luZm8g KmluZm8sIHN0cnVjdCB2aXJ0cXVldWUgKip2cXApCit7CisJc3RydWN0IHZpcnRxdWV1ZSAqdnE7 CisJaW50IGVycm9yOworCisJKnZxcCA9IE5VTEw7CisJZXJyb3IgPSAwOworCisJaWYgKHNpemUg PT0gMCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgInZpcnRxdWV1ZSBzaXplIGlzIHplcm9cbiIp OworCQlyZXR1cm4gKEVOT0RFVik7CisJfSBlbHNlIGlmICghcG93ZXJvZjIoc2l6ZSkpIHsKKwkJ ZGV2aWNlX3ByaW50ZihkZXYsICJ2aXJ0cXVldWUgc2l6ZSBpcyBub3QgcG93ZXIgb2YgMjogJWRc biIsCisJCSAgICBzaXplKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJdnEgPSBtYWxsb2Mo c2l6ZW9mKHN0cnVjdCB2aXJ0cXVldWUpICsKKwkgICAgc2l6ZSAqIHNpemVvZihzdHJ1Y3QgdnFf ZGVzY19leHRyYSksIE1fREVWQlVGLAorCSAgICBNX05PV0FJVCB8IE1fWkVSTyk7CisJaWYgKHZx ID09IE5VTEwpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgdmlydHF1 ZXVlXG4iKTsKKwkJcmV0dXJuIChFTk9NRU0pOworCX0KKworCS8qIEluaXRpYWxpemUgdmlydHF1 ZXVlLiAqLworCXZxLT52cV9kZXYgPSBkZXY7CisJc3RybGNweSh2cS0+dnFfbmFtZSwgaW5mby0+ dnFhaV9uYW1lLCBzaXplb2YodnEtPnZxX25hbWUpKTsKKwl2cS0+dnFfcXVldWVfaW5kZXggPSBx dWV1ZTsKKwl2cS0+dnFfYWxpZ25tZW50ID0gYWxpZ247CisJdnEtPnZxX25lbnRyaWVzID0gc2l6 ZTsKKwl2cS0+dnFfZnJlZV9jbnQgPSBzaXplOworCXZxLT52cV9tYXhfaW5kaXJlY3Rfc3ogPSBp bmZvLT52cWFpX21heGluZGlyc3o7CisJdnEtPnZxX2ludHJoYW5kID0gaW5mby0+dnFhaV9pbnRy OworCXZxLT52cV9pbnRyaGFuZF9hcmcgPSBpbmZvLT52cWFpX2ludHJfYXJnOworCisJLyogQWxs b2NhdGUgbWVtb3J5IGZvciBpbmRpcmVjdCBkZXNjcmlwdG9ycy4gKi8KKwlpZiAodnEtPnZxX21h eF9pbmRpcmVjdF9zeiA+IDEgJiYKKwkgICAgVklSVElPX0JVU19XSVRIX0ZFQVRVUkUoZGV2LAor CSAgICAgICAgVklSVElPX0ZfUklOR19JTkRJUkVDVF9ERVNDKSkgeworCisJCWVycm9yID0gdmly dHF1ZXVlX2luaXRfaW5kaXJlY3QodnEpOworCQlpZiAoZXJyb3IpIHsKKwkJCWRldmljZV9wcmlu dGYoZGV2LCAiY2Fubm90IGFsbG9jYXRlIG1lbW9yeSAiCisJCQkgICAgImZvciBpbmRpcmVjdCBk ZXNjcmlwdG9yc1xuIik7CisJCQlnb3RvIGZhaWw7CisJCX0KKwl9CisKKwkvKgorCSAqIEFsbG9j YXRlIG1lbW9yeSBmb3IgdGhlIHZyaW5nLgorCSAqIFhYWDogVGhlIDRHQiB1cHBlciBib3VuZGFy eSBpcyBhIFBDSSBsaW1pdGF0aW9uLgorCSAqLworCXZxLT52cV9yaW5nX3NpemUgPSByb3VuZF9w YWdlKHZyaW5nX3NpemUoc2l6ZSwgYWxpZ24pKTsKKwl2cS0+dnFfcmluZ19tZW0gPSBjb250aWdt YWxsb2ModnEtPnZxX3Jpbmdfc2l6ZSwgTV9ERVZCVUYsCisJICAgIE1fV0FJVE9LIHwgTV9aRVJP LCAwLCAweEZGRkZGRkZGVUwsIFBBR0VfU0laRSwgMCk7CisJaWYgKHZxLT52cV9yaW5nX21lbSA9 PSBOVUxMKSB7CisJCWRldmljZV9wcmludGYoZGV2LAorCQkgICAgImNhbm5vdCBhbGxvY2F0ZSBt ZW1vcnkgZm9yIHZpcnRxdWV1ZSByaW5nXG4iKTsKKwkJZXJyb3IgPSBFTk9NRU07CisJCWdvdG8g ZmFpbDsKKwl9CisKKwl2cV9yaW5nX2luaXQodnEpOworCisJLyogRGVmYXVsdCB0byBpbnRlcnJ1 cHRzIGRpc2FibGVkLiAqLworCXZpcnRxdWV1ZV9kaXNhYmxlX2ludHIodnEpOworCisJKnZxcCA9 IHZxOworCitmYWlsOgorCWlmIChlcnJvcikKKwkJdmlydHF1ZXVlX2ZyZWUodnEpOworCisJcmV0 dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK3ZpcnRxdWV1ZV9pbml0X2luZGlyZWN0KHN0 cnVjdCB2aXJ0cXVldWUgKnZxKQoreworCXN0cnVjdCB2cmluZ19kZXNjICpkZXNjOworCWludCBz aXplOworCisJc2l6ZSA9IHZxLT52cV9tYXhfaW5kaXJlY3Rfc3ogKiBzaXplb2Yoc3RydWN0IHZy aW5nX2Rlc2MpOworCXNpemUgKj0gdnEtPnZxX25lbnRyaWVzOworCisJZGVzYyA9IGNvbnRpZ21h bGxvYyhzaXplLCBNX0RFVkJVRiwgTV9OT1dBSVQgfCBNX1pFUk8sCisJICAgIDAsIH4wdWwsIFBB R0VfU0laRSwgMCk7CisJaWYgKGRlc2MgPT0gTlVMTCkKKwkJcmV0dXJuIChFTk9NRU0pOworCisJ dnEtPnZxX2ZsYWdzIHw9IFZJUlRRVUVVRV9JTkRJUkVDVDsKKwl2cS0+dnFfaW5kaXJlY3RfbWVt ID0gZGVzYzsKKwl2cS0+dnFfaW5kaXJlY3RfbWVtX3N6ID0gc2l6ZTsKKworCXJldHVybiAoMCk7 Cit9CisKK3N0YXRpYyB2b2lkCit2aXJ0cXVldWVfZnJlZV9pbmRpcmVjdChzdHJ1Y3QgdmlydHF1 ZXVlICp2cSkKK3sKKworCWlmICgodnEtPnZxX2ZsYWdzICYgVklSVFFVRVVFX0lORElSRUNUKSA9 PSAwKQorCQlyZXR1cm47CisKKwljb250aWdmcmVlKHZxLT52cV9pbmRpcmVjdF9tZW0sIHZxLT52 cV9pbmRpcmVjdF9tZW1fc3osIE1fREVWQlVGKTsKKworCXZxLT52cV9mbGFncyAmPSB+VklSVFFV RVVFX0lORElSRUNUOworCXZxLT52cV9pbmRpcmVjdF9tZW0gPSBOVUxMOworCXZxLT52cV9pbmRp cmVjdF9tZW1fc3ogPSAwOworfQorCitpbnQKK3ZpcnRxdWV1ZV9yZWluaXQoc3RydWN0IHZpcnRx dWV1ZSAqdnEsIHVpbnQxNl90IHNpemUpCit7CisKKwlpZiAodnEtPnZxX25lbnRyaWVzICE9IHNp emUpIHsKKwkJZGV2aWNlX3ByaW50Zih2cS0+dnFfZGV2LAorCQkgICAgInZxX3JlaW5pdDogJyVz JyBjaGFuZ2VkIHNpemU7IG9sZD0laHUsIG5ldz0laHVcbiIsCisJCSAgICB2cS0+dnFfbmFtZSwg dnEtPnZxX25lbnRyaWVzLCBzaXplKTsKKwkJcmV0dXJuIChFSU5WQUwpOworCX0KKworCS8qIFdh cm4gaWYgdGhlIHZpcnRxdWV1ZSB3YXMgbm90IHByb3Blcmx5IGNsZWFuZWQgdXAuICovCisJaWYg KHZxLT52cV9mcmVlX2NudCAhPSB2cS0+dnFfbmVudHJpZXMpIHsKKwkJZGV2aWNlX3ByaW50Zih2 cS0+dnFfZGV2LAorCQkgICAgInZxX3JlaW5pdDogd2FybmluZywgJyVzJyB2aXJ0cXVldWUgbm90 IGVtcHR5LCAiCisJCSAgICAibGVha2luZyAlZCBlbnRyaWVzXG4iLCB2cS0+dnFfbmFtZSwKKwkJ ICAgIHZxLT52cV9uZW50cmllcyAtIHZxLT52cV9mcmVlX2NudCk7CisJfQorCisJdnEtPnZxX2hl YWRfaWR4ID0gMDsKKwl2cS0+dnFfbGFzdF91c2VkX2lkeCA9IDA7CisJdnEtPnZxX3F1ZXVlZF9j bnQgPSAwOworCXZxLT52cV9mcmVlX2NudCA9IHZxLT52cV9uZW50cmllczsKKworCS8qIFRvIGJl IHNhZmUsIHplcm8gYWxsIG91ciBhbGxvY2F0ZWQgbWVtb3J5LiAqLworCWJ6ZXJvKCZ2cS0+dnFf ZGVzY3hbMF0sIHNpemUgKiBzaXplb2Yoc3RydWN0IHZxX2Rlc2NfZXh0cmEpKTsKKwliemVybyh2 cS0+dnFfcmluZ19tZW0sIHZxLT52cV9yaW5nX3NpemUpOworCWlmICh2cS0+dnFfZmxhZ3MgJiBW SVJUUVVFVUVfSU5ESVJFQ1QpCisJCWJ6ZXJvKHZxLT52cV9pbmRpcmVjdF9tZW0sIHZxLT52cV9p bmRpcmVjdF9tZW1fc3opOworCisJdnFfcmluZ19pbml0KHZxKTsKKwl2aXJ0cXVldWVfZGlzYWJs ZV9pbnRyKHZxKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyB2b2lkCit2cV9yaW5nX2lu aXQoc3RydWN0IHZpcnRxdWV1ZSAqdnEpCit7CisJc3RydWN0IHZyaW5nICp2cjsKKwljaGFyICpy aW5nX21lbTsKKwlpbnQgaSwgc2l6ZTsKKworCXJpbmdfbWVtID0gdnEtPnZxX3JpbmdfbWVtOwor CXNpemUgPSB2cS0+dnFfbmVudHJpZXM7CisJdnIgPSAmdnEtPnZxX3ZyaW5nOworCisJdnJpbmdf aW5pdCh2ciwgc2l6ZSwgcmluZ19tZW0sIHZxLT52cV9hbGlnbm1lbnQpOworCisJZm9yIChpID0g MDsgaSA8IHNpemUgLSAxOyBpKyspCisJCXZyLT5kZXNjW2ldLm5leHQgPSBpICsgMTsKKwl2ci0+ ZGVzY1tpXS5uZXh0ID0gVlFfUklOR19ERVNDX0NIQUlOX0VORDsKK30KKwordm1fcGFkZHJfdAor dnFfcmluZ19wYWRkcihzdHJ1Y3QgdmlydHF1ZXVlICp2cSkKK3sKKworCXJldHVybiAodnRvcGh5 cyh2cS0+dnFfcmluZ19tZW0pKTsKK30KKwordm9pZAordmlydHF1ZXVlX2ZyZWUoc3RydWN0IHZp cnRxdWV1ZSAqdnEpCit7CisJaW50IG5sZWFraW5nOworCisJbmxlYWtpbmcgPSB2cS0+dnFfbmVu dHJpZXMgLSB2cS0+dnFfZnJlZV9jbnQ7CisJaWYgKG5sZWFraW5nID4gMCkgeworCQlkZXZpY2Vf cHJpbnRmKHZxLT52cV9kZXYsICIlczogZnJlZWluZyBub24tZW1wdHkgdmlydHF1ZXVlLCAiCisJ CSAgICAibGVha2luZyAlZCBlbnRyaWVzXG4iLCB2cS0+dnFfbmFtZSwgbmxlYWtpbmcpOworCX0K KworCXZpcnRxdWV1ZV9mcmVlX2luZGlyZWN0KHZxKTsKKworCWlmICh2cS0+dnFfcmluZ19tZW0g IT0gTlVMTCkgeworCQljb250aWdmcmVlKHZxLT52cV9yaW5nX21lbSwgdnEtPnZxX3Jpbmdfc2l6 ZSwgTV9ERVZCVUYpOworCQl2cS0+dnFfcmluZ19zaXplID0gMDsKKwkJdnEtPnZxX3JpbmdfbWVt ID0gTlVMTDsKKwl9CisKKwlmcmVlKHZxLCBNX0RFVkJVRik7Cit9CisKK2ludAordmlydHF1ZXVl X3NpemUoc3RydWN0IHZpcnRxdWV1ZSAqdnEpCit7CisKKwlyZXR1cm4gKHZxLT52cV9uZW50cmll cyk7Cit9CisKK2ludAordmlydHF1ZXVlX2VtcHR5KHN0cnVjdCB2aXJ0cXVldWUgKnZxKQorewor CisJcmV0dXJuICh2cS0+dnFfbmVudHJpZXMgPT0gdnEtPnZxX2ZyZWVfY250KTsKK30KKworaW50 Cit2aXJ0cXVldWVfZnVsbChzdHJ1Y3QgdmlydHF1ZXVlICp2cSkKK3sKKworCXJldHVybiAodnEt PnZxX2ZyZWVfY250ID09IDApOworfQorCitpbnQKK3ZpcnRxdWV1ZV9udXNlZChzdHJ1Y3Qgdmly dHF1ZXVlICp2cSkKK3sKKwl1aW50MTZfdCBudXNlZDsKKworCWlmICh2cS0+dnFfdnJpbmcudXNl ZC0+aWR4ID49IHZxLT52cV9sYXN0X3VzZWRfaWR4KQorCQludXNlZCA9IHZxLT52cV92cmluZy51 c2VkLT5pZHggLSB2cS0+dnFfbGFzdF91c2VkX2lkeDsKKwllbHNlCisJCW51c2VkID0gVUlOVDE2 X01BWCAtIHZxLT52cV9sYXN0X3VzZWRfaWR4ICsKKwkJICAgIHZxLT52cV92cmluZy51c2VkLT5p ZHggKyAxOworCisJS0FTU0VSVChudXNlZCA8PSB2cS0+dnFfbmVudHJpZXMsICgidXNlZCBtb3Jl IHRoYW4gYXZhaWxhYmxlIikpOworCisJcmV0dXJuIChudXNlZCk7Cit9CisKK3ZvaWQKK3ZpcnRx dWV1ZV9kaXNhYmxlX2ludHIoc3RydWN0IHZpcnRxdWV1ZSAqdnEpCit7CisKKwkvKgorCSAqIE5v dGUgdGhpcyBpcyBvbmx5IGNvbnNpZGVyZWQgYSBoaW50IHRvIHRoZSBob3N0LgorCSAqLworCXZx LT52cV92cmluZy5hdmFpbC0+ZmxhZ3MgfD0gVlJJTkdfQVZBSUxfRl9OT19JTlRFUlJVUFQ7Cit9 CisKK2ludAordmlydHF1ZXVlX2VuYWJsZV9pbnRyKHN0cnVjdCB2aXJ0cXVldWUgKnZxKQorewor CisJLyoKKwkgKiBFbmFibGUgaW50ZXJydXB0cywgbWFraW5nIHN1cmUgd2UgZ2V0IHRoZSBsYXRl c3QKKwkgKiBpbmRleCBvZiB3aGF0J3MgYWxyZWFkeSBiZWVuIHVzZWQuCisJICovCisJdnEtPnZx X3ZyaW5nLmF2YWlsLT5mbGFncyAmPSB+VlJJTkdfQVZBSUxfRl9OT19JTlRFUlJVUFQ7CisKKwlt YigpOworCisJLyoKKwkgKiBBZGRpdGlvbmFsIGl0ZW1zIG1heSBoYXZlIGJlZW4gdXNlZCBpbiB0 aGUgdGltZSBiZXR3ZWVuCisJICogc2luY2Ugd2UgbGFzdCBjaGVja2VkIGFuZCBlbmFibGVkIGlu dGVycnVwdHMgYWJvdmUuIExldAorCSAqIG91ciBjYWxsZXIga25vdyBzbyBpdCBwcm9jZXNzZXMg dGhlIG5ldyB1c2VkIGVudHJpZXMuCisJICovCisJaWYgKHZxLT52cV9sYXN0X3VzZWRfaWR4ICE9 IHZxLT52cV92cmluZy51c2VkLT5pZHgpCisJCXJldHVybiAoMSk7CisKKwlyZXR1cm4gKDApOwor fQorCitpbnQKK3ZpcnRxdWV1ZV9pbnRyX2VuYWJsZWQoc3RydWN0IHZpcnRxdWV1ZSAqdnEpCit7 CisKKwlyZXR1cm4gKCh2cS0+dnFfdnJpbmcuYXZhaWwtPmZsYWdzICYgVlJJTkdfQVZBSUxfRl9O T19JTlRFUlJVUFQpID09IDApOworfQorCitpbnQKK3ZpcnRxdWV1ZV9pbnRyKHN0cnVjdCB2aXJ0 cXVldWUgKnZxKQoreworCisJaWYgKHZxLT52cV9sYXN0X3VzZWRfaWR4ID09IHZxLT52cV92cmlu Zy51c2VkLT5pZHgpCisJCXJldHVybiAoMCk7CisKKwlpZiAodnEtPnZxX2ludHJoYW5kICE9IE5V TEwpCisJCXZxLT52cV9pbnRyaGFuZCh2cS0+dnFfaW50cmhhbmRfYXJnKTsKKworCXJldHVybiAo MSk7Cit9CisKK3ZvaWQKK3ZpcnRxdWV1ZV9ub3RpZnkoc3RydWN0IHZpcnRxdWV1ZSAqdnEsIGlu dCBmb3JjZSkKK3sKKworCWlmIChmb3JjZSB8fAorCSAgICAodnEtPnZxX3ZyaW5nLnVzZWQtPmZs YWdzICYgVlJJTkdfVVNFRF9GX05PX05PVElGWSkgPT0gMCkKKwkJVklSVElPX0JVU19OT1RJRllf VlEodnEtPnZxX2RldiwgdnEtPnZxX3F1ZXVlX2luZGV4KTsKK30KKwordm9pZCAqCit2aXJ0cXVl dWVfZHJhaW4oc3RydWN0IHZpcnRxdWV1ZSAqdnEpCit7CisJdm9pZCAqY29va2llOworCWludCBp OworCisJY29va2llID0gTlVMTDsKKworCS8qIFZpcnRxdWV1ZXMgYXJlIHNtYWxsIC0gYWx3YXlz IHN0YXJ0IG92ZXIgYXQgdGhlIGJlZ2lubmluZy4gKi8KKwlmb3IgKGkgPSAwOyBpIDwgdnEtPnZx X25lbnRyaWVzOyBpKyspIHsKKwkJaWYgKChjb29raWUgPSB2cS0+dnFfZGVzY3hbaV0uY29va2ll KSAhPSBOVUxMKSB7CisJCQl2cV9yaW5nX2ZyZWVfY2hhaW4odnEsIGkpOworCQkJdnEtPnZxX2Rl c2N4W2ldLmNvb2tpZSA9IE5VTEw7CisJCQlicmVhazsKKwkJfQorCX0KKworCXJldHVybiAoY29v a2llKTsKK30KKworaW50Cit2cV9yaW5nX2VucXVldWUoc3RydWN0IHZpcnRxdWV1ZSAqdnEsIHZv aWQgKmNvb2tpZSwgc3RydWN0IHNnbGlzdCAqc2csCisgICAgaW50IHJlYWRhYmxlLCBpbnQgd3Jp dGFibGUpCit7CisJc3RydWN0IHNnbGlzdF9zZWcgKnNlZzsKKwlzdHJ1Y3QgdnJpbmdfZGVzYyAq ZHA7CisJaW50IGksIGlkeCwgbmVlZGVkLCBoZWFkLCBhdmFpbF9pZHg7CisKKwluZWVkZWQgPSBy ZWFkYWJsZSArIHdyaXRhYmxlOworCisJVlFBU1NFUlQodnEsIGNvb2tpZSAhPSBOVUxMLCAiTlVM TCBjb29raWUiKTsKKwlWUUFTU0VSVCh2cSwgbmVlZGVkID09IHNnLT5zZ19uc2VnLCAic2VnbWVu dCBjb3VudCBtaXNtYXRjaCwgJWQsICVkIiwKKwkgICAgbmVlZGVkLCBzZy0+c2dfbnNlZyk7CisJ VlFBU1NFUlQodnEsCisJICAgIG5lZWRlZCA8PSB2cS0+dnFfbmVudHJpZXMgfHwgbmVlZGVkIDw9 IHZxLT52cV9tYXhfaW5kaXJlY3Rfc3osCisJICAgICJ0b28gbWFueSBzZWdtZW50cyB0byBlbnF1 ZXVlOiAlZCwgJWQvJWQiLCBuZWVkZWQsCisJICAgIHZxLT52cV9uZW50cmllcywgdnEtPnZxX21h eF9pbmRpcmVjdF9zeik7CisKKwlpZiAobmVlZGVkIDwgMSkKKwkJcmV0dXJuIChFSU5WQUwpOwor CisJLyogVXNlIGluZGlyZWN0IGlmIHBvc3NpYmxlLiAqLworCWlmICh2cV9yaW5nX2RvX2luZGly ZWN0KHZxLCBuZWVkZWQpKSB7CisJCXZxX3JpbmdfZW5xdWV1ZV9pbmRpcmVjdCh2cSwgY29va2ll LCBzZywgcmVhZGFibGUsIHdyaXRhYmxlKTsKKwkJcmV0dXJuICgwKTsKKwl9CisKKwlpZiAodnEt PnZxX2ZyZWVfY250IDwgbmVlZGVkKSB7CisJCS8qCisJCSAqIE5vdGlmeSB0aGUgaG9zdCBvbmx5 IGZvciByZWFkLW9ubHkgYnVmZmVycy4KKwkJICovCisJCWlmICh3cml0YWJsZSA9PSAwKQorCQkJ dmlydHF1ZXVlX25vdGlmeSh2cSwgMSk7CisKKwkJaWYgKHZxLT52cV9mcmVlX2NudCA9PSAwKQor CQkJcmV0dXJuIChFTk9TUEMpOworCQllbHNlCisJCQkvKiBDYWxsZXIgbWF5IGRlZnJhZyBhbmQg dHJ5IGFnYWluLiAqLworCQkJcmV0dXJuIChFTVNHU0laRSk7CisJfQorCisJaGVhZCA9IHZxLT52 cV9oZWFkX2lkeDsKKworCWZvciAoaSA9IDAsIGlkeCA9IGhlYWQsIHNlZyA9IHNnLT5zZ19zZWdz OworCSAgICAgaSA8IG5lZWRlZDsKKwkgICAgIGkrKywgaWR4ID0gZHAtPm5leHQsIHNlZysrKSB7 CisJCVZRX1JJTkdfQVNTRVJUX1ZBTElEX0lEWCh2cSwgaWR4KTsKKworCQlkcCA9ICZ2cS0+dnFf dnJpbmcuZGVzY1tpZHhdOworCQlkcC0+YWRkciA9IHNlZy0+c3NfcGFkZHI7CisJCWRwLT5sZW4g PSBzZWctPnNzX2xlbjsKKwkJZHAtPmZsYWdzID0gVlJJTkdfREVTQ19GX05FWFQ7CisJCWlmIChp ID49IHJlYWRhYmxlKQorCQkJZHAtPmZsYWdzIHw9IFZSSU5HX0RFU0NfRl9XUklURTsKKwl9CisJ ZHAtPmZsYWdzICY9IH5WUklOR19ERVNDX0ZfTkVYVDsKKworCS8qIFNldCB0aGUgbmV3IGhlYWQu ICovCisJdnEtPnZxX2hlYWRfaWR4ID0gZHAtPm5leHQ7CisJdnEtPnZxX2ZyZWVfY250IC09IG5l ZWRlZDsKKwlpZiAodnEtPnZxX2ZyZWVfY250ID09IDApCisJCVZRX1JJTkdfQVNTRVJUX0NIQUlO X1RFUk0odnEpOworCWVsc2UKKwkJVlFfUklOR19BU1NFUlRfVkFMSURfSURYKHZxLCB2cS0+dnFf aGVhZF9pZHgpOworCisJLyoKKwkgKiBBZGQgYSBuZXcgZW50cnkgdG8gdGhlIGF2YWlsYWJsZSBy aW5nLCBidXQgcG9zdHBvbmUKKwkgKiB0ZWxsaW5nIHRoZSBob3N0IGFib3V0IGl0IHVudGlsIHZx X3Jpbmdfc3luYygpLiBUaGUKKwkgKiBzcGVjaWZpY2F0aW9uIGFkdm9jYXRlcyBkb2luZyB0aGlz IHRvIHJlZHVjZSBndWVzdC9ob3N0CisJICogY29udGV4dCBzd2l0Y2hlcy4KKwkgKi8KKwlhdmFp bF9pZHggPSAodnEtPnZxX3ZyaW5nLmF2YWlsLT5pZHggKyB2cS0+dnFfcXVldWVkX2NudCsrKSAl CisJICAgIHZxLT52cV9uZW50cmllczsKKwl2cS0+dnFfdnJpbmcuYXZhaWwtPnJpbmdbYXZhaWxf aWR4XSA9IGhlYWQ7CisJVlFBU1NFUlQodnEsIHZxLT52cV9kZXNjeFtoZWFkXS5jb29raWUgPT0g TlVMTCwKKwkgICAgImNvb2tpZSBhbHJlYWR5IGV4aXN0cyBmb3IgaWR4ICVkIiwgaGVhZCk7CisJ dnEtPnZxX2Rlc2N4W2hlYWRdLmNvb2tpZSA9IGNvb2tpZTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBpbnQKK3ZxX3JpbmdfZG9faW5kaXJlY3Qoc3RydWN0IHZpcnRxdWV1ZSAqdnEsIGlu dCBuZWVkZWQpCit7CisKKwlpZiAoKHZxLT52cV9mbGFncyAmIFZJUlRRVUVVRV9JTkRJUkVDVCkg PT0gMCkKKwkJcmV0dXJuICgwKTsKKworCWlmICh2cS0+dnFfZnJlZV9jbnQgPT0gMCkKKwkJcmV0 dXJuICgwKTsKKworCWlmICh2cS0+dnFfbWF4X2luZGlyZWN0X3N6IDwgbmVlZGVkKQorCQlyZXR1 cm4gKDApOworCisJaWYgKG5lZWRlZCA8IDIpCisJCXJldHVybiAoMCk7CisKKwlyZXR1cm4gKDEp OworfQorCitzdGF0aWMgdm9pZAordnFfcmluZ19lbnF1ZXVlX2luZGlyZWN0KHN0cnVjdCB2aXJ0 cXVldWUgKnZxLCB2b2lkICpjb29raWUsCisgICAgc3RydWN0IHNnbGlzdCAqc2csIGludCByZWFk YWJsZSwgaW50IHdyaXRhYmxlKQoreworCXN0cnVjdCBzZ2xpc3Rfc2VnICpzZWc7CisJc3RydWN0 IHZyaW5nX2Rlc2MgKmRwLCAqaW5kaXJlY3QsICppZHA7CisJaW50IGksIG5lZWRlZCwgaGVhZCwg YXZhaWxfaWR4OworCisJaGVhZCA9IHZxLT52cV9oZWFkX2lkeDsKKwlWUV9SSU5HX0FTU0VSVF9W QUxJRF9JRFgodnEsIGhlYWQpOworCW5lZWRlZCA9IHJlYWRhYmxlICsgd3JpdGFibGU7CisKKwlW UUFTU0VSVCh2cSwgbmVlZGVkIDw9IHZxLT52cV9tYXhfaW5kaXJlY3Rfc3osCisJICAgICJlbnF1 ZXVpbmcgdG9vIG1hbnkgaW5kaXJlY3QgZGVzY3JpcHRvcnMiKTsKKworCWluZGlyZWN0ID0gaWRw ID0gJnZxLT52cV9pbmRpcmVjdF9tZW1baGVhZCAqIHZxLT52cV9tYXhfaW5kaXJlY3Rfc3pdOwor CisJZm9yIChpID0gMCwgc2VnID0gc2ctPnNnX3NlZ3M7CisJICAgICBpIDwgbmVlZGVkOworCSAg ICAgaSsrLCBzZWcrKykgeworCisJCWlkcCA9ICZpbmRpcmVjdFtpXTsKKwkJaWRwLT5hZGRyID0g c2VnLT5zc19wYWRkcjsKKwkJaWRwLT5sZW4gPSBzZWctPnNzX2xlbjsKKwkJaWRwLT5mbGFncyA9 IFZSSU5HX0RFU0NfRl9ORVhUOworCQlpZHAtPm5leHQgPSBpICsgMTsKKwkJaWYgKGkgPj0gcmVh ZGFibGUpCisJCQlpZHAtPmZsYWdzIHw9IFZSSU5HX0RFU0NfRl9XUklURTsKKwl9CisJaWRwLT5m bGFncyAmPSB+VlJJTkdfREVTQ19GX05FWFQ7CisJaWRwLT5uZXh0ID0gVlFfUklOR19ERVNDX0NI QUlOX0VORDsKKworCWRwID0gJnZxLT52cV92cmluZy5kZXNjW2hlYWRdOworCWRwLT5hZGRyID0g dnRvcGh5cyhpbmRpcmVjdCk7CisJZHAtPmxlbiA9IG5lZWRlZCAqIHNpemVvZihzdHJ1Y3QgdnJp bmdfZGVzYyk7CisJZHAtPmZsYWdzID0gVlJJTkdfREVTQ19GX0lORElSRUNUOworCisJLyogU2V0 IHRoZSBuZXcgaGVhZC4gKi8KKwl2cS0+dnFfaGVhZF9pZHggPSBkcC0+bmV4dDsKKwl2cS0+dnFf ZnJlZV9jbnQtLTsKKwlpZiAodnEtPnZxX2ZyZWVfY250ID09IDApCisJCVZRX1JJTkdfQVNTRVJU X0NIQUlOX1RFUk0odnEpOworCWVsc2UKKwkJVlFfUklOR19BU1NFUlRfVkFMSURfSURYKHZxLCB2 cS0+dnFfaGVhZF9pZHgpOworCisJVlFBU1NFUlQodnEsIHZxLT52cV9kZXNjeFtoZWFkXS5jb29r aWUgPT0gTlVMTCwKKwkgICAgImNvb2tpZSBhbHJlYWR5IGV4aXN0cyBmb3IgaWR4ICVkIiwgaGVh ZCk7CisJdnEtPnZxX2Rlc2N4W2hlYWRdLmNvb2tpZSA9IGNvb2tpZTsKKworCWF2YWlsX2lkeCA9 ICh2cS0+dnFfdnJpbmcuYXZhaWwtPmlkeCArIHZxLT52cV9xdWV1ZWRfY250KyspICUKKwkgICAg dnEtPnZxX25lbnRyaWVzOworCXZxLT52cV92cmluZy5hdmFpbC0+cmluZ1thdmFpbF9pZHhdID0g aGVhZDsKK30KKwordm9pZAordnFfcmluZ19zeW5jKHN0cnVjdCB2aXJ0cXVldWUgKnZxKQorewor CisJLyogVXBkYXRlIGF2YWlsYWJsZSByaW5nLiAqLworCW1iKCk7CisJdnEtPnZxX3ZyaW5nLmF2 YWlsLT5pZHggKz0gdnEtPnZxX3F1ZXVlZF9jbnQ7CisJdnEtPnZxX3F1ZXVlZF9jbnQgPSAwOwor CisJLyogTm90aWZ5IGhvc3QuICovCisJbWIoKTsKKwl2aXJ0cXVldWVfbm90aWZ5KHZxLCAwKTsK K30KKwordm9pZCAqCit2cV9yaW5nX2RlcXVldWUoc3RydWN0IHZpcnRxdWV1ZSAqdnEsIHVpbnQz Ml90ICpsZW4pCit7CisJc3RydWN0IHZyaW5nX3VzZWRfZWxlbSAqdWVwOworCXZvaWQgKmNvb2tp ZTsKKwlpbnQgdXNlZF9pZHgsIGRlc2NfaWR4OworCisJaWYgKHZxLT52cV9sYXN0X3VzZWRfaWR4 ID09IHZxLT52cV92cmluZy51c2VkLT5pZHgpCisJCXJldHVybiAoTlVMTCk7CisKKwltYigpOwor CXVzZWRfaWR4ID0gdnEtPnZxX2xhc3RfdXNlZF9pZHggJSB2cS0+dnFfbmVudHJpZXM7CisJdWVw ID0gJnZxLT52cV92cmluZy51c2VkLT5yaW5nW3VzZWRfaWR4XTsKKwl2cS0+dnFfbGFzdF91c2Vk X2lkeCsrOworCisJZGVzY19pZHggPSB1ZXAtPmlkOworCWlmIChsZW4gIT0gTlVMTCkKKwkJKmxl biA9IHVlcC0+bGVuOworCWNvb2tpZSA9IHZxLT52cV9kZXNjeFtkZXNjX2lkeF0uY29va2llOwor CVZRQVNTRVJUKHZxLCBjb29raWUgIT0gTlVMTCwgIm5vIGNvb2tpZSBmb3IgaW5kZXggJWQiLCBk ZXNjX2lkeCk7CisJdnEtPnZxX2Rlc2N4W2Rlc2NfaWR4XS5jb29raWUgPSBOVUxMOworCisJdnFf cmluZ19mcmVlX2NoYWluKHZxLCBkZXNjX2lkeCk7CisKKwlyZXR1cm4gKGNvb2tpZSk7Cit9CisK K3N0YXRpYyB2b2lkCit2cV9yaW5nX2ZyZWVfY2hhaW4oc3RydWN0IHZpcnRxdWV1ZSAqdnEsIGlu dCBkZXNjX2lkeCkKK3sKKwlzdHJ1Y3QgdnJpbmdfZGVzYyAqaGRwLCAqZHA7CisKKwloZHAgPSBk cCA9ICZ2cS0+dnFfdnJpbmcuZGVzY1tkZXNjX2lkeF07CisJaWYgKHZxLT52cV9mcmVlX2NudCA9 PSAwKQorCQlWUV9SSU5HX0FTU0VSVF9DSEFJTl9URVJNKHZxKTsKKworCWlmICgoZHAtPmZsYWdz ICYgVlJJTkdfREVTQ19GX0lORElSRUNUKSA9PSAwKSB7CisJCS8qIE1hcmsgdGhlIGNoYWluIGFz IGZyZWUuICovCisJCXdoaWxlIChkcC0+ZmxhZ3MgJiBWUklOR19ERVNDX0ZfTkVYVCkgeworCQkJ VlFfUklOR19BU1NFUlRfVkFMSURfSURYKHZxLCBkcC0+bmV4dCk7CisKKwkJCWRwID0gJnZxLT52 cV92cmluZy5kZXNjW2RwLT5uZXh0XTsKKwkJCWRwLT5mbGFncyAmPSBWUklOR19ERVNDX0ZfTkVY VDsKKwkJCXZxLT52cV9mcmVlX2NudCsrOworCQl9CisJfQorCisJLyogTWFyayAqaGRwIGFzIGZy ZWUuICovCisJaGRwLT5mbGFncyAmPSBWUklOR19ERVNDX0ZfTkVYVDsKKwl2cS0+dnFfZnJlZV9j bnQrKzsKKworCS8qCisJICogQXBwZW5kIHRoZSBleGlzdGluZyBmcmVlIGNoYWluLCBpZiBhbnks IHRvIHRoZSBuZXdseSBmcmVlZAorCSAqIGNoYWluLiBNdXN0IGFwcGVuZCBvbGQgdG8gbmV3IGlu IGNhc2UgdGhlIHZpcnRxdWV1ZSB3YXMKKwkgKiBmdWxsLgorCSAqLworCWRwLT5uZXh0ID0gdnEt PnZxX2hlYWRfaWR4OworCWRwLT5mbGFncyA9IFZSSU5HX0RFU0NfRl9ORVhUOworCS8qIFNldCBk ZXNjX2lkeCBhcyB0aGUgbmV3IGhlYWQuICovCisJdnEtPnZxX2hlYWRfaWR4ID0gZGVzY19pZHg7 Cit9CisKK3ZvaWQKK3ZpcnRxdWV1ZV9kdW1wKHN0cnVjdCB2aXJ0cXVldWUgKnZxKQoreworCisJ aWYgKHZxID09IE5VTEwpCisJCXJldHVybjsKKworCXByaW50ZigiVlE6ICVzIC0gbGFzdF91c2Vk X2lkeDogJWQ7IHVzZWQuaWR4OiAlZDsgIgorCSAgICAiYXZhaWwuaWR4OiAlZDsgZnJlZTogJWQ7 IGZsYWdzOiAweCV4XG4iLCB2cS0+dnFfbmFtZSwKKwkgICAgdnEtPnZxX2xhc3RfdXNlZF9pZHgs IHZxLT52cV92cmluZy51c2VkLT5pZHgsCisJICAgIHZxLT52cV92cmluZy5hdmFpbC0+aWR4LCB2 cS0+dnFfZnJlZV9jbnQsCisJICAgIHZxLT52cV92cmluZy5hdmFpbC0+ZmxhZ3MpOworfQpkaWZm IC0tZ2l0IGEvc3lzL2Rldi92aXJ0aW8vdmlydHF1ZXVlLmggYi9zeXMvZGV2L3ZpcnRpby92aXJ0 cXVldWUuaApuZXcgZmlsZSBtb2RlIDEwMDY0NAotLS0gL2Rldi9udWxsCisrKyBiL3N5cy9kZXYv dmlydGlvL3ZpcnRxdWV1ZS5oCkBAIC0wLDAgKzEsNjggQEAKKyNpZm5kZWYgX1ZJUlRJT19WSVJU UVVFVUVfSAorI2RlZmluZSBfVklSVElPX1ZJUlRRVUVVRV9ICisKKyNpbmNsdWRlIDxzeXMvdHlw ZXMuaD4KKworc3RydWN0IHZpcnRxdWV1ZTsKK3N0cnVjdCBzZ2xpc3Q7CisKKy8qIFN1cHBvcnQg Zm9yIGluZGlyZWN0IGJ1ZmZlciBkZXNjcmlwdG9ycy4gKi8KKyNkZWZpbmUgVklSVElPX0ZfUklO R19JTkRJUkVDVF9ERVNDCSgxIDw8IDI4KQorCisvKiBEZXZpY2UgY2FsbGJhY2sgZm9yIGEgdmly dHF1ZXVlIGludGVycnVwdC4gKi8KK3R5cGVkZWYgaW50IHZpcnRxdWV1ZV9pbnRyX3Qodm9pZCAq KTsKKworI2RlZmluZSBWSVJUUVVFVUVfTUFYX05BTUVfU1oJMzIKKworLyogT25lIGZvciBlYWNo IHZpcnRxdWV1ZSB0aGUgZHJpdmVyIHdpc2hlcyB0byBhbGxvY2F0ZS4gKi8KK3N0cnVjdCB2cV9h bGxvY19pbmZvIHsKKwljaGFyCQkgICB2cWFpX25hbWVbVklSVFFVRVVFX01BWF9OQU1FX1NaXTsK KwlpbnQJCSAgIHZxYWlfbWF4aW5kaXJzejsKKwl2aXJ0cXVldWVfaW50cl90ICAqdnFhaV9pbnRy OworCXZvaWQJCSAgKnZxYWlfaW50cl9hcmc7CisJc3RydWN0IHZpcnRxdWV1ZSAqKnZxYWlfdnE7 Cit9OworCisjZGVmaW5lIFZRX0FMTE9DX0lORk9fSU5JVChfaSxfbnNlZ3MsX2ludHIsX2FyZyxf dnFwLF9zdHIsLi4uKSBkbyB7CVwKKwlzbnByaW50ZigoX2kpLT52cWFpX25hbWUsIFZJUlRRVUVV RV9NQVhfTkFNRV9TWiwgX3N0ciwJCVwKKwkgICAgIyNfX1ZBX0FSR1NfXyk7CQkJCQkJXAorCShf aSktPnZxYWlfbWF4aW5kaXJzeiA9IChfbnNlZ3MpOwkJCQlcCisJKF9pKS0+dnFhaV9pbnRyID0g KF9pbnRyKTsJCQkJCVwKKwkoX2kpLT52cWFpX2ludHJfYXJnID0gKF9hcmcpOwkJCQkJXAorCShf aSktPnZxYWlfdnEgPSAoX3ZxcCk7CQkJCQkJXAorfSB3aGlsZSAoMCkKKwordWludDMyX3Qgdmly dHF1ZXVlX2ZpbHRlcl9mZWF0dXJlcyh1aW50MzJfdCk7CisKK2ludAl2aXJ0cXVldWVfYWxsb2Mo ZGV2aWNlX3QgZGV2LCB1aW50MTZfdCBxdWV1ZSwgdWludDE2X3Qgc2l6ZSwKKwkgICAgaW50IGFs aWduLCBzdHJ1Y3QgdnFfYWxsb2NfaW5mbyAqaW5mbywKKwkgICAgc3RydWN0IHZpcnRxdWV1ZSAq KnZxcCk7Cit2b2lkCSp2aXJ0cXVldWVfZHJhaW4oc3RydWN0IHZpcnRxdWV1ZSAqdnEpOwordm9p ZAkgdmlydHF1ZXVlX2ZyZWUoc3RydWN0IHZpcnRxdWV1ZSAqdnEpOworaW50CSB2aXJ0cXVldWVf cmVpbml0KHN0cnVjdCB2aXJ0cXVldWUgKnZxLCB1aW50MTZfdCBzaXplKTsKKworaW50CSB2aXJ0 cXVldWVfaW50cihzdHJ1Y3QgdmlydHF1ZXVlICp2cSk7CitpbnQgCSB2aXJ0cXVldWVfZW5hYmxl X2ludHIoc3RydWN0IHZpcnRxdWV1ZSAqdnEpOwordm9pZCAJIHZpcnRxdWV1ZV9kaXNhYmxlX2lu dHIoc3RydWN0IHZpcnRxdWV1ZSAqdnEpOworaW50CSB2aXJ0cXVldWVfaW50cl9lbmFibGVkKHN0 cnVjdCB2aXJ0cXVldWUgKnZxKTsKK3ZvaWQJIHZpcnRxdWV1ZV9ub3RpZnkoc3RydWN0IHZpcnRx dWV1ZSAqdnEsIGludCBmb3JjZSk7CisKK2ludAkgdmlydHF1ZXVlX2Z1bGwoc3RydWN0IHZpcnRx dWV1ZSAqdnEpOworaW50CSB2aXJ0cXVldWVfZW1wdHkoc3RydWN0IHZpcnRxdWV1ZSAqdnEpOwor aW50CSB2aXJ0cXVldWVfc2l6ZShzdHJ1Y3QgdmlydHF1ZXVlICp2cSk7CitpbnQJIHZpcnRxdWV1 ZV9udXNlZChzdHJ1Y3QgdmlydHF1ZXVlICp2cSk7Cit2b2lkCSB2aXJ0cXVldWVfZHVtcChzdHJ1 Y3QgdmlydHF1ZXVlICp2cSk7CisKKy8qCisgKiBUaGUgVmlydElPIHJpbmcgaXMgdGhlIG9ubHkg dHJhbnNwb3J0IHdlIHN1cHBvcnQuCisgKi8KKworLyogR2V0IHBoeXNpY2FsIGFkZHJlc3Mgb2Yg dGhlIHZxIHJpbmcuICovCit2bV9wYWRkcl90IHZxX3JpbmdfcGFkZHIoc3RydWN0IHZpcnRxdWV1 ZSAqdnEpOworCitpbnQJIHZxX3JpbmdfZW5xdWV1ZShzdHJ1Y3QgdmlydHF1ZXVlICp2cSwgdm9p ZCAqY29va2llLAorCSAgICAgc3RydWN0IHNnbGlzdCAqc2csIGludCByZWFkYWJsZSwgaW50IHdy aXRhYmxlKTsKK3ZvaWQJIHZxX3Jpbmdfc3luYyhzdHJ1Y3QgdmlydHF1ZXVlICp2cSk7Cit2b2lk CSp2cV9yaW5nX2RlcXVldWUoc3RydWN0IHZpcnRxdWV1ZSAqdnEsIHVpbnQzMl90ICpsZW4pOwor CisjZW5kaWYgLyogX1ZJUlRJT19WSVJUUVVFVUVfSCAqLwpkaWZmIC0tZ2l0IGEvc3lzL21vZHVs ZXMvTWFrZWZpbGUgYi9zeXMvbW9kdWxlcy9NYWtlZmlsZQotLS0gYS9zeXMvbW9kdWxlcy9NYWtl ZmlsZQorKysgYi9zeXMvbW9kdWxlcy9NYWtlZmlsZQpAQCAtMzAyLDYgKzMwMiw3IEBACiAJdXRv cGlhIFwKIAkke192ZXNhfSBcCiAJdmdlIFwKKwkke192aXJ0aW99IFwKIAl2a2JkIFwKIAkke192 cG99IFwKIAl2ciBcCmRpZmYgLS1naXQgYS9zeXMvbW9kdWxlcy92aXJ0aW8vTWFrZWZpbGUgYi9z eXMvbW9kdWxlcy92aXJ0aW8vTWFrZWZpbGUKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0tIC9kZXYv bnVsbAorKysgYi9zeXMvbW9kdWxlcy92aXJ0aW8vTWFrZWZpbGUKQEAgLTAsMCArMSwyOCBAQAor IworIyAkRnJlZUJTRCQKKyMKKyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0Ogor IyAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3Zl IGNvcHlyaWdodAorIyAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg Zm9sbG93aW5nIGRpc2NsYWltZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMg ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhl IGRpc3RyaWJ1dGlvbi4KKyMKKyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorIyBBTlkgRVhQUkVTUyBPUiBJTVBM SUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyMgSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKKyMgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyMgRk9SIEFOWSBESVJFQ1QsIElORElS RUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyMg REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNV QlNUSVRVVEUgR09PRFMKKyMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9G SVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisjIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBB TlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisjIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkKKyMgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJ RiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorIyBTVUNIIERBTUFHRS4KKyMKKworU1VC RElSPQl2aXJ0aW8gcGNpIG5ldHdvcmsKKworLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+CmRpZmYg LS1naXQgYS9zeXMvbW9kdWxlcy92aXJ0aW8vYmxvY2svTWFrZWZpbGUgYi9zeXMvbW9kdWxlcy92 aXJ0aW8vYmxvY2svTWFrZWZpbGUKbmV3IGZpbGUgbW9kZSAxMDA2NDQKLS0tIC9kZXYvbnVsbAor KysgYi9zeXMvbW9kdWxlcy92aXJ0aW8vYmxvY2svTWFrZWZpbGUKQEAgLTAsMCArMSwzMyBAQAor IworIyAkRnJlZUJTRCQKKyMKKyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0Ogor IyAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3Zl IGNvcHlyaWdodAorIyAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUg Zm9sbG93aW5nIGRpc2NsYWltZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMg ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhl IGRpc3RyaWJ1dGlvbi4KKyMKKyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVU SE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorIyBBTlkgRVhQUkVTUyBPUiBJTVBM SUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyMgSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKKyMgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyMgRk9SIEFOWSBESVJFQ1QsIElORElS RUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyMg REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNV QlNUSVRVVEUgR09PRFMKKyMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9G SVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisjIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBB TlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisjIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkKKyMgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJ RiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorIyBTVUNIIERBTUFHRS4KKyMKKworLlBB VEg6ICR7LkNVUkRJUn0vLi4vLi4vLi4vZGV2L3ZpcnRpby9ibG9jaworCitLTU9EPQl2dGJsawor U1JDUz0JdnRibGsuYworU1JDUys9CXZpcnRpb19idXNfaWYuaCB2aXJ0aW9faWYuaAorU1JDUys9 CWJ1c19pZi5oIGRldmljZV9pZi5oIAorCisuaW5jbHVkZSA8YnNkLmttb2QubWs+CmRpZmYgLS1n aXQgYS9zeXMvbW9kdWxlcy92aXJ0aW8vbmV0d29yay9NYWtlZmlsZSBiL3N5cy9tb2R1bGVzL3Zp cnRpby9uZXR3b3JrL01ha2VmaWxlCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwK KysrIGIvc3lzL21vZHVsZXMvdmlydGlvL25ldHdvcmsvTWFrZWZpbGUKQEAgLTAsMCArMSwzMyBA QAorIworIyAkRnJlZUJTRCQKKyMKKyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBl cm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0 OgorIyAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFi b3ZlIGNvcHlyaWdodAorIyAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkg Zm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUK KyMgICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGgg dGhlIGRpc3RyaWJ1dGlvbi4KKyMKKyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUg QVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorIyBBTlkgRVhQUkVTUyBPUiBJ TVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyMg SU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQ QVJUSUNVTEFSIFBVUlBPU0UKKyMgQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBU SEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyMgRk9SIEFOWSBESVJFQ1QsIElO RElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwK KyMgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9G IFNVQlNUSVRVVEUgR09PRFMKKyMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQ Uk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisjIEhPV0VWRVIgQ0FVU0VEIEFORCBP TiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisj IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkKKyMgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZF TiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorIyBTVUNIIERBTUFHRS4KKyMKKwor LlBBVEg6ICR7LkNVUkRJUn0vLi4vLi4vLi4vZGV2L3ZpcnRpby9uZXR3b3JrCisKK0tNT0Q9CWlm X3Z0bmV0CitTUkNTPQlpZl92dG5ldC5jCitTUkNTKz0JdmlydGlvX2J1c19pZi5oIHZpcnRpb19p Zi5oCitTUkNTKz0JYnVzX2lmLmggZGV2aWNlX2lmLmggCisKKy5pbmNsdWRlIDxic2Qua21vZC5t az4KZGlmZiAtLWdpdCBhL3N5cy9tb2R1bGVzL3ZpcnRpby9wY2kvTWFrZWZpbGUgYi9zeXMvbW9k dWxlcy92aXJ0aW8vcGNpL01ha2VmaWxlCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251 bGwKKysrIGIvc3lzL21vZHVsZXMvdmlydGlvL3BjaS9NYWtlZmlsZQpAQCAtMCwwICsxLDMzIEBA CisjCisjICRGcmVlQlNEJAorIworIyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyMgbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisjIGFyZSBtZXQ6 CisjIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRo ZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyMgMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBm b3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyMgICAgbm90aWNlLCB0aGlz IGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQor IyAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUgZGlzdHJpYnV0aW9uLgorIworIyBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBB VVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisjIEFOWSBFWFBSRVNTIE9SIElN UExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorIyBJ TVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRQorIyBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorIyBGT1IgQU5ZIERJUkVDVCwgSU5E SVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAor IyBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0Yg U1VCU1RJVFVURSBHT09EUworIyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBS T0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyMgSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyMg TElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFS SVNJTkcgSU4gQU5ZIFdBWQorIyBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVO IElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisjIFNVQ0ggREFNQUdFLgorIworCisu UEFUSDogJHsuQ1VSRElSfS8uLi8uLi8uLi9kZXYvdmlydGlvL3BjaQorCitLTU9EPQl2aXJ0aW9f cGNpCitTUkNTPQl2aXJ0aW9fcGNpLmMKK1NSQ1MrPQl2aXJ0aW9fYnVzX2lmLmggdmlydGlvX2lm LmggCitTUkNTKz0JYnVzX2lmLmggZGV2aWNlX2lmLmggcGNpX2lmLmgKKworLmluY2x1ZGUgPGJz ZC5rbW9kLm1rPgpkaWZmIC0tZ2l0IGEvc3lzL21vZHVsZXMvdmlydGlvL3ZpcnRpby9NYWtlZmls ZSBiL3N5cy9tb2R1bGVzL3ZpcnRpby92aXJ0aW8vTWFrZWZpbGUKbmV3IGZpbGUgbW9kZSAxMDA2 NDQKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMvbW9kdWxlcy92aXJ0aW8vdmlydGlvL01ha2VmaWxl CkBAIC0wLDAgKzEsMzUgQEAKKyMKKyMgJEZyZWVCU0QkCisjCisjIFJlZGlzdHJpYnV0aW9uIGFu ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorIyBtb2Rp ZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRp dGlvbnMKKyMgYXJlIG1ldDoKKyMgMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11 c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyMgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2Yg Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorIyAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAor IyAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIgaW4gdGhlCisjICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFs cyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisjCisjIFRISVMgU09GVFdBUkUgSVMg UFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyMg QU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCisjIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisjIEFSRSBESVNDTEFJTUVELiAgSU4g Tk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisjIEZP UiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBP UiBDT05TRVFVRU5USUFMCisjIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisjIE9SIFNFUlZJQ0VTOyBMT1NTIE9G IFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorIyBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09O VFJBQ1QsIFNUUklDVAorIyBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNF IE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisjIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyMgU1VD SCBEQU1BR0UuCisjCisKKy5QQVRIOiAkey5DVVJESVJ9Ly4uLy4uLy4uL2Rldi92aXJ0aW8KKwor S01PRD0JdmlydGlvCisKK1NSQ1M9CXZpcnRpby5jIHZpcnRxdWV1ZS5jCitTUkNTKz0JdmlydGlv X2J1c19pZi5jIHZpcnRpb19idXNfaWYuaAorU1JDUys9CXZpcnRpb19pZi5jIHZpcnRpb19pZi5o CitTUkNTKz0JYnVzX2lmLmggZGV2aWNlX2lmLmggCisKKy5pbmNsdWRlIDxic2Qua21vZC5taz4K --20cf30549f434fb2120498e508cb-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 07:09:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97ACE106566C for ; Mon, 3 Jan 2011 07:09:06 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 265F48FC0C for ; Mon, 3 Jan 2011 07:09:05 +0000 (UTC) Received: by fxm16 with SMTP id 16so12840389fxm.13 for ; Sun, 02 Jan 2011 23:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eqS6/cVP/S6PbXPPmutWshvRifXmUb/r+iG1zVy26JI=; b=MqsQ/THGEFfllqDlwpwm1D6SDnzaGljFmfJc10xPvKo+nsURxhXy47XN4xSPeYZg2Z S9IOC8jaAqe/H6izN70OsmZHaplT8qYiWqUkn5x79BKZAsrvekPp1Iyp7LxVc4rsU744 hrSukZcm7+ZbEC29sFtShp9QJncKYKNYVZOqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jOBnfE7TXQ6PokKhOzFLXzRjswDmkn1QZfLLZiLZHgKZkWfmtBl4yUkR87FiktRHNF JY4ql/75yUiCEoCPoOtXT0lmIH/jNYExKlbI8RrjdZCp7+EwHuc0GpHAKjG8FaE/OmiO S+/fUA+Bs9G+01P40cQB5QcqusrBtIsPHPxEY= MIME-Version: 1.0 Received: by 10.223.106.129 with SMTP id x1mr404755fao.13.1294038544995; Sun, 02 Jan 2011 23:09:04 -0800 (PST) Received: by 10.223.114.4 with HTTP; Sun, 2 Jan 2011 23:09:04 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 01:09:04 -0600 Message-ID: From: Adam Vande More To: bv Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: [Call for testers] FreeBSD VirtIO Network Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 07:09:07 -0000 On Sun, Jan 2, 2011 at 5:02 PM, bv wrote: > Hi. > > I'd like to present the network VirtIO driver I've been working on for > the last few months in my spare time. It is not based on the NetBSD code > that is floating around. The attached patch should apply to both recent > -current and -stable. Early development was done on VirtualBox, > but most has been done on KVM/QEMU. > > I'm going to be away from my computer for the next couple of days, > I'll get to any email after then. > Thanks for this work, I'm sure it will be quite useful. I'm testing on a FreeBSD Virtualbox Host/Guest. Guest is CURRENT kern.osrevision: 199506 virtualbox-ose-3.2.10_2 My particular version of Virtualbox isn't optimized yet for virtio I believe, but I did see about 1/3 higher peak bandwidth and a definite reduction in CPU usage. -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 10:46:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97834106564A for ; Mon, 3 Jan 2011 10:46:33 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 716F38FC08 for ; Mon, 3 Jan 2011 10:46:33 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id C860837B4C0; Mon, 3 Jan 2011 04:28:53 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 0C62461C5A; Mon, 3 Jan 2011 04:28:53 -0600 (CST) Date: Mon, 3 Jan 2011 04:28:53 -0600 From: "Matthew D. Fuller" To: current@freebsd.org Message-ID: <20110103102853.GA89454@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.5 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: mav@FreeBSD.org Subject: Oddities in -current post-eventtimer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 10:46:33 -0000 OK, this has happened a couple times now. I'm running a mid-Oct -CURRENT, and at around 25 days uptime (not exact but consistently in that vicinity), things start getting very choppy. It's easily visible in playing videos; things get very jerky and slow, but all sorts of things start acting like they're happening in little chunks of time; keyboard repeats get very slow, things that often take notable time take much more, etc. It's accompanied by a big spat of "calcru: runtime went backwards" messages (presumably just another symptom). The only fix I've found is to reboot, and then it's good for another 25ish days. As a workaround, enabling kern.eventtimer.idletick sets things rightish. A look at the interrupts turns up a hint; while vmstat says the overall average for cpu0 is just under 300/s, systat -vmstat shows that it's currnetly running around 20-some. The other CPU's also settle at much lower levels. Another more tiring workaround is just slinging the mouse around real fast; that seems to hint to the system to keep checking stuff. Watching systat, that doesn't seem to bring the cpuX interrupt rate up very much, but the videos start playing smoothly. FreeBSD 9.0-CURRENT #0 r214107: Wed Oct 20 06:25:50 CDT 2010 Quad-core running amd64. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 11:21:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD341065694 for ; Mon, 3 Jan 2011 11:21:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE74C8FC1B for ; Mon, 3 Jan 2011 11:21:18 +0000 (UTC) Received: by fxm16 with SMTP id 16so12944631fxm.13 for ; Mon, 03 Jan 2011 03:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Q05TzUSrs9bKmA5XtDEdsOepuhyeVW+GtQuLskGx7Lw=; b=PFck1CkON6dd6gxMpv+WwXglM3TQ5Bk9VGAjh8vu5SMvVQeDhVOu682kl01G7MdfVl UB2D487jDDHzxo8RCF9DQbeSQSACrep+vsbpUYQXikoGFKwCIraxZP8QrS7f7fqqL3Wf JMjpYs/EmmymrEQmTb4dDxU23BBn1iI7D/zCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=v7c5S+Ww+RjNPCQhfEc/viRJsdEfG7jWKjfW6XhFmuCsNNCvb08qxyi/493aXCB/5N KfchUw6TVDNg9nSQvUOn6S/mwMUWJaO6ZCXVVMTFTQg+IrYlUvAdisfUpmYUfQWDuLc+ eCIx8b/y3yWKQxSS8S7OD/3vkoTd4TsoG1g48= Received: by 10.223.101.141 with SMTP id c13mr1754582fao.118.1294053677696; Mon, 03 Jan 2011 03:21:17 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.253]) by mx.google.com with ESMTPS id 21sm4718521fav.17.2011.01.03.03.21.15 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 03:21:16 -0800 (PST) Sender: Alexander Motin Message-ID: <4D21B126.1020207@FreeBSD.org> Date: Mon, 03 Jan 2011 13:21:10 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Matthew D. Fuller" References: <20110103102853.GA89454@over-yonder.net> In-Reply-To: <20110103102853.GA89454@over-yonder.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Oddities in -current post-eventtimer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 11:21:19 -0000 On 03.01.2011 12:28, Matthew D. Fuller wrote: > OK, this has happened a couple times now. I'm running a mid-Oct > -CURRENT, and at around 25 days uptime (not exact but consistently in > that vicinity), things start getting very choppy. It's easily visible > in playing videos; things get very jerky and slow, but all sorts of > things start acting like they're happening in little chunks of time; > keyboard repeats get very slow, things that often take notable time > take much more, etc. It's accompanied by a big spat of "calcru: > runtime went backwards" messages (presumably just another symptom). > > The only fix I've found is to reboot, and then it's good for another > 25ish days. As a workaround, enabling kern.eventtimer.idletick sets > things rightish. A look at the interrupts turns up a hint; while > vmstat says the overall average for cpu0 is just under 300/s, systat > -vmstat shows that it's currnetly running around 20-some. The other > CPU's also settle at much lower levels. > > Another more tiring workaround is just slinging the mouse around real > fast; that seems to hint to the system to keep checking stuff. > Watching systat, that doesn't seem to bring the cpuX interrupt rate up > very much, but the videos start playing smoothly. > > FreeBSD 9.0-CURRENT #0 r214107: Wed Oct 20 06:25:50 CDT 2010 > Quad-core running amd64. Symptoms look very alike to ones fixed at r214597 on 2010-10-31: Fix callout_tickstofirst() behavior after signed integer ticks overflow. This should fix callout precision drop to 1/4s after 25 days of uptime with HZ = 1000. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 11:58:15 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E291106566B; Mon, 3 Jan 2011 11:58:15 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 160E48FC13; Mon, 3 Jan 2011 11:58:14 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 3811837B494; Mon, 3 Jan 2011 05:58:14 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 75EDA61C5A; Mon, 3 Jan 2011 05:58:13 -0600 (CST) Date: Mon, 3 Jan 2011 05:58:13 -0600 From: "Matthew D. Fuller" To: Alexander Motin Message-ID: <20110103115813.GB89454@over-yonder.net> References: <20110103102853.GA89454@over-yonder.net> <4D21B126.1020207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D21B126.1020207@FreeBSD.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.96.5 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: Oddities in -current post-eventtimer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 11:58:15 -0000 On Mon, Jan 03, 2011 at 01:21:10PM +0200 I heard the voice of Alexander Motin, and lo! it spake thus: > > Symptoms look very alike to ones fixed at r214597 on 2010-10-31: Shoot, I missed that going by. Sorry for the noise; I guess I've got a good excuse to go upgrade now 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 13:14:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090F2106566C for ; Mon, 3 Jan 2011 13:14:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B42518FC0A for ; Mon, 3 Jan 2011 13:14:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PZkF8-0000E2-IG for freebsd-current@freebsd.org; Mon, 03 Jan 2011 14:14:34 +0100 Received: from cpe-188-129-77-254.dynamic.amis.hr ([188.129.77.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Jan 2011 14:14:34 +0100 Received: from ivoras by cpe-188-129-77-254.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Jan 2011 14:14:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 03 Jan 2011 14:14:23 +0100 Lines: 26 Message-ID: References: <4D1B0E41.40405@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-77-254.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4D1B0E41.40405@gmail.com> Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 13:14:36 -0000 On 12/29/10 11:32, David Demelier wrote: > Hello, > > Sometimes when I use my external harddrive I get these awful message : > > g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5 > /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: > g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5 > /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: > g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5 > /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: > g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5 > /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: > g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5 > /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: > g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error = 5 > /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: > g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error = 5 > /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: > g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 > > I think for a lambda user these are absolutely not understandable. I Would a better message be "WRITE error on da0, offset=34590720. length=65536, errno=5"? From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 13:21:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA6561065670 for ; Mon, 3 Jan 2011 13:21:19 +0000 (UTC) (envelope-from dsc.fbsd.current@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2568FC21 for ; Mon, 3 Jan 2011 13:21:18 +0000 (UTC) Received: by ewy24 with SMTP id 24so6272018ewy.13 for ; Mon, 03 Jan 2011 05:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=ASvMCyOvmUsNFE2SnbOX9Hhfb/PrlbXKZmCzAyD+Jgw=; b=tPi4W4YF9HRSt6kXhIhfS7txIWXo67eGvgWyYKclazCzg0dvsbYE15E/FBNlnVacdG NBPy8WMDus5LGjZ5RTNxw4vEELHuBWYfngX1dRMhBS2f0SdFc0dAKrnfcOLjmZZ09JOK VbF1CkVW8KZkoZmDJFTaCrSJLpR6N/ISsJP4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=UsdIdzqkwFbjiWmcAdI/247LhHpjLFnfhGJTIn62fiBU69jLc1tpPPABKcklUPGBIC lfS/418y0+0Gd+K3hsM1wx2Ipr6un3JS4whryw4dFCt87a1aGtAWQwibFjh32yc6sMEm Kd23BycxQUrNAZd5O7odXoXNDPEPlpVgAJmao= Received: by 10.213.6.193 with SMTP id a1mr1141513eba.63.1294060877960; Mon, 03 Jan 2011 05:21:17 -0800 (PST) Received: from fscld ([94.176.153.23]) by mx.google.com with ESMTPS id x54sm14785439eeh.23.2011.01.03.05.21.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 05:21:17 -0800 (PST) From: "dsc fbsd.current" To: "'J. Hellenthal'" Date: Mon, 3 Jan 2011 15:20:55 +0200 Message-ID: <002301cbab49$10468350$30d389f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcurSA3CDWMqYCv4SJSn/jf6Fe559A== Content-Language: en-us Cc: freebsd-current@freebsd.org Subject: RE: jailing MYSQL error [SOLVED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 13:21:19 -0000 Hello, SOLVED ! But the problem was in another place. Host world and kernel were build with src r215329 (patched with head-v28-v2.patch from Martin Matuska), but ezjail buildworld was made using more recent sources with no patch (in fact I was trying to apply the same patch to more recent sources, but it doesn't work ... but that's another issue). Mysql seems to have problems in this case (kernel and world based on different versions of src). But other stuff work just fine. So, first I've made a jail (standard steps from the handbook) using the same src r215329 (patched for zfs v28). Mysql works fine under this jail. After this step, I've updated the ezjail basejail (ezjail-admin update -i). Now, Mysql works just fine under ezjail too. Thanks for your time and help. Regards, Lulu -----Original Message----- From: J. Hellenthal [mailto:jhellenthal@gmail.com] On Behalf Of J. Hellenthal Sent: Monday, January 03, 2011 12:24 AM To: dsc fbsd.current Cc: freebsd-current@freebsd.org Subject: Re: jailing MYSQL error -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Just to be sure as the long detailed information that you laid before can lead to confusion, lets take this one step at a time. Assuming all your bases are covered and it sinks down to a permissions issue try this: chown root:wheel /path/to/jail/tmp /path/to/jail/var/tmp chmod 1777 /path/to/jail/tmp /path/to/jail/var/tmp rm -rf /path/to/jail/var/db/mysql - -Login to the jail here- make sure that rc.conf* only contains mysql_enable="YES" service mysql-server start ls -ld /var/db/mysql should convey mode 700 or drwx------ and uid/88 gid/88 mysql/mysql At this point your mysql server should be running and fully working. Another thing to make sure you eliminate just in case... would be any my.cnf files in /etc or /usr/local/etc Good luck - -- Regards, jhell,v JJH48-ARIN -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNIPrkAAoJEJBXh4mJ2FR+fLEH/0N91782PKGna/DZNoRF4hWJ 8tTh9bPFaHGjRu2ITC08gFJBLaAK8hE5oh9Tg5k6eysyzjE1EEHXUAJaL6B8Rg+N w5m66OGtvunX8JQqwu8d6ulDLk4EHex7Aaf0G2wfpW2OBDP4oCbeXxaakDJp+dzB GGf4a4ezODgQsr8Hxva71bgesfQ6a1BEirf/pwGcaQs9y1lCgoRK6M+iKDKqruLM Vyp4oNCHX52GTKa/cpx2VveZG/F21RabYtCVrBhU3Xq0EbDeDkiP2JjZt0xNPJVA dnCfCtTRECeruqlFHekH7MayF7uZ5nZIjJ3SEA6xHTCyt3PVC7oxr1NCmaETWJQ= =HFv4 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 13:43:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928E71065670 for ; Mon, 3 Jan 2011 13:43:21 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id DB2808FC12 for ; Mon, 3 Jan 2011 13:43:20 +0000 (UTC) Received: (qmail invoked by alias); 03 Jan 2011 13:16:39 -0000 Received: from p4FE32505.dip.t-dialin.net (EHLO [192.168.0.3]) [79.227.37.5] by mail.gmx.net (mp007) with SMTP; 03 Jan 2011 14:16:39 +0100 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+8fGFSwu68OMypILqZRskInbys02YOpSKDlo5O3U V7DZbMxNiM+ZJ7 Message-ID: <4D21CC35.5060803@gmx.de> Date: Mon, 03 Jan 2011 14:16:37 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Mnenhy/0.8.2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4D1B0E41.40405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 13:43:21 -0000 Am 03.01.2011 14:14, schrieb Ivan Voras: > On 12/29/10 11:32, David Demelier wrote: >> Hello, >> >> Sometimes when I use my external harddrive I get these awful message : >> >> g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5 >> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: >> g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5 >> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: >> g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5 >> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: >> g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5 >> /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: >> g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5 >> /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: >> g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error >> = 5 >> /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: >> g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error >> = 5 >> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: >> g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error >> = 5 >> >> I think for a lambda user these are absolutely not understandable. I > > Would a better message be "WRITE error on da0, offset=34590720. > length=65536, errno=5"? nah, strerror(errno) isn't that much of an effort From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 14:18:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF8A106564A for ; Mon, 3 Jan 2011 14:18:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E40F8FC0C for ; Mon, 3 Jan 2011 14:18:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p03EIUA2028329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 16:18:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p03EIU1o003747; Mon, 3 Jan 2011 16:18:30 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p03EIUCv003746; Mon, 3 Jan 2011 16:18:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 3 Jan 2011 16:18:30 +0200 From: Kostik Belousov To: Matthias Andree Message-ID: <20110103141830.GC3140@deviant.kiev.zoral.com.ua> References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qjNfmADvan18RZcF" Content-Disposition: inline In-Reply-To: <4D21CC35.5060803@gmx.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 14:18:34 -0000 --qjNfmADvan18RZcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: > Am 03.01.2011 14:14, schrieb Ivan Voras: > > On 12/29/10 11:32, David Demelier wrote: > >> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: > >> g_vfs_done():ufs/public[READ(offset=3D232718991360, length=3D131072)]e= rror > >> =3D 5 > >> > >> I think for a lambda user these are absolutely not understandable. I > >=20 > > Would a better message be "WRITE error on da0, offset=3D34590720. > > length=3D65536, errno=3D5"? >=20 > nah, strerror(errno) isn't that much of an effort In kernel ? There is no strerror, and there is no great need to import the sys_errlist. --qjNfmADvan18RZcF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0h2rUACgkQC3+MBN1Mb4gWaQCg9cqqoZpu742uty4LiJial7T2 g1IAn2kWeUollTDDb7d7xZDyUv7hWGjg =Hn1z -----END PGP SIGNATURE----- --qjNfmADvan18RZcF-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 15:36:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3EB106566B for ; Mon, 3 Jan 2011 15:36:42 +0000 (UTC) (envelope-from hasegaw@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5959E8FC08 for ; Mon, 3 Jan 2011 15:36:42 +0000 (UTC) Received: by gxk8 with SMTP id 8so5625362gxk.13 for ; Mon, 03 Jan 2011 07:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=yjusnV8O1I68LHYW3jtCuWX7a93wobByf32+8D2/tZ4=; b=ABw4sYM8Bc10T0spt2HNbbo++HpWSTWzV/Zn0YuDVNRaO10oJzYdDB1gSi9EcZQjHo RHhkxkKh0vuA3E5FlFi7P3+WtzhtL3jGs/k/5pqqwcUXmudtxnD/hVa3NIk8fPkLK+/J 5S1FBSeiZ4c4Pgz4gWWFSXw3wajaaEOB0mJgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=WhDaPIL063lN19o82ZlQwEdWu0wmhr1b5FxLk4QPkkswc+3cx3XGtcKHz6Mo04zNbh JcqgB1njaus1Urm6PT2qHL0QZ4GC6M/t8tUZRm+0JTFl3ESWFhzIKp761DBTAYUf4hRs qtM96q1lHYy1mSNIR7HpOSQzVLZz2WCPRujYw= MIME-Version: 1.0 Received: by 10.90.32.19 with SMTP id f19mr12587969agf.138.1294067461184; Mon, 03 Jan 2011 07:11:01 -0800 (PST) Received: by 10.91.147.11 with HTTP; Mon, 3 Jan 2011 07:11:01 -0800 (PST) Date: Tue, 4 Jan 2011 00:11:01 +0900 Message-ID: From: Takeshi HASEGAWA To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: wakatono@todo.gr.jp, soda@netbsd.org, rusty@au.ibm.com, Takeshi HASEGAWA , ito@virtualtech.jp, aliguori@us.ibm.com Subject: Another virtio drivers for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:36:42 -0000 Hi freebsd-current, I noticed there are some threads about virtio drivers for FreeBSD and NetBSD on this mailing list, so I would like to post my virtio drivers. I've worked on these drivers for a few months to understand para-virtalized drivers. I sent early versions to Rusty Russel, the author of virtio, since I attended to Rusty's virtio session at LinuxCon 2010 Tokyo and decided to work on it. My virtio-net & virtio-blk driver is not complete just now, but it looks working fine. I confirmed these drivers working with FreeBSD 8.1-R on Fedora 14 KVM. Both driver can deliver better performance than h/w emulation. http://ysr.jp/~hasegaw/virtio-20110103-2316.tar.gz I'm sorry for very nasty code; I am newbie in both of C and kernel-space code. ;) Now I am suffering with performance problem with virtio-blk driver. I've heard some people said FreeBSD's disk I/O on KVM is very poor so I have implemented block I/O, but the paravirtual driver's performance is still very bad - "almost same" with SCSI emulation, expecting CPU stress. http://ysr.jp/~hasegaw/20101203virtio-blk5.txt Now I am doubting FreeBSD and qemu-kvm's storage layer may not be compatible so well. Anyone is examining about this? I especially thank to Noriyuki Soda because he gave me a lot of advices when I was suffering with usage of bus_dma framework and some other issues. For NetBSD, it looks Makoto Minoura has already ported virtio drivers. (I'm not sure these are already commited to main tree or not) http://www.minoura.org/~minoura/virtio-100605/ -- Takeshi HASEGAWA From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 16:56:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163AB106564A for ; Mon, 3 Jan 2011 16:56:37 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1CB8FC17 for ; Mon, 3 Jan 2011 16:56:36 +0000 (UTC) Received: by bwz12 with SMTP id 12so6476129bwz.13 for ; Mon, 03 Jan 2011 08:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=CZyzOtjuUrJq1hILFaxj4wmZ59ITQQHpGe+1+ihlWvk=; b=Z0nJ4e6WsV1kvRdH8YGO1sIVbXRKvtV+l86W7VmoaoKRqOfiozkppuoigLSMI/2DkQ tLlVi6t8E1l0i4qymODtLraGinnqe/44Ga5xW8ecxKqpAmVvDzxb1VTau+hxkJ2Btd01 55zbl6gVl/sKQAYyXTosIMUHx0tcntxqq6gHI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=RgOPVchgatxvp7l4ohakKfBETtIXS4fDqaqCkuWZY+ufbhyr2mCb4e1BEvPXutIXd7 aCGQq1GzyQIr7RlP+m+bKVR1lLV37oMqw8LvC/bcTIk+G70bG6ycPYBuO/L+XSWt+2MN If46XBzH9YbRfExmJ0gYBgAD2KNAODls6N6OM= Received: by 10.204.60.195 with SMTP id q3mr2928435bkh.188.1294072398847; Mon, 03 Jan 2011 08:33:18 -0800 (PST) Received: from [192.168.2.4] (gate19.robnet.pl [194.105.132.219]) by mx.google.com with ESMTPS id x38sm10292075bkj.13.2011.01.03.08.33.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 08:33:17 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20110103141830.GC3140@deviant.kiev.zoral.com.ua> Date: Mon, 3 Jan 2011 17:33:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1082) Cc: Matthias Andree , freebsd-current@freebsd.org Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:56:37 -0000 Wiadomo=B6=E6 napisana przez Kostik Belousov w dniu 2011-01-03, o godz. = 15:18: > On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: >> Am 03.01.2011 14:14, schrieb Ivan Voras: >>> On 12/29/10 11:32, David Demelier wrote: >>>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: >>>> g_vfs_done():ufs/public[READ(offset=3D232718991360, = length=3D131072)]error >>>> =3D 5 >>>>=20 >>>> I think for a lambda user these are absolutely not understandable. = I >>>=20 >>> Would a better message be "WRITE error on da0, offset=3D34590720. >>> length=3D65536, errno=3D5"? >>=20 >> nah, strerror(errno) isn't that much of an effort > In kernel ? There is no strerror, and there is no great need to import = the > sys_errlist. I had code that adds strerror() to the kernel in one of my old p4 = branches. Error messages like the one above look much better this way, but I = didn't have time to push it into the tree, and there is a risk of yet another = i18n discussion. If someone is interested - let me know; I'll try to find = it. -- If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 17:55:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D8A1106566B; Mon, 3 Jan 2011 17:55:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F37898FC12; Mon, 3 Jan 2011 17:55:43 +0000 (UTC) Received: by yxh35 with SMTP id 35so5799677yxh.13 for ; Mon, 03 Jan 2011 09:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=YIN61CkhhF8g/wnh6gKownGUdjYAQkeevuZvTei6vTU=; b=oLnMFFAiWFP+/ASKVCdITWeEw+A8PF3bywtU0/ejDZ29df1xhebz88ib8OoKIktT8m tZduQrEFBHQalGA9g6GIZ+Ohpb8NgAETMJpbIPqqrWRw6rRRhgE8l6rpn03BuOUePj+w ELBS1+KGISAMlyMR5AQgyc+VIeXCy7DEVcKN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=QluNZ6z+o7L54gwVNx9PxOBR3eKM2SezXc9xDywthpMvKn50hYggI1E24GVpD2WGAU CJA2khmGW0hUReIQ27s3siyORg6tlt1KMGN8kFtgKG+kwgTmB/aWwLWCUayD2B/gPAWV FcqdL/zF0h796ARe0EBCSF703rIwA7UFusOMY= Received: by 10.236.111.39 with SMTP id v27mr26895239yhg.20.1294077343223; Mon, 03 Jan 2011 09:55:43 -0800 (PST) Received: from [192.168.20.8] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id n67sm12443212yha.26.2011.01.03.09.55.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 09:55:41 -0800 (PST) References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> In-Reply-To: <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8C148) From: Garrett Cooper Date: Mon, 3 Jan 2011 09:55:30 -0800 To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: Kostik Belousov , Matthias Andree , "freebsd-current@freebsd.org" Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:55:44 -0000 On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napiera=C5=82a = wrote: > Wiadomo=C5=9B=C4=87 napisana przez Kostik Belousov w dniu 2011-01-03, o go= dz. 15:18: >> On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: >>> Am 03.01.2011 14:14, schrieb Ivan Voras: >>>> On 12/29/10 11:32, David Demelier wrote: >>>>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: >>>>> g_vfs_done():ufs/public[READ(offset=3D232718991360, length=3D131072)]e= rror >>>>> =3D 5 >>>>>=20 >>>>> I think for a lambda user these are absolutely not understandable. I >>>>=20 >>>> Would a better message be "WRITE error on da0, offset=3D34590720. >>>> length=3D65536, errno=3D5"? >>>=20 >>> nah, strerror(errno) isn't that much of an effort >> In kernel ? There is no strerror, and there is no great need to import th= e >> sys_errlist. >=20 > I had code that adds strerror() to the kernel in one of my old p4 branches= . > Error messages like the one above look much better this way, but I didn't > have time to push it into the tree, and there is a risk of yet another i18= n > discussion. If someone is interested - let me know; I'll try to find it. Some thoughts: - It's a pain to parse (before I just had to scan for an int -- now it's a s= tring?!?) - It slows down printing (slow kernel -> dog slow system). - Fills up logs quicker if a subsystem or piece of hardware is going south a= nd these messages slam syslog, which means I have to scan more logs looking f= or useful data, the likelihood of messages being lost in various buffers is h= igher, etc. Why not just provide a more standard sensical printout for the messages and p= rovide a secret decoder ring in userland or something for interested parties= the don't know that error is an errno value (eg my mom and dad because they= 're unix illiterate), or just copyout all of the error data via an ioctl, pr= int out the ioctl failures, and skip the kernel level printing altogether? Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 18:22:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF24106566C; Mon, 3 Jan 2011 18:22:05 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DEE748FC0C; Mon, 3 Jan 2011 18:22:04 +0000 (UTC) Received: by wwf26 with SMTP id 26so13403675wwf.31 for ; Mon, 03 Jan 2011 10:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=jDvdq+rSNFZy4kTP48qt6eRE5GD7BODEPRNGQUt027s=; b=KyDI5WaBSi8uIehtTfzMBIx/VARym1zQTi+UqzE8pm4fyp2j6i5KUJlksozO4auyA3 19mAvIe/zGa8sgtwv4a2zc1GtF1+Vr0yUZfKFC3fR7TrbAsfZEbZCiG4yeOtXsFA/XgE nwZDK0YDfid2loGzQQY/RSOQipK3g903+LYnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=IG52ozu57Zd21y18hf0orVb0ng2C7xX2rfggddvzQ5mPGuXPFpVhbBnFHij1k7RB0u ASaaAX058fmxSHPoc0SMYSPMG+HOnqkKst3MY8RvuXgAc4UdFLoMw/ocHawrB2495fWw zIWnBv4syukqAaRV+/kK0Y8ZMd6gJGwZL3WaU= Received: by 10.216.1.149 with SMTP id 21mr24371039wed.10.1294078923940; Mon, 03 Jan 2011 10:22:03 -0800 (PST) Received: from localhost (server51262.uk2net.com [83.170.92.9]) by mx.google.com with ESMTPS id t5sm10024306wes.9.2011.01.03.10.22.01 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 10:22:03 -0800 (PST) From: Anonymous To: Garrett Cooper References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> Date: Mon, 03 Jan 2011 21:20:42 +0300 In-Reply-To: (Garrett Cooper's message of "Mon, 3 Jan 2011 09:55:30 -0800") Message-ID: <86vd256e85.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Belousov , Kostik, Matthias Andree , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , "freebsd-current@freebsd.org" Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:22:06 -0000 Garrett Cooper writes: > On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napiera=C5=82a wrote: > >> Wiadomo=C5=9B=C4=87 napisana przez Kostik Belousov w dniu 2011-01-03, o = godz. 15:18: >>> On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: >>>> Am 03.01.2011 14:14, schrieb Ivan Voras: >>>>> On 12/29/10 11:32, David Demelier wrote: >>>>>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: >>>>>> g_vfs_done():ufs/public[READ(offset=3D232718991360, length=3D131072)= ]error >>>>>> =3D 5 >>>>>>=20 >>>>>> I think for a lambda user these are absolutely not understandable. I >>>>>=20 >>>>> Would a better message be "WRITE error on da0, offset=3D34590720. >>>>> length=3D65536, errno=3D5"? >>>>=20 >>>> nah, strerror(errno) isn't that much of an effort >>> In kernel ? There is no strerror, and there is no great need to import = the >>> sys_errlist. >>=20 >> I had code that adds strerror() to the kernel in one of my old p4 branch= es. >> Error messages like the one above look much better this way, but I didn't >> have time to push it into the tree, and there is a risk of yet another i= 18n >> discussion. If someone is interested - let me know; I'll try to find it. > > Some thoughts: > - It's a pain to parse (before I just had to scan for an int -- now it's = a string?!?) > - It slows down printing (slow kernel -> dog slow system). > - Fills up logs quicker if a subsystem or piece of hardware is going > south and these messages slam syslog, which means I have to scan more > logs looking for useful data, the likelihood of messages being lost in > various buffers is higher, etc. > > Why not just provide a more standard sensical printout for the > messages and provide a secret decoder ring in userland or something Do you mean perror(1)? $ perror 5 Input/output error > for interested parties the don't know that error is an errno value (eg > my mom and dad because they're unix illiterate), or just copyout all > of the error data via an ioctl, print out the ioctl failures, and skip > the kernel level printing altogether? From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 18:41:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 451DE106564A; Mon, 3 Jan 2011 18:41:46 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B29C58FC1D; Mon, 3 Jan 2011 18:41:45 +0000 (UTC) Received: by iwn39 with SMTP id 39so13893492iwn.13 for ; Mon, 03 Jan 2011 10:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=o6BmPgEgGx/6JqLrc0VB64uLBrOV7se0HtyX4vcSIXU=; b=WbxM7LpdqfGqGJ65exK5KiYX0GXToDYd6LjrZa5dfpejuiFFLBJNFn//ZSgh8m1Ojk DeQrQ162vEKiWXbDViZGQq/jkg4WzC/FMkLHBGXrNstQB0N0bi4Bzznfa8kPaqSjlKRO lc2BF6yLrMj30Li4DYQX7hMv6dGvaTi73/yho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SzE0Bn/XeIm+G61GOYPS6z7tYCtbCyhzyITuB8ovMDUWjZKNQtuPOe01Djb5Pze9S1 rBPKkkIIbXL2I/QHck53njRNzgWbiMNrdqGzVZkDppspINS93ZQ3i3o76P529+ao4LXS VsL9FD9/w6ouSxTGxFYVCClRwSHwEh96YxAE8= Received: by 10.42.179.66 with SMTP id bp2mr15172230icb.81.1294080105162; Mon, 03 Jan 2011 10:41:45 -0800 (PST) Received: from [192.168.20.5] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id ca7sm10723350icb.0.2011.01.03.10.41.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 10:41:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Garrett Cooper In-Reply-To: <86vd256e85.fsf@gmail.com> Date: Mon, 3 Jan 2011 10:41:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00F09384-B3B3-44D2-9C93-029ED7BBB4EE@gmail.com> References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> <86vd256e85.fsf@gmail.com> To: Anonymous X-Mailer: Apple Mail (2.1082) Cc: Kostik Belousov , Matthias Andree , =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= , "freebsd-current@freebsd.org" Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:41:46 -0000 On Jan 3, 2011, at 10:20 AM, Anonymous wrote: > Garrett Cooper writes: >=20 >> On Jan 3, 2011, at 8:33 AM, Edward Tomasz Napiera=C5=82a = wrote: >>=20 >>> Wiadomo=C5=9B=C4=87 napisana przez Kostik Belousov w dniu = 2011-01-03, o godz. 15:18: >>>> On Mon, Jan 03, 2011 at 02:16:37PM +0100, Matthias Andree wrote: >>>>> Am 03.01.2011 14:14, schrieb Ivan Voras: >>>>>> On 12/29/10 11:32, David Demelier wrote: >>>>>>> /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: >>>>>>> g_vfs_done():ufs/public[READ(offset=3D232718991360, = length=3D131072)]error >>>>>>> =3D 5 >>>>>>>=20 >>>>>>> I think for a lambda user these are absolutely not = understandable. I >>>>>>=20 >>>>>> Would a better message be "WRITE error on da0, offset=3D34590720. >>>>>> length=3D65536, errno=3D5"? >>>>>=20 >>>>> nah, strerror(errno) isn't that much of an effort >>>> In kernel ? There is no strerror, and there is no great need to = import the >>>> sys_errlist. >>>=20 >>> I had code that adds strerror() to the kernel in one of my old p4 = branches. >>> Error messages like the one above look much better this way, but I = didn't >>> have time to push it into the tree, and there is a risk of yet = another i18n >>> discussion. If someone is interested - let me know; I'll try to = find it. >>=20 >> Some thoughts: >> - It's a pain to parse (before I just had to scan for an int -- now = it's a string?!?) >> - It slows down printing (slow kernel -> dog slow system). >> - Fills up logs quicker if a subsystem or piece of hardware is going >> south and these messages slam syslog, which means I have to scan more >> logs looking for useful data, the likelihood of messages being lost = in >> various buffers is higher, etc. >>=20 >> Why not just provide a more standard sensical printout for the >> messages and provide a secret decoder ring in userland or something >=20 > Do you mean perror(1)? >=20 > $ perror 5 > Input/output error Heh -- didn't realize that someone made a userland app for that libcall = already :D... You learn new things everyday I guess :). In that case IMO nothing needs to be done minus (if you're interested) = creating a parser that data mines stuff to make it more human readable = in a common format, i.e. error: 5 (Input/output error) that would make life when reporting PRs or issues on the list a lot more = uniform and easier to follow, and could apply to several utilities = (atacontrol, camcontrol, etc). My company has a similar in-house tool = that does that, but it's not necessarily the easiest tool to deal with = nor the most correct when it comes to some issues in FreeBSD. >> for interested parties the don't know that error is an errno value = (eg >> my mom and dad because they're unix illiterate), or just copyout all >> of the error data via an ioctl, print out the ioctl failures, and = skip >> the kernel level printing altogether? Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 19:11:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 265AC1065696 for ; Mon, 3 Jan 2011 19:11:17 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0C69B8FC15 for ; Mon, 3 Jan 2011 19:11:16 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 4AA005B30; Mon, 3 Jan 2011 11:02:45 -0800 (PST) To: Anonymous In-reply-to: Your message of "Mon, 03 Jan 2011 21:20:42 +0300." <86vd256e85.fsf@gmail.com> References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> <86vd256e85.fsf@gmail.com> Comments: In-reply-to Anonymous message dated "Mon, 03 Jan 2011 21:20:42 +0300." Date: Mon, 03 Jan 2011 11:02:45 -0800 From: Bakul Shah Message-Id: <20110103190245.4AA005B30@mail.bitblocks.com> Cc: freebsd-current@freebsd.org Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:11:17 -0000 On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous wrote: > > Do you mean perror(1)? > > $ perror 5 > Input/output error I prefer mine: $ errno () { grep "^#.*\\<$*\\>" /usr/include/sys/errno.h } $ errno 5 #define EIO 5 /* Input/output error */ $ errno EIO #define EIO 5 /* Input/output error */ From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 19:23:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10A36106564A for ; Mon, 3 Jan 2011 19:23:39 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A59F8FC12 for ; Mon, 3 Jan 2011 19:23:38 +0000 (UTC) Received: by fxm16 with SMTP id 16so13323657fxm.13 for ; Mon, 03 Jan 2011 11:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=qyMBoiFPfbB4WrY733RI8LmkUJ+4aDvV1lBSTvghvoo=; b=NhjWKEPfH0cu6z7T7Fz1mTZOFmK157OPQzfFV+hCRnhalb54hzMj83GIOzwrx8wkn5 NoP3tV1qSOxzLnXwCH15AxKXRZ4cUefFuw8qss/YK+I2seo82U7D1+iHHkcWWhXSo2cb hLRpC/k54JaM2pLQWQIisnz+qztQggFiddEbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=Crj5ewRZNSUP8VAtW/Ru9MGlTrPbgioiY8yya2a0l4Gyg5f1ydyo9WroY6A0KeltJU m7WGcbt/sS4qHhOQ4a2cSVNLdO0w6QpMtkD7wS5xDq1SckiEInh724/Wy9ABI6ApIG50 lFv2n2YBoo2j9wa0Y9PtubfT/AxIGC84JoxC0= Received: by 10.223.95.203 with SMTP id e11mr3264021fan.60.1294082617472; Mon, 03 Jan 2011 11:23:37 -0800 (PST) Received: from localhost ([87.236.194.191]) by mx.google.com with ESMTPS id n3sm4864669fax.31.2011.01.03.11.23.27 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 11:23:36 -0800 (PST) From: Anonymous To: Bakul Shah References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> <86vd256e85.fsf@gmail.com> <20110103190245.4AA005B30@mail.bitblocks.com> Date: Mon, 03 Jan 2011 22:21:51 +0300 In-Reply-To: <20110103190245.4AA005B30@mail.bitblocks.com> (Bakul Shah's message of "Mon, 03 Jan 2011 11:02:45 -0800") Message-ID: <8639p923ow.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:23:39 -0000 Bakul Shah writes: > On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous wrote: >>=20 >> Do you mean perror(1)? >>=20 >> $ perror 5 >> Input/output error > > I prefer mine: > > $ errno () { grep "^#.*\\<$*\\>" /usr/include/sys/errno.h } > $ errno 5 > #define EIO 5 /* Input/output error */ > $ errno EIO > #define EIO 5 /* Input/output error */ perror(1) displays localized messages $ LANG=3Dja_JP.UTF-8 perror 5 =E5=85=A5=E5=87=BA=E5=8A=9B=E3=82=A8=E3=83=A9=E3=83=BC=E3=81=A7=E3=81=99 $ LANG=3Duk_UA.UTF-8 perror 5 =D0=9F=D0=BE=D0=BC=D0=B8=D0=BB=D0=BA=D0=B0 =D0=B2=D0=B2=D0=BE=D0=B4=D1=83= -=D0=B2=D0=B8=D0=B2=D0=BE=D0=B4=D1=83 but I have to agree that knowing errno macro is useful From owner-freebsd-current@FreeBSD.ORG Mon Jan 3 20:01:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0022B106566C for ; Mon, 3 Jan 2011 20:01:16 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id D500B8FC12 for ; Mon, 3 Jan 2011 20:01:16 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id F2FCA5B30; Mon, 3 Jan 2011 11:53:50 -0800 (PST) To: Anonymous In-reply-to: Your message of "Mon, 03 Jan 2011 22:21:51 +0300." <8639p923ow.fsf@gmail.com> References: <4D1B0E41.40405@gmail.com> <4D21CC35.5060803@gmx.de> <20110103141830.GC3140@deviant.kiev.zoral.com.ua> <47B52F19-AB6B-4116-9F5E-219B26519115@FreeBSD.org> <86vd256e85.fsf@gmail.com> <20110103190245.4AA005B30@mail.bitblocks.com> <8639p923ow.fsf@gmail.com> Comments: In-reply-to Anonymous message dated "Mon, 03 Jan 2011 22:21:51 +0300." Date: Mon, 03 Jan 2011 11:53:50 -0800 From: Bakul Shah Message-Id: <20110103195350.F2FCA5B30@mail.bitblocks.com> Cc: freebsd-current@freebsd.org Subject: Re: No human readable message with g_vfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:01:17 -0000 On Mon, 03 Jan 2011 22:21:51 +0300 Anonymous wrote: > Bakul Shah writes: > > > On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous wrote: > >>=20 > >> Do you mean perror(1)? > >>=20 > >> $ perror 5 > >> Input/output error > > > > I prefer mine: > > > > $ errno () { grep "^#.*\\<$*\\>" /usr/include/sys/errno.h } > > $ errno 5 > > #define EIO 5 /* Input/output error */ > > $ errno EIO > > #define EIO 5 /* Input/output error */ > > perror(1) displays localized messages > > $ LANG=3Dja_JP.UTF-8 perror 5 > =E5=85=A5=E5=87=BA=E5=8A=9B=E3=82=A8=E3=83=A9=E3=83=BC=E3=81=A7=E3=81=99 > > $ LANG=3Duk_UA.UTF-8 perror 5 > =D0=9F=D0=BE=D0=BC=D0=B8=D0=BB=D0=BA=D0=B0 =D0=B2=D0=B2=D0=BE=D0=B4=D1=83= > -=D0=B2=D0=B8=D0=B2=D0=BE=D0=B4=D1=83 Yes, definitely useful. Perhaps strerror would be a better name? > but I have to agree that knowing errno macro is useful And you can use grep tricks :-) $ errno '[dD]evice' #define ENXIO 6 /* Device not configured */ #define ENOTBLK 15 /* Block device required */ #define EBUSY 16 /* Device busy */ #define EXDEV 18 /* Cross-device link */ #define ENODEV 19 /* Operation not supported by device */ #define ENOTTY 25 /* Inappropriate ioctl for device */ #define ENOSPC 28 /* No space left on device */ From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 06:36:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87633106564A for ; Tue, 4 Jan 2011 06:36:22 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 475A58FC1B for ; Tue, 4 Jan 2011 06:36:22 +0000 (UTC) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id B85658B143C for ; Tue, 4 Jan 2011 07:19:06 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=0.035, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id xn77Kd0uvvmw for ; Tue, 4 Jan 2011 07:19:04 +0100 (CET) Received: from [192.168.100.35] (p54B0DD94.dip.t-dialin.net [84.176.221.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id DB9328B143B for ; Tue, 4 Jan 2011 07:19:03 +0100 (CET) Message-ID: <4D22BB75.3000703@executive-computing.de> Date: Tue, 04 Jan 2011 07:17:25 +0100 From: Marco Steinbach User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: AMD X2/Opteron Rev E workaround ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 06:36:22 -0000 Hi, it's been a while since this topic was touched, see http://lists.freebsd.org/pipermail/freebsd-current/2009-November/013129.html. I coulnd't find anything more recent than the following commit, which prints a warning message, if a suspectible CPU model is detected: http://svn.freebsd.org/viewvc/base?view=revision&revision=198868 If someone has any patches, even very preliminary ones, I'd be more than happy to give them a thorough try on otherwise unused machines. MfG CoCo From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 13:30:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 988C61065674; Tue, 4 Jan 2011 13:30:45 +0000 (UTC) (envelope-from dbaio@bsd.com.br) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47EFA8FC0A; Tue, 4 Jan 2011 13:30:44 +0000 (UTC) Received: by ywp6 with SMTP id 6so6103420ywp.13 for ; Tue, 04 Jan 2011 05:30:44 -0800 (PST) Received: by 10.90.49.12 with SMTP id w12mr283084agw.63.1294146402080; Tue, 04 Jan 2011 05:06:42 -0800 (PST) Received: from dbaionb.localdomain.com ([200.140.196.107]) by mx.google.com with ESMTPS id f10sm29496178anh.5.2011.01.04.05.06.38 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 05:06:41 -0800 (PST) Received: by dbaionb.localdomain.com (sSMTP sendmail emulation); Tue, 04 Jan 2011 11:06:25 -0200 From: "Danilo G. Baio" Date: Tue, 4 Jan 2011 11:06:25 -0200 To: freebsd-current@freebsd.org Message-ID: <20110104130541.GA1377@warlock.localdomain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: mfiutil and raid level X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 13:30:45 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi guys, mfiutil don't show raid level right with Perc H700. Before to post i've read all /usr/src/usr.sbin/mfiutil and sorry, i dont have the knowledge for that. :( noname# mfiutil show adapter mfi0 Adapter: Product Name: PERC H700 Integrated Serial Number: 0B202SK Firmware: 12.10.0-0025 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8K Maximum Stripe: 1M With DEBUG noname# mfiutil show adapter mfi0 Adapter: Product Name: PERC H700 Integrated Serial Number: 0B202SK Firmware: 12.10.0-0025 RAID Levels: (0xcf7) JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8K Maximum Stripe: 1M noname# mfiutil show config mfi0 Configuration: 3 arrays, 2 volumes, 0 spares array 0 of 2 drives: drive 4 ( 466G) ONLINE SAS enclosure 1, slot 4 drive 5 ( 466G) ONLINE SAS enclosure 1, slot 5 array 1 of 2 drives: drive 0 ( 137G) ONLINE SAS enclosure 1, slot 0 drive 1 ( 137G) ONLINE SAS enclosure 1, slot 1 array 2 of 2 drives: drive 2 ( 137G) ONLINE SAS enclosure 1, slot 2 drive 3 ( 137G) ONLINE SAS enclosure 1, slot 3 volume mfid0 (465G) RAID-1 64K OPTIMAL spans: array 0 volume mfid1 (272G) RAID-1 64K OPTIMAL spans: array 1 array 2 noname# mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled mfid1 ( 272G) RAID-1 64K OPTIMAL Disabled noname# The mfid1 is raid-10. Just for confirm, see the bios screen raid 10: http://img718.imageshack.us/img718/2752/dellr510h700.jpg I am running 8.1-RELEASE If can i help and something, just ask. Regards. --=20 Danilo G. Baio (dbaio) --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EAREIAAYFAk0jG1AACgkQXWqInMUxNiHSxAD/ScpYbwciao2liEz7twHzlBrg O4t3wffVz43xUGyKf2wA/0HHwJuLEIp6N2byn8e6gtZoxZ1nps2nqYVG5sttl8hT =MyYT -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 13:57:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F7CB106566C; Tue, 4 Jan 2011 13:57:24 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id D8F6D8FC17; Tue, 4 Jan 2011 13:57:23 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Pa7O5-000LNN-OI; Tue, 04 Jan 2011 13:57:21 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pa7O5-0008rH-NQ; Tue, 04 Jan 2011 13:57:21 +0000 Date: Tue, 04 Jan 2011 13:57:21 +0000 Message-Id: To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, luke-lists@hybrid-logic.co.uk In-Reply-To: <1293726772.5853.1348.camel@pow> From: Pete French X-Mailman-Approved-At: Tue, 04 Jan 2011 13:58:51 +0000 Cc: Subject: Re: Virtio drivers for FreeBSD on KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 13:57:24 -0000 > With more cloud infrastructure providers using KVM than ever before, the > importance of having FreeBSD performant as a guest on these > infrastructures [1], [2], [3] is increasing. It seems that using Virtio > drivers give a pretty significant performance boost [4], [5]. > > There was a NetBSD driver, and there seems to (have been) some work > happening to port this to DragonFly BSD at [6] and [7] -- does anyone > know if this code is stable, or if it has stalled, or if anyone's > working on it? Are the virtio devices provided by Linux KVM the same as those provided by VirtualBox ? Certainly their website says that the networking one is. How about giving the drivers provided by /usr/ports/emulators/virtualbox-ose-additions a try and see if they will work with KVM ? -pete. From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 13:58:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911031065672; Tue, 4 Jan 2011 13:58:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 58BEC8FC13; Tue, 4 Jan 2011 13:58:06 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Pa7On-000LSj-Ny; Tue, 04 Jan 2011 13:58:05 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pa7On-0008rK-N6; Tue, 04 Jan 2011 13:58:05 +0000 Date: Tue, 04 Jan 2011 13:58:05 +0000 Message-Id: To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, luke-lists@hybrid-logic.co.uk In-Reply-To: <1293726772.5853.1348.camel@pow> From: Pete French X-Mailman-Approved-At: Tue, 04 Jan 2011 13:59:19 +0000 Cc: Subject: Re: Virtio drivers for FreeBSD on KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 13:58:06 -0000 Actually, it does look like virtio is more than just for networking... http://vbox.innotek.de/pipermail/vbox-dev/2009-November/002053.html From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 15:12:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459BA106566C for ; Tue, 4 Jan 2011 15:12:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1854E8FC14 for ; Tue, 4 Jan 2011 15:12:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A937446B39; Tue, 4 Jan 2011 10:12:07 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C62008A009; Tue, 4 Jan 2011 10:12:06 -0500 (EST) From: John Baldwin To: "Danilo G. Baio" Date: Tue, 4 Jan 2011 10:05:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110104130541.GA1377@warlock.localdomain.com> In-Reply-To: <20110104130541.GA1377@warlock.localdomain.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101041005.43095.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 04 Jan 2011 10:12:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: mfiutil and raid level X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 15:12:08 -0000 On Tuesday, January 04, 2011 8:06:25 am Danilo G. Baio wrote: > Hi guys, > > mfiutil don't show raid level right with Perc H700. > Before to post i've read all /usr/src/usr.sbin/mfiutil > and sorry, i dont have the knowledge for that. :( Can you get the output of 'mfiutil show debug' when compiled with DEBUG? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 15:26:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26797106564A; Tue, 4 Jan 2011 15:26:29 +0000 (UTC) (envelope-from dbaio@bsd.com.br) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBB518FC1E; Tue, 4 Jan 2011 15:26:28 +0000 (UTC) Received: by gwj21 with SMTP id 21so7022925gwj.13 for ; Tue, 04 Jan 2011 07:26:28 -0800 (PST) Received: by 10.100.226.6 with SMTP id y6mr13048333ang.131.1294154787985; Tue, 04 Jan 2011 07:26:27 -0800 (PST) Received: from [192.168.6.125] ([201.86.94.44]) by mx.google.com with ESMTPS id 17sm13840313anx.13.2011.01.04.07.26.26 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 07:26:27 -0800 (PST) Message-ID: <4D233C1A.3000400@bsd.com.br> Date: Tue, 04 Jan 2011 13:26:18 -0200 From: "Danilo G. Baio" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: jhb@freebsd.org References: <20110104130541.GA1377@warlock.localdomain.com> <201101041005.43095.jhb@freebsd.org> In-Reply-To: <201101041005.43095.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: mfiutil and raid level X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 15:26:29 -0000 Em 04/01/2011 13:05, John Baldwin escreveu: > On Tuesday, January 04, 2011 8:06:25 am Danilo G. Baio wrote: >> Hi guys, >> >> mfiutil don't show raid level right with Perc H700. >> Before to post i've read all /usr/src/usr.sbin/mfiutil >> and sorry, i dont have the knowledge for that. :( > > Can you get the output of 'mfiutil show debug' when compiled with DEBUG? > Sorry... i forgot to post. noname# ./mfiutil debug mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares array size: 288 volume size: 256 spare size: 40 array 0 of 2 drives: size = 975699968 drive 4 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 drive 5 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 array 1 of 2 drives: size = 285474816 drive 0 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 1 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 array 2 of 2 drives: size = 285474816 drive 2 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 3 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 volume mfid0 RAID-1 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 0 @ 0 : 975699968 volume mfid1 RAID-1 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 1 @ 0 : 285474816 array 2 @ 0 : 285474816 noname# I used this patch to compile with debug: http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101004/52f0782c/fix-mfiutil-debug.obj -- Danilo G. Baio (dbaio) From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 16:44:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA439106566B for ; Tue, 4 Jan 2011 16:44:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2D08FC20 for ; Tue, 4 Jan 2011 16:44:32 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 48B8046B5B; Tue, 4 Jan 2011 11:44:32 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 563E88A01D; Tue, 4 Jan 2011 11:44:31 -0500 (EST) From: John Baldwin To: "Danilo G. Baio" Date: Tue, 4 Jan 2011 11:37:59 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110104130541.GA1377@warlock.localdomain.com> <201101041005.43095.jhb@freebsd.org> <4D233C1A.3000400@bsd.com.br> In-Reply-To: <4D233C1A.3000400@bsd.com.br> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101041137.59865.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 04 Jan 2011 11:44:31 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: mfiutil and raid level X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:44:32 -0000 On Tuesday, January 04, 2011 10:26:18 am Danilo G. Baio wrote: > Em 04/01/2011 13:05, John Baldwin escreveu: > > On Tuesday, January 04, 2011 8:06:25 am Danilo G. Baio wrote: > >> Hi guys, > >> > >> mfiutil don't show raid level right with Perc H700. > >> Before to post i've read all /usr/src/usr.sbin/mfiutil > >> and sorry, i dont have the knowledge for that. :( > > > > Can you get the output of 'mfiutil show debug' when compiled with DEBUG? > > > > Sorry... i forgot to post. > > noname# ./mfiutil debug > mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares > array size: 288 > volume size: 256 > spare size: 40 > array 0 of 2 drives: > size = 975699968 > drive 4 ONLINE > raw size: 976773168 > non-coerced size: 975724592 > coerced size: 975699968 > drive 5 ONLINE > raw size: 976773168 > non-coerced size: 975724592 > coerced size: 975699968 > array 1 of 2 drives: > size = 285474816 > drive 0 ONLINE > raw size: 286749480 > non-coerced size: 285700904 > coerced size: 285474816 > drive 1 ONLINE > raw size: 286749480 > non-coerced size: 285700904 > coerced size: 285474816 > array 2 of 2 drives: > size = 285474816 > drive 2 ONLINE > raw size: 286749480 > non-coerced size: 285700904 > coerced size: 285474816 > drive 3 ONLINE > raw size: 286749480 > non-coerced size: 285700904 > coerced size: 285474816 > volume mfid0 RAID-1 OPTIMAL > primary raid level: 1 > raid level qualifier: 0 > secondary raid level: 0 > stripe size: 7 > num drives: 2 > init state: 0 > consistent: 1 > no bgi: 0 > spans: > array 0 @ 0 : 975699968 > volume mfid1 RAID-1 OPTIMAL > primary raid level: 1 > raid level qualifier: 0 > secondary raid level: 0 Previous RAID-10 volumes that I've seen MFI BIOSes create used a non-zero secondary raid level (they all used '3', which is what mfiutil uses to create RAID-10 volumes itself). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 19:18:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF294106564A for ; Tue, 4 Jan 2011 19:18:00 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 366608FC16 for ; Tue, 4 Jan 2011 19:17:59 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 37BD89CB070 for ; Tue, 4 Jan 2011 19:59:31 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7etxJdLvGAB for ; Tue, 4 Jan 2011 19:59:30 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 45B0C9CB2F5 for ; Tue, 4 Jan 2011 19:59:30 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p04IxUx2064599 for current@freebsd.org; Tue, 4 Jan 2011 19:59:30 +0100 (CET) (envelope-from rdivacky) Date: Tue, 4 Jan 2011 19:59:30 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20110104185930.GA62775@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [RFC]: unnecessary padding in various kernel structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:18:00 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, clang (svn version) has ability to detect unnecessary padding in structures. I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC), preprocessed this and posted on web. The lists contain the file of the definition, name of the structure, size of the unnecessary padding and reason for the alignment. The last field is how many times this was hit during the build of the kernel. The lists are sorted by the size of the padding. Examples (i386): dev/usb/controller/ohci.h:64:8: 2 times padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary sys/pcpu.h:156:8: 58 times padding size of 'struct pcpu' with 108 bytes to alignment boundary sys/pcpu.h:199:2: 58 times padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf' dev/usb/controller/ehci.h:170:8: 1 times padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary kern/sched_ule.c:206:8: 1 times padding size of 'struct tdq' with 41 bytes to alignment boundary Examples(amd64): net/flowtable.c:179:11: 1 times padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle' dev/usb/controller/ohci.h:64:8: 2 times padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary net/flowtable.c:160:8: 1 times padding size of 'struct flowtable' with 108 bytes to alignment boundary vm/uma_int.h:184:8: 6 times padding size of 'struct uma_cache' with 96 bytes to alignment boundary vm/uma_int.h:338:19: 5 times padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu' net/flowtable.c:149:8: 1 times padding size of 'struct flowtable_stats' with 64 bytes to alignment boundary Full lists can be found here: http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-i386.txt http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-amd64.txt Instances of some of these structures can be in memory many times. And thus we can be losing a lot of memory without noticing it. Can you guys look at the biggest offenders or some other interesting structures in the lists and do something about it? Maybe be simple reshuffling we can improve things a lot! Thank you Roman --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk0jbhIACgkQLVEj6D3CBEwNoACeKhwUuyn+Qslahs2drb6OKfSX brQAn3CySLHNNPn4FL0BCZbX4myDC7Hd =KvrJ -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 19:46:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D41DF1065672; Tue, 4 Jan 2011 19:46:41 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 49EE28FC12; Tue, 4 Jan 2011 19:46:40 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 507EE45B36; Tue, 4 Jan 2011 20:46:38 +0100 (CET) Received: from localhost (89-73-192-49.dynamic.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6A06A45683; Tue, 4 Jan 2011 20:46:32 +0100 (CET) Date: Tue, 4 Jan 2011 20:46:27 +0100 From: Pawel Jakub Dawidek To: Andrei Kolu Message-ID: <20110104194627.GA1793@garage.freebsd.pl> References: <20101213214556.GC2038@garage.freebsd.pl> <20101213231208.GK2038@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Next ZFSv28 patchset ready for testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:46:42 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2010 at 10:15:40AM +0200, Andrei Kolu wrote: > 2010/12/14 Pawel Jakub Dawidek > > > > On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote: > > > Hi. > > > > > > The new patchset is ready for testing: > > > > > > =A0 =A0 =A0 http://people.freebsd.org/~pjd/patches/zfs_20101212.patch= .bz2 > > > > You can also download the whole source tree already patched from here: > > > > =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/zfs_20101212.tbz > > >=20 > # uname -a > FreeBSD freebsd9.raidon.eu 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Dec > 14 14:37:01 EET 2010 > root@freebsd9.raidon.eu:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > Create files filled with zeroes: > # mkfile 512m disk1 disk2 disk3 disk4 > #=A0zpool create andmed raidz /home/antik/disk{1,2,3,4} > # zpool status andmed > pool: andmed > state: ONLINE > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > andmed ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > /home/antik/disk1 ONLINE 0 0 0 > /home/antik/disk2 ONLINE 0 0 0 > /home/antik/disk3 ONLINE 0 0 0 > /home/antik/disk4 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > Now let's try to scrub: > # zpool scrub andmed >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address =3D 0x1fb8007b > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff812967d2 > stack pointer =3D 0x20:0xffffff80ee605548 > frame pointer =3D 0x28:0xffffff80ee605730 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 2081 (initial thread) > [ thread pid 2081 tid 100121 ] > Stopped at vdev_file_open+0x92: testb $0x20,0x7b(%rax) Could you verify if this patch fixes the problem for you? http://people.freebsd.org/~pjd/patches/vdev_file.c.2.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk0jeRMACgkQForvXbEpPzRjGwCfWR5Yq4kdgT6pxWej+4tlin5E 9MwAn0dIFO4Gih0iRf6cuomKB59+OCxQ =EBYd -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 4 20:53:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9C01065670; Tue, 4 Jan 2011 20:53:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2B18FC18; Tue, 4 Jan 2011 20:53:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:6585:4c82:cc96:98f0] (unknown [IPv6:2001:7b8:3a7:0:6585:4c82:cc96:98f0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DB4A55C5A; Tue, 4 Jan 2011 21:53:08 +0100 (CET) Message-ID: <4D2388AF.5080408@FreeBSD.org> Date: Tue, 04 Jan 2011 21:53:03 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Ladan?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: userland weirdness between r216351 and r216738 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 20:53:09 -0000 On 2010-12-31 22:35, Ren=E9 Ladan wrote: > somewhere between 9.0-amd64 r216351 and r216738, I've noticed some > userland weirdness. > Symptoms are: > - pseudo-random number generator not starting, preventing ssh(d) from w= orking > - fonts in X.org (xfce4) missing or replaced > - mouse only working when hald is running =2E.. > Kernel and world are compiled with > FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 This problem should now be fixed by r216977. From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 00:00:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C115106564A for ; Wed, 5 Jan 2011 00:00:24 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 025178FC0A for ; Wed, 5 Jan 2011 00:00:23 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p04NdFTp015843 for ; Wed, 5 Jan 2011 00:39:15 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id p04NaTnL035134 for ; Wed, 5 Jan 2011 00:36:29 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id p04NaTbQ035131; Wed, 5 Jan 2011 00:36:29 +0100 (CET) (envelope-from arno) To: freebsd-current@freebsd.org From: "Arno J. Klaassen" Date: Wed, 05 Jan 2011 00:36:29 +0100 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4D23AFA3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D23AFA3.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Subject: usb-regression (Tyan S3992-E) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 00:00:24 -0000 Hallo, definitely my Tyan S3992-E based box I didn't touch since a while, has difficulties with recent code; this time I wanted to cross-install from it on a USB-stick and noticed it didn't work. From dmesg : ohci early: SMM active, request owner change found-> vendor=0x1166, dev=0x0223, revid=0x01 domain=0, bus=0, slot=3, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xff6ed000, size 12, enabled map[14]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 10 unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ed000 ohci early: SMM active, request owner change [same on -current and -8-stable] I compiled and ran a 7-stable kernel of Oct6-sources (last time I cvs updated ...) on it, which gives : ohci0: port 0xd400-0xd4ff mem 0xff6ec000-0xff6ecfff irq 10 at device 3.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ec000 ohci0: (New OHCI DeviceId=0x02231166) ioapic0: routing intpin 10 (ISA IRQ 10) to vector 52 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered Pleasure to provide more info and/or test suggestions. Merci, Arno From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 08:11:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362F21065693 for ; Wed, 5 Jan 2011 08:11:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id B3D358FC1C for ; Wed, 5 Jan 2011 08:11:40 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=Isu4AnyF6WwA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=tBDZrvYw17uuL3pXsjAA:9 a=lIUumgjcQ-rJ6HQIV5gA:7 a=d8pCnhL3ajMu9NbOvrCmjovt__gA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 69581920; Wed, 05 Jan 2011 09:11:36 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 5 Jan 2011 09:11:42 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101050911.42835.hselasky@c2i.net> Cc: "Arno J. Klaassen" Subject: Re: usb-regression (Tyan S3992-E) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 08:11:41 -0000 On Wednesday 05 January 2011 00:36:29 Arno J. Klaassen wrote: > Hallo, > > definitely my Tyan S3992-E based box I didn't touch since a while, has > difficulties with recent code; this time I wanted to cross-install from > it on a USB-stick and noticed it didn't work. From dmesg : > > ohci early: SMM active, request owner change > found-> vendor=0x1166, dev=0x0223, revid=0x01 > domain=0, bus=0, slot=3, func=1 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xff6ed000, size 12, > enabled > map[14]: type I/O Port, range 32, base 0xd800, size 8, enabled > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 10 > unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ed000 > ohci early: SMM active, request owner change > > [same on -current and -8-stable] > > I compiled and ran a 7-stable kernel of Oct6-sources (last time I cvs > updated ...) on it, which gives : > > > ohci0: port 0xd400-0xd4ff mem > 0xff6ec000-0xff6ecfff irq 10 at device 3.0 on pci0 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ec000 > ohci0: (New OHCI DeviceId=0x02231166) > ioapic0: routing intpin 10 (ISA IRQ 10) to vector 52 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on > usb0 > uhub0: 2 ports with 2 removable, self powered > > > Pleasure to provide more info and/or test suggestions. This might be ACPI related. Have you tried booting without ACPI? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 11:02:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA61810656A8; Wed, 5 Jan 2011 11:02:50 +0000 (UTC) (envelope-from dbaio@bsd.com.br) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99D898FC19; Wed, 5 Jan 2011 11:02:50 +0000 (UTC) Received: by gxk8 with SMTP id 8so6327876gxk.13 for ; Wed, 05 Jan 2011 03:02:49 -0800 (PST) Received: by 10.90.114.5 with SMTP id m5mr493410agc.25.1294225369684; Wed, 05 Jan 2011 03:02:49 -0800 (PST) Received: from [192.168.6.125] ([201.86.94.44]) by mx.google.com with ESMTPS id 17sm14971290anx.33.2011.01.05.03.02.47 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 03:02:48 -0800 (PST) Message-ID: <4D244FF1.8040005@bsd.com.br> Date: Wed, 05 Jan 2011 09:03:13 -0200 From: "Danilo G. Baio" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: jhb@freebsd.org, freebsd-current@freebsd.org References: <20110104130541.GA1377@warlock.localdomain.com> <201101041005.43095.jhb@freebsd.org> <4D233C1A.3000400@bsd.com.br> <201101041137.59865.jhb@freebsd.org> In-Reply-To: <201101041137.59865.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: mfiutil and raid level X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:02:51 -0000 Em 04/01/2011 14:37, John Baldwin escreveu: > > Previous RAID-10 volumes that I've seen MFI BIOSes create used a non-zero > secondary raid level (they all used '3', which is what mfiutil uses to > create RAID-10 volumes itself). > Thank you for the answer, i will use the array created with mfiutil... Just for confirm, i´ve made more tests and more one time the array from bios still stay with secondary raid level = 0 when creates a raid 10. Creating with mfiutil, OK... mfiutil create raid10 e1:s0,e1:s1 e1:s2,e1:s3 mfiutil name mfid1 DADOS noname# mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled mfid1 ( 272G) RAID-10 64K OPTIMAL Writes noname# ./mfiutil debug mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares array size: 288 volume size: 256 spare size: 40 array 0 of 2 drives: size = 975699968 drive 4 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 drive 5 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 array 1 of 2 drives: size = 285474816 drive 0 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 1 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 array 2 of 2 drives: size = 285474816 drive 2 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 3 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 volume mfid0 RAID-1 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 0 @ 0 : 975699968 volume mfid1 RAID-10 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 3 stripe size: 7 num drives: 2 init state: 0 consistent: 0 no bgi: 0 spans: array 1 @ 0 : 285474816 array 2 @ 0 : 285474816 noname# ------------------------------------------------------------ Creating with BIOS... secondary raid level = 0 noname# mfiutil show volumes mfi0 Volumes: Id Size Level Stripe State Cache Name mfid0 ( 465G) RAID-1 64K OPTIMAL Disabled mfid1 ( 272G) RAID-1 64K OPTIMAL Disabled noname# ./mfiutil debug mfi0 Configuration (Debug): 3 arrays, 2 volumes, 0 spares array size: 288 volume size: 256 spare size: 40 array 0 of 2 drives: size = 975699968 drive 4 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 drive 5 ONLINE raw size: 976773168 non-coerced size: 975724592 coerced size: 975699968 array 1 of 2 drives: size = 285474816 drive 0 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 1 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 array 2 of 2 drives: size = 285474816 drive 2 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 drive 3 ONLINE raw size: 286749480 non-coerced size: 285700904 coerced size: 285474816 volume mfid0 RAID-1 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 1 no bgi: 0 spans: array 0 @ 0 : 975699968 volume mfid1 RAID-1 OPTIMAL primary raid level: 1 raid level qualifier: 0 secondary raid level: 0 stripe size: 7 num drives: 2 init state: 0 consistent: 0 no bgi: 0 spans: array 1 @ 0 : 285474816 array 2 @ 0 : 285474816 noname# Screen from BIOS: http://img808.imageshack.us/i/dellr510h70003lds.jpg/ http://img824.imageshack.us/i/dellr510h70002create.jpg/ http://img338.imageshack.us/i/dellr510h70001noarray.jpg/ Regards. -- Danilo G. Baio (dbaio) From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 11:23:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C07C51065670 for ; Wed, 5 Jan 2011 11:23:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 46A8B8FC0C for ; Wed, 5 Jan 2011 11:23:02 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PaRSH-0002IJ-Bn for freebsd-current@freebsd.org; Wed, 05 Jan 2011 12:23:01 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2011 12:23:01 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2011 12:23:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 05 Jan 2011 12:22:50 +0100 Lines: 46 Message-ID: References: <20110104185930.GA62775@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110104185930.GA62775@freebsd.org> X-Enigmail-Version: 1.1.2 Subject: Re: [RFC]: unnecessary padding in various kernel structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:23:03 -0000 On 04/01/2011 19:59, Roman Divacky wrote: > hi, > > clang (svn version) has ability to detect unnecessary padding in structures. > > I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC), > preprocessed this and posted on web. > > The lists contain the file of the definition, name of the structure, size of > the unnecessary padding and reason for the alignment. The last field is > how many times this was hit during the build of the kernel. It looks like "padding... to alignment boundary" means "because of struct {...} __aligned(CACHE_LINE_SIZE)" and such, and we cannot run away from those - maybe you should filter those results out? > The lists are sorted by the size of the padding. > > Examples (i386): > > dev/usb/controller/ohci.h:64:8: 2 times > padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary > sys/pcpu.h:156:8: 58 times > padding size of 'struct pcpu' with 108 bytes to alignment boundary > sys/pcpu.h:199:2: 58 times > padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf' > dev/usb/controller/ehci.h:170:8: 1 times > padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary > kern/sched_ule.c:206:8: 1 times > padding size of 'struct tdq' with 41 bytes to alignment boundary > > Examples(amd64): > > net/flowtable.c:179:11: 1 times > padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle' > dev/usb/controller/ohci.h:64:8: 2 times > padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary > net/flowtable.c:160:8: 1 times > padding size of 'struct flowtable' with 108 bytes to alignment boundary > vm/uma_int.h:184:8: 6 times > padding size of 'struct uma_cache' with 96 bytes to alignment boundary > vm/uma_int.h:338:19: 5 times > padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu' > net/flowtable.c:149:8: 1 times > padding size of 'struct flowtable_stats' with 64 bytes to alignment boundary From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 11:46:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7E7010658C2; Wed, 5 Jan 2011 11:46:41 +0000 (UTC) (envelope-from oleg.nauman@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8898FC08; Wed, 5 Jan 2011 11:46:41 +0000 (UTC) Received: by pvc22 with SMTP id 22so3186499pvc.13 for ; Wed, 05 Jan 2011 03:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lv7DwORDsidIFYpW4ze3L7nT6RWReI5WurZCDaVV1cM=; b=uqn8pLh878FEAcw6QU1FCiGNm8MRe5eyHuMbIIdzR77XGLGaTF2y5/wd+PBSdFRy79 bjOnupJIzT8Zrpl7jjA0uZVkUFxsFBNTGHh4/YLTRPFl7LyJqrXCemuEgqvSPLhCTqqX G8GvGucKeV5bsCavPikOD3QK90yKpRdHnT3Bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dmfz9hyBjLe2CciyHhwPKQA3eKQfU6UowMQhrzuBewBiJLkJP3rUrWucIefkAtd3Jo ZXsYzeNG/utbcigOaArLbPcD1adpsPFCzEpiRZLmoSDokuMlIdVLbF9JYjdK6zUjKk39 B+av/45lMouuO0zlUoUqfCMHPu6FzmknGVQ7o= MIME-Version: 1.0 Received: by 10.142.48.14 with SMTP id v14mr18731726wfv.157.1294228000959; Wed, 05 Jan 2011 03:46:40 -0800 (PST) Received: by 10.142.230.17 with HTTP; Wed, 5 Jan 2011 03:46:40 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Jan 2011 13:46:40 +0200 Message-ID: From: Oleg Nauman To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CAM related panic on 8.2-PRERELEASE Was: Re: USB related panic on 8.2-PRERELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:46:42 -0000 On Tue, Dec 28, 2010 at 9:49 AM, Oleg Nauman wrote: > On Fri, Dec 10, 2010 at 8:15 PM, Hans Petter Selasky w= rote: >> Hi, > > =C2=A0Hello, > >> >> I think this is a known issue which never got fixed. Please try the atta= ched >> patch and report back. >> >> XXX_SAFE !=3D XXX_REAL_SAFE :-) > > =C2=A0My laptop experienced a crash again, this time it seems CAM related= : > > Unread portion of the kernel message buffer: > umass0: at uhub5, port 3, addr 2 (disconnected) > (probe0:umass-sim0:0:0:0): AutoSense failed > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =C2=A0 =3D 0x14 > fault code =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D supervisor= read, page not present > instruction pointer =C2=A0 =C2=A0 =3D 0x20:0xc0736482 > stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xc5225bd4 > frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xc5225bec > code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, limit= 0xfffff, type 0x1b > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D resume, IOPL =3D 0 > current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 12 (swi2: cambio) > trap number =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xc072ac57 at kdb_backtrace+0x47 > #1 0xc06ffe97 at panic+0x117 > #2 0xc09a31f3 at trap_fatal+0x323 > #3 0xc09a3602 at trap+0x152 > #4 0xc098c87c at calltrap+0x6 > #5 0xc06f25e9 at _mtx_unlock_sleep+0x49 > #6 0xc06f2669 at _mtx_unlock_flags+0x49 > #7 0xc0473bb0 at camisr+0x110 > #8 0xc06de98c at intr_event_execute_handlers+0x14c > #9 0xc06df77e at ithread_loop+0xbe > #10 0xc06dccde at fork_exit+0xee > #11 0xc098c8f4 at fork_trampoline+0x8 > Uptime: 6m55s > Physical memory: 2027 MB > Dumping 121 MB: 106 90 74 58 42 26 10 > > Reading symbols from /boot/modules/bwn_v4_ucode.ko...Reading symbols > from /boot/modules/bwn_v4_ucode.ko.symbols...done. > done. > Loaded symbols for /boot/modules/bwn_v4_ucode.ko > Reading symbols from /boot/modules/cuse4bsd.ko...done. > Loaded symbols for /boot/modules/cuse4bsd.ko > #0 =C2=A0doadump () at pcpu.h:231 > 231 =C2=A0 =C2=A0 pcpu.h: No such file or directory. > =C2=A0 =C2=A0 =C2=A0 =C2=A0in pcpu.h > (kgdb) #0 =C2=A0doadump () at pcpu.h:231 > #1 =C2=A00xc06ffc93 in boot (howto=3D260) at ../../../kern/kern_shutdown.= c:419 > #2 =C2=A00xc06ffed0 in panic (fmt=3DVariable "fmt" is not available. > ) at ../../../kern/kern_shutdown.c:592 > #3 =C2=A00xc09a31f3 in trap_fatal (frame=3D0xc5225b94, eva=3D20) > =C2=A0 =C2=A0at ../../../i386/i386/trap.c:946 > #4 =C2=A00xc09a3602 in trap (frame=3D0xc5225b94) at ../../../i386/i386/tr= ap.c:326 > #5 =C2=A00xc098c87c in calltrap () at ../../../i386/i386/exception.s:166 > #6 =C2=A00xc0736482 in turnstile_broadcast (ts=3D0x0, queue=3D0) > =C2=A0 =C2=A0at ../../../kern/subr_turnstile.c:831 > #7 =C2=A00xc06f25e9 in _mtx_unlock_sleep (m=3D0xc67e170c, opts=3D0, > =C2=A0 =C2=A0file=3D0xc0a04b40 "../../../cam/cam_xpt.c", line=3D4715) > =C2=A0 =C2=A0at ../../../kern/kern_mutex.c:675 > #8 =C2=A00xc06f2669 in _mtx_unlock_flags (m=3D0xc67e170c, opts=3D0, > =C2=A0 =C2=A0file=3D0xc0a04b40 "../../../cam/cam_xpt.c", line=3D4715) > =C2=A0 =C2=A0at ../../../kern/kern_mutex.c:227 > #9 =C2=A00xc0473bb0 in camisr (dummy=3D0x0) at ../../../cam/cam_xpt.c:471= 5 > #10 0xc06de98c in intr_event_execute_handlers (p=3D0xc556f7f8, ie=3D0xc56= a8800) > =C2=A0 =C2=A0at ../../../kern/kern_intr.c:1220 > #11 0xc06df77e in ithread_loop (arg=3D0xc556e2b0) > =C2=A0 =C2=A0at ../../../kern/kern_intr.c:1233 > #12 0xc06dccde in fork_exit (callout=3D0xc06df6c0 , > =C2=A0 =C2=A0arg=3D0xc556e2b0, frame=3D0xc5225d28) at ../../../kern/kern_= fork.c:845 > #13 0xc098c8f4 in fork_trampoline () at ../../../i386/i386/exception.s:27= 3 > (kgdb) Filed PR 153514 for better the things tracking. Is it possible to look into this issue? > > It happens with > device umass > enabled in my kernel config file > >> >> --HPS >> >> On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: >>> On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman wro= te: >>> > =C2=A0Hello Hans, >>> > >>> > On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky >> wrote: >>> >> On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: >>> >>> Hello, >>> >>> >>> >>> Unfortunately my notebook experienced the crash during the attempts= to >>> >>> attach EVDO modem supplied with builtin MicroSD cardreader. >>> >>> Related core.txt file is attached as well as 'usbconfig >>> >>> dump_all_config_desc' output (all_config.txt) >>> >>> USB subsystem reports endless USB_ERR_STALLED events during attempt= s >>> >>> to attach umass device, but attaches it finally ( sometimes it >>> >>> attached after two attempts, sometimes it trying to attach during >>> >>> 15-20 minutes ).MicroSD is inserted there, without any effect =C2= =A0on >>> >>> attachment attempts though. >>> >> >>> >> Hi, >>> >> >>> >> Can you reproduce the panic using a kernel built with INVARIANTS opt= ions >>> >> and DEBUG_MEMGUARD . >>> > >>> > =C2=A0I rebuilt my kernel with options you mentioned ( have added >>> > INVARIANT_SUPPORT required =C2=A0by INVARIANTS though ) >>> > >>> > Waiting on panic.. >>> >>> =C2=A0Got it finally ( core.txt file is attached ) >>> >> > From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 13:00:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D16106566C for ; Wed, 5 Jan 2011 13:00:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CF8B38FC0C for ; Wed, 5 Jan 2011 13:00:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8096C46B38; Wed, 5 Jan 2011 08:00:17 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A75E58A009; Wed, 5 Jan 2011 08:00:16 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 5 Jan 2011 07:46:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101050746.58358.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 05 Jan 2011 08:00:16 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Arno J. Klaassen" Subject: Re: usb-regression (Tyan S3992-E) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:00:18 -0000 On Tuesday, January 04, 2011 6:36:29 pm Arno J. Klaassen wrote: > > Hallo, > > definitely my Tyan S3992-E based box I didn't touch since a while, has > difficulties with recent code; this time I wanted to cross-install from > it on a USB-stick and noticed it didn't work. From dmesg : > > ohci early: SMM active, request owner change > found-> vendor=0x1166, dev=0x0223, revid=0x01 > domain=0, bus=0, slot=3, func=1 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xff6ed000, size 12, > enabled > map[14]: type I/O Port, range 32, base 0xd800, size 8, enabled > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 10 > unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff6ed000 > ohci early: SMM active, request owner change Can you get a larger chunk of dmesg? These are just the messages from the PCI bus driver, not from the ohci driver. Are you sure you have ohci in your test kernel? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 13:14:41 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99721065673 for ; Wed, 5 Jan 2011 13:14:41 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4D38FC1F for ; Wed, 5 Jan 2011 13:14:41 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p05DEdB0029949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 14:14:39 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 5 Jan 2011 14:14:39 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org Message-ID: <20110105131439.GN23329@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:14:41 -0000 Hello folks, Now that I'm fairly confident that the stability issues with your.org's VMs have been resolved, I'd like to point you to the new and improved, semi-weekly analyzer runs at http://scan.freebsd.your.org/freebsd-head/ If you are an HTML/CSS expert and want to help "style" that page a little more in FreeBSD style, please get in touch with me. Thanks! Uli From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 13:21:56 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0E231065672 for ; Wed, 5 Jan 2011 13:21:56 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 384F38FC0A for ; Wed, 5 Jan 2011 13:21:56 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p05DLtaQ030118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 14:21:55 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1294233715; bh=g9zZ8Tl2Dbqy2xRFClj/b+7usueaN8Vd9HfBZ+8JmI0=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=e17JibYZhfG4x5us0+/WfjqOA1wBy/SgtPAy9ZBzBZOISE3mvliHeiB3dwen8WIlQ 6Hb6tZTL4VNnYSiJ42jLGOAn16LruWHhP6LH/2WArvor/0r785pfsY9F/KZ0vpmoWR xhk/g8IENYTunvm2e6zPZ0bY3vRYh9MYN+kYjyDA= Date: Wed, 5 Jan 2011 14:21:55 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org Message-ID: <20110105132155.GO23329@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:21:56 -0000 !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the YYYY/MM/DD format (I can't help it ...). Given that this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. The ultimate goal would be to change syslog's timestamp and ps(1) output, but that goal is far off ... http://en.wikipedia.org/wiki/ISO_8601 Uli From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 13:44:18 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DEC6106564A for ; Wed, 5 Jan 2011 13:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id ECE5C8FC21 for ; Wed, 5 Jan 2011 13:44:17 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p05DiDGO057743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Jan 2011 15:44:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p05DiDq7018176 for ; Wed, 5 Jan 2011 15:44:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p05DiDK0018175 for current@FreeBSD.org; Wed, 5 Jan 2011 15:44:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 5 Jan 2011 15:44:13 +0200 From: Kostik Belousov To: current@FreeBSD.org Message-ID: <20110105134413.GG12599@deviant.kiev.zoral.com.ua> References: <20110105132155.GO23329@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zGQnqpIoxlsbsOfg" Content-Disposition: inline In-Reply-To: <20110105132155.GO23329@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 13:44:18 -0000 --zGQnqpIoxlsbsOfg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2011 at 02:21:55PM +0100, Ulrich Sp??rlein wrote: > !ACHTUNG BIKESHED ALERT! >=20 > Hello, >=20 > With the recent changes to the committer graphs, I again was reminded > how much I hate the YYYY/MM/DD format (I can't help it ...). Given that > this almost looks like ISO 8601, but is an unreadable variant of it, I > would like to aggressively change this throughout the tree. >=20 > I'd like to start with minor stuff like share/misc/*.dot. Then probably > src/UPDATING, and ports/UPDATING after I've identified the consumers of > these docs. Can we, please, move share/misc/*.dot to doc/ repository, where it belongs and would make a nice addition to the freebsd-contributors article ? >=20 > The ultimate goal would be to change syslog's timestamp and ps(1) > output, but that goal is far off ... >=20 > http://en.wikipedia.org/wiki/ISO_8601 >=20 > Uli > _______________________________________________ > 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" --zGQnqpIoxlsbsOfg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0kda0ACgkQC3+MBN1Mb4jJvgCgyADfNLiNT1tD2Wffzl9a8dmK zGwAoKoDBhQ1ND3k7ko1p93lb47m/UAe =vfuD -----END PGP SIGNATURE----- --zGQnqpIoxlsbsOfg-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 14:11:53 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50121106566C; Wed, 5 Jan 2011 14:11:53 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id D89088FC17; Wed, 5 Jan 2011 14:11:52 +0000 (UTC) Received: from [192.168.0.46] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp1.one.com (Postfix) with ESMTP id 95C6D1BC00A25; Wed, 5 Jan 2011 14:11:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-108-249414753; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> Date: Wed, 5 Jan 2011 15:11:50 +0100 Message-Id: References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@FreeBSD.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:11:53 -0000 --Apple-Mail-108-249414753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: > Ignoring contrib code for the moment, I decided to look at usr.sbin.pw = from 2011-01-05. There's one report = (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/re= port-KkilQ3.html#EndPath) which turns out to be a false positive: >=20 > * Step 6 calls cmdhelp() on line 168; > * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume = is exit(3) from libc > * The analyzer doesn't know that this function never returns and = continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() = which is also causing false positive reports. They ultimately call = exit(3). Erik= --Apple-Mail-108-249414753-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 14:14:25 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE40106564A; Wed, 5 Jan 2011 14:14:25 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id E08378FC22; Wed, 5 Jan 2011 14:14:23 +0000 (UTC) Received: from [192.168.0.46] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp1.one.com (Postfix) with ESMTP id 47A891BC03A46; Wed, 5 Jan 2011 13:56:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-105-248476387; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20110105131439.GN23329@acme.spoerlein.net> Date: Wed, 5 Jan 2011 14:56:12 +0100 Message-Id: <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> References: <20110105131439.GN23329@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@FreeBSD.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:14:25 -0000 --Apple-Mail-105-248476387 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Den 05/01/2011 kl. 14.14 skrev Ulrich Sp=F6rlein: > Hello folks, >=20 > Now that I'm fairly confident that the stability issues with = your.org's > VMs have been resolved, I'd like to point you to the new and improved, > semi-weekly analyzer runs at >=20 > http://scan.freebsd.your.org/freebsd-head/ I had a look at this again. There are over 9.000 reports so it's a bit = overwhelming, but I suspect there's a lot of "collateral damage". Ignoring contrib code for the moment, I decided to look at usr.sbin.pw = from 2011-01-05. There's one report = (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/re= port-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume = is exit(3) from libc * The analyzer doesn't know that this function never returns and = continues to flag a null dereference in step 8 What's the fix here? I think the reports are an excellent way to get acquainted with FreeBSD = code. Marking and fixing the false positives would make bug-hunting in = the remaining reports more motivating :-) Thanks, Erik= --Apple-Mail-105-248476387-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 14:36:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B6C1065679 for ; Wed, 5 Jan 2011 14:36:51 +0000 (UTC) (envelope-from regnauld@bluepipe.net) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by mx1.freebsd.org (Postfix) with ESMTP id BAA6C8FC20 for ; Wed, 5 Jan 2011 14:36:50 +0000 (UTC) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id B898F4D0EDE for ; Wed, 5 Jan 2011 15:13:48 +0100 (CET) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id htg9SzlcItS6 for ; Wed, 5 Jan 2011 15:13:46 +0100 (CET) Received: from macbook.catpipe.net (flow.bluepipe.dk [195.249.214.179]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 593654D0EDD for ; Wed, 5 Jan 2011 15:13:46 +0100 (CET) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 235DA24CA2F7; Wed, 5 Jan 2011 15:13:46 +0100 (CET) Date: Wed, 5 Jan 2011 15:13:46 +0100 From: Phil Regnauld To: freebsd-current@freebsd.org Message-ID: <20110105141341.GI4613@macbook.catpipe.net> References: <1293726772.5853.1348.camel@pow> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Darwin 10.4.0 i386 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Virtio drivers for FreeBSD on KVM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:36:51 -0000 Pete French (petefrench) writes: > Actually, it does look like virtio is more than just for > networking... > > http://vbox.innotek.de/pipermail/vbox-dev/2009-November/002053.html Yes indeed. Disk drivers as well. By the way, does anyone whatever happened to the KVM for FreeBSD project ? Nothing since Summer of Code 2007... http://wiki.freebsd.org/FabioChecconi/PortingLinuxKVMToFreeBSD http://retis.sssup.it/~fabio/freebsd/lkvm/ Cheers, Phil From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 14:38:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA3C1065670; Wed, 5 Jan 2011 14:38:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2F48FC13; Wed, 5 Jan 2011 14:38:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 58DEC46B2D; Wed, 5 Jan 2011 09:38:42 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4F3768A01D; Wed, 5 Jan 2011 09:38:41 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 5 Jan 2011 09:34:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101050934.49845.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 05 Jan 2011 09:38:41 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: =?iso-8859-15?q?Sp=F6rlein?= , Erik Cederstrand , Ulrich Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 14:38:42 -0000 On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: > > Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: > > > Ignoring contrib code for the moment, I decided to look at usr.sbin.pw > > from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) > > which turns out to be a false positive: > > > > * Step 6 calls cmdhelp() on line 168; > > * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume > > is exit(3) from libc > > * The analyzer doesn't know that this function never returns and > > continues to flag a null dereference in step 8 > > The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() > which is also causing false positive reports. They ultimately call exit(3). These are all marked as __dead2, so the compiler should "know" that these do not return. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 16:55:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2A8106564A; Wed, 5 Jan 2011 16:55:47 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 42B6C8FC17; Wed, 5 Jan 2011 16:55:47 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p05Gtjx9034096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 17:55:45 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Wed, 5 Jan 2011 17:55:45 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: John Baldwin Message-ID: <20110105165545.GP23329@acme.spoerlein.net> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org, Erik Cederstrand References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101050934.49845.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Erik Cederstrand Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 16:55:47 -0000 On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: > On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: > > > > Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: > > > > > Ignoring contrib code for the moment, I decided to look at usr.sbin.pw > > > from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) > > > which turns out to be a false positive: > > > > > > * Step 6 calls cmdhelp() on line 168; > > > * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume > > > is exit(3) from libc > > > * The analyzer doesn't know that this function never returns and > > > continues to flag a null dereference in step 8 > > > > The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() > > which is also causing false positive reports. They ultimately call exit(3). > > These are all marked as __dead2, so the compiler should "know" that these do > not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) - come up with a way to mark the false positives (kinda impossible with the way scan-build currently works) All interested parties with src access are encouraged to take a look at our Coverity Prevent installation (which is down for maintenance, but should be up soon). Regards, Uli From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 17:30:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3583106564A for ; Wed, 5 Jan 2011 17:30:08 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 51CC78FC08 for ; Wed, 5 Jan 2011 17:30:08 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5AC269CB42B; Wed, 5 Jan 2011 18:13:31 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPNmYJPbyxn4; Wed, 5 Jan 2011 18:13:30 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 160CD9CB492; Wed, 5 Jan 2011 18:13:30 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p05HDTIg070312; Wed, 5 Jan 2011 18:13:29 +0100 (CET) (envelope-from rdivacky) Date: Wed, 5 Jan 2011 18:13:29 +0100 From: Roman Divacky To: John Baldwin , freebsd-current@freebsd.org, Erik Cederstrand Message-ID: <20110105171329.GA69338@freebsd.org> References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110105165545.GP23329@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:30:08 -0000 On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp??rlein wrote: > On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: > > On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: > > > > > > Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: > > > > > > > Ignoring contrib code for the moment, I decided to look at usr.sbin.pw > > > > from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) > > > > which turns out to be a false positive: > > > > > > > > * Step 6 calls cmdhelp() on line 168; > > > > * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume > > > > is exit(3) from libc > > > > * The analyzer doesn't know that this function never returns and > > > > continues to flag a null dereference in step 8 > > > > > > The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() > > > which is also causing false positive reports. They ultimately call exit(3). > > > > These are all marked as __dead2, so the compiler should "know" that these do > > not return. > > And clang did the right thing here in the past. Beware that it does no > inter-procedural analysis yet, so it will usually miss that usage() > calls exit unconditionally. > > *But*, it should grok that for err(3) and exit(3). Now there are some > possible remedies: > > - get IPA to work with clang, or at least file a bug > - mark functions as __dead2 (please don't do that) > - come up with a way to mark the false positives (kinda impossible with > the way scan-build currently works) The problem is that while exit() is __dead2 the actual cmdhelp() is not. At least clang does not see it as such. Thus the static analyzer just sees a call to a normal function (it does not recurse into it) and produces this false positive... I wonder how how hard would it to be to add some trivial IPA that analyzes cases like this.. From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 18:20:47 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD42106564A for ; Wed, 5 Jan 2011 18:20:47 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id D46BB8FC0C for ; Wed, 5 Jan 2011 18:20:46 +0000 (UTC) Received: from park.js.berklix.net (p5B22F147.dip.t-dialin.net [91.34.241.71]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p05I0PUq010608; Wed, 5 Jan 2011 18:00:31 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p05I0LM9030575; Wed, 5 Jan 2011 19:00:21 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id p05I0V7k002583; Wed, 5 Jan 2011 19:00:36 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201101051800.p05I0V7k002583@fire.js.berklix.net> To: Ulrich =?utf-8?B?U3DDtnJsZWlu?= From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 05 Jan 2011 14:21:55 +0100." <20110105132155.GO23329@acme.spoerlein.net> Date: Wed, 05 Jan 2011 19:00:31 +0100 Sender: jhs@berklix.com Cc: current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:20:47 -0000 Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: > !ACHTUNG BIKESHED ALERT! > > Hello, > > With the recent changes to the committer graphs, I again was reminded > how much I hate the YYYY/MM/DD format (I can't help it ...). Given that I guess & hope you mean you like linear decreasing order but dislike '/' as a delimeter & want to swap from '/' to '-' as in ISO ? > this almost looks like ISO 8601, but is an unreadable variant of it, I > would like to aggressively change this throughout the tree. > > I'd like to start with minor stuff like share/misc/*.dot. Then probably > src/UPDATING, and ports/UPDATING after I've identified the consumers of > these docs. Do you mean you would like to swap eg src/UPDATING 20100720 to eg 2010-07-20 ? That would be more readable. > The ultimate goal would be to change syslog's timestamp and ps(1) > output, but that goal is far off ... I've long had a mental note to get round to fixing isnd which emits: "05.01.2011 13:15:06" To "2011-01-05 13:15:06" However reading that URL, I see isdnd should have eg: 2011-01-05T13:15:06 2011-01-05T13:15:06+01:00 2011-01-05T12:15:06Z But that 'T' is hard to see, so either space it (allowed by ISO) 2011-01-05 13:15:06 2011-01-05 13:15:06+01:00 2011-01-05 12:15:06Z or lower case the 't' (if ISO allows ?) 2011-01-05t13:15:06 2011-01-05t13:15:06+01:00 2011-01-05t12:15:06Z > http://en.wikipedia.org/wiki/ISO_8601 > > Uli Week numbers in ISO standard can (& should IMO) be ignored: Not much use for week numbers in FreeBSD, Dates when source code is released, & /var/logs get stamped etc, best without week numbers, just simplistic linearly progressive continuously decremental digit format (ie Year Month Day Hour Minute Second Week numbers not used much, eg I'm British, lived in Germany 25 years. First I ever saw of week numbers was in Germany, never saw them in Britain. /usr/src/bin/date/ Although default output of date eg Wed Jan 5 17:41:06 CET 2011 is both non linear, & also non conformant in timezone (CET should be +01:00) it would open a can of worms to change default output, [unless it hangs on an env var.] ... [at least yet] ... too many shells use it (in user's own code, not just in /usr/src & /usr/ports). I don't see anything in `man date` to internaly emit timezone per ISO, this works: echo "`date -u +%Y-%m-%dt%H:%M:%S`Z" echo "`date -u +%Y-%m-%dt%H:%M:%S`+00:00" echo "`date -v-1H +%Y-%m-%dt%H:%M:%S`Z" # (as my TZ is -01:00) but as that wouldnt do if nested inside more quotes from other shells, we could add to date.c to emit an explicit timezone, 2 flags to add, I suggest: - '-U' to force '-u' & also swap output of eg "CET 2011" to "2011Z" or "2011+00:00" ( '-U' is not yet used ). - Some flag to specify a numeric string eg [+-][0-5][0-9]:[0-5][0-9] (... maybe tie that in with man environ TZ tzset ? ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses. From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 19:36:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBD11065675; Wed, 5 Jan 2011 19:36:55 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 384658FC15; Wed, 5 Jan 2011 19:36:55 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 47C491DD724; Wed, 5 Jan 2011 20:36:53 +0100 (CET) Received: by turtle.stack.nl (Postfix, from userid 1677) id 3E5821707A; Wed, 5 Jan 2011 20:36:53 +0100 (CET) Date: Wed, 5 Jan 2011 20:36:53 +0100 From: Jilles Tjoelker To: John Baldwin , freebsd-current@freebsd.org, Erik Cederstrand Message-ID: <20110105193653.GA49285@stack.nl> References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110105165545.GP23329@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:36:55 -0000 On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: > On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: > > These are all marked as __dead2, so the compiler should "know" that these do > > not return. > And clang did the right thing here in the past. Beware that it does no > inter-procedural analysis yet, so it will usually miss that usage() > calls exit unconditionally. > *But*, it should grok that for err(3) and exit(3). Now there are some > possible remedies: > - get IPA to work with clang, or at least file a bug > - mark functions as __dead2 (please don't do that) Why not? I have done this in some cases because it leads to better code with gcc (the system version in 9-current). See SVN commit r212508 to bin/sh/parser.c. Although synexpect() and synerror() are static, adding __dead2 to both makes the executable 576 bytes smaller on i386 (these functions are called many times). Adding __dead2 to synexpect() only causes a warning "noreturn function does return" (it calls synerror()). Adding __dead2 to synerror() only also makes the executable smaller but not as much as adding it to both. Reordering the functions in the file does not help to make gcc see that the functions do not return. > - come up with a way to mark the false positives (kinda impossible with > the way scan-build currently works) -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 19:47:52 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14D6106566B for ; Wed, 5 Jan 2011 19:47:52 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31E768FC27 for ; Wed, 5 Jan 2011 19:47:52 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p05Jlnts037364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 20:47:50 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1294256870; bh=qvoejjd3v3udCgSDzKZJcnQyahr7wlv4yz/GtRa0Knw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=aKKDWlJ2yspLXwpSBDydQ2LdYDchRzS1Xkpj0dZo/TtxS5WXl/V5nYNVT/ffGHuHd JyEHxFPHP+cIIoNyuK0ig88V7yKT8fafosKS8K5huf55jLaJUXXbSXRv4mfSTv9LR9 2LMVTU5eZ0OtW5N/5rXkyy6ZgN29/mbQEoEAyWk4= Date: Wed, 5 Jan 2011 20:47:49 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "Julian H. Stacey" Message-ID: <20110105194748.GS23329@acme.spoerlein.net> Mail-Followup-To: "Julian H. Stacey" , current@freebsd.org References: <20110105132155.GO23329@acme.spoerlein.net> <201101051800.p05I0V7k002583@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101051800.p05I0V7k002583@fire.js.berklix.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:47:52 -0000 On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: > Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: > > !ACHTUNG BIKESHED ALERT! > > > > Hello, > > > > With the recent changes to the committer graphs, I again was reminded > > how much I hate the YYYY/MM/DD format (I can't help it ...). Given that > > I guess & hope you mean you like linear decreasing order but > dislike '/' as a delimeter & want to swap from '/' to '-' as in ISO ? Exactly. > > this almost looks like ISO 8601, but is an unreadable variant of it, I > > would like to aggressively change this throughout the tree. > > > > I'd like to start with minor stuff like share/misc/*.dot. Then probably > > src/UPDATING, and ports/UPDATING after I've identified the consumers of > > these docs. > > Do you mean you would like to swap eg src/UPDATING 20100720 to eg > 2010-07-20 ? That would be more readable. Yes, I think for lists of dates like in UPDATING or automatically generated date output like syslogd, the ISO8601 format only has advantages. > > The ultimate goal would be to change syslog's timestamp and ps(1) > > output, but that goal is far off ... > > I've long had a mental note to get round to fixing isnd which emits: > "05.01.2011 13:15:06" > To > "2011-01-05 13:15:06" Hehe, isdnd was written by a German, it seems :) > However reading that URL, I see isdnd should have eg: > 2011-01-05T13:15:06 > 2011-01-05T13:15:06+01:00 > 2011-01-05T12:15:06Z > But that 'T' is hard to see, so either space it (allowed by ISO) > 2011-01-05 13:15:06 > 2011-01-05 13:15:06+01:00 > 2011-01-05 12:15:06Z > or lower case the 't' (if ISO allows ?) > 2011-01-05t13:15:06 > 2011-01-05t13:15:06+01:00 > 2011-01-05t12:15:06Z I'd prefer the space to "T" or "t" for easier human parsing (and for machine parsing it doesn't really matter) > > http://en.wikipedia.org/wiki/ISO_8601 > > > > Uli > > Week numbers in ISO standard can (& should IMO) be ignored: > Not much use for week numbers in FreeBSD, > Dates when source code is released, & /var/logs get > stamped etc, best without week numbers, just > simplistic linearly progressive continuously > decremental digit format (ie Year Month Day Hour > Minute Second > Week numbers not used much, eg > I'm British, lived in Germany 25 years. First I > ever saw of week numbers was in Germany, never saw > them in Britain. Outside of cal/ncal I don't think we use week numbers anywhere in FreeBSD. > /usr/src/bin/date/ > Although default output of date eg > Wed Jan 5 17:41:06 CET 2011 > is both non linear, & also non conformant in timezone (CET should > be +01:00) it would open a can of worms to change default > output, [unless it hangs on an env var.] ... [at least > yet] ... too many shells use it (in user's own code, not > just in /usr/src & /usr/ports). > > I don't see anything in `man date` to internaly emit timezone per ISO, > this works: > echo "`date -u +%Y-%m-%dt%H:%M:%S`Z" > echo "`date -u +%Y-%m-%dt%H:%M:%S`+00:00" > echo "`date -v-1H +%Y-%m-%dt%H:%M:%S`Z" # (as my TZ is -01:00) > but as that wouldnt do if nested inside more quotes from other shells, > we could add to date.c to emit an explicit timezone, > 2 flags to add, I suggest: > - '-U' to force '-u' & also swap output of eg "CET 2011" to > "2011Z" or "2011+00:00" ( '-U' is not yet used ). > - Some flag to specify a numeric string eg [+-][0-5][0-9]:[0-5][0-9] > (... maybe tie that in with man environ TZ tzset ? ) It's too late to change anything in date(1)'s default output, and it has %F already via strftime(3) so people like me can already use that everywhere. Regards, Uli From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 20:19:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F501065674 for ; Wed, 5 Jan 2011 20:19:04 +0000 (UTC) (envelope-from ipfreak@yahoo.com) Received: from web130203.mail.mud.yahoo.com (web130203.mail.mud.yahoo.com [66.94.238.139]) by mx1.freebsd.org (Postfix) with SMTP id A91A98FC1F for ; Wed, 5 Jan 2011 20:19:03 +0000 (UTC) Received: (qmail 62916 invoked by uid 60001); 5 Jan 2011 19:52:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294257143; bh=x5p6+X2ThiFWvSWwLfwfV8TTuxmMtV5A3xJwBCGI9Bg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=WeOF1burWymTTfHvX9bd2bfyx7UJmV85s+FzfIrO5taTDaNBBRmDIcGNAZ4/NrJNuuL2+AG28jPoO4ASoW4LhWMBueU2i0EQGvvzmfPE6yxfKLMKg+SzjpsGRI0NSNgqXJLUo5MYDwYPsKdVG+r2RNcPV0EGnzh/z2UjGXkOL7M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=oI9IsWjLhMFTkCqRKOqd56KL4k97uG6hVAmdtfZ/mh6ADLA6Edt171GB92xyI91dyT3gdFL54uwNLQlZsGTdIGG7Iv14sZuZ/C0hblqQOEsZ1LBKRcKGFDBLexA26NTX6vCPv9LvYpfeuvB56kiTAgiTd5FuPn2YIS7hOK4W3zI=; Message-ID: <534524.62805.qm@web130203.mail.mud.yahoo.com> X-YMail-OSG: .V2uOnMVM1mgsrqFqsNcrXgEDT14SEIlDy2U1WIslT34BZa wmTJqwUg9fXMx7bJ4gkr_EAaP0jXr2pj60m7mu_Rn0fXrflV0SwC3O.71T8L 5k7HvX_Wblep4jSJ.VtI4vlqFZ02zaGlOAz4zgU5mSkm4QGKh2q4mXdtt_1s LY3LU8AK_BQJO6Kh190VyTo_YSDqVns6t52.snvR4pXlTZhMgHr5ElXBK7lE lSYSU3W8qW6gmM_hNVIa_aGJB.IfjxMAEJNv65B7H6ElmxpgDi4X3SzEwlU8 tdAsZ1HOm7TeV86dwk2QRUY1JPVSXpW7.Jy2IoLkPpgxpvuaXpfPFqmuc2jr q7FK7TZFMPtGaXhCDTQWEA9JqO6Z_e3s_Ii0Vd6DKRiMd24Sazuv79_QD6rK 0aJOKTXUqgA7_ Received: from [184.80.143.6] by web130203.mail.mud.yahoo.com via HTTP; Wed, 05 Jan 2011 11:52:23 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 5 Jan 2011 11:52:23 -0800 (PST) From: gahn To: free bsd , freebsd general questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: freebsd and X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:19:04 -0000 hi all: i set up the freeradius 21.100.1 on freebsd 8.1. it uses local authentication database of /etc/passwd (thanks to the previous discussions alan did with others). the problem is: it only works with the condition of the server id running as "root" instead of "freeradius" due to the one way MD5 hash of /etc/passwd file. are there any other better ways to implement this? From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 20:22:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A0F1106564A; Wed, 5 Jan 2011 20:22:45 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id D9F888FC13; Wed, 5 Jan 2011 20:22:44 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp3.one.com (Postfix) with ESMTP id 065532405623; Wed, 5 Jan 2011 20:22:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-136-271666640; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20110105165545.GP23329@acme.spoerlein.net> Date: Wed, 5 Jan 2011 21:22:42 +0100 Message-Id: <1D4E1C30-82CB-4131-831F-EE3D167BACA2@cederstrand.dk> References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:22:45 -0000 --Apple-Mail-136-271666640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Den 05/01/2011 kl. 17.55 skrev Ulrich Sp=F6rlein: > And clang did the right thing here in the past. Beware that it does no > inter-procedural analysis yet, so it will usually miss that usage() > calls exit unconditionally. >=20 > *But*, it should grok that for err(3) and exit(3). Now there are some > possible remedies: >=20 > - get IPA to work with clang, or at least file a bug I filed a bug with LLVM (http://llvm.org/bugs/show_bug.cgi?id=3D8914) = but it seems IPA bugs filed on the analyzer have been rejected in the = past. Erik= --Apple-Mail-136-271666640-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 20:26:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80FAD106564A for ; Wed, 5 Jan 2011 20:26:24 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 36AD38FC0C for ; Wed, 5 Jan 2011 20:26:23 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 6BE569CB42B; Wed, 5 Jan 2011 21:26:22 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JweVgeK75tdm; Wed, 5 Jan 2011 21:26:21 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9F3859CB492; Wed, 5 Jan 2011 21:26:21 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p05KQLUY095127; Wed, 5 Jan 2011 21:26:21 +0100 (CET) (envelope-from rdivacky) Date: Wed, 5 Jan 2011 21:26:21 +0100 From: Roman Divacky To: Erik Cederstrand Message-ID: <20110105202621.GA94901@freebsd.org> References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> <1D4E1C30-82CB-4131-831F-EE3D167BACA2@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D4E1C30-82CB-4131-831F-EE3D167BACA2@cederstrand.dk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG, Ulrich Sp?rlein Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:26:24 -0000 On Wed, Jan 05, 2011 at 09:22:42PM +0100, Erik Cederstrand wrote: > > Den 05/01/2011 kl. 17.55 skrev Ulrich Sp?rlein: > > > And clang did the right thing here in the past. Beware that it does no > > inter-procedural analysis yet, so it will usually miss that usage() > > calls exit unconditionally. > > > > *But*, it should grok that for err(3) and exit(3). Now there are some > > possible remedies: > > > > - get IPA to work with clang, or at least file a bug > > I filed a bug with LLVM (http://llvm.org/bugs/show_bug.cgi?id=8914) but it seems IPA bugs filed on the analyzer have been rejected in the past. I have a dumb patch that may help here... can someone test it? http://lev.vlakno.cz/~rdivacky/clang-checker-no-return.patch it may slow down the analysis a lot, if it does please add a recursion limit there... roman From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 21:30:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59A431065673; Wed, 5 Jan 2011 21:30:47 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id D9E858FC23; Wed, 5 Jan 2011 21:30:46 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p05LUhde052485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 22:30:43 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1294263043; bh=4nykzlMJdmy58KZIO4yhecwTXiSHh08tvUr7/rJFBiI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=jivSn2FCraFQTfF1k9wOfX7mFhoREn9q18zNNhvnQTiFEUuMlYTMTeimrIUTm6Dsr JvzevB/4xs5VZWEe/pKk7+f0OWu2g2JVgoTtbxHvORjuaxRGloEjIGEp/yGbLuQTrM TROHbimm61HHCG70w1dtM/1qSulTjFmSnZhHxuH8= Date: Wed, 5 Jan 2011 22:30:43 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Jilles Tjoelker Message-ID: <20110105213043.GT23329@acme.spoerlein.net> Mail-Followup-To: Jilles Tjoelker , John Baldwin , freebsd-current@freebsd.org, Erik Cederstrand References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> <20110105193653.GA49285@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110105193653.GA49285@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Erik Cederstrand Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:30:47 -0000 On Wed, 05.01.2011 at 20:36:53 +0100, Jilles Tjoelker wrote: > On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: > > On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: > > > These are all marked as __dead2, so the compiler should "know" that these do > > > not return. > > > And clang did the right thing here in the past. Beware that it does no > > inter-procedural analysis yet, so it will usually miss that usage() > > calls exit unconditionally. > > > *But*, it should grok that for err(3) and exit(3). Now there are some > > possible remedies: > > > - get IPA to work with clang, or at least file a bug > > > - mark functions as __dead2 (please don't do that) > > Why not? Cause IMHO it adds clutter, is noisy and needs to be maintained manually, when we have these "computer" things that should deduct this by themselves. > I have done this in some cases because it leads to better code with gcc > (the system version in 9-current). See SVN commit r212508 to > bin/sh/parser.c. Although synexpect() and synerror() are static, adding > __dead2 to both makes the executable 576 bytes smaller on i386 (these > functions are called many times). Adding __dead2 to synexpect() only > causes a warning "noreturn function does return" (it calls synerror()). > Adding __dead2 to synerror() only also makes the executable smaller but > not as much as adding it to both. > > Reordering the functions in the file does not help to make gcc see that > the functions do not return. This is too bad and really makes me sad. It shouldn't be necessary to hand-hold the compilers like that. Could you try some tests with gcc 4.5 to confirm this is still required? Uli From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 23:58:40 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D13A3106564A for ; Wed, 5 Jan 2011 23:58:40 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE308FC17 for ; Wed, 5 Jan 2011 23:58:39 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id ED33519E02F; Thu, 6 Jan 2011 00:40:11 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D310A19E02E; Thu, 6 Jan 2011 00:40:09 +0100 (CET) Message-ID: <4D250159.30108@quip.cz> Date: Thu, 06 Jan 2011 00:40:09 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 MIME-Version: 1.0 To: current@freebsd.org, =?ISO-8859-1?Q?Ulrich_Sp=F6rlein?= References: <20110105132155.GO23329@acme.spoerlein.net> <201101051800.p05I0V7k002583@fire.js.berklix.net> <20110105194748.GS23329@acme.spoerlein.net> In-Reply-To: <20110105194748.GS23329@acme.spoerlein.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Julian H. Stacey" Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:58:40 -0000 Ulrich Spörlein wrote: > On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: >> Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: >>> !ACHTUNG BIKESHED ALERT! >>> >>> Hello, >>> >>> With the recent changes to the committer graphs, I again was reminded >>> how much I hate the YYYY/MM/DD format (I can't help it ...). Given that >> >> I guess& hope you mean you like linear decreasing order but >> dislike '/' as a delimeter& want to swap from '/' to '-' as in ISO ? > > Exactly. > >>> this almost looks like ISO 8601, but is an unreadable variant of it, I >>> would like to aggressively change this throughout the tree. >>> >>> I'd like to start with minor stuff like share/misc/*.dot. Then probably >>> src/UPDATING, and ports/UPDATING after I've identified the consumers of >>> these docs. >> >> Do you mean you would like to swap eg src/UPDATING 20100720 to eg >> 2010-07-20 ? That would be more readable. > > Yes, I think for lists of dates like in UPDATING or automatically > generated date output like syslogd, the ISO8601 format only has > advantages. I am using ISO8601 date + time format for years in my scripts, logs etc., so it would be nice to have it on all places of FreeBSD as a standard format. I think 2010-07-20 is really readable than 20100720 or 2010/07/20 and "2011-01-06 00:03:50" is better than "Jan 6 00:03:50" (in logs) +1 Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 23:41:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48587106566B for ; Wed, 5 Jan 2011 23:41:02 +0000 (UTC) (envelope-from zhushazang@yahoo.com) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by mx1.freebsd.org (Postfix) with SMTP id 256668FC16 for ; Wed, 5 Jan 2011 23:41:02 +0000 (UTC) Received: from [98.139.91.63] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 23:27:33 -0000 Received: from [98.136.185.43] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 05 Jan 2011 23:27:33 -0000 Received: from [127.0.0.1] by smtp104.mail.gq1.yahoo.com with NNFMP; 05 Jan 2011 23:27:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294270053; bh=VWTYTaTO5GwGavXuZOZ4dVTJNo80MMDIBVinlP7nnQY=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=inayvsWatGCcglBbAdfK9sbQ6KPprjUAMNOGYHDxHVEyioLVcjt3jIKmbFf1nl0bMqH3xDzkYo2u8Gg5K2XB8VUOemMfasRsszvl79Zur4Jjwfc7BX4SNm87GGEYlT1FLTge1c0vX+iJV3xBv1zP17u88+mxH9IcOZDjYguQn7Q= X-Yahoo-Newman-Id: 434745.99422.bm@smtp104.mail.gq1.yahoo.com Received: from [172.16.0.160] (zhushazang@143.107.237.216 with plain) by smtp104.mail.gq1.yahoo.com with SMTP; 05 Jan 2011 15:27:30 -0800 PST X-Yahoo-SMTP: wVK5oRCswBA1lmVH9vtYmRrIUKN_46M- X-YMail-OSG: szcAG_QVM1noJug1KiM.jz92UdTVZHlm2dGjzVDV4QGdV_t HmCru7Si43bXYtxJGIPc73I1vYj17tmPQ0yfp.mz2YIThPqW5AA1CnCQYS98 XApIayFMtcQsH.fwAyJ_7eOqf4DQF9IpbHeYhdhOyfbW6nVJC6XGzYe5xlMf 7Y9zA13mEjBj5ONE3JHTlFprY_g2QYy_m3K7RdXcCl0FErkDL4Eh4ExFDTqD HpK9NQS_AZk4ku7Ukv2jgMf4MaFOiRS5tCIsyY2k6l.3DpPY0CVdrglEMl2U LAukEHPUdBatoSO2WpTGXDziYKQjixAFVon0zWPyuKNFB1_Geu5NgTfeCe4E fz7zAgiKi7RHs4AU9XPJiTYdq.3Q0PFngg59SbSYd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D24FE7D.1090000@yahoo.com> Date: Wed, 05 Jan 2011 21:27:57 -0200 From: Zhu Sha Zang User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110104 Lightning/1.0b3pre Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Jan 2011 00:00:42 +0000 Subject: system sleeping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:41:02 -0000 My 9-CURRENT system are sleeping randomly and i can't see any error in logs. There are a related bug with ACPI? And, sleeping include don't answer any tcp/ip connection like ssh or the simple work that i've installed he: a gateway. But, if someone touch the keyboard, everything "wake up" again. The system are installed over a old AMD Semprom (x86) machine. Thanks From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 01:25:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9DE7106566C for ; Thu, 6 Jan 2011 01:25:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 813D48FC0C for ; Thu, 6 Jan 2011 01:25:33 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4D38E5813A for ; Wed, 5 Jan 2011 18:57:16 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 7elWm7RoBnY0 for ; Wed, 5 Jan 2011 18:57:16 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id E998558139 for ; Wed, 5 Jan 2011 18:57:15 -0600 (CST) Message-ID: <4D25136A.4070107@freebsd.org> Date: Wed, 05 Jan 2011 18:57:14 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:25:33 -0000 As part of work on a new installer, I would like to update the base system dialog and libdialog to the newer one provided by Thomas Dickey (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a much nicer, fuller featured version of dialog that simplifies the creation of new dialog-using tools (a longstanding impediment to a new versions of sade, sysinstall, etc.), and is under a marginally better license (LGPL2 instead of GPL2). Patches to effect the import can be found at: - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff What the patches do: - Replaces dialog(1) with a new version. All command-line options of the old dialog except --fstree are accepted by the new dialog, and the ports options framework continues to work without modification. - Renames libdialog to libodialog (old dialog). The new dialog library has a much more pleasant API than the old one -- which directly implies that it has a substantially different API. Until sysinstall, sade, and tzsetup are replaced or rewritten, we need to keep the old library around. - Modifies sysinstall, sade, and tzsetup to link to libodialog instead of libdialog. - Deletes all man pages and examples associated with libodialog. This is deprecated code. - Installs new dialog library as libdialog - Bumps __FreeBSD_version to 900030 Layout of new files: - /usr/src/contrib/dialog -- contents of 20100428 release of dialog (the same as the current ports version) - /usr/src/gnu/lib/dialog -- new dialog library - /usr/src/gnu/lib/libodialog -- old dialog library - /usr/src/gnu/usr.bin/dialog -- new dialog binary I would appreciate any comments or adverse test results. If I hear nothing, I plan to commit this on Wednesday, January 12, one week from today. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 01:45:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71911106566C for ; Thu, 6 Jan 2011 01:45:36 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 49BAC8FC08 for ; Thu, 6 Jan 2011 01:45:36 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id B9F1758133 for ; Wed, 5 Jan 2011 19:45:35 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id T4o5BfbroEXP for ; Wed, 5 Jan 2011 19:45:35 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 6CDEB58137 for ; Wed, 5 Jan 2011 19:45:35 -0600 (CST) Message-ID: <4D251EBE.8030400@freebsd.org> Date: Wed, 05 Jan 2011 19:45:34 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4D25136A.4070107@freebsd.org> In-Reply-To: <4D25136A.4070107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:45:36 -0000 On 01/05/11 18:57, Nathan Whitehorn wrote: > > - /usr/src/gnu/lib/dialog -- new dialog library This was a typo. It should be /usr/src/gnu/lib/libdialog. Apologies for the noise. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 02:07:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB5DA106564A for ; Thu, 6 Jan 2011 02:07:08 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 818058FC08 for ; Thu, 6 Jan 2011 02:07:08 +0000 (UTC) Received: by wwf26 with SMTP id 26so15760676wwf.31 for ; Wed, 05 Jan 2011 18:07:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.144.205 with SMTP id n55mr150429wej.5.1294278140790; Wed, 05 Jan 2011 17:42:20 -0800 (PST) Received: by 10.216.241.11 with HTTP; Wed, 5 Jan 2011 17:42:20 -0800 (PST) X-Originating-IP: [128.95.133.155] In-Reply-To: <20110105132155.GO23329@acme.spoerlein.net> References: <20110105132155.GO23329@acme.spoerlein.net> Date: Wed, 5 Jan 2011 17:42:20 -0800 Message-ID: From: Rob Farmer To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:07:08 -0000 On Wed, Jan 5, 2011 at 05:21, Ulrich Sp=F6rlein wrote: > !ACHTUNG BIKESHED ALERT! > > Hello, > > With the recent changes to the committer graphs, I again was reminded > how much I hate the YYYY/MM/DD format (I can't help it ...). Given that > this almost looks like ISO 8601, but is an unreadable variant of it, I > would like to aggressively change this throughout the tree. > The current format is ISO 8601 compliant, because it allows omitting the hyphen for compactness in computer files that may be automatically processed. Also, adding the hyphen is a bit confusing, because many common (non-compliant) date systems use hyphens or slashes with the components in different orders. Omitting it is non-intuitive to everyone and thus least likely to cause confusion due to local assumptions in cases like 2001-01-02. --=20 Rob Farmer From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 08:01:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B9E8106566C; Thu, 6 Jan 2011 08:01:11 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id E4BCF8FC1B; Thu, 6 Jan 2011 08:01:10 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp3.one.com (Postfix) with ESMTP id 5CBE2240639E; Thu, 6 Jan 2011 08:01:08 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-140-313573145; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <20110105193653.GA49285@stack.nl> Date: Thu, 6 Jan 2011 09:01:09 +0100 Message-Id: <7FA66A47-CB15-4C22-8614-B58E986CFFA4@cederstrand.dk> References: <20110105131439.GN23329@acme.spoerlein.net> <4184C8F2-3C6D-46FB-8F10-DDEBA6DB1C35@cederstrand.dk> <201101050934.49845.jhb@freebsd.org> <20110105165545.GP23329@acme.spoerlein.net> <20110105193653.GA49285@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 08:01:11 -0000 --Apple-Mail-140-313573145 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: > On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp=F6rlein wrote: >> On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: >>> These are all marked as __dead2, so the compiler should "know" that = these do >>> not return. >=20 >> And clang did the right thing here in the past. Beware that it does = no >> inter-procedural analysis yet, so it will usually miss that usage() >> calls exit unconditionally. >=20 >> *But*, it should grok that for err(3) and exit(3). Now there are some >> possible remedies: >=20 >> - get IPA to work with clang, or at least file a bug >=20 >> - mark functions as __dead2 (please don't do that) >=20 > Why not? Because the analyzer is supposed to find bugs. Only the function that = really doesn't return should be marked as such. If we begin spewing = __dead2's everywhere, it's bound to silence a valid bug somewhere down = the line when e.g. a conditional in a print_help() function is changed = subtly so it doesn't always reach exit(). Erik= --Apple-Mail-140-313573145-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 10:19:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 130781065672; Thu, 6 Jan 2011 10:19:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D3CEE8FC18; Thu, 6 Jan 2011 10:19:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p06AJFGn009572; Thu, 6 Jan 2011 05:19:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p06AJF5a009567; Thu, 6 Jan 2011 10:19:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 6 Jan 2011 10:19:15 GMT Message-Id: <201101061019.p06AJF5a009567@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 10:19:17 -0000 TB --- 2011-01-06 08:29:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-06 08:29:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-06 08:29:16 - cleaning the object tree TB --- 2011-01-06 08:29:29 - cvsupping the source tree TB --- 2011-01-06 08:29:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-06 08:30:04 - building world TB --- 2011-01-06 08:30:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 08:30:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 08:30:04 - TARGET=powerpc TB --- 2011-01-06 08:30:04 - TARGET_ARCH=powerpc TB --- 2011-01-06 08:30:04 - TZ=UTC TB --- 2011-01-06 08:30:04 - __MAKE_CONF=/dev/null TB --- 2011-01-06 08:30:04 - cd /src TB --- 2011-01-06 08:30:04 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 6 08:30:05 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 6 10:06:32 UTC 2011 TB --- 2011-01-06 10:06:32 - generating LINT kernel config TB --- 2011-01-06 10:06:32 - cd /src/sys/powerpc/conf TB --- 2011-01-06 10:06:32 - /usr/bin/make -B LINT TB --- 2011-01-06 10:06:33 - building LINT kernel TB --- 2011-01-06 10:06:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 10:06:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 10:06:33 - TARGET=powerpc TB --- 2011-01-06 10:06:33 - TARGET_ARCH=powerpc TB --- 2011-01-06 10:06:33 - TZ=UTC TB --- 2011-01-06 10:06:33 - __MAKE_CONF=/dev/null TB --- 2011-01-06 10:06:33 - cd /src TB --- 2011-01-06 10:06:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 6 10:06:33 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/ps3/if_glc.c cc1: warnings being treated as errors /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr_filter': /src/sys/powerpc/ps3/if_glc.c:837: warning: implicit declaration of function 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c:837: warning: nested extern declaration of 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr': /src/sys/powerpc/ps3/if_glc.c:849: warning: implicit declaration of function 'atomic_readandclear_64' /src/sys/powerpc/ps3/if_glc.c:849: warning: nested extern declaration of 'atomic_readandclear_64' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-06 10:19:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-06 10:19:15 - ERROR: failed to build lint kernel TB --- 2011-01-06 10:19:15 - 5317.34 user 842.23 system 6598.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 11:22:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71EAD106566C for ; Thu, 6 Jan 2011 11:22:14 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 041198FC08 for ; Thu, 6 Jan 2011 11:22:13 +0000 (UTC) Received: from c83-255-61-120.bredband.comhem.se ([83.255.61.120]:50274 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.72) (envelope-from ) id 1Panii-0002cO-8g for freebsd-current@freebsd.org; Thu, 06 Jan 2011 12:09:31 +0100 Received: (qmail 32788 invoked from network); 6 Jan 2011 12:09:27 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 6 Jan 2011 12:09:27 +0100 Received: (qmail 75353 invoked by uid 1001); 6 Jan 2011 12:09:27 +0100 Date: Thu, 6 Jan 2011 12:09:27 +0100 From: Erik Trulsson To: Nathan Whitehorn Message-ID: <20110106110927.GA75316@owl.midgard.homeip.net> References: <4D25136A.4070107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D25136A.4070107@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: 83.255.61.120 X-Scan-Result: No virus found in message 1Panii-0002cO-8g. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Panii-0002cO-8g 3de9810693a528a7692911a085c241c0 Cc: freebsd-current@freebsd.org Subject: Re: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:22:14 -0000 On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: > As part of work on a new installer, I would like to update the base > system dialog and libdialog to the newer one provided by Thomas Dickey > (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a > much nicer, fuller featured version of dialog that simplifies the > creation of new dialog-using tools (a longstanding impediment to a new > versions of sade, sysinstall, etc.), and is under a marginally better > license (LGPL2 instead of GPL2). > > Patches to effect the import can be found at: > - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff > > What the patches do: > - Replaces dialog(1) with a new version. All command-line options of the > old dialog except --fstree are accepted by the new dialog, and the ports > options framework continues to work without modification. > - Renames libdialog to libodialog (old dialog). The new dialog library > has a much more pleasant API than the old one -- which directly implies > that it has a substantially different API. Until sysinstall, sade, and > tzsetup are replaced or rewritten, we need to keep the old library around. > - Modifies sysinstall, sade, and tzsetup to link to libodialog instead > of libdialog. > - Deletes all man pages and examples associated with libodialog. This is > deprecated code. > - Installs new dialog library as libdialog > - Bumps __FreeBSD_version to 900030 Are there any ports which link to the old version of libdialog, and if so, what will happen to them? Why not keep the old version as libdialog and instead use a new name for the new library (libndialog or whatever) ? (I am not saying you should do this - it is a real question.) -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 11:29:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1DC2106566B; Thu, 6 Jan 2011 11:29:17 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 8217F8FC0C; Thu, 6 Jan 2011 11:29:17 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9B7CEE8B45; Thu, 6 Jan 2011 11:29:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=S6d1Ua1WnYXm XkQCLAFJDOMG1Ds=; b=mkZGB8vYy2pR110b4WAZtfS2zMQHaQWHZtF81XLXqKgo TBIbvXJk4swV2n9MCH6/AirnF/UQwZU2MfYNhM2hQArzm5KSNwsRha5mLe1wE8US NFapdCldcOWKalDYM0LbXjBsgck9yk04vEg1eRrik4dJPO4iRkI4c0bx50/cEFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=Pph350 0smwMwMmZYrRb+g+r14jYLMywp6Qgf+t2ZJ8T6UFXgsmhoL2SiQ0bRmg4ssRuQib 2+M3jyX1b8NlvTY44Ps8VYph7SrCBGnuaRisS+M3EJVH7x7FQyXN5kpfEBBLszbq 8IUd4pq3IqJNYqG+C7WNoGSyUsUepSJ0gbo+k= Received: from unknown (client-86-27-23-77.glfd.adsl.virginmedia.com [86.27.23.77]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 519B1E72B1; Thu, 6 Jan 2011 11:29:16 +0000 (GMT) Date: Thu, 6 Jan 2011 11:29:05 +0000 From: Bruce Cran To: Erik Trulsson Message-ID: <20110106112905.0000135e@unknown> In-Reply-To: <20110106110927.GA75316@owl.midgard.homeip.net> References: <4D25136A.4070107@freebsd.org> <20110106110927.GA75316@owl.midgard.homeip.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:29:18 -0000 On Thu, 6 Jan 2011 12:09:27 +0100 Erik Trulsson wrote: > Why not keep the old version as libdialog and instead use a new name > for the new library (libndialog or whatever) ? > (I am not saying you should do this - it is a real question.) Because then we can never upgrade to a newer version of libdialog. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 14:17:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1905106564A for ; Thu, 6 Jan 2011 14:17:42 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 77F628FC0C for ; Thu, 6 Jan 2011 14:17:42 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id CE0D15811D; Thu, 6 Jan 2011 08:17:41 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 68LvTdQ94KyL; Thu, 6 Jan 2011 08:17:41 -0600 (CST) Received: from comporellon.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4E6AB5811B; Thu, 6 Jan 2011 08:17:41 -0600 (CST) Message-ID: <4D25CF04.5020605@freebsd.org> Date: Thu, 06 Jan 2011 08:17:40 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101214 Thunderbird/3.1.7 MIME-Version: 1.0 To: Erik Trulsson References: <4D25136A.4070107@freebsd.org> <20110106110927.GA75316@owl.midgard.homeip.net> In-Reply-To: <20110106110927.GA75316@owl.midgard.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:17:42 -0000 On 01/06/11 05:09, Erik Trulsson wrote: > On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: >> As part of work on a new installer, I would like to update the base >> system dialog and libdialog to the newer one provided by Thomas Dickey >> (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a >> much nicer, fuller featured version of dialog that simplifies the >> creation of new dialog-using tools (a longstanding impediment to a new >> versions of sade, sysinstall, etc.), and is under a marginally better >> license (LGPL2 instead of GPL2). >> >> Patches to effect the import can be found at: >> - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff >> >> What the patches do: >> - Replaces dialog(1) with a new version. All command-line options of the >> old dialog except --fstree are accepted by the new dialog, and the ports >> options framework continues to work without modification. >> - Renames libdialog to libodialog (old dialog). The new dialog library >> has a much more pleasant API than the old one -- which directly implies >> that it has a substantially different API. Until sysinstall, sade, and >> tzsetup are replaced or rewritten, we need to keep the old library around. >> - Modifies sysinstall, sade, and tzsetup to link to libodialog instead >> of libdialog. >> - Deletes all man pages and examples associated with libodialog. This is >> deprecated code. >> - Installs new dialog library as libdialog >> - Bumps __FreeBSD_version to 900030 > Are there any ports which link to the old version of libdialog, and if > so, what will happen to them? I could not find any, but the search was not amazingly thorough. The libdialog we had was entirely peculiar to FreeBSD, basically only for the use of sysinstall. Most external dialog-using things use dialog(1), which is compatible, and those that don't require the newer version I propose to import. > Why not keep the old version as libdialog and instead use a new name > for the new library (libndialog or whatever) ? > (I am not saying you should do this - it is a real question. Since I plan to immediately replace dialog(1), and libodialog is immediately deprecated, renaming the old library seemed to simplify things substantially. Having libdialog under its standard name reducing the need for patching it, patching dependent ports, and confusion. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 15:09:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86011106564A; Thu, 6 Jan 2011 15:09:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57D998FC1C; Thu, 6 Jan 2011 15:09:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1162B46B49; Thu, 6 Jan 2011 10:09:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3147A8A009; Thu, 6 Jan 2011 10:09:04 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 6 Jan 2011 07:52:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110105132155.GO23329@acme.spoerlein.net> <20110105194748.GS23329@acme.spoerlein.net> <4D250159.30108@quip.cz> In-Reply-To: <4D250159.30108@quip.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101060752.32539.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 06 Jan 2011 10:09:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ulrich, Miroslav Lachman <000.fbsd@quip.cz>, "Julian H. Stacey" , current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:09:05 -0000 On Wednesday, January 05, 2011 6:40:09 pm Miroslav Lachman wrote: > Ulrich Sp=F6rlein wrote: > > On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: > >> Ulrich =3D?utf-8?B?U3DDtnJsZWlu?=3D wrote: > >>> !ACHTUNG BIKESHED ALERT! > >>> > >>> Hello, > >>> > >>> With the recent changes to the committer graphs, I again was reminded > >>> how much I hate the YYYY/MM/DD format (I can't help it ...). Given th= at > >> > >> I guess& hope you mean you like linear decreasing order but > >> dislike '/' as a delimeter& want to swap from '/' to '-' as in ISO ? > > > > Exactly. > > > >>> this almost looks like ISO 8601, but is an unreadable variant of it, I > >>> would like to aggressively change this throughout the tree. > >>> > >>> I'd like to start with minor stuff like share/misc/*.dot. Then probab= ly > >>> src/UPDATING, and ports/UPDATING after I've identified the consumers = of > >>> these docs. > >> > >> Do you mean you would like to swap eg src/UPDATING 20100720 to eg > >> 2010-07-20 ? That would be more readable. > > > > Yes, I think for lists of dates like in UPDATING or automatically > > generated date output like syslogd, the ISO8601 format only has > > advantages. >=20 > I am using ISO8601 date + time format for years in my scripts, logs=20 > etc., so it would be nice to have it on all places of FreeBSD as a=20 > standard format. > I think 2010-07-20 is really readable than 20100720 or 2010/07/20 and=20 > "2011-01-06 00:03:50" is better than "Jan 6 00:03:50" (in logs) Changing the format of syslog messages is guaranteed to break ${INFINITY}=20 scripts and other log parsing tools. I think that is too large of a POLA=20 violation to justify. I also don't find the format used in UPDATING that hard to read as I use it= on=20 an almost daily basis myself. Given that the format in UPDATING is already= =20 compliant, this mostly seems to be a gratuitous change. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 15:09:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86011106564A; Thu, 6 Jan 2011 15:09:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57D998FC1C; Thu, 6 Jan 2011 15:09:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1162B46B49; Thu, 6 Jan 2011 10:09:05 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3147A8A009; Thu, 6 Jan 2011 10:09:04 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 6 Jan 2011 07:52:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20110105132155.GO23329@acme.spoerlein.net> <20110105194748.GS23329@acme.spoerlein.net> <4D250159.30108@quip.cz> In-Reply-To: <4D250159.30108@quip.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201101060752.32539.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 06 Jan 2011 10:09:04 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ulrich, Miroslav Lachman <000.fbsd@quip.cz>, "Julian H. Stacey" , current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:09:05 -0000 On Wednesday, January 05, 2011 6:40:09 pm Miroslav Lachman wrote: > Ulrich Sp=F6rlein wrote: > > On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: > >> Ulrich =3D?utf-8?B?U3DDtnJsZWlu?=3D wrote: > >>> !ACHTUNG BIKESHED ALERT! > >>> > >>> Hello, > >>> > >>> With the recent changes to the committer graphs, I again was reminded > >>> how much I hate the YYYY/MM/DD format (I can't help it ...). Given th= at > >> > >> I guess& hope you mean you like linear decreasing order but > >> dislike '/' as a delimeter& want to swap from '/' to '-' as in ISO ? > > > > Exactly. > > > >>> this almost looks like ISO 8601, but is an unreadable variant of it, I > >>> would like to aggressively change this throughout the tree. > >>> > >>> I'd like to start with minor stuff like share/misc/*.dot. Then probab= ly > >>> src/UPDATING, and ports/UPDATING after I've identified the consumers = of > >>> these docs. > >> > >> Do you mean you would like to swap eg src/UPDATING 20100720 to eg > >> 2010-07-20 ? That would be more readable. > > > > Yes, I think for lists of dates like in UPDATING or automatically > > generated date output like syslogd, the ISO8601 format only has > > advantages. >=20 > I am using ISO8601 date + time format for years in my scripts, logs=20 > etc., so it would be nice to have it on all places of FreeBSD as a=20 > standard format. > I think 2010-07-20 is really readable than 20100720 or 2010/07/20 and=20 > "2011-01-06 00:03:50" is better than "Jan 6 00:03:50" (in logs) Changing the format of syslog messages is guaranteed to break ${INFINITY}=20 scripts and other log parsing tools. I think that is too large of a POLA=20 violation to justify. I also don't find the format used in UPDATING that hard to read as I use it= on=20 an almost daily basis myself. Given that the format in UPDATING is already= =20 compliant, this mostly seems to be a gratuitous change. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 15:09:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 727161065672; Thu, 6 Jan 2011 15:09:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 461938FC16; Thu, 6 Jan 2011 15:09:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0227246B39; Thu, 6 Jan 2011 10:09:07 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0EF108A027; Thu, 6 Jan 2011 10:09:06 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 6 Jan 2011 07:54:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4D25136A.4070107@freebsd.org> <20110106110927.GA75316@owl.midgard.homeip.net> In-Reply-To: <20110106110927.GA75316@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101060754.38140.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 06 Jan 2011 10:09:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Nathan Whitehorn Subject: Re: Request for testing/comments -- import of new dialog/libdialog X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:09:07 -0000 On Thursday, January 06, 2011 6:09:27 am Erik Trulsson wrote: > On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: > > As part of work on a new installer, I would like to update the base > > system dialog and libdialog to the newer one provided by Thomas Dickey > > (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a > > much nicer, fuller featured version of dialog that simplifies the > > creation of new dialog-using tools (a longstanding impediment to a new > > versions of sade, sysinstall, etc.), and is under a marginally better > > license (LGPL2 instead of GPL2). > > > > Patches to effect the import can be found at: > > - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff > > > > What the patches do: > > - Replaces dialog(1) with a new version. All command-line options of the > > old dialog except --fstree are accepted by the new dialog, and the ports > > options framework continues to work without modification. > > - Renames libdialog to libodialog (old dialog). The new dialog library > > has a much more pleasant API than the old one -- which directly implies > > that it has a substantially different API. Until sysinstall, sade, and > > tzsetup are replaced or rewritten, we need to keep the old library around. > > - Modifies sysinstall, sade, and tzsetup to link to libodialog instead > > of libdialog. > > - Deletes all man pages and examples associated with libodialog. This is > > deprecated code. > > - Installs new dialog library as libdialog > > - Bumps __FreeBSD_version to 900030 > > Are there any ports which link to the old version of libdialog, and if > so, what will happen to them? I think we should probably work on porting the existing libdialog consumers in the tree to the new version and then retire libodialog completely. We could then have a port of the old library for any ports that need it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 15:34:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF4C106564A; Thu, 6 Jan 2011 15:34:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 85DEA8FC14; Thu, 6 Jan 2011 15:34:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p06FYG4C058081; Thu, 6 Jan 2011 10:34:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p06FYGlJ058072; Thu, 6 Jan 2011 15:34:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 6 Jan 2011 15:34:16 GMT Message-Id: <201101061534.p06FYGlJ058072@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:34:17 -0000 TB --- 2011-01-06 13:44:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-06 13:44:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-01-06 13:44:16 - cleaning the object tree TB --- 2011-01-06 13:44:24 - cvsupping the source tree TB --- 2011-01-06 13:44:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-01-06 13:45:23 - building world TB --- 2011-01-06 13:45:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 13:45:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 13:45:23 - TARGET=powerpc TB --- 2011-01-06 13:45:23 - TARGET_ARCH=powerpc TB --- 2011-01-06 13:45:23 - TZ=UTC TB --- 2011-01-06 13:45:23 - __MAKE_CONF=/dev/null TB --- 2011-01-06 13:45:23 - cd /src TB --- 2011-01-06 13:45:23 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 6 13:45:24 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 6 15:21:36 UTC 2011 TB --- 2011-01-06 15:21:36 - generating LINT kernel config TB --- 2011-01-06 15:21:36 - cd /src/sys/powerpc/conf TB --- 2011-01-06 15:21:36 - /usr/bin/make -B LINT TB --- 2011-01-06 15:21:36 - building LINT kernel TB --- 2011-01-06 15:21:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-06 15:21:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-06 15:21:36 - TARGET=powerpc TB --- 2011-01-06 15:21:36 - TARGET_ARCH=powerpc TB --- 2011-01-06 15:21:36 - TZ=UTC TB --- 2011-01-06 15:21:36 - __MAKE_CONF=/dev/null TB --- 2011-01-06 15:21:36 - cd /src TB --- 2011-01-06 15:21:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 6 15:21:36 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/ps3/if_glc.c cc1: warnings being treated as errors /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr_filter': /src/sys/powerpc/ps3/if_glc.c:837: warning: implicit declaration of function 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c:837: warning: nested extern declaration of 'atomic_set_64' /src/sys/powerpc/ps3/if_glc.c: In function 'glc_intr': /src/sys/powerpc/ps3/if_glc.c:849: warning: implicit declaration of function 'atomic_readandclear_64' /src/sys/powerpc/ps3/if_glc.c:849: warning: nested extern declaration of 'atomic_readandclear_64' *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-06 15:34:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-06 15:34:15 - ERROR: failed to build lint kernel TB --- 2011-01-06 15:34:15 - 5317.41 user 834.84 system 6599.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 15:45:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9084106566C for ; Thu, 6 Jan 2011 15:45:40 +0000 (UTC) (envelope-from lists@mschuette.name) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [IPv6:2001:638:807:3a:20d:56ff:fefd:1183]) by mx1.freebsd.org (Postfix) with ESMTP id 46BF98FC23 for ; Thu, 6 Jan 2011 15:45:40 +0000 (UTC) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [IPv6:2001:638:807:3a:20d:56ff:fefd:1183]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 3FB7D502436 for ; Thu, 6 Jan 2011 16:45:39 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id 0oFN1GYu-lBe for ; Thu, 6 Jan 2011 16:45:32 +0100 (CET) Received: from dagny.mschuette.name (cl-485.dus-01.de.sixxs.net [IPv6:2a01:198:200:1e4::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) (Authenticated sender: mschuett) by mail.asta.uni-potsdam.de (Postfix) with ESMTPSA id 95F4E502435 for ; Thu, 6 Jan 2011 16:45:32 +0100 (CET) Message-ID: <4D25E39B.2050804@mschuette.name> Date: Thu, 06 Jan 2011 16:45:31 +0100 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.13) Gecko/20101230 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110105132155.GO23329@acme.spoerlein.net> <20110105194748.GS23329@acme.spoerlein.net> <4D250159.30108@quip.cz> <201101060752.32539.jhb@freebsd.org> In-Reply-To: <201101060752.32539.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:45:40 -0000 On 01/06/11 13:52, John Baldwin wrote: >> I am using ISO8601 date + time format for years in my scripts, logs >> etc., so it would be nice to have it on all places of FreeBSD as a >> standard format. > Changing the format of syslog messages is guaranteed to break ${INFINITY} > scripts and other log parsing tools. I think that is too large of a POLA > violation to justify. On the other ahnd there is also a new syslog RFC which uses ISO8601 timestamps (http://tools.ietf.org/html/rfc5424) and is implemented by syslog-ng, rsyslog and NetBSD-current. As with most major changes the format should be configurable and use the old format as default. But in the long term I would expect the new format to spread (maybe just because I use it on my logserver and already changed my parsing tools). -- Martin From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 17:27:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD00106566B for ; Thu, 6 Jan 2011 17:27:19 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 387938FC18 for ; Thu, 6 Jan 2011 17:27:18 +0000 (UTC) Received: by fxm16 with SMTP id 16so16121120fxm.13 for ; Thu, 06 Jan 2011 09:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=Tq6XNEKddbKuGI7lMLb5r6Ech77yeGH07PEo6rB2lhQ=; b=Tzm+SN1PoZ9oJsi9ieAO6tFw+FJWMuNdE4mDPqjPL1tCOuGPrNCOrfW5el8dL008nd 43oP0LcUyCzua6se6uhTIL8z9aAjoHXQLJXxeyvhef6MtJ/8YHq6kU+7vuxRrV+cpHdW joLoeLDTAGtQ/g7RP2l5lFhxuwrmOhpI/Y24Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=Mm1oseYsock4tkYAtDCrwWQaNZR/yArjWGg3uw23uTkmOFpnR644sd8lOsWV+WhmB/ 3D1XnRVi/ltbgZwl7/Nyfv8CMph3t87aqOhv+aPQztNwsIQ5hhj+6w33RJu6rWMAOr5h g1h2Ap+OGQ+jl7J19SqiDxFvFZXKyT61g4OcM= Received: by 10.223.96.6 with SMTP id f6mr122083fan.132.1294332954637; Thu, 06 Jan 2011 08:55:54 -0800 (PST) Received: from ernst.jennejohn.org (p578E243A.dip.t-dialin.net [87.142.36.58]) by mx.google.com with ESMTPS id 5sm5910754fak.23.2011.01.06.08.55.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 08:55:53 -0800 (PST) Date: Thu, 6 Jan 2011 17:55:50 +0100 From: Gary Jennejohn To: Ulrich =?ISO-8859-1?Q?Sp=F6rlein?= Message-ID: <20110106175550.092759c4@ernst.jennejohn.org> In-Reply-To: <20110105194748.GS23329@acme.spoerlein.net> References: <20110105132155.GO23329@acme.spoerlein.net> <201101051800.p05I0V7k002583@fire.js.berklix.net> <20110105194748.GS23329@acme.spoerlein.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "Julian H. Stacey" , current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:27:19 -0000 On Wed, 5 Jan 2011 20:47:49 +0100 Ulrich Spörlein wrote: > > I've long had a mental note to get round to fixing isnd which emits: > > "05.01.2011 13:15:06" > > To > > "2011-01-05 13:15:06" > > Hehe, isdnd was written by a German, it seems :) > How quickly the world forgets :( isdnd was developed by hm@. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 17:48:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666421065675 for ; Thu, 6 Jan 2011 17:48:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id C9FC38FC1E for ; Thu, 6 Jan 2011 17:48:21 +0000 (UTC) Received: from park.js.berklix.net (p5B22DE60.dip.t-dialin.net [91.34.222.96]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p06HmIJQ026865; Thu, 6 Jan 2011 17:48:19 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p06HmpDY034791; Thu, 6 Jan 2011 18:48:51 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id p06Hmaeh052118; Thu, 6 Jan 2011 18:48:41 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201101061748.p06Hmaeh052118@fire.js.berklix.net> To: gljennjohn@googlemail.com From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 06 Jan 2011 17:55:50 +0100." <20110106175550.092759c4@ernst.jennejohn.org> Date: Thu, 06 Jan 2011 18:48:36 +0100 Sender: jhs@berklix.com Cc: current@freebsd.org Subject: Re: RFC regarding usage of ISO 8601 throughout the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:48:22 -0000 Gary Jennejohn wrote: > On Wed, 5 Jan 2011 20:47:49 +0100 > Ulrich Spörlein wrote: > > > > I've long had a mental note to get round to fixing isnd which emits: > > > "05.01.2011 13:15:06" > > > To > > > "2011-01-05 13:15:06" > > > > Hehe, isdnd was written by a German, it seems :) > > How quickly the world forgets :( isdnd was developed by hm@. How quickly the world spins ;-) Hellmuth's http://kts.org --> http://people.freebsd.org/~hm/i4b-home/ Last edit-date: Nov 2001 Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses. From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 20:26:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E3B106564A for ; Thu, 6 Jan 2011 20:26:17 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay003.isp.belgacom.be (mailrelay003.isp.belgacom.be [195.238.6.53]) by mx1.freebsd.org (Postfix) with ESMTP id CEBB28FC08 for ; Thu, 6 Jan 2011 20:26:16 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsFALSsJU1bsdOk/2dsb2JhbACWEI4OdL4FhUwE Received: from 164.211-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.211.164]) by relay.skynet.be with ESMTP; 06 Jan 2011 20:56:58 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id p06JuvZ0007746 for ; Thu, 6 Jan 2011 20:56:57 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Thu, 6 Jan 2011 20:56:49 +0100 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.2; i386; ; ) References: <20110105131439.GN23329@acme.spoerlein.net> <20110105193653.GA49285@stack.nl> <7FA66A47-CB15-4C22-8614-B58E986CFFA4@cederstrand.dk> In-Reply-To: <7FA66A47-CB15-4C22-8614-B58E986CFFA4@cederstrand.dk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5939611.85pHghQyDQ"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201101062056.55807.tijl@coosemans.org> Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:26:17 -0000 --nextPart5939611.85pHghQyDQ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: > Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: >> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp=F6rlein wrote: >>> On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: >>>> These are all marked as __dead2, so the compiler should "know" that th= ese do >>>> not return. >>>=20 >>> And clang did the right thing here in the past. Beware that it does no >>> inter-procedural analysis yet, so it will usually miss that usage() >>> calls exit unconditionally. >>>=20 >>> *But*, it should grok that for err(3) and exit(3). Now there are some >>> possible remedies: >>>=20 >>> - get IPA to work with clang, or at least file a bug >>> - mark functions as __dead2 (please don't do that) >>=20 >> Why not? >=20 > Because the analyzer is supposed to find bugs. Only the function that > really doesn't return should be marked as such. If we begin spewing > __dead2's everywhere, it's bound to silence a valid bug somewhere > down the line when e.g. a conditional in a print_help() function is > changed subtly so it doesn't always reach exit(). On the other hand you can't really expect the compiler/analyser to know what a procedure in another file does, so in that case you need __dead2 anyway. For procedures in the same file it would be nice if the compiler automatically optimised non-returning calls, but I'm not sure the analyser should do that. If the code relies on the fact that a procedure doesn't return, which is the case here, it's a good thing to declare it as such exactly to prevent bugs from creeping in. You can't add a return statement to a non-returning procedure without the compiler complaining about it and I'm sure the analyser would complain about it as well. So you won't be hiding other bugs by adding __dead2 here and there. --nextPart5939611.85pHghQyDQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iF4EABEIAAYFAk0mHocACgkQfoCS2CCgtiuTrwEAhgdh9cpPFD4/Rk7UixjBaCcO ScEq/6b7K7VkWhgn74gA/2NbkpKAbZsjL+ZIntFyXx8vgXH83zVf0h7ueofLExL+ =C1aR -----END PGP SIGNATURE----- --nextPart5939611.85pHghQyDQ-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 21:53:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEAC81065670 for ; Thu, 6 Jan 2011 21:53:02 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A83198FC15 for ; Thu, 6 Jan 2011 21:53:02 +0000 (UTC) Received: by qwj9 with SMTP id 9so16554637qwj.13 for ; Thu, 06 Jan 2011 13:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=O1vkaMpE7fex/z79htLgA0RBEO0DypJYyxJ6oTauATo=; b=mINZz46VT9ycVGRIv5Dc+0Y0vwpH2E4nq8KvnNSSjwpsZyUxhaiNq7zaYOcYvHkKue QttVu/7XDcHVRMDMavv/jc0JgfD24ozOYdAxWiNZuQjDx/Pgdm5aafsHvZAymK30mfak T+9PHgE0KF+t4WbrUeUCHicr5whrc59Fm+K5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=dtJhU6SbT6GGF5vgKajc66TzYkCJwRudh++YCmPM/rbriQkH+2Ws2/+P/mELSAZ0qc z8dLfUW5QdpYlLcEUCqWLULW3yVgJJaJqqBlCOf+rAqg0jM1mTedI8jHp5F5pLKz3rnl RvPH/NDFbq2JmWU3lf4KWHc4qk3O3GNnOsLF0= Received: by 10.224.67.75 with SMTP id q11mr23878780qai.3.1294349445872; Thu, 06 Jan 2011 13:30:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.87.4 with HTTP; Thu, 6 Jan 2011 13:30:25 -0800 (PST) In-Reply-To: <4A4ACB13-5EF4-4118-95BF-B8B40389A081@gmail.com> References: <1880316.880341293477607558.JavaMail.defaultUser@defaultHost> <4A4ACB13-5EF4-4118-95BF-B8B40389A081@gmail.com> From: Krzysztof Dajka Date: Thu, 6 Jan 2011 22:30:25 +0100 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Nikolay Denev , Barbara Subject: Re: ahci timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:53:03 -0000 I'm having these problems either. I'm running 8.2-PRERELEASE #0 r216555: Sun Dec 19 12:10:37. With only one disk connected: [FreeBSD:~] # camcontrol devlist at scbus0 target 0 lun 0 (pass1,ada0) Everything is fine. Sometimes after reconnecting drive to other Marvell bus and using: camcontrol reset/rescan I'm getting ahci timeouts. But after that system runs fine. I had problems connecting my 4xraidz1 zpool to Asus Hummingbird motherboard= : ahci0: on atapci0 ahci1: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xfbcfbc00-0xfbcfbfff irq 21 at device 31.2 on pci0 Two disk are connected to Intel controller and another two to Marvell. I never had done anything more than importing pool and list files. After while I see ahci timeouts on Marvell controller. On Wed, Dec 29, 2010 at 5:09 PM, Nikolay Denev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 27 Dec, 2010, at 21:20 , Barbara wrote: > >> >> As my old PATA hard disk was failing, I had to replace it with a new SAT= A >> drive where I moved my FreeBSDs installations, as PATA drives are not ea= sy to >> find these days. >> So I had to move one of my data drive from a VIA8237A SATA controller to= the >> last free SATA slot on a Marvell 88SX6121 to make room for the new hd. >> The hd I moved was working perfectly when connected to the VIA controlle= r. >> Now, with the Marvell I'm getting messages like the following twos while= using >> the disk: >> =C2=A0 =C2=A0ahcich0: Timeout on slot 10 >> =C2=A0 =C2=A0ahcich0: is 00000000 cs 3ffff800 ss 3ffffc00 rs 3ffffc00 tf= d 50010040 serr >> 00000000 >> >> =C2=A0 =C2=A0ahcich0: Timeout on slot 5 >> =C2=A0 =C2=A0ahcich0: is 00000000 cs 00000180 ss 000001e0 rs 000001e0 tf= d 50040040 serr >> 00000000 >> >> This doesn't happen regularly. For example downloading from a slow websi= te on >> it, so few kb/s, is ok. >> But if I copy files from the disk attacked to the Marvell controller to >> another another disk, or for example run md5 on some files, it's very li= kely to >> happen. >> The process accessing the disk can not be killed even with -9, ^C does >> nothing, and umount doesn't exit. >> If I'm copying files on it from another disk it can't be unmounted too a= s the >> unkillable process has it in use. >> On shutdown many disk doesn't get unmounted, so there are a lot of fsck = on >> boot, and on CURRENT (last built yesterday), FreeBSD enter debugger as i= t fail >> flushing disk caches. >> >> Relevant part from dmesg: >> >> atapci0: port 0xdc00-0xdc07,0xd880= - >> 0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdffc00-0xfbdfff= ff irq >> 28 at device 0.0 on pci6 >> ahci0: on atapci0 >> ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported >> ahcich0: at channel 0 on ahci0 >> ahcich1: at channel 1 on ahci0 >> ata2: on atapci0 >> atapci1: port 0xbc00-0xbc07,0xb880-0xb883= , >> 0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f,0xb000-0xb0ff irq 21 at device= 15.0 >> on pci0 >> ata3: on atapci1 >> ata4: on atapci1 >> atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77, >> 0x376,0xfc00-0xfc0f at device 15.1 on pci0 >> ata0: on atapci2 >> ata1: on atapci2 >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada1 at ata3 bus 0 scbus3 target 0 lun 0 >> ada1: ATA-7 SATA 2.x device >> ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) >> ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) >> ada2 at ata4 bus 0 scbus4 target 0 lun 0 >> ada2: ATA-8 SATA 1.x device >> ada2: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) >> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada3 at ata0 bus 0 scbus5 target 0 lun 0 >> ada3: ATA-7 device >> ada3: 100.000MB/s transfers (UDMA5, PIO 8192bytes) >> ada3: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" > > Just to add a "me too". > > I'm running -STABLE but have the same problems with Marvell 88SX6121 givi= ng "ahci timeout" messages. > > Regards, > Nikolay > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (Darwin) > > iEYEARECAAYFAk0bXUwACgkQHNAJ/fLbfrnWbQCdHQtnxDHkv0GXV5+gL3/qo46e > Q1YAn3eQkCbQ95WRiWG1+ELMEzKXRFT9 > =3DzG6+ > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 22:22:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3911065674 for ; Thu, 6 Jan 2011 22:22:09 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 83E3D8FC19 for ; Thu, 6 Jan 2011 22:22:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LEM00H02E0XSE00@smtpauth3.wiscmail.wisc.edu>; Thu, 06 Jan 2011 15:22:09 -0600 (CST) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LEM00GJTE0USX00@smtpauth3.wiscmail.wisc.edu>; Thu, 06 Jan 2011 15:22:06 -0600 (CST) Date: Thu, 06 Jan 2011 15:22:06 -0600 From: Nathan Whitehorn To: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org Message-id: <4D26327E.7070307@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-10, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.6.210916, SenderIP=128.104.160.176 User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.13) Gecko/20110104 Thunderbird/3.1.7 Cc: Subject: [ANNOUNCE] Playstation 3 support now in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:22:09 -0000 Yesterday, I imported support for the Sony Playstation 3 into our 64-bit PowerPC port, expanding our game console support into the current generation. There are still a few rough edges due to missing hardware support, but the machine boots and runs FreeBSD stably. These rough edges should be smoothed out in time for the 9.0 release. Thanks to Peter Grehan for donating the hardware that made this port possible. -Nathan Supported hardware: - Sony Playstation 3 Fat, firmware version< 3.21 - Netbooting only - 480i/480p only Instructions: The PS3 must be netbooted. First, acquire and install a copy of Petitboot from http://ozlabs.org/~jk/projects/petitboot/ Next, set up a second machine with DHCP, NFS, and TFTP. Setup DHCP to netboot loader.ps3 over TFTP, with the root path pointing to an NFS directory. DHCP Setup: host ps3 { hardware ethernet XX:XX:XX:XX:XX:XX; filename "/loader.ps3"; option host-name "ps3"; next-server 10.0.1.37; option root-path "10.0.1.37:/usr/netboot-ps3"; } NFS setup: mkdir /usr/netboot-ps3 cd /usr/src make buildworld installworld distribution TARGET=powerpc TARGET_ARCH=powerpc64 DESTDIR=/usr/netboot-ps3 Then share /usr/netboot-ps3 read/write over NFS with the PS3. Connect a monitor set to 480i or 480p to the video output, and boot! From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 22:59:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66031106566B for ; Thu, 6 Jan 2011 22:59:09 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id F34468FC14 for ; Thu, 6 Jan 2011 22:59:08 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id A6E5D1BC006BA; Thu, 6 Jan 2011 22:59:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-216-367451071; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <201101062056.55807.tijl@coosemans.org> Date: Thu, 6 Jan 2011 23:59:07 +0100 Message-Id: <1EF28C3A-954D-4A4B-8069-F0E767EF3669@cederstrand.dk> References: <20110105131439.GN23329@acme.spoerlein.net> <20110105193653.GA49285@stack.nl> <7FA66A47-CB15-4C22-8614-B58E986CFFA4@cederstrand.dk> <201101062056.55807.tijl@coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:59:09 -0000 --Apple-Mail-216-367451071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Den 06/01/2011 kl. 20.56 skrev Tijl Coosemans: > On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: >> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: >>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp=F6rlein wrote: >>>> - get IPA to work with clang, or at least file a bug >>>> - mark functions as __dead2 (please don't do that) >>>=20 >>> Why not? >>=20 >> Because the analyzer is supposed to find bugs. Only the function that >> really doesn't return should be marked as such. If we begin spewing >> __dead2's everywhere, it's bound to silence a valid bug somewhere >> down the line when e.g. a conditional in a print_help() function is >> changed subtly so it doesn't always reach exit(). >=20 > On the other hand you can't really expect the compiler/analyser to = know > what a procedure in another file does, so in that case you need = __dead2 > anyway. [...] I have high expectations of LLVM :-) LLVM already has some knowledge of = what's going on in other files (see LTO) so why shouldn't it be able to = detect the __noreturn__ ? All the necessary information should be = readily available. Erik= --Apple-Mail-216-367451071-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 23:30:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CAC7106564A for ; Thu, 6 Jan 2011 23:30:25 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3878FC1C for ; Thu, 6 Jan 2011 23:30:24 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 8055 invoked from network); 7 Jan 2011 00:03:44 +0100 Received: from cwx170.internetdsl.tpnet.pl (HELO marekdesktop) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 7 Jan 2011 00:03:44 +0100 Message-ID: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> From: "Marek Salwerowicz" To: Date: Fri, 7 Jan 2011 00:03:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EYJm] X-Mailman-Approved-At: Thu, 06 Jan 2011 23:53:08 +0000 Subject: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:30:25 -0000 Hi all, I am trying to run NFSv4 client on 64bit FreeBSD 9.0-Current. I have inserted into /etc/rc.conf following lines: nfsuserd_enable="YES" nfscbd_enable="YES" and after restart, during boot there is a meesage: Jan 6 23:50:56 vm-salwerom root: /etc/rc: WARNING: failed to start nfsuserd Jan 6 23:50:56 vm-salwerom kernel: KLD nfscommon.ko: depends on nfssvc - not available or version mismatch Jan 6 23:50:56 vm-salwerom kernel: linker_load_file: Unsupported file type Jan 6 23:50:59 vm-salwerom root: /etc/rc: WARNING: failed to start nfscbd Jan 6 23:50:59 vm-salwerom kernel: KLD nfscl.ko: depends on nfssvc - not available or version mismatch Jan 6 23:50:59 vm-salwerom kernel: linker_load_file: Unsupported file type the file nfssvc exists: vm-salwerom% ls /boot/kernel/nfss* /boot/kernel/nfsserver.ko /boot/kernel/nfssvc.ko Is there a problem with kernel modules or something else? -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 05:09:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920141065675 for ; Fri, 7 Jan 2011 05:09:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id EDC518FC0C for ; Fri, 7 Jan 2011 05:09:06 +0000 (UTC) Received: by wwf26 with SMTP id 26so16872272wwf.31 for ; Thu, 06 Jan 2011 21:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0sdUYY0YU19YUn4lvOoxHTVgY7VUT2IHMVfkwdVb9xY=; b=u8wNVKzn66jMQ+vdPls+ku8o/frG0s68TAl17LqfaCKAD8IQklf6oqRXXpEN3/1jF6 9ce8zdl39EBwkuEGvvpRpVZItjbmRVrO2ZiDeSaJAcqL2+FtBz1rgBosOgr6rqoII4IQ sYLZn8qij9f9vN//Kb8Q+F5wVWd5ArciLUMJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=r6S9ulCT3hYvTXmn3ukObQuswy1zqXfrS29TXj+16vFQXcUV32Z+EH4bsoQprNxwTj fVR4PhVw7ngAccGExZPi9W+GFppTfEaeg2OJMQ17h5q47+fxP8fqnvU6avYhUmu9HdCY qgrOJKWPEhGLHNZrTVgtOvWFjIYkwmzkZoHCo= MIME-Version: 1.0 Received: by 10.216.141.37 with SMTP id f37mr9965720wej.31.1294376945561; Thu, 06 Jan 2011 21:09:05 -0800 (PST) Sender: yanegomi@gmail.com Received: by 10.216.254.226 with HTTP; Thu, 6 Jan 2011 21:09:05 -0800 (PST) In-Reply-To: <4D269B72.4040709@ee.lbl.gov> References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> Date: Thu, 6 Jan 2011 21:09:05 -0800 X-Google-Sender-Auth: mW2XIN9NB2zw_tBwFW7ksTMZ4TM Message-ID: From: Garrett Cooper To: Craig Leres Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Ed Schouten Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:09:07 -0000 On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote: > On 01/06/11 20:05, Garrett Cooper wrote: >> Just to make sure we're both on the same page: >> >> $ grep xterm /etc/ttys >> ttyv0 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv1 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv2 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv3 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv4 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv5 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv6 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv7 "/usr/libexec/getty Pc" =A0 =A0 =A0 =A0 xterm =A0 on =A0secure >> ttyv8 "/usr/local/bin/xdm -nodaemon" =A0xterm =A0 off secure > > No, that's not what mine looks like. I changed it to match and rebooted > but it doesn't help with the TIOCCONS issue. > > When I run xinit, it starts up the xterm -C which does a TIOCCONS. The > 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the > request: > > =A0 =A0 =A0 =A0case TIOCCONS: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Set terminal as console TTY. */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (*(int *)data) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D priv_check(td, P= RIV_TTY_CONSOLE); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (er= ror); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * XXX: constty should rea= lly need to be locked! > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * XXX: allow disconnected= constty's to be stolen! > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (constty =3D=3D tp) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0)= ; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (constty !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EB= USY); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tty_unlock(tp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constty_set(tp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tty_lock(tp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (constty =3D=3D tp) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constty_clear(); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > > There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE > in any case. You could rewrite the above like this: > > =A0 =A0 =A0 =A0case TIOCCONS: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Set terminal as console TTY. */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (*(int *)data) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (EPERM) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else if (constty =3D=3D tp) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constty_clear(); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > and it won't change any behavior. Ok -- figured I would ask about the obvious. I wish I could help you further right now, but unfortunately I have a lot on my plate. I've CCed ed@ and the list again so that someone else might be able to chime in and help you further. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 07:49:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72190106566B for ; Fri, 7 Jan 2011 07:49:02 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2BAE28FC08 for ; Fri, 7 Jan 2011 07:49:01 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 139639CB0C4; Fri, 7 Jan 2011 08:49:00 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWceQzYJP3E3; Fri, 7 Jan 2011 08:48:59 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 32A659CB50A; Fri, 7 Jan 2011 08:48:59 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p077mwh9087429; Fri, 7 Jan 2011 08:48:58 +0100 (CET) (envelope-from rdivacky) Date: Fri, 7 Jan 2011 08:48:58 +0100 From: Roman Divacky To: Erik Cederstrand Message-ID: <20110107074858.GA87281@freebsd.org> References: <20110105131439.GN23329@acme.spoerlein.net> <20110105193653.GA49285@stack.nl> <7FA66A47-CB15-4C22-8614-B58E986CFFA4@cederstrand.dk> <201101062056.55807.tijl@coosemans.org> <1EF28C3A-954D-4A4B-8069-F0E767EF3669@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF28C3A-954D-4A4B-8069-F0E767EF3669@cederstrand.dk> User-Agent: Mutt/1.4.2.3i Cc: Tijl Coosemans , freebsd-current@freebsd.org Subject: Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 07:49:02 -0000 On Thu, Jan 06, 2011 at 11:59:07PM +0100, Erik Cederstrand wrote: > > Den 06/01/2011 kl. 20.56 skrev Tijl Coosemans: > > > On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: > >> Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: > >>> On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp?rlein wrote: > >>>> - get IPA to work with clang, or at least file a bug > >>>> - mark functions as __dead2 (please don't do that) > >>> > >>> Why not? > >> > >> Because the analyzer is supposed to find bugs. Only the function that > >> really doesn't return should be marked as such. If we begin spewing > >> __dead2's everywhere, it's bound to silence a valid bug somewhere > >> down the line when e.g. a conditional in a print_help() function is > >> changed subtly so it doesn't always reach exit(). > > > > On the other hand you can't really expect the compiler/analyser to know > > what a procedure in another file does, so in that case you need __dead2 > > anyway. [...] > > I have high expectations of LLVM :-) LLVM already has some knowledge of what's going on in other files (see LTO) so why shouldn't it be able to detect the __noreturn__ ? All the necessary information should be readily available. the static analyzer has nothing to do with LLVM. it's a clang component and uses only the info that clang knows. and clang (ie. the C frontend) does not perform any analysis of this kind, thus it does not know that stuff is dead. fwiw - my trivial (but working) patch brought down the number of reports by mere 5% so the bulk is probably somewhere else... From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 10:06:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B849B106564A for ; Fri, 7 Jan 2011 10:06:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1E48FC17 for ; Fri, 7 Jan 2011 10:06:23 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p079mTlD014768 for ; Fri, 7 Jan 2011 04:48:29 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Fri, 07 Jan 2011 04:48:29 -0500 (EST) Date: Fri, 7 Jan 2011 04:48:29 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:06:23 -0000 When sending multicast packets to a socket that is _not_ bound to the multicast address, this generates bad UDP checksums. This use to work and was broke sometime between the middle of October and late December as far as I can tell. A test program is here: http://people.freebsd.org/~deischen/test_net.c It will use multicast with the -b option, so run it with something like this: test_net -b 225.168.2.50 -p 5000 -m 64 And on another box, use tcpdump to see the bad checksums, as in: tcpdump -x -s0 -vvv host 225.168.2.50 and port 5000 This is a real problem for us because our applications cannot read the multicast data (both the Solaris and VxWork stacks refuse to deliver the packets with bad checksums). As a data point, if the sending socket is bound to the multicast address, then the checksums are calculated correctly. It is only if the socket is bound to a different address (the host IP and ephemeral port), that the checksum is invalid. To see this, you can change line 827 in test_net.c from this: if ((ss = init_mcast_socket(p, mcast_addr, if_addr, 1, 0)) < 0) to if ((ss = init_mcast_socket(p, mcast_addr, if_addr, 1, 1)) < 0) Here's a snippet from a tcpdump showing the problem: 04:46:13.640846 IP (tos 0x0, ttl 1, id 42777, offset 0, flags [none], proto UDP (17), length 92) 192.168.3.85.60133 > 225.168.2.50.5000: [bad udp cksum 3c02!] UDP, length 64 0x0000: 4500 005c a719 0000 0111 6aa0 c0a8 0355 0x0010: e1a8 0232 eae5 1388 0048 1cc6 0000 0038 0x0020: 0000 0018 0000 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 04:46:13.741800 IP (tos 0x0, ttl 1, id 42778, offset 0, flags [none], proto UDP (17), length 92) 192.168.3.85.60133 > 225.168.2.50.5000: [bad udp cksum 3c02!] UDP, length 64 0x0000: 4500 005c a71a 0000 0111 6a9f c0a8 0355 0x0010: e1a8 0232 eae5 1388 0048 c76f 0000 0038 0x0020: 0000 0019 5555 5555 5555 5555 5555 5555 0x0030: 5555 5555 5555 5555 5555 5555 5555 5555 0x0040: 5555 5555 5555 5555 5555 5555 5555 5555 0x0050: 5555 5555 5555 5555 5555 5555 -- DE From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 10:14:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2794106566B; Fri, 7 Jan 2011 10:14:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7929B8FC08; Fri, 7 Jan 2011 10:14:13 +0000 (UTC) Received: by pxi1 with SMTP id 1so3373936pxi.13 for ; Fri, 07 Jan 2011 02:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PVb9GyIO3y1RGN+hzUVd9tGCVkkdY6SlZlqBNrnZW+I=; b=Vfe4HjV2hEPjSEVSTN3CXfBnEDJk+91dxaxO7HTXBbKbIr/cba8JxpkzPgfDoqME5a 4q2k3Xb7XkTgasCUV85zVRz9BpL6flFdYJCy9qjQzzaHyHpKF19qvH6hpdWe30Ytf+DB UnDWdCYJXzt1oTpuJHjmQ9MOS9dqaaDw+Wr4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=ZznCvA70KXDjjpHFsDUSBUWscyumduLMBUYpw+CE0cmRUcJO16ZRgiVadqdhDB5Vwl 55F8Lc2esA4+tfMoe7FHnhkc5sUeZmY3OPgcV4/u+Q05wAt89XBSUmJcHD6PZGJXHzh2 nbmD/I/dq2PJLiXcYxKErrymp/jlRPFJWWwUg= Received: by 10.143.43.12 with SMTP id v12mr1591263wfj.344.1294395252862; Fri, 07 Jan 2011 02:14:12 -0800 (PST) Received: from [192.168.20.5] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id p8sm2426326wff.16.2011.01.07.02.14.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 02:14:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper X-Priority: 3 In-Reply-To: Date: Fri, 7 Jan 2011 02:14:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3027245F-CDB1-4271-B27F-13A9F24A0BDA@gmail.com> References: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> To: "Marek Salwerowicz" X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:14:13 -0000 On Jan 7, 2011, at 1:09 AM, Marek Salwerowicz wrote: >>=20 >> kldload nfssvc && dmesg | tail -n 10 ? >>=20 >=20 > vm-salwerom% sudo kldload nfssvc > kldload: can't load nfssvc: File exists >=20 > but: >=20 > vm-salwerom% sudo kldload nfssvc.ko > vm-salwerom% dmesg | tail -n 10 > em0 at 194.29.146.128 server 194.29.146.27 server name amp2 > subnet mask 255.255.255.0 router 194.29.146.1 rootfs 194.29.146.3:/ = rootopts nolockd hostname vm-salwerom > Adjusted interface em0 > SMP: AP CPU #1 Launched! > Trying to mount root from nfs: []... > NFS ROOT: 194.29.146.3:/ > KLD nfscommon.ko: depends on nfssvc - not available or version = mismatch > linker_load_file: Unsupported file type > KLD nfscl.ko: depends on nfssvc - not available or version mismatch > linker_load_file: Unsupported file type > vm-salwerom% > vm-salwerom% >=20 >=20 > so, why if I want to load nfssvc I have to type it with the suffix? = How can I tell nfsuserd and anfscbd to try to load it with suffix during = system boot? Try loading all of the modules one-by-one. -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 10:45:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77723106564A; Fri, 7 Jan 2011 10:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 096F58FC16; Fri, 7 Jan 2011 10:45:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0CD3041C64A; Fri, 7 Jan 2011 11:45:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id t3wqeVO2Fndx; Fri, 7 Jan 2011 11:45:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 4046541C67B; Fri, 7 Jan 2011 11:45:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 37D374448F3; Fri, 7 Jan 2011 10:40:31 +0000 (UTC) Date: Fri, 7 Jan 2011 10:40:31 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Daniel Eischen In-Reply-To: Message-ID: <20110107103837.E14966@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:45:08 -0000 On Fri, 7 Jan 2011, Daniel Eischen wrote: > When sending multicast packets to a socket that is _not_ > bound to the multicast address, this generates bad UDP > checksums. This use to work and was broke sometime between > the middle of October and late December as far as I can > tell. My very best guess would be: r215110 Otherwise the usual questions apply though I am almost certain you got that right: - dumps taken on the receiver side not the sender as - NIC offload capabilities might confuse tcpdump and you might want to turn them off and test as well w/o them /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:17:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 581941065758 for ; Fri, 7 Jan 2011 11:17:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E54388FC13 for ; Fri, 7 Jan 2011 11:17:48 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p07BHl7D022732; Fri, 7 Jan 2011 06:17:47 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Fri, 07 Jan 2011 06:17:48 -0500 (EST) Date: Fri, 7 Jan 2011 06:17:47 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bjoern A. Zeeb" In-Reply-To: <20110107103837.E14966@maildrop.int.zabbadoz.net> Message-ID: References: <20110107103837.E14966@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:17:49 -0000 On Fri, 7 Jan 2011, Bjoern A. Zeeb wrote: > On Fri, 7 Jan 2011, Daniel Eischen wrote: > >> When sending multicast packets to a socket that is _not_ >> bound to the multicast address, this generates bad UDP >> checksums. This use to work and was broke sometime between >> the middle of October and late December as far as I can >> tell. > > My very best guess would be: r215110 It doesn't look very harmful, but I'll try backing it out. > Otherwise the usual questions apply though I am almost certain you got > that right: > > - dumps taken on the receiver side not the sender as Yes, dumps were taken on both receiving Solaris 10 and FreeBSD hosts. > - NIC offload capabilities might confuse tcpdump and you might > want to turn them off and test as well w/o them Disabling checksum offloading makes no difference, and the problem occurs on all interfaces I have tested (sis, bfe, wpi). -- DE From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:22:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E1DB106564A; Fri, 7 Jan 2011 11:22:12 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 824B08FC15; Fri, 7 Jan 2011 11:22:11 +0000 (UTC) Received: by bwz12 with SMTP id 12so9869247bwz.13 for ; Fri, 07 Jan 2011 03:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=r32os0l9rx6/nB/aH5jdnAgHarILibTzxrf6YrQyDA0=; b=qz90YEbai6RkHcnwi6j2+JghQEbjHLTFJAysapquBKBHqjHOKcCKi0cxeh2cghh3Ji HmABAl7d8FlBYHzXMSVv+nQps+C0wu8Y4i0DQVK097CCv2VkuK/d5cjENA2u/vK+0rtB FwALbWHtfinMrOof6fShqI4RYG45OXssVXYdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=dOq/NXZqE9sUi7D/N7fEdZeZ8adZNOw6n718Aa0NRwnk5XdNahmtxaaC5gWhaECvCX Oa02EkmSFJ4wJY/nYsslt2Ybxt/rStcNwTwLQkKtitkEb8/pdgVnbNH1taeI1UGo/omg 7Ne33epjRIjarq9IXp9kywg42XIGSXZdyc/CA= Received: by 10.204.64.208 with SMTP id f16mr2601265bki.61.1294397590972; Fri, 07 Jan 2011 02:53:10 -0800 (PST) Received: from ernst.jennejohn.org (p578E194D.dip.t-dialin.net [87.142.25.77]) by mx.google.com with ESMTPS id v1sm13967356bkt.5.2011.01.07.02.53.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 02:53:09 -0800 (PST) Date: Fri, 7 Jan 2011 11:53:06 +0100 From: Gary Jennejohn To: Garrett Cooper Message-ID: <20110107115306.2bfd15d8@ernst.jennejohn.org> In-Reply-To: References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Ed Schouten , Craig Leres Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:22:12 -0000 On Thu, 6 Jan 2011 21:09:05 -0800 Garrett Cooper wrote: > On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote: > > On 01/06/11 20:05, Garrett Cooper wrote: > >> Just to make sure we're both on the same page: > >> > >> $ grep xterm /etc/ttys > >> ttyv0 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv1 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv2 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv3 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv4 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv5 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv6 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv7 "/usr/libexec/getty Pc"         xterm   on  secure > >> ttyv8 "/usr/local/bin/xdm -nodaemon"  xterm   off secure > > > > No, that's not what mine looks like. I changed it to match and rebooted > > but it doesn't help with the TIOCCONS issue. > > > > When I run xinit, it starts up the xterm -C which does a TIOCCONS. The > > 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the > > request: > > > >        case TIOCCONS: > >                /* Set terminal as console TTY. */ > >                if (*(int *)data) { > >                        error = priv_check(td, PRIV_TTY_CONSOLE); > >                        if (error) > >                                return (error); > > > >                        /* > >                         * XXX: constty should really need to be locked! > >                         * XXX: allow disconnected constty's to be stolen! > >                         */ > > > >                        if (constty == tp) > >                                return (0); > >                        if (constty != NULL) > >                                return (EBUSY); > > > >                        tty_unlock(tp); > >                        constty_set(tp); > >                        tty_lock(tp); > >                } else if (constty == tp) { > >                        constty_clear(); > >                } > >                return (0); > > > > > > There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE > > in any case. You could rewrite the above like this: > > > >        case TIOCCONS: > >                /* Set terminal as console TTY. */ > >                if (*(int *)data) { > >                        return (EPERM) > >                } else if (constty == tp) { > >                        constty_clear(); > >                } > >                return (0); > > > > and it won't change any behavior. > > Ok -- figured I would ask about the obvious. I wish I could help > you further right now, but unfortunately I have a lot on my plate. > I've CCed ed@ and the list again so that someone else might be able to > chime in and help you further. > I'd say there are a few factors which come into play here: 1) the setting of security.bsd.suser_enabled, default 1 2) kern_tty.c checking for a cred which is never set 3) whether xterm is setuid root a) suser_enabled is almost guaranteed to be 1 on OP's system since just about nothing works when it is set to 0 (tried that) b) the kernel checking for the cred PRIV_TTY_CONSOLE is probably a bug since it never gets set anywhere. However, this usually isn't noticed because c) xterm is generally setuid root and the logic in priv_check_cred() in kern_priv.c doesn't even look at what cred is set to, except for a few which can raise some limits, because cr_uid is 0 (super user) So, the crux of the matter is whether OP's xterm is setuid root. My xterm is and I can run 'xterm -C' without a problem. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:31:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA3871065674 for ; Fri, 7 Jan 2011 11:31:48 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 64AF38FC16 for ; Fri, 7 Jan 2011 11:31:48 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 10420 invoked from network); 7 Jan 2011 12:31:46 +0100 Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 7 Jan 2011 12:31:46 +0100 Date: Fri, 07 Jan 2011 12:31:46 +0100 From: "Marek Salwerowicz" To: Garrett Cooper Message-ID: <4d26f9a20813d5.52450662@wp.pl> References: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> <3027245F-CDB1-4271-B27F-13A9F24A0BDA@gmail.com> In-reply-to: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> <3027245F-CDB1-4271-B27F-13A9F24A0BDA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2) Gecko/20100115 Firefox/3.6 Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html X-WP-IP: 194.29.146.3 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [kdPU] Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:31:48 -0000 > Try loading all of the modules one-by-one. so, after loading nfssvc.ko: vm-salwerom% sudo ./nfsuserd start Starting nfsuserd. vm-salwerom% sudo ./nfscbd start Starting nfscbd. nfscbd: Can't get fully qualified host name vm-salwerom% kldstat Id Refs Address Size Name 1 29 0xffffffff80100000 711d58 kernel 2 1 0xffffffff80812000 85d0 procfs.ko 3 2 0xffffffff8081b000 9628 pseudofs.ko 4 1 0xffffffff80825000 68ad0 if_em.ko 5 1 0xffffffff80a12000 2c92 geom_md.ko 6 1 0xffffffff80a15000 50fb tmpfs.ko 7 1 0xffffffff80a1b000 1fa green_saver.ko 8 3 0xffffffff80a1c000 381 nfssvc.ko 9 2 0xffffffff80a1d000 fd24 nfscommon.ko 10 1 0xffffffff80a2d000 2df67 nfscl.ko vm-salwerom% I am able to mount via nfsv4: vm-salwerom% mount_nfs -o nfsv4 free:/home/stud/salwerom nfs vm-salwerom% mount 194.29.146.3:/ on / (nfs, read-only) devfs on /dev (devfs, local) /dev/md0 on /etc (ufs, local) procfs on /proc (procfs, local) tmpfs on /tmp (tmpfs, local) tmpfs on /var (tmpfs, local) tmpfs on /home/stud/salwerom (tmpfs, local) free:/home/stud/salwerom on /home/stud/salwerom/nfs (newnfs) vm-salwerom% The problem is how to automatically load during system boot nfssvc(.ko) ? -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:42:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180E7106564A for ; Fri, 7 Jan 2011 11:42:03 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C7F578FC19 for ; Fri, 7 Jan 2011 11:42:02 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p07Bg1aS032591; Fri, 7 Jan 2011 06:42:01 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Fri, 07 Jan 2011 06:42:01 -0500 (EST) Date: Fri, 7 Jan 2011 06:42:01 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: References: <20110107103837.E14966@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rrs@freebsd.org, freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:42:03 -0000 On Fri, 7 Jan 2011, Daniel Eischen wrote: > On Fri, 7 Jan 2011, Bjoern A. Zeeb wrote: > >> On Fri, 7 Jan 2011, Daniel Eischen wrote: >> >>> When sending multicast packets to a socket that is _not_ >>> bound to the multicast address, this generates bad UDP >>> checksums. This use to work and was broke sometime between >>> the middle of October and late December as far as I can >>> tell. >> >> My very best guess would be: r215110 > > It doesn't look very harmful, but I'll try backing it out. Backing this out seems to fix it. I'll have to test it more after I get some sleep ;-) > >> Otherwise the usual questions apply though I am almost certain you got >> that right: >> >> - dumps taken on the receiver side not the sender as > > Yes, dumps were taken on both receiving Solaris 10 > and FreeBSD hosts. > >> - NIC offload capabilities might confuse tcpdump and you might >> want to turn them off and test as well w/o them > > Disabling checksum offloading makes no difference, and the > problem occurs on all interfaces I have tested (sis, bfe, > wpi). -- DE From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:53:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91B5B1065673 for ; Fri, 7 Jan 2011 11:53:58 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by mx1.freebsd.org (Postfix) with ESMTP id 0BCF58FC13 for ; Fri, 7 Jan 2011 11:53:57 +0000 (UTC) Received: from localhost ([92.156.106.245]) by mwinf5d07 with ME id sbPs1f00T5Hi3Yk03bPs44; Fri, 07 Jan 2011 12:23:54 +0100 Message-ID: <4D26F7C8.2010508@orange.fr> Date: Fri, 07 Jan 2011 12:23:52 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: Garrett Cooper References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ed Schouten , Craig Leres Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:53:58 -0000 On 01/07/2011 06:09, Garrett Cooper wrote: > On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote: >> On 01/06/11 20:05, Garrett Cooper wrote: >>> Just to make sure we're both on the same page: >>> >>> $ grep xterm /etc/ttys >>> ttyv0 "/usr/libexec/getty Pc" xterm on secure >>> ttyv1 "/usr/libexec/getty Pc" xterm on secure >>> ttyv2 "/usr/libexec/getty Pc" xterm on secure >>> ttyv3 "/usr/libexec/getty Pc" xterm on secure >>> ttyv4 "/usr/libexec/getty Pc" xterm on secure >>> ttyv5 "/usr/libexec/getty Pc" xterm on secure >>> ttyv6 "/usr/libexec/getty Pc" xterm on secure >>> ttyv7 "/usr/libexec/getty Pc" xterm on secure >>> ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure >> >> No, that's not what mine looks like. I changed it to match and rebooted >> but it doesn't help with the TIOCCONS issue. >> >> When I run xinit, it starts up the xterm -C which does a TIOCCONS. The >> 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the >> request: >> >> case TIOCCONS: >> /* Set terminal as console TTY. */ >> if (*(int *)data) { >> error = priv_check(td, PRIV_TTY_CONSOLE); >> if (error) >> return (error); >> >> /* >> * XXX: constty should really need to be locked! >> * XXX: allow disconnected constty's to be stolen! >> */ >> >> if (constty == tp) >> return (0); >> if (constty != NULL) >> return (EBUSY); >> >> tty_unlock(tp); >> constty_set(tp); >> tty_lock(tp); >> } else if (constty == tp) { >> constty_clear(); >> } >> return (0); >> >> >> There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE >> in any case. You could rewrite the above like this: >> >> case TIOCCONS: >> /* Set terminal as console TTY. */ >> if (*(int *)data) { >> return (EPERM) >> } else if (constty == tp) { >> constty_clear(); >> } >> return (0); >> >> and it won't change any behavior. > > Ok -- figured I would ask about the obvious. I wish I could help > you further right now, but unfortunately I have a lot on my plate. > I've CCed ed@ and the list again so that someone else might be able to > chime in and help you further. > Cheers, a > -Garrett > _______________________________________________ > 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" > This is not a new problem, as it lead to a thread on hackers@ in November 2008 (search for "[Testers wanted] /dev/console cleanups" and "xconsole"). I tried a "proof of concept" by building a kernel with options MAC, and patching mac_stub.c to have stub_priv_grant() return 0 in stade of EPERM for PRIV_TTY_CONSOLE. With this, the kernel messages are displayed in xconsole, but not the others messages sent with syslog. Of course, this hack is not to be used on a production system. I hope that a true solution will be found one day or another. Claude Buisson. From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 09:09:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4B2106564A for ; Fri, 7 Jan 2011 09:09:46 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id A87B88FC12 for ; Fri, 7 Jan 2011 09:09:45 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 29409 invoked from network); 7 Jan 2011 10:09:44 +0100 Received: from cwx170.internetdsl.tpnet.pl (HELO marekdesktop) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 7 Jan 2011 10:09:44 +0100 Message-ID: From: "Marek Salwerowicz" To: "Garrett Cooper" References: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> Date: Fri, 7 Jan 2011 10:09:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [4RPX] X-Mailman-Approved-At: Fri, 07 Jan 2011 12:27:40 +0000 Cc: freebsd-current@freebsd.org Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:09:46 -0000 > > kldload nfssvc && dmesg | tail -n 10 ? > vm-salwerom% sudo kldload nfssvc kldload: can't load nfssvc: File exists but: vm-salwerom% sudo kldload nfssvc.ko vm-salwerom% dmesg | tail -n 10 em0 at 194.29.146.128 server 194.29.146.27 server name amp2 subnet mask 255.255.255.0 router 194.29.146.1 rootfs 194.29.146.3:/ rootopts nolockd hostname vm-salwerom Adjusted interface em0 SMP: AP CPU #1 Launched! Trying to mount root from nfs: []... NFS ROOT: 194.29.146.3:/ KLD nfscommon.ko: depends on nfssvc - not available or version mismatch linker_load_file: Unsupported file type KLD nfscl.ko: depends on nfssvc - not available or version mismatch linker_load_file: Unsupported file type vm-salwerom% vm-salwerom% so, why if I want to load nfssvc I have to type it with the suffix? How can I tell nfsuserd and anfscbd to try to load it with suffix during system boot? -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 14:47:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 980D61065675; Fri, 7 Jan 2011 14:47:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 258408FC1A; Fri, 7 Jan 2011 14:47:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPe1Jk2DaFvO/2dsb2JhbACDd6EjrjmNYoEhgzd0BIRnhiI X-IronPort-AV: E=Sophos;i="4.60,289,1291611600"; d="scan'208";a="104582331" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Jan 2011 09:47:16 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 58ADBB3F86; Fri, 7 Jan 2011 09:47:16 -0500 (EST) Date: Fri, 7 Jan 2011 09:47:16 -0500 (EST) From: Rick Macklem To: Marek Salwerowicz Message-ID: <1543154155.235420.1294411636305.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4d26f9a20813d5.52450662@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: Garrett Cooper , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:47:17 -0000 > > Try loading all of the modules one-by-one. > > so, after loading nfssvc.ko: > > vm-salwerom% sudo ./nfsuserd start > Starting nfsuserd. > vm-salwerom% sudo ./nfscbd start > Starting nfscbd. > nfscbd: Can't get fully qualified host name This won't break the nfscbd, which you don't need unless you are using delegations. (Not enabled by default in the FreeBSD server.) However, in nfsuserd can't figure out your domain, you'll need to set one via the "-domain xxx.yyy" option for nfsuserd. What it needs to know is the domain name that you are using for bind, etc since that is appended to user and group names that go on the wire. For example: - If the machine's name is nfs-client.cis.uoguelph.ca as shown by the hostname command... --> the domain name is cis.uoguelph.ca then the user rick will go on the wire as rick@cis.uoguelph.ca - if your hostname doesn't have a domain spec, it will try and get a fully qualified name via the ai_canonname returned from getaddrinfo. For example: # hostname nfs-client <-- no .xxx domain spec so --> does a getaddrinfo for nfs-client and then looks for .xxx in ai_canonname If you do "ls -l" on an NFSv4 mounted directory and see lotts nobody this domain spec either isn't configured or isn't configured the same as the server. > vm-salwerom% kldstat > Id Refs Address Size Name > 1 29 0xffffffff80100000 711d58 kernel > 2 1 0xffffffff80812000 85d0 procfs.ko > 3 2 0xffffffff8081b000 9628 pseudofs.ko > 4 1 0xffffffff80825000 68ad0 if_em.ko > 5 1 0xffffffff80a12000 2c92 geom_md.ko > 6 1 0xffffffff80a15000 50fb tmpfs.ko > 7 1 0xffffffff80a1b000 1fa green_saver.ko > 8 3 0xffffffff80a1c000 381 nfssvc.ko > 9 2 0xffffffff80a1d000 fd24 nfscommon.ko > 10 1 0xffffffff80a2d000 2df67 nfscl.ko > vm-salwerom% > > I am able to mount via nfsv4: > > vm-salwerom% mount_nfs -o nfsv4 free:/home/stud/salwerom nfs > vm-salwerom% mount > 194.29.146.3:/ on / (nfs, read-only) > devfs on /dev (devfs, local) > /dev/md0 on /etc (ufs, local) > procfs on /proc (procfs, local) > tmpfs on /tmp (tmpfs, local) > tmpfs on /var (tmpfs, local) > tmpfs on /home/stud/salwerom (tmpfs, local) > free:/home/stud/salwerom on /home/stud/salwerom/nfs (newnfs) > vm-salwerom% > > > The problem is how to automatically load during system boot > nfssvc(.ko) ? > Hmm, everything seems ok in head and works for me, but it might have been broken at some point. As a workaround, you can build your kernel with options NFSCL in the kernel config file so that it doesn't need to load the modules at all. rick From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 14:48:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79EDC106566C; Fri, 7 Jan 2011 14:48:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2769A8FC0C; Fri, 7 Jan 2011 14:48:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABuwJk2DaFvO/2dsb2JhbACDd6EjrjmNZYEhgzd0BIRnhiI X-IronPort-AV: E=Sophos;i="4.60,289,1291611600"; d="scan'208";a="104579604" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Jan 2011 09:20:26 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4E2E5B4032; Fri, 7 Jan 2011 09:20:26 -0500 (EST) Date: Fri, 7 Jan 2011 09:20:26 -0500 (EST) From: Rick Macklem To: Marek Salwerowicz Message-ID: <368766744.233482.1294410026259.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:48:37 -0000 > > > > kldload nfssvc && dmesg | tail -n 10 ? > > > > vm-salwerom% sudo kldload nfssvc > kldload: can't load nfssvc: File exists > > but: > > vm-salwerom% sudo kldload nfssvc.ko > vm-salwerom% dmesg | tail -n 10 > em0 at 194.29.146.128 server 194.29.146.27 server name amp2 > subnet mask 255.255.255.0 router 194.29.146.1 rootfs 194.29.146.3:/ > rootopts > nolockd hostname vm-salwerom > Adjusted interface em0 > SMP: AP CPU #1 Launched! > Trying to mount root from nfs: []... > NFS ROOT: 194.29.146.3:/ > KLD nfscommon.ko: depends on nfssvc - not available or version > mismatch > linker_load_file: Unsupported file type > KLD nfscl.ko: depends on nfssvc - not available or version mismatch > linker_load_file: Unsupported file type > vm-salwerom% > vm-salwerom% > > > so, why if I want to load nfssvc I have to type it with the suffix? > How can > I tell nfsuserd and anfscbd to try to load it with suffix during > system > boot? > I'm not very good at this stuff so others might need to chime in, but it looks to me like some of your kernel modules are from different builds. I always: # make KERNEL= install after doing a kernel build, which copies the kernel and all the modules to /boot/. I always use a other than "kernel" just in case it doesn't work, then you can move it over if is seems ok. Both nfscl.ko and nfsd.ko specify nfssvc.ko as a module they depend on, so they should be loaded automagically if all the correct versions are in the /boot/ tree. (At least it works that way for me.) rick From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 16:14:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 991EA1065674 for ; Fri, 7 Jan 2011 16:14:09 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 298218FC15 for ; Fri, 7 Jan 2011 16:14:08 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 28861 invoked from network); 7 Jan 2011 17:14:06 +0100 Received: from cwx170.internetdsl.tpnet.pl (HELO marekdesktop) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 7 Jan 2011 17:14:06 +0100 Message-ID: <76E8B151C6514E358F6B1C86D2E21862@marekdesktop> From: "Marek Salwerowicz" To: "Rick Macklem" References: <368766744.233482.1294410026259.JavaMail.root@erie.cs.uoguelph.ca> Date: Fri, 7 Jan 2011 17:13:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [YSM3] X-Mailman-Approved-At: Fri, 07 Jan 2011 16:33:07 +0000 Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:14:09 -0000 > I'm not very good at this stuff so others might need to chime in, > but it looks to me like some of your kernel modules are from different > builds. > > I always: > # make KERNEL= install > after doing a kernel build, which copies the kernel and all the modules > to /boot/. I always use a other than "kernel" > just in case it doesn't work, then you can move it over if is seems ok. > > Both nfscl.ko and nfsd.ko specify nfssvc.ko as a module they depend on, > so they should be loaded automagically if all the correct versions are > in the /boot/ tree. (At least it works that way for me.) Kernel modules are from the same build. look at this: vm-salwerom% kldstat Id Refs Address Size Name 1 19 0xffffffff80100000 711d58 kernel 2 1 0xffffffff80812000 85d0 procfs.ko 3 2 0xffffffff8081b000 9628 pseudofs.ko 4 1 0xffffffff80825000 68ad0 if_em.ko 5 1 0xffffffff80a12000 2c92 geom_md.ko 6 1 0xffffffff80a15000 50fb tmpfs.ko 7 1 0xffffffff80a1b000 1fa green_saver.ko vm-salwerom% sudo kldload nfssvc kldload: can't load nfssvc: File exists vm-salwerom% kldstat Id Refs Address Size Name 1 19 0xffffffff80100000 711d58 kernel 2 1 0xffffffff80812000 85d0 procfs.ko 3 2 0xffffffff8081b000 9628 pseudofs.ko 4 1 0xffffffff80825000 68ad0 if_em.ko 5 1 0xffffffff80a12000 2c92 geom_md.ko 6 1 0xffffffff80a15000 50fb tmpfs.ko 7 1 0xffffffff80a1b000 1fa green_saver.ko vm-salwerom% sudo kldload nfssvc.ko <-------the suffix is needed vm-salwerom% kldstat Id Refs Address Size Name 1 21 0xffffffff80100000 711d58 kernel 2 1 0xffffffff80812000 85d0 procfs.ko 3 2 0xffffffff8081b000 9628 pseudofs.ko 4 1 0xffffffff80825000 68ad0 if_em.ko 5 1 0xffffffff80a12000 2c92 geom_md.ko 6 1 0xffffffff80a15000 50fb tmpfs.ko 7 1 0xffffffff80a1b000 1fa green_saver.ko 8 1 0xffffffff80a1c000 381 nfssvc.ko vm-salwerom% so I am able to load nfssvc.ko (with '.ko' suffix) ant unable to load nfssvc (without '.ko' suffix) - why ? -- Marek Salwerowicz From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 19:12:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3161065675 for ; Fri, 7 Jan 2011 19:12:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6489C8FC13 for ; Fri, 7 Jan 2011 19:12:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PbHjh-0004yJ-UJ for freebsd-current@freebsd.org; Fri, 07 Jan 2011 20:12:29 +0100 Received: from cpe-188-129-116-202.dynamic.amis.hr ([188.129.116.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jan 2011 20:12:29 +0100 Received: from ivoras by cpe-188-129-116-202.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Jan 2011 20:12:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 07 Jan 2011 20:12:15 +0100 Lines: 12 Message-ID: References: <4d26f9a20813d5.52450662@wp.pl> <1543154155.235420.1294411636305.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-116-202.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <1543154155.235420.1294411636305.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:12:31 -0000 On 01/07/11 15:47, Rick Macklem wrote: > What it needs to know is the domain name that you are using > for bind, etc since that is appended to user and group names > that go on the wire. For example: > - If the machine's name is nfs-client.cis.uoguelph.ca as shown > by the hostname command... > --> the domain name is cis.uoguelph.ca > then the user rick will go on the wire as rick@cis.uoguelph.ca That's nice - so finally no UIDs over the wire? Or is it only for logins? From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 19:15:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1E3106566B for ; Fri, 7 Jan 2011 19:15:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EB2C88FC1B for ; Fri, 7 Jan 2011 19:15:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAD/1Jk2DaFvO/2dsb2JhbACDd6EnrXaNQoEhgzd0BIRnhiI X-IronPort-AV: E=Sophos;i="4.60,290,1291611600"; d="scan'208";a="104622568" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 07 Jan 2011 14:15:31 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E46A6B3F24; Fri, 7 Jan 2011 14:15:31 -0500 (EST) Date: Fri, 7 Jan 2011 14:15:31 -0500 (EST) From: Rick Macklem To: Ivan Voras Message-ID: <490948409.256117.1294427731921.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:15:33 -0000 > On 01/07/11 15:47, Rick Macklem wrote: > > > What it needs to know is the domain name that you are using > > for bind, etc since that is appended to user and group names > > that go on the wire. For example: > > - If the machine's name is nfs-client.cis.uoguelph.ca as shown > > by the hostname command... > > --> the domain name is cis.uoguelph.ca > > then the user rick will go on the wire as rick@cis.uoguelph.ca > > That's nice - so finally no UIDs over the wire? Or is it only for > logins? > Well, no UIDs on the wire inside the NFSv4 RPCs. Unfortunately, if you are using AUTH_SYS, there are still UIDs in the RPC header. But if you use krb5 then, yes, no UIDs on the wire. rick From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 20:16:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 784631065675; Fri, 7 Jan 2011 20:16:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 264DB8FC0C; Fri, 7 Jan 2011 20:16:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAE8DJ02DaFvO/2dsb2JhbACDd6EnrXONMYEhgzd0BIRnhiI X-IronPort-AV: E=Sophos;i="4.60,290,1291611600"; d="scan'208";a="106293091" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 07 Jan 2011 15:16:32 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 37B34B4170; Fri, 7 Jan 2011 15:16:32 -0500 (EST) Date: Fri, 7 Jan 2011 15:16:32 -0500 (EST) From: Rick Macklem To: Ivan Voras Message-ID: <1136425833.263121.1294431392106.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:16:33 -0000 > > I was thinking about the practical scenario where users share a server > - currently, as there's AFAIK no facility for remapping UIDs in > FreeBSD, UIDs and usernames have to match on all machines. Will this > change with NFSv4? Unless you use Kerberized mounts (sec=krb5 or sec=krb5i or sec=krb5p), no. I, personally, think that a simple authentication mechanism that had a name instead of uid in it would be nice. However, to have any chance of getting that through the ietf working group, I think it would have to be accompanied by some sort of host based security (think "like an ssh tunnel using IPSEC") and I don't have the time nor expertise to work that all out. Then, it all has to be written up as an internet draft, and then, since I don't have any travel budget to go to the IETF meetings, I'll bet it'd never get anywhere. If some NFS vendor likes this idea, I'd be happy to work wth them on it, because I believe setting up Kerberos is just too much hassle for most people. rick From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 20:26:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BAAD106564A for ; Fri, 7 Jan 2011 20:26:30 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C568D8FC12 for ; Fri, 7 Jan 2011 20:26:29 +0000 (UTC) Received: by qwj9 with SMTP id 9so17531116qwj.13 for ; Fri, 07 Jan 2011 12:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=TZtioWowM8uJIxNh/pBTggCDBhivm9F//7RbfZMOXPg=; b=dJBJ8SIhbyNjpjYq7xPC1A1P45G714ynIlKRE52p4FGfhwKsHJLTG/SHnPYfXtZS9f 8vwgS0j7ljILhUzkTloUsXLe7Ms+czAzu4g3Zgb+5LF0Wm5bASuub4kwLioL+9IvPsaw s4ltfopTCxlWryPcvRUeFfroFcK+QoFtMzoZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Zhl4w0092ySv+oudnBeo3ubMk1ifUd/ax2irl2YLx0sikGwCoOrgTT88ziI8IF2NX4 KOjDhShoJ1ZVWDQ+xDTEs5XqA6GpuGjDpfCHE/j3PoqsZjvQfI3myCTDIC5ywKfyxAVF 9nhwg3MMwz90cc4js3W97FGJPCMCi349NX2FI= Received: by 10.229.190.204 with SMTP id dj12mr3586185qcb.101.1294430582183; Fri, 07 Jan 2011 12:03:02 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.44.70 with HTTP; Fri, 7 Jan 2011 12:02:21 -0800 (PST) In-Reply-To: <490948409.256117.1294427731921.JavaMail.root@erie.cs.uoguelph.ca> References: <490948409.256117.1294427731921.JavaMail.root@erie.cs.uoguelph.ca> From: Ivan Voras Date: Fri, 7 Jan 2011 21:02:21 +0100 X-Google-Sender-Auth: 3uSQzax_hKltAktowgIQb9kFMKk Message-ID: To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:26:30 -0000 On 7 January 2011 20:15, Rick Macklem wrote: >> On 01/07/11 15:47, Rick Macklem wrote: >> >> > What it needs to know is the domain name that you are using >> > for bind, etc since that is appended to user and group names >> > that go on the wire. For example: >> > - If the machine's name is nfs-client.cis.uoguelph.ca as shown >> > =C2=A0 =C2=A0by the hostname command... >> > =C2=A0 =C2=A0--> the domain name is cis.uoguelph.ca >> > =C2=A0 =C2=A0then the user rick will go on the wire as rick@cis.uoguel= ph.ca >> >> That's nice - so finally no UIDs over the wire? Or is it only for >> logins? >> > Well, no UIDs on the wire inside the NFSv4 RPCs. Unfortunately, if > you are using AUTH_SYS, there are still UIDs in the RPC header. But > if you use krb5 then, yes, no UIDs on the wire. I was thinking about the practical scenario where users share a server - currently, as there's AFAIK no facility for remapping UIDs in FreeBSD, UIDs and usernames have to match on all machines. Will this change with NFSv4? From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 20:41:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF778106566C for ; Fri, 7 Jan 2011 20:41:30 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2EA8FC1A for ; Fri, 7 Jan 2011 20:41:29 +0000 (UTC) Received: by fxm16 with SMTP id 16so17292196fxm.13 for ; Fri, 07 Jan 2011 12:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=kPCEY2+UMTSrlLQQxYKNcyyC877qPvLs+QPOkr0Ec+c=; b=V1xCw6ZtOoRFZxGi/IhyoT9g0UxObJcJc2yimjLv3yqkrgJFZvaY3pKaRKkIgpZi4F JP52nObGORNQ+QJWnZGEFv5u15WhGfpkinZbTkn5u+J5ll90Z0ooB9/uynuv1Kg3XFFd vPUVD4cwP9pSSWeXjtpcF4KgKBjQhzn+xTOLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=pHpnFi4UPu6PiiWRaA6yNAO1lfp6sQfvawd3QV/wLJXkEbNJHzAW9XDSHNHGqp6gUw l1itd4fZo7AyVrGcHXfD7B4F+jbVhd6aTDSCxGm9Xf6vssSpJec/+dCLkHpMrXQoscwT /OAcbPI0RYUoMtVBVfAhs+2oIblg03o5U5Ys0= Received: by 10.223.86.16 with SMTP id q16mr329613fal.58.1294432889170; Fri, 07 Jan 2011 12:41:29 -0800 (PST) Received: from localhost (narf.dsw2k3.info [195.71.226.87]) by mx.google.com with ESMTPS id e17sm6278905fak.10.2011.01.07.12.41.25 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 12:41:28 -0800 (PST) From: Anonymous To: Ivan Voras References: <490948409.256117.1294427731921.JavaMail.root@erie.cs.uoguelph.ca> Date: Fri, 07 Jan 2011 23:41:12 +0300 In-Reply-To: (Ivan Voras's message of "Fri, 7 Jan 2011 21:02:21 +0100") Message-ID: <86ipy0phuf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:41:30 -0000 Ivan Voras writes: > On 7 January 2011 20:15, Rick Macklem wrote: >> Well, no UIDs on the wire inside the NFSv4 RPCs. Unfortunately, if >> you are using AUTH_SYS, there are still UIDs in the RPC header. But >> if you use krb5 then, yes, no UIDs on the wire. > > I was thinking about the practical scenario where users share a server > - currently, as there's AFAIK no facility for remapping UIDs in > FreeBSD, UIDs and usernames have to match on all machines. Will this > change with NFSv4? We had one, mount_umap(8). I've used it to remap 0 (root) -> 1001 (foo) for an NFS mount a year ago on NetBSD. It was pretty stable there. From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 20:57:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B533106566C for ; Fri, 7 Jan 2011 20:57:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D3C9E8FC0C for ; Fri, 7 Jan 2011 20:57:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e] (unknown [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B712F5C5A for ; Fri, 7 Jan 2011 21:57:42 +0100 (CET) Message-ID: <4D277E4B.1030006@FreeBSD.org> Date: Fri, 07 Jan 2011 21:57:47 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:57:44 -0000 Hi all, For some time, I have been working on importing a newer version of binutils into -current. This updates our quite ancient 2.15 version to the last version available under GPLv2, 2.17.50. (Special thanks to Nathan Whitehorn for his valuable feedback.) As far as I know, all issues building and running the base system with this version of binutils have been solved, so I am planning to merge it into -current in approximately one week (e.g. Friday, 2011-01-14). If you want to test, please checkout the project branch: svn://svn.freebsd.org/base/projects/binutils-2.17 or apply the following diff to r217118 or later (warning: very large diff, might need handholding to apply successfully, and use -E while patching): http://www.andric.com/freebsd/binutils/binutils-2.17-r217118-1.diff.xz Then build world and kernel from the resulting source tree, and install them. There should be no directly visible changes, except for the newer version number reported by as(1), ld(1) and so on: 2.17.50 [FreeBSD] 2007-07-03 Please report any problems with either the base system, or ports that come up as a result of this binutils update. From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 21:21:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53517106566B for ; Fri, 7 Jan 2011 21:21:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2398FC15 for ; Fri, 7 Jan 2011 21:21:08 +0000 (UTC) Received: by iwn39 with SMTP id 39so17855055iwn.13 for ; Fri, 07 Jan 2011 13:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R+kz2ySI5bA8PD9DvQs7ps5WEl+itgK5jrgyoEGMYYE=; b=qDEk8dIY1zDO9+Y6+zPTCo50hzUNgLMz87AQiarL57jgSfNgbtcXqAd6FDO/M3tQz1 U9m7FP0awGgUN6ayilepgM7qpPlMio3rFHZt4ZPhmO6Up0Az8CuEuP7mUJfKttFtEApC 9KRPDr8Rg8yfdaqbfPO0J/Mct9OdMtlnhY4t0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nAZjL7Oehx5yXVyBxgQxjHDjPzun8Y3xqRbbpem45WERS3ZOSOift/baNhVnL4Hl3E 1XRGvPSQ5DYu+B6WsAnnGyNzwkgNzAUfWCrwhPihRzaAwD+3r+OcXLOZxKTzFIAkRwYJ LGKZE8bxPPSemXxuh22TKGe5VBOgJREe4BsGM= MIME-Version: 1.0 Received: by 10.231.36.198 with SMTP id u6mr26264897ibd.100.1294435268538; Fri, 07 Jan 2011 13:21:08 -0800 (PST) Received: by 10.231.79.197 with HTTP; Fri, 7 Jan 2011 13:21:08 -0800 (PST) In-Reply-To: <4D277E4B.1030006@FreeBSD.org> References: <4D277E4B.1030006@FreeBSD.org> Date: Fri, 7 Jan 2011 16:21:08 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:21:09 -0000 On Fri, Jan 7, 2011 at 3:57 PM, Dimitry Andric wrote: > Hi all, > > For some time, I have been working on importing a newer version of > binutils into -current. This updates our quite ancient 2.15 version to > the last version available under GPLv2, 2.17.50. (Special thanks to > Nathan Whitehorn for his valuable feedback.) > > As far as I know, all issues building and running the base system with > this version of binutils have been solved, so I am planning to merge it > into -current in approximately one week (e.g. Friday, 2011-01-14). > > If you want to test, please checkout the project branch: > > svn://svn.freebsd.org/base/projects/binutils-2.17 > > or apply the following diff to r217118 or later (warning: very large > diff, might need handholding to apply successfully, and use -E while > patching): > > http://www.andric.com/freebsd/binutils/binutils-2.17-r217118-1.diff.xz > > Then build world and kernel from the resulting source tree, and install > them. There should be no directly visible changes, except for the newer > version number reported by as(1), ld(1) and so on: > > 2.17.50 [FreeBSD] 2007-07-03 > > Please report any problems with either the base system, or ports that > come up as a result of this binutils update. > In the main directory http://svn.freebsd.org/base/projects/binutils-2.17/ all of the Text files are seen as Binary files by Firefox in Linux , then , instead of displaying them , it is starting a download dialog about a binary file . It is likely that , the others in sub directories are the same . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 21:22:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A448910656A8 for ; Fri, 7 Jan 2011 21:22:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 30BE68FC0A for ; Fri, 7 Jan 2011 21:22:20 +0000 (UTC) Received: (qmail 7013 invoked by uid 399); 7 Jan 2011 21:22:20 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Jan 2011 21:22:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D27840A.8020107@FreeBSD.org> Date: Fri, 07 Jan 2011 13:22:18 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4D277E4B.1030006@FreeBSD.org> In-Reply-To: <4D277E4B.1030006@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:22:21 -0000 On 01/07/2011 12:57, Dimitry Andric wrote: > Please report any problems with either the base system, or ports that > come up as a result of this binutils update. This is much appreciated work of course, but I'm wondering if you've requested an experimental ports run with the change? It would be good to know how much damage to expect before the change gets committed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 21:29:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5020F106564A; Fri, 7 Jan 2011 21:29:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 12FD58FC1A; Fri, 7 Jan 2011 21:29:07 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e] (unknown [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 610735C5A; Fri, 7 Jan 2011 22:29:06 +0100 (CET) Message-ID: <4D2785A7.7080106@FreeBSD.org> Date: Fri, 07 Jan 2011 22:29:11 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: Doug Barton References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> In-Reply-To: <4D27840A.8020107@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:29:07 -0000 On 2011-01-07 22:22, Doug Barton wrote: > This is much appreciated work of course, but I'm wondering if you've > requested an experimental ports run with the change? It would be good to > know how much damage to expect before the change gets committed. Yes, I submitted an exp-run request Nov 15, 2010: http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately, there has been little or no interest. From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 21:30:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCD0B1065679 for ; Fri, 7 Jan 2011 21:30:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6048FC0C for ; Fri, 7 Jan 2011 21:30:53 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e] (unknown [IPv6:2001:7b8:3a7:0:5c0b:8518:f9c5:c52e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E11A85C5A; Fri, 7 Jan 2011 22:30:52 +0100 (CET) Message-ID: <4D278611.9030504@FreeBSD.org> Date: Fri, 07 Jan 2011 22:30:57 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: Mehmet Erol Sanliturk References: <4D277E4B.1030006@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:30:53 -0000 On 2011-01-07 22:21, Mehmet Erol Sanliturk wrote: > http://svn.freebsd.org/base/projects/binutils-2.17/ > > all of the Text files are seen as Binary files by Firefox in Linux Try http://svn.freebsd.org/viewvc/base/projects/binutils-2.17/ instead. For checking out the source tree, please use a Subversion client, not a browser. From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 21:41:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A01C01065674 for ; Fri, 7 Jan 2011 21:41:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 26D9C8FC0A for ; Fri, 7 Jan 2011 21:41:37 +0000 (UTC) Received: (qmail 30749 invoked by uid 399); 7 Jan 2011 21:41:36 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Jan 2011 21:41:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D27888F.4090703@FreeBSD.org> Date: Fri, 07 Jan 2011 13:41:35 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dimitry Andric References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> In-Reply-To: <4D2785A7.7080106@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:41:37 -0000 On 01/07/2011 13:29, Dimitry Andric wrote: > On 2011-01-07 22:22, Doug Barton wrote: >> This is much appreciated work of course, but I'm wondering if you've >> requested an experimental ports run with the change? It would be good to >> know how much damage to expect before the change gets committed. > > Yes, I submitted an exp-run request Nov 15, 2010: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Ah, well done then. :) > Unfortunately, there has been little or no interest. Fair enough, that sounds to me like portmgr is volunteering to clean up the mess then. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 22:26:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC601065673 for ; Fri, 7 Jan 2011 22:26:47 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id 074218FC26 for ; Fri, 7 Jan 2011 22:26:46 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbKGl-0008Xd-UV; Fri, 07 Jan 2011 21:54:48 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ade Lovett In-Reply-To: <4D27888F.4090703@FreeBSD.org> Date: Fri, 7 Jan 2011 15:54:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:26:47 -0000 On Jan 07, 2011, at 15:41 , Doug Barton wrote: > On 01/07/2011 13:29, Dimitry Andric wrote: >>=20 >> Yes, I submitted an exp-run request Nov 15, 2010: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D152268 >> Unfortunately, there has been little or no interest. >=20 > Fair enough, that sounds to me like portmgr is volunteering to clean = up the mess then. Most likely it's low priority given all the other exp-runs that affect = 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of = other infrastructure stuff. Not to mention the impending 7- and 8- = RELEASEs. Then of course there's the issue (which is certainly getting better) of = finding a point in time along the -CURRENT path where the tree is stable = (sic) enough to get through a full ports run (which is one of the bigger = internal stress tests we have of the system). IMO, the best approach would be to make sure it does the right thing = with 'make universe' (twice, naturally, the second time being when all = traces of the previous binutils has been purged from the building = system). Once that's done, commit (please bump __FreeBSD_version as = part of this, in case ports OSVERSION hacks are eventually needed), and = then give the exp-run a whirl -- with all of the above, this should be = nicely after 7.4/8.2 -aDe From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 23:37:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D15E106566C for ; Fri, 7 Jan 2011 23:37:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id C219A8FC18 for ; Fri, 7 Jan 2011 23:37:30 +0000 (UTC) Received: (qmail 3982 invoked by uid 399); 7 Jan 2011 23:37:30 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 7 Jan 2011 23:37:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D27A3B8.4070401@FreeBSD.org> Date: Fri, 07 Jan 2011 15:37:28 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ade Lovett References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> In-Reply-To: <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:37:31 -0000 On 01/07/2011 13:54, Ade Lovett wrote: > > On Jan 07, 2011, at 15:41 , Doug Barton wrote: >> On 01/07/2011 13:29, Dimitry Andric wrote: >>> >>> Yes, I submitted an exp-run request Nov 15, 2010: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately, >>> there has been little or no interest. >> >> Fair enough, that sounds to me like portmgr is volunteering to >> clean up the mess then. > > Most likely it's low priority given all the other exp-runs that > affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a > bunch of other infrastructure stuff. Not to mention the impending 7- > and 8- RELEASEs. That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. > Then of course there's the issue (which is certainly getting better) > of finding a point in time along the -CURRENT path where the tree is > stable (sic) enough to get through a full ports run (which is one of > the bigger internal stress tests we have of the system). IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. The way I would approach the problem of building packages for -current is to pick a day to update the src tree, then do the following: 1. make buildworld && make kernel && reboot && 2. make installworld && reboot && 3. update ports tree && 4. start building ports That can all be automated, and at the point where any of it fails the system barks loudly and stops trying to proceed. This would of course require a human to be involved once a week or so with running mergemaster, and maybe the odd cleanup here or there, but most times that doesn't even have to happen in band. I suggest Wednesday as "the day" to update the source since there is usually a lot of activity on the weekend, and if something is broken on Wednesday it gives people a chance to respond during working hours. The great thing about this is that if it fails, no harm no foul. Having some packages, even a week or so out of date is much better than what we have now. Of course, there are other things that would go along with this ... finding and tagging the very few packages that actually deeply care about system internals being first on the "off the top of my head" list. But the current system of "don't do anything" just isn't cutting it. > IMO, the best approach would be to make sure it does the right thing > with 'make universe' (twice, naturally, the second time being when > all traces of the previous binutils has been purged from the building > system). Once that's done, commit (please bump __FreeBSD_version as > part of this, in case ports OSVERSION hacks are eventually needed), > and then give the exp-run a whirl -- with all of the above, this > should be nicely after 7.4/8.2 If portmgr is unwilling/unable to do the exp-run before dim is ready to commit, then I'd say yes, that all sounds fine; especially bumping __FreeBSD_version. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 00:04:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F7D1065693 for ; Sat, 8 Jan 2011 00:04:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 981AD8FC0A for ; Sat, 8 Jan 2011 00:04:38 +0000 (UTC) Received: by qyk8 with SMTP id 8so927449qyk.13 for ; Fri, 07 Jan 2011 16:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8YAku0c3nc1m+oHbPhinIygowIEnez+JEs3mdv3rnsA=; b=WQHQcqhK9gex9gnT+MPPrAcKI5qhKhU4stkPxVN0b98dY2r+6PCQRNkd/uQjLnCj/m tt6J4jgWmpIlMlX7+9mq5q0ZHtsZp4EFvhoQKapZ8wl/iDI4YyxG1TEiQ701CdePbmSl mX5Jb+AUwmOaIWaS/a1QGWKQ/3ZP3MGOELWzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WNJT2HmzjGNPGn94Vf5qf+olTGW8iHaFZrvHl3f25jjH3mPq84jXs04wMK8tjXJbFD NfB9NJ981+cEC/QIBFuNGilMm6Pp70ij4cmDbpWFMLV9BLOJZ6epdiaQSYs0z1I25eC3 qoY6N+/4bmq6XtykU5u+0ObuBo7dLvVvRV2S8= MIME-Version: 1.0 Received: by 10.229.185.1 with SMTP id cm1mr22907521qcb.81.1294445077710; Fri, 07 Jan 2011 16:04:37 -0800 (PST) Received: by 10.229.39.147 with HTTP; Fri, 7 Jan 2011 16:04:37 -0800 (PST) In-Reply-To: References: <53A6C7B1EBA748F09DE5186D784D2CDA@marekdesktop> Date: Sat, 8 Jan 2011 03:04:37 +0300 Message-ID: From: Sergey Kandaurov To: Marek Salwerowicz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: nfssvc not available or version mismatch (nfsv4 client) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 00:04:39 -0000 On 7 January 2011 12:09, Marek Salwerowicz wrote: >> >> kldload nfssvc && dmesg | tail -n 10 ? >> > > vm-salwerom% sudo kldload nfssvc > kldload: can't load nfssvc: File exists > > but: > > vm-salwerom% sudo kldload nfssvc.ko > vm-salwerom% dmesg | tail -n 10 > em0 at 194.29.146.128 server 194.29.146.27 server name amp2 > subnet mask 255.255.255.0 router 194.29.146.1 rootfs 194.29.146.3:/ rootopts > nolockd hostname vm-salwerom > Adjusted interface em0 > SMP: AP CPU #1 Launched! > Trying to mount root from nfs: []... > NFS ROOT: 194.29.146.3:/ > KLD nfscommon.ko: depends on nfssvc - not available or version mismatch > linker_load_file: Unsupported file type > KLD nfscl.ko: depends on nfssvc - not available or version mismatch > linker_load_file: Unsupported file type > vm-salwerom% > vm-salwerom% > > > so, why if I want to load nfssvc I have to type it with the suffix? How can > I tell nfsuserd and anfscbd to try to load it with suffix during system > boot? That's because .ko (a kldname mode) and w/o .ko (a modname mode) are handled differently (see kern/kern_linker.c). AFAIR, the latter looks if the interface name (modname) is already registered by kernel or some earlier loaded KLD (and returns EEXIST on success), otherwise it searches the requested interface name in the list of available KLDs in the module path and loads the appropriate one. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 00:55:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC51E1065672; Sat, 8 Jan 2011 00:55:03 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27F158FC08; Sat, 8 Jan 2011 00:55:02 +0000 (UTC) Received: by bwz12 with SMTP id 12so10519319bwz.13 for ; Fri, 07 Jan 2011 16:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=SNYOjd81s1D8K2Ipj+u1TR8lO0TKo33eSbUw9YAVkVk=; b=Ph/v5rPdmZp/8zXVl4GJ1S7ZHz8n06PixDnqlYNBeCayw1+ue4IO/zdJZwBJdoH66Y zF7zrtCYzlXss0ln4PnRM+Uv7YI6VYspqvR1quVtRziHvzRdDyQUvzExp59rsRs9WSWl 3bSvJtf4bp7kAulCi6QB9vxH86f5X/UC8CteI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=ctKIsdTeJAN7K2kVf/22XRMAqM8QGOpYC3Y9XOHDCzcZnof1hAH6WvWzVHcz30kk0D HsMR5UAVJTaNLH0xdxI70uAKW99AsbaB5+TEy41BB61gIZtEvueojsl/nrW+kplMdY3f +vmswZRBN1WzmVLvEKPYPIn9zgSqQPPTy05f0= Received: by 10.204.65.206 with SMTP id k14mr587112bki.26.1294448099909; Fri, 07 Jan 2011 16:54:59 -0800 (PST) Received: from localhost (anonymizer3.torservers.net [174.36.199.201]) by mx.google.com with ESMTPS id j11sm14469092bka.12.2011.01.07.16.54.54 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 16:54:59 -0800 (PST) From: Anonymous To: Dimitry Andric References: <4D277E4B.1030006@FreeBSD.org> Date: Sat, 08 Jan 2011 03:54:33 +0300 Message-ID: <864o9kfc52.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 00:55:04 -0000 Dimitry Andric writes: [...] > Please report any problems with either the base system, or ports that > come up as a result of this binutils update. Looks like lang/sbcl doesn't like new ld(1), here on amd64. Same error when building using devel/binutils. Can you reproduce? $ make [...] obj/from-xc/src/code/signal.lisp-obj obj/from-xc/src/code/late-defbangmethod.lisp-obj obj/from-xc/src/pcl/walk.lisp-obj [building initial core file in "output/cold-sbcl.core": writing 8192 bytes [2 pages] from # writing 4096 bytes [1 page] from # writing 44081152 bytes [10762 pages] from # /(DESCRIPTOR-BITS INITIAL-FUN)=#X100288BA79 done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 158.30 real 145.93 user 9.10 sys //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.43, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Bus error 0.20 real 0.07 user 0.13 sys *** Error code 138 $ env -i gdb --args ./src/runtime/sbcl --core output/cold-sbcl.core [...] Program received signal SIGUSR1, User defined signal 1. 0x0000000801f843bc in kill () at kill.S:3 3 RSYSCALL(kill) Current language: auto; currently asm (gdb) bt #0 0x0000000801f843bc in kill () at kill.S:3 #1 0x0000000000411d47 in see_if_sigaction_nodefer_works () at interrupt.c:1691 #2 0x000000000041216d in interrupt_init () at interrupt.c:1828 #3 0x00000000004156e4 in main (argc=3, argv=0x7fffffff3f88, envp=0x7fffffff3fa8) at runtime.c:316 (gdb) bt f #0 0x0000000801f843bc in kill () at kill.S:3 No locals. #1 0x0000000000411d47 in see_if_sigaction_nodefer_works () at interrupt.c:1691 sa = { __sigaction_u = { __sa_handler = 0x411c30 , __sa_sigaction = 0x411c30 }, sa_flags = 80, sa_mask = { __bits = {536870944, 0, 0, 0} } } old_sa = { __sigaction_u = { __sa_handler = 0, __sa_sigaction = 0 }, sa_flags = 2, sa_mask = { __bits = {0, 0, 0, 0} } } #2 0x000000000041216d in interrupt_init () at interrupt.c:1828 i = 0 #3 0x00000000004156e4 in main (argc=3, argv=0x7fffffff3f88, envp=0x7fffffff3fa8) at runtime.c:316 core = 0x0 sbcl_argv = (char **) 0x0 embedded_core_offset = 0 runtime_path = 0x0 noinform = 0 end_runtime_options = 0 disable_lossage_handler_p = 0 initial_function = 140737488306056 sbcl_home = 0x0 From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 05:48:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16C5010656C0; Sat, 8 Jan 2011 05:48:21 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id E13A78FC08; Sat, 8 Jan 2011 05:48:20 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbRf2-0009DH-0C; Sat, 08 Jan 2011 05:48:20 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ade Lovett In-Reply-To: <4D27A3B8.4070401@FreeBSD.org> Date: Fri, 7 Jan 2011 23:48:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> <4D27A3B8.4070401@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1082) Cc: freebsd-current@freebsd.org, Ade Lovett Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "developers@freebsd.org Developers" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 05:48:21 -0000 On Jan 07, 2011, at 17:37 , Doug Barton wrote: > On 01/07/2011 13:54, Ade Lovett wrote: >>=20 >> Most likely it's low priority given all the other exp-runs that >> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a >> bunch of other infrastructure stuff. Not to mention the impending 7- >> and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr =20 > That may very well be the case, but if so then it's incumbent on = portmgr to communicate that. If you check the audit trail you will find = that they did not. Horsecrap. You are taking an individual PR history without reference to = the whole host of things that were also going on at the same time. Like = it or not, when it comes to ports, -STABLE wins over -CURRENT every = single time. > IMO this is a total red herring, and has been for several years now. I = run -current every day on my real-work system, and barring the = occasional hiccup it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. = The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT = on a single system, as opposed to a cluster of systems that are tightly = interlinked. I do not doubt that -CURRENT works for you on your = individual machines. If you would like a taste of how heavily package = build clusters stress out whatever host system they are running on, then = I urge you to install one of the two tinderbox ports under ports-mgmt, = proceed to add, let's say, x11/gnome2 or x11/kde4, and run the build. make buildworld/buildkernel/installworld/installkernel plus associated = steps is in fact an exceptionally tiny subset of what FreeBSD actually = does on a daily basis. Even more so when it comes to the bulk building = of packages that apparently a lot of folks rely on. > The way I would approach the problem of building packages for -current = is to pick a day to update the src tree, then do the following: Sadly, the only thing I can say to your 4-step procedure, and with = utmost politeness, is that your src-centric views are completely missing = the point. "4. start building ports" is in fact a 20- or 30-step = process to ensure no cross-contamination. Even a cursory glance at = /usr/ports/Tools/portbuild would verify this. No-one really likes = having massive clusters, requiring continual attention (hardware = failures and so on). Really. > But the current system of "don't do anything" just isn't cutting it. I look forward to your input and total solutions on how to make this = better. I do. This may sound sarcastic, but I am absolutely, = positively, 100-percent looking for better solutions, particularly in = situations where, to take a random example, the entire existing compiler = base is removed and replaced with something better. Doug, you have comprehensively shown that in its current (sic) = instantiation, the package building cluster is completely, utterly, and = totally incapable of keeping up with the sandbox that is -CURRENT. I for one look forward to your proposed solutions to this righteous = problem. Regards, -aDe From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 06:06:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8665910656BF; Sat, 8 Jan 2011 06:06:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 442888FC12; Sat, 8 Jan 2011 06:05:59 +0000 (UTC) Received: by pxi1 with SMTP id 1so3516156pxi.13 for ; Fri, 07 Jan 2011 22:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mbj6jah5B5afXIEmqm/eJAX3d4hUudpyAs1Wne8rogk=; b=Uy+U+D80+3rdBFx+8EdC4fe8DwdqG3OpYogkRjmMMbaRwv/CL0ZiDkjMcGNlJ9j0i6 2XkN6nfDgtQnts0Cj4e5NGmsvnZXEqvpGSuf1c4x9myQrQN2n+VKDGGeCSOxii+I2ucK mQid6kPSWqRa/FJGDa0tlQb1M9FUjvFFrdN74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AArIWnY3M9NLAudj/S5lbZtIz8GpndTFNnaeiJrkPhLlAW/WabhZxT5/eG1NU9fNEh +4fo7mq+6xrWUfSTA0jbHM5BM2H9avKWDOVzsB1NJzeaBtwgcPMDNI+UTvebVUbz0q0s y0DZvHpeuaxL9+3szHGh69NxNZp3ixJixeML4= Received: by 10.142.188.21 with SMTP id l21mr2374447wff.14.1294466759531; Fri, 07 Jan 2011 22:05:59 -0800 (PST) Received: from dhcp-173-37-0-197.cisco.com (nat.ironport.com [63.251.108.100]) by mx.google.com with ESMTPS id x35sm3741162wfd.1.2011.01.07.22.05.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 22:05:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> Date: Fri, 7 Jan 2011 22:05:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> <4D27A3B8.4070401@FreeBSD.org> <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> To: "developers@freebsd.org Developers" X-Mailer: Apple Mail (2.1082) Cc: Doug Barton , Ade Lovett , freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 06:06:00 -0000 On Jan 7, 2011, at 9:48 PM, Ade Lovett wrote: >=20 > On Jan 07, 2011, at 17:37 , Doug Barton wrote: >> On 01/07/2011 13:54, Ade Lovett wrote: >>>=20 >>> Most likely it's low priority given all the other exp-runs that >>> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a >>> bunch of other infrastructure stuff. Not to mention the impending = 7- >>> and 8- RELEASEs. >=20 > Before I start on this, I would like a few things noted for the = record: >=20 > 1. I have set Reply-To to developers@ (this should be a major hint) > 2. I am not a current member of portmgr@ > 3. I requested, and served, for a very short time, on the first = portmgr >=20 >=20 >> That may very well be the case, but if so then it's incumbent on = portmgr to communicate that. If you check the audit trail you will find = that they did not. >=20 > Horsecrap. You are taking an individual PR history without reference = to the whole host of things that were also going on at the same time. = Like it or not, when it comes to ports, -STABLE wins over -CURRENT every = single time. >=20 >> IMO this is a total red herring, and has been for several years now. = I run -current every day on my real-work system, and barring the = occasional hiccup it's been buildable nearly every time I've tried. >=20 > Apologies for not being able to drive my email client appropriately. = The issue at hand is one of running -CURRENT. >=20 > There is a distinct, and fundamental difference between running = -CURRENT on a single system, as opposed to a cluster of systems that are = tightly interlinked. I do not doubt that -CURRENT works for you on = your individual machines. If you would like a taste of how heavily = package build clusters stress out whatever host system they are running = on, then I urge you to install one of the two tinderbox ports under = ports-mgmt, proceed to add, let's say, x11/gnome2 or x11/kde4, and run = the build. >=20 > make buildworld/buildkernel/installworld/installkernel plus associated = steps is in fact an exceptionally tiny subset of what FreeBSD actually = does on a daily basis. Even more so when it comes to the bulk building = of packages that apparently a lot of folks rely on. >=20 >> The way I would approach the problem of building packages for = -current is to pick a day to update the src tree, then do the following: >=20 > Sadly, the only thing I can say to your 4-step procedure, and with = utmost politeness, is that your src-centric views are completely missing = the point. "4. start building ports" is in fact a 20- or 30-step = process to ensure no cross-contamination. Even a cursory glance at = /usr/ports/Tools/portbuild would verify this. No-one really likes = having massive clusters, requiring continual attention (hardware = failures and so on). Really. >=20 >> But the current system of "don't do anything" just isn't cutting it. >=20 > I look forward to your input and total solutions on how to make this = better. I do. This may sound sarcastic, but I am absolutely, = positively, 100-percent looking for better solutions, particularly in = situations where, to take a random example, the entire existing compiler = base is removed and replaced with something better. >=20 > Doug, you have comprehensively shown that in its current (sic) = instantiation, the package building cluster is completely, utterly, and = totally incapable of keeping up with the sandbox that is -CURRENT. >=20 > I for one look forward to your proposed solutions to this righteous = problem. Hi Ade, Sorry to jump in, but I think that a lot of the solution to this = problem is two part: 1. Using the VM resources at your.org . 2. Replicating pointyhat's infrastructure for mass deployment. Back at BSDCan 2010 your.org offered cycles and resources for = tinderboxes (ports and src alike), but I think that due to lack of time = / resources portmgr hasn't been able to invest in that solution (*slap = me please if I'm incorrect :)..*). Not sure if the src development = tinderbox infrastructure became a reality either. If developers had access to a [relatively] easy to deploy = infrastructure and pointyhat was easy to replicate (that in and of = itself is a major project that linimon@ was working on in the past year = or so), then this would be less of a problem. Granted, the ports tree is huge, but by now dim@ could have = probably finished off a few self-service exp-runs on his own if he could = have done it on his own. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 06:35:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D54410656C2 for ; Sat, 8 Jan 2011 06:35:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id A8CF98FC19 for ; Sat, 8 Jan 2011 06:35:24 +0000 (UTC) Received: (qmail 13178 invoked by uid 399); 8 Jan 2011 06:35:23 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Jan 2011 06:35:23 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D2805AA.2090700@FreeBSD.org> Date: Fri, 07 Jan 2011 22:35:22 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> <4D27A3B8.4070401@FreeBSD.org> <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> In-Reply-To: <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@FreeBSD.org, Ade Lovett Subject: Package building for -current (Was: Re: HEADS UP: Merge of binutils 2.17) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 06:35:25 -0000 I'm happy to have a discussion about this topic either publicly, or privately, your choice. Since your message went to -current@, that's where my reply is headed. I've also cc'ed ports@ since the topic is relevant there too. Meanwhile, I've snipped some of what you wrote to focus on the issues that I think are most relevant. I value and respect both your opinion and your experience in these issues, but I have some rather profound disagreements with your conclusions. On 01/07/2011 21:48, Ade Lovett wrote: > > On Jan 07, 2011, at 17:37 , Doug Barton wrote: >> On 01/07/2011 13:54, Ade Lovett wrote: >>> >>> Most likely it's low priority given all the other exp-runs that >>> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and >>> a bunch of other infrastructure stuff. Not to mention the >>> impending 7- and 8- RELEASEs. > > Before I start on this, I would like a few things noted for the > record: > > 1. I have set Reply-To to developers@ (this should be a major hint) > 2. I am not a current member of portmgr@ 3. I requested, and > served, for a very short time, on the first portmgr > > >> That may very well be the case, but if so then it's incumbent on >> portmgr to communicate that. If you check the audit trail you will >> find that they did not. > > Horsecrap. You are taking an individual PR history without reference > to the whole host of things that were also going on at the same time. > Like it or not, when it comes to ports, -STABLE wins over -CURRENT > every single time. I disagree rather profoundly on this point. We have a tolerance/expectation of our leadership just plain not communicating with us that has gone way past unhealthy. It takes 30 seconds to respond to a PR and say "We can't get to this before the pending releases, here is a suggested course of action." That's a perfectly reasonable thing for a person to expect in response to a request. In addition to not responding just being plain rude, it fosters the attitude of "Why should I bother communicating with portmgr, they never respond anyway." Not to mention the fact that occasionally the fact that portmgr doesn't like to communicate can sometimes create actual problems, such as when they removed the MD5 checksum stuff without warning, and therefore broke all the ports management and other tools that depended on them. I was glad of the action to finish the change, but the action came after months of no communication about it at all. >> IMO this is a total red herring, and has been for several years >> now. I run -current every day on my real-work system, and barring >> the occasional hiccup it's been buildable nearly every time I've >> tried. > > Apologies for not being able to drive my email client appropriately. > The issue at hand is one of running -CURRENT. > > There is a distinct, and fundamental difference between running > -CURRENT on a single system, as opposed to a cluster of systems that > are tightly interlinked. Believe it or not, I understand that. I also get that sometimes running package building on -current stresses it in ways that cause it to break. That's a good thing. :) My point is that YEARS of ignoring the problem is not acceptable, and needs to change. For a long time portmgr griped about not having enough systems for the build cluster. Now they have plenty of hardware available, but the problem is that the system is too pointy-hat centric. Apparently significant progress has been made in that area, but none of it seems to have trickled down to actually getting more packages built for more platforms better and faster. I do, honestly, get that this is a hard problem. But if portmgr needs help, it needs to ask for it. It asked for and received more hardware, so clearly the foundation and the FreeBSD community at large is ready to step up to help. I think it's pretty obvious at this point that the gating factor is person-hours, so portmgr needs to be a lot more aggressive in developing new volunteers, asking for help with specific tasks, etc. etc. The fact that they are dealing with hard problems is no longer an acceptable excuse for years of failure to solve them. > Sadly, the only thing I can say to your 4-step procedure, and with > utmost politeness, is that your src-centric views are completely > missing the point. "4. start building ports" is in fact a 20- or > 30-step process to ensure no cross-contamination. Once again, I get that bit too. Since we do, in fact, already have a package building cluster I was handwaving it because I was trying to address your red herring about "we can't find a version of -current we like so we can't even try." The essential points that I'm trying to communicate are: 1. Most of the time HEAD works pretty well nowadays 2. Very few ports care that deeply about the guts of the system they are running on > I look forward to your input and total solutions on how to make this > better. I do. See above. I would love it if the foundation wanted to fund me to spend the amount of time it would take to actually step in and do the work, but I myself cannot do it alone as a volunteer. That's even if portmgr would accept my help which I find rather highly unlikely. My point is not, "I know all the answers," my point is that the solution is not going to come from continuing to ignore the problem; and if portmgr does not currently have the people-bandwidth necessary to address it then it ought to be reaching out to develop it. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 07:50:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5968D1065673 for ; Sat, 8 Jan 2011 07:50:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id DCBBC8FC0A for ; Sat, 8 Jan 2011 07:50:45 +0000 (UTC) Received: (qmail 23717 invoked by uid 399); 8 Jan 2011 07:50:45 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Jan 2011 07:50:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D281753.4060105@FreeBSD.org> Date: Fri, 07 Jan 2011 23:50:43 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Churanov References: <4D1E812A.5060500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: boost libs error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 07:50:46 -0000 On 01/01/2011 13:40, Alexander Churanov wrote: > 2011/1/1 Doug Barton: >> I'm getting the following with qbittorrent-23 which depends on >> libtorrent-rasterbar-15 after the latest boost lib update: >> >> qbittorrent >> terminate called after throwing an instance of 'std::runtime_error' >> what(): locale::facet::_S_create_c_locale name not valid >> Abort trap: 6 (core dumped) > > Doug, please, check whether you have are observing the issue ports/153561. > > Alexander Churanov, > maintainer of devel/boost-* I didn't see your reply to the PR, so I wasn't aware that you had approved the patches until I double-checked tonight. But the update is done now, thanks! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 13:56:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE8E310656A7; Sat, 8 Jan 2011 13:56:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AD7F88FC08; Sat, 8 Jan 2011 13:56:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9851:3b44:3a32:d7a0] (unknown [IPv6:2001:7b8:3a7:0:9851:3b44:3a32:d7a0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F1B5C5C5A; Sat, 8 Jan 2011 14:56:57 +0100 (CET) Message-ID: <4D286D30.2020002@FreeBSD.org> Date: Sat, 08 Jan 2011 14:57:04 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: Ade Lovett References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> In-Reply-To: <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 13:56:59 -0000 On 2011-01-07 22:54, Ade Lovett wrote: > Most likely it's low priority given all the other exp-runs that affect > 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of > other infrastructure stuff. Not to mention the impending 7- and 8- > RELEASEs. I understand, and there will probably also be shortage of people with time during the holiday season. I'm fine with holding this off for as long as it takes to make it work for everybody. It would be nice to get it in well before 9.0 slowly starts going into freeze mode, though. > Then of course there's the issue (which is certainly getting better) > of finding a point in time along the -CURRENT path where the tree is > stable (sic) enough to get through a full ports run (which is one of > the bigger internal stress tests we have of the system). Yes, unfortunately there are some stability problems in vanilla -current as of late, especially with long multiprocess builds, such as universes or bulk packaging with -j nnn. Sometimes it panics. :( > IMO, the best approach would be to make sure it does the right thing > with 'make universe' (twice, naturally, the second time being when all > traces of the previous binutils has been purged from the building > system). Since the beginning of the binutils 2.17 project branch, I have built universes many times with it, and as far as I know, all problems with the base system have been solved, on all arches. > Once that's done, commit (please bump __FreeBSD_version as > part of this, in case ports OSVERSION hacks are eventually needed), > and then give the exp-run a whirl -- with all of the above, this should > be nicely after 7.4/8.2 I would rather see exp-run results before committing this. :) From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 18:22:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0F9F10656D9; Sat, 8 Jan 2011 18:22:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 835438FC16; Sat, 8 Jan 2011 18:22:00 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p08ILxpe026548; Sat, 8 Jan 2011 13:21:59 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sat, 08 Jan 2011 13:21:59 -0500 (EST) Date: Sat, 8 Jan 2011 13:21:59 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: References: <20110107103837.E14966@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-1294510919=:27326" Cc: rrs@freebsd.org, freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:22:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-959030623-1294510919=:27326 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 7 Jan 2011, Daniel Eischen wrote: > On Fri, 7 Jan 2011, Daniel Eischen wrote: > >> On Fri, 7 Jan 2011, Bjoern A. Zeeb wrote: >> >>> On Fri, 7 Jan 2011, Daniel Eischen wrote: >>> >>>> When sending multicast packets to a socket that is _not_ >>>> bound to the multicast address, this generates bad UDP >>>> checksums. This use to work and was broke sometime between >>>> the middle of October and late December as far as I can >>>> tell. >>> >>> My very best guess would be: r215110 >> >> It doesn't look very harmful, but I'll try backing it out. > > Backing this out seems to fix it. I'll have to test it > more after I get some sleep ;-) I've attached what may be a proper patch. Please review. I'd like to get this fixed in releng_8 too. -- DE ---559023410-959030623-1294510919=:27326 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=in_pcb.c.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=in_pcb.c.diff SW5kZXg6IG5ldGluZXQvaW5fcGNiLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCi0tLSBuZXRpbmV0L2luX3BjYi5jCShyZXZpc2lvbiAyMTY2OTApDQor KysgbmV0aW5ldC9pbl9wY2IuYwkod29ya2luZyBjb3B5KQ0KQEAgLTg3NCw2 ICs4NzQsNyBAQA0KIAkJfQ0KIAl9DQogCWlmIChsYWRkci5zX2FkZHIgPT0g SU5BRERSX0FOWSkgew0KKwkJZXJyb3IgPSBpbl9wY2JsYWRkcihpbnAsICZm YWRkciwgJmxhZGRyLCBjcmVkKTsNCiAJCS8qDQogCQkgKiBJZiB0aGUgZGVz dGluYXRpb24gYWRkcmVzcyBpcyBtdWx0aWNhc3QgYW5kIGFuIG91dGdvaW5n DQogCQkgKiBpbnRlcmZhY2UgaGFzIGJlZW4gc2V0IGFzIGEgbXVsdGljYXN0 IG9wdGlvbiwgdXNlIHRoZQ0KQEAgLTg5MywxNiArODk0LDE3IEBADQogCQkJ CQkJYnJlYWs7DQogCQkJCWlmIChpYSA9PSBOVUxMKSB7DQogCQkJCQlJTl9J RkFERFJfUlVOTE9DSygpOw0KLQkJCQkJcmV0dXJuIChFQUREUk5PVEFWQUlM KTsNCisJCQkJCWVycm9yID0gRUFERFJOT1RBVkFJTDsNCisJCQkJfSBlbHNl IHsNCisJCQkJCWxhZGRyID0gaWEtPmlhX2FkZHIuc2luX2FkZHI7DQorCQkJ CQlJTl9JRkFERFJfUlVOTE9DSygpOw0KKwkJCQkJLyogT3ZlcnJpZGUgZXJy b3IgZnJvbSBpbl9wY2JsYWRkcigpLiAqLw0KKwkJCQkJZXJyb3IgPSAwOw0K IAkJCQl9DQotCQkJCWxhZGRyID0gaWEtPmlhX2FkZHIuc2luX2FkZHI7DQot CQkJCUlOX0lGQUREUl9SVU5MT0NLKCk7DQogCQkJfQ0KLQkJfSBlbHNlIHsN Ci0JCQllcnJvciA9IGluX3BjYmxhZGRyKGlucCwgJmZhZGRyLCAmbGFkZHIs IGNyZWQpOw0KLQkJCWlmIChlcnJvcikgDQotCQkJCXJldHVybiAoZXJyb3Ip Ow0KIAkJfQ0KKwkJaWYgKGVycm9yKQ0KKwkJCXJldHVybiAoZXJyb3IpOw0K IAl9DQogCW9pbnAgPSBpbl9wY2Jsb29rdXBfaGFzaChpbnAtPmlucF9wY2Jp bmZvLCBmYWRkciwgZnBvcnQsIGxhZGRyLCBscG9ydCwNCiAJICAgIDAsIE5V TEwpOw0K ---559023410-959030623-1294510919=:27326-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 19:10:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7A20106571E; Sat, 8 Jan 2011 19:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADAF8FC0C; Sat, 8 Jan 2011 19:10:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B2D5841C707; Sat, 8 Jan 2011 20:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id MKQXYujFXA8C; Sat, 8 Jan 2011 20:10:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E0EA641C6FC; Sat, 8 Jan 2011 20:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 696DE4448F3; Sat, 8 Jan 2011 19:07:04 +0000 (UTC) Date: Sat, 8 Jan 2011 19:07:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Daniel Eischen In-Reply-To: Message-ID: <20110108185914.D14966@maildrop.int.zabbadoz.net> References: <20110107103837.E14966@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:10:08 -0000 On Sat, 8 Jan 2011, Daniel Eischen wrote: >>>>> When sending multicast packets to a socket that is _not_ >>>>> bound to the multicast address, this generates bad UDP >>>>> checksums. This use to work and was broke sometime between >>>>> the middle of October and late December as far as I can >>>>> tell. >>>> >>>> My very best guess would be: r215110 >>> >>> It doesn't look very harmful, but I'll try backing it out. >> >> Backing this out seems to fix it. I'll have to test it >> more after I get some sleep ;-) > > I've attached what may be a proper patch. Please review. > I'd like to get this fixed in releng_8 too. I would remove the comment from the MC good path about the in_pcbladdr() error but just change the description at the top s,use,prefer, to be more exact. The other question I am not sure what shoud happen is, in the case in_pcbladdr() returns a source address but a given one via MC option/ifp does not find an address (in case outgoing itnerface could be different)? That was never considered in the past. It's probably easiest understood with the slightly modified version of the patch. Otherwise I think it would match both the historic behaviour again and keep the fix for r215110 (that rev. should be mentioned in the commit message). So apart from the 1 line comment change (ignoring my XXX-BZ completely for the moment and this fix) this looks good. /bz PS: I doubt you can make 8.2-R anymore. Index: in_pcb.c =================================================================== --- in_pcb.c (revision 216952) +++ in_pcb.c (working copy) @@ -874,9 +874,10 @@ in_pcbconnect_setup(struct inpcb *inp, struct sock } } if (laddr.s_addr == INADDR_ANY) { + error = in_pcbladdr(inp, &faddr, &laddr, cred); /* * If the destination address is multicast and an outgoing - * interface has been set as a multicast option, use the + * interface has been set as a multicast option, prefer the * address of that interface as our source address. */ if (IN_MULTICAST(ntohl(faddr.s_addr)) && @@ -893,16 +894,23 @@ in_pcbconnect_setup(struct inpcb *inp, struct sock break; if (ia == NULL) { IN_IFADDR_RUNLOCK(); - return (EADDRNOTAVAIL); + /* + * XXX-BZ should we use a possible + * source address from in_pcbladdr() + * and only overwrite the error if + * there was one? + * if (error) + */ + error = EADDRNOTAVAIL; + } else { + laddr = ia->ia_addr.sin_addr; + IN_IFADDR_RUNLOCK(); + error = 0; } - laddr = ia->ia_addr.sin_addr; - IN_IFADDR_RUNLOCK(); } - } else { - error = in_pcbladdr(inp, &faddr, &laddr, cred); - if (error) - return (error); } + if (error) + return (error); } oinp = in_pcblookup_hash(inp->inp_pcbinfo, faddr, fport, laddr, lport, 0, NULL); -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 19:31:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3DBB1065695 for ; Sat, 8 Jan 2011 19:31:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5E858FC0A for ; Sat, 8 Jan 2011 19:31:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:9851:3b44:3a32:d7a0] (unknown [IPv6:2001:7b8:3a7:0:9851:3b44:3a32:d7a0]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B0BEB5C5A; Sat, 8 Jan 2011 20:31:02 +0100 (CET) Message-ID: <4D28BB7B.3080004@FreeBSD.org> Date: Sat, 08 Jan 2011 20:31:07 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.14pre) Gecko/20110104 Lanikai/3.1.8pre MIME-Version: 1.0 To: Anonymous References: <4D277E4B.1030006@FreeBSD.org> <864o9kfc52.fsf@gmail.com> In-Reply-To: <864o9kfc52.fsf@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:31:04 -0000 On 2011-01-08 01:54, Anonymous wrote: > Looks like lang/sbcl doesn't like new ld(1), here on amd64. > Same error when building using devel/binutils. Can you reproduce? ... > //doing warm init - compilation phase > This is SBCL 1.0.43, an implementation of ANSI Common Lisp. > More information about SBCL is available at. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > Bus error Yes, it gives a bus error here too, at least on amd64. I found a similar thread about such an issue with sbcl, started by you in March 2009: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004690.html It looks like in this case, the same problem happens, it eats large amounts of memory, and then dies (this is on a box with 4G RAM and a few G of swap): PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 33512 dim 1 111 0 8244M 3055M CPU1 1 0:54 68.99% sbcl Obviously, when it tries to actually access stuff that is above the total virtual memory of the box, it will die. In any case, the workaround in that previous thread (setting the sysctl machdep.prot_fault_translation=2) works for me, at least to let the port build to completion, and install succesfully. Now, in the previous report, it seems there was something going on with .note.ABI-tag sections, which needed a kernel fix. And since Kostik is now introducing new .note sections, for the non-executable stack feature, it may be that I just hit a window where it is not entirely complete? The last sync of binutils-2.17 with head was at r217118, just after the introduction of those .note sections, but before several related changes in the kernel and other areas. I will sync the binutils-2.17 branch again, and see if that helps the port to build without setting the workaround sysctl. From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 21:05:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7900F1065673; Sat, 8 Jan 2011 21:05:46 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0168FC17; Sat, 8 Jan 2011 21:05:45 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id p08KsWMl018263; Sat, 8 Jan 2011 15:54:32 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Sat, 08 Jan 2011 15:54:32 -0500 (EST) Date: Sat, 8 Jan 2011 15:54:32 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bjoern A. Zeeb" In-Reply-To: <20110108185914.D14966@maildrop.int.zabbadoz.net> Message-ID: References: <20110107103837.E14966@maildrop.int.zabbadoz.net> <20110108185914.D14966@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:05:46 -0000 On Sat, 8 Jan 2011, Bjoern A. Zeeb wrote: > On Sat, 8 Jan 2011, Daniel Eischen wrote: > >>>>>> When sending multicast packets to a socket that is _not_ >>>>>> bound to the multicast address, this generates bad UDP >>>>>> checksums. This use to work and was broke sometime between >>>>>> the middle of October and late December as far as I can >>>>>> tell. >>>>> >>>>> My very best guess would be: r215110 >>>> >>>> It doesn't look very harmful, but I'll try backing it out. >>> >>> Backing this out seems to fix it. I'll have to test it >>> more after I get some sleep ;-) >> >> I've attached what may be a proper patch. Please review. >> I'd like to get this fixed in releng_8 too. > > I would remove the comment from the MC good path about the in_pcbladdr() > error but just change the description at the top s,use,prefer, to be > more exact. Agreed. > The other question I am not sure what shoud happen is, in the case > in_pcbladdr() returns a source address but a given one via MC option/ifp > does not find an address (in case outgoing itnerface could be different)? > That was never considered in the past. Yes, I considered that as well. I wasn't sure about that, but the more I think about it, it might make sense to ignore any error from an invalid/nonexistent interface set as an MC option if we are able to find one via in_pcbladdr(). But we'll ignore that for now. Also, are there any restrictions with jail? If we're in a jail and can't find an address, do we really want to allow _any_ address set with an MC option? I've never used jails, but was just wondering if the application could somehow use an interface address that it wasn't allowed to use. > It's probably easiest understood with the slightly modified version > of the patch. > > Otherwise I think it would match both the historic behaviour again > and keep the fix for r215110 (that rev. should be mentioned in the > commit message). > > So apart from the 1 line comment change (ignoring my XXX-BZ completely > for the moment and this fix) this looks good. Ok, I'll commit the patch, and thank you very much for helping me solve this problem :-) -- DE From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 21:32:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD58106564A; Sat, 8 Jan 2011 21:32:13 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 563748FC17; Sat, 8 Jan 2011 21:32:13 +0000 (UTC) Received: by yie19 with SMTP id 19so5342101yie.13 for ; Sat, 08 Jan 2011 13:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ncksmiFQKCmBI2P8rQhBXiONfsK5bCgLIPMaWjmZKmk=; b=Xs0nd8Qxz5zYcL+gWeB0dS87u/gS2m8xYwMkmzOxqcAvtC2NL7SBU56rZDP8cdx17Q SvBchH8/CwNDyebF2qWToz7mAEYG7rDXmla8crhz/332fFouWPEQfZKAK4AxVnQFmIbv 1cEV+sS0WO51S1OWPN/RPHpChUlr3wKQ3YsiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AlnMuqjXNiAo/Gm64m9FDQC5Obu4QsI+qDxI0YCFJ+azQ8JRuXkA8nJDv2s4Lz/YnF hzwvYTadmL8Y4olb3rkvB95yE5zkON+Dlk7scBbeXUU4QcMuESvQIzfOd3cQuIwTsrhP AR7GUBNRPhkkM3LXzR1Udihpx8Pn1SY7rei8g= MIME-Version: 1.0 Received: by 10.100.112.9 with SMTP id k9mr16248228anc.50.1294520908772; Sat, 08 Jan 2011 13:08:28 -0800 (PST) Received: by 10.100.166.5 with HTTP; Sat, 8 Jan 2011 13:08:28 -0800 (PST) In-Reply-To: <4D26327E.7070307@freebsd.org> References: <4D26327E.7070307@freebsd.org> Date: Sat, 8 Jan 2011 21:08:28 +0000 Message-ID: From: "Sevan / Venture37" To: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: [ANNOUNCE] Playstation 3 support now in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:32:13 -0000 Well done Nathan, very cool! :) any chance you could post the dmesg output to the list Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 21:40:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF497106564A; Sat, 8 Jan 2011 21:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9A88FC12; Sat, 8 Jan 2011 21:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6338241C710; Sat, 8 Jan 2011 22:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id OeKFaYK3KxTX; Sat, 8 Jan 2011 22:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id C516E41C735; Sat, 8 Jan 2011 22:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D56AD44490C; Sat, 8 Jan 2011 21:35:19 +0000 (UTC) Date: Sat, 8 Jan 2011 21:35:19 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Daniel Eischen In-Reply-To: Message-ID: <20110108211712.T14966@maildrop.int.zabbadoz.net> References: <20110107103837.E14966@maildrop.int.zabbadoz.net> <20110108185914.D14966@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randall Stewart , freebsd-current@freebsd.org Subject: Re: UDP checksum broken, -head and releng_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:40:07 -0000 On Sat, 8 Jan 2011, Daniel Eischen wrote: > Also, are there any restrictions with jail? If we're > in a jail and can't find an address, do we really want > to allow _any_ address set with an MC option? I've > never used jails, but was just wondering if the > application could somehow use an interface address > that it wasn't allowed to use. Yes, I think you can do that there but I'd hope the bind following would fail it. -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 23:10:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3001065670 for ; Sat, 8 Jan 2011 23:10:50 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7716A8FC18 for ; Sat, 8 Jan 2011 23:10:50 +0000 (UTC) Received: from macfeast.lan (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp3.one.com (Postfix) with ESMTP id C27D124061D7; Sat, 8 Jan 2011 23:10:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-317-540951899; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: <1294515254.16774.32.camel@hood.oook.cz> Date: Sun, 9 Jan 2011 00:10:47 +0100 Message-Id: References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> <4D27A3B8.4070401@FreeBSD.org> <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> <1294515254.16774.32.camel@hood.oook.cz> To: pav@FreeBSD.org X-Mailer: Apple Mail (2.1082) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , Ivan Voras , freebsd-ports@FreeBSD.org Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:10:51 -0000 --Apple-Mail-317-540951899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: > Package cluster is quite clever, akshully, and since this is OT here, > just terse comments Sorry, replied to a bad message... redirecting to current@ >>> 1. adding SSD disks >=20 > irrelevant because of bullet 2. >=20 >>> 2. source and destination directories on md devices >=20 > already done, swap backed md devices are used >=20 >>> 3. huge ccache cache >>> 4. dist-cc >=20 > these tend to have their own issues >=20 >>> 5. some heuristics on which ports could be skipped because = dependencies haven't changed since last run >=20 > this is also already done, we call it "incremental builds" >=20 >>> 6. tuning the host system for this specific task >=20 > empty words I was pretty sure I couldn't improve anything with 5 minutes of = thinking. I'm glad the most obvious things have already been done, and = I'm sure you and others have put a lot of effort into this. My question = was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Thanks, Erik= --Apple-Mail-317-540951899-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 23:56:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C677F106566B for ; Sat, 8 Jan 2011 23:56:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 674B48FC12 for ; Sat, 8 Jan 2011 23:56:21 +0000 (UTC) Received: by iwn39 with SMTP id 39so18525244iwn.13 for ; Sat, 08 Jan 2011 15:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=B1m3dTXOur3MQskmWvHkFJOTRhd2LJewyADTuqZuv/U=; b=CGskIMUYaLPGI4+BPJVZVWnFkGjw1euqSItJQg3p5UCubZpg9Tp1SjwG2ZDvEk5bjJ VSvUEwPwW3T5hiauwWcTPWouo7kuSjWIz1+PDR7BdmME1aemnlCd4WmvV1Dh7EhJds9b c6Rqjpbksudb0jF8XT5I9orYvRpVWV0wXXCk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PZHG4AAQQnAHo85hTDoRMVmkvaCUKT4/eTRH/oTUjEKK/JvR/mEayeeDqb5CpZIBL7 BPx0WG8bk7h7GScRc7yAUTx6yoGcC95BMqOOTAj8XX6gYVhiBS2NRZ+DqlcVLA4p01FI 9rjx3qicPT81AQSOLnTW8Nkmb2H2++x1IxE4g= Received: by 10.42.171.197 with SMTP id k5mr1971006icz.505.1294530980585; Sat, 08 Jan 2011 15:56:20 -0800 (PST) Received: from [192.168.20.5] (c-24-130-151-210.hsd1.ca.comcast.net [24.130.151.210]) by mx.google.com with ESMTPS id k42sm2080695ick.20.2011.01.08.15.56.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 15:56:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sat, 8 Jan 2011 15:56:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6FBE1A24-CA62-4F08-99C1-EBAC4C3AC956@gmail.com> References: <4D277E4B.1030006@FreeBSD.org> <4D27840A.8020107@FreeBSD.org> <4D2785A7.7080106@FreeBSD.org> <4D27888F.4090703@FreeBSD.org> <467EA052-70AB-4C4C-B28E-9AD037C8BF14@FreeBSD.org> <4D27A3B8.4070401@FreeBSD.org> <82CF1B3F-B5F0-4B26-A6D1-8767370C1E0E@FreeBSD.org> <1294515254.16774.32.camel@hood.oook.cz> To: Erik Cederstrand X-Mailer: Apple Mail (2.1082) Cc: pav@FreeBSD.org, Ivan Voras , freebsd-ports@FreeBSD.org, FreeBSD Current Subject: Re: HEADS UP: Merge of binutils 2.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:56:21 -0000 On Jan 8, 2011, at 3:10 PM, Erik Cederstrand wrote: > Hello Pav, >=20 > Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: >=20 >> Package cluster is quite clever, akshully, and since this is OT here, >> just terse comments >=20 > Sorry, replied to a bad message... redirecting to current@ >=20 >>>> 1. adding SSD disks >>=20 >> irrelevant because of bullet 2. >>=20 >>>> 2. source and destination directories on md devices >>=20 >> already done, swap backed md devices are used >>=20 >>>> 3. huge ccache cache >>>> 4. dist-cc >>=20 >> these tend to have their own issues >>=20 >>>> 5. some heuristics on which ports could be skipped because = dependencies haven't changed since last run >>=20 >> this is also already done, we call it "incremental builds" >>=20 >>>> 6. tuning the host system for this specific task >>=20 >> empty words >=20 > I was pretty sure I couldn't improve anything with 5 minutes of = thinking. I'm glad the most obvious things have already been done, and = I'm sure you and others have put a lot of effort into this. My question = was more what, if anything, can be done to speed up the cluster. >=20 > Also, how long does it take to complete an exp-run on the cluster? Erik, As I said before, the tinderbox / exp-run infrastructure needs = to be made portable, the infrastructure needs to be there, and as extra = credit (I've stated this in other emails in the past) parallelization in = ports/pkg_install needs to be fixed as ports/packaging in FreeBSD = doesn't work in an ACID[1]-like manner. I'd rather not repeat the = reasons in greater detail. Please look for my replies to this thread on = current@ for more details in "part A", and look for my replies on ports@ = for more details in "part B". Thanks, -Garrett 1. http://en.wikipedia.org/wiki/ACID=