From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 10 16:35:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3236616A7FE; Sat, 10 Jun 2006 16:35:42 +0000 (UTC) (envelope-from hiroo@oikumene.gcd.org) Received: from smtp2.inetd.co.jp (smtp2.inetd.co.jp [211.13.220.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50FE74525D; Sat, 10 Jun 2006 09:31:22 +0000 (GMT) (envelope-from hiroo@oikumene.gcd.org) Received: from chrysanthe.oikumene.gcd.org (206.162.192.61.tokyo.global.alpha-net.ne.jp [61.192.162.206]) by smtp2.inetd.co.jp (Postfix) with ESMTP id 2748EC4EB3; Sat, 10 Jun 2006 18:31:21 +0900 (JST) Received: from chrysanthe.oikumene.gcd.org (mail.oikumene.gcd.org [192.168.0.2]) (authenticated bits=0) by chrysanthe.oikumene.gcd.org (8.13.6/8.13.6) with ESMTP id k5A9VAmS000694; Sat, 10 Jun 2006 18:31:16 +0900 (JST) (envelope-from hiroo@oikumene.gcd.org) Date: Sat, 10 Jun 2006 18:31:10 +0900 Message-ID: <86ver9qrvl.wl%hiroo@oikumene.gcd.org> From: Hiroo Ono To: Alexander Leidinger In-Reply-To: <20060531133814.acykloyqhkcccg80@netchild.homeip.net> References: <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> <4433CA53.5050000@freebsd.org> <444E13BA.8050902@freebsd.org> <4475C119.1020305@freebsd.org> <447C919B.20303@freebsd.org> <86bqteikj4.fsf@xps.des.no> <20060531133814.acykloyqhkcccg80@netchild.homeip.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sun, 11 Jun 2006 00:04:46 +0000 Cc: ozawa@ongs.co.jp, dkirhlarov@oilspace.com, freebsd-hackers@freebsd.org, Daichi GOTO , meianoite@gmail.com, freebsd-fs@freebsd.org, freebsd-current@freebsd.org, kris@obsecurity.org, Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Subject: Re: [ANN] unionfs patchset-13 release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 16:35:42 -0000 At Wed, 31 May 2006 13:38:14 +0200, Alexander Leidinger wrote: > He's not a src-committer and he prefers to let a src-committer do it. > I offered to commit it, but so far either the man-page was missing > (what's the status of this?) or a bug showed up. Daichi and ozawa do not have enough time to write the manual page. I talked with daichi that I will write the manpage update to mount_unionfs.8. My english is not so good, so I think the patch to the manual page I am going to make should be intensively reviewed. I will send it to -fs and -current for review in a few days. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 10 18:38:20 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FFC616A479; Sat, 10 Jun 2006 18:38:20 +0000 (UTC) (envelope-from bruno@clisp.org) Received: from ftp.ilog.fr (ftp.ilog.fr [81.80.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C02AF4A1F8; Sat, 10 Jun 2006 16:24:20 +0000 (GMT) (envelope-from bruno@clisp.org) Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.1/8.13.1) with ESMTP id k5AGOEfD013943; Sat, 10 Jun 2006 18:24:19 +0200 Received: from marbore.ilog.biz (marbore.ilog.biz [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id k5AGO8AF022961; Sat, 10 Jun 2006 18:24:09 +0200 Received: from honolulu.ilog.fr ([172.16.15.121]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Jun 2006 18:24:19 +0200 Received: by honolulu.ilog.fr (Postfix, from userid 1001) id 900D5F1432; Sat, 10 Jun 2006 18:22:46 +0200 (CEST) From: Bruno Haible To: hackers@freebsd.org Date: Sat, 10 Jun 2006 18:22:46 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606101822.46437.bruno@clisp.org> X-OriginalArrivalTime: 10 Jun 2006 16:24:19.0641 (UTC) FILETIME=[534B4A90:01C68CAA] X-Mailman-Approved-At: Sun, 11 Jun 2006 00:06:11 +0000 Cc: Vasil Dimov Subject: valid VMA ranges and mincore() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 18:38:20 -0000 Hi memory management hackers, The mincore(2) system call is, on FreeBSD, not usable for some purposes for which it can be used on other platforms. Let me explain the purpose, the problem and two proposed solutions. The purpose =========== The task at hand is to enumerate the VMAs of the current process. In other words, determine which address ranges are mapped and which aren't. If the /proc filesystem is available, the /proc/curproc/map file can be opened and parsed; it contains the necessary information. But I'm being told that /proc is not mounted by default, and as an application developer I have no control over that. So, I must look for a solution that works also when /proc is not mounted. The purpose of this task can be a) To detect whether a SIGSEGV is actually a stack overflow, a write access to a read-only memory page, or simply a bug in the program. If the fault address is near to the stack segment, it's likely a stack overflow; if it's nearer to a data segment, it's more likely a bug. b) To choose optimal addresses for mmap with MAP_FIXED that obey some constraints about lengths and bit patterns. Ideally the OS would have a system call that allows to iterate over the VMAs of the current process (corresponding to the lines of /proc/curproc/map), or to retrieve the list of VMAs as a big array. Lacking such a system call, on platforms other than FreeBSD, for example NetBSD, I can use mincore() instead. The problem =========== On NetBSD, Linux, Solaris, mincore() applied to a range of addresses that is partially not mapped, returns -1 with errno set to ENOMEM. See NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/mincore.2?rev=1.19&content-type=text/plain Linux: http://linux.about.com/library/cmd/blcmdl2_mincore.htm Solaris: http://docs.sun.com/app/docs/doc/816-5167/6mbb2jaib?a=view This is consistent with mprotect(), which also fails with errno = ENOMEM if the address range is not fully mapped. FreeBSD doesn't work this way: it fills 0 values into the array passed as argument instead, a 0 for each unmapped page. This makes it impossible to distinguish a page which is valid address range but currently swapped out from a page which is unmapped. As a consequence, mincore() does not help for the aforementioned purpose. Proposals ========= Alternatively: Proposal 1: Change mincore() to behave like the one on NetBSD, Linux, Solaris. Proposal 2: Define a new constant MINCORE_MAPPED != 0, and change mincore() to set the per-page value to - MINCORE_MAPPED for a page that is mapped but swapped out, - 0 for a page which is unmapped address range. Proposal 1 would have the advantage to lead to the same code across platforms. Proposal 2 would have the advantage to be backward compatible. Can you do something about this? Bruno (an application programmer, not a FreeBSD kernel hacker) From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 05:51:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AC3E16A41B for ; Sun, 11 Jun 2006 05:51:38 +0000 (UTC) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from correo.novusordo.net (cdjj.org [216.194.85.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1462843D46 for ; Sun, 11 Jun 2006 05:51:37 +0000 (GMT) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from [192.168.2.100] (S010600c049bda6b5.ed.shawcable.net [68.149.198.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by correo.novusordo.net (Postfix) with ESMTP id BA7E6114C8 for ; Sat, 10 Jun 2006 23:51:36 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: Chris Jones Date: Sat, 10 Jun 2006 23:51:33 -0600 X-Mailer: Apple Mail (2.750) Subject: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 05:51:38 -0000 Hi, folks --- as some of you might know, FreeBSD has a Summer of Code project to bring resource limits to jails, and one part of that is to permit an administrator to put limits on a jail's CPU usage. That's where I come in: I'm the guy doing the project, and I've been spending the last two weeks coming up to speed on scheduling and the like. What I'd like from freebsd-hackers is the following: - are there any good references on scheduling that you know of which I should read? I've already got Design & Implementation of FreeBSD and the Petrou / Milford / Gibson and Waldspurger / Weihl papers on lottery scheduling. - what're your thoughts on making the existing scheduler jail- aware as opposed to writing a sort of 'meta-scheduler' that would schedule between jails, and then delegate to a scheduler per jail (which could be very similar, if not identical, to the existing scheduler)? I've got some very preliminary thoughts on this, but I'd like to hear what you've got to say, as I'm aware that this is rather ... complex. Thanks, Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 07:55:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE3C016A476 for ; Sun, 11 Jun 2006 07:55:13 +0000 (UTC) (envelope-from szyderca@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316DD43D4C for ; Sun, 11 Jun 2006 07:55:12 +0000 (GMT) (envelope-from szyderca@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so529095nzf for ; Sun, 11 Jun 2006 00:55:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Zbj+H2o/CVL1EW5Hr8hlBpdb0Ws4wZp3mvKyy8vBWO/HnR/spLFgmnYKWrh9eZYzP+L97Xv6SVKo1JclLgl27I1eF0381IESUw9tQIOAsO4HrNl6Eb7+nAKOrYZl9tq5qnqJcNwQ4yKcw467HpYSsLixaVioKnGwPQWs71KwvlM= Received: by 10.36.120.14 with SMTP id s14mr6819337nzc; Sun, 11 Jun 2006 00:55:12 -0700 (PDT) Received: by 10.36.96.6 with HTTP; Sun, 11 Jun 2006 00:55:12 -0700 (PDT) Message-ID: Date: Sun, 11 Jun 2006 09:55:12 +0200 From: "Marcin Cylke" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: proxy device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 07:55:13 -0000 Hi I'd like to write a proxy device for another usb device. I'd like it to be able to create a device only when an usb dev is attached, then destroy it when detached. What should I do? Where can I find information about this matter? Marcin From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 10:34:04 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFCA516A41A; Sun, 11 Jun 2006 10:34:04 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320B243D45; Sun, 11 Jun 2006 10:34:04 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp6-g19.free.fr (Postfix) with ESMTP id F14382258C; Sun, 11 Jun 2006 12:34:02 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id C945E9C3F9; Sun, 11 Jun 2006 10:34:17 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id AE25540A5; Sun, 11 Jun 2006 12:34:13 +0200 (CEST) Date: Sun, 11 Jun 2006 12:34:13 +0200 From: Jeremie Le Hen To: Darren Pilgrim Message-ID: <20060611103413.GJ1273@obiwan.tataz.chchile.org> References: <20060609094052.GH1273@obiwan.tataz.chchile.org> <20060609.074844.1324583587.imp@bsdimp.com> <4489E354.5070201@bitfreak.org> <20060609.153340.-432838362.imp@bsdimp.com> <4489FA7C.7080207@bitfreak.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <4489FA7C.7080207@bitfreak.org> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@FreeBSD.ORG, ru@FreeBSD.org, jeremie@le-hen.org Subject: Re: [fbsd] Re: How to disable a src.conf on command-line X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 10:34:05 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Darren, Warner, On Fri, Jun 09, 2006 at 03:47:24PM -0700, Darren Pilgrim wrote: > M. Warner Losh wrote: > >In message: <4489E354.5070201@bitfreak.org> > > Darren Pilgrim writes: > >: M. Warner Losh wrote: > >: > So if you make WITH_SSP off by default, then having WITH_SSP in the > >: > src.conf can't be overridden. If you have it on by default, having > >: > WITHOUT_SSP in the src.conf file can't be overriden. this appears to > >: > be an unintended flaw with the with/without stuff. I'm not sure the > >: > right way to compensate. > >: > >: I can't speak for the "right" way, but if you specify the variable in > >: src.conf/make.conf with ?= instead of =, you can override it on the > >: command-line: > >: > >: # grep KERNCONF /etc/make.conf > >: KERNCONF?=TTPWEB > >: # make -V KERNCONF > >: TTPWEB > >: # env KERNCONF=SOMETHING_ELSE make -V KERNCONF > >: SOMETHING_ELSE > > > >?= doesn't mesh well with WITH/WITHOUT because then it will always be > >defined, thus defeating its purpose. > > Use .ifndef to define WITH/WITHOUT iff its counterpart is undef: > > .ifndef WITHOUT_FOO > WITH_FOO=def > .endif Yes, this is indeed the way to go but actually I would prefer to this this wrapped in share/mk/bsd.own.mk, so that src.conf(5) would only handle variable assignments (in a rc.conf(5) fashion) without using make(1) magic. This would be pretty less puzzling for users. IMHO, the attached patch makes things better in case both WITH_FOO and WITHOUT_FOO are defined. Variables defined on command-line are read-only, therefore I take advantage of this to give the priority to the knob that has been defined on command-line. % jarjarbinks# head -n 1 /etc/src.conf % WITH_SSP=YES % % jarjarbinks# make echo.o % cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow-Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -fstack-protector -c /usr/src/bin/echo/echo.c % ^^^^^^^^^^^^^^^^^ % jarjarbinks# make clean % rm -f echo echo.o echo.1.gz echo.1.cat.gz % % jarjarbinks# make WITHOUT_SSP=yes echo.o % cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow-Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/bin/echo/echo.c % ^^^^^^^^^^^^^^^^^ % jarjarbinks# make clean % rm -f echo echo.o echo.1.gz echo.1.cat.gz % % jarjarbinks# echo "WITHOUT_SSP=YES" >> /etc/src.conf % jarjarbinks# make echo.o % "/usr/share/mk/bsd.own.mk", line 394: WITH_SSP and WITHOUT_SSP can't both be set from the same place. % Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bsd.own.mk.patch" Index: bsd.own.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.own.mk,v retrieving revision 1.54 diff -u -r1.54 bsd.own.mk --- bsd.own.mk 28 Apr 2006 12:03:36 -0000 1.54 +++ bsd.own.mk 11 Jun 2006 10:25:43 -0000 @@ -352,7 +352,20 @@ USB \ WPA_SUPPLICANT_EAPOL .if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. +# Check the user didn't define both variables from the same place. +WITH_${var}:= bsd.own.mk +WITHOUT_${var}:= bsd.own.mk +.if (${WITH_${var}} == "bsd.own.mk" && ${WITHOUT_${var}} == "bsd.own.mk") || \ + (${WITH_${var}} != "bsd.own.mk" && ${WITHOUT_${var}} != "bsd.own.mk") +.error WITH_${var} and WITHOUT_${var} can't both be set from the same place. +.endif +.if ${WITH_${var}} != "bsd.own.mk" +# WITH_${var} is defined on comand-line +.undef WITHOUT_${var} +.else +# WITHOUT_${var} is defined on comand-line +.undef WITH_${var} +.endif .endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. @@ -372,7 +385,20 @@ HESIOD \ IDEA .if defined(WITH_${var}) && defined(WITHOUT_${var}) -.error WITH_${var} and WITHOUT_${var} can't both be set. +# Check the user didn't define both variables from the same place. +WITH_${var}:= bsd.own.mk +WITHOUT_${var}:= bsd.own.mk +.if (${WITH_${var}} == "bsd.own.mk" && ${WITHOUT_${var}} == "bsd.own.mk") || \ + (${WITH_${var}} != "bsd.own.mk" && ${WITHOUT_${var}} != "bsd.own.mk") +.error WITH_${var} and WITHOUT_${var} can't both be set from the same place. +.endif +.if ${WITH_${var}} != "bsd.own.mk" +# WITH_${var} is defined on comand-line +.undef WITHOUT_${var} +.else +# WITHOUT_${var} is defined on comand-line +.undef WITH_${var} +.endif .endif .if defined(MK_${var}) .error MK_${var} can't be set by a user. --Q68bSM7Ycu6FN28Q-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 12:50:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A8216A418 for ; Sun, 11 Jun 2006 12:50:36 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E597543D45 for ; Sun, 11 Jun 2006 12:50:35 +0000 (GMT) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id k5BCoVxt017823; Sun, 11 Jun 2006 14:50:31 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Sun, 11 Jun 2006 14:50:30 +0200 User-Agent: KMail/1.9.3 References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> In-Reply-To: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606111450.31041.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Chris Jones Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 12:50:36 -0000 Hi Chris, On Sunday 11 June 2006 07:51, Chris Jones wrote: > Hi, folks --- as some of you might know, FreeBSD has a Summer of Code > project to bring resource limits to jails, and one part of that is to > permit an administrator to put limits on a jail's CPU usage. That's > where I come in: I'm the guy doing the project, and I've been > spending the last two weeks coming up to speed on scheduling and the > like. > > What I'd like from freebsd-hackers is the following: > > - are there any good references on scheduling that you know of > which I should read? I've already got Design & Implementation of > FreeBSD and the Petrou / Milford / Gibson and Waldspurger / Weihl > papers on lottery scheduling. For my CS study I picked up "Operating System Concepts" by Silberschatz, Galvin and Gagne. It has a fairly detailed description of the inner workings of a scheduler and the various algorithms involved, but no actual implementation. > > - what're your thoughts on making the existing scheduler jail- > aware as opposed to writing a sort of 'meta-scheduler' that would > schedule between jails, and then delegate to a scheduler per jail > (which could be very similar, if not identical, to the existing > scheduler)? I've got some very preliminary thoughts on this, but I'd > like to hear what you've got to say, as I'm aware that this is > rather ... complex. I suppose by limiting the jail CPU usage you mean that jails contending over CPU each get their assigned share. But when the system is idle one jail can get all the CPU it wants. Suppose you could detect wether a certain jail used too much CPU, wouldn't it be possible to lower the priorities of all the processes running inside that jail? And when the jail is "behind" on it's CPU quota, raise their priorities back to normal. I guess you could implement such a thing by a hook in the scheduler which examines the current CPU usage of each jail, say each second, and takes appropriate action accordingly. Regards, Pieter From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 13:17:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28FB416A41B for ; Sun, 11 Jun 2006 13:17:58 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F3043D46 for ; Sun, 11 Jun 2006 13:17:57 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.72]) by hydra.bec.de (Postfix) with ESMTP id 2274735707 for ; Sun, 11 Jun 2006 15:17:54 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 856BE6CEC2; Sun, 11 Jun 2006 15:17:27 +0200 (CEST) Date: Sun, 11 Jun 2006 15:17:27 +0200 From: joerg@britannica.bec.de To: freebsd-hackers@freebsd.org Message-ID: <20060611131727.GA2904@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> User-Agent: Mutt/1.5.11 Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 13:17:58 -0000 On Sat, Jun 10, 2006 at 11:51:33PM -0600, Chris Jones wrote: > > - what're your thoughts on making the existing scheduler jail- > aware as opposed to writing a sort of 'meta-scheduler' that would > schedule between jails, and then delegate to a scheduler per jail > (which could be very similar, if not identical, to the existing > scheduler)? I've got some very preliminary thoughts on this, but I'd > like to hear what you've got to say, as I'm aware that this is > rather ... complex. Take a look at Luigis weighted fair CPU scheduler back from the 4.x days. The link should still be somehwere on his page. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 13:43:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24ECC16A41B for ; Sun, 11 Jun 2006 13:43:14 +0000 (UTC) (envelope-from root@hnaz.ath.cx) Received: from 4profs.de (4profs.de [62.216.169.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B028743D45 for ; Sun, 11 Jun 2006 13:43:13 +0000 (GMT) (envelope-from root@hnaz.ath.cx) Received: from localhost (localhost [127.0.0.1]) by 4profs.de (Postfix) with ESMTP id 309DC8BC42 for ; Sun, 11 Jun 2006 15:43:08 +0200 (CEST) Received: from 4profs.de ([127.0.0.1]) by localhost (exilia [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 19893-08 for ; Sun, 11 Jun 2006 15:43:07 +0200 (CEST) Received: from localhost (ppp406.jetzweb.de [217.65.21.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by 4profs.de (Postfix) with ESMTP id AC94F8BC41 for ; Sun, 11 Jun 2006 15:43:06 +0200 (CEST) Date: Sun, 11 Jun 2006 15:44:19 +0200 From: Johannes Weiner To: freebsd-hackers@freebsd.org Message-ID: <20060611134419.GA71676@leiferikson.flosken.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeLSD) X-Virus-Scanned: by amavisd-new at 4profs.de X-Mailman-Approved-At: Sun, 11 Jun 2006 14:12:42 +0000 Subject: Kernelinternal function return value caching? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 13:43:14 -0000 Hi folks, when I found out, that playing sound with xmms does not always work out 100%, I started experimenting with the sound driver. What I got first was, that when a sound channel is opened/initialized, the optimal playback values for speed, format and blocksize of the channel are guessed by iterating combinations until the best is found (at least that is what I think it does). When this is done, the playback is started. Not all playback parameters are increased simultaneously, though. The blocksize incrementation doesn't work out. Although the function for setting it to a higher value is called, it just doesn't get executed. I checked that with a simple printf() within the concerned function. I read how objects are looked up and saw that KOBJOPLOOKUP() tries to cache functions before looking them up again. This should not lead to the caching of function return values instead of really executing them, should it? I wrote a small frontend to avoid KOBJOPLOOKUP() and even after I got a straight pointer on the function, and make a call on this, it still doesn't get executed. How could that be? Is it possible that the return values are cached when a function is inlined or marked static? I don't get it... Hannes PS: code reference: * hardware-specific setblocksize() that doesn't get executed when called: static int fm801ch_setblocksize() in sys/dev/sound/pci/fm801.c * generic setblocksize() that should execute the specific one: int chn_setblocksize() in sys/dev/sound/pcm/channel.c calls specific setblocksize() with the macro CHANNEL_SETBLOCKSIZE() From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 15:56:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 901CB16A484 for ; Sun, 11 Jun 2006 15:56:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266B743D46 for ; Sun, 11 Jun 2006 15:56:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k5BFtQCL091022; Sun, 11 Jun 2006 09:55:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jun 2006 09:55:37 -0600 (MDT) Message-Id: <20060611.095537.1226243136.imp@bsdimp.com> To: szyderca@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: proxy device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 15:56:18 -0000 In message: "Marcin Cylke" writes: : Hi : I'd like to write a proxy device for another usb device. I'd like it to : be able to create a device only when an usb dev is attached, then : destroy it when detached. : : What should I do? Where can I find information about this matter? Start by looking in uhub.c. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 17:36:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF4F716A41B for ; Sun, 11 Jun 2006 17:36:47 +0000 (UTC) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from correo.novusordo.net (cdjj.org [216.194.85.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 989A243D46 for ; Sun, 11 Jun 2006 17:36:47 +0000 (GMT) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from [192.168.2.100] (S010600c049bda6b5.ed.shawcable.net [68.149.198.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by correo.novusordo.net (Postfix) with ESMTP id 067F511523 for ; Sun, 11 Jun 2006 11:36:47 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <473BD08B-7088-48E3-99AE-26DD572E95E6@novusordo.net> References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> <200606111450.31041.pieter@degoeje.nl> <473BD08B-7088-48E3-99AE-26DD572E95E6@novusordo.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chris Jones Date: Sun, 11 Jun 2006 11:36:45 -0600 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.750) Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 17:36:48 -0000 On 11-Jun-06, at 6:50 AM, Pieter de Goeje wrote: > For my CS study I picked up "Operating System Concepts" by > Silberschatz, > Galvin and Gagne. It has a fairly detailed description of the inner > workings > of a scheduler and the various algorithms involved, but no actual > implementation. Yep, we used the Dinosaur Book and I've still got it. I may even have Tanenbaum's OS book kicking around somewhere. >> - what're your thoughts on making the existing scheduler jail- >> aware as opposed to writing a sort of 'meta-scheduler' that would >> schedule between jails, and then delegate to a scheduler per jail >> (which could be very similar, if not identical, to the existing >> scheduler)? I've got some very preliminary thoughts on this, but I'd >> like to hear what you've got to say, as I'm aware that this is >> rather ... complex. > > I suppose by limiting the jail CPU usage you mean that jails > contending over > CPU each get their assigned share. But when the system is idle one > jail can > get all the CPU it wants. Exactly. Think of it as being like nice-on-steroids, but for a whole jail instead of a process. > Suppose you could detect wether a certain jail used too much CPU, > wouldn't it > be possible to lower the priorities of all the processes running > inside that > jail? And when the jail is "behind" on it's CPU quota, raise their > priorities > back to normal. > > I guess you could implement such a thing by a hook in the scheduler > which > examines the current CPU usage of each jail, say each second, and > takes > appropriate action accordingly. That's one way to do it using one big scheduler; on the other hand, the hierarchical scheduler approach could be as trivial as round- robin timeslicing on the "metascheduler" between the individual jails' schedulers (obviously, you'd really want at least to be able to do proportional timeslicing and probably to set the schedulers up to hand their timeslice back if they'd otherwise run the idle process). Joerg: thanks for the pointer to Luigi's scheduler; I'll check it out. Cheers, Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 18:46:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34BCC16A418 for ; Sun, 11 Jun 2006 18:46:29 +0000 (UTC) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (ns.sevcity.net [193.47.166.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B6343D6B for ; Sun, 11 Jun 2006 18:46:22 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 3CE6D17000A; Sun, 11 Jun 2006 21:48:01 +0300 (EEST) Received: from berloga.shadowland (umka.sevcity.net [193.47.166.138]) by mail.sevcity.net (Postfix) with ESMTP id A52BF170004; Sun, 11 Jun 2006 21:46:46 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.11.20060308/8.12.11) with ESMTP id k5BIj01W023491; Sun, 11 Jun 2006 21:45:00 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11.20060308/8.12.11/Submit) id k5BIiuup023487; Sun, 11 Jun 2006 21:44:56 +0300 From: Alex Lyashkov To: Chris Jones In-Reply-To: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: Positive Software Message-Id: <1150051496.3315.25.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Date: Sun, 11 Jun 2006 21:44:56 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-hackers@freebsd.org Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 18:46:29 -0000 =F7 =F7=D3=CB, 11.06.2006, =D7 08:51, Chris Jones =D0=C9=DB=C5=D4: > Hi, folks --- as some of you might know, FreeBSD has a Summer of Code =20 > project to bring resource limits to jails, and one part of that is to =20 > permit an administrator to put limits on a jail's CPU usage. That's =20 > where I come in: I'm the guy doing the project, and I've been =20 > spending the last two weeks coming up to speed on scheduling and the =20 > like. >=20 > What I'd like from freebsd-hackers is the following: >=20 > - are there any good references on scheduling that you know of =20 > which I should read? I've already got Design & Implementation of =20 > FreeBSD and the Petrou / Milford / Gibson and Waldspurger / Weihl =20 > papers on lottery scheduling. >=20 > - what're your thoughts on making the existing scheduler jail-=20 > aware as opposed to writing a sort of 'meta-scheduler' that would =20 > schedule between jails, and then delegate to a scheduler per jail =20 > (which could be very similar, if not identical, to the existing =20 > scheduler)? I've got some very preliminary thoughts on this, but I'd =20 > like to hear what you've got to say, as I'm aware that this is =20 > rather ... complex. >=20 > Thanks, You are look in FreeBSD 4.x vimage project or linux projects (OpenVZ, FreeVPS, Linux-VServer)?=20 other reference can be 'fair share scheduler' where groups equal jail. --=20 FreeVPS Developers Team http://www.freevps.com Positive Software http://www.psoft.net From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 17:35:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A73916A41A for ; Sun, 11 Jun 2006 17:35:41 +0000 (UTC) (envelope-from cdjones@novusordo.net) Received: from correo.novusordo.net (cdjj.org [216.194.85.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B513343D58 for ; Sun, 11 Jun 2006 17:35:40 +0000 (GMT) (envelope-from cdjones@novusordo.net) Received: from [192.168.2.100] (S010600c049bda6b5.ed.shawcable.net [68.149.198.157]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by correo.novusordo.net (Postfix) with ESMTP id 9C8ED114F5; Sun, 11 Jun 2006 11:35:39 -0600 (MDT) In-Reply-To: <200606111450.31041.pieter@degoeje.nl> References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> <200606111450.31041.pieter@degoeje.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <473BD08B-7088-48E3-99AE-26DD572E95E6@novusordo.net> Content-Transfer-Encoding: 7bit From: Chris Jones Date: Sun, 11 Jun 2006 11:35:37 -0600 To: Pieter de Goeje X-Mailer: Apple Mail (2.750) X-Mailman-Approved-At: Sun, 11 Jun 2006 18:54:35 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 17:35:41 -0000 On 11-Jun-06, at 6:50 AM, Pieter de Goeje wrote: > For my CS study I picked up "Operating System Concepts" by > Silberschatz, > Galvin and Gagne. It has a fairly detailed description of the inner > workings > of a scheduler and the various algorithms involved, but no actual > implementation. Yep, we used the Dinosaur Book and I've still got it. I may even have Tanenbaum's OS book kicking around somewhere. >> - what're your thoughts on making the existing scheduler jail- >> aware as opposed to writing a sort of 'meta-scheduler' that would >> schedule between jails, and then delegate to a scheduler per jail >> (which could be very similar, if not identical, to the existing >> scheduler)? I've got some very preliminary thoughts on this, but I'd >> like to hear what you've got to say, as I'm aware that this is >> rather ... complex. > > I suppose by limiting the jail CPU usage you mean that jails > contending over > CPU each get their assigned share. But when the system is idle one > jail can > get all the CPU it wants. Exactly. Think of it as being like nice-on-steroids, but for a whole jail instead of a process. > Suppose you could detect wether a certain jail used too much CPU, > wouldn't it > be possible to lower the priorities of all the processes running > inside that > jail? And when the jail is "behind" on it's CPU quota, raise their > priorities > back to normal. > > I guess you could implement such a thing by a hook in the scheduler > which > examines the current CPU usage of each jail, say each second, and > takes > appropriate action accordingly. That's one way to do it using one big scheduler; on the other hand, the hierarchical scheduler approach could be as trivial as round- robin timeslicing on the "metascheduler" between the individual jails' schedulers (obviously, you'd really want at least to be able to do proportional timeslicing and probably to set the schedulers up to hand their timeslice back if they'd otherwise run the idle process). Joerg: thanks for the pointer to Luigi's scheduler; I'll check it out. Cheers, Chris From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 11 18:59:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF34716A41A; Sun, 11 Jun 2006 18:59:00 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63FB343D46; Sun, 11 Jun 2006 18:59:00 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.3] (east62-p219.eaccess.hi-ho.ne.jp [219.105.24.220]) by natial.ongs.co.jp (Postfix) with ESMTP id 4D9C9244C3A; Mon, 12 Jun 2006 03:58:59 +0900 (JST) Message-ID: <448C67EF.4070906@freebsd.org> Date: Mon, 12 Jun 2006 03:58:55 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5.0.4 (X11/20060605) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> <4433CA53.5050000@freebsd.org> <444E13BA.8050902@freebsd.org> <4475C119.1020305@freebsd.org> <447C919B.20303@freebsd.org> <86bqteikj4.fsf@xps.des.no> <20060531133814.acykloyqhkcccg80@netchild.homeip.net> <86u076h0ue.fsf@xps.des.no> In-Reply-To: <86u076h0ue.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander Leidinger , Daichi GOTO , freebsd-hackers@freebsd.org Subject: Re: [ANN] unionfs patchset-13 release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 18:59:00 -0000 Dag-Erling Smørgrav wrote: >> If everyone is happy with the current patchset (if the man-page is >> still missing, we may agree that it can be delivered at a later >> time), I can try to get time to do it at the weekend (but feel free >> to beat me in committing it). > > I have an even better suggestion: sponsor him for a commit bit. He > obviously has the required skills. > > DES It is a good idea for providing the maintenance of unionfs. Someone, please take office as my src mentor :) -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 00:15:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12DCC16A473 for ; Mon, 12 Jun 2006 00:15:46 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C9E243D7B for ; Mon, 12 Jun 2006 00:15:33 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail10.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k5C0FOkm002397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 12 Jun 2006 10:15:26 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k5C0FOmh033659; Mon, 12 Jun 2006 10:15:24 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k5C0FOFM033658; Mon, 12 Jun 2006 10:15:24 +1000 (EST) (envelope-from peter) Date: Mon, 12 Jun 2006 10:15:24 +1000 From: Peter Jeremy To: Pieter de Goeje Message-ID: <20060612001524.GD739@turion.vk2pj.dyndns.org> References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> <200606111450.31041.pieter@degoeje.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606111450.31041.pieter@degoeje.nl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, Chris Jones Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 00:15:46 -0000 On Sun, 2006-Jun-11 14:50:30 +0200, Pieter de Goeje wrote: >I suppose by limiting the jail CPU usage you mean that jails contending over >CPU each get their assigned share. But when the system is idle one jail can >get all the CPU it wants. IBM MVS had an interesting alternative approach, which I believe was part of the scheduler: You could place an upper limit on the CPU allocated to a process. From a user perspective, an application would respond in (say) 2 seconds whether the system was completely idle or at normal load. This stopped users complaining that the system was slow as the system got loaded. In the case of jailed systems, it could also prevent (or minimize) traffic analysis of the system by a jailed process. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 01:38:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4BB516A41A for ; Mon, 12 Jun 2006 01:38:53 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6722443D45 for ; Mon, 12 Jun 2006 01:38:53 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so1127604nzn for ; Sun, 11 Jun 2006 18:38:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rwZVOfn3nxKeqn+Bbf/LrUWFqXEALGTn+4EmQiYNxXQBfbAGb3uu2L7HfnXGhKQ/a7bGEIBFY+sMuMcYRkXC4K30Z6EjZ0W9o6FYkOFMGCsbp5Mg4SvIzear6x19cFza29abV0L+e8t/LA8SKPNSLTGWnd4FxFankOzyFUyxshQ= Received: by 10.64.150.16 with SMTP id x16mr1773252qbd; Sun, 11 Jun 2006 18:38:52 -0700 (PDT) Received: by 10.65.231.11 with HTTP; Sun, 11 Jun 2006 18:38:52 -0700 (PDT) Message-ID: Date: Sun, 11 Jun 2006 18:38:52 -0700 From: "Kip Macy" To: "Peter Jeremy" In-Reply-To: <20060612001524.GD739@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> <200606111450.31041.pieter@degoeje.nl> <20060612001524.GD739@turion.vk2pj.dyndns.org> Cc: Pieter de Goeje , Chris Jones , freebsd-hackers@freebsd.org Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 01:38:54 -0000 I personally prefer the notion of layering the normal scheduler on top of a simple fair-share scheduler. This would not add any overhead for the non-jailed case. Complicating the process scheduler poses maintenance, scalability, and general performance problems. -Kip On 6/11/06, Peter Jeremy wrote: > On Sun, 2006-Jun-11 14:50:30 +0200, Pieter de Goeje wrote: > >I suppose by limiting the jail CPU usage you mean that jails contending over > >CPU each get their assigned share. But when the system is idle one jail can > >get all the CPU it wants. > > IBM MVS had an interesting alternative approach, which I believe was > part of the scheduler: You could place an upper limit on the CPU > allocated to a process. From a user perspective, an application would > respond in (say) 2 seconds whether the system was completely idle or > at normal load. This stopped users complaining that the system was > slow as the system got loaded. In the case of jailed systems, it > could also prevent (or minimize) traffic analysis of the system by a > jailed process. > > -- > Peter Jeremy > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 12:49:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C0A16A477 for ; Mon, 12 Jun 2006 12:49:52 +0000 (UTC) (envelope-from betogigi@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1648E43E17 for ; Mon, 12 Jun 2006 12:48:38 +0000 (GMT) (envelope-from betogigi@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so1141685nzp for ; Mon, 12 Jun 2006 05:48:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=AUJGIgWct0VBWCj81/cPCrpGpNgdYvJrFffCufly/ZFxxQUeoQ2lDC48zRNLmP3L8pWcwaBLRpRx1TPK6MHbcF31EfQ+GEGarad8CHi8ge8XFofVqpgNnKTxQPP1yyDwjtJDgnN+pWbkP96HoZQnjSTUMo/vWJ6TSi8OxuH6xNE= Received: by 10.36.118.11 with SMTP id q11mr8641703nzc; Mon, 12 Jun 2006 05:48:27 -0700 (PDT) Received: by 10.36.135.19 with HTTP; Mon, 12 Jun 2006 05:48:26 -0700 (PDT) Message-ID: Date: Mon, 12 Jun 2006 09:48:26 -0300 From: "Roberto Lima" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1853_19119760.1150116506221" Subject: Re: Jail-Aware Scheduling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 12:49:52 -0000 ------=_Part_1853_19119760.1150116506221 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, i have a patch from freebsd 4.x not developed for me, but this is very good for appreciate and or upgrade the patch for versions 5.x 6.x or current. This use sysctl oids to limit memory ram and cpu use. Regards and sorry for my bad english, Roberto Lima. ------=_Part_1853_19119760.1150116506221 Content-Type: application/octet-stream; name=jail_seperation.v7.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_eoctn9x4 Content-Disposition: attachment; filename="jail_seperation.v7.patch" ZGlmZiAtdXIgc3JjLnZpcmdpbi9zeXMva2Vybi9rZXJuX2ZvcmsuYyBzcmMuZGlydHkvc3lzL2tl cm4va2Vybl9mb3JrLmMKLS0tIHNyYy52aXJnaW4vc3lzL2tlcm4va2Vybl9mb3JrLmMJTW9uIERl YyAgOSAxOTozMzo0NCAyMDAyCisrKyBzcmMuZGlydHkvc3lzL2tlcm4va2Vybl9mb3JrLmMJVGh1 IEZlYiAyNyAxNzozODozMiAyMDAzCkBAIC0xMjAsNiArMTIwLDExIEBACiAJaW50IGVycm9yOwog CXN0cnVjdCBwcm9jICpwMjsKIAorCWVycm9yID0gamFpbF9jaGVja19yZXNvdXJjZXModGQpOwor CWlmIChlcnJvcikgeworCQlyZXR1cm4gZXJyb3I7CisJfQorCQkKIAltdHhfbG9jaygmR2lhbnQp OwogCWVycm9yID0gZm9yazEodGQsIFJGRkRHIHwgUkZQUk9DLCAwLCAmcDIpOwogCWlmIChlcnJv ciA9PSAwKSB7CkBAIC0xNDIsNiArMTQ3LDExIEBACiAJaW50IGVycm9yOwogCXN0cnVjdCBwcm9j ICpwMjsKIAorCWVycm9yID0gamFpbF9jaGVja19yZXNvdXJjZXModGQpOworCWlmIChlcnJvcikg eworCQlyZXR1cm4gZXJyb3I7CisJfQorCiAJbXR4X2xvY2soJkdpYW50KTsKIAllcnJvciA9IGZv cmsxKHRkLCBSRkZERyB8IFJGUFJPQyB8IFJGUFBXQUlUIHwgUkZNRU0sIDAsICZwMik7CiAJaWYg KGVycm9yID09IDApIHsKQEAgLTE2Miw2ICsxNzIsMTEgQEAKIHsKIAlpbnQgZXJyb3I7CiAJc3Ry dWN0IHByb2MgKnAyOworCisJZXJyb3IgPSBqYWlsX2NoZWNrX3Jlc291cmNlcyh0ZCk7CisJaWYg KGVycm9yKSB7CisJCXJldHVybiBlcnJvcjsKKwl9CiAKIAkvKiBEb24ndCBhbGxvdyBrZXJuZWwg b25seSBmbGFncy4gKi8KIAlpZiAoKHVhcC0+ZmxhZ3MgJiBSRktFUk5FTE9OTFkpICE9IDApCmRp ZmYgLXVyIHNyYy52aXJnaW4vc3lzL2tlcm4va2Vybl9qYWlsLmMgc3JjLmRpcnR5L3N5cy9rZXJu L2tlcm5famFpbC5jCi0tLSBzcmMudmlyZ2luL3N5cy9rZXJuL2tlcm5famFpbC5jCVRodSBEZWMg MTkgMDI6NDA6MTAgMjAwMgorKysgc3JjLmRpcnR5L3N5cy9rZXJuL2tlcm5famFpbC5jCVNhdCBN YXIgMjIgMTM6MjU6MzkgMjAwMwpAQCAtMTgsNiArMTgsMTEgQEAKICNpbmNsdWRlIDxzeXMvc3lz cHJvdG8uaD4KICNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CiAjaW5jbHVkZSA8c3lzL3Byb2MuaD4K KyNpbmNsdWRlIDx2bS92bS5oPgorI2luY2x1ZGUgPHZtL3ZtX2V4dGVybi5oPgorI2luY2x1ZGUg PHZtL3ZtX3BhZ2UuaD4KKyNpbmNsdWRlIDx2bS92bV9vYmplY3QuaD4KKyNpbmNsdWRlIDx2bS92 bV9tYXAuaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrLmg+CiAj aW5jbHVkZSA8c3lzL211dGV4Lmg+CkBAIC0yNSw2ICszMCwxMCBAQAogI2luY2x1ZGUgPHN5cy9z eXNjdGwuaD4KICNpbmNsdWRlIDxuZXQvaWYuaD4KICNpbmNsdWRlIDxuZXRpbmV0L2luLmg+Cisj aW5jbHVkZSA8c3lzL3NidWYuaD4KKyNpbmNsdWRlIDxzeXMvc2NoZWQuaD4KKyNpbmNsdWRlIDxz eXMvdm5vZGUuaD4KKyNpbmNsdWRlIDxzeXMvbW91bnQuaD4KIAogTUFMTE9DX0RFRklORShNX1BS SVNPTiwgInByaXNvbiIsICJQcmlzb24gc3RydWN0dXJlcyIpOwogCkBAIC00OSw2ICs1OCwxMTgg QEAKICAgICAmamFpbF9zeXN2aXBjX2FsbG93ZWQsIDAsCiAgICAgIlByb2Nlc3NlcyBpbiBqYWls IGNhbiB1c2UgU3lzdGVtIFYgSVBDIHByaW1pdGl2ZXMiKTsKIAoraW50IGphaWxfcXVvdGFzX2Fs bG93ZWQgPSAwOworU1lTQ1RMX0lOVChfc2VjdXJpdHlfamFpbCwgT0lEX0FVVE8sIHF1b3Rhc19h bGxvd2VkLCBDVExGTEFHX1JXLCAmamFpbF9xdW90YXNfYWxsb3dlZCwgMCwKKyAgICAiUHJvY2Vz c2VzIGhhdmUgYWNjZXNzIHRvIHRoZSBxdW90YSBzeXN0ZW0uIik7CisKK2ludAlqYWlsX2hpZGVf cHJvY2Vzc2VzID0gMDsKK1NZU0NUTF9JTlQoX3NlY3VyaXR5X2phaWwsIE9JRF9BVVRPLCBoaWRl X3Byb2Nlc3NlcywgQ1RMRkxBR19SVywKKyAgICAmamFpbF9oaWRlX3Byb2Nlc3NlcywgMCwKKyAg ICAiUHJvY2Vzc2VzIGluIGphaWwgYXJlIG5vdCB2aXNpYmxlIG91dHNpZGUgdGhlIGphaWwgKGV4 Y2VwdCB0byByb290KSIpOworCitpbnQJamFpbF9oaWRlX2ZpbGVzID0gMDsKK1NZU0NUTF9JTlQo X3NlY3VyaXR5X2phaWwsIE9JRF9BVVRPLCBoaWRlX2ZpbGVzLCBDVExGTEFHX1JXLAorICAgICZq YWlsX2hpZGVfZmlsZXMsIDAsCisgICAgIkZpbGVzIGluIGphaWwgYXJlIG5vdCB2aXNpYmxlIG91 dHNpZGUgdGhlIGphaWwgKGV4Y2VwdCB0byByb290KSIpOworCitzdHJ1Y3QgamFpbHMgZmlyc3Rq YWlsID0gTElTVF9IRUFEX0lOSVRJQUxJWkVSKGphaWxzKTsKKworU1lTQ1RMX05PREUoLCBPSURf QVVUTywgamFpbCwgQ1RMRkxBR19SRCwgMCwgImphaWwgcGFyYW1ldGVycyIpOworU1lTQ1RMX05P REUoX2phaWwsIE9JRF9BVVRPLCBqYWlscywgQ1RMRkxBR19SRCwgMCwgInBlci1qYWlsIHNldHRp bmdzIik7CisKK2ludCBqYWlsX2lwdjRhZGRyX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsK KworaW50CitqYWlsX2lwdjRhZGRyX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWlu dCBlcnJvciwgaSA9IDAsIGogPSAwLCBrLCBpcG1vZGU7CisJY2hhciBidWZbMTAyNF0sICp0bXBw dHIsICp0bXBidWYsICp0bXBidWYyOworCXN0cnVjdCBwcmlzb24gKnByID0gKHN0cnVjdCBwcmlz b24qKShvaWRwLT5vaWRfYXJnMSk7CisJdV9pbnQzMl90ICppcHNfbmV3OworCWluX2FkZHJfdCBh ZGRyOworCXN0cnVjdCBzYnVmICpzYjsKKwlzdHJ1Y3QgaW5fYWRkciBpbmFkZHI7CisJdW5zaWdu ZWQgbG9uZyBpcGVsZW1lbnRbNF07CisKKwkvKiBTcGl0IG91dCBhbGwgSVAgYWRkcmVzc2VzIGlu IGphaWwuICovCisJc2IgPSBzYnVmX25ldyhOVUxMLCBOVUxMLCAxMDI0LCBTQlVGX0FVVE9FWFRF TkQpOworCWZvciAoaSA9IDA7IGkgPCBwci0+cHJfbmlwczsgaSsrKSB7CisJCWluYWRkci5zX2Fk ZHIgPSBudG9obChwci0+cHJfaXBzW2ldKTsKKwkJc2J1Zl9wcmludGYoc2IsICIlcyIsIGluZXRf bnRvYShpbmFkZHIpKTsKKwkJaWYgKGkgIT0gcHItPnByX25pcHMgLSAxKSB7CisJCQlzYnVmX3By aW50ZihzYiwgIiwiKTsKKwkJfQorCX0KKwlzYnVmX2ZpbmlzaChzYik7CisJc3RybGNweShidWYs IHNidWZfZGF0YShzYiksIHNpemVvZihidWYpKTsKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfc3Ry aW5nKG9pZHAsICZidWZbMF0sIHNpemVvZihidWYpLCByZXEpOworCXNidWZfZGVsZXRlKHNiKTsK KworCWlmIChlcnJvciA9PSAwICYmIHJlcS0+bmV3cHRyICE9IE5VTEwpIHsKKwkJaWYgKGJ1Zlsw XSA9PSAnKycgfHwgKGJ1ZlswXSA+PSA0OCAmJiBidWZbMF0gPD0gNTcpKSB7CisJCQlpcG1vZGUg PSAwOworCQkJTUFMTE9DKGlwc19uZXcsIHVfaW50MzJfdCAqLCBzaXplb2YodV9pbnQzMl90KSAq IChwci0+cHJfbmlwcyArIDEpLCBNX1BSSVNPTiwgTV9XQUlUT0spOworCQkJbWVtY3B5KGlwc19u ZXcsIHByLT5wcl9pcHMsIHNpemVvZih1X2ludDMyX3QpICogKHByLT5wcl9uaXBzKSk7CisJCX0g ZWxzZSBpZiAoYnVmWzBdID09ICctJykgeworCQkJaXBtb2RlID0gMTsKKwkJCWlmIChwci0+cHJf bmlwcyA9PSAxKSB7CisJCQkJcmV0dXJuIEVJTlZBTDsKKwkJCX0KKwkJCU1BTExPQyhpcHNfbmV3 LCB1X2ludDMyX3QgKiwgc2l6ZW9mKHVfaW50MzJfdCkgKiAocHItPnByX25pcHMgLSAxKSwgTV9Q UklTT04sIE1fV0FJVE9LKTsKKwkJfSBlbHNlIHsKKwkJCXJldHVybiBFSU5WQUw7CisJCX0KKwor CQkvKiBTaW11bGF0ZSBpbmV0X2F0b24gKnNpZ2gqLiAqLworCQl0bXBwdHIgPSAoY2hhciopJmFk ZHI7CisJCWlmIChidWZbMF0gPT0gJysnIHx8IGJ1ZlswXSA9PSAnLScpIHsKKwkJCXRtcGJ1ZjIg PSBidWYgKyAxOworCQl9IGVsc2UgeworCQkJdG1wYnVmMiA9IGJ1ZjsKKwkJfQorCQl0bXBidWYg PSB0bXBidWYyOworCQl3aGlsZSgqdG1wYnVmKSB7CisJCQkvKiBGaXJzdCBwYXNzOiByZXBsYWNl ICcuJyB3aXRoICdcMCcuICovCisJCQlpZiAoKnRtcGJ1ZiA9PSAnLicpIHsKKwkJCQlpKys7CisJ CQkJKnRtcGJ1ZiA9ICdcMCc7CisJCQl9CisJCQl0bXBidWYrKzsKKwkJfQorCQl0bXBidWYgPSB0 bXBidWYyOworCQlmb3IoaiA9IDA7IGogPD0gaTsgaisrKSB7CisJCQkvKiBTZWNvbmQgcGFzczog ZmlsbCBhZGRyLiAqLworCQkJaXBlbGVtZW50W2pdID0gc3RydG91bCh0bXBidWYsIE5VTEwsIDEw KTsKKwkJCWsgPSBzdHJsZW4odG1wYnVmKTsKKwkJCXRtcGJ1ZiArPSBrICsgMTsKKwkJfQorCQlh ZGRyID0gaXBlbGVtZW50WzNdOworCQlhZGRyIHw9IChpcGVsZW1lbnRbMF0gPDwgMjQpIHwgKGlw ZWxlbWVudFsxXSA8PCAxNikgfCAoaXBlbGVtZW50WzJdIDw8IDgpOworCisJCS8qIFBlcmZvcm0g YWRkL2RlbGV0ZSAqLworCQltdHhfbG9jaygmcHItPnByX210eCk7CisJCWlmIChpcG1vZGUgPT0g MCkgeworCQkJaXBzX25ld1twci0+cHJfbmlwc10gPSBhZGRyOworCQkJcHItPnByX25pcHMrKzsK KwkJfSBlbHNlIHsKKwkJCWkgPSAwOworCQkJZm9yIChqID0gMDsgaiA8IHByLT5wcl9uaXBzOyBq KyspIHsKKwkJCQlpZiAoYWRkciAhPSBwci0+cHJfaXBzW2pdKSB7CisJCQkJCWlwc19uZXdbaV0g PSBwci0+cHJfaXBzW2pdOworCQkJCQlpKys7CisJCQkJfQorCQkJfQorCQkJcHItPnByX25pcHMt LTsKKwkJfQorCQlGUkVFKHByLT5wcl9pcHMsIE1fUFJJU09OKTsKKwkJcHItPnByX2lwcyA9IGlw c19uZXc7CisJCW10eF91bmxvY2soJnByLT5wcl9tdHgpOworCisJfQorCisJcmV0dXJuIGVycm9y OworfQorCiAvKgogICogTVBTQUZFCiAgKi8KQEAgLTYwLDE2ICsxODEsMTggQEAKIAl9ICovICp1 YXA7CiB7CiAJc3RydWN0IHByb2MgKnAgPSB0ZC0+dGRfcHJvYzsKLQlpbnQgZXJyb3I7CisJaW50 IGVycm9yLCBzaXplID0gMDsKIAlzdHJ1Y3QgcHJpc29uICpwcjsKIAlzdHJ1Y3QgamFpbCBqOwog CXN0cnVjdCBjaHJvb3RfYXJncyBjYTsKIAlzdHJ1Y3QgdWNyZWQgKm5ld2NyZWQgPSBOVUxMLCAq b2xkY3JlZDsKKwlzdHJ1Y3QgamFpbGVsZW1lbnQgKnRtcGVsZW1lbnQ7CisJY2hhciAqdG1wU3Ry aW5nOwogCiAJZXJyb3IgPSBjb3B5aW4odWFwLT5qYWlsLCAmaiwgc2l6ZW9mIGopOwogCWlmIChl cnJvcikKIAkJcmV0dXJuIChlcnJvcik7Ci0JaWYgKGoudmVyc2lvbiAhPSAwKQorCWlmIChqLnZl cnNpb24gIT0gMSkKIAkJcmV0dXJuIChFSU5WQUwpOwogCiAJTUFMTE9DKHByLCBzdHJ1Y3QgcHJp c29uICosIHNpemVvZiAqcHIgLCBNX1BSSVNPTiwgTV9XQUlUT0sgfCBNX1pFUk8pOwpAQCAtODUs NyArMjA4LDE2IEBACiAJaWYgKGVycm9yKQogCQlnb3RvIGJhaWw7CiAJbmV3Y3JlZCA9IGNyZ2V0 KCk7Ci0JcHItPnByX2lwID0gai5pcF9udW1iZXI7CisKKwlNQUxMT0MocHItPnByX2lwcywgdV9p bnQzMl90ICosIHNpemVvZih1X2ludDMyX3QpICogai5uaXBzLCBNX1BSSVNPTiwKKwkgICAgTV9X QUlUT0spOworCWVycm9yID0gY29weWluKGouaXBzLCBwci0+cHJfaXBzLCBzaXplb2YodV9pbnQz Ml90KSAqIGoubmlwcyk7CisJaWYgKGVycm9yKSB7CisJCUZSRUUocHItPnByX2lwcywgTV9QUklT T04pOworCQlnb3RvIGJhaWw7CisJfQorCXByLT5wcl9uaXBzID0gai5uaXBzOworCiAJUFJPQ19M T0NLKHApOwogCS8qIEltcGxpY2l0bHkgZmFpbCBpZiBhbHJlYWR5IGluIGphaWwuICAqLwogCWVy cm9yID0gc3VzZXJfY3JlZChwLT5wX3VjcmVkLCAwKTsKQEAgLTk2LDYgKzIyOCw0OCBAQAogCXAt PnBfdWNyZWQgPSBuZXdjcmVkOwogCXAtPnBfdWNyZWQtPmNyX3ByaXNvbiA9IHByOwogCXByLT5w cl9yZWYgPSAxOworCisJLyogQWRkIGphaWwgdG8gbGlzdC4gKi8KKwlNQUxMT0ModG1wZWxlbWVu dCwgc3RydWN0IGphaWxlbGVtZW50Kiwgc2l6ZW9mKHN0cnVjdCBqYWlsZWxlbWVudCksIE1fUFJJ U09OLCBNX1dBSVRPSyB8IE1fWkVSTyk7CisJdG1wZWxlbWVudC0+cHIgPSBwcjsKKwlNQUxMT0Mo dG1wZWxlbWVudC0+Y2hyb290X3BhdGgsIGNoYXIgKiwgc3RybGVuKGoucGF0aCkgKyAxLCBNX1BS SVNPTiwgTV9XQUlUT0spOworCWNvcHlpbnN0cihqLnBhdGgsIHRtcGVsZW1lbnQtPmNocm9vdF9w YXRoLCBzdHJsZW4oai5wYXRoKSArIDEsICZzaXplKTsKKwlMSVNUX0lOU0VSVF9IRUFEKCZmaXJz dGphaWwsIHRtcGVsZW1lbnQsIHBvaW50ZXJzKTsKKworCS8qIEFkZCBzeXNjdGxzLiAqLworCXN0 cmNweShwci0+cHJfaG9zdF9vaWQsIHByLT5wcl9ob3N0KTsKKwl0bXBTdHJpbmcgPSBwci0+cHJf aG9zdF9vaWQ7CisJd2hpbGUoKnRtcFN0cmluZykgeworCQlpZiAoKnRtcFN0cmluZyA9PSAnLicp IHsKKwkJCSp0bXBTdHJpbmcgPSAnXyc7CisJCX0KKwkJdG1wU3RyaW5nKys7CisJfQorCQorCXN5 c2N0bF9jdHhfaW5pdCgmcHItPmpkX3N5c2N0bHRyZWUpOworCXByLT5qZF9zeXNjdGx0cmVldG9w ID0gU1lTQ1RMX0FERF9OT0RFKCZwci0+amRfc3lzY3RsdHJlZSwKKwkJU1lTQ1RMX1NUQVRJQ19D SElMRFJFTihfamFpbF9qYWlscyksIE9JRF9BVVRPLAorCQlwci0+cHJfaG9zdF9vaWQsIENUTEZM QUdfUkQsIDAsICJqYWlsIGhvc3RuYW1lIik7CisJU1lTQ1RMX0FERF9JTlQoJnByLT5qZF9zeXNj dGx0cmVlLCBTWVNDVExfQ0hJTERSRU4ocHItPmpkX3N5c2N0bHRyZWV0b3ApLCBPSURfQVVUTywg ImFsbG93X3Jhd19zb2NrZXRzIiwgCisJCUNUTEZMQUdfUlcsICZwci0+amFpbF9zZXR0aW5ncy5h bGxvd19yYXdfc29ja2V0cywgMCwgIkFsbG93IHJhdyBzb2NrZXRzIGluIGphaWw/Iik7CisJU1lT Q1RMX0FERF9JTlQoJnByLT5qZF9zeXNjdGx0cmVlLCBTWVNDVExfQ0hJTERSRU4ocHItPmpkX3N5 c2N0bHRyZWV0b3ApLCBPSURfQVVUTywgImFsbG93X2lwZnciLCAKKwkJQ1RMRkxBR19SVywgJnBy LT5qYWlsX3NldHRpbmdzLmFsbG93X2lwZncsIDAsICJBbGxvdyBpcGZ3IHVzZT8iKTsKKwlTWVND VExfQUREX0lOVCgmcHItPmpkX3N5c2N0bHRyZWUsIFNZU0NUTF9DSElMRFJFTihwci0+amRfc3lz Y3RsdHJlZXRvcCksIE9JRF9BVVRPLCAibWF4X3JhbSIsIAorCQlDVExGTEFHX1JXLCAmcHItPmph aWxfc2V0dGluZ3MubWF4X3JhbSwgMCwgIk1heGltdW0gUkFNIGFsbG93ZWQgZm9yIGphaWwgKDAg PSB1bmxpbWl0ZWQpIik7CisJU1lTQ1RMX0FERF9JTlQoJnByLT5qZF9zeXNjdGx0cmVlLCBTWVND VExfQ0hJTERSRU4ocHItPmpkX3N5c2N0bHRyZWV0b3ApLCBPSURfQVVUTywgIm1heF9jcHUiLCAK KwkJQ1RMRkxBR19SVywgJnByLT5qYWlsX3NldHRpbmdzLm1heF9jcHUsIDAsICJNYXhpbXVtIENQ VSBhbGxvd2VkIGZvciBqYWlsICgwID0gdW5saW1pdGVkKSIpOworCVNZU0NUTF9BRERfSU5UKCZw ci0+amRfc3lzY3RsdHJlZSwgU1lTQ1RMX0NISUxEUkVOKHByLT5qZF9zeXNjdGx0cmVldG9wKSwg T0lEX0FVVE8sICJtYXhfcHJvY3MiLCAKKwkJQ1RMRkxBR19SVywgJnByLT5qYWlsX3NldHRpbmdz Lm1heF9wcm9jcywgMCwgIk1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyBhbGxvd2VkIGZvciBq YWlsICgwID0gdW5saW1pdGVkKSIpOworCVNZU0NUTF9BRERfSU5UKCZwci0+amRfc3lzY3RsdHJl ZSwgU1lTQ1RMX0NISUxEUkVOKHByLT5qZF9zeXNjdGx0cmVldG9wKSwgT0lEX0FVVE8sICJwcm9j c191c2VkIiwgCisJCUNUTEZMQUdfUkQsICZwci0+amFpbF9zZXR0aW5ncy5wcm9jc191c2VkLCAw LCAiTnVtYmVyIG9mIHByb2Nlc3NlcyBydW5uaW5nIik7CisJU1lTQ1RMX0FERF9JTlQoJnByLT5q ZF9zeXNjdGx0cmVlLCBTWVNDVExfQ0hJTERSRU4ocHItPmpkX3N5c2N0bHRyZWV0b3ApLCBPSURf QVVUTywgInJhbV91c2VkIiwgCisJCUNUTEZMQUdfUkQsICZwci0+amFpbF9zZXR0aW5ncy5yYW1f dXNlZCwgMCwgIkFtb3VudCBvZiBSQU0gdXNlZCIpOworCVNZU0NUTF9BRERfSU5UKCZwci0+amRf c3lzY3RsdHJlZSwgU1lTQ1RMX0NISUxEUkVOKHByLT5qZF9zeXNjdGx0cmVldG9wKSwgT0lEX0FV VE8sICJjcHVfdXNlZCIsIAorCQlDVExGTEFHX1JELCAmcHItPmphaWxfc2V0dGluZ3MuY3B1X3Vz ZWQsIDAsICJBbW91bnQgb2YgQ1BVIHVzZWQiKTsKKwlTWVNDVExfQUREX1BST0MoJnByLT5qZF9z eXNjdGx0cmVlLCBTWVNDVExfQ0hJTERSRU4ocHItPmpkX3N5c2N0bHRyZWV0b3ApLCBPSURfQVVU TywgCisJCSJpcHY0YWRkciIsIENUTFRZUEVfU1RSSU5HIHwgQ1RMRkxBR19SVywgcHIsIHNpemVv ZiAoc3RydWN0IHByaXNvbiksIGphaWxfaXB2NGFkZHJfc3lzY3RsLAorCQkiQSIsICJMaXN0IG9m IElQdjQgYWRkcmVzc2VzIGluIGphaWwuIik7CisKIAlQUk9DX1VOTE9DSyhwKTsKIAljcmZyZWUo b2xkY3JlZCk7CiAJcmV0dXJuICgwKTsKQEAgLTEwNywxNyArMjgxLDE1NyBAQAogCXJldHVybiAo ZXJyb3IpOwogfQogCitpbnQKK2phaWxfY2FsY3RvdGFsdXNlZChwcikKKwlzdHJ1Y3QgcHJpc29u ICpwcjsKK3sKKwlzdHJ1Y3QgcHJvYyAqcHJvY2VzczsKKwl1X2ludCB0b3RhbHJhbSA9IDA7CisJ dV9pbnQgbnVtcHJvY3MgPSAwOworCisJLyogR28gdGhyb3VnaCBldmVyeSBwcm9jZXNzIGluIHRo ZSBzeXN0ZW0gYW5kIGNhbGN1bGF0ZSAKKwkgICB0aGUgYW1vdW50IG9mIENQVSBhbmQgUkFNIHVz ZWQuICovCisJRk9SRUFDSF9QUk9DX0lOX1NZU1RFTShwcm9jZXNzKSB7CisJCWlmICghamFpbGVk KHByb2Nlc3MtPnBfdWNyZWQpKSB7CisJCQljb250aW51ZTsKKwkJfQorCisJCWlmIChwcm9jZXNz LT5wX3VjcmVkLT5jcl9wcmlzb24gIT0gcHIpIHsKKwkJCWNvbnRpbnVlOworCQl9CisKKwkJbnVt cHJvY3MrKzsKKwkJdG90YWxyYW0gKz0gcHJvY2Vzcy0+cF92bXNwYWNlLT52bV90c2l6ZSArIHBy b2Nlc3MtPnBfdm1zcGFjZS0+dm1fZHNpemUKKwkJICAgICsgcHJvY2Vzcy0+cF92bXNwYWNlLT52 bV9zc2l6ZTsKKwl9CisKKwltdHhfbG9jaygmcHItPnByX210eCk7CisJcHItPmphaWxfc2V0dGlu Z3MucmFtX3VzZWQgPSB0b3RhbHJhbSAqIFBBR0VfU0laRTsKKwlwci0+amFpbF9zZXR0aW5ncy5w cm9jc191c2VkID0gbnVtcHJvY3M7CisJbXR4X3VubG9jaygmcHItPnByX210eCk7CisKKwlyZXR1 cm4gMDsKK30KKworLyogVGhpcyBpcyBmcm9tIHByaW50LmMgaW4gL3Vzci9zcmMvYmluL3BzLiAq LworI2RlZmluZSBmeHRvZmwoZml4cHQpICAgKChkb3VibGUpKGZpeHB0KSAvIEZTQ0FMRSkKKwor dm9pZAoramFpbF91cGRhdGVfY3B1KHZvaWQpCit7CisJc3RydWN0IHByb2MgKnA7CisJc3RydWN0 IGphaWxlbGVtZW50ICplbGVtZW50OworCXN0cnVjdCB0aHJlYWQgKnRkOworCisJLyogSWYgbm8g amFpbHMgZXhpc3QsIGV4aXQgZnVuY3Rpb24uICovCisJaWYgKCFmaXJzdGphaWwubGhfZmlyc3Qp IHsKKwkJcmV0dXJuOworCX0KKworCS8qIENsZWFyIGphaWwgQ1BVIGNvdW50ZXJzLiAqLworCUxJ U1RfRk9SRUFDSChlbGVtZW50LCAmZmlyc3RqYWlsLCBwb2ludGVycykgeworCQllbGVtZW50LT5w ci0+amFpbF9zZXR0aW5ncy5jcHVfdXNlZCA9IDA7CisJfQorCisJLyogQ2hlY2sgYWxsIHByb2Nl c3NlcyBmb3IgQ1BVIHVzYWdlLiAqLworCUZPUkVBQ0hfUFJPQ19JTl9TWVNURU0ocCkgeworCQlG T1JFQUNIX1RIUkVBRF9JTl9QUk9DKHAsIHRkKSB7CisJCQlpZiAodGQtPnRkX2tzZSAmJiB0ZC0+ dGRfdWNyZWQtPmNyX3ByaXNvbikgeworCQkJCXRkLT50ZF91Y3JlZC0+Y3JfcHJpc29uLT5qYWls X3NldHRpbmdzLmNwdV91c2VkICs9IAorCQkJCSAgICBmeHRvZmwoc2NoZWRfcGN0Y3B1KHRkLT50 ZF9rc2UpKSAqIDEwMC4wOworCQkJfQorCQl9CisJfQorCisJLyogRXhpdCBmdW5jdGlvbi4gKi8K KwlyZXR1cm47Cit9CisKK2ludAoramFpbF9jaGVja19jcHUodWMpCisJc3RydWN0IHVjcmVkICp1 YzsKK3sKKwlpZiAodWMtPmNyX3ByaXNvbiAmJiB1Yy0+Y3JfcHJpc29uLT5qYWlsX3NldHRpbmdz LmNwdV91c2VkID49IAorCSAgICB1Yy0+Y3JfcHJpc29uLT5qYWlsX3NldHRpbmdzLm1heF9jcHUg JiYgdWMtPmNyX3ByaXNvbi0+amFpbF9zZXR0aW5ncy5tYXhfY3B1ID4gMCkgeworCQlyZXR1cm4g MTsKKwl9IGVsc2UgeworCQlyZXR1cm4gMDsKKwl9Cit9CisKK2ludAoramFpbF9jaGVja19yZXNv dXJjZXModGQpCisJc3RydWN0IHRocmVhZCAqdGQ7Cit7CisJc3RydWN0IHByaXNvbiAqcHIgPSB0 ZC0+dGRfcHJvYy0+cF91Y3JlZC0+Y3JfcHJpc29uOworICAgICAgICAKKwlpZiAocHIpIHsKKwkJ LyogRW5zdXJlIGphaWwgaXNuJ3QgdXNpbmcgbW9yZSB0aGFuIGl0IGlzIGFsbG9jYXRlZC4gKi8g CisJCWphaWxfY2FsY3RvdGFsdXNlZChwcik7CisJCWlmIChwci0+amFpbF9zZXR0aW5ncy5tYXhf cmFtID4gMCAmJiAKKwkJICAgIHByLT5qYWlsX3NldHRpbmdzLnJhbV91c2VkID4gcHItPmphaWxf c2V0dGluZ3MubWF4X3JhbSkgeworCQkJcmV0dXJuIEVOT01FTTsKKwkJfSBlbHNlIGlmIChwci0+ amFpbF9zZXR0aW5ncy5tYXhfcHJvY3MgPiAwICYmCisJCSAgICBwci0+amFpbF9zZXR0aW5ncy5w cm9jc191c2VkID4gcHItPmphaWxfc2V0dGluZ3MubWF4X3Byb2NzKSB7CisJCQlyZXR1cm4gRUFH QUlOOworCQl9IGVsc2UgaWYgKHByLT5qYWlsX3NldHRpbmdzLm1heF9jcHUgPiAwICYmICAKKwkJ ICAgIHByLT5qYWlsX3NldHRpbmdzLmNwdV91c2VkID4gcHItPmphaWxfc2V0dGluZ3MubWF4X2Nw dSkgeyAgICAKKwkJCXJldHVybiBFQUdBSU47CisJCX0KKwl9CisKKwlyZXR1cm4gMDsKK30KKwor aW50CitqYWlsX2NoZWNrX2ZpbGVwZXJtKHZwLCBjcmVkLCB0ZCkKKwlzdHJ1Y3Qgdm5vZGUgKnZw OworCXN0cnVjdCB1Y3JlZCAqY3JlZDsKKwlzdHJ1Y3QgdGhyZWFkICp0ZDsKK3sKKwlzdHJ1Y3Qg amFpbGVsZW1lbnQgKmVsZW1lbnQ7CisKKwkvKiBJZiBmaWxlIGlzIGluIGEgcnVubmluZyBqYWls LCBhbmQgamFpbF9oaWRlX2ZpbGVzID0gMSwgZGVueSBwZXJtaXNzaW9uCisJICAgdG8gYWxsIGJ1 dCByb290LiAqLworCWlmIChqYWlsX2hpZGVfZmlsZXMgJiYgIWNyZWQtPmNyX3ByaXNvbiAmJiBj cmVkLT5jcl91aWQgPiAwKSB7CisJCUxJU1RfRk9SRUFDSChlbGVtZW50LCAmZmlyc3RqYWlsLCBw b2ludGVycykgeworCQkJaWYgKCFzdHJuY21wKHZwLT52X21vdW50LT5tbnRfc3RhdC5mX21udG9u bmFtZSwgZWxlbWVudC0+Y2hyb290X3BhdGgsCisJCQkgICAgc3RybGVuKGVsZW1lbnQtPmNocm9v dF9wYXRoKSkpIHsKKwkJCQlyZXR1cm4gRUFDQ0VTOworCQkJfQorCQl9IAorCX0KKworCXJldHVy biAwOworfQorCiB2b2lkCiBwcmlzb25fZnJlZShzdHJ1Y3QgcHJpc29uICpwcikKIHsKKwlzdHJ1 Y3QgamFpbGVsZW1lbnQgKmVsZW1lbnQ7CiAKIAltdHhfbG9jaygmcHItPnByX210eCk7CiAJcHIt PnByX3JlZi0tOwogCWlmIChwci0+cHJfcmVmID09IDApIHsKIAkJbXR4X3VubG9jaygmcHItPnBy X210eCk7CiAJCW10eF9kZXN0cm95KCZwci0+cHJfbXR4KTsKKworCQkvKiBSZW1vdmUgamFpbCBm cm9tIGxpc3QuICovCisJCUxJU1RfRk9SRUFDSChlbGVtZW50LCAmZmlyc3RqYWlsLCBwb2ludGVy cykgeworCQkJaWYgKGVsZW1lbnQtPnByID09IHByKSB7CisJCQkJTElTVF9SRU1PVkUoZWxlbWVu dCwgcG9pbnRlcnMpOworCQkJCWJyZWFrOworCQkJfQorCQl9CisKIAkJaWYgKHByLT5wcl9saW51 eCAhPSBOVUxMKQogCQkJRlJFRShwci0+cHJfbGludXgsIE1fUFJJU09OKTsKKwkJRlJFRShwci0+ cHJfaXBzLCBNX1BSSVNPTik7CisKKwkJLyogUmVtb3ZlIHN5c2N0bHMuICovCisJCXByLT5qZF9z eXNjdGx0cmVldG9wID0gTlVMTDsKKwkJc3lzY3RsX2N0eF9mcmVlKCZwci0+amRfc3lzY3RsdHJl ZSk7CisKIAkJRlJFRShwciwgTV9QUklTT04pOwogCQlyZXR1cm47CiAJfQpAQCAtMTM3LDcgKzQ1 MSw3IEBACiBwcmlzb25fZ2V0aXAoc3RydWN0IHVjcmVkICpjcmVkKQogewogCi0JcmV0dXJuIChj cmVkLT5jcl9wcmlzb24tPnByX2lwKTsKKwlyZXR1cm4gKGNyZWQtPmNyX3ByaXNvbi0+cHJfaXBz WzBdKTsKIH0KIAogaW50CkBAIC0xNTIsMjAgKzQ2NiwxNiBAQAogCWVsc2UKIAkJdG1wID0gbnRv aGwoKmlwKTsKIAlpZiAodG1wID09IElOQUREUl9BTlkpIHsKLQkJaWYgKGZsYWcpIAotCQkJKmlw ID0gY3JlZC0+Y3JfcHJpc29uLT5wcl9pcDsKLQkJZWxzZQotCQkJKmlwID0gaHRvbmwoY3JlZC0+ Y3JfcHJpc29uLT5wcl9pcCk7CiAJCXJldHVybiAoMCk7CiAJfQogCWlmICh0bXAgPT0gSU5BRERS X0xPT1BCQUNLKSB7CiAJCWlmIChmbGFnKQotCQkJKmlwID0gY3JlZC0+Y3JfcHJpc29uLT5wcl9p cDsKKwkJCSppcCA9IGNyZWQtPmNyX3ByaXNvbi0+cHJfaXBzWzBdOwogCQllbHNlCi0JCQkqaXAg PSBodG9ubChjcmVkLT5jcl9wcmlzb24tPnByX2lwKTsKKwkJCSppcCA9IGh0b25sKGNyZWQtPmNy X3ByaXNvbi0+cHJfaXBzWzBdKTsKIAkJcmV0dXJuICgwKTsKIAl9Ci0JaWYgKGNyZWQtPmNyX3By aXNvbi0+cHJfaXAgIT0gdG1wKQorCWlmICghcHJpc29uX2NoZWNrX2lwKGNyZWQtPmNyX3ByaXNv biwgdG1wKSkKIAkJcmV0dXJuICgxKTsKIAlyZXR1cm4gKDApOwogfQpAQCAtMTgzLDkgKzQ5Myw5 IEBACiAJCXRtcCA9IG50b2hsKCppcCk7CiAJaWYgKHRtcCA9PSBJTkFERFJfTE9PUEJBQ0spIHsK IAkJaWYgKGZsYWcpCi0JCQkqaXAgPSBjcmVkLT5jcl9wcmlzb24tPnByX2lwOworCQkJKmlwID0g Y3JlZC0+Y3JfcHJpc29uLT5wcl9pcHNbMF07CiAJCWVsc2UKLQkJCSppcCA9IGh0b25sKGNyZWQt PmNyX3ByaXNvbi0+cHJfaXApOworCQkJKmlwID0gaHRvbmwoY3JlZC0+Y3JfcHJpc29uLT5wcl9p cHNbMF0pOwogCQlyZXR1cm47CiAJfQogCXJldHVybjsKQEAgLTIwMSw3ICs1MTEsNyBAQAogCQlv ayA9IDE7CiAJZWxzZSBpZiAoc2FpLT5zaW5fZmFtaWx5ICE9IEFGX0lORVQpCiAJCW9rID0gMDsK LQllbHNlIGlmIChjcmVkLT5jcl9wcmlzb24tPnByX2lwICE9IG50b2hsKHNhaS0+c2luX2FkZHIu c19hZGRyKSkKKwllbHNlIGlmICghcHJpc29uX2NoZWNrX2lwKGNyZWQtPmNyX3ByaXNvbiwgbnRv aGwoc2FpLT5zaW5fYWRkci5zX2FkZHIpKSkKIAkJb2sgPSAxOwogCWVsc2UKIAkJb2sgPSAwOwpA QCAtMjIxLDYgKzUzMSwxMiBAQAogCQkJcmV0dXJuIChFU1JDSCk7CiAJCWlmIChjcmVkMi0+Y3Jf cHJpc29uICE9IGNyZWQxLT5jcl9wcmlzb24pCiAJCQlyZXR1cm4gKEVTUkNIKTsKKwl9IGVsc2Ug eworCQkvKiBUaGlzIGlzIG5lY2Vzc2FyeSBiZWNhdXNlIGl0IGFwcGVhcnMgaWYgYSBwcm9jZXNz IGlzIHJ1bm5pbmcgaW4KKwkJICAgYSBqYWlsIGFuZCB0aGUgcHJvY2VzcyBpcyBydW5uaW5nIHVu ZGVyIHRoZSBzYW1lIFVJRCBhcyB0aGUgdXNlciwKKwkJICAga2lsbCgpIHdpbGwgYWN0dWFsbHkg a2lsbCBpdC4gKi8KKwkJaWYgKGphaWxlZChjcmVkMikgJiYgY3JlZDEtPmNyX3J1aWQgIT0gMCAm JiBqYWlsX2hpZGVfcHJvY2Vzc2VzKQorCQkJcmV0dXJuIChFU1JDSCk7CiAJfQogCiAJcmV0dXJu ICgwKTsKQEAgLTI1NCw0ICs1NzAsMjAgQEAKIAl9CiAJZWxzZQogCQlzdHJsY3B5KGJ1ZiwgaG9z dG5hbWUsIHNpemUpOworfQorCisvKgorICogUmV0dXJucyAxIGlmIHRoZSBJUCBleGlzdHMgaW4g dGhlIGphaWwuCisgKi8KK2ludAorcHJpc29uX2NoZWNrX2lwKHN0cnVjdCBwcmlzb24gKnByLCB1 X2ludDMyX3QgaXApCit7CisJcmVnaXN0ZXIgdV9pbnQgaTsKKworCWZvciAoaSA9IDA7IGkgPCBw ci0+cHJfbmlwczsgKytpKSB7CisJCWlmIChwci0+cHJfaXBzW2ldID09IGlwKQorCQkJcmV0dXJu ICgxKTsKKwl9CisKKwlyZXR1cm4gKDApOwogfQpkaWZmIC11ciBzcmMudmlyZ2luL3N5cy9rZXJu L2tlcm5fc3dpdGNoLmMgc3JjLmRpcnR5L3N5cy9rZXJuL2tlcm5fc3dpdGNoLmMKLS0tIHNyYy52 aXJnaW4vc3lzL2tlcm4va2Vybl9zd2l0Y2guYwlNb24gT2N0IDE0IDE0OjQzOjAyIDIwMDIKKysr IHNyYy5kaXJ0eS9zeXMva2Vybi9rZXJuX3N3aXRjaC5jCVRodSBGZWIgMjcgMTc6Mzg6MzIgMjAw MwpAQCAtOTgsNiArOTgsNyBAQAogI2luY2x1ZGUgPHN5cy9wcm9jLmg+CiAjaW5jbHVkZSA8c3lz L3F1ZXVlLmg+CiAjaW5jbHVkZSA8c3lzL3NjaGVkLmg+CisjaW5jbHVkZSA8c3lzL2phaWwuaD4K ICNpbmNsdWRlIDxtYWNoaW5lL2NyaXRpY2FsLmg+CiAKIENUQVNTRVJUKChSUUJfQlBXICogUlFC X0xFTikgPT0gUlFfTlFTKTsKQEAgLTI0MSw2ICsyNDIsMTAgQEAKIAkJCW9yaWdpbmFsLT50ZF9r c2UgPSBOVUxMOwogCQlvcmlnaW5hbCA9IG93bmVyOwogCisJCWlmIChURF9JU19KU0xFRVAob3du ZXIpICYmIGphaWxfY2hlY2tfY3B1KG93bmVyLT50ZF91Y3JlZCkgPT0gMCkgeworCQkJLyogV2Fr ZSBpdCB1cC4gKi8KKwkJCVREX0NMUl9KU0xFRVAob3duZXIpOworCQl9CiAJCWlmIChURF9DQU5f UlVOKG93bmVyKSkgewogCQkJLyoKIAkJCSAqIElmIHRoZSBvd25lciB0aHJlYWQgaXMgbm93IHJ1 bm5hYmxlLCAgcnVuIGl0Li4KQEAgLTM3OSw2ICszODQsMTMgQEAKIAlzdHJ1Y3Qga3NlZ3JwICpr ZzsKIAlzdHJ1Y3QgdGhyZWFkICp0ZDI7CiAJc3RydWN0IHRocmVhZCAqdGRhOworCisJaWYgKHRk LT50ZF91Y3JlZCAmJiBqYWlsX2NoZWNrX2NwdSh0ZC0+dGRfdWNyZWQpID09IDEpIHsKKwkJLyog RG9uJ3QgYWRkIHRvIHJ1biBxdWV1ZS4gUHV0IGl0IHRvIHNsZWVwLiBFeGl0IGZ1bmN0aW9uLiAq LworCQlURF9TRVRfSlNMRUVQKHRkKTsKKwkJdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24tPnJlc2No ZWQgPSAxOworCQlyZXR1cm47CisJfQogCiAJQ1RSMShLVFJfUlVOUSwgInNldHJ1bnF1ZXVlOiB0 ZCVwIiwgdGQpOwogCW10eF9hc3NlcnQoJnNjaGVkX2xvY2ssIE1BX09XTkVEKTsKZGlmZiAtdXIg c3JjLnZpcmdpbi9zeXMva2Vybi9zY2hlZF80YnNkLmMgc3JjLmRpcnR5L3N5cy9rZXJuL3NjaGVk XzRic2QuYwotLS0gc3JjLnZpcmdpbi9zeXMva2Vybi9zY2hlZF80YnNkLmMJVGh1IE5vdiAyMSAw MjozMDo1NSAyMDAyCisrKyBzcmMuZGlydHkvc3lzL2tlcm4vc2NoZWRfNGJzZC5jCVRodSBGZWIg MjcgMTc6Mzg6MzIgMjAwMwpAQCAtNDIsNiArNDIsNyBAQAogI2luY2x1ZGUgPHN5cy9zeXN0bS5o PgogI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KICNpbmNsdWRlIDxzeXMva3RyLmg+CisjaW5jbHVk ZSA8c3lzL2phaWwuaD4KICNpbmNsdWRlIDxzeXMvbG9jay5oPgogI2luY2x1ZGUgPHN5cy9tdXRl eC5oPgogI2luY2x1ZGUgPHN5cy9wcm9jLmg+CkBAIC0xMTYsNyArMTE3LDcgQEAKIHsKIAogCW10 eF9hc3NlcnQoJnNjaGVkX2xvY2ssIE1BX09XTkVEKTsKLQlpZiAodGQtPnRkX3ByaW9yaXR5IDwg Y3VydGhyZWFkLT50ZF9wcmlvcml0eSkKKwlpZiAodGQtPnRkX3ByaW9yaXR5IDwgY3VydGhyZWFk LT50ZF9wcmlvcml0eSB8fCB0ZC0+dGRfdWNyZWQtPmNyX3ByaXNvbikKIAkJY3VydGhyZWFkLT50 ZF9rc2UtPmtlX2ZsYWdzIHw9IEtFRl9ORUVEUkVTQ0hFRDsKIH0KIApAQCAtMjQxLDEyICsyNDIs MjkgQEAKIAlzdHJ1Y3Qga3NlICprZTsKIAlzdHJ1Y3Qga3NlZ3JwICprZzsKIAlpbnQgcmVhbHN0 YXRoejsKLQlpbnQgYXdha2U7CisJaW50IGF3YWtlLCBjaGVja2VkX3N0YXR1cyA9IDA7CiAKIAly ZWFsc3RhdGh6ID0gc3RhdGh6ID8gc3RhdGh6IDogaHo7CiAJc3hfc2xvY2soJmFsbHByb2NfbG9j ayk7CiAJRk9SRUFDSF9QUk9DX0lOX1NZU1RFTShwKSB7CiAJCW10eF9sb2NrX3NwaW4oJnNjaGVk X2xvY2spOworCQlpZiAocC0+cF91Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQlpZiAoIWphaWxfY2hl Y2tfY3B1KHAtPnBfdWNyZWQpKSB7CisJCQkJbXR4X3VubG9ja19zcGluKCZzY2hlZF9sb2NrKTsK KwkJCQlGT1JFQUNIX1RIUkVBRF9JTl9QUk9DKHAsIHRkKSB7CisJCQkJCWlmIChURF9JU19KU0xF RVAodGQpKSB7CisJCQkJCQlURF9DTFJfSlNMRUVQKHRkKTsKKwkJCQkJCXNldHJ1bnF1ZXVlKHRk KTsKKwkJCQkJfQorCQkJCX0KKwkJCQltdHhfbG9ja19zcGluKCZzY2hlZF9sb2NrKTsKKwkJCX0K KwkJCWlmIChjaGVja2VkX3N0YXR1cyA9PSAwKSB7CisJCQkJamFpbF91cGRhdGVfY3B1KCk7CisJ CQkJY2hlY2tlZF9zdGF0dXMgPSAxOworCQkJfQorCQl9CisKIAkJcC0+cF9zd3RpbWUrKzsKIAkJ Rk9SRUFDSF9LU0VHUlBfSU5fUFJPQyhwLCBrZykgeyAKIAkJCWF3YWtlID0gMDsKZGlmZiAtdXIg c3JjLnZpcmdpbi9zeXMva2Vybi9zeXN2X2lwYy5jIHNyYy5kaXJ0eS9zeXMva2Vybi9zeXN2X2lw Yy5jCi0tLSBzcmMudmlyZ2luL3N5cy9rZXJuL3N5c3ZfaXBjLmMJTW9uIEFwciAgMSAxNDozMTow MCAyMDAyCisrKyBzcmMuZGlydHkvc3lzL2tlcm4vc3lzdl9pcGMuYwlUaHUgRmViIDI3IDE3OjM4 OjMyIDIwMDMKQEAgLTc4LDYgKzc4LDExIEBACiB7CiAJc3RydWN0IHVjcmVkICpjcmVkID0gdGQt PnRkX3VjcmVkOwogCisJLyogQ2hlY2sgZm9yIGphaWwgbWF0Y2guICovCisJaWYgKGNyZWQtPmNy X3ByaXNvbiAhPSBwZXJtLT5wcikgeworCQlyZXR1cm4gRUFDQ0VTOworCX0KKwogCS8qIENoZWNr IGZvciB1c2VyIG1hdGNoLiAqLwogCWlmIChjcmVkLT5jcl91aWQgIT0gcGVybS0+Y3VpZCAmJiBj cmVkLT5jcl91aWQgIT0gcGVybS0+dWlkKSB7CiAJCWlmIChtb2RlICYgSVBDX00pCmRpZmYgLXVy IHNyYy52aXJnaW4vc3lzL2tlcm4vc3lzdl9tc2cuYyBzcmMuZGlydHkvc3lzL2tlcm4vc3lzdl9t c2cuYwotLS0gc3JjLnZpcmdpbi9zeXMva2Vybi9zeXN2X21zZy5jCVN1biBEZWMgMTUgMDY6NTQ6 NTUgMjAwMgorKysgc3JjLmRpcnR5L3N5cy9rZXJuL3N5c3ZfbXNnLmMJVGh1IEZlYiAyNyAxNzoz ODozMiAyMDAzCkBAIC00MzUsNiArNDM1LDcgQEAKIAkJbXNxcHRyLT5tc2dfcGVybS5naWQgPSBt c3FidWYubXNnX3Blcm0uZ2lkOwkvKiBjaGFuZ2UgdGhlIG93bmVyICovCiAJCW1zcXB0ci0+bXNn X3Blcm0ubW9kZSA9IChtc3FwdHItPm1zZ19wZXJtLm1vZGUgJiB+MDc3NykgfAogCQkgICAgKG1z cWJ1Zi5tc2dfcGVybS5tb2RlICYgMDc3Nyk7CisJCW1zcXB0ci0+bXNnX3Blcm0ucHIgPSB0ZC0+ dGRfdWNyZWQtPmNyX3ByaXNvbjsKIAkJbXNxcHRyLT5tc2dfcWJ5dGVzID0gbXNxYnVmLm1zZ19x Ynl0ZXM7CiAJCW1zcXB0ci0+bXNnX2N0aW1lID0gdGltZV9zZWNvbmQ7CiAJCWJyZWFrOwpAQCAt NTM5LDYgKzU0MCw3IEBACiAJCW1zcXB0ci0+bXNnX3Blcm0ubW9kZSA9IChtc2dmbGcgJiAwNzc3 KTsKIAkJLyogTWFrZSBzdXJlIHRoYXQgdGhlIHJldHVybmVkIG1zcWlkIGlzIHVuaXF1ZSAqLwog CQltc3FwdHItPm1zZ19wZXJtLnNlcSA9IChtc3FwdHItPm1zZ19wZXJtLnNlcSArIDEpICYgMHg3 ZmZmOworCQltc3FwdHItPm1zZ19wZXJtLnByID0gdGQtPnRkX3VjcmVkLT5jcl9wcmlzb247CiAJ CW1zcXB0ci0+bXNnX2ZpcnN0ID0gTlVMTDsKIAkJbXNxcHRyLT5tc2dfbGFzdCA9IE5VTEw7CiAJ CW1zcXB0ci0+bXNnX2NieXRlcyA9IDA7CmRpZmYgLXVyIHNyYy52aXJnaW4vc3lzL2tlcm4vc3lz dl9zZW0uYyBzcmMuZGlydHkvc3lzL2tlcm4vc3lzdl9zZW0uYwotLS0gc3JjLnZpcmdpbi9zeXMv a2Vybi9zeXN2X3NlbS5jCUZyaSBPY3QgMTggMjA6MDc6MzUgMjAwMgorKysgc3JjLmRpcnR5L3N5 cy9rZXJuL3N5c3Zfc2VtLmMJVGh1IEZlYiAyNyAxNzozODozMiAyMDAzCkBAIC01ODUsNiArNTg1 LDcgQEAKIAkJc2VtYXB0ci0+c2VtX3Blcm0ubW9kZSA9IChzZW1hcHRyLT5zZW1fcGVybS5tb2Rl ICYgfjA3NzcpIHwKIAkJICAgIChzYnVmLnNlbV9wZXJtLm1vZGUgJiAwNzc3KTsKIAkJc2VtYXB0 ci0+c2VtX2N0aW1lID0gdGltZV9zZWNvbmQ7CisJCXNlbWFwdHItPnNlbV9wZXJtLnByID0gdGQt PnRkX3VjcmVkLT5jcl9wcmlzb247CiAJCWJyZWFrOwogCiAJY2FzZSBJUENfU1RBVDoKQEAgLTgz Miw2ICs4MzMsNyBAQAogCQlzZW1hW3NlbWlkXS5zZW1fcGVybS5tb2RlID0gKHNlbWZsZyAmIDA3 NzcpIHwgU0VNX0FMTE9DOwogCQlzZW1hW3NlbWlkXS5zZW1fcGVybS5zZXEgPQogCQkgICAgKHNl bWFbc2VtaWRdLnNlbV9wZXJtLnNlcSArIDEpICYgMHg3ZmZmOworCQlzZW1hW3NlbWlkXS5zZW1f cGVybS5wciA9IGNyZWQtPmNyX3ByaXNvbjsKIAkJc2VtYVtzZW1pZF0uc2VtX25zZW1zID0gbnNl bXM7CiAJCXNlbWFbc2VtaWRdLnNlbV9vdGltZSA9IDA7CiAJCXNlbWFbc2VtaWRdLnNlbV9jdGlt ZSA9IHRpbWVfc2Vjb25kOwpkaWZmIC11ciBzcmMudmlyZ2luL3N5cy9rZXJuL3N5c3Zfc2htLmMg c3JjLmRpcnR5L3N5cy9rZXJuL3N5c3Zfc2htLmMKLS0tIHNyYy52aXJnaW4vc3lzL2tlcm4vc3lz dl9zaG0uYwlXZWQgQXVnIDE0IDIwOjEwOjEyIDIwMDIKKysrIHNyYy5kaXJ0eS9zeXMva2Vybi9z eXN2X3NobS5jCVRodSBGZWIgMjcgMTc6Mzg6MzIgMjAwMwpAQCAtMjI2LDYgKzIyNiwxMSBAQAog CiAJc2VnbnVtID0gSVBDSURfVE9fSVgoc2htbWFwX3MtPnNobWlkKTsKIAlzaG1zZWcgPSAmc2ht c2Vnc1tzZWdudW1dOworCS8qIENoZWNrIGphaWwgcGVybWlzc2lvbnMuICovCisJaWYgKHAtPnBf dWNyZWQtPmNyX3ByaXNvbiAhPSBzaG1zZWctPnNobV9wZXJtLnByKSB7CisJCXJldHVybihFQUND RVMpOworCX0KKwogCXNpemUgPSByb3VuZF9wYWdlKHNobXNlZy0+c2htX3NlZ3N6KTsKIAlyZXN1 bHQgPSB2bV9tYXBfcmVtb3ZlKCZwLT5wX3Ztc3BhY2UtPnZtX21hcCwgc2htbWFwX3MtPnZhLAog CSAgICBzaG1tYXBfcy0+dmEgKyBzaXplKTsKQEAgLTUzOCw2ICs1NDMsNyBAQAogCQkgICAgKHNo bXNlZy0+c2htX3Blcm0ubW9kZSAmIH5BQ0NFU1NQRVJNUykgfAogCQkgICAgKGluYnVmLnNobV9w ZXJtLm1vZGUgJiBBQ0NFU1NQRVJNUyk7CiAJCXNobXNlZy0+c2htX2N0aW1lID0gdGltZV9zZWNv bmQ7CisJCXNobXNlZy0+c2htX3Blcm0ucHIgPSB0ZC0+dGRfdWNyZWQtPmNyX3ByaXNvbjsKIAkJ YnJlYWs7CiAJY2FzZSBJUENfUk1JRDoKIAkJZXJyb3IgPSBpcGNwZXJtKHRkLCAmc2htc2VnLT5z aG1fcGVybSwgSVBDX00pOwpAQCAtNjQ1LDYgKzY1MSw3IEBACiAJc2htc2VnLT5zaG1fcGVybS5t b2RlID0gU0hNU0VHX0FMTE9DQVRFRCB8IFNITVNFR19SRU1PVkVEOwogCXNobXNlZy0+c2htX3Bl cm0ua2V5ID0gdWFwLT5rZXk7CiAJc2htc2VnLT5zaG1fcGVybS5zZXEgPSAoc2htc2VnLT5zaG1f cGVybS5zZXEgKyAxKSAmIDB4N2ZmZjsKKwlzaG1zZWctPnNobV9wZXJtLnByID0gdGQtPnRkX3Vj cmVkLT5jcl9wcmlzb247CiAJc2htX2hhbmRsZSA9IChzdHJ1Y3Qgc2htX2hhbmRsZSAqKQogCSAg ICBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBzaG1faGFuZGxlKSwgTV9TSE0sIE1fV0FJVE9LKTsKIAlz aG1pZCA9IElYU0VRX1RPX0lQQ0lEKHNlZ251bSwgc2htc2VnLT5zaG1fcGVybSk7CkBAIC02NzMs NiArNjgwLDcgQEAKIAlzaG1zZWctPnNobV9scGlkID0gc2htc2VnLT5zaG1fbmF0dGNoID0gMDsK IAlzaG1zZWctPnNobV9hdGltZSA9IHNobXNlZy0+c2htX2R0aW1lID0gMDsKIAlzaG1zZWctPnNo bV9jdGltZSA9IHRpbWVfc2Vjb25kOworCXNobXNlZy0+c2htX3Blcm0ucHIgPSB0ZC0+dGRfdWNy ZWQtPmNyX3ByaXNvbjsKIAlzaG1fY29tbWl0dGVkICs9IGJ0b2Moc2l6ZSk7CiAJc2htX251c2Vk Kys7CiAJaWYgKHNobXNlZy0+c2htX3Blcm0ubW9kZSAmIFNITVNFR19XQU5URUQpIHsKZGlmZiAt dXIgc3JjLnZpcmdpbi9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYyBzcmMuZGlydHkvc3lzL2tlcm4v dmZzX3N5c2NhbGxzLmMKLS0tIHNyYy52aXJnaW4vc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmMJTW9u IEphbiAgNiAxNDoyMDo1NCAyMDAzCisrKyBzcmMuZGlydHkvc3lzL2tlcm4vdmZzX3N5c2NhbGxz LmMJTW9uIE1hciAgMyAwNzo1MzoyNyAyMDAzCkBAIC0xNTgsNyArMTU4LDggQEAKIH0KIAogLyog WFhYIFBSSVNPTjogY291bGQgYmUgcGVyIHByaXNvbiBmbGFnICovCi1zdGF0aWMgaW50IHByaXNv bl9xdW90YXM7CisvKnN0YXRpYyBpbnQgcHJpc29uX3F1b3RhczsqLworZXh0ZXJuIGludCBqYWls X3F1b3Rhc19hbGxvd2VkOwogI2lmIDAKIFNZU0NUTF9JTlQoX2tlcm5fcHJpc29uLCBPSURfQVVU TywgcXVvdGFzLCBDVExGTEFHX1JXLCAmcHJpc29uX3F1b3RhcywgMCwgIiIpOwogI2VuZGlmCkBA IC0xODksNyArMTkwLDcgQEAKIAlpbnQgZXJyb3I7CiAJc3RydWN0IG5hbWVpZGF0YSBuZDsKIAot CWlmIChqYWlsZWQodGQtPnRkX3VjcmVkKSAmJiAhcHJpc29uX3F1b3RhcykKKwlpZiAoamFpbGVk KHRkLT50ZF91Y3JlZCkgJiYgIWphaWxfcXVvdGFzX2FsbG93ZWQpCiAJCXJldHVybiAoRVBFUk0p OwogCU5ESU5JVCgmbmQsIExPT0tVUCwgRk9MTE9XLCBVSU9fVVNFUlNQQUNFLCB1YXAtPnBhdGgs IHRkKTsKIAlpZiAoKGVycm9yID0gbmFtZWkoJm5kKSkgIT0gMCkKQEAgLTMxMSw2ICszMTIsOCBA QAogCWludCBmbGFnczsKIH07CiAjZW5kaWYKK2V4dGVybiBzdHJ1Y3QgamFpbHMgZmlyc3RqYWls OworCiBpbnQKIGdldGZzc3RhdCh0ZCwgdWFwKQogCXN0cnVjdCB0aHJlYWQgKnRkOwpAQCAtMzI0 LDYgKzMyNyw3IEBACiAJcmVnaXN0ZXIgc3RydWN0IHN0YXRmcyAqc3A7CiAJY2FkZHJfdCBzZnNw OwogCWxvbmcgY291bnQsIG1heGNvdW50LCBlcnJvcjsKKwlzdHJ1Y3Qgc3RhdGZzICp0bXBzcDsK IAogCW1heGNvdW50ID0gdWFwLT5idWZzaXplIC8gc2l6ZW9mKHN0cnVjdCBzdGF0ZnMpOwogCXNm c3AgPSAoY2FkZHJfdCl1YXAtPmJ1ZjsKQEAgLTM1Niw3ICszNjAsMzUgQEAKIAkJCQljb250aW51 ZTsKIAkJCX0KIAkJCXNwLT5mX2ZsYWdzID0gbXAtPm1udF9mbGFnICYgTU5UX1ZJU0ZMQUdNQVNL OwotCQkJZXJyb3IgPSBjb3B5b3V0KHNwLCBzZnNwLCBzaXplb2YoKnNwKSk7CisKKwkJCS8qIElm IGphaWxlZCwgb25seSByZXR1cm4gdGhlIG1vdW50cG9pbnRzIHRoYXQgYXJlIGluIHRoZSBqYWls LiAqLworCQkJaWYgKHRkLT50ZF9wcm9jLT5wX3VjcmVkLT5jcl9wcmlzb24pIHsKKwkJCQlzdHJ1 Y3QgamFpbGVsZW1lbnQgKmVsZW1lbnQ7CisJCQkJTElTVF9GT1JFQUNIKGVsZW1lbnQsICZmaXJz dGphaWwsIHBvaW50ZXJzKSB7CisJCQkJCWlmIChlbGVtZW50LT5wciA9PSB0ZC0+dGRfcHJvYy0+ cF91Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQkJCQlicmVhazsKKwkJCQkJfQorCQkJCX0KKwkJCQlp ZiAoIXN0cm5jbXAoZWxlbWVudC0+Y2hyb290X3BhdGgsIHNwLT5mX21udG9ubmFtZSwgCisJCQkJ ICBzdHJsZW4oZWxlbWVudC0+Y2hyb290X3BhdGgpKSkgeworCQkJCQlNQUxMT0ModG1wc3AsIHN0 cnVjdCBzdGF0ZnMgKiwgc2l6ZW9mKHN0cnVjdCBzdGF0ZnMpLCBNX1BSSVNPTiwgTV9XQUlUT0sp OworCQkJCQltZW1jcHkodG1wc3AsIHNwLCBzaXplb2Yoc3RydWN0IHN0YXRmcykpOworCQkJCQlz dHJjcHkodG1wc3AtPmZfbW50b25uYW1lLCBzcC0+Zl9tbnRvbm5hbWUgKyBzdHJsZW4oZWxlbWVu dC0+Y2hyb290X3BhdGgpKTsKKwkJCQkJaWYgKHN0cmxlbih0bXBzcC0+Zl9tbnRvbm5hbWUpID09 IDApIHsKKwkJCQkJCS8qIFJvb3QgbW91bnQuICovCisJCQkJCQlzdHJjcHkodG1wc3AtPmZfbW50 b25uYW1lLCAiLyIpOworCQkJCQl9CisJCQkJCWVycm9yID0gY29weW91dCh0bXBzcCwgc2ZzcCwg c2l6ZW9mKCp0bXBzcCkpOworCQkJCQlGUkVFKHRtcHNwLCBNX1BSSVNPTik7CisJCQkJfSBlbHNl IHsKKwkJCQkJbXR4X2xvY2soJm1vdW50bGlzdF9tdHgpOworCQkJCQlubXAgPSBUQUlMUV9ORVhU KG1wLCBtbnRfbGlzdCk7CisJCQkJCXZmc191bmJ1c3kobXAsIHRkKTsKKwkJCQkJY29udGludWU7 CisJCQkJfQorCQkJfSBlbHNlIHsKKwkJCQllcnJvciA9IGNvcHlvdXQoc3AsIHNmc3AsIHNpemVv Zigqc3ApKTsKKwkJCX0KIAkJCWlmIChlcnJvcikgewogCQkJCXZmc191bmJ1c3kobXAsIHRkKTsK IAkJCQlyZXR1cm4gKGVycm9yKTsKQEAgLTE0MjMsNiArMTQ1NSw3IEBACiAJCQlmbGFncyB8PSBW V1JJVEU7CiAJCWlmICh1c2VyX2ZsYWdzICYgWF9PSykKIAkJCWZsYWdzIHw9IFZFWEVDOworCiAj aWZkZWYgTUFDCiAJCWVycm9yID0gbWFjX2NoZWNrX3Zub2RlX2FjY2VzcyhjcmVkLCB2cCwgZmxh Z3MpOwogCQlpZiAoZXJyb3IpCmRpZmYgLXVyIHNyYy52aXJnaW4vc3lzL25ldGluZXQvaW5fcGNi LmMgc3JjLmRpcnR5L3N5cy9uZXRpbmV0L2luX3BjYi5jCi0tLSBzcmMudmlyZ2luL3N5cy9uZXRp bmV0L2luX3BjYi5jCUZyaSBOb3YgIDggMTY6NTA6MzIgMjAwMgorKysgc3JjLmRpcnR5L3N5cy9u ZXRpbmV0L2luX3BjYi5jCVN1biBNYXIgIDIgMTk6NTc6NDAgMjAwMwpAQCAtMjk2LDcgKzI5Niw3 IEBACiAJCQkgICAgIUlOX01VTFRJQ0FTVChudG9obChzaW4tPnNpbl9hZGRyLnNfYWRkcikpKSB7 CiAJCQkJdCA9IGluX3BjYmxvb2t1cF9sb2NhbChpbnAtPmlucF9wY2JpbmZvLAogCQkJCSAgICBz aW4tPnNpbl9hZGRyLCBscG9ydCwKLQkJCQkgICAgcHJpc29uID8gMCA6ICBJTlBMT09LVVBfV0lM RENBUkQpOworCQkJCSAgICBwcmlzb24gPyAwIDogIElOUExPT0tVUF9XSUxEQ0FSRCwgcHJpc29u ID8gdGQgOiBOVUxMKTsKIAkJCQlpZiAodCAmJgogCQkJCSAgICAobnRvaGwoc2luLT5zaW5fYWRk ci5zX2FkZHIpICE9IElOQUREUl9BTlkgfHwKIAkJCQkgICAgIG50b2hsKHQtPmlucF9sYWRkci5z X2FkZHIpICE9IElOQUREUl9BTlkgfHwKQEAgLTMxOSw3ICszMTksNyBAQAogCQkJICAgIHByaXNv bl9pcCh0ZC0+dGRfdWNyZWQsIDAsICZzaW4tPnNpbl9hZGRyLnNfYWRkcikpCiAJCQkJcmV0dXJu IChFQUREUk5PVEFWQUlMKTsKIAkJCXQgPSBpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgc2lu LT5zaW5fYWRkciwKLQkJCSAgICBscG9ydCwgcHJpc29uID8gMCA6IHdpbGQpOworCQkJICAgIGxw b3J0LCBwcmlzb24gPyAwIDogd2lsZCwgcHJpc29uID8gdGQgOiBOVUxMKTsKIAkJCWlmICh0ICYm CiAJCQkgICAgKHJldXNlcG9ydCAmIHQtPmlucF9zb2NrZXQtPnNvX29wdGlvbnMpID09IDApIHsK ICNpZiBkZWZpbmVkKElORVQ2KQpAQCAtMzQwLDYgKzM0MCw5IEBACiAJCXVzaG9ydCBmaXJzdCwg bGFzdDsKIAkJaW50IGNvdW50OwogCisJCWlmIChsYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAm JiB0ZC0+dGRfdWNyZWQtPmNyX3ByaXNvbikKKwkJCWxhZGRyLnNfYWRkciA9IGh0b25sKHByaXNv bl9nZXRpcCh0ZC0+dGRfdWNyZWQpKTsKKwogCQlpZiAobGFkZHIuc19hZGRyICE9IElOQUREUl9B TlkpCiAJCQlpZiAocHJpc29uX2lwKHRkLT50ZF91Y3JlZCwgMCwgJmxhZGRyLnNfYWRkcikpCiAJ CQkJcmV0dXJuIChFSU5WQUwpOwpAQCAtMzgxLDcgKzM4NCw3IEBACiAJCQkJCSpsYXN0cG9ydCA9 IGZpcnN0OwogCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKIAkJCX0gd2hpbGUgKGluX3Bj Ymxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwgbHBvcnQsCi0JCQkgICAgd2lsZCkpOworCQkJ ICAgIHdpbGQsIHdpbGQgPyBOVUxMIDogdGQpKTsKIAkJfSBlbHNlIHsKIAkJCS8qCiAJCQkgKiBj b3VudGluZyB1cApAQCAtMzk2LDcgKzM5OSw3IEBACiAJCQkJCSpsYXN0cG9ydCA9IGZpcnN0Owog CQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKIAkJCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9s b2NhbChwY2JpbmZvLCBsYWRkciwgbHBvcnQsCi0JCQkgICAgd2lsZCkpOworCQkJICAgIHdpbGQs IHdpbGQgPyBOVUxMIDogdGQpKTsKIAkJfQogCX0KIAlpZiAocHJpc29uX2lwKHRkLT50ZF91Y3Jl ZCwgMCwgJmxhZGRyLnNfYWRkcikpCkBAIC01MTksOSArNTIyLDEzIEBACiAJCSAqIGFuZCB0aGUg cHJpbWFyeSBpbnRlcmZhY2Ugc3VwcG9ydHMgYnJvYWRjYXN0LAogCQkgKiBjaG9vc2UgdGhlIGJy b2FkY2FzdCBhZGRyZXNzIGZvciB0aGF0IGludGVyZmFjZS4KIAkJICovCi0JCWlmIChmYWRkci5z X2FkZHIgPT0gSU5BRERSX0FOWSkKLQkJCWZhZGRyID0gSUFfU0lOKFRBSUxRX0ZJUlNUKCZpbl9p ZmFkZHJoZWFkKSktPnNpbl9hZGRyOwotCQllbHNlIGlmIChmYWRkci5zX2FkZHIgPT0gKHVfbG9u ZylJTkFERFJfQlJPQURDQVNUICYmCisJCWlmIChmYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSkg eworCQkJaWYgKGphaWxlZChjcmVkKSkgeworCQkJCWZhZGRyLnNfYWRkciA9IGh0b25sKHByaXNv bl9nZXRpcChjcmVkKSk7CisJCQl9IGVsc2UgeworCQkJCWZhZGRyID0gSUFfU0lOKFRBSUxRX0ZJ UlNUKCZpbl9pZmFkZHJoZWFkKSktPnNpbl9hZGRyOworCQkJfQorCQl9IGVsc2UgaWYgKGZhZGRy LnNfYWRkciA9PSAodV9sb25nKUlOQUREUl9CUk9BRENBU1QgJiYKIAkJICAgIChUQUlMUV9GSVJT VCgmaW5faWZhZGRyaGVhZCktPmlhX2lmcC0+aWZfZmxhZ3MgJgogCQkgICAgSUZGX0JST0FEQ0FT VCkpCiAJCQlmYWRkciA9IHNhdG9zaW4oJlRBSUxRX0ZJUlNUKApAQCAtODc2LDExICs4ODMsMTIg QEAKICAqIExvb2t1cCBhIFBDQiBiYXNlZCBvbiB0aGUgbG9jYWwgYWRkcmVzcyBhbmQgcG9ydC4K ICAqLwogc3RydWN0IGlucGNiICoKLWluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwg bHBvcnRfYXJnLCB3aWxkX29rYXkpCitpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIs IGxwb3J0X2FyZywgd2lsZF9va2F5LCB0ZCkKIAlzdHJ1Y3QgaW5wY2JpbmZvICpwY2JpbmZvOwog CXN0cnVjdCBpbl9hZGRyIGxhZGRyOwogCXVfaW50IGxwb3J0X2FyZzsKIAlpbnQgd2lsZF9va2F5 OworCXN0cnVjdCB0aHJlYWQgKnRkOwogewogCXJlZ2lzdGVyIHN0cnVjdCBpbnBjYiAqaW5wOwog CWludCBtYXRjaHdpbGQgPSAzLCB3aWxkY2FyZDsKQEAgLTkwMCwxMSArOTA4LDE4IEBACiAjZW5k aWYKIAkJCWlmIChpbnAtPmlucF9mYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAmJgogCQkJICAg IGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBsYWRkci5zX2FkZHIgJiYKLQkJCSAgICBpbnAtPmlu cF9scG9ydCA9PSBscG9ydCkgeworCQkJICAgIGlucC0+aW5wX2xwb3J0ID09IGxwb3J0ICYmIAor CQkJICAgIChsYWRkci5zX2FkZHIgIT0gSU5BRERSX0FOWSB8fCAhdGQtPnRkX3VjcmVkLT5jcl9w cmlzb24pKSB7CiAJCQkJLyoKIAkJCQkgKiBGb3VuZC4KIAkJCQkgKi8KIAkJCQlyZXR1cm4gKGlu cCk7CisJCQl9IGVsc2UgaWYgKHRkLT50ZF91Y3JlZC0+Y3JfcHJpc29uICYmCisJCQkgICAgdGQt PnRkX3VjcmVkLT5jcl9wcmlzb24gPT0gaW5wLT5pbnBfc29ja2V0LT5zb19jcmVkLT5jcl9wcmlz b24gJiYKKwkJCSAgICBpbnAtPmlucF9mYWRkci5zX2FkZHIgPT0gSU5BRERSX0FOWSAmJgorCQkJ ICAgIGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBsYWRkci5zX2FkZHIgJiYKKwkJCSAgICBpbnAt PmlucF9scG9ydCA9PSBscG9ydCkgeworCQkJCXJldHVybiAoaW5wKTsKIAkJCX0KIAkJfQogCQkv KgpAQCAtMTAwNSwxMiArMTAyMCwyNCBAQAogCiAJCWhlYWQgPSAmcGNiaW5mby0+aGFzaGJhc2Vb SU5QX1BDQkhBU0goSU5BRERSX0FOWSwgbHBvcnQsIDAsIHBjYmluZm8tPmhhc2htYXNrKV07CiAJ CUxJU1RfRk9SRUFDSChpbnAsIGhlYWQsIGlucF9oYXNoKSB7CisJCQlpZiAoaW5wLT5pbnBfc29j a2V0LT5zb19jcmVkLT5jcl9wcmlzb24gJiYKKwkJCSAgICBpbnAtPmlucF9scG9ydCA9PSBscG9y dCAmJgorCQkJICAgIGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZKSB7CisJCQkJ aWYgKHByaXNvbl9jaGVja19pcChpbnAtPmlucF9zb2NrZXQtPnNvX2NyZWQtPmNyX3ByaXNvbiwg bnRvaGwobGFkZHIuc19hZGRyKSkpIHsKKwkJCQkJcmV0dXJuIChpbnApOworCQkJCX0KKwkJCX0K KwkJfQorCisJCWhlYWQgPSAmcGNiaW5mby0+aGFzaGJhc2VbSU5QX1BDQkhBU0goSU5BRERSX0FO WSwgbHBvcnQsIDAsIHBjYmluZm8tPmhhc2htYXNrKV07CisJCUxJU1RfRk9SRUFDSChpbnAsIGhl YWQsIGlucF9oYXNoKSB7CiAjaWZkZWYgSU5FVDYKIAkJCWlmICgoaW5wLT5pbnBfdmZsYWcgJiBJ TlBfSVBWNCkgPT0gMCkKIAkJCQljb250aW51ZTsKICNlbmRpZgogCQkJaWYgKGlucC0+aW5wX2Zh ZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZICYmCi0JCQkgICAgaW5wLT5pbnBfbHBvcnQgPT0gbHBv cnQpIHsKKwkJCSAgICBpbnAtPmlucF9scG9ydCA9PSBscG9ydCAmJgorCQkJICAgICFpbnAtPmlu cF9zb2NrZXQtPnNvX2NyZWQtPmNyX3ByaXNvbikgewogCQkJCWlmIChpZnAgJiYgaWZwLT5pZl90 eXBlID09IElGVF9GQUlUSCAmJgogCQkJCSAgICAoaW5wLT5pbnBfZmxhZ3MgJiBJTlBfRkFJVEgp ID09IDApCiAJCQkJCWNvbnRpbnVlOwpAQCAtMTAxOSwxMSArMTA0NiwxNCBAQAogCQkJCWVsc2Ug aWYgKGlucC0+aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZKSB7CiAjaWYgZGVmaW5lZChJ TkVUNikKIAkJCQkJaWYgKElOUF9DSEVDS19TT0NLQUYoaW5wLT5pbnBfc29ja2V0LAotCQkJCQkJ CSAgICAgQUZfSU5FVDYpKQorCQkJCQkJCSAgICAgQUZfSU5FVDYpKSB7CiAJCQkJCQlsb2NhbF93 aWxkX21hcHBlZCA9IGlucDsKLQkJCQkJZWxzZQorCQkJCQl9IGVsc2UgeworI2VuZGlmIC8qIGRl ZmluZWQoSU5FVDYpICovCisJCQkJCQlsb2NhbF93aWxkID0gaW5wOworI2lmIGRlZmluZWQoSU5F VDYpCisJCQkJCX0KICNlbmRpZiAvKiBkZWZpbmVkKElORVQ2KSAqLwotCQkJCQlsb2NhbF93aWxk ID0gaW5wOwogCQkJCX0KIAkJCX0KIAkJfQpAQCAtMTE0NSw3ICsxMTc1LDcgQEAKIHsKIAlpZiAo IWphaWxlZCh0ZC0+dGRfdWNyZWQpKQogCQlyZXR1cm4gKDApOwotCWlmIChudG9obChpbnAtPmlu cF9sYWRkci5zX2FkZHIpID09IHByaXNvbl9nZXRpcCh0ZC0+dGRfdWNyZWQpKQorCWlmIChwcmlz b25fY2hlY2tfaXAodGQtPnRkX3VjcmVkLT5jcl9wcmlzb24sIG50b2hsKGlucC0+aW5wX2xhZGRy LnNfYWRkcikpKQogCQlyZXR1cm4gKDApOwogCXJldHVybiAoMSk7CiB9CmRpZmYgLXVyIHNyYy52 aXJnaW4vc3lzL25ldGluZXQvaW5fcGNiLmggc3JjLmRpcnR5L3N5cy9uZXRpbmV0L2luX3BjYi5o Ci0tLSBzcmMudmlyZ2luL3N5cy9uZXRpbmV0L2luX3BjYi5oCVR1ZSBOb3YgMTIgMTM6NDQ6Mzgg MjAwMgorKysgc3JjLmRpcnR5L3N5cy9uZXRpbmV0L2luX3BjYi5oCVRodSBGZWIgMjcgMTc6Mzg6 MzMgMjAwMwpAQCAtMzM5LDcgKzMzOSw3IEBACiBpbnQJaW5fcGNiaW5zaGFzaChzdHJ1Y3QgaW5w Y2IgKik7CiBzdHJ1Y3QgaW5wY2IgKgogCWluX3BjYmxvb2t1cF9sb2NhbChzdHJ1Y3QgaW5wY2Jp bmZvICosCi0JICAgIHN0cnVjdCBpbl9hZGRyLCB1X2ludCwgaW50KTsKKwkgICAgc3RydWN0IGlu X2FkZHIsIHVfaW50LCBpbnQsIHN0cnVjdCB0aHJlYWQgKik7CiBzdHJ1Y3QgaW5wY2IgKgogCWlu X3BjYmxvb2t1cF9oYXNoKHN0cnVjdCBpbnBjYmluZm8gKiwgc3RydWN0IGluX2FkZHIsIHVfaW50 LAogCSAgICBzdHJ1Y3QgaW5fYWRkciwgdV9pbnQsIGludCwgc3RydWN0IGlmbmV0ICopOwpkaWZm IC11ciBzcmMudmlyZ2luL3N5cy9uZXRpbmV0L2lwX2Z3LmMgc3JjLmRpcnR5L3N5cy9uZXRpbmV0 L2lwX2Z3LmMKLS0tIHNyYy52aXJnaW4vc3lzL25ldGluZXQvaXBfZncuYwlTYXQgSnVuIDIyIDA1 OjUxOjAyIDIwMDIKKysrIHNyYy5kaXJ0eS9zeXMvbmV0aW5ldC9pcF9mdy5jCVNhdCBNYXIgMjIg MTM6MzY6MDkgMjAwMwpAQCAtNjQsNiArNjQsOCBAQAogCiAjaW5jbHVkZSA8bmV0aW5ldC9pZl9l dGhlci5oPiAvKiBYWFggZXRoZXJ0eXBlX2lwICovCiAKKyNpbmNsdWRlIDxzeXMvamFpbC5oPgor CiBzdGF0aWMgaW50IGZ3X2RlYnVnID0gMTsKICNpZmRlZiBJUEZJUkVXQUxMX1ZFUkJPU0UKIHN0 YXRpYyBpbnQgZndfdmVyYm9zZSA9IDE7CkBAIC0yMDEwLDYgKzIwMTIsMTEgQEAKIAl9CiAKIAll cnJvciA9IDA7CisKKwkvKiBJZiBhbGxvd19pcGZ3IGlzIG5vdCBlbmFibGVkLCByZXR1cm4gYW4g ZXJyb3IuICovCisJaWYgKHNvcHQtPnNvcHRfdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24gJiYgIXNv cHQtPnNvcHRfdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24tPmphaWxfc2V0dGluZ3MuYWxsb3dfaXBm dykgeworCQlyZXR1cm4gRVBFUk07CisJfQogCiAJc3dpdGNoIChzb3B0LT5zb3B0X25hbWUpIHsK IAljYXNlIElQX0ZXX0dFVDoKZGlmZiAtdXIgc3JjLnZpcmdpbi9zeXMvbmV0aW5ldC9pcF9mdzIu YyBzcmMuZGlydHkvc3lzL25ldGluZXQvaXBfZncyLmMKLS0tIHNyYy52aXJnaW4vc3lzL25ldGlu ZXQvaXBfZncyLmMJU3VuIERlYyAxNSAwNjo1Nzo0MyAyMDAyCisrKyBzcmMuZGlydHkvc3lzL25l dGluZXQvaXBfZncyLmMJU3VuIE1hciAyMyAxMDowNTozNyAyMDAzCkBAIC03Nyw2ICs3Nyw4IEBA CiAKICNpbmNsdWRlIDxtYWNoaW5lL2luX2Nrc3VtLmg+CS8qIFhYWCBmb3IgaW5fY2tzdW0gKi8K IAorI2luY2x1ZGUgPHN5cy9qYWlsLmg+CisKIC8qCiAgKiBYWFggVGhpcyBvbmUgc2hvdWxkIGdv IGluIHN5cy9tYnVmLmguIEl0IGlzIHVzZWQgdG8gYXZvaWQgdGhhdAogICogYSBmaXJld2FsbC1n ZW5lcmF0ZWQgcGFja2V0IGxvb3BzIGZvcmV2ZXIgdGhyb3VnaCB0aGUgZmlyZXdhbGwuCkBAIC0y NDQwLDYgKzI0NDIsMzQgQEAKIAlyZXR1cm4gRUlOVkFMOwogfQogCitzdGF0aWMgaW50CitjaGVj a19pcGZ3X2phaWwoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBpcF9mdyAqcnVsZSkKK3sKKwlp cGZ3X2luc25faXAgKmlwX2NtZDsKKwlpcGZ3X2luc24gKmNtZDsKKworCS8qIEphaWxlZD8gKi8K KwlpZiAoIXRkLT50ZF91Y3JlZC0+Y3JfcHJpc29uKSB7CisJCXJldHVybiAwOworCX0KKworCS8q IERlZmF1bHQgcnVsZT8gKi8KKwlpZiAocnVsZS0+cnVsZW51bSA9PSBJUEZXX0RFRkFVTFRfUlVM RSkgeworCQlyZXR1cm4gMDsKKwl9CisKKwkvKiBDaGVjayBhbGwgSVAgYWRkcmVzc2VzIGluIG9w Y29kZSBsaXN0LiAqLworCWZvciAoY21kID0gcnVsZS0+Y21kOyBjbWQgIT0gQUNUSU9OX1BUUihy dWxlKTsgY21kKyspIHsKKwkJaWYgKGNtZC0+b3Bjb2RlID09IE9fSVBfRFNUIHx8IGNtZC0+b3Bj b2RlID09IE9fSVBfU1JDKSB7CisJCQlpcF9jbWQgPSAoaXBmd19pbnNuX2lwKikoY21kKTsKKwkJ CWlmIChwcmlzb25fY2hlY2tfaXAodGQtPnRkX3VjcmVkLT5jcl9wcmlzb24sIGh0b25sKGlwX2Nt ZC0+YWRkci5zX2FkZHIpKSkgeworCQkJCXJldHVybiAwOworCQkJfQorCQl9CisJfQorCisJcmV0 dXJuIEVQRVJNOworfQogCiAvKioKICAqIHtzZXR8Z2V0fXNvY2tvcHQgcGFyc2VyLgpAQCAtMjQ3 MSw2ICsyNTAxLDExIEBACiAKIAllcnJvciA9IDA7CiAKKyAgICAgICAgLyogSWYgYWxsb3dfaXBm dyBpcyBub3QgZW5hYmxlZCwgcmV0dXJuIGFuIGVycm9yLiAqLworCWlmIChzb3B0LT5zb3B0X3Rk LT50ZF91Y3JlZC0+Y3JfcHJpc29uICYmICFzb3B0LT5zb3B0X3RkLT50ZF91Y3JlZC0+Y3JfcHJp c29uLT5qYWlsX3NldHRpbmdzLmFsbG93X2lwZncpIHsKKwkJcmV0dXJuIEVQRVJNOworCX0KKwog CXN3aXRjaCAoc29wdC0+c29wdF9uYW1lKSB7CiAJY2FzZSBJUF9GV19HRVQ6CiAJCS8qCkBAIC0y NDk4LDEwICsyNTMzLDEyIEBACiAKIAkJYnAgPSBidWY7CiAJCWZvciAocnVsZSA9IGxheWVyM19j aGFpbjsgcnVsZSA7IHJ1bGUgPSBydWxlLT5uZXh0KSB7Ci0JCQlpbnQgaSA9IFJVTEVTSVpFKHJ1 bGUpOwotCQkJYmNvcHkocnVsZSwgYnAsIGkpOwotCQkJKChzdHJ1Y3QgaXBfZncgKilicCktPnNl dF9kaXNhYmxlID0gc2V0X2Rpc2FibGU7Ci0JCQlicCA9IChzdHJ1Y3QgaXBfZncgKikoKGNoYXIg KilicCArIGkpOworCQkJaWYgKCFjaGVja19pcGZ3X2phaWwoc29wdC0+c29wdF90ZCwgcnVsZSkp IHsKKwkJCQlpbnQgaSA9IFJVTEVTSVpFKHJ1bGUpOworCQkJCWJjb3B5KHJ1bGUsIGJwLCBpKTsK KwkJCQkoKHN0cnVjdCBpcF9mdyAqKWJwKS0+c2V0X2Rpc2FibGUgPSBzZXRfZGlzYWJsZTsKKwkJ CQlicCA9IChzdHJ1Y3QgaXBfZncgKikoKGNoYXIgKilicCArIGkpOworCQkJfQogCQl9CiAJCWlm IChpcGZ3X2R5bl92KSB7CiAJCQlpbnQgaTsKQEAgLTI1NDcsNyArMjU4NCwxMCBAQAogCQkgKiB0 aGUgbGlzdCB0byBwb2ludCB0byB0aGUgZGVmYXVsdCBydWxlLCBhbmQgdGhlbiBmcmVlaW5nCiAJ CSAqIHRoZSBvbGQgbGlzdCB3aXRob3V0IHRoZSBuZWVkIGZvciBhIGxvY2suCiAJCSAqLwotCisJ CWlmIChzb3B0LT5zb3B0X3RkLT50ZF91Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQllcnJvciA9IEVQ RVJNOworCQkJYnJlYWs7CisJCX0KIAkJcyA9IHNwbGltcCgpOwogCQlmcmVlX2NoYWluKCZsYXll cjNfY2hhaW4sIDAgLyoga2VlcCBkZWZhdWx0IHJ1bGUgKi8pOwogCQlzcGx4KHMpOwpAQCAtMjU2 MSw2ICsyNjAxLDEwIEBACiAJCWlmIChlcnJvciB8fCAoZXJyb3IgPSBjaGVja19pcGZ3X3N0cnVj dChydWxlLCBzaXplKSkpCiAJCQlicmVhazsKIAorCQkvKiBDaGVjayBhbmQgbWFrZSBzdXJlIElQ IGFkZHJlc3NlcyBhcmUgdmFsaWQgKGlmIGphaWxlZCkuICovCisJCWVycm9yID0gY2hlY2tfaXBm d19qYWlsKHNvcHQtPnNvcHRfdGQsIHJ1bGUpOworCQlpZiAoZXJyb3IpIGJyZWFrOworCiAJCWVy cm9yID0gYWRkX3J1bGUoJmxheWVyM19jaGFpbiwgcnVsZSk7CiAJCXNpemUgPSBSVUxFU0laRShy dWxlKTsKIAkJaWYgKCFlcnJvciAmJiBzb3B0LT5zb3B0X2RpciA9PSBTT1BUX0dFVCkKQEAgLTI1 ODQsNiArMjYyOCw5IEBACiAJCQkyKnNpemVvZih1X2ludDMyX3QpLCBzaXplb2YodV9pbnQzMl90 KSk7CiAJCWlmIChlcnJvcikKIAkJCWJyZWFrOworCQllcnJvciA9IGNoZWNrX2lwZndfamFpbChz b3B0LT5zb3B0X3RkLCAoc3RydWN0IGlwX2Z3KilydWxlX2J1Zik7CisJCWlmIChlcnJvcikKKwkJ CWJyZWFrOwogCQlzaXplID0gc29wdC0+c29wdF92YWxzaXplOwogCQlpZiAoc2l6ZSA9PSBzaXpl b2YodV9pbnQzMl90KSkJLyogZGVsZXRlIG9yIHJlYXNzaWduICovCiAJCQllcnJvciA9IGRlbF9l bnRyeSgmbGF5ZXIzX2NoYWluLCBydWxlX2J1ZlswXSk7CkBAIC0yNjA1LDcgKzI2NTIsMjIgQEAK IAkJICAgIGlmIChlcnJvcikKIAkJCWJyZWFrOwogCQl9Ci0JCWVycm9yID0gemVyb19lbnRyeShy dWxlbnVtLCBzb3B0LT5zb3B0X25hbWUgPT0gSVBfRldfUkVTRVRMT0cpOworCisJCWlmIChzb3B0 LT5zb3B0X3RkLT50ZF91Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQkvKiBXZSBoYXZlIHRvIGRvIHRo aXMgc2xpZ2h0bHkgZGlmZmVyZW50bHkuIHJ1bGVudW0gY2FuJ3QgYmUKKwkJCSAgIGEgcnVsZSB0 aGF0J3Mgb3V0c2lkZSB0aGUgamFpbC4gKi8KKwkJCWZvciAocnVsZSA9IGxheWVyM19jaGFpbjsg cnVsZSA7IHJ1bGUgPSBydWxlLT5uZXh0KSB7CisJCQkJaWYgKHJ1bGUtPnJ1bGVudW0gPT0gcnVs ZW51bSB8fCBydWxlbnVtID09IDApIHsKKwkJCQkJaWYgKCFjaGVja19pcGZ3X2phaWwoc29wdC0+ c29wdF90ZCwgcnVsZSkpIHsKKwkJCQkJCXplcm9fZW50cnkocnVsZS0+cnVsZW51bSwgc29wdC0+ c29wdF9uYW1lID09IElQX0ZXX1JFU0VUTE9HKTsKKwkJCQkJfSBlbHNlIHsKKwkJCQkJCWNvbnRp bnVlOworCQkJCQl9CisJCQkJfQorCQkJfQorCQl9IGVsc2UgeworCQkJZXJyb3IgPSB6ZXJvX2Vu dHJ5KHJ1bGVudW0sIHNvcHQtPnNvcHRfbmFtZSA9PSBJUF9GV19SRVNFVExPRyk7CisJCX0KIAkJ YnJlYWs7CiAKIAlkZWZhdWx0OgpkaWZmIC11ciBzcmMudmlyZ2luL3N5cy9uZXRpbmV0L3Jhd19p cC5jIHNyYy5kaXJ0eS9zeXMvbmV0aW5ldC9yYXdfaXAuYwotLS0gc3JjLnZpcmdpbi9zeXMvbmV0 aW5ldC9yYXdfaXAuYwlXZWQgTm92IDIwIDEyOjAwOjU0IDIwMDIKKysrIHNyYy5kaXJ0eS9zeXMv bmV0aW5ldC9yYXdfaXAuYwlTYXQgTWFyIDIyIDEyOjE5OjQ2IDIwMDMKQEAgLTc4LDYgKzc4LDgg QEAKICNpbmNsdWRlIDxuZXRpbmV0Ni9pcHNlYy5oPgogI2VuZGlmIC8qSVBTRUMqLwogCisjaW5j bHVkZSA8c3lzL2phaWwuaD4KKwogc3RydWN0CWlucGNiaGVhZCByaXBjYjsKIHN0cnVjdAlpbnBj YmluZm8gcmlwY2JpbmZvOwogCkBAIC01MjgsMTIgKzUzMCwyMCBAQAogewogCXN0cnVjdCBpbnBj YiAqaW5wOwogCWludCBlcnJvciwgczsKKwlzdHJ1Y3QgcHJpc29uICpzYXZlZCA9IE5VTEw7CiAK IAlpbnAgPSBzb3RvaW5wY2Ioc28pOwogCWlmIChpbnApCiAJCXBhbmljKCJyaXBfYXR0YWNoIik7 Ci0JaWYgKHRkICYmIChlcnJvciA9IHN1c2VyKHRkKSkgIT0gMCkKKwlpZiAodGQgJiYgdGQtPnRk X3VjcmVkLT5jcl9wcmlzb24gJiYgdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24tPmphaWxfc2V0dGlu Z3MuYWxsb3dfcmF3X3NvY2tldHMpIHsKKwkJc2F2ZWQgPSB0ZC0+dGRfdWNyZWQtPmNyX3ByaXNv bjsKKwkJdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24gPSBOVUxMOworCX0KKwlpZiAodGQgJiYgKGVy cm9yID0gc3VzZXIodGQpKSAhPSAwKSB7CisJCXRkLT50ZF91Y3JlZC0+Y3JfcHJpc29uID0gc2F2 ZWQ7CiAJCXJldHVybiBlcnJvcjsKKwl9CisJdGQtPnRkX3VjcmVkLT5jcl9wcmlzb24gPSBzYXZl ZDsKIAogCWlmIChwcm90byA+PSBJUFBST1RPX01BWCB8fCBwcm90byA8IDApCiAJCXJldHVybiBF UFJPVE9OT1NVUFBPUlQ7CmRpZmYgLXVyIHNyYy52aXJnaW4vc3lzL25ldGluZXQ2L2luNl9wY2Iu YyBzcmMuZGlydHkvc3lzL25ldGluZXQ2L2luNl9wY2IuYwotLS0gc3JjLnZpcmdpbi9zeXMvbmV0 aW5ldDYvaW42X3BjYi5jCVR1ZSBPY3QgMTUgMjA6MjU6MDUgMjAwMgorKysgc3JjLmRpcnR5L3N5 cy9uZXRpbmV0Ni9pbjZfcGNiLmMJVGh1IEZlYiAyNyAxNzozODozMyAyMDAzCkBAIC0yMTMsNyAr MjEzLDcgQEAKIAkJCQkJaW42X3NpbjZfMl9zaW4oJnNpbiwgc2luNik7CiAJCQkJCXQgPSBpbl9w Y2Jsb29rdXBfbG9jYWwocGNiaW5mbywKIAkJCQkJCXNpbi5zaW5fYWRkciwgbHBvcnQsCi0JCQkJ CQlJTlBMT09LVVBfV0lMRENBUkQpOworCQkJCQkJSU5QTE9PS1VQX1dJTERDQVJELCBOVUxMKTsK IAkJCQkJaWYgKHQgJiYKIAkJCQkJICAgIChzby0+c29fY3JlZC0+Y3JfdWlkICE9CiAJCQkJCSAg ICAgdC0+aW5wX3NvY2tldC0+c29fY3JlZC0+Y3JfdWlkKSAmJgpAQCAtMjM0LDcgKzIzNCw3IEBA CiAKIAkJCQlpbjZfc2luNl8yX3Npbigmc2luLCBzaW42KTsKIAkJCQl0ID0gaW5fcGNibG9va3Vw X2xvY2FsKHBjYmluZm8sIHNpbi5zaW5fYWRkciwKLQkJCQkJCSAgICAgICBscG9ydCwgd2lsZCk7 CisJCQkJCQkgICAgICAgbHBvcnQsIHdpbGQsIHdpbGQgPyBOVUxMIDogdGQpOwogCQkJCWlmICh0 ICYmCiAJCQkJICAgIChyZXVzZXBvcnQgJiB0LT5pbnBfc29ja2V0LT5zb19vcHRpb25zKQogCQkJ CSAgICA9PSAwICYmCmRpZmYgLXVyIHNyYy52aXJnaW4vc3lzL3N5cy9pcGMuaCBzcmMuZGlydHkv c3lzL3N5cy9pcGMuaAotLS0gc3JjLnZpcmdpbi9zeXMvc3lzL2lwYy5oCU1vbiBPY3QgMTQgMTQ6 NTA6NDEgMjAwMgorKysgc3JjLmRpcnR5L3N5cy9zeXMvaXBjLmgJVGh1IEZlYiAyNyAxNzozODoz MyAyMDAzCkBAIC04NCw2ICs4NCw3IEBACiAJdXNob3J0CW1vZGU7CS8qIHIvdyBwZXJtaXNzaW9u ICovCiAJdXNob3J0CXNlcTsJLyogc2VxdWVuY2UgIyAodG8gZ2VuZXJhdGUgdW5pcXVlIG1zZy9z ZW0vc2htIGlkKSAqLwogCWtleV90CWtleTsJLyogdXNlciBzcGVjaWZpZWQgbXNnL3NlbS9zaG0g a2V5ICovCisJc3RydWN0IHByaXNvbiAqcHI7CS8qIEZvciBqYWlsIGNvbnRyb2wuICovCiB9Owog CiAjaWYgX19CU0RfVklTSUJMRQpkaWZmIC11ciBzcmMudmlyZ2luL3N5cy9zeXMvamFpbC5oIHNy Yy5kaXJ0eS9zeXMvc3lzL2phaWwuaAotLS0gc3JjLnZpcmdpbi9zeXMvc3lzL2phaWwuaAlTdW4g TWF5ICA1IDIxOjEzOjA4IDIwMDIKKysrIHNyYy5kaXJ0eS9zeXMvc3lzL2phaWwuaAlTYXQgTWFy IDIyIDEzOjM0OjEyIDIwMDMKQEAgLTE3LDcgKzE3LDggQEAKIAl1X2ludDMyX3QJdmVyc2lvbjsK IAljaGFyCQkqcGF0aDsKIAljaGFyCQkqaG9zdG5hbWU7Ci0JdV9pbnQzMl90CWlwX251bWJlcjsK Kwl1X2ludDMyX3QJKmlwczsKKwl1X2ludAkJbmlwczsKIH07CiAKICNpZm5kZWYgX0tFUk5FTApA QCAtMjksNiArMzAsOSBAQAogI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgogI2luY2x1ZGUgPHN5cy9f bG9jay5oPgogI2luY2x1ZGUgPHN5cy9fbXV0ZXguaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+ CisKK3N0cnVjdCB2bm9kZTsKIAogI2lmZGVmIE1BTExPQ19ERUNMQVJFCiBNQUxMT0NfREVDTEFS RShNX1BSSVNPTik7CkBAIC00OCwxMCArNTIsMjYgQEAKIHN0cnVjdCBwcmlzb24gewogCWludAkJ IHByX3JlZjsJCQkvKiAocCkgcmVmY291bnQgKi8KIAljaGFyIAkJIHByX2hvc3RbTUFYSE9TVE5B TUVMRU5dOwkvKiAocCkgamFpbCBob3N0bmFtZSAqLwotCXVfaW50MzJfdAkgcHJfaXA7CQkJCS8q IChjKSBpcCBhZGRyIGhvc3QgKi8KKwl1X2ludDMyX3QJICpwcl9pcHM7CQkJLyogKGMpIGlwIGFk ZHIgaG9zdCAqLworCXVfaW50CQlwcl9uaXBzOwogCXZvaWQJCSpwcl9saW51eDsJCQkvKiAocCkg bGludXggYWJpICovCiAJaW50CQkgcHJfc2VjdXJlbGV2ZWw7CQkvKiAocCkgc2VjdXJlbGV2ZWwg Ki8KIAlzdHJ1Y3QgbXR4CSBwcl9tdHg7CisJdV9pbnQJCXByX251bXByb2NzOworCXN0cnVjdCB7 CisJCXVfaW50IG1heF9yYW07CisJCXVfaW50IG1heF9jcHU7CisJCXVfaW50IG1heF9wcm9jczsK KwkJdV9pbnQgcmFtX3VzZWQ7CisJCXVfaW50IHByb2NzX3VzZWQ7CisJCXVfaW50IGNwdV91c2Vk OworCQl1X2ludCBhbGxvd19yYXdfc29ja2V0czsKKwkJdV9pbnQgYWxsb3dfaXBmdzsKKwl9IGph aWxfc2V0dGluZ3M7CisJY2hhciBwcl9ob3N0X29pZFtNQVhIT1NUTkFNRUxFTl07CisJc3RydWN0 IHN5c2N0bF9jdHhfbGlzdCBqZF9zeXNjdGx0cmVlOworCXN0cnVjdCBzeXNjdGxfb2lkICpqZF9z eXNjdGx0cmVldG9wOworCWludCByZXNjaGVkOwogfTsKIAogLyoKQEAgLTY0LDYgKzg0LDE3IEBA CiBleHRlcm4gaW50CWphaWxfc3lzdmlwY19hbGxvd2VkOwogCiAvKgorICogTGlzdCBvZiBqYWls cyAoZm9yIGphaWxfYXR0YWNoKCksIGV0LiBhbC4pCisgKi8KK3N0cnVjdCBqYWlsZWxlbWVudCB7 CisJc3RydWN0IHByaXNvbiAqcHI7CQkJCS8qIFByaXNvbiBlbGVtZW50ICovCisJY2hhciAqY2hy b290X3BhdGg7CQkJCS8qIFBhdGggdG8gY2hyb290IHRvLiAqLworCUxJU1RfRU5UUlkoamFpbGVs ZW1lbnQpIHBvaW50ZXJzOworfTsKKworTElTVF9IRUFEKGphaWxzLCBqYWlsZWxlbWVudCk7CisK Ky8qCiAgKiBLZXJuZWwgc3VwcG9ydCBmdW5jdGlvbnMgZm9yIGphaWwoKS4KICAqLwogc3RydWN0 IHVjcmVkOwpAQCAtNzcsNiArMTA4LDEyIEBACiBpbnQgcHJpc29uX2lmKHN0cnVjdCB1Y3JlZCAq Y3JlZCwgc3RydWN0IHNvY2thZGRyICpzYSk7CiBpbnQgcHJpc29uX2lwKHN0cnVjdCB1Y3JlZCAq Y3JlZCwgaW50IGZsYWcsIHVfaW50MzJfdCAqaXApOwogdm9pZCBwcmlzb25fcmVtb3RlX2lwKHN0 cnVjdCB1Y3JlZCAqY3JlZCwgaW50IGZsYWdzLCB1X2ludDMyX3QgKmlwKTsKK2ludCBwcmlzb25f Y2hlY2tfaXAoc3RydWN0IHByaXNvbiAqcHIsIHVfaW50MzJfdCBpcCk7CitpbnQgamFpbF9jYWxj dG90YWx1c2VkKHN0cnVjdCBwcmlzb24gKnByKTsKK2ludCBqYWlsX2NoZWNrX3Jlc291cmNlcyhz dHJ1Y3QgdGhyZWFkICp0ZCk7CitpbnQgamFpbF9jaGVja19jcHUoc3RydWN0IHVjcmVkICp1Yyk7 Cit2b2lkIGphaWxfdXBkYXRlX2NwdSh2b2lkKTsKK2ludCBqYWlsX2NoZWNrX2ZpbGVwZXJtKHN0 cnVjdCB2bm9kZSAqdnAsIHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IHRocmVhZCAqdGQpOwog CiAjZW5kaWYgLyogIV9LRVJORUwgKi8KICNlbmRpZiAvKiAhX1NZU19KQUlMX0hfICovCmRpZmYg LXVyIHNyYy52aXJnaW4vc3lzL3N5cy9wcm9jLmggc3JjLmRpcnR5L3N5cy9zeXMvcHJvYy5oCi0t LSBzcmMudmlyZ2luL3N5cy9zeXMvcHJvYy5oCU1vbiBEZWMgIDkgMTk6MzM6NDUgMjAwMgorKysg c3JjLmRpcnR5L3N5cy9zeXMvcHJvYy5oCVRodSBGZWIgMjcgMTc6Mzg6MzMgMjAwMwpAQCAtMzQ3 LDYgKzM0Nyw3IEBACiAjZGVmaW5lCVRESV9MT0NLCTB4MDgJLyogU3RvcHBlZCBvbiBhIGxvY2su ICovCiAjZGVmaW5lCVRESV9JV0FJVAkweDEwCS8qIEF3YWl0aW5nIGludGVycnVwdC4gKi8KICNk ZWZpbmUJVERJX0xPQU4JMHgyMAkvKiBib3VuZCB0aHJlYWQncyBLU0UgaXMgbGVudCAqLworI2Rl ZmluZSBURElfSlNMRUVQCTB4NDAJLyogSmFpbCBzdXNwZW5zaW9uIGR1ZSB0byBoaWdoIENQVS4g Ki8KIAogI2RlZmluZQlURF9JU19TTEVFUElORyh0ZCkJKCh0ZCktPnRkX2luaGliaXRvcnMgJiBU RElfU0xFRVBJTkcpCiAjZGVmaW5lCVREX09OX1NMRUVQUSh0ZCkJKCh0ZCktPnRkX3djaGFuICE9 IE5VTEwpCkBAIC0zNTUsNiArMzU2LDcgQEAKICNkZWZpbmUJVERfT05fTE9DSyh0ZCkJCSgodGQp LT50ZF9pbmhpYml0b3JzICYgVERJX0xPQ0spCiAjZGVmaW5lCVREX0xFTlQodGQpCQkoKHRkKS0+ dGRfaW5oaWJpdG9ycyAmIFRESV9MT0FOKQogI2RlZmluZQlURF9BV0FJVElOR19JTlRSKHRkKQko KHRkKS0+dGRfaW5oaWJpdG9ycyAmIFRESV9JV0FJVCkKKyNkZWZpbmUgVERfSVNfSlNMRUVQKHRk KQkoKHRkKS0+dGRfaW5oaWJpdG9ycyAmIFRESV9KU0xFRVApCiAjZGVmaW5lCVREX0lTX1JVTk5J TkcodGQpCSgodGQpLT50ZF9zdGF0ZSA9PSBURFNfUlVOTklORykKICNkZWZpbmUJVERfT05fUlVO USh0ZCkJCSgodGQpLT50ZF9zdGF0ZSA9PSBURFNfUlVOUSkKICNkZWZpbmUJVERfQ0FOX1JVTih0 ZCkJCSgodGQpLT50ZF9zdGF0ZSA9PSBURFNfQ0FOX1JVTikKQEAgLTM3Nyw2ICszNzksNyBAQAog I2RlZmluZQlURF9TRVRfU1VTUEVOREVEKHRkKQlURF9TRVRfSU5ISUIoKHRkKSwgVERJX1NVU1BF TkRFRCkKICNkZWZpbmUJVERfU0VUX0lXQUlUKHRkKQlURF9TRVRfSU5ISUIoKHRkKSwgVERJX0lX QUlUKQogI2RlZmluZQlURF9TRVRfTE9BTih0ZCkJCVREX1NFVF9JTkhJQigodGQpLCBURElfTE9B TikKKyNkZWZpbmUgVERfU0VUX0pTTEVFUCh0ZCkJVERfU0VUX0lOSElCKCh0ZCksIFRESV9KU0xF RVApCiAKICNkZWZpbmUJVERfQ0xSX1NMRUVQSU5HKHRkKQlURF9DTFJfSU5ISUIoKHRkKSwgVERJ X1NMRUVQSU5HKQogI2RlZmluZQlURF9DTFJfU1dBUFBFRCh0ZCkJVERfQ0xSX0lOSElCKCh0ZCks IFRESV9TV0FQUEVEKQpAQCAtMzg0LDYgKzM4Nyw3IEBACiAjZGVmaW5lCVREX0NMUl9TVVNQRU5E RUQodGQpCVREX0NMUl9JTkhJQigodGQpLCBURElfU1VTUEVOREVEKQogI2RlZmluZQlURF9DTFJf SVdBSVQodGQpCVREX0NMUl9JTkhJQigodGQpLCBURElfSVdBSVQpCiAjZGVmaW5lCVREX0NMUl9M T0FOKHRkKQkJVERfQ0xSX0lOSElCKCh0ZCksIFRESV9MT0FOKQorI2RlZmluZSBURF9DTFJfSlNM RUVQKHRkKQlURF9DTFJfSU5ISUIoKHRkKSwgVERJX0pTTEVFUCkKIAogI2RlZmluZQlURF9TRVRf UlVOTklORyh0ZCkJZG8geyh0ZCktPnRkX3N0YXRlID0gVERTX1JVTk5JTkc7IH0gd2hpbGUgKDAp CiAjZGVmaW5lCVREX1NFVF9SVU5RKHRkKQkJZG8geyh0ZCktPnRkX3N0YXRlID0gVERTX1JVTlE7 IH0gd2hpbGUgKDApCmRpZmYgLXVyIHNyYy52aXJnaW4vc3lzL3Vmcy91ZnMvdWZzX3Zub3BzLmMg c3JjLmRpcnR5L3N5cy91ZnMvdWZzL3Vmc192bm9wcy5jCi0tLSBzcmMudmlyZ2luL3N5cy91ZnMv dWZzL3Vmc192bm9wcy5jCVN1biBPY3QgMjcgMTE6MDk6NDkgMjAwMgorKysgc3JjLmRpcnR5L3N5 cy91ZnMvdWZzL3Vmc192bm9wcy5jCU1vbiBNYXIgIDMgMDc6NTc6MTcgMjAwMwpAQCAtNjIsNiAr NjIsNyBAQAogI2luY2x1ZGUgPHN5cy9jb25mLmg+CiAjaW5jbHVkZSA8c3lzL2FjbC5oPgogI2lu Y2x1ZGUgPHN5cy9tYWMuaD4KKyNpbmNsdWRlIDxzeXMvamFpbC5oPgogCiAjaW5jbHVkZSA8bWFj aGluZS9tdXRleC5oPgogCkBAIC0zMzksNiArMzQwLDEyIEBACiAJc3RydWN0IGFjbCAqYWNsOwog CXNpemVfdCBsZW47CiAjZW5kaWYKKworCS8qIERvIHNwZWNpYWwgamFpbCBjaGVja2luZywgaWYg bmVjZXNzYXJ5LiAqLworCWVycm9yID0gamFpbF9jaGVja19maWxlcGVybSh2cCwgYXAtPmFfY3Jl ZCwgYXAtPmFfdGQpOworCWlmIChlcnJvcikgeworCQlyZXR1cm4gZXJyb3I7CisJfQogCiAJLyoK IAkgKiBEaXNhbGxvdyB3cml0ZSBhdHRlbXB0cyBvbiByZWFkLW9ubHkgZmlsZXN5c3RlbXM7CmRp ZmYgLXVyIHNyYy52aXJnaW4vdXNyLnNiaW4vamFpbC9qYWlsLmMgc3JjLmRpcnR5L3Vzci5zYmlu L2phaWwvamFpbC5jCi0tLSBzcmMudmlyZ2luL3Vzci5zYmluL2phaWwvamFpbC5jCU1vbiBBcHIg MjIgMDc6NDQ6NDMgMjAwMgorKysgc3JjLmRpcnR5L3Vzci5zYmluL2phaWwvamFpbC5jCVRodSBG ZWIgMjcgMTc6Mzg6MzMgMjAwMwpAQCAtMjYsMjggKzI2LDY4IEBACiBtYWluKGludCBhcmdjLCBj aGFyICoqYXJndikKIHsKIAlzdHJ1Y3QgamFpbCBqOwotCWludCBpOworCWludCBpLCBrLCBtLCBj ID0gMTsKIAlzdHJ1Y3QgaW5fYWRkciBpbjsKKwljaGFyICp0ZW1wc3RyaW5nLCBpcHN0cmluZ1sx Nl07CiAKLQlpZiAoYXJnYyA8IDUpIAotCQllcnJ4KDEsICJ1c2FnZTogJXMgcGF0aCBob3N0bmFt ZSBpcC1udW1iZXIgY29tbWFuZCAuLi5cbiIsCisJaWYgKGFyZ2MgPCA1KSB7CisJCWVycngoMSwg IlVzYWdlOiAlcyBwYXRoIGhvc3RuYW1lIGlwMVssaXAyWy4uLl1dIGNvbW1hbmQgLi4uXG4iLAog CQkgICAgYXJndlswXSk7CisJfQorCiAJaSA9IGNoZGlyKGFyZ3ZbMV0pOwogCWlmIChpKQogCQll cnIoMSwgImNoZGlyICVzIiwgYXJndlsxXSk7CiAJbWVtc2V0KCZqLCAwLCBzaXplb2YoaikpOwot CWoudmVyc2lvbiA9IDA7CisJai52ZXJzaW9uID0gMTsKIAlqLnBhdGggPSBhcmd2WzFdOwogCWou aG9zdG5hbWUgPSBhcmd2WzJdOwotCWkgPSBpbmV0X2F0b24oYXJndlszXSwgJmluKTsKLQlpZiAo IWkpCi0JCWVycngoMSwgIkNvdWxkbid0IG1ha2Ugc2Vuc2Ugb2YgaXAtbnVtYmVyXG4iKTsKLQlq LmlwX251bWJlciA9IG50b2hsKGluLnNfYWRkcik7CisKKwkvKiBGZWIuIDEsIDIwMDMgKE1TKTog RGV0ZXJtaW5lIGhvdyBtYW55IElQIGFkZHJlc3NlcyB1c2VyIHBhc3NlZCB0byBqYWlsLiBUaGlz CisJICAgaXMgaW1wb3J0YW50IGxhdGVyIGZvciBmaWxsaW5nIGluIGoubmlwcyBhbmQgZm9yIGFs bG9jYXRpbmcgdGhlIHByb3BlciBhbW91bnQKKwkgICBvZiBtZW1vcnkuICovCisJdGVtcHN0cmlu ZyA9IGFyZ3ZbM107CisJd2hpbGUoKnRlbXBzdHJpbmcpIHsKKwkJaWYgKCp0ZW1wc3RyaW5nID09 ICcsJykgYysrOworCQl0ZW1wc3RyaW5nKys7CisJfQorCWoubmlwcyA9IGM7CisKKwkvKiBBbGxv Y2F0ZSBSQU0sIGRlcGVuZGluZyBvbiBudW1iZXIgb2YgSVAgYWRkcmVzc2VzIHBhc3NlZC4gKi8K KwlqLmlwcyA9ICh1X2ludDMyX3QgKiltYWxsb2Moc2l6ZW9mKHVfaW50MzJfdCkgKiBjKTsKKwlp ZiAoai5pcHMgPT0gTlVMTCkgeworCQllcnJ4KDEsICJtYWxsb2MoKSBpc3N1ZSwgbGluZSA1NiAo L3Vzci9zcmMvdXNyLnNiaW4vamFpbC9qYWlsLmMpLiBQb3NzaWJsZSBsYWNrIG9mIFJBTSBvciBz b2Z0d2FyZSBidWcuIik7CisJfQorCisJLyogQ29weSBlYWNoIElQIGludG8gdGhlIGFycmF5Lgor CSAgIE5vdGUgKE1TLCAwMi8wMS8yMDAzKTogNC54IHZlcnNpb24gdXNlZCBzdHJ0b2soKSwgYSBk YW5nZXJvdXMgcHJvZ3JhbW1pbmcgY29uc3RydWN0LiAqLworCXRlbXBzdHJpbmcgPSBhcmd2WzNd OworCW0gPSAwOworCXdoaWxlICgqdGVtcHN0cmluZykgeworCQlrID0gMDsKKwkJd2hpbGUgKDEp IHsKKwkJCWlmICgqKHRlbXBzdHJpbmcraykgPT0gJywnIHx8ICoodGVtcHN0cmluZytrKSA9PSAn XDAnKSB7CisJCQkJc3RybmNweShpcHN0cmluZywgdGVtcHN0cmluZywgayk7CisJCQkJaXBzdHJp bmdba10gPSAnXDAnOworCQkJCWkgPSBpbmV0X2F0b24oaXBzdHJpbmcsICZpbik7CisJCQkJaWYg KCFpKSB7CisJCQkJCWZyZWUoai5pcHMpOworCQkJCQllcnJ4KDEsICJDb3VsZG4ndCBtYWtlIHNl bnNlIG9mIElQIGFkZHJlc3MgJXMiLCBpcHN0cmluZyk7CisJCQkJfQorCQkJCWouaXBzW20rK10g PSBudG9obChpbi5zX2FkZHIpOworCQkJCWJyZWFrOworCQkJfQorCQkJaysrOworCQl9CisJCXRl bXBzdHJpbmcgPSB0ZW1wc3RyaW5nICsgazsKKwkJaWYgKCp0ZW1wc3RyaW5nID09ICcsJykgdGVt cHN0cmluZysrOworCX0KKwkJCiAJaSA9IGphaWwoJmopOwogCWlmIChpKQotCQllcnIoMSwgIklt cHJpc29ubWVudCBmYWlsZWQiKTsKKwkJZXJyeCgxLCAiSW1wcmlzb25tZW50IGZhaWxlZCIpOwog CWkgPSBleGVjdihhcmd2WzRdLCBhcmd2ICsgNCk7CiAJaWYgKGkpCi0JCWVycigxLCAiZXhlY3Yo JXMpIiwgYXJndls0XSk7CisJCWVycngoMSwgImV4ZWN2KCVzKSIsIGFyZ3ZbNF0pOwogCWV4aXQg KDApOwogfQo= ------=_Part_1853_19119760.1150116506221-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 16:24:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA7B16A477 for ; Mon, 12 Jun 2006 16:24:07 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E597643D49 for ; Mon, 12 Jun 2006 16:24:05 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 00F559AE49; Mon, 12 Jun 2006 18:24:04 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 2FDCF9B46E; Mon, 12 Jun 2006 16:24:25 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id DEAC7405D; Mon, 12 Jun 2006 18:24:24 +0200 (CEST) Date: Mon, 12 Jun 2006 18:24:24 +0200 From: Jeremie Le Hen To: Andrey Simonenko Message-ID: <20060612162424.GI19457@obiwan.tataz.chchile.org> References: <20060421095610.GA1137@pm513-1.comsys.ntu-kpi.kiev.ua> <20060516092310.GA1110@pm513-1.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060516092310.GA1110@pm513-1.comsys.ntu-kpi.kiev.ua> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: [fbsd] Re: Atomic updates of NFS export lists X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:24:07 -0000 Hi Andrey, On Tue, May 16, 2006 at 12:23:10PM +0300, Andrey Simonenko wrote: > Hello again, > > I found another one security bug in mountd (from RELENG_6). > Details are described in the CHANGES file. Updated version > is available here: > > http://comsys.ntu-kpi.kiev.ua/~simon/mountd/ Thank you very much for working on this, your work seems very interesting. I am a bit late on the topic, but I would like to take advantage to ask a question I've been thinking of for much time. It might be a dumb question to your eyes, but it is not obvious for me : I've been annoyed in the past because I couldn't export two directories from the same filesystem with different credentials [1]. First, where does this limitation come from ? Then, is it possible to remove this limitation without being too intrusive in the VFS code ? [1] http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007300.html Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 16:50:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1047516A418 for ; Mon, 12 Jun 2006 16:50:01 +0000 (UTC) (envelope-from plcplc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE3C43D45 for ; Mon, 12 Jun 2006 16:50:00 +0000 (GMT) (envelope-from plcplc@gmail.com) Received: by nf-out-0910.google.com with SMTP id x29so904024nfb for ; Mon, 12 Jun 2006 09:49:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=KtyXxigNcmrUsFk7QZf/VYjBvrPd+rIsSqYlOS5DE8LGtwiMC3t3SNMvs5UYSgQcw7sSH8LICsY108iPsa8H2d4IxplD7b/sFJxfKoom52xIfuBwx0/IFEnr6HinzUbMrWFf3zuZBTc2FrbTHzT25uQ3m9/geK0U0CUz48sNCn0= Received: by 10.49.65.12 with SMTP id s12mr5044510nfk; Mon, 12 Jun 2006 09:49:58 -0700 (PDT) Received: from ?10.0.1.254? ( [62.79.82.201]) by mx.gmail.com with ESMTP id p72sm6670526nfc.2006.06.12.09.49.57; Mon, 12 Jun 2006 09:49:57 -0700 (PDT) From: Philip Lykke Carlsen To: freebsd-hackers@freebsd.org Date: Mon, 12 Jun 2006 18:49:43 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606121849.45538.plcplc@gmail.com> Subject: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plcplc@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:50:01 -0000 Hello all. I don't want to cry wolf, but i think this calls for some sort of attention :-/ Around yesterday my computer suddenly stared acting really strange :s It started typing on its own. and it seemed to be typing things that I had been typing over GAIM a week or so ago, complete with typo's beeing corrected the same way that i had made them originally. At first I thought that i might be some attacker from outside, but after unplugging the network, the typing persisted. I also noted that it was bound to "pressing" the actual buttons on the keyboard, rather than the resulting strings, as it was total nonsense at first (given that I had been using another keyboard layout the day of writing the text, that it was now printing on the screen), but when I changed the layout back i recognised the text as the chat messages that I had been writing a week before in the past. Then I ran ps -ax as root thinking it most probable to be a virus, but I couldn't find anything suspicious. And even more alarming, the typing persisted when I rebooted the machine in singleuser mode, totally distrupting the terminal. But this at least singles out the location of the virus to be on / and not on /usr, since it wasn't mounted at the time because of a filesystem inconsistency. Then I installed both f-prot and clamav, but they have yet to discover anything. f-prot however seems to hang when it scans /libexec/ld-elf.so.1.old, whose origin is unknown to me, though it may have been created when i last recompiled the base system and kernel to upgrade to 6.1. I don't know if this is of any importance however.. it's probably just a bug in f-prot. I tried searching for it on google, but no-one seem to have experienced anything quite like this. Personally it's my first ever virus infection on freebsd, so naturally I wasn't prepared for it at all. As the virus only seems to be outputting old chat messages, it's not actually dangerous but just damn irritating. untill it starts outputting shell commands, which it has yet to do. It appears to me that I may have gotten the virus from Gaim, but this is rather unlikely, as I'm the only one on my contact list running FreeBSD, let alone gaim in the first place. Any help or input would be greatly appreaciated. :-/ -PLC From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 16:54:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE9D016A41B for ; Mon, 12 Jun 2006 16:54:46 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [80.237.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DFE143D5D for ; Mon, 12 Jun 2006 16:54:45 +0000 (GMT) (envelope-from erdgeist@erdgeist.org) Received: (qmail 43223 invoked by uid 0); 12 Jun 2006 16:54:33 -0000 Received: from erdgeist.org (erdgeist@erdgeist.org@80.237.196.15) by elektropost.org with AES256-SHA encrypted SMTP; 12 Jun 2006 16:54:33 -0000 Date: Mon, 12 Jun 2006 18:54:33 +0200 (CEST) From: Dirk Engling To: Philip Lykke Carlsen In-Reply-To: <200606121849.45538.plcplc@gmail.com> Message-ID: <20060612185341.H15476@erdgeist.org> References: <200606121849.45538.plcplc@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 16:54:47 -0000 On Mon, 12 Jun 2006, Philip Lykke Carlsen wrote: > Around yesterday my computer suddenly stared acting really strange :s > It started typing on its own. > and it seemed to be typing things that I had been typing over GAIM a week or > so ago, complete with typo's beeing corrected the same way that i had made > them originally. Try http://en.wikipedia.org/wiki/Keylogger Regards, erdgeist From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 17:04:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 514E816A507 for ; Mon, 12 Jun 2006 17:04:40 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1425443D69 for ; Mon, 12 Jun 2006 17:04:30 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5C6392085; Mon, 12 Jun 2006 19:04:24 +0200 (CEST) X-Spam-Tests: none X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 4FA812083; Mon, 12 Jun 2006 19:04:24 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 36F7133C8D; Mon, 12 Jun 2006 19:04:24 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: plcplc@gmail.com References: <200606121849.45538.plcplc@gmail.com> Date: Mon, 12 Jun 2006 19:04:24 +0200 In-Reply-To: <200606121849.45538.plcplc@gmail.com> (Philip Lykke Carlsen's message of "Mon, 12 Jun 2006 18:49:43 +0200") Message-ID: <863bea2tlz.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 17:04:40 -0000 Philip Lykke Carlsen writes: > Around yesterday my computer suddenly stared acting really strange :s > It started typing on its own. > and it seemed to be typing things that I had been typing over GAIM a > week or so ago, complete with typo's beeing corrected the same way > that i had made them originally. Someone attached a keylogger to your keyboard, and you somehow managed to trigger its playback function. Check your keyboard cable. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 17:50:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEB5A16A41A for ; Mon, 12 Jun 2006 17:50:14 +0000 (UTC) (envelope-from plcplc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58AF343D45 for ; Mon, 12 Jun 2006 17:50:11 +0000 (GMT) (envelope-from plcplc@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so950036nfc for ; Mon, 12 Jun 2006 10:50:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=IcrGeVQUqa+unD2K4Q57VSeppaLzSP1Z2YFarRQJy9aJdJHRoGhhOCmIMlXpxsLLiCyXD1NqwYK2du6J8LW6j6xh7VbkKsV+h7vXbR9jUVDg/rhJXS68VdAKmppAFX4PscUAgcQ6PHYNbCv/OkIWCfYbMePRkOs5xZ0iA787bMs= Received: by 10.48.213.1 with SMTP id l1mr5095828nfg; Mon, 12 Jun 2006 10:50:10 -0700 (PDT) Received: from ?10.0.1.254? ( [62.79.82.201]) by mx.gmail.com with ESMTP id p43sm1131755nfa.2006.06.12.10.50.08; Mon, 12 Jun 2006 10:50:09 -0700 (PDT) From: Philip Lykke Carlsen To: "Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=" Date: Mon, 12 Jun 2006 19:49:54 +0200 User-Agent: KMail/1.9.1 References: <200606121849.45538.plcplc@gmail.com> <863bea2tlz.fsf@xps.des.no> In-Reply-To: <863bea2tlz.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606121949.55928.plcplc@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plcplc@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 17:50:14 -0000 mandag 12 juni 2006 19:04 skrev du: > Philip Lykke Carlsen writes: > > Around yesterday my computer suddenly stared acting really strange :s > > It started typing on its own. > > and it seemed to be typing things that I had been typing over GAIM a > > week or so ago, complete with typo's beeing corrected the same way > > that i had made them originally. > > Someone attached a keylogger to your keyboard, and you somehow managed > to trigger its playback function. Check your keyboard cable. > > DES Well, the thing is, it's a laptop. there's no way a physical device could have been planted between the keyboard and the computer :-/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 18:42:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D45A16A41A for ; Mon, 12 Jun 2006 18:42:20 +0000 (UTC) (envelope-from plcplc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93F0943D49 for ; Mon, 12 Jun 2006 18:42:19 +0000 (GMT) (envelope-from plcplc@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so706994nfc for ; Mon, 12 Jun 2006 11:42:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=WKK8JwTATjlg3IUGXTNahXdM9J10Xk+AzC7ka/x3AOuVHKCuDxnI3qRPfmdG7XReeieJqsczwtuxnwaL1dhXMA1jSFX7HOXMjs5XQbnZwe4N6ist01CI+wd4bkos8n4bOoklP4wUBo/R35N5NRifsExj3l1uVqYHQ3zqBA4zifc= Received: by 10.49.9.20 with SMTP id m20mr5047171nfi; Mon, 12 Jun 2006 11:42:17 -0700 (PDT) Received: from ?10.0.1.254? ( [62.79.82.201]) by mx.gmail.com with ESMTP id r33sm6694886nfc.2006.06.12.11.42.16; Mon, 12 Jun 2006 11:42:16 -0700 (PDT) From: Philip Lykke Carlsen To: freebsd-hackers@freebsd.org Date: Mon, 12 Jun 2006 20:41:54 +0200 User-Agent: KMail/1.9.1 References: <200606121849.45538.plcplc@gmail.com> In-Reply-To: <200606121849.45538.plcplc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606122042.00928.plcplc@gmail.com> Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plcplc@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 18:42:20 -0000 Hm. A little more research seems to have narrowed it down a bit. Apparently the text come from my sisters windows pc and is transmitted realtime to my freebsd machine, peculiar as it may sound. but at least now I have the means to look at the problem more carefully. But I am still at a loss as to explain how it continued typing even after I unplugged the network card (it's a laptop..), and how it was able to continue even in singleuser mode before the network had been properly set up (let alone plugged in at all). mandag 12 juni 2006 18:49 skrev Philip Lykke Carlsen: > Hello all. > > I don't want to cry wolf, but i think this calls for some sort of > attention :-/ > > Around yesterday my computer suddenly stared acting really strange :s > It started typing on its own. > and it seemed to be typing things that I had been typing over GAIM a week > or so ago, complete with typo's beeing corrected the same way that i had > made them originally. > > At first I thought that i might be some attacker from outside, but after > unplugging the network, the typing persisted. > > I also noted that it was bound to "pressing" the actual buttons on the > keyboard, rather than the resulting strings, as it was total nonsense at > first (given that I had been using another keyboard layout the day of > writing the text, that it was now printing on the screen), but when I > changed the layout back i recognised the text as the chat messages that I > had been writing a week before in the past. > > Then I ran ps -ax as root thinking it most probable to be a virus, but I > couldn't find anything suspicious. > > And even more alarming, the typing persisted when I rebooted the machine in > singleuser mode, totally distrupting the terminal. > > But this at least singles out the location of the virus to be on / and not > on /usr, since it wasn't mounted at the time because of a filesystem > inconsistency. > > Then I installed both f-prot and clamav, but they have yet to discover > anything. f-prot however seems to hang when it > scans /libexec/ld-elf.so.1.old, whose origin is unknown to me, though it > may have been created when i last recompiled the base system and kernel to > upgrade to 6.1. I don't know if this is of any importance however.. it's > probably just a bug in f-prot. > > I tried searching for it on google, but no-one seem to have experienced > anything quite like this. > Personally it's my first ever virus infection on freebsd, so naturally I > wasn't prepared for it at all. > > As the virus only seems to be outputting old chat messages, it's not > actually dangerous but just damn irritating. untill it starts outputting > shell commands, which it has yet to do. > > It appears to me that I may have gotten the virus from Gaim, but this is > rather unlikely, as I'm the only one on my contact list running FreeBSD, > let alone gaim in the first place. > > Any help or input would be greatly appreaciated. :-/ > > -PLC From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 18:48:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 060F216A418 for ; Mon, 12 Jun 2006 18:48:44 +0000 (UTC) (envelope-from david@madole.net) Received: from b.omd3.com (b.omd3.com [69.90.174.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C66A43D5C for ; Mon, 12 Jun 2006 18:48:43 +0000 (GMT) (envelope-from david@madole.net) Received: from static-66-212-193-19.myeastern.com ([66.212.193.19] helo=[192.168.231.195]) by b.omd3.com with esmtpa (Exim 4.54) id 1FprSs-000M8f-Dw; Mon, 12 Jun 2006 14:48:42 -0400 Message-ID: <448DB707.8020105@madole.net> Date: Mon, 12 Jun 2006 14:48:39 -0400 From: "David S. Madole" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: plcplc@gmail.com References: <200606121849.45538.plcplc@gmail.com> <200606122042.00928.plcplc@gmail.com> In-Reply-To: <200606122042.00928.plcplc@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 18:48:44 -0000 Philip Lykke Carlsen wrote: > Hm. A little more research seems to have narrowed it down a bit. > > Apparently the text come from my sisters windows pc and is transmitted > realtime to my freebsd machine, peculiar as it may sound. but at least now I > have the means to look at the problem more carefully. > > But I am still at a loss as to explain how it continued typing even after I > unplugged the network card (it's a laptop..), and how it was able to continue > even in singleuser mode before the network had been properly set up (let > alone plugged in at all). > Wireless keyboard on your sister's machine and your laptop just happens to have a compatible receiver built-in? David From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 12 19:17:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652BE16A41B for ; Mon, 12 Jun 2006 19:17:43 +0000 (UTC) (envelope-from plcplc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02D8643D45 for ; Mon, 12 Jun 2006 19:17:41 +0000 (GMT) (envelope-from plcplc@gmail.com) Received: by nf-out-0910.google.com with SMTP id h2so943881nfe for ; Mon, 12 Jun 2006 12:17:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=GHJ8EGlb/Nst1Hn82Sy7YuWVxfSSYuaQDKQmPGmweVU1ZK24Opt77ebsVCfREKrge+KxOSlnfasgIjqGc8c45XmLlrvDVkJCWkv8o4nIc9QMZNKDFu2fh3ajKsMjI4Pz+PR0SWgm9dugyGUtJuuMftRV+789eJnIwWDSP/LVo7M= Received: by 10.48.208.18 with SMTP id f18mr5139729nfg; Mon, 12 Jun 2006 12:17:40 -0700 (PDT) Received: from ?10.0.1.254? ( [62.79.82.201]) by mx.gmail.com with ESMTP id a23sm6780070nfc.2006.06.12.12.17.39; Mon, 12 Jun 2006 12:17:40 -0700 (PDT) From: Philip Lykke Carlsen To: "David S. Madole" Date: Mon, 12 Jun 2006 21:17:28 +0200 User-Agent: KMail/1.9.1 References: <200606121849.45538.plcplc@gmail.com> <200606122042.00928.plcplc@gmail.com> <448DB707.8020105@madole.net> In-Reply-To: <448DB707.8020105@madole.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606122117.29276.plcplc@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plcplc@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 19:17:43 -0000 mandag 12 juni 2006 20:48 skrev du: > Philip Lykke Carlsen wrote: > > Hm. A little more research seems to have narrowed it down a bit. > > > > Apparently the text come from my sisters windows pc and is transmitted > > realtime to my freebsd machine, peculiar as it may sound. but at least > > now I have the means to look at the problem more carefully. > > > > But I am still at a loss as to explain how it continued typing even after > > I unplugged the network card (it's a laptop..), and how it was able to > > continue even in singleuser mode before the network had been properly set > > up (let alone plugged in at all). > > Wireless keyboard on your sister's machine and your laptop just happens > to have a compatible receiver built-in? > > David Hm. now that you mention it, that does seem probable. And sure enough.. looking closer, the typing stops when I unplug the usb wireless mouse/keyboard reciever.. it's just.. it has never happened before now.. and we've been using this setup for ages.. and I never had quite this success in keyboard transmitting range.. 10 meters at least and through at least four solid brick and steel walls.. hm.. i guess disabling usb-keyboards via devfs.rules or by removing the support from the kernel would solve the problem. But thanks very much. very much indeed :-D hm.. I wonder why I didn't at least consider the possibility of it being the wireless keyboard.. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 00:47:35 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295F516A46F for ; Tue, 13 Jun 2006 00:47:35 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB0F43D46 for ; Tue, 13 Jun 2006 00:47:34 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 97B0516376; Mon, 12 Jun 2006 20:47:33 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 2B39B4AC46; Mon, 12 Jun 2006 20:47:13 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17550.2830.500237.71736@canoe.dclg.ca> Date: Mon, 12 Jun 2006 20:47:10 -0400 To: freebsd-hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Subject: destroying tunN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 00:47:35 -0000 first off, why don't if_tun devices destroy themselves when the owner closes the device? But... aslo, why can't I 'unplumb' an unused tunN device with ifconfig? Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 00:58:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1808616A41B for ; Tue, 13 Jun 2006 00:58:55 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6666543D46 for ; Tue, 13 Jun 2006 00:58:54 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k5D0wlJ0027202; Mon, 12 Jun 2006 17:58:47 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k5D0wlkP027201; Mon, 12 Jun 2006 17:58:47 -0700 Date: Mon, 12 Jun 2006 17:58:47 -0700 From: Brooks Davis To: David Gilbert Message-ID: <20060613005847.GA23824@odin.ac.hmc.edu> References: <17550.2830.500237.71736@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <17550.2830.500237.71736@canoe.dclg.ca> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: freebsd-hackers@freebsd.org Subject: Re: destroying tunN X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 00:58:55 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 12, 2006 at 08:47:10PM -0400, David Gilbert wrote: > first off, why don't if_tun devices destroy themselves when the owner > closes the device? Historical behavior. I suspect many people would be very suprised it they automaticly vanished, but there's some argument that's the right thing to do. > But... aslo, why can't I 'unplumb' an unused tunN device with > ifconfig? Because they aren't hooked to the interface cloning system since their auto creation code predates it. This should be fixed, but is more difficult than for a staticly compiled interface due to the existing cloning code. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEjg3GXY6L6fI4GtQRAtp3AKCVWzbHWdTgozSAl7QjGJ4+fuUrGwCfV4jN XNENOWRiWL5X8llFLZ/vChU= =gMKN -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 09:01:17 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8BB116A41A for ; Tue, 13 Jun 2006 09:01:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F6A43D46 for ; Tue, 13 Jun 2006 09:01:16 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k5D914Ks012307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jun 2006 12:01:04 +0300 (EEST) (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.13.6/8.13.6) with ESMTP id k5D91F4c083366; Tue, 13 Jun 2006 12:01:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k5D91Bcx083365; Tue, 13 Jun 2006 12:01:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Jun 2006 12:01:11 +0300 From: Konstantin Belousov To: Divacky Roman Message-ID: <20060613090111.GS54415@deviant.kiev.zoral.com.ua> References: <20060606144455.GA502@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mln0rGgUGuXEqmuI" Content-Disposition: inline In-Reply-To: <20060606144455.GA502@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean Cc: hackers@freebsd.org Subject: Re: SoC: strange magic with objcopy and module builds X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 09:01:18 -0000 --mln0rGgUGuXEqmuI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 06, 2006 at 04:44:55PM +0200, Divacky Roman wrote: > Hi, >=20 > I am working on SoC linuxolator and I found strange thing I dont know how= to > cope with: >=20 > I made a patch which enables module build of linuxolator on amd64 but it > refuses to kldload because of missing symbol. I tracked the problem down = to > the fact that i386 module build works in a way that it builds .kld and th= en > turns this into .ko: >=20 > ld -Bshareable -d -warn-common -o linux.ko linux.kld >=20 > this line makes transition from U symbol to A symbol. >=20 > Amd64 version uses only .ko, so this step doesnt exist there so those sym= bols > remain U. >=20 > can someone explain me whats going on? >=20 > thnx roman In private communication, Roman said that the problem symbols are __start* and __stop*. That symbols are generated by the static linker for the section start/end. Since AMD64 uses relocatable objects as kld instead of shared ones, that symbols are leaved undefined. Patch below will simulate behaviour of the static linker for the in-kernel elf_obj linker. The patch makes the linker_set.h machinery fully operatable on AMD64. Please test. Index: kern/link_elf_obj.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/kern/link_elf_obj.c,v retrieving revision 1.87.2.3 diff -u -r1.87.2.3 link_elf_obj.c --- kern/link_elf_obj.c 30 Dec 2005 22:13:58 -0000 1.87.2.3 +++ kern/link_elf_obj.c 13 Jun 2006 08:56:08 -0000 @@ -1112,6 +1112,51 @@ } =20 static void +link_elf_fix_link_set(elf_file_t ef) +{ + static const char startn[] =3D "__start_"; + static const char stopn[] =3D "__stop_"; + Elf_Sym *sym; + const char *sym_name, *linkset_name; + Elf_Addr startp, stopp; + Elf_Size symidx; + int start, i; + + startp =3D stopp =3D 0; + for (symidx =3D 1 /* zero entry is special */; + symidx < ef->ddbsymcnt; symidx++) { + sym =3D ef->ddbsymtab + symidx; + if (sym->st_shndx !=3D SHN_UNDEF) + continue; + + sym_name =3D ef->ddbstrtab + sym->st_name; + if (strncmp(sym_name, startn, sizeof(startn) - 1) =3D=3D 0) { + start =3D 1; + linkset_name =3D sym_name + sizeof(startn) - 1; + } + else if (strncmp(sym_name, stopn, sizeof(stopn) - 1) =3D=3D 0) { + start =3D 0; + linkset_name =3D sym_name + sizeof(stopn) - 1; + } + else + continue; + + for (i =3D 0; i < ef->nprogtab; i++) { + if (strcmp(ef->progtab[i].name, linkset_name) =3D=3D 0) { + startp =3D (Elf_Addr)ef->progtab[i].addr; + stopp =3D (Elf_Addr)(startp + ef->progtab[i].size); + break; + } + } + if (i =3D=3D ef->nprogtab) + continue; + + sym->st_value =3D start ? startp : stopp; + sym->st_shndx =3D i; + } +} + +static void link_elf_reloc_local(linker_file_t lf) { elf_file_t ef =3D (elf_file_t)lf; @@ -1124,6 +1169,8 @@ int i; Elf_Size symidx; =20 + link_elf_fix_link_set(ef); + /* Perform relocations without addend if there are any: */ for (i =3D 0; i < ef->nrel; i++) { rel =3D ef->reltab[i].rel; --mln0rGgUGuXEqmuI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEjn7XC3+MBN1Mb4gRAjT8AKDL3nWsdigFsTFbBFoEfnB1zpm5sQCffb7W 2USILVow6G8PYF9CxuUxxNI= =JV6x -----END PGP SIGNATURE----- --mln0rGgUGuXEqmuI-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 09:18:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A728716A41A for ; Tue, 13 Jun 2006 09:18:08 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFEA343D53 for ; Tue, 13 Jun 2006 09:18:04 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.13.6/8.13.6) with ESMTP id k5D9J2Ka003995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jun 2006 12:19:02 +0300 (EEST) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id D72625C024; Tue, 13 Jun 2006 12:17:48 +0300 (EEST) Date: Tue, 13 Jun 2006 12:17:48 +0300 From: Andrey Simonenko To: Jeremie Le Hen Message-ID: <20060613091748.GA753@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20060421095610.GA1137@pm513-1.comsys.ntu-kpi.kiev.ua> <20060516092310.GA1110@pm513-1.comsys.ntu-kpi.kiev.ua> <20060612162424.GI19457@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060612162424.GI19457@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/1456/Thu May 11 08:57:31 2006 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [fbsd] Re: Atomic updates of NFS export lists X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 09:18:08 -0000 On Mon, Jun 12, 2006 at 06:24:24PM +0200, Jeremie Le Hen wrote: > > I've been annoyed in the past because I couldn't export two directories > from the same filesystem with different credentials [1]. > First, where does this limitation come from ? Then, is it possible to > remove this limitation without being too intrusive in the VFS code ? > > [1] http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007300.html > In current implementation of NFSv2 and v3 filesystems are exported, not directories in filesystems. Suppose you have following configuration: /usr/a -mapall=user1 host1 /usr/b -mapall=user2 host2 /usr/a and /usr/b are in the same filesystem /usr. To start to work with /usr/a, a client host1 sends the MOUNT request to mountd. Mountd verifies that a client is allowed to work with /usr/a and sends a client special filehandle, which a client will use for conversation with nfsserver (the kernel part of NFS). Here the role of mountd is finished for client host1. When mountd starts, it parses /etc/exports and says the nfsserver following configuration: /usr -mapall=user1 host1 -mapall=user2 host2 The kernel knows nothing about settings for directories. As the result it verifies if a client is allowed to work with filesystem according to settings in a filesystem. Suppose you have: /usr/a -mapall=user1 host1 /usr/a -mapall=userx host2 /usr/b -mapall=user2 host2 Now there is a conflict, since host2 has two duplicated export specifications for one filesystem /usr. Exporting directories in a filesystem is good feature in such implementation of NFSv2 and v3 for honest hosts, but really is insecure. You can read more detail description about this at the end of updated exports(5). Right now I cannot answer if it is a good or bad idea, or if it is possible to respect Unix filesystem semantic when putting NFS export specifications to filesystems' directories, rather than to filesystems. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 09:51:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB2FA16A474 for ; Tue, 13 Jun 2006 09:51:08 +0000 (UTC) (envelope-from hnazfoo@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E909543D5A for ; Tue, 13 Jun 2006 09:51:07 +0000 (GMT) (envelope-from hnazfoo@googlemail.com) Received: by nf-out-0910.google.com with SMTP id y25so1000460nfb for ; Tue, 13 Jun 2006 02:51:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:date:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=ioBFPikSPP3919a58EMNjjTRUFm8iy1enIkgz1DDT8DeNdxHlYsl1QGwtIJVL5zg/o+Di/iSNf/XY62LVRLh97aSptlSvVF+4GMVJFTbKxIGDGwR/tJHaVCZ1fCtdme/9gGarMB3HhzY+gM9Wt9gWZsiKBMsDUt6Swmr1297AG0= Received: by 10.49.93.18 with SMTP id v18mr5658366nfl; Tue, 13 Jun 2006 02:51:06 -0700 (PDT) Received: from localhost ( [217.65.21.89]) by mx.gmail.com with ESMTP id q28sm7445657nfc.2006.06.13.02.51.05; Tue, 13 Jun 2006 02:51:06 -0700 (PDT) Date: Tue, 13 Jun 2006 11:52:13 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20060613095213.GA1020@leiferikson.flosken.lan> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20060611134419.GA71676@leiferikson.flosken.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060611134419.GA71676@leiferikson.flosken.lan> User-Agent: mutt-ng/devel-r804 (FreeLSD) From: Johannes Weiner Subject: Re: Kernelinternal function return value caching? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 09:51:09 -0000 Hi folks, never mind about this. The function got called but returned before the debugging printf().. The problem was somewhere else but it's fixed now and the patch submitted. Hannes From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 13:08:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D11BF16A41A for ; Tue, 13 Jun 2006 13:08:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2093743D45 for ; Tue, 13 Jun 2006 13:08:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5DD8P94022803; Tue, 13 Jun 2006 09:08:27 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 13 Jun 2006 09:08:24 -0400 User-Agent: KMail/1.9.1 References: <20060606144455.GA502@stud.fit.vutbr.cz> <20060613090111.GS54415@deviant.kiev.zoral.com.ua> In-Reply-To: <20060613090111.GS54415@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200606130908.25380.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Tue, 13 Jun 2006 09:08:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1537/Tue Jun 13 07:24:06 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Konstantin Belousov , Divacky Roman Subject: Re: SoC: strange magic with objcopy and module builds X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 13:08:29 -0000 On Tuesday 13 June 2006 05:01, Konstantin Belousov wrote: > On Tue, Jun 06, 2006 at 04:44:55PM +0200, Divacky Roman wrote: > > Hi, > >=20 > > I am working on SoC linuxolator and I found strange thing I dont know h= ow to > > cope with: > >=20 > > I made a patch which enables module build of linuxolator on amd64 but it > > refuses to kldload because of missing symbol. I tracked the problem dow= n to > > the fact that i386 module build works in a way that it builds .kld and = then > > turns this into .ko: > >=20 > > ld -Bshareable -d -warn-common -o linux.ko linux.kld > >=20 > > this line makes transition from U symbol to A symbol. > >=20 > > Amd64 version uses only .ko, so this step doesnt exist there so those s= ymbols > > remain U. > >=20 > > can someone explain me whats going on? > >=20 > > thnx roman > In private communication, Roman said that the problem symbols > are __start* and __stop*. That symbols are generated by the static linker > for the section start/end. >=20 > Since AMD64 uses relocatable objects as kld instead of shared ones, > that symbols are leaved undefined. >=20 > Patch below will simulate behaviour of the static linker for the > in-kernel elf_obj linker. The patch makes the linker_set.h > machinery fully operatable on AMD64. Please test. Alternatively you can not use the SET_* macros in kernel modules, but ask the kernel linker to lookup the linker sets you need in your mod_event handler. The linker manually looks up linker sets for things like sysinit and sysctl, so it is probably best if we continue to just look them up manually. You don't want to create duplicate start/stop for existing sets which might confuse things. I have an example of this for HEAD in my crash and crash2 modules available in the smpng branch in p4 at //depot/projects/smpng/src/sys/modules/crash/crash.c and //depot/projects/smpng/src/sys/modules/crash2/crash2.c. I'm not opposed to this fix either though, but peter@ should probably review it. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 14:44:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFD2D16A46F for ; Tue, 13 Jun 2006 14:44:46 +0000 (UTC) (envelope-from e.schuele@computer.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA7843D45 for ; Tue, 13 Jun 2006 14:44:46 +0000 (GMT) (envelope-from e.schuele@computer.org) Received: from [208.206.151.59] (host59.gtisd.com?[208.206.151.59]) by comcast.net (sccrmhc11) with ESMTP id <200606131444440110000jqve>; Tue, 13 Jun 2006 14:44:44 +0000 Message-ID: <448ECF5A.9090501@computer.org> Date: Tue, 13 Jun 2006 09:44:42 -0500 From: Eric Schuele User-Agent: Thunderbird 1.5.0.4 (X11/20060604) MIME-Version: 1.0 To: plcplc@gmail.com References: <200606121849.45538.plcplc@gmail.com> <200606122042.00928.plcplc@gmail.com> <448DB707.8020105@madole.net> <200606122117.29276.plcplc@gmail.com> In-Reply-To: <200606122117.29276.plcplc@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "David S. Madole" Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 14:44:46 -0000 On 06/12/06 14:17, Philip Lykke Carlsen wrote: > mandag 12 juni 2006 20:48 skrev du: >> Philip Lykke Carlsen wrote: >>> Hm. A little more research seems to have narrowed it down a bit. >>> >>> Apparently the text come from my sisters windows pc and is transmitted >>> realtime to my freebsd machine, peculiar as it may sound. but at least >>> now I have the means to look at the problem more carefully. >>> >>> But I am still at a loss as to explain how it continued typing even after >>> I unplugged the network card (it's a laptop..), and how it was able to >>> continue even in singleuser mode before the network had been properly set >>> up (let alone plugged in at all). >> Wireless keyboard on your sister's machine and your laptop just happens >> to have a compatible receiver built-in? >> >> David > > Hm. now that you mention it, that does seem probable. > > And sure enough.. looking closer, the typing stops when I unplug the usb > wireless mouse/keyboard reciever.. it's just.. it has never happened before > now.. and we've been using this setup for ages.. and I never had quite this > success in keyboard transmitting range.. 10 meters at least and through at > least four solid brick and steel walls.. > hm.. i guess disabling usb-keyboards via devfs.rules or by removing the > support from the kernel would solve the problem. > > But thanks very much. > very much indeed :-D > > hm.. I wonder why I didn't at least consider the possibility of it being the > wireless keyboard.. I'm curious.... Originally you said it was playing back YOUR previous GAIM conversation. Then above you mention "real time text" from your sister's pc. If it is the former... your sister's pc may have a keylogger on it, no? And may require some investigation. Either way, now (with wireless keyboard)... the keylogger only needs to be near your machine, not installed on it. :S > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Regards, Eric From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 15:29:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D64D816A479 for ; Tue, 13 Jun 2006 15:29:22 +0000 (UTC) (envelope-from plcplc@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D47543D6B for ; Tue, 13 Jun 2006 15:29:12 +0000 (GMT) (envelope-from plcplc@gmail.com) Received: by nf-out-0910.google.com with SMTP id x29so1054117nfb for ; Tue, 13 Jun 2006 08:29:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=XIMlgQgHf08Cp26O2gmCYPyKI7sL4Gi/BfymcSudE18WxY6INPvMarFg/YMeOzENK87mX4qW6QjEijgtiI4u3sv3pIsau/TnO2cPUEmN0hkTZVickPU+6d+EzXtH6RvwKhCgOL9AFzlBPrruaLALEVOCqiX999xJF4Rnow7/KNg= Received: by 10.48.213.1 with SMTP id l1mr5921520nfg; Tue, 13 Jun 2006 08:29:00 -0700 (PDT) Received: from ?10.0.1.254? ( [62.79.82.201]) by mx.gmail.com with ESMTP id l38sm5706828nfc.2006.06.13.08.28.59; Tue, 13 Jun 2006 08:28:59 -0700 (PDT) From: Philip Lykke Carlsen To: freebsd-hackers@freebsd.org Date: Tue, 13 Jun 2006 17:28:58 +0200 User-Agent: KMail/1.9.1 References: <200606121849.45538.plcplc@gmail.com> <200606122117.29276.plcplc@gmail.com> <448ECF5A.9090501@computer.org> In-Reply-To: <448ECF5A.9090501@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606131728.59050.plcplc@gmail.com> Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: plcplc@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 15:29:23 -0000 tirsdag 13 juni 2006 16:44 skrev Eric Schuele: > On 06/12/06 14:17, Philip Lykke Carlsen wrote: > > mandag 12 juni 2006 20:48 skrev du: > >> Philip Lykke Carlsen wrote: > >>> Hm. A little more research seems to have narrowed it down a bit. > >>> > >>> Apparently the text come from my sisters windows pc and is transmitted > >>> realtime to my freebsd machine, peculiar as it may sound. but at least > >>> now I have the means to look at the problem more carefully. > >>> > >>> But I am still at a loss as to explain how it continued typing even > >>> after I unplugged the network card (it's a laptop..), and how it was > >>> able to continue even in singleuser mode before the network had been > >>> properly set up (let alone plugged in at all). > >> > >> Wireless keyboard on your sister's machine and your laptop just happens > >> to have a compatible receiver built-in? > >> > >> David > > > > Hm. now that you mention it, that does seem probable. > > > > And sure enough.. looking closer, the typing stops when I unplug the usb > > wireless mouse/keyboard reciever.. it's just.. it has never happened > > before now.. and we've been using this setup for ages.. and I never had > > quite this success in keyboard transmitting range.. 10 meters at least > > and through at least four solid brick and steel walls.. > > hm.. i guess disabling usb-keyboards via devfs.rules or by removing the > > support from the kernel would solve the problem. > > > > But thanks very much. > > very much indeed :-D > > > > hm.. I wonder why I didn't at least consider the possibility of it being > > the wireless keyboard.. > > I'm curious.... > Originally you said it was playing back YOUR previous GAIM conversation. > Then above you mention "real time text" from your sister's pc. If it > is the former... your sister's pc may have a keylogger on it, no? And > may require some investigation. > Well, that is, I thought so. Because the text being replayed looked very much like the conversation my sister had had when she borrowed my GAIM a week ago. A little detail that I neglected to tell about . Heh, that just proves how very low the diversity in her conversations is :p So.. no keylogger in the end.. just the damned keyboard muxer.. > Either way, now (with wireless keyboard)... the keylogger only needs to > be near your machine, not installed on it. :S > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 17:24:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 681DB16A478 for ; Tue, 13 Jun 2006 17:24:11 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1FC443D5D for ; Tue, 13 Jun 2006 17:24:07 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so2754301uge for ; Tue, 13 Jun 2006 10:24:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y0eerNefQulDJbm5sIF6/3+fVaqj3nOV+8cDqcHnvHzNDWPUDyV6rhKDVP+iBtVVuD2t2/8H1srYr379XxExDjJoiRsGsbRyFpcpe9fedtNEQaeio2f0TP6tKPh8FDhsmfWxbn+BA+3FLT7HC4SLGRYf13cks+eSTok51linVcM= Received: by 10.78.136.2 with SMTP id j2mr91904hud; Mon, 12 Jun 2006 20:17:05 -0700 (PDT) Received: by 10.78.48.1 with HTTP; Mon, 12 Jun 2006 20:17:00 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2006 11:17:00 +0800 From: "Jiawei Ye" To: plcplc@gmail.com In-Reply-To: <200606122117.29276.plcplc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606121849.45538.plcplc@gmail.com> <200606122042.00928.plcplc@gmail.com> <448DB707.8020105@madole.net> <200606122117.29276.plcplc@gmail.com> Cc: freebsd-hackers@freebsd.org, "David S. Madole" Subject: Re: Strange keyboard (viral?) behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:24:11 -0000 On 6/13/06, Philip Lykke Carlsen wrote: > Hm. now that you mention it, that does seem probable. > > And sure enough.. looking closer, the typing stops when I unplug the usb > wireless mouse/keyboard reciever.. it's just.. it has never happened before > now.. and we've been using this setup for ages.. and I never had quite this > success in keyboard transmitting range.. 10 meters at least and through at > least four solid brick and steel walls.. > hm.. i guess disabling usb-keyboards via devfs.rules or by removing the > support from the kernel would solve the problem. > > But thanks very much. > very much indeed :-D > > hm.. I wonder why I didn't at least consider the possibility of it being the > wireless keyboard.. It proves how well our kbdmux works :) -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 17:33:19 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BCFC16A41B for ; Tue, 13 Jun 2006 17:33:19 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5522243D76 for ; Tue, 13 Jun 2006 17:33:15 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from webmail.centtech.com (mailbox.centtech.com [10.20.0.15]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k5DHXE0n038915 for ; Tue, 13 Jun 2006 12:33:14 -0500 (CDT) (envelope-from anderson@centtech.com) Received: from 10.20.200.100 (SquirrelMail authenticated user anderson); by otter.centtech.com with HTTP; Tue, 13 Jun 2006 12:33:14 -0500 (CDT) Message-ID: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> Date: Tue, 13 Jun 2006 12:33:14 -0500 (CDT) From: "Eric Anderson" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: ClamAV 0.87.1/1537/Tue Jun 13 06:24:06 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:33:19 -0000 >From the subject, you probably already know my dilemma. After booting a linux livecd (I'll refrain from naming the distro), my laptop no longer has any partitions. Now, the drive was not newfs'ed with any other OS, so I believe only the boot loader and partitioning are messed up. I see an ffsrecov tool, that could probably help me, but I want to make sure I don't make any bad decisions here. So, my partitioning was something like: ad0 ad0s1 DOS ad0s2 ?? ad0s3 ?? ad0s4 Linux root / swap FreeBSD was on either ad0s2 or ad0s3, I can't recall which, but I believe it was ad0s3. I had 3 partitions (/, /alt, /home) and a swap. I'm running the ffsrecov tool now, but it appears to be very slow chugging through the disk. Is there any additional ways I can find the partitioning scheme, or find the bsdlabel's on the disk? Does anyone know of a command line (dd+some tools/perl/etc) way to find the bsdlabels? Once the bsdlabels are found, then what? Also - if I rewrite the bsdlabel exactly as it was before, I should be in business, correct? I'm in a very bad spot without this machine (happened at a particularly in-opportune time also, of course), so I'd appreciate any help anyone could provide. Thanks in advance! Eric -- ------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology You have my continuous partial attention ------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 20:53:05 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B983816A478 for ; Tue, 13 Jun 2006 20:53:05 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 501EE43D6E for ; Tue, 13 Jun 2006 20:52:56 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DA8D.dip.t-dialin.net [84.165.218.141]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.4/8.13.4) with ESMTP id k5DKnCQe071708; Tue, 13 Jun 2006 22:49:12 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k5DKqnrp018445; Tue, 13 Jun 2006 22:52:49 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Tue, 13 Jun 2006 22:53:16 +0200 From: Alexander Leidinger To: "Eric Anderson" Message-ID: <20060613225316.53d939a3@Magellan.Leidinger.net> In-Reply-To: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.18; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Tue, 13 Jun 2006 20:54:12 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 20:53:05 -0000 Quoting "Eric Anderson" (Tue, 13 Jun 2006 12:33:14 -0500 (CDT)): > >From the subject, you probably already know my dilemma. After booting a > linux livecd (I'll refrain from naming the distro), my laptop no longer > has any partitions. Now, the drive was not newfs'ed with any other OS, so > I believe only the boot loader and partitioning are messed up. I see an > ffsrecov tool, that could probably help me, but I want to make sure I > don't make any bad decisions here. > > So, my partitioning was something like: > ad0 > ad0s1 DOS > ad0s2 ?? > ad0s3 ?? > ad0s4 Linux root / swap For this particular reason I always print out the layout. Got hit once, wrote a program to recover (only understands ufs1 disklabels, and stopped to work after a particular 4.x... I assume it's because of a blocksize/fragsize change introduced then), learned my lesson. > FreeBSD was on either ad0s2 or ad0s3, I can't recall which, but I believe > it was ad0s3. I had 3 partitions (/, /alt, /home) and a swap. > > I'm running the ffsrecov tool now, but it appears to be very slow chugging > through the disk. There are ways to speed such a search up. I assume my own tool tries to be too smart (or it's not smart enough, at least it uses wrong invariants) for the disklabels. And it only prints assumptions about the start of a FreeBSD slice, not about other slice types. > Is there any additional ways I can find the partitioning scheme, or find > the bsdlabel's on the disk? Does anyone know of a command line (dd+some Try to remember them. If you know how large the partitions have been, you just have to write the MBR and everything should work. If nothing works, you remembered wrong. > tools/perl/etc) way to find the bsdlabels? > > Once the bsdlabels are found, then what? > > Also - if I rewrite the bsdlabel exactly as it was before, I should be in > business, correct? The bsdlabels are still there I assume, it sounds just like your MBR got hosed. Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 21:02:35 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DEED16A41B for ; Tue, 13 Jun 2006 21:02:35 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C967F43D48 for ; Tue, 13 Jun 2006 21:02:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from webmail.centtech.com (mailbox.centtech.com [10.20.0.15]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k5DL2Xps055552; Tue, 13 Jun 2006 16:02:33 -0500 (CDT) (envelope-from anderson@centtech.com) Received: from 10.20.200.100 (SquirrelMail authenticated user anderson); by otter.centtech.com with HTTP; Tue, 13 Jun 2006 16:02:33 -0500 (CDT) Message-ID: <54950.10.20.200.100.1150232553.squirrel@10.20.200.100> In-Reply-To: <20060613225316.53d939a3@Magellan.Leidinger.net> References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> <20060613225316.53d939a3@Magellan.Leidinger.net> Date: Tue, 13 Jun 2006 16:02:33 -0500 (CDT) From: "Eric Anderson" To: "Alexander Leidinger" User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: ClamAV 0.87.1/1537/Tue Jun 13 06:24:06 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 21:02:35 -0000 Alexander Leidinger said: > Quoting "Eric Anderson" (Tue, 13 Jun 2006 12:33:14 > -0500 (CDT)): > >> >From the subject, you probably already know my dilemma. After booting >> a >> linux livecd (I'll refrain from naming the distro), my laptop no longer >> has any partitions. Now, the drive was not newfs'ed with any other OS, >> so >> I believe only the boot loader and partitioning are messed up. I see an >> ffsrecov tool, that could probably help me, but I want to make sure I >> don't make any bad decisions here. >> >> So, my partitioning was something like: >> ad0 >> ad0s1 DOS >> ad0s2 ?? >> ad0s3 ?? >> ad0s4 Linux root / swap > > For this particular reason I always print out the layout. Got hit once, > wrote a program to recover (only understands ufs1 disklabels, and > stopped to work after a particular 4.x... I assume it's because of a > blocksize/fragsize change introduced then), learned my lesson. I'll probably look into writing such a tool, since this is very painful. :( Printing is a good idea. :) >> FreeBSD was on either ad0s2 or ad0s3, I can't recall which, but I >> believe >> it was ad0s3. I had 3 partitions (/, /alt, /home) and a swap. >> >> I'm running the ffsrecov tool now, but it appears to be very slow >> chugging >> through the disk. > > There are ways to speed such a search up. I assume my own tool tries to > be too smart (or it's not smart enough, at least it uses wrong > invariants) for the disklabels. And it only prints assumptions about > the start of a FreeBSD slice, not about other slice types. Is there a good way to identify the bsdlabel, or other partitioning information from a hexdumped output? >> Is there any additional ways I can find the partitioning scheme, or find >> the bsdlabel's on the disk? Does anyone know of a command line >> (dd+some > > Try to remember them. If you know how large the partitions have been, > you just have to write the MBR and everything should work. If nothing > works, you remembered wrong. I have some general guesses as to the sizes. Do you know if any of that data would be in a dmesg,sysctl,etc type output? I have much of that logged to an external site I can look at for the details.. >> tools/perl/etc) way to find the bsdlabels? >> >> Once the bsdlabels are found, then what? >> >> Also - if I rewrite the bsdlabel exactly as it was before, I should be >> in >> business, correct? > > The bsdlabels are still there I assume, it sounds just like your MBR > got hosed. fdisk reports nothing, so I'm sure I just need to put the fdisk partitioning back. Problem is, I don't know the offsets. Eric -- ------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology You have my continuous partial attention ------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 13 21:08:21 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60CE016A477 for ; Tue, 13 Jun 2006 21:08:21 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A328C43D46 for ; Tue, 13 Jun 2006 21:08:20 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k5DL88Xl021530; Wed, 14 Jun 2006 01:08:11 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 14 Jun 2006 01:08:08 +0400 (MSD) From: Maxim Konovalov To: Eric Anderson In-Reply-To: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> Message-ID: <20060614010608.R21481@mp2.macomnet.net> References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 21:08:21 -0000 [...] > Is there any additional ways I can find the partitioning scheme, or find > the bsdlabel's on the disk? Does anyone know of a command line (dd+some > tools/perl/etc) way to find the bsdlabels? ports/sysutils/scan_ffs/ src/tools/tools/find-sb/ > Once the bsdlabels are found, then what? Restore it, bsdlabel -e. -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 03:54:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE0DB16A41A for ; Wed, 14 Jun 2006 03:54:58 +0000 (UTC) (envelope-from cyberbotx@cyberbotx.com) Received: from samus.cyberbotx.com (cyberbotx.com [70.88.125.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7EC43D48 for ; Wed, 14 Jun 2006 03:54:58 +0000 (GMT) (envelope-from cyberbotx@cyberbotx.com) Received: from localhost (localhost [127.0.0.1]) by samus.cyberbotx.com (Postfix) with ESMTP id 84D99C207; Tue, 13 Jun 2006 23:54:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at cyberbotx.com Received: from samus.cyberbotx.com ([127.0.0.1]) by localhost (samus.cyberbotx.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b1MboTk83s6; Tue, 13 Jun 2006 23:54:31 -0400 (EDT) Received: from metroid (c-68-61-58-20.hsd1.mi.comcast.net [68.61.58.20]) by samus.cyberbotx.com (Postfix) with SMTP id 76D45C1B1; Tue, 13 Jun 2006 23:54:30 -0400 (EDT) Message-ID: <00cf01c68f66$3de93e50$fe02a8c0@metroid> From: "Naram Qashat" To: "Eric Anderson" , References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> Date: Tue, 13 Jun 2006 23:54:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Cc: Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 03:54:58 -0000 You've also got the choice of using the program testdisk in sysutils/testdisk to try to fix your problem. It helped me when I accidently hosed the MBR and partition table on one of my drives. Naram Qashat ----- Original Message ----- From: "Eric Anderson" To: Sent: Tuesday, June 13, 2006 01:33 PM Subject: fdisk partition / disklabel recovery (help!) > >From the subject, you probably already know my dilemma. After booting a > linux livecd (I'll refrain from naming the distro), my laptop no longer > has any partitions. Now, the drive was not newfs'ed with any other OS, so > I believe only the boot loader and partitioning are messed up. I see an > ffsrecov tool, that could probably help me, but I want to make sure I > don't make any bad decisions here. > > So, my partitioning was something like: > ad0 > ad0s1 DOS > ad0s2 ?? > ad0s3 ?? > ad0s4 Linux root / swap > > FreeBSD was on either ad0s2 or ad0s3, I can't recall which, but I believe > it was ad0s3. I had 3 partitions (/, /alt, /home) and a swap. > > I'm running the ffsrecov tool now, but it appears to be very slow chugging > through the disk. > > Is there any additional ways I can find the partitioning scheme, or find > the bsdlabel's on the disk? Does anyone know of a command line (dd+some > tools/perl/etc) way to find the bsdlabels? > > Once the bsdlabels are found, then what? > > Also - if I rewrite the bsdlabel exactly as it was before, I should be in > business, correct? > > I'm in a very bad spot without this machine (happened at a particularly > in-opportune time also, of course), so I'd appreciate any help anyone > could provide. > > Thanks in advance! > Eric > > > > -- > ------------------------------------------------------------- > Eric Anderson anderson@centtech.com Centaur Technology > You have my continuous partial attention > ------------------------------------------------------------- > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 10:34:51 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FE8F16A474; Wed, 14 Jun 2006 10:34:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BC3043D78; Wed, 14 Jun 2006 10:34:34 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k5EAYMcd054892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 13:34:22 +0300 (EEST) (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.13.6/8.13.6) with ESMTP id k5EAYMcN032711; Wed, 14 Jun 2006 13:34:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k5EAYLo7032710; Wed, 14 Jun 2006 13:34:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Jun 2006 13:34:20 +0300 From: Konstantin Belousov To: Bruno Haible Message-ID: <20060614103420.GA86300@deviant.kiev.zoral.com.ua> References: <200606101822.46437.bruno@clisp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <200606101822.46437.bruno@clisp.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: Vasil Dimov , hackers@freebsd.org Subject: Re: valid VMA ranges and mincore() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 10:34:51 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 10, 2006 at 06:22:46PM +0200, Bruno Haible wrote: > Proposal 1: Change mincore() to behave like the one on NetBSD, Linux, > Solaris. Please, evaluate the patch. If it does what you need, I will push it for review. Index: vm_mmap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/vm/vm_mmap.c,v retrieving revision 1.205 diff -u -r1.205 vm_mmap.c --- vm_mmap.c 21 Apr 2006 07:17:25 -0000 1.205 +++ vm_mmap.c 14 Jun 2006 10:32:11 -0000 @@ -907,6 +907,40 @@ ++lastvecindex; } =20 + /* Mark unmapped areas of the queried address + * space with -1. + */ + for (addr =3D first_addr; addr < end; ) { + vm_offset_t saddr, eaddr; + + vm_map_lock_read(map); + if (vm_map_lookup_entry(map, addr, &entry)) { + addr =3D entry->end; + vm_map_unlock_read(map); + continue; + } + entry =3D entry->next; + if (entry->start < addr) { + /* past the last entry in the map */ + saddr =3D eaddr =3D end; + } else { + saddr =3D entry->start; + eaddr =3D entry->end; + } + vm_map_unlock_read(map); + + while (addr < saddr) { + vecindex =3D OFF_TO_IDX(addr - first_addr); + error =3D subyte(vec + vecindex, -1); + if (error) { + error =3D EFAULT; + goto done2; + } + addr +=3D PAGE_SIZE; + } + addr =3D eaddr; + } + /* * If the map has changed, due to the subyte, the previous * output may be invalid. --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEj+YsC3+MBN1Mb4gRAllsAJ9tTfcBapLXj9FhxrMu+Thz9Ia4VQCg21YU W8evbRThZZeWi827tB6T61g= =YmSo -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 07:20:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CB3816A41A for ; Wed, 14 Jun 2006 07:20:02 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A17EC43D45 for ; Wed, 14 Jun 2006 07:20:00 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DA8D.dip.t-dialin.net [84.165.218.141]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.4/8.13.4) with ESMTP id k5E7GEcj074402; Wed, 14 Jun 2006 09:16:14 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k5E7JuUk009016; Wed, 14 Jun 2006 09:19:56 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 14 Jun 2006 09:19:55 +0200 Message-ID: <20060614091955.16e3e61mo4gcw4sw@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 14 Jun 2006 09:19:55 +0200 From: Alexander Leidinger To: Eric Anderson References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> <20060613225316.53d939a3@Magellan.Leidinger.net> <54950.10.20.200.100.1150232553.squirrel@10.20.200.100> In-Reply-To: <54950.10.20.200.100.1150232553.squirrel@10.20.200.100> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Wed, 14 Jun 2006 11:26:12 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 07:20:02 -0000 Quoting Eric Anderson (from Tue, 13 Jun 2006 =20 16:02:33 -0500 (CDT)): > Alexander Leidinger said: >> Quoting "Eric Anderson" (Tue, 13 Jun 2006 12:33:1= 4 >> -0500 (CDT)): >> >>> >From the subject, you probably already know my dilemma. After booting >>> a >>> linux livecd (I'll refrain from naming the distro), my laptop no longer >>> has any partitions. Now, the drive was not newfs'ed with any other OS, >>> so >>> I believe only the boot loader and partitioning are messed up. I see an >>> ffsrecov tool, that could probably help me, but I want to make sure I >>> don't make any bad decisions here. >>> >>> So, my partitioning was something like: >>> ad0 >>> ad0s1 DOS >>> ad0s2 ?? >>> ad0s3 ?? >>> ad0s4 Linux root / swap >> >> For this particular reason I always print out the layout. Got hit once, >> wrote a program to recover (only understands ufs1 disklabels, and >> stopped to work after a particular 4.x... I assume it's because of a >> blocksize/fragsize change introduced then), learned my lesson. > > I'll probably look into writing such a tool, since this is very painful. := ( You can have a look at =20 http://www.leidinger.net/FreeBSD/ffsrescue.tar.gz to get an idea (I =20 think some offsets are wrong now for UFS1, and UFS2-labels aren't =20 searched) what to do. > Printing is a good idea. :) > > >>> FreeBSD was on either ad0s2 or ad0s3, I can't recall which, but I >>> believe >>> it was ad0s3. I had 3 partitions (/, /alt, /home) and a swap. >>> >>> I'm running the ffsrecov tool now, but it appears to be very slow >>> chugging >>> through the disk. >> >> There are ways to speed such a search up. I assume my own tool tries to >> be too smart (or it's not smart enough, at least it uses wrong >> invariants) for the disklabels. And it only prints assumptions about >> the start of a FreeBSD slice, not about other slice types. > > Is there a good way to identify the bsdlabel, or other partitioning > information from a hexdumped output? You have to look at the superblock magic number at specific offsets. =20 Have a look at the above mentioned code to see what to do for UFS1. It =20 should give you a hint what you want to search for regarding UFS2. Regarding the superblocks: if you remember the blocksize/fragsize you =20 used, you can newfs a md on another system and have a look at which =20 offsets superblocks are generated. For UFS1 the first one is in block =20 16, the second one in block 32. So if you find two superblocks with a =20 distance of 16 blocks, the start of a partition is probably 16 blocks =20 before the first superblock. If you know which partition belongs to =20 which slice (AFAIR "last mounted on" is available in the superblock), =20 you should be able to find the right offsets for the slices. I don't =20 know the numbers for UFS2 out of my head. >>> Is there any additional ways I can find the partitioning scheme, or find >>> the bsdlabel's on the disk? Does anyone know of a command line >>> (dd+some >> >> Try to remember them. If you know how large the partitions have been, >> you just have to write the MBR and everything should work. If nothing >> works, you remembered wrong. > > I have some general guesses as to the sizes. Do you know if any of that > data would be in a dmesg,sysctl,etc type output? I have much of that > logged to an external site I can look at for the details.. Maybe in some geom related output, but I'm not sure. >>> tools/perl/etc) way to find the bsdlabels? >>> >>> Once the bsdlabels are found, then what? >>> >>> Also - if I rewrite the bsdlabel exactly as it was before, I should be >>> in >>> business, correct? >> >> The bsdlabels are still there I assume, it sounds just like your MBR >> got hosed. > > fdisk reports nothing, so I'm sure I just need to put the fdisk > partitioning back. Problem is, I don't know the offsets. I didn't knowed them either. But I remembered the size of the first =20 partition, so I was able to recover at least the first 2 partitions =20 out of my head at that time. Bye, Alexander. --=20 Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 12:05:48 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E17216A41A; Wed, 14 Jun 2006 12:05:48 +0000 (UTC) (envelope-from bruno@clisp.org) Received: from ftp.ilog.fr (ftp.ilog.fr [81.80.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BDFE43D49; Wed, 14 Jun 2006 12:05:46 +0000 (GMT) (envelope-from bruno@clisp.org) Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.1/8.13.1) with ESMTP id k5EC5eeE002970; Wed, 14 Jun 2006 14:05:40 +0200 Received: from marbore.ilog.biz (marbore.ilog.biz [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id k5EC5X6S028958; Wed, 14 Jun 2006 14:05:33 +0200 Received: from honolulu.ilog.fr ([172.16.15.121]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 14:05:49 +0200 Received: by honolulu.ilog.fr (Postfix, from userid 1001) id E741EF1433; Wed, 14 Jun 2006 14:04:08 +0200 (CEST) From: Bruno Haible To: Konstantin Belousov Date: Wed, 14 Jun 2006 14:04:08 +0200 User-Agent: KMail/1.9.1 References: <200606101822.46437.bruno@clisp.org> <20060614103420.GA86300@deviant.kiev.zoral.com.ua> In-Reply-To: <20060614103420.GA86300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606141404.08811.bruno@clisp.org> X-OriginalArrivalTime: 14 Jun 2006 12:05:49.0578 (UTC) FILETIME=[E03A7EA0:01C68FAA] X-Mailman-Approved-At: Wed, 14 Jun 2006 12:08:28 +0000 Cc: Vasil Dimov , hackers@freebsd.org Subject: Re: valid VMA ranges and mincore() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 12:05:48 -0000 Hello Konstantin, Thanks for reacting on this issue. > Please, evaluate the patch. If it does what you need - It doesn't change the manual page mincore.2. - For unmapped areas, it appears to be filling in values of -1 into the array. This is not what Linux, Solaris, NetBSD do: They return -1 from the system call and set errno to ENOMEM. See Linux: http://linux.about.com/library/cmd/blcmdl2_mincore.htm Solaris: http://docs.sun.com/app/docs/doc/816-5167/6mbb2jaib?a=view NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/mincore.2?rev=1.19&content-type=text/plain - Filling in values of -1 into the array will confuse existing applications, because -1 is all bits set, i.e. the nonexistent pages will appear to be in-core, modified, referenced. - Filling in values of -1 into the array could be done more easily by changing the statements in sys/vm/vm_mmap.c lines 861 and 902. Thanks. Bruno From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 13:56:13 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C86E116A479; Wed, 14 Jun 2006 13:56:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA13043D49; Wed, 14 Jun 2006 13:56:12 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k5EDu1wZ041023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 16:56:01 +0300 (EEST) (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.13.6/8.13.6) with ESMTP id k5EDu17s085389; Wed, 14 Jun 2006 16:56:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k5EDu0Ne085388; Wed, 14 Jun 2006 16:56:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Jun 2006 16:56:00 +0300 From: Konstantin Belousov To: Bruno Haible Message-ID: <20060614135600.GB86300@deviant.kiev.zoral.com.ua> References: <200606101822.46437.bruno@clisp.org> <20060614103420.GA86300@deviant.kiev.zoral.com.ua> <200606141404.08811.bruno@clisp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <200606141404.08811.bruno@clisp.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: Vasil Dimov , hackers@freebsd.org Subject: Re: valid VMA ranges and mincore() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 13:56:14 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 14, 2006 at 02:04:08PM +0200, Bruno Haible wrote: > Hello Konstantin, >=20 > Thanks for reacting on this issue. >=20 > > Please, evaluate the patch. If it does what you need >=20 > - It doesn't change the manual page mincore.2. Yes, it was intended. Exactly because I anticipated issues you described below. > - For unmapped areas, it appears to be filling in values of -1 into > the array. This is not what Linux, Solaris, NetBSD do: They return > -1 from the system call and set errno to ENOMEM. See > Linux: http://linux.about.com/library/cmd/blcmdl2_mincore.htm > Solaris: http://docs.sun.com/app/docs/doc/816-5167/6mbb2jaib?a=3Dview > NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/mincore.= 2?rev=3D1.19&content-type=3Dtext/plain > - Filling in values of -1 into the array will confuse existing applicatio= ns, > because -1 is all bits set, i.e. the nonexistent pages will appear to > be in-core, modified, referenced. Ok. See below. I hope that I fixed my problems with comprehension. > - Filling in values of -1 into the array could be done more easily by > changing the statements in sys/vm/vm_mmap.c lines 861 and 902. I do not agree. It zeroes array not only for holes, but also for (some) skipped vm areas. For instance, it happens for freshly allocated anonymous memory that has not faulted any pages still. Index: vm_mmap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/vm/vm_mmap.c,v retrieving revision 1.205 diff -u -r1.205 vm_mmap.c --- vm_mmap.c 21 Apr 2006 07:17:25 -0000 1.205 +++ vm_mmap.c 14 Jun 2006 13:51:20 -0000 @@ -756,8 +756,10 @@ first_addr =3D addr =3D trunc_page((vm_offset_t) uap->addr); end =3D addr + (vm_size_t)round_page(uap->len); map =3D &td->td_proc->p_vmspace->vm_map; - if (end > vm_map_max(map) || end < addr) + if (end < addr) return (EINVAL); + if (end > vm_map_max(map)) + return (ENOMEM); =20 /* * Address of byte vector @@ -770,8 +772,18 @@ RestartScan: timestamp =3D map->timestamp; =20 - if (!vm_map_lookup_entry(map, addr, &entry)) - entry =3D entry->next; + if (!vm_map_lookup_entry(map, first_addr, &entry)) { + vm_map_unlock_read(map); + return (ENOMEM); + } + for (current =3D entry; + (current !=3D &map->header) && (current->end < end); + current =3D current->next) { + if (current->end !=3D current->next->start) { + vm_map_unlock_read(map); + return (ENOMEM); + } + } =20 /* * Do this on a map entry basis so that if the pages are not --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEkBVrC3+MBN1Mb4gRAmZFAJ9l+IK963pIg2T4UOH/5HDGt3rKfACg4EBB CEwdj3EuDfmaSv5cCMpH6GA= =bnEY -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 14:15:28 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C71016A47A; Wed, 14 Jun 2006 14:15:28 +0000 (UTC) (envelope-from bruno@clisp.org) Received: from ftp.ilog.fr (ftp.ilog.fr [81.80.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C31B443D48; Wed, 14 Jun 2006 14:15:27 +0000 (GMT) (envelope-from bruno@clisp.org) Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.1/8.13.1) with ESMTP id k5EEFQpf011299; Wed, 14 Jun 2006 16:15:26 +0200 Received: from marbore.ilog.biz (marbore.ilog.biz [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id k5EEFIEX002011; Wed, 14 Jun 2006 16:15:19 +0200 Received: from honolulu.ilog.fr ([172.16.15.121]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 16:15:34 +0200 Received: by honolulu.ilog.fr (Postfix, from userid 1001) id 287C9F1433; Wed, 14 Jun 2006 16:13:54 +0200 (CEST) From: Bruno Haible To: Konstantin Belousov Date: Wed, 14 Jun 2006 16:13:53 +0200 User-Agent: KMail/1.9.1 References: <200606101822.46437.bruno@clisp.org> <200606141404.08811.bruno@clisp.org> <20060614135600.GB86300@deviant.kiev.zoral.com.ua> In-Reply-To: <20060614135600.GB86300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606141613.54027.bruno@clisp.org> X-OriginalArrivalTime: 14 Jun 2006 14:15:34.0931 (UTC) FILETIME=[00A91630:01C68FBD] X-Mailman-Approved-At: Wed, 14 Jun 2006 14:16:33 +0000 Cc: Vasil Dimov , hackers@freebsd.org Subject: Re: valid VMA ranges and mincore() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:15:28 -0000 Hello Konstantin, > > - Filling in values of -1 into the array could be done more easily by > > changing the statements in sys/vm/vm_mmap.c lines 861 and 902. > I do not agree. It zeroes array not only for holes, but also for (some) > skipped vm areas. ok, you understand the code better than I do :-) > Index: vm_mmap.c > =================================================================== > RCS file: /usr/local/arch/ncvs/src/sys/vm/vm_mmap.c,v > retrieving revision 1.205 > diff -u -r1.205 vm_mmap.c > --- vm_mmap.c 21 Apr 2006 07:17:25 -0000 1.205 > +++ vm_mmap.c 14 Jun 2006 13:51:20 -0000 > @@ -756,8 +756,10 @@ > first_addr = addr = trunc_page((vm_offset_t) uap->addr); > end = addr + (vm_size_t)round_page(uap->len); > map = &td->td_proc->p_vmspace->vm_map; > - if (end > vm_map_max(map) || end < addr) > + if (end < addr) > return (EINVAL); > + if (end > vm_map_max(map)) > + return (ENOMEM); > > /* > * Address of byte vector > @@ -770,8 +772,18 @@ > RestartScan: > timestamp = map->timestamp; > > - if (!vm_map_lookup_entry(map, addr, &entry)) > - entry = entry->next; > + if (!vm_map_lookup_entry(map, first_addr, &entry)) { > + vm_map_unlock_read(map); > + return (ENOMEM); > + } > + for (current = entry; > + (current != &map->header) && (current->end < end); > + current = current->next) { > + if (current->end != current->next->start) { > + vm_map_unlock_read(map); > + return (ENOMEM); > + } > + } > > /* > * Do this on a map entry basis so that if the pages are not > Looks good to me: This does what Linux, NetBSD, Solaris do. Thanks! Bruno From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 14 16:33:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BD5716A56C for ; Wed, 14 Jun 2006 16:33:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3E343D49 for ; Wed, 14 Jun 2006 16:33:26 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA06908 for ; Wed, 14 Jun 2006 19:33:24 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44903A53.9030007@icyb.net.ua> Date: Wed, 14 Jun 2006 19:33:23 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.2 (X11/20060512) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Subject: apic detection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 16:33:30 -0000 What is proper way to check from a driver/module if APIC is being used ? Or even narrower, if local APIC timer is being used ? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 06:55:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3362716A47C for ; Thu, 15 Jun 2006 06:55:33 +0000 (UTC) (envelope-from hongz@promisechina.com) Received: from mxdxt7.hichina.com (mxdxt7.hichina.com [218.244.143.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE19C43D48 for ; Thu, 15 Jun 2006 06:55:29 +0000 (GMT) (envelope-from hongz@promisechina.com) Received: from 222.128.58.137 (HELO hongzhao) (envelope-from hongz@promisechina.com) by mxdxt7.hichina.com (quarkmail-1.2.1) with ESMTP id S5174629AbWFOGzW for freebsd-hackers@freebsd.org; Thu, 15 Jun 2006 14:55:22 +0800 From: To: Date: Thu, 15 Jun 2006 14:55:30 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcaQSLCSSscyl2ZbRzCL7tO+peSsZA== Message-ID: <1150354522$36510$27619252@hongz@promisechina.com> X-Mailman-Approved-At: Thu, 15 Jun 2006 11:28:33 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help:why bus resource shortage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 06:55:33 -0000 Hi guys: I failed to get the pci bus resource after the driver is loaded (sc->r_mem is NULL after bus_alloc_resource_any is called). Is it because bus resources have been consumed by other drivers? Or other something happened? Please help me on this! Thanks! Hong Notes: /* get resources */ rid = 0x10; sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); if (!sc->r_mem) return ENOMEM; The pci resources on our cards: shasta0: port 0x2400-0x247f, 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe9000000-0xe901ffff irq 17 at device 5.0 on pci2 From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 07:04:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 215AD16A47E for ; Thu, 15 Jun 2006 07:04:16 +0000 (UTC) (envelope-from gs_stoller@juno.com) Received: from outbound-mail.nyc.untd.com (outbound-mail.nyc.untd.com [64.136.20.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 72B3C43D49 for ; Thu, 15 Jun 2006 07:04:15 +0000 (GMT) (envelope-from gs_stoller@juno.com) Received: from webmail04.nyc.untd.com (webmail04.nyc.untd.com [10.141.27.144]) by smtpout01.nyc.untd.com with SMTP id AABCKCBU5AAK3MMA for (sender ); Thu, 15 Jun 2006 00:03:55 -0700 (PDT) Received: (from gs_stoller@juno.com) by webmail04.nyc.untd.com (jqueuemail) id LSVW3CSS; Thu, 15 Jun 2006 00:03:00 PDT Received: from [67.84.52.37] by webmail04.nyc.untd.com with HTTP: Thu, 15 Jun 2006 07:02:11 GMT X-Originating-IP: [67.84.52.37] Mime-Version: 1.0 From: "gs_stoller@juno.com" Date: Thu, 15 Jun 2006 07:02:11 GMT To: jhb@freebsd.org, keramida@ceid.upatras.gr, langd-freebsd-hackers@leo.org, anderson@centtech.com, xfb52@dial.pipex.com, parv@pair.com, rizzo@icir.org, darren.pilgrim@bitfreak.org, des@des.no X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20060615.000300.15626.148175@webmail04.nyc.untd.com> X-ContentStamp: 22:11:1941679759 X-UNTD-OriginStamp: /s5f1SIGSI3+WdnoYQ8yRCaKp419qRprifUVXBiIvBy/tc/3oaN5YA== X-UNTD-Peer-Info: 10.141.27.144|webmail04.nyc.untd.com|webmail04.nyc.untd.com|gs_stoller@juno.com X-Mailman-Approved-At: Thu, 15 Jun 2006 11:35:17 +0000 Cc: freebsd-hackers@freebsd.org Subject: Options for boot program X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 07:04:16 -0000 My way of operating is to multi-task almost all the time. As such, while working on one task, if another task on which I am also working (but had to pause in it because some information or equipment that the task needed wasn't available) of higher priority suddenly became available/operable, then I would want to know about this so that I could switch to the higher priority task. Thus I want that the computer should tell me that it needs input for one of its tasks, or that some task is showing output that I may want to see (this usually means error messages rather than standard output). The best way for the computer to tell me these things (i.e., to call my attention to itself) is by sound (because the ear detects from all around, while the eye detects only from in front of itself [so I would have to be looking at the screen]). Thus I can do other things and be called back to the computer as needed. Hence I want the boot program to sound a bell (possibly several times with a short interval to wait between successive times, and proceed immediately when I respond [and not wait for a set # of bells to be sounded]) if it is waiting for input (say, as to which slice to boot), and the amount of time (in seconds) that it waits for that input, and if it doesn't get any input before this time period expires, it boots the current default slice. I want to set the length of this time period (to wait before booting the current default slice). I realize that other users of the boot program may want it to behave differently than I do. Consequently, each user should be able to tell the boot program how he wants it to behave regarding these matters, and other matters that some user may be able to describe. A programmer of the boot program should not impose his preferences on the users of the boot program, but code in a way that allows them to get their preferred operation from the boot program. This can't be easily/safely done by options in the call of the boot program because the boot program isn't called (as we are familiar with it). It is read into RAM from the boot sector and then control is transferred to it, and all this is done by the BIOS or a small program built into the hardware of a computer. One way to make the boot program aware of a user's preferences is to store these preferences (options) in the boot sector, say the last byte or two of that sector. That way, this data will not have a chance of being in the midst of code. The setting of these bytes can be done as part of the installation of the boot program, and/or have a special patch program that patches just this area (even after installation so if the owner wants to change his options after installation, he can easily do so). I would like to suggest some minor changes to the boot program for FreeBSD , mainly in the area of options that the user can set when installing it. Hopefully the space available for the boot program will be big enough to allow these changes. By the way, is there more space available (e.g., more sectors on the platter/cylinder) for the boot program? Where can one get the code for the boot? Also, how much space is available for the boot code? Also, can one add more slices (so there are more than 4) to the system, and have ways of booting them. Another thing that could be done is to introduce "logical slice" (the term has been used before), say by allowing more than 8 partitions per slice and allowing the user to be able to specify which set of 5 to mount (and these 5 form a "logical slice"). From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 10:56:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9527416A474; Thu, 15 Jun 2006 10:56:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4F643D46; Thu, 15 Jun 2006 10:56:33 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k5FAtdxi000674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 13:55:43 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k5FAvt2a016391; Thu, 15 Jun 2006 13:57:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k5FAvloh016390; Thu, 15 Jun 2006 13:57:47 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) To: "gs_stoller@juno.com" References: <20060615.000300.15626.148175@webmail04.nyc.untd.com> From: Giorgos Keramidas Date: Thu, 15 Jun 2006 13:57:47 +0300 In-Reply-To: <20060615.000300.15626.148175@webmail04.nyc.untd.com> (gs's message of "Thu, 15 Jun 2006 07:02:11 GMT") Message-ID: <86y7vyr8ic.fsf@gothmog.pc> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.171, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.23, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No X-Mailman-Approved-At: Thu, 15 Jun 2006 11:35:31 +0000 Cc: darren.pilgrim@bitfreak.org, xfb52@dial.pipex.com, parv@pair.com, rizzo@icir.org, freebsd-hackers@freebsd.org, des@des.no Subject: Re: Options for boot program X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 10:56:34 -0000 On Thu, 15 Jun 2006 07:02:11 GMT, "gs_stoller@juno.com" wrote: > My way of operating is to multi-task almost all the time [...] > > Hence I want the boot program to sound a bell (possibly several > times with a short interval to wait between successive times, and > proceed immediately when I respond [and not wait for a set # of bells > to be sounded]) if it is waiting for input [...] > > I realize that other users of the boot program may want it to > behave differently than I do. Consequently, each user should be able > to tell the boot program how he wants it to behave regarding these > matters, and other matters that some user may be able to describe [...] > > One way to make the boot program aware of a user's preferences > is to store these preferences (options) in the boot sector [...] I apologise in advance if excessive snipping was done above, but I tried to keep your major points intact. I don't think it is a good idea to try to cram more features in the severely limited space the boot0 stage currently has. The entire boot0 object code should fit in less than 512 bytes (some of that space is used to store the BIOS-partition table too). Adding more and more features every time we want to extend it will quickly make it either buggy or unusable for the majority of the people who currently use it. On the other hand, there are other boot managers, which can use more space and are not as limited. It may be a good idea to try one of those and extend it to cover your needs. A very featureful and nice option is GRUB, which -AFAIK- currently supports Windows, Linux, FreeBSD, Solaris and a few other OSes. Unfortunately, the GRUB port of FreeBSD is i386-only, so if you are running something else (sparc64 or amd64), it is impossible to use it. I'd put my own money into porting GRUB to work with all the major architectures currently supported by FreeBSD. Then, I would add the features you like to GRUB, which already includes an extended set of configuration options and can easily incorporate more. > I would like to suggest some minor changes to the boot program for > FreeBSD , mainly in the area of options that the user can set when > installing it. Hopefully the space available for the boot program > will be big enough to allow these changes. By the way, is there more > space available (e.g., more sectors on the platter/cylinder) for the > boot program? Not much space is available. > Where can one get the code for the boot? The source code for the boot0-stage loader is: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot0/boot0.S > Also, how much space is available for the boot code? A very small number of bytes. Forget about this, if you ask me... - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 12:16:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4951816A41A for ; Thu, 15 Jun 2006 12:16:03 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA8A143D46 for ; Thu, 15 Jun 2006 12:16:02 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so268172wxd for ; Thu, 15 Jun 2006 05:16:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TG56nGSJwiz8J4/2T5sLmn2KJxFbdH7muhd4yUkGV0+A7GeBg9apy6aLYrnDBfD/DfwsEJvpRPiWULJ4QaSN86fF57HA7TyWOIsCOoyGhrbPPIE8e4v9R2cocQ9l7bgNNW8dLPp8TKGGigXYMtsffR96+o0zF7/q3g8hJ3bTaIU= Received: by 10.70.23.17 with SMTP id 17mr2123939wxw; Thu, 15 Jun 2006 05:15:54 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Thu, 15 Jun 2006 05:15:54 -0700 (PDT) Message-ID: <3bbf2fe10606150515p58bc62c3p3edc58495b15a22f@mail.gmail.com> Date: Thu, 15 Jun 2006 14:15:54 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "hongz@promisechina.com" , freebsd-hackers@freebsd.org In-Reply-To: <5769599057805718758@unknownmsgid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5769599057805718758@unknownmsgid> X-Google-Sender-Auth: a95847b78243cfe3 Cc: Subject: Re: Help:why bus resource shortage? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 12:16:03 -0000 2006/6/15, hongz@promisechina.com : > Hi guys: > > > > I failed to get the pci bus resource after the driver is loaded (sc->r_mem > is NULL after bus_alloc_resource_any is called). Is it because bus resources > have been consumed by other drivers? Or other something happened? Please > help me on this! > > > > Thanks! > > > > Hong > > > > Notes: > > /* get resources */ > > rid = 0x10; > > sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid, > RF_ACTIVE); > > if (!sc->r_mem) return ENOMEM; > > > > The pci resources on our cards: > > shasta0: port 0x2400-0x247f, > 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe9000000-0xe901ffff irq 17 at > device 5.0 on pci2 I suspect your PCI BAR pointer is wrong. Are you sure about its value? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 14:04:35 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4406816A47C for ; Thu, 15 Jun 2006 14:04:35 +0000 (UTC) (envelope-from szyderca@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id A25EA43D46 for ; Thu, 15 Jun 2006 14:04:34 +0000 (GMT) (envelope-from szyderca@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so403682nzf for ; Thu, 15 Jun 2006 07:04:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=H6tLwTRLTDTndsyKlkKIUKNgKU+rb/o7GXwuQCRWzyunj+QFKyoftlSPffMUMUP9c/zir+Pmk4KKYUMiJWxz0WTZvlmGOEbujtVqYOls50lcaEjBp7MVGnSLggqGKeADqymLW8rxhBU3rpKTrUAxgVT647kdby3xzxzOewG5Ut0= Received: by 10.37.22.35 with SMTP id z35mr2641788nzi; Thu, 15 Jun 2006 07:04:34 -0700 (PDT) Received: by 10.36.96.13 with HTTP; Thu, 15 Jun 2006 07:04:34 -0700 (PDT) Message-ID: Date: Thu, 15 Jun 2006 16:04:34 +0200 From: "Marcin Cylke" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: interfacing uhid devs from kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:04:35 -0000 Hello Is it possible to use functions from libusbhid in kernel module? It would really ease some things for me, but I realize it is a userland library. Still, is there some way to do this? Bye Marcin Cylke From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 14:09:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E08B16A474 for ; Thu, 15 Jun 2006 14:09:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from mail48.e.nsc.no (mail48.e.nsc.no [193.213.115.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EA643D46 for ; Thu, 15 Jun 2006 14:09:32 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from Unknown-00-c0-9f-49-78-d8.lan (ti131310a080-15519.bb.online.no [85.165.252.159]) by mail48.nsc.no (8.13.6/8.13.5) with ESMTP id k5FE9Tnk002285; Thu, 15 Jun 2006 16:09:30 +0200 (CEST) From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 15 Jun 2006 16:09:34 +0200 User-Agent: KMail/1.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151609.35267.hselasky@c2i.net> Cc: Marcin Cylke Subject: Re: interfacing uhid devs from kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:09:33 -0000 On Thursday 15 June 2006 16:04, Marcin Cylke wrote: > Hello > Is it possible to use functions from libusbhid in kernel module? It > would really ease some things for me, but I realize it is a userland > library. Still, is there some way to do this? > What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 14:20:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEBFD16A492 for ; Thu, 15 Jun 2006 14:20:47 +0000 (UTC) (envelope-from flz@FreeBSD.org) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B75343D4C for ; Thu, 15 Jun 2006 14:20:47 +0000 (GMT) (envelope-from flz@FreeBSD.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 77DF1114B5; Thu, 15 Jun 2006 16:20:42 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23312-02; Thu, 15 Jun 2006 16:20:37 +0200 (CEST) Received: from mayday.esat.net (mayday.esat.net [193.95.134.156]) by smtp.xbsd.org (Postfix) with ESMTP id AAC8211443; Thu, 15 Jun 2006 16:20:36 +0200 (CEST) From: Florent Thoumie To: Naram Qashat In-Reply-To: <00cf01c68f66$3de93e50$fe02a8c0@metroid> References: <61325.10.20.200.100.1150219994.squirrel@10.20.200.100> <00cf01c68f66$3de93e50$fe02a8c0@metroid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qtadWPuYaTUJD0YKwd/K" Date: Thu, 15 Jun 2006 15:20:34 +0100 Message-Id: <1150381234.28739.1.camel@mayday.esat.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: fdisk partition / disklabel recovery (help!) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:20:48 -0000 --=-qtadWPuYaTUJD0YKwd/K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2006-06-13 at 23:54 -0400, Naram Qashat wrote: > You've also got the choice of using the program testdisk in > sysutils/testdisk to try to fix your problem. It helped me when I > accidently hosed the MBR and partition table on one of my drives. I second this (because it saved my life, not because I'm the maintainer).=20 --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer --=-qtadWPuYaTUJD0YKwd/K Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEkWyyMxEkbVFH3PQRAskEAJ9RSC8xBKqkF7RQujW7RlOcLjua8gCdH68l gNea6eEUvkkm2id0GrS7tSU= =ld3a -----END PGP SIGNATURE----- --=-qtadWPuYaTUJD0YKwd/K-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 14:56:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 065E816A47A for ; Thu, 15 Jun 2006 14:56:44 +0000 (UTC) (envelope-from aanton@spintech.ro) Received: from smtpx.spintech.ro (smtpx.spintech.ro [81.180.92.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9851743D48 for ; Thu, 15 Jun 2006 14:56:43 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from [10.0.0.2] (beastie [10.0.0.2]) by smtpx.spintech.ro (Postfix) with ESMTP id 35CD73A4B0 for ; Thu, 15 Jun 2006 15:26:13 +0000 (UTC) Message-ID: <44917529.60704@spintech.ro> Date: Thu, 15 Jun 2006 17:56:41 +0300 From: Alin-Adrian Anton Organization: Spintech Security Systems User-Agent: Mozilla Thunderbird 1.0 (X11/20041229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: ipw3945 intel wireless miniPCI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aanton@spintech.ro List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:56:44 -0000 Hi Hackers, Did anyone manage to get this card working under FreeBSD? I'm using FreeBSD 6.1_REL0 on my laptop. I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear to work on 3945. I know about ipw3945.sourceforge.net, there's an opensource stable driver for linux. Any help/tip is greatly appreciated. Thanks. Yours, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 15:51:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DDD16A41A for ; Thu, 15 Jun 2006 15:51:06 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7441943D45 for ; Thu, 15 Jun 2006 15:51:04 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0W006SJS129A@ms-dienst.rz.rwth-aachen.de> for freebsd-hackers@freebsd.org; Thu, 15 Jun 2006 17:51:03 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Thu, 15 Jun 2006 17:51:02 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k5FFp1IM018544; Thu, 15 Jun 2006 17:51:01 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Fqu7a-0002N5-CY; Thu, 15 Jun 2006 17:51:02 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 154D73F431; Thu, 15 Jun 2006 17:51:02 +0200 (CEST) Date: Thu, 15 Jun 2006 17:51:01 +0200 From: Christian Brueffer In-reply-to: <44917529.60704@spintech.ro> To: Alin-Adrian Anton Message-id: <20060615155101.GA1410@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary="J2SCkAp4GZ/dPZZf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.1-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <44917529.60704@spintech.ro> Cc: freebsd-hackers@freebsd.org Subject: Re: ipw3945 intel wireless miniPCI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 15:51:06 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: > Hi Hackers, >=20 > Did anyone manage to get this card working under FreeBSD? I'm using=20 > FreeBSD 6.1_REL0 on my laptop. >=20 > I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear=20 > to work on 3945. I know about ipw3945.sourceforge.net, there's an=20 > opensource stable driver for linux. >=20 > Any help/tip is greatly appreciated. Thanks. >=20 Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD has support for it in CURRENT in form of the wpi(4) driver. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEkYHlbHYXjKDtmC0RAlx/AKDaoiBgQUFrik9iLvTDDCKsOPtGJwCg9qdO Yc2iaQp0X8eZBk5jsl5tA54= =ZhbG -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 16:50:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF52016A474 for ; Thu, 15 Jun 2006 16:50:20 +0000 (UTC) (envelope-from szyderca@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10D9F43D48 for ; Thu, 15 Jun 2006 16:50:19 +0000 (GMT) (envelope-from szyderca@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so441698nzf for ; Thu, 15 Jun 2006 09:50:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WlslLE1sXg0kJsho+uJ9E9hWWC/Ya4YiZ/Ds2ZVDtPWlOkNbBUgXdE+M/eOt/a9RBpWMW+C10tJw60irfIsIlD+93H047YcenXWdbSZ8hReyPjpPyhikIgXPd+e+SZBBqD+unf4oNTZiMGVeP9kFVetZSHGEo4pDyDPSJtXpzbA= Received: by 10.36.41.16 with SMTP id o16mr2846951nzo; Thu, 15 Jun 2006 09:44:11 -0700 (PDT) Received: by 10.36.96.13 with HTTP; Thu, 15 Jun 2006 09:44:11 -0700 (PDT) Message-ID: Date: Thu, 15 Jun 2006 18:44:11 +0200 From: "Marcin Cylke" To: freebsd-hackers@freebsd.org In-Reply-To: <200606151609.35267.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606151609.35267.hselasky@c2i.net> Subject: Re: interfacing uhid devs from kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:50:21 -0000 On 6/15/06, Hans Petter Selasky wrote: > What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? I would like to use the whole infrastructure: struct hid_item hid_usage_page() hid_usage_in_page() hid_init() hid_get_report_desc() Bye From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 17:02:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EFC116A41A for ; Thu, 15 Jun 2006 17:02:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9127643D46 for ; Thu, 15 Jun 2006 17:02:05 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id s17so301362wxc for ; Thu, 15 Jun 2006 10:02:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XhyeowC6jsFm1smjAMS3A5X333LQ25iOldImSORXpqqw1PcKfHmawbthUNlFJuITZbD4UNXQj69mhEonR5RuIE7we73PAtJV0P4gCECm8dwxJXDRUrRTmUCU/xyw1Xog1202sbjd0PJYzTXVZYp3y9p7aXGKIgfst3o7bgWEwq0= Received: by 10.70.103.16 with SMTP id a16mr2528846wxc; Thu, 15 Jun 2006 10:02:04 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Thu, 15 Jun 2006 10:02:04 -0700 (PDT) Message-ID: <3bbf2fe10606151002k3f0ef021o1361a3cc8f3a469b@mail.gmail.com> Date: Thu, 15 Jun 2006 19:02:04 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Marcin Cylke" , "Hans Petter Selasky" , freebsd-hackers@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606151609.35267.hselasky@c2i.net> X-Google-Sender-Auth: f34849b6ef5b559b Cc: Subject: Re: interfacing uhid devs from kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:02:06 -0000 2006/6/15, Marcin Cylke : > On 6/15/06, Hans Petter Selasky wrote: > > > What functions do you need? Have you looked at uhid.c under /sys/dev/usb ? > > I would like to use the whole infrastructure: > struct hid_item > hid_usage_page() > hid_usage_in_page() > hid_init() > hid_get_report_desc() Give a look at USB mouse (ums.c) which give a good overview about HID kernelspace API. However I don't know if Hans has plans to change it in the new stack... Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 17:51:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7494616A474; Thu, 15 Jun 2006 17:51:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from mail42.e.nsc.no (mail42.e.nsc.no [193.213.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D696243D48; Thu, 15 Jun 2006 17:51:46 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from Unknown-00-c0-9f-49-78-d8.lan (ti131310a080-6417.bb.online.no [85.165.217.17]) by mail42.nsc.no (8.13.6/8.13.5) with ESMTP id k5FHpg2K012720; Thu, 15 Jun 2006 19:51:43 +0200 (CEST) From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 15 Jun 2006 19:51:46 +0200 User-Agent: KMail/1.7 References: <3bbf2fe10606151002k3f0ef021o1361a3cc8f3a469b@mail.gmail.com> In-Reply-To: <3bbf2fe10606151002k3f0ef021o1361a3cc8f3a469b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151951.48171.hselasky@c2i.net> Cc: Attilio Rao , Marcin Cylke , Hans Petter Selasky Subject: Re: interfacing uhid devs from kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 17:51:47 -0000 On Thursday 15 June 2006 19:02, Attilio Rao wrote: > 2006/6/15, Marcin Cylke : > > On 6/15/06, Hans Petter Selasky wrote: > > > What functions do you need? Have you looked at uhid.c under > > > /sys/dev/usb ? > > > > I would like to use the whole infrastructure: > > struct hid_item > > hid_usage_page() > > hid_usage_in_page() > > hid_init() > > hid_get_report_desc() > > Give a look at USB mouse (ums.c) which give a good overview about HID > kernelspace API. > > However I don't know if Hans has plans to change it in the new stack... I have changed it a little bit, but I don't have any plans to change it further. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 18:17:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B82616A474 for ; Thu, 15 Jun 2006 18:17:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCA0F43D45 for ; Thu, 15 Jun 2006 18:17:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5FIGxYM049462; Thu, 15 Jun 2006 14:16:59 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 15 Jun 2006 13:10:33 -0400 User-Agent: KMail/1.9.1 References: <44903A53.9030007@icyb.net.ua> In-Reply-To: <44903A53.9030007@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151310.34246.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 15 Jun 2006 14:17:00 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1539/Wed Jun 14 10:21:49 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Andriy Gapon Subject: Re: apic detection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:17:02 -0000 On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: > > What is proper way to check from a driver/module if APIC is being used ? > Or even narrower, if local APIC timer is being used ? There isn't currently. Why do you need to know? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 18:23:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23EFB16A474; Thu, 15 Jun 2006 18:23:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1516243D45; Thu, 15 Jun 2006 18:23:57 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA02552; Thu, 15 Jun 2006 21:23:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4491A5BA.9060801@icyb.net.ua> Date: Thu, 15 Jun 2006 21:23:54 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.2 (X11/20060512) MIME-Version: 1.0 To: John Baldwin References: <44903A53.9030007@icyb.net.ua> <200606151310.34246.jhb@freebsd.org> In-Reply-To: <200606151310.34246.jhb@freebsd.org> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: apic detection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:23:59 -0000 on 15/06/2006 20:10 John Baldwin said the following: > On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: >> What is proper way to check from a driver/module if APIC is being used ? >> Or even narrower, if local APIC timer is being used ? > > There isn't currently. Why do you need to know? > There is a driver that I am working on that could change frequency of local APIC timer by changing FSB frequency and I want to make that driver smarter and refuse to attach if local APIC timer is used. I know that in 6.X and CURRENT local APIC timer is always used and in 5.X it is never used, but I want my driver to handle environment more generally. I am thinking, can I just somehow check if IRQ0 is in use ? Would it be something close to proper solution ? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 18:17:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB11116A479 for ; Thu, 15 Jun 2006 18:17:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C83C543D58 for ; Thu, 15 Jun 2006 18:17:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5FIGxYP049462; Thu, 15 Jun 2006 14:17:05 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "gs_stoller@juno.com" Date: Thu, 15 Jun 2006 14:16:52 -0400 User-Agent: KMail/1.9.1 References: <20060615.000300.15626.148175@webmail04.nyc.untd.com> In-Reply-To: <20060615.000300.15626.148175@webmail04.nyc.untd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151416.54452.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 15 Jun 2006 14:17:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1539/Wed Jun 14 10:21:49 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Mailman-Approved-At: Thu, 15 Jun 2006 18:33:22 +0000 Cc: darren.pilgrim@bitfreak.org, xfb52@dial.pipex.com, parv@pair.com, rizzo@icir.org, freebsd-hackers@freebsd.org, keramida@ceid.upatras.gr, des@des.no Subject: Re: Options for boot program X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:17:39 -0000 I can identify with your condition. :) Unfortunately, the early boot loaders (boot0, and boot1+boot2) are simply too tight on space to add more features. I think boot0 literally has 0 or 1 bytes free right now. However /boot/loader has a lot more free space and can be easily and intuitively configured via /boot/loader.conf. All of the boot code can be found under src/sys/boot. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 20:22:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA2516A41A for ; Thu, 15 Jun 2006 20:22:28 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A4D743D53 for ; Thu, 15 Jun 2006 20:22:11 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0X00BEJ4KXZB@ms-dienst.rz.rwth-aachen.de> for freebsd-hackers@freebsd.org; Thu, 15 Jun 2006 22:22:10 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Thu, 15 Jun 2006 22:22:09 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k5FKM8RK013068; Thu, 15 Jun 2006 22:22:08 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FqyLx-0003MQ-6t; Thu, 15 Jun 2006 22:22:09 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 094243F40A; Thu, 15 Jun 2006 22:22:08 +0200 (CEST) Date: Thu, 15 Jun 2006 22:22:08 +0200 From: Christian Brueffer In-reply-to: <20060615155101.GA1410@haakonia.hitnet.RWTH-Aachen.DE> Message-id: <20060615202208.GB2310@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary=GID0FwUMdk1T2AWN; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.1-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <44917529.60704@spintech.ro> <20060615155101.GA1410@haakonia.hitnet.RWTH-Aachen.DE> Cc: freebsd-hackers@freebsd.org, Alin-Adrian Anton Subject: Re: ipw3945 intel wireless miniPCI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 20:22:28 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 15, 2006 at 05:51:01PM +0200, Christian Brueffer wrote: > On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: > > Hi Hackers, > >=20 > > Did anyone manage to get this card working under FreeBSD? I'm using=20 > > FreeBSD 6.1_REL0 on my laptop. > >=20 > > I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear=20 > > to work on 3945. I know about ipw3945.sourceforge.net, there's an=20 > > opensource stable driver for linux. > >=20 > > Any help/tip is greatly appreciated. Thanks. > >=20 >=20 > Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD > has support for it in CURRENT in form of the wpi(4) driver. >=20 That should read the OpenBSD driver is still very much a work in progress, so don't get your hopes too high. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEkcFwbHYXjKDtmC0RAhTBAJ9UIbCx9lHvGAfTFLbHyS/nII430ACeOYCD SCKelBs92SVTS24bfUqKFDY= =hitr -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 21:07:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3360E16A47E for ; Thu, 15 Jun 2006 21:07:45 +0000 (UTC) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id B774243D53 for ; Thu, 15 Jun 2006 21:07:44 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from [10.242.169.24] (c-67-171-135-169.hsd1.or.comcast.net [67.171.135.169]) by mail.bitfreak.org (Postfix) with ESMTP id 4B50617596 for ; Thu, 15 Jun 2006 14:07:43 -0700 (PDT) Message-ID: <4491CC20.8000007@bitfreak.org> Date: Thu, 15 Jun 2006 14:07:44 -0700 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20060615.000300.15626.148175@webmail04.nyc.untd.com> <86y7vyr8ic.fsf@gothmog.pc> In-Reply-To: <86y7vyr8ic.fsf@gothmog.pc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Jun 2006 21:17:36 +0000 Subject: Re: Options for boot program X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 21:07:45 -0000 I don't know why I was included in the CC list for this thread, nor do I have any input on the subject. Please trim my address from the CC list. Thanks. -- Darren Pilgrim From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 21:19:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AEE616A47A for ; Thu, 15 Jun 2006 21:19:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E73843D76 for ; Thu, 15 Jun 2006 21:19:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5FLJiYN050549; Thu, 15 Jun 2006 17:19:47 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Thu, 15 Jun 2006 17:08:09 -0400 User-Agent: KMail/1.9.1 References: <44903A53.9030007@icyb.net.ua> <200606151310.34246.jhb@freebsd.org> <4491A5BA.9060801@icyb.net.ua> In-Reply-To: <4491A5BA.9060801@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606151708.10218.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 15 Jun 2006 17:19:47 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1541/Thu Jun 15 15:36:31 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: apic detection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 21:19:54 -0000 On Thursday 15 June 2006 14:23, Andriy Gapon wrote: > on 15/06/2006 20:10 John Baldwin said the following: > > On Wednesday 14 June 2006 12:33, Andriy Gapon wrote: > >> What is proper way to check from a driver/module if APIC is being used ? > >> Or even narrower, if local APIC timer is being used ? > > > > There isn't currently. Why do you need to know? > > > > There is a driver that I am working on that could change frequency of > local APIC timer by changing FSB frequency and I want to make that > driver smarter and refuse to attach if local APIC timer is used. I know > that in 6.X and CURRENT local APIC timer is always used and in 5.X it is > never used, but I want my driver to handle environment more generally. It it always used if APIC is used. > I am thinking, can I just somehow check if IRQ0 is in use ? Would it be > something close to proper solution ? On x86 there is a variable called 'using_lapic_timer' that is available in sys/i386/isa/clock.c (and the amd64 equivalent), but I think it is static to that file, so you probably can't get to it. Other than that there really isn't a current way to know as the vast majority of the system does not (and should not) know or care. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 15 22:46:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D88216A47A for ; Thu, 15 Jun 2006 22:46:56 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41B0F43D4C for ; Thu, 15 Jun 2006 22:46:53 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k5FMklJg081090 for ; Fri, 16 Jun 2006 02:46:47 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k5FMklhn081089 for freebsd-hackers@freebsd.org; Fri, 16 Jun 2006 02:46:47 +0400 (MSD) (envelope-from yar) Date: Fri, 16 Jun 2006 02:46:47 +0400 From: Yar Tikhiy To: freebsd-hackers@freebsd.org Message-ID: <20060615224646.GA79952@comp.chem.msu.su> References: <20060516071240.GA6338@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060516071240.GA6338@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Subject: Re: Stack frame problem in gdb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 22:46:56 -0000 On Tue, May 16, 2006 at 11:12:40AM +0400, Yar Tikhiy wrote: > > Has our stock GDB lost the ability to set the current stack frame > by its address? In 4.11-STABLE, the old recipe from the Developer's > Handbook still works: > > frame > > Alas, it no longer works in RELENG_6 or CURRENT (tested on i386 and > amd64.) A sample typescript is attached. It boils down to the > following: The "frame" command accepts one argument at most in the > new GDB, which is taken for the address of a frame if it's sufficiently > large. Refusing now to read the instruction pointer value from the > command line, GDB sets it to 0 -- a smart guess, damn it. Finally, > GDB crashes on the bogus frame it made up. It seems to be a genuine GDB 6 i386 bug reported as early as in 2002: . It exists in Linux, too, as tested in Debian with GDB 6.3. Moreover, GDB 6 fails to assign correct addresses to stack frames. This might be related to the former issue, as testing on alpha showed (see below.) Does anybody know GDB folks who can help in fixing the issues? Example: %%% GDB 6 i386 %%% (gdb) i f 2 Stack frame at 0xbfbfeca8: eip = 0x80484ac in b (test.c:13); saved eip 0x80484b8 called by frame at 0xbfbfecb0, caller of frame at 0xbfbfeca0 source language c. Arglist at 0xbfbfeca0, args: Locals at 0xbfbfeca0, Previous frame's sp is 0xbfbfeca8 Saved registers: ebp at 0xbfbfeca0, eip at 0xbfbfeca4 (gdb) i f 3 Stack frame at 0xbfbfecb0: eip = 0x80484b8 in c (test.c:18); saved eip 0x80484dd called by frame at 0xbfbfecd0, caller of frame at 0xbfbfeca8 source language c. Arglist at 0xbfbfeca8, args: Locals at 0xbfbfeca8, Previous frame's sp is 0xbfbfecb0 Saved registers: ebp at 0xbfbfeca8, eip at 0xbfbfecac ### The frame addresses were off by one frame. It was a coincidence, ### as the following tests on alpha will show. The addresses are just ### bogus. %%% GDB 6 alpha %%% (gdb) i f 2 Stack frame at 0x11ffeb80: pc = 0x12000087c in b (test.c:13); saved pc 0x1200008ac called by frame at 0x11ffeb90, caller of frame at 0x11ffeb70 source language c. Arglist at 0x11ffeb80, args: Locals at 0x11ffeb80, Previous frame's sp is 0x11ffeb80 Saved registers: fp at 0x11ffeb78, ra at 0x11ffeb70, pc at 0x11ffeb70 (gdb) i f 3 Stack frame at 0x11ffeb90: pc = 0x1200008ac in c (test.c:18); saved pc 0x1200008dc called by frame at 0x11ffeba0, caller of frame at 0x11ffeb80 source language c. Arglist at 0x11ffeb90, args: Locals at 0x11ffeb90, Previous frame's sp is 0x11ffeb90 Saved registers: fp at 0x11ffeb88, ra at 0x11ffeb80, pc at 0x11ffeb80 ### The frame addresses were just bogus. ### Let's look at frame 2 by its address: (gdb) i f 0x11ffeb80 0x12000087c Stack frame at 0x11ffeb80: pc = 0x12000087c in b (test.c:14); saved pc 0x12000084c called by frame at 0x11ffeb70 source language c. Arglist at 0x11ffeb60, args: Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60 Saved registers: fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50 ### It's not frame 2! Which frame is it?.. (gdb) i f 0 Stack frame at 0x11ffeb60: pc = 0x120000810 in x (test.c:3); saved pc 0x12000084c called by frame at 0x11ffeb70 source language c. Arglist at 0x11ffeb60, args: Locals at 0x11ffeb60, Previous frame's sp is 0x11ffeb60 Saved registers: fp at 0x11ffeb58, ra at 0x11ffeb50, pc at 0x11ffeb50 ### Oops, GDB showed us frame 0 when we tried to look at ### the frame @ 0x11ffeb80! %%% GDB 4 i386 %%% (gdb) i f 2 Stack frame at 0xbfbff6f0: eip = 0x804849f in b (test.c:13); saved eip 0x80484b7 called by frame at 0xbfbff700, caller of frame at 0xbfbff6e0 source language c. Arglist at 0xbfbff6f0, args: Locals at 0xbfbff6f0, Previous frame's sp is 0x0 Saved registers: ebp at 0xbfbff6f0, eip at 0xbfbff6f4 (gdb) i f 3 Stack frame at 0xbfbff700: eip = 0x80484b7 in c (test.c:18); saved eip 0x80484cf called by frame at 0xbfbff710, caller of frame at 0xbfbff6f0 source language c. Arglist at 0xbfbff700, args: Locals at 0xbfbff700, Previous frame's sp is 0x0 Saved registers: ebp at 0xbfbff700, eip at 0xbfbff704 ### The good old GDB 4 was working OK... -- Yar P.S. The program used for the tests was as follows: x() { return 1; } a() { return x(); } b() { return a(); } c() { return b(); } main() { return c(); } From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 01:40:21 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6372E16A47A; Fri, 16 Jun 2006 01:40:21 +0000 (UTC) (envelope-from aanton@spintech.ro) Received: from smtpx.spintech.ro (smtpx.spintech.ro [81.180.92.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B7C543D45; Fri, 16 Jun 2006 01:40:21 +0000 (GMT) (envelope-from aanton@spintech.ro) Received: from [10.0.0.2] (beastie [10.0.0.2]) by smtpx.spintech.ro (Postfix) with ESMTP id 11D663A4B0; Fri, 16 Jun 2006 02:09:45 +0000 (UTC) Message-ID: <44920BFB.3080309@spintech.ro> Date: Fri, 16 Jun 2006 04:40:11 +0300 From: Alin-Adrian Anton Organization: Spintech Security Systems User-Agent: Mozilla Thunderbird 1.0 (X11/20041229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Brueffer References: <44917529.60704@spintech.ro> <20060615155101.GA1410@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20060615155101.GA1410@haakonia.hitnet.RWTH-Aachen.DE> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: ipw3945 intel wireless miniPCI X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aanton@spintech.ro List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 01:40:21 -0000 Christian Brueffer wrote: > On Thu, Jun 15, 2006 at 05:56:41PM +0300, Alin-Adrian Anton wrote: > >>Hi Hackers, >> >> Did anyone manage to get this card working under FreeBSD? I'm using >>FreeBSD 6.1_REL0 on my laptop. >> >> I know the /usr/ports/net-firmware/ is for IPW2100. Doesn't appear >> to work on 3945. I know about ipw3945.sourceforge.net, there's an >>opensource stable driver for linux. >> >> Any help/tip is greatly appreciated. Thanks. >> > > > Unfortunately there is no support in FreeBSD for this chip yet. OpenBSD > has support for it in CURRENT in form of the wpi(4) driver. > > - Christian > Thank you for the information. Regards, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 07:53:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D7D16A47A; Fri, 16 Jun 2006 07:53:33 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.232.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D14243D48; Fri, 16 Jun 2006 07:53:30 +0000 (GMT) (envelope-from daichi@freebsd.org) Received: from [192.168.1.101] (dullmdaler.ongs.co.jp [202.216.232.62]) by natial.ongs.co.jp (Postfix) with ESMTP id E68B1244C3A; Fri, 16 Jun 2006 16:53:29 +0900 (JST) Message-ID: <44926377.5000005@freebsd.org> Date: Fri, 16 Jun 2006 16:53:27 +0900 From: Daichi GOTO User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jun 2006 11:41:43 +0000 Cc: ozawa@ongs.co.jp, dkirhlarov@oilspace.com, daichi@freebsd.org, freebsd-listen@fabiankeil.de, meianoite@gmail.com, kris@obsecurity.org, Alexander@Leidinger.net, saturnero@freesbie.org Subject: [ANN] unionfs patchset-14 release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 07:53:33 -0000 Hi Guys! It is my pleasure and honor to announce the availability of the unionfs patchset-14. Patchset-14: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p14.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p14.diff Changes in unionfs-p14.diff - Added a patch of mount_unionfs.8. It means that this patchset is ready to be merged to FreeBSD base system. (hrs contributed it, thanks) - Fixed a problem that sets EXTATTR(ACL, MAC) information to lower layer files and directories. - Removed the third terms of the BSD License to get more easy to handle for FreeBSD. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) We think that patchset-14 is ready to be merged to FreeBSD base system with the production level high quality :) Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 15:45:58 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B2116A481 for ; Fri, 16 Jun 2006 15:45:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6113043D48 for ; Fri, 16 Jun 2006 15:45:58 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k5GFjvqr042177; Fri, 16 Jun 2006 08:45:57 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k5GFjvGS042176; Fri, 16 Jun 2006 08:45:57 -0700 (PDT) (envelope-from david) Date: Fri, 16 Jun 2006 08:45:56 -0700 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20060616154556.GI32476@bunrab.catwhisker.org> References: <20060615232240.GX32476@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xfF7EeK4BVJ+jDf" Content-Disposition: inline In-Reply-To: <20060615232240.GX32476@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:45:59 -0000 --+xfF7EeK4BVJ+jDf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote: > I had one of these [kernel panics] a couple of weeks ago or so... > ...[upgrade to -STABLE as of 15 June; repeat panic]... The message to which I'm replying (posted to -stable) has the particulars about the panic in question, and the machine in question is still sitting at the DDB prompt, if anyone wishes to work with me on that. But the reason for this message is to report that I upgraded the other test machines -- identical confguration: 2x3 GHz Xeons w/ 4 GB RAM; kernel config is called "SMP_PAE_DDB" for a fairly good reason -- to today's -CURRENT, then started the same test that cause -STABLE to crash & burn within a couple of minutes. That was 30 minutes ago; the test is still running on FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Fri Jun 16 07:28:18 P= DT 2006 dhw@localhost:/usr/obj/usr/src/sys/SMP_PAE_DDB i386 As I commented in email to some colleagues, "color me surprised." I've suggested to the vendor (the program under test on the box is from a vendor, built under & for FreeBSD 5.x; I'm using the misc/compat5x port) that they consider trying this themselves, and perhaps also take advantage of John Birrell's work to date on the FreeBSD port of DTrace. I'm still not too keen to run a production workload on a -CURRENT platform. I don't know if whatever is causing -CURRENT to keep running while -STABLE dies is an MFC candidate, but it seems to me that identifying the salient change(s) would be helpful in figuring that out. Any suggestions for how to go about doing that? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Doing business with spammers only encourages them. Please boycott spammers. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+xfF7EeK4BVJ+jDf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkSSz9oACgkQmprOCmdXAD0aLwCeKRUNqF3eO8a0sHHnFDuUztCv CxsAnAk3F2Ki1mYYr6l8UjuVacMCdbhW =jUtT -----END PGP SIGNATURE----- --+xfF7EeK4BVJ+jDf-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 15:59:24 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 169F616A47A for ; Fri, 16 Jun 2006 15:59:24 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E5E43D46 for ; Fri, 16 Jun 2006 15:59:16 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.3) with ESMTP id k5GFw5LJ094493; Fri, 16 Jun 2006 19:58:05 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 16 Jun 2006 19:58:05 +0400 (MSD) From: Maxim Konovalov To: David Wolfskill In-Reply-To: <20060616154556.GI32476@bunrab.catwhisker.org> Message-ID: <20060616195410.L23922@mp2.macomnet.net> References: <20060615232240.GX32476@bunrab.catwhisker.org> <20060616154556.GI32476@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hackers@freebsd.org Subject: Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 15:59:24 -0000 On Fri, 16 Jun 2006, 08:45-0700, David Wolfskill wrote: > On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote: > > I had one of these [kernel panics] a couple of weeks ago or so... > > ...[upgrade to -STABLE as of 15 June; repeat panic]... > > The message to which I'm replying (posted to -stable) has the > particulars about the panic in question, and the machine in question is > still sitting at the DDB prompt, if anyone wishes to work with me on > that. > > But the reason for this message is to report that I upgraded the other > test machines -- identical confguration: 2x3 GHz Xeons w/ 4 GB RAM; > kernel config is called "SMP_PAE_DDB" for a fairly good reason -- to > today's -CURRENT, then started the same test that cause -STABLE to crash > & burn within a couple of minutes. > > That was 30 minutes ago; the test is still running on > > FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Fri Jun 16 07:28:18 PDT 2006 dhw@localhost:/usr/obj/usr/src/sys/SMP_PAE_DDB i386 > > As I commented in email to some colleagues, "color me surprised." > > I've suggested to the vendor (the program under test on the box is > from a vendor, built under & for FreeBSD 5.x; I'm using the > misc/compat5x port) that they consider trying this themselves, and > perhaps also take advantage of John Birrell's work to date on the > FreeBSD port of DTrace. > > I'm still not too keen to run a production workload on a -CURRENT > platform. I don't know if whatever is causing -CURRENT to keep running > while -STABLE dies is an MFC candidate, but it seems to me that > identifying the salient change(s) would be helpful in figuring that out. > > Any suggestions for how to go about doing that? "trace" in ddb would be good start. Do you really need PAE? -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 16:22:35 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2205616A47A for ; Fri, 16 Jun 2006 16:22:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFEBA43D45 for ; Fri, 16 Jun 2006 16:22:33 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k5GGM6cA042262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jun 2006 19:22:06 +0300 (EEST) (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.13.6/8.13.6) with ESMTP id k5GGM6m9091410; Fri, 16 Jun 2006 19:22:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k5GGM3iW091409; Fri, 16 Jun 2006 19:22:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Jun 2006 19:22:03 +0300 From: Konstantin Belousov To: Maxim Konovalov Message-ID: <20060616162203.GE42822@deviant.kiev.zoral.com.ua> References: <20060615232240.GX32476@bunrab.catwhisker.org> <20060616154556.GI32476@bunrab.catwhisker.org> <20060616195410.L23922@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cPi+lWm09sJ+d57q" Content-Disposition: inline In-Reply-To: <20060616195410.L23922@mp2.macomnet.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 16:22:35 -0000 --cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 16, 2006 at 07:58:05PM +0400, Maxim Konovalov wrote: > On Fri, 16 Jun 2006, 08:45-0700, David Wolfskill wrote: >=20 > > On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote: > > > I had one of these [kernel panics] a couple of weeks ago or so... > > > ...[upgrade to -STABLE as of 15 June; repeat panic]... > > > > The message to which I'm replying (posted to -stable) has the > > particulars about the panic in question, and the machine in question is > > still sitting at the DDB prompt, if anyone wishes to work with me on > > that. > > > > But the reason for this message is to report that I upgraded the other > > test machines -- identical confguration: 2x3 GHz Xeons w/ 4 GB RAM; > > kernel config is called "SMP_PAE_DDB" for a fairly good reason -- to > > today's -CURRENT, then started the same test that cause -STABLE to crash > > & burn within a couple of minutes. > > > > That was 30 minutes ago; the test is still running on > > > > FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Fri Jun 16 07:28:= 18 PDT 2006 dhw@localhost:/usr/obj/usr/src/sys/SMP_PAE_DDB i386 > > > > As I commented in email to some colleagues, "color me surprised." > > > > I've suggested to the vendor (the program under test on the box is > > from a vendor, built under & for FreeBSD 5.x; I'm using the > > misc/compat5x port) that they consider trying this themselves, and > > perhaps also take advantage of John Birrell's work to date on the > > FreeBSD port of DTrace. > > > > I'm still not too keen to run a production workload on a -CURRENT > > platform. I don't know if whatever is causing -CURRENT to keep running > > while -STABLE dies is an MFC candidate, but it seems to me that > > identifying the salient change(s) would be helpful in figuring that out. > > > > Any suggestions for how to go about doing that? >=20 > "trace" in ddb would be good start. Do you really need PAE? The real problem is that trace does not work. Original message contains the details. It is either NULL-pointer function call (most likely), or stack array overflow. I already sent the OP the instructions how to proceed. And waiting for response. --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEktqqC3+MBN1Mb4gRAsb2AJ0QtWjR7j6bUlZ3r0olhmlp/5Vw3QCfdxCF GZjTQWDVxQosTA61B953+Gs= =tkPC -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 21:11:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 328B816A47A for ; Fri, 16 Jun 2006 21:11:18 +0000 (UTC) (envelope-from msaad@datapipe.com) Received: from exchewr01.datapipe-corp.net (exchewr01.datapipe-corp.net [64.106.130.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4285F43D67 for ; Fri, 16 Jun 2006 21:11:11 +0000 (GMT) (envelope-from msaad@datapipe.com) Received: from [192.168.81.31] ([192.168.81.31]) by exchewr01.datapipe-corp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 17:11:11 -0400 Message-ID: <44931E6E.9000006@datapipe.com> Date: Fri, 16 Jun 2006 17:11:10 -0400 From: Mark Saad User-Agent: Thunderbird 1.5.0.4 (X11/20060607) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 21:11:11.0032 (UTC) FILETIME=[648FA380:01C69189] Subject: sysinstall question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msaad@datapipe.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:11:18 -0000 Hello All, I am working on building a FreeBSD 6.1 Jumpstart. One issue I ran into is with sysinstall editing the rc.conf file that I add from a package . The issue is that my options are perpended with the string "#REMOVED" . My questions is, Is there a preferred way to add a custom rc.conf, and does anyone know why I am getting the "#REMOVED" added in the first place ? -- Mark Saad msaad@datapipe.com From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 21:21:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D210E16A47E for ; Fri, 16 Jun 2006 21:21:22 +0000 (UTC) (envelope-from fradonan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A78743D6B for ; Fri, 16 Jun 2006 21:21:17 +0000 (GMT) (envelope-from fradonan@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so29566uge for ; Fri, 16 Jun 2006 14:21:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tFPR6qdQt0ZVGiSjKBUlx1pMl5kI3dnKZR9xU8a98/TMIi/mzybiUy3uMJ/SHw7hkIT//RPdSTnXPm1oEGcnrWnZ7UTg/bcx6XvHKIV2iAlCGqWt3qjyd4JAkZF5/DpshkXLDWePK8o59Fawm8TDd4ckhsB8FDyxqTKvUsurRNg= Received: by 10.78.32.16 with SMTP id f16mr335715huf; Tue, 13 Jun 2006 12:53:44 -0700 (PDT) Received: by 10.78.43.12 with HTTP; Tue, 13 Jun 2006 12:53:44 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2006 12:53:44 -0700 From: "Franklin Donan" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: adm1026 support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:21:22 -0000 Hi, I want to use healthd to monitor values exported by an adm1026 chip, using the smbus interface. Here's the data sheet for this chip: http://www.analog.com/UploadedFiles/Data_Sheets/779263102ADM1026_a.pdf This chip is smbus & iic compatible. I am thinking I will have to write an adm1026 specific kernel module to interface with the iicbus module, but am not sure. Can someone please let me know what exactly needs to be done? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 16 21:55:10 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC08216A479 for ; Fri, 16 Jun 2006 21:55:10 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F373843D4C for ; Fri, 16 Jun 2006 21:55:09 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5GLt1EM018083; Sat, 17 Jun 2006 00:55:01 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sat, 17 Jun 2006 00:55:01 +0300 (EEST) From: Dmitry Pryanishnikov To: Franklin Donan In-Reply-To: Message-ID: <20060617005036.D3928@atlantis.atlantis.dp.ua> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: adm1026 support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:55:10 -0000 Hello! On Tue, 13 Jun 2006, Franklin Donan wrote: > I want to use healthd to monitor values exported by an adm1026 chip, > using the smbus interface. > Here's the data sheet for this chip: > http://www.analog.com/UploadedFiles/Data_Sheets/779263102ADM1026_a.pdf > > This chip is smbus & iic compatible. I am thinking I will have to write an > adm1026 specific kernel module to interface with the iicbus module, but am > not sure. Can someone please let me know what exactly needs to be done? There's no need in kernel module, all you want is a small piece of chip-specific userland code for healthd itself. Take a look at my patch: ftp://external.atlantis.dp.ua/FreeBSD/healthd/0.7.9/patch-IntelDeskBoards.v04 It adds support for several chips including ADM1025. Unfortunately I have neither ADM1026-based motherboard nor spare time to help you, but I hope you'll get an idea - code is very simple indeed. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 17 17:04:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6967316A474 for ; Sat, 17 Jun 2006 17:04:20 +0000 (UTC) (envelope-from info@gabitasoft.com) Received: from serv1.gabita.com (serv1.gabita.com [216.127.70.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C6E43D49 for ; Sat, 17 Jun 2006 17:04:20 +0000 (GMT) (envelope-from info@gabitasoft.com) Received: from dd5769ece.access.telenet.be ([213.118.158.206] helo=[192.168.1.100]) by serv1.gabita.com with esmtpa (Exim 4.52) id 1FreCp-0000Gt-6F for freebsd-hackers@freebsd.org; Sat, 17 Jun 2006 12:03:31 -0500 Message-ID: <4494361C.3070501@gabitasoft.com> Date: Sat, 17 Jun 2006 19:04:28 +0200 From: info User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv1.gabita.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gabitasoft.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Sat, 17 Jun 2006 19:00:13 +0000 Subject: Port of wpi driver ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 17:04:20 -0000 Hi Does anybody know whether OpenBSD's-Current wpi driver (Intel 3945 abg) will be ported to Freebsd-Current ? Thanks Roel From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 17 20:13:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D53516A47B for ; Sat, 17 Jun 2006 20:13:48 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx0.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8E043D48 for ; Sat, 17 Jun 2006 20:13:47 +0000 (GMT) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx0.rink.nu (Postfix) with ESMTP id 9109D17070; Sat, 17 Jun 2006 22:13:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx0.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0SxCBBrK+A2; Sat, 17 Jun 2006 22:13:53 +0200 (CEST) Received: by mx0.rink.nu (Postfix, from userid 1678) id DB8F91706F; Sat, 17 Jun 2006 22:13:53 +0200 (CEST) Date: Sat, 17 Jun 2006 22:13:53 +0200 From: Rink Springer To: info Message-ID: <20060617201353.GB72064@rink.nu> References: <4494361C.3070501@gabitasoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <4494361C.3070501@gabitasoft.com> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: Port of wpi driver ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:13:48 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, > Does anybody know whether OpenBSD's-Current wpi driver (Intel 3945 abg)= =20 > will be ported to Freebsd-Current ? I heard OpenBSD's wpi driver is very experimental; have you tested it yet? --=20 Rink P.W. Springer - http://rink.nu "Richter: Tribute? You steal men's souls, and make them your slaves! Dracula: Perhaps the same could be said of all religions." - Castlevania: Symphony of the Night --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFElGKBb3O60uztv/8RAneaAJ0fOPRw8/x4l1twpTD9jTRSmopv+ACeLy8i zjE/lr8jy7zo7A3uA4t5LS0= =7Haw -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP--