From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 00:36:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66921065672 for ; Sun, 20 Jul 2008 00:36:35 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8952A8FC1A for ; Sun, 20 Jul 2008 00:36:35 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so271932ywe.13 for ; Sat, 19 Jul 2008 17:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=BK48/bvQblPgNtTq7qwH15BjFfL+hNZ+BIRQDFGRDG8=; b=VLohEkXXxJ7kuNL56ylhSbnVsV6tRJZIsELBRqIrdT+xx221jkqa8NaWhT1pSXrqVg +vNBhLmkxMCCudkpF6TfgcIOIvZ2BmQUT18UUZqkK1vr0aorcHE9iUqWMbAcmdfQbXKL 141frZa0AulaeuHEWok1fqa+1w4dVBoJVMTO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=rPVU+JNfWZtRYudzuvGAbmVPL8ibTMrDFLS4SZWNJeKU+eAKgRmnNSnTzv8Plc/LQx yfDo/tDJHjgrodf7YuzCT8BumqHPEflJHt1U1oZD1Jt5oT63KpVi1YREYH+uSsE4HPBt faowf63TqepIdsmjyjinuLr658D73VLh7lEvk= Received: by 10.150.202.3 with SMTP id z3mr1930268ybf.224.1216514193867; Sat, 19 Jul 2008 17:36:33 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.22.162]) by mx.google.com with ESMTPS id 9sm630998yxs.5.2008.07.19.17.36.32 (version=SSLv3 cipher=RC4-MD5); Sat, 19 Jul 2008 17:36:33 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Giorgos Keramidas In-Reply-To: <87iqv1h1g8.fsf@kobe.laptop> References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> <87tzelebd7.fsf@kobe.laptop> <1216508230.2172.8.camel@RabbitsDen> <87iqv1h1g8.fsf@kobe.laptop> Content-Type: text/plain; charset=utf-8 Date: Sat, 19 Jul 2008 20:36:22 -0400 Message-Id: <1216514182.2172.28.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 00:36:35 -0000 On Sun, 2008-07-20 at 02:57 +0300, Giorgos Keramidas wrote: > On Sat, 19 Jul 2008 18:57:10 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > > On Sun, 2008-07-20 at 01:51 +0300, Giorgos Keramidas wrote: > >> That was it. Thanks! > >> > >> # sysctl -a | egrep -e 'cx_(usage|support)' > >> dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > >> dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% > >> dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > >> dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% > >> > >> With anything except "C1" the CPU is obviously too slow to do > >> anything useful :-) > > > > I guess it got worse in CURRENT: > > > > # uname -a > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 7.0-STABLE FreeBSD 7.0-STABLE > > #0: Wed Jul 9 16:52:35 EDT 2008 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > RabbitsDen# sysctl -a | egrep -e 'cx_(usage|support)' > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.1.cx_usage: 0.00% 4.43% 95.56% > > Now that I know what to look for, I see that what is reported in > cx_supported is an array from the `struct acpi_cpu_softc' for each cpu. > The initialization of per-cpu dev.cpu.*.cx_xxx values in the softc of > the cpu is done in sys/dev/acpica/acpi_cpu.c:acpi_cpu_cx_cst(). > > I am probably not qualified to say if 'things got worse' in CURRENT, but > I wish there was a way to find out *before* entering a state where the > CPU is too slow to do basic tasks (i.e. time keeping, and scheduling > processes). > What I meant is that my laptop, runnig RELENG_7 is pretty happy with "C2" (set through /etc/rc.conf as performance_cx_lowest="C2", and even "C3" (set through /etc/sysctl.conf as dev.cpu.1.cx_lowest=C3), so long as cpu0 is not allowed to go into C3. You seemed to indicate that in your case nothing but "C1" worked. If you just did not try the configuration above, would you, please, try it and see if it works. Apart from, hopefully, giving someone the data point, it will make your laptop cooler and less power hungry. Now, as far as finding out how bad coming out of the state is, that's what the numbers after the slash in "supported" are for. Coming out of C3 on my CPU (and yours) will take 57 times longer than coming out of C2. You can play games with your ASL to change that value. I am sure that I am not qualified to say whether it gets honored, though. Few more data points: -- CPU0 and CPU1 are somehow not treated interchangeably by FreeBSD. -- at some point when earth was warm and 7.0 was CURRENT, "C3" used to work on my laptop, even on CPU0. -- I have not filed a PR. If you think it is warranted, you could do it or I can -- it's just I did a couple of embarrassing ones and got somewhat trigger-shy ;) -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 01:00:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692C3106564A for ; Sun, 20 Jul 2008 01:00:37 +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 D538A8FC12 for ; Sun, 20 Jul 2008 01:00:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl133-207.kln.forthnet.gr [77.49.252.207]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6K10O0c001521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 04:00:30 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6K10NP4003717; Sun, 20 Jul 2008 04:00:23 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6K10M5M003716; Sun, 20 Jul 2008 04:00:22 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Alexandre \"Sunny\" Kovalenko" References: <87prpcjrsk.fsf@kobe.laptop> <1216501388.971.6.camel@RabbitsDen> <87mykd5wsl.fsf@kobe.laptop> <87tzelebd7.fsf@kobe.laptop> <1216508230.2172.8.camel@RabbitsDen> <87iqv1h1g8.fsf@kobe.laptop> <1216514182.2172.28.camel@RabbitsDen> Date: Sun, 20 Jul 2008 04:00:22 +0300 In-Reply-To: <1216514182.2172.28.camel@RabbitsDen> (Alexandre Kovalenko's message of "Sat, 19 Jul 2008 20:36:22 -0400") Message-ID: <874p6lfjyx.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6K10O0c001521 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.787, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 01:00:37 -0000 On Sat, 19 Jul 2008 20:36:22 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > What I meant is that my laptop, runnig RELENG_7 is pretty happy with > "C2" (set through /etc/rc.conf as performance_cx_lowest="C2", and even > "C3" (set through /etc/sysctl.conf as dev.cpu.1.cx_lowest=C3), so long > as cpu0 is not allowed to go into C3. You seemed to indicate that in > your case nothing but "C1" worked. If you just did not try the > configuration above, would you, please, try it and see if it works. > Apart from, hopefully, giving someone the data point, it will make > your laptop cooler and less power hungry. Ah, now I get it :) Well, I did try the following after booting with both CPUs in C1 state: (1) hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_lowest: C2 I left the laptop to boot with both CPUs in C1, and then after a while I manually set dev.cpu.0.cx_lowest=C2. This setup seems ok. I can see processes being scheduled on both cpu.0 and cpu.1 and there's no "freeze" when the laptop is idle. (2) hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_lowest: C3 Same as above, only this time I set dev.cpu.0.cx_lowest=C3. (3) hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_lowest: C2 Not ok. When the laptop stays idle for some time, it starts getting too slow to type stuff in a terminal, and after a while I get `calcru: runtime went backwards' messages. I don't know if being scheduled on cpu.1 when it is in C2/C3 state has any measurable impact on user processes. Should I leave the settings to option (1) or (2) above for a while? Is there any way to find out if this causes any problems? Right now I am running for a couple of minutes with $ sysctl -a | fgrep .cx_ hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 0.00% 100.00% 0.00% and things seem ok so far :-) Thank you for all the help. It's been _very_ useful :) > Few more data points: > -- CPU0 and CPU1 are somehow not treated interchangeably by FreeBSD. > -- at some point when earth was warm and 7.0 was CURRENT, "C3" used to > work on my laptop, even on CPU0. > -- I have not filed a PR. If you think it is warranted, you could do it > or I can -- it's just I did a couple of embarrassing ones and got > somewhat trigger-shy ;) Heh. I've filed my own share of bogus PRs too. Please don't feel shy, and just report whatever seems out of the ordinary. It's better to have a few extra PRs that are not really bugs, than never-fixed bugs :) From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 09:03:35 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D9081065673; Sun, 20 Jul 2008 09:03:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8888FC08; Sun, 20 Jul 2008 09:03:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KKUpI-0004Ld-CR; Sun, 20 Jul 2008 12:03:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Peter Ross In-reply-to: <20080720003343.S23554@oldie.bigpond.com> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> <1216473536.1991.5.camel@wombat.2hip.net> <20080720003343.S23554@oldie.bigpond.com> Comments: In-reply-to Peter Ross message dated "Sun, 20 Jul 2008 01:07:32 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 2008 12:03:32 +0300 From: Danny Braniss Message-ID: Cc: Doug Barton , Robert Noland , freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 09:03:35 -0000 > On Sat, 19 Jul 2008, Robert Noland wrote: > > > On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote: > > > Bernd Walter wrote: > > > > Speaking about small systems, where startup time is more a problem than > > > > on 08/15 desktop and server systems. > > > > What I would love to see is that scripts like moused, ypserv, lpt, etc > > > > are not started if the services are disabled. > > > > > > That wold be a neat trick, how do you propose we accomplish it? (no, > > > I'm not being snide.) > > > .. > > > One way you could do this is to have /etc/rc.d/active and > > > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical > > > stuff that most people shouldn't touch). Then you could have a > > > vipw-like system to allow users to edit rc.conf that would move the > > > scripts to the right directory. Of course, this would be fraught with > > > potential for problems. :) > > > > I almost hate to toss this out there, but what about a sys v type rc? > > Usually the scripts are running run_rc_command. > > This does a checkyesno for the rcvar variable which is usually > ${name}_enable. In most of the cases it uses set_rcvar to achieve this. > > If so, /etc/rc could evaluate ${name}_enable (it already knows them via > /etc/rc.conf) before actually calling a script. > > There are some irregular names amongst the name of the rcvar variable. > > I am not 100% sure whether same of the scripts set ${name}_enable vaiables > implicitly. That could complicate things. I could not find evidence by > browsing through them. I went ahead with my idea - to reduce the list rcorder delivers, by eliminating those that don't have ${name}_enable, and I opened a pandora box :-) - dummy dependency like SERVERS/LOGIN don't have ${name}_enable nor should have. - REQUIERE: xxx complains if xxx is not 'loaded' like in the case of NETWORKING requirement of ppp which I don't have enabled. - some scripts rely on the existance of a ${file} which is better than the original /etc/rc which used to run mountd if /etc/exports existed, but does not 'conform' to the ${name}_enable paradigm. - some scripts like abi don't have abi_enable, but sysvipc_enable, linux_enable and svr4_enable. All these - and some more that I probably missed - can be fixed, or the warnings ignored, but is it worthwhile? > > I also do not know whether there are scripts that actually do something > valuable before calling run_rc_command. > > At the moment it looks to me that these excemptions could be dealt with by > adapting the scripts so they meet the standard (running only when > ${name}_enable is set). > > I only looked through some of the /etc/rc.d scripts en detail (+ some > greps for rcvar etc. in the directory) so it needs some more > investigation. > > If it works it avoids messing around with symlinks or moving scripts > around, and it reduces the scripts that actually run. > > As a sys admin I really like the BSD way of having everything relevant to > my system in one /etc/rc.conf. It is very convenient. > > Regards > Peter > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 10:29:42 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED3811065671 for ; Sun, 20 Jul 2008 10:29:41 +0000 (UTC) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id 423298FC08 for ; Sun, 20 Jul 2008 10:29:41 +0000 (UTC) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from nskntotgx02p.mx.bigpond.com ([124.176.185.159]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20080720102939.DVBH16527.nskntmtas05p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Sun, 20 Jul 2008 10:29:39 +0000 Received: from oldie.bigpond.com ([124.176.185.159]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080720102937.AWV15862.nskntotgx02p.mx.bigpond.com@oldie.bigpond.com>; Sun, 20 Jul 2008 10:29:37 +0000 Received: from oldie.bigpond.com (localhost [127.0.0.1]) by oldie.bigpond.com (8.14.2/8.14.2) with ESMTP id m6KAUDko000986; Sun, 20 Jul 2008 20:30:13 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from localhost (petros@localhost) by oldie.bigpond.com (8.14.2/8.14.2/Submit) with ESMTP id m6KAU6KA000983; Sun, 20 Jul 2008 20:30:10 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) X-Authentication-Warning: oldie.bigpond.com: petros owned process doing -bs Date: Sun, 20 Jul 2008 20:30:06 +1000 (EST) From: Peter Ross X-X-Sender: petros@oldie.bigpond.com To: Danny Braniss In-Reply-To: Message-ID: <20080720200229.T894@oldie.bigpond.com> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> <1216473536.1991.5.camel@wombat.2hip.net> <20080720003343.S23554@oldie.bigpond.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.48831392.008C,ss=1,fgs=0 Cc: Doug Barton , Robert Noland , freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 10:29:42 -0000 On Sun, 20 Jul 2008, Danny Braniss wrote: > I went ahead with my idea - to reduce the list rcorder delivers, by > eliminating those that don't have ${name}_enable, and I opened a pandora > box :-) > - dummy dependency like SERVERS/LOGIN don't have ${name}_enable > nor should have. Two options: - Just eliminate the scripts that have the variable, and set it to "no" - A dummy entry in /etc/defaults/rc.conf with "# Don't overwrite this" (So only one who really knows what he is doing will try it - hopefully) > - REQUIERE: xxx complains if xxx is not 'loaded' like in the case > of NETWORKING requirement of ppp which I don't have enabled. Solved by point 1? > - some scripts rely on the existance of a ${file} which is better than > the original /etc/rc which used to run mountd if /etc/exports existed, > but does not 'conform' to the ${name}_enable paradigm. The same? > - some scripts like abi don't have abi_enable, but sysvipc_enable, > linux_enable and svr4_enable. I looked at this. abi is in fact a container for three start scripts. Of course splitting them makes the situation worse.. If the ${name}_enable check becomes a function some special cases could be treated in a case statement case ${name} of mountd) if [ -f /etc/exports ]; then result=1; fi ;; abi) if [ checkyesno sysvipc -o checkyesno linux_enable .. ]; then result=1; fi ;; *) enable=eval \$${name}_enable if [ "X${enable}" = "X" ]; then result=1 else result=`checkyesno ${enable}`; fi ;; esac [That's untested demo code and may contain typos] Unfortunately the rc.d scripts are not self-contained anymore. That may offend some. But there is shared *.subr code already. > All these - and some more that I probably missed - can be fixed, or the > warnings ignored, but is it worthwhile? That's a good question. It is up to the users of "slower" hardware (e.g.embedded devices), I think. Regards Peter From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 12:34:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CC3B106566B; Sun, 20 Jul 2008 12:34:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 60DB28FC1B; Sun, 20 Jul 2008 12:34:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 869D61CF83; Sun, 20 Jul 2008 14:32:56 +0200 (CEST) Date: Sun, 20 Jul 2008 14:32:56 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Arch Message-ID: <20080720123256.GE21188@hoeg.nl> References: <20080702190901.GS14567@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lkTb+7nhmha7W+c3" Content-Disposition: inline In-Reply-To: <20080702190901.GS14567@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: Re: MPSAFE TTY schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 12:34:57 -0000 --lkTb+7nhmha7W+c3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, Today is July 20, which means I'm supposed to send you a message: * Ed Schouten wrote: > July 20 2008: > Send another heads-up to the lists about the new TTY layer. > Kindly ask people to test the patchset, port more drivers, etc. As usual, the latest mpsafetty patchset can be found here. I would really appreciate it if I could get more reviews on the code. Thanks! http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/ The following drivers have not been ported to the new TTY layer yet: cy(4), digi(4), ng_h4(4), ng_tty(4), nmdm(4), rc(4), rp(4), si(4), sio(4), snp(4), ubser(4). I've been working on nmdm(4). I'll probably get it working in time. If not it will be fixed not long after the integration next month. The line disciplines like snp(4), ng_tty(4) and ng_h4(4) can only be fixed after the import, because the hooks layer will be written after the import. In the other news: kris@ reported a possible performance regression to me. He discovered `make -C /usr/ports index' consumed more system time on his hardware when the mpsafetty patches were applied. For some reason, I'm not capable of reproducing them. I even experience a performance gain when running mpsafetty, which is quite plausible, because I've also made some small improvements to `struct session' locking, but we also don't pick up Giant in kern_proc.c anymore. Because kris@ committed a patch to improve `make index' performance yesterday, I re-ran my tests today, showing the performance difference is now nihil. Here are the raw numbers: http://80386.nl/files/mpsafetty-stats.txt Maybe someone is interested in performing more thorough benchmarks? Yours, --=20 Ed Schouten WWW: http://80386.nl/ --lkTb+7nhmha7W+c3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiDMHgACgkQ52SDGA2eCwXIaACePBQ+9QntL3faYFCyck8VOlOp C6QAn3E0Pd1dm3xBTa77pRrAbAvlPO5j =+NBc -----END PGP SIGNATURE----- --lkTb+7nhmha7W+c3-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 13:23:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6961065676; Sun, 20 Jul 2008 13:23:31 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id D9E1E8FC15; Sun, 20 Jul 2008 13:23:30 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from dslb-084-056-162-062.pools.arcor-ip.net ([84.56.162.62] helo=[192.168.0.9]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KKYss-0003go-1E; Sun, 20 Jul 2008 15:23:30 +0200 Message-ID: <48833C50.8030507@lobraun.de> Date: Sun, 20 Jul 2008 15:23:28 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Attilio Rao References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> In-Reply-To: <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 13:23:31 -0000 Hi Attilio, > can you please try this on the top of -CURRENT: > http://www.freebsd.org/~attilio/xfs2.diff Thank you for the patch. The panic and the dead lock disappeard, but there is a new problem insteed. The commands mkfs.xfs /dev/ad8s4 mount -t xfs /dev/ad8s4 /home mkdir /home/lothar chown lothar:lothar /home/lothar /var/log/messages showed this debug output for the above commands: Jul 20 13:24:54 finch kernel: SGI XFS with large block numbers, tracing, no debug enabled Jul 20 13:24:54 finch kernel: fsname '/dev/ad8s4' logname '' rtname '' Jul 20 13:24:54 finch kernel: flags 0x200000 sunit 0 swidth 0 logbufs -1 logbufsize -1 Jul 20 13:24:54 finch kernel: xfs_setsize_buftarg NI 0xc694f200 Jul 20 13:24:54 finch kernel: XFS mounting filesystem /dev/ad8s4 Jul 20 13:24:55 finch kernel: Ending clean XFS mount for filesystem: /dev/ad8s4 Jul 20 13:25:09 finch kernel: lock order reversal: Jul 20 13:25:09 finch kernel: 1st 0xc6dc3dc8 xfs (xfs) @ /usr/src/sys/kern/vfs_lookup.c:432 Jul 20 13:25:09 finch kernel: 2nd 0xc6f40090 xfsino (xfsino) @ /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs_iget.c:881 Jul 20 13:25:09 finch kernel: 3rd 0xc6dc39c0 xfs (xfs) @ /usr/src/sys/modules/xfs/../../gnu/fs/xfs/FreeBSD/xfs_freebsd_iget.c:393 Jul 20 13:25:09 finch kernel: KDB: stack backtrace: Jul 20 13:25:09 finch kernel: db_trace_self_wrapper(c0b2f902,e9073760,c07ce8ee,c0b32188,c6dc39c0,...) at db_trace_self_wrapper+0x26 Jul 20 13:25:09 finch kernel: kdb_backtrace(c0b32188,c6dc39c0,c6e7fe19,c6e7fe19,c6e7fd6e,...) at kdb_backtrace+0x29 Jul 20 13:25:09 finch kernel: witness_checkorder(c6dc39c0,9,c6e7fd6e,189,4,...) at witness_checkorder+0x6de Jul 20 13:25:09 finch kernel: __lockmgr_args(c6dc39c0,80400,c6dc3a28,0,0,...) at __lockmgr_args+0x777 Jul 20 13:25:09 finch kernel: vop_stdlock(e9073860,c6dc3a5c,c6dc3968,80400,c6dc3968,...) at vop_stdlock+0x65 Jul 20 13:25:09 finch kernel: VOP_LOCK1_APV(c6e895c0,e9073860,c0c3a2a0,c6dc3968,80400,...) at VOP_LOCK1_APV+0xa5 Jul 20 13:25:09 finch kernel: _vn_lock(c6dc3968,80400,c6e7fd6e,189,e90738dc,...) at _vn_lock+0x5e Jul 20 13:25:09 finch kernel: xfs_iget(c6745c00,c6f9c000,83,0,1,...) at xfs_iget+0x27b Jul 20 13:25:09 finch kernel: xfs_trans_iget(c6745c00,c6f9c000,83,0,1,...) at xfs_trans_iget+0x256 Jul 20 13:25:09 finch kernel: xfs_ialloc(c6f9c000,c6f40000,41ed,2,0,...) at xfs_ialloc+0xda Jul 20 13:25:09 finch kernel: xfs_dir_ialloc(e9073a78,c6f40000,41ed,2,0,...) at xfs_dir_ialloc+0x82 Jul 20 13:25:09 finch kernel: xfs_mkdir(c6f40020,e9073c04,e9073ab4,e9073b28,c6cce300,...) at xfs_mkdir+0x457 Jul 20 13:25:09 finch kernel: _xfs_mkdir(e9073c28,c0b6262e,0,e9073c28,e9073bd8,...) at _xfs_mkdir+0xb0 Jul 20 13:25:09 finch kernel: VOP_MKDIR_APV(c6e895c0,e9073c28,e97,e95,1,...) at VOP_MKDIR_APV+0xc5 Jul 20 13:25:09 finch kernel: kern_mkdirat(c6d95af0,ffffff9c,bfbfee32,0,1ff,...) at kern_mkdirat+0x276 Jul 20 13:25:09 finch kernel: kern_mkdir(c6d95af0,bfbfee32,0,1ff,e9073d2c,...) at kern_mkdir+0x2e Jul 20 13:25:09 finch kernel: mkdir(c6d95af0,e9073cf8,8,c,c0c003e0,...) at mkdir+0x29 Jul 20 13:25:09 finch kernel: syscall(e9073d38) at syscall+0x2a3 Jul 20 13:25:09 finch kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 20 13:25:09 finch kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x28159cd3, esp = 0xbfbfec5c, ebp = 0xbfbfed28 --- Jul 20 13:25:34 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f40000 Jul 20 13:25:34 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 13:25:39 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 13:25:49 finch kernel: xfs_remove: dvp 0xc675b740 vp 0xc67738a0 Jul 20 13:25:49 finch kernel: vn_iowait doing nothing on FreeBSD? Jul 20 13:26:05 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 13:26:05 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fc00 Afterwards i copied a tar.bz2 to the created folder and tried to extract it with scp somehost:/some-tarfile.tar.bz2 /home/lothar tar xjvf some-tarfile.tar.bz2 and got a Input/Output-Error on the device. /var/log/messages contains ul 20 15:06:15 finch kernel: xfs_buf_iomove NI Jul 20 15:06:15 finch kernel: xfs_buf_iomove NI Jul 20 15:06:19 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 15:06:19 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fa80 Jul 20 15:06:19 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6fcc300 Jul 20 15:07:20 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 15:07:33 finch kernel: vn_iowait doing nothing on FreeBSD? Jul 20 15:07:33 finch kernel: xfs_itruncate_data NI Jul 20 15:07:44 finch kernel: xfs_buf_iomove NI Jul 20 15:07:44 finch kernel: xfs_buf_iomove NI Jul 20 15:07:44 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fc00 Jul 20 15:07:44 finch kernel: xfs_buf_iomove NI Jul 20 15:07:44 finch kernel: xfs_buf_iomove NI Jul 20 15:07:44 finch kernel: cmn_err level 1 Filesystem "/dev/ad8s4": XFS internal error xfs_iformat(7) at line 493 of file /usr/src/sys/mo dules/xfs/../../gnu/fs/xfs/xfs_inode.c. Caller 0x0xc6e2b78c Jul 20 15:07:44 finch kernel: Jul 20 15:07:44 finch kernel: KDB: stack backtrace: Jul 20 15:07:44 finch kernel: db_trace_self_wrapper(c0b2f902,e906a880,c6e3d698,c6e81f22,1,...) at db_trace_self_wrapper+0x26 Jul 20 15:07:44 finch kernel: kdb_backtrace(c6e81f22,1,c6745c00,c6e807b0,1ed,...) at kdb_backtrace+0x29 Jul 20 15:07:44 finch kernel: xfs_iread(c6745c00,c6fa9000,6000080,0,e906a8dc,...) at xfs_iread+0x508 Jul 20 15:07:44 finch kernel: xfs_iget(c6745c00,c6fa9000,6000080,0,1,...) at xfs_iget+0x1dc Jul 20 15:07:44 finch kernel: xfs_trans_iget(c6745c00,c6fa9000,6000080,0,1,...) at xfs_trans_iget+0x256 Jul 20 15:07:44 finch kernel: xfs_ialloc(c6fa9000,c6f3f900,41ed,2,0,...) at xfs_ialloc+0xda Jul 20 15:07:44 finch kernel: xfs_dir_ialloc(e906aa78,c6f3f900,41ed,2,0,...) at xfs_dir_ialloc+0x275 Jul 20 15:07:44 finch kernel: xfs_mkdir(c6f3f920,e906ac04,e906aab4,e906ab28,c6a9ae00,...) at xfs_mkdir+0x457 Jul 20 15:07:44 finch kernel: _xfs_mkdir(e906ac28,c0b6262e,0,e906ac28,e906abd8,...) at _xfs_mkdir+0xb0 Jul 20 15:07:44 finch kernel: VOP_MKDIR_APV(c6e895c0,e906ac28,e97,e95,1,...) at VOP_MKDIR_APV+0xc5 Jul 20 15:07:44 finch kernel: kern_mkdirat(c6d96230,ffffff9c,8102200,0,1ed,...) at kern_mkdirat+0x276 Jul 20 15:07:44 finch kernel: kern_mkdir(c6d96230,8102200,0,1ed,e906ad2c,...) at kern_mkdir+0x2e Jul 20 15:07:44 finch kernel: mkdir(c6d96230,e906acf8,8,c0b328ba,c0c003e0,...) at mkdir+0x29 Jul 20 15:07:44 finch kernel: syscall(e906ad38) at syscall+0x2a3 Jul 20 15:07:44 finch kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 20 15:07:44 finch kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281b2cd3, esp = 0xbfbfe97c, ebp = 0xbfbfe9a8 --- Jul 20 15:07:44 finch kernel: cmn_err level 1 Filesystem "/dev/ad8s4": xfs_iread: xfs_iformat() returned error 990 Jul 20 15:07:44 finch kernel: cmn_err level 1 Filesystem "/dev/ad8s4": XFS internal error xfs_trans_cancel at line 1155 of file /usr/src/sys /modules/xfs/../../gnu/fs/xfs/xfs_trans.c. Caller 0x0xc6e6018b Jul 20 15:07:44 finch kernel: Jul 20 15:07:44 finch kernel: KDB: stack backtrace: Jul 20 15:07:44 finch kernel: db_trace_self_wrapper(c0b2f902,e906a9e0,c6e51deb,c6e84dcf,1,...) at db_trace_self_wrapper+0x26 Jul 20 15:07:44 finch kernel: kdb_backtrace(c6e84dcf,1,c6745c00,c6e84c1c,483,...) at kdb_backtrace+0x29 Jul 20 15:07:44 finch kernel: xfs_trans_cancel(c6fa9000,c,41ed,2,0,...) at xfs_trans_cancel+0x11b Jul 20 15:07:44 finch kernel: xfs_mkdir(c6f3f920,e906ac04,e906aab4,e906ab28,c6a9ae00,...) at xfs_mkdir+0x2db Jul 20 15:07:44 finch kernel: _xfs_mkdir(e906ac28,c0b6262e,0,e906ac28,e906abd8,...) at _xfs_mkdir+0xb0 Jul 20 15:07:44 finch kernel: VOP_MKDIR_APV(c6e895c0,e906ac28,e97,e95,1,...) at VOP_MKDIR_APV+0xc5 Jul 20 15:07:44 finch kernel: kern_mkdirat(c6d96230,ffffff9c,8102200,0,1ed,...) at kern_mkdirat+0x276 Jul 20 15:07:44 finch kernel: kern_mkdir(c6d96230,8102200,0,1ed,e906ad2c,...) at kern_mkdir+0x2e Jul 20 15:07:44 finch kernel: mkdir(c6d96230,e906acf8,8,c0b328ba,c0c003e0,...) at mkdir+0x29 Jul 20 15:07:44 finch kernel: syscall(e906ad38) at syscall+0x2a3 Jul 20 15:07:44 finch kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 20 15:07:44 finch kernel: --- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281b2cd3, esp = 0xbfbfe97c, ebp = 0xbfbfe9a8 --- Jul 20 15:07:44 finch kernel: xfs_force_shutdown(/dev/ad8s4,0x8) called from line 1156 of file /usr/src/sys/modules/xfs/../../gnu/fs/xfs/xfs _trans.c. Return address = 0x0xc6e51e22 Jul 20 15:07:45 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3f900 Jul 20 15:07:45 finch kernel: xfs_iunpin: REC RECABLE ip 0xc6f3fd80 Jul 20 15:07:45 finch kernel: XFS: Transforming an alert into a BUG. Jul 20 15:07:45 finch kernel: cmn_err level 0 Filesystem "/dev/ad8s4": Corruption of in-memory data detected. Shutting down filesystem: /de v/ad8s4 Jul 20 15:07:45 finch kernel: Please umount the filesystem, and rectify the problem(s) Best regards, Lothar From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 15:03:33 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6EAB106566B; Sun, 20 Jul 2008 15:03:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 67E2C8FC0C; Sun, 20 Jul 2008 15:03:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1KKaRd-0008h9-Hl; Sun, 20 Jul 2008 18:03:29 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Peter Ross In-reply-to: <20080720200229.T894@oldie.bigpond.com> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> <20080718122928.GD35340@cicely7.cicely.de> <4881795A.4070604@FreeBSD.org> <1216473536.1991.5.camel@wombat.2hip.net> <20080720003343.S23554@oldie.bigpond.com> <20080720200229.T894@oldie.bigpond.com> Comments: In-reply-to Peter Ross message dated "Sun, 20 Jul 2008 20:30:06 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 2008 18:03:29 +0300 From: Danny Braniss Message-ID: Cc: Doug Barton , Robert Noland , freebsd-current@FreeBSD.org, ticso@cicely.de Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 15:03:33 -0000 > On Sun, 20 Jul 2008, Danny Braniss wrote: > > > I went ahead with my idea - to reduce the list rcorder delivers, by > > eliminating those that don't have ${name}_enable, and I opened a pandora > > box :-) > > - dummy dependency like SERVERS/LOGIN don't have ${name}_enable > > nor should have. > > Two options: > - Just eliminate the scripts that have the variable, and set it to "no" > - A dummy entry in /etc/defaults/rc.conf with "# Don't overwrite this" > (So only one who really knows what he is doing will try it - hopefully) > as usual I forgot one word, don't have ${name}_enable should have been: don't have ${name}_enable="YES" (or true or 1) personaly, I prefer self-contained, like iscsi_enable=${iscsi_enable:-"NO"} instead of adding it to /etc/defaults/rc.conf, though I can see the benefit. what I'm trying to say, is keep the complexity to a minimum, less foot-shooting :-) > > - REQUIERE: xxx complains if xxx is not 'loaded' like in the case > > of NETWORKING requirement of ppp which I don't have enabled. > > Solved by point 1? > > > - some scripts rely on the existance of a ${file} which is better than > > the original /etc/rc which used to run mountd if /etc/exports existed, > > but does not 'conform' to the ${name}_enable paradigm. > > The same? > > > - some scripts like abi don't have abi_enable, but sysvipc_enable, > > linux_enable and svr4_enable. > > I looked at this. abi is in fact a container for three start scripts. > > Of course splitting them makes the situation worse.. > > If the ${name}_enable check becomes a function > some special cases could be treated in a case statement > > case ${name} of > mountd) > if [ -f /etc/exports ]; then result=1; fi > ;; > abi) > if [ checkyesno sysvipc -o checkyesno linux_enable .. ]; then > result=1; fi > ;; > *) > enable=eval \$${name}_enable > if [ "X${enable}" = "X" ]; then result=1 > else result=`checkyesno ${enable}`; fi > ;; > esac > > [That's untested demo code and may contain typos] > > Unfortunately the rc.d scripts are not self-contained anymore. That may > offend some. But there is shared *.subr code already. > the initial idea behind rcng (was it called like that?), was, and most of it is still good, it's nicer that the monolithick /etc/rc of old, and less messy than sys5's. lets try and keep it 'simple' - as usual the KISS principle has more than one interpretation :-) > > All these - and some more that I probably missed - can be fixed, or the > > warnings ignored, but is it worthwhile? > > That's a good question. It is up to the users of "slower" hardware > (e.g.embedded devices), I think. > yup, on the other hand, servers take so long to boot nowadays, that speeding up rc, IMHO, wont make a difference, or even if it's fast, a fsck that's running in the background will slow the host anyways :-). > Regards > Peter cheers, danny From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 16:04:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4648106568A for ; Sun, 20 Jul 2008 16:04:42 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 37C458FC16 for ; Sun, 20 Jul 2008 16:04:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so670771fgb.35 for ; Sun, 20 Jul 2008 09:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LZ2yEJjqnlQUVHHHxGee8B7JhChejOrOjsXbpLtKInc=; b=Mudn0VrkMEFoxpgX/FuqK6hfCN2n5iMbDlR5XFMAPBpmmElKWs8l2zgvnQ6vzS/Ugs v2DL0a5KhQtVZhDlp7eUHDfFGDleMkMEyRnR2PFsRk71UL+r7+qpiKOQsLZ5gv7WSPJi vya92p+TNxP2zV1J1Mke8KM3GVSI3ZqI92Fv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=u17sqMStdlzK4OXG/llsNkyr4lRqI+hGC60lSDnxTNYL7zOhup8qAjmG8NSXpw8YuS UbMHnuOBOTUHwWs4aocz9JHJyUvHMVoihr43rls4UuGxEAm8aV/jkj51/9cZG6Q8nWaG h13TZcfUCjAeMHnSWwgP7LnO4WKhhXXftdpg0= Received: by 10.86.72.3 with SMTP id u3mr2439376fga.62.1216569879403; Sun, 20 Jul 2008 09:04:39 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sun, 20 Jul 2008 09:04:39 -0700 (PDT) Message-ID: <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> Date: Sun, 20 Jul 2008 18:04:39 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Lothar Braun" In-Reply-To: <48833C50.8030507@lobraun.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> X-Google-Sender-Auth: b815cd2d34c2c225 Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 16:04:42 -0000 2008/7/20, Lothar Braun : > Hi Attilio, > > > > > can you please try this on the top of -CURRENT: > > http://www.freebsd.org/~attilio/xfs2.diff > > > > Thank you for the patch. The panic and the dead lock disappeard, but there > is a new problem insteed. The commands > > mkfs.xfs /dev/ad8s4 > mount -t xfs /dev/ad8s4 /home > mkdir /home/lothar > chown lothar:lothar /home/lothar For what I remind, it is likely XFS is still not ready for writing. This means you should only use it in read-only. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 16:26:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39178106567D for ; Sun, 20 Jul 2008 16:26:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id B71A18FC18 for ; Sun, 20 Jul 2008 16:26:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so674466fgb.35 for ; Sun, 20 Jul 2008 09:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=0a8CdSwqIx77+MgjaHl8ZCQ3NUJEZlM29VDCYf4uk5M=; b=H/snaMkuymPA7+wXILjUNyqHXO3v5XlOuO5XsIzJtFjBwzg/6DKNNLPeYYYCYTS/WR g2eEJeLnrbHjW4EgK+u0YUJ1ox8y/hlIMEFHMTA1tC1oL5IuBeDet0smMN/UgdFrAQb/ Jyma2+vkjE+317j4IXD+/6j2rW5S6/VAp8IMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mtEtpkgrkajm2/Pe3NlQnp061jcmUsJ4Yddn5ujL3vXak5yz36TRAsJ89ed+i3gNJo K4rKmmKrlCttT9MWEQ01SeHtghR4evj5oHFPsLRtv35dhXspQjMsW9a/h+VngSPEYznK hmUTrdhHZSUETPsZjR7hy6TcojWvFjpnmMLt4= Received: by 10.86.57.9 with SMTP id f9mr3562102fga.66.1216571165018; Sun, 20 Jul 2008 09:26:05 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sun, 20 Jul 2008 09:26:04 -0700 (PDT) Message-ID: <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> Date: Sun, 20 Jul 2008 18:26:04 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Lothar Braun" In-Reply-To: <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> X-Google-Sender-Auth: 835279189bde1c29 Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 16:26:07 -0000 2008/7/20, Attilio Rao : > 2008/7/20, Lothar Braun : > > > Hi Attilio, > > > > > > > > > can you please try this on the top of -CURRENT: > > > http://www.freebsd.org/~attilio/xfs2.diff > > > > > > > Thank you for the patch. The panic and the dead lock disappeard, but there > > is a new problem insteed. The commands > > > > mkfs.xfs /dev/ad8s4 > > mount -t xfs /dev/ad8s4 /home > > mkdir /home/lothar > > chown lothar:lothar /home/lothar > > > For what I remind, it is likely XFS is still not ready for writing. > This means you should only use it in read-only. Speaking of which, I think we should mark it again like a read-only fs until writing is not 100% ready. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 17:15:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC7E8106567E for ; Sun, 20 Jul 2008 17:15:04 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id B7F048FC12 for ; Sun, 20 Jul 2008 17:15:04 +0000 (UTC) (envelope-from rnoland@2hip.net) Received: from [192.168.1.151] (adsl-19-213-9.bna.bellsouth.net [68.19.213.9]) (authenticated bits=0) by gizmo.2hip.net (8.13.8/8.13.8) with ESMTP id m6KHEw3v044124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 13:14:58 -0400 (EDT) (envelope-from rnoland@2hip.net) From: Robert Noland To: Peter Ross In-Reply-To: <20080720022644.H23554@oldie.bigpond.com> References: <20080720022644.H23554@oldie.bigpond.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cdChWYDJYrWM8QnZlQ6F" Organization: 2Hip Networks Date: Sun, 20 Jul 2008 13:14:52 -0400 Message-Id: <1216574092.1887.1.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 17:15:05 -0000 --=-cdChWYDJYrWM8QnZlQ6F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2008-07-20 at 02:32 +1000, Peter Ross wrote: > [Resending - maybe I used the wrong mail address which is not subscribed=20 > to -current? Does it matter? Anyway, the message did not make it to the=20 > list, it seems, and I did not get a notice.. strange] > ---------- Forwarded message ---------- > Date: Sun, 20 Jul 2008 01:07:32 +1000 (EST) >=20 > On Sat, 19 Jul 2008, Robert Noland wrote: >=20 > > On Fri, 2008-07-18 at 22:19 -0700, Doug Barton wrote: > > > Bernd Walter wrote: > > > > Speaking about small systems, where startup time is more a problem = than > > > > on 08/15 desktop and server systems. > > > > What I would love to see is that scripts like moused, ypserv, lpt, = etc > > > > are not started if the services are disabled. > > >=20 > > > That wold be a neat trick, how do you propose we accomplish it? (no,=20 > > > I'm not being snide.) > > > ..=20 > > > One way you could do this is to have /etc/rc.d/active and=20 > > > /etc/rc.d/inactive (and probably an /etc/rc.d/system for critical=20 > > > stuff that most people shouldn't touch). Then you could have a=20 > > > vipw-like system to allow users to edit rc.conf that would move the=20 > > > scripts to the right directory. Of course, this would be fraught with= =20 > > > potential for problems. :) > >=20 > > I almost hate to toss this out there, but what about a sys v type rc? >=20 > Usually the scripts are running run_rc_command. >=20 > This does a checkyesno for the rcvar variable which is usually=20 > ${name}_enable. In most of the cases it uses set_rcvar to achieve this. >=20 > If so, /etc/rc could evaluate ${name}_enable (it already knows them via=20 > /etc/rc.conf) before actually calling a script. >=20 > There are some irregular names amongst the name of the rcvar variable. Actually, gnome comes to mind... The gnome_enable option, starts all of the relevant components of which there are a few... robert. > I am not 100% sure whether same of the scripts set ${name}_enable vaiable= s=20 > implicitly. That could complicate things. I could not find evidence by=20 > browsing through them. >=20 > I also do not know whether there are scripts that actually do something=20 > valuable before calling run_rc_command. >=20 > At the moment it looks to me that these excemptions could be dealt with b= y=20 > adapting the scripts so they meet the standard (running only when=20 > ${name}_enable is set). >=20 > I only looked through some of the /etc/rc.d scripts en detail (+ some=20 > greps for rcvar etc. in the directory) so it needs some more=20 > investigation. >=20 > If it works it avoids messing around with symlinks or moving scripts=20 > around, and it reduces the scripts that actually run. >=20 > As a sys admin I really like the BSD way of having everything relevant to= =20 > my system in one /etc/rc.conf. It is very convenient. >=20 > Regards > Peter > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=-cdChWYDJYrWM8QnZlQ6F Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkiDcowACgkQM4TrQ4qfRONsfwCfRqPh1qlJKr1jXoSL1v1EDR9o xSMAnjLB4qM6/zGxG4qAiqhEu8YqGoTE =HZGE -----END PGP SIGNATURE----- --=-cdChWYDJYrWM8QnZlQ6F-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 17:46:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72E56106567B for ; Sun, 20 Jul 2008 17:46:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id F10B58FC18 for ; Sun, 20 Jul 2008 17:46:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so688498fgb.35 for ; Sun, 20 Jul 2008 10:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6+LtWaIotFfZ8hHoAUOe2vaOis3B5ZCJuVOMlg6ubiQ=; b=jZAMeUuSs9EfBjfpnPwEStcQwhKUhCAsEN+5JXzim/OBBtntDoxpedVcMwaxpNiTSA LCy2o+422kXxWNd7jnlyqNWooI0WzkM0SVvD4QbdxuaBJvDQLfN6lTTwDktBxwdP318a 9NCaMoHxJmc2cZ35bb4uVkNidTFBTMibXBrpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=UXpUAZzJtQC4hNQQ/QLccTqiJ6hHhL+orjwOH3q6os5yvRR40vrJNfvzjZ3suAf1MH HDJZHPjQSZJRuR62BbFPD+Lt18bUi4NLIqE55kU/Ctj4mwh92NyHVrpRSgCS5lmmvgah kYahalWToiWylVxIgaIZA9o1YWBctGuHHRBtM= Received: by 10.86.49.13 with SMTP id w13mr3722474fgw.15.1216575991133; Sun, 20 Jul 2008 10:46:31 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sun, 20 Jul 2008 10:46:31 -0700 (PDT) Message-ID: <3bbf2fe10807201046i109caccfl88e8641f424226eb@mail.gmail.com> Date: Sun, 20 Jul 2008 19:46:31 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Lothar Braun" In-Reply-To: <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> X-Google-Sender-Auth: d6cc9877fab039ef Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 17:46:33 -0000 2008/7/20, Attilio Rao : > 2008/7/20, Attilio Rao : > > > 2008/7/20, Lothar Braun : > > > > > Hi Attilio, > > > > > > > > > > > > > can you please try this on the top of -CURRENT: > > > > http://www.freebsd.org/~attilio/xfs2.diff > > > > > > > > > > Thank you for the patch. The panic and the dead lock disappeard, but there > > > is a new problem insteed. The commands > > > > > > mkfs.xfs /dev/ad8s4 > > > mount -t xfs /dev/ad8s4 /home > > > mkdir /home/lothar > > > chown lothar:lothar /home/lothar > > > > > > For what I remind, it is likely XFS is still not ready for writing. > > This means you should only use it in read-only. > > > Speaking of which, I think we should mark it again like a read-only fs > until writing is not 100% ready. Lothar, can you please try this patch on the top of -CURRENT: http://www.freebsd.com/~attilio/xfs3.diff it should avoid to mount an xfs partition in write mode. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 18:30:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8745D1065671 for ; Sun, 20 Jul 2008 18:30:53 +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 086278FC1A for ; Sun, 20 Jul 2008 18:30:52 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl10-74.kln.forthnet.gr [77.49.137.74]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6KIUaCn007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 21:30:42 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6KIUaod009782; Sun, 20 Jul 2008 21:30:36 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6KIUZqd009781; Sun, 20 Jul 2008 21:30:35 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Paul B. Mahol" References: <3a142e750801220927q3b818ecg464c6319b5be30ca@mail.gmail.com> <3a142e750806030316s4b1145eck3062baf16ed3f4cf@mail.gmail.com> <87od6i8tjo.fsf@kobe.laptop> Date: Sun, 20 Jul 2008 21:30:35 +0300 In-Reply-To: <87od6i8tjo.fsf@kobe.laptop> (Giorgos Keramidas's message of "Tue, 03 Jun 2008 17:47:07 +0300") Message-ID: <871w1o4ddg.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6KIUaCn007159 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.79, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current Subject: Re: tcsh coredumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 18:30:53 -0000 On Tue, 03 Jun 2008 17:47:07 +0300, Giorgos Keramidas wrote: > On Tue, 3 Jun 2008 12:16:19 +0200, "Paul B. Mahol" wrote: >> Reminder that fix is still not available in HEAD. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=124191 > > No, it isn't. Sorry for that. I'll see if we are waiting for a new > tcsh drop for HEAD, and if not we'll have to take the file off the > vendor branc, I guess :-/ > > I've assigned the PR to me now... Fixed in HEAD. This is a long standing crash in tcsh, but I've committed the fix to svn:base/head/ and will merge it to stable branches in a couple of days. Note that the xgetpass() code is *still* broken. It fails to authenticate correctly even if you give the correct password. At least it doesn't crash now :) From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 18:34:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DB01065671 for ; Sun, 20 Jul 2008 18:34:01 +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 063748FC12 for ; Sun, 20 Jul 2008 18:34:00 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl10-74.kln.forthnet.gr [77.49.137.74]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6KIXTTJ007280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Jul 2008 21:33:35 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6KIXTh6009813; Sun, 20 Jul 2008 21:33:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6KIXTwJ009812; Sun, 20 Jul 2008 21:33:29 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Ed Schouten References: <20080702190901.GS14567@hoeg.nl> <20080720123256.GE21188@hoeg.nl> Date: Sun, 20 Jul 2008 21:33:29 +0300 In-Reply-To: <20080720123256.GE21188@hoeg.nl> (Ed Schouten's message of "Sun, 20 Jul 2008 14:32:56 +0200") Message-ID: <87wsjg2yo6.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6KIXTTJ007280 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.79, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.61, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Arch , FreeBSD Current Subject: Re: MPSAFE TTY schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 18:34:01 -0000 On Sun, 20 Jul 2008 14:32:56 +0200, Ed Schouten wrote: > Hello everyone, > > Today is July 20, which means I'm supposed to send you a message: > > * Ed Schouten wrote: >> July 20 2008: >> Send another heads-up to the lists about the new TTY layer. >> Kindly ask people to test the patchset, port more drivers, etc. > > As usual, the latest mpsafetty patchset can be found here. I would > really appreciate it if I could get more reviews on the code. Thanks! > > http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/ Hi Ed, I see the latest patch at: http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/mpsafetty-20080720.diff.gz Kris has mentioned that it breaks tcsh's autodetection for ptys (we've seen that before when /dev/pts kern.pts.enable=1 was added), so I'd like to build a test kernel+world with the patch to check this. Anything I should be careful about? From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 19:41:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ACA9106567F for ; Sun, 20 Jul 2008 19:41:20 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.176]) by mx1.freebsd.org (Postfix) with ESMTP id 367E28FC08 for ; Sun, 20 Jul 2008 19:41:19 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so863910ika.3 for ; Sun, 20 Jul 2008 12:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=G/BizW7qWh+EDykQmf4Ljt20NnIOvgPTNzJcpmDerRI=; b=nZb0p8jpIGuUJOUF0VxvOCGDyWgNX41WYno5xIyXHNx1FfMvWGlIm6JD7KY3WPR+H4 OPKTMOBeTpTPH2LYSko7So3/diyGNzOsVzWzu4/nDiuHZnb9VpWW3geWrGzAg0werOLv 9UjWqIyl/RHBe7O2zcobP5oEuOhb9J9/LAkXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=sLSmubInUTbOf/fm6Z4QDbUsD+USfUwRkvEAXUzMuhAz3zDLtFX04cwWAJc0sFwjyU KA9C5+kh4aG8U6QNSFx8bMOzuhDCk1NGz8NtVywNXTlqPn9E0tZRou8JxqfflLNMr6J6 TP/pSOlc0KXgQEjf3EbnC9ggX7kPOi5LLu2q0= Received: by 10.210.131.6 with SMTP id e6mr2479468ebd.10.1216581394150; Sun, 20 Jul 2008 12:16:34 -0700 (PDT) Received: by 10.210.62.13 with HTTP; Sun, 20 Jul 2008 12:16:34 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 12:16:34 -0700 From: "Mehmet Erol Sanliturk" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Handbook of FreeBSD : Improvement suggestion ( 1 ) . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 19:41:20 -0000 Dear Sirs , How to start X Window is described in the Handbook , but how it is closed , it is not described . If you include this information into Handbook X Window part it may be very useful to users . The hardware parts list like a form to record relevant information may be included into Handbook to be filled before starting configuration of X Window would be useful . In that way the installer user may prepare these values before starting configuration of X . This is required because some values are not detected correctly when left to installer causing an unusable booted FreeBSD . In such a case it is becoming necessary to install from scratch or when possible , configure related files which is difficult for a new user . Thank you very much , Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 20:47:12 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2FA31065670 for ; Sun, 20 Jul 2008 20:47:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outi.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id DC6F28FC0A for ; Sun, 20 Jul 2008 20:47:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id EB6D42476 for ; Sun, 20 Jul 2008 13:47:12 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 633EF2D6046 for ; Sun, 20 Jul 2008 13:47:12 -0700 (PDT) Message-ID: <4883A457.4060201@elischer.org> Date: Sun, 20 Jul 2008 13:47:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Symbol.map for libc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 20:47:13 -0000 I'm backporting the multi-routing table (ABI comapt version) to 7.x so that it can be in 7.1 where do I add the 'setfib' entry in the Symbol.map? do I just add it? or is there going to be a special set of symbols named as "added in 7.1"? From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 20:59:32 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 279F6106566C for ; Sun, 20 Jul 2008 20:59:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D133B8FC14 for ; Sun, 20 Jul 2008 20:59:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id D5B9228448 for ; Mon, 21 Jul 2008 04:59:30 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 24FEDEB886F; Mon, 21 Jul 2008 04:59:30 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id V0axa3e0Yfi6; Mon, 21 Jul 2008 04:59:24 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id ACD28EB0EC5; Mon, 21 Jul 2008 04:59:23 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=tdtXQWjg7y6G58QbfkA0gPtutMj2MnP2Pf3fVv5euVu1OZ3Z5GvBCF71qqJARbt/u nLWPaPyliUb02XYVMXMWA== Message-ID: <4883A729.1080002@delphij.net> Date: Sun, 20 Jul 2008 13:59:21 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Julian Elischer References: <4883A457.4060201@elischer.org> In-Reply-To: <4883A457.4060201@elischer.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Symbol.map for libc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 20:59:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: | I'm backporting the multi-routing table (ABI comapt version) to 7.x | so that it can be in 7.1 | | where do I add the 'setfib' entry in the Symbol.map? | | do I just add it? or is there going to be a special set of symbols named | as "added in 7.1"? This should be added into FBSD_1.1 symbol set like we have in -CURRENT, so that the binary would work without change in -CURRENT as they referenced the same symbol/version pair. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiDpykACgkQi+vbBBjt66BufACfZN8mdERTO6XuPYxQKyqkueH0 ClkAnAuFJ+NFZJ7EevpRaEZTCNaYm+5+ =RVdo -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 21:06:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286C31065672 for ; Sun, 20 Jul 2008 21:06:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 20DB38FC0C for ; Sun, 20 Jul 2008 21:06:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 03C762495; Sun, 20 Jul 2008 14:06:38 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 5A8E52D6060; Sun, 20 Jul 2008 14:06:37 -0700 (PDT) Message-ID: <4883A8E3.7090606@elischer.org> Date: Sun, 20 Jul 2008 14:06:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: d@delphij.net References: <4883A457.4060201@elischer.org> <4883A729.1080002@delphij.net> In-Reply-To: <4883A729.1080002@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Symbol.map for libc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 21:06:38 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julian Elischer wrote: > | I'm backporting the multi-routing table (ABI comapt version) to 7.x > | so that it can be in 7.1 > | > | where do I add the 'setfib' entry in the Symbol.map? > | > | do I just add it? or is there going to be a special set of symbols named > | as "added in 7.1"? > > This should be added into FBSD_1.1 symbol set like we have in -CURRENT, > so that the binary would work without change in -CURRENT as they > referenced the same symbol/version pair. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkiDpykACgkQi+vbBBjt66BufACfZN8mdERTO6XuPYxQKyqkueH0 > ClkAnAuFJ+NFZJ7EevpRaEZTCNaYm+5+ > =RVdo > -----END PGP SIGNATURE----- there is no 1.1 section in releng 7 From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 21:13:36 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82163106567C for ; Sun, 20 Jul 2008 21:13:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 36AA48FC2B for ; Sun, 20 Jul 2008 21:13:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 4CDED28448 for ; Mon, 21 Jul 2008 05:13:35 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 1AAACEB99E0; Mon, 21 Jul 2008 05:13:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 27vFNvfzV-k9; Mon, 21 Jul 2008 05:13:30 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 9726AEB0EC5; Mon, 21 Jul 2008 05:13:29 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=MvsGr/YnSNkPm+9NhlDEv8EDSLPn0dgzDHP17etT+uQo5/r4nt4MSSC7SbQ3Tqwa0 Qi8SFLhvwkzvAkPw7njhg== Message-ID: <4883AA77.5080000@delphij.net> Date: Sun, 20 Jul 2008 14:13:27 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Julian Elischer References: <4883A457.4060201@elischer.org> <4883A729.1080002@delphij.net> <4883A8E3.7090606@elischer.org> In-Reply-To: <4883A8E3.7090606@elischer.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: d@delphij.net, FreeBSD Current Subject: Re: Symbol.map for libc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 21:13:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: | Xin LI wrote: | Julian Elischer wrote: | | I'm backporting the multi-routing table (ABI comapt version) to 7.x | | so that it can be in 7.1 | | | | where do I add the 'setfib' entry in the Symbol.map? | | | | do I just add it? or is there going to be a special set of symbols | named | | as "added in 7.1"? | | This should be added into FBSD_1.1 symbol set like we have in -CURRENT, | so that the binary would work without change in -CURRENT as they | referenced the same symbol/version pair. [...] | there is no 1.1 section in releng 7 Yes, one should be added by the first person who touch this area :) Revision 179367 on RELENG_7 shows how to do this. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiDqncACgkQi+vbBBjt66AtsACfbHPK7gT9ONx042P6UKICYedQ K/QAn1EwrwMyLrv7hFnxmFtcr02HrrKQ =vPb4 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 20 21:36:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F7A81065671 for ; Sun, 20 Jul 2008 21:36:35 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 085FD8FC12 for ; Sun, 20 Jul 2008 21:36:34 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so436729nfh.33 for ; Sun, 20 Jul 2008 14:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=QIp3F7D0u4omrktawJTsnuWnTsCM6kBh10GZ/LFiV88=; b=ZxziiGTzHiOuaAVK8BY3n3GhFiahbQ64ezFgc24MX/ColB2/MWuYnoULpbJ3n4bBPF jcm4NXXGsSRdj7e8r9ZejgLNk68bCzsXq27mg4UzJVlGPrZ60vfFAyccuuyqUfhKhkU1 Sdz08+IPQNhZvEN+rNUt+nJDUzVpPUdoxF3WY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=EFAtQ29sGXDLCoKkUAOLJzLX74e26nnGwz+CJXHuBz33r7WVm21ss6PN3rApWmt3vB hl7mvFuihdYt/yvJAm3Y8lD/NK315vD0chnvuJyJxmIB/IP3m3dc/GkZnYe8QSmutY40 rhqeDZqAzVfIrRG0P1SRilOMz9G2cOGXoi8rQ= Received: by 10.210.139.15 with SMTP id m15mr2574919ebd.51.1216589793075; Sun, 20 Jul 2008 14:36:33 -0700 (PDT) Received: by 10.210.62.13 with HTTP; Sun, 20 Jul 2008 14:36:33 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 14:36:33 -0700 From: "Mehmet Erol Sanliturk" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Installation of FreeBSD . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 21:36:35 -0000 Dear Sirs , (1) The installer may be allowed to make an installation diskette or USB stick to store installation options . When a new installation is tried on the same machine or in another similar machine ( especially for multiple installations ), allow user to use such an aid to use input of options . As an example : Mandriva Free 2008 . (2) I know FreeBSD for a long time , but now more than six months I am using it to learn it properly and utilize it as a secure operating system and a platform for program development ( especially with Free Pascal ) . I am not fluent in C/C++ as much as Pascal and actually I am not using them . This means that I am not able to suggest any solution about mentioned improvements at present other than inform you about problems . (3) I want to inform you about a problem of booting of FreeBSD . I copied "/boot/defaults/loader.conf "as "/boot/loader.conf ". I have changed the following parameters : usb_load="YES" ukbd_load="YES" ums_load="YES" umass_load="YES" umodem_load="YES" uscanner_load="YES" After these changes when started to boot FreeBSD , it is locked in detecting ( or probing ) keyboard controller . Any one of the boot option selected from the initial boot menu did not worked . I am using Intel 965WHMKR mainboard , and Intel 6450 processor , 2 GB main memory , Seagate 250 GB SATA hard disk . I attached (i) USB keyboard (1) only ( worked to give initial parameters ) (2) with PS/2 keyboard ( worked to give initial parameters ) (ii) PS/2 keyboard only ( worked to give initial parameters ) . I removed hard disk and attached it to an ASUS mainboard . It could NOT booted due to lock in detecting ( or probing ) keyboard controller . Since initial boot could not be achieved it could not be possible to correct related configuration file , and all of my works have been wasted due to a new install . In FreeBSD installs , there is a very important missing feature : Boot and re-configure configuration files . Install ALWAYS insisting partition of disks without checking whether there are valid partitions or not , and it is not suggesting repair of existing configuration files in hard disk . If live file system CD or only boot CD is used , it is also starting to a new install . In any way it is not possible ( or I do not know how ) to mount hard disk partitions or directories to edit the configuration files . There is no any rescue CD ( let's say ) to repair the above mentioned parts ( configuration files ) . I think this is a very important point to consider . (4) During installation , if a list of ports collection is selected , it is continuously asking interchange of CD's . Instead of this , all of the CD contents may be copied into a temporary directory and then they may be installed from this directory . OR ( I do not know internal workings of pkg_add command ) a list of selected packages may be made and first all of the packages in CD 1 may be added , and then CD 2 packages may be added , etc . I copied all of the packages into a DVD , but it did NOT worked because the installer is requesting CD with its NUMBER by checking the number in a file . Instead of this , it may check presence of package and if the package is present it may be added , if it is not present the installer may request the CD which it contains the requested package . In that way a DVD containing all of the packages may be used . There no DVD *.ISO files for installations . If it is NOT diifcult to generate DVD *.ISO files , it may solve this CD interchanging difficulty . (5) (6) The above points show that installation steps of FreeBSD should be re-considered carefully when compared to other operating system installations . Personally I am a computer professional since 1974 and I have a PhD on Computer Engineering , and I find the install of FreeBSD difficult , but there are many MORE difficult other Operating Systems installations. (7) During an upgrade of FreeBSD , because of inability of boot due to a configuration file error , the installer is installing only the programs and leaving the configuration files unchanged . Since inability to boot is resulting from the error(s) in configuration file(s) , upgrading the FreeBSD is not solving the problem . On such a case it is becoming to commit a full re-install by re-structuring , re-partitioning , re-installing everything . To prevent such an install it would be very useful to include an item to upgrade menu to allow the installer to re-new or edit the configuration file(s) . With this facility sometimes it may not be necessary to re-install the programs . (8) During install , in the menus or action selection points , there is NO a "Back" option to go back and re-select an option . Approximately all the menus are advancing forward to a new step . If "Back" step is included in the menus it will make possible to correct errors . (9) In network card configuration , there is no a new re-start to configure another network card . In this part , repetition is necessary to configure multiple cards until an exit is selected . (10) Easiness of usage is NOT a GUI interface or text based interface , but the ability to follow steps to apply easily and to find information required to understand the step . In this regard help information may be displayed at the side of the install menus related to high-lighted items . Thank you very much , Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 00:16:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A3E106566C for ; Mon, 21 Jul 2008 00:16:57 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id BC1318FC14 for ; Mon, 21 Jul 2008 00:16:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so748727fgb.35 for ; Sun, 20 Jul 2008 17:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qoFJsnUoVF7smrMCwlgtYNJR5fn6yHY+qvJLY124ZU8=; b=BVS4bOMlrMjrVPnGryEv/3NCW+YQTP0mE/rdW4mkXV8zikRshFM/b8Ts7aWFNmybyJ ofSZp97XczfcjxiLaSCJrBtIpTQH6qNaRRYFB415lGf4T4qqiyePjk4YfvEbfVulUqJ/ VW/oJHN3EdjifVBPJr3rotxyEsXcoeMaMDPXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=PvKSSD1xM35A/oCzdgCle6cCgOUd94qsPfdIcJfTQJN6Q2j5/u7K4bGqpecbdWHIXY 2Fs52xCzH8sOMzYPyUQ0+YJ6M1unWIFJWNhNIPevgBcV2wuVs7MNLeH1caK/k/ZPzfbA x4Vrguyj2yEbxherDmEph/OFzphjA4Ls+pqgU= Received: by 10.86.33.19 with SMTP id g19mr1030435fgg.50.1216599415012; Sun, 20 Jul 2008 17:16:55 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Sun, 20 Jul 2008 17:16:54 -0700 (PDT) Message-ID: <7d6fde3d0807201716j6260d1b1hecacc090fb5fca03@mail.gmail.com> Date: Sun, 20 Jul 2008 17:16:54 -0700 From: "Garrett Cooper" To: "Mehmet Erol Sanliturk" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Installation of FreeBSD . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 00:16:57 -0000 On Sun, Jul 20, 2008 at 2:36 PM, Mehmet Erol Sanliturk wrote: > Dear Sirs , > [trimmed terse junk] > Mehmet Erol Sanliturk Mehmet, Please provide more helpful information and less commentary. Maybe break your comments up into separate emails and pass it along again. Also, try questions@ unless you're using 8-CURRENT based media. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 00:24:23 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 011AA106564A for ; Mon, 21 Jul 2008 00:24:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6F68FC16 for ; Mon, 21 Jul 2008 00:24:22 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so749774fgb.35 for ; Sun, 20 Jul 2008 17:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bSh2qP2eo8aI1PrbPkxqi2K0MKLZeRxYKExC5vT7CAQ=; b=D2vUO7N5p+scMxX1JbeGy/a3YgjOt8I2xGQifbSFvCGTIrAyTa3Bbwi5CmPCc/SAZr FQsKyGkgNlf4fEKtWlgw/2S7kCNcJoeLCqN89nMVXaAoAj2zwV7mq6TTRdoWRlai6ltS RLGbn8vPwV2dLAxQtlPhU8EYUvk/mBA2+mQrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UCo5KxvIPzs7AOFZFnr8pjEKgyIEXfCQBVRyjDsc8jD4UIKIfR3vrvlkFiIVFznF82 CK8FbCcS9VYgIdsA2ZWQGYqdlK4LskazeTaUzxS74BQT06SvQfzYZ3077USjC8o1YflS u+zrmeNiD2UrMaYLn1/MG4ifFLJDJzIMdvvD4= Received: by 10.86.33.19 with SMTP id g19mr1035660fgg.50.1216599861266; Sun, 20 Jul 2008 17:24:21 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Sun, 20 Jul 2008 17:24:21 -0700 (PDT) Message-ID: <7d6fde3d0807201724l17c5af2aw9ecc421b46e514f4@mail.gmail.com> Date: Sun, 20 Jul 2008 17:24:21 -0700 From: "Garrett Cooper" To: "Mehmet Erol Sanliturk" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Handbook of FreeBSD : Improvement suggestion ( 1 ) . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 00:24:23 -0000 On Sun, Jul 20, 2008 at 12:16 PM, Mehmet Erol Sanliturk wrote: > Dear Sirs , > > > How to start X Window is described in the Handbook , but how it is closed , > it is not described . > If you include this information into Handbook X Window part it may be very > useful to users . This isn't in the scope of the handbook (IMHO), and given the number of DE's and WM's out there, ways to represent logon and logoff, this is unnecessary. Besides, the page references other pages which go into how to use the respective X11 environment in more gross detail than the handbook should... > The hardware parts list like a form to record relevant information may be > included into Handbook to be filled > before starting configuration of X Window would be useful . > In that way the installer user may prepare these values before starting > configuration of X . > This is required because some values are not detected correctly when left to > installer causing > an unusable booted FreeBSD . In such a case > it is becoming necessary to install from scratch or when possible , > configure related files which is > difficult for a new user . This is an issue that is just a learning experience with installing X11 and is covered to some extent in . A reference to pciconf -lv couldn't hurt though as a "gather process" before configuring things. > Thank you very much , > > Mehmet Erol Sanliturk Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 02:19:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8890C1065679 for ; Mon, 21 Jul 2008 02:19:38 +0000 (UTC) (envelope-from unixmania@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 0B8768FC13 for ; Mon, 21 Jul 2008 02:19:37 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so233452uge.37 for ; Sun, 20 Jul 2008 19:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Xvsfpg8DZy387I9hkXZua7hYaw/GwLLOLi7Umnp6dVA=; b=m1Ed36IyRRuQTHwp5f5xHfbu+3HLesUSPgEVe7bdGnmDc3JqsMu5+6htgrNg0nyOdX nare/4QbrH8WOS+AsEQe54rFXCnTsX2C8N8KjSpVhmk3xvxdoU0t38TbnYklxoych6tu g9bTlO90J72miNFXYF0Yq/eFXSy0FJdo8A4/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Wf6zjFsijeOpRt1DcVIgCB7bt+1rQruJfNx3/RzfeL6fT3bB7f/MpKL7SYrs2eEMuN sbR9IrJW/eQEKO20+kUH/7YnghKIUu1LQnEIH2YwFQ69NKkAVgqatYwhpeFpH7yBwHgY 0o1nsNsK1iugh8UCf/QeTYYnTthuKcrHMAj04= Received: by 10.67.116.8 with SMTP id t8mr1290999ugm.57.1216605301518; Sun, 20 Jul 2008 18:55:01 -0700 (PDT) Received: by 10.67.31.16 with HTTP; Sun, 20 Jul 2008 18:55:01 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 22:55:01 -0300 From: "Carlos A. M. dos Santos" To: "Mehmet Erol Sanliturk" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Installation of FreeBSD . X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 02:19:38 -0000 On Sun, Jul 20, 2008 at 6:36 PM, Mehmet Erol Sanliturk wrote: > The installer may be allowed to make an installation diskette or USB stick > to store installation options . > When a new installation is tried on the same machine or in another similar > machine ( especially for multiple installations ), > allow user to use such an aid to use input of options . > As an example : Mandriva Free 2008 . The sysinstall(8) utility already automatic installation (though it could be improved). Nothing prevents you also from installing FreeBSD on a thumb drive and create some custom installation script. [...] > I am not fluent in C/C++ as much as Pascal and actually I am not using them. > This means that I am not able to suggest any solution about mentioned > improvements at present other than > inform you about problems . I doubt you would need C/C++ or Pascal. Shell scripting would suffice. > I copied "/boot/defaults/loader.conf "as "/boot/loader.conf ". The loader already reads /boot/defaults/loader.conf so you only need to add to /boot/loader.conf the things that you want to change. > I have changed the following parameters : > > usb_load="YES" > ukbd_load="YES" > ums_load="YES" > umass_load="YES" > umodem_load="YES" > uscanner_load="YES" > > > After these changes when started to boot FreeBSD , it is locked in detecting > ( or probing ) keyboard controller . I guess you are attempting to load ukbd with the GENERIC kernel, that already includes the driver. [trimmed stuff] > There is no any rescue CD ( let's say ) to repair the above mentioned parts > ( configuration files ) . > > I think this is a very important point to consider . ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.0/7.0-RELEASE-i386-livefs.iso > During installation , if a list of ports collection is selected , it is > continuously asking interchange of CD's . [trimmed stuff] > There no DVD *.ISO files for installations . If it is NOT diifcult to > generate DVD *.ISO files , > it may solve this CD interchanging difficulty . This was also lengthly discussed before too. Consider the option of installing packages from network. If an installation DVD is required then look at FreeBSD Mall: http://www.freebsdmall.com/cgi-bin/fm > The above points show that installation steps of FreeBSD should be > re-considered carefully > when compared to other operating system installations . They are already being considered. Please follow the discussion lists for a while. [discussion about installation, GUI-based installation, et cetera] There are several ongoing projects attempting to address this. Take a look at PC-BSD and DesktopBSD: http://www.desktopbsd.net/ http://www.pcbsd.org/ -- If you think things can't get worse it's probably only because you lack sufficient imagination. From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 10:49:34 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6331065677 for ; Mon, 21 Jul 2008 10:49:34 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp11.yandex.ru (smtp11.yandex.ru [213.180.223.93]) by mx1.freebsd.org (Postfix) with ESMTP id CFB4D8FC1F for ; Mon, 21 Jul 2008 10:49:32 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:42747 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1247007AbYGUKh4 (ORCPT ); Mon, 21 Jul 2008 14:37:56 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp11 X-Yandex-TimeMark: 1216636676 X-MsgDayCount: 6 X-Comment: RFC 2476 MSA function at smtp11.yandex.ru logged sender identity as: bu7cher Message-ID: <4884668C.5060606@yandex.ru> Date: Mon, 21 Jul 2008 14:35:56 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Sergey G Nasonov References: <200807151124.36621.snasonov@bcc.ru> In-Reply-To: <200807151124.36621.snasonov@bcc.ru> Content-Type: multipart/mixed; boundary="------------070900010409000403070108" Cc: freebsd-current@freebsd.org, =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= Subject: RFC, RFT: AHCI driver reorganization (was: Re: ATA subsystem lost drive after resume process) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 10:49:34 -0000 This is a multi-part message in MIME format. --------------070900010409000403070108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sergey G Nasonov wrote: > to disk. So the basic issue preventing normal suspend/resume > process on modern Lenovo laptops is ata subsystem. Does anyone can > help with this problem? I can test any path or provide additional > info. Hi, All. I wrote patch for AHCI driver and Sergey tested it. So, He reported that now "suspend/resume" works on his laptop. I'll try to describe all changes which my patch makes. 1. Initialization: * Global AHCI reset code moved to ata_ahci_reset_controller() function (it will be reused in ata_ahci_resume). * Detection of implemented ports moved to ata_ahci_allocate() function (i think it isn't needed to detect it on each reset). * From ata_ahci_allocate() function removed all working code, only initialization code is here. 2. Resetting: * ata_ahci_reset() function reorganized and splitted to several functions: ata_ahci_stop_channel() - stop all port activity; ata_ahci_fre_stop() - disable FIS receiving; ata_ahci_fre_start() - setup work areas and enable FIS receiving; ata_ahci_clo_enable() - enable command list override. * working code from ata_ahci_allocate moved to ata_ahci_reset. * CLO shall only be set immediately prior to setting the PxCMD.ST bit to '1' (from AHCI spec). * Software shall not set PxCMD.ST to 1 until it is determined that a functional device is present on the port (from AHCI spec). * removed hack when didn't detect signature asuming disk device (it may broke some systems, but it needs testing). 3. Interrupts handling: * Call ata_sata_phy_check_events() only when PHY changing detected. * Fatal error handling changed. 4. Suspend/resume: * Added new methods to atapci(4) driver * Added suspend/resume implementation for AHCI: + Software must disable interrupts prior to requesting a transition of the HBA to the D3 state. + Reset controller and enable interrupts before resume. So, any comments and suggestions are welcome. -- WBR, Andrey V. Elsukov --------------070900010409000403070108 Content-Type: text/plain; name="ata_ahci_improvements_with_suspend_resume.diff.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ata_ahci_improvements_with_suspend_resume.diff.txt" SW5kZXg6IHNyYy9zeXMvZGV2L2F0YS9hdGEtYWxsLmgKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL25jdnMvc3JjL3N5cy9kZXYvYXRhL2F0YS1hbGwuaCx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS4xMzMKZGlmZiAtdSAtYiAtcCAtcjEuMTMzIGF0YS1hbGwuaAotLS0gc3JjL3N5cy9k ZXYvYXRhL2F0YS1hbGwuaAkxNyBBcHIgMjAwOCAxMjoyOTozNSAtMDAwMAkxLjEzMworKysg c3JjL3N5cy9kZXYvYXRhL2F0YS1hbGwuaAkyMSBKdWwgMjAwOCAwOToyMzozMSAtMDAwMApA QCAtMTg4LDYgKzE4OCw5IEBACiAjZGVmaW5lICAgICAgICAgQVRBX0FIQ0lfUF9JWF9IQkYg ICAgICAgMHgyMDAwMDAwMAogI2RlZmluZSAgICAgICAgIEFUQV9BSENJX1BfSVhfVEZFICAg ICAgIDB4NDAwMDAwMDAKICNkZWZpbmUgICAgICAgICBBVEFfQUhDSV9QX0lYX0NQRCAgICAg ICAweDgwMDAwMDAwCisjZGVmaW5lICAgICAgICAgQVRBX0FIQ0lfUF9JWF9GRSBcCisgICAg ICAgICAgICAgICAgICAgICAgICAoQVRBX0FIQ0lfUF9JWF9URkUgfCBBVEFfQUhDSV9QX0lY X0hCRiB8XAorICAgICAgICAgICAgICAgICAgICAgICAgIEFUQV9BSENJX1BfSVhfSEJEIHwg QVRBX0FIQ0lfUF9JWF9JRikKIAogI2RlZmluZSBBVEFfQUhDSV9QX0NNRCAgICAgICAgICAg ICAgICAgIDB4MTE4CiAjZGVmaW5lICAgICAgICAgQVRBX0FIQ0lfUF9DTURfU1QgICAgICAg MHgwMDAwMDAwMQpJbmRleDogc3JjL3N5cy9kZXYvYXRhL2F0YS1jaGlwc2V0LmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL3N5cy9kZXYvYXRhL2F0YS1jaGlwc2V0LmMs dgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjI0CmRpZmYgLXUgLWIgLXAgLXIxLjIyNCBhdGEt Y2hpcHNldC5jCi0tLSBzcmMvc3lzL2Rldi9hdGEvYXRhLWNoaXBzZXQuYwkxMCBKdWwgMjAw OCAyMTozNjo1MyAtMDAwMAkxLjIyNAorKysgc3JjL3N5cy9kZXYvYXRhL2F0YS1jaGlwc2V0 LmMJMjEgSnVsIDIwMDggMDk6MjM6MzEgLTAwMDAKQEAgLTYyLDYgKzYyLDkgQEAgc3RhdGlj IGludCBhdGFfc2F0YV9jb25uZWN0KHN0cnVjdCBhdGFfYwogc3RhdGljIHZvaWQgYXRhX3Nh dGFfc2V0bW9kZShkZXZpY2VfdCBkZXYsIGludCBtb2RlKTsKIHN0YXRpYyBpbnQgYXRhX3Jl cXVlc3QyZmlzX2gyZChzdHJ1Y3QgYXRhX3JlcXVlc3QgKnJlcXVlc3QsIHVfaW50OF90ICpm aXMpOwogc3RhdGljIGludCBhdGFfYWhjaV9jaGlwaW5pdChkZXZpY2VfdCBkZXYpOworc3Rh dGljIGludCBhdGFfYWhjaV9zdXNwZW5kKGRldmljZV90IGRldik7CitzdGF0aWMgaW50IGF0 YV9haGNpX3Jlc3VtZShkZXZpY2VfdCBkZXYpOworc3RhdGljIGludCBhdGFfYWhjaV9yZXNl dF9jb250cm9sbGVyKGRldmljZV90IGRldik7CiBzdGF0aWMgaW50IGF0YV9haGNpX2FsbG9j YXRlKGRldmljZV90IGRldik7CiBzdGF0aWMgaW50IGF0YV9haGNpX3N0YXR1cyhkZXZpY2Vf dCBkZXYpOwogc3RhdGljIGludCBhdGFfYWhjaV9iZWdpbl90cmFuc2FjdGlvbihzdHJ1Y3Qg YXRhX3JlcXVlc3QgKnJlcXVlc3QpOwpAQCAtNjksNiArNzIsMTEgQEAgc3RhdGljIGludCBh dGFfYWhjaV9lbmRfdHJhbnNhY3Rpb24oc3RydQogc3RhdGljIGludCBhdGFfYWhjaV9wbV9y ZWFkKGRldmljZV90IGRldiwgaW50IHBvcnQsIGludCByZWcsIHVfaW50MzJfdCAqcmVzdWx0 KTsKIHN0YXRpYyBpbnQgYXRhX2FoY2lfcG1fd3JpdGUoZGV2aWNlX3QgZGV2LCBpbnQgcG9y dCwgaW50IHJlZywgdV9pbnQzMl90IHJlc3VsdCk7CiBzdGF0aWMgdV9pbnQzMl90IGF0YV9h aGNpX3NvZnRyZXNldChkZXZpY2VfdCBkZXYsIGludCBwb3J0KTsKK3N0YXRpYyB2b2lkIGF0 YV9haGNpX2ZyZV9zdGFydChzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoKTsKK3N0YXRpYyB2b2lk IGF0YV9haGNpX2ZyZV9zdG9wKHN0cnVjdCBhdGFfY2hhbm5lbCAqY2gpOworc3RhdGljIHZv aWQgYXRhX2FoY2lfc3RvcF9jaGFubmVsKHN0cnVjdCBhdGFfY2hhbm5lbCAqY2gpOworc3Rh dGljIHZvaWQgYXRhX2FoY2lfcmVzdGFydF9jaGFubmVsKHN0cnVjdCBhdGFfY2hhbm5lbCAq Y2gpOworc3RhdGljIHZvaWQgYXRhX2FoY2lfY2xvX2VuYWJsZShzdHJ1Y3QgYXRhX2NoYW5u ZWwgKmNoKTsKIHN0YXRpYyB2b2lkIGF0YV9haGNpX3Jlc2V0KGRldmljZV90IGRldik7CiBz dGF0aWMgdm9pZCBhdGFfYWhjaV9kbWFzZXRwcmQodm9pZCAqeHNjLCBidXNfZG1hX3NlZ21l bnRfdCAqc2VncywgaW50IG5zZWdzLCBpbnQgZXJyb3IpOwogc3RhdGljIHZvaWQgYXRhX2Fo Y2lfZG1haW5pdChkZXZpY2VfdCBkZXYpOwpAQCAtNTgyLDYgKzU5MCwyOSBAQCBhdGFfYWhj aV9pZGVudChkZXZpY2VfdCBkZXYpCiB9CiAKIHN0YXRpYyBpbnQKK2F0YV9haGNpX3Jlc2V0 X2NvbnRyb2xsZXIoZGV2aWNlX3QgZGV2KQoreworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRy b2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKyAgICAvKiBlbmFibGUg QUhDSSBtb2RlICovCisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMs IEFUQV9BSENJX0dIQ19BRSk7CisKKyAgICAvKiByZXNldCBBSENJIGNvbnRyb2xsZXIgKi8K KyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0dIQywgQVRBX0FIQ0lfR0hD X0hSKTsKKyAgICBERUxBWSgxMDAwMDAwKTsKKyAgICBpZiAoQVRBX0lOTChjdGxyLT5yX3Jl czIsIEFUQV9BSENJX0dIQykgJiBBVEFfQUhDSV9HSENfSFIpIHsKKwlidXNfcmVsZWFzZV9y ZXNvdXJjZShkZXYsIGN0bHItPnJfdHlwZTIsIGN0bHItPnJfcmlkMiwgY3Rsci0+cl9yZXMy KTsKKwlkZXZpY2VfcHJpbnRmKGRldiwgIkFIQ0kgY29udHJvbGxlciByZXNldCBmYWlsdXJl XG4iKTsKKwlyZXR1cm4gRU5YSU87CisgICAgfQorCisgICAgLyogcmVlbmFibGUgQUhDSSBt b2RlICovCisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMsIEFUQV9B SENJX0dIQ19BRSk7CisKKyAgICByZXR1cm4gMDsKK30KKworc3RhdGljIGludAogYXRhX2Fo Y2lfY2hpcGluaXQoZGV2aWNlX3QgZGV2KQogewogICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRy b2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CkBAIC02MDIsMjAgKzYzMyw4 IEBAIGF0YV9haGNpX2NoaXBpbml0KGRldmljZV90IGRldikKICAgICBlbHNlCiAJZGV2aWNl X3ByaW50ZihkZXYsICJBSENJIGNhbGxlZCBmcm9tIHZlbmRvciBzcGVjaWZpYyBkcml2ZXJc biIpOwogCi0gICAgLyogZW5hYmxlIEFIQ0kgbW9kZSAqLwotICAgIEFUQV9PVVRMKGN0bHIt PnJfcmVzMiwgQVRBX0FIQ0lfR0hDLCBBVEFfQUhDSV9HSENfQUUpOwotCi0gICAgLyogcmVz ZXQgQUhDSSBjb250cm9sbGVyICovCi0gICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFf QUhDSV9HSEMsIEFUQV9BSENJX0dIQ19IUik7Ci0gICAgREVMQVkoMTAwMDAwMCk7Ci0gICAg aWYgKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMpICYgQVRBX0FIQ0lfR0hD X0hSKSB7Ci0JYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBjdGxyLT5yX3R5cGUyLCBjdGxy LT5yX3JpZDIsIGN0bHItPnJfcmVzMik7Ci0JZGV2aWNlX3ByaW50ZihkZXYsICJBSENJIGNv bnRyb2xsZXIgcmVzZXQgZmFpbHVyZVxuIik7CisgICAgaWYgKGF0YV9haGNpX3Jlc2V0X2Nv bnRyb2xsZXIoZGV2KSkKIAlyZXR1cm4gRU5YSU87Ci0gICAgfQotCi0gICAgLyogcmVlbmFi bGUgQUhDSSBtb2RlICovCi0gICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9H SEMsIEFUQV9BSENJX0dIQ19BRSk7CiAKICAgICAvKiBnZXQgdGhlIG51bWJlciBvZiBIVyBj aGFubmVscyAqLwogICAgIGN0bHItPmNoYW5uZWxzID0KQEAgLTYzMyw2ICs2NTIsOCBAQCBh dGFfYWhjaV9jaGlwaW5pdChkZXZpY2VfdCBkZXYpCiAgICAgY3Rsci0+ZG1haW5pdCA9IGF0 YV9haGNpX2RtYWluaXQ7CiAgICAgY3Rsci0+YWxsb2NhdGUgPSBhdGFfYWhjaV9hbGxvY2F0 ZTsKICAgICBjdGxyLT5zZXRtb2RlID0gYXRhX3NhdGFfc2V0bW9kZTsKKyAgICBjdGxyLT5y ZXN1bWUgPSBhdGFfYWhjaV9yZXN1bWU7CisgICAgY3Rsci0+c3VzcGVuZCA9IGF0YV9haGNp X3N1c3BlbmQ7CiAKICAgICAvKiBlbmFibGUgUENJIGludGVycnVwdCAqLwogICAgIHBjaV93 cml0ZV9jb25maWcoZGV2LCBQQ0lSX0NPTU1BTkQsCkBAIC02NTUsOSArNjc2LDEzIEBAIGF0 YV9haGNpX2FsbG9jYXRlKGRldmljZV90IGRldikKIHsKICAgICBzdHJ1Y3QgYXRhX3BjaV9j b250cm9sbGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChk ZXYpKTsKICAgICBzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOwotICAgIHVfaW50NjRfdCB3b3JrOwogICAgIGludCBvZmZzZXQgPSBjaC0+dW5pdCA8 PCA3OwogCisgICAgaWYgKCEoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BJKSAm ICgxIDw8IGNoLT51bml0KSkpIHsKKwlkZXZpY2VfcHJpbnRmKGRldiwgInBvcnQgbm90IGlt cGxlbWVudGVkXG4iKTsKKwlyZXR1cm4gRU5YSU87CisgICAgfQorCiAgICAgLyogc2V0IHRo ZSBTQVRBIHJlc291cmNlcyAqLwogICAgIGNoLT5yX2lvW0FUQV9TU1RBVFVTXS5yZXMgPSBj dGxyLT5yX3JlczI7CiAgICAgY2gtPnJfaW9bQVRBX1NTVEFUVVNdLm9mZnNldCA9IEFUQV9B SENJX1BfU1NUUyArIG9mZnNldDsKQEAgLTY3NiwzMCArNzAxLDQ1IEBAIGF0YV9haGNpX2Fs bG9jYXRlKGRldmljZV90IGRldikKICAgICBjaC0+aHcucG1fcmVhZCA9IGF0YV9haGNpX3Bt X3JlYWQ7CiAgICAgY2gtPmh3LnBtX3dyaXRlID0gYXRhX2FoY2lfcG1fd3JpdGU7CiAKLSAg ICAvKiBzZXR1cCB3b3JrIGFyZWFzICovCi0gICAgd29yayA9IGNoLT5kbWEud29ya19idXMg KyBBVEFfQUhDSV9DTF9PRkZTRVQ7Ci0gICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFf QUhDSV9QX0NMQiArIG9mZnNldCwgd29yayAmIDB4ZmZmZmZmZmYpOwotICAgIEFUQV9PVVRM KGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTEJVICsgb2Zmc2V0LCB3b3JrID4+IDMyKTsK KyAgICByZXR1cm4gMDsKK30KIAotICAgIHdvcmsgPSBjaC0+ZG1hLndvcmtfYnVzICsgQVRB X0FIQ0lfRkJfT0ZGU0VUOwotICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lf UF9GQiArIG9mZnNldCwgd29yayAmIDB4ZmZmZmZmZmYpOyAKLSAgICBBVEFfT1VUTChjdGxy LT5yX3JlczIsIEFUQV9BSENJX1BfRkJVICsgb2Zmc2V0LCB3b3JrID4+IDMyKTsKK3N0YXRp YyBpbnQKK2F0YV9haGNpX3N1c3BlbmQoZGV2aWNlX3QgZGV2KQoreworICAgIHN0cnVjdCBh dGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKLSAg ICAvKiBlbmFibGUgd2FudGVkIHBvcnQgaW50ZXJydXB0cyAqLwotICAgIEFUQV9PVVRMKGN0 bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9JRSArIG9mZnNldCwKLQkgICAgIChBVEFfQUhDSV9Q X0lYX0NQRCB8IEFUQV9BSENJX1BfSVhfVEZFIHwgQVRBX0FIQ0lfUF9JWF9IQkYgfAotCSAg ICAgIEFUQV9BSENJX1BfSVhfSEJEIHwgQVRBX0FIQ0lfUF9JWF9JRiB8IEFUQV9BSENJX1Bf SVhfT0YgfAotCSAgICAgIEFUQV9BSENJX1BfSVhfUFJDIHwgQVRBX0FIQ0lfUF9JWF9QQyB8 IEFUQV9BSENJX1BfSVhfRFAgfAotCSAgICAgIEFUQV9BSENJX1BfSVhfVUYgfCBBVEFfQUhD SV9QX0lYX1NEQiB8IEFUQV9BSENJX1BfSVhfRFMgfAotCSAgICAgIEFUQV9BSENJX1BfSVhf UFMgfCBBVEFfQUhDSV9QX0lYX0RIUikpOworICAgIC8qIFhYWDogUHhDTUQuU1QgbXVzdCBi ZSBjbGVhcmVkIHRvICcwJyBiZWZvcmUgZW50cnkgaW50byB0aGUKKyAgICAgKiBEMyBwb3dl ciBzdGF0ZS4KKyAgICAgKi8KIAotICAgIC8qIGVuYWJsZSBGSVMgYmFzZWQgc3dpdGNoaW5n ICovCi0gICAgLy9BVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfRkJTICsgb2Zm c2V0LCAweDAwMDAwMDAzKTsKKyAgICAvKiBTb2Z0d2FyZSBtdXN0IGRpc2FibGUgaW50ZXJy dXB0cyAoR0hDLklFIG11c3QgYmUgY2xlYXJlZCB0byAwKQorICAgICAqIHByaW9yIHRvIHJl cXVlc3RpbmcgYSB0cmFuc2l0aW9uIG9mIHRoZSBIQkEgdG8gdGhlIEQzIHN0YXRlLgorICAg ICAqLwogCi0gICAgLyogc3RhcnQgb3BlcmF0aW9ucyBvbiB0aGlzIGNoYW5uZWwgKi8KLSAg ICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LAotCSAg ICAgKEFUQV9BSENJX1BfQ01EX0FDVElWRSB8IEFUQV9BSENJX1BfQ01EX0ZSRSB8Ci0JICAg ICAgQVRBX0FIQ0lfUF9DTURfUE9EIHwgQVRBX0FIQ0lfUF9DTURfU1VEIHwgQVRBX0FIQ0lf UF9DTURfU1QpKTsKKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0dIQywK KwkgICAgIEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9HSEMpICYgKH5BVEFfQUhD SV9HSENfSUUpKTsKKworICAgIHJldHVybiAwOworfQorCitzdGF0aWMgaW50CithdGFfYWhj aV9yZXN1bWUoZGV2aWNlX3QgZGV2KQoreworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xs ZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKyAgICAvKiByZXNldCBjb250 cm9sbGVyICovCisgICAgaWYgKGF0YV9haGNpX3Jlc2V0X2NvbnRyb2xsZXIoZGV2KSkKKwly ZXR1cm4gRU5YSU87IC8qIFhYWCAqLworCisgICAgLyogY2xlYXIgaW50ZXJydXB0cyAqLwor ICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfSVMsIEFUQV9JTkwoY3Rsci0+ cl9yZXMyLCBBVEFfQUhDSV9JUykpOworCisgICAgLyogZW5hYmxlIEFIQ0kgaW50ZXJydXB0 cyAqLworICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfR0hDLAorCSAgICAg QVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0dIQykgfCBBVEFfQUhDSV9HSENfSUUp OworCisgICAgLyogbmV4dCBwYXJ0IHdpbGwgYmUgZG9uZSBieSBhdGFfcmVzdW1lICovCiAg ICAgcmV0dXJuIDA7CiB9CiAKQEAgLTcxNiwzOCArNzU2LDI0IEBAIGF0YV9haGNpX3N0YXR1 cyhkZXZpY2VfdCBkZXYpCiAJdV9pbnQzMl90IGNzdGF0dXMgPSBBVEFfSU5MKGN0bHItPnJf cmVzMiwgQVRBX0FIQ0lfUF9DSSArIG9mZnNldCk7CiAKIAkvKiBjbGVhciBpbnRlcnJ1cHQo cykgKi8KLQlBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX0lTLCBhY3Rpb24gJiAo MSA8PCBjaC0+dW5pdCkpOwogCUFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9J UyArIG9mZnNldCwgaXN0YXR1cyk7CisJQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhD SV9JUywgYWN0aW9uICYgKDEgPDwgY2gtPnVuaXQpKTsKIAogCS8qIGRvIHdlIGhhdmUgYW55 IFBIWSBldmVudHMgPyAqLwotCS8qIFhYWCBTT1MgY2hlY2sgaXN0YXR1cyBwaHkgYml0cyAq LworCWlmIChpc3RhdHVzICYgKEFUQV9BSENJX1BfSVhfUFJDIHwgQVRBX0FIQ0lfUF9JWF9Q QykpCiAJYXRhX3NhdGFfcGh5X2NoZWNrX2V2ZW50cyhkZXYpOwogCiAJLyogZG8gd2UgaGF2 ZSBhIHBvdGVudGlhbGx5IGhhbmdpbmcgZW5naW5lIHRvIHRha2UgY2FyZSBvZj8gKi8KIAkv KiBYWFggU09TIHdoYXQgdG9kbyBvbiBOQ1EgKi8KLQlpZiAoKGlzdGF0dXMgJiAweDc4NDAw MDUwKSAmJiAoY3N0YXR1cyAmIDEpKSB7Ci0KLQkgICAgdV9pbnQzMl90IGNtZCA9IEFUQV9J TkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCk7Ci0JICAgIGludCB0 aW1lb3V0ID0gMDsKLQotCSAgICAvKiBraWxsIG9mZiBhbGwgYWN0aXZpdHkgb24gdGhpcyBj aGFubmVsICovCi0JICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTUQg KyBvZmZzZXQsCi0JCSAgICAgY21kICYgfihBVEFfQUhDSV9QX0NNRF9GUkUgfCBBVEFfQUhD SV9QX0NNRF9TVCkpOwotCi0JICAgIC8qIFhYWCBTT1MgdGhpcyBpcyBub3QgZW50aXJlbHkg d3JvbmcgKi8KLQkgICAgZG8gewotCQlERUxBWSgxMDAwKTsKLQkJaWYgKHRpbWVvdXQrKyA+ IDEwMDApIHsKLQkJICAgIGRldmljZV9wcmludGYoZGV2LCAic3RvcHBpbmcgQUhDSSBlbmdp bmUgZmFpbGVkXG4iKTsKLQkJICAgIGJyZWFrOwotCQl9Ci0gICAgCSAgICB9IHdoaWxlIChB VEFfSU5MKGN0bHItPnJfcmVzMiwKLQkJCSAgICAgQVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQp ICYgQVRBX0FIQ0lfUF9DTURfQ1IpOwotCi0JICAgIC8qIHN0YXJ0IG9wZXJhdGlvbnMgb24g dGhpcyBjaGFubmVsICovCi0JICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lf UF9DTUQgKyBvZmZzZXQsCi0JCSAgICAgY21kIHwgKEFUQV9BSENJX1BfQ01EX0ZSRSB8IEFU QV9BSENJX1BfQ01EX1NUKSk7Ci0KKwlpZiAoKGlzdGF0dXMgJiBBVEFfQUhDSV9QX0lYX0ZF KSAmJiAoY3N0YXR1cyAmIDEpKSB7CisJICAgIGlmIChib290dmVyYm9zZSkKKwkJZGV2aWNl X3ByaW50ZihkZXYsICJQSFkgZmF0YWwgZXJyb3I6IFB4SVMgPSAweCUwOHhcbiIsCisJCQkg ICAgaXN0YXR1cyk7CisJICAgIC8qIFRvIHJlY292ZXIgZmF0YWwgZXJyb3JzLCB0aGUgcG9y dCBtdXN0IGJlIHJlc3RhcnRlZDsKKwkgICAgICogdGhlIHBvcnQgaXMgcmVzdGFydGVkIGJ5 IGNsZWFyaW5nIFB4Q01ELlNUIHRvICcwJyBhbmQKKwkgICAgICogdGhlbiBzZXR0aW5nIFB4 Q01ELlNUIHRvICcxJy4KKwkgICAgICovCisJICAgIGF0YV9haGNpX3Jlc3RhcnRfY2hhbm5l bChjaCk7CiAJICAgIHJldHVybiAxOwogCX0KIAllbHNlCkBAIC05OTgsNDYgKzEwMjQsMTA3 IEBAIGF0YV9haGNpX3BtX3dyaXRlKGRldmljZV90IGRldiwgaW50IHBvcnQKICAgICByZXR1 cm4gKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX1RGRCArIG9mZnNldCkgPj4g OCkgJiAweGZmOwogfQogCisvKiBDTE8gc2hhbGwgb25seSBiZSBzZXQgaW1tZWRpYXRlbHkg cHJpb3IgdG8gc2V0dGluZworICogdGhlIFB4Q01ELlNUIGJpdCB0byAnMScgZnJvbSBhIHBy ZXZpb3VzIHZhbHVlIG9mICcwJworICovCiBzdGF0aWMgdm9pZAotYXRhX2FoY2lfcmVzdGFy dChkZXZpY2VfdCBkZXYpCithdGFfYWhjaV9jbG9fZW5hYmxlKHN0cnVjdCBhdGFfY2hhbm5l bCAqY2gpCiB7Ci0gICAgc3RydWN0IGF0YV9wY2lfY29udHJvbGxlciAqY3RsciA9IGRldmlj ZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSk7Ci0gICAgc3RydWN0IGF0YV9j aGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLSAgICB1X2ludDMyX3QgY21k OworICAgIHN0cnVjdCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldmljZV9nZXRfcGFyZW50KGNoLT5kZXYpKTsKICAgICBpbnQgb2Zmc2V0ID0gY2gt PnVuaXQgPDwgNzsKLSAgICBpbnQgdGltZW91dDsKKyAgICBpbnQgdGltZW91dCA9IDA7Cisg ICAgdV9pbnQzMl90IGNtZDsKIAotICAgIC8qIGtpbGwgb2ZmIGFsbCBhY3Rpdml0eSBvbiB0 aGlzIGNoYW5uZWwgKi8KKyAgICBpZiAoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJ X0NBUCkgJiBBVEFfQUhDSV9DQVBfQ0xPKSB7CiAgICAgY21kID0gQVRBX0lOTChjdGxyLT5y X3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0KTsKICAgICBBVEFfT1VUTChjdGxyLT5y X3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LAotCSAgICAgY21kICYgfihBVEFfQUhD SV9QX0NNRF9GUkUgfCBBVEFfQUhDSV9QX0NNRF9TVCkpOwotCi0gICAgLyogWFhYIFNPUyB0 aGlzIGlzIG5vdCBlbnRpcmVseSB3cm9uZyAqLwotICAgIHRpbWVvdXQgPSAwOworCQkJY21k IHwgQVRBX0FIQ0lfUF9DTURfQ0xPKTsKICAgICBkbyB7CiAJREVMQVkoMTAwMCk7CiAJaWYg KHRpbWVvdXQrKyA+IDEwMDApIHsKLQkgICAgZGV2aWNlX3ByaW50ZihkZXYsICJzdG9wcGlu ZyBBSENJIGVuZ2luZSBmYWlsZWRcbiIpOworCQlkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJl eGVjdXRpbmcgQ0xPIGZhaWxlZFxuIik7CiAJICAgIGJyZWFrOwogCX0KKyAgICAgICAgfSB3 aGlsZSAoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0KQor CQkJJiBBVEFfQUhDSV9QX0NNRF9DTE8pOwogICAgIH0KLSAgICB3aGlsZSAoQVRBX0lOTChj dGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0KSAmIEFUQV9BSENJX1BfQ01E X0NSKTsKK30KKworLyogV2hlbiBQeENNRC5GUiBhbmQgUHhDTUQuRlJFIGFyZSBib3RoIGNs ZWFyZWQgdG8gJzAnLCBzb2Z0d2FyZSBtYXkgdXBkYXRlCisgKiB0aGUgdmFsdWVzIG9mIFB4 RkIgYW5kIFB4RkJVLiBQcmlvciB0byBzZXR0aW5nIFB4Q01ELkZSRSB0byAnMScsIHNvZnR3 YXJlCisgKiBzaGFsbCBlbnN1cmUgdGhhdCBQeEZCIGFuZCBQeEZCVSBhcmUgc2V0IHRvIHZh bGlkIHZhbHVlcy4gU29mdHdhcmUgc2hhbGwKKyAqIG5vdCB3cml0ZSBQeEZCIGFuZCBQeEZC VSB3aGlsZSBQeENNRC5GUkUgaXMgc2V0IHRvICcxJy4KKyAqLworc3RhdGljIHZvaWQKK2F0 YV9haGNpX2ZyZV9zdGFydChzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoKQoreworICAgIHN0cnVj dCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9n ZXRfcGFyZW50KGNoLT5kZXYpKTsKKyAgICB1X2ludDMyX3Qgb2Zmc2V0ID0gY2gtPnVuaXQg PDwgNzsKKyAgICB1X2ludDY0X3Qgd29yazsKKworICAgIC8qIHNldHVwIHdvcmsgYXJlYXMg Ki8KKyAgICB3b3JrID0gY2gtPmRtYS53b3JrX2J1cyArIEFUQV9BSENJX0NMX09GRlNFVDsK KyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ0xCICsgb2Zmc2V0LCB3 b3JrICYgMHhmZmZmZmZmZik7CisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhD SV9QX0NMQlUgKyBvZmZzZXQsIHdvcmsgPj4gMzIpOworCisgICAgd29yayA9IGNoLT5kbWEu d29ya19idXMgKyBBVEFfQUhDSV9GQl9PRkZTRVQ7CisgICAgQVRBX09VVEwoY3Rsci0+cl9y ZXMyLCBBVEFfQUhDSV9QX0ZCICsgb2Zmc2V0LCB3b3JrICYgMHhmZmZmZmZmZik7IAorICAg IEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9GQlUgKyBvZmZzZXQsIHdvcmsg Pj4gMzIpOworCisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCAr IG9mZnNldCwKKwkgICAgQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsg b2Zmc2V0KSB8IEFUQV9BSENJX1BfQ01EX0ZSRSk7Cit9CisKK3N0YXRpYyB2b2lkCithdGFf YWhjaV9mcmVfc3RvcChzdHJ1Y3QgYXRhX2NoYW5uZWwgKmNoKQoreworICAgIHN0cnVjdCBh dGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldmljZV9nZXRf cGFyZW50KGNoLT5kZXYpKTsKKyAgICB1X2ludDMyX3Qgb2Zmc2V0ID0gY2gtPnVuaXQgPDwg NzsKKyAgICBpbnQgdGltZW91dCA9IDA7CisKKyAgICBBVEFfT1VUTChjdGxyLT5yX3JlczIs IEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LAorCSAgICBBVEFfSU5MKGN0bHItPnJfcmVzMiwg QVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQpICYgKH5BVEFfQUhDSV9QX0NNRF9GUkUpKTsKIAot ICAgIC8qIGlzc3VlIENvbW1hbmQgTGlzdCBPdmVycmlkZSBpZiBzdXBwb3J0ZWQgKi8gCi0g ICAgaWYgKEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9DQVApICYgQVRBX0FIQ0lf Q0FQX0NMTykgewotCWNtZCA9IEFUQV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NN RCArIG9mZnNldCk7Ci0JY21kIHw9IEFUQV9BSENJX1BfQ01EX0NMTzsKLQlBVEFfT1VUTChj dGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0LCBjbWQpOwotCXRpbWVvdXQg PSAwOwogCWRvIHsKIAkgICAgREVMQVkoMTAwMCk7CiAJICAgIGlmICh0aW1lb3V0KysgPiAx MDAwKSB7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiZXhlY3V0aW5nIENMTyBmYWlsZWRcbiIp OworCSAgICBkZXZpY2VfcHJpbnRmKGNoLT5kZXYsICJhdGFfYWhjaV9mcmVfc3RvcCBmYWls ZWRcbiIpOwogCQlicmVhazsKIAkgICAgfQorICAgIH0gd2hpbGUgKEFUQV9JTkwoY3Rsci0+ cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCkgJiBBVEFfQUhDSV9QX0NNRF9GUik7 Cit9CisKK3N0YXRpYyB2b2lkCithdGFfYWhjaV9zdG9wX2NoYW5uZWwoc3RydWN0IGF0YV9j aGFubmVsICpjaCkKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChjaC0+ZGV2KSk7CisgICAgdV9p bnQzMl90IGNtZCwgb2Zmc2V0ID0gY2gtPnVuaXQgPDwgNzsKKyAgICBpbnQgdGltZW91dCA9 IDA7CisKKyAgICBjbWQgPSBBVEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTUQg KyBvZmZzZXQpOworICAgIGlmICgoY21kICYgKEFUQV9BSENJX1BfQ01EX1NUIHwgQVRBX0FI Q0lfUF9DTURfQ1IpKSA9PSAwKQorCXJldHVybjsKKworICAgIEFUQV9PVVRMKGN0bHItPnJf cmVzMiwgQVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQsCisJCSAgICBjbWQgJiAofkFUQV9BSENJ X1BfQ01EX1NUKSk7CisgICAgZG8geworCURFTEFZKDEwMDApOworCWlmICh0aW1lb3V0Kysg PiAxMDAwKSB7CisJICAgIGRldmljZV9wcmludGYoY2gtPmRldiwgImF0YV9haGNpX3N0b3Bf Y2hhbm5lbCBmYWlsZWRcbiIpOworCSAgICBicmVhazsKICAgICAgICAgfQotCXdoaWxlIChB VEFfSU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTUQrb2Zmc2V0KSZBVEFfQUhDSV9Q X0NNRF9DTE8pOwotICAgIH0KKyAgICB9IHdoaWxlIChBVEFfSU5MKGN0bHItPnJfcmVzMiwg QVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQpICYgQVRBX0FIQ0lfUF9DTURfQ1IpOworfQorCisK K3N0YXRpYyB2b2lkCithdGFfYWhjaV9yZXN0YXJ0X2NoYW5uZWwoc3RydWN0IGF0YV9jaGFu bmVsICpjaCkKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyICpjdGxyID0gZGV2 aWNlX2dldF9zb2Z0YyhkZXZpY2VfZ2V0X3BhcmVudChjaC0+ZGV2KSk7CisgICAgaW50IG9m ZnNldCA9IGNoLT51bml0IDw8IDc7CisKKyAgICAvKiBraWxsIG9mZiBhbGwgYWN0aXZpdHkg b24gdGhpcyBjaGFubmVsICovCisgICAgYXRhX2FoY2lfc3RvcF9jaGFubmVsKGNoKTsKIAog ICAgIC8qIGNsZWFyIFNBVEEgZXJyb3IgcmVnaXN0ZXIgKi8KICAgICBBVEFfSURYX09VVEwo Y2gsIEFUQV9TRVJST1IsIEFUQV9JRFhfSU5MKGNoLCBBVEFfU0VSUk9SKSk7CkBAIC0xMDQ2 LDExICsxMTMzLDEyIEBAIGF0YV9haGNpX3Jlc3RhcnQoZGV2aWNlX3QgZGV2KQogICAgIEFU QV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9JUyArIG9mZnNldCwKIAkgICAgIEFU QV9JTkwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0lTICsgb2Zmc2V0KSk7CiAKKyAgICAv KiBpc3N1ZSBDb21tYW5kIExpc3QgT3ZlcnJpZGUgaWYgc3VwcG9ydGVkICovCisgICAgYXRh X2FoY2lfY2xvX2VuYWJsZShjaCk7CisKICAgICAvKiBzdGFydCBvcGVyYXRpb25zIG9uIHRo aXMgY2hhbm5lbCAqLwogICAgIEFUQV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9D TUQgKyBvZmZzZXQsCi0JICAgICAoQVRBX0FIQ0lfUF9DTURfQUNUSVZFIHwgQVRBX0FIQ0lf UF9DTURfRlJFIHwKLQkgICAgICBBVEFfQUhDSV9QX0NNRF9QT0QgfCBBVEFfQUhDSV9QX0NN RF9TVUQgfCBBVEFfQUhDSV9QX0NNRF9TVCkKLQkgICAgIHwgKGNoLT5kZXZpY2VzICYgQVRB X1BPUlRNVUxUSVBMSUVSID8gQVRBX0FIQ0lfUF9DTURfUE1BIDogMCkpOworCSAgICBBVEFf SU5MKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9DTUQgKyBvZmZzZXQpIHwgQVRBX0FIQ0lf UF9DTURfU1QpOwogfQogCiBzdGF0aWMgdV9pbnQzMl90CkBAIC0xMDY1LDcgKzExNTMsNyBA QCBhdGFfYWhjaV9zb2Z0cmVzZXQoZGV2aWNlX3QgZGV2LCBpbnQgcG9yCiAJKHN0cnVjdCBh dGFfYWhjaV9jbWRfdGFiICopKGNoLT5kbWEud29yayArIEFUQV9BSENJX0NUX09GRlNFVCk7 CiAKICAgICAvKiBraWNrIGNvbnRyb2xsZXIgaW50byBzYW5lIHN0YXRlIGlmIG5lZWRlZCAq LwotICAgIGF0YV9haGNpX3Jlc3RhcnQoZGV2KTsKKyAgICBhdGFfYWhjaV9yZXN0YXJ0X2No YW5uZWwoY2gpOwogCiAgICAgLyogcHVsbCByZXNldCBhY3RpdmUgKi8KICAgICBiemVybyhj dHAtPmNmaXMsIDY0KTsKQEAgLTEwOTQsNyArMTE4Miw3IEBAIGF0YV9haGNpX3NvZnRyZXNl dChkZXZpY2VfdCBkZXYsIGludCBwb3IKICNlbmRpZgogICAgIGRvIHsKIAkgICAgREVMQVko MTAwMCk7Ci0JICAgIGlmICh0aW1lb3V0KysgPiAxMDAwKSB7CisJICAgIGlmICh0aW1lb3V0 KysgPiA1MDAwKSB7CiAJCWRldmljZV9wcmludGYoZGV2LCAic3RpbGwgQlVTWSBhZnRlciBz b2Z0cmVzZXRcbiIpOwogCQlicmVhazsKIAkgICAgfQpAQCAtMTExMCwxOSArMTE5OCwzNSBA QCBhdGFfYWhjaV9yZXNldChkZXZpY2VfdCBkZXYpCiB7CiAgICAgc3RydWN0IGF0YV9wY2lf Y29udHJvbGxlciAqY3RsciA9IGRldmljZV9nZXRfc29mdGMoZGV2aWNlX2dldF9wYXJlbnQo ZGV2KSk7CiAgICAgc3RydWN0IGF0YV9jaGFubmVsICpjaCA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKLSAgICB1X2ludDMyX3Qgc2lnbmF0dXJlOworICAgIHVfaW50MzJfdCBzaWduYXR1 cmUsIG9mZnNldCA9IGNoLT51bml0IDw8IDc7CisgICAgY2gtPmRldmljZXMgPSAwOwogCi0g ICAgaWYgKCEoQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BJKSAmICgxIDw8IGNo LT51bml0KSkpIHsKLQlkZXZpY2VfcHJpbnRmKGRldiwgInBvcnQgbm90IGltcGxlbWVudGVk XG4iKTsKLQlyZXR1cm47Ci0gICAgfQorICAgIC8qIGtpbGwgb2ZmIGFsbCBhY3Rpdml0eSBv biB0aGlzIGNoYW5uZWwgKi8KKyAgICBhdGFfYWhjaV9zdG9wX2NoYW5uZWwoY2gpOworICAg IGF0YV9haGNpX2ZyZV9zdG9wKGNoKTsKKworICAgIC8qIHNldHVwIHdvcmsgYXJlYXMgYW5k IGVuYWJsZSBGSVMgcmVjZWl2aW5nICovCisgICAgYXRhX2FoY2lfZnJlX3N0YXJ0KGNoKTsK KworICAgIC8qIGNsZWFyIFNBVEEgZXJyb3IgcmVnaXN0ZXIgKi8KKyAgICBBVEFfSURYX09V VEwoY2gsIEFUQV9TRVJST1IsIEFUQV9JRFhfSU5MKGNoLCBBVEFfU0VSUk9SKSk7CisKKyAg ICAvKiBjbGVhciBwb3J0IGludGVycnVwdHMgKi8KKyAgICBBVEFfT1VUTChjdGxyLT5yX3Jl czIsIEFUQV9BSENJX1BfSVMgKyBvZmZzZXQsCisJCUFUQV9JTkwoY3Rsci0+cl9yZXMyLCBB VEFfQUhDSV9QX0lTICsgb2Zmc2V0KSk7CisgICAgQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBB VEFfQUhDSV9JUywgKDEgPDwgY2gtPnVuaXQpKTsKIAotICAgIGF0YV9haGNpX3Jlc3RhcnQo ZGV2KTsKKyAgICAvKiBlbmFibGUgd2FudGVkIHBvcnQgaW50ZXJydXB0cyAqLworICAgIEFU QV9PVVRMKGN0bHItPnJfcmVzMiwgQVRBX0FIQ0lfUF9JRSArIG9mZnNldCwKKwkgICAgIChB VEFfQUhDSV9QX0lYX0NQRCB8IEFUQV9BSENJX1BfSVhfVEZFIHwgQVRBX0FIQ0lfUF9JWF9I QkYgfAorCSAgICAgIEFUQV9BSENJX1BfSVhfSEJEIHwgQVRBX0FIQ0lfUF9JWF9JRiB8IEFU QV9BSENJX1BfSVhfT0YgfAorCSAgICAgIEFUQV9BSENJX1BfSVhfUFJDIHwgQVRBX0FIQ0lf UF9JWF9QQyB8IEFUQV9BSENJX1BfSVhfRFAgfAorCSAgICAgIEFUQV9BSENJX1BfSVhfVUYg fCBBVEFfQUhDSV9QX0lYX1NEQiB8IEFUQV9BSENJX1BfSVhfRFMgfAorCSAgICAgIEFUQV9B SENJX1BfSVhfUFMgfCBBVEFfQUhDSV9QX0lYX0RIUikpOwogCiAgICAgaWYgKCFhdGFfc2F0 YV9waHlfcmVzZXQoZGV2KSkgewogCWlmIChib290dmVyYm9zZSkKIAkgICAgZGV2aWNlX3By aW50ZihkZXYsICJwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNlXG4iKTsKLQljaC0+ZGV2aWNl cyA9IDA7CiAJcmV0dXJuOwogICAgIH0KIApAQCAtMTE0NiwxMyArMTI1MCwyNCBAQCBhdGFf YWhjaV9yZXNldChkZXZpY2VfdCBkZXYpCiAgICAgY2FzZSAweGViMTQwMTAxOgogCWNoLT5k ZXZpY2VzID0gQVRBX0FUQVBJX01BU1RFUjsKIAlicmVhazsKLSAgICBkZWZhdWx0OiAvKiBT T1MgWFhYICovCisgICAgZGVmYXVsdDoKIAlpZiAoYm9vdHZlcmJvc2UpCiAJICAgIGRldmlj ZV9wcmludGYoZGV2LCAiTm8gc2lnbmF0dXJlLCBhc3VtaW5nIGRpc2sgZGV2aWNlXG4iKTsK LQljaC0+ZGV2aWNlcyA9IEFUQV9BVEFfTUFTVEVSOwogICAgIH0KICAgICBpZiAoYm9vdHZl cmJvc2UpCiAgICAgICAgIGRldmljZV9wcmludGYoZGV2LCAiYWhjaV9yZXNldCBkZXZpY2Vz PSUwOHhcbiIsIGNoLT5kZXZpY2VzKTsKKworICAgIC8qIFNvZnR3YXJlIHNoYWxsIG5vdCBz ZXQgUHhDTUQuU1QgdG8gMSB1bnRpbCBpdCBpcyBkZXRlcm1pbmVkCisgICAgICogdGhhdCBh IGZ1bmN0aW9uYWwgZGV2aWNlIGlzIHByZXNlbnQgb24gdGhlIHBvcnQuCisgICAgICovCisg ICAgaWYgKGNoLT5kZXZpY2VzKSB7CisgICAgICAgIC8qIGlzc3VlIENvbW1hbmQgTGlzdCBP dmVycmlkZSBpZiBzdXBwb3J0ZWQgKi8KKyAgICAgICAgYXRhX2FoY2lfY2xvX2VuYWJsZShj aCk7CisJQVRBX09VVEwoY3Rsci0+cl9yZXMyLCBBVEFfQUhDSV9QX0NNRCArIG9mZnNldCwK KwkJQVRBX0lOTChjdGxyLT5yX3JlczIsIEFUQV9BSENJX1BfQ01EICsgb2Zmc2V0KSB8IEFU QV9BSENJX1BfQ01EX1NVRCB8CisJCSAgICAgIEFUQV9BSENJX1BfQ01EX0FDVElWRSB8IEFU QV9BSENJX1BfQ01EX1BPRCB8IEFUQV9BSENJX1BfQ01EX1NUIHwKKwkJICAgICAgKGNoLT5k ZXZpY2VzICYgQVRBX1BPUlRNVUxUSVBMSUVSID8gQVRBX0FIQ0lfUF9DTURfUE1BIDogMCkp OworICAgIH0KIH0KIAogc3RhdGljIHZvaWQKSW5kZXg6IHNyYy9zeXMvZGV2L2F0YS9hdGEt cGNpLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25jdnMvc3JjL3N5cy9kZXYvYXRhL2F0 YS1wY2kuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMjgKZGlmZiAtdSAtYiAtcCAtcjEu MTI4IGF0YS1wY2kuYwotLS0gc3JjL3N5cy9kZXYvYXRhL2F0YS1wY2kuYwkxMSBKdW4gMjAw OCAwNjo0NDo1OCAtMDAwMAkxLjEyOAorKysgc3JjL3N5cy9kZXYvYXRhL2F0YS1wY2kuYwky MSBKdWwgMjAwOCAwOToyMzozMSAtMDAwMApAQCAtMjYyLDYgKzI2MiwzMiBAQCBhdGFfcGNp X2RldGFjaChkZXZpY2VfdCBkZXYpCiAgICAgcmV0dXJuIDA7CiB9CiAKK2ludAorYXRhX3Bj aV9zdXNwZW5kKGRldmljZV90IGRldikKK3sKKyAgICBzdHJ1Y3QgYXRhX3BjaV9jb250cm9s bGVyICpjdGxyID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworICAgIGludCBlcnJvciA9IDA7 CisKKyAgICBidXNfZ2VuZXJpY19zdXNwZW5kKGRldik7CisgICAgaWYgKGN0bHItPnN1c3Bl bmQpCisJZXJyb3IgPSBjdGxyLT5zdXNwZW5kKGRldik7CisKKyAgICByZXR1cm4gZXJyb3I7 Cit9CisKK2ludAorYXRhX3BjaV9yZXN1bWUoZGV2aWNlX3QgZGV2KQoreworICAgIHN0cnVj dCBhdGFfcGNpX2NvbnRyb2xsZXIgKmN0bHIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7Cisg ICAgaW50IGVycm9yID0gMDsKKworICAgIGlmIChjdGxyLT5yZXN1bWUpCisJZXJyb3IgPSBj dGxyLT5yZXN1bWUoZGV2KTsKKyAgICBidXNfZ2VuZXJpY19yZXN1bWUoZGV2KTsKKworICAg IHJldHVybiBlcnJvcjsKK30KKwogc3RydWN0IHJlc291cmNlICoKIGF0YV9wY2lfYWxsb2Nf cmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAq cmlkLAogCQkgICAgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQs IHVfaW50IGZsYWdzKQpAQCAtNTU2LDggKzU4Miw4IEBAIHN0YXRpYyBkZXZpY2VfbWV0aG9k X3QgYXRhX3BjaV9tZXRob2RzW10KICAgICBERVZNRVRIT0QoZGV2aWNlX2F0dGFjaCwgICAg ICAgICAgICBhdGFfcGNpX2F0dGFjaCksCiAgICAgREVWTUVUSE9EKGRldmljZV9kZXRhY2gs ICAgICAgICAgICAgYXRhX3BjaV9kZXRhY2gpLAogICAgIERFVk1FVEhPRChkZXZpY2Vfc2h1 dGRvd24sICAgICAgICAgIGJ1c19nZW5lcmljX3NodXRkb3duKSwKLSAgICBERVZNRVRIT0Qo ZGV2aWNlX3N1c3BlbmQsICAgICAgICAgICBidXNfZ2VuZXJpY19zdXNwZW5kKSwKLSAgICBE RVZNRVRIT0QoZGV2aWNlX3Jlc3VtZSwgICAgICAgICAgICBidXNfZ2VuZXJpY19yZXN1bWUp LAorICAgIERFVk1FVEhPRChkZXZpY2Vfc3VzcGVuZCwgICAgICAgICAgIGF0YV9wY2lfc3Vz cGVuZCksCisgICAgREVWTUVUSE9EKGRldmljZV9yZXN1bWUsICAgICAgICAgICAgYXRhX3Bj aV9yZXN1bWUpLAogCiAgICAgLyogYnVzIG1ldGhvZHMgKi8KICAgICBERVZNRVRIT0QoYnVz X2FsbG9jX3Jlc291cmNlLCAgICAgICBhdGFfcGNpX2FsbG9jX3Jlc291cmNlKSwKSW5kZXg6 IHNyYy9zeXMvZGV2L2F0YS9hdGEtcGNpLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL25j dnMvc3JjL3N5cy9kZXYvYXRhL2F0YS1wY2kuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS44 OQpkaWZmIC11IC1iIC1wIC1yMS44OSBhdGEtcGNpLmgKLS0tIHNyYy9zeXMvZGV2L2F0YS9h dGEtcGNpLmgJMTAgSnVsIDIwMDggMjE6MzY6NTMgLTAwMDAJMS44OQorKysgc3JjL3N5cy9k ZXYvYXRhL2F0YS1wY2kuaAkyMSBKdWwgMjAwOCAwOToyMzozMSAtMDAwMApAQCAtNTUsNiAr NTUsOCBAQCBzdHJ1Y3QgYXRhX3BjaV9jb250cm9sbGVyIHsKICAgICB2b2lkICAgICAgICAg ICAgICAgICgqcmVzZXQpKGRldmljZV90KTsKICAgICB2b2lkICAgICAgICAgICAgICAgICgq ZG1haW5pdCkoZGV2aWNlX3QpOwogICAgIHZvaWQgICAgICAgICAgICAgICAgKCpzZXRtb2Rl KShkZXZpY2VfdCwgaW50KTsKKyAgICBpbnQgICAgICAgICAgICAgICAgICgqc3VzcGVuZCko ZGV2aWNlX3QpOworICAgIGludCAgICAgICAgICAgICAgICAgKCpyZXN1bWUpKGRldmljZV90 KTsKICAgICBzdHJ1Y3QgewogICAgIHZvaWQgICAgICAgICAgICAgICAgKCpmdW5jdGlvbiko dm9pZCAqKTsKICAgICB2b2lkICAgICAgICAgICAgICAgICphcmd1bWVudDsKQEAgLTQ2MCw2 ICs0NjIsOCBAQCBzdHJ1Y3QgYXRhX2Nvbm5lY3RfdGFzayB7CiBpbnQgYXRhX3BjaV9wcm9i ZShkZXZpY2VfdCBkZXYpOwogaW50IGF0YV9wY2lfYXR0YWNoKGRldmljZV90IGRldik7CiBp bnQgYXRhX3BjaV9kZXRhY2goZGV2aWNlX3QgZGV2KTsKK2ludCBhdGFfcGNpX3N1c3BlbmQo ZGV2aWNlX3QgZGV2KTsKK2ludCBhdGFfcGNpX3Jlc3VtZShkZXZpY2VfdCBkZXYpOwogc3Ry dWN0IHJlc291cmNlICogYXRhX3BjaV9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRl dmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50ICpyaWQsIHVfbG9uZyBzdGFydCwgdV9sb25n IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncyk7CiBpbnQgYXRhX3BjaV9yZWxlYXNl X3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQg cmlkLCBzdHJ1Y3QgcmVzb3VyY2UgKnIpOwogaW50IGF0YV9wY2lfc2V0dXBfaW50cihkZXZp Y2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBzdHJ1Y3QgcmVzb3VyY2UgKmlycSwgaW50IGZs YWdzLCBkcml2ZXJfZmlsdGVyX3QgKmZpbHRlciwgZHJpdmVyX2ludHJfdCAqZnVuY3Rpb24s IHZvaWQgKmFyZ3VtZW50LCB2b2lkICoqY29va2llcCk7Cg== --------------070900010409000403070108-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 11:31:46 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1455F1065679 for ; Mon, 21 Jul 2008 11:31:46 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 294F98FC0A for ; Mon, 21 Jul 2008 11:31:28 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from laptop.deepcore.dk (laptop.deepcore.dk [192.168.0.138]) by deepcore.dk (8.14.2/8.13.8) with ESMTP id m6LAtweS076793; Mon, 21 Jul 2008 12:55:58 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Andrey V. Elsukov" In-Reply-To: <4884668C.5060606@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 12:55:58 +0200 References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> X-Mailer: Apple Mail (2.926) Cc: freebsd-current@FreeBSD.ORG, Sergey G Nasonov Subject: Re: RFC, RFT: AHCI driver reorganization (was: Re: ATA subsystem lost drive after resume process) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 11:31:46 -0000 Hi Just a short notice from here, I'm on vacation and cannot look into =20 this for about 2 weeks. This does massive changes to the way AHCI devices are treated, so it =20 will need testing on all the AHCI platforms currently supported to =20 make sure nothing breaks. The adding of PM learned me this is a =20 critical part to touch, ouch :) At any rate, fixing the suspend / resume problems should be dealt with =20= in a more generic manner, not just for AHCI, by splitting the work =20 done by the _chipinit and _allocate functions so that just the chipset =20= specifics can be restored on resume, not the allocations etc. I'm in doubt as to what makes most sense todo, I'm spare time limitted =20= still, so progress here is slow, heck my WIP on NCQ support is still =20 just that and touches the same code parts in ACHI so they willl get =20 even more behind, oh well... I'm starting to wonder if I should just let it go and leave ATA to its =20= own faith, and get on with other things... laters... -S=F8ren On 21Jul, 2008, at 12:35 , Andrey V. Elsukov wrote: > Sergey G Nasonov wrote: >> to disk. So the basic issue preventing normal suspend/resume >> process on modern Lenovo laptops is ata subsystem. Does anyone can >> help with this problem? I can test any path or provide additional >> info. > > Hi, All. > > I wrote patch for AHCI driver and Sergey tested it. > So, He reported that now "suspend/resume" works on his laptop. > I'll try to describe all changes which my patch makes. > > 1. Initialization: > > * Global AHCI reset code moved to ata_ahci_reset_controller() > function (it will be reused in ata_ahci_resume). > > * Detection of implemented ports moved to ata_ahci_allocate() > function (i think it isn't needed to detect it on each reset). > > * =46rom ata_ahci_allocate() function removed all working code, > only initialization code is here. > > 2. Resetting: > > * ata_ahci_reset() function reorganized and splitted to several > functions: > ata_ahci_stop_channel() - stop all port activity; > ata_ahci_fre_stop() - disable FIS receiving; > ata_ahci_fre_start() - setup work areas and enable FIS receiving; > ata_ahci_clo_enable() - enable command list override. > > * working code from ata_ahci_allocate moved to ata_ahci_reset. > > * CLO shall only be set immediately prior to setting the PxCMD.ST > bit to '1' (from AHCI spec). > > * Software shall not set PxCMD.ST to 1 until it is determined that a > functional device is present on the port (from AHCI spec). > > * removed hack when didn't detect signature asuming disk device (it > may broke some systems, but it needs testing). > > 3. Interrupts handling: > > * Call ata_sata_phy_check_events() only when PHY changing detected. > > * Fatal error handling changed. > > 4. Suspend/resume: > > * Added new methods to atapci(4) driver > > * Added suspend/resume implementation for AHCI: > + Software must disable interrupts prior to requesting a > transition of the HBA to the D3 state. > + Reset controller and enable interrupts before resume. > > > So, any comments and suggestions are welcome. > > --=20 > WBR, Andrey V. Elsukov > > Index: src/sys/dev/ata/ata-all.h > =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: /ncvs/src/sys/dev/ata/ata-all.h,v > retrieving revision 1.133 > diff -u -b -p -r1.133 ata-all.h > --- src/sys/dev/ata/ata-all.h 17 Apr 2008 12:29:35 -0000 1.133 > +++ src/sys/dev/ata/ata-all.h 21 Jul 2008 09:23:31 -0000 > @@ -188,6 +188,9 @@ > #define ATA_AHCI_P_IX_HBF 0x20000000 > #define ATA_AHCI_P_IX_TFE 0x40000000 > #define ATA_AHCI_P_IX_CPD 0x80000000 > +#define ATA_AHCI_P_IX_FE \ > + (ATA_AHCI_P_IX_TFE | ATA_AHCI_P_IX_HBF |\ > + ATA_AHCI_P_IX_HBD | ATA_AHCI_P_IX_IF) > > #define ATA_AHCI_P_CMD 0x118 > #define ATA_AHCI_P_CMD_ST 0x00000001 > Index: src/sys/dev/ata/ata-chipset.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: /ncvs/src/sys/dev/ata/ata-chipset.c,v > retrieving revision 1.224 > diff -u -b -p -r1.224 ata-chipset.c > --- src/sys/dev/ata/ata-chipset.c 10 Jul 2008 21:36:53 -0000 = 1.224 > +++ src/sys/dev/ata/ata-chipset.c 21 Jul 2008 09:23:31 -0000 > @@ -62,6 +62,9 @@ static int ata_sata_connect(struct ata_c > static void ata_sata_setmode(device_t dev, int mode); > static int ata_request2fis_h2d(struct ata_request *request, u_int8_t =20= > *fis); > static int ata_ahci_chipinit(device_t dev); > +static int ata_ahci_suspend(device_t dev); > +static int ata_ahci_resume(device_t dev); > +static int ata_ahci_reset_controller(device_t dev); > static int ata_ahci_allocate(device_t dev); > static int ata_ahci_status(device_t dev); > static int ata_ahci_begin_transaction(struct ata_request *request); > @@ -69,6 +72,11 @@ static int ata_ahci_end_transaction(stru > static int ata_ahci_pm_read(device_t dev, int port, int reg, =20 > u_int32_t *result); > static int ata_ahci_pm_write(device_t dev, int port, int reg, =20 > u_int32_t result); > static u_int32_t ata_ahci_softreset(device_t dev, int port); > +static void ata_ahci_fre_start(struct ata_channel *ch); > +static void ata_ahci_fre_stop(struct ata_channel *ch); > +static void ata_ahci_stop_channel(struct ata_channel *ch); > +static void ata_ahci_restart_channel(struct ata_channel *ch); > +static void ata_ahci_clo_enable(struct ata_channel *ch); > static void ata_ahci_reset(device_t dev); > static void ata_ahci_dmasetprd(void *xsc, bus_dma_segment_t *segs, =20 > int nsegs, int error); > static void ata_ahci_dmainit(device_t dev); > @@ -582,6 +590,29 @@ ata_ahci_ident(device_t dev) > } > > static int > +ata_ahci_reset_controller(device_t dev) > +{ > + struct ata_pci_controller *ctlr =3D device_get_softc(dev); > + > + /* enable AHCI mode */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_AE); > + > + /* reset AHCI controller */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_HR); > + DELAY(1000000); > + if (ATA_INL(ctlr->r_res2, ATA_AHCI_GHC) & ATA_AHCI_GHC_HR) { > + bus_release_resource(dev, ctlr->r_type2, ctlr->r_rid2, ctlr-=20 > >r_res2); > + device_printf(dev, "AHCI controller reset failure\n"); > + return ENXIO; > + } > + > + /* reenable AHCI mode */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_AE); > + > + return 0; > +} > + > +static int > ata_ahci_chipinit(device_t dev) > { > struct ata_pci_controller *ctlr =3D device_get_softc(dev); > @@ -602,20 +633,8 @@ ata_ahci_chipinit(device_t dev) > else > device_printf(dev, "AHCI called from vendor specific driver\n"); > > - /* enable AHCI mode */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_AE); > - > - /* reset AHCI controller */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_HR); > - DELAY(1000000); > - if (ATA_INL(ctlr->r_res2, ATA_AHCI_GHC) & ATA_AHCI_GHC_HR) { > - bus_release_resource(dev, ctlr->r_type2, ctlr->r_rid2, ctlr-=20 > >r_res2); > - device_printf(dev, "AHCI controller reset failure\n"); > + if (ata_ahci_reset_controller(dev)) > return ENXIO; > - } > - > - /* reenable AHCI mode */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, ATA_AHCI_GHC_AE); > > /* get the number of HW channels */ > ctlr->channels =3D > @@ -633,6 +652,8 @@ ata_ahci_chipinit(device_t dev) > ctlr->dmainit =3D ata_ahci_dmainit; > ctlr->allocate =3D ata_ahci_allocate; > ctlr->setmode =3D ata_sata_setmode; > + ctlr->resume =3D ata_ahci_resume; > + ctlr->suspend =3D ata_ahci_suspend; > > /* enable PCI interrupt */ > pci_write_config(dev, PCIR_COMMAND, > @@ -655,9 +676,13 @@ ata_ahci_allocate(device_t dev) > { > struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(dev)); > struct ata_channel *ch =3D device_get_softc(dev); > - u_int64_t work; > int offset =3D ch->unit << 7; > > + if (!(ATA_INL(ctlr->r_res2, ATA_AHCI_PI) & (1 << ch->unit))) { > + device_printf(dev, "port not implemented\n"); > + return ENXIO; > + } > + > /* set the SATA resources */ > ch->r_io[ATA_SSTATUS].res =3D ctlr->r_res2; > ch->r_io[ATA_SSTATUS].offset =3D ATA_AHCI_P_SSTS + offset; > @@ -676,30 +701,45 @@ ata_ahci_allocate(device_t dev) > ch->hw.pm_read =3D ata_ahci_pm_read; > ch->hw.pm_write =3D ata_ahci_pm_write; > > - /* setup work areas */ > - work =3D ch->dma.work_bus + ATA_AHCI_CL_OFFSET; > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CLB + offset, work & =20 > 0xffffffff); > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CLBU + offset, work >> 32); > + return 0; > +} > > - work =3D ch->dma.work_bus + ATA_AHCI_FB_OFFSET; > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_FB + offset, work & =20 > 0xffffffff); > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_FBU + offset, work >> 32); > +static int > +ata_ahci_suspend(device_t dev) > +{ > + struct ata_pci_controller *ctlr =3D device_get_softc(dev); > > - /* enable wanted port interrupts */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_IE + offset, > - (ATA_AHCI_P_IX_CPD | ATA_AHCI_P_IX_TFE | ATA_AHCI_P_IX_HBF = | > - ATA_AHCI_P_IX_HBD | ATA_AHCI_P_IX_IF | ATA_AHCI_P_IX_OF | > - ATA_AHCI_P_IX_PRC | ATA_AHCI_P_IX_PC | ATA_AHCI_P_IX_DP | > - ATA_AHCI_P_IX_UF | ATA_AHCI_P_IX_SDB | ATA_AHCI_P_IX_DS | > - ATA_AHCI_P_IX_PS | ATA_AHCI_P_IX_DHR)); > + /* XXX: PxCMD.ST must be cleared to '0' before entry into the > + * D3 power state. > + */ > > - /* enable FIS based switching */ > - //ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_FBS + offset, 0x00000003); > + /* Software must disable interrupts (GHC.IE must be cleared to 0) > + * prior to requesting a transition of the HBA to the D3 state. > + */ > > - /* start operations on this channel */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > - (ATA_AHCI_P_CMD_ACTIVE | ATA_AHCI_P_CMD_FRE | > - ATA_AHCI_P_CMD_POD | ATA_AHCI_P_CMD_SUD | = ATA_AHCI_P_CMD_ST)); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, > + ATA_INL(ctlr->r_res2, ATA_AHCI_GHC) & (~ATA_AHCI_GHC_IE)); > + > + return 0; > +} > + > +static int > +ata_ahci_resume(device_t dev) > +{ > + struct ata_pci_controller *ctlr =3D device_get_softc(dev); > + > + /* reset controller */ > + if (ata_ahci_reset_controller(dev)) > + return ENXIO; /* XXX */ > + > + /* clear interrupts */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_IS, ATA_INL(ctlr->r_res2, =20 > ATA_AHCI_IS)); > + > + /* enable AHCI interrupts */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_GHC, > + ATA_INL(ctlr->r_res2, ATA_AHCI_GHC) | ATA_AHCI_GHC_IE); > + > + /* next part will be done by ata_resume */ > return 0; > } > > @@ -716,38 +756,24 @@ ata_ahci_status(device_t dev) > u_int32_t cstatus =3D ATA_INL(ctlr->r_res2, ATA_AHCI_P_CI + = offset); > > /* clear interrupt(s) */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_IS, action & (1 << ch->unit)); > ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_IS + offset, istatus); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_IS, action & (1 << ch->unit)); > > /* do we have any PHY events ? */ > - /* XXX SOS check istatus phy bits */ > + if (istatus & (ATA_AHCI_P_IX_PRC | ATA_AHCI_P_IX_PC)) > ata_sata_phy_check_events(dev); > > /* do we have a potentially hanging engine to take care of? */ > /* XXX SOS what todo on NCQ */ > - if ((istatus & 0x78400050) && (cstatus & 1)) { > - > - u_int32_t cmd =3D ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + = offset); > - int timeout =3D 0; > - > - /* kill off all activity on this channel */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > - cmd & ~(ATA_AHCI_P_CMD_FRE | ATA_AHCI_P_CMD_ST)); > - > - /* XXX SOS this is not entirely wrong */ > - do { > - DELAY(1000); > - if (timeout++ > 1000) { > - device_printf(dev, "stopping AHCI engine failed\n"); > - break; > - } > - } while (ATA_INL(ctlr->r_res2, > - ATA_AHCI_P_CMD + offset) & = ATA_AHCI_P_CMD_CR); > - > - /* start operations on this channel */ > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > - cmd | (ATA_AHCI_P_CMD_FRE | ATA_AHCI_P_CMD_ST)); > - > + if ((istatus & ATA_AHCI_P_IX_FE) && (cstatus & 1)) { > + if (bootverbose) > + device_printf(dev, "PHY fatal error: PxIS =3D 0x%08x\n", > + istatus); > + /* To recover fatal errors, the port must be restarted; > + * the port is restarted by clearing PxCMD.ST to '0' and > + * then setting PxCMD.ST to '1'. > + */ > + ata_ahci_restart_channel(ch); > return 1; > } > else > @@ -998,46 +1024,107 @@ ata_ahci_pm_write(device_t dev, int port > return (ATA_INL(ctlr->r_res2, ATA_AHCI_P_TFD + offset) >> 8) & =20 > 0xff; > } > > +/* CLO shall only be set immediately prior to setting > + * the PxCMD.ST bit to '1' from a previous value of '0' > + */ > static void > -ata_ahci_restart(device_t dev) > +ata_ahci_clo_enable(struct ata_channel *ch) > { > - struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(dev)); > - struct ata_channel *ch =3D device_get_softc(dev); > - u_int32_t cmd; > + struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(ch->dev)); > int offset =3D ch->unit << 7; > - int timeout; > + int timeout =3D 0; > + u_int32_t cmd; > > - /* kill off all activity on this channel */ > + if (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_CAP_CLO) { > cmd =3D ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset); > ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > - cmd & ~(ATA_AHCI_P_CMD_FRE | ATA_AHCI_P_CMD_ST)); > - > - /* XXX SOS this is not entirely wrong */ > - timeout =3D 0; > + cmd | ATA_AHCI_P_CMD_CLO); > do { > DELAY(1000); > if (timeout++ > 1000) { > - device_printf(dev, "stopping AHCI engine failed\n"); > + device_printf(ch->dev, "executing CLO failed\n"); > break; > } > + } while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) > + & ATA_AHCI_P_CMD_CLO); > } > - while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) & =20 > ATA_AHCI_P_CMD_CR); > +} > + > +/* When PxCMD.FR and PxCMD.FRE are both cleared to '0', software =20 > may update > + * the values of PxFB and PxFBU. Prior to setting PxCMD.FRE to '1', =20= > software > + * shall ensure that PxFB and PxFBU are set to valid values. =20 > Software shall > + * not write PxFB and PxFBU while PxCMD.FRE is set to '1'. > + */ > +static void > +ata_ahci_fre_start(struct ata_channel *ch) > +{ > + struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(ch->dev)); > + u_int32_t offset =3D ch->unit << 7; > + u_int64_t work; > + > + /* setup work areas */ > + work =3D ch->dma.work_bus + ATA_AHCI_CL_OFFSET; > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CLB + offset, work & =20 > 0xffffffff); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CLBU + offset, work >> 32); > + > + work =3D ch->dma.work_bus + ATA_AHCI_FB_OFFSET; > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_FB + offset, work & =20 > 0xffffffff); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_FBU + offset, work >> 32); > + > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > + ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) | =20 > ATA_AHCI_P_CMD_FRE); > +} > + > +static void > +ata_ahci_fre_stop(struct ata_channel *ch) > +{ > + struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(ch->dev)); > + u_int32_t offset =3D ch->unit << 7; > + int timeout =3D 0; > + > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > + ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) & =20 > (~ATA_AHCI_P_CMD_FRE)); > > - /* issue Command List Override if supported */ > - if (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_CAP_CLO) { > - cmd =3D ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset); > - cmd |=3D ATA_AHCI_P_CMD_CLO; > - ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, cmd); > - timeout =3D 0; > do { > DELAY(1000); > if (timeout++ > 1000) { > - device_printf(dev, "executing CLO failed\n"); > + device_printf(ch->dev, "ata_ahci_fre_stop failed\n"); > break; > } > + } while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) & =20 > ATA_AHCI_P_CMD_FR); > +} > + > +static void > +ata_ahci_stop_channel(struct ata_channel *ch) > +{ > + struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(ch->dev)); > + u_int32_t cmd, offset =3D ch->unit << 7; > + int timeout =3D 0; > + > + cmd =3D ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset); > + if ((cmd & (ATA_AHCI_P_CMD_ST | ATA_AHCI_P_CMD_CR)) =3D=3D 0) > + return; > + > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > + cmd & (~ATA_AHCI_P_CMD_ST)); > + do { > + DELAY(1000); > + if (timeout++ > 1000) { > + device_printf(ch->dev, "ata_ahci_stop_channel failed\n"); > + break; > } > - while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD=20 > +offset)&ATA_AHCI_P_CMD_CLO); > - } > + } while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) & =20 > ATA_AHCI_P_CMD_CR); > +} > + > + > +static void > +ata_ahci_restart_channel(struct ata_channel *ch) > +{ > + struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(ch->dev)); > + int offset =3D ch->unit << 7; > + > + /* kill off all activity on this channel */ > + ata_ahci_stop_channel(ch); > > /* clear SATA error register */ > ATA_IDX_OUTL(ch, ATA_SERROR, ATA_IDX_INL(ch, ATA_SERROR)); > @@ -1046,11 +1133,12 @@ ata_ahci_restart(device_t dev) > ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_IS + offset, > ATA_INL(ctlr->r_res2, ATA_AHCI_P_IS + offset)); > > + /* issue Command List Override if supported */ > + ata_ahci_clo_enable(ch); > + > /* start operations on this channel */ > ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > - (ATA_AHCI_P_CMD_ACTIVE | ATA_AHCI_P_CMD_FRE | > - ATA_AHCI_P_CMD_POD | ATA_AHCI_P_CMD_SUD | = ATA_AHCI_P_CMD_ST) > - | (ch->devices & ATA_PORTMULTIPLIER ? ATA_AHCI_P_CMD_PMA : = 0)); > + ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) | =20 > ATA_AHCI_P_CMD_ST); > } > > static u_int32_t > @@ -1065,7 +1153,7 @@ ata_ahci_softreset(device_t dev, int por > (struct ata_ahci_cmd_tab *)(ch->dma.work + ATA_AHCI_CT_OFFSET); > > /* kick controller into sane state if needed */ > - ata_ahci_restart(dev); > + ata_ahci_restart_channel(ch); > > /* pull reset active */ > bzero(ctp->cfis, 64); > @@ -1094,7 +1182,7 @@ ata_ahci_softreset(device_t dev, int por > #endif > do { > DELAY(1000); > - if (timeout++ > 1000) { > + if (timeout++ > 5000) { > device_printf(dev, "still BUSY after softreset\n"); > break; > } > @@ -1110,19 +1198,35 @@ ata_ahci_reset(device_t dev) > { > struct ata_pci_controller *ctlr =3D =20 > device_get_softc(device_get_parent(dev)); > struct ata_channel *ch =3D device_get_softc(dev); > - u_int32_t signature; > + u_int32_t signature, offset =3D ch->unit << 7; > + ch->devices =3D 0; > > - if (!(ATA_INL(ctlr->r_res2, ATA_AHCI_PI) & (1 << ch->unit))) { > - device_printf(dev, "port not implemented\n"); > - return; > - } > + /* kill off all activity on this channel */ > + ata_ahci_stop_channel(ch); > + ata_ahci_fre_stop(ch); > + > + /* setup work areas and enable FIS receiving */ > + ata_ahci_fre_start(ch); > + > + /* clear SATA error register */ > + ATA_IDX_OUTL(ch, ATA_SERROR, ATA_IDX_INL(ch, ATA_SERROR)); > + > + /* clear port interrupts */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_IS + offset, > + ATA_INL(ctlr->r_res2, ATA_AHCI_P_IS + offset)); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_IS, (1 << ch->unit)); > > - ata_ahci_restart(dev); > + /* enable wanted port interrupts */ > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_IE + offset, > + (ATA_AHCI_P_IX_CPD | ATA_AHCI_P_IX_TFE | ATA_AHCI_P_IX_HBF = | > + ATA_AHCI_P_IX_HBD | ATA_AHCI_P_IX_IF | ATA_AHCI_P_IX_OF | > + ATA_AHCI_P_IX_PRC | ATA_AHCI_P_IX_PC | ATA_AHCI_P_IX_DP | > + ATA_AHCI_P_IX_UF | ATA_AHCI_P_IX_SDB | ATA_AHCI_P_IX_DS | > + ATA_AHCI_P_IX_PS | ATA_AHCI_P_IX_DHR)); > > if (!ata_sata_phy_reset(dev)) { > if (bootverbose) > device_printf(dev, "phy reset found no device\n"); > - ch->devices =3D 0; > return; > } > > @@ -1146,13 +1250,24 @@ ata_ahci_reset(device_t dev) > case 0xeb140101: > ch->devices =3D ATA_ATAPI_MASTER; > break; > - default: /* SOS XXX */ > + default: > if (bootverbose) > device_printf(dev, "No signature, asuming disk device\n"); > - ch->devices =3D ATA_ATA_MASTER; > } > if (bootverbose) > device_printf(dev, "ahci_reset devices=3D%08x\n", = ch->devices); > + > + /* Software shall not set PxCMD.ST to 1 until it is determined > + * that a functional device is present on the port. > + */ > + if (ch->devices) { > + /* issue Command List Override if supported */ > + ata_ahci_clo_enable(ch); > + ATA_OUTL(ctlr->r_res2, ATA_AHCI_P_CMD + offset, > + ATA_INL(ctlr->r_res2, ATA_AHCI_P_CMD + offset) | =20 > ATA_AHCI_P_CMD_SUD | > + ATA_AHCI_P_CMD_ACTIVE | ATA_AHCI_P_CMD_POD | =20 > ATA_AHCI_P_CMD_ST | > + (ch->devices & ATA_PORTMULTIPLIER ? = ATA_AHCI_P_CMD_PMA : 0)); > + } > } > > static void > Index: src/sys/dev/ata/ata-pci.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: /ncvs/src/sys/dev/ata/ata-pci.c,v > retrieving revision 1.128 > diff -u -b -p -r1.128 ata-pci.c > --- src/sys/dev/ata/ata-pci.c 11 Jun 2008 06:44:58 -0000 1.128 > +++ src/sys/dev/ata/ata-pci.c 21 Jul 2008 09:23:31 -0000 > @@ -262,6 +262,32 @@ ata_pci_detach(device_t dev) > return 0; > } > > +int > +ata_pci_suspend(device_t dev) > +{ > + struct ata_pci_controller *ctlr =3D device_get_softc(dev); > + int error =3D 0; > + > + bus_generic_suspend(dev); > + if (ctlr->suspend) > + error =3D ctlr->suspend(dev); > + > + return error; > +} > + > +int > +ata_pci_resume(device_t dev) > +{ > + struct ata_pci_controller *ctlr =3D device_get_softc(dev); > + int error =3D 0; > + > + if (ctlr->resume) > + error =3D ctlr->resume(dev); > + bus_generic_resume(dev); > + > + return error; > +} > + > struct resource * > ata_pci_alloc_resource(device_t dev, device_t child, int type, int =20 > *rid, > u_long start, u_long end, u_long count, u_int = flags) > @@ -556,8 +582,8 @@ static device_method_t ata_pci_methods[] > DEVMETHOD(device_attach, ata_pci_attach), > DEVMETHOD(device_detach, ata_pci_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > - DEVMETHOD(device_suspend, bus_generic_suspend), > - DEVMETHOD(device_resume, bus_generic_resume), > + DEVMETHOD(device_suspend, ata_pci_suspend), > + DEVMETHOD(device_resume, ata_pci_resume), > > /* bus methods */ > DEVMETHOD(bus_alloc_resource, ata_pci_alloc_resource), > Index: src/sys/dev/ata/ata-pci.h > =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: /ncvs/src/sys/dev/ata/ata-pci.h,v > retrieving revision 1.89 > diff -u -b -p -r1.89 ata-pci.h > --- src/sys/dev/ata/ata-pci.h 10 Jul 2008 21:36:53 -0000 1.89 > +++ src/sys/dev/ata/ata-pci.h 21 Jul 2008 09:23:31 -0000 > @@ -55,6 +55,8 @@ struct ata_pci_controller { > void (*reset)(device_t); > void (*dmainit)(device_t); > void (*setmode)(device_t, int); > + int (*suspend)(device_t); > + int (*resume)(device_t); > struct { > void (*function)(void *); > void *argument; > @@ -460,6 +462,8 @@ struct ata_connect_task { > int ata_pci_probe(device_t dev); > int ata_pci_attach(device_t dev); > int ata_pci_detach(device_t dev); > +int ata_pci_suspend(device_t dev); > +int ata_pci_resume(device_t dev); > struct resource * ata_pci_alloc_resource(device_t dev, device_t =20 > child, int type, int *rid, u_long start, u_long end, u_long count, =20 > u_int flags); > int ata_pci_release_resource(device_t dev, device_t child, int type, =20= > int rid, struct resource *r); > int ata_pci_setup_intr(device_t dev, device_t child, struct resource =20= > *irq, int flags, driver_filter_t *filter, driver_intr_t *function, =20 > void *argument, void **cookiep); -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 12:48:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68C4B1065678; Mon, 21 Jul 2008 12:48:21 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id 11E2B8FC0C; Mon, 21 Jul 2008 12:48:21 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from honshu.net.informatik.tu-muenchen.de ([131.159.14.60]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KKuoP-0004EU-2N; Mon, 21 Jul 2008 14:48:21 +0200 Message-ID: <48848598.1010202@lobraun.de> Date: Mon, 21 Jul 2008 14:48:24 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Attilio Rao References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> <3bbf2fe10807201046i109caccfl88e8641f424226eb@mail.gmail.com> In-Reply-To: <3bbf2fe10807201046i109caccfl88e8641f424226eb@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 12:48:21 -0000 Attilio Rao wrote: >> > For what I remind, it is likely XFS is still not ready for writing. >> > This means you should only use it in read-only. Uh, I somehow missed it (aka didn't read xfs(5) :-(). >> >> Speaking of which, I think we should mark it again like a read-only fs >> until writing is not 100% ready. Yes, that could be a good idea. > Lothar, > can you please try this patch on the top of -CURRENT: > http://www.freebsd.com/~attilio/xfs3.diff > > it should avoid to mount an xfs partition in write mode. Yes, I'm not allowed to mount that partition in write mode, with the patch applied to the kernel. Regards, Lothar From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 13:02:08 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C181065673; Mon, 21 Jul 2008 13:02:08 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp10.yandex.ru (smtp10.yandex.ru [213.180.223.92]) by mx1.freebsd.org (Postfix) with ESMTP id 975A28FC0C; Mon, 21 Jul 2008 13:02:07 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:33263 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5867044AbYGUNCA (ORCPT + 1 other); Mon, 21 Jul 2008 17:02:00 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp10 X-Yandex-TimeMark: 1216645320 X-MsgDayCount: 9 X-Comment: RFC 2476 MSA function at smtp10.yandex.ru logged sender identity as: bu7cher Message-ID: <48848887.6020201@yandex.ru> Date: Mon, 21 Jul 2008 17:00:55 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> In-Reply-To: <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.ORG, Sergey G Nasonov Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 13:02:08 -0000 Søren Schmidt wrote: > This does massive changes to the way AHCI devices are treated, so it > will need testing on all the AHCI platforms currently supported to make > sure nothing breaks. The adding of PM learned me this is a critical part > to touch, ouch :) Yes, I agree. I think 2 weeks is good time to test :) > At any rate, fixing the suspend / resume problems should be dealt with > in a more generic manner, not just for AHCI, by splitting the work done > by the _chipinit and _allocate functions so that just the chipset > specifics can be restored on resume, not the allocations etc. No, splitting was made before.. It targeted to be more conform to AHCI spec. I think after vacation you will have much more time to review. Currently I replaced bus_generic_suspend/bus_generic_resume to: int ata_pci_suspend(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); int error = 0; bus_generic_suspend(dev); if (ctlr->suspend) error = ctlr->suspend(dev); return error; } int ata_pci_resume(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); int error = 0; if (ctlr->resume) error = ctlr->resume(dev); bus_generic_resume(dev); return error; } So, I think it's easy to implement ctlr->suspend/resume for each specific controller.. > I'm in doubt as to what makes most sense todo, I'm spare time limitted > still, so progress here is slow, heck my WIP on NCQ support is still > just that and touches the same code parts in ACHI so they willl get even > more behind, oh well... > > I'm starting to wonder if I should just let it go and leave ATA to its > own faith, and get on with other things... What about merging some parts of your WIP (which may be published) to perforce repository, it may take some time for you, but after that some people can help to do some work with your review. ATA is a big subsystem and it isn't easy to maintain it alone. I think.. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 13:52:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E9B21065697 for ; Mon, 21 Jul 2008 13:52:07 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 497618FC12 for ; Mon, 21 Jul 2008 13:52:04 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from laptop.deepcore.dk (laptop.deepcore.dk [192.168.0.138]) by deepcore.dk (8.14.2/8.13.8) with ESMTP id m6LDq1RG079219; Mon, 21 Jul 2008 15:52:01 +0200 (CEST) (envelope-from sos@freebsd.org) Message-Id: From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Andrey V. Elsukov" In-Reply-To: <48848887.6020201@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 15:52:01 +0200 References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> X-Mailer: Apple Mail (2.926) Cc: freebsd-current@freebsd.org, Sergey G Nasonov Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 13:52:07 -0000 On 21Jul, 2008, at 15:00 , Andrey V. Elsukov wrote: > S=F8ren Schmidt wrote: >> This does massive changes to the way AHCI devices are treated, so =20 >> it will need testing on all the AHCI platforms currently supported =20= >> to make sure nothing breaks. The adding of PM learned me this is a =20= >> critical part to touch, ouch :) > > Yes, I agree. I think 2 weeks is good time to test :) Well, this is not a question of time, its a question about getting it =20= tested on all possible platforms. This is a major PITA as I'm no =20 longer able to have a significant variation of boards/controllers in =20 the lab (lack of HW/funds), so its hard to test up front. Posting =20 patches wont help much either experience shows, its first when it hits =20= the official sources and some time has gone by, that those sytems out =20= there will get upgrade and then show the failures. > > >> At any rate, fixing the suspend / resume problems should be dealt =20 >> with in a more generic manner, not just for AHCI, by splitting the =20= >> work done by the _chipinit and _allocate functions so that just the =20= >> chipset specifics can be restored on resume, not the allocations etc. > > No, splitting was made before.. It targeted to be more conform to AHCI > spec. I think after vacation you will have much more time to review. Much more time ? not likely :) Anyhow, some of the splitting you have posted before, and I'm not =20 convinced that it is the right thing todo, in fact I dont think it is. =20= I always lean towards generic code that works on as much HW as =20 possible, makes life lots easier in the long run, and I happen to know =20= what I'm talking about here, been architecting/developing/maintaining =20= ATA as is for 10 fsck'ing years. Now, trying to hide this under an AHCI specific suspend/resume fix =20 wont make it better :) As I said suspend/resume should be fixed generically so that it helps =20= ALL chipsets, that wont get done by random hacks to different =20 chipsets, it will lead us right to chaos and kludges all over the =20 place, and that scenario will be without yours truely at the ATA helm. Mind you all the needed code for suspend/resume is already there, its =20= "just" a matter of being able to call the different parts in new ways. >> I'm in doubt as to what makes most sense todo, I'm spare time =20 >> limitted still, so progress here is slow, heck my WIP on NCQ =20 >> support is still just that and touches the same code parts in ACHI =20= >> so they willl get even more behind, oh well... >> I'm starting to wonder if I should just let it go and leave ATA to =20= >> its own faith, and get on with other things... > > What about merging some parts of your WIP (which may be published) to > perforce repository, it may take some time for you, but after that > some people can help to do some work with your review. ATA is a big > subsystem and it isn't easy to maintain it alone. I think.. Well, the WIP's I have here cannot be merged in pieces, its all or =20 nothing as it changes stuff in many subtle places. Right now I have =20 code for NCQ support and for RAID5 support in the outbound queue, but =20= both changes vital parts of the system. I have my own VCS here so =20 getting it to something else is just a waste of time that I dont have :) Some of it still needs clearance before it is let loose in the =20 official repos. Which gets us to the last part about maintenance, yes ATA is a rather =20= big subsystem, and its complicated due to all kinds of broken HW out =20 there and spec violations etc etc. If I had the time, I could write a book on how things are put =20 together, and how I have architected the subsystem to cope with new =20 stuff and feature, but alas that wont happen as my spare time gets =20 smaller by the years and so does the donations that could make me use =20= business hours for it. So its all just in my head and on lots of notes around here in the lab =20= which makes it difficult to get it across to others. This is really a =20= bottleneck, but so far noone has shown the interest or amount of =20 knowledge / motivation to get into the matter. I can understand that =20 as the workload is immense and there are no returns, only new bug =20 reports and requests for support plus the usual whining.. I guess this is a general problem in this kind of project and cannot =20 easily be solved.. Now, back to my much needed vacation... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 14:35:53 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCC1E1065672 for ; Mon, 21 Jul 2008 14:35:53 +0000 (UTC) (envelope-from rohit.x.tripathi@jpmchase.com) Received: from sf1.svr.bankone.net (sf1.jpmchase.com [159.53.36.249]) by mx1.freebsd.org (Postfix) with ESMTP id 624268FC16 for ; Mon, 21 Jul 2008 14:35:53 +0000 (UTC) (envelope-from rohit.x.tripathi@jpmchase.com) Received: from sj6.svr.bankone.net (sj6.svr.bankone.net [155.180.102.162]) by sf1.svr.bankone.net (Switch-3.1.8/Switch-3.1.7) with ESMTP id m6LE8Dtj023900 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 21 Jul 2008 10:08:13 -0400 Received: from si4.svr.bankone.net (si4.svr.bankone.net [155.180.56.116]) by sj6.svr.bankone.net (Switch-3.1.8/Switch-3.1.7) with ESMTP id m6LE8TJH020669 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 21 Jul 2008 10:08:29 -0400 Received: from bankone.net (imf3.svr.bankone.net [155.180.232.177]) by si4.svr.bankone.net (Switch-3.1.8/Switch-3.1.7) with ESMTP id m6LE7xs5019981 for ; Mon, 21 Jul 2008 10:07:59 -0400 Received: from ([169.81.34.42]) by imf3.bankone.net with ESMTP id KP-BRATA.57088759; Mon, 21 Jul 2008 10:07:44 -0400 To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 CCH5 September 12, 2005 Message-ID: From: rohit.x.tripathi@jpmchase.com Date: Mon, 21 Jul 2008 10:07:43 -0400 X-MIMETrack: Serialize by Router on PHLMS133/JPMCHASE(Release 6.5.6FP2|October 17, 2007) at 07/21/2008 10:07:43, Serialize complete at 07/21/2008 10:07:43 Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: init 1 hangs computer when called from within gnome X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 14:35:53 -0000 hi, not sure if its a bug or some error in configuration on my part. I'm running a core2duo Lenovo t61p laptop. I built i386 world and debug kernel from current and found that calling init 1 from a gnome terminal causes the machine to hang....with some red "blood" leaking near the top panel. regards, Rohit ----------------------------------------- This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 15:30:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430A8106566B for ; Mon, 21 Jul 2008 15:30:51 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx1.freebsd.org (Postfix) with ESMTP id E684A8FC18 for ; Mon, 21 Jul 2008 15:30:50 +0000 (UTC) (envelope-from lothar@lobraun.de) Received: from honshu.net.informatik.tu-muenchen.de ([131.159.14.60]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1KKxLf-0004Jk-4s; Mon, 21 Jul 2008 17:30:51 +0200 Message-ID: <4884ABAE.2080605@lobraun.de> Date: Mon, 21 Jul 2008 17:30:54 +0200 From: Lothar Braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: William Grzybowski References: <20080707113401.GA1672@venon.lost.garden> <20080707123655.GA1917@venon.lost.garden> In-Reply-To: <20080707123655.GA1917@venon.lost.garden> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: mount ext2fs - geom_label X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 15:30:51 -0000 William Grzybowski wrote: > On Mon, Jul 07, 2008 at 02:12:44PM +0200, Ivan Voras wrote: >> William Grzybowski wrote: >>> Hi! >>> >>> I'm running -CURRENT from 4 July. >>> I can mount my ext3 partition without any errors but I can't access it: >>> >>> # mount -t ext2fs /dev/ad0s1 /media/ >>> # cd /media >>> cd: not a directory: /media >>> # ls /media >>> ls: /media: Bad file descriptor [snip] > The label was "/", I did change it to "st" and unfortunelly this issue still exists... > >>> I'm not sure if this slice was mounting fine over an older build but for sure it is ext3. >>> Another partition with ext3 is (at least was) working. >>> >>> Am I missing something? Is that some kind of bug? Should i file it? Can you check the inode size on both file systems (tune2fs -l /dev/ | grep Inode)? Do they differ? I encountered a similar problems with a file system that had an inode size of 265 bytes. FreeBSD wasn't able to handle them correctly (see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621) Best regards, Lothar From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 17:21:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16B1106566B for ; Mon, 21 Jul 2008 17:21:14 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 668A98FC1B for ; Mon, 21 Jul 2008 17:21:14 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wx-out-0506.google.com with SMTP id h27so446408wxd.7 for ; Mon, 21 Jul 2008 10:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=keUtLCpcn+HgVMH/z19VAOr6lgEtnAgHnp+R/AKTLpM=; b=r6cHvXjwBqojpvRIRwH4QiOHvbI6GV5v4E0wniX+rhCccMQESUrpoWIQZcoqGiN3Cv +3K4EX5HyX6x03ajVNOawfE2kiPx0F6YA2AJfunVk2EIlk3KWp0u+o/i6XH/WuHxVN9f 7CjzPHZaiXMIgcF7n360sESipqeS5h3ABRp6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TFL3H4SBUQ1XlfcqDCIIKU9azWd6OarPJsTvGbFdDq59mFpE01JCOouawv0hY8pTdR yHoeFmKTXOKW2NMIlhNmMePhpvCWh1EfP0W0bwuwfKc/puipXjNGHiC6FXUzbTayZvD5 We9nNne7y1y/AB9qTLv9s9ipfFdG2m6IKd4ko= Received: by 10.70.78.1 with SMTP id a1mr3276434wxb.80.1216660872283; Mon, 21 Jul 2008 10:21:12 -0700 (PDT) Received: from localhost ( [189.32.44.149]) by mx.google.com with ESMTPS id i16sm1825583wxd.25.2008.07.21.10.21.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jul 2008 10:21:11 -0700 (PDT) Date: Mon, 21 Jul 2008 14:21:05 -0300 From: William Grzybowski To: Lothar Braun Message-ID: <20080721172105.GA16665@venon.lost.garden> References: <20080707113401.GA1672@venon.lost.garden> <20080707123655.GA1917@venon.lost.garden> <4884ABAE.2080605@lobraun.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884ABAE.2080605@lobraun.de> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: mount ext2fs - geom_label X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 17:21:14 -0000 On Mon, Jul 21, 2008 at 05:30:54PM +0200, Lothar Braun wrote: > William Grzybowski wrote: >> On Mon, Jul 07, 2008 at 02:12:44PM +0200, Ivan Voras wrote: >>> William Grzybowski wrote: >>>> Hi! >>>> >>>> I'm running -CURRENT from 4 July. >>>> I can mount my ext3 partition without any errors but I can't access it: >>>> >>>> # mount -t ext2fs /dev/ad0s1 /media/ >>>> # cd /media >>>> cd: not a directory: /media >>>> # ls /media >>>> ls: /media: Bad file descriptor > > [snip] > >> The label was "/", I did change it to "st" and unfortunelly this issue still exists... >> >>>> I'm not sure if this slice was mounting fine over an older build but for sure it is ext3. >>>> Another partition with ext3 is (at least was) working. >>>> >>>> Am I missing something? Is that some kind of bug? Should i file it? > > Can you check the inode size on both file systems (tune2fs -l > /dev/ | grep Inode)? Do they differ? Right, this seems to be my problem, the working partition has the inode size of 128 and the non working 256... Thank you. > > I encountered a similar problems with a file system that had an inode > size of 265 bytes. FreeBSD wasn't able to handle them correctly (see > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621) > > Best regards, > Lothar From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 17:31:31 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327B71065678; Mon, 21 Jul 2008 17:31:31 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail53.yandex.ru (webmail53.yandex.ru [77.88.32.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6625D8FC1C; Mon, 21 Jul 2008 17:31:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail53) by mail.yandex.ru id S13189194AbYGURb1 for (+ 1 other); Mon, 21 Jul 2008 21:31:27 +0400 X-Yandex-Spam: 1 Received: from [77.72.136.71] ([77.72.136.71]) by mail.yandex.ru with HTTP; Mon, 21 Jul 2008 21:31:26 +0400 From: "Andrey V. Elsukov" To: sos@freebsd.org In-Reply-To: References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> MIME-Version: 1.0 Message-Id: <827001216661486@webmail53.yandex.ru> Date: Mon, 21 Jul 2008 21:31:26 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: bu7cher@yandex.ru, snasonov@bcc.ru, freebsd-current@freebsd.org Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 17:31:31 -0000 21.07.08, 17:52, "Søren Schmidt" : > Now, trying to hide this under an AHCI specific suspend/resume fix > wont make it better :) > As I said suspend/resume should be fixed generically so that it helps > ALL chipsets, that wont get done by random hacks to different > chipsets, it will lead us right to chaos and kludges all over the > place, and that scenario will be without yours truely at the ATA helm. > Mind you all the needed code for suspend/resume is already there, its > "just" a matter of being able to call the different parts in new ways. > >> I'm in doubt as to what makes most sense todo, I'm spare time > >> limitted still, so progress here is slow, heck my WIP on NCQ > >> support is still just that and touches the same code parts in ACHI > >> so they willl get even more behind, oh well... > >> I'm starting to wonder if I should just let it go and leave ATA to > >> its own faith, and get on with other things... > > > > What about merging some parts of your WIP (which may be published) to > > perforce repository, it may take some time for you, but after that > > some people can help to do some work with your review. ATA is a big > > subsystem and it isn't easy to maintain it alone. I think.. > Well, the WIP's I have here cannot be merged in pieces, its all or > nothing as it changes stuff in many subtle places. Right now I have > code for NCQ support and for RAID5 support in the outbound queue, but > both changes vital parts of the system. I have my own VCS here so > getting it to something else is just a waste of time that I dont have :) > Some of it still needs clearance before it is let loose in the > official repos. > Which gets us to the last part about maintenance, yes ATA is a rather > big subsystem, and its complicated due to all kinds of broken HW out > there and spec violations etc etc. > If I had the time, I could write a book on how things are put > together, and how I have architected the subsystem to cope with new > stuff and feature, but alas that wont happen as my spare time gets > smaller by the years and so does the donations that could make me use > business hours for it. > So its all just in my head and on lots of notes around here in the lab > which makes it difficult to get it across to others. This is really a > bottleneck, but so far noone has shown the interest or amount of > knowledge / motivation to get into the matter. I can understand that > as the workload is immense and there are no returns, only new bug > reports and requests for support plus the usual whining.. > I guess this is a general problem in this kind of project and cannot > easily be solved.. > Now, back to my much needed vacation... It's sad, I just tried fix problems. But if you want to do it himself, ok. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 17:57:00 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 523EF1065674 for ; Mon, 21 Jul 2008 17:57:00 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1508FC24 for ; Mon, 21 Jul 2008 17:56:58 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from laptop.deepcore.dk (laptop.deepcore.dk [192.168.0.138]) by deepcore.dk (8.14.2/8.13.8) with ESMTP id m6LHutBf084670; Mon, 21 Jul 2008 19:56:56 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) Message-Id: <92DC99EC-22E6-409A-A2A4-A25C57B8A8C3@FreeBSD.ORG> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: "Andrey V. Elsukov" In-Reply-To: <827001216661486@webmail53.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 21 Jul 2008 19:56:55 +0200 References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> <827001216661486@webmail53.yandex.ru> X-Mailer: Apple Mail (2.926) Cc: freebsd-current@FreeBSD.ORG, snasonov@bcc.ru Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 17:57:00 -0000 On 21Jul, 2008, at 19:31 , Andrey V. Elsukov wrote: > 21.07.08, 17:52, "S=F8ren Schmidt" : >> Now, trying to hide this under an AHCI specific suspend/resume fix >> wont make it better :) >> As I said suspend/resume should be fixed generically so that it helps >> ALL chipsets, that wont get done by random hacks to different >> chipsets, it will lead us right to chaos and kludges all over the >> place, and that scenario will be without yours truely at the ATA =20 >> helm. >> Mind you all the needed code for suspend/resume is already there, its >> "just" a matter of being able to call the different parts in new =20 >> ways. >>>> I'm in doubt as to what makes most sense todo, I'm spare time >>>> limitted still, so progress here is slow, heck my WIP on NCQ >>>> support is still just that and touches the same code parts in ACHI >>>> so they willl get even more behind, oh well... >>>> I'm starting to wonder if I should just let it go and leave ATA to >>>> its own faith, and get on with other things... >>> >>> What about merging some parts of your WIP (which may be published) =20= >>> to >>> perforce repository, it may take some time for you, but after that >>> some people can help to do some work with your review. ATA is a big >>> subsystem and it isn't easy to maintain it alone. I think.. >> Well, the WIP's I have here cannot be merged in pieces, its all or >> nothing as it changes stuff in many subtle places. Right now I have >> code for NCQ support and for RAID5 support in the outbound queue, =20= >> but >> both changes vital parts of the system. I have my own VCS here so >> getting it to something else is just a waste of time that I dont =20 >> have :) >> Some of it still needs clearance before it is let loose in the >> official repos. >> Which gets us to the last part about maintenance, yes ATA is a rather >> big subsystem, and its complicated due to all kinds of broken HW out >> there and spec violations etc etc. >> If I had the time, I could write a book on how things are put >> together, and how I have architected the subsystem to cope with new >> stuff and feature, but alas that wont happen as my spare time gets >> smaller by the years and so does the donations that could make me use >> business hours for it. >> So its all just in my head and on lots of notes around here in the =20= >> lab >> which makes it difficult to get it across to others. This is really a >> bottleneck, but so far noone has shown the interest or amount of >> knowledge / motivation to get into the matter. I can understand that >> as the workload is immense and there are no returns, only new bug >> reports and requests for support plus the usual whining.. >> I guess this is a general problem in this kind of project and cannot >> easily be solved.. >> Now, back to my much needed vacation... > > It's sad, I just tried fix problems. But if you want to do it =20 > himself, ok. Well, that was not what I said, but anyways, as long as I stand as =20 maintainer I'd at least try to have a say on how things should be done =20= so maintenance doesn't get more of a nightmare than it already is, nor =20= add work when there is enough already. However, as I already indicated I'm amongst other things using this =20 vacation to think about my continued role here, I've done ATA for 10y, =20= FreeBSD in general for 15y, so forgive me if I sound like an old tired =20= man, I certainly am from time to time :) -S=F8ren > > > --=20 > WBR, Andrey V. Elsukov > -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 20:23:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58DF5106566B for ; Mon, 21 Jul 2008 20:23:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 093088FC1E for ; Mon, 21 Jul 2008 20:23:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KL1uh-0005zj-9s for freebsd-current@freebsd.org; Mon, 21 Jul 2008 20:23:19 +0000 Received: from 77.237.115.237 ([77.237.115.237]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jul 2008 20:23:19 +0000 Received: from ivoras by 77.237.115.237 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jul 2008 20:23:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 21 Jul 2008 22:22:59 +0200 Lines: 17 Message-ID: References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com> <487E5DCD.3010206@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 77.237.115.237 User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) In-Reply-To: <487E5DCD.3010206@FreeBSD.org> Sender: news Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 20:23:24 -0000 Doug Barton wrote: > The ability to do things sequentially is a key benefit of the rc.d > system. The fact that we have not been taking full advantage of that to > date is (once again IMO) an oversight. I hope you mean "sequentially, if needed" - serializing the entire shutdown sequence would be very bad for performance (-> user experience). Offtopic, but related to this and the thread about paralelizing startup scripts: I don't know what Ubuntu is using nowadays, but that thing (the x64 "server" version to be precise) boots and shutdowns incredibly fast. Linux used to be much slower than FreeBSD at startup, to the point of ridicule, but at least the Ubuntu variety is now flaming fast. The improvements are not only in the userland but also at in-kernel hardware detection. I think both the hardware detection and the userland startup each go in parallel (at their appropriate stages, obviously). From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 21:03:28 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B901106567A for ; Mon, 21 Jul 2008 21:03:28 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 278DF8FC14 for ; Mon, 21 Jul 2008 21:03:28 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id m6LL3KhG027313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jul 2008 17:03:27 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu m6LL3KhG027313 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1216674207; bh=q6PS3Ur1IRtLq/Ckl1N5wgLOtkNYnD977MxXfbgbkcI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=uGY5sTmn/GQXgMtYuQnAE2FXHjJOO3+fVLj+v lEt6YgRvjFZ+bISPXVzaMYPHv0OjdurAiT0iCiyRBPAxLcAcw/3SYwRmSZHHRqFAy/E bGutoekRqBrp5myIgizLmFj9NN4trU3OfK2WJrhlpFmWWZ2p8k0AQ0dPaGP9g08lx7Q = Message-ID: <4884F992.7090008@cs.duke.edu> Date: Mon, 21 Jul 2008 17:03:14 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 21:03:28 -0000 I can panic today's -current reliably (or hang it with WITNESS/INVARIENTS disabled). When it crashes, I see the appended panic messages. It seems to be 100% reproducible on my box (AMD64 x2, 512MB ram, UFS2). If anybody savvy in this area would like to reproduce it, I've left the program at ~gallatin/ahunt.c on freefall. Compile it, and run it as: ./a.out -mmbfileinit -madvise=/var/tmp/zot -random -size=95536 -touch=4096 -rewrite=2 Cheers, Drew PS: Here is a serial console log from the panic: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #2 r180446:180672: Mon Jul 21 16:35:46 EDT 2008 gallatin@venice:/usr/src/sys/amd64/compile/WITNESS WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2050.16-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 usable memory = 522149888 (497 MB) avail memory = 502501376 (479 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfeb00000-0xfeb000ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: waiting for BIOS to give up control usb1: timed out waiting for BIOS usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd400-0xd40f mem 0xfe02c000-0xfe02cfff irq 23 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc000-0xc00f mem 0xfe02b000-0xfe02bfff irq 21 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pci1: on pcib1 vgapci0: port 0xac00-0xacff mem 0xd8000000-0xdfffffff,0xfdfe0000-0xfdfeffff irq 18 at device 6.0 on pci1 fwohci0: port 0xa800-0xa87f mem 0xfdfff000-0xfdfff7ff irq 17 at device 9.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:01:29:10:00:04:d8:01 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:01:29:04:d8:01 fwe0: Ethernet address: 02:01:29:04:d8:01 fwip0: on firewire0 fwip0: Firewire address: 00:01:29:10:00:04:d8:01 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1174000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode skc0: port 0xa400-0xa4ff mem 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci1 skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:01:29:f5:bc:3e miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [ITHREAD] nfe0: port 0xbc00-0xbc07 mem 0xfe02a000-0xfe02afff irq 22 at device 10.0 on pci0 miibus1: on nfe0 ciphy0: PHY 1 on miibus1 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:01:29:f5:6b:91 nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pci5: at device 0.0 (no driver attached) cpu0: on acpi0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 device_attach: powernow1 attach returned 6 acpi_button0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] sio1: port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xd37ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: on uhub0 uhub2: 3 ports with 2 removable, bus powered ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 ums0: on uhub2 ums0: 1 buttons. Timecounter "TSC" freqfirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) uency 2050155704 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 ad8: 78167MB at ata4-master SATA150 ad10: 114473MB at ata5-master SATA150 GEOM_LABEL: Label for provider ad8s2 is ext2fs//1. SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. lock order reversal: (sleepable after non-sleepable) 1st 0xffffff000175d028 struct mount mtx (struct mount mtx) @ kern/vfs_subr.c:343 2nd 0xffffff000175d000 vfslock (vfslock) @ kern/vfs_subr.c:370 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x609 __lockmgr_args() at __lockmgr_args+0xc74 vfs_busy() at vfs_busy+0xe7 vfs_mount_alloc() at vfs_mount_alloc+0x8b vfs_mountroot() at vfs_mountroot+0x241 start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40010d30, rbp = 0 --- lock order reversal: (sleepable after non-sleepable) 1st 0xffffff0001763470 vnode interlock (vnode interlock) @ fs/devfs/devfs_vnops.c:288 2nd 0xffffff0001763448 devfs (devfs) @ kern/vfs_subr.c:2044 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x609 __lockmgr_args() at __lockmgr_args+0x502 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x10c devfs_root() at devfs_root+0x52 set_rootvnode() at set_rootvnode+0x2d vfs_mountroot() at vfs_mountroot+0x2fe start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40010d30, rbp = 0 --- Trying to mount root from ufs:/dev/ad8s3a lock order reversal: (sleepable after non-sleepable) 1st 0xffffff00017632f0 bufobj interlock (bufobj interlock) @ kern/vfs_bio.c:2429 2nd 0xfffffffe503099e8 bufwait (bufwait) @ kern/vfs_bio.c:2443 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x609 __lockmgr_args() at __lockmgr_args+0x502 getblk() at getblk+0xe3 breadn() at breadn+0x3f bread() at bread+0x1e ffs_blkatoff() at ffs_blkatoff+0x61 ufs_lookup() at ufs_lookup+0x5f3 vfs_cache_lookup() at vfs_cache_lookup+0xf8 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95 lookup() at lookup+0x4b2 namei() at namei+0x43f kern_unlinkat() at kern_unlinkat+0x9d vfs_mountroot_try() at vfs_mountroot_try+0x41b vfs_mountroot() at vfs_mountroot+0x3eb start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe40010d30, rbp = 0 --- Entropy harvesting: interrupts ethernet point_to_point kickstart. /dev/ad8s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad8s3a: clean, 56390 free (1062 frags, 6916 blocks, 0.8% fragmentation) /dev/ad8s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad8s3d: clean, 126833 free (25 frags, 15851 blocks, 0.0% fragmentation) /dev/ad8s3f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad8s3f: clean, 2601443 free (90875 frags, 313821 blocks, 2.3% fragmentation) /dev/ad8s3e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad8s3e: clean, 847205 free (28653 frags, 102319 blocks, 1.l9% fragmentationoc) k order reversal: 1st 0xffffff00018447f8 ufs (ufs) @ kern/vfs_subr.c:2044 2nd 0xffffffff80b0fcc0 kernel linker (kernel linker) @ kern/kern_linker.c:693 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x609 _sx_xlock() at _sx_xlock+0x52 linker_file_lookup_set() at linker_file_lookup_set+0xe1 linker_file_register_sysctls() at linker_file_register_sysctls+0x20 linker_load_module() at linker_load_module+0x909 linker_load_dependencies() at linker_load_dependencies+0x1bc link_elf_load_file() at link_elf_load_file+0xa8a linker_load_module() at linker_load_module+0x8bf kern_kldload() at kern_kldload+0xac kldload() at kldload+0x84 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xab --- syscall (304, FreeBSD ELF64, kldload), rip = 0x800691c5c, rsp = 0x7fffffffedd8, rbp = 0 --- This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 6 ZFS storage pool version 6 nfe0: link state changed to DOWN Starting Network: lo0 nfe0. sk0: link state changed to DOWN /etc/rc.d/power_profile: WARNING: unable to set hw.acpi.cpu.cx_lowest=C1 Waiting 30s for an interface to come up: ................nfe0: link state changed to UP (nfe0) Mounting NFS file systems:. Setting date via ntp. 21 Jul 16:46:30 ntpdate[1360]: adjust time server 152.2.21.1 offset 0.316513 sec Recovering vi editor sessions:. Configuring syscons: blanktime. Mon Jul 21 16:46:32 EDT 2008 FreeBSD/amd64 (venice) (ttyd0) login: shared lock of (lockmgr) ufs @ kern/vfs_subr.c:2044 while exclusively locked from kern/vfs_vnops.c:593 panic: share->excl cpuid = 1 KDB: enter: panic [thread pid 1702 tid 100149 ] Stopped at kdb_enter+0x3d: movq $0,0x639958(%rip) db> tr Tracing pid 1702 tid 100149 td 0xffffff000d08f000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x176 witness_checkorder() at witness_checkorder+0x137 __lockmgr_args() at __lockmgr_args+0xc74 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vnode_pager_lock() at vnode_pager_lock+0x146 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x395 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff8079f2bd, rsp = 0xfffffffe58c2f7b0, rbp = 0xfffffffe58c2f830 --- copyin() at copyin+0x3d ffs_write() at ffs_write+0x2f8 VOP_WRITE_APV() at VOP_WRITE_APV+0x10b vn_write() at vn_write+0x23f dofilewrite() at dofilewrite+0x85 --More-- kern_writev() at kern_writev+0x60 write() at write+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xab --- syscall (4, FreeBSD ELF64, write), rip = 0x8007296ec, rsp = 0x7fffffffe158, rbp = 0x7fffffffe210 --- db> show locks exclusive sleep mutex vnode interlock r = 0 (0xffffff000d0dc0c0) locked @ vm/vnode_pager.c:1199 exclusive sx user map r = 0 (0xffffff000d054360) locked @ vm/vm_map.c:3115 exclusive lockmgr bufwait r = 0 (0xfffffffe5047f278) locked @ kern/vfs_bio.c:1783 exclusive lockmgr ufs r = 0 (0xffffff000d0dc098) locked @ kern/vfs_vnops.c:593 db> From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 22:17:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781081065676 for ; Mon, 21 Jul 2008 22:17:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DF7758FC22 for ; Mon, 21 Jul 2008 22:17:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6LMHdxS085114; Mon, 21 Jul 2008 18:17:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 21 Jul 2008 17:27:36 -0400 User-Agent: KMail/1.9.7 References: <87prpcjrsk.fsf@kobe.laptop> <1216514182.2172.28.camel@RabbitsDen> <874p6lfjyx.fsf@kobe.laptop> In-Reply-To: <874p6lfjyx.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807211727.36427.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 21 Jul 2008 18:17:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7771/Mon Jul 21 17:09:37 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Giorgos Keramidas , "Alexandre \"Sunny\" Kovalenko" Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:17:49 -0000 On Saturday 19 July 2008 09:00:22 pm Giorgos Keramidas wrote: > On Sat, 19 Jul 2008 20:36:22 -0400, "Alexandre \"Sunny\" Kovalenko" wrote: > > What I meant is that my laptop, runnig RELENG_7 is pretty happy with > > "C2" (set through /etc/rc.conf as performance_cx_lowest="C2", and even > > "C3" (set through /etc/sysctl.conf as dev.cpu.1.cx_lowest=C3), so long > > as cpu0 is not allowed to go into C3. You seemed to indicate that in > > your case nothing but "C1" worked. If you just did not try the > > configuration above, would you, please, try it and see if it works. > > Apart from, hopefully, giving someone the data point, it will make > > your laptop cooler and less power hungry. > > Ah, now I get it :) > > Well, I did try the following after booting with both CPUs in C1 state: > > (1) hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_lowest: C2 > > I left the laptop to boot with both CPUs in C1, and then after a > while I manually set dev.cpu.0.cx_lowest=C2. This setup seems > ok. I can see processes being scheduled on both cpu.0 and cpu.1 > and there's no "freeze" when the laptop is idle. > > (2) hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_lowest: C3 > > Same as above, only this time I set dev.cpu.0.cx_lowest=C3. > > (3) hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_lowest: C2 > dev.cpu.0.cx_lowest: C2 > > Not ok. When the laptop stays idle for some time, it starts > getting too slow to type stuff in a terminal, and after a while > I get `calcru: runtime went backwards' messages. > > I don't know if being scheduled on cpu.1 when it is in C2/C3 state has > any measurable impact on user processes. Should I leave the settings to > option (1) or (2) above for a while? Is there any way to find out if > this causes any problems? My guess is that when both CPUs are in C2 or lower, the local APIC timer is getting shut off and that is why your box is no longer responsive. Fixing this is doable, but not very easy currently. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 22:40:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78E131065684; Mon, 21 Jul 2008 22:40:24 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E82598FC0A; Mon, 21 Jul 2008 22:40:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.2/8.14.2) with ESMTP id m6LMe8SK053703; Tue, 22 Jul 2008 02:40:08 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Tue, 22 Jul 2008 02:40:08 +0400 (MSD) From: Dmitry Morozovsky To: "Andrey V. Elsukov" In-Reply-To: <827001216661486@webmail53.yandex.ru> Message-ID: <20080722023756.T53123@woozle.rinet.ru> References: <200807151124.36621.snasonov@bcc.ru> <4884668C.5060606@yandex.ru> <4DCB1935-4248-472B-8328-E0365306B953@FreeBSD.ORG> <48848887.6020201@yandex.ru> <827001216661486@webmail53.yandex.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (woozle.rinet.ru [0.0.0.0]); Tue, 22 Jul 2008 02:40:08 +0400 (MSD) Cc: snasonov@bcc.ru, freebsd-current@freebsd.org, sos@freebsd.org Subject: Re: RFC, RFT: AHCI driver reorganization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:40:24 -0000 On Mon, 21 Jul 2008, Andrey V. Elsukov wrote: [snip all] AVE> It's sad, I just tried fix problems. But if you want to do it himself, ok. Andy, it seems it would be feasible to create perforce branch where you can commit your step-by-step pactches so at least committers can test them? Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Jul 21 22:41:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A085106566C; Mon, 21 Jul 2008 22:41:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E40DF8FC29; Mon, 21 Jul 2008 22:41:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6LMex7x086831; Mon, 21 Jul 2008 18:40:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6LMexSE062921; Mon, 21 Jul 2008 18:40:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 96D1A73039; Mon, 21 Jul 2008 18:40:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080721224059.96D1A73039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 18:40:59 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:41:02 -0000 TB --- 2008-07-21 21:33:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-21 21:33:54 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-21 21:33:54 - cleaning the object tree TB --- 2008-07-21 21:34:17 - cvsupping the source tree TB --- 2008-07-21 21:34:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-21 21:34:24 - building world (CFLAGS=-O -pipe) TB --- 2008-07-21 21:34:24 - cd /src TB --- 2008-07-21 21:34:24 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 21 21:34:25 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 21 22:39:04 UTC 2008 TB --- 2008-07-21 22:39:04 - generating LINT kernel config TB --- 2008-07-21 22:39:04 - cd /src/sys/sun4v/conf TB --- 2008-07-21 22:39:04 - /usr/bin/make -B LINT TB --- 2008-07-21 22:39:04 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-21 22:39:04 - cd /src TB --- 2008-07-21 22:39:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 21 22:39:04 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-21 22:40:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-21 22:40:59 - ERROR: failed to build lint kernel TB --- 2008-07-21 22:40:59 - tinderbox aborted TB --- 2973.72 user 373.52 system 4024.80 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 00:34:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F233106564A; Tue, 22 Jul 2008 00:34:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 07CF18FC13; Tue, 22 Jul 2008 00:34:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M0Yqak053600; Mon, 21 Jul 2008 20:34:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M0Yq59078572; Mon, 21 Jul 2008 20:34:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DB7D473039; Mon, 21 Jul 2008 20:34:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722003451.DB7D473039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 20:34:51 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 00:34:55 -0000 TB --- 2008-07-21 22:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-21 22:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-07-21 22:45:00 - cleaning the object tree TB --- 2008-07-21 22:45:41 - cvsupping the source tree TB --- 2008-07-21 22:45:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-07-21 22:45:46 - building world (CFLAGS=-O -pipe) TB --- 2008-07-21 22:45:46 - cd /src TB --- 2008-07-21 22:45:46 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 21 22:45:48 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 22 00:26:43 UTC 2008 TB --- 2008-07-22 00:26:43 - generating LINT kernel config TB --- 2008-07-22 00:26:43 - cd /src/sys/amd64/conf TB --- 2008-07-22 00:26:43 - /usr/bin/make -B LINT TB --- 2008-07-22 00:26:43 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 00:26:43 - cd /src TB --- 2008-07-22 00:26:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 00:26:43 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 00:34:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 00:34:51 - ERROR: failed to build lint kernel TB --- 2008-07-22 00:34:51 - tinderbox aborted TB --- 4767.21 user 613.84 system 6591.09 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 00:53:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B5C01065679 for ; Tue, 22 Jul 2008 00:53:30 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1BA8FC16 for ; Tue, 22 Jul 2008 00:53:29 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl10-74.kln.forthnet.gr [77.49.137.74]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-4) with ESMTP id m6M0rHew005292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jul 2008 03:53:23 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m6M0rHaK005961; Tue, 22 Jul 2008 03:53:17 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m6M0rGdS005960; Tue, 22 Jul 2008 03:53:17 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: John Baldwin References: <87prpcjrsk.fsf@kobe.laptop> <1216514182.2172.28.camel@RabbitsDen> <874p6lfjyx.fsf@kobe.laptop> <200807211727.36427.jhb@freebsd.org> Date: Tue, 22 Jul 2008 03:53:16 +0300 In-Reply-To: <200807211727.36427.jhb@freebsd.org> (John Baldwin's message of "Mon, 21 Jul 2008 17:27:36 -0400") Message-ID: <87fxq2u4cj.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m6M0rHew005292 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.263, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.14, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, "Alexandre \"Sunny\" Kovalenko" Subject: Re: Broken APIC on my laptop or bug in FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 00:53:30 -0000 On Mon, 21 Jul 2008 17:27:36 -0400, John Baldwin wrote: > On Saturday 19 July 2008 09:00:22 pm Giorgos Keramidas wrote: >> Well, I did try the following after booting with both CPUs in C1 state: >> >> (1) hw.acpi.cpu.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C2 >> >> I left the laptop to boot with both CPUs in C1, and then after a >> while I manually set dev.cpu.0.cx_lowest=C2. This setup seems >> ok. I can see processes being scheduled on both cpu.0 and cpu.1 >> and there's no "freeze" when the laptop is idle. >> >> (2) hw.acpi.cpu.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C3 >> >> Same as above, only this time I set dev.cpu.0.cx_lowest=C3. >> >> (3) hw.acpi.cpu.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C2 >> dev.cpu.0.cx_lowest: C2 >> >> Not ok. When the laptop stays idle for some time, it starts >> getting too slow to type stuff in a terminal, and after a while >> I get `calcru: runtime went backwards' messages. >> >> I don't know if being scheduled on cpu.1 when it is in C2/C3 state has >> any measurable impact on user processes. Should I leave the settings to >> option (1) or (2) above for a while? Is there any way to find out if >> this causes any problems? > > My guess is that when both CPUs are in C2 or lower, the local APIC > timer is getting shut off and that is why your box is no longer > responsive. Fixing this is doable, but not very easy currently. Thanks! I can live with at least one core being in C1. It was mostly an annoying thing that "used to work" and seemed to be broken when I had to replace the old dead laptop. Thanks to Alexandre's excellent help, I can keep working now. If there's any sort of patch or experimental thing I can test, or you happen to think of something that would be nice to try, count me in :) From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 01:10:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06480106564A; Tue, 22 Jul 2008 01:10:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B25808FC15; Tue, 22 Jul 2008 01:10:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M1Aiqq057671; Mon, 21 Jul 2008 21:10:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M1AiTd098526; Mon, 21 Jul 2008 21:10:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0C01D73039; Mon, 21 Jul 2008 21:10:44 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722011044.0C01D73039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 21:10:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 01:10:47 -0000 TB --- 2008-07-21 23:51:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-21 23:51:58 - starting HEAD tinderbox run for i386/i386 TB --- 2008-07-21 23:51:58 - cleaning the object tree TB --- 2008-07-21 23:52:32 - cvsupping the source tree TB --- 2008-07-21 23:52:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-07-21 23:52:41 - building world (CFLAGS=-O -pipe) TB --- 2008-07-21 23:52:41 - cd /src TB --- 2008-07-21 23:52:41 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 21 23:52:43 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 01:02:13 UTC 2008 TB --- 2008-07-22 01:02:13 - generating LINT kernel config TB --- 2008-07-22 01:02:13 - cd /src/sys/i386/conf TB --- 2008-07-22 01:02:13 - /usr/bin/make -B LINT TB --- 2008-07-22 01:02:13 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 01:02:13 - cd /src TB --- 2008-07-22 01:02:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 01:02:13 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 01:10:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 01:10:43 - ERROR: failed to build lint kernel TB --- 2008-07-22 01:10:43 - tinderbox aborted TB --- 3404.93 user 424.70 system 4725.15 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 01:52:35 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF5CB106566C; Tue, 22 Jul 2008 01:52:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE818FC16; Tue, 22 Jul 2008 01:52:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M1qWLq061013; Mon, 21 Jul 2008 21:52:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M1qWwT025235; Mon, 21 Jul 2008 21:52:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 49E1673039; Mon, 21 Jul 2008 21:52:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722015232.49E1673039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 21:52:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 01:52:35 -0000 TB --- 2008-07-22 00:34:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 00:34:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-07-22 00:34:52 - cleaning the object tree TB --- 2008-07-22 00:35:18 - cvsupping the source tree TB --- 2008-07-22 00:35:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-07-22 00:35:24 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 00:35:24 - cd /src TB --- 2008-07-22 00:35:24 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 00:35:26 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 01:44:55 UTC 2008 TB --- 2008-07-22 01:44:55 - generating LINT kernel config TB --- 2008-07-22 01:44:55 - cd /src/sys/pc98/conf TB --- 2008-07-22 01:44:55 - /usr/bin/make -B LINT TB --- 2008-07-22 01:44:55 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 01:44:55 - cd /src TB --- 2008-07-22 01:44:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 01:44:55 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 01:52:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 01:52:32 - ERROR: failed to build lint kernel TB --- 2008-07-22 01:52:32 - tinderbox aborted TB --- 3334.15 user 430.49 system 4660.16 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 02:39:41 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1431065674; Tue, 22 Jul 2008 02:39:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2278FC18; Tue, 22 Jul 2008 02:39:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M2ddTP005781; Mon, 21 Jul 2008 22:39:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M2ddp0031266; Mon, 21 Jul 2008 22:39:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DC69A73039; Mon, 21 Jul 2008 22:39:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722023938.DC69A73039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 22:39:38 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 02:39:41 -0000 TB --- 2008-07-22 01:10:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 01:10:44 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-07-22 01:10:44 - cleaning the object tree TB --- 2008-07-22 01:11:17 - cvsupping the source tree TB --- 2008-07-22 01:11:17 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-07-22 01:11:23 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 01:11:23 - cd /src TB --- 2008-07-22 01:11:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 01:11:26 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 02:30:57 UTC 2008 TB --- 2008-07-22 02:30:57 - generating LINT kernel config TB --- 2008-07-22 02:30:57 - cd /src/sys/ia64/conf TB --- 2008-07-22 02:30:57 - /usr/bin/make -B LINT TB --- 2008-07-22 02:30:57 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 02:30:57 - cd /src TB --- 2008-07-22 02:30:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 02:30:57 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 02:39:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 02:39:38 - ERROR: failed to build lint kernel TB --- 2008-07-22 02:39:38 - tinderbox aborted TB --- 3879.42 user 425.48 system 5334.48 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 03:08:48 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC9AB1065672; Tue, 22 Jul 2008 03:08:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1578FC1E; Tue, 22 Jul 2008 03:08:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M38lHP007346; Mon, 21 Jul 2008 23:08:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M38kwK054835; Mon, 21 Jul 2008 23:08:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9F01273039; Mon, 21 Jul 2008 23:08:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722030846.9F01273039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 23:08:46 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 03:08:49 -0000 TB --- 2008-07-22 01:52:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 01:52:32 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-07-22 01:52:32 - cleaning the object tree TB --- 2008-07-22 01:52:59 - cvsupping the source tree TB --- 2008-07-22 01:52:59 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-07-22 01:53:08 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 01:53:08 - cd /src TB --- 2008-07-22 01:53:08 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 01:53:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 03:02:40 UTC 2008 TB --- 2008-07-22 03:02:40 - generating LINT kernel config TB --- 2008-07-22 03:02:40 - cd /src/sys/powerpc/conf TB --- 2008-07-22 03:02:40 - /usr/bin/make -B LINT TB --- 2008-07-22 03:02:40 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 03:02:40 - cd /src TB --- 2008-07-22 03:02:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 03:02:40 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 03:08:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 03:08:46 - ERROR: failed to build lint kernel TB --- 2008-07-22 03:08:46 - tinderbox aborted TB --- 3343.91 user 402.12 system 4574.12 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 03:53:48 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E23F1065679; Tue, 22 Jul 2008 03:53:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 346E58FC13; Tue, 22 Jul 2008 03:53:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M3rjt4009789; Mon, 21 Jul 2008 23:53:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M3rjx2085223; Mon, 21 Jul 2008 23:53:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 62C0673039; Mon, 21 Jul 2008 23:53:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722035345.62C0673039@freebsd-current.sentex.ca> Date: Mon, 21 Jul 2008 23:53:45 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 03:53:48 -0000 TB --- 2008-07-22 02:39:39 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 02:39:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-22 02:39:39 - cleaning the object tree TB --- 2008-07-22 02:40:05 - cvsupping the source tree TB --- 2008-07-22 02:40:05 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-22 02:40:11 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 02:40:11 - cd /src TB --- 2008-07-22 02:40:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 02:40:13 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 03:46:41 UTC 2008 TB --- 2008-07-22 03:46:41 - generating LINT kernel config TB --- 2008-07-22 03:46:41 - cd /src/sys/sparc64/conf TB --- 2008-07-22 03:46:41 - /usr/bin/make -B LINT TB --- 2008-07-22 03:46:41 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 03:46:41 - cd /src TB --- 2008-07-22 03:46:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 03:46:41 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 03:53:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 03:53:45 - ERROR: failed to build lint kernel TB --- 2008-07-22 03:53:45 - tinderbox aborted TB --- 3168.48 user 401.73 system 4446.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 04:14:08 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C390106566C; Tue, 22 Jul 2008 04:14:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id B70C68FC1A; Tue, 22 Jul 2008 04:14:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M4E4g1073564; Tue, 22 Jul 2008 00:14:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M4E4TB019945; Tue, 22 Jul 2008 00:14:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6FF0073039; Tue, 22 Jul 2008 00:14:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722041404.6FF0073039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 00:14:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 04:14:08 -0000 TB --- 2008-07-22 03:08:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 03:08:46 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-22 03:08:46 - cleaning the object tree TB --- 2008-07-22 03:09:06 - cvsupping the source tree TB --- 2008-07-22 03:09:06 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-22 03:09:13 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 03:09:13 - cd /src TB --- 2008-07-22 03:09:13 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 03:09:14 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 04:12:16 UTC 2008 TB --- 2008-07-22 04:12:16 - generating LINT kernel config TB --- 2008-07-22 04:12:16 - cd /src/sys/sun4v/conf TB --- 2008-07-22 04:12:16 - /usr/bin/make -B LINT TB --- 2008-07-22 04:12:16 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 04:12:16 - cd /src TB --- 2008-07-22 04:12:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 04:12:16 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 04:14:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 04:14:04 - ERROR: failed to build lint kernel TB --- 2008-07-22 04:14:04 - tinderbox aborted TB --- 2963.52 user 376.44 system 3917.59 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 05:29:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCF52106564A for ; Tue, 22 Jul 2008 05:29:19 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA758FC0C for ; Tue, 22 Jul 2008 05:29:19 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:Subject:From:X-Attribution:Date:Message-Id; b=gzgVZ+nBwBgFDCMKnK8laaogE8yor1sXDlbIivvYaeGkx9DfGgO10VZiCLwQeGbm0HS2Xg4cFCiyyWvm0WdUwInQBEIn2jdlRhkFgnJTcheT8LeZ7XWekR+k5bJuARSp8WNmqEJyk0j+IMJdoivJhGjumeCRDKXcmOVpm+h4pzYsUFTGxvXNvYUlO02IBL3vOvt/L+XuBX6agdAtnl29ICOU7NvebinkIo53GAuuPEtK+WexzDqNQXbM34T9htY8; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1KLA4q-0005Ev-Gs for current@freebsd.org; Tue, 22 Jul 2008 05:06:20 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KLA48-0002D0-Eu for current@freebsd.org; Tue, 22 Jul 2008 05:05:36 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLA49-0000W2-I1 for current@freebsd.org; Tue, 22 Jul 2008 07:05:37 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Tue, 22 Jul 2008 07:05:37 +0200 Message-Id: Cc: Subject: Recent Padlock changes break ssh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 05:29:19 -0000 Hi Reverting to src/sys/crypto/via/padlock.c to r1.13 allow me to once again ssh into my VIA C7 based system. I get the following error on the local side when attempting to ssh to the server when r1.14 is in use. [apple] ~ $ ssh control.freislich.nom.za Disconnecting: Bad packet length 4108489293. [apple] ~ $ ssh control.freislich.nom.za Disconnecting: Bad packet length 3064303097. I do however see this message on the very first ssh attempt to the server in question with a working kernel (12 July 2008). Subsequent connections connections work correctly. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 06:05:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DCCD106567E; Tue, 22 Jul 2008 06:05:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCCB8FC14; Tue, 22 Jul 2008 06:05:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M64w5K081755; Tue, 22 Jul 2008 02:04:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6M64wV9086017; Tue, 22 Jul 2008 02:04:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9898173039; Tue, 22 Jul 2008 02:04:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722060458.9898173039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 02:04:58 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 06:05:02 -0000 TB --- 2008-07-22 04:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 04:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-07-22 04:15:00 - cleaning the object tree TB --- 2008-07-22 04:15:39 - cvsupping the source tree TB --- 2008-07-22 04:15:39 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-07-22 04:15:46 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 04:15:46 - cd /src TB --- 2008-07-22 04:15:46 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 04:15:48 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 22 05:56:52 UTC 2008 TB --- 2008-07-22 05:56:52 - generating LINT kernel config TB --- 2008-07-22 05:56:52 - cd /src/sys/amd64/conf TB --- 2008-07-22 05:56:52 - /usr/bin/make -B LINT TB --- 2008-07-22 05:56:52 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 05:56:52 - cd /src TB --- 2008-07-22 05:56:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 05:56:52 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_id.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_mcast.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_4tuple_get': /src/sys/netinet/in_pcb.c:1306: warning: passing argument 1 of '_rw_assert' discards qualifiers from pointer target type /src/sys/netinet/in_pcb.c:1307: error: incompatible types in assignment /src/sys/netinet/in_pcb.c:1308: error: incompatible types in assignment *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 06:04:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 06:04:58 - ERROR: failed to build lint kernel TB --- 2008-07-22 06:04:58 - tinderbox aborted TB --- 4767.67 user 615.14 system 6597.95 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 08:14:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B813C1065683 for ; Tue, 22 Jul 2008 08:14:51 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 029888FC08 for ; Tue, 22 Jul 2008 08:14:50 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 28C2945C98; Tue, 22 Jul 2008 10:14:49 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6913945685; Tue, 22 Jul 2008 10:14:44 +0200 (CEST) Date: Tue, 22 Jul 2008 10:14:49 +0200 From: Pawel Jakub Dawidek To: Ian FREISLICH Message-ID: <20080722081449.GA3241@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org Subject: Re: Recent Padlock changes break ssh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 08:14:51 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 07:05:37AM +0200, Ian FREISLICH wrote: > Hi >=20 > Reverting to src/sys/crypto/via/padlock.c to r1.13 allow me to once > again ssh into my VIA C7 based system. >=20 > I get the following error on the local side when attempting to ssh > to the server when r1.14 is in use. >=20 > [apple] ~ $ ssh control.freislich.nom.za > Disconnecting: Bad packet length 4108489293. > [apple] ~ $ ssh control.freislich.nom.za > Disconnecting: Bad packet length 3064303097. >=20 > I do however see this message on the very first ssh attempt to the > server in question with a working kernel (12 July 2008). Subsequent > connections connections work correctly. Could you try this patch? Those are the only changes that could eventually change the behaviour. http://people.freebsd.org/~pjd/patches/padlock.c.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhZb4ForvXbEpPzQRAgz+AJ40tQjyral5pKQdsGIn+LxpOx6+EwCgyD8V C5sXfgWuTAooWTYEtZDjToM= =KbVy -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 08:50:31 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A475D1065676 for ; Tue, 22 Jul 2008 08:50:31 +0000 (UTC) (envelope-from ng-freebsd-current@mindstep.com) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB3FC8FC1B for ; Tue, 22 Jul 2008 08:50:30 +0000 (UTC) (envelope-from ng-freebsd-current@mindstep.com) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix1-g20.free.fr (Postfix) with ESMTP id E8F022882755 for ; Tue, 22 Jul 2008 10:24:14 +0200 (CEST) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 8504917F538; Tue, 22 Jul 2008 10:24:12 +0200 (CEST) Received: from crest.mindstep.com (crest.mindstep.com [88.167.204.204]) by smtp8-g19.free.fr (Postfix) with ESMTP id 4095617F515; Tue, 22 Jul 2008 10:24:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kawa.mindstep.fr (Postfix) with ESMTP id E4409FDB8F7; Tue, 22 Jul 2008 10:24:11 +0200 (CEST) (envelope-from ng-freebsd-current@mindstep.com) X-Virus-Scanned: by amavisd-new on ZunoBox at kawa.mindstep.fr Received: from kawa.mindstep.fr ([127.0.0.1]) by localhost (kawa.mindstep.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r6mz2auJDl-S; Tue, 22 Jul 2008 10:24:11 +0200 (CEST) Received: from [192.168.25.13] (pickwick.mindstep.fr [192.168.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kawa.mindstep.fr (Postfix) with ESMTP id B1BF1FDB8CD; Tue, 22 Jul 2008 10:24:11 +0200 (CEST) (envelope-from ng-freebsd-current@mindstep.com) Message-ID: <48859927.4090203@mindstep.com> Date: Tue, 22 Jul 2008 10:24:07 +0200 From: Patrick Bihan-Faou User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20080722081449.GA3241@garage.freebsd.pl> In-Reply-To: <20080722081449.GA3241@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Ian FREISLICH , current@freebsd.org Subject: Re: Recent Padlock changes break ssh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ng-freebsd-current@mindstep.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 08:50:31 -0000 Hi, I have noticed the same problem as described by Ian, on systems using C7 processor with padlock support compiled in the kernel, the very first connection via SSH fails with the message indicated below (bad packet length), subsequent connections are always fine. This is with FreeBSD 6.x (I am now using 6.3-p3, but this has been noticed since I started using C7 bases systems with FreeBSD 6.0) Patrick. Pawel Jakub Dawidek a crit : > On Tue, Jul 22, 2008 at 07:05:37AM +0200, Ian FREISLICH wrote: > >> Hi >> >> Reverting to src/sys/crypto/via/padlock.c to r1.13 allow me to once >> again ssh into my VIA C7 based system. >> >> I get the following error on the local side when attempting to ssh >> to the server when r1.14 is in use. >> >> [apple] ~ $ ssh control.freislich.nom.za >> Disconnecting: Bad packet length 4108489293. >> [apple] ~ $ ssh control.freislich.nom.za >> Disconnecting: Bad packet length 3064303097. >> >> I do however see this message on the very first ssh attempt to the >> server in question with a working kernel (12 July 2008). Subsequent >> connections connections work correctly. >> > > Could you try this patch? Those are the only changes that could > eventually change the behaviour. > > http://people.freebsd.org/~pjd/patches/padlock.c.patch > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 10:11:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74843106567F; Tue, 22 Jul 2008 10:11:18 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 344288FC0C; Tue, 22 Jul 2008 10:11:18 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:References:X-Attribution:Date:Message-Id; b=bIqjW/JoZS58157bgo0Nb4vrLDt0T99PD8aq2+ahWtfZgAVRFFWnTsRb3ftSwz7q+Z0BzMCPpD3vN2XsfLtYNjjQmqqHwNkbqTUALLjMgwvVYCwyyoDImYH5wFMUnD36FheNy5XNTp+WPq/yPEjmP+ilSIPO3yh6jybN8egfE+n8RNtLN4TzPIRsisgTQVnJCcWeCzpw7Ka4hDaZ6ySzRj9M7ZFy6GVTDk1o3IqyaTam9s9dcKqLgkgWQOG6xq5K; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1KLEpx-00059A-FZ; Tue, 22 Jul 2008 10:11:17 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KLEpN-00058N-Pu; Tue, 22 Jul 2008 10:10:41 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLEpQ-0000x5-RQ; Tue, 22 Jul 2008 12:10:44 +0200 To: Pawel Jakub Dawidek From: Ian FREISLICH In-Reply-To: <20080722081449.GA3241@garage.freebsd.pl> References: <20080722081449.GA3241@garage.freebsd.pl> X-Attribution: BOFH Date: Tue, 22 Jul 2008 12:10:44 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: Recent Padlock changes break ssh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 10:11:18 -0000 Pawel Jakub Dawidek wrote: > On Tue, Jul 22, 2008 at 07:05:37AM +0200, Ian FREISLICH wrote: > > Hi > >=20 > > Reverting to src/sys/crypto/via/padlock.c to r1.13 allow me to once > > again ssh into my VIA C7 based system. > >=20 > > I get the following error on the local side when attempting to ssh > > to the server when r1.14 is in use. > >=20 > > [apple] ~ $ ssh control.freislich.nom.za > > Disconnecting: Bad packet length 4108489293. > > [apple] ~ $ ssh control.freislich.nom.za > > Disconnecting: Bad packet length 3064303097. > >=20 > > I do however see this message on the very first ssh attempt to the > > server in question with a working kernel (12 July 2008). Subsequent > > connections connections work correctly. > > Could you try this patch? Those are the only changes that could > eventually change the behaviour. > > http://people.freebsd.org/~pjd/patches/padlock.c.patch Even the first connection works correctly with this patch now or r1.14. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 10:35:56 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18ECA106566C; Tue, 22 Jul 2008 10:35:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D44888FC15; Tue, 22 Jul 2008 10:35:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MAZrLq004628; Tue, 22 Jul 2008 06:35:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MAZqQA081470; Tue, 22 Jul 2008 06:35:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D7F8473039; Tue, 22 Jul 2008 06:35:52 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722103552.D7F8473039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 06:35:52 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 10:35:56 -0000 TB --- 2008-07-22 09:27:11 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 09:27:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-22 09:27:11 - cleaning the object tree TB --- 2008-07-22 09:27:31 - cvsupping the source tree TB --- 2008-07-22 09:27:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-22 09:27:39 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 09:27:39 - cd /src TB --- 2008-07-22 09:27:39 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 22 09:27:40 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 22 10:33:29 UTC 2008 TB --- 2008-07-22 10:33:29 - generating LINT kernel config TB --- 2008-07-22 10:33:29 - cd /src/sys/sun4v/conf TB --- 2008-07-22 10:33:29 - /usr/bin/make -B LINT TB --- 2008-07-22 10:33:29 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-22 10:33:29 - cd /src TB --- 2008-07-22 10:33:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 22 10:33:29 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] machine -> /src/sys/sun4v/include sparc64 -> /src/sys/sparc64/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/obj/sun4v/src/sys/LINT /src/sys/modules/mem/../../dev/mem/memdev.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c /src/sys/modules/mem/../../sparc64/sparc64/mem.c:73:27: error: machine/cache.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/sys/modules/mem. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-22 10:35:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 10:35:52 - ERROR: failed to build lint kernel TB --- 2008-07-22 10:35:52 - tinderbox aborted TB --- 2981.77 user 374.44 system 4121.66 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 12:44:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAB51065672; Tue, 22 Jul 2008 12:44:44 +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 597A58FC2A; Tue, 22 Jul 2008 12:44:44 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C27D92092; Tue, 22 Jul 2008 14:44:42 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> <20080718070624.GC1976@garage.freebsd.pl> Date: Tue, 22 Jul 2008 14:44:42 +0200 In-Reply-To: <20080718070624.GC1976@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri\, 18 Jul 2008 09\:06\:24 +0200") Message-ID: <86fxq2ozph.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Peter Jeremy , Remko Lodder , src-committers@freebsd.org, "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 12:44:44 -0000 Pawel Jakub Dawidek writes: > Just to be clear. I fully agree with you guys. What I could do about > that when I was working on gmirror (starting from the simplest > solution): > > 1. Skip disks which have version lower then what we have in the kernel. > > 2. Upgrade the on-disk metadata automatically. > > 3. Make gmirror kernel module to work with all the previous versions and > add 'gmirror upgrade' command, so one can upgrade on-disk metadata. 4. Allow an older mirror to be accessed r/o by a newer kernel, side- stepping the issue of converting metadata back to the old format. Require an explicit 'gmirror upgrade' to upgrade the metadata and allow r/w access. IIRC, this is what ZFS does. I believe it would be a good compromise between 2 and 3. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 12:50:25 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D121065674; Tue, 22 Jul 2008 12:50:25 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id D50188FC2F; Tue, 22 Jul 2008 12:50:24 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D61BB45C89; Tue, 22 Jul 2008 14:50:22 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 29B5F45B26; Tue, 22 Jul 2008 14:50:19 +0200 (CEST) Date: Tue, 22 Jul 2008 14:50:24 +0200 From: Pawel Jakub Dawidek To: Dag-Erling Sm??rgrav Message-ID: <20080722125024.GE3241@garage.freebsd.pl> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> <20080718070624.GC1976@garage.freebsd.pl> <86fxq2ozph.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ILuaRSyQpoVaJ1HG" Content-Disposition: inline In-Reply-To: <86fxq2ozph.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Peter Jeremy , Remko Lodder , src-committers@freebsd.org, "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 12:50:25 -0000 --ILuaRSyQpoVaJ1HG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 02:44:42PM +0200, Dag-Erling Sm??rgrav wrote: > Pawel Jakub Dawidek writes: > > Just to be clear. I fully agree with you guys. What I could do about > > that when I was working on gmirror (starting from the simplest > > solution): > > > > 1. Skip disks which have version lower then what we have in the kernel. > > > > 2. Upgrade the on-disk metadata automatically. > > > > 3. Make gmirror kernel module to work with all the previous versions and > > add 'gmirror upgrade' command, so one can upgrade on-disk metadata. >=20 > 4. Allow an older mirror to be accessed r/o by a newer kernel, side- > stepping the issue of converting metadata back to the old format. > Require an explicit 'gmirror upgrade' to upgrade the metadata and > allow r/w access. >=20 > IIRC, this is what ZFS does. I believe it would be a good compromise > between 2 and 3. ZFS does exactly 3. What you are suggesting could be done by not loading geom_mirror.ko module and mounting file system read-only from one of the mirror components. Of course automatic gmirror metadata upgrade is in most of the cases a surprise. Although, one can still just boot it on an older system and create mirror once again - 'gmirror label' command won't touch the data. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ILuaRSyQpoVaJ1HG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhdePForvXbEpPzQRAnUNAJ98KeRKc3WocUSWBQGnfNH85LadtQCg9Eay zz2kiky+kTZjE6w5gxb0pFs= =3ZyY -----END PGP SIGNATURE----- --ILuaRSyQpoVaJ1HG-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 13:38:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78FE41065675; Tue, 22 Jul 2008 13:38:21 +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 1164C8FC0C; Tue, 22 Jul 2008 13:38:21 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 7FB24208F; Tue, 22 Jul 2008 15:38:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> <20080718070624.GC1976@garage.freebsd.pl> <86fxq2ozph.fsf@ds4.des.no> <20080722125024.GE3241@garage.freebsd.pl> Date: Tue, 22 Jul 2008 15:38:19 +0200 In-Reply-To: <20080722125024.GE3241@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Tue\, 22 Jul 2008 14\:50\:24 +0200") Message-ID: <863am2ox84.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Peter Jeremy , Remko Lodder , src-committers@freebsd.org, "current@freebsd.org" Subject: Re: geom_mirror silently upgrading metadata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 13:38:21 -0000 Pawel Jakub Dawidek writes: > ZFS does exactly 3. What you are suggesting could be done by not loading > geom_mirror.ko module and mounting file system read-only from one of the > mirror components. [...] Would it really be that hard for geom_mirror to translate enough of the old metadata to access the mirror r/o, and only perform the upgrade on explicit request? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 14:53:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E2D1065673; Tue, 22 Jul 2008 14:53:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id ED7478FC1B; Tue, 22 Jul 2008 14:53:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MErAqj073165; Tue, 22 Jul 2008 10:53:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MErAOO090077; Tue, 22 Jul 2008 10:53:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 19E5C73039; Tue, 22 Jul 2008 10:53:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722145310.19E5C73039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 10:53:10 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 14:53:13 -0000 TB --- 2008-07-22 14:52:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 14:52:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-07-22 14:52:36 - cleaning the object tree TB --- 2008-07-22 14:53:02 - cvsupping the source tree TB --- 2008-07-22 14:53:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-07-22 14:53:09 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 14:53:09 - cd /src TB --- 2008-07-22 14:53:09 - /usr/bin/make -B buildworld TB --- 2008-07-22 14:53:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 14:53:09 - ERROR: failed to build world TB --- 2008-07-22 14:53:09 - tinderbox aborted TB --- 2.15 user 3.09 system 33.89 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 15:15:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1658F1065856 for ; Tue, 22 Jul 2008 15:15:17 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 016878FC08 for ; Tue, 22 Jul 2008 15:15:16 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [172.17.2.20] (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6MEmqJP093510 for ; Tue, 22 Jul 2008 10:48:53 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: current@freebsd.org Date: Tue, 22 Jul 2008 10:48:48 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221048.48729.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: ath vap - second hostap _almost_ works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:15:17 -0000 Sam et al- I just upgraded my "router" box to -CURRENT so I could try out the new vap code. The upgrade went fine and the single access point setup I had before works fine on wlan0. I'm trying to set up a second access point for an "insecure" network. I am able to create and configure the wlan1 interface and clients can see the SSID and associate to the network. However the access point is unable to send traffic over the interface (the 103 network below): stealth# ping 192.168.103.240 PING 192.168.103.240 (192.168.103.240): 56 data bytes ping: sendto: Network is down Interestingly, it can receive traffic just fine. DHCP, for instance: stealth# tcpdump -i wlan1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan1, link-type EN10MB (Ethernet), capture size 68 bytes 10:35:32.557438 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp] 10:35:36.558022 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp] etc. dhcpd receives and acts on the requests but is unable to send replies: Jul 22 10:11:13 stealth dhcpd: DHCPDISCOVER from 00:1b:77:9d:ab:ba (jnielsengl1830) via wlan1 Jul 22 10:11:13 stealth dhcpd: DHCPOFFER on 192.168.103.240 to 00:1b:77:9d:ab:ba (jnielsengl1830) via wlan1 Jul 22 10:11:13 stealth dhcpd: send_packet: Network is down The problem seems to follow the second hostap device configured (e.g. wlan1). I swapped the networks and the insecure one worked propery and the "old" network stopped working. I'm trying to determine if this is a misconfiguration on my part, a software bug or a hardware limitation. I've tested with ipfw turned off via sysctl and with and without hidessid and bgscan on both interfaces. Details of my setup: FreeBSD stealth.jnielsen.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jul 21 03:24:10 EDT 2008 john@stealth.jnielsen.net:/usr/obj/usr/src8/src/sys/STEALTH i386 (D-Link DWL-G520 PCI card) ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xe5040000-0xe504ffff irq 16 at device 8.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 5.6 phy 4.1 radio 4.5 stealth# egrep "ath|wlan" /etc/rc.conf | grep -v "^#" wlans_ath0="wlan0 wlan1" create_args_wlan0="wlanmode hostap" create_args_wlan1="wlanmode hostap wlanaddr 10:0d:88:a6:61:a8" ifconfig_wlan0="inet 192.168.3.10 netmask 255.255.255.0 ssid sixten wepmode on deftxkey 1 wepkey 1:0x[26 digit hex key]" ifconfig_wlan1="inet 192.168.103.1 netmask 255.255.255.0 ssid freewifi wepmode off" stealth# ifconfig ath0 && ifconfig wlan0 && ifconfig wlan1 ath0: flags=8843 metric 0 mtu 2290 ether 00:0d:88:a6:61:a8 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running wlan0: flags=8843 metric 0 mtu 1500 ether 00:0d:88:a6:61:a8 inet 192.168.3.10 netmask 0xffffff00 broadcast 192.168.3.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid sixten channel 6 (2437 Mhz 11g) bssid 00:0d:88:a6:61:a8 regdomain FCC indoor ecm authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 19 scanvalid 60 protmode CTS wme burst ff dturbo dtimperiod 1 -dfs wlan1: flags=8c43 metric 0 mtu 1500 ether 10:0d:88:a6:61:a8 inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid freewifi channel 6 (2437 Mhz 11g) bssid 10:0d:88:a6:61:a8 regdomain FCC indoor ecm authmode OPEN privacy OFF txpower 19 scanvalid 60 protmode CTS wme burst ff dturbo dtimperiod 1 -dfs Any input greatly appreciated. Thanks! JN From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 15:28:33 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1860106568E for ; Tue, 22 Jul 2008 15:28:33 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDD28FC17 for ; Tue, 22 Jul 2008 15:28:33 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [172.17.2.20] (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6MFSVJP025402; Tue, 22 Jul 2008 11:28:32 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: current@freebsd.org, fs@freebsd.org Date: Tue, 22 Jul 2008 11:28:27 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807221128.27592.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:28:33 -0000 I have a FreeBSD server (which I use as a NAS device, among other things)=20 and a FreeBSD deskop. The desktop is running 7-STABLE from a couple days=20 ago and the server is running 8-CURRENT from yesterday. The server has=20 several NFS-exported ZFS'es which I mount from the desktop. Since moving=20 the shares to ZFS I've been having trouble writing to them from the=20 desktop--the mount hangs after the first or second attempt. This is=20 similar if not identical to what's described in the thread=20 (from -current) I partially copied below. Today I discovered that the problem seems to go away if I change the NFS=20 mount options on the desktop. The following is a summary/timeline of what=20 I've tried: 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; works 7-STABLE client, no NFS options (defaults); 7-STABLE server, ZFS; broken 7-STABLE client, no NFS options (defaults); 8-CURRENT server, ZFS; broken 7-STABLE client, tcp,nfsv3,-r32768,-w32768; 8-CURRENT server, ZFS, works My litmus test is to run fetch in the NFS directory a couple times since=20 in my typical usage the failure is most apparent when fetching distfiles=20 to the shared ports tree. I didn't do a thorough search but I don't see any open PR's about this=20 issue (though I remember the thread below and other discussions about the=20 same time). Should I submit one? Other than that I just wanted to report that 1) this is apparently (still)= =20 an issue and 2) the NFS flags above seem like a good workaround so far. Thanks, JN > Newsgroups: muc.lists.freebsd.current > From: d...@des.no (Dag-Erling Sm=F8rgrav) > Date: Sun, 07 Oct 2007 10:48:49 +0200 > Local: Sun, Oct 7 2007 4:48 am > Subject: Re: ZFS & NFS integration... >=20 > Darren Reed writes: > > Dag-Erling Sm=F8rgrav wrote: > > > Darren Reed writes: > > > > Whats the planned status for ZFS+NFS with 7.0? > > > Don't Do It, basically. > > This sounds like a "shoot yourself in the foot" comment. >=20 > > Why? >=20 > I haven't figured out the exact details yet, but apparently when the > client closes a file that was opened read / write, the server stops > responding to that client. >=20 > DES From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 15:30:29 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E041065781 for ; Tue, 22 Jul 2008 15:30:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3BE8FC1F for ; Tue, 22 Jul 2008 15:30:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6MFUQoY030960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 08:30:27 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4885FD12.1090408@freebsd.org> Date: Tue, 22 Jul 2008 08:30:26 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: John Nielsen References: <200807221048.48729.lists@jnielsen.net> In-Reply-To: <200807221048.48729.lists@jnielsen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: ath vap - second hostap _almost_ works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:30:29 -0000 John Nielsen wrote: > Sam et al- > > I just upgraded my "router" box to -CURRENT so I could try out the new vap > code. The upgrade went fine and the single access point setup I had > before works fine on wlan0. > > I'm trying to set up a second access point for an "insecure" network. I am > able to create and configure the wlan1 interface and clients can see the > SSID and associate to the network. However the access point is unable to > send traffic over the interface (the 103 network below): > > stealth# ping 192.168.103.240 > PING 192.168.103.240 (192.168.103.240): 56 data bytes > ping: sendto: Network is down > > Interestingly, it can receive traffic just fine. DHCP, for instance: > > stealth# tcpdump -i wlan1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on wlan1, link-type EN10MB (Ethernet), capture size 68 bytes > 10:35:32.557438 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request [|bootp] > 10:35:36.558022 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request [|bootp] > > etc. dhcpd receives and acts on the requests but is unable to send > replies: > > Jul 22 10:11:13 stealth dhcpd: DHCPDISCOVER from 00:1b:77:9d:ab:ba > (jnielsengl1830) via wlan1 > Jul 22 10:11:13 stealth dhcpd: DHCPOFFER on 192.168.103.240 to > 00:1b:77:9d:ab:ba (jnielsengl1830) via wlan1 > Jul 22 10:11:13 stealth dhcpd: send_packet: Network is down > > The problem seems to follow the second hostap device configured (e.g. > wlan1). I swapped the networks and the insecure one worked propery and > the "old" network stopped working. I'm trying to determine if this is a > misconfiguration on my part, a software bug or a hardware limitation. > I've tested with ipfw turned off via sysctl and with and without hidessid > and bgscan on both interfaces. Details of my setup: > > FreeBSD stealth.jnielsen.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jul > 21 03:24:10 EDT 2008 > john@stealth.jnielsen.net:/usr/obj/usr/src8/src/sys/STEALTH i386 > > (D-Link DWL-G520 PCI card) > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xe5040000-0xe504ffff irq 16 at device 8.0 on > pci0 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 5.6 phy 4.1 radio 4.5 > > stealth# egrep "ath|wlan" /etc/rc.conf | grep -v "^#" > wlans_ath0="wlan0 wlan1" > create_args_wlan0="wlanmode hostap" > create_args_wlan1="wlanmode hostap wlanaddr 10:0d:88:a6:61:a8" > FWIW, it's better to just use "wlanmode hostap bssid" to get a unique address. > ifconfig_wlan0="inet 192.168.3.10 netmask 255.255.255.0 ssid sixten > wepmode on deftxkey 1 wepkey 1:0x[26 digit hex key]" > ifconfig_wlan1="inet 192.168.103.1 netmask 255.255.255.0 ssid freewifi > wepmode off" > What happens if you disable WEP use? > stealth# ifconfig ath0 && ifconfig wlan0 && ifconfig wlan1 > ath0: flags=8843 metric 0 mtu 2290 > ether 00:0d:88:a6:61:a8 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > wlan0: flags=8843 metric 0 mtu > 1500 > ether 00:0d:88:a6:61:a8 > inet 192.168.3.10 netmask 0xffffff00 broadcast 192.168.3.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid sixten channel 6 (2437 Mhz 11g) bssid 00:0d:88:a6:61:a8 > regdomain FCC indoor ecm authmode OPEN privacy ON deftxkey 1 > wepkey 1:104-bit txpower 19 scanvalid 60 protmode CTS wme burst ff > dturbo dtimperiod 1 -dfs > wlan1: flags=8c43 metric 0 > mtu 1500 > ether 10:0d:88:a6:61:a8 > inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid freewifi channel 6 (2437 Mhz 11g) bssid 10:0d:88:a6:61:a8 > regdomain FCC indoor ecm authmode OPEN privacy OFF txpower 19 > scanvalid 60 protmode CTS wme burst ff dturbo dtimperiod 1 -dfs > > Any input greatly appreciated. Thanks! > > I'll need to setup this config as I don't think I've ever tested one like it (my vap's are typically bridged and don't terminate on the wireless host). You might check wlanstats of each vap to see if packets are being tossed. Otherwise you'll need to look at a lower level to find where the packets are being lost; e.g. use tcpdump -y IEEE802_11 on the wlan devices to see if the missing frames are being dispatched from the ath driver. If you can't find the reason please file a PR w/ the details you've provided. Sam From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 15:48:45 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93FC21065672; Tue, 22 Jul 2008 15:48:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDEE8FC23; Tue, 22 Jul 2008 15:48:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6MFmQZ5035128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 18:48:26 +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.14.2/8.14.2) with ESMTP id m6MFmPTe070783; Tue, 22 Jul 2008 18:48:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6MFmP88070782; Tue, 22 Jul 2008 18:48:25 +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, 22 Jul 2008 18:48:25 +0300 From: Kostik Belousov To: Andrew Gallatin , attilio@freebsd.org Message-ID: <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> References: <4884F992.7090008@cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bzpMzqNg2PA1wk8L" Content-Disposition: inline In-Reply-To: <4884F992.7090008@cs.duke.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:48:45 -0000 --bzpMzqNg2PA1wk8L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 05:03:14PM -0400, Andrew Gallatin wrote: > I can panic today's -current reliably (or hang it with > WITNESS/INVARIENTS disabled). When it crashes, I see > the appended panic messages. >=20 > It seems to be 100% reproducible on my box (AMD64 x2, > 512MB ram, UFS2). If anybody savvy in this area would > like to reproduce it, I've left the program at ~gallatin/ahunt.c > on freefall. Compile it, and run it as: > ./a.out -mmbfileinit -madvise=3D/var/tmp/zot -random -size=3D95536=20 > -touch=3D4096 -rewrite=3D2 >=20 >=20 > Cheers, >=20 > Drew >=20 > PS: Here is a serial console log from the panic: =2E.. > login: shared lock of (lockmgr) ufs @ kern/vfs_subr.c:2044 > while exclusively locked from kern/vfs_vnops.c:593 > panic: share->excl > cpuid =3D 1 > KDB: enter: panic > [thread pid 1702 tid 100149 ] > Stopped at kdb_enter+0x3d: movq $0,0x639958(%rip) > db> tr > Tracing pid 1702 tid 100149 td 0xffffff000d08f000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x176 > witness_checkorder() at witness_checkorder+0x137 > __lockmgr_args() at __lockmgr_args+0xc74 > ffs_lock() at ffs_lock+0x8c > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x7b > vnode_pager_lock() at vnode_pager_lock+0x146 > vm_fault() at vm_fault+0x1e2 > trap_pfault() at trap_pfault+0x128 > trap() at trap+0x395 > calltrap() at calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff8079f2bd, rsp =3D 0xfffffffe58c2f7b0, rbp= =3D=20 > 0xfffffffe58c2f830 --- > copyin() at copyin+0x3d > ffs_write() at ffs_write+0x2f8 > VOP_WRITE_APV() at VOP_WRITE_APV+0x10b > vn_write() at vn_write+0x23f > dofilewrite() at dofilewrite+0x85 > --More-- >=20 > kern_writev() at kern_writev+0x60 > write() at write+0x54 > syscall() at syscall+0x1dd > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (4, FreeBSD ELF64, write), rip =3D 0x8007296ec, rsp =3D=20 > 0x7fffffffe158, rbp =3D 0x7fffffffe210 --- > db> show locks > exclusive sleep mutex vnode interlock r =3D 0 (0xffffff000d0dc0c0) locked= =20 > @ vm/vnode_pager.c:1199 > exclusive sx user map r =3D 0 (0xffffff000d054360) locked @ vm/vm_map.c:3= 115 > exclusive lockmgr bufwait r =3D 0 (0xfffffffe5047f278) locked @=20 > kern/vfs_bio.c:1783 > exclusive lockmgr ufs r =3D 0 (0xffffff000d0dc098) locked @=20 > kern/vfs_vnops.c:593 > db> Essentially, you tried to do the write of the part of the region mmaped from the file, to the file. The VOP_WRITE() is called with exclusively locked vnode, while fault handler tried to lock the vnode in shared mode to page in. The following change fixed it for me. Attilio, would it make sense to consider LK_CANRECURSE | LK_SHARED as a request for the exlusive lock when the current thread already hold the exclusive lock instead ? I think this would be a proper solution. diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c index 4758456..61f4fd9 100644 --- a/sys/vm/vnode_pager.c +++ b/sys/vm/vnode_pager.c @@ -1179,6 +1179,7 @@ vnode_pager_lock(vm_object_t first_object) { struct vnode *vp; vm_object_t backing_object, object; + int locked, lockf; =20 VM_OBJECT_LOCK_ASSERT(first_object, MA_OWNED); for (object =3D first_object; object !=3D NULL; object =3D backing_object= ) { @@ -1196,13 +1197,19 @@ vnode_pager_lock(vm_object_t first_object) return NULL; } vp =3D object->handle; + locked =3D VOP_ISLOCKED(vp); VI_LOCK(vp); VM_OBJECT_UNLOCK(object); if (first_object !=3D object) VM_OBJECT_UNLOCK(first_object); VFS_ASSERT_GIANT(vp->v_mount); - if (vget(vp, LK_CANRECURSE | LK_INTERLOCK | - LK_RETRY | LK_SHARED, curthread)) { + if (locked =3D=3D LK_EXCLUSIVE) + lockf =3D LK_CANRECURSE | LK_INTERLOCK | LK_RETRY | + LK_EXCLUSIVE; + else + lockf =3D LK_CANRECURSE | LK_INTERLOCK | LK_RETRY | + LK_SHARED; + if (vget(vp, lockf, curthread)) { VM_OBJECT_LOCK(first_object); if (object !=3D first_object) VM_OBJECT_LOCK(object); --bzpMzqNg2PA1wk8L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiGAUgACgkQC3+MBN1Mb4i8cwCcChw4RDWDWsAeNfYcuMnVVW77 zNAAoLfLXmVxqMbNU/A2qPrxQeRtvr3C =Qp8H -----END PGP SIGNATURE----- --bzpMzqNg2PA1wk8L-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 16:45:17 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33F231065676; Tue, 22 Jul 2008 16:45:17 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 1208D8FC19; Tue, 22 Jul 2008 16:45:16 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [172.17.2.20] (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6MGWXJP071467; Tue, 22 Jul 2008 12:32:34 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Tue, 22 Jul 2008 12:32:29 -0400 User-Agent: KMail/1.9.7 References: <200807221048.48729.lists@jnielsen.net> <4885FD12.1090408@freebsd.org> In-Reply-To: <4885FD12.1090408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807221232.29323.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Sam Leffler Subject: Re: ath vap - second hostap _almost_ works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 16:45:17 -0000 On Tuesday 22 July 2008 11:30:26 am Sam Leffler wrote: > John Nielsen wrote: > > I'm trying to set up a second access point for an "insecure" network. > > I am able to create and configure the wlan1 interface and clients can > > see the SSID and associate to the network. However the access point > > is unable to send traffic over the interface (the 103 network below): > > > > stealth# egrep "ath|wlan" /etc/rc.conf | grep -v "^#" > > wlans_ath0="wlan0 wlan1" > > create_args_wlan0="wlanmode hostap" > > create_args_wlan1="wlanmode hostap wlanaddr 10:0d:88:a6:61:a8" > > FWIW, it's better to just use "wlanmode hostap bssid" to get a unique > address. Thanks. That's cleaner but no functional difference (as expected). > > ifconfig_wlan0="inet 192.168.3.10 netmask 255.255.255.0 ssid sixten > > wepmode on deftxkey 1 wepkey 1:0x[26 digit hex key]" > > ifconfig_wlan1="inet 192.168.103.1 netmask 255.255.255.0 ssid > > freewifi wepmode off" > > What happens if you disable WEP use? Same result. The wlan0 network is able to send/receive traffic, the wlan1 one is able to receive only. > I'll need to setup this config as I don't think I've ever tested one > like it (my vap's are typically bridged and don't terminate on the > wireless host). I played w/ bridging when I first set this up but decided to go this way to avoid broadcast issues, link speed and MTU differences, etc. And in the case of the insecure wireless network the whole point is to keep it separate from other segments. :) > You might check wlanstats of each vap to see if > packets are being tossed. Nothing stands out to me but this is the first time I've run it: %wlanstats 1 rx from wrong bssid 8 rx discard 'cuz dup 6 rx w/ wrong direction 6 rx ctrl frames 1791 rx beacon frames 2905 rx element unknown 130 rx frame ssid mismatch 1 rx deauthentication 1 active scans started 6 ps-poll received with nothing to send 1971 rx management frames 272 total data frames transmit 272 multicast data frames sent 0M current transmit rate > Otherwise you'll need to look at a lower > level to find where the packets are being lost; e.g. use tcpdump -y > IEEE802_11 on the wlan devices to see if the missing frames are being > dispatched from the ath driver. I never knew how chatty my neighbors' access points were! :) Again though I see the DHCP requests from the client but no replies. I don't know enough about the protocol stack to do much theorizing, but I'm not convinced that the packets are going far enough down the stack to even hit the hardware. What I'm seeing looks exactly like what I see on an OpenVPN TAP interface when the interface is up but the VPN link is down. Anyone have any ideas on how I could dig in to this further? > If you can't find the reason please file a PR w/ the details you've > provided. I'll do that. Thanks! JN From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 16:54:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397A61065674 for ; Tue, 22 Jul 2008 16:54:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id B7DCF8FC13 for ; Tue, 22 Jul 2008 16:54:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1210696fgb.35 for ; Tue, 22 Jul 2008 09:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6MGYw+sp7g2lMq/6fbiyh0RYJyXNCh8NtQ3p+w2Ozr0=; b=gEmOIGtEFICUkNHHpl9ygJ/kEiuybVZn64OUiXVr7zCkhDgvw5tYQjsjvwYng15JYc N747BMa++Lns2N/P7siCEra+L82ls0Gvj6ce7+ivlqjM9pKzU1oKA9XcYqLqUmnSqYlQ 5kfIERN83HxfYeJqaUUaSTeLddOcjq/61YEyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=UDovx5yTS20u5PMvbNOSg+ITBMSFBYXGFVCXKPwSL5wlM+SplaOXjH9HSiyPKSTzAm 4XB+PUXkr17f7imWYR6De+qASRUEX3BL5qIRn+HDUaEtlZOyytieTHUfopO0A7nEtLUl cXu/CVchJrYwQDqX6frOr9PCJPjDjNXcQBcLw= Received: by 10.86.77.5 with SMTP id z5mr6583749fga.10.1216745644357; Tue, 22 Jul 2008 09:54:04 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Tue, 22 Jul 2008 09:54:04 -0700 (PDT) Message-ID: <3bbf2fe10807220954q60ee6747x40076e39884daf19@mail.gmail.com> Date: Tue, 22 Jul 2008 18:54:04 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kostik Belousov" In-Reply-To: <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4884F992.7090008@cs.duke.edu> <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> X-Google-Sender-Auth: e252689620ad329d Cc: freebsd-current@freebsd.org, Andrew Gallatin Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 16:54:06 -0000 2008/7/22, Kostik Belousov : > On Mon, Jul 21, 2008 at 05:03:14PM -0400, Andrew Gallatin wrote: > > I can panic today's -current reliably (or hang it with > > WITNESS/INVARIENTS disabled). When it crashes, I see > > the appended panic messages. > > > > It seems to be 100% reproducible on my box (AMD64 x2, > > 512MB ram, UFS2). If anybody savvy in this area would > > like to reproduce it, I've left the program at ~gallatin/ahunt.c > > on freefall. Compile it, and run it as: > > ./a.out -mmbfileinit -madvise=/var/tmp/zot -random -size=95536 > > -touch=4096 -rewrite=2 > > > > > > Cheers, > > > > Drew > > > > PS: Here is a serial console log from the panic: > > ... > > > > login: shared lock of (lockmgr) ufs @ kern/vfs_subr.c:2044 > > while exclusively locked from kern/vfs_vnops.c:593 > > panic: share->excl > > cpuid = 1 > > KDB: enter: panic > > [thread pid 1702 tid 100149 ] > > Stopped at kdb_enter+0x3d: movq $0,0x639958(%rip) > > db> tr > > Tracing pid 1702 tid 100149 td 0xffffff000d08f000 > > kdb_enter() at kdb_enter+0x3d > > panic() at panic+0x176 > > witness_checkorder() at witness_checkorder+0x137 > > __lockmgr_args() at __lockmgr_args+0xc74 > > ffs_lock() at ffs_lock+0x8c > > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > > _vn_lock() at _vn_lock+0x47 > > vget() at vget+0x7b > > vnode_pager_lock() at vnode_pager_lock+0x146 > > vm_fault() at vm_fault+0x1e2 > > trap_pfault() at trap_pfault+0x128 > > trap() at trap+0x395 > > calltrap() at calltrap+0x8 > > --- trap 0xc, rip = 0xffffffff8079f2bd, rsp = 0xfffffffe58c2f7b0, rbp = > > 0xfffffffe58c2f830 --- > > copyin() at copyin+0x3d > > ffs_write() at ffs_write+0x2f8 > > VOP_WRITE_APV() at VOP_WRITE_APV+0x10b > > vn_write() at vn_write+0x23f > > dofilewrite() at dofilewrite+0x85 > > --More-- > > > > kern_writev() at kern_writev+0x60 > > write() at write+0x54 > > syscall() at syscall+0x1dd > > Xfast_syscall() at Xfast_syscall+0xab > > --- syscall (4, FreeBSD ELF64, write), rip = 0x8007296ec, rsp = > > 0x7fffffffe158, rbp = 0x7fffffffe210 --- > > db> show locks > > exclusive sleep mutex vnode interlock r = 0 (0xffffff000d0dc0c0) locked > > @ vm/vnode_pager.c:1199 > > exclusive sx user map r = 0 (0xffffff000d054360) locked @ vm/vm_map.c:3115 > > exclusive lockmgr bufwait r = 0 (0xfffffffe5047f278) locked @ > > kern/vfs_bio.c:1783 > > exclusive lockmgr ufs r = 0 (0xffffff000d0dc098) locked @ > > kern/vfs_vnops.c:593 > > db> > > > Essentially, you tried to do the write of the part of the region mmaped > from the file, to the file. The VOP_WRITE() is called with exclusively > locked vnode, while fault handler tried to lock the vnode in shared mode > to page in. > > The following change fixed it for me. > Attilio, would it make sense to consider LK_CANRECURSE | LK_SHARED as > a request for the exlusive lock when the current thread already hold the > exclusive lock instead ? I think this would be a proper solution. I don't like this kind of magics and ecoding in lockmgr. I think that the better thing to do here is to recurse the exclusive lock as you pass to vget(). Also note that without WITNESS the code will return EDEADLK in this case while traditionally what would have happened is that the lockmgr would have to be downgraded silently, but as you can expect this is a very dangerous practice. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:05:47 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5111065679; Tue, 22 Jul 2008 17:05:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1277D8FC1C; Tue, 22 Jul 2008 17:05:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6MH5e9w039284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 20:05:40 +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.14.2/8.14.2) with ESMTP id m6MH5eql072712; Tue, 22 Jul 2008 20:05:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6MH5eOo072711; Tue, 22 Jul 2008 20:05:40 +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, 22 Jul 2008 20:05:40 +0300 From: Kostik Belousov To: Attilio Rao Message-ID: <20080722170540.GA17123@deviant.kiev.zoral.com.ua> References: <4884F992.7090008@cs.duke.edu> <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> <3bbf2fe10807220954q60ee6747x40076e39884daf19@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g3+pAoj2zJcoLeOT" Content-Disposition: inline In-Reply-To: <3bbf2fe10807220954q60ee6747x40076e39884daf19@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Andrew Gallatin Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:05:47 -0000 --g3+pAoj2zJcoLeOT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 06:54:04PM +0200, Attilio Rao wrote: > 2008/7/22, Kostik Belousov : > > On Mon, Jul 21, 2008 at 05:03:14PM -0400, Andrew Gallatin wrote: > > > I can panic today's -current reliably (or hang it with > > > WITNESS/INVARIENTS disabled). When it crashes, I see > > > the appended panic messages. > > > > > > It seems to be 100% reproducible on my box (AMD64 x2, > > > 512MB ram, UFS2). If anybody savvy in this area would > > > like to reproduce it, I've left the program at ~gallatin/ahunt.c > > > on freefall. Compile it, and run it as: > > > ./a.out -mmbfileinit -madvise=3D/var/tmp/zot -random -size=3D95536 > > > -touch=3D4096 -rewrite=3D2 > > > > > > > > > Cheers, > > > > > > Drew > > > > > > PS: Here is a serial console log from the panic: > > > > ... > > > > > > > login: shared lock of (lockmgr) ufs @ kern/vfs_subr.c:2044 > > > while exclusively locked from kern/vfs_vnops.c:593 > > > panic: share->excl > > > cpuid =3D 1 > > > KDB: enter: panic > > > [thread pid 1702 tid 100149 ] > > > Stopped at kdb_enter+0x3d: movq $0,0x639958(%rip) > > > db> tr > > > Tracing pid 1702 tid 100149 td 0xffffff000d08f000 > > > kdb_enter() at kdb_enter+0x3d > > > panic() at panic+0x176 > > > witness_checkorder() at witness_checkorder+0x137 > > > __lockmgr_args() at __lockmgr_args+0xc74 > > > ffs_lock() at ffs_lock+0x8c > > > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > > > _vn_lock() at _vn_lock+0x47 > > > vget() at vget+0x7b > > > vnode_pager_lock() at vnode_pager_lock+0x146 > > > vm_fault() at vm_fault+0x1e2 > > > trap_pfault() at trap_pfault+0x128 > > > trap() at trap+0x395 > > > calltrap() at calltrap+0x8 > > > --- trap 0xc, rip =3D 0xffffffff8079f2bd, rsp =3D 0xfffffffe58c2f7b0= , rbp =3D > > > 0xfffffffe58c2f830 --- > > > copyin() at copyin+0x3d > > > ffs_write() at ffs_write+0x2f8 > > > VOP_WRITE_APV() at VOP_WRITE_APV+0x10b > > > vn_write() at vn_write+0x23f > > > dofilewrite() at dofilewrite+0x85 > > > --More-- > > > > > > kern_writev() at kern_writev+0x60 > > > write() at write+0x54 > > > syscall() at syscall+0x1dd > > > Xfast_syscall() at Xfast_syscall+0xab > > > --- syscall (4, FreeBSD ELF64, write), rip =3D 0x8007296ec, rsp =3D > > > 0x7fffffffe158, rbp =3D 0x7fffffffe210 --- > > > db> show locks > > > exclusive sleep mutex vnode interlock r =3D 0 (0xffffff000d0dc0c0) l= ocked > > > @ vm/vnode_pager.c:1199 > > > exclusive sx user map r =3D 0 (0xffffff000d054360) locked @ vm/vm_ma= p.c:3115 > > > exclusive lockmgr bufwait r =3D 0 (0xfffffffe5047f278) locked @ > > > kern/vfs_bio.c:1783 > > > exclusive lockmgr ufs r =3D 0 (0xffffff000d0dc098) locked @ > > > kern/vfs_vnops.c:593 > > > db> > > > > > > Essentially, you tried to do the write of the part of the region mmaped > > from the file, to the file. The VOP_WRITE() is called with exclusively > > locked vnode, while fault handler tried to lock the vnode in shared mo= de > > to page in. > > > > The following change fixed it for me. > > Attilio, would it make sense to consider LK_CANRECURSE | LK_SHARED as > > a request for the exlusive lock when the current thread already hold t= he > > exclusive lock instead ? I think this would be a proper solution. >=20 > I don't like this kind of magics and ecoding in lockmgr. > I think that the better thing to do here is to recurse the exclusive > lock as you pass to vget(). It could be argued that lockmgr is a black magic in whole. On the other hand, I had to use VOP_ISLOCKED() and manually construct lock request while all needed information is at hands inside the lockmgr. Moreover, I believe that doing implicit shared->exclusive request upgrade in this situation (excl locked by curthread, LK_CANRECURSE present) is right. >=20 > Also note that without WITNESS the code will return EDEADLK in this > case while traditionally what would have happened is that the lockmgr > would have to be downgraded silently, but as you can expect this is a > very dangerous practice. Fully agree. --g3+pAoj2zJcoLeOT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiGE2MACgkQC3+MBN1Mb4hygACeOSgFz4Qct1+dMcxRetwJJIIc gGYAn2O5wMApwEFRPhVDGoI1NeHsCHlx =du+u -----END PGP SIGNATURE----- --g3+pAoj2zJcoLeOT-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:10:59 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74B30106581E; Tue, 22 Jul 2008 17:10:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB538FC1B; Tue, 22 Jul 2008 17:10:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MHAuxo015847; Tue, 22 Jul 2008 13:10:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6MHAuSR048997; Tue, 22 Jul 2008 13:10:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2072073039; Tue, 22 Jul 2008 13:10:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080722171055.2072073039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 13:10:54 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:10:59 -0000 TB --- 2008-07-22 17:10:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-22 17:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-07-22 17:10:00 - cleaning the object tree TB --- 2008-07-22 17:10:48 - cvsupping the source tree TB --- 2008-07-22 17:10:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-07-22 17:10:54 - building world (CFLAGS=-O -pipe) TB --- 2008-07-22 17:10:54 - cd /src TB --- 2008-07-22 17:10:54 - /usr/bin/make -B buildworld TB --- 2008-07-22 17:10:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-22 17:10:54 - ERROR: failed to build world TB --- 2008-07-22 17:10:54 - tinderbox aborted TB --- 2.41 user 4.54 system 54.11 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:15:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E809106564A; Tue, 22 Jul 2008 17:15:20 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 069F78FC22; Tue, 22 Jul 2008 17:15:19 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id m6MHFIBR019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 13:15:18 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu m6MHFIBR019092 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1216746918; bh=MIF3XvuZXzL9d9npbpqIrV7vShO2AEsd4ebx5qAwQ6s=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=I/c48NUUJ9/J HqVsdOeouIo+f7pHW6VP38jDN3MRjN8pn09UoA+osjopXCRXNGJNdI+xUqCrUY9FFev 5nh5kDS/D1S9dMnHfWzkB/SmmLeaTknGsRtx/8HY4+Ybln3/0pVHHaItYpcgI51c3WL 1hT5Xn+HrftMae146bk0gcBFU= Message-ID: <488615A0.7030106@cs.duke.edu> Date: Tue, 22 Jul 2008 13:15:12 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Kostik Belousov References: <4884F992.7090008@cs.duke.edu> <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:15:20 -0000 Kostik Belousov wrote: > Essentially, you tried to do the write of the part of the region mmaped > from the file, to the file. The VOP_WRITE() is called with exclusively > locked vnode, while fault handler tried to lock the vnode in shared mode > to page in. Yes, the operations attempted were rather nonsensical, but should not have killed the system. Thank you for looking into it. Drew From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 17:43:59 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787DF106564A for ; Tue, 22 Jul 2008 17:43:59 +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 34C6F8FC1E for ; Tue, 22 Jul 2008 17:43:58 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E8732208E; Tue, 22 Jul 2008 19:43:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD Tinderbox References: <20080722171055.2072073039@freebsd-current.sentex.ca> Date: Tue, 22 Jul 2008 19:43:56 +0200 In-Reply-To: <20080722171055.2072073039@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Tue\, 22 Jul 2008 13\:10\:54 -0400 \(EDT\)") Message-ID: <86ljztolur.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:43:59 -0000 FreeBSD Tinderbox writes: > TB --- 2008-07-22 17:10:00 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2008-07-22 17:10:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2008-07-22 17:10:00 - cleaning the object tree > TB --- 2008-07-22 17:10:48 - cvsupping the source tree > TB --- 2008-07-22 17:10:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /= tinderbox/HEAD/amd64/amd64/supfile > TB --- 2008-07-22 17:10:54 - building world (CFLAGS=3D-O -pipe) > TB --- 2008-07-22 17:10:54 - cd /src > TB --- 2008-07-22 17:10:54 - /usr/bin/make -B buildworld > TB --- 2008-07-22 17:10:54 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2008-07-22 17:10:54 - ERROR: failed to build world > TB --- 2008-07-22 17:10:54 - tinderbox aborted > TB --- 2.41 user 4.54 system 54.11 real src/Makefile contains the following code: STARTTIME!=3D LC_ALL=3DC date CHECK_TIME!=3D find ${.CURDIR}/sys/sys/param.h -mtime -0 .if !empty(CHECK_TIME) .error check your date/time: ${STARTTIME} .endif This causes the build to fail if 'make' is invoked within the same second that sys/sys/param.h was updated, as happened here: TB --- 2008-07-22 17:10:48 - cvsupping the source tree TB --- 2008-07-22 17:10:48 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /ti= nderbox/HEAD/amd64/amd64/supfile Connected to 127.0.0.1 Updating collection src-all/cvs Edit src/games/fortune/datfiles/fortunes Edit src/include/stdlib.h Edit src/lib/libc/gen/Makefile.inc Edit src/lib/libc/gen/Symbol.map Edit src/lib/libc/gen/arc4random.3 Edit src/lib/libc/gen/arc4random.c Edit src/lib/libc/stdio/mktemp.c Edit src/share/misc/committers-src.dot Edit src/sys/arm/at91/at91_pmc.c Edit src/sys/dev/esp/esp_sbus.c Edit src/sys/dev/esp/ncr53c9x.c Edit src/sys/dev/esp/ncr53c9xvar.h Edit src/sys/libkern/arc4random.c Edit src/sys/security/audit/audit.c Edit src/sys/security/audit/audit.h Edit src/sys/security/audit/audit_arg.c Edit src/sys/security/audit/audit_bsm.c Edit src/sys/security/audit/audit_bsm_klib.c Edit src/sys/security/audit/audit_bsm_token.c Edit src/sys/security/audit/audit_private.h Edit src/sys/security/audit/audit_syscalls.c Edit src/sys/security/audit/audit_worker.c Edit src/sys/sys/param.h Finished successfully TB --- 2008-07-22 17:10:54 - building world (CFLAGS=3D-O -pipe) TB --- 2008-07-22 17:10:54 - cd /src TB --- 2008-07-22 17:10:54 - /usr/bin/make -B buildworld "Makefile", line 177: check your date/time: Tue Jul 22 17:10:54 UTC 2008 TB --- 2008-07-22 17:10:54 - WARNING: /usr/bin/make returned exit code 1=20 TB --- 2008-07-22 17:10:54 - ERROR: failed to build world DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 19:19:35 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F51E1065678; Tue, 22 Jul 2008 19:19:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id E0E848FC1F; Tue, 22 Jul 2008 19:19:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6MJJSNi047443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 22:19:28 +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.14.2/8.14.2) with ESMTP id m6MJJS4t075190; Tue, 22 Jul 2008 22:19:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6MJJRAo075189; Tue, 22 Jul 2008 22:19:27 +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, 22 Jul 2008 22:19:27 +0300 From: Kostik Belousov To: Andrew Gallatin Message-ID: <20080722191927.GB17123@deviant.kiev.zoral.com.ua> References: <4884F992.7090008@cs.duke.edu> <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> <488615A0.7030106@cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zDIj/tilPJu/aAeA" Content-Disposition: inline In-Reply-To: <488615A0.7030106@cs.duke.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 19:19:35 -0000 --zDIj/tilPJu/aAeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 01:15:12PM -0400, Andrew Gallatin wrote: > Kostik Belousov wrote: >=20 > >Essentially, you tried to do the write of the part of the region mmaped > >from the file, to the file. The VOP_WRITE() is called with exclusively > >locked vnode, while fault handler tried to lock the vnode in shared mode > >to page in. >=20 > Yes, the operations attempted were rather nonsensical, but should > not have killed the system. Thank you for looking into it. Why nonsensical ? The operations are legitimate, and kernel must not panic. The question still open is whether the patch fixed the issue for you. --zDIj/tilPJu/aAeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiGMr8ACgkQC3+MBN1Mb4gJJgCgwNGngTSiw12YAscXzoiHD/0E HAEAoI4+GvjALZFS8Rj/EUhrX+h4A8Rm =rrbl -----END PGP SIGNATURE----- --zDIj/tilPJu/aAeA-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 19:51:00 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E68F10656A4; Tue, 22 Jul 2008 19:51:00 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 496798FC1F; Tue, 22 Jul 2008 19:51:00 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id m6MJoxiv000834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 15:50:59 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu m6MJoxiv000834 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1216756259; bh=Fi3byXqcbMRGMi96LWN5zjGrz6Aq7nTi19NYk7cQa2c=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EzjxiRmLYzto TT7a7Q0K0OJaYhqfGDlzof01olkz9nhUPd6xqQG+jvCtksyiaXZUw79tKkAE8EyFKs2 h23LvfqMsKdkTfMxMr4/wGYAZmh5SkbenXn4pXciFicAXU8zhHG4CtieIZjduD71DqF L0Kn7qOP4yudiBMw0NOAbLfsc= Message-ID: <48863A1B.6030808@cs.duke.edu> Date: Tue, 22 Jul 2008 15:50:51 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Kostik Belousov References: <4884F992.7090008@cs.duke.edu> <20080722154825.GZ17123@deviant.kiev.zoral.com.ua> <488615A0.7030106@cs.duke.edu> <20080722191927.GB17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080722191927.GB17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible "panic: share->excl" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 19:51:00 -0000 Kostik Belousov wrote: > On Tue, Jul 22, 2008 at 01:15:12PM -0400, Andrew Gallatin wrote: >> Kostik Belousov wrote: >> >>> Essentially, you tried to do the write of the part of the region mmaped >> >from the file, to the file. The VOP_WRITE() is called with exclusively >>> locked vnode, while fault handler tried to lock the vnode in shared mode >>> to page in. >> Yes, the operations attempted were rather nonsensical, but should >> not have killed the system. Thank you for looking into it. > > Why nonsensical ? The operations are legitimate, and kernel must not panic. > > The question still open is whether the patch fixed the issue for you. Yes, the patch fixes the panic. Thank you, Drew From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 22:59:58 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 399F51065685 for ; Tue, 22 Jul 2008 22:59:58 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2F98FC1A for ; Tue, 22 Jul 2008 22:59:58 +0000 (UTC) (envelope-from mgowda82@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2515417rvf.43 for ; Tue, 22 Jul 2008 15:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=QdeaHj0IEEIPW7GgWs4KYMDJNOSNzJ727hABkTbfoII=; b=aqZRN0zWUwqkclpo7W3/83t2SXQcEmN391r4/gFr4av9QPm0zoSw/iUGFBLXyVkZYs M99upS6YEUfxxYVVjGntS/ujJKA45XFaZBgfi0T6YqA3oAwKlxMj50bduaES8+erbDN0 F0lE2rsDZid4KJNTKNR/z+thRbkGUDTPdGG4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=dm60emGAcNtQNnq+11TfTiU6dI8oho/sXSTCQTULt9cnKN8Q4aeIhoIeV4v49UYUwc enbk/USLYlwmbSWI7zX1cO4zkBAoA4AVfgzF4rIWQ7DeMQoR2+9X415jaP562p+Lj/1p RemqzE1sLn6GkulzRyPbXMehlvnBZeiNDpAp8= Received: by 10.140.133.9 with SMTP id g9mr184840rvd.235.1216766111395; Tue, 22 Jul 2008 15:35:11 -0700 (PDT) Received: by 10.141.145.12 with HTTP; Tue, 22 Jul 2008 15:35:10 -0700 (PDT) Message-ID: Date: Tue, 22 Jul 2008 15:35:10 -0700 From: "Manjunath Ranganathaiah" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: setting memory size with hw.physmem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 22:59:58 -0000 On of my system with 8G of RAM running 7.0R amd64, dmesg shows memory usage as: usable memory = 8576397312 (8179 MB) avail memory = 8289071104 (7905 MB) If I set hw.physmem tunable to 8g, dmesg shows the following usable memory = 7771095040 (7411 MB) avail memory = 7507386368 (7159 MB) If I set hw.physmem to 8950M usable memory = 8565911552 (8169 MB) avail memory = 8278892544 (7895 MB) if I set hw.physmem to 8999M usable memory = 8576397312 (8179 MB) avail memory = 8289071104 (7905 MB) Is this expected behavior? How do I increase or decrease physical memory size by 1MB? Thanks, -Manjunath From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 04:15:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE00106567A for ; Wed, 23 Jul 2008 04:15:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9C38FC12 for ; Wed, 23 Jul 2008 04:15:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so844532ywe.13 for ; Tue, 22 Jul 2008 21:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:message-id :date:subject:from:to:user-agent:mime-version:content-type :content-transfer-encoding:x-priority:importance:sender; bh=r0hcEZFK/IGiQSet25Ps/iXMBzQt2BQrK3guUoiIwHQ=; b=iuDCz7STN2GXyAUzZC6zTkDv/enra9J/0hkpOFxL2Skl9nl0XIM3eD64H6FQV/tLza Ru7HbIl42+5DoHRnyqEeydmR7LA+tydeVCYD3e8tFnEsjfabPht3POCSYthKOrgYMc7V mfFi35RGTIe9+g2RvwpoS+snOlKetle0wL/r8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance:sender; b=hVjMZEkQLoWq0+C19rKtr/U+El7bF8/OYNdK/ytPS+f7lhkabQaoK6yUaVKsB7LloC BPynTNV80k1DADhaw05MM2qJ/JwcT0S+qhRXCLAYbTXoM3fNDF+nSQu6BX3zu8Kf/n1d QSyVFeWfO6yjozzAPvXE0JP2U/MGEd0y9PUFE= Received: by 10.150.91.17 with SMTP id o17mr6474499ybb.222.1216784876075; Tue, 22 Jul 2008 20:47:56 -0700 (PDT) Received: from cygnus.homeunix.com ( [189.71.51.242]) by mx.google.com with ESMTPS id 6sm1393630ywp.3.2008.07.22.20.47.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jul 2008 20:47:55 -0700 (PDT) Received: by cygnus.homeunix.com (Postfix, from userid 80) id 1B526EB; Wed, 23 Jul 2008 00:47:50 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus@eternamente.info) by cygnus with HTTP; Wed, 23 Jul 2008 00:47:49 -0300 (BRT) Message-ID: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> Date: Wed, 23 Jul 2008 00:47:49 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: Nenhum_de_Nos Subject: Linuxulator64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 04:15:55 -0000 hail, I've read some time about this and as this is something that I really look forward to seeing in freebsd, I came to ask how is the state of this feature now. when I'm able to run 64 bits linux bins from inside freebsd I can switch to breebsd in this box and begin testing this if necessary :) thanks in advance, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 05:05:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24F42106564A for ; Wed, 23 Jul 2008 05:05:33 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id DCBCD8FC16 for ; Wed, 23 Jul 2008 05:05:32 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from sp34.ipt.ru ([194.62.233.107] helo=bs1.sp34.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1KLWXb-000Drv-AV; Wed, 23 Jul 2008 09:05:31 +0400 Received: from bsam by bs1.sp34.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLWZR-0000SF-AP; Wed, 23 Jul 2008 09:07:25 +0400 To: "Nenhum_de_Nos" References: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> From: Boris Samorodov Date: Wed, 23 Jul 2008 09:07:25 +0400 In-Reply-To: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> (Nenhum de Nos's message of "Wed\, 23 Jul 2008 00\:47\:49 -0300 \(BRT\)") Message-ID: <16090834@bs1.sp34.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 05:05:33 -0000 On Wed, 23 Jul 2008 00:47:49 -0300 (BRT) Nenhum_de_Nos wrote: > I've read some time about this and as this is something that I really look > forward to seeing in freebsd, I came to ask how is the state of this > feature now. when I'm able to run 64 bits linux bins from inside freebsd I > can switch to breebsd in this box and begin testing this if necessary :) Work is in progress. More info one may find at (recent) emulation@ ML. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 08:24:06 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFA921065675 for ; Wed, 23 Jul 2008 08:24:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 193218FC15 for ; Wed, 23 Jul 2008 08:24:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id CB36045CA0; Wed, 23 Jul 2008 10:24:03 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C2A69456B1; Wed, 23 Jul 2008 10:23:55 +0200 (CEST) Date: Wed, 23 Jul 2008 10:24:01 +0200 From: Pawel Jakub Dawidek To: John Nielsen Message-ID: <20080723082401.GC3603@garage.freebsd.pl> References: <200807221128.27592.lists@jnielsen.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline In-Reply-To: <200807221128.27592.lists@jnielsen.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org, fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 08:24:06 -0000 --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 11:28:27AM -0400, John Nielsen wrote: > I have a FreeBSD server (which I use as a NAS device, among other things)= =20 > and a FreeBSD deskop. The desktop is running 7-STABLE from a couple days= =20 > ago and the server is running 8-CURRENT from yesterday. The server has=20 > several NFS-exported ZFS'es which I mount from the desktop. Since moving= =20 > the shares to ZFS I've been having trouble writing to them from the=20 > desktop--the mount hangs after the first or second attempt. This is=20 > similar if not identical to what's described in the thread=20 > (from -current) I partially copied below. >=20 > Today I discovered that the problem seems to go away if I change the NFS= =20 > mount options on the desktop. The following is a summary/timeline of what= =20 > I've tried: >=20 > 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; works > 7-STABLE client, no NFS options (defaults); 7-STABLE server, ZFS; broken > 7-STABLE client, no NFS options (defaults); 8-CURRENT server, ZFS; broken > 7-STABLE client, tcp,nfsv3,-r32768,-w32768; 8-CURRENT server, ZFS, works Do you need all the options here? If not, could you try to find the smallest subset of options that are needed to make ZFS work? Maybe 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use many NFS exported ZFS file systems, mostly accessed from MacOS X and we see no problems. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rQ2U398070+RC21q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhuqeForvXbEpPzQRAs4EAKDGY1A+IgVfv39uNEejIE+EsWBmiQCgqTkh WFx1jU696o+AKZJyf1jKD1U= =0PAa -----END PGP SIGNATURE----- --rQ2U398070+RC21q-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 09:05:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286E6106566C; Wed, 23 Jul 2008 09:05:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6F0658FC15; Wed, 23 Jul 2008 09:05:01 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6N94wr8048538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2008 11:04:59 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6N94q1h087198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 11:04:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6N94qNX064591; Wed, 23 Jul 2008 11:04:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6N94pvX064590; Wed, 23 Jul 2008 11:04:51 +0200 (CEST) (envelope-from ticso) Date: Wed, 23 Jul 2008 11:04:51 +0200 From: Bernd Walter To: Pawel Jakub Dawidek Message-ID: <20080723090450.GV58113@cicely7.cicely.de> References: <200807221128.27592.lists@jnielsen.net> <20080723082401.GC3603@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080723082401.GC3603@garage.freebsd.pl> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.141, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: John Nielsen , current@freebsd.org, fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 09:05:02 -0000 On Wed, Jul 23, 2008 at 10:24:01AM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jul 22, 2008 at 11:28:27AM -0400, John Nielsen wrote: > > I have a FreeBSD server (which I use as a NAS device, among other things) > > and a FreeBSD deskop. The desktop is running 7-STABLE from a couple days > > ago and the server is running 8-CURRENT from yesterday. The server has > > several NFS-exported ZFS'es which I mount from the desktop. Since moving > > the shares to ZFS I've been having trouble writing to them from the > > desktop--the mount hangs after the first or second attempt. This is > > similar if not identical to what's described in the thread > > (from -current) I partially copied below. > > > > Today I discovered that the problem seems to go away if I change the NFS > > mount options on the desktop. The following is a summary/timeline of what > > I've tried: > > > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; works > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, ZFS; broken > > 7-STABLE client, no NFS options (defaults); 8-CURRENT server, ZFS; broken > > 7-STABLE client, tcp,nfsv3,-r32768,-w32768; 8-CURRENT server, ZFS, works > > Do you need all the options here? If not, could you try to find the > smallest subset of options that are needed to make ZFS work? Maybe > 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use > many NFS exported ZFS file systems, mostly accessed from MacOS X and > we see no problems. Whenever changing NFS transport options has an influence on reliability my first task is to verify the network. Especially there were often hardware problems with some NIC lately, of which some have worked around in the drivers and some not. Disabling TSO and checksum offloading typically helps. This kind of problem is typical on both the client and server, but also on routers. Of course network problems can also be on any cable, switch in between as well, but are less typical to produce complete NFS hangs. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 10:30:24 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA7B1065678 for ; Wed, 23 Jul 2008 10:30:24 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA228FC13 for ; Wed, 23 Jul 2008 10:30:24 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1424657fgb.35 for ; Wed, 23 Jul 2008 03:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=G19tZSpOr44gHBnPoBJqpKWnEwp0Tt4km2hGxdDYOvY=; b=hWgOoCENNVarWHmuk63JqGfxhGebYDmeQ36gXYwHH5XxBMwJSZ3bDbQZS5fLY3xbDp iSPyvEaeNBG1YqEQDX45FvmJyQupL46rHneqTd86U75cJh+rty4myuiqAACRI25f5ePk 0qHuybABjM5QNzkTtm6Jq2d/F4xS0DY8Xpel0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uJRwqKgsxpWEA+fcCXFOWnCXYWNj8SsBfpMtDlCygeIIMeIwyikC3U0fHOfarlbBSK v0TyMMrAdrnhBJf+X8jn1CBcG5zZ8JBEJ5hHx/MrsXBDTJpVKSP17IUSMDdH4upZZGjQ M22kd6XxbZSbfz4AJ+5eiWDOTQ6sVDnXCLD6o= Received: by 10.86.70.8 with SMTP id s8mr1434641fga.50.1216807287377; Wed, 23 Jul 2008 03:01:27 -0700 (PDT) Received: by 10.86.79.5 with HTTP; Wed, 23 Jul 2008 03:01:27 -0700 (PDT) Message-ID: Date: Wed, 23 Jul 2008 12:01:27 +0200 From: "Claus Guttesen" To: "Pawel Jakub Dawidek" In-Reply-To: <20080723082401.GC3603@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807221128.27592.lists@jnielsen.net> <20080723082401.GC3603@garage.freebsd.pl> Cc: John Nielsen , current@freebsd.org, fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 10:30:24 -0000 >> Today I discovered that the problem seems to go away if I change the NFS >> mount options on the desktop. The following is a summary/timeline of what >> I've tried: >> >> 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; works >> 7-STABLE client, no NFS options (defaults); 7-STABLE server, ZFS; broken >> 7-STABLE client, no NFS options (defaults); 8-CURRENT server, ZFS; broken >> 7-STABLE client, tcp,nfsv3,-r32768,-w32768; 8-CURRENT server, ZFS, works > > Do you need all the options here? If not, could you try to find the > smallest subset of options that are needed to make ZFS work? Maybe > 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use > many NFS exported ZFS file systems, mostly accessed from MacOS X and > we see no problems. Good to hear. I've just started testing a setup with an areca arc-1680 sas card and an external sas-cabinet. It currently has a zpool with ten 1 TB-drives in raidz2. It may grow to a two-digit TB system if the testing goes fine. It will nfs-share the partitions to my FreeBSD webservers. I'm using nfs v.3 and tcp with a read- and write-size at 32768. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 13:39:15 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1D8106566B; Wed, 23 Jul 2008 13:39:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C22408FC23; Wed, 23 Jul 2008 13:39:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NDd5QW075555; Wed, 23 Jul 2008 09:39:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NDd5CK045504; Wed, 23 Jul 2008 09:39:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B8F8773039; Wed, 23 Jul 2008 09:39:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723133905.B8F8773039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 09:39:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 13:39:15 -0000 TB --- 2008-07-23 13:05:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 13:05:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-07-23 13:05:00 - cleaning the object tree TB --- 2008-07-23 13:05:28 - cvsupping the source tree TB --- 2008-07-23 13:05:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-07-23 13:05:35 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 13:05:35 - cd /src TB --- 2008-07-23 13:05:35 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 13:05:37 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] In file included from /obj/arm/src/tmp/usr/include/machine/cpufunc.h:50, from /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:42, from /src/sbin/ipf/ipresend/../../../sys/sys/refcount.h:36, from /src/sbin/ipf/ipresend/../../../sys/sys/file.h:42, from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:42: /obj/arm/src/tmp/usr/include/machine/cpuconf.h:94:2: error: #error ARM_NARCH is 0 /obj/arm/src/tmp/usr/include/machine/cpuconf.h:152:2: error: #error ARM_NMMUS is 0 mkdep: compile failed *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 13:39:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 13:39:05 - ERROR: failed to build world TB --- 2008-07-23 13:39:05 - tinderbox aborted TB --- 1479.30 user 214.05 system 2044.59 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 14:06:46 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C95106564A; Wed, 23 Jul 2008 14:06:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F3E568FC16; Wed, 23 Jul 2008 14:06:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NE6hv7083694; Wed, 23 Jul 2008 10:06:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NE6h3O078921; Wed, 23 Jul 2008 10:06:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 53E2173039; Wed, 23 Jul 2008 10:06:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723140643.53E2173039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 10:06:43 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 14:06:46 -0000 TB --- 2008-07-23 13:05:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 13:05:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-07-23 13:05:00 - cleaning the object tree TB --- 2008-07-23 13:05:50 - cvsupping the source tree TB --- 2008-07-23 13:05:50 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-07-23 13:05:56 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 13:05:56 - cd /src TB --- 2008-07-23 13:05:56 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 13:05:59 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:81: /obj/amd64/src/tmp/usr/include/string.h:81: error: conflicting types for 'strdup' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:109: error: previous declaration of 'strdup' was here In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:82: /obj/amd64/src/tmp/usr/include/stdlib.h:163: error: conflicting types for 'setenv' /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:239: error: previous declaration of 'setenv' was here /obj/amd64/src/tmp/usr/include/stdlib.h:201: error: conflicting types for 'random' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:99: error: previous declaration of 'random' was here *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 14:06:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 14:06:43 - ERROR: failed to build world TB --- 2008-07-23 14:06:43 - tinderbox aborted TB --- 2665.99 user 332.28 system 3702.33 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 14:38:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED8F1065689; Wed, 23 Jul 2008 14:38:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 22F928FC2B; Wed, 23 Jul 2008 14:38:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NEcAUg092894; Wed, 23 Jul 2008 10:38:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NEcAV6038923; Wed, 23 Jul 2008 10:38:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 62AC373039; Wed, 23 Jul 2008 10:38:10 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723143810.62AC373039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 10:38:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 14:38:17 -0000 TB --- 2008-07-23 13:39:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 13:39:05 - starting HEAD tinderbox run for i386/i386 TB --- 2008-07-23 13:39:05 - cleaning the object tree TB --- 2008-07-23 13:39:37 - cvsupping the source tree TB --- 2008-07-23 13:39:37 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-07-23 13:39:44 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 13:39:44 - cd /src TB --- 2008-07-23 13:39:44 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 13:39:45 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:81: /obj/src/tmp/usr/include/string.h:81: error: conflicting types for 'strdup' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:109: error: previous declaration of 'strdup' was here In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:82: /obj/src/tmp/usr/include/stdlib.h:163: error: conflicting types for 'setenv' /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:239: error: previous declaration of 'setenv' was here /obj/src/tmp/usr/include/stdlib.h:201: error: conflicting types for 'random' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:99: error: previous declaration of 'random' was here *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 14:38:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 14:38:10 - ERROR: failed to build world TB --- 2008-07-23 14:38:10 - tinderbox aborted TB --- 2587.77 user 316.67 system 3544.42 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 15:06:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5EFE106567B; Wed, 23 Jul 2008 15:06:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 936508FC14; Wed, 23 Jul 2008 15:06:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NF6681099919; Wed, 23 Jul 2008 11:06:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NF66Wx068461; Wed, 23 Jul 2008 11:06:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DD88D73039; Wed, 23 Jul 2008 11:06:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723150605.DD88D73039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 11:06:05 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:06:14 -0000 TB --- 2008-07-23 14:06:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 14:06:43 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-07-23 14:06:43 - cleaning the object tree TB --- 2008-07-23 14:07:14 - cvsupping the source tree TB --- 2008-07-23 14:07:14 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-07-23 14:07:19 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 14:07:19 - cd /src TB --- 2008-07-23 14:07:19 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 14:07:21 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:81: /obj/pc98/src/tmp/usr/include/string.h:81: error: conflicting types for 'strdup' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:109: error: previous declaration of 'strdup' was here In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:82: /obj/pc98/src/tmp/usr/include/stdlib.h:163: error: conflicting types for 'setenv' /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:239: error: previous declaration of 'setenv' was here /obj/pc98/src/tmp/usr/include/stdlib.h:201: error: conflicting types for 'random' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:99: error: previous declaration of 'random' was here *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 15:06:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 15:06:05 - ERROR: failed to build world TB --- 2008-07-23 15:06:05 - tinderbox aborted TB --- 2585.28 user 330.88 system 3562.38 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 15:38:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC2A106564A for ; Wed, 23 Jul 2008 15:38:07 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id B48888FC16 for ; Wed, 23 Jul 2008 15:38:06 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id B978E6D41E; Wed, 23 Jul 2008 17:38:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkSHz7KSYi06; Wed, 23 Jul 2008 17:38:49 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 4BA166D41B; Wed, 23 Jul 2008 17:38:49 +0200 (CEST) Date: Wed, 23 Jul 2008 17:38:49 +0200 From: Rink Springer To: Attilio Rao Message-ID: <20080723153849.GA5117@rink.nu> References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Lothar Braun , freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:38:07 -0000 On Sun, Jul 20, 2008 at 06:26:04PM +0200, Attilio Rao wrote: > 2008/7/20, Attilio Rao : > > 2008/7/20, Lothar Braun : > > > > > Hi Attilio, > > > > > > > > > > > > > can you please try this on the top of -CURRENT: > > > > http://www.freebsd.org/~attilio/xfs2.diff > > > > > > > > > > Thank you for the patch. The panic and the dead lock disappeard, but there > > > is a new problem insteed. The commands > > > > > > mkfs.xfs /dev/ad8s4 > > > mount -t xfs /dev/ad8s4 /home > > > mkdir /home/lothar > > > chown lothar:lothar /home/lothar > > > > > > For what I remind, it is likely XFS is still not ready for writing. > > This means you should only use it in read-only. > > Speaking of which, I think we should mark it again like a read-only fs > until writing is not 100% ready. NTFS suffers from the same issue; it 'kind of' supports writes. The result is that it supports writes in so limited circumstances that the write support is mostly useless (and it even tends to lead to panics...) I think a better solution is to mount such filesystems r/o by default, and only mount them r/w if explicitely asked to do so, for example by '-o rw' - it would make things a lot clearer for our users when trying to use filesystems, and brave souls are always welcome to force r/w that way. What do you think? -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 15:44:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE027106567B; Wed, 23 Jul 2008 15:44:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB708FC08; Wed, 23 Jul 2008 15:44:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NFiPiF044620; Wed, 23 Jul 2008 11:44:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NFiPKd097812; Wed, 23 Jul 2008 11:44:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D4D2173039; Wed, 23 Jul 2008 11:44:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723154424.D4D2173039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 11:44:24 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:44:27 -0000 TB --- 2008-07-23 14:38:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 14:38:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2008-07-23 14:38:10 - cleaning the object tree TB --- 2008-07-23 14:38:34 - cvsupping the source tree TB --- 2008-07-23 14:38:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2008-07-23 14:38:40 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 14:38:40 - cd /src TB --- 2008-07-23 14:38:40 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 14:38:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:81: /obj/ia64/src/tmp/usr/include/string.h:81: error: conflicting types for 'strdup' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:109: error: previous declaration of 'strdup' was here In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:82: /obj/ia64/src/tmp/usr/include/stdlib.h:163: error: conflicting types for 'setenv' /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:239: error: previous declaration of 'setenv' was here /obj/ia64/src/tmp/usr/include/stdlib.h:201: error: conflicting types for 'random' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:99: error: previous declaration of 'random' was here *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 15:44:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 15:44:24 - ERROR: failed to build world TB --- 2008-07-23 15:44:24 - tinderbox aborted TB --- 2930.50 user 328.73 system 3974.16 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 16:05:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F7B21065676; Wed, 23 Jul 2008 16:05:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id D1C0D8FC0C; Wed, 23 Jul 2008 16:05:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NG5nQ0050738; Wed, 23 Jul 2008 12:05:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NG5mfO022853; Wed, 23 Jul 2008 12:05:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CA4E073039; Wed, 23 Jul 2008 12:05:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723160548.CA4E073039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 12:05:48 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 16:05:51 -0000 TB --- 2008-07-23 15:06:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 15:06:05 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2008-07-23 15:06:06 - cleaning the object tree TB --- 2008-07-23 15:06:33 - cvsupping the source tree TB --- 2008-07-23 15:06:33 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2008-07-23 15:06:41 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 15:06:41 - cd /src TB --- 2008-07-23 15:06:41 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 15:06:44 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:81: /obj/powerpc/src/tmp/usr/include/string.h:81: error: conflicting types for 'strdup' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:109: error: previous declaration of 'strdup' was here In file included from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:82: /obj/powerpc/src/tmp/usr/include/stdlib.h:163: error: conflicting types for 'setenv' /src/sbin/ipf/ipresend/../../../sys/sys/systm.h:239: error: previous declaration of 'setenv' was here /obj/powerpc/src/tmp/usr/include/stdlib.h:201: error: conflicting types for 'random' /src/sbin/ipf/ipresend/../../../sys/sys/libkern.h:99: error: previous declaration of 'random' was here *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 16:05:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:05:48 - ERROR: failed to build world TB --- 2008-07-23 16:05:48 - tinderbox aborted TB --- 2623.82 user 321.73 system 3582.79 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 16:09:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB131065680; Wed, 23 Jul 2008 16:09:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7328FC1B; Wed, 23 Jul 2008 16:09:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NG97Er051603; Wed, 23 Jul 2008 12:09:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NG97rv026698; Wed, 23 Jul 2008 12:09:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3DABB73039; Wed, 23 Jul 2008 12:09:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723160907.3DABB73039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 12:09:05 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 16:09:09 -0000 TB --- 2008-07-23 15:44:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 15:44:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2008-07-23 15:44:25 - cleaning the object tree TB --- 2008-07-23 15:44:50 - cvsupping the source tree TB --- 2008-07-23 15:44:50 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2008-07-23 15:44:56 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 15:44:56 - cd /src TB --- 2008-07-23 15:44:56 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 15:44:58 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris/sys/atomic.h:33, from /src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:67, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/refcount.h:33, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:54: /obj/sparc64/src/tmp/usr/include/machine/atomic.h:272: error: conflicting types for 'atomic_add_acq_int' /obj/sparc64/src/tmp/usr/include/sys/refcount.h:46: error: previous implicit declaration of 'atomic_add_acq_int' was here *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 16:09:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:09:05 - ERROR: failed to build world TB --- 2008-07-23 16:09:05 - tinderbox aborted TB --- 1026.88 user 145.19 system 1480.05 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 16:27:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 233331065674; Wed, 23 Jul 2008 16:27:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 080358FC16; Wed, 23 Jul 2008 16:27:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NGR7lx016825; Wed, 23 Jul 2008 12:27:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NGR7Uw054968; Wed, 23 Jul 2008 12:27:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8BF2D73039; Wed, 23 Jul 2008 12:27:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723162707.8BF2D73039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 12:27:07 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 16:27:11 -0000 TB --- 2008-07-23 16:05:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 16:05:48 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2008-07-23 16:05:48 - cleaning the object tree TB --- 2008-07-23 16:06:08 - cvsupping the source tree TB --- 2008-07-23 16:06:08 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2008-07-23 16:06:14 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 16:06:14 - cd /src TB --- 2008-07-23 16:06:14 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 16:06:15 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris/sys/atomic.h:33, from /src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:67, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/refcount.h:33, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:54: /obj/sun4v/src/tmp/usr/include/machine/atomic.h:272: error: conflicting types for 'atomic_add_acq_int' /obj/sun4v/src/tmp/usr/include/sys/refcount.h:46: error: previous implicit declaration of 'atomic_add_acq_int' was here *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 16:27:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:27:07 - ERROR: failed to build world TB --- 2008-07-23 16:27:07 - tinderbox aborted TB --- 1013.78 user 144.98 system 1278.63 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 16:57:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3CB106566B; Wed, 23 Jul 2008 16:57:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 841F98FC19; Wed, 23 Jul 2008 16:57:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NGvO6t023680; Wed, 23 Jul 2008 12:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NGvOrW083159; Wed, 23 Jul 2008 12:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 126D473039; Wed, 23 Jul 2008 12:57:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723165724.126D473039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 12:57:24 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 16:57:26 -0000 TB --- 2008-07-23 16:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 16:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-07-23 16:30:00 - cleaning the object tree TB --- 2008-07-23 16:30:19 - cvsupping the source tree TB --- 2008-07-23 16:30:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-07-23 16:30:27 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 16:30:27 - cd /src TB --- 2008-07-23 16:30:27 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 16:30:28 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c cc -O -pipe -I/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libzpool/../../../cddl/compat/opensolaris/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libzpool/../../../cddl/lib/libumem -I/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libnvpair -fstack-protector -Wno-unknown-pragmas -c /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c In file included from /src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris/sys/atomic.h:33, from /src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:67, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/refcount.h:33, from /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:54: /obj/amd64/src/tmp/usr/include/machine/atomic.h:165: error: conflicting types for 'atomic_fetchadd_int' /obj/amd64/src/tmp/usr/include/sys/refcount.h:53: error: previous implicit declaration of 'atomic_fetchadd_int' was here *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 16:57:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 16:57:23 - ERROR: failed to build world TB --- 2008-07-23 16:57:23 - tinderbox aborted TB --- 1161.43 user 156.41 system 1643.39 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 17:23:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F4B4106564A; Wed, 23 Jul 2008 17:23:21 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 20CA78FC1B; Wed, 23 Jul 2008 17:23:21 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from max.local (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6NHNGJP088425; Wed, 23 Jul 2008 13:23:16 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org, ticso@cicely.de Date: Wed, 23 Jul 2008 13:23:37 -0400 User-Agent: KMail/1.9.7 References: <200807221128.27592.lists@jnielsen.net> <20080723082401.GC3603@garage.freebsd.pl> <20080723090450.GV58113@cicely7.cicely.de> In-Reply-To: <20080723090450.GV58113@cicely7.cicely.de> X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231323.37358.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Pawel Jakub Dawidek , current@freebsd.org, fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 17:23:21 -0000 On Wednesday 23 July 2008, Bernd Walter wrote: > On Wed, Jul 23, 2008 at 10:24:01AM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Jul 22, 2008 at 11:28:27AM -0400, John Nielsen wrote: > > > I have a FreeBSD server (which I use as a NAS device, among other > > > things) and a FreeBSD deskop. The desktop is running 7-STABLE from a > > > couple days ago and the server is running 8-CURRENT from yesterday. > > > The server has several NFS-exported ZFS'es which I mount from the > > > desktop. Since moving the shares to ZFS I've been having trouble > > > writing to them from the desktop--the mount hangs after the first or > > > second attempt. This is similar if not identical to what's described > > > in the thread > > > (from -current) I partially copied below. > > > > > > Today I discovered that the problem seems to go away if I change the > > > NFS mount options on the desktop. The following is a summary/timeline > > > of what I've tried: > > > > > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; > > > works 7-STABLE client, no NFS options (defaults); 7-STABLE server, > > > ZFS; broken 7-STABLE client, no NFS options (defaults); 8-CURRENT > > > server, ZFS; broken 7-STABLE client, tcp,nfsv3,-r32768,-w32768; > > > 8-CURRENT server, ZFS, works > > > > Do you need all the options here? If not, could you try to find the > > smallest subset of options that are needed to make ZFS work? Maybe > > 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use > > many NFS exported ZFS file systems, mostly accessed from MacOS X and > > we see no problems. > > Whenever changing NFS transport options has an influence on reliability > my first task is to verify the network. > Especially there were often hardware problems with some NIC lately, > of which some have worked around in the drivers and some not. > Disabling TSO and checksum offloading typically helps. > This kind of problem is typical on both the client and server, but also > on routers. > Of course network problems can also be on any cable, switch in between > as well, but are less typical to produce complete NFS hangs. A good strategy I'm sure. However in this case the whole network is within arm's reach, the switch and cables are brand new and I haven't had any other issues that would point to a network fault. Further, I saw the exact same behavior on a completely different set of hardware around the time of 7-BETA. In both cases the NFS shares worked fine prior to my moving the shared ports tree to ZFS. PJD- I'll try to narrow the options needed this afternoon or tomorrow and let you know what I find. JN From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 17:23:21 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F4B4106564A; Wed, 23 Jul 2008 17:23:21 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 20CA78FC1B; Wed, 23 Jul 2008 17:23:21 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from max.local (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6NHNGJP088425; Wed, 23 Jul 2008 13:23:16 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org, ticso@cicely.de Date: Wed, 23 Jul 2008 13:23:37 -0400 User-Agent: KMail/1.9.7 References: <200807221128.27592.lists@jnielsen.net> <20080723082401.GC3603@garage.freebsd.pl> <20080723090450.GV58113@cicely7.cicely.de> In-Reply-To: <20080723090450.GV58113@cicely7.cicely.de> X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231323.37358.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Pawel Jakub Dawidek , current@freebsd.org, fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 17:23:21 -0000 On Wednesday 23 July 2008, Bernd Walter wrote: > On Wed, Jul 23, 2008 at 10:24:01AM +0200, Pawel Jakub Dawidek wrote: > > On Tue, Jul 22, 2008 at 11:28:27AM -0400, John Nielsen wrote: > > > I have a FreeBSD server (which I use as a NAS device, among other > > > things) and a FreeBSD deskop. The desktop is running 7-STABLE from a > > > couple days ago and the server is running 8-CURRENT from yesterday. > > > The server has several NFS-exported ZFS'es which I mount from the > > > desktop. Since moving the shares to ZFS I've been having trouble > > > writing to them from the desktop--the mount hangs after the first or > > > second attempt. This is similar if not identical to what's described > > > in the thread > > > (from -current) I partially copied below. > > > > > > Today I discovered that the problem seems to go away if I change the > > > NFS mount options on the desktop. The following is a summary/timeline > > > of what I've tried: > > > > > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; > > > works 7-STABLE client, no NFS options (defaults); 7-STABLE server, > > > ZFS; broken 7-STABLE client, no NFS options (defaults); 8-CURRENT > > > server, ZFS; broken 7-STABLE client, tcp,nfsv3,-r32768,-w32768; > > > 8-CURRENT server, ZFS, works > > > > Do you need all the options here? If not, could you try to find the > > smallest subset of options that are needed to make ZFS work? Maybe > > 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use > > many NFS exported ZFS file systems, mostly accessed from MacOS X and > > we see no problems. > > Whenever changing NFS transport options has an influence on reliability > my first task is to verify the network. > Especially there were often hardware problems with some NIC lately, > of which some have worked around in the drivers and some not. > Disabling TSO and checksum offloading typically helps. > This kind of problem is typical on both the client and server, but also > on routers. > Of course network problems can also be on any cable, switch in between > as well, but are less typical to produce complete NFS hangs. A good strategy I'm sure. However in this case the whole network is within arm's reach, the switch and cables are brand new and I haven't had any other issues that would point to a network fault. Further, I saw the exact same behavior on a completely different set of hardware around the time of 7-BETA. In both cases the NFS shares worked fine prior to my moving the shared ports tree to ZFS. PJD- I'll try to narrow the options needed this afternoon or tomorrow and let you know what I find. JN From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 17:26:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 939911065671; Wed, 23 Jul 2008 17:26:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 50EE58FC1A; Wed, 23 Jul 2008 17:26:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NHQLlt031509; Wed, 23 Jul 2008 13:26:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NHQLQe014087; Wed, 23 Jul 2008 13:26:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8F2D273039; Wed, 23 Jul 2008 13:26:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723172621.8F2D273039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 13:26:21 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 17:26:27 -0000 TB --- 2008-07-23 16:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 16:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-07-23 16:30:00 - cleaning the object tree TB --- 2008-07-23 16:30:11 - cvsupping the source tree TB --- 2008-07-23 16:30:11 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-07-23 16:30:20 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 16:30:20 - cd /src TB --- 2008-07-23 16:30:20 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 16:30:21 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c cc1: warnings being treated as errors In file included from /src/sbin/ipf/ipresend/../../../sys/sys/file.h:42, from /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/sock.c:42: /src/sbin/ipf/ipresend/../../../sys/sys/refcount.h: In function 'refcount_acquire': /src/sbin/ipf/ipresend/../../../sys/sys/refcount.h:46: warning: implicit declaration of function 'atomic_add_acq_int' /src/sbin/ipf/ipresend/../../../sys/sys/refcount.h: In function 'refcount_release': /src/sbin/ipf/ipresend/../../../sys/sys/refcount.h:53: warning: implicit declaration of function 'atomic_fetchadd_int' *** Error code 1 Stop in /src/sbin/ipf/ipresend. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 17:26:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 17:26:21 - ERROR: failed to build world TB --- 2008-07-23 17:26:21 - tinderbox aborted TB --- 2526.91 user 323.68 system 3380.94 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 17:54:11 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6868F106564A for ; Wed, 23 Jul 2008 17:54:11 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 301958FC0C for ; Wed, 23 Jul 2008 17:54:11 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 0BAE367DB2A; Wed, 23 Jul 2008 19:37:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUTCvwQqwYnR; Wed, 23 Jul 2008 19:36:58 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A731867D307; Wed, 23 Jul 2008 19:36:58 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.2/8.14.2/Submit) id m6NHavo6020971; Wed, 23 Jul 2008 19:36:57 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 23 Jul 2008 19:36:57 +0200 From: Roman Divacky To: Nenhum_de_Nos Message-ID: <20080723173657.GA20918@freebsd.org> References: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, dmitry.chagin@gmail.com Subject: Re: Linuxulator64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 17:54:11 -0000 On Wed, Jul 23, 2008 at 12:47:49AM -0300, Nenhum_de_Nos wrote: > hail, > > I've read some time about this and as this is something that I really look > forward to seeing in freebsd, I came to ask how is the state of this > feature now. when I'm able to run 64 bits linux bins from inside freebsd I > can switch to breebsd in this box and begin testing this if necessary :) > > thanks in advance, there's a work in progress done by Dmitry Chagin, I'd say it's progressing well.. current status (afaik) is that the basic program runs, but the "fancy" stuff (signals, dynamic loading of libraries etc.) does not... can you commetn a little dmitry? From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 17:55:20 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3ED1065682 for ; Wed, 23 Jul 2008 17:55:20 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 929E78FC33 for ; Wed, 23 Jul 2008 17:55:20 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so966530ywe.13 for ; Wed, 23 Jul 2008 10:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:message-id :in-reply-to:references:date:subject:from:to:cc:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance:sender; bh=aHLC72VLjE0XSe3ZaoQhPXPxzq/3aSn9HYna27d+QYc=; b=G3zvVw/eGF5CPu0trbEG4KHhCkxAJQ/sinRaW3DKu8nGq0HGmZES4AZMJ+esQ3lOKt QmmRAG88lN66gUqisDjyJnLVLkQhGu5K4JZ7ZpUXeFTVce1HVJIEIUu9C0vpPwbmFDFJ uyixkJBcebgyTQPbUk+36ASy6EiqW9t4q3U8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:in-reply-to:references:date:subject:from:to:cc :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance:sender; b=djdUFuaP0JDvTTp6BufiH9SOww3gShop9XJ1jUBfiVjWqUjTNUASzMmeDXQ53BgfLE xa5aeOqK948ryowUMMbNylaZ/Dh7NKDv/1rBSp0CB0vrMXVQx98PdNsZRIdDd7Bp6gRt 2coPcu6BTzGkUSFT7+TK2fnyyLH4YplXOVT3Y= Received: by 10.151.45.2 with SMTP id x2mr502013ybj.219.1216835719461; Wed, 23 Jul 2008 10:55:19 -0700 (PDT) Received: from cygnus.homeunix.com ( [189.71.52.253]) by mx.google.com with ESMTPS id 5sm2334685ywl.4.2008.07.23.10.55.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jul 2008 10:55:18 -0700 (PDT) Received: by cygnus.homeunix.com (Postfix, from userid 80) id 318B1110; Wed, 23 Jul 2008 14:55:13 -0300 (BRT) Received: from 200.252.157.118 (proxying for 10.12.1.211, 10.12.1.3) (SquirrelMail authenticated user matheus@eternamente.info) by cygnus.homeunix.com with HTTP; Wed, 23 Jul 2008 14:55:13 -0300 (BRT) Message-ID: In-Reply-To: <20080723173657.GA20918@freebsd.org> References: <7e234610a9e9840c81048127782412c9.squirrel@cygnus> <20080723173657.GA20918@freebsd.org> Date: Wed, 23 Jul 2008 14:55:13 -0300 (BRT) From: "Nenhum_de_Nos" To: "Roman Divacky" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: Nenhum_de_Nos Cc: freebsd-current@freebsd.org Subject: Re: Linuxulator64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 17:55:20 -0000 On Wed, July 23, 2008 14:36, Roman Divacky wrote: > On Wed, Jul 23, 2008 at 12:47:49AM -0300, Nenhum_de_Nos wrote: >> hail, >> >> I've read some time about this and as this is something that I really >> look >> forward to seeing in freebsd, I came to ask how is the state of this >> feature now. when I'm able to run 64 bits linux bins from inside freebsd >> I >> can switch to breebsd in this box and begin testing this if necessary :) >> >> thanks in advance, > > there's a work in progress done by Dmitry Chagin, I'd say it's progressing > well.. > > current status (afaik) is that the basic program runs, but the "fancy" > stuff (signals, dynamic loading of libraries etc.) does not... > > can you commetn a little dmitry? Well, if anyone is familiar with Folding at Home (I bet so), and if its smp client (that runs on 64bits linux only) is able to work, as far as -CURRENT is satable enough for a desktop use I can migrate as soon as I have time, which is not that long (one week from now, tops). matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 18:02:40 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF5B1065709; Wed, 23 Jul 2008 18:02:40 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id AB6598FC25; Wed, 23 Jul 2008 18:02:40 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from max.local (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6NI2dJP009816; Wed, 23 Jul 2008 14:02:40 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Wed, 23 Jul 2008 14:02:59 -0400 User-Agent: KMail/1.9.7 References: <200807221128.27592.lists@jnielsen.net> <20080723082401.GC3603@garage.freebsd.pl> In-Reply-To: <20080723082401.GC3603@garage.freebsd.pl> X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231402.59893.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Pawel Jakub Dawidek , fs@freebsd.org Subject: Re: NFS writes and ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 18:02:41 -0000 On Wednesday 23 July 2008, Pawel Jakub Dawidek wrote: > On Tue, Jul 22, 2008 at 11:28:27AM -0400, John Nielsen wrote: > > I have a FreeBSD server (which I use as a NAS device, among other > > things) and a FreeBSD deskop. The desktop is running 7-STABLE from a > > couple days ago and the server is running 8-CURRENT from yesterday. The > > server has several NFS-exported ZFS'es which I mount from the desktop. > > Since moving the shares to ZFS I've been having trouble writing to them > > from the desktop--the mount hangs after the first or second attempt. > > This is similar if not identical to what's described in the thread > > (from -current) I partially copied below. > > > > Today I discovered that the problem seems to go away if I change the > > NFS mount options on the desktop. The following is a summary/timeline > > of what I've tried: > > > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, UFS; works > > 7-STABLE client, no NFS options (defaults); 7-STABLE server, ZFS; > > broken 7-STABLE client, no NFS options (defaults); 8-CURRENT server, > > ZFS; broken 7-STABLE client, tcp,nfsv3,-r32768,-w32768; 8-CURRENT > > server, ZFS, works > > Do you need all the options here? If not, could you try to find the > smallest subset of options that are needed to make ZFS work? Maybe > 'nfsv3' is all that is needed, or 'tcp' alone fixes it? At work we use > many NFS exported ZFS file systems, mostly accessed from MacOS X and > we see no problems. No. "tcp" alone fixes it. That's not too surprising since nfsv3 should be a no-op. With everything _but_ "tcp" it took only slightly longer to hang the mount (not scientifically measured). With the default NFS mount mode changed to TCP in -CURRENT the workaround is already in place for FreeBSD clients, and the issue apparently never popped up on other clients--there are a few people (yourself included) who say they've never had a problem with Mac OS, e.g.. I haven't come across reports either way about Solaris or Linux. Are we the last ones to use UDP by default? Anyway, I hope this is helpful. Let me know if I should file a PR or anything. Thanks, JN From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 18:11:43 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F3B1065670; Wed, 23 Jul 2008 18:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 47C728FC21; Wed, 23 Jul 2008 18:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NIBeTn043084; Wed, 23 Jul 2008 14:11:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6NIBego052577; Wed, 23 Jul 2008 14:11:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A61E273039; Wed, 23 Jul 2008 14:11:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080723181140.A61E273039@freebsd-current.sentex.ca> Date: Wed, 23 Jul 2008 14:11:40 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7748/Fri Jul 18 10:28:37 2008 clamav-milter version 0.93 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 18:11:43 -0000 TB --- 2008-07-23 16:57:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-07-23 16:57:24 - starting HEAD tinderbox run for i386/i386 TB --- 2008-07-23 16:57:24 - cleaning the object tree TB --- 2008-07-23 16:57:42 - cvsupping the source tree TB --- 2008-07-23 16:57:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-07-23 16:57:47 - building world (CFLAGS=-O -pipe) TB --- 2008-07-23 16:57:47 - cd /src TB --- 2008-07-23 16:57:47 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 23 16:57:49 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 23 18:06:45 UTC 2008 TB --- 2008-07-23 18:06:45 - generating LINT kernel config TB --- 2008-07-23 18:06:45 - cd /src/sys/i386/conf TB --- 2008-07-23 18:06:45 - /usr/bin/make -B LINT TB --- 2008-07-23 18:06:45 - building LINT kernel (COPTFLAGS=) TB --- 2008-07-23 18:06:45 - cd /src TB --- 2008-07-23 18:06:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 23 18:06:45 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/dev/acpica/utobject.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/dev/acpica/utresrc.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/dev/acpica/utstate.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/dev/acpica/utxface.c cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/contrib/ipfilter/netinet/fil.c -I/src/sys/contrib/ipfilter In file included from /src/sys/sys/file.h:42, from /src/sys/contrib/ipfilter/netinet/fil.c:49: /src/sys/sys/refcount.h:38:2: error: #warning _KERNEL defined *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-23 18:11:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-23 18:11:40 - ERROR: failed to build lint kernel TB --- 2008-07-23 18:11:40 - tinderbox aborted TB --- 3227.76 user 404.17 system 4456.21 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 18:46:14 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 402201065672 for ; Wed, 23 Jul 2008 18:46:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 928B48FC27 for ; Wed, 23 Jul 2008 18:46:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6NIk0n9049681; Wed, 23 Jul 2008 14:46:06 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 23 Jul 2008 10:50:56 -0400 User-Agent: KMail/1.9.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: <200807231050.56507.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 23 Jul 2008 14:46:06 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7798/Wed Jul 23 13:42:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Manjunath Ranganathaiah Subject: Re: setting memory size with hw.physmem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 18:46:14 -0000 On Tuesday 22 July 2008 06:35:10 pm Manjunath Ranganathaiah wrote: > On of my system with 8G of RAM running 7.0R amd64, dmesg shows memory usage as: > > usable memory = 8576397312 (8179 MB) > avail memory = 8289071104 (7905 MB) > > If I set hw.physmem tunable to 8g, dmesg shows the following > > usable memory = 7771095040 (7411 MB) > avail memory = 7507386368 (7159 MB) > > If I set hw.physmem to 8950M > > usable memory = 8565911552 (8169 MB) > avail memory = 8278892544 (7895 MB) > > if I set hw.physmem to 8999M > > usable memory = 8576397312 (8179 MB) > avail memory = 8289071104 (7905 MB) > > > Is this expected behavior? Yes. hw.physmem is really setting a "max physical address". So any physical memory above that address is ignored. Generally part of the address space in the low 4GB range is used for memio (PCI memory BARs, VGA/CGA/EGA framebuffer (0xa0000)) and isn't backed by RAM. As a result, capping hw.physmem=4g can actually result in a bit less than 4GB of usable/avail memory. > How do I increase or decrease physical memory size by 1MB? Examine your SMAP (currently only available via loader 'smap' command or from verbose boot messages) and find the max phys addr of your RAM. Then subtract 1MB from that ending address and use that for your hw.physmem setting. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 20:01:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D10601065670; Wed, 23 Jul 2008 20:01:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id BEC918FC21; Wed, 23 Jul 2008 20:01:57 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from max.local (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m6NK1uJP076429; Wed, 23 Jul 2008 16:01:57 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Wed, 23 Jul 2008 16:02:15 -0400 User-Agent: KMail/1.9.7 References: <200807221048.48729.lists@jnielsen.net> <4885FD12.1090408@freebsd.org> <200807221232.29323.lists@jnielsen.net> In-Reply-To: <200807221232.29323.lists@jnielsen.net> X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231602.16894.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Sam Leffler Subject: Re: ath vap - second hostap _almost_ works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 20:01:57 -0000 On Tuesday 22 July 2008, John Nielsen wrote: > On Tuesday 22 July 2008 11:30:26 am Sam Leffler wrote: > > If you can't find the reason please file a PR w/ the details you've > > provided. > > I'll do that. Thanks! I have filed this as kern/125906. Let me know if anyone has further testing or patches they'd like me to try. Thanks, JN From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 22:48:02 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 487121065670 for ; Wed, 23 Jul 2008 22:48:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E48EE8FC1B for ; Wed, 23 Jul 2008 22:48:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6NMlt8n051300 for ; Wed, 23 Jul 2008 18:47:55 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Wed, 23 Jul 2008 18:46:33 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231846.33728.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 23 Jul 2008 18:47:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7805/Wed Jul 23 17:27:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 22:48:02 -0000 So I upgraded a test box today to HEAD and got my first taste of the trimmed down boot messages. I can appreciate the slimness of them. However, personally I actually find the detail useful (at least sometimes). Unfortunately, there doesn't appear to be a knob I can flip to actually get all the messages back as /etc/rc unconditionally uses 'quietstart' rather than 'start'. Am I the only one who finds it useful to know which daemon is making my startup hang for an extra second? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 23 23:02:38 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B47C1065682; Wed, 23 Jul 2008 23:02:38 +0000 (UTC) (envelope-from faber@ISI.EDU) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0578FC08; Wed, 23 Jul 2008 23:02:38 +0000 (UTC) (envelope-from faber@ISI.EDU) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m6NMq43V025506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Jul 2008 15:52:05 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m6NMq4VC000239; Wed, 23 Jul 2008 15:52:04 -0700 (PDT) (envelope-from faber) Date: Wed, 23 Jul 2008 15:52:04 -0700 From: Ted Faber To: John Baldwin Message-ID: <20080723225204.GG3021@zod.isi.edu> References: <200807231846.33728.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yZnyZsPjQYjG7xG7" Content-Disposition: inline In-Reply-To: <200807231846.33728.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 23:02:38 -0000 --yZnyZsPjQYjG7xG7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 23, 2008 at 06:46:33PM -0400, John Baldwin wrote: > Am I the only one who finds it useful to know which daemon= is=20 > making my startup hang for an extra second? You are not alone. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --yZnyZsPjQYjG7xG7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiHthMACgkQaUz3f+Zf+XuCewCeIt6MOz+aOabu9NcHGtKXtKlx +R4Aniqlcg/rN9PxKVKE2TACRmk7rFnX =O/LX -----END PGP SIGNATURE----- --yZnyZsPjQYjG7xG7-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 01:04:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5FF01065674 for ; Thu, 24 Jul 2008 01:04:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 93E348FC17 for ; Thu, 24 Jul 2008 01:04:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6O14ZR9029285; Wed, 23 Jul 2008 21:04:36 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 23 Jul 2008 21:04:36 -0400 (EDT) Date: Wed, 23 Jul 2008 21:04:35 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200807231846.33728.jhb@freebsd.org> Message-ID: References: <200807231846.33728.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 01:04:38 -0000 On Wed, 23 Jul 2008, John Baldwin wrote: > So I upgraded a test box today to HEAD and got my first taste of the trimmed > down boot messages. I can appreciate the slimness of them. However, > personally I actually find the detail useful (at least sometimes). > Unfortunately, there doesn't appear to be a knob I can flip to actually get > all the messages back as /etc/rc unconditionally uses 'quietstart' rather > than 'start'. Am I the only one who finds it useful to know which daemon is > making my startup hang for an extra second? No, you are not. I too would like that. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 03:15:09 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C636106566B for ; Thu, 24 Jul 2008 03:15:09 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id EA3248FC08 for ; Thu, 24 Jul 2008 03:15:08 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so948939wra.27 for ; Wed, 23 Jul 2008 20:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=7DwjHN5d0Xn4XFypq/tsRa69T1d2xj00Z5XsIs5UbXA=; b=sIrlas4HQoQ1oKW8cC6dMci2P8bwZ/nlIlZf9+0tp4D9azll8F2syak03fSKmEPOZw S8q/+djJoaYstR96jDM2vaOKlzHYbZzdYsdM4pCh8gB/d7JpGGjtNvoLJUKrWQqTLxEf EgT64Exbl2fd5C8Ga4nGCNhGMIfh4wsyrf238= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TvZf6GeJLDRj3M8XgAueMLsH5T0OHqudgpScFjtMB1np5V/cFKbkD3vN9wTi7EiLPf U9L+JxLc5tMbHhiS03+C+QFL+JPsDAxGZdYK05cIVr5XewN7sJ7rAeDS2ndbwSyn33nF H6D+dkh/Y+Hh7VYhMHhqagd7YRIvFRaYjQ85Y= Received: by 10.90.65.14 with SMTP id n14mr705049aga.88.1216867759722; Wed, 23 Jul 2008 19:49:19 -0700 (PDT) Received: by 10.150.12.12 with HTTP; Wed, 23 Jul 2008 19:49:19 -0700 (PDT) Message-ID: <5f67a8c40807231949i2b2514bbw78dd36cf418cf573@mail.gmail.com> Date: Wed, 23 Jul 2008 22:49:19 -0400 From: "Zaphod Beeblebrox" To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 References: <200807231846.33728.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 03:15:09 -0000 On Wed, Jul 23, 2008 at 9:04 PM, Daniel Eischen wrote: > On Wed, 23 Jul 2008, John Baldwin wrote: > > than 'start'. Am I the only one who finds it useful to know which daemon >> is >> making my startup hang for an extra second? >> > > No, you are not. I too would like that. > I'd go further: it was nice when startup scripts printed their name (no newline) and then '.\n' when they were finished. It then becomes unambiguous who is at fault. It's hard to tell with the current non-system which of the 2 scrpts (the one that has printed it's name, or the one that next prints it's name) is at fault. Worse.. it could be the quiet script in between. From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 03:21:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663B5106566C; Thu, 24 Jul 2008 03:21:18 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0978A8FC16; Thu, 24 Jul 2008 03:21:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6O3LGFV013628; Wed, 23 Jul 2008 23:21:16 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 23 Jul 2008 23:21:17 -0400 (EDT) Date: Wed, 23 Jul 2008 23:21:16 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Zaphod Beeblebrox In-Reply-To: <5f67a8c40807231949i2b2514bbw78dd36cf418cf573@mail.gmail.com> Message-ID: References: <200807231846.33728.jhb@freebsd.org> <5f67a8c40807231949i2b2514bbw78dd36cf418cf573@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 03:21:18 -0000 On Wed, 23 Jul 2008, Zaphod Beeblebrox wrote: > On Wed, Jul 23, 2008 at 9:04 PM, Daniel Eischen > wrote: > >> On Wed, 23 Jul 2008, John Baldwin wrote: >> >> than 'start'. Am I the only one who finds it useful to know which daemon >>> is >>> making my startup hang for an extra second? >>> >> >> No, you are not. I too would like that. >> > > I'd go further: it was nice when startup scripts printed their name (no > newline) and then '.\n' when they were finished. It then becomes > unambiguous who is at fault. It's hard to tell with the current non-system > which of the 2 scrpts (the one that has printed it's name, or the one that > next prints it's name) is at fault. Worse.. it could be the quiet script in > between. Agreed, but you could delineate it with something other than '\n" too. Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is done and has moved on to the next service. -- DE From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 06:30:04 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50BCA1065676; Thu, 24 Jul 2008 06:30:04 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from websrv01.jr-hosting.nl (websrv01.jr-hosting.nl [78.47.69.233]) by mx1.freebsd.org (Postfix) with ESMTP id E8F518FC20; Thu, 24 Jul 2008 06:30:03 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from [88.131.73.154] (helo=joel-dahls-macbook.local) by websrv01.jr-hosting.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLtv5-0002ms-7p; Thu, 24 Jul 2008 08:03:19 +0200 Message-ID: <48881B22.2010703@FreeBSD.org> Date: Thu, 24 Jul 2008 08:03:14 +0200 From: Joel Dahl User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: John Baldwin References: <200807231846.33728.jhb@freebsd.org> In-Reply-To: <200807231846.33728.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 06:30:04 -0000 John Baldwin skrev: > So I upgraded a test box today to HEAD and got my first taste of the trimmed > down boot messages. I can appreciate the slimness of them. However, > personally I actually find the detail useful (at least sometimes). > Unfortunately, there doesn't appear to be a knob I can flip to actually get > all the messages back as /etc/rc unconditionally uses 'quietstart' rather > than 'start'. Am I the only one who finds it useful to know which daemon is > making my startup hang for an extra second? +1. -- Joel From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 07:26:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 062CD106566C for ; Thu, 24 Jul 2008 07:26:38 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F56E8FC12 for ; Thu, 24 Jul 2008 07:26:37 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KLvDe-0001KX-9X for freebsd-current@freebsd.org; Thu, 24 Jul 2008 07:26:34 +0000 Received: from utwig.xim.bz ([195.184.197.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Jul 2008 07:26:34 +0000 Received: from c.kworr by utwig.xim.bz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Jul 2008 07:26:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Volodymyr Kostyrko Date: Thu, 24 Jul 2008 10:26:27 +0300 Lines: 13 Message-ID: References: <200807231846.33728.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: utwig.xim.bz User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.16) Gecko/20080718 SeaMonkey/1.1.11 In-Reply-To: <200807231846.33728.jhb@freebsd.org> Sender: news Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 07:26:38 -0000 John Baldwin wrote: > So I upgraded a test box today to HEAD and got my first taste of the trimmed > down boot messages. I can appreciate the slimness of them. However, > personally I actually find the detail useful (at least sometimes). > Unfortunately, there doesn't appear to be a knob I can flip to actually get > all the messages back as /etc/rc unconditionally uses 'quietstart' rather > than 'start'. Am I the only one who finds it useful to know which daemon is > making my startup hang for an extra second? Tap ^T. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 12:02:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6781065670 for ; Thu, 24 Jul 2008 12:02:55 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by mx1.freebsd.org (Postfix) with ESMTP id 842D08FC28 for ; Thu, 24 Jul 2008 12:02:54 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1352089tid.3 for ; Thu, 24 Jul 2008 05:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:subject :message-id:mail-followup-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem:from; bh=1YxbedG5w9yJitE2B+PtkiPYdpRNZ2il5kmikBm5KLY=; b=EVtaTVD9RoCbkJFt0GVwzN2+9z6jCwKucAHd5Fj3KPcCIXpywiptsNuvKmcJPfBJTB kCLkT1OQFXne1EFUjT5x++RapARhMzyCAkNo/aW4MZRSYx0pRC5/5bLPdONWLDmHJRB4 lTW++3zci1dd92MciA6+4HaL/HKwlmv8tlz9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem:from; b=do1T7TeUtEyNyHwyzHm+ETOc/CRdFiGxvb2w810TyIhzxzAQkBKh4u+Wwgyt6b+Ke3 qUkaN8MV5zee/BNaPWtw5UT7RydpOhnUgSDOJDbGHszig0k0ixSw01wLz/a+pIhGzYIN 82HQxCsadjLVCuyV0SUqcU8ttJfaMyNx1RhMc= Received: by 10.110.20.17 with SMTP id 17mr185112tit.12.1216900971619; Thu, 24 Jul 2008 05:02:51 -0700 (PDT) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id j5sm18163710tid.12.2008.07.24.05.02.49 (version=SSLv3 cipher=RC4-MD5); Thu, 24 Jul 2008 05:02:50 -0700 (PDT) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Thu, 24 Jul 2008 21:02:10 +0900 Date: Thu, 24 Jul 2008 21:02:10 +0900 To: freebsd-current@freebsd.org Message-ID: <20080724120210.GA38346@freebsd.weongyo.org> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Subject: CFT/CFR: NDIS(4) USB support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 12:02:55 -0000 Hello All, It looks that NDIS USB support works for some USB wireless drivers so I'd like to call for tests to everyone who interested in NDIS for FreeBSD. I have 7 USB wireless adapters and with current NDIS USB support 4 of 7 adapters are supported. The detail is as follows: Working: U-Khan UW-2054i (Marvell Libertas chipset) Netgear WG111v2 (Intersil/Prism chipset) - supported by upgt(4) EFM-IPTIME G054U2 (Ralink RT2573) - supported by rum(4) ZCOM XM-142 (Intersil/Prism chipset, another revision) Not working: Unicorn WL-54G (ZyDAS zd1211b chipset) - supported by zyd(4) Attaching is working sucessfully and LED works fine but it's not UPed. Zyxel G-200v2 (ZyDAS zd1211 chipset) - supported by zyd(4) The sympotom is same with Unicorn WL-54G. SMCWUSBT-G-CA EZ 108Mbps (Atheros chipset) This NDIS driver uses some functions which aren't supported by current NDIS implementation. So I can't test it now. The patch for HEAD can be found at: http://people.freebsd.org/~weongyo/patch_ndisusb_20080724.diff When you try to test this patch, you should make sure that ndiscvt(8) is updated. Some instructions like below could be helpful: # cd /usr/src # patch -p0 < ~/patch_ndisusb_20080724.diff # cd usr.sbin/ndiscvt # make && make install # cd ~/ # ndisgen ABC.inf ABC.sys # cd /usr/src/sys/modules/ndis # make # kldload ./ndis.ko # cd /usr/src/sys/modules/if_ndis # make # kldload ./if_ndis.ko # kldload ~/ABC_sys.ko It seems that the current status of NDIS USB support is beta status so I'm not sure I've implemented all features yet that it needs more debugging and stability. I don't have all H/Ws for testing! :) Please tell me if you were successful or you failed though it looks it's not easy to debug NDIS .sys binary using disassembler. Any help and comments are welcome. Thanks. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 13:05:10 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013E9106564A; Thu, 24 Jul 2008 13:05:10 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id E36EF8FC0C; Thu, 24 Jul 2008 13:05:09 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.81.39]) by dire.wubethiopia.com (Postfix) with ESMTPSA id 9560A4FD9EB3; Thu, 24 Jul 2008 12:46:10 +0000 (UTC) Message-ID: <48887AFC.2060000@wubethiopia.com> Date: Thu, 24 Jul 2008 15:52:12 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: John Baldwin References: <200807231846.33728.jhb@freebsd.org> In-Reply-To: <200807231846.33728.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 13:05:10 -0000 John Baldwin wrote: > So I upgraded a test box today to HEAD and got my first taste of the trimmed > down boot messages. I can appreciate the slimness of them. However, > personally I actually find the detail useful (at least sometimes). > Unfortunately, there doesn't appear to be a knob I can flip to actually get > all the messages back as /etc/rc unconditionally uses 'quietstart' rather > than 'start'. Am I the only one who finds it useful to know which daemon is > making my startup hang for an extra second? > Heh, no you aren't. I'll be committing the functionality shortly. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 15:17:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B52E106566B for ; Thu, 24 Jul 2008 15:17:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 00EDF8FC12 for ; Thu, 24 Jul 2008 15:17:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2039482fgb.35 for ; Thu, 24 Jul 2008 08:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=aqMzyJ9ApFpImaCF6qRoGwNCHy9a9wDqgiA/vGL9of4=; b=TwfYueLvnBX241P2CW7eT7C8WePzGsh9iMy1x96LZJfOJ+DxE8bh5JHLJ3mMTkMEyO 6pxSFBhA34Gz8T/+osTdUSgBB3AoKTC0o6zt2+8WrOQNlyBaTKQZ1STXocO09uv0mPwE P2TxmCC+FHkEfKGwCL0ZXJeYNOq6krO+5de0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Pkp+ZPR1wt+hirF0MXAigeXgyIHffVtkPLd4hOmT5XWWBqoItpetGO2gCZfEYodnrT L1vRlVeeiMiEfxdyaEYdNqrHL2UcQJQoqdSfeGDXYNhKT6xeHAr/mNnOJkDeSx06gDah 1Jmy4xZV605858NlbXsNhMzqiCz1REPjZhTP0= Received: by 10.86.89.1 with SMTP id m1mr936618fgb.68.1216912672889; Thu, 24 Jul 2008 08:17:52 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Thu, 24 Jul 2008 08:17:52 -0700 (PDT) Message-ID: <3bbf2fe10807240817l7aedc58fnf56e54155d7beda7@mail.gmail.com> Date: Thu, 24 Jul 2008 17:17:52 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Rink Springer" In-Reply-To: <20080723153849.GA5117@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <3bbf2fe10807171306y59d30b13y868c1e27697412a7@mail.gmail.com> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> <20080723153849.GA5117@rink.nu> X-Google-Sender-Auth: 9df6260cfe5cd2d3 Cc: Lothar Braun , freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 15:17:54 -0000 2008/7/23 Rink Springer : > On Sun, Jul 20, 2008 at 06:26:04PM +0200, Attilio Rao wrote: >> 2008/7/20, Attilio Rao : >> > 2008/7/20, Lothar Braun : >> > >> > > Hi Attilio, >> > > >> > > >> > > >> > > > can you please try this on the top of -CURRENT: >> > > > http://www.freebsd.org/~attilio/xfs2.diff >> > > > >> > > >> > > Thank you for the patch. The panic and the dead lock disappeard, but there >> > > is a new problem insteed. The commands >> > > >> > > mkfs.xfs /dev/ad8s4 >> > > mount -t xfs /dev/ad8s4 /home >> > > mkdir /home/lothar >> > > chown lothar:lothar /home/lothar >> > >> > >> > For what I remind, it is likely XFS is still not ready for writing. >> > This means you should only use it in read-only. >> >> Speaking of which, I think we should mark it again like a read-only fs >> until writing is not 100% ready. > > NTFS suffers from the same issue; it 'kind of' supports writes. The > result is that it supports writes in so limited circumstances that the > write support is mostly useless (and it even tends to lead to panics...) > > I think a better solution is to mount such filesystems r/o by default, > and only mount them r/w if explicitely asked to do so, for example by '-o > rw' - it would make things a lot clearer for our users when trying to > use filesystems, and brave souls are always welcome to force r/w that > way. > > What do you think? As long as you state that the write support is almost useless, I think the better thing is that we should simply drop the write support for the moment (and leaving the implementation there, of course, so that interested hackers can keep solidifying the support). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 16:06:11 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373FC106564A for ; Thu, 24 Jul 2008 16:06:11 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFEA8FC16 for ; Thu, 24 Jul 2008 16:06:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id DB91B1A009B1A for ; Thu, 24 Jul 2008 08:33:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mw2AdrWbkrie for ; Thu, 24 Jul 2008 08:33:52 -0700 (PDT) Received: from coal (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 54DCF1A009B07 for ; Thu, 24 Jul 2008 08:33:52 -0700 (PDT) From: Freddie Cash To: current@freebsd.org Date: Thu, 24 Jul 2008 08:33:51 -0700 User-Agent: KMail/1.9.9 References: <200807231846.33728.jhb@freebsd.org> <5f67a8c40807231949i2b2514bbw78dd36cf418cf573@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807240833.51750.fjwcash@gmail.com> Cc: Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 16:06:11 -0000 On July 23, 2008 08:21 pm Daniel Eischen wrote: > On Wed, 23 Jul 2008, Zaphod Beeblebrox wrote: > > On Wed, Jul 23, 2008 at 9:04 PM, Daniel Eischen > > > > > > wrote: > >> On Wed, 23 Jul 2008, John Baldwin wrote: > >> > >> than 'start'. Am I the only one who finds it useful to know which > >> daemon > >> > >>> is > >>> making my startup hang for an extra second? > >> > >> No, you are not. I too would like that. > > > > I'd go further: it was nice when startup scripts printed their name > > (no newline) and then '.\n' when they were finished. It then becomes > > unambiguous who is at fault. It's hard to tell with the current > > non-system which of the 2 scrpts (the one that has printed it's name, > > or the one that next prints it's name) is at fault. Worse.. it could > > be the quiet script in between. > > Agreed, but you could delineate it with something other than '\n" too. > Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is > done and has moved on to the next service. I like that. [ means processing has started, name is the service/script runnging, ] means processing of that script has completed. All the info you need for multiple services, all on one line. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 17:02:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69279106566C for ; Thu, 24 Jul 2008 17:02:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id EA59C8FC20 for ; Thu, 24 Jul 2008 17:02:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2079803fgb.35 for ; Thu, 24 Jul 2008 10:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Y962LyPYKaWTnoW0wSK+p1wy37Ns40GJ53ZY0YeF5+8=; b=sWfi7xFSWQ1VZ4nRUZICBAvI+iK5qrX48aRGaCuUw7hIR1pJGkvn7a03+UkYKiRc8v xrceqTAIg+nDwfKr/oripbSojM6dv7Jg3300HQkwzDm0WmPP1pzwS5/afjiM6cMrC6lQ 0k3uRHAlPhLWVyltii28rNnqAM0+amb0R2J4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pTzL0xUBT++Vb/LWqoP9QvJGvWtM1oW7vGsCXL0wTUgqgP0MhipedngzOWadMsKUMX Kjn+rfcoipLP/elPiX1qAOy6RHIEHqzAzm+TaKEEYYbFlw/osgqbF5Y57MRAw7jRrZ7e YFnFTmEFD5QgNbWyMKFyVh6l06CNvjXWAFbSc= Received: by 10.86.51.10 with SMTP id y10mr1069377fgy.6.1216918959700; Thu, 24 Jul 2008 10:02:39 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Thu, 24 Jul 2008 10:02:39 -0700 (PDT) Message-ID: <7d6fde3d0807241002u66f90717rbb3b97efa76423fd@mail.gmail.com> Date: Thu, 24 Jul 2008 10:02:39 -0700 From: "Garrett Cooper" To: "Attilio Rao" In-Reply-To: <3bbf2fe10807240817l7aedc58fnf56e54155d7beda7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <487F32C6.5030502@lobraun.de> <48805EEE.90109@lobraun.de> <48806684.4000908@FreeBSD.org> <4880921C.10700@lobraun.de> <3bbf2fe10807190827k24c738c9s4f258ac006035b75@mail.gmail.com> <48833C50.8030507@lobraun.de> <3bbf2fe10807200904y32cc6d04n94bc262aa3c6c2be@mail.gmail.com> <3bbf2fe10807200926k5aa8fd2an7b2689f92bbba05d@mail.gmail.com> <20080723153849.GA5117@rink.nu> <3bbf2fe10807240817l7aedc58fnf56e54155d7beda7@mail.gmail.com> Cc: Rink Springer , Lothar Braun , freebsd-current@freebsd.org Subject: Re: panic: __lockmgr_args: unknown lockmgr request 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 17:02:42 -0000 On Thu, Jul 24, 2008 at 8:17 AM, Attilio Rao wrote: > 2008/7/23 Rink Springer : >> On Sun, Jul 20, 2008 at 06:26:04PM +0200, Attilio Rao wrote: >>> 2008/7/20, Attilio Rao : >>> > 2008/7/20, Lothar Braun : >>> > >>> > > Hi Attilio, >>> > > >>> > > >>> > > >>> > > > can you please try this on the top of -CURRENT: >>> > > > http://www.freebsd.org/~attilio/xfs2.diff >>> > > > >>> > > >>> > > Thank you for the patch. The panic and the dead lock disappeard, but there >>> > > is a new problem insteed. The commands >>> > > >>> > > mkfs.xfs /dev/ad8s4 >>> > > mount -t xfs /dev/ad8s4 /home >>> > > mkdir /home/lothar >>> > > chown lothar:lothar /home/lothar >>> > >>> > >>> > For what I remind, it is likely XFS is still not ready for writing. >>> > This means you should only use it in read-only. >>> >>> Speaking of which, I think we should mark it again like a read-only fs >>> until writing is not 100% ready. >> >> NTFS suffers from the same issue; it 'kind of' supports writes. The >> result is that it supports writes in so limited circumstances that the >> write support is mostly useless (and it even tends to lead to panics...) >> >> I think a better solution is to mount such filesystems r/o by default, >> and only mount them r/w if explicitely asked to do so, for example by '-o >> rw' - it would make things a lot clearer for our users when trying to >> use filesystems, and brave souls are always welcome to force r/w that >> way. >> >> What do you think? > > As long as you state that the write support is almost useless, I think > the better thing is that we should simply drop the write support for > the moment (and leaving the implementation there, of course, so that > interested hackers can keep solidifying the support). > > Thanks, > Attilio Knobs per src.conf for fs experimental functionality? -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 18:17:44 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1E01065671 for ; Thu, 24 Jul 2008 18:17:44 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 13D968FC0A for ; Thu, 24 Jul 2008 18:17:43 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.2/8.14.2) with ESMTP id m6OHmh5w096319 for ; Thu, 24 Jul 2008 14:48:43 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Thu, 24 Jul 2008 14:48:30 -0300 User-Agent: KMail/1.9.7 References: <200807231846.33728.jhb@freebsd.org> <200807240833.51750.fjwcash@gmail.com> In-Reply-To: <200807240833.51750.fjwcash@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807241448.30627.joao@matik.com.br> X-Virus-Scanned: ClamAV 0.93.1/7815/Thu Jul 24 12:09:44 2008 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 18:17:44 -0000 On Thursday 24 July 2008 12:33:51 Freddie Cash wrote: > On July 23, 2008 08:21 pm Daniel Eischen wrote: > > On Wed, 23 Jul 2008, Zaphod Beeblebrox wrote: > > > On Wed, Jul 23, 2008 at 9:04 PM, Daniel Eischen > > > > > > > > > wrote: > > >> On Wed, 23 Jul 2008, John Baldwin wrote: > > >> > > >> than 'start'. Am I the only one who finds it useful to know which > > >> daemon > > >> > > >>> is > > >>> making my startup hang for an extra second? > > >> > > >> No, you are not. I too would like that. > > > > > > I'd go further: it was nice when startup scripts printed their name > > > (no newline) and then '.\n' when they were finished. It then becomes > > > unambiguous who is at fault. It's hard to tell with the current > > > non-system which of the 2 scrpts (the one that has printed it's name, > > > or the one that next prints it's name) is at fault. Worse.. it could > > > be the quiet script in between. > > > > Agreed, but you could delineate it with something other than '\n" too. > > Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is > > done and has moved on to the next service. > > I like that. [ means processing has started, name is the service/script > runnging, ] means processing of that script has completed. All the info > you need for multiple services, all on one line. simply another wiered outcome - not understandable btw same as this mystica= l=20 dot thing=20 something more obvious would be: starting $service_name ... up starting $service_name ... up =2E.. that would be something clear, specially for whom did not invented it =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:19:54 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47C851065671 for ; Thu, 24 Jul 2008 19:19:54 +0000 (UTC) (envelope-from sven@dmv.com) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0768FC15 for ; Thu, 24 Jul 2008 19:19:53 +0000 (UTC) (envelope-from sven@dmv.com) Received: from [216.240.97.46] (lanshark.dmv.com [216.240.97.46]) by smtp-gw-cl-d.dmv.com (8.12.10/8.12.10) with ESMTP id m6OIqfN0047987; Thu, 24 Jul 2008 14:52:42 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Maurice Volaski In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Zl3QXM2dyhM6PkBzcIMF" Date: Thu, 24 Jul 2008 14:52:41 -0400 Message-Id: <1216925561.6489.6.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Scanned-By: MIMEDefang 2.48 on 216.240.97.42 Cc: freebsd-current@freebsd.org, pjd@freebsd.org Subject: Re: Would ZFS and gmirror work well together in a two-node failover cluster? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 19:19:54 -0000 --=-Zl3QXM2dyhM6PkBzcIMF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-07-18 at 12:06 -0400, Maurice Volaski wrote: > I am looking to put together a two-node high-availability cluster=20 > where each node has identical data storage consisting of a set of=20 > internal data drives (separate from the boot drive). I want ZFS to=20 > manage the drives as a JDBOD in a RAIDZ2 configuration. Thus, if an=20 > individual drive misbehaves or fails, ZFS detects and handles the=20 > fault. >=20 > But I'm also looking to mirror this entire setup in real time to a=20 > second identical server. >=20 > Basically, my question is can this work well on FreeBSD while taking=20 > full advantage of ZFS? >=20 > Specifically, my understanding is that the only way to handle the=20 > real time mirror is with gmirror and ggated, but it's not clear how=20 > gmirror would interact with ZFS. >=20 My findings have been that ZFS and ggate[cd] do *not* play nicely together so I would concur taht gmirror/ggate[cd] would be the way to create a real-time mirror. (For those interested, I have posted some information on how ggate[cd] and zpool will cause lockups rendering it unsuitable for real-time multi-host mirroring over on -STABLE). > I am assuming that gmirror operates only on individual drives, so if=20 > I had a set of 24 drives on each server, there would be 24 mirrored=20 > drive pairs. >=20 > One concern I have is that this setup could run into trouble with=20 > gmirror's potentially sabotaging ZFS's RAIDZ2. For example, when a=20 > drive starts failing, won't gmirror see it before ZFS does and take=20 > the unfavorable action of substituting the corresponding drive in the=20 > failover server in subsequent I/O, leaving ZFS's RAIDZ2 out of the=20 > loop? >=20 > This is just one particular scenario, but in general, it's not=20 > entirely clear that it's possible to have fine-grained control of=20 > when, how much and in what direction gmirror manages synchronization=20 > among drive pairs. >=20 > -Maurice As was suggested in other followups, it would seem that zfs send/recv may be a viable option depending on whethere it is granular enough (timewise) to be practical. As far as failover goes (e.g. yank power cord out) your best bet would be using CARP as a virtual IP and using devd or ifstated to trigger an event on CARP interface change (from BACKUP to MASTER or vice-versa). I would be interested in seeing how well the zfs option of snapshots would work as rebuilding a 500GB gmirror is really a lengthy process ... Sven --=-Zl3QXM2dyhM6PkBzcIMF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBIiM95Snmnd8q3JGsRAkWCAJ9wqgLFhdygQbnV07k2sXChdhznAACdGcAV Slp9cGV01W3JaBWYGBciDN0= =TwiU -----END PGP SIGNATURE----- --=-Zl3QXM2dyhM6PkBzcIMF-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:30:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9E5106567B for ; Thu, 24 Jul 2008 19:30:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id B3EC18FC14 for ; Thu, 24 Jul 2008 19:30:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 825C919E023; Thu, 24 Jul 2008 21:30:11 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 74F7119E019; Thu, 24 Jul 2008 21:30:09 +0200 (CEST) Message-ID: <4888D859.3090809@quip.cz> Date: Thu, 24 Jul 2008 21:30:33 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: JoaoBR References: <200807231846.33728.jhb@freebsd.org> <200807240833.51750.fjwcash@gmail.com> <200807241448.30627.joao@matik.com.br> In-Reply-To: <200807241448.30627.joao@matik.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 19:30:14 -0000 JoaoBR wrote: [...] >>>>I'd go further: it was nice when startup scripts printed their name >>>>(no newline) and then '.\n' when they were finished. It then becomes >>>>unambiguous who is at fault. It's hard to tell with the current >>>>non-system which of the 2 scrpts (the one that has printed it's name, >>>>or the one that next prints it's name) is at fault. Worse.. it could >>>>be the quiet script in between. >>> >>>Agreed, but you could delineate it with something other than '\n" too. >>>Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is >>>done and has moved on to the next service. >> >>I like that. [ means processing has started, name is the service/script >>runnging, ] means processing of that script has completed. All the info >>you need for multiple services, all on one line. > > > simply another wiered outcome - not understandable btw same as this mystical > dot thing > > something more obvious would be: > > starting $service_name ... up > starting $service_name ... up > ... > > that would be something clear, specially for whom did not invented it It seems too verbose. (does anybody expect "stoping" service on system boot?) And each service on separate line seems to me like vaste of space. Line like "[ssh] [smtp] [dhcpd] [mysql]" is enough for me. It is easy to document it in handbook and man pages. Just my 0.02 Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:36:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97C9106567D for ; Thu, 24 Jul 2008 19:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id A8ACF8FC0A for ; Thu, 24 Jul 2008 19:36:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 40DD923F9; Thu, 24 Jul 2008 12:36:18 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id ACD012D6061; Thu, 24 Jul 2008 12:36:17 -0700 (PDT) Message-ID: <4888D995.5000908@elischer.org> Date: Thu, 24 Jul 2008 12:35:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <200807231846.33728.jhb@freebsd.org> <200807240833.51750.fjwcash@gmail.com> <200807241448.30627.joao@matik.com.br> <4888D859.3090809@quip.cz> In-Reply-To: <4888D859.3090809@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, JoaoBR Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 19:36:18 -0000 Miroslav Lachman wrote: > JoaoBR wrote: > > [...] > >>>>> I'd go further: it was nice when startup scripts printed their name >>>>> (no newline) and then '.\n' when they were finished. It then becomes >>>>> unambiguous who is at fault. It's hard to tell with the current >>>>> non-system which of the 2 scrpts (the one that has printed it's name, >>>>> or the one that next prints it's name) is at fault. Worse.. it could >>>>> be the quiet script in between. >>>> >>>> Agreed, but you could delineate it with something other than '\n" too. >>>> Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is >>>> done and has moved on to the next service. >>> >>> I like that. [ means processing has started, name is the service/script >>> runnging, ] means processing of that script has completed. All the info >>> you need for multiple services, all on one line. >> >> >> simply another wiered outcome - not understandable btw same as this >> mystical dot thing >> something more obvious would be: >> >> starting $service_name ... up >> starting $service_name ... up >> ... >> >> that would be something clear, specially for whom did not invented it > > It seems too verbose. (does anybody expect "stoping" service on system > boot?) And each service on separate line seems to me like vaste of space. > Line like "[ssh] [smtp] [dhcpd] [mysql]" is enough for me. > It is easy to document it in handbook and man pages. if we start doing things in parallel then you need to know who has started running and you need to knwo when they finished. otherwise you don't know who it is that has hung and is stopping your boot. [amd starting]...[amd successful] [smtpd starting]... [smptd succcessful] or maybe: [amd starting]...[smtpd starting]...[smptd succcessful]...[amd successful] etc.. > > Just my 0.02 > > Miroslav Lachman > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 24 19:19:42 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F6BD1065672 for ; Thu, 24 Jul 2008 19:19:42 +0000 (UTC) (envelope-from Melzer.Pinto@sig.com) Received: from blink.balmail.susq.com (ext157.sig.com [141.162.101.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE248FC0A for ; Thu, 24 Jul 2008 19:19:42 +0000 (UTC) (envelope-from Melzer.Pinto@sig.com) Received: from secspambal104.susq.com (localhost [127.0.0.1]) by blink.balmail.susq.com (8.12.10/8.12.10) with SMTP id m6OJ0KW7008804 for ; Thu, 24 Jul 2008 15:00:20 -0400 (EDT) Received: from (unknown [10.10.128.214]) by secspambal104.susq.com with smtp id 22c8_c2a05f48_59b2_11dd_a52b_0019b9eb1a81; Thu, 24 Jul 2008 15:00:19 -0400 Received: from msgbal514.ds.susq.com ([10.10.128.206]) by msgbal522.ds.susq.com ([10.10.128.214]) with mapi; Thu, 24 Jul 2008 15:00:19 -0400 From: "Pinto, Melzer" To: "freebsd-current@freebsd.org" Date: Thu, 24 Jul 2008 15:00:18 -0400 Thread-Topic: iscsi software inititator Thread-Index: Acjtv4OqPWoVah70QXCbI5weLGihuw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Jul 2008 21:57:57 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: iscsi software inititator X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 19:19:42 -0000 I'm trying to install an iscsi software initiator on a 64 bit machine. I wa= s able to untar the linux-iscsi 4.0.2 version and also install the kernel s= ource. However when I try to 'make' it gives an error Melzer:/iscsisata/linux-iscsi-4.0.2 # make Note: using kernel source from /lib/modules/2.6.16.46-0.12-smp/build containing kernel version 2.6. Note: using kernel config from /lib/modules/2.6.16.46-0.12-smp/build/.config make[1]: Entering directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' make -C ../../../linux-2.6.16.46-0.12 O=3D../linux-2.6.16.46-0.12-obj/x86_6= 4/smp modules CC [M] /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: error: code model = `kernel' not supported in the 32 bit mode /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: sorry, unimplement= ed: 64-bit mode not compiled in make[4]: *** [/iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o] Error = 1 make[3]: *** [_module_/iscsisata/linux-iscsi-4.0.2/driver] Error 2 make[2]: *** [modules] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' make: *** [module] Error 2 I have a 64 bit machine and this app is 64 bit one. Can anyone figure this = out? This article might make it easier to understand what I'm trying to do http://www.cuddletech.com/articles/iscsi/ar01s04.html Thanks Melzer Pinto ________________________________ IMPORTANT: The information contained in this email and/or its attachments i= s confidential. If you are not the intended recipient, please notify the se= nder immediately by reply and immediately delete this message and all its a= ttachments. Any review, use, reproduction, disclosure or dissemination of t= his message or any attachment by an unintended recipient is strictly prohib= ited. Neither this message nor any attachment is intended as or should be c= onstrued as an offer, solicitation or recommendation to buy or sell any sec= urity or other financial instrument. Neither the sender, his or her employe= r nor any of their respective affiliates makes any warranties as to the com= pleteness or accuracy of any of the information contained herein or that th= is message or any of its attachments is free of viruses. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 00:48:38 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BEAB1065689 for ; Fri, 25 Jul 2008 00:48:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 725B38FC08 for ; Fri, 25 Jul 2008 00:48:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 86E8423F1; Thu, 24 Jul 2008 17:49:00 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E5E102D6037; Thu, 24 Jul 2008 17:48:37 -0700 (PDT) Message-ID: <488922C3.1040802@elischer.org> Date: Thu, 24 Jul 2008 17:48:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Pinto, Melzer" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: iscsi software inititator X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 00:48:38 -0000 Pinto, Melzer wrote: > I'm trying to install an iscsi software initiator on a 64 bit machine. > I was able to untar the linux-iscsi 4.0.2 version and also install the kernel > source. However when I try to 'make' it gives an error > > Melzer:/iscsisata/linux-iscsi-4.0.2 # make > > Note: using kernel source from /lib/modules/2.6.16.46-0.12-smp/build > containing kernel version 2.6. > > Note: using kernel config from > /lib/modules/2.6.16.46-0.12-smp/build/.config > > make[1]: Entering directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' > make -C ../../../linux-2.6.16.46-0.12 O=../linux-2.6.16.46-0.12-obj/x86_64/smp modules > CC [M] /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o > /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: error: code model `kernel' not > supported in the 32 bit mode > /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: sorry, unimplemented: 64-bit > mode not compiled in > make[4]: *** [/iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o] Error 1 > make[3]: *** [_module_/iscsisata/linux-iscsi-4.0.2/driver] Error 2 > make[2]: *** [modules] Error 2 > make[1]: *** [modules] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' > make: *** [module] Error 2 > > > I have a 64 bit machine and this app is 64 bit one. Can anyone figure this out? > > This article might make it easier to understand what I'm trying to do I see what you are trying to do but I don't see why you are asking on a FreeBSD mailing list? > > http://www.cuddletech.com/articles/iscsi/ar01s04.html > > > Thanks > Melzer Pinto > > > ________________________________ > IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 10:47:27 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02E8D1065677 for ; Fri, 25 Jul 2008 10:47:27 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id A11368FC18 for ; Fri, 25 Jul 2008 10:47:26 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id 686943FAA for ; Fri, 25 Jul 2008 11:47:25 +0100 (BST) Message-Id: <917122D1-007F-4C2D-8437-D8B7059CAE34@rabson.org> From: Doug Rabson To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 25 Jul 2008 11:47:25 +0100 X-Mailer: Apple Mail (2.928.1) Cc: Subject: NFS and nmount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 10:47:27 -0000 Does anyone have patches that integrates NFS with nmount a bit more usefully than it does right now? At the moment it just packs its legacy nfs_args structure into a single nmount option which makes it hard to extend. Ideally all the various NFS options should be passed as individual nmount options. If there aren't any existing patches, I will probably work on this since I need to add stuff for GSS-API authentication options. From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 08:31:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE112106564A for ; Fri, 25 Jul 2008 08:31:55 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 44F3E8FC12 for ; Fri, 25 Jul 2008 08:31:55 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman-macbook.lon.namesco.net (126.117-84-212.staticip.namesco.net [212.84.117.126]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m6P8VvoE069780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 09:31:58 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <48898F77.9030909@unsane.co.uk> Date: Fri, 25 Jul 2008 09:31:51 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Pinto, Melzer" References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Jul 2008 11:07:00 +0000 Cc: "freebsd-current@freebsd.org" Subject: Re: iscsi software inititator X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 08:31:56 -0000 You could try FreeBSD, it has one included in the base system. ;) Pinto, Melzer wrote: > I'm trying to install an iscsi software initiator on a 64 bit machine. I was able to untar the linux-iscsi 4.0.2 version and also install the kernel source. However when I try to 'make' it gives an error > > Melzer:/iscsisata/linux-iscsi-4.0.2 # make > > Note: using kernel source from /lib/modules/2.6.16.46-0.12-smp/build > containing kernel version 2.6. > > Note: using kernel config from > /lib/modules/2.6.16.46-0.12-smp/build/.config > > make[1]: Entering directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' > make -C ../../../linux-2.6.16.46-0.12 O=../linux-2.6.16.46-0.12-obj/x86_64/smp modules > CC [M] /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o > /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: error: code model `kernel' not supported in the 32 bit mode > /iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.c:1: sorry, unimplemented: 64-bit mode not compiled in > make[4]: *** [/iscsisata/linux-iscsi-4.0.2/driver/iscsi-initiator.o] Error 1 > make[3]: *** [_module_/iscsisata/linux-iscsi-4.0.2/driver] Error 2 > make[2]: *** [modules] Error 2 > make[1]: *** [modules] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.6.16.46-0.12-obj/x86_64/smp' > make: *** [module] Error 2 > > > I have a 64 bit machine and this app is 64 bit one. Can anyone figure this out? > > This article might make it easier to understand what I'm trying to do > > http://www.cuddletech.com/articles/iscsi/ar01s04.html > > > Thanks > Melzer Pinto > > > ________________________________ > IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 13:11:47 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71A2C106564A for ; Fri, 25 Jul 2008 13:11:47 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id E09E08FC16 for ; Fri, 25 Jul 2008 13:11:44 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id m6PDBfLU012535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 17:11:42 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMN5B-000MYN-1M; Fri, 25 Jul 2008 17:11:41 +0400 From: Vladimir Grebenschikov To: freebsd-mobile Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Fri, 25 Jul 2008 17:11:40 +0400 Message-Id: <1216991500.1765.35.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current Subject: Hard lockup CURRENT lockup with ath0 and no wireless networks in proximity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 13:11:47 -0000 Hi all I have more or less recent 8-CURRENT. And I've noticed that attempt to start wireless (start of wpa_supplicatnt) when there is no wireless networks in proximity leads to hard lockup of notebook, even DDB can't be called. I have IBM T60 with: FreeBSD 8.0-CURRENT #3: Tue Jul 15 14:42:12 MSD 2008 root@vbook:/usr/obj/usr/src/sys/VBOOK ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 10.3 phy 6.1 radio 10.2 wlan0: Ethernet address: 00:19:7d:44:44:44 Once I've noticed extremely high interrupt rate before lockup. In case when there is wireless networks around everything goes as expected. Any hints will be very appreciated. -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:27:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023601065675 for ; Fri, 25 Jul 2008 16:27:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 992A18FC1F for ; Fri, 25 Jul 2008 16:27:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6PGRDEg071433; Fri, 25 Jul 2008 12:27:14 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Jul 2008 11:19:30 -0400 User-Agent: KMail/1.9.7 References: <200807231846.33728.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807251119.30364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 25 Jul 2008 12:27:14 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7826/Fri Jul 25 08:51:06 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Volodymyr Kostyrko Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 16:27:21 -0000 On Thursday 24 July 2008 03:26:27 am Volodymyr Kostyrko wrote: > John Baldwin wrote: > > So I upgraded a test box today to HEAD and got my first taste of the trimmed > > down boot messages. I can appreciate the slimness of them. However, > > personally I actually find the detail useful (at least sometimes). > > Unfortunately, there doesn't appear to be a knob I can flip to actually get > > all the messages back as /etc/rc unconditionally uses 'quietstart' rather > > than 'start'. Am I the only one who finds it useful to know which daemon is > > making my startup hang for an extra second? > > Tap ^T. Knowing that 'sleep' is running isn't always helpful. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:27:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01EC81065674 for ; Fri, 25 Jul 2008 16:27:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5553F8FC15 for ; Fri, 25 Jul 2008 16:27:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6PGRDEh071433; Fri, 25 Jul 2008 12:27:20 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 25 Jul 2008 11:22:01 -0400 User-Agent: KMail/1.9.7 References: <917122D1-007F-4C2D-8437-D8B7059CAE34@rabson.org> In-Reply-To: <917122D1-007F-4C2D-8437-D8B7059CAE34@rabson.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807251122.02120.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 25 Jul 2008 12:27:21 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7826/Fri Jul 25 08:51:06 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: NFS and nmount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 16:27:29 -0000 On Friday 25 July 2008 06:47:25 am Doug Rabson wrote: > Does anyone have patches that integrates NFS with nmount a bit more > usefully than it does right now? At the moment it just packs its > legacy nfs_args structure into a single nmount option which makes it > hard to extend. Ideally all the various NFS options should be passed > as individual nmount options. If there aren't any existing patches, I > will probably work on this since I need to add stuff for GSS-API > authentication options. Please do. People at work keep asking why they can't see NFS options like tcp vs udp in 'mount' output for mounted filesystems, so it is sort of on my todo list, but I haven't started on it at all. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 17:02:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2032D1065671 for ; Fri, 25 Jul 2008 17:02:18 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9564E8FC08 for ; Fri, 25 Jul 2008 17:02:17 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.2/8.14.2) with ESMTP id m6PH2EWd032947; Fri, 25 Jul 2008 14:02:14 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org Date: Fri, 25 Jul 2008 14:02:00 -0300 User-Agent: KMail/1.9.7 References: <200807231846.33728.jhb@freebsd.org> <200807241448.30627.joao@matik.com.br> <4888D859.3090809@quip.cz> In-Reply-To: <4888D859.3090809@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200807251402.00871.joao@matik.com.br> X-Virus-Scanned: ClamAV 0.93.1/7826/Fri Jul 25 09:51:06 2008 on msrv.matik.com.br X-Virus-Status: Clean Cc: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 17:02:18 -0000 On Thursday 24 July 2008 16:30:33 Miroslav Lachman wrote: > JoaoBR wrote: > > [...] > > >>>>I'd go further: it was nice when startup scripts printed their name > >>>>(no newline) and then '.\n' when they were finished. It then becomes > >>>>unambiguous who is at fault. It's hard to tell with the current > >>>>non-system which of the 2 scrpts (the one that has printed it's name, > >>>>or the one that next prints it's name) is at fault. Worse.. it could > >>>>be the quiet script in between. > >>> > >>>Agreed, but you could delineate it with something other than '\n" too. > >>>Like '[amd] [smtp] [dhcpd] ...', with the ']' meaning the script is > >>>done and has moved on to the next service. > >> > >>I like that. [ means processing has started, name is the service/script > >>runnging, ] means processing of that script has completed. All the info > >>you need for multiple services, all on one line. > > > > simply another wiered outcome - not understandable btw same as this > > mystical dot thing > > > > something more obvious would be: > > > > starting $service_name ... up > > starting $service_name ... up > > ... > > > > that would be something clear, specially for whom did not invented it > > It seems too verbose. (does anybody expect "stoping" service on system > boot?) And each service on separate line seems to me like vaste of space. > Line like "[ssh] [smtp] [dhcpd] [mysql]" is enough for me. > It is easy to document it in handbook and man pages. > > Just my 0.02 > well, the obvious often is'nt :)=20 for me it would be something like: starting $service_name ... up starting $service_name ... failed starting $service_name ... up what waste of space? running lines not buffered but in dmesg.*=20 anyway the waste of space is it worse as price for clearness and as I said before what is clear for the inventor or for you and me is on= e=20 thing but when you're supporting a remote server which is not coming up and= =20 a "not-knowing-the-secret" person eventual in another language (not english= =20 speaking) needs to say it ... well, then my friend, when this happens to yo= u=20 then you will remember this thread and will bite your ass for not having=20 agreed ... :) =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 19:01:13 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB7F106567D for ; Fri, 25 Jul 2008 19:01:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2FE8FC20 for ; Fri, 25 Jul 2008 19:01:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6FD7419E023; Fri, 25 Jul 2008 21:01:11 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 53FC619E019; Fri, 25 Jul 2008 21:01:09 +0200 (CEST) Message-ID: <488A2310.7070008@quip.cz> Date: Fri, 25 Jul 2008 21:01:36 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: JoaoBR References: <200807231846.33728.jhb@freebsd.org> <200807241448.30627.joao@matik.com.br> <4888D859.3090809@quip.cz> <200807251402.00871.joao@matik.com.br> In-Reply-To: <200807251402.00871.joao@matik.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: I like my rc.d boot messages :( X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 19:01:13 -0000 JoaoBR wrote: > On Thursday 24 July 2008 16:30:33 Miroslav Lachman wrote: > >>JoaoBR wrote: [...] >>>something more obvious would be: >>> >>>starting $service_name ... up >>>starting $service_name ... up >>>... >>> >>>that would be something clear, specially for whom did not invented it >> >>It seems too verbose. (does anybody expect "stoping" service on system >>boot?) And each service on separate line seems to me like vaste of space. >>Line like "[ssh] [smtp] [dhcpd] [mysql]" is enough for me. >>It is easy to document it in handbook and man pages. >> >>Just my 0.02 >> > > > well, the obvious often is'nt :) > for me it would be something like: > > starting $service_name ... up > starting $service_name ... failed > starting $service_name ... up > > what waste of space? running lines not buffered but in dmesg.* > anyway the waste of space is it worse as price for clearness > > and as I said before what is clear for the inventor or for you and me is one > thing but when you're supporting a remote server which is not coming up and > a "not-knowing-the-secret" person eventual in another language (not english > speaking) needs to say it ... well, then my friend, when this happens to you > then you will remember this thread and will bite your ass for not having > agreed ... :) What waste? Let's imagine starting too many services, that useful information already scrolled out of the screen too quickly because each service has it's own line... it is just another point of view of the same problem with person on the phone and that's why I can't agree ;o) I am not saying your version is bad, just I don't need it that verbose, I'll be happier with "oneline for all". Maybe there could be some verbosity switch for users choice: 0 - show nothing 1 - show just names in brackets on one line 2 - show full line with named state on separate lines But maybe this is too complex solution for this easy task... YMMV Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 20:16:51 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3531065679; Fri, 25 Jul 2008 20:16:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 658FF8FC16; Fri, 25 Jul 2008 20:16:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6PKGjtV073014; Fri, 25 Jul 2008 16:16:45 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Fri, 25 Jul 2008 16:16:30 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807251616.30249.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 25 Jul 2008 16:16:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7827/Fri Jul 25 14:13:59 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arm@freebsd.org Subject: PATCH: iicbus(4) locking, please test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 20:16:51 -0000 I have a first attempt at adding locking to iicbus(4). Originally my goal was to do this so if_ic(4) could be locked. However, if_ic(4) does evil things in its ioctl routine so I'm actually going to leave that alone unless someone says they want to test possible changes. Back to iicbus(4), this patch adds locking to the core of iicbus and the various related drivers. A few drivers (ixp_iic, lpbb, and bktr) just use Giant for their driver lock for now. It has been compiled on my laptop (i386) but not anything else yet. http://www.FreeBSD.org/~jhb/patches/iicbus.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 22:08:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CDA91065687 for ; Fri, 25 Jul 2008 22:08:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 34C538FC1D for ; Fri, 25 Jul 2008 22:08:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6PLTx11077942; Fri, 25 Jul 2008 17:29:59 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m6PLTwhs021540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 17:29:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200807252129.m6PLTwhs021540@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jul 2008 17:30:01 -0400 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 22:08:04 -0000 At 12:02 PM 6/6/2008, Marcel Moolenaar wrote: >On Jun 6, 2008, at 5:59 AM, Mike Tancsa wrote: > >>I have been starting to take a look at moving some of our embedded >>platforms to RELENG_7 and noticed that support for the 3Com PCI >>cards are broken. Previously, in pucdata.c, they were defined as >> >> /* US Robotics (3Com) PCI Modems */ >> { "US Robotics (3Com) 3CP5609 PCI 16550 Modem", >> { 0x12b9, 0x1008, 0, 0 }, >> { 0xffff, 0xffff, 0, 0 }, >> { >> { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, >> }, >> }, >> >> >>However, in the newer version they are not there, and uart is not >>picking up the device. > >Since this is a single-port UART, puc(4) is not supposed to have >support for it. The uart(4) can handle it without needing puc(4). >However, that implies that uart(4) needs to have the support for >it and I guess that's not present. Hi, I am finally getting back to this project again and am now looking at a more recent version of RELENG_7 post the UART re-write. It now shows a bit of a different problem. I have a 5501 Soekris and if I boot with uart just in the kernel, all seems to work well. I updated the /boot/device.hints to reflect uart instead of sio and I can see the system console. However, if I have the 3com PCI modem installed, cuau0 becomes the modem and I am not able to login via the console 1 FreeBSD 2 FreeBSD Default: 1 /boot.config: -h FreeBSD/i386 boot Default: 0:ad(0,a)/boot/loader boot: Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (mdtancsa@releng7.sentex.ca, Wed Jul 23 12:29:59 EDT 2008) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x36ab14 data=0x325e0+0x2182c syms=[0x4+0x41890+0x4+0x544d6] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Wed Jul 23 12:49:33 EDT 2008 mdtancsa@releng7.sentex.ca:/usr/obj/nanobsd.soekris5501/usr/src/sys/nano5501 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (433.25-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 253218816 (241 MB) K6-family MTRR support enabled (2 registers) cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 Geode LX: Soekris net5501 comBIOS ver. 1.33 20070103 Copyright (C) 2000-2007 MFGPT bar: f00100006200 pci0: at device 1.2 (no driver attached) vr0: port 0xe100-0xe1ff mem 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0 vr0: Quirks: 0x6 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:24:ca:41:dc vr0: [ITHREAD] vr1: port 0xe200-0xe2ff mem 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0 vr1: Quirks: 0x6 vr1: Revision: 0x96 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:00:24:ca:41:dd vr1: [ITHREAD] vr2: port 0xe300-0xe3ff mem 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0 vr2: Quirks: 0x6 vr2: Revision: 0x96 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr2: Ethernet address: 00:00:24:ca:41:de vr2: [ITHREAD] vr3: port 0xe400-0xe4ff mem 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0 vr3: Quirks: 0x6 vr3: Revision: 0x96 miibus3: on vr3 ukphy3: PHY 1 on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr3: Ethernet address: 00:00:24:ca:41:df vr3: [ITHREAD] uart0: port 0xe500-0xe507 irq 10 at device 14.0 on pci0 uart0: [FILTER] isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xa0005000-0xa0005fff irq 15 at device 21.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xa0006000-0xa0006fff irq 15 at device 21.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered cpu0 on motherboard orm0: at iomem 0xc8000-0xd27ff pnpid ORM0000 on isa0 uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounter "TSC" frequency 433251618 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 1953MB at ata0-master PIO4 Trying to mount root from ufs:/dev/ad0s1a pid 106 (fsck_ufs), uid 0: exited on signal 8 vr0: link state changed to UP vr1: link state changed to DOWN pflog0: promiscuous mode enabled the device.hints looks like hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" hint.uart.2.at="isa" #hint.uart.2.disabled="1" hint.uart.2.port="0x3E8" hint.uart.2.irq="5" hint.uart.3.at="isa" #hint.uart.3.disabled="1" hint.uart.3.port="0x2E8" hint.uart.3.irq="11" uart0@pci0:0:14:0: class=0x070002 card=0x00d312b9 chip=0x100812b9 rev=0x01 hdr=0x00 vendor = '3COM Corp, Modem Division (Formerly US Robotics)' device = 'USR5610B USR5610B (0005610-02) 56K Performance Pro Modem (PCI Internal)' class = simple comms subclass = UART How can I force the PCI modem *not* to be uart0 so that the onboard com ports show up? # cu -l /dev/cuau0 Connected ati3 U.S. Robotics 56K FAX INT V5.22.91 OK ~ [EOT] Without the modem installed, the bootup looks like this ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xa0005000-0xa0005fff irq 15 at device 21.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xa0006000-0xa0006fff irq 15 at device 21.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered cpu0 on motherboard orm0: at iomem 0xc8000-0xd27ff pnpid ORM0000 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] RTC BIOS diagnostic error c0 Timecounter "TSC" frequency 499903954 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 1953MB at ata0-master PIO4 ---Mike >>In the new re-write, what is the proper way to add support for >>devices no longer recognized ? > >Add the PCI Ids to uart_bus_pci.c. Keep the list of Ids sorted, >because it's assumed by uart_pci_match(). > >If you can send me a patch, I'll commit to head and stable. > >FYI, > >-- >Marcel Moolenaar >xcllnt@mac.com > > From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 22:26:04 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32685106568A for ; Fri, 25 Jul 2008 22:26:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id 23C858FC16 for ; Fri, 25 Jul 2008 22:26:04 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.102] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4L00LUL2BFWW30@asmtp016.mac.com> for freebsd-current@freebsd.org; Fri, 25 Jul 2008 15:26:04 -0700 (PDT) Sender: xcllnt@mac.com Message-id: <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200807252129.m6PLTwhs021540@lava.sentex.ca> Date: Fri, 25 Jul 2008 15:26:02 -0700 References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 22:26:04 -0000 On Jul 25, 2008, at 2:30 PM, Mike Tancsa wrote: ... > uart0: port > 0xe500-0xe507 irq 10 at device 14.0 on pci0 > uart0: [FILTER] ... > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] ... There's no uart device found (i.e. probed and attached) at port 0x3f8. So, there's no uart that can be associated with the console and you won't have a /dev/cuau that is opened for/by init(8). > How can I force the PCI modem *not* to be uart0 so that the onboard > com ports show up? uart(4) deals with the fact that the console may not be associated with uart0, so the real problem is not having a uart driver for the serial port at 0x3f8. > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] Odd.. Is the 3com configured to take over COM1 or something? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 02:13:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A521106566C for ; Sat, 26 Jul 2008 02:13:05 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 056608FC1E for ; Sat, 26 Jul 2008 02:13:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6Q2D2Hv097624; Fri, 25 Jul 2008 22:13:02 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m6Q2D22u022503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 22:13:02 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200807260213.m6Q2D22u022503@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jul 2008 22:13:05 -0400 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 02:13:05 -0000 At 06:26 PM 7/25/2008, Marcel Moolenaar wrote: >On Jul 25, 2008, at 2:30 PM, Mike Tancsa wrote: > >... >>uart0: port >>0xe500-0xe507 irq 10 at device 14.0 on pci0 >>uart0: [FILTER] >... >>uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 >>uart1: [FILTER] >... > >There's no uart device found (i.e. probed and attached) at port 0x3f8. >So, there's no uart that can be associated with the console and you >won't have a /dev/cuau that is opened for/by init(8). But if I remove the modem, it does appear and work just fine. >>How can I force the PCI modem *not* to be uart0 so that the onboard >>com ports show up? > >uart(4) deals with the fact that the console may not be associated >with uart0, so the real problem is not having a uart driver for the >serial port at 0x3f8. > >>uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on >>isa0 >>uart0: [FILTER] >>uart0: console (9600,n,8,1) >>uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 >>uart1: [FILTER] > >Odd.. Is the 3com configured to take over COM1 or something? Nope, there is nothing that can be configured on it from what I see. ---Mike >-- >Marcel Moolenaar >xcllnt@mac.com > > From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 02:23:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14021106567B for ; Sat, 26 Jul 2008 02:23:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by mx1.freebsd.org (Postfix) with ESMTP id F37BD8FC49 for ; Sat, 26 Jul 2008 02:23:32 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.102] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4L00HEWDB4BV70@asmtp013.mac.com> for freebsd-current@freebsd.org; Fri, 25 Jul 2008 19:23:32 -0700 (PDT) Sender: xcllnt@mac.com Message-id: <7A311400-66E1-43F0-8B5F-22658D5276A0@mac.com> From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200807260213.m6Q2D22u022503@lava.sentex.ca> Date: Fri, 25 Jul 2008 19:23:27 -0700 References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> <200807260213.m6Q2D22u022503@lava.sentex.ca> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 02:23:33 -0000 On Jul 25, 2008, at 7:13 PM, Mike Tancsa wrote: > But if I remove the modem, it does appear and work just fine. > > >>> How can I force the PCI modem *not* to be uart0 so that the onboard >>> com ports show up? >> >> uart(4) deals with the fact that the console may not be associated >> with uart0, so the real problem is not having a uart driver for the >> serial port at 0x3f8. >> >>> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on >>> isa0 >>> uart0: [FILTER] >>> uart0: console (9600,n,8,1) >>> uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 >>> uart1: [FILTER] >> >> Odd.. Is the 3com configured to take over COM1 or something? > > Nope, there is nothing that can be configured on it from what I see. My best guess is that the hints are interfering. Try renumbering the hints. The number does not matter for the console. HTH, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 02:36:01 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 322BD1065674 for ; Sat, 26 Jul 2008 02:36:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EFE008FC16 for ; Sat, 26 Jul 2008 02:36:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6Q2ZxBv099214; Fri, 25 Jul 2008 22:35:59 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m6Q2ZwcS022585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 22:35:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200807260235.m6Q2ZwcS022585@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jul 2008 22:36:01 -0400 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: <7A311400-66E1-43F0-8B5F-22658D5276A0@mac.com> References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> <200807260213.m6Q2D22u022503@lava.sentex.ca> <7A311400-66E1-43F0-8B5F-22658D5276A0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 02:36:01 -0000 At 10:23 PM 7/25/2008, Marcel Moolenaar wrote: >My best guess is that the hints are interfering. Try >renumbering the hints. The number does not matter for >the console. You are right, if I add hint.uart.4.at="isa" hint.uart.4.port="0x3F8" hint.uart.4.flags="0x10" hint.uart.4.irq="4" # dmesg | grep -i uart uart0: port 0xe500-0xe507 irq 10 at device 14.0 on pci0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] uart0: port 0xe500-0xe507 irq 10 at device 14.0 on pci0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] uart0: port 0xe500-0xe507 irq 10 at device 14.0 on pci0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] uart4: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart4: [FILTER] However, serial console at bootup stops at 1 FreeBSD 2 FreeBSD Default: 1 /boot.config: -h FreeBSD/i386 boot Default: 0:ad(0,a)/boot/loader boot: Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (mdtancsa@releng7.sentex.ca, Wed Jul 23 12:29:59 EDT 2008) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x36ab14 data=0x325e0+0x2182c syms=[0x4+0x41890+0x4+0x544d6] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... \ From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 03:17:56 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D810F106567D for ; Sat, 26 Jul 2008 03:17:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id C2F248FC1F for ; Sat, 26 Jul 2008 03:17:56 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.102] (209-128-86-226.bayarea.net [209.128.86.226]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4L00FHVFTV9Y40@asmtp017.mac.com> for freebsd-current@freebsd.org; Fri, 25 Jul 2008 20:17:56 -0700 (PDT) Sender: xcllnt@mac.com Message-id: From: Marcel Moolenaar To: Mike Tancsa In-reply-to: <200807260235.m6Q2ZwcS022585@lava.sentex.ca> Date: Fri, 25 Jul 2008 20:17:55 -0700 References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> <200807260213.m6Q2D22u022503@lava.sentex.ca> <7A311400-66E1-43F0-8B5F-22658D5276A0@mac.com> <200807260235.m6Q2ZwcS022585@lava.sentex.ca> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 03:17:56 -0000 On Jul 25, 2008, at 7:36 PM, Mike Tancsa wrote: > At 10:23 PM 7/25/2008, Marcel Moolenaar wrote: > >> My best guess is that the hints are interfering. Try >> renumbering the hints. The number does not matter for >> the console. > > You are right, if I add > > hint.uart.4.at="isa" > hint.uart.4.port="0x3F8" > hint.uart.4.flags="0x10" > hint.uart.4.irq="4" *snip* > uart0: port > 0xe500-0xe507 irq 10 at device 14.0 on pci0 > uart0: [FILTER] > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] > uart4: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart4: [FILTER] > > > However, serial console at bootup stops at *snip* Ok, I was a bit too imprecise. While the number doesn't matter, it has to be 0, 1, 2 or 3 for the flags to take effect for the console. So, change 4 to 3 and it should work. Alternatively, remove the flags hint for uart.4 and instead set the following in /boot/loader.conf: hw.uart.console="io:0x3f8" This is the new and improved way of setting up a serial console. Besides the io tag it allows setting baudrate and much more. But for you, this should be enough. HTH, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 03:32:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BA5B1065678 for ; Sat, 26 Jul 2008 03:32:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 225A78FC27 for ; Sat, 26 Jul 2008 03:32:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6Q3Wvc1003159; Fri, 25 Jul 2008 23:32:57 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m6Q3WuQh022782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2008 23:32:56 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200807260332.m6Q3WuQh022782@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jul 2008 23:33:00 -0400 To: Marcel Moolenaar From: Mike Tancsa In-Reply-To: References: <200806061259.m56CxhdR045603@lava.sentex.ca> <018816ED-8FF3-4834-AD17-59637C87D30D@mac.com> <200807252129.m6PLTwhs021540@lava.sentex.ca> <2F58935E-6439-45A1-9CB3-894FC577ECF2@mac.com> <200807260213.m6Q2D22u022503@lava.sentex.ca> <7A311400-66E1-43F0-8B5F-22658D5276A0@mac.com> <200807260235.m6Q2ZwcS022585@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 03:32:59 -0000 At 11:17 PM 7/25/2008, Marcel Moolenaar wrote: >Ok, I was a bit too imprecise. While the number >doesn't matter, it has to be 0, 1, 2 or 3 for >the flags to take effect for the console. >So, change 4 to 3 and it should work. Thanks! Yes, that works now >Alternatively, remove the flags hint for uart.4 >and instead set the following in /boot/loader.conf: > > hw.uart.console="io:0x3f8" Yes, this works as well. Perhaps it would be good to add this to the man page ? Thanks for the help in getting it working! ---Mike >This is the new and improved way of setting up >a serial console. Besides the io tag it allows >setting baudrate and much more. But for you, >this should be enough. > >HTH, > >-- >Marcel Moolenaar >xcllnt@mac.com > > From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 14:14:26 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 187F81065671 for ; Sat, 26 Jul 2008 14:14:26 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id C9EF78FC12 for ; Sat, 26 Jul 2008 14:14:25 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by wx-out-0506.google.com with SMTP id h27so1235883wxd.7 for ; Sat, 26 Jul 2008 07:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=dCuOYnmO4E3vryS+Ww9CdVpQO9iqllmExObivVpN5gM=; b=vg5gUnu64kej536VXaSyZTzt7kvp/Qp5W93tskyxnh0XuH49TEXZgBxiYYqINN+F4k CPmJ4b6ghq4gYihgGFwGhw9+072m58MuIqaYEDHGcobYeNVh1FE8vd0MfwxDHMt6j0Qz b9HUjwkYDdk1kJC4HdQHHdcuplJCOT2NJMXb4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=lOJ/eczkIPm5pgEsn44WuRrFI2ouzP4lg2HarSnfdCCiFCbO8HsVOqv4+gDIzneRa7 zGmGwkjSLPDLffBhcp1DCjjrvIKDX/pq3u0rGURKr1g8YpdfqSj/heSPBl3ezad9yiH/ 7t8R+x8wt7Wa0kEApcoBVHrYum9/mSnCUKh/U= Received: by 10.70.112.4 with SMTP id k4mr3576319wxc.24.1217080053739; Sat, 26 Jul 2008 06:47:33 -0700 (PDT) Received: from ?10.0.3.231? ( [70.111.2.146]) by mx.google.com with ESMTPS id h40sm10818835wxd.33.2008.07.26.06.47.32 (version=SSLv3 cipher=RC4-MD5); Sat, 26 Jul 2008 06:47:33 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: vova@fbsd.ru In-Reply-To: <1216991500.1765.35.camel@localhost> References: <1216991500.1765.35.camel@localhost> Content-Type: text/plain; charset=utf-8 Date: Sat, 26 Jul 2008 09:47:23 -0400 Message-Id: <1217080043.1167.2.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: current , freebsd-mobile Subject: Re: Hard lockup CURRENT lockup with ath0 and no wireless networks in proximity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 14:14:26 -0000 On Fri, 2008-07-25 at 17:11 +0400, Vladimir Grebenschikov wrote: > Hi all > > I have more or less recent 8-CURRENT. > > And I've noticed that attempt to start wireless (start of > wpa_supplicatnt) when there is no wireless networks in proximity leads > to hard lockup of notebook, even DDB can't be called. > > I have IBM T60 with: > FreeBSD 8.0-CURRENT #3: Tue Jul 15 14:42:12 MSD 2008 > root@vbook:/usr/obj/usr/src/sys/VBOOK > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > ath0: mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: mac 10.3 phy 6.1 radio 10.2 > wlan0: Ethernet address: 00:19:7d:44:44:44 > > Once I've noticed extremely high interrupt rate before lockup. > > In case when there is wireless networks around everything goes as > expected. > > Any hints will be very appreciated. > Are you running powerd? And if yes, does the problem disappear if you stop powerd before starting wpa_supplicant? If both answers are "Yes", see: http://www.freebsd.org/cgi/getmsg.cgi?fetch=474718+0 +/usr/local/www/db/text/2008/freebsd-stable/20080713.freebsd-stable HTH, -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 19:20:03 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EEE21065683; Sat, 26 Jul 2008 19:20:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [IPv6:2001:418:1::39]) by mx1.freebsd.org (Postfix) with ESMTP id 19E708FC13; Sat, 26 Jul 2008 19:20:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from [130.129.1.147] (helo=rmac.psg.com) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMpJA-0002Hk-6P; Sat, 26 Jul 2008 19:20:00 +0000 Message-ID: <488B78DE.108@psg.com> Date: Sat, 26 Jul 2008 20:19:58 +0100 From: Randy Bush User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: work0 drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 19:20:03 -0000 hardware problem caused looping page fault problems. scrub cored i zpool remove'd the offending drive for the moment and the system works. randy --- acd0: CDROM at ata0-slave UDMA33 ad4: 305245MB at ata2-master SATA150 ad6: 305245MB at ata3-master SATA150 ad8: 305245MB at ata4-master SATA150 ad10: 305245MB at ata5-master SATA150 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/boot launched (1/2). GEOM_MIRROR: Device boot: rebuilding provider ad4s1. Trying to mount root from ufs:/dev/mirror/boota WARNING: / was not properly dismounted Loading configuration files. dumpon: /dev/ad4s1b: No such file or directory Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/mirror/bootb as swap device Starting file system checks: /dev/mirror/boota: 2690 files, 185913 used, 3875150 free (3686 frags, 483933 blocks, 0.1% fragmentation) Setting hostuuid: 7634a964-b127-0430-c299-00304891d708. Setting hostid: 0xeebf67d9. Mounting local file systems:. ad6: FAILURE - READ_DMA status=51 error=40 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff801aaa06 stack pointer = 0x10:0xffffffff80a64bc0 frame pointer = 0x10:0x51 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) trap number = 12 panic: page fault cpuid = 1 From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 21:51:35 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79BB106564A for ; Sat, 26 Jul 2008 21:51:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1E48FC08 for ; Sat, 26 Jul 2008 21:51:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m6QLnMkO028252; Sat, 26 Jul 2008 15:49:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 Jul 2008 15:49:38 -0600 (MDT) Message-Id: <20080726.154938.2040342628.imp@bsdimp.com> To: mike@sentex.net From: "M. Warner Losh" In-Reply-To: <200807260332.m6Q3WuQh022782@lava.sentex.ca> References: <200807260235.m6Q2ZwcS022585@lava.sentex.ca> <200807260332.m6Q3WuQh022782@lava.sentex.ca> X-Mailer: Mew version 5.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-current@FreeBSD.org, xcllnt@mac.com Subject: Re: PUC rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 21:51:35 -0000 In message: <200807260332.m6Q3WuQh022782@lava.sentex.ca> Mike Tancsa writes: : At 11:17 PM 7/25/2008, Marcel Moolenaar wrote: : : >Ok, I was a bit too imprecise. While the number : >doesn't matter, it has to be 0, 1, 2 or 3 for : >the flags to take effect for the console. : >So, change 4 to 3 and it should work. : : Thanks! Yes, that works now : : >Alternatively, remove the flags hint for uart.4 : >and instead set the following in /boot/loader.conf: : > : > hw.uart.console="io:0x3f8" : : Yes, this works as well. Perhaps it would be good to add this to the : man page ? Thanks for the help in getting it working! This gets the console working, but does nothing to help with the wiring of units to the underlying hardware. There were changes to make this happen, but they have been rejected by one person so we're trying to work out something better. The switch from sio, which kludged around the problem, to uart, which doesn't, has brought this problem more to the fore-front. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 26 22:17:18 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AF131065681 for ; Sat, 26 Jul 2008 22:17:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id B06D28FC1B for ; Sat, 26 Jul 2008 22:17:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3210795fgb.35 for ; Sat, 26 Jul 2008 15:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=AIwMWUHkXBccKmQnLXQltmimMNtOYHW+/rCqleZxuq8=; b=FdLWKq3YGgZ5EloCSw7q0oq8w5fzJIwit1jV1Vl921tgPvEcteS1dkhPh8OXLJ2CBv reuNhYSid319lcD8GLtZMO1bIw3mh3flA4oIRoZhvuSPXqHoMa8OZG58toksD9dwwy4L EjvBFmy8e7yafZKrbaBEnCQMu/tM7H6BTpT0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=gfwsRadsQvIfMl5EFfVjosArKkxosnhBmKhVyNxuLcJaIb1UCrA/xSRDvlRw77vUTV 3MLVCAUBDRt1JpOiIgXyJPPt7cRK78+bPDFh3EXu71duevzgKlWD3lRnVatQSjZTNXYn 6QQa0sMv1pjoUZyKGhQnO3V71IL7EKLG99Cf0= Received: by 10.86.4.2 with SMTP id 2mr1185684fgd.67.1217110636131; Sat, 26 Jul 2008 15:17:16 -0700 (PDT) Received: by 10.86.51.1 with HTTP; Sat, 26 Jul 2008 15:17:16 -0700 (PDT) Message-ID: <7d6fde3d0807261517g9714b72hbcf777f49ff91e3b@mail.gmail.com> Date: Sat, 26 Jul 2008 15:17:16 -0700 From: "Garrett Cooper" To: "Peter Wemm" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: current@freebsd.org Subject: freebsd svn repo busted or bad usage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 22:17:18 -0000 $ svn co svn://svn.freebsd.org/base/head # ... svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and tr y again svn: Can't open file 'head/usr.bin/window/.svn/tmp/text-base/:ww.svn-base': No s uch file or directory gcooper@ob2 /cygdrive/e/freebsd/head $ svn cleanup gcooper@ob2 /cygdrive/e/freebsd/head $ svn up svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and tr y again svn: Can't open file 'usr.bin/window/.svn/tmp/text-base/:ww.svn-base': No such f ile or directory