From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 00:13:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03C761065675 for ; Sun, 26 Jun 2011 00:13:33 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9705C8FC0A for ; Sun, 26 Jun 2011 00:13:32 +0000 (UTC) Received: (qmail 4906 invoked from network); 25 Jun 2011 20:13:31 -0400 Received: from host-64-202-138-67.cybera.net (HELO Macintosh-21.local) (64.202.138.67) by mail.atlantawebhost.com with SMTP; 25 Jun 2011 20:13:31 -0400 Message-ID: <4E0679AA.20100@shadowsun.net> Date: Sat, 25 Jun 2011 20:13:30 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: GHC Port on 9-CURRENT 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, 26 Jun 2011 00:13:33 -0000 The GHC (Glasgow Haskell Compiler) was marked broken by pointyhat sometime back in May, following its update to GHC 7.0.3_1. I'm not sure if anyone has looked at this, but it doesn't appear anyone has. Sorry if any of this is repeated. I tried building the port yesterday, with both GCC and Clang. The GCC build succeeds, and the compiler seems to work just fine (it has no trouble compiling and installing the haskell-platform port, as well as many of my own haskell programs). With Clang, an error occurs in one of the configure scripts, because Clang warns about unused command-line arguments, and the configure script assumes that to be a compiler error. You can deal with this by adding -Qunused-parameter to CFLAGS. With this, it builds the bootstrap and stage 1 compilers. However, the stage 1 compiler's parser appears to be broken, as it reports erroneous parse errors on the GHC compiler's source code (and probably for any haskell program, but it never gets a chance to). I'm not sure why this happens, but I will investigate more closely once I deal with some more important issues I'm investigating. In any case, the port builds fine with GCC. Perhaps it would be prudent to set CC=gcc and CXX=g++ in the makefile for the time being and mark the port as working again? -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 01:32:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C353106566B; Sun, 26 Jun 2011 01:32:49 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 657C08FC14; Sun, 26 Jun 2011 01:32:47 +0000 (UTC) Received: by fxe6 with SMTP id 6so715041fxe.17 for ; Sat, 25 Jun 2011 18:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=O0s1kLWDnuMc+P1gDYBTtcxtuSWyUc1nk+WdyvHTvfc=; b=ZQdnSQKy61BNuKU6BlbkNiTDURzeJ8K4Xiytb4TSruBHD0clmFQt3ph57z8uG0KTar 8VLpbVdWA5zvu1jvTgZy6UT5RCCaOKyhqgduE9FakuAgx5y0n9CxqTK0vy7v6kNDuZZW Nk2BDqxhDczCVocdkoNUXjBJDivXbG6xzIfmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=taYd+0/qKDQPxTZp/3Kys/YrTcoAEEDVKcmFWbWaMbVA6TDfvGUz/0B9X5J/baYlIo zXsRqZ/MroE+2GSSdyQf6Eqyf077exXSisiNamBKqF7U/q40CP+zO92AGu+su5xC4HlW 7I7ZLgAHm1dKrcAF2WmnZ4NLr6UhP8R4NHeMY= Received: by 10.223.53.85 with SMTP id l21mr6697386fag.26.1309050491437; Sat, 25 Jun 2011 18:08:11 -0700 (PDT) Received: from [192.168.1.7] (catv-86-101-5-202.catv.broadband.hu [86.101.5.202]) by mx.google.com with ESMTPS id n13sm2580669fab.46.2011.06.25.18.08.10 (version=SSLv3 cipher=OTHER); Sat, 25 Jun 2011 18:08:10 -0700 (PDT) Sender: =?UTF-8?B?UMOBTEkgR8OhYm9yIErDoW5vcw==?= Message-ID: <4E06863F.7010104@FreeBSD.org> Date: Sun, 26 Jun 2011 03:07:11 +0200 From: Gabor PALI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100925 Thunderbird/3.1.4 MIME-Version: 1.0 To: Eric McCorkle References: <4E0679AA.20100@shadowsun.net> In-Reply-To: <4E0679AA.20100@shadowsun.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: GHC Port on 9-CURRENT 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, 26 Jun 2011 01:32:49 -0000 Hi Eric, On 06/26/11 02:13, Eric McCorkle wrote: > The GHC (Glasgow Haskell Compiler) was marked broken by pointyhat > sometime back in May, following its update to GHC 7.0.3_1. I'm not > sure if anyone has looked at this, but it doesn't appear anyone has. Yes, you are right, sorry, I have not had time to take a closer look at this, but there is a log [1] for it on pointyhat (that I could not also reproduce on a -CURRENT system). > The GCC build succeeds Sounds great. > With Clang, an error occurs in one of the configure scripts, because > Clang warns about unused command-line arguments, and the configure > script assumes that to be a compiler error. You can deal with this by > adding -Qunused-parameter to CFLAGS. Thanks for investigating this. > However, the stage 1 compiler's parser appears to be broken, as it > reports erroneous parse errors on the GHC compiler's source code (and > probably for any haskell program, but it never gets a chance to). I'm > not sure why this happens, but I will investigate more closely once I > deal with some more important issues I'm investigating. I would be happy to see the logs. > In any case, the port builds fine with GCC. Perhaps it would be > prudent to set CC=gcc and CXX=g++ in the makefile for the time being > and mark the port as working again? Yeah, that might be a solution, I will try it. [1] http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/a.9.20110516102328/ghc-7.0.3.log From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 03:06:02 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04FA7106564A for ; Sun, 26 Jun 2011 03:06:01 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 43C348FC12 for ; Sun, 26 Jun 2011 03:06:00 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.4/8.14.4) with ESMTP id p5Q35suC087007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jun 2011 22:05:54 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2011; t=1309057555; bh=MJSpN4H8smWrWePsu6uCkzgApuDsce35uD1Qc25wV2k=; l=263; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=rpMBSuug/LP7q4MQYGKjhn3Ie+okaNagiSi5rrqwVKFmltNCq1OsHHiulrF9/rwF8 QJVVfHyfRRRECkDjLJIh48i0GFJpM45iiM92MwiOBDarDdx9OqSShFzmAqb51HZ6ky k9rXqTUkAJUzh4QZ2RoaqJBwmQYZp++gWvrtMwco= Date: Sat, 25 Jun 2011 22:05:54 -0500 (CDT) From: Greg Rivers To: Andriy Gapon In-Reply-To: <4E063977.6090305@FreeBSD.org> Message-ID: References: <201106241531.19375.hselasky@c2i.net> <4E063977.6090305@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (roadkill.tharned.org [75.145.12.185]); Sat, 25 Jun 2011 22:05:55 -0500 (CDT) Cc: Greg Rivers , freebsd-current@FreeBSD.org, Hans Petter Selasky Subject: Re: [Testing wanted] USB patch for HAL 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, 26 Jun 2011 03:06:02 -0000 On Sat, 25 Jun 2011, Andriy Gapon wrote: > Hm, I have to ask, have you tried this without sg driver? > Thanks for the suggestion. Hans Petter suggested the same thing in IRC earlier today. We're trying that and a few other things. -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 05:40:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A47106564A for ; Sun, 26 Jun 2011 05:40:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 173E98FC16 for ; Sun, 26 Jun 2011 05:40:03 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=vrJF5kjXe35rRze0mxLgGFcjILUNrTxl1QHeo1urnh8= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=JCE9WutFZhIA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=8eF6gJYlM6NEsIY2xsQA:9 a=811Xaz8LuLWyf-R5y_kA:7 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 145312086; Sun, 26 Jun 2011 07:40:02 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 26 Jun 2011 07:38:21 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> In-Reply-To: <201106251907.02052.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106260738.21847.hselasky@c2i.net> Cc: Jeremy Messenger , Robert Millan , Warner Losh Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] 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, 26 Jun 2011 05:40:04 -0000 On Saturday 25 June 2011 19:07:01 Hans Petter Selasky wrote: > On Saturday 25 June 2011 18:45:14 Warner Losh wrote: > > On Jun 25, 2011, at 9:42 AM, Hans Petter Selasky wrote: > > > On Saturday 25 June 2011 01:05:26 Jeremy Messenger wrote: > > >> Jeremy Messenger > > > > > > Done. > > > > > > http://svn.freebsd.org/changeset/base/223536 > > > > Please move it back. It doesn't belong in /etc/defaults. It belongs in > > /etc/devd if we're going to have it at all. If you have a full GENERIC > > kernel, there will never be a NOMATCH line generated, so these entries > > will just be ignored. > > > > Warner > > Done. > > http://svn.freebsd.org/changeset/base/223543 > Hi, I see that a lot of PCI device drivers use code to check their ID's. One simple way to dump all the PCI device ID's is to compile or load all modules and then make a dummy PCI device, which only calls device_probe on the full 32-bit space of the pci_get_devid(). This should take in matter of some minutes to produce a complete list of PCI ID's. Then add these ID's to all the respective drivers like a generic device ID table: struct pci_device_id { uint32_t device_id; uint32_t card_id; const char *description; unsigned long driver_info; } __aligned(32); Then export those automatically generated structures into the "pci_device_id" section and have tools/bus_autoconf generate the matching rules. PCI format structure for bus_autoconf: "pci_device_id{256,:}" "device_id[0]{" U32_XOR ",8}" "device_id[1]{" U32_XOR ",8}" "device_id[2]{" U32_XOR ",8}" "device_id[3]{" U32_XOR ",8}" "card_id[0]{" U32_XOR ",8}" "card_id[1]{" U32_XOR ",8}" "card_id[2]{" U32_XOR ",8}" "card_id[3]{" U32_XOR ",8}" --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 05:51:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B756106566C; Sun, 26 Jun 2011 05:51:24 +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 2F0618FC14; Sun, 26 Jun 2011 05:51:24 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5Q5pLwO038505 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 25 Jun 2011 23:51:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E05F582.2010500@FreeBSD.org> Date: Sat, 25 Jun 2011 23:51:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> References: <4E05F582.2010500@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 25 Jun 2011 23:51:22 -0600 (MDT) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: kern.sync_on_panic 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, 26 Jun 2011 05:51:24 -0000 On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: > Does anybody actually use kern.sync_on_panic tunable/sysctl? > If yes, then in what circumstances do you need it? > That is, why any other alternative doesn't work for you? > Like: > 1. remounting filesystems R/O before panic if you knowingly provoke it = for testing > 2. using netboot for your test system > 3. using su+j, gjournal or a different filesystem altogether > 4. using fsck after reboot >=20 > It seems to me that syncing filesystems in panic context is an = adventure. And it > may become even more of an adventure if we introduce code that = completely stops > scheduler in and after panic. I've used it in the past when I was developing a device driver that was = in the late stages of maturing. Since all the panics in the system were = when the driver dereferenced NULL in that driver, sync was safe because = all the data structures were sane except the aforementioned driver. (1) It was a production system, and everything that could be was already = mounted r/w. However, some small, but every critical, amount of data = was still r/w and it was very important to not lose this data. = Production here likely should be in quotes, because it was in the late = stages of testing/validation. The problem was without this sometimes = the saved state of the GPS receiver and other hardware would wind up = being zero, which meant that we'd have to do a cold start which cost us = a few hours of time. At the time I was doing this, we saw zero files a = couple times a day without this turned on. (2) netbooting wasn't an option since we were qualifying a = non-netbooting system. (3) these weren't available at the time, but the goal was to prevent = data loss, not to necessarily have to avoid fsck on boot. (4) Data loss without it. Now, I'll be the first to admit this has been a few years, and I haven't = done a fresh evaluation to see if things are still safe. I'll also be = the first to admit that this was a useful debugging setting late in = development, and not in production. I'm also the first to admit this = isn't what I'd call a very wide-spread case. But it did come in very = handy when chasing a few bugs to be able to do 10 panic/reboot cycles an = hour rather than 2 a day. Warner= From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 06:02:21 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16641065670 for ; Sun, 26 Jun 2011 06:02:20 +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 952FB8FC0A for ; Sun, 26 Jun 2011 06:02:20 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5Q60U9h038569 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 26 Jun 2011 00:00:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201106260738.21847.hselasky@c2i.net> Date: Sun, 26 Jun 2011 00:00:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3FC50F07-2C7B-4DD4-A75C-49001CFEF85D@bsdimp.com> References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 26 Jun 2011 00:00:32 -0600 (MDT) Cc: Jeremy Messenger , Robert Millan , freebsd-current@FreeBSD.org Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] 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, 26 Jun 2011 06:02:21 -0000 On Jun 25, 2011, at 11:38 PM, Hans Petter Selasky wrote: > On Saturday 25 June 2011 19:07:01 Hans Petter Selasky wrote: >> On Saturday 25 June 2011 18:45:14 Warner Losh wrote: >>> On Jun 25, 2011, at 9:42 AM, Hans Petter Selasky wrote: >>>> On Saturday 25 June 2011 01:05:26 Jeremy Messenger wrote: >>>>> Jeremy Messenger >>>>=20 >>>> Done. >>>>=20 >>>> http://svn.freebsd.org/changeset/base/223536 >>>=20 >>> Please move it back. It doesn't belong in /etc/defaults. It = belongs in >>> /etc/devd if we're going to have it at all. If you have a full = GENERIC >>> kernel, there will never be a NOMATCH line generated, so these = entries >>> will just be ignored. >>>=20 >>> Warner >>=20 >> Done. >>=20 >> http://svn.freebsd.org/changeset/base/223543 >>=20 >=20 > Hi, >=20 > I see that a lot of PCI device drivers use code to check their ID's. >=20 > One simple way to dump all the PCI device ID's is to compile or load = all=20 > modules and then make a dummy PCI device, which only calls = device_probe on the=20 > full 32-bit space of the pci_get_devid(). This should take in matter = of some=20 > minutes to produce a complete list of PCI ID's. Then add these ID's to = all the=20 > respective drivers like a generic device ID table: >=20 > struct pci_device_id { > uint32_t device_id; > uint32_t card_id; > const char *description; > unsigned long driver_info; > } __aligned(32); >=20 > Then export those automatically generated structures into the = "pci_device_id"=20 > section and have tools/bus_autoconf generate the matching rules. >=20 > PCI format structure for bus_autoconf: >=20 > "pci_device_id{256,:}" > "device_id[0]{" U32_XOR ",8}" > "device_id[1]{" U32_XOR ",8}" > "device_id[2]{" U32_XOR ",8}" > "device_id[3]{" U32_XOR ",8}" >=20 > "card_id[0]{" U32_XOR ",8}" > "card_id[1]{" U32_XOR ",8}" > "card_id[2]{" U32_XOR ",8}" > "card_id[3]{" U32_XOR ",8}" I like the idea of having a standardized table. I've done this with PC = Card and it really works well. It isn't the design pattern that all = drivers use, and it may be hard to get everyone lined up on this. I = tried PCI back after I did PC Card and met resistance. Most of the = resistance was from people that are no longer active in the project, so = I think that we could do this today. I suspect that some of the vendor = drivers today might stand in the way of having PCI be completely = uniform. The big advantage of USB is that it is uniform now. PCI isn't. It = would take a lot of work to make it uniform. Also, like I was saying on IRC, I don't like the fact that we have to = have different bus code in this automatic tool. It shouldn't know nor = care about what the bus or drivers do. The drivers should export a = table and a descriptor for the table that would allow it to either = generate the devd.conf lines needed to do the matching, or for some = other program to examine the pnp_string information from newbus and = figure out which module(s) to load. Also, I don't find the above syntax = easy to read or understand (sorry). Don't get me wrong. I love the USB autoload code you've done so far, = but I consider it more of a prototype for the final system than the = final system itself. Warner= From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 07:27:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D737A106567E for ; Sun, 26 Jun 2011 07:27:29 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 798298FC12 for ; Sun, 26 Jun 2011 07:27:29 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.4/8.14.4) with ESMTP id p5Q7RMvj088015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jun 2011 02:27:23 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2011; t=1309073243; bh=8Tchrl0I17LXvx8hYFNVpx8eBppEYp0foh32jZKlGqQ=; l=1899; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=TI1AwtL3BE3eU3VljA613BcHsFpEZ/HWv7jC76HQMIPpxErp04QsCrRLmA+lhiJ/I 2VAYfHATIZuTxb7KVui3dZM+z4g7QIjk63wsA0+9wQemWlM1tApOZiR0hLKVrPf1lZ K5Ep+kbBBuLiOovE1K943GSPyShC+ttypfJ3XNhg= Date: Sun, 26 Jun 2011 02:27:22 -0500 (CDT) From: Greg Rivers To: Hans Petter Selasky In-Reply-To: <201106252054.38056.hselasky@c2i.net> Message-ID: References: <201106241531.19375.hselasky@c2i.net> <201106252054.38056.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (roadkill.tharned.org [75.145.12.185]); Sun, 26 Jun 2011 02:27:23 -0500 (CDT) Cc: freebsd-current@freebsd.org Subject: Re: [Testing wanted] USB patch for HAL 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, 26 Jun 2011 07:27:29 -0000 Here are some of the results from testing based on your instructions and patches in IRC earlier today. First, per your instructions, I removed sg by modifying /usr/src/sys/conf/files and rebuilding the kernel: --- files.orig 2011-06-25 16:26:46.000000000 -0500 +++ files 2011-06-25 16:26:58.000000000 -0500 @@ -127,3 +127,2 @@ cam/scsi/scsi_ses.c optional ses -cam/scsi/scsi_sg.c optional sg cam/scsi/scsi_targ_bh.c optional targbh Curiously, with this change, /dev/sg0 was still created and sg0 still appeared in `camcontrol devlist`, but things were better. hald still stopped working after the first detach, but was not unkillable and started working again after it was restarted. And whether or not hald was restarted, the USB bus no longer wedged and continued to work properly. Next, leaving the above patch in place, I rebuilt the kernel with the patch you provided for /usr/src/sys/cam/cam_xpt.c: --- cam_xpt.c 2011-06-26 00:16:44.000000000 +0200 +++ cam_xpt.c 2011-06-26 00:16:13.000000000 +0200 @@ -3592,6 +3592,9 @@ xpt_free_ccb(free_ccb); sim->ccb_count--; } else { + /* reset private data */ + memset(&free_ccb->ccb_h.periph_priv, 0, sizeof(free_ccb->ccb_h.periph_priv)); + SLIST_INSERT_HEAD(&sim->ccb_freeq, &free_ccb->ccb_h, xpt_links.sle); } With this change, the USB bus continued to operate as expected while attaching and detaching a USB flash drive. On start up, hald was not detecting the attach/detach events, but started working and kept working after restarting it. In summary, with both of the above changes, everything worked pretty much correctly. I know this is still inconclusive, but I wanted to report what I had so far. After I get some sleep, I'll proceed with trying to get the back traces inside cam_periph_release_locked that you asked for. -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 07:41:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E38E3106564A for ; Sun, 26 Jun 2011 07:41:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C4BAC155A0F for ; Sun, 26 Jun 2011 07:41:14 +0000 (UTC) Message-ID: <4E06E29A.6090402@FreeBSD.org> Date: Sun, 26 Jun 2011 00:41:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4E04F5EE.3000002@FreeBSD.org> In-Reply-To: <4E04F5EE.3000002@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: sys/boot/i386/boot2 (install) fail 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, 26 Jun 2011 07:41:15 -0000 On 06/24/2011 13:39, Doug Barton wrote: > On r223514M, kernel installed Ok, then after reboot and attempt to > installworld I first get a failure that "btxld" is not found. So I add > that to ITOOLS and then I get this. Any ideas? Building again with a clean /usr/obj "solved" this problem, FYI. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 10:33:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC82F106566B for ; Sun, 26 Jun 2011 10:33:19 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFAE8FC1B for ; Sun, 26 Jun 2011 10:33:19 +0000 (UTC) Received: by pzk5 with SMTP id 5so3626692pzk.17 for ; Sun, 26 Jun 2011 03:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tnLsQxdtelBaN15j4utCmMfc5xAsgN3MPEnr46m0zeA=; b=STp9jgOaTSR0h8OHeJ4kCPzmIEfB/ENEFX4gqqmoNfz5emK13YhYV94TUH5a0sMXhz V6F+S45yo1iYowLM9n533v/ZppgO4o7f+zTbBrmU9XzU7uQrSK3fyB9/4iqwRGvBqwxH humlCIWTgH1sU3GQgnsjTsFup5nJiHNJ8BVNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=GV+Jw+59JN2lYum/Z4eI1wvQwk22qVHjBEwezg/RM1XoSbVZdyt80759+IhgdyWWho /VN5m1Q0hlA724XIspW1QuEUfhYo2qyghB+Z79Tx/5YHmZBqXapIjrpoU+DXHWBf9PJR JqzE6iTMuXCM53W4A3Ghpzq/GVfh10RuIjMgE= MIME-Version: 1.0 Received: by 10.68.36.195 with SMTP id s3mr2325703pbj.388.1309084398958; Sun, 26 Jun 2011 03:33:18 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.68.49.169 with HTTP; Sun, 26 Jun 2011 03:33:18 -0700 (PDT) In-Reply-To: <201106260738.21847.hselasky@c2i.net> References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> Date: Sun, 26 Jun 2011 12:33:18 +0200 X-Google-Sender-Auth: RX-BLoBDukcsTIg97D5R8iVxSGA Message-ID: From: Robert Millan To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 26 Jun 2011 11:35:50 +0000 Cc: Jeremy Messenger , freebsd-current@freebsd.org, Warner Losh Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] 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, 26 Jun 2011 10:33:19 -0000 2011/6/26 Hans Petter Selasky : > Hi, > > I see that a lot of PCI device drivers use code to check their ID's. > > [...] I seem to recall devd doesn't process PCI because it is event-driven and there are no "events" associated with PCI cards. Perhaps it could be modified to scan for PCI cards via libpci on initialization and generate "fake" events for them? -- Robert Millan From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 11:45:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A239106566B for ; Sun, 26 Jun 2011 11:45:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id C6EE98FC0C for ; Sun, 26 Jun 2011 11:45:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=XR4AdwVFe5G+K9PtySS1/JOnv6WK/hruile8wX/SUjk= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=_7x1bjhUSeMA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=N3vH5299AAAA:8 a=NYErYoLLKTYTOfMIxwUA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 144231524; Sun, 26 Jun 2011 13:45:33 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 26 Jun 2011 13:43:53 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106241531.19375.hselasky@c2i.net> <201106252054.38056.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106261343.53522.hselasky@c2i.net> Cc: Subject: Re: [Testing wanted] USB patch for HAL 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, 26 Jun 2011 11:45:36 -0000 On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: > With this change, the USB bus continued to operate as expected while > attaching and detaching a USB flash drive. On start up, hald was not > detecting the attach/detach events, but started working and kept working > after restarting it. In summary, with both of the above changes, > everything worked pretty much correctly. Try this patch to hald: cd /usr/ports/sysutils/hal/files fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c cd .. make all deinstall install clean --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 14:00:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4134F1065678; Sun, 26 Jun 2011 14:00:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id D0E5B8FC16; Sun, 26 Jun 2011 14:00:19 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D3E075C59; Sun, 26 Jun 2011 15:42:02 +0200 (CEST) Message-ID: <4E07372A.7000600@FreeBSD.org> Date: Sun, 26 Jun 2011 15:42:02 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.19pre) Gecko/20110622 Lanikai/3.1.12pre MIME-Version: 1.0 To: "Hartmann, O." References: <4E059500.40107@zedat.fu-berlin.de> <20110625081056.GA28892@freebsd.org> <4E060484.5050905@zedat.fu-berlin.de> In-Reply-To: <4E060484.5050905@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Roman Divacky , FreeBSD Current Subject: Re: LLVM: llvm-as, llvm-ld and so on not contained in FreeBSD core contrib? 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, 26 Jun 2011 14:00:22 -0000 On 2011-06-25 17:53, Hartmann, O. wrote: > On 06/25/11 10:10, Roman Divacky wrote: >> On Sat, Jun 25, 2011 at 09:57:52AM +0200, Hartmann, O. wrote: >>> Hello. >>> Just for my couriosity: I'm missing llvm-as, llvm-ld and other binutils >>> from LLVM and was wondering why they are contained in the port's llvm >>> collection but not in FreeBSD's source contribution. >> >> There's no use for these utilities in FreeBSD base system. >> >>> I build FreeBSD 9 with CLANG. But as a missing llvm-as and llvm-ld (or >>> llvm-ar) would imply, the binaries are generated via binutils from >>> theGNU suite, aren't they? >> llvm-{as,ld,ar} are not replacements for those from binutils. llvm-* >> work on the llvm bitcode only and are of no use for normal object >> files. >> >> dim@ made a patch that adds those utilities if you really need them >> >> http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-June/000216.html >> >> By default when you compile things with clang it uses its own assembler >> (ie. it goes directly from C -> .o) so typically only gnu ld is used >> in the compilation chain. >> >> >> roman > Thank you very much. Patched and works. What's the general opinion on applying this to -current? Otherwise it'll be sitting in my private tree, possibly bit-rotting. :) For people that are experimenting with llvm and/or clang, these additional tools might sometimes come in handy. For normal users, it won't have any impact, except for a few extra source files in the tree. These tools will not be built by default. From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 16:35:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18019106564A for ; Sun, 26 Jun 2011 16:35:24 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id C97808FC0A for ; Sun, 26 Jun 2011 16:35:23 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.4/8.14.4) with ESMTP id p5QGZHGB090935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jun 2011 11:35:17 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2011; t=1309106118; bh=dKeSZFG35tS7TO7zjyLPLJISf8HV8+DYli4H/lNHkQs=; l=1009; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=VLJQpEsBCCaGSe7Mw3SlVTqtb9X2zc3q4OjYIJMRGe2JMOrwFnkogDxbovEYi3mrC tWZmJyCw950V7uNuS6x76eBTskQBn4amqKOrQM7gQMmAJ4ic2eGGuZrYldpdNQ7mUW hvRVOTkf2xS/bbMcG2Rm6Hx8lnyoDDxqoVJt4Mmc= Date: Sun, 26 Jun 2011 11:35:17 -0500 (CDT) From: Greg Rivers To: Hans Petter Selasky In-Reply-To: <201106261343.53522.hselasky@c2i.net> Message-ID: References: <201106241531.19375.hselasky@c2i.net> <201106252054.38056.hselasky@c2i.net> <201106261343.53522.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (roadkill.tharned.org [75.145.12.185]); Sun, 26 Jun 2011 11:35:18 -0500 (CDT) Cc: freebsd-current@freebsd.org Subject: Re: [Testing wanted] USB patch for HAL 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, 26 Jun 2011 16:35:24 -0000 On Sun, 26 Jun 2011, Hans Petter Selasky wrote: > On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: >> With this change, the USB bus continued to operate as expected while >> attaching and detaching a USB flash drive. On start up, hald was not >> detecting the attach/detach events, but started working and kept working >> after restarting it. In summary, with both of the above changes, >> everything worked pretty much correctly. > > Try this patch to hald: > > cd /usr/ports/sysutils/hal/files > fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c > > cd .. > make all deinstall install clean > With this patch, and the CAM patches still in place, the USB bus works fine, but hald never sees any attach/detach events, even after restarting it. I reverted the CAM patches and tested again with the same result. So this patch to hald does stop the CAM sg errors, and prevents the USB from wedging. It just doesn't detect attach events. -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 17:54:16 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FE6F1065670 for ; Sun, 26 Jun 2011 17:54:16 +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 5A1A48FC0A for ; Sun, 26 Jun 2011 17:54:16 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5QHqX7w043389 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 26 Jun 2011 11:52:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 26 Jun 2011 11:51:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106242342.47194.hselasky@c2i.net> <201106251907.02052.hselasky@c2i.net> <201106260738.21847.hselasky@c2i.net> To: Robert Millan X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 26 Jun 2011 11:52:35 -0600 (MDT) Cc: Jeremy Messenger , freebsd-current@FreeBSD.org, Hans Petter Selasky Subject: Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules] 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, 26 Jun 2011 17:54:16 -0000 On Jun 26, 2011, at 4:33 AM, Robert Millan wrote: > 2011/6/26 Hans Petter Selasky : >> Hi, >>=20 >> I see that a lot of PCI device drivers use code to check their ID's. >>=20 >> [...] >=20 > I seem to recall devd doesn't process PCI because it is event-driven = and > there are no "events" associated with PCI cards. That's totally false. > Perhaps it could be modified to scan for PCI cards via libpci on = initialization > and generate "fake" events for them? Since your premise is false, this solution also is false. Devices are handled in a completely uniform manner in the system. When = they attach, an attach even is generated. When they detach, a detach = event is generated. When there is no driver attached after the = probe/attach sequence, a NOMATCH event is generated. Events are queued = up during the early boot process until devd can run. They are then = processed in order. Devices that haven't had a driver attach to them = would be processed when devd had a chance to start. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 18:44:15 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6AE106566B for ; Sun, 26 Jun 2011 18:44:15 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26D788FC0A for ; Sun, 26 Jun 2011 18:44:14 +0000 (UTC) Received: by iyb11 with SMTP id 11so5007158iyb.13 for ; Sun, 26 Jun 2011 11:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=haBw5QujTCk3v5ddPFA/dFpjXMpO3cIt75vRFXJ8qsk=; b=fnCqP3RFABctAtl4AVL7Z1/Y38+Gs2Ny/LENQ+Y0O3CIpX6de4uo88L6uxQ3F+QbwU nJRFAOIxnbeg13vunMAlyYhdWRr4hJWUQfYxQnaY27U4FrIxh/1mwI0YVw8gbmGYafmq 5y9NdzKfuE0jqIuJoMv1vZhutmJCz1nkmU7z0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=D9OiF7cioxqPJvsRobbajCaYgJp93RFPLNggVNSZJtcrFFNSgkbxWtMkxDt/R+VIRa 5KtHM3Tbcu8o2+fdBHL/Fc/FDuv/gFSXHLXcIFYDLRmdNFbvDIMDnXDMG3NC/K5v+fYW lXL9kZT6UFOFtvi8psN4PhHCGJf6JdkHKt+Qs= Received: by 10.231.167.197 with SMTP id r5mr5015335iby.70.1309113854074; Sun, 26 Jun 2011 11:44:14 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.49.193 with HTTP; Sun, 26 Jun 2011 11:43:44 -0700 (PDT) From: Chris Rees Date: Sun, 26 Jun 2011 19:43:44 +0100 X-Google-Sender-Auth: If9Gp5pxfiLGRkz_ywsdoUXUTSs Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Build failure during 9-CURRENT make world 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, 26 Jun 2011 18:44:15 -0000 Hi all, Just trying to install 9-CURRENT (csupped today) for my Xbox. What I did: mounted all partitions under /mnt cd /usr/cursrc/src make KERNCONF=CERBERUS DESTDIR=/mnt world kernel *chug chug* ===> usr.bin/clang/clang (all) c++ -O2 -pipe -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -fstack-protector -fno-exceptions -fno-rtti -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzerfrontend/libclangstaticanalyzerfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercheckers/libclangstaticanalyzercheckers.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercore/libclangstaticanalyzercore.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinstprinter/libllvmpowerpcinstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmtarget/libllvmtarget.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86instprinter/libllvmx86instprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86utils/libllvmx86utils.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcore/libllvmcore.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86info/libllvmx86info.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmc/libllvmmc.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmsupport/libllvmsupport.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: could not read symbols: File format not recognized *** Error code 1 Stop in /usr/cursrc/src/usr.bin/clang/clang. *** Error code 1 Stop in /usr/cursrc/src/usr.bin/clang. *** Error code 1 Stop in /usr/cursrc/src/usr.bin. *** Error code 1 Stop in /usr/cursrc/src. *** Error code 1 Stop in /usr/cursrc/src. *** Error code 1 Stop in /usr/cursrc/src. [crees@hydra]/usr/cursrc/src% Any ideas please??? Not that it's probably relevant, but CERBERUS is a copy of the csupped XBOX kernel with options KDB_UNATTENDED added. Chris From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 19:15:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B290A106566C for ; Sun, 26 Jun 2011 19:15:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73A5D8FC0C for ; Sun, 26 Jun 2011 19:15:17 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 201035C59; Sun, 26 Jun 2011 20:55:48 +0200 (CEST) Message-ID: <4E0780AF.7030203@FreeBSD.org> Date: Sun, 26 Jun 2011 20:55:43 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.19pre) Gecko/20110622 Lanikai/3.1.12pre MIME-Version: 1.0 To: Chris Rees References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Build failure during 9-CURRENT make world 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, 26 Jun 2011 19:15:17 -0000 On 2011-06-26 20:43, Chris Rees wrote: ... > cd /usr/cursrc/src > make KERNCONF=CERBERUS DESTDIR=/mnt world kernel ... > /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: > could not read symbols: File format not recognized ... > Any ideas please??? The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a is busted, for some reason. My guess would be that you built it for a different architecture. You can try removing it, and building again, or if you want to use brute force, zap your entire /usr/obj and rebuild. From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 19:20:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A936D106564A; Sun, 26 Jun 2011 19:20:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6453C8FC17; Sun, 26 Jun 2011 19:20:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QausK-0007Ef-A8>; Sun, 26 Jun 2011 21:20:08 +0200 Received: from e178024206.adsl.alicedsl.de ([85.178.24.206] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QausK-0004oW-71>; Sun, 26 Jun 2011 21:20:08 +0200 Message-ID: <4E078667.4060900@zedat.fu-berlin.de> Date: Sun, 26 Jun 2011 21:20:07 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110622 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dimitry Andric References: <4E059500.40107@zedat.fu-berlin.de> <20110625081056.GA28892@freebsd.org> <4E060484.5050905@zedat.fu-berlin.de> <4E07372A.7000600@FreeBSD.org> In-Reply-To: <4E07372A.7000600@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.24.206 Cc: Roman Divacky , FreeBSD Current Subject: Re: LLVM: llvm-as, llvm-ld and so on not contained in FreeBSD core contrib? 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, 26 Jun 2011 19:20:09 -0000 On 06/26/11 15:42, Dimitry Andric wrote: > On 2011-06-25 17:53, Hartmann, O. wrote: >> On 06/25/11 10:10, Roman Divacky wrote: >>> On Sat, Jun 25, 2011 at 09:57:52AM +0200, Hartmann, O. wrote: >>>> Hello. >>>> Just for my couriosity: I'm missing llvm-as, llvm-ld and other >>>> binutils >>>> from LLVM and was wondering why they are contained in the port's llvm >>>> collection but not in FreeBSD's source contribution. >>> >>> There's no use for these utilities in FreeBSD base system. >>> >>>> I build FreeBSD 9 with CLANG. But as a missing llvm-as and llvm-ld (or >>>> llvm-ar) would imply, the binaries are generated via binutils from >>>> theGNU suite, aren't they? >>> llvm-{as,ld,ar} are not replacements for those from binutils. llvm-* >>> work on the llvm bitcode only and are of no use for normal object >>> files. >>> >>> dim@ made a patch that adds those utilities if you really need them >>> >>> http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-June/000216.html >>> >>> >>> By default when you compile things with clang it uses its own assembler >>> (ie. it goes directly from C -> .o) so typically only gnu ld is used >>> in the compilation chain. >>> >>> >>> roman >> Thank you very much. Patched and works. > > What's the general opinion on applying this to -current? Otherwise > it'll be sitting in my private tree, possibly bit-rotting. :) For > people that are experimenting with llvm and/or clang, these additional > tools might sometimes come in handy. > > For normal users, it won't have any impact, except for a few extra > source files in the tree. These tools will not be built by default. I can only speak for myself and several people of my department, which are doing experiments with LLVM. It is nice to have the knob building the missing tools on demand (should be documented anywhere). I like it and I appreciate your work. Oliver From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 19:46:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1A5106564A for ; Sun, 26 Jun 2011 19:46:45 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 822FE8FC14 for ; Sun, 26 Jun 2011 19:46:45 +0000 (UTC) Received: by iwr19 with SMTP id 19so5029240iwr.13 for ; Sun, 26 Jun 2011 12:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=o9oQYFFxQkqSJp1ghF4pmUi+LmMDUSa+6vRh1tsGLug=; b=DLluFvfxmxIkJY5tASnffrv6Gwmn7C1/yA2u34E3O4AVK8uXsTRL+Dg0NOhWFfyUv7 NejDJK0B+nOjn3pR/68I+KmY8/u6owGVsQXEmTBFNY5RckNbGceH9WHWwPK81NH2Igpj ZZEoq0VHvptl1DxSajVwu5MOT9W/P3whjUYC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=tpHCBBWl8H1bdJc899JLdOMsx0bO7SM2M8aspPzQB2SI1SkBdY1TRmTT8etYR6GM2Q wpfrZNXYsgKwLKIZYPF+eJJeVWFeI+jkfYQtP7YIj0TbZZHhkTwwvim1Wrz+e3/npEoA CgRjLh8c921mxwY+C3tAxgnSrrd6KSksHH3ys= Received: by 10.231.167.197 with SMTP id r5mr5060701iby.70.1309117604804; Sun, 26 Jun 2011 12:46:44 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.49.193 with HTTP; Sun, 26 Jun 2011 12:46:14 -0700 (PDT) In-Reply-To: <4E0780AF.7030203@FreeBSD.org> References: <4E0780AF.7030203@FreeBSD.org> From: Chris Rees Date: Sun, 26 Jun 2011 20:46:14 +0100 X-Google-Sender-Auth: 7OAsjiwXhikdypHk9SGBauav6O8 Message-ID: To: Dimitry Andric , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Build failure during 9-CURRENT make world 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, 26 Jun 2011 19:46:45 -0000 On 26 June 2011 19:55, Dimitry Andric wrote: > On 2011-06-26 20:43, Chris Rees wrote: > ... >> >> cd /usr/cursrc/src >> make KERNCONF=3DCERBERUS DESTDIR=3D/mnt world kernel > > ... >> >> >> /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodege= n/libllvmcodegen.a: >> could not read symbols: File format not recognized > > ... >> >> Any ideas please??? > > The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a > is busted, for some reason. =A0My guess would be that you built it for a > different architecture. =A0You can try removing it, and building again, o= r > if you want to use brute force, zap your entire /usr/obj and rebuild. > I thought I'd tried that... Turns out I hadn't! The file was corrupted presumably because of a disk full error that I had since corrected. I hang my head in shame accordingly. Thanks, Chris From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 20:52:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B593D1065670; Sun, 26 Jun 2011 20:52:23 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 715988FC14; Sun, 26 Jun 2011 20:52:23 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC46F13.dip.t-dialin.net [79.196.111.19]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3845384400D; Sun, 26 Jun 2011 22:52:10 +0200 (CEST) Received: from unknown (unknown [192.168.1.5]) by outgoing.leidinger.net (Postfix) with ESMTP id 8A2212DD1; Sun, 26 Jun 2011 22:52:07 +0200 (CEST) Date: Sun, 26 Jun 2011 22:52:07 +0200 From: Alexander Leidinger To: Andriy Gapon Message-ID: <20110626225207.000022a6@unknown> In-Reply-To: <4E047D26.7070108@FreeBSD.org> References: <6C3F8332272B7D4DA26909F15F1C90E1DDCCC3@SRV01.double-l.local> <4E047D26.7070108@FreeBSD.org> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3845384400D.ABD64 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_SV 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1309726331.13917@BCBYJC3Mcr2sMy4wjBofhQ X-EBL-Spam-Status: No Cc: "freebsd-current@freebsd.org" , Johan Hendriks Subject: Re: MFC 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, 26 Jun 2011 20:52:23 -0000 On Fri, 24 Jun 2011 15:03:50 +0300 Andriy Gapon wrote: > on 24/06/2011 14:44 Johan Hendriks said the following: > > Hello all i have a question regarding MFC > > > > At the svn page from head most revisions comments contain a line > > like MFC after: x weeks or x days. or x months. > > Is this done automaticly, or is this still done by the auther. > > It's done manually. 'MFC after' only states original intent. > Sometimes developers forget to do MFC; sometimes they discover new > circumstances which prevent MFC; etc. As there is an automatic reminder-mail to the developer when the MFC time is triggered, I would not say the developer forgets, it's more that he hasn't the time for it or he voluntary deletes the mail before MFCing (for whatever reason, a showstopper issue may be one of the possible reasons). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 21:33:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEF21065672 for ; Sun, 26 Jun 2011 21:33:01 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE278FC0A for ; Sun, 26 Jun 2011 21:33:01 +0000 (UTC) Received: by yxl31 with SMTP id 31so2237306yxl.13 for ; Sun, 26 Jun 2011 14:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xK6lHBMEqTZkoQG021I25ZAdYp4USqEIenCzaSum5T8=; b=oWjI85KpiAdAyT1dspVW0lCD/I14pmiUCM/JF+tTMLFCJ5FZmo9UFsuFX5JkurDxh2 nfqQ0f3WKlqReoYqG/wSyb+Xbws4Zsx3VD5dwvTiyAs76Lz6VLlyIVJaw48XRws6Ortj QkdN7S1a0rl2QvYRP9QWep8ahx5W27KCvejXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l6tGXDjxjH4P59oS3HkBsKukYPmSqBbYlN8v0q/lIkVQy7bvRYppxLfmTLRWbUIlgr s07+Z1Qqj8uyLvBYbhkeXBouljuZv4C8+tLpTGN580v3vcRMGI8QGAWUPLl+OuflJgn8 KDzFxOJuJbE/kZ9ve86yVAVX/VBLOAj1h/V70= MIME-Version: 1.0 Received: by 10.236.143.101 with SMTP id k65mr7709968yhj.164.1309123980515; Sun, 26 Jun 2011 14:33:00 -0700 (PDT) Received: by 10.236.202.135 with HTTP; Sun, 26 Jun 2011 14:33:00 -0700 (PDT) Date: Sun, 26 Jun 2011 23:33:00 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: /var/crash permissions 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, 26 Jun 2011 21:33:01 -0000 the FreeBSD Developers' Handbook recommends /var/crash to have drwx------ permissions [1]. ``make installworld'' alters those permissions to drwxr-x---. one of the two is trolling. which one? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN From owner-freebsd-current@FreeBSD.ORG Sun Jun 26 22:59:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3158106564A for ; Sun, 26 Jun 2011 22:59:34 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 906D08FC12 for ; Sun, 26 Jun 2011 22:59:34 +0000 (UTC) Received: by iyb11 with SMTP id 11so5129870iyb.13 for ; Sun, 26 Jun 2011 15:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=essOoY/4Vp4CG5hlJFJGbeYYskW+Ats4JNotuNdh0C4=; b=TbyjvoeLOh/aOIjllqpkhjLN4f9284nB3K6eKWECOaOkSKTr4GPPD7lFufwXLxt4q/ pSx5YSekq+2OzpEAAyS+7xnGkPqL8B4WIyg8cbT1fYuPuc2051MSC/rpC4AJS3eeOH38 icFEL750T8tkcxcitwU6VKqS2AcfoblsS1brE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=U8HuL1cFqC8COYleXoWm8HTPSaW/Yglxz6CXhM1RkH0QjS9sp8QclCW+F3fSHjM4ni Wyc32SWqZVe9ZU4sLf5CRNy+8k5JPkNCZoXBaRF0w9t1cpCC6/cHMlSaOBpbC9hbgUxL nOc51lIpO9zmo5pnNcf/fS6pNBuFRaobMi6D0= Received: by 10.42.108.9 with SMTP id f9mr6056675icp.358.1309129173873; Sun, 26 Jun 2011 15:59:33 -0700 (PDT) Received: from disbatch.dataix.local (adsl-99-190-86-179.dsl.klmzmi.sbcglobal.net [99.190.86.179]) by mx.google.com with ESMTPS id s2sm4798638icw.5.2011.06.26.15.59.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Jun 2011 15:59:32 -0700 (PDT) Sender: "J. Hellenthal" Received: from disbatch.dataix.local (localhost [127.0.0.1]) by disbatch.dataix.local (8.14.5/8.14.5) with ESMTP id p5QMxTQD047713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jun 2011 18:59:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by disbatch.dataix.local (8.14.5/8.14.5/Submit) id p5QMxTsL047709; Sun, 26 Jun 2011 18:59:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 26 Jun 2011 18:59:29 -0400 From: jhell To: "deeptech71@gmail.com" Message-ID: <20110626225928.GA38064@DataIX.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: /var/crash permissions 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, 26 Jun 2011 22:59:34 -0000 On Sun, Jun 26, 2011 at 11:33:00PM +0200, deeptech71@gmail.com wrote: > the FreeBSD Developers' Handbook recommends /var/crash to have > drwx------ permissions [1]. ``make installworld'' alters those > permissions to drwxr-x---. one of the two is trolling. which one? > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN It used to be that the permissions were as stated in the handbook but were changed to allow access to the directory by those in group wheel. But as the files that are still created in that directory are still created with a umask of 077 the directories mode being 750 doesnt make any sense as the files there are still not readable by anyone but root owned processes. At this time I would say that the handbook should be changed to reflect its current mode of 750 since its easy to alter the contained files than it is for a user to mess with mtree permissions if they want wheel users to have access to that directory. From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 02:32:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0335B106566C for ; Mon, 27 Jun 2011 02:32:05 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 94FCB8FC15 for ; Mon, 27 Jun 2011 02:32:04 +0000 (UTC) Received: (qmail 22231 invoked from network); 26 Jun 2011 22:32:04 -0400 Received: from ool-6039c07a.static.optonline.net (HELO Macintosh-21.local) (96.57.192.122) by mail.atlantawebhost.com with SMTP; 26 Jun 2011 22:32:03 -0400 Message-ID: <4E07EBA2.70500@shadowsun.net> Date: Sun, 26 Jun 2011 22:32:02 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Clang buildworld failure due to multiple definitions of __isnanf 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, 27 Jun 2011 02:32:05 -0000 I've both seen reports and experienced make buildworld with clang failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what fails), because lint1 is statically linked, and there is a definition of __isnanf in both libc and libm. GCC, on the other hand, builds just fine. The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from math.h. After some investigation, I figured out what's going on. math.h includes a macro version of isnan, which expands out to an expression that calls isnan, __isnanl, and __isnanf. GCC seems to treat all of these as builtin functions, and implements them with its code generator, rather than generating calls. Clang, on the other hand, does not, which leaves calls to __isnanf in the resulting object file, which will result in multiple definitions at link time. There are several possible solutions. The workaround I used is to add -Wl,--allow-multiple-definition to LDADD in the makefile for xlint. A better solution, I think, is to modify math.h with something like this: #ifdef __clang__ #define isnan(n) __builtin_isnan(n) ... #endif (It might be a good idea to add these kinds of definitions for all of clang's builtins, actually.) Anyway, I hope this helps someone. PS. Sorry I don't have build logs, assembler output, etc. My FreeBSD machine's wireless card isn't supported (yet). -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 02:58:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7101C106564A for ; Mon, 27 Jun 2011 02:58:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 395B88FC13 for ; Mon, 27 Jun 2011 02:58:25 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id p5R2wOY8090030; Sun, 26 Jun 2011 19:58:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id p5R2wO15090029; Sun, 26 Jun 2011 19:58:24 -0700 (PDT) (envelope-from sgk) Date: Sun, 26 Jun 2011 19:58:24 -0700 From: Steve Kargl To: Eric McCorkle Message-ID: <20110627025824.GA90022@troutmask.apl.washington.edu> References: <4E07EBA2.70500@shadowsun.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E07EBA2.70500@shadowsun.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 27 Jun 2011 02:58:25 -0000 On Sun, Jun 26, 2011 at 10:32:02PM -0400, Eric McCorkle wrote: > > A better solution, I think, is to modify math.h with something like this: > > #ifdef __clang__ > #define isnan(n) __builtin_isnan(n) > ... > #endif Please, no. Don't touch math.h. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 04:06:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 340C81065670 for ; Mon, 27 Jun 2011 04:06:11 +0000 (UTC) (envelope-from vkushnir@bigmir.net) Received: from ex.volia.net (ex.volia.net [82.144.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id DE65F8FC0A for ; Mon, 27 Jun 2011 04:06:10 +0000 (UTC) Received: from em.volia.net ([82.144.192.9]) by ex.volia.net with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Qb2FT-000F8g-GS; Mon, 27 Jun 2011 06:12:31 +0300 Received: from enough.saddler.volia.net ([93.72.207.82] helo=kushnir1.kiev.ua) by em.volia.net with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Qb2FT-000EZC-A7; Mon, 27 Jun 2011 06:12:31 +0300 Received: from localhost (localhost [IPv6:::1]) by kushnir1.kiev.ua (8.14.5/8.14.5) with ESMTP id p5R3CuXx010027; Mon, 27 Jun 2011 06:12:56 +0300 (EEST) (envelope-from vkushnir@bigmir.net) Date: Mon, 27 Jun 2011 06:12:56 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: Greg Rivers In-Reply-To: Message-ID: References: <201106241531.19375.hselasky@c2i.net> <201106252054.38056.hselasky@c2i.net> <201106261343.53522.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Volia-Original-IP: 93.72.207.82 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [Testing wanted] USB patch for HAL 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, 27 Jun 2011 04:06:11 -0000 Sorry for slightly off-topic post but (see below) On Sun, 26 Jun 2011, Greg Rivers wrote: > On Sun, 26 Jun 2011, Hans Petter Selasky wrote: >> On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: >>> With this change, the USB bus continued to operate as expected while >>> attaching and detaching a USB flash drive. On start up, hald was not >>> detecting the attach/detach events, but started working and kept working >>> after restarting it. In summary, with both of the above changes, >>> everything worked pretty much correctly. >> >> Try this patch to hald: >> >> cd /usr/ports/sysutils/hal/files >> fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c >> >> cd .. >> make all deinstall install clean >> > > With this patch, and the CAM patches still in place, the USB bus works fine, > but hald never sees any attach/detach events, even after restarting it. > > I reverted the CAM patches and tested again with the same result. So this > patch to hald does stop the CAM sg errors, and prevents the USB from wedging. > It just doesn't detect attach events. > > -- > Greg Rivers > _______________________________________________ I'm fairly aware this would be only a workaround rather than a proper solution but isn't it enough to just tell hald to ignore /dev/sg*? What I did was put into /usr/local/etc/hal/fdi/preprobe an fdi I've spotted some time ago (sorry can't recall the original URL) and so far everything works with patched HAL but without any changes to kernel. amd64-CURRENT, desktop, USB mouse and storage devices (flash and HDD). Hope this helps (and sorry for OT again), Vladimir //// 30-ignore-sg.fdi true true true From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 08:20:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C371065670; Mon, 27 Jun 2011 08:20:08 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A49918FC15; Mon, 27 Jun 2011 08:20:07 +0000 (UTC) Received: by bwa20 with SMTP id 20so1569389bwa.13 for ; Mon, 27 Jun 2011 01:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=SyHr7k1tcGscvsCnnT275lBhGu1mb8z3k+cjFJZ3qIo=; b=wO5KvGbwuxCcYGaiKDfkCmEGBQeVuxmqpvdwKAipBpBeCiX1044ngLpUxSEYw+4OsL C6zaKfACxmbu195CqLDQsGMi0rXkXVW5RH7DznQY+WWUVdP9D8jpOJT0zhp96ZNaExps MZz3jLBE3ozLOPgzMnK66uZuwt096hv90Rv6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=VRJ5iwjKnZ9aXszmiCYg75rW3+CGUSPiJG1eGZtDTXKW5IG1jC5a+iPUq3+KcbsdS6 syUXSWpSyFzxVJyTe3gJ75EyIPZoEkFCYlkAJFilhkJ1ab8J0dwQ7xc/ps0k6TKsQ3uq YBZFJxObdlvh833W6LJJFD3HQyH7dD+6pUvt8= Received: by 10.205.24.9 with SMTP id rc9mr4019904bkb.92.1309161240063; Mon, 27 Jun 2011 00:54:00 -0700 (PDT) Received: from localhost (minsk.agava.net [212.98.174.157]) by mx.google.com with ESMTPS id ag6sm3917860bkc.18.2011.06.27.00.53.57 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 00:53:58 -0700 (PDT) Date: Mon, 27 Jun 2011 10:54:08 +0300 From: "Sergey V. Dyatko" To: Bernhard Froehlich Message-ID: <20110627105408.514b3dd5@gmail.com> In-Reply-To: <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> References: <201106241451.23071.jkim@FreeBSD.org> <201106241611.29357.jkim@FreeBSD.org> <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 08:20:08 -0000 On Sat, 25 Jun 2011 16:28:41 +0200 Bernhard Froehlich wrote: > On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: > > On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: > >> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim > > wrote: > >> >> Any ideas regarding the virtualbox itself ? > >> > > >> > I am rebuilding world/kernel now. =EF=BF=BDAfter that, I'll rebuild > >> > virtualbox-ose and try to fix it unless someone beat me to it. > >> > :-) > >> > > >> > Jung-uk Kim > >> > >> Brilliant !!! > >=20 > > Please try this patch: > >=20 > > http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-freebsd-= HostHardwareFreeBSD.cpp > >=20 > > Just drop this in ports/emulators/virtualbox-ose/files and rebuild. >=20 > Thanks a lot, they look good. Do you agree that those two patches are > licensed under MIT License so that i can push them upstream? >=20 Hi,=20 Works good for me (head, amd64). Pushing patches into upstream is a good idea. What prevents to put them in ports tree now? --=20 wbr, tiger From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 10:08:24 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C8106564A; Mon, 27 Jun 2011 10:08:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEC58FC16; Mon, 27 Jun 2011 10:08:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA20175; Mon, 27 Jun 2011 13:08:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qb8jm-0001ue-DE; Mon, 27 Jun 2011 13:08:14 +0300 Message-ID: <4E08568E.4060309@FreeBSD.org> Date: Mon, 27 Jun 2011 13:08:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh References: <4E05F582.2010500@FreeBSD.org> <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> In-Reply-To: <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: kern.sync_on_panic 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, 27 Jun 2011 10:08:24 -0000 on 26/06/2011 08:51 Warner Losh said the following: > > On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: >> Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, then >> in what circumstances do you need it? That is, why any other alternative >> doesn't work for you? Like: 1. remounting filesystems R/O before panic if >> you knowingly provoke it for testing 2. using netboot for your test system >> 3. using su+j, gjournal or a different filesystem altogether 4. using fsck >> after reboot >> >> It seems to me that syncing filesystems in panic context is an adventure. >> And it may become even more of an adventure if we introduce code that >> completely stops scheduler in and after panic. > > I've used it in the past when I was developing a device driver that was in > the late stages of maturing. Since all the panics in the system were when > the driver dereferenced NULL in that driver, sync was safe because all the > data structures were sane except the aforementioned driver. > > (1) It was a production system, and everything that could be was already > mounted r/w. However, some small, but every critical, amount of data was > still r/w and it was very important to not lose this data. Production here > likely should be in quotes, because it was in the late stages of > testing/validation. The problem was without this sometimes the saved state > of the GPS receiver and other hardware would wind up being zero, which meant > that we'd have to do a cold start which cost us a few hours of time. At the > time I was doing this, we saw zero files a couple times a day without this > turned on. (2) netbooting wasn't an option since we were qualifying a > non-netbooting system. (3) these weren't available at the time, but the goal > was to prevent data loss, not to necessarily have to avoid fsck on boot. (4) > Data loss without it. > > Now, I'll be the first to admit this has been a few years, and I haven't done > a fresh evaluation to see if things are still safe. I'll also be the first > to admit that this was a useful debugging setting late in development, and > not in production. I'm also the first to admit this isn't what I'd call a > very wide-spread case. But it did come in very handy when chasing a few bugs > to be able to do 10 panic/reboot cycles an hour rather than 2 a day. A fine enough use-case for me. I guess the problem ultimately boiled down to peculiarities of UFS behavior, but still... However, please be aware that sync_on_panic might get broken when/if we start stopping scheduler in panic. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 10:04:28 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF80106566C for ; Mon, 27 Jun 2011 10:04:28 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB588FC22 for ; Mon, 27 Jun 2011 10:04:27 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 03656B; Mon, 27 Jun 2011 11:49:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Mon, 27 Jun 2011 11:49:20 +0200 From: Bernhard Froehlich To: "Sergey V. Dyatko" In-Reply-To: <20110627105408.514b3dd5@gmail.com> References: <201106241451.23071.jkim@FreeBSD.org> <201106241611.29357.jkim@FreeBSD.org> <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> <20110627105408.514b3dd5@gmail.com> Message-ID: <38f7bca04e7d0169f80d5185af46c403@bluelife.at> X-Sender: decke@bluelife.at User-Agent: Roundcube Webmail/0.5.3 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0202.4E08521F.01BA,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-Mailman-Approved-At: Mon, 27 Jun 2011 11:10:20 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 10:04:28 -0000 On Mon, 27 Jun 2011 10:54:08 +0300, Sergey V. Dyatko wrote: > On Sat, 25 Jun 2011 16:28:41 +0200 > Bernhard Froehlich wrote: > >> On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: >> > On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: >> >> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim >> > wrote: >> >> >> Any ideas regarding the virtualbox itself ? >> >> > >> >> > I am rebuilding world/kernel now. �After that, I'll rebuild >> >> > virtualbox-ose and try to fix it unless someone beat me to it. >> >> > :-) >> >> > >> >> > Jung-uk Kim >> >> >> >> Brilliant !!! >> > >> > Please try this patch: >> > >> > http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-freebsd-HostHardwareFreeBSD.cpp >> > >> > Just drop this in ports/emulators/virtualbox-ose/files and rebuild. >> >> Thanks a lot, they look good. Do you agree that those two patches are >> licensed under MIT License so that i can push them upstream? >> > Hi, > > Works good for me (head, amd64). > Pushing patches into upstream is a good idea. What prevents > to put them in ports tree now? I just waited for some feedback as I could not test it myself right now. -- Bernhard Fröhlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 12:29:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C66106564A for ; Mon, 27 Jun 2011 12:29:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0687F8FC18 for ; Mon, 27 Jun 2011 12:29:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c85c:48ef:432b:843] (unknown [IPv6:2001:7b8:3a7:0:c85c:48ef:432b:843]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3A4325C59; Mon, 27 Jun 2011 14:29:03 +0200 (CEST) Message-ID: <4E08778D.2050302@FreeBSD.org> Date: Mon, 27 Jun 2011 14:29:01 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.19pre) Gecko/20110622 Lanikai/3.1.12pre MIME-Version: 1.0 To: Eric McCorkle References: <4E07EBA2.70500@shadowsun.net> In-Reply-To: <4E07EBA2.70500@shadowsun.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 27 Jun 2011 12:29:06 -0000 On 2011-06-27 04:32, Eric McCorkle wrote: > I've both seen reports and experienced make buildworld with clang > failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what > fails), because lint1 is statically linked, and there is a definition of > __isnanf in both libc and libm. GCC, on the other hand, builds just fine. ... I have never seen this failure, and neither does the clang buildbot, so maybe there is something in your build environment causing this problem? Can you please post: - Your build architecture (e.g. i386 or amd64) - Your /etc/make.conf and /etc/src.conf, if applicable - Any build-related environment variables (WITH_FOO, WITHOUT_FOO, CFLAGS, etc) > The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from > math.h. After some investigation, I figured out what's going on. > math.h includes a macro version of isnan, which expands out to an > expression that calls isnan, __isnanl, and __isnanf. GCC seems to treat > all of these as builtin functions, and implements them with its code > generator, rather than generating calls. Clang, on the other hand, does > not, which leaves calls to __isnanf in the resulting object file, which > will result in multiple definitions at link time. I don't see this at all here. Clang simply expands the macro: #define isnan(x) \ ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ : (sizeof (x) == sizeof (double)) ? isnan(x) \ : __isnanl(x)) then sees x is a double, so eliminates the unneeded parts of the ?: operators, and simply calls the isnan() function. There is no trace of __isnanf() anywhere in the resulting .s or .o file. Maybe you compiled with non-default optimization flags? If so, please supply them. > There are several possible solutions. The workaround I used is to add > -Wl,--allow-multiple-definition to LDADD in the makefile for xlint. Actually, I think the problem is that there are multiple definitions of __isnanf(), one in libc and one in libm. In lib/libc/gen/isnan.c, there is this comment: /* * XXX These routines belong in libm, but they must remain in libc for * binary compat until we can bump libm's major version number. */ after which both __isnan() and __isnanf() are defined, and weakly bound to isnan() and isnanf(). Then, in lib/msun/src/s_isnan.c, the isnan() definition is commented out, but not the __isnanf() definition. I think this never caused a problem with gcc, since, as you said, it usually expands it using builtins. Weirdly enough, a small test program that directly calls __isnanf(), and is linked with -lm doesn't cause any problems here, neither with gcc, nor with clang. > A better solution, I think, is to modify math.h with something like this: > > #ifdef __clang__ > #define isnan(n) __builtin_isnan(n) > ... > #endif > > (It might be a good idea to add these kinds of definitions for all of > clang's builtins, actually.) I'm not sure why gcc inserts builtins for isnan() and friends, since if you wanted those, you should probably #define isnan as __builtin_isnan. Otherwise, the implementations in libc and libm would never be used. I hope those are 'better' than the ones builtin to gcc (or clang), but this is not really for me to say, better ask Bruce Evans, David Schultz or Steve Kargl. :) From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 14:18:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEE07106564A for ; Mon, 27 Jun 2011 14:18:11 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD1778FC15 for ; Mon, 27 Jun 2011 14:18:11 +0000 (UTC) Received: by pwi7 with SMTP id 7so2075603pwi.13 for ; Mon, 27 Jun 2011 07:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lDBZm1IKZtfWkQMjpQ+aazqDqoASQ/j3+MrOO3GirGI=; b=Psv1wShDahdVSW5c5h0D9ooq8NuyyRSCFaljMeIMBKstIWkfhEMC8filcH8rw6Qv1L QdhXLrBWiyObReiatTgixSJEvC/4Zwz+soUgPLU83d1DSJ+URz3xGQ7Rqsh49qY5Vf4z cLOaj6r3seAsTeVvV8q36unMygL1UmlJ+kiWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ojy3iDpe352c8e1X+EHAjZ31qfkFXD8sgZLHiLnn2niYEHThz3uN6UTTNv6LBqxsmW MfcUPgSDie28+l25HSdm6yBDjoeU9LOirHC9rCzrxDCazodj8ZxQrwyNdn9bfLOsr5ur IdLBttOAY5xXdJeWi2jRS1xAk07Vy53x21LJU= Received: by 10.142.49.15 with SMTP id w15mr1187257wfw.328.1309184291172; Mon, 27 Jun 2011 07:18:11 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id x1sm4341791pbb.82.2011.06.27.07.18.08 (version=SSLv3 cipher=OTHER); Mon, 27 Jun 2011 07:18:09 -0700 (PDT) Message-ID: <4E08911F.8040701@gmail.com> Date: Mon, 27 Jun 2011 07:18:07 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <201106241451.23071.jkim@FreeBSD.org> <201106241611.29357.jkim@FreeBSD.org> <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> <20110627105408.514b3dd5@gmail.com> <38f7bca04e7d0169f80d5185af46c403@bluelife.at> In-Reply-To: <38f7bca04e7d0169f80d5185af46c403@bluelife.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 14:18:12 -0000 On 06/27/11 02:49, Bernhard Froehlich wrote: > On Mon, 27 Jun 2011 10:54:08 +0300, Sergey V. Dyatko wrote: >> On Sat, 25 Jun 2011 16:28:41 +0200 >> Bernhard Froehlich wrote: >> >>> On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: >>>> On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: >>>>> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim >>>> wrote: >>>>>>> Any ideas regarding the virtualbox itself ? >>>>>> I am rebuilding world/kernel now. �After that, I'll rebuild >>>>>> virtualbox-ose and try to fix it unless someone beat me to it. >>>>>> :-) >>>>>> >>>>>> Jung-uk Kim >>>>> Brilliant !!! >>>> Please try this patch: >>>> >>>> http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-freebsd-HostHardwareFreeBSD.cpp >>>> >>>> Just drop this in ports/emulators/virtualbox-ose/files and rebuild. >>> Thanks a lot, they look good. Do you agree that those two patches are >>> licensed under MIT License so that i can push them upstream? >>> >> Hi, >> >> Works good for me (head, amd64). >> Pushing patches into upstream is a good idea. What prevents >> to put them in ports tree now? > I just waited for some feedback as I could not test it myself right > now. > Worked on my machines running a VM with two procs, also was able to complete two different OS installs. No issues for what it's worth. Thanks again, Matt From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 15:40:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 670D7106566C; Mon, 27 Jun 2011 15:40:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bernhard Froehlich Date: Mon, 27 Jun 2011 11:40:31 -0400 User-Agent: KMail/1.6.2 References: <201106241611.29357.jkim@FreeBSD.org> <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> In-Reply-To: <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201106271140.36038.jkim@FreeBSD.org> Cc: Matt , freebsd-current@freebsd.org, George Kontostanos Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 15:40:51 -0000 On Saturday 25 June 2011 10:28 am, Bernhard Froehlich wrote: > On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: > > On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: > >> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim > > > > wrote: > >> >> Any ideas regarding the virtualbox itself ? > >> > > >> > I am rebuilding world/kernel now. �After that, I'll rebuild > >> > virtualbox-ose and try to fix it unless someone beat me to it. > >> > > >> > :-) > >> > > >> > Jung-uk Kim > >> > >> Brilliant !!! > > > > Please try this patch: > > > > http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-fr > >eebsd-HostHardwareFreeBSD.cpp > > > > Just drop this in ports/emulators/virtualbox-ose/files and > > rebuild. > > Thanks a lot, they look good. Do you agree that those two patches > are licensed under MIT License so that i can push them upstream? Yes, of course. Please feel free. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 15:50:09 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 435D21065673 for ; Mon, 27 Jun 2011 15:50:09 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id ACE7A8FC17 for ; Mon, 27 Jun 2011 15:50:08 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 127815EE; Mon, 27 Jun 2011 16:22:46 +0200 (CEST) Date: Mon, 27 Jun 2011 17:31:44 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20110627153144.GF1775@garage.freebsd.pl> References: <4DDD4890.70604@FreeBSD.org> <86hb8du5fo.fsf@kopusha.home.net> <4DE89AA3.908@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5L6AZ1aJH5mDrqCQ" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , "current@freebsd.org" Subject: Re: Weird issue with hastd(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:50:09 -0000 --5L6AZ1aJH5mDrqCQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 25, 2011 at 05:54:13PM +0300, Mikolaj Golub wrote: > For me the idea to send updates to secondary only via > synchronization thread, starting it periodically looks > interesting. Sure it should not be the replacement for "real" > async mode, but having something like this in hast apart other > synchronization modes might be useful. >=20 > Comparing it with "real" async that is described in manual it has > the following advantages: >=20 > 1) It is much easier to implement. >=20 > 2) If you have frequent updates of the same blocks, "real" async > will send them all, while with sync thread approach we will skip > many intermediate updates. I must say I don't agree with your points here. We should not implement one more replication mode, because it is easier to implement. Imagine situation when we finally get proper 'async' mode and we will need to explain to the users the difference between 'async' and 'async2' modes as "async2 was easier to implement back when we had no async yet, but for you it does more or less the same". And we will need to keep support for both of them. If anything, I'd prefer to call it 'async' and then change underlying algorithm entirely. This will handle users confusion, but still leaves the need to protocol compatiblity between hastds implementing older and newer 'async'. The second argument reveals weakness of this approach. The very important thing is to keep data consistent when nodes are connected. By 'consistent' I mean that in every point in time if primary dies, secondary can start operating - it may have a bit older data in async mode, but the data will be consistent - you can fsck file system and start your services. In the way you described no care is taken to move the data to the secondary node in proper order, ie. some later writes can be send before earlier writes, because eg. they are placed in lower extent and if you have primary failure right there, the secondary data view won't be consistent and your file system will most likely by corrupt. In async mode you can skip and combine only consecutive writes. For example if your queue contains the following writes (number. offset size): 1. 0 1024 2. 512 1024 3. 0 1024 4. 4096 1024 5. 0 1536 You can compress it to: 2+3. 0 1536 4. 4096 1024 5. 0 1536 Where we ignore first write entirely and combine writes 2 and 3, but we cannot simply skip first three writes, only because we have fifth write that covers them, as there is 4096,1024 request in between. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --5L6AZ1aJH5mDrqCQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk4Iol8ACgkQForvXbEpPzRrDwCbB8mNf6u0MMjMfuzNWmg/V8/p BMQAn0KGlSVBRzPFP5dVSLk4qAuj7vPP =caqZ -----END PGP SIGNATURE----- --5L6AZ1aJH5mDrqCQ-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 15:50:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F27A5106566B for ; Mon, 27 Jun 2011 15:50:41 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC6C68FC0A for ; Mon, 27 Jun 2011 15:50:41 +0000 (UTC) Received: by pwi7 with SMTP id 7so2151963pwi.13 for ; Mon, 27 Jun 2011 08:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=BG9OwKJkNjN91Tc4RJk9kdeX41xMDR9KoLaAMsIPOps=; b=dbe7DcJ5s5/+FU1x51bftxAxCM9QN5M7A5OCC/a12/3VvyKWsl4xCNVoZOjWC5nniU I4CEqP0rkNj4MeBXrJr/ez6eNWmOLA5R0RckbQ1XTrxfdUWqMphtn6X/RAWFFNF2ZeXb aqDCEknAOl0Yq5jOjKFFVUukwdRsn3Dv+T+A8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ecqO4YPo7xwSxaCSZ5ocCVFDAW4lB3uJwQSe1vwxuVDlForb73l8iAJcTtj6eHfcj7 gV9JSglpdBH1mw9wKdUGyvwAf06TIay7PrFBfXM53seMQyY/vPX8ilNW4qFNYPDqtUxX /NpUJDRFoa2F+tH3F7ukt5To5my3OR3689ItI= MIME-Version: 1.0 Received: by 10.68.65.105 with SMTP id w9mr3119925pbs.39.1309187973745; Mon, 27 Jun 2011 08:19:33 -0700 (PDT) Received: by 10.68.56.104 with HTTP; Mon, 27 Jun 2011 08:19:33 -0700 (PDT) Date: Mon, 27 Jun 2011 19:19:33 +0400 Message-ID: From: KOT MATPOCKuH To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: =?koi8-r?b?bmFtZWQgY3Jhc2hlcyBvbiBhc3NlcnRpb24gaW4gcmJ0ZGIuYyBv?= =?koi8-r?b?1CBzcGFyYzY0L1NNUA==?= 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, 27 Jun 2011 15:50:42 -0000 Hello! I'm got a problem with named on FreeBSD-CURRENT/sparc64. Up to 5 times a day it crashes with these messages: 27-Jun-2011 03:42:14.384 general: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: REQUIRE(prev > 0) failed 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) The problem is still in latest system's bind: # named -v BIND 9.6.-ESV-R4-P1 This problem exists only on SMP sparc64 system. On my another sparc64, with 1 processor, I does not have this problem. I found a some similar problems on alpha and IA64, which was related to problems with isc_atomic_xadd() function in include/isc/atomic.h. But I don't understand that there may be incorrect for sparc64 and this function was not changed for a minimum 4 years... How can I help solve this problem? -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 15:59:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432DF106564A for ; Mon, 27 Jun 2011 15:59:25 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id EC8BF8FC12 for ; Mon, 27 Jun 2011 15:59:24 +0000 (UTC) Received: (qmail 7076 invoked from network); 27 Jun 2011 11:59:24 -0400 Received: from yktgi01e0-s5.watson.ibm.com (HELO atom-edge.watson.ibm.com) (129.34.20.19) by mail.atlantawebhost.com with SMTP; 27 Jun 2011 11:59:24 -0400 Message-ID: <4E08A8DB.2020805@shadowsun.net> Date: Mon, 27 Jun 2011 11:59:23 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> In-Reply-To: <4E08778D.2050302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 27 Jun 2011 15:59:25 -0000 On 6/27/11 8:29 AM, Dimitry Andric wrote: > On 2011-06-27 04:32, Eric McCorkle wrote: >> I've both seen reports and experienced make buildworld with clang >> failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what >> fails), because lint1 is statically linked, and there is a definition of >> __isnanf in both libc and libm. GCC, on the other hand, builds just fine. > ... > > I have never seen this failure, and neither does the clang buildbot, so > maybe there is something in your build environment causing this problem? > Can you please post: > > - Your build architecture (e.g. i386 or amd64) > - Your /etc/make.conf and /etc/src.conf, if applicable > - Any build-related environment variables (WITH_FOO, WITHOUT_FOO, > CFLAGS, etc) > Sorry. It's an amd64 system, 9-CURRENT, last updated on friday. src.conf: LOADER_ZFS_SUPPORT="YES" make.conf: CPUTYPE?=core2 .if !defined(CC) || ${CC} == "cc" CC=clang CFLAGS=-Qunused-arguments .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif NO_WERROR= WERROR= NO_FSCHG= PERL_VERSION=5.12.3 Just noticed, the CFLAGS would disable optimization, which would explain why no one else seems to see this. Still, I think the underlying issue warrants investigation. > I don't see this at all here. Clang simply expands the macro: > > #define isnan(x) \ > ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ > : (sizeof (x) == sizeof (double)) ? isnan(x) \ > : __isnanl(x)) > > then sees x is a double, so eliminates the unneeded parts of the ?: > operators, and simply calls the isnan() function. There is no trace of > __isnanf() anywhere in the resulting .s or .o file. > > Maybe you compiled with non-default optimization flags? If so, please > supply them. Hmm. I somehow got clang to generate calls to isnan, __isnanf, and __isnanl, (ie expanding the macro but not simplifying it) last night, but I can't seem to reproduce it now... However, compiling: #include double d; int main() { return isnan(d); } with gcc -S -O0 produces a .s file with no calls to isnan, so it's definitely replacing calls to isnan. > /* > * XXX These routines belong in libm, but they must remain in libc for > * binary compat until we can bump libm's major version number. > */ > > after which both __isnan() and __isnanf() are defined, and weakly bound > to isnan() and isnanf(). Then, in lib/msun/src/s_isnan.c, the isnan() > definition is commented out, but not the __isnanf() definition. > > I think this never caused a problem with gcc, since, as you said, it > usually expands it using builtins. I saw that. Perhaps removing the duplicate __isnanf could be rolled into 9-RELEASE? > > Weirdly enough, a small test program that directly calls __isnanf(), and > is linked with -lm doesn't cause any problems here, neither with gcc, > nor with clang. > You need to call __isnanf and something that's in libm, otherwise the linker appears to stop at libc and doesn't link with libm at all. Try this: double d; int main() { return __isnanf(d) && __isnanl(d); } From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 17:42:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C4BE106564A for ; Mon, 27 Jun 2011 17:42:08 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCA58FC16 for ; Mon, 27 Jun 2011 17:42:07 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id p5RHg7m9002546; Mon, 27 Jun 2011 10:42:07 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id p5RHg7Me002545; Mon, 27 Jun 2011 10:42:07 -0700 (PDT) (envelope-from obrien) Date: Mon, 27 Jun 2011 10:42:07 -0700 From: "David O'Brien" To: Kostik Belousov Message-ID: <20110627174207.GA99971@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Kostik Belousov , freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <20110623202153.GS48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110623202153.GS48734@deviant.kiev.zoral.com.ua> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 17:42:08 -0000 Hi KIB, Thanks for the list of issues you know about -- I don't believe we have PRs covering those. On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: > - I believe Peter Holm has more test cases that fails with tmpfs. He > would have more details. I somewhat remember some panic on execve(2) the > binary located on tmpfs. I've been following the patches you've been passing to Peter Holm as part of this thread. Seems good progress has been made in fixing some of the issues. > Removing the warning will not make the issues coming away. Quite true, but is there any other subsystem where we know we have bugs and have put up such a scary warning? I've never used ZFS on i386, but I understand it is trivial to panic with out-of-the-box settings. We don't print a dire warning for ZFS usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. I cannot tell from your response if you're OK or against removing the warning. [especially if your patches pass the Peter Holm test and remove some of the bugs] -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 19:42:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF871106564A for ; Mon, 27 Jun 2011 19:42:33 +0000 (UTC) (envelope-from decke@FreeBSD.org) Received: from groupware.itac.at (groupware.itac.at [91.205.172.99]) by mx1.freebsd.org (Postfix) with ESMTP id 7684A8FC0A for ; Mon, 27 Jun 2011 19:42:33 +0000 (UTC) Received: from home.bluelife.at (93.104.210.95) by groupware.itac.at (Axigen) with (AES256-SHA encrypted) ESMTPSA id 0C1B83; Mon, 27 Jun 2011 21:42:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Mon, 27 Jun 2011 21:42:33 +0200 From: Bernhard Froehlich To: Jung-uk Kim In-Reply-To: <201106271140.36038.jkim@FreeBSD.org> References: <201106241611.29357.jkim@FreeBSD.org> <90df18bd4c1927b0fc1b549d0ad07cd7@bluelife.at> <201106271140.36038.jkim@FreeBSD.org> Message-ID: <9721f5a37d94e11433cef97569570eb6@bluelife.at> X-Sender: decke@FreeBSD.org User-Agent: Roundcube Webmail/0.5.3 X-AxigenSpam-Level: 1 X-CTCH-RefID: str=0001.0A0B0205.4E08DD28.00D6,ss=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown Cc: Matt , freebsd-current@freebsd.org, George, Kontostanos Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 19:42:34 -0000 On Mon, 27 Jun 2011 11:40:31 -0400, Jung-uk Kim wrote: > On Saturday 25 June 2011 10:28 am, Bernhard Froehlich wrote: >> On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: >> > On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: >> >> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim >> > >> > wrote: >> >> >> Any ideas regarding the virtualbox itself ? >> >> > >> >> > I am rebuilding world/kernel now. �After that, I'll rebuild >> >> > virtualbox-ose and try to fix it unless someone beat me to it. >> >> > >> >> > :-) >> >> > >> >> > Jung-uk Kim >> >> >> >> Brilliant !!! >> > >> > Please try this patch: >> > >> > http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server-fr >> >eebsd-HostHardwareFreeBSD.cpp >> > >> > Just drop this in ports/emulators/virtualbox-ose/files and >> > rebuild. >> >> Thanks a lot, they look good. Do you agree that those two patches >> are licensed under MIT License so that i can push them upstream? > > Yes, of course. Please feel free. Shouldn't the changes only be done for __FreeBSD_version >= 900038 ? It's also not fully correct because the version wasn't bumped for the CAM changes but it's the best we can get. The same is true for the cpuset_t change but the version wasn't bumped either. http://svnweb.freebsd.org/base?view=revision&revision=223081 http://svnweb.freebsd.org/base?view=revision&revision=222813 -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 19:44:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB48106567C; Mon, 27 Jun 2011 19:44:02 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B246E8FC18; Mon, 27 Jun 2011 19:44:01 +0000 (UTC) Received: by qwc9 with SMTP id 9so3325799qwc.13 for ; Mon, 27 Jun 2011 12:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Byw1LAt81lMq+TWGgK6RADIQ6nTVMrpLaO6WoCIpF8=; b=pFJolZ5LjOqENLfxJRFf6vXBXQEc/uWAJfxm90T61x9Cj+b7jM+13sHqV3BB5jiHfL DxziLzymcytsTrDB2W/bunrlpVHlMgz5zY1u5ihMwlb41nDw/NBlikV06QUT7WLYoT6F eW3MeKxDhm4rbeNRRYIxqUEJ6vkM2k8TjKVRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dIAqSUBh177ZiXnvwS4CIWta7at6vhppdCwPOHq3C/Z2vAJG38uIqqnNDnVxIpqR5i qKMoCu93/iMlhPC9TipRFMMHHzLiYGw1vcDG2Sr5K4qM3WNHBKtYklTuzajI0jXNjTxK 1Cp4r25iQKF/blwWES35t9ifiqDSyvKE/IoA8= MIME-Version: 1.0 Received: by 10.229.2.131 with SMTP id 3mr4966220qcj.156.1309202387229; Mon, 27 Jun 2011 12:19:47 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.62.229 with HTTP; Mon, 27 Jun 2011 12:19:47 -0700 (PDT) In-Reply-To: <4E08568E.4060309@FreeBSD.org> References: <4E05F582.2010500@FreeBSD.org> <6C42CE07-9298-444A-8094-9C60384CA4F1@bsdimp.com> <4E08568E.4060309@FreeBSD.org> Date: Mon, 27 Jun 2011 12:19:47 -0700 X-Google-Sender-Auth: i-1OHeDAibxgLbgyt5oGPFFA918 Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Warner Losh Subject: Re: kern.sync_on_panic 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, 27 Jun 2011 19:44:02 -0000 On Mon, Jun 27, 2011 at 3:08 AM, Andriy Gapon wrote: > on 26/06/2011 08:51 Warner Losh said the following: >> >> On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote: >>> Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, th= en >>> in what circumstances do you need it? That is, why any other alternativ= e >>> doesn't work for you? Like: 1. remounting filesystems R/O before panic = if >>> you knowingly provoke it for testing 2. using netboot for your test sys= tem >>> 3. using su+j, gjournal or a different filesystem altogether 4. using f= sck >>> after reboot >>> >>> It seems to me that syncing filesystems in panic context is an adventur= e. >>> And it may become even more of an adventure if we introduce code that >>> completely stops scheduler in and after panic. >> >> I've used it in the past when I was developing a device driver that was = in >> the late stages of maturing. =A0Since all the panics in the system were = when >> the driver dereferenced NULL in that driver, sync was safe because all t= he >> data structures were sane except the aforementioned driver. >> >> (1) It was a production system, and everything that could be was already >> mounted r/w. =A0However, some small, but every critical, amount of data = was >> still r/w and it was very important to not lose this data. =A0Production= here >> likely should be in quotes, because it was in the late stages of >> testing/validation. =A0The problem was without this sometimes the saved = state >> of the GPS receiver and other hardware would wind up being zero, which m= eant >> that we'd have to do a cold start which cost us a few hours of time. =A0= At the >> time I was doing this, we saw zero files a couple times a day without th= is >> turned on. (2) netbooting wasn't an option since we were qualifying a >> non-netbooting system. (3) these weren't available at the time, but the = goal >> was to prevent data loss, not to necessarily have to avoid fsck on boot.= (4) >> Data loss without it. >> >> Now, I'll be the first to admit this has been a few years, and I haven't= done >> a fresh evaluation to see if things are still safe. =A0I'll also be the = first >> to admit that this was a useful debugging setting late in development, a= nd >> not in production. =A0I'm also the first to admit this isn't what I'd ca= ll a >> very wide-spread case. =A0But it did come in very handy when chasing a f= ew bugs >> to be able to do 10 panic/reboot cycles an hour rather than 2 a day. > > A fine enough use-case for me. =A0I guess the problem ultimately boiled d= own to > peculiarities of UFS behavior, but still... > However, please be aware that sync_on_panic might get broken when/if we s= tart > stopping scheduler in panic. The entirety of the sync code should be a subroutine in vfs_bio.c so the 'buf' variable is static to the file. At that point it would be reasonable to explicitly call it at the beginning of panic(9) for the sync-on-panic case, either before IPIing the other CPUs, or at least before entering the critical section that prevents the scheduler from running. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 20:01:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 550A1106564A; Mon, 27 Jun 2011 20:01:13 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bernhard Froehlich Date: Mon, 27 Jun 2011 16:00:55 -0400 User-Agent: KMail/1.6.2 References: <201106271140.36038.jkim@FreeBSD.org> <9721f5a37d94e11433cef97569570eb6@bluelife.at> In-Reply-To: <9721f5a37d94e11433cef97569570eb6@bluelife.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201106271600.57713.jkim@FreeBSD.org> Cc: Matt , freebsd-current@freebsd.org, George Kontostanos Subject: Re: virtualbox-ose 4.0.8 fails 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, 27 Jun 2011 20:01:14 -0000 On Monday 27 June 2011 03:42 pm, Bernhard Froehlich wrote: > On Mon, 27 Jun 2011 11:40:31 -0400, Jung-uk Kim wrote: > > On Saturday 25 June 2011 10:28 am, Bernhard Froehlich wrote: > >> On Fri, 24 Jun 2011 16:11:27 -0400, Jung-uk Kim wrote: > >> > On Friday 24 June 2011 02:58 pm, George Kontostanos wrote: > >> >> On Fri, Jun 24, 2011 at 9:51 PM, Jung-uk Kim > >> >> > >> > > >> > wrote: > >> >> >> Any ideas regarding the virtualbox itself ? > >> >> > > >> >> > I am rebuilding world/kernel now. �After that, I'll rebuild > >> >> > virtualbox-ose and try to fix it unless someone beat me to > >> >> > it. > >> >> > > >> >> > :-) > >> >> > > >> >> > Jung-uk Kim > >> >> > >> >> Brilliant !!! > >> > > >> > Please try this patch: > >> > > >> > http://people.freebsd.org/~jkim/patch-src-VBox-Main-src-server > >> >-fr eebsd-HostHardwareFreeBSD.cpp > >> > > >> > Just drop this in ports/emulators/virtualbox-ose/files and > >> > rebuild. > >> > >> Thanks a lot, they look good. Do you agree that those two > >> patches are licensed under MIT License so that i can push them > >> upstream? > > > > Yes, of course. Please feel free. > > Shouldn't the changes only be done for __FreeBSD_version >= 900038 > ? It's also not fully correct because the version wasn't bumped for > the CAM changes but it's the best we can get. > > The same is true for the cpuset_t change but the version wasn't > bumped either. > > http://svnweb.freebsd.org/base?view=revision&revision=223081 > http://svnweb.freebsd.org/base?view=revision&revision=222813 To be absolutely correct, yes, we need to bump __FreeBSD_version first. However, it is very close to feature freeze and I don't think anybody wants to do that ATM. For -CURRENT, I don't think it really matters as I said earlier: http://docs.freebsd.org/cgi/mid.cgi?201106241352.14262.jkim Now, are you going to "fix" __FreeBSD_version >= 700000 in these files, too? ;-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 21:58:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91FF5106566B; Mon, 27 Jun 2011 21:58:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 483668FC14; Mon, 27 Jun 2011 21:58:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p5RLwDQV030048; Mon, 27 Jun 2011 17:58:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p5RLwDjE030025; Mon, 27 Jun 2011 21:58:13 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 27 Jun 2011 21:58:13 GMT Message-Id: <201106272158.p5RLwDjE030025@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Mon, 27 Jun 2011 21:58:14 -0000 TB --- 2011-06-27 20:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-27 20:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-06-27 20:10:00 - cleaning the object tree TB --- 2011-06-27 20:10:43 - cvsupping the source tree TB --- 2011-06-27 20:10:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-06-27 20:10:56 - building world TB --- 2011-06-27 20:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-27 20:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-27 20:10:56 - TARGET=amd64 TB --- 2011-06-27 20:10:56 - TARGET_ARCH=amd64 TB --- 2011-06-27 20:10:56 - TZ=UTC TB --- 2011-06-27 20:10:56 - __MAKE_CONF=/dev/null TB --- 2011-06-27 20:10:56 - cd /src TB --- 2011-06-27 20:10:56 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 27 20:10:56 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm pxeboot.tmp ===> sys/boot/i386/zfsboot (all) cc -DBOOTPROG=\"zfsboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/zfsboot/../../common -I/src/sys/boot/i386/zfsboot/../common -I/src/sys/boot/i386/zfsboot/../../zfs -I/src/sys/boot/i386/zfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/zfsboot/../btx/lib -I. -I/src/sys/boot/i386/zfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -c /src/sys/boot/i386/zfsboot/zfsldr.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -e main -Ttext 0x7c00 -o zfsldr.out zfsldr.o zfsldr.o: In function `main': (.text+0xa): undefined reference to `start' zfsldr.o: In function `seta20.3': (.text+0xa7): undefined reference to `start' *** Error code 1 Stop in /src/sys/boot/i386/zfsboot. *** Error code 1 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-27 21:58:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-27 21:58:12 - ERROR: failed to build world TB --- 2011-06-27 21:58:12 - 5143.55 user 937.30 system 6492.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 27 22:03:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6511065673; Mon, 27 Jun 2011 22:03:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 628FD8FC28; Mon, 27 Jun 2011 22:03:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p5RM3D0c083691; Mon, 27 Jun 2011 18:03:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p5RM3DcF083690; Mon, 27 Jun 2011 22:03:13 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 27 Jun 2011 22:03:13 GMT Message-Id: <201106272203.p5RM3DcF083690@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Mon, 27 Jun 2011 22:03:14 -0000 TB --- 2011-06-27 20:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-27 20:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-06-27 20:10:00 - cleaning the object tree TB --- 2011-06-27 20:10:44 - cvsupping the source tree TB --- 2011-06-27 20:10:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-06-27 20:16:07 - building world TB --- 2011-06-27 20:16:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-27 20:16:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-27 20:16:07 - TARGET=i386 TB --- 2011-06-27 20:16:07 - TARGET_ARCH=i386 TB --- 2011-06-27 20:16:07 - TZ=UTC TB --- 2011-06-27 20:16:07 - __MAKE_CONF=/dev/null TB --- 2011-06-27 20:16:07 - cd /src TB --- 2011-06-27 20:16:07 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 27 20:16:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm pxeboot.tmp ===> sys/boot/i386/zfsboot (all) cc -DBOOTPROG=\"zfsboot\" -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -DBOOT2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/zfsboot/../../common -I/src/sys/boot/i386/zfsboot/../common -I/src/sys/boot/i386/zfsboot/../../zfs -I/src/sys/boot/i386/zfsboot/../../../cddl/boot/zfs -I/src/sys/boot/i386/zfsboot/../btx/lib -I. -I/src/sys/boot/i386/zfsboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -c /src/sys/boot/i386/zfsboot/zfsldr.S ld -static -N --gc-sections -nostdlib -e main -Ttext 0x7c00 -o zfsldr.out zfsldr.o zfsldr.o: In function `main': (.text+0xa): undefined reference to `start' zfsldr.o: In function `seta20.3': (.text+0xa7): undefined reference to `start' *** Error code 1 Stop in /src/sys/boot/i386/zfsboot. *** Error code 1 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-27 22:03:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-27 22:03:13 - ERROR: failed to build world TB --- 2011-06-27 22:03:13 - 5101.20 user 921.73 system 6792.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 04:34:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE3E106564A for ; Tue, 28 Jun 2011 04:34:28 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id A34AA8FC08 for ; Tue, 28 Jun 2011 04:34:28 +0000 (UTC) X-AuditID: 12074424-b7bc6ae000005a77-df-4e09564e3726 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5D.A5.23159.E46590E4; Tue, 28 Jun 2011 00:19:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p5S4JP6m020257; Tue, 28 Jun 2011 00:19:26 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5S4JLn7006812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2011 00:19:25 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p5S4JLgm008512; Tue, 28 Jun 2011 00:19:21 -0400 (EDT) Date: Tue, 28 Jun 2011 00:19:20 -0400 (EDT) From: Benjamin Kaduk To: Eric McCorkle In-Reply-To: <4E08A8DB.2020805@shadowsun.net> Message-ID: References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> <4E08A8DB.2020805@shadowsun.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrusXxulnMHGTmMX/F7uYLOa8+cDk wOQx49N8Fo8rKz8xBzBFcdmkpOZklqUW6dslcGXs3LyYveAVR8Xno34NjP/Zuhg5OSQETCTO fJ7LAmGLSVy4tx4ozsUhJLCPUaJ9zStmCGcDo8St5ytZIZwDTBKv5i5khHAaGCWe/VjMCtLP IqAtsfn5XyYQm01ARWLmm41gO0QE1CR+NW0C28EsIC/x/8plsBphAX+JWd9aweKcAroSn/bu ZQSxeQUcJPZvewVmCwlkSTzdcQNsvqiAjsTq/VNYIGoEJU7OfAI101Li3J/rbBMYBWchSc1C klrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjOFRdVHYwNh9SOsQowMGo xMPLuJLDT4g1say4MvcQoyQHk5Io755gTj8hvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxTjYBy vCmJlVWpRfkwKWkOFiVx3lLv/75CAumJJanZqakFqUUwWRkODiUJ3nchQI2CRanpqRVpmTkl CGkmDk6Q4TxAw++HggwvLkjMLc5Mh8ifYlSUEud9BZIQAElklObB9cJSyStGcaBXhHmfgFTx ANMQXPcroMFMQIN1TDlABpckIqSkGhiD5F5GTft59WdP6qqPupcZKjYsu2uQx2Eu+5r36Nyp CsHrf+jd1/xVpBVel3o9cc3PE/Z3FxzzjdK1yJU+N+9QlkvqxdJ1SnWb1aZ4R3wq6Mn/wpFl uTL/L9uthDzGM/FrprNP3Zg9xUT3ePOq9DStVx5Cb+MDRLq/b910c8VuI4HFn9eKTpBVYinO SDTUYi4qTgQAVg8WaQADAAA= Cc: freebsd-current@freebsd.org Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 28 Jun 2011 04:34:29 -0000 On Mon, 27 Jun 2011, Eric McCorkle wrote: > make.conf: > CPUTYPE?=core2 > .if !defined(CC) || ${CC} == "cc" > CC=clang > CFLAGS=-Qunused-arguments > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > NO_WERROR= > WERROR= > NO_FSCHG= > PERL_VERSION=5.12.3 > > Just noticed, the CFLAGS would disable optimization, which would explain why > no one else seems to see this. Still, I think the underlying issue warrants > investigation. I seem to recall that our gcc-4.2 with -O0 is known to be buggy -- certainly I just tripped over a panic in a third-party kernel module build using bsd.kmod.mk with -O0 that was fixed by compiling the object in question with -O. It is not terribly easy to search for, but my archives find at least http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076028.html I would try with -O1 and confirm that your issues go away, and not spend time on the core issue if it proves to be a gcc bug. Unfortunately, we are stuck with an old gcc in base ... though I have yet to see if clang -O0 has issues with my module. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 05:11:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EE2A1065675 for ; Tue, 28 Jun 2011 05:11:08 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1822C8FC16 for ; Tue, 28 Jun 2011 05:11:07 +0000 (UTC) Received: by iwr19 with SMTP id 19so6507413iwr.13 for ; Mon, 27 Jun 2011 22:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=jvBeKZrwFYRlizNaj+WSkfRcij78CTULIMN8gFkOxH8=; b=IqHmIXiEw2EaZbwATz2Arn7fKJ6uu6VsCZcQRzZPPLPTCTI6EYv9V9cFSPI2fpUmXP t1TYdNUz9/8iM/V9RKNro2yhHirOErFmd6CL6+bNkjIfSnoJSlMMl2guMNnsk5nuiyZn KIrnPD8+1VjgnXK/x54eo1vhyIhbeapUOMz24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Uy5XFfPfBAn3tfUhG84oiOeGoFJN0cKoXGqDHrwVe4uCUwOBpTU/1SKnCIwYaZWXmg E9xWSY7lwSpFi6xd8aUOv4aw9sCIKGaEKjHODCNj8gTeIVrnLOxO65gNKK224V3TfB0H clHIi0OdR1LToC6/XZpGabnWgUWJTHMKfK6vc= Received: by 10.231.48.197 with SMTP id s5mr2346139ibf.193.1309237866122; Mon, 27 Jun 2011 22:11:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.38.5 with HTTP; Mon, 27 Jun 2011 22:10:46 -0700 (PDT) In-Reply-To: <20110627174207.GA99971@dragon.NUXI.org> References: <20110623163109.GA508@dragon.NUXI.org> <20110623202153.GS48734@deviant.kiev.zoral.com.ua> <20110627174207.GA99971@dragon.NUXI.org> From: Eir Nym Date: Tue, 28 Jun 2011 05:10:46 +0000 Message-ID: To: obrien@freebsd.org, Kostik Belousov , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 28 Jun 2011 05:11:08 -0000 On 27 June 2011 17:42, David O'Brien wrote: > Hi KIB, > Thanks for the list of issues you know about -- I don't believe we have > PRs covering those. > > > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: >> - I believe Peter Holm has more test cases that fails with tmpfs. He >> would have more details. I somewhat remember some panic on execve(2) the >> binary located on tmpfs. > > I've been following the patches you've been passing to Peter Holm as part > of this thread. =C2=A0Seems good progress has been made in fixing some of= the > issues. > > >> Removing the warning will not make the issues coming away. > > Quite true, but is there any other subsystem where we know we have bugs > and have put up such a scary warning? > > I've never used ZFS on i386, but I understand it is trivial to panic > with out-of-the-box settings. =C2=A0We don't print a dire warning for ZFS > usage on 32-bit platforms. =C2=A0So I'm not sure we should keep it for TM= PFS. > amd64 with 4G ram is also not the best for heavy-loaded ZFS server. I have to increase kernel memory up to 1.5-2 G to be sure if it works stable and fast. -- Eir Nym > > I cannot tell from your response if you're OK or against removing > the warning. =C2=A0[especially if your patches pass the Peter Holm test > and remove some of the bugs] > > -- > -- David =C2=A0(obrien@FreeBSD.org) > _______________________________________________ > 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 Tue Jun 28 05:11:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C901065674 for ; Tue, 28 Jun 2011 05:11:47 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by mx1.freebsd.org (Postfix) with SMTP id 4DD978FC20 for ; Tue, 28 Jun 2011 05:11:47 +0000 (UTC) Received: from [98.138.90.57] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 04:58:38 -0000 Received: from [98.138.87.1] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 04:58:38 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 04:58:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 17098.94190.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 89046 invoked by uid 60001); 28 Jun 2011 04:58:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1309237117; bh=VSHo9e1fX0NLy7K7nqNoDJUpl7eFlV6oBGSSQ//j72s=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6L1UZ0MlDQkcUG446qG6PQoR+Rv3FMGMFJtArTbqs4Pg0v6Xh9ECvcDlyyfDn7b/q7QMk3zmjzKI7QmeW+xfCbyJXUa9QdLdCEL/uzesqN7jsA8sgz4+J2smkaYHKcAKEjBNv1DnrPiMExF2+dEHDSOpIYMcf9zVxT2G0QNju1M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lUwhxcX7nS7gJqWcW2zbXqsgj1pviqOV5Atjn3O9/6WSZu46b0SO841JnkeIMy1ICd2Z+x8mXNW+/XJwTObh0CC703agj5I6e3jNQvmyCJzBO5mQzu9wIaSSLI8vootbCuh5yuG6vFh18yB+4X4vTOcJdt7wmuOLAFWWVTm2L9c=; X-YMail-OSG: Wd6aSFEVM1mBxMqMYS9MpjyhV_r3Xk7CuAE_QmSLus21sIo gtESt4IWn5l6kHAEbjcPjobOdWiz6raEcWrL.GWhOLUoakhgFibuaAEK0BcK y8N4JQ2_Lhskfb85ZGYoYgQLN8I42166hdAQvVGlWDXXJnbA.J5G2P4qjTeQ mnIgWDSPFxTg4vlnxks574FGUzR0KLHOlqGuNjiu_9BRMW5H5zyoIMf4PYY9 GQbNEpBcfDRnfqLiJPX0xw0aXxCGSCG8B0gw_Tlyd8LCxxsuNImAVlQWKZaf HQyQq33m6EAJbKh1E6JwBB8dlcvxA14ndKyx4t95UuIZBsAdOPli1LoQCna8 Nw_f80ijBPRaBbdoyvAKE3IutmDhsbPPStI6aH4bmbfyxJu2HXBs1ynuTdX7 qYHrDMvwtVfbsr5sAKQWTKVMdtkPlh3ECZ2xNV.VrwsbEL31NOY7w6sdj_q9 B.aLdbPkeJtMRB8G5kHA584k1aSgxVypLugtz4vNk4Fp1T2Iy2kIq3uSx8e. 7pc1hSW4wCTh0Niegjb24E.lk.ORO9ANQqg6IBasIsKjztEk.Z5GyHUXiJfR d8SEtZQDfO9s- Received: from [199.126.193.41] by web39307.mail.mud.yahoo.com via HTTP; Mon, 27 Jun 2011 21:58:37 PDT X-Mailer: YahooMailWebService/0.8.112.307740 Message-ID: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> Date: Mon, 27 Jun 2011 21:58:37 -0700 (PDT) From: PseudoCylon To: "freebsd-wireless@freebsd.org" , "freebsd-current@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: [CFT] Sierra Wireless HSPA+ USB modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PseudoCylon List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 05:11:47 -0000 Hello=0A=0AHere is a driver for Sierra Wireless HSPA+ USB modem. Please tes= t it. My subscription will expire on June 29, 2011. (Yes, it sounds silly.)= So, try it before too late.=0A=0Asource tree=A0https://gitorious.org/usie/= usie/trees/master=0Atarball=A0https://gitorious.org/usie/usie/archive-tarba= ll/master=0A=0AThe driver should work on CURRENT and 8.2 RELEASE.=0ASupport= s only Direct IP supported models with device ID of 0x68a3=0A=0A(Direct IP = =3D=3D the device has a port we can=A0throw=A0IP packets at, no need to use= any serial port)=0AA list of=A0supported=A0device names are posted on Free= BSD forum.=0Ahttp://forums.freebsd.org/showthread.php?p=3D138758#post138758= =0A=0A=0A* How to use=0A0) add a following to=A0somewhere in /usr/src/sys/d= ev/usbdevs=0Aproduct AIRPRIME USB3080x68A3 =A0USB308 HSPA+ USB Modem=0A1) c= ompile=0A2) #kldload usie=0A3) plugin the device (Make sure load the module= first)=0A4)=A0wait while the modem is going though power up cycle=0A5) #dh= client usie0=0A6) surf=0A=0A* To disconnect=0A#ifconfig usie0 down=0Aor=0A#= kldunload usie=0A=0A=0AAK=0A From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 05:42:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91AE5106566B for ; Tue, 28 Jun 2011 05:42:18 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id 437C58FC16 for ; Tue, 28 Jun 2011 05:42:17 +0000 (UTC) X-AuditID: 1209190f-b7b0eae000000a42-01-4e0969bbc88d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F9.D3.02626.BB9690E4; Tue, 28 Jun 2011 01:42:19 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p5S5gGww024380; Tue, 28 Jun 2011 01:42:16 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5S5gF0f015438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2011 01:42:16 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p5S5gEiO009413; Tue, 28 Jun 2011 01:42:14 -0400 (EDT) Date: Tue, 28 Jun 2011 01:42:14 -0400 (EDT) From: Benjamin Kaduk To: Eric McCorkle In-Reply-To: Message-ID: References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> <4E08A8DB.2020805@shadowsun.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrrs7k9PPYOtNIYv/L3YxWcx584HJ gcljxqf5LB5XVn5iDmCK4rJJSc3JLEst0rdL4Mp4P3E5a8E2roqzx7rZGxjncHQxcnJICJhI dG+/zwphi0lcuLeerYuRi0NIYB+jxOGGD8wgCSGBDYwSN75IQNgHmCTuzYuBKGpglFjxaiM7 SIJFQFviyOGVYDabgIrEzDcb2UBsEQE1iV9Nm1hAbGYBeYn/Vy4zgdjCAv4Ss761gsU5BRwl JpybCLaMV8BB4vSP30wQC+YzSuybcgWsQVRAR2L1/iksEEWCEidnPoEaailx7s91tgmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRFKqckvw7GL8dVDrE KMDBqMTDy7SSw0+INbGsuDL3EKMkB5OSKO/8DE4/Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8 U42AcrwpiZVVqUX5MClpDhYlcd5y7/++QgLpiSWp2ampBalFMFkZDg4lCd7FIEMFi1LTUyvS MnNKENJMHJwgw3mAhs8DqeEtLkjMLc5Mh8ifYlSUEuddAJIQAElklObB9cJSyStGcaBXhHkX glTxANMQXPcroMFMQIN1TDlABpckIqSkGhg9p4m0dGs3PTLhEum6E+wbUpGus//g7WDpM0wn HX8WnXpddIPnVQQfm2tVUWbT9a7ezU/3/tpyI6dujce72TPudEvv/aIz97K16oIpBlddz2jb amft99XZL/1i2l3r/5/1J7wRM1SamSbyRTmqbM6sB56mWUon0yLvah7uYTT4VaPI877QU02J pTgj0VCLuag4EQB7ltiFAAMAAA== Cc: freebsd-current@freebsd.org Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 28 Jun 2011 05:42:18 -0000 On Tue, 28 Jun 2011, Benjamin Kaduk wrote: > On Mon, 27 Jun 2011, Eric McCorkle wrote: > >> make.conf: >> CPUTYPE?=core2 >> .if !defined(CC) || ${CC} == "cc" >> CC=clang >> CFLAGS=-Qunused-arguments >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> NO_WERROR= >> WERROR= >> NO_FSCHG= >> PERL_VERSION=5.12.3 >> >> Just noticed, the CFLAGS would disable optimization, which would explain >> why no one else seems to see this. Still, I think the underlying issue >> warrants investigation. > > I seem to recall that our gcc-4.2 with -O0 is known to be buggy -- certainly > I just tripped over a panic in a third-party kernel module build using > bsd.kmod.mk with -O0 that was fixed by compiling the object in question with > -O. > It is not terribly easy to search for, but my archives find at least > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076028.html > > I would try with -O1 and confirm that your issues go away, and not spend time > on the core issue if it proves to be a gcc bug. > > Unfortunately, we are stuck with an old gcc in base ... though I have yet to > see if clang -O0 has issues with my module. Wow, I juxtaposed the two compilers due to working on too little sleep. Please disregard, and sorry for the noise. -Ben From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 06:52:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DBFF106566B for ; Tue, 28 Jun 2011 06:52:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 70CE48FC12 for ; Tue, 28 Jun 2011 06:52:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=3OyxrDLVq9sri6DuQhVzJBEiMCfYdL5zDZJFh5fE9Ak= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=8GCaWQNJa_IA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=lRxpQPx1AAAA:8 a=6I5d2MoRAAAA:8 a=WtEsqzCQpRS1c7UvwfQA:9 a=ljWClKXTy1Oq55aLIlcA:7 a=wPNLvfGTeEIA:10 a=tlJW8gxtbz4A:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 145914512; Tue, 28 Jun 2011 08:52:39 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, PseudoCylon Date: Tue, 28 Jun 2011 08:50:57 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> In-Reply-To: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106280850.57645.hselasky@c2i.net> Cc: "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem 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, 28 Jun 2011 06:52:44 -0000 On Tuesday 28 June 2011 06:58:37 PseudoCylon wrote: > Hello > > Here is a driver for Sierra Wireless HSPA+ USB modem. Please test it. My > subscription will expire on June 29, 2011. (Yes, it sounds silly.) So, try > it before too late. > > source tree https://gitorious.org/usie/usie/trees/master > tarball https://gitorious.org/usie/usie/archive-tarball/master > > The driver should work on CURRENT and 8.2 RELEASE. > Supports only Direct IP supported models with device ID of 0x68a3 > > (Direct IP == the device has a port we can throw IP packets at, no need to > use any serial port) A list of supported device names are posted on > FreeBSD forum. > http://forums.freebsd.org/showthread.php?p=138758#post138758 > > > * How to use > 0) add a following to somewhere in /usr/src/sys/dev/usbdevs > product AIRPRIME USB3080x68A3 USB308 HSPA+ USB Modem > 1) compile > 2) #kldload usie > 3) plugin the device (Make sure load the module first) > 4) wait while the modem is going though power up cycle > 5) #dhclient usie0 > 6) surf > > * To disconnect > #ifconfig usie0 down > or > #kldunload usie > Hi, I'm going to review and import your driver. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 09:10:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8185F1065672; Tue, 28 Jun 2011 09:10:06 +0000 (UTC) (envelope-from gber@freebsd.org) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6588FC0C; Tue, 28 Jun 2011 09:10:05 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 648E5C869B; Tue, 28 Jun 2011 10:51:52 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id cj0beVGmf8mp; Tue, 28 Jun 2011 10:51:51 +0200 (CEST) Received: from gjb-host.home (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id C96B0C8580; Tue, 28 Jun 2011 10:51:51 +0200 (CEST) Message-ID: <4E0996AB.9000802@freebsd.org> Date: Tue, 28 Jun 2011 10:54:03 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100630 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rmacklem@FreeBSD.org Subject: NFS/BOOTP problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 09:10:06 -0000 Hi, After rebasing to new -current I experienced problem with mounting root via NFS. I was getting error: "Mounting from nfs: failed with error 2: unknown file system.". I use BOOTP and NFSv3 (option NFSCLIENT). It seems that bootp set fs type to 'nfs' and recently NFSv3 was renamed to 'oldnfs'. Patch below fixes the problem. Do you think it is proper solution? Could it be fixed some other better way? thanks, grzesiek diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c index 49dbc34..a47092d 100644 --- a/sys/nfs/bootp_subr.c +++ b/sys/nfs/bootp_subr.c @@ -44,6 +44,7 @@ __FBSDID("$FreeBSD: src/sys/nfs/bootp_subr.c,v 1.31 2011/04/25 22:22:51 rmackle #include "opt_bootp.h" +#include "opt_nfs.h" #include #include @@ -1699,6 +1700,9 @@ bootpc_init(void) } rootdevnames[0] = "nfs:"; +#ifdef NFSCLIENT + rootdevnames[1] = "oldnfs:"; +#endif mountopts(&nd->root_args, NULL); for (ifctx = gctx->interfaces; ifctx != NULL; ifctx = ifctx->next) From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 09:38:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E013F106566B; Tue, 28 Jun 2011 09:38:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 44B2F8FC0C; Tue, 28 Jun 2011 09:38:03 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p5S9c0sB009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2011 12:38:00 +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.4/8.14.4) with ESMTP id p5S9bx5T034339; Tue, 28 Jun 2011 12:37:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p5S9bxSh034338; Tue, 28 Jun 2011 12:37:59 +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, 28 Jun 2011 12:37:59 +0300 From: Kostik Belousov To: obrien@freebsd.org, freebsd-current@freebsd.org Message-ID: <20110628093759.GH48734@deviant.kiev.zoral.com.ua> References: <20110623163109.GA508@dragon.NUXI.org> <20110623202153.GS48734@deviant.kiev.zoral.com.ua> <20110627174207.GA99971@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tCg73T+C/jTUGm03" Content-Disposition: inline In-Reply-To: <20110627174207.GA99971@dragon.NUXI.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 28 Jun 2011 09:38:05 -0000 --tCg73T+C/jTUGm03 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 27, 2011 at 10:42:07AM -0700, David O'Brien wrote: > Hi KIB, > Thanks for the list of issues you know about -- I don't believe we have > PRs covering those. >=20 >=20 > On Thu, Jun 23, 2011 at 11:21:53PM +0300, Kostik Belousov wrote: > > - I believe Peter Holm has more test cases that fails with tmpfs. He > > would have more details. I somewhat remember some panic on execve(2) the > > binary located on tmpfs. >=20 > I've been following the patches you've been passing to Peter Holm as part > of this thread. Seems good progress has been made in fixing some of the > issues. >=20 >=20 > > Removing the warning will not make the issues coming away. >=20 > Quite true, but is there any other subsystem where we know we have bugs > and have put up such a scary warning? >=20 > I've never used ZFS on i386, but I understand it is trivial to panic > with out-of-the-box settings. We don't print a dire warning for ZFS > usage on 32-bit platforms. So I'm not sure we should keep it for TMPFS. >=20 > I cannot tell from your response if you're OK or against removing > the warning. [especially if your patches pass the Peter Holm test > and remove some of the bugs] If anything, the removal of the said warning would reduce the kernel text size. Probably, it should be moved to the man page, which already has similar, but not that strong, wording. --tCg73T+C/jTUGm03 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4JoPcACgkQC3+MBN1Mb4jZbgCfRPXd7uPMqlpSg/x/SgSG5evJ 6kYAoOomggMYCwSJiS1B8F2udPFk0el+ =Z1cq -----END PGP SIGNATURE----- --tCg73T+C/jTUGm03-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 09:44:30 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D330D106566C for ; Tue, 28 Jun 2011 09:44:30 +0000 (UTC) (envelope-from st_esser@t-online.de) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9908B8FC0C for ; Tue, 28 Jun 2011 09:44:30 +0000 (UTC) Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de ) by mailout03.t-online.de with smtp id 1QbUao-0002Gr-Mh; Tue, 28 Jun 2011 11:28:27 +0200 Received: from [192.168.119.20] (rSOVCyZCrhmXcCCQ6vfMfS-2j6QBjmtjsdPBC8noZbmrDaXNP-dlj6vz-1GTT-jZPG@[81.173.158.158]) by fwd24.t-online.de with esmtp id 1QbUag-2KQFZQ0; Tue, 28 Jun 2011 11:28:18 +0200 Message-ID: <4E099EB2.7050902@freebsd.org> Date: Tue, 28 Jun 2011 11:28:18 +0200 From: "Stefan Esser" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110620 Thunderbird/5.0b2 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ID: rSOVCyZCrhmXcCCQ6vfMfS-2j6QBjmtjsdPBC8noZbmrDaXNP-dlj6vz-1GTT-jZPG X-TOI-MSGID: 9647439a-9b4e-4f25-944e-3106411223fd X-Mailman-Approved-At: Tue, 28 Jun 2011 11:02:18 +0000 Cc: Subject: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 09:44:30 -0000 Hi, is this a known issue? My -CURRENT system (r223560M, amd64, 8GB, Atheros WLAN) panics after minutes to hours of uptime with the following message: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 0 fault virtual address = 0xffffff807f502000 fault code = supervisor data read, page not present ... processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock) [ thread pid 11 tid 1000012 ] Stopped at ieee80211_tx_mgmt_timeout+0x1: movq (%rdi),%rdi db> bt Tracing pid 11 tid 100012 td 0xfffffe00032e0000 ieee80211_tx_mgmt_timeout() at ieee80211_tx_mgmt_timeout+0x1 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0x96 fork_exit() at fork_exit+0x11d fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000288d00, rbp = 0 --- This panic message is manually transcribed, since the GPT-only partitioning prevents dumping of a kernel core. (Why, BTW?) I could add a swap partition on a MBR disk, if a core dump seems neccessary to diagnose the problem. I'm also willing to wait for that panic to occur again and to gather more debug output. Other information: The Atheros WLAN in this system is unused (not associated) but both ath0 and wlan0 were "UP" at the time of the panic. Initial testing shows the system to be stable with both wlan0 and ath0 set to "down" after boot. But still, the timeout should not panic the kernel, if WLAN is active but not fully configured (e.g. no SSID). Any ideas? Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 13:38:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A6F91065675; Tue, 28 Jun 2011 13:38:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 962EC8FC14; Tue, 28 Jun 2011 13:38:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EACHZCU6DaFvO/2dsb2JhbABShEmjb7h7kTKBK4N5gQwEkhCQPQ X-IronPort-AV: E=Sophos;i="4.65,437,1304308800"; d="scan'208";a="129237045" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 28 Jun 2011 09:38:00 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 26AB1B3F20; Tue, 28 Jun 2011 09:38:00 -0400 (EDT) Date: Tue, 28 Jun 2011 09:38:00 -0400 (EDT) From: Rick Macklem To: Grzegorz Bernacki Message-ID: <40143899.5952.1309268280142.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4E0996AB.9000802@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: rmacklem@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: NFS/BOOTP problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:38:11 -0000 Grzegorz Bernacki wrote: > Hi, > > After rebasing to new -current I experienced problem with mounting > root > via NFS. I was getting error: "Mounting from nfs: failed with error 2: > unknown file system.". I use BOOTP and NFSv3 (option NFSCLIENT). It > seems that bootp set fs type to 'nfs' and recently NFSv3 was renamed > to > 'oldnfs'. Patch below fixes the problem. Do you think it is proper > solution? Could it be fixed some other better way? > If you wish to use the old NFS client as the root fs, you can add a line like: vfs.root.mountfrom="oldnfs:" in the boot/loader.conf file on the root fs in the NFS server to have the same effect as your patch. (This is mentioned in the message in UPDATING.) However, it would be nice if you used the new NFS client instead, by building the kernel with "option NFSCL" so that it uses the new NFS client. (The new NFS client does NFSv3 in what I believe to be a completely compatible way as the old one.) If you tried the new NFS client and it didn't work for you, I would like to hear what the problem was, so it can be resolved. (The intent was to leave the old NFS client in the system so that it could be used as a fallback when the new one didn't work correctly for some situation.) If others feel that having a system that will boot via the old NFS client without needing to add the line to loader.conf is important, then doing your patch would be appropriate. I didn't do what your patch does, since I was hoping folks would use the new client instead and only force use of the old one when it was really necessary. rick [patch snipped for brevity] From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 15:09:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1094C1065670 for ; Tue, 28 Jun 2011 15:09:30 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C41D48FC14 for ; Tue, 28 Jun 2011 15:09:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1QbZuq-0008BF-FH>; Tue, 28 Jun 2011 17:09:28 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1QbZuq-0000x0-D9>; Tue, 28 Jun 2011 17:09:28 +0200 Message-ID: <4E09EEA8.9020006@zedat.fu-berlin.de> Date: Tue, 28 Jun 2011 17:09:28 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110627 Thunderbird/3.1.11 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Subject: CAM/SATA: attach/detach problems with harddrive 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, 28 Jun 2011 15:09:30 -0000 Hello. Several maintenance of a ZFS pools has to be done and my intention was to swap the 2TB hd disk (WDC WD20EARS-00MVWB0) with a 3TB hd disk (WD30EZRX). zfs umount works well, zpool export POOL also worked well, but I didn't find any "detach command" within camcontrol (I use the new AHACI/CAM layout in the kernel on FreeBSD 9.0-CURRENT/amd64 r223597, so my harddrives all show up as ada0 to ada4. Since the box has a IcyDock 5-Slot backplane attached to the ICH0R chipset and camcontrol doesn't reveal any detach command like atacontrol did, I trusted in hotplugging capabilities and simply pulled the disk. All right, the box reported a lost device but did not crash. The I inserted the new drive. Entered camcontrol rescan all and camcontrol devlist showed up the new device. But I can't do anything with the drive. Even with the former device inserted again, rescaned etc., a zpool import command get stuck as well as any diskinfo -ctv ada4 issued to the device. The drive shows up in camcontrol devlist, but seems inoperable. What I'm doing wrong? Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 15:58:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8420C106566B for ; Tue, 28 Jun 2011 15:58:05 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1A39E8FC08 for ; Tue, 28 Jun 2011 15:58:04 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p5SFw3hU026701; Tue, 28 Jun 2011 17:58:03 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5SFw399026700; Tue, 28 Jun 2011 17:58:03 +0200 (CEST) (envelope-from marius) Date: Tue, 28 Jun 2011 17:58:03 +0200 From: Marius Strobl To: KOT MATPOCKuH Message-ID: <20110628155802.GA26562@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c o? sparc64/SMP 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, 28 Jun 2011 15:58:05 -0000 On Mon, Jun 27, 2011 at 07:19:33PM +0400, KOT MATPOCKuH wrote: > Hello! > > I'm got a problem with named on FreeBSD-CURRENT/sparc64. > Up to 5 times a day it crashes with these messages: > 27-Jun-2011 03:42:14.384 general: > /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: > REQUIRE(prev > 0) failed > 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) > > The problem is still in latest system's bind: > # named -v > BIND 9.6.-ESV-R4-P1 > > This problem exists only on SMP sparc64 system. On my another sparc64, > with 1 processor, I does not have this problem. > > I found a some similar problems on alpha and IA64, which was related > to problems with isc_atomic_xadd() function in include/isc/atomic.h. > But I don't understand that there may be incorrect for sparc64 and > this function was not changed for a minimum 4 years... > > How can I help solve this problem? > Uhm, we once fixed a problem in the MD atomic implementation which still seems to present in the ISC copy. Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff Marius From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 16:01:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F390C1065673 for ; Tue, 28 Jun 2011 16:01:56 +0000 (UTC) (envelope-from cyko@cykotix.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C2A218FC17 for ; Tue, 28 Jun 2011 16:01:56 +0000 (UTC) Received: by iyb11 with SMTP id 11so384081iyb.13 for ; Tue, 28 Jun 2011 09:01:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.24.155 with SMTP id v27mr6535619ibb.57.1309275266449; Tue, 28 Jun 2011 08:34:26 -0700 (PDT) Sender: cyko@cykotix.com Received: by 10.231.30.73 with HTTP; Tue, 28 Jun 2011 08:34:26 -0700 (PDT) X-Originating-IP: [205.142.197.72] Date: Tue, 28 Jun 2011 11:34:26 -0400 X-Google-Sender-Auth: I0BoVKoQZ3QmfX1teDqFzQnkvXo Message-ID: From: Patrick Lahni To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hang at Timecounters tick every 1.000 msec 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, 28 Jun 2011 16:01:57 -0000 Hello, I have tried installed FreeBSD-CURRENT on my machine but it hangs on boot. It gets as far as "Timecounters tick every 1.000 msec" and stops responding and I have to perform a hard reset. I was originally running 8.2-STABLE without any issues and decided to upgrade. That said, I can boot using my 8.2 kernel (of course it doesn't like this) and at least get to a shell prompt. Switch back to GENERIC -CURRENT amd64 and it hangs in the same spot every time. http://jetway.com.tw/jw/ipcboard_view.asp?productid=832&proname=NF99FL-525 This is the board I'm currently using. To make things even more interesting, I dropped the SATA drive into an HP Elitebook 8440p just for grins to see if it would boot and it does without any issues using the -CURRENT GENERIC amd64 kernel. Latest sources were checked out this morning. Any ideas on what I can do to at least get this to boot properly off the jetway board? I apologize for the lack of initial information but since I can't get it to finish booting, copying and pasting any sort of output from the machine is impossible at this point. Thanks, Patrick From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 17:20:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580F0106566C for ; Tue, 28 Jun 2011 17:20:48 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E2EA48FC08 for ; Tue, 28 Jun 2011 17:20:47 +0000 (UTC) Received: by eyg7 with SMTP id 7so218704eyg.13 for ; Tue, 28 Jun 2011 10:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IsworZxUAMF+v1fPmZzDydZEFzz3W6zweGuwQjYcfFc=; b=xhsXibhUsA6ZtZyS0bOCITPGzF+S6qcCt8U957sUJO464tunfcglqmqDF0Y0qQhxAR vnGjd32NC3ws9ywoQ6CfAuagXyekMk7f21CHCQOLycwb0JZZjR3/ZT/DMPmij8FMZOku 1LQqsRNgtnCxncQ56pGHEv7hGatEc56bwO+ec= MIME-Version: 1.0 Received: by 10.213.19.78 with SMTP id z14mr98789eba.10.1309279832546; Tue, 28 Jun 2011 09:50:32 -0700 (PDT) Received: by 10.213.11.20 with HTTP; Tue, 28 Jun 2011 09:50:32 -0700 (PDT) In-Reply-To: <4E099EB2.7050902@freebsd.org> References: <4E099EB2.7050902@freebsd.org> Date: Tue, 28 Jun 2011 11:50:32 -0500 Message-ID: From: Scot Hetzel To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:20:48 -0000 On Tue, Jun 28, 2011 at 4:28 AM, Stefan Esser wrote: > This panic message is manually transcribed, since the GPT-only > partitioning prevents dumping of a kernel core. (Why, BTW?) You should be able to get a kernel core dump on a system with a GPT partitioned disk. Do you have a freebsd-swap partition? How is your GPT disk partitioned? Scot From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 18:34:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB8D41065674 for ; Tue, 28 Jun 2011 18:34:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1FD8FC19 for ; Tue, 28 Jun 2011 18:34:04 +0000 (UTC) Received: by fxe6 with SMTP id 6so428430fxe.17 for ; Tue, 28 Jun 2011 11:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HyxvCPLhN7MGVYg0t1HYwWF5nPmH3yeHTnYajeBSCvg=; b=Ei6lsoRa5kCJ8AXO4m99/iPbJTslJGJwUYuXhOTpajpQKwpYZcYxRsg0FhEJnkosZf /Cc8MiT9UfTiY28THwuMaXIAhlW6keseJYJu22va//KB/8IvHiGM1WlxNv4Mpq1YugHm eG6T3UZxD5Svr5d9vu5vyzlaKlZAZiZmJAjp0= Received: by 10.223.91.129 with SMTP id n1mr11075402fam.113.1309286044073; Tue, 28 Jun 2011 11:34:04 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id m5sm305282fai.1.2011.06.28.11.34.02 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 11:34:03 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E0A1E91.3030909@FreeBSD.org> Date: Tue, 28 Jun 2011 21:33:53 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110616 Thunderbird/3.1.10 MIME-Version: 1.0 To: "O. Hartmann" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: CAM/SATA: attach/detach problems with harddrive 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, 28 Jun 2011 18:34:05 -0000 On 28.06.2011 18:09, O. Hartmann wrote: > Several maintenance of a ZFS pools has to be done and my intention was > to swap the 2TB hd disk (WDC WD20EARS-00MVWB0) with a 3TB hd disk > (WD30EZRX). > > zfs umount works well, > zpool export POOL also worked well, > > but I didn't find any "detach command" within camcontrol (I use the new > AHACI/CAM layout in the kernel on FreeBSD 9.0-CURRENT/amd64 r223597, so > my harddrives all show up as ada0 to ada4. > Since the box has a IcyDock 5-Slot backplane attached to the ICH0R > chipset and camcontrol doesn't reveal any detach command like atacontrol > did, I trusted in hotplugging capabilities and simply pulled the disk. > All right, the box reported a lost device but did not crash. The I > inserted the new drive. Entered > > camcontrol rescan all > > and > > camcontrol devlist showed up the new device. But I can't do anything > with the drive. Even with the former device inserted again, rescaned > etc., a zpool import command get stuck as well as any diskinfo -ctv ada4 > issued to the device. The drive shows up in camcontrol devlist, but > seems inoperable. What I'm doing wrong? With controller in AHCI mode device plug-in should be detected without any additional activity. If not, `camcontrol reset X`, `camcontrol rescan X` sequence should force it, where X is a CAM scbus number. Without additional info I can't say what went wrong there. I would recommend to enable verbose kernel messages to get more info. Also consider that SATA default timeout is 30 seconds, so if due to some issues during plug-in some command was lost, recovery may take a bit. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 19:17:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 417C4106566B for ; Tue, 28 Jun 2011 19:17:35 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id E95FC8FC15 for ; Tue, 28 Jun 2011 19:17:34 +0000 (UTC) Received: (qmail 18551 invoked from network); 28 Jun 2011 15:10:53 -0400 Received: from yktgi01e0-s5.watson.ibm.com (HELO atom-edge.watson.ibm.com) (129.34.20.19) by mail.atlantawebhost.com with SMTP; 28 Jun 2011 15:10:53 -0400 Message-ID: <4E0A273C.2010303@shadowsun.net> Date: Tue, 28 Jun 2011 15:10:52 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> <4E08A8DB.2020805@shadowsun.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 28 Jun 2011 19:17:35 -0000 On 6/28/11 1:42 AM, Benjamin Kaduk wrote: > On Tue, 28 Jun 2011, Benjamin Kaduk wrote: > >> On Mon, 27 Jun 2011, Eric McCorkle wrote: >> >>> make.conf: >>> CPUTYPE?=core2 >>> .if !defined(CC) || ${CC} == "cc" >>> CC=clang >>> CFLAGS=-Qunused-arguments >>> .endif >>> .if !defined(CXX) || ${CXX} == "c++" >>> CXX=clang++ >>> .endif >>> NO_WERROR= >>> WERROR= >>> NO_FSCHG= >>> PERL_VERSION=5.12.3 >>> >>> Just noticed, the CFLAGS would disable optimization, which would >>> explain why no one else seems to see this. Still, I think the >>> underlying issue warrants investigation. >> >> I seem to recall that our gcc-4.2 with -O0 is known to be buggy -- >> certainly I just tripped over a panic in a third-party kernel module >> build using bsd.kmod.mk with -O0 that was fixed by compiling the >> object in question with -O. >> It is not terribly easy to search for, but my archives find at least >> http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076028.html >> >> >> I would try with -O1 and confirm that your issues go away, and not >> spend time on the core issue if it proves to be a gcc bug. >> >> Unfortunately, we are stuck with an old gcc in base ... though I have >> yet to see if clang -O0 has issues with my module. > > Wow, I juxtaposed the two compilers due to working on too little sleep. > Please disregard, and sorry for the noise. > Getting rid of the CFLAGS in my make.conf got rid of the multiple definitions (I still think the underlying issue merits investigation and resolution) for both compilers. From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 19:20:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0D71065670; Tue, 28 Jun 2011 19:20:02 +0000 (UTC) (envelope-from inyaoo@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05DE18FC16; Tue, 28 Jun 2011 19:20:01 +0000 (UTC) Received: by pzk27 with SMTP id 27so477449pzk.13 for ; Tue, 28 Jun 2011 12:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=vlOP6ue5fcpld+fkTAfchDy6JkpUarKeSvAu54IeONg=; b=tIylt2DzcWP80vJztTl9L7kkNDIKJ1L6nZfwLCMbdiaY1LdsDL4LYEJ+xbdmYD3AaS je4MM/GAa7COuGy/fFPPjmYRXlWymuQWYfyw1SPHQq0/g8QvzQMng9ABIqhD5H6ZfxfY /DWtK9mfimsVFmtNvMsPYqgnFidVnKlIzwN/0= Received: by 10.142.150.27 with SMTP id x27mr1688367wfd.72.1309288801459; Tue, 28 Jun 2011 12:20:01 -0700 (PDT) Received: from localhost (tor-exit-router42-readme.formlessnetworking.net [199.48.147.42]) by mx.google.com with ESMTPS id w24sm287993wfd.17.2011.06.28.12.19.57 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 12:19:59 -0700 (PDT) From: Pan Tsu To: Niclas Zeising References: <4E0679AA.20100@shadowsun.net> <4E06863F.7010104@FreeBSD.org> <4E0A2172.7000800@daemonic.se> Date: Tue, 28 Jun 2011 23:19:41 +0400 In-Reply-To: <4E0A2172.7000800@daemonic.se> (Niclas Zeising's message of "Tue, 28 Jun 2011 20:46:10 +0200") Message-ID: <86k4c5epbm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Gabor PALI , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: -Qunused-parameter and clang (was Re: GHC Port on 9-CURRENT) 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, 28 Jun 2011 19:20:02 -0000 Niclas Zeising writes: > Sorry for hijacking this thread, and cross posting. > > On 2011-06-26 03:07, Gabor PALI wrote: >> >> >>> With Clang, an error occurs in one of the configure scripts, because >>> Clang warns about unused command-line arguments, and the configure >>> script assumes that to be a compiler error. You can deal with this by >>> adding -Qunused-parameter to CFLAGS. >> >> Thanks for investigating this. >> > > This should probably be made the default, at least for ports when clang > is compiled, since the output generated when not using > -Qunused-parameter confuses configure scripts, and stops at least > FireFox 5 from compiling, that I know of. Do you use ccache? Try without. For example, the combo confuses libtool http://docs.freebsd.org/cgi/mid.cgi?86d3i8b3dc.fsf From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 19:37:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2280D1065672 for ; Tue, 28 Jun 2011 19:37:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D12498FC17 for ; Tue, 28 Jun 2011 19:37:39 +0000 (UTC) Received: by vxg33 with SMTP id 33so573949vxg.13 for ; Tue, 28 Jun 2011 12:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w9qUD4KI6YVJY5puGuA3c0FYKEvsVbcsEQcuaReFORY=; b=b59OYxOqvy9j/j8/EO7KLaebxVhcitSoH6fRW9PJYMBHTpfmSpxRAZ5EUJDDPNQgdr Xw3ZhlWVW59T4dFut0Cz9FnzjtgJMtIBkycUxGxkveANWdyPxCKiM+ZiBYMi5dSB0fz5 4Lk38zusHVRuTQd35k7B6szU8cEZnOgu8WTUw= MIME-Version: 1.0 Received: by 10.220.7.79 with SMTP id c15mr1977296vcc.3.1309289858809; Tue, 28 Jun 2011 12:37:38 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Tue, 28 Jun 2011 12:37:38 -0700 (PDT) In-Reply-To: <4E08A8DB.2020805@shadowsun.net> References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> <4E08A8DB.2020805@shadowsun.net> Date: Tue, 28 Jun 2011 12:37:38 -0700 Message-ID: From: Garrett Cooper To: Eric McCorkle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 28 Jun 2011 19:37:40 -0000 On Mon, Jun 27, 2011 at 8:59 AM, Eric McCorkle wrote: > On 6/27/11 8:29 AM, Dimitry Andric wrote: >> >> On 2011-06-27 04:32, Eric McCorkle wrote: >>> >>> I've both seen reports and experienced make buildworld with clang >>> failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what >>> fails), because lint1 is statically linked, and there is a definition o= f >>> __isnanf in both libc and libm. GCC, on the other hand, builds just fin= e. >> >> ... >> >> I have never seen this failure, and neither does the clang buildbot, so >> maybe there is something in your build environment causing this problem? >> Can you please post: >> >> - Your build architecture (e.g. i386 or amd64) >> - Your /etc/make.conf and /etc/src.conf, if applicable >> - Any build-related environment variables (WITH_FOO, WITHOUT_FOO, >> CFLAGS, etc) >> > > Sorry. =A0It's an amd64 system, 9-CURRENT, last updated on friday. > > src.conf: > LOADER_ZFS_SUPPORT=3D"YES" > > make.conf: > CPUTYPE?=3Dcore2 > .if !defined(CC) || ${CC} =3D=3D "cc" > CC=3Dclang > CFLAGS=3D-Qunused-arguments > .endif > .if !defined(CXX) || ${CXX} =3D=3D "c++" > CXX=3Dclang++ > .endif > NO_WERROR=3D > WERROR=3D > NO_FSCHG=3D > PERL_VERSION=3D5.12.3 > > Just noticed, the CFLAGS would disable optimization, which would explain = why > no one else seems to see this. =A0Still, I think the underlying issue war= rants > investigation. Two things are wrong here: 1. You should use CC?=3D, CXX?=3D, etc in order to properly crossbuild (as Warner pointed out to me in another thread). 2. You should use CFLAGS+=3D, CXXFLAGS+=3D, otherwise you're going to obliterate any predefined CFLAGS, CXXFLAGS, etc. My guess is that if you use +=3D instead, things will actually work. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 19:49:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C522106564A for ; Tue, 28 Jun 2011 19:49:48 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C08F98FC08 for ; Tue, 28 Jun 2011 19:49:47 +0000 (UTC) Received: by vxg33 with SMTP id 33so584501vxg.13 for ; Tue, 28 Jun 2011 12:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IWZaNieM9Es5oLBD+CrlewpUpapSVWQS2rz04383bdc=; b=paOjokwE5/T5LPZ4GI8PshvXxGpbxulfsh7+NUDM2wZKxu0KTabUOTzMsXVzfd9WZn yGLVeKhDJXKI4VvccQxgRikAB9E8NAlLue6AmW1tdcu48HzNZ3BMkuvCRVYnIt6WB0m7 E4l+gcJpfZ5WS3uDQvHa+CQGwtRC7nakl+o1Y= MIME-Version: 1.0 Received: by 10.52.109.66 with SMTP id hq2mr8923260vdb.146.1309290587063; Tue, 28 Jun 2011 12:49:47 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Tue, 28 Jun 2011 12:49:47 -0700 (PDT) In-Reply-To: <86y60ld9gk.fsf@gmail.com> References: <4E07EBA2.70500@shadowsun.net> <4E08778D.2050302@FreeBSD.org> <4E08A8DB.2020805@shadowsun.net> <86y60ld9gk.fsf@gmail.com> Date: Tue, 28 Jun 2011 12:49:47 -0700 Message-ID: From: Garrett Cooper To: Pan Tsu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 28 Jun 2011 19:49:48 -0000 On Tue, Jun 28, 2011 at 12:47 PM, Pan Tsu wrote: > Garrett Cooper writes: > > [...] >>> Just noticed, the CFLAGS would disable optimization, which would explai= n why >>> no one else seems to see this. =A0Still, I think the underlying issue w= arrants >>> investigation. >> >> Two things are wrong here: >> 1. You should use CC?=3D, CXX?=3D, etc in order to properly crossbuild (= as >> Warner pointed out to me in another thread). > > Huh? sys.mk already defines ${CC} and *before* make.conf. > > =A0$ echo 'CC ?=3D clang' >foo.mk > =A0$ __MAKE_CONF=3Dfoo.mk make -dv /dev/null |& fgrep :CC > =A0Global:CC =3D cc I was probably misremembering CPUTYPE?=3D. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 20:06:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965C4106564A; Tue, 28 Jun 2011 20:06:23 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 216498FC22; Tue, 28 Jun 2011 20:06:23 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4CDF240003; Tue, 28 Jun 2011 22:06:22 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 41FB140021; Tue, 28 Jun 2011 22:06:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,FREEMAIL_FROM autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id EE9A740003; Tue, 28 Jun 2011 22:06:20 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id AD79B119C08; Tue, 28 Jun 2011 22:06:20 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 8461912B1E5; Tue, 28 Jun 2011 22:06:20 +0200 (CEST) Message-ID: <4E0A343C.6000008@gmail.com> Date: Tue, 28 Jun 2011 22:06:20 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Pan Tsu References: <4E0679AA.20100@shadowsun.net> <4E06863F.7010104@FreeBSD.org> <4E0A2172.7000800@daemonic.se> <86k4c5epbm.fsf@gmail.com> In-Reply-To: <86k4c5epbm.fsf@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Gabor PALI , freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: -Qunused-parameter and clang (was Re: GHC Port on 9-CURRENT) 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, 28 Jun 2011 20:06:23 -0000 On 2011-06-28 21:19, Pan Tsu wrote: > Niclas Zeising writes: > >> Sorry for hijacking this thread, and cross posting. >> >> On 2011-06-26 03:07, Gabor PALI wrote: >>> >>> >>>> With Clang, an error occurs in one of the configure scripts, because >>>> Clang warns about unused command-line arguments, and the configure >>>> script assumes that to be a compiler error. You can deal with this by >>>> adding -Qunused-parameter to CFLAGS. >>> >>> Thanks for investigating this. >>> >> >> This should probably be made the default, at least for ports when clang >> is compiled, since the output generated when not using >> -Qunused-parameter confuses configure scripts, and stops at least >> FireFox 5 from compiling, that I know of. > > Do you use ccache? Try without. > > For example, the combo confuses libtool > It has nothing to do with cccache. The issue is that clang by default warns when passed flags (-std= -f -W etc.) that's not used during the compilation/linking. This can be silenced with -Qunused-arguments, and if not, it confuses configure scripts that believe this is an error in the code it uses to test for features. Regards! -- Niclas Zeising From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 20:21:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAA03106566B for ; Tue, 28 Jun 2011 20:21:06 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 123F58FC17 for ; Tue, 28 Jun 2011 20:21:05 +0000 (UTC) Received: (qmail 30513 invoked from network); 28 Jun 2011 16:21:05 -0400 Received: from yktgi01e0-s5.watson.ibm.com (HELO atom-edge.watson.ibm.com) (129.34.20.19) by mail.atlantawebhost.com with SMTP; 28 Jun 2011 16:21:05 -0400 Message-ID: <4E0A37B0.5030101@shadowsun.net> Date: Tue, 28 Jun 2011 16:21:04 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E0679AA.20100@shadowsun.net> <4E06863F.7010104@FreeBSD.org> In-Reply-To: <4E06863F.7010104@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------010907080205050908040800" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GHC Port on 9-CURRENT 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, 28 Jun 2011 20:21:06 -0000 This is a multi-part message in MIME format. --------------010907080205050908040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/25/11 9:07 PM, Gabor PALI wrote: > I would be happy to see the logs. Attached. Sorry it took so long. --------------010907080205050908040800-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 21:20:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6A1106564A for ; Tue, 28 Jun 2011 21:20:59 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm23-vm4.bullet.mail.ne1.yahoo.com (nm23-vm4.bullet.mail.ne1.yahoo.com [98.138.91.183]) by mx1.freebsd.org (Postfix) with SMTP id 665938FC13 for ; Tue, 28 Jun 2011 21:20:59 +0000 (UTC) Received: from [98.138.90.48] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 21:20:58 -0000 Received: from [98.138.87.1] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 21:20:58 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 28 Jun 2011 21:20:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 917079.96800.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 87366 invoked by uid 60001); 28 Jun 2011 21:20:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1309296058; bh=s7rRlEEt/gQVpMn+ySJH0/GN0PQsU1fmSt2SDczn5F8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DDsAhN4uwMhsvf5i9+WQVshIFdJLzmgB4Ca8jG5GgEoxxNULovjU01fCdtqPU0F+/ncJNNG5CO1oWS4FmfJior3WgdB2j+SEPCGPS5xl4yuYKjGAkXTGbtdF9XAjrnLgx/M305oP+3jPwTwJF11TJxbSTCTb8HPqFIZeqIWVEMU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CJ0qGGu5DsRp9XUz4HxcI4+y6yKimiHYAq/sgVDmpnbUHp3sJ7TRCO+gFqIuJShw13VTo+jhkzowakc8RrMALiGCBdINxh2p1ggCiXQujMNwArrjibQJc/kp56uI5/FCapQKvpd0S8kcIUzmnL8j6IW0YiA5i5nju8QtZVEzvSE=; X-YMail-OSG: 9ykSjI0VM1n_8VYD8LqHYevQBD_HBEA.Pr3TmI_jsxZutjj 4xKejmD4MAjgXcG9Du_YDxyHcM_BSIQVOSwz3zWQOLMdm3TqS65tvjWAvRPh HIxY2LcnTTNA2XogLM8_vK_geME7dq4p5tVV5K2d.c9mFj9Zito.E0dfJfLB YmS3SbUV.1wHHxPfURQFR0ISQ_RCq5QjC6f45SKIkx4Sd3yRQ5DTXoygyLcQ USlYsciJXq9dBYQoFqTuH6Q1LsUoFPCwC2L3XGtZ5iaDKUfzZdVxxBnVU4dd mcpyql1xJpFYWD9y2DiFOwcGe3mPIErQu_tO3b3GJZPkZL54E8Wf0E1HjeRA ns5sEGSCoJnoeRfciAjvYfLzGUnJK2BhalxqoqOu8T5vM5UE8GmzJqB1uVqM z1VwewDrGikoZASStDevCj.asRUV8ZTu6W4MhY5vXkT7yinbsgBwprAqh7fc XJS1WdlJj7Vqm06T8H1KYHLcXtd0uv.ocE_csBX0UlMxT Received: from [199.126.193.41] by web39301.mail.mud.yahoo.com via HTTP; Tue, 28 Jun 2011 14:20:58 PDT X-Mailer: YahooMailWebService/0.8.112.307740 References: <1309237117.88943.YahooMailNeo@web39307.mail.mud.yahoo.com> <201106280850.57645.hselasky@c2i.net> Message-ID: <1309296058.81875.YahooMailNeo@web39301.mail.mud.yahoo.com> Date: Tue, 28 Jun 2011 14:20:58 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky , "freebsd-current@freebsd.org" In-Reply-To: <201106280850.57645.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" Subject: Re: [CFT] Sierra Wireless HSPA+ USB modem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PseudoCylon List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:20:59 -0000 ----- Original Message -----=0A=0A> From: Hans Petter Selasky =0A> To: freebsd-current@freebsd.org; PseudoCylon =0A> Cc: "freebsd-wireless@freebsd.org" = =0A> Sent: Tuesday, June 28, 2011 12:50:57 AM=0A> Subject: Re: [CFT] Sierra= Wireless HSPA+ USB modem=0A> =0A> On Tuesday 28 June 2011 06:58:37 PseudoC= ylon wrote:=0A>> Hello=0A>> =0A>> Here is a driver for Sierra Wireless HS= PA+ USB modem. Please test it. My=0A>> subscription will expire on June 29= , 2011. (Yes, it sounds silly.) So, try=0A>> it before too late.=0A>> =0A>= > source tree https://gitorious.org/usie/usie/trees/master=0A>> tarball h= ttps://gitorious.org/usie/usie/archive-tarball/master=0A>> =0A>> The drive= r should work on CURRENT and 8.2 RELEASE.=0A>> Supports only Direct IP sup= ported models with device ID of 0x68a3=0A>> =0A>> (Direct IP =3D=3D the de= vice has a port we can throw IP packets at, no need to=0A>> use any serial= port) A list of supported device names are posted on=0A>> FreeBSD forum.= =0A>> http://forums.freebsd.org/showthread.php?p=3D138758#post138758=0A>> = =0A>> =0A>> * How to use=0A>> 0) add a following to somewhere in /usr/src= /sys/dev/usbdevs=0A>> product AIRPRIME USB3080x68A3=A0 USB308 HSPA+ USB Mo= dem=0A>> 1) compile=0A>> 2) #kldload usie=0A>> 3) plugin the device (Mak= e sure load the module first)=0A>> 4) wait while the modem is going though= power up cycle=0A>> 5) #dhclient usie0=0A>> 6) surf=0A>> =0A>> * To dis= connect=0A>> #ifconfig usie0 down=0A>> or=0A>> #kldunload usie=0A>> =0A>= =0A> Hi,=0A> =0A> I'm going to review and import your driver.=0A=0A=0A=0AT= hank you.=0A=0A=0ABTW,=0AU3G_DEV(SIERRA, MC8700, 0) in u3g.c=0A=0Aand=0AUSI= E_DEV(SIERRA,MC8700) in usie.c=0A=0Aare=A0referring=A0the same device, and= =A0MC8700=A0should support direct IP.=0A=0A=0AAK=0A From owner-freebsd-current@FreeBSD.ORG Tue Jun 28 22:32:42 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9F00106566C for ; Tue, 28 Jun 2011 22:32:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id BEB988FC13 for ; Tue, 28 Jun 2011 22:32:42 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6E3B5F8EE; Tue, 28 Jun 2011 15:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1309300362; bh=twwTuMSMo7i2slUusgzm0rTZeLk/ETpN8vHDnMy8blk=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type; b=hWjwwJMHeIOYsdRr25jbs9r1blwMwRqEzajzRO99piCe6qGLf7yX43ihTJd3poJsj Rwm86J9puWtKbweOI3dqgHhKN9y6/DnJ0vO4j/2MQ//YCZWgeOgErmlIu2lVUgFVP4 831fRxKo9m3BeDtCmJIZrtZEJbf/ftO0fUR+KW10= Message-ID: <4E0A5689.2020302@delphij.net> Date: Tue, 28 Jun 2011 15:32:41 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------030701090905090802000303" Cc: Subject: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/amd64 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: Tue, 28 Jun 2011 22:32:42 -0000 This is a multi-part message in MIME format. --------------030701090905090802000303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'd like to request for comments on the attached driver, which supports watchdogs on several Winbond super I/O chip models and have been tested on a few of recent Supermicro motherboards. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJOClaJAAoJEATO+BI/yjfBhUkH/16ECciGDOCh2TxvKbnUmE5M vNpZdhRjliEcMHh3YLGz9Zj/LOlZ97EjRYd2UBq5r5sf5cLhgUaKNoy7MblyHXy3 SPrkjY1IDlwLAVAeU9sJ5JjhPSh8xt/aDKnolXucutUqeZQlITQoesbJR2u7WEV7 Miyrm5/ypGObWhKz2v4dJGuHMl00uOrQpRaHurABkI8r+En9VlaJPHzcUEvpg4yq qomlAxpIA1ojCzor2CRDjvKS3N77hdy9Fh8rfhoLHZUalzWgNVOLsigLw26DuAcR bjBUgPKBFfVgeLuqJKQ3wHcGye48vujS4rlhdA4dtExhgoz0IkrmTpQcQysK71c= =LVyb -----END PGP SIGNATURE----- --------------030701090905090802000303 Content-Type: text/plain; name="0001-Driver-for-Winbond-watchdog.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Driver-for-Winbond-watchdog.patch" RnJvbSAzNDNiMmU3YjZlZDE5ZTRiNmNhMmJmNzZjMGNhNmI4NTQ0ZGQ0MzIwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBYaW4gTEkgPGRAZGVscGhpai5uZXQ+CkRhdGU6IE1v biwgMjcgSnVuIDIwMTEgMjE6NTQ6MTMgLTA3MDAKU3ViamVjdDogW1BBVENIXSBEcml2ZXIg Zm9yIFdpbmJvbmQgd2F0Y2hkb2cuCgotLS0KIHNoYXJlL21hbi9tYW40L01ha2VmaWxlICAg ICAgICB8ICAgIDMgKwogc2hhcmUvbWFuL21hbjQvd2luYm9uZHdkLjQgICAgIHwgICA4OCAr KysrKysrKysrCiBzeXMvYW1kNjQvY29uZi9OT1RFUyAgICAgICAgICAgfCAgICAyICsKIHN5 cy9jb25mL2ZpbGVzLmFtZDY0ICAgICAgICAgICB8ICAgIDEgKwogc3lzL2NvbmYvZmlsZXMu aTM4NiAgICAgICAgICAgIHwgICAgMSArCiBzeXMvZGV2L3dpbmJvbmR3ZC93aW5ib25kd2Qu YyAgfCAgMzY4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIHN5 cy9kZXYvd2luYm9uZHdkL3dpbmJvbmR3ZC5oICB8ICAgNDcgKysrKysKIHN5cy9pMzg2L2Nv bmYvTk9URVMgICAgICAgICAgICB8ICAgIDIgKwogc3lzL21vZHVsZXMvTWFrZWZpbGUgICAg ICAgICAgIHwgICAgMyArCiBzeXMvbW9kdWxlcy93aW5ib25kd2QvTWFrZWZpbGUgfCAgICA4 ICsKIDEwIGZpbGVzIGNoYW5nZWQsIDUyMyBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygt KQogY3JlYXRlIG1vZGUgMTAwNjQ0IHNoYXJlL21hbi9tYW40L3dpbmJvbmR3ZC40CiBjcmVh dGUgbW9kZSAxMDA2NDQgc3lzL2Rldi93aW5ib25kd2Qvd2luYm9uZHdkLmMKIGNyZWF0ZSBt b2RlIDEwMDY0NCBzeXMvZGV2L3dpbmJvbmR3ZC93aW5ib25kd2QuaAogY3JlYXRlIG1vZGUg MTAwNjQ0IHN5cy9tb2R1bGVzL3dpbmJvbmR3ZC9NYWtlZmlsZQoKZGlmZiAtLWdpdCBhL3No YXJlL21hbi9tYW40L01ha2VmaWxlIGIvc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUKaW5kZXgg N2NjY2NmYi4uNzc3ZTJmZCAxMDA2NDQKLS0tIGEvc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUK KysrIGIvc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUKQEAgLTQ0Nyw2ICs0NDcsNyBAQCBNQU49 CWFhYy40IFwKIAl0dW4uNCBcCiAJdHdhLjQgXAogCXR3ZS40IFwKKwl0d3MuNCBcCiAJdHgu NCBcCiAJdHhwLjQgXAogCXUzZy40IFwKQEAgLTUwMyw2ICs1MDQsNyBAQCBNQU49CWFhYy40 IFwKIAl3YXRjaGRvZy40IFwKIAl3Yi40IFwKIAl3aS40IFwKKwkke193aW5ib25kd2QuNH0g XAogCXdpdG5lc3MuNCBcCiAJd2xhbi40IFwKIAl3bGFuX2FjbC40IFwKQEAgLTcwNiw2ICs3 MDgsNyBAQCBfc3BlYWtlci40PQlzcGVha2VyLjQKIF9zcGtyLjQ9CXNwa3IuNAogX3RwbS40 PQkJdHBtLjQKIF91cnR3LjQ9CXVydHcuNAorX3dpbmJvbmR3ZC40PQl3aW5ib25kd2QuNAog X3dwaS40PQkJd3BpLjQKIF94ZW4uND0JCXhlbi40CiAKZGlmZiAtLWdpdCBhL3NoYXJlL21h bi9tYW40L3dpbmJvbmR3ZC40IGIvc2hhcmUvbWFuL21hbjQvd2luYm9uZHdkLjQKbmV3IGZp bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNmZkMjcxOQotLS0gL2Rldi9udWxsCisr KyBiL3NoYXJlL21hbi9tYW40L3dpbmJvbmR3ZC40CkBAIC0wLDAgKzEsODggQEAKKy5cIi0K Ky5cIiBDb3B5cmlnaHQgKGMpIDIwMTEgWGluIExJIDxkZWxwaGlqQEZyZWVCU0Qub3JnPgor LlwiIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisuXCIKKy5cIiBSZWRpc3RyaWJ1dGlvbiBhbmQg dXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKy5cIiBt b2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5n IGNvbmRpdGlvbnMKKy5cIiBhcmUgbWV0OgorLlwiIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBz b3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisuXCIgICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFp bWVyLgorLlwiIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisuXCIgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2Yg Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorLlwiICAg IGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRo ZSBkaXN0cmlidXRpb24uCisuXCIKKy5cIiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisuXCIgQU5ZIEVY UFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgVEhFCisuXCIgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBB TkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKy5cIiBBUkUgRElTQ0xBSU1F RC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJ QUJMRQorLlwiIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisuXCIgREFNQUdFUyAoSU5DTFVESU5H LCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMK Ky5cIiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJV U0lORVNTIElOVEVSUlVQVElPTikKKy5cIiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRI RU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorLlwiIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkKKy5cIiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJF LCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisuXCIgU1VDSCBEQU1B R0UuCisuXCIKKy5cIiAkRnJlZUJTRCQKKy5cIgorLkRkIEp1bHkgMSwgMjAxMQorLkR0IFdJ TkJPTkRXRCA0CisuT3MKKy5TaCBOQU1FCisuTm0gd2luYm9uZHdkCisuTmQgZGV2aWNlIGRy aXZlciBmb3IgdGhlIFdpbmJvbmQgU3VwZXIgSS9PIHdhdGNoZG9nIHRpbWVyCisuU2ggU1lO T1BTSVMKK1RvIGNvbXBpbGUgdGhpcyBkcml2ZXIgaW50byB0aGUga2VybmVsLAorcGxhY2Ug dGhlIGZvbGxvd2luZyBsaW5lIGluIHlvdXIKK2tlcm5lbCBjb25maWd1cmF0aW9uIGZpbGU6 CisuQmQgLXJhZ2dlZCAtb2Zmc2V0IGluZGVudAorLkNkICJkZXZpY2Ugd2luYm9uZHdkIgor LkVkCisuUHAKK0FsdGVybmF0aXZlbHksIHRvIGxvYWQgdGhlIGRyaXZlciBhcyBhCittb2R1 bGUgYXQgYm9vdCB0aW1lLCBwbGFjZSB0aGUgZm9sbG93aW5nIGxpbmUgaW4KKy5YciBsb2Fk ZXIuY29uZiA1IDoKKy5CZCAtbGl0ZXJhbCAtb2Zmc2V0IGluZGVudAord2luYm9uZHdkX2xv YWQ9IllFUyIKKy5FZAorLlNoIERFU0NSSVBUSU9OCitUaGUKKy5ObQorZHJpdmVyIHByb3Zp ZGVzCisuWHIgd2F0Y2hkb2cgNAorc3VwcG9ydCBmb3IgdGhlIHdhdGNoZG9nIGludGVycnVw dCB0aW1lciBwcmVzZW50IG9uCithbGwgV2luYm9uZCBzdXBlciBJL08gY29udHJvbGxlcnMu CisuUHAKK1RoZSBXaW5ib25kIHN1cGVyIEkvTyBjb250cm9sbGVyIGhhdmUgYSBidWlsdC1p biB3YXRjaGRvZyB0aW1lciwKK3doaWNoIGNhbiBiZSBlbmFibGVkIGFuZCBkaXNhYmxlZCBi eSB1c2VyJ3MgcHJvZ3JhbSBhbmQgc2V0IGJldHdlZW4KKzEgdG8gMjU1IHNlY29uZHMgb3Ig MSB0byAyNTUgbWludXRlcy4KK1N1cHBvcnRlZCB3YXRjaGRvZyBpbnRlcnZhbHMgcmFuZ2Ug ZnJvbSAxIHRvIDI1NSBzZWNvbmRzLgorLlBwCitPbiBzb21lIHN5c3RlbXMgdGhlIHdhdGNo ZG9nIHRpbWVyIGlzIGVuYWJsZWQgYW5kIHNldCB0byA1IG1pbnV0ZXMKK2J5IEJJT1Mgb24g Ym9vdC4KK1RoZQorLk5tCitkcml2ZXIgd2lsbCBkZXRlY3QgYW5kIHByaW50IG91dCB0aGUg ZXhpc3Rpbmcgc2V0dGluZywgaG93ZXZlciwgCitpdCB3aWxsIG5vdCBtYWtlIGFueSBjaGFu Z2VzIHVubGVzcyB0b2xkIGJ5IHRoZSB1c2VybGFuZCB0aHJvdWdoCit0aGUKKy5YciB3YXRj aGRvZyA0CitpbnRlcmZhY2UsCitmb3IgaW5zdGFuY2UgYnkgdXNpbmcgdGhlCisuWHIgd2F0 Y2hkb2dkIDgKK2RhZW1vbi4KKy5TaCBTRUUgQUxTTworLlhyIHdhdGNoZG9nIDQgLAorLlhy IHdhdGNoZG9nIDggLAorLlhyIHdhdGNoZG9nZCA4ICwKKy5YciB3YXRjaGRvZyA5CisuU2gg SElTVE9SWQorVGhlCisuTm0KK2RyaXZlciBmaXJzdCBhcHBlYXJlZCBpbgorLkZ4IDkuMCAu CisuU2ggQVVUSE9SUworLkFuIC1ub3NwbGl0CitUaGUKKy5ObQorZHJpdmVyIGFuZCB0aGlz IG1hbnVhbCBwYWdlIHdlcmUgd3JpdHRlbiBieQorLkFuIFhpbiBMSSBBcSBkZWxwaGlqQEZy ZWVCU0Qub3JnIC4KZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9jb25mL05PVEVTIGIvc3lzL2Ft ZDY0L2NvbmYvTk9URVMKaW5kZXggNGE0N2FjZS4uM2IyNWFlYSAxMDA2NDQKLS0tIGEvc3lz L2FtZDY0L2NvbmYvTk9URVMKKysrIGIvc3lzL2FtZDY0L2NvbmYvTk9URVMKQEAgLTQ1Myw5 ICs0NTMsMTEgQEAgZGV2aWNlCQl0cG0KICMKICMgaWNod2Q6IEludGVsIElDSCB3YXRjaGRv ZyB0aW1lcgogIyBhbWRzYndkOiBBTUQgU0I3eHggd2F0Y2hkb2cgdGltZXIKKyMgd2luYm9u ZHdkOiBXaW5ib25kIHdhdGNoZG9nIHRpbWVyCiAjCiBkZXZpY2UJCWljaHdkCiBkZXZpY2UJ CWFtZHNid2QKK2RldmljZQkJd2luYm9uZHdkCiAKICMKICMgVGVtcGVyYXR1cmUgc2Vuc29y czoKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmFtZDY0IGIvc3lzL2NvbmYvZmlsZXMu YW1kNjQKaW5kZXggMTM4OGQwMS4uMThkYmVhNiAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmls ZXMuYW1kNjQKKysrIGIvc3lzL2NvbmYvZmlsZXMuYW1kNjQKQEAgLTIyMyw2ICsyMjMsNyBA QCBkZXYvdHBtL3RwbS5jCQkJb3B0aW9uYWwJdHBtCiBkZXYvdHBtL3RwbV9hY3BpLmMJCW9w dGlvbmFsCXRwbSBhY3BpCiBkZXYvdHBtL3RwbV9pc2EuYwkJb3B0aW9uYWwJdHBtIGlzYQog ZGV2L3VhcnQvdWFydF9jcHVfYW1kNjQuYwlvcHRpb25hbAl1YXJ0CitkZXYvd2luYm9uZHdk L3dpbmJvbmR3ZC5jCW9wdGlvbmFsCXdpbmJvbmR3ZAogZGV2L3dwaS9pZl93cGkuYwkJb3B0 aW9uYWwJd3BpCiBpc2Evc3lzY29uc19pc2EuYwkJb3B0aW9uYWwJc2MKIGlzYS92Z2FfaXNh LmMJCQlvcHRpb25hbAl2Z2EKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmkzODYgYi9z eXMvY29uZi9maWxlcy5pMzg2CmluZGV4IDQxYTE3NzIuLjExMjExNWQgMTAwNjQ0Ci0tLSBh L3N5cy9jb25mL2ZpbGVzLmkzODYKKysrIGIvc3lzL2NvbmYvZmlsZXMuaTM4NgpAQCAtMjM4 LDYgKzIzOCw3IEBAIGRldi90cG0vdHBtX2lzYS5jCQlvcHRpb25hbCB0cG0gaXNhCiBkZXYv dWFydC91YXJ0X2NwdV9pMzg2LmMJb3B0aW9uYWwgdWFydAogZGV2L2FjcGljYS9hY3BpX2lm Lm0JCXN0YW5kYXJkCiBkZXYvYWNwaV9zdXBwb3J0L2FjcGlfd21pX2lmLm0Jc3RhbmRhcmQK K2Rldi93aW5ib25kd2Qvd2luYm9uZHdkLmMJb3B0aW9uYWwgd2luYm9uZHdkCiBkZXYvd3Bp L2lmX3dwaS5jCQlvcHRpb25hbCB3cGkKIGkzODYvYWNwaWNhL2FjcGlfbWFjaGRlcC5jCW9w dGlvbmFsIGFjcGkKIGFjcGlfd2FrZWNvZGUubwkJCW9wdGlvbmFsIGFjcGkJCQkJXApkaWZm IC0tZ2l0IGEvc3lzL2Rldi93aW5ib25kd2Qvd2luYm9uZHdkLmMgYi9zeXMvZGV2L3dpbmJv bmR3ZC93aW5ib25kd2QuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5m YTUzNzM1Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2Rldi93aW5ib25kd2Qvd2luYm9uZHdk LmMKQEAgLTAsMCArMSwzNjggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDEwIGlYc3lz dGVtcywgSW5jLgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqICAgICBXcml0dGVuIGJ5 OiBYaW4gTEkgPGRlbHBoaWpARnJlZUJTRC5vcmc+CisgKgorICogUmVkaXN0cmlidXRpb24g YW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Cisg KiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93 aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Yg c291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFp bWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9k dWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRv Y3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBk aXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUg QVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1Mg T1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg VEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRO RVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBO TyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAq IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBM QVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VS VklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRF UlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBU T1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5Z IFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJ U0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKworLyoK KyAqIFdpbmJvbmQgV2F0Y2hkb2cgVGltZXIgKFdEVCkgZHJpdmVyCisgKi8KKworI2luY2x1 ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8 c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9t b2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+ CisjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgorI2lu Y2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4KKyNpbmNsdWRlIDxzeXMvd2F0Y2hkb2cuaD4K KworI2luY2x1ZGUgPGlzYS9pc2F2YXIuaD4KKyNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5o PgorCisjaW5jbHVkZSA8ZGV2L3dpbmJvbmR3ZC93aW5ib25kd2QuaD4KKworc3RhdGljIGRl dmNsYXNzX3Qgd2luYm9uZHdkX2RldmNsYXNzOworCisjZGVmaW5lIHdpbmJvbmR3ZF9yZWFk XzEoc2MsIG9mZikgXAorCSAgICBidXNfc3BhY2VfcmVhZF8xKChzYyktPndiX2JzdCwgKHNj KS0+d2JfYnNoLCAob2ZmKSkKKworI2RlZmluZSB3aW5ib25kd2Rfd3JpdGVfMShzYywgb2Zm LCB2YWwpIFwKKwkgICAgYnVzX3NwYWNlX3dyaXRlXzEoKHNjKS0+d2JfYnN0LCAoc2MpLT53 Yl9ic2gsIChvZmYpLCAodmFsKSkKKworLyoKKyAqIEVudGVyIFdpbmJvbmQgRXh0ZW5kZWQg RnVuY3Rpb25zIFN0YXRlCisgKi8KK3N0YXRpYyBfX2lubGluZSB2b2lkCit3aW5ib25kd2Rf Y29uZmlnX2VudGVyKHN0cnVjdCB3aW5ib25kd2Rfc29mdGMgKnNjKQoreworCisJd2luYm9u ZHdkX3dyaXRlXzEoc2MsIDAsIDB4ODcpOworCXdpbmJvbmR3ZF93cml0ZV8xKHNjLCAwLCAw eDg3KTsKK30KKworLyoKKyAqIExlYXZlIFdpbmJvbmQgRXh0ZW5kZWQgRnVuY3Rpb25zIFN0 YXRlCisgKi8KK3N0YXRpYyBfX2lubGluZSB2b2lkCit3aW5ib25kd2RfY29uZmlnX2xlYXZl KHN0cnVjdCB3aW5ib25kd2Rfc29mdGMgKnNjKQoreworCisJd2luYm9uZHdkX3dyaXRlXzEo c2MsIDAsIDB4YWEpOworfQorCitzdGF0aWMgX19pbmxpbmUgdW5zaWduZWQgY2hhcgord2lu Ym9uZHdkX3JlYWRfcmVnKHN0cnVjdCB3aW5ib25kd2Rfc29mdGMgKnNjLCB1bnNpZ25lZCBj aGFyIHJlZykKK3sKKworCXdpbmJvbmR3ZF93cml0ZV8xKHNjLCAwLCByZWcpOworCXJldHVy biAod2luYm9uZHdkX3JlYWRfMShzYywgMSkpOworfQorCisvKgorICogV3JpdGUgc3BlY2lm aWVkIGV4dGVuZGVkIGZ1bmN0aW9uIHJlZ2lzdGVyCisgKi8KK3N0YXRpYyBfX2lubGluZSB2 b2lkCit3aW5ib25kd2Rfd3JpdGVfcmVnKHN0cnVjdCB3aW5ib25kd2Rfc29mdGMgKnNjLCB1 bnNpZ25lZCBjaGFyIHJlZywgdW5zaWduZWQgY2hhciB2YWwpCit7CisKKwl3aW5ib25kd2Rf d3JpdGVfMShzYywgMCwgcmVnKTsKKwl3aW5ib25kd2Rfd3JpdGVfMShzYywgMSwgdmFsKTsK K30KKworLyoKKyAqIFNlbGVjdCB0aGUgd2F0Y2hkb2cgZGV2aWNlIChHUElPIFBvcnQgMiwg TG9naWNhbCBkZXZpY2UgOCkKKyAqLworc3RhdGljIHZvaWQKK3dpbmJvbmR3ZF9zZWxlY3Qo c3RydWN0IHdpbmJvbmR3ZF9zb2Z0YyAqc2MpCit7CisKKwl3aW5ib25kd2RfY29uZmlnX2Vu dGVyKHNjKTsKKwl3aW5ib25kd2Rfd3JpdGVfcmVnKHNjLCAvKiBMRE4gYml0IDc6MSAqLyAw eDcsIC8qIEdQSU8gUG9ydCAyICovIDB4OCk7CisJd2luYm9uZHdkX3dyaXRlX3JlZyhzYywg LyogQ1IzMCAqLyAweDMwLCAvKiBBY3RpdmF0ZSAqLyAweDEpOworfQorCisvKgorICogRGVz ZWxlY3QgdGhlIHdhdGNoZG9nIGRldmljZSAob25seSBhIGNvbmZpZ19sZWF2ZSBpcyBuZWVk ZWQpCisgKi8KK3N0YXRpYyB2b2lkCit3aW5ib25kd2RfZGVzZWxlY3Qoc3RydWN0IHdpbmJv bmR3ZF9zb2Z0YyAqc2MpCit7CisKKwl3aW5ib25kd2RfY29uZmlnX2xlYXZlKHNjKTsKK30K KworLyoKKyAqIFNob3cgdGltZW91dAorICovCitzdGF0aWMgdm9pZAord2luYm9uZHdkX3No b3dfdGltZW91dChzdHJ1Y3Qgd2luYm9uZHdkX3NvZnRjICpzYykKK3sKKwljb25zdCBjaGFy ICptb2RlX3N0cjsKKwl1bnNpZ25lZCBjaGFyIHRpbWVvdXQsIG1vZGU7CisKKwl3aW5ib25k d2Rfc2VsZWN0KHNjKTsKKwl0aW1lb3V0ID0gd2luYm9uZHdkX3JlYWRfcmVnKHNjLCAweGY2 IC8qIFRpbWVvdXQgQ1IgKi8pOworCWlmICh0aW1lb3V0ID09IDApIHsKKwkJc2MtPmFjdGl2 ZSA9IDA7CisJCWlmIChib290dmVyYm9zZSkKKwkJCWRldmljZV9wcmludGYoc2MtPmRldmlj ZSwKKwkJCSAgICAiV2luYm9uZCB3YXRjaGRvZyBub3QgcnVubmluZ1xuIik7CisJfSBlbHNl IHsKKwkJc2MtPmFjdGl2ZSA9IDE7CisJCW1vZGUgPSB3aW5ib25kd2RfcmVhZF9yZWcoc2Ms IDB4ZjUgLyogQml0IDM6IGNvdW50IG1vZGUgKi8pOworCQltb2RlX3N0ciA9IChtb2RlICYg KDEgPDwgMikpPyAibWludXRlIiA6ICJzZWNvbmQiOworCQlkZXZpY2VfcHJpbnRmKHNjLT5k ZXZpY2UsCisJCSAgICAiV2luYm9uZCB3YXRjaGRvZyB3aWxsIHRpbWVvdXQgYWZ0ZXIgJWho dSAlcyVzXG4iLAorCQkgICAgdGltZW91dCwgbW9kZV9zdHIsICgodGltZW91dCA+IDEpPyAi cyIgOiAiIikpOworCX0KKwl3aW5ib25kd2RfZGVzZWxlY3Qoc2MpOworfQorCisvKgorICog U2V0IHRpbWVvdXQgaW4gc2Vjb25kczsgMCA9IGRpc2FibGUKKyAqLworc3RhdGljIHZvaWQK K3dpbmJvbmR3ZF9zZXRfdGltZW91dChzdHJ1Y3Qgd2luYm9uZHdkX3NvZnRjICpzYywgdW5z aWduZWQgY2hhciB0aW1lb3V0KQoreworCXVuc2lnbmVkIGNoYXIgbW9kZTsKKworCS8qIERv bid0IGJvdGhlciB0byBkaXNhYmxlIGlmIHRoZSB3YXRjaGRvZyBpcyBub3QgcnVubmluZyAq LworCWlmIChzYy0+YWN0aXZlID09IDAgJiYgdGltZW91dCA9PSAwKQorCQlyZXR1cm47CisK Kwl3aW5ib25kd2Rfc2VsZWN0KHNjKTsKKwltb2RlID0gd2luYm9uZHdkX3JlYWRfcmVnKHNj LCAweGY1IC8qIEJpdCAzOiBjb3VudCBtb2RlICovKTsKKwltb2RlICY9IH4oMSA8PCAyKTsJ LyogQ2hvb3NlIHNlY29uZHMgbW9kZSAqLworCXdpbmJvbmR3ZF93cml0ZV9yZWcoc2MsIDB4 ZjUsIG1vZGUpOworCisJd2luYm9uZHdkX3dyaXRlX3JlZyhzYywgMHhmNiAvKiBUaW1lb3V0 IENSICovLCB0aW1lb3V0KTsKKwl3aW5ib25kd2RfZGVzZWxlY3Qoc2MpOworCisJaWYgKGJv b3R2ZXJib3NlKSB7CisJCWlmICh0aW1lb3V0ID09IDApCisJCQlkZXZpY2VfcHJpbnRmKHNj LT5kZXZpY2UsCisJCQkgICAgIldpbmJvbmQgd2F0Y2hkb2cgZGlzYWJsZWQuXG4iKTsKKwkJ ZWxzZQorCQkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2aWNlLAorCQkJICAgICJXaW5ib25kIHdh dGNoZG9nIHRpbWVvdXQgYWZ0ZXIgJWhodSBzZWNvbmRzLlxuIiwKKwkJCSAgICB0aW1lb3V0 KTsKKwl9CisKKwlzYy0+YWN0aXZlID0gKHRpbWVvdXQgPT0gMCkgPyAwIDogMTsKK30KKwor LyoKKyAqIFdhdGNoZG9nIGV2ZW50IGhhbmRsZXIgLSBjYWxsZWQgYnkgdGhlIGZyYW1ld29y ayB0byBlbmFibGUgb3IgZGlzYWJsZQorICogdGhlIHdhdGNoZG9nIG9yIGNoYW5nZSB0aGUg aW5pdGlhbCB0aW1lb3V0IHZhbHVlLgorICovCitzdGF0aWMgdm9pZAord2luYm9uZHdkX2V2 ZW50KHZvaWQgKmFyZywgdW5zaWduZWQgaW50IGNtZCwgaW50ICplcnJvcikKK3sKKwlzdHJ1 Y3Qgd2luYm9uZHdkX3NvZnRjICpzYyA9IGFyZzsKKwl1bnNpZ25lZCBjaGFyIHJ0aW1lb3V0 OworCXVpbnQ2NF90IHRpbWVvdXQ7CisKKwlpZiAoY21kID09IDApCisJCXdpbmJvbmR3ZF9z ZXRfdGltZW91dChzYywgMCk7CisJZWxzZSB7CisJCXRpbWVvdXQgPSAodWludDY0X3QpMSA8 PCAoY21kICYgV0RfSU5URVJWQUwpOworCQlpZiAodGltZW91dCA8ICh1aW50NjRfdCkweGZm ICogMTAwMCAqIDEwMDAgKiAxMDAwKSB7CisJCQlydGltZW91dCA9IHRpbWVvdXQgLyAoMTAw MCAqIDEwMDAgKiAxMDAwKTsKKwkJCWlmIChydGltZW91dCA9PSAwKQorCQkJCXJ0aW1lb3V0 ID0gMHhmZjsKKwkJCXdpbmJvbmR3ZF9zZXRfdGltZW91dChzYywgcnRpbWVvdXQpOworCQl9 IGVsc2UgeworCQkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2aWNlLAorCQkJICAgICJWYWx1ZSAl dSB0b28gYmlnLCBkaXNhYmxpbmdcbiIsIGNtZCAmIFdEX0lOVEVSVkFMKTsKKwkJCS8qIFBy b3Bvc2VkIHRpbWVvdXQgY2FuIG5vdCBiZSBzYXRpc2lmaWVkICovCisJCQl3aW5ib25kd2Rf c2V0X3RpbWVvdXQoc2MsIDApOworCQl9CisJfQorfQorCisvKgorICogQSBoYWNrIHRvIHBy b2JlIFdpbmJvbmQgY2hpcCdzIGJhc2UgcG9ydC4KKyAqLworc3RhdGljIHVuc2lnbmVkIGlu dAord2luYm9uZHdkX2Jhc2Vwb3J0X3Byb2JlKHZvaWQpCit7CisJdW5zaWduZWQgY2hhciB2 YWw7CisJaW50IGk7CisJY29uc3QgdW5zaWduZWQgaW50IGJhc2Vwb3J0X2NhbmRpZGF0ZXNb XSA9IHsgMHgyZSwgMHg0ZSwgMCB9OworCisJZm9yIChpID0gMDsgYmFzZXBvcnRfY2FuZGlk YXRlc1tpXSAhPSAwOyBpKyspIHsKKwkJLyoKKwkJICogRW50ZXIgY29uZmlnIG1vZGUuCisJ CSAqCisJCSAqIE91dHB1dCBtYWdpYyBudW1iZXIgdHdpY2UgdG8gdGhlIGluZGV4IHJlZ2lz dGVyCisJCSAqLworCQlvdXRiKGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV0sIDB4ODcpOworCQlv dXRiKGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV0sIDB4ODcpOworCisJCS8qCisJCSAqIEkga25v dyB0aGlzIGlzIHVnbHkgYnV0IEkgZGlkbid0IGZvdW5kIGEgd2F5IHRvIGRvCisJCSAqIHRo aXMgaW4gYSBjbGVhbmVyIG1hbm5lci4KKwkJICovCisJCS8qIEdldCBkYXRhIGZyb20gQ1Ig MHgyMCAoRGV2aWNlIElEKSAqLworCQlvdXRiKGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV0sIDB4 MjApOworCQl2YWwgPSBpbmIoYmFzZXBvcnRfY2FuZGlkYXRlc1tpXSsxKTsKKworCQlpZiAo Ym9vdHZlcmJvc2UpCisJCQlwcmludGYoIndpbmJvbmR3ZDA6IENSMjAgcHJvYmluZyBwb3J0 IDB4JXggZ290IDB4JXhcbiIsIGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV0sIHZhbCk7CisKKwkJ aWYgKHZhbCAhPSAweGZmKSB7CisJCQlvdXRiKGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV0sIDB4 YWEpOworCQkJcmV0dXJuIGJhc2Vwb3J0X2NhbmRpZGF0ZXNbaV07CisJCX0KKwl9CisKKwly ZXR1cm4gKHVuc2lnbmVkIGludCkoLTEpOworfQorCQkKKwkKKworLyoKKyAqIExvb2sgZm9y IFdpbmJvbmQgZGV2aWNlLgorICovCitzdGF0aWMgdm9pZAord2luYm9uZHdkX2lkZW50aWZ5 KGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCkKK3sKKwl1bnNpZ25lZCBpbnQg YmFzZXBvcnQ7CisJZGV2aWNlX3QgZGV2OworCisgICAgICAgIGlmICgoZGV2ID0gZGV2aWNl X2ZpbmRfY2hpbGQocGFyZW50LCBkcml2ZXItPm5hbWUsIDApKSA9PSBOVUxMKSB7CisJCWlm IChyZXNvdXJjZV9pbnRfdmFsdWUoIndpbmJvbmR3ZCIsIDAsICJiYXNlcG9ydCIsICZiYXNl cG9ydCkgIT0gMCkgeworCQkJYmFzZXBvcnQgPSB3aW5ib25kd2RfYmFzZXBvcnRfcHJvYmUo KTsKKwkJCWlmIChiYXNlcG9ydCA9PSAodW5zaWduZWQgaW50KSgtMSkpIHsKKwkJCQlwcmlu dGYoIndpbmJvbmR3ZDA6IENvbXBhdGlibGUgV2luYm9uZCBTdXBlciBJL08gbm90IGZvdW5k LlxuIik7CisJCQkJcmV0dXJuOworCQkJfQorCQl9CisKKwkJZGV2ID0gQlVTX0FERF9DSElM RChwYXJlbnQsIDAsIGRyaXZlci0+bmFtZSwgMCk7CisKKwkJYnVzX3NldF9yZXNvdXJjZShk ZXYsIFNZU19SRVNfSU9QT1JULCAwLCBiYXNlcG9ydCwgMik7CisJfQorCisJaWYgKGRldiA9 PSBOVUxMKQorCQlyZXR1cm47Cit9CisKK3N0YXRpYyBpbnQKK3dpbmJvbmR3ZF9wcm9iZShk ZXZpY2VfdCBkZXYpCit7CisKKwkvKiBEbyBub3QgY2xhaW0gc29tZSBJU0EgUG5QIGRldmlj ZSBieSBhY2NpZGVudC4gKi8KKwlpZiAoaXNhX2dldF9sb2dpY2FsaWQoZGV2KSAhPSAwKQor CQlyZXR1cm4gKEVOWElPKTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50Cit3aW5i b25kd2RfYXR0YWNoKGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3Qgd2luYm9uZHdkX3NvZnRj ICpzYzsKKwl1bnNpZ25lZCBpbnQgYmFzZXBvcnQ7CisKKwlzYyA9IGRldmljZV9nZXRfc29m dGMoZGV2KTsKKwlzYy0+ZGV2aWNlID0gZGV2OworCisJaWYgKHJlc291cmNlX2ludF92YWx1 ZSgid2luYm9uZHdkIiwgMCwgImJhc2Vwb3J0IiwgJmJhc2Vwb3J0KSAhPSAwKSB7CisJCWJh c2Vwb3J0ID0gd2luYm9uZHdkX2Jhc2Vwb3J0X3Byb2JlKCk7CisJCWlmIChiYXNlcG9ydCA9 PSAodW5zaWduZWQgaW50KSgtMSkpIHsKKwkJCWRldmljZV9wcmludGYoZGV2LAorCQkJICAg ICJObyBjb21wYXRpYmxlIFdpbmJvbmQgU3VwZXIgSS9PIGZvdW5kLlxuIik7CisJCQlyZXR1 cm4gKEVOWElPKTsKKwkJfQorCX0KKworCS8qIGFsbG9jYXRlIEkvTyByZWdpc3RlciBzcGFj ZSAqLworCXNjLT53Yl9yaWQgPSAwOworCXNjLT53Yl9yZXMgPSBidXNfYWxsb2NfcmVzb3Vy Y2UoZGV2LCBTWVNfUkVTX0lPUE9SVCwgJnNjLT53Yl9yaWQsCisJICAgIGJhc2Vwb3J0LCBi YXNlcG9ydCArIDEsIDIsIFJGX0FDVElWRSB8IFJGX1NIQVJFQUJMRSk7CisJaWYgKHNjLT53 Yl9yZXMgPT0gTlVMTCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgIlVuYWJsZSB0byByZXNl cnZlIEV4dGVuZGVkIEZ1bmN0aW9uIFJlZ2lzdGVyc1xuIik7CisJCWdvdG8gZmFpbDsKKwl9 CisJc2MtPndiX2JzdCA9IHJtYW5fZ2V0X2J1c3RhZyhzYy0+d2JfcmVzKTsKKwlzYy0+d2Jf YnNoID0gcm1hbl9nZXRfYnVzaGFuZGxlKHNjLT53Yl9yZXMpOworCisJLyogRGlzcGxheSB0 aGUgZGV2aWNlIHN0YXR1cyAqLworCXdpbmJvbmR3ZF9zaG93X3RpbWVvdXQoc2MpOworCisJ LyogcmVnaXN0ZXIgdGhlIHdhdGNoZG9nIGV2ZW50IGhhbmRsZXIgKi8KKwlzYy0+ZXZfdGFn ID0gRVZFTlRIQU5ETEVSX1JFR0lTVEVSKHdhdGNoZG9nX2xpc3QsIHdpbmJvbmR3ZF9ldmVu dCwgc2MsIDApOworCisJcmV0dXJuICgwKTsKKworZmFpbDoKKwlpZiAoc2MtPndiX3JlcyAh PSBOVUxMKQorCQlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfSU9QT1JULAor CQkgICAgc2MtPndiX3JpZCwgc2MtPndiX3Jlcyk7CisJcmV0dXJuIChFTlhJTyk7Cit9CisK K3N0YXRpYyBpbnQKK3dpbmJvbmR3ZF9kZXRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVj dCB3aW5ib25kd2Rfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CisKKwkvKiBkZXJlZ2lzdGVyIGV2ZW50IGhhbmRsZXIgKi8KKwlpZiAoc2MtPmV2X3RhZyAh PSBOVUxMKQorCQlFVkVOVEhBTkRMRVJfREVSRUdJU1RFUih3YXRjaGRvZ19saXN0LCBzYy0+ ZXZfdGFnKTsKKwlzYy0+ZXZfdGFnID0gTlVMTDsKKworCS8qIERpc2FibGUgdGhlIHdhdGNo ZG9nICovCisJaWYgKHNjLT5hY3RpdmUpCisJCXdpbmJvbmR3ZF9zZXRfdGltZW91dChzYywg MCk7CisKKwkvKiBkZWFsbG9jYXRlIEkvTyByZWdpc3RlciBzcGFjZSAqLworCWJ1c19yZWxl YXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19JT1BPUlQsIHNjLT53Yl9yaWQsIHNjLT53Yl9y ZXMpOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGRldmljZV9tZXRob2RfdCB3aW5i b25kd2RfbWV0aG9kc1tdID0geworCURFVk1FVEhPRChkZXZpY2VfaWRlbnRpZnksIHdpbmJv bmR3ZF9pZGVudGlmeSksCisJREVWTUVUSE9EKGRldmljZV9wcm9iZSwJd2luYm9uZHdkX3By b2JlKSwKKwlERVZNRVRIT0QoZGV2aWNlX2F0dGFjaCwgd2luYm9uZHdkX2F0dGFjaCksCisJ REVWTUVUSE9EKGRldmljZV9kZXRhY2gsIHdpbmJvbmR3ZF9kZXRhY2gpLAorCURFVk1FVEhP RChkZXZpY2Vfc2h1dGRvd24sIHdpbmJvbmR3ZF9kZXRhY2gpLAorCXswLDB9Cit9OworCitz dGF0aWMgZHJpdmVyX3Qgd2luYm9uZHdkX2RyaXZlciA9IHsKKwkid2luYm9uZHdkIiwKKwl3 aW5ib25kd2RfbWV0aG9kcywKKwlzaXplb2Yoc3RydWN0IHdpbmJvbmR3ZF9zb2Z0YyksCit9 OworCitEUklWRVJfTU9EVUxFKHdpbmJvbmR3ZCwgaXNhLCB3aW5ib25kd2RfZHJpdmVyLCB3 aW5ib25kd2RfZGV2Y2xhc3MsIE5VTEwsIE5VTEwpOwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi93 aW5ib25kd2Qvd2luYm9uZHdkLmggYi9zeXMvZGV2L3dpbmJvbmR3ZC93aW5ib25kd2QuaApu ZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi41N2ExYTIzCi0tLSAvZGV2L251 bGwKKysrIGIvc3lzL2Rldi93aW5ib25kd2Qvd2luYm9uZHdkLmgKQEAgLTAsMCArMSw0NyBA QAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTAgaVhzeXN0ZW1zLCBJbmMuCisgKiBBbGwg cmlnaHRzIHJlc2VydmVkLgorICogICAgIFdyaXR0ZW4gYnk6IFhpbiBMSSA8ZGVscGhpakBG cmVlQlNELm9yZz4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBh bmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICog YXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJl dGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3Ry aWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHly aWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisg KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJV VE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJ RVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBB VVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElO RElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJ QUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJF TUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0Us IERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VW RVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBD T05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdM SUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhF IFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM SVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqLworCisjaWZu ZGVmIF9XSU5CT05EV0RfSF8KKyNkZWZpbmUgX1dJTkJPTkRXRF9IXworCitzdHJ1Y3Qgd2lu Ym9uZHdkX3NvZnRjIHsKKwlkZXZpY2VfdAkJIGRldmljZTsKKworCWludAkJCSBhY3RpdmU7 CisJdW5zaWduZWQgaW50CQkgdGltZW91dDsKKworCWludAkJCSB3Yl9yaWQ7CisJc3RydWN0 IHJlc291cmNlCQkqd2JfcmVzOworCWJ1c19zcGFjZV90YWdfdAkJIHdiX2JzdDsKKwlidXNf c3BhY2VfaGFuZGxlX3QJIHdiX2JzaDsKKworCWV2ZW50aGFuZGxlcl90YWcJIGV2X3RhZzsK K307CisKKyNlbmRpZiAvKiBfV0lOQk9ORFdEX0hfICovCmRpZmYgLS1naXQgYS9zeXMvaTM4 Ni9jb25mL05PVEVTIGIvc3lzL2kzODYvY29uZi9OT1RFUwppbmRleCA4NjZlNjQxLi44MGQ4 MmEyIDEwMDY0NAotLS0gYS9zeXMvaTM4Ni9jb25mL05PVEVTCisrKyBiL3N5cy9pMzg2L2Nv bmYvTk9URVMKQEAgLTgyOCw5ICs4MjgsMTEgQEAgaGludC5wY2YuMC5pcnE9IjUiCiAjCiAj IGljaHdkOiBJbnRlbCBJQ0ggd2F0Y2hkb2cgdGltZXIKICMgYW1kc2J3ZDogQU1EIFNCN3h4 IHdhdGNoZG9nIHRpbWVyCisjIHdpbmJvbmR3ZDogV2luYm9uZCB3YXRjaGRvZyB0aW1lcgog IwogZGV2aWNlCQlpY2h3ZAogZGV2aWNlCQlhbWRzYndkCitkZXZpY2UJCXdpbmJvbmR3ZAog CiAjCiAjIFRlbXBlcmF0dXJlIHNlbnNvcnM6CmRpZmYgLS1naXQgYS9zeXMvbW9kdWxlcy9N YWtlZmlsZSBiL3N5cy9tb2R1bGVzL01ha2VmaWxlCmluZGV4IDJkYmMzZDkuLmRlNTMzZTQg MTAwNjQ0Ci0tLSBhL3N5cy9tb2R1bGVzL01ha2VmaWxlCisrKyBiL3N5cy9tb2R1bGVzL01h a2VmaWxlCkBAIC0zMjAsNiArMzIwLDcgQEAgU1VCRElSPQkke18zZGZ4fSBcCiAJdnggXAog CXdiIFwKIAkke193aX0gXAorCSR7X3dpbmJvbmR3ZH0gXAogCXdsYW4gXAogCXdsYW5fYWNs IFwKIAl3bGFuX2FtcnIgXApAQCAtNDY5LDYgKzQ3MCw3IEBAIF9zdGc9CQlzdGcKIF9zdHJl YW1zPQlzdHJlYW1zCiBfc3ZyND0JCXN2cjQKIF93aT0JCXdpCitfd2luYm9uZHdkPQl3aW5i b25kd2QKIF94ZT0JCXhlCiAuaWYgJHtNS19aRlN9ICE9ICJubyIgfHwgZGVmaW5lZChBTExf TU9EVUxFUykKIF96ZnM9CQl6ZnMKQEAgLTYyMyw2ICs2MjUsNyBAQCBfdHdhPQkJdHdhCiBf dmVzYT0JCXZlc2EKIF94ODZiaW9zPQl4ODZiaW9zCiBfd2k9CQl3aQorX3dpbmJvbmR3ZD0J d2luYm9uZHdkCiBfd3BpPQkJd3BpCiBfd3BpZnc9CQl3cGlmdwogLmlmICR7TUtfWkZTfSAh PSAibm8iIHx8IGRlZmluZWQoQUxMX01PRFVMRVMpCmRpZmYgLS1naXQgYS9zeXMvbW9kdWxl cy93aW5ib25kd2QvTWFrZWZpbGUgYi9zeXMvbW9kdWxlcy93aW5ib25kd2QvTWFrZWZpbGUK bmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uMzgyZDM3ZgotLS0gL2Rldi9u dWxsCisrKyBiL3N5cy9tb2R1bGVzL3dpbmJvbmR3ZC9NYWtlZmlsZQpAQCAtMCwwICsxLDgg QEAKKyMgJEZyZWVCU0QkCisKKy5QQVRIOiAkey5DVVJESVJ9Ly4uLy4uL2Rldi93aW5ib25k d2QKKworS01PRD0Jd2luYm9uZHdkCitTUkNTPQl3aW5ib25kd2QuYyBkZXZpY2VfaWYuaCBi dXNfaWYuaCBwY2lfaWYuaCBpc2FfaWYuaAorCisuaW5jbHVkZSA8YnNkLmttb2QubWs+Ci0t IAoxLjcuNS40Cgo= --------------030701090905090802000303-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 00:25:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A044C106566B; Wed, 29 Jun 2011 00:25:49 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA318FC14; Wed, 29 Jun 2011 00:25:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QbibE-0004nO-9E>; Wed, 29 Jun 2011 02:25:48 +0200 Received: from e178033214.adsl.alicedsl.de ([85.178.33.214] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QbibE-0006tG-5u>; Wed, 29 Jun 2011 02:25:48 +0200 Message-ID: <4E0A710C.2020906@zedat.fu-berlin.de> Date: Wed, 29 Jun 2011 02:25:48 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110627 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alexander Motin References: <4E0A1E91.3030909@FreeBSD.org> In-Reply-To: <4E0A1E91.3030909@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.33.214 Cc: FreeBSD-Current Subject: Re: CAM/SATA: attach/detach problems with harddrive 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, 29 Jun 2011 00:25:49 -0000 On 06/28/11 20:33, Alexander Motin wrote: > On 28.06.2011 18:09, O. Hartmann wrote: >> Several maintenance of a ZFS pools has to be done and my intention was >> to swap the 2TB hd disk (WDC WD20EARS-00MVWB0) with a 3TB hd disk >> (WD30EZRX). >> >> zfs umount works well, >> zpool export POOL also worked well, >> >> but I didn't find any "detach command" within camcontrol (I use the new >> AHACI/CAM layout in the kernel on FreeBSD 9.0-CURRENT/amd64 r223597, so >> my harddrives all show up as ada0 to ada4. >> Since the box has a IcyDock 5-Slot backplane attached to the ICH0R >> chipset and camcontrol doesn't reveal any detach command like atacontrol >> did, I trusted in hotplugging capabilities and simply pulled the disk. >> All right, the box reported a lost device but did not crash. The I >> inserted the new drive. Entered >> >> camcontrol rescan all >> >> and >> >> camcontrol devlist showed up the new device. But I can't do anything >> with the drive. Even with the former device inserted again, rescaned >> etc., a zpool import command get stuck as well as any diskinfo -ctv ada4 >> issued to the device. The drive shows up in camcontrol devlist, but >> seems inoperable. What I'm doing wrong? > > With controller in AHCI mode device plug-in should be detected without > any additional activity. If not, `camcontrol reset X`, `camcontrol > rescan X` sequence should force it, where X is a CAM scbus number. > > Without additional info I can't say what went wrong there. I would > recommend to enable verbose kernel messages to get more info. Also > consider that SATA default timeout is 30 seconds, so if due to some > issues during plug-in some command was lost, recovery may take a bit. > I issued this command sequence (reset X, rescan X or rescan all), but nothing happened. When unpluggin the drive, I get a message from kernel, like "ada4 lost" or similar, I don;t have the message handy right now (will provide more). Plugging in the drive again, or even another hard drive, forces a message from kernel on console reporting a device, like one will see when kernel boots and drive gets detected. A camcontrol rescan all and devlist shows also the new device. But any kind of access to the new device, like gpart or simply a zpool import to show the pool to be imported gets locked up forever (waited two hours). The state could only be resolved by resetting the box and then the filesystem is unclean an needs to be fsck'ed. Will proceed with a verbose kernel. From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 01:50:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC775106564A for ; Wed, 29 Jun 2011 01:50:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA748FC1A for ; Wed, 29 Jun 2011 01:50:09 +0000 (UTC) Received: by gyf3 with SMTP id 3so423501gyf.13 for ; Tue, 28 Jun 2011 18:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pwhxZxSZ7lZ6nJAWE5x7CPzJ2XDRCr9W7bOBdOwqn9w=; b=WQs7SLbmbjKE8TfC6llfacknedWiuvai59LcF+0lBlDAafqepL2eJKQNYpAWiWX3b7 WvMUseE282nBXmHR2UTANtb9TxN7jxJg3ZhDj2mtduYaAApvcieH0LMIgG+sGi+oQutw jS3GJmvD776A11evwbtK+r85NUBMQ3f+xx408= MIME-Version: 1.0 Received: by 10.150.208.8 with SMTP id f8mr214560ybg.399.1309312208784; Tue, 28 Jun 2011 18:50:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Tue, 28 Jun 2011 18:50:08 -0700 (PDT) In-Reply-To: <4E099EB2.7050902@freebsd.org> References: <4E099EB2.7050902@freebsd.org> Date: Wed, 29 Jun 2011 09:50:08 +0800 X-Google-Sender-Auth: qK1K0lW-JVxqM6sALBFkiUdJ_Ho Message-ID: From: Adrian Chadd To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 01:50:09 -0000 This is kinda strange; that symbol doesn't exist in the net80211 or ath sou= rce. What the heck? adrian On 28 June 2011 17:28, Stefan Esser wrote: > Hi, > > is this a known issue? > > My -CURRENT system (r223560M, amd64, 8GB, Atheros WLAN) panics after > minutes to hours of uptime with the following message: > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 0 > fault virtual address =A0 =3D 0xffffff807f502000 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor data read, page not = present > ... > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 11 (swi4: clock) > [ thread pid 11 tid 1000012 ] > Stopped at =A0 =A0 =A0ieee80211_tx_mgmt_timeout+0x1: =A0movq =A0 =A0 (%rd= i),%rdi > > db> bt > Tracing pid 11 tid 100012 td 0xfffffe00032e0000 > ieee80211_tx_mgmt_timeout() at ieee80211_tx_mgmt_timeout+0x1 > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > ithread_loop() at ithread_loop+0x96 > fork_exit() at fork_exit+0x11d > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8000288d00, rbp =3D 0 --- > > This panic message is manually transcribed, since the GPT-only > partitioning prevents dumping of a kernel core. (Why, BTW?) > I could add a swap partition on a MBR disk, if a core dump seems > neccessary to diagnose the problem. I'm also willing to wait for that > panic to occur again and to gather more debug output. > > > Other information: The Atheros WLAN in this system is unused (not > associated) but both ath0 and wlan0 were "UP" at the time of the panic. > > Initial testing shows the system to be stable with both wlan0 and ath0 > set to "down" after boot. But still, the timeout should not panic the > kernel, if WLAN is active but not fully configured (e.g. no SSID). > > Any ideas? > > Best regards, STefan > _______________________________________________ > 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 Wed Jun 29 06:05:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E2E3106564A; Wed, 29 Jun 2011 06:05:17 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C13578FC0C; Wed, 29 Jun 2011 06:05:16 +0000 (UTC) Received: by bwa20 with SMTP id 20so1089547bwa.13 for ; Tue, 28 Jun 2011 23:05:15 -0700 (PDT) Received: by 10.204.103.2 with SMTP id i2mr343512bko.7.1309327515406; Tue, 28 Jun 2011 23:05:15 -0700 (PDT) Received: from jessie.localnet (p5B2EC842.dip0.t-ipconnect.de [91.46.200.66]) by mx.google.com with ESMTPS id e6sm827898bka.11.2011.06.28.23.05.13 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 23:05:14 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-current@freebsd.org Date: Wed, 29 Jun 2011 08:03:36 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4E099EB2.7050902@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106290803.36647.bschmidt@freebsd.org> Cc: Stefan Esser , Adrian Chadd Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:05:17 -0000 On Wednesday, June 29, 2011 03:50:08 Adrian Chadd wrote: > This is kinda strange; that symbol doesn't exist in the net80211 or ath source. > > What the heck? > > > > adrian > > > > On 28 June 2011 17:28, Stefan Esser wrote: > > Hi, > > > > is this a known issue? > > > > My -CURRENT system (r223560M, amd64, 8GB, Atheros WLAN) panics after > > minutes to hours of uptime with the following message: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 0 > > fault virtual address = 0xffffff807f502000 > > fault code = supervisor data read, page not present > > ... > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 11 (swi4: clock) > > [ thread pid 11 tid 1000012 ] > > Stopped at ieee80211_tx_mgmt_timeout+0x1: movq (%rdi),%rdi > > > > db> bt > > Tracing pid 11 tid 100012 td 0xfffffe00032e0000 > > ieee80211_tx_mgmt_timeout() at ieee80211_tx_mgmt_timeout+0x1 > > intr_event_execute_handlers() at intr_event_execute_handlers+0x66 > > ithread_loop() at ithread_loop+0x96 > > fork_exit() at fork_exit+0x11d > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff8000288d00, rbp = 0 --- > > > > This panic message is manually transcribed, since the GPT-only > > partitioning prevents dumping of a kernel core. (Why, BTW?) > > I could add a swap partition on a MBR disk, if a core dump seems > > neccessary to diagnose the problem. I'm also willing to wait for that > > panic to occur again and to gather more debug output. > > > > > > Other information: The Atheros WLAN in this system is unused (not > > associated) but both ath0 and wlan0 were "UP" at the time of the panic. > > > > Initial testing shows the system to be stable with both wlan0 and ath0 > > set to "down" after boot. But still, the timeout should not panic the > > kernel, if WLAN is active but not fully configured (e.g. no SSID). > > > > Any ideas? It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC requests. Afaik there is even a similar PR about that. Adrian, you've got a AP set up to drop either a AUTH or ASSOC response frame? -- Bernhard From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 07:17:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF2AB106566B for ; Wed, 29 Jun 2011 07:17:56 +0000 (UTC) (envelope-from gber@freebsd.org) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 80FE98FC08 for ; Wed, 29 Jun 2011 07:17:56 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 50D3BC5B20; Wed, 29 Jun 2011 09:17:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id tSZ4N-KpEwTw; Wed, 29 Jun 2011 09:17:54 +0200 (CEST) Received: from gjb-host.home (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7AE96C4C6A; Wed, 29 Jun 2011 09:17:54 +0200 (CEST) Message-ID: <4E0AD226.6080107@freebsd.org> Date: Wed, 29 Jun 2011 09:20:06 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100630 Thunderbird/3.0.5 MIME-Version: 1.0 To: Rick Macklem References: <40143899.5952.1309268280142.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <40143899.5952.1309268280142.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: NFS/BOOTP problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:17:56 -0000 On 06/28/11 15:38, Rick Macklem wrote: > Grzegorz Bernacki wrote: >> Hi, >> >> After rebasing to new -current I experienced problem with mounting >> root >> via NFS. I was getting error: "Mounting from nfs: failed with error 2: >> unknown file system.". I use BOOTP and NFSv3 (option NFSCLIENT). It >> seems that bootp set fs type to 'nfs' and recently NFSv3 was renamed >> to >> 'oldnfs'. Patch below fixes the problem. Do you think it is proper >> solution? Could it be fixed some other better way? >> > If you wish to use the old NFS client as the root fs, you can add a line > like: > vfs.root.mountfrom="oldnfs:" > > in the boot/loader.conf file on the root fs in the NFS server to have the > same effect as your patch. (This is mentioned in the message in UPDATING.) > > However, it would be nice if you used the new NFS client instead, by building > the kernel with "option NFSCL" so that it uses the new NFS client. > (The new NFS client does NFSv3 in what I believe to be a completely compatible > way as the old one.) > > If you tried the new NFS client and it didn't work for you, I would like > to hear what the problem was, so it can be resolved. (The intent was to leave > the old NFS client in the system so that it could be used as a fallback when > the new one didn't work correctly for some situation.) > > If others feel that having a system that will boot via the old NFS client > without needing to add the line to loader.conf is important, then doing > your patch would be appropriate. I didn't do what your patch does, since I > was hoping folks would use the new client instead and only force use of the > old one when it was really necessary. > > rick > [patch snipped for brevity] Hi Rick, The problem is that in embedded development sometimes loader is not used. And in that case we would like to have possibity to use old NFS client without patching code every time. So if you don't mind I would like to commit the patch. I also will try new nfs client and let you know if I find any problems. grzesiek From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 07:41:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432EF106564A for ; Wed, 29 Jun 2011 07:41:34 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 226B28FC13 for ; Wed, 29 Jun 2011 07:41:34 +0000 (UTC) Received: by pzk27 with SMTP id 27so894763pzk.13 for ; Wed, 29 Jun 2011 00:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=i05um+bVq1PuU8Vj2DUXvjEYMYIYoy2B/i7iPbkJKps=; b=VtG39qh+Qx6y56eexiMF+3HR8ZRaqENm2OUaftf+hIATW2vgM+78dQoz8OC5MPrML9 tyS+OOpEhhH1VTmzM1ep8ID3XcwhWyTBYFaABpFiJ1FSR4nX7Wnnv4eCXAtBEHtokWk7 IIV5QZkMiskP4JEZpNBgBT2b5BELPfHUgAJTg= MIME-Version: 1.0 Received: by 10.68.41.165 with SMTP id g5mr759334pbl.106.1309333293661; Wed, 29 Jun 2011 00:41:33 -0700 (PDT) Received: by 10.68.56.104 with HTTP; Wed, 29 Jun 2011 00:41:33 -0700 (PDT) Date: Wed, 29 Jun 2011 11:41:33 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 29 Jun 2011 07:41:34 -0000 2011/6/28 Marius Strobl : >> I'm got a problem with named on FreeBSD-CURRENT/sparc64. >> Up to 5 times a day it crashes with these messages: >> 27-Jun-2011 03:42:14.384 general: >> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: >> REQUIRE(prev > 0) failed >> 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) >> I found a some similar problems on alpha and IA64, which was related >> to problems with isc_atomic_xadd() function in include/isc/atomic.h. >> But I don't understand that there may be incorrect for sparc64 and >> this function was not changed for a minimum 4 years... > Uhm, we once fixed a problem in the MD atomic implementation which > still seems to present in the ISC copy. Could you please test whether > the following patch makes a difference? > http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff Oh, Marius, You are my savior... I ran named with your patch and and watching him. I think this should be sufficient: cd /usr/src/lib/bind/dns make clean make cd /usr/src/usr.sbin/named make clean make make install (and named's restart) -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 08:01:14 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A37C106566B for ; Wed, 29 Jun 2011 08:01:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5D31A8FC19 for ; Wed, 29 Jun 2011 08:01:05 +0000 (UTC) Received: from alph.allbsd.org (p3028-ipbf608funabasi.chiba.ocn.ne.jp [125.175.94.28]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5T7dsSn059682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Jun 2011 16:40:05 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5T7doBD041375 for ; Wed, 29 Jun 2011 16:39:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 29 Jun 2011 16:34:28 +0900 (JST) Message-Id: <20110629.163428.868599432127233969.hrs@allbsd.org> To: current@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jun_29_16_34_28_2011_211)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Wed, 29 Jun 2011 16:40:05 +0900 (JST) X-Spam-Status: No, score=2.3 required=14.0 tests=BAYES_40, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: Subject: daily snapshot build 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, 29 Jun 2011 08:01:14 -0000 ----Security_Multipart(Wed_Jun_29_16_34_28_2011_211)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Just wanted to let you know that daily snapshot builds from the HEAD source tree are available again at http://pub.allbsd.org/FreeBSD-snapshots/. Currently i386 and amd64 build have been recovered. Although it was down for a while due to hardware failure, it is recovering now including other archs. The snapshot builds can also be found via ftp://ftp.allbsd.org/pub or rsync://rsync.allbsd.org/freebsd-snapshots/. I hope these help for testing purpose. Please note that it may be unstable this week because temporary network access outage (for a short time) is planned on Friday. -- Hiroki ----Security_Multipart(Wed_Jun_29_16_34_28_2011_211)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk4K1YQACgkQTyzT2CeTzy3WhQCfW+yrBttD7uWwxnuavkrDEVfX oigAoNVGpZzqY26LLJ2Z1yraLEohxYAB =C8M0 -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jun_29_16_34_28_2011_211)---- From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 08:03:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711641065675; Wed, 29 Jun 2011 08:03:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E61A8FC1D; Wed, 29 Jun 2011 08:03:02 +0000 (UTC) Received: by gyf3 with SMTP id 3so512479gyf.13 for ; Wed, 29 Jun 2011 01:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P2Bgya4b9W9NmubnM/XMGzIJbFDOquNn6N0JWK+hV4E=; b=VtlUCxLdlRBP4cTVp20sXNqCI84zOzkZ7yfgTxDU8lRtoriykL+c0/1+yYAK1OtylM ds51UkSrWvXxUJcnvih1Giu4kSbXLN05/ueJ8+ba5x6jrbK0XWOE0Ior7iiuebzKdhCQ 9JONRubGm1g4ZgIq/ld338k97kZjaalA9p6RU= MIME-Version: 1.0 Received: by 10.151.92.3 with SMTP id u3mr434060ybl.114.1309334582253; Wed, 29 Jun 2011 01:03:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Wed, 29 Jun 2011 01:03:02 -0700 (PDT) In-Reply-To: <201106290803.36647.bschmidt@freebsd.org> References: <4E099EB2.7050902@freebsd.org> <201106290803.36647.bschmidt@freebsd.org> Date: Wed, 29 Jun 2011 16:03:02 +0800 X-Google-Sender-Auth: tYcICCzqv0mXiLkQ-TjT71GNP2Y Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Stefan Esser , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:03:03 -0000 On 29 June 2011 14:03, Bernhard Schmidt wrote: > It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC > requests. Afaik there is even a similar PR about that. > > Adrian, you've got a AP set up to drop either a AUTH or ASSOC > response frame? Tell me how and I'll set it up. A panic at that point in the function indicates maybe ni is NULL? or ni->vap is now NULL, maybe? Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 08:29:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3710E106566C; Wed, 29 Jun 2011 08:29:40 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4FA8FC1D; Wed, 29 Jun 2011 08:29:36 +0000 (UTC) Received: by fxe6 with SMTP id 6so850403fxe.17 for ; Wed, 29 Jun 2011 01:29:36 -0700 (PDT) Received: by 10.223.6.198 with SMTP id a6mr845586faa.130.1309336176120; Wed, 29 Jun 2011 01:29:36 -0700 (PDT) Received: from jessie.localnet (p5B2EC842.dip0.t-ipconnect.de [91.46.200.66]) by mx.google.com with ESMTPS id v20sm675447fai.7.2011.06.29.01.29.34 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 01:29:35 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Wed, 29 Jun 2011 10:27:56 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4E099EB2.7050902@freebsd.org> <201106290803.36647.bschmidt@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106291027.56939.bschmidt@freebsd.org> Cc: Stefan Esser , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 08:29:40 -0000 On Wednesday, June 29, 2011 10:03:02 Adrian Chadd wrote: > On 29 June 2011 14:03, Bernhard Schmidt wrote: > > > It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC > > requests. Afaik there is even a similar PR about that. > > > > Adrian, you've got a AP set up to drop either a AUTH or ASSOC > > response frame? > > Tell me how and I'll set it up. > > A panic at that point in the function indicates maybe ni is NULL? > or ni->vap is now NULL, maybe? vap should never be NULL, so, I'd guess it's ni. Hmm.. I'd guess there is some kind of racy behavior, if the driver is telling us that it was able to send the AUTH req frame, net80211 sets up the timeout callback. What happens if the AUTH resp as well as the callback hit at the same time? It should be locked appropriately, but is it? This will drop the AUTH response: Index: sys/net80211/ieee80211_hostap.c =================================================================== --- sys/net80211/ieee80211_hostap.c (revision 223661) +++ sys/net80211/ieee80211_hostap.c (working copy) @@ -978,7 +978,7 @@ hostap_auth_open(struct ieee80211_node *ni, struct "%s", "station authentication defered (radius acl)"); ieee80211_notify_node_auth(ni); } else { - IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); + //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_DEBUG | IEEE80211_MSG_AUTH, ni->ni_macaddr, "%s", "station authenticated (open)"); @@ -1158,7 +1158,7 @@ hostap_auth_shared(struct ieee80211_node *ni, stru estatus = IEEE80211_STATUS_SEQUENCE; goto bad; } - IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); + //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); return; bad: /* -- Bernhard From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 08:42:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C8A1065670; Wed, 29 Jun 2011 08:42:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DD1798FC0C; Wed, 29 Jun 2011 08:42:22 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA22097; Wed, 29 Jun 2011 11:42:19 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QbqLj-0008kb-9X; Wed, 29 Jun 2011 11:42:19 +0300 Message-ID: <4E0AE56A.8070508@FreeBSD.org> Date: Wed, 29 Jun 2011 11:42:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Hartmann, O." References: <4E0A1E91.3030909@FreeBSD.org> <4E0A710C.2020906@zedat.fu-berlin.de> In-Reply-To: <4E0A710C.2020906@zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current Subject: Re: CAM/SATA: attach/detach problems with harddrive 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, 29 Jun 2011 08:42:23 -0000 on 29/06/2011 03:25 Hartmann, O. said the following: > But any kind of access to the new device, like gpart or simply a zpool import to > show the pool to be imported gets locked up forever (waited two hours). The > state could only be resolved by resetting the box and then the filesystem is > unclean an needs to be fsck'ed. > > Will proceed with a verbose kernel. I think that procstat -kk output for at least one stuck process could also turn out to be useful. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 09:07:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49BAB1065670 for ; Wed, 29 Jun 2011 09:07:38 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm5-vm0.bullet.mail.ne1.yahoo.com (nm5-vm0.bullet.mail.ne1.yahoo.com [98.138.90.251]) by mx1.freebsd.org (Postfix) with SMTP id 183358FC1E for ; Wed, 29 Jun 2011 09:07:38 +0000 (UTC) Received: from [98.138.90.48] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2011 08:53:43 -0000 Received: from [98.138.84.34] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2011 08:53:43 -0000 Received: from [127.0.0.1] by smtp102.mail.ne1.yahoo.com with NNFMP; 29 Jun 2011 08:53:43 -0000 X-Yahoo-Newman-Id: 606197.96215.bm@smtp102.mail.ne1.yahoo.com Received: from [192.168.119.20] (se@81.173.144.90 with plain) by smtp102.mail.ne1.yahoo.com with SMTP; 29 Jun 2011 01:53:42 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: vl3NgUcVM1kGkTVe8dTugvA6Mx7aL9n8TA7NtarETXGA_O2 UIMhPFLNq79rRDoaS8u5d0cXw4shodd35Zw0uaD1fMpzYyoXoXSKgCAHSbhH JZxboJY0MOVTM1Cn770v4l.99iNycaXVafKKeCH1ETga_x_stzRvxdO8fv7C Kh0gA_je9g5qV538dfXBmNDELZs2k4vpJvGW150PT9HZSFwArfu16kNrcXQK vb.gcNnwArwcme2cGXHgN0hfOsc6huh9JLzkD9drYjtU.lXTjYko.Krp8fQp pRVtcQ_tXbTLBqCHO7LPO5LAkSist9ckXLPCkqUngUv8zZYZONvzN.wyvnNQ 2Bo8hJ0tNdElLoU1Ntt3.ve9vZTnXRfSkBvf0lQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E0AE815.2070502@freebsd.org> Date: Wed, 29 Jun 2011 10:53:41 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110620 Thunderbird/5.0b2 MIME-Version: 1.0 To: Adrian Chadd References: <4E099EB2.7050902@freebsd.org> <201106290803.36647.bschmidt@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, bschmidt@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:07:38 -0000 Am 29.06.2011 10:03, schrieb Adrian Chadd: > On 29 June 2011 14:03, Bernhard Schmidt wrote: >> It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC >> requests. Afaik there is even a similar PR about that. Sorry, I manually entered the panic message, since dumps were not working on my system at the time of that panic. >> Adrian, you've got a AP set up to drop either a AUTH or ASSOC >> response frame? I've got a number of AUTH -> SCAN transition lost messages for wlan0, seconds to minutes apart: Jun 28 21:16:17 kernel: wlan0: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost Jun 28 21:34:46 kernel: wlan0: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost Jun 28 21:36:33 kernel: wlan0: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost Jun 28 21:45:14 kernel: wlan0: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost Jun 28 21:45:44 kernel: wlan0: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost The setup is easy to reproduce, my rc.conf contained: wlans_ath0="wlan0" ifconfig_ath0="down" ifconfig_wlan0="down" wpa_supplicant_enable="YES" This system used to be connected via ath0, but recently was moved to a place where Ethernet is available. The panics started only after WLAN was not used anymore. I might disable wpa_supplicant, since it is not required in the current situation, but did not try whether that helps prevent the panic. > Tell me how and I'll set it up. > > A panic at that point in the function indicates maybe ni is NULL? > or ni->vap is now NULL, maybe? I recreated the panic, this time with kernel dumps correctly configured (thanks for the hint, Scott). The panic message is: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffff809c7a1000 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805e1851 stack pointer = 0x28:0xffffff8000288ab0 frame pointer = 0x28:0xffffff8000288b60 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 = 11 (swi4: clock) Traceback: #10 0xffffffff805e1851 in ieee80211_tx_mgt_timeout (arg=0xffffff809c7a1000) at ../../../net80211/ieee80211_output.c:2487 This indicates, that an invalid argument is passed and assigned to "*ni", which causes the page fault when dereferencing "ni" to obtain "*va". I'm afraid that the assumption in the comment (about timeout being save to use) does not really hold: static void ieee80211_tx_mgt_timeout(void *arg) { struct ieee80211_node *ni = arg; struct ieee80211vap *vap = ni->ni_vap; if (vap->iv_state != IEEE80211_S_INIT && (vap->iv_ic->ic_flags & IEEE80211_F_SCAN) == 0) { /* * NB: it's safe to specify a timeout as the reason here; * it'll only be used in the right state. */ ieee80211_new_state(vap, IEEE80211_S_SCAN, IEEE80211_SCAN_FAIL_TIMEOUT)*vap ; } } If "vap" is valid during one invocation of that function, I'd expect it to at least be a pointer to valid kernel memory after the timeout. I.e., the value found by dereferencing it may be stale, but the pointer itself should at least not cause a page fault. (???) The compressed core.txt is 27KB, the compressed vmcore is 800MB. I might be able to find a place to upload the vmcore file to, but since I'm currently on a DSL with only 672KBit/s upstream, it would take me some 3 hours to upload to a better connected server (and I'd like to avoid doing that, if not essential for debugging). The core.txt is small enough to send by mail. Let me know if you think it helps you understand the problem. I'm willing to support debugging, e.g. by placement of printfs in my kernel for the timeout handler and the creation and destruction of *vap structures. After removal of "wlans_ath0=wlan0" the system will most probably be stable, I did not specifically test this case (i.e. ath0 configured, but no wlan0 created). I do know, that an "ifconfig down" of ath0 and wlan0 suffices; probably an "ifconfig wlan0 down" alone would be enough. So, I know how to avoid the panic, but I think it is still important to find the cause. Thank you for looking into this! Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 09:16:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8ADF106566B for ; Wed, 29 Jun 2011 09:16:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by mx1.freebsd.org (Postfix) with SMTP id 8A0048FC1C for ; Wed, 29 Jun 2011 09:16:20 +0000 (UTC) Received: from [98.139.91.70] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jun 2011 09:03:50 -0000 Received: from [208.71.42.208] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jun 2011 09:03:50 -0000 Received: from [127.0.0.1] by smtp219.mail.gq1.yahoo.com with NNFMP; 29 Jun 2011 09:03:50 -0000 X-Yahoo-Newman-Id: 129554.88532.bm@smtp219.mail.gq1.yahoo.com Received: from [192.168.119.20] (se@81.173.144.90 with plain) by smtp219.mail.gq1.yahoo.com with SMTP; 29 Jun 2011 02:03:49 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: mvwkV1oVM1nM5Y_5F6WljkzySuQc.g6NybE9CJTaEet2qXj 0QZl3mPR25o1szrm4EgQsbXAR4W1AOCHPuaK9zbb9wy0aKR8h9T4yDwpkrCi 24qT1ga_JIDqV5j.edPOkHv8rlNEi6y_4AzUpKySdyEDufpGVzd9IjUSHCw. lpIO3bYstOOE8lM7pbphyKaIYOQ64wrDv_9ren5FqMVe_nZflq9Pa.OorOkF YNT9rHaXfbE1mBOkZALjpPisL.ygYcEprCFYV03ahQGsFgOZKMMszJqPV.Ma UU6uLARwPxvW9AZrNc_iTV_r6oRrfiwYF6g0D7dI.6XYfzT8gbK.uM5bZcOW cnN6TNmu1ch_p5ERYR7RfIsxWlg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E0AEA74.1050603@freebsd.org> Date: Wed, 29 Jun 2011 11:03:48 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110620 Thunderbird/5.0b2 MIME-Version: 1.0 To: bschmidt@freebsd.org References: <4E099EB2.7050902@freebsd.org> <201106290803.36647.bschmidt@freebsd.org> <201106291027.56939.bschmidt@freebsd.org> In-Reply-To: <201106291027.56939.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:16:20 -0000 On 29.06.2011 10:27, Bernhard Schmidt wrote: > On Wednesday, June 29, 2011 10:03:02 Adrian Chadd wrote: >> On 29 June 2011 14:03, Bernhard Schmidt wrote: >> >>> It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC >>> requests. Afaik there is even a similar PR about that. >>> >>> Adrian, you've got a AP set up to drop either a AUTH or ASSOC >>> response frame? >> >> Tell me how and I'll set it up. >> >> A panic at that point in the function indicates maybe ni is NULL? >> or ni->vap is now NULL, maybe? > > vap should never be NULL, so, I'd guess it's ni. No, neither vap no vap->ni appear to cause NULL dereferences. The panic message indicates a fault address of 0xffffff809c7a1000, which is the value of arg passed to ieee80211_tx_mgt_timeout(). The fault occurs on the first instruction within that function and I take this to mean, that it points outside kernel VM space. (I have got to admit, that I do not know the exact memory layout for amd64, though.) > Hmm.. I'd guess there is some kind of racy behavior, if the driver is > telling us that it was able to send the AUTH req frame, net80211 sets > up the timeout callback. What happens if the AUTH resp as well as the > callback hit at the same time? It should be locked appropriately, but > is it? > > This will drop the AUTH response: I have received a number of messages that might indicate a lost race: ieee80211_new_state_locked: pending AUTH -> SCAN transition lost repeats with between a few seconds and 20 minutes between messages. > Index: sys/net80211/ieee80211_hostap.c > =================================================================== > --- sys/net80211/ieee80211_hostap.c (revision 223661) > +++ sys/net80211/ieee80211_hostap.c (working copy) > @@ -978,7 +978,7 @@ hostap_auth_open(struct ieee80211_node *ni, struct > "%s", "station authentication defered (radius acl)"); > ieee80211_notify_node_auth(ni); > } else { > - IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); > + //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); > IEEE80211_NOTE_MAC(vap, > IEEE80211_MSG_DEBUG | IEEE80211_MSG_AUTH, ni->ni_macaddr, > "%s", "station authenticated (open)"); > @@ -1158,7 +1158,7 @@ hostap_auth_shared(struct ieee80211_node *ni, stru > estatus = IEEE80211_STATUS_SEQUENCE; > goto bad; > } > - IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); > + //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1); > return; > bad: > /* > > I could try that patch for a few hours ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 09:21:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9744A106566C; Wed, 29 Jun 2011 09:21:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 457908FC08; Wed, 29 Jun 2011 09:21:56 +0000 (UTC) Received: by yic13 with SMTP id 13so534513yic.13 for ; Wed, 29 Jun 2011 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bk1O7ABdo0Tap11y5nCTPrRTFZIjLuQ9I7FAa1Xm480=; b=k61x9cdCTSO/cjvCVzKUY5KM9kTBcOfpeZyEap1KwyPPBWGwnjjdEWk+Zc7lJ9ZutR 0N+1Y2NL1R3bp/0P6zbDFV9B+CvGtPQI0C7mJXONj2MenpTEBu8GfhxMLAsBOuoLhB9a c+9Zo8/mF1C6a2zT6g8tVqbjD40LuGJb6S0VE= MIME-Version: 1.0 Received: by 10.150.208.8 with SMTP id f8mr498038ybg.399.1309339315427; Wed, 29 Jun 2011 02:21:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Wed, 29 Jun 2011 02:21:55 -0700 (PDT) In-Reply-To: <201106291027.56939.bschmidt@freebsd.org> References: <4E099EB2.7050902@freebsd.org> <201106290803.36647.bschmidt@freebsd.org> <201106291027.56939.bschmidt@freebsd.org> Date: Wed, 29 Jun 2011 17:21:55 +0800 X-Google-Sender-Auth: Yo9wAgsqCuMfsJ8S5vSEYNzggB0 Message-ID: From: Adrian Chadd To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Esser , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:21:56 -0000 The question here is - what context is the callback being called in? The lack of net80211 locking has me confused and sad. :/ Adrian On 29 June 2011 16:27, Bernhard Schmidt wrote: > On Wednesday, June 29, 2011 10:03:02 Adrian Chadd wrote: >> On 29 June 2011 14:03, Bernhard Schmidt wrote: >> >> > It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC >> > requests. Afaik there is even a similar PR about that. >> > >> > Adrian, you've got a AP set up to drop either a AUTH or ASSOC >> > response frame? >> >> Tell me how and I'll set it up. >> >> A panic at that point in the function indicates maybe ni is NULL? >> or ni->vap is now NULL, maybe? > > vap should never be NULL, so, I'd guess it's ni. > > Hmm.. I'd guess there is some kind of racy behavior, if the driver is > telling us that it was able to send the AUTH req frame, net80211 sets > up the timeout callback. What happens if the AUTH resp as well as the > callback hit at the same time? It should be locked appropriately, but > is it? > > This will drop the AUTH response: > > Index: sys/net80211/ieee80211_hostap.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 > --- sys/net80211/ieee80211_hostap.c =A0 =A0 (revision 223661) > +++ sys/net80211/ieee80211_hostap.c =A0 =A0 (working copy) > @@ -978,7 +978,7 @@ hostap_auth_open(struct ieee80211_node *ni, struct > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s", "station authentication defe= red (radius acl)"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ieee80211_notify_node_auth(ni); > =A0 =A0 =A0 =A0} else { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTY= PE_AUTH, seq + 1); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUB= TYPE_AUTH, seq + 1); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_NOTE_MAC(vap, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_MSG_DEBUG | IEEE80211_MS= G_AUTH, ni->ni_macaddr, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s", "station authenticated (open= )"); > @@ -1158,7 +1158,7 @@ hostap_auth_shared(struct ieee80211_node *ni, stru > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0estatus =3D IEEE80211_STATUS_SEQUENCE; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > =A0 =A0 =A0 =A0} > - =A0 =A0 =A0 IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq + 1= ); > + =A0 =A0 =A0 //IEEE80211_SEND_MGMT(ni, IEEE80211_FC0_SUBTYPE_AUTH, seq += 1); > =A0 =A0 =A0 =A0return; > =A0bad: > =A0 =A0 =A0 =A0/* > > > -- > Bernhard > From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 09:22:39 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F644106564A for ; Wed, 29 Jun 2011 09:22:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 323E78FC19 for ; Wed, 29 Jun 2011 09:22:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23049; Wed, 29 Jun 2011 12:22:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QbqyZ-0008n3-Uu; Wed, 29 Jun 2011 12:22:28 +0300 Message-ID: <4E0AEED2.7060702@FreeBSD.org> Date: Wed, 29 Jun 2011 12:22:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: d@delphij.net References: <4E0A5689.2020302@delphij.net> In-Reply-To: <4E0A5689.2020302@delphij.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Xin LI Subject: Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/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: Wed, 29 Jun 2011 09:22:39 -0000 on 29/06/2011 01:32 Xin LI said the following: > Hi, > > I'd like to request for comments on the attached driver, which supports > watchdogs on several Winbond super I/O chip models and have been tested > on a few of recent Supermicro motherboards. Some comments. > From 343b2e7b6ed19e4b6ca2bf76c0ca6b8544dd4320 Mon Sep 17 00:00:00 2001 > From: Xin LI > Date: Mon, 27 Jun 2011 21:54:13 -0700 > Subject: [PATCH] Driver for Winbond watchdog. > > --- > share/man/man4/Makefile | 3 + > share/man/man4/winbondwd.4 | 88 ++++++++++ > sys/amd64/conf/NOTES | 2 + > sys/conf/files.amd64 | 1 + > sys/conf/files.i386 | 1 + > sys/dev/winbondwd/winbondwd.c | 368 ++++++++++++++++++++++++++++++++++++++++ > sys/dev/winbondwd/winbondwd.h | 47 +++++ > sys/i386/conf/NOTES | 2 + > sys/modules/Makefile | 3 + > sys/modules/winbondwd/Makefile | 8 + > 10 files changed, 523 insertions(+), 0 deletions(-) > create mode 100644 share/man/man4/winbondwd.4 > create mode 100644 sys/dev/winbondwd/winbondwd.c > create mode 100644 sys/dev/winbondwd/winbondwd.h > create mode 100644 sys/modules/winbondwd/Makefile > > diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile > index 7ccccfb..777e2fd 100644 > --- a/share/man/man4/Makefile > +++ b/share/man/man4/Makefile > @@ -447,6 +447,7 @@ MAN= aac.4 \ > tun.4 \ > twa.4 \ > twe.4 \ > + tws.4 \ Looks like this has sneaked in accidentally. > tx.4 \ > txp.4 \ > u3g.4 \ > @@ -503,6 +504,7 @@ MAN= aac.4 \ > watchdog.4 \ > wb.4 \ > wi.4 \ > + ${_winbondwd.4} \ > witness.4 \ > wlan.4 \ > wlan_acl.4 \ > @@ -706,6 +708,7 @@ _speaker.4= speaker.4 > _spkr.4= spkr.4 > _tpm.4= tpm.4 > _urtw.4= urtw.4 > +_winbondwd.4= winbondwd.4 > _wpi.4= wpi.4 > _xen.4= xen.4 > > diff --git a/share/man/man4/winbondwd.4 b/share/man/man4/winbondwd.4 > new file mode 100644 > index 0000000..6fd2719 > --- /dev/null > +++ b/share/man/man4/winbondwd.4 > @@ -0,0 +1,88 @@ > +.\"- > +.\" Copyright (c) 2011 Xin LI > +.\" All rights reserved. > +.\" > +.\" Redistribution and use in source and binary forms, with or without > +.\" modification, are permitted provided that the following conditions > +.\" are met: > +.\" 1. Redistributions of source code must retain the above copyright > +.\" notice, this list of conditions and the following disclaimer. > +.\" 2. Redistributions in binary form must reproduce the above copyright > +.\" notice, this list of conditions and the following disclaimer in the > +.\" documentation and/or other materials provided with the distribution. > +.\" > +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > +.\" SUCH DAMAGE. > +.\" > +.\" $FreeBSD$ > +.\" > +.Dd July 1, 2011 > +.Dt WINBONDWD 4 > +.Os > +.Sh NAME > +.Nm winbondwd > +.Nd device driver for the Winbond Super I/O watchdog timer > +.Sh SYNOPSIS > +To compile this driver into the kernel, > +place the following line in your > +kernel configuration file: > +.Bd -ragged -offset indent > +.Cd "device winbondwd" > +.Ed > +.Pp > +Alternatively, to load the driver as a > +module at boot time, place the following line in > +.Xr loader.conf 5 : > +.Bd -literal -offset indent > +winbondwd_load="YES" > +.Ed > +.Sh DESCRIPTION > +The > +.Nm > +driver provides > +.Xr watchdog 4 > +support for the watchdog interrupt timer present on > +all Winbond super I/O controllers. > +.Pp > +The Winbond super I/O controller have a built-in watchdog timer, > +which can be enabled and disabled by user's program and set between > +1 to 255 seconds or 1 to 255 minutes. > +Supported watchdog intervals range from 1 to 255 seconds. > +.Pp > +On some systems the watchdog timer is enabled and set to 5 minutes > +by BIOS on boot. > +The > +.Nm > +driver will detect and print out the existing setting, however, > +it will not make any changes unless told by the userland through > +the > +.Xr watchdog 4 > +interface, > +for instance by using the > +.Xr watchdogd 8 > +daemon. > +.Sh SEE ALSO > +.Xr watchdog 4 , > +.Xr watchdog 8 , > +.Xr watchdogd 8 , > +.Xr watchdog 9 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Fx 9.0 . > +.Sh AUTHORS > +.An -nosplit > +The > +.Nm > +driver and this manual page were written by > +.An Xin LI Aq delphij@FreeBSD.org . > diff --git a/sys/amd64/conf/NOTES b/sys/amd64/conf/NOTES > index 4a47ace..3b25aea 100644 > --- a/sys/amd64/conf/NOTES > +++ b/sys/amd64/conf/NOTES > @@ -453,9 +453,11 @@ device tpm > # > # ichwd: Intel ICH watchdog timer > # amdsbwd: AMD SB7xx watchdog timer > +# winbondwd: Winbond watchdog timer > # > device ichwd > device amdsbwd > +device winbondwd > > # > # Temperature sensors: > diff --git a/sys/conf/files.amd64 b/sys/conf/files.amd64 > index 1388d01..18dbea6 100644 > --- a/sys/conf/files.amd64 > +++ b/sys/conf/files.amd64 > @@ -223,6 +223,7 @@ dev/tpm/tpm.c optional tpm > dev/tpm/tpm_acpi.c optional tpm acpi > dev/tpm/tpm_isa.c optional tpm isa > dev/uart/uart_cpu_amd64.c optional uart > +dev/winbondwd/winbondwd.c optional winbondwd > dev/wpi/if_wpi.c optional wpi > isa/syscons_isa.c optional sc > isa/vga_isa.c optional vga > diff --git a/sys/conf/files.i386 b/sys/conf/files.i386 > index 41a1772..112115d 100644 > --- a/sys/conf/files.i386 > +++ b/sys/conf/files.i386 > @@ -238,6 +238,7 @@ dev/tpm/tpm_isa.c optional tpm isa > dev/uart/uart_cpu_i386.c optional uart > dev/acpica/acpi_if.m standard > dev/acpi_support/acpi_wmi_if.m standard > +dev/winbondwd/winbondwd.c optional winbondwd > dev/wpi/if_wpi.c optional wpi > i386/acpica/acpi_machdep.c optional acpi > acpi_wakecode.o optional acpi \ > diff --git a/sys/dev/winbondwd/winbondwd.c b/sys/dev/winbondwd/winbondwd.c > new file mode 100644 > index 0000000..fa53735 > --- /dev/null > +++ b/sys/dev/winbondwd/winbondwd.c > @@ -0,0 +1,368 @@ > +/*- > + * Copyright (c) 2010 iXsystems, Inc. > + * All rights reserved. > + * Written by: Xin LI > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + */ > + > +/* > + * Winbond Watchdog Timer (WDT) driver > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include > + > +static devclass_t winbondwd_devclass; > + > +#define winbondwd_read_1(sc, off) \ > + bus_space_read_1((sc)->wb_bst, (sc)->wb_bsh, (off)) > + > +#define winbondwd_write_1(sc, off, val) \ > + bus_space_write_1((sc)->wb_bst, (sc)->wb_bsh, (off), (val)) > + > +/* > + * Enter Winbond Extended Functions State > + */ > +static __inline void > +winbondwd_config_enter(struct winbondwd_softc *sc) > +{ > + > + winbondwd_write_1(sc, 0, 0x87); > + winbondwd_write_1(sc, 0, 0x87); > +} > + > +/* > + * Leave Winbond Extended Functions State > + */ > +static __inline void > +winbondwd_config_leave(struct winbondwd_softc *sc) > +{ > + > + winbondwd_write_1(sc, 0, 0xaa); > +} > + > +static __inline unsigned char > +winbondwd_read_reg(struct winbondwd_softc *sc, unsigned char reg) > +{ > + > + winbondwd_write_1(sc, 0, reg); > + return (winbondwd_read_1(sc, 1)); > +} > + > +/* > + * Write specified extended function register > + */ > +static __inline void > +winbondwd_write_reg(struct winbondwd_softc *sc, unsigned char reg, unsigned char val) > +{ > + > + winbondwd_write_1(sc, 0, reg); > + winbondwd_write_1(sc, 1, val); > +} > + > +/* > + * Select the watchdog device (GPIO Port 2, Logical device 8) > + */ > +static void > +winbondwd_select(struct winbondwd_softc *sc) > +{ > + > + winbondwd_config_enter(sc); > + winbondwd_write_reg(sc, /* LDN bit 7:1 */ 0x7, /* GPIO Port 2 */ 0x8); > + winbondwd_write_reg(sc, /* CR30 */ 0x30, /* Activate */ 0x1); > +} > + > +/* > + * Deselect the watchdog device (only a config_leave is needed) > + */ > +static void > +winbondwd_deselect(struct winbondwd_softc *sc) > +{ > + > + winbondwd_config_leave(sc); > +} > + > +/* > + * Show timeout > + */ > +static void > +winbondwd_show_timeout(struct winbondwd_softc *sc) > +{ > + const char *mode_str; > + unsigned char timeout, mode; > + > + winbondwd_select(sc); > + timeout = winbondwd_read_reg(sc, 0xf6 /* Timeout CR */); > + if (timeout == 0) { > + sc->active = 0; > + if (bootverbose) > + device_printf(sc->device, > + "Winbond watchdog not running\n"); > + } else { > + sc->active = 1; > + mode = winbondwd_read_reg(sc, 0xf5 /* Bit 3: count mode */); > + mode_str = (mode & (1 << 2))? "minute" : "second"; > + device_printf(sc->device, > + "Winbond watchdog will timeout after %hhu %s%s\n", > + timeout, mode_str, ((timeout > 1)? "s" : "")); > + } > + winbondwd_deselect(sc); > +} > + > +/* > + * Set timeout in seconds; 0 = disable > + */ > +static void > +winbondwd_set_timeout(struct winbondwd_softc *sc, unsigned char timeout) > +{ > + unsigned char mode; > + > + /* Don't bother to disable if the watchdog is not running */ > + if (sc->active == 0 && timeout == 0) > + return; > + > + winbondwd_select(sc); > + mode = winbondwd_read_reg(sc, 0xf5 /* Bit 3: count mode */); > + mode &= ~(1 << 2); /* Choose seconds mode */ > + winbondwd_write_reg(sc, 0xf5, mode); > + > + winbondwd_write_reg(sc, 0xf6 /* Timeout CR */, timeout); > + winbondwd_deselect(sc); > + > + if (bootverbose) { > + if (timeout == 0) > + device_printf(sc->device, > + "Winbond watchdog disabled.\n"); > + else > + device_printf(sc->device, > + "Winbond watchdog timeout after %hhu seconds.\n", > + timeout); > + } > + > + sc->active = (timeout == 0) ? 0 : 1; > +} > + > +/* > + * Watchdog event handler - called by the framework to enable or disable > + * the watchdog or change the initial timeout value. > + */ > +static void > +winbondwd_event(void *arg, unsigned int cmd, int *error) > +{ > + struct winbondwd_softc *sc = arg; > + unsigned char rtimeout; > + uint64_t timeout; > + > + if (cmd == 0) > + winbondwd_set_timeout(sc, 0); > + else { > + timeout = (uint64_t)1 << (cmd & WD_INTERVAL); > + if (timeout < (uint64_t)0xff * 1000 * 1000 * 1000) { > + rtimeout = timeout / (1000 * 1000 * 1000); > + if (rtimeout == 0) > + rtimeout = 0xff; > + winbondwd_set_timeout(sc, rtimeout); > + } else { > + device_printf(sc->device, > + "Value %u too big, disabling\n", cmd & WD_INTERVAL); > + /* Proposed timeout can not be satisified */ > + winbondwd_set_timeout(sc, 0); > + } > + } > +} > + > +/* > + * A hack to probe Winbond chip's base port. > + */ > +static unsigned int > +winbondwd_baseport_probe(void) > +{ > + unsigned char val; > + int i; > + const unsigned int baseport_candidates[] = { 0x2e, 0x4e, 0 }; I also have a system with port 0x3f0. > + for (i = 0; baseport_candidates[i] != 0; i++) { > + /* > + * Enter config mode. > + * > + * Output magic number twice to the index register > + */ > + outb(baseport_candidates[i], 0x87); > + outb(baseport_candidates[i], 0x87); > + > + /* > + * I know this is ugly but I didn't found a way to do > + * this in a cleaner manner. > + */ > + /* Get data from CR 0x20 (Device ID) */ > + outb(baseport_candidates[i], 0x20); > + val = inb(baseport_candidates[i]+1); > + > + if (bootverbose) > + printf("winbondwd0: CR20 probing port 0x%x got 0x%x\n", baseport_candidates[i], val); > + > + if (val != 0xff) { > + outb(baseport_candidates[i], 0xaa); > + return baseport_candidates[i]; > + } > + } > + > + return (unsigned int)(-1); > +} > + > + > + > +/* > + * Look for Winbond device. > + */ > +static void > +winbondwd_identify(driver_t *driver, device_t parent) > +{ > + unsigned int baseport; > + device_t dev; > + > + if ((dev = device_find_child(parent, driver->name, 0)) == NULL) { > + if (resource_int_value("winbondwd", 0, "baseport", &baseport) != 0) { > + baseport = winbondwd_baseport_probe(); > + if (baseport == (unsigned int)(-1)) { > + printf("winbondwd0: Compatible Winbond Super I/O not found.\n"); > + return; > + } > + } > + > + dev = BUS_ADD_CHILD(parent, 0, driver->name, 0); > + > + bus_set_resource(dev, SYS_RES_IOPORT, 0, baseport, 2); > + } > + > + if (dev == NULL) > + return; These last two lines are redundant? Also, maybe I am confused, but I think that in ISA identify method you don't actually need to parse any hints/tunables. That is, you can use standard hints approach like e.g.: hint.winbondwd.0.at="isa" hint.winbondwd.0.port="0x3F0" and ISA will automatically add a winbondwd child with an I/O port resource at 0x3F0. The identify method should only add a child for a no-hints/auto-probing case. E.g. see boiler-plate code for the ISA case in share/examples/drivers/make_device_driver.sh, especially the comments. I am not saying that your approach won't work (apparently it does) or that it is inherently bad. It just seems to be different from how other ISA drivers do their identify+probe dance. > +} > + > +static int > +winbondwd_probe(device_t dev) > +{ > + > + /* Do not claim some ISA PnP device by accident. */ > + if (isa_get_logicalid(dev) != 0) > + return (ENXIO); > + return (0); > +} > + > +static int > +winbondwd_attach(device_t dev) > +{ > + struct winbondwd_softc *sc; > + unsigned int baseport; > + > + sc = device_get_softc(dev); > + sc->device = dev; > + > + if (resource_int_value("winbondwd", 0, "baseport", &baseport) != 0) { > + baseport = winbondwd_baseport_probe(); > + if (baseport == (unsigned int)(-1)) { > + device_printf(dev, > + "No compatible Winbond Super I/O found.\n"); > + return (ENXIO); > + } > + } > + > + /* allocate I/O register space */ > + sc->wb_rid = 0; > + sc->wb_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->wb_rid, > + baseport, baseport + 1, 2, RF_ACTIVE | RF_SHAREABLE); > + if (sc->wb_res == NULL) { > + device_printf(dev, "Unable to reserve Extended Function Registers\n"); > + goto fail; > + } > + sc->wb_bst = rman_get_bustag(sc->wb_res); > + sc->wb_bsh = rman_get_bushandle(sc->wb_res); > + > + /* Display the device status */ > + winbondwd_show_timeout(sc); > + > + /* register the watchdog event handler */ > + sc->ev_tag = EVENTHANDLER_REGISTER(watchdog_list, winbondwd_event, sc, 0); > + > + return (0); > + > +fail: > + if (sc->wb_res != NULL) > + bus_release_resource(dev, SYS_RES_IOPORT, > + sc->wb_rid, sc->wb_res); > + return (ENXIO); > +} > + > +static int > +winbondwd_detach(device_t dev) > +{ > + struct winbondwd_softc *sc; > + > + sc = device_get_softc(dev); > + > + /* deregister event handler */ > + if (sc->ev_tag != NULL) > + EVENTHANDLER_DEREGISTER(watchdog_list, sc->ev_tag); > + sc->ev_tag = NULL; > + > + /* Disable the watchdog */ > + if (sc->active) > + winbondwd_set_timeout(sc, 0); > + > + /* deallocate I/O register space */ > + bus_release_resource(dev, SYS_RES_IOPORT, sc->wb_rid, sc->wb_res); > + > + return (0); > +} > + > +static device_method_t winbondwd_methods[] = { > + DEVMETHOD(device_identify, winbondwd_identify), > + DEVMETHOD(device_probe, winbondwd_probe), > + DEVMETHOD(device_attach, winbondwd_attach), > + DEVMETHOD(device_detach, winbondwd_detach), > + DEVMETHOD(device_shutdown, winbondwd_detach), > + {0,0} > +}; > + > +static driver_t winbondwd_driver = { > + "winbondwd", > + winbondwd_methods, > + sizeof(struct winbondwd_softc), > +}; > + > +DRIVER_MODULE(winbondwd, isa, winbondwd_driver, winbondwd_devclass, NULL, NULL); > diff --git a/sys/dev/winbondwd/winbondwd.h b/sys/dev/winbondwd/winbondwd.h > new file mode 100644 > index 0000000..57a1a23 > --- /dev/null > +++ b/sys/dev/winbondwd/winbondwd.h > @@ -0,0 +1,47 @@ > +/*- > + * Copyright (c) 2010 iXsystems, Inc. > + * All rights reserved. > + * Written by: Xin LI > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + * > + * $FreeBSD$ > + */ > + > +#ifndef _WINBONDWD_H_ > +#define _WINBONDWD_H_ > + > +struct winbondwd_softc { > + device_t device; > + > + int active; > + unsigned int timeout; > + > + int wb_rid; > + struct resource *wb_res; > + bus_space_tag_t wb_bst; > + bus_space_handle_t wb_bsh; > + > + eventhandler_tag ev_tag; > +}; > + > +#endif /* _WINBONDWD_H_ */ > diff --git a/sys/i386/conf/NOTES b/sys/i386/conf/NOTES > index 866e641..80d82a2 100644 > --- a/sys/i386/conf/NOTES > +++ b/sys/i386/conf/NOTES > @@ -828,9 +828,11 @@ hint.pcf.0.irq="5" > # > # ichwd: Intel ICH watchdog timer > # amdsbwd: AMD SB7xx watchdog timer > +# winbondwd: Winbond watchdog timer > # > device ichwd > device amdsbwd > +device winbondwd > > # > # Temperature sensors: > diff --git a/sys/modules/Makefile b/sys/modules/Makefile > index 2dbc3d9..de533e4 100644 > --- a/sys/modules/Makefile > +++ b/sys/modules/Makefile > @@ -320,6 +320,7 @@ SUBDIR= ${_3dfx} \ > vx \ > wb \ > ${_wi} \ > + ${_winbondwd} \ > wlan \ > wlan_acl \ > wlan_amrr \ > @@ -469,6 +470,7 @@ _stg= stg > _streams= streams > _svr4= svr4 > _wi= wi > +_winbondwd= winbondwd > _xe= xe > .if ${MK_ZFS} != "no" || defined(ALL_MODULES) > _zfs= zfs > @@ -623,6 +625,7 @@ _twa= twa > _vesa= vesa > _x86bios= x86bios > _wi= wi > +_winbondwd= winbondwd > _wpi= wpi > _wpifw= wpifw > .if ${MK_ZFS} != "no" || defined(ALL_MODULES) > diff --git a/sys/modules/winbondwd/Makefile b/sys/modules/winbondwd/Makefile > new file mode 100644 > index 0000000..382d37f > --- /dev/null > +++ b/sys/modules/winbondwd/Makefile > @@ -0,0 +1,8 @@ > +# $FreeBSD$ > + > +.PATH: ${.CURDIR}/../../dev/winbondwd > + > +KMOD= winbondwd > +SRCS= winbondwd.c device_if.h bus_if.h pci_if.h isa_if.h > + > +.include I once wrote a similar driver, but of non-production quality for experimental purposes: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/40276/focus=40752 (btw, there are other interesting posts in that thread). And a litte bit of information just in case: many Winbond Super I/Os support several pins as possible "Watchdog Output" signal. One thing that I've noticed is that on some (admittedly consumer) systems they do connect one of those pins to the chipset reset input pin. But BIOS doesn't do any additional Super I/O configuration for watchdog to actually work. For example, sometimes they forget to configure the pin to actually serve as WDTO function. I had to hack in some additional configuration code for that. I intended to support configuration for all supported pins, but actually stopped after one pin that I really need. Also, just for fun, I also added some led(4) bits to control power indicator (it was also driven via Super I/O), but that was totally, well, just for fun. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:22:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C17D71065673; Wed, 29 Jun 2011 10:22:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 193618FC1C; Wed, 29 Jun 2011 10:22:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=3OyxrDLVq9sri6DuQhVzJBEiMCfYdL5zDZJFh5fE9Ak= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=z--MOQ7iQl0A:10 a=WQU8e4WWZSUA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=DKFexy3NOBZrKERJC80A:9 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 146574078; Wed, 29 Jun 2011 12:22:50 +0200 From: Hans Petter Selasky To: Robert Millan Date: Wed, 29 Jun 2011 12:21:06 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106242342.47194.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106291221.07049.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Warner Losh Subject: Re: [RFT] Automatic load of USB kernel modules 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, 29 Jun 2011 10:22:52 -0000 On Wednesday 29 June 2011 12:10:36 Robert Millan wrote: > 2011/6/24 Hans Petter Selasky : > > I would like to request testing of the attached > > patch before I commit it. The patch is about only having ukbd, ums and > > umass per default in the kernel GENERIC config file(s). > > What about urio? It is loaded automatically now. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:23:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3D1106568A; Wed, 29 Jun 2011 10:23:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 836C78FC15; Wed, 29 Jun 2011 10:23:25 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=EIZfbDsN8gr1c4B7uGrP4foh/gtfZ6zZRee2cLtKwTU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=z--MOQ7iQl0A:10 a=WQU8e4WWZSUA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=MSd9V3lNUkZ2ZQSsk04A:9 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 146782279; Wed, 29 Jun 2011 12:23:23 +0200 From: Hans Petter Selasky To: Robert Millan Date: Wed, 29 Jun 2011 12:21:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106242342.47194.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106291221.41580.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Warner Losh Subject: Re: [RFT] Automatic load of USB kernel modules 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, 29 Jun 2011 10:23:26 -0000 On Wednesday 29 June 2011 12:10:36 Robert Millan wrote: > 2011/6/24 Hans Petter Selasky : > > I would like to request testing of the attached > > patch before I commit it. The patch is about only having ukbd, ums and > > umass per default in the kernel GENERIC config file(s). > > What about urio? Hi, urio is not used for booting the kernel, so it is not important that it is in the kernel. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:33:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3ACD106566B for ; Wed, 29 Jun 2011 10:33:07 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 901C68FC0C for ; Wed, 29 Jun 2011 10:33:07 +0000 (UTC) Received: by pzk27 with SMTP id 27so1007910pzk.13 for ; Wed, 29 Jun 2011 03:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5MXFc4qQMRJk4hd3EVboJA6kAkJKmFY3+1gGeuMXE7Y=; b=xBsUfpfdsGufshJllef2lvYKQhBvc50rKOxP8idSaxWcZt2JA6zAty2GEKasydCXB4 3pvRfuwwrngXKCdDLQ8MWXCy248tA/eDuu3BfLT48MLX2qqf60cH+u7nRJYJimDDxNMC HUQTkkRDQSdL58dAYA3fNgOAmitpG3it2C1JE= MIME-Version: 1.0 Received: by 10.68.52.196 with SMTP id v4mr966418pbo.508.1309343586737; Wed, 29 Jun 2011 03:33:06 -0700 (PDT) Received: by 10.68.56.104 with HTTP; Wed, 29 Jun 2011 03:33:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jun 2011 14:33:06 +0400 Message-ID: From: KOT MATPOCKuH To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 29 Jun 2011 10:33:07 -0000 2011/6/29 KOT MATPOCKuH : >>> I'm got a problem with named on FreeBSD-CURRENT/sparc64. >>> Up to 5 times a day it crashes with these messages: >>> 27-Jun-2011 03:42:14.384 general: >>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: >>> REQUIRE(prev > 0) failed >>> 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) > >>> I found a some similar problems on alpha and IA64, which was related >>> to problems with isc_atomic_xadd() function in include/isc/atomic.h. >>> But I don't understand that there may be incorrect for sparc64 and >>> this function was not changed for a minimum 4 years... >> Uhm, we once fixed a problem in the MD atomic implementation which >> still seems to present in the ISC copy. Could you please test whether >> the following patch makes a difference? >> http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff > I ran named with your patch and and watching him. Omg. Or I incorrectly rebuilt named, or the problem is not solved. I got a crash after about 2 hours after named restarted: 29-Jun-2011 13:51:28.855 general: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: REQUIRE(prev > 0) failed 29-Jun-2011 13:51:28.856 general: exiting (due to assertion failure) -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:42:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46ECB106566B; Wed, 29 Jun 2011 10:42:57 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 809008FC13; Wed, 29 Jun 2011 10:42:56 +0000 (UTC) Received: by fxe6 with SMTP id 6so928002fxe.17 for ; Wed, 29 Jun 2011 03:42:55 -0700 (PDT) Received: by 10.223.21.7 with SMTP id h7mr1050795fab.72.1309344175533; Wed, 29 Jun 2011 03:42:55 -0700 (PDT) Received: from jessie.localnet (p5B2EC842.dip0.t-ipconnect.de [91.46.200.66]) by mx.google.com with ESMTPS id m6sm2770456fac.1.2011.06.29.03.42.54 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 03:42:54 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Stefan Esser Date: Wed, 29 Jun 2011 12:41:16 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4E099EB2.7050902@freebsd.org> <4E0AE815.2070502@freebsd.org> In-Reply-To: <4E0AE815.2070502@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106291241.17371.bschmidt@freebsd.org> Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:42:57 -0000 On Wednesday, June 29, 2011 10:53:41 Stefan Esser wrote: > Am 29.06.2011 10:03, schrieb Adrian Chadd: > > On 29 June 2011 14:03, Bernhard Schmidt wrote: > >> It's name is ieee80211_tx_mgt_timeout used to track AUTH/ASSOC > >> requests. Afaik there is even a similar PR about that. > > Sorry, I manually entered the panic message, since dumps were not > working on my system at the time of that panic. > > >> Adrian, you've got a AP set up to drop either a AUTH or ASSOC > >> response frame? > > I've got a number of AUTH -> SCAN transition lost messages for wlan0, > seconds to minutes apart: > > Jun 28 21:16:17 kernel: wlan0: ieee80211_new_state_locked: pending AUTH > -> SCAN transition lost > Jun 28 21:34:46 kernel: wlan0: ieee80211_new_state_locked: pending AUTH > -> SCAN transition lost > Jun 28 21:36:33 kernel: wlan0: ieee80211_new_state_locked: pending AUTH > -> SCAN transition lost > Jun 28 21:45:14 kernel: wlan0: ieee80211_new_state_locked: pending AUTH > -> SCAN transition lost > Jun 28 21:45:44 kernel: wlan0: ieee80211_new_state_locked: pending AUTH > -> SCAN transition lost > > The setup is easy to reproduce, my rc.conf contained: > > wlans_ath0="wlan0" > ifconfig_ath0="down" > ifconfig_wlan0="down" > wpa_supplicant_enable="YES" Strip the last 3 lines, don't ever fiddle around with ath0 directly. This configuration always starts wpa_supplicant. > This system used to be connected via ath0, but recently was moved to a > place where Ethernet is available. The panics started only after WLAN > was not used anymore. I might disable wpa_supplicant, since it is not > required in the current situation, but did not try whether that helps > prevent the panic. > > > Tell me how and I'll set it up. > > > > A panic at that point in the function indicates maybe ni is NULL? > > or ni->vap is now NULL, maybe? > > I recreated the panic, this time with kernel dumps correctly configured > (thanks for the hint, Scott). The panic message is: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffffff809c7a1000 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805e1851 > stack pointer = 0x28:0xffffff8000288ab0 > frame pointer = 0x28:0xffffff8000288b60 > 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 = 11 (swi4: clock) > > Traceback: > > #10 0xffffffff805e1851 in ieee80211_tx_mgt_timeout (arg=0xffffff809c7a1000) > at ../../../net80211/ieee80211_output.c:2487 > > This indicates, that an invalid argument is passed and assigned to > "*ni", which causes the page fault when dereferencing "ni" to obtain "*va". The problem here seems to be wpa_supplicant. It can try to associate at any given point in time which results in the BSS ni being destroyed, though it might still be referenced somewhere (In this case the timeout stuff, or better said ath's TX queue). Not clearing the reference (or stopping whatever is using it) is the fault here. Now how to figure out who the caller is? Got the complete backtrace? -- Bernhard From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 11:06:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBE1D106566C; Wed, 29 Jun 2011 11:06:41 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id A45978FC1B; Wed, 29 Jun 2011 11:06:41 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id AA7852B481; Wed, 29 Jun 2011 12:46:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id eDjI16OhwXid; Wed, 29 Jun 2011 12:46:50 +0200 (CEST) Received: from danger-mbp.local (bband-dyn13.95-103-249.t-com.sk [95.103.249.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 5A8EB2B473; Wed, 29 Jun 2011 12:46:50 +0200 (CEST) Message-ID: <4E0B0299.2020205@FreeBSD.org> Date: Wed, 29 Jun 2011 12:46:49 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.19pre) Gecko/20110620 Lanikai/3.1.11pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: Call for FreeBSD Status Reports - 2Q/2011 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, 29 Jun 2011 11:06:42 -0000 Dear all, I would like to remind you that the next round of status reports covering the second quarter of 2011 is due on July 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 11:09:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AECA1065673 for ; Wed, 29 Jun 2011 11:09:48 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by mx1.freebsd.org (Postfix) with SMTP id F276A8FC1F for ; Wed, 29 Jun 2011 11:09:47 +0000 (UTC) Received: from [98.139.212.153] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jun 2011 10:57:18 -0000 Received: from [98.139.211.200] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 29 Jun 2011 10:57:18 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 29 Jun 2011 10:57:18 -0000 X-Yahoo-Newman-Id: 607633.19837.bm@smtp209.mail.bf1.yahoo.com Received: from [192.168.119.20] (se@81.173.144.90 with plain) by smtp209.mail.bf1.yahoo.com with SMTP; 29 Jun 2011 03:57:18 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: I5d.GDIVM1k65EH9rZKcmLymzivVWcYWu1hWBWt8Z7qnjVj tVxCOeEsKmQVjUoy0W1bavxCjbGVVBFrCoVwCnBiOH_f_pLforymz4Y3ExbX xyRT62UEs.nmtzIuH7ILWazcFVrhzCk10aaWvDHtevaTFh3D__behkIdpzoy 5bzWuaah0hvydd02eeyIv.CrhnfkoCztxJv6tx5ZbgsXGAVYNv8KbglLm4O3 iVkgx35NceUgcAdhAwVyiGytxBb57Vvo8jWQOQTvu34Oxi5JE51Q84dkP3in texMUZ4JihhMW2BbgJvP8r67Npp9HtpSeA84IUUqcMkcdLroXlYhmQ4qkKTd B4Y26G8BhOeSuRPmY6_DMx1dgG871fIloaO3R_wU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E0B050D.6090408@freebsd.org> Date: Wed, 29 Jun 2011 12:57:17 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: bschmidt@freebsd.org References: <4E099EB2.7050902@freebsd.org> <4E0AE815.2070502@freebsd.org> <201106291241.17371.bschmidt@freebsd.org> In-Reply-To: <201106291241.17371.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org Subject: Re: Panic in ieee80211 tx mgmt timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 11:09:48 -0000 Am 29.06.2011 12:41, schrieb Bernhard Schmidt: > On Wednesday, June 29, 2011 10:53:41 Stefan Esser wrote: >> I recreated the panic, this time with kernel dumps correctly configured >> (thanks for the hint, Scott). The panic message is: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0xffffff809c7a1000 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805e1851 >> stack pointer = 0x28:0xffffff8000288ab0 >> frame pointer = 0x28:0xffffff8000288b60 >> 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 = 11 (swi4: clock) >> >> Traceback: >> >> #10 0xffffffff805e1851 in ieee80211_tx_mgt_timeout (arg=0xffffff809c7a1000) >> at ../../../net80211/ieee80211_output.c:2487 >> >> This indicates, that an invalid argument is passed and assigned to >> "*ni", which causes the page fault when dereferencing "ni" to obtain "*va". > > The problem here seems to be wpa_supplicant. It can try to associate > at any given point in time which results in the BSS ni being destroyed, > though it might still be referenced somewhere (In this case the timeout > stuff, or better said ath's TX queue). Not clearing the reference (or > stopping whatever is using it) is the fault here. Now how to figure out > who the caller is? Got the complete backtrace? Not sure that I understand your question correctly ... #10 0xffffffff805e1851 in ieee80211_tx_mgt_timeout (arg=0xffffff809c7a1000) at ../../../net80211/ieee80211_output.c:2487 #11 0xffffffff8050f45c in softclock (arg=Variable "arg" is not available.) at ../../../kern/kern_timeout.c:564 #12 0xffffffff804d9876 in intr_event_execute_handlers (p=Variable "p" is not available.) at ../../../kern/kern_intr.c:1257 #13 0xffffffff804da4d6 in ithread_loop (arg=0xfffffe00032dcc60) at ../../../kern/kern_intr.c:1270 #14 0xffffffff804d718d in fork_exit (callout=0xffffffff804da440 , arg=0xfffffe00032dcc60, frame=0xffffff8000288c50) at ../../../kern/kern_fork.c:920 #15 0xffffffff807258ce in fork_trampoline () at ../../../amd64/amd64/exception.S:603 Bernhard, I'm sending you the compressed "core.txt" in private mail. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:10:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1494106566C; Wed, 29 Jun 2011 10:10:39 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C69A08FC20; Wed, 29 Jun 2011 10:10:37 +0000 (UTC) Received: by pzk27 with SMTP id 27so992473pzk.13 for ; Wed, 29 Jun 2011 03:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=97MydsNsjnhF0hxHB8ksqW6vIunLItirzZZcG2JmfuQ=; b=LThEYbr6bjsAX4Pk2k5IRpI0+lbGdJbiWD1wP2dnXFvB63FU5eP4LRdJpzRW+jZzo5 vJZzJzOn2ucSv1yKGpvjBav/KBToFOHcSCt+TnFaA/HDQtMUxd8QSrw/vzgupFyCw1sL BN14LU9d6BC6MSR7gh/zucMte4ltH/dGGTzyA= MIME-Version: 1.0 Received: by 10.68.13.68 with SMTP id f4mr805050pbc.404.1309342236837; Wed, 29 Jun 2011 03:10:36 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.68.47.138 with HTTP; Wed, 29 Jun 2011 03:10:36 -0700 (PDT) In-Reply-To: <201106242342.47194.hselasky@c2i.net> References: <201106242342.47194.hselasky@c2i.net> Date: Wed, 29 Jun 2011 12:10:36 +0200 X-Google-Sender-Auth: ejo7DP4boo_SJzpOvKKqstG0sqo Message-ID: From: Robert Millan To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 29 Jun 2011 11:10:04 +0000 Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Warner Losh Subject: Re: [RFT] Automatic load of USB kernel modules 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, 29 Jun 2011 10:10:40 -0000 2011/6/24 Hans Petter Selasky : > I would like to request testing of the attached > patch before I commit it. The patch is about only having ukbd, ums and umass > per default in the kernel GENERIC config file(s). What about urio? -- Robert Millan From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 10:29:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9237106566B; Wed, 29 Jun 2011 10:29:43 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5AA8FC14; Wed, 29 Jun 2011 10:29:43 +0000 (UTC) Received: by pwi7 with SMTP id 7so1039297pwi.13 for ; Wed, 29 Jun 2011 03:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HZN/aDwSkzlzpTAKrFNCSHMgIXocI5rFxbOOD2mFUQQ=; b=TLFgTFpwNwzf3UdyAe5EIWvNBZocp2pgHucYIB7OI8n06tG99W6m1z0PdqJRCFeKqR Elr9F0aHPSjpsw5/4jGVZc02o54DIOSk2DwkKEEq9kx1nD0laBQebDRLjlUUbeGBLBUP SQKCJq62AJqxxYCMqu1GbRG8jggnWBAJdCgaM= MIME-Version: 1.0 Received: by 10.68.13.68 with SMTP id f4mr824389pbc.404.1309343383131; Wed, 29 Jun 2011 03:29:43 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.68.47.138 with HTTP; Wed, 29 Jun 2011 03:29:43 -0700 (PDT) In-Reply-To: <201106291221.41580.hselasky@c2i.net> References: <201106242342.47194.hselasky@c2i.net> <201106291221.41580.hselasky@c2i.net> Date: Wed, 29 Jun 2011 12:29:43 +0200 X-Google-Sender-Auth: iWJcG6wrYiibAyK7LJ-2SDz_Jd4 Message-ID: From: Robert Millan To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 29 Jun 2011 11:10:14 +0000 Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Warner Losh Subject: Re: [RFT] Automatic load of USB kernel modules 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, 29 Jun 2011 10:29:43 -0000 2011/6/29 Hans Petter Selasky : >> What about urio? > > Hi, > > urio is not used for booting the kernel, so it is not important that it is in > the kernel. Ah, ok. I thought /dev/urio0 was a block device. -- Robert Millan From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 12:20:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8984B106564A; Wed, 29 Jun 2011 12:20:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 604198FC15; Wed, 29 Jun 2011 12:20:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0F0D946B1A; Wed, 29 Jun 2011 08:20:46 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 90BE08A01F; Wed, 29 Jun 2011 08:20:45 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 29 Jun 2011 08:11:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E0A5689.2020302@delphij.net> <4E0AEED2.7060702@FreeBSD.org> In-Reply-To: <4E0AEED2.7060702@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106290811.34443.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 29 Jun 2011 08:20:45 -0400 (EDT) Cc: Xin LI , d@delphij.net, Andriy Gapon Subject: Re: [RFC] winbond watchdog driver for FreeBSD/i386 and FreeBSD/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: Wed, 29 Jun 2011 12:20:46 -0000 On Wednesday, June 29, 2011 5:22:26 am Andriy Gapon wrote: > on 29/06/2011 01:32 Xin LI said the following: > > +/* > > + * Look for Winbond device. > > + */ > > +static void > > +winbondwd_identify(driver_t *driver, device_t parent) > > +{ > > + unsigned int baseport; > > + device_t dev; > > + > > + if ((dev = device_find_child(parent, driver->name, 0)) == NULL) { > > + if (resource_int_value("winbondwd", 0, "baseport", &baseport) != 0) { > > + baseport = winbondwd_baseport_probe(); > > + if (baseport == (unsigned int)(-1)) { > > + printf("winbondwd0: Compatible Winbond Super I/O not found.\n"); > > + return; > > + } > > + } > > + > > + dev = BUS_ADD_CHILD(parent, 0, driver->name, 0); > > + > > + bus_set_resource(dev, SYS_RES_IOPORT, 0, baseport, 2); > > + } > > + > > + if (dev == NULL) > > + return; > > These last two lines are redundant? > > Also, maybe I am confused, but I think that in ISA identify method you don't > actually need to parse any hints/tunables. That is, you can use standard hints > approach like e.g.: > hint.winbondwd.0.at="isa" > hint.winbondwd.0.port="0x3F0" > and ISA will automatically add a winbondwd child with an I/O port resource at > 0x3F0. The identify method should only add a child for a no-hints/auto-probing > case. > E.g. see boiler-plate code for the ISA case in > share/examples/drivers/make_device_driver.sh, especially the comments. > > I am not saying that your approach won't work (apparently it does) or that it is > inherently bad. It just seems to be different from how other ISA drivers do > their identify+probe dance. I agree, it should probably look something like this: { if (device_find_child(parent, driver->name, 0) != NULL) return; if (resource_int_value(driver->name, 0, "port", &baseport) == 0) return; baseport = winbondwd_baseport_probe(); if (baseport == -1) /* No reason to warn on every boot here. */ return; dev = BUS_ADD_CHILD(parent, 0, driver->name, 0); if (dev != NULL) bus_set_resource(dev, SYS_RES_IOPORT, 0, baseport, 2); } > > + sc->wb_bst = rman_get_bustag(sc->wb_res); > > + sc->wb_bsh = rman_get_bushandle(sc->wb_res); Please don't use these. bus_read_X(sc->wb_wres) is easier on the eyes. One other comment, several places in the code are using various magic numbers for register offsets, bit field values, etc. For example: + winbondwd_write_reg(sc, /* LDN bit 7:1 */ 0x7, /* GPIO Port 2 */ 0x8); + winbondwd_write_reg(sc, /* CR30 */ 0x30, /* Activate */ 0x1); Could you add a winbondwdreg.h header and define constants for the registers and their bitfields instead? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 13:08:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DC2106564A for ; Wed, 29 Jun 2011 13:08:07 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 014148FC16 for ; Wed, 29 Jun 2011 13:08:06 +0000 (UTC) Received: by pvg11 with SMTP id 11so1070853pvg.13 for ; Wed, 29 Jun 2011 06:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=x2+yk1k3yl2sdT70QqZP5+G7Xs262cyID9qRi0EaqY8=; b=lF7YOz9YAcm/ygCt4Z55oDgxx5iF9Iwmin3O0vm+S4SS41WSqTpCmvwxqna+jg/0LL hBM+dBS0/Sj/835rhXDDjCz7V1FxJNc//EUaTBcj5VsP/VgAlUXrq7oi4meXam415a+P gQX0go2mQRCrbQvclHh3OFpIU+/GLvsF7vJEA= MIME-Version: 1.0 Received: by 10.142.61.3 with SMTP id j3mr429876wfa.102.1309351412386; Wed, 29 Jun 2011 05:43:32 -0700 (PDT) Received: by 10.142.239.4 with HTTP; Wed, 29 Jun 2011 05:43:32 -0700 (PDT) Date: Wed, 29 Jun 2011 14:43:32 +0200 Message-ID: From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: a question about message 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, 29 Jun 2011 13:08:07 -0000 Hi, I've got message from ifa_del_loopback_route() called from rip_ctlinput(). Is IFA_RTSELF flag consistent with ifa_add_loopback_route() and ifa_del_loopback_route() calls? I think that rip_ctlinput() in sys/netinet/raw_ip.c should be patched to do a check that IFA_RTSELF flag is set before ifa_del_loopback_route() is called. The proposed check is done in in_scrubprefix() in sys/netinet/in.c. Or exists some reason that it is not a good idea? I've got the message as nobody calls ifa_add_loopback_route() before ifa_del_loopback_route(). Svata From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 13:09:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12C7106566B; Wed, 29 Jun 2011 13:09:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 482CA8FC12; Wed, 29 Jun 2011 13:09:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAIojC06DaFvO/2dsb2JhbABShEmkCIh4rxqRDIErg3mBDASSF5BG X-IronPort-AV: E=Sophos;i="4.65,443,1304308800"; d="scan'208";a="125531462" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2011 09:09:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 58089B3F33; Wed, 29 Jun 2011 09:09:42 -0400 (EDT) Date: Wed, 29 Jun 2011 09:09:42 -0400 (EDT) From: Rick Macklem To: Grzegorz Bernacki Message-ID: <1483355723.51315.1309352982344.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4E0AD226.6080107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: NFS/BOOTP problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 13:09:43 -0000 > > Hi Rick, > > The problem is that in embedded development sometimes loader is not > used. And in that case we would like to have possibity to use old NFS > client without patching code every time. So if you don't mind I would > like to commit the patch. > I also will try new nfs client and let you know if I find any > problems. > Ok, sure. (I actually had something similar in the code when I was testing the diskless stuff, but took it out once I saw that the environment variable worked. However I didn't realize that some situations don't use the loader.) rick From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 13:15:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37A41106564A; Wed, 29 Jun 2011 13:15:14 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 957E48FC1C; Wed, 29 Jun 2011 13:15:13 +0000 (UTC) Received: by bwa20 with SMTP id 20so1460987bwa.13 for ; Wed, 29 Jun 2011 06:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.140.18 with SMTP id g18mr712530bku.59.1309351815400; Wed, 29 Jun 2011 05:50:15 -0700 (PDT) Sender: antony@mawer.org X-Google-Sender-Delegation: antony@mawer.org Received: by 10.204.57.137 with HTTP; Wed, 29 Jun 2011 05:50:15 -0700 (PDT) Date: Wed, 29 Jun 2011 22:50:15 +1000 X-Google-Sender-Auth: BV-JcN5RQ9IG7Cw491aYkJLQVv0 Message-ID: From: Antony Mawer To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: kern/143370: splash_txt ASCII splash screen module 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, 29 Jun 2011 13:15:14 -0000 Hi all, Not sure if this is the right place to post it -- about 6 years ago I put together a module which displays an ASCII splash screen on boot (rather than the graphical splash_pcx and splash_bmp modules). We have been running it in production since that time without issue. With the the code slush for 9.0 on the horizon, I thought it might again be worth trying to see if someone is prepared to get this into the tree so others can benefit from it. I have a PR open, kern/143370, which includes the patch for the module; it is against 7.0 but has been used largely unmodified since 4.x days. It currently builds on 8.x still fine as we are running it in production on 8.x for $WORK. Summary of instructions from my previous post about this from ~18mths ago: In case the list eats the patch, you can grab a copy of it here: http://www.mawer.org/freebsd/splash_txt.patch To give you an idea of what it looks like, here is a screenshot of a quick generic FreeBSD splash screen I put together: http://www.mawer.org/freebsd/splash_txt_1.png http://www.mawer.org/freebsd/splash_txt_2.png If you'd like to try it for yourself then the process to build it should be something like this: 1. Download the attached patch 2. Create the required folders before applying the patch -- cd /usr/src && mkdir sys/modules/splash/txt 3. Apply the patch -- patch < splash_txt.patch 4. Build the module -- cd sys/modules/splash/txt && make && make install Once that's completed, you can configure it by adding the following to loader.conf: splash_txt_load="YES" bitmap_load="YES" bitmap_name="/boot/freebsd.bin" I have uploaded two sample boot splash screens at http://www.mawer.org/freebsd/freebsd1.bin and http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced using TheDraw and saving in its Binary file format, which consists of a sequence of 2 byte pairs. The first byte in a pair is the character to draw on the screen, and the second is the colour/display attributes to draw the character with. If anyone else would like to try this out and has any feedback, or if someone thinks it may be of interest to integrate into the tree please let me know ... Otherwise if anyone would like to help push this into the tree in time for 9.0 would be great. It should be safe to MFC to 8.x as well -- as I said we've been running it ever since 4.x days. I am sure others out there would gain at least some (cosmetic) benefits from this! -- Antony From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 13:41:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12500106564A for ; Wed, 29 Jun 2011 13:41:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9F15D8FC13 for ; Wed, 29 Jun 2011 13:41:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p5TDfeVW039561; Wed, 29 Jun 2011 15:41:40 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5TDfeaW039560; Wed, 29 Jun 2011 15:41:40 +0200 (CEST) (envelope-from marius) Date: Wed, 29 Jun 2011 15:41:40 +0200 From: Marius Strobl To: KOT MATPOCKuH , dougb@freebsd.org Message-ID: <20110629134140.GF14797@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 29 Jun 2011 13:41:43 -0000 On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote: > 2011/6/29 KOT MATPOCKuH : > >>> I'm got a problem with named on FreeBSD-CURRENT/sparc64. > >>> Up to 5 times a day it crashes with these messages: > >>> 27-Jun-2011 03:42:14.384 general: > >>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: > >>> REQUIRE(prev > 0) failed > >>> 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) > > > >>> I found a some similar problems on alpha and IA64, which was related > >>> to problems with isc_atomic_xadd() function in include/isc/atomic.h. > >>> But I don't understand that there may be incorrect for sparc64 and > >>> this function was not changed for a minimum 4 years... > >> Uhm, we once fixed a problem in the MD atomic implementation which > >> still seems to present in the ISC copy. Could you please test whether > >> the following patch makes a difference? > >> http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff > > > I ran named with your patch and and watching him. > Omg. > Or I incorrectly rebuilt named, or the problem is not solved. > I got a crash after about 2 hours after named restarted: > 29-Jun-2011 13:51:28.855 general: > /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: > REQUIRE(prev > 0) failed > 29-Jun-2011 13:51:28.856 general: exiting (due to assertion failure) > The remainder of the isc atomic.h looks fine though, so this likely is a general bug in BIND, especially if it didn't happen before BIND 9.6.-ESV-R4-P1. Doug should be able to help you. Doug, could you please nevertheless take care of getting the above patch into BIND? It's a merge of r148453. Marius From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 20:46:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 6D0941065674 for ; Wed, 29 Jun 2011 20:46:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B8B761A71F7; Wed, 29 Jun 2011 20:46:29 +0000 (UTC) Message-ID: <4E0B8F25.7090107@FreeBSD.org> Date: Wed, 29 Jun 2011 13:46:29 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Marius Strobl References: <20110629134140.GF14797@alchemy.franken.de> In-Reply-To: <20110629134140.GF14797@alchemy.franken.de> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KOT MATPOCKuH , FreeBSD Current Subject: Re: named crashes on assertion in rbtdb.c on sparc64/SMP 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, 29 Jun 2011 20:46:30 -0000 On 06/29/2011 06:41, Marius Strobl wrote: > On Wed, Jun 29, 2011 at 02:33:06PM +0400, KOT MATPOCKuH wrote: >> 2011/6/29 KOT MATPOCKuH: >>>>> I'm got a problem with named on FreeBSD-CURRENT/sparc64. >>>>> Up to 5 times a day it crashes with these messages: >>>>> 27-Jun-2011 03:42:14.384 general: >>>>> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: >>>>> REQUIRE(prev> 0) failed >>>>> 27-Jun-2011 03:42:14.385 general: exiting (due to assertion failure) >>> >>>>> I found a some similar problems on alpha and IA64, which was related >>>>> to problems with isc_atomic_xadd() function in include/isc/atomic.h. >>>>> But I don't understand that there may be incorrect for sparc64 and >>>>> this function was not changed for a minimum 4 years... >>>> Uhm, we once fixed a problem in the MD atomic implementation which >>>> still seems to present in the ISC copy. Could you please test whether >>>> the following patch makes a difference? >>>> http://people.freebsd.org/~marius/sparc64_isc_atomic.h.diff >> >>> I ran named with your patch and and watching him. >> Omg. >> Or I incorrectly rebuilt named, or the problem is not solved. >> I got a crash after about 2 hours after named restarted: >> 29-Jun-2011 13:51:28.855 general: >> /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/rbtdb.c:1614: >> REQUIRE(prev> 0) failed >> 29-Jun-2011 13:51:28.856 general: exiting (due to assertion failure) >> > > The remainder of the isc atomic.h looks fine though, so this likely > is a general bug in BIND, especially if it didn't happen before > BIND 9.6.-ESV-R4-P1. Doug should be able to help you. > Doug, could you please nevertheless take care of getting the above > patch into BIND? It's a merge of r148453. Hmm, I thought I had already pushed that rock up the appropriate hill, but maybe not. I've been following this thread, but it's incredibly unlikely that I'll be able to do anything useful with it until Friday. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 21:09:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDD90106564A; Wed, 29 Jun 2011 21:09:49 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD018FC14; Wed, 29 Jun 2011 21:09:49 +0000 (UTC) Received: by fxe6 with SMTP id 6so1404302fxe.17 for ; Wed, 29 Jun 2011 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OHK51Y9+QWQYn1tnVPuIyuV+zdAvjZoaM+IbJ+pYYNc=; b=xOX5EqG8wRMjpp8DGWJwl8TNZGXzdEAfproEW3Isd98+DHGmHwTVk9QHtZ4k4K1RmH JXAIGfRA9nALxDInPrPtNhd9hN+jSNQQArbif1K2rXfdnoP0Sox9t+6bnWVR6fKL9wK/ FP9BZsEgloK329eDDhEgTyKJUllZ+LbNzskFQ= Received: by 10.223.16.136 with SMTP id o8mr1836295faa.21.1309379775728; Wed, 29 Jun 2011 13:36:15 -0700 (PDT) Received: from limbo.lan ([195.225.157.86]) by mx.google.com with ESMTPS id q14sm1116343faa.3.2011.06.29.13.36.13 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 13:36:14 -0700 (PDT) Message-ID: <4E0B8CBC.8080601@gmail.com> Date: Wed, 29 Jun 2011 23:36:12 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.9.2.18) Gecko/20110622 Thunderbird/3.1.11 MIME-Version: 1.0 To: obrien@freebsd.org, freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> In-Reply-To: <20110623163109.GA508@dragon.NUXI.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 29 Jun 2011 21:09:50 -0000 23.06.2011 19:31, David O'Brien wrote: > Does anyone object to this patch? > > David Wolfskill and I have run TMPFS on a number of machines for two > years with no problems. > > I may have missed something, but I'm not aware of any serious PRs on > TMPFS either. > Maybe i'm missing something but creating/removing large number of files in one directory on tmpfs was very slow for me. That was long ago and ZFS was in so i'll try to retest... -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 21:50:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B26141065677 for ; Wed, 29 Jun 2011 21:50:07 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 064688FC0C for ; Wed, 29 Jun 2011 21:50:02 +0000 (UTC) Received: by iyb11 with SMTP id 11so1951863iyb.13 for ; Wed, 29 Jun 2011 14:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=jlxvYmaymh8sGynK2tT3gh0sAiXgpONLohP1OQ6Jr9k=; b=q18KnkgSmrn/9julZGTlZJbDHQ3ngNgpjPjvh9pnuolU9wf4sU3xa142ajYVJ4N+3o WIM8VsBxRYcl8NuPuWNb8Je6sQVRnVxTw+MgN/HRdiXaS0Sh1j5zaMQMml8qT6ZVm9wm rEsXgBieVQUuZ6fM9TQUx8xO4uq+esIedwuJM= Received: by 10.42.240.69 with SMTP id kz5mr1191897icb.263.1309384201896; Wed, 29 Jun 2011 14:50:01 -0700 (PDT) Received: from sidhe.local (adsl-67-118-230-86.dsl.pltn13.pacbell.net [67.118.230.86]) by mx.google.com with ESMTPS id hp8sm1417266icc.23.2011.06.29.14.49.59 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 14:50:00 -0700 (PDT) Message-ID: <4E0B9E08.1090202@gmail.com> Date: Wed, 29 Jun 2011 14:50:00 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Time keeping Issues with the low-resolution TSC timecounter 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, 29 Jun 2011 21:50:07 -0000 On 06/23/11 08:25, Jung-uk Kim wrote: > On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote: >> Jung-uk Kim wrote: >>> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: >>>> Can you please try the attached patch? It should disable >>>> TSC/TSC-low timecounter for your CPU models, I think. >>> Sorry, I attached a wrong patch. Please ignore the previous one >>> and try this, instead. >> TSC-low is not presented as an option any more: >> >> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class >> CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c >> Stepping = 2 >> Features=0xbfe9fbff> R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >> Features2=0x40c39d> OVBE> AMD Features2=0x1 >> TSC: P-state invariant, performance statistics >> >> Event timer "LAPIC" quality 400 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0:<24-bit timer at 3.579545MHz> port 0x408-0x40b on >> acpi0 atrtc0: port 0x70-0x77 on acpi0 >> atrtc0: Warning: Couldn't map I/O. >> Event timer "RTC" frequency 32768 Hz quality 0 >> hpet0: iomem 0xfed00000-0xfed003ff irq >> 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 450 >> Event timer "HPET1" frequency 14318180 Hz quality 440 >> Event timer "HPET2" frequency 14318180 Hz quality 440 >> attimer0: port 0x40-0x43,0x50-0x53 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> >> kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) >> ACPI-fast(900) dummy(-1000000) > It's already committed (r223426). > > Thanks! > > Jung-uk Kim > _______________________________________________ > 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" > > I had been holding off on csup on this machine for a moment: Machine: Thinkpad SL410 Core2Duo T6570 I rm -rf /usr/src& csup'd sources yesterday. Issues still exist with TSC-low on Intel laptop hardware. Quality was set to 1000, but time was inaccurate. Felt like 300 baud serial console over a very long link! I have C2& powerd: /etc/sysctl.conf: ... # Save electricity& thermal hw.pci.do_power_nodriver=3 hw.acpi.cpu.cx_lowest=C2 dev.cpu.1.cx_lowest=C2 dev.cpu.0.cx_lowest=C2 ... /etc/rc.conf: ... #power powerd_enable="YES" powerd_flags="-b adaptive -a maximum" ... I'm getting as far as /usr/src/sys/x86/x86: ... if (smp_cpus> 1) { tsc_timecounter.tc_quality = test_smp_tsc(); max_freq>>= 8; ... test_smp_tsc() returns 1000, allowing TSC-slow to "win". Forcing this to 50 fixed all time/speed issues, allowing HPET to "win". I think the test for C3 above that may need to include additional machines under its protection! I have no C3 support, but it's clear that issues are occuring with TSC clocks even in C2 on intel platforms. Matt From owner-freebsd-current@FreeBSD.ORG Wed Jun 29 22:55:25 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 00377106566C; Wed, 29 Jun 2011 22:55:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 29 Jun 2011 18:55:09 -0400 User-Agent: KMail/1.6.2 References: <4E0B9E08.1090202@gmail.com> In-Reply-To: <4E0B9E08.1090202@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106291855.13710.jkim@FreeBSD.org> Cc: Matt Subject: Re: Time keeping Issues with the low-resolution TSC timecounter 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, 29 Jun 2011 22:55:25 -0000 On Wednesday 29 June 2011 05:50 pm, Matt wrote: > On 06/23/11 08:25, Jung-uk Kim wrote: > > On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote: > >> Jung-uk Kim wrote: > >>> On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: > >>>> Can you please try the attached patch? It should disable > >>>> TSC/TSC-low timecounter for your CPU models, I think. > >>> > >>> Sorry, I attached a wrong patch. Please ignore the previous > >>> one and try this, instead. > >> > >> TSC-low is not presented as an option any more: > >> > >> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz > >> 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 > >> Model = 1c Stepping = 2 > >> > >> Features=0xbfe9fbff >>MTR > >> R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > >>PBE> > >> Features2=0x40c39d >>M,M OVBE> AMD Features2=0x1 > >> TSC: P-state invariant, performance statistics > >> > >> Event timer "LAPIC" quality 400 > >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > >> acpi_timer0:<24-bit timer at 3.579545MHz> port 0x408-0x40b on > >> acpi0 atrtc0: port 0x70-0x77 on acpi0 > >> atrtc0: Warning: Couldn't map I/O. > >> Event timer "RTC" frequency 32768 Hz quality 0 > >> hpet0: iomem > >> 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" > >> frequency 14318180 Hz quality 950 Event timer "HPET" frequency > >> 14318180 Hz quality 450 > >> Event timer "HPET1" frequency 14318180 Hz quality 440 > >> Event timer "HPET2" frequency 14318180 Hz quality 440 > >> attimer0: port 0x40-0x43,0x50-0x53 on acpi0 > >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> Event timer "i8254" frequency 1193182 Hz quality 100 > >> > >> kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) > >> ACPI-fast(900) dummy(-1000000) > > > > It's already committed (r223426). > > > > Thanks! > > > > Jung-uk Kim > > _______________________________________________ > > 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" > > I had been holding off on csup on this machine for a moment: > Machine: Thinkpad SL410 Core2Duo T6570 > I rm -rf /usr/src& csup'd sources yesterday. > > Issues still exist with TSC-low on Intel laptop hardware. Quality > was set to 1000, but time was inaccurate. Felt like 300 baud serial > console over a very long link! > > I have C2& powerd: > > /etc/sysctl.conf: > ... > # Save electricity& thermal > hw.pci.do_power_nodriver=3 This betther be set from /boot/loader.conf. > hw.acpi.cpu.cx_lowest=C2 > dev.cpu.1.cx_lowest=C2 > dev.cpu.0.cx_lowest=C2 There is no reason to do this here. Just add a line in /etc/rc.conf: economy_cx_lowest="C2" > ... > > /etc/rc.conf: > ... > #power > powerd_enable="YES" > powerd_flags="-b adaptive -a maximum" > ... > > I'm getting as far as > /usr/src/sys/x86/x86: > ... > if (smp_cpus> 1) { > tsc_timecounter.tc_quality = test_smp_tsc(); > max_freq>>= 8; > ... > > test_smp_tsc() returns 1000, allowing TSC-slow to "win". > Forcing this to 50 fixed all time/speed issues, allowing HPET to > "win". > > I think the test for C3 above that may need to include additional > machines under its protection! I have no C3 support, but it's clear > that issues are occuring with TSC clocks even in C2 on intel > platforms. Hmm... That's strange. Can you show me verbose dmesg output? Also, I'd like to see 'acpidump -dt' output. Sorry about the trouble. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 09:24:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5FE9106566B for ; Thu, 30 Jun 2011 09:24:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 32C9E8FC1E for ; Thu, 30 Jun 2011 09:24:21 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=3OyxrDLVq9sri6DuQhVzJBEiMCfYdL5zDZJFh5fE9Ak= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=WQU8e4WWZSUA:10 a=kj9zAlcOel0A:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=uW40wIcy7NoaaMJ7YNYA:9 a=fgOpgn9iLWncQRrZiasA:7 a=CjuIK1q_8ugA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 147062368 for freebsd-current@freebsd.org; Thu, 30 Jun 2011 11:24:19 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 30 Jun 2011 11:22:36 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106301122.36155.hselasky@c2i.net> Subject: Crossbuild failure on 8-stable 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, 30 Jun 2011 09:24:22 -0000 Hi, Trying to cross build ARM fails in the following way on 8-stable: 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 make toolchain TARGET=arm Is this perhaps also an issue in 9-current? Any clues? cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float - D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - I/usr/src/lib/libstand/../libz -std=gnu99 -c /usr/src/lib/libstand/../libc/net/ntoh.c {standard input}: Assembler messages: {standard input}:27: Error: bad instruction `bswap r0' {standard input}:53: Error: bad instruction `bswap r0' --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 10:44:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F8C1065674 for ; Thu, 30 Jun 2011 10:44:51 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f287.mail.ru (f287.mail.ru [217.69.128.254]) by mx1.freebsd.org (Postfix) with ESMTP id B25208FC08 for ; Thu, 30 Jun 2011 10:44:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:Date:Mime-Version:Subject:To:From; bh=5UU4jqHFs0jCiA3tWHRJg6F22TT7K8n6EqKhPjvX2YI=; b=TSs5QwRA0rmS+F/ch6B1Ph1GFNDGHocSTOOdo+wRjOV64K932MyaHywmmRSsrggORqxqYtKHn3lQD9HtHX+OBWrEfzejpgOiMejYz/IuB5kNTx7S/Yi0kLRtrk5I0AZj; Received: from mail by f287.mail.ru with local id 1QcEjo-0005Zh-00 for freebsd-current@freebsd.org; Thu, 30 Jun 2011 14:44:48 +0400 Received: from [95.32.183.114] by e.mail.ru with HTTP; Thu, 30 Jun 2011 14:44:48 +0400 From: Andrey Smagin To: freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [95.32.183.114] Date: Thu, 30 Jun 2011 14:44:48 +0400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok Subject: AX88772A AX88772B chipset differences? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:44:51 -0000 SSBoYXZlIGNhcmQgYmFzZWQgb24gQVg4ODc3MkIuIEkgdHJpZWQgcGF0Y2ggYXhlIGRyaXZlciBm b3IgdmVuZG9yIGFuZCBkZXZpY2UgSURzLiBjYXJkIGRldGVjdGVkLCBzZXQgdXAgbGluaywgYnV0 IG5vIGRhdGEgcmVjZWl2ZWQuIFdoYXQgZWxzZSBuZWVkIGZvciBwYXRjaCBpbiAgdGhpcyBkcml2 ZXIgPyBBbnlib2R5IGhhdmUgZGF0YXNoZWV0ID8K From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 10:46:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B22651065675 for ; Thu, 30 Jun 2011 10:46:10 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 744338FC19 for ; Thu, 30 Jun 2011 10:46:10 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QcERN-0006ft-9G; Thu, 30 Jun 2011 11:25:45 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QcERN-0004Qa-43; Thu, 30 Jun 2011 11:25:45 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id p5UAPijD097624; Thu, 30 Jun 2011 11:25:44 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id p5UAPiPp097623; Thu, 30 Jun 2011 11:25:44 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 30 Jun 2011 11:25:44 +0100 From: Anton Shterenlikht To: current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: current@freebsd.org, freebsd-ia64@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: isp(4) timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:46:10 -0000 I see in my logs: isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ isp_plogx:2122) isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) isp0: Chan 0 PLOGI 0x010500 failed isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) isp0: mailbox cmd (0x4000) with no waiters What do these isp messages mean? It seems em0 went down the same time. The serial console was fine, and em1 was fine too. But I had to reboot to get em0 working again. This is on ia64 r221340 After reboot: ZEEV> ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:13:21:5b:05:1c inet 137.222.187.28 netmask 0xffffff00 broadcast 137.222.187.255 inet6 fe80::213:21ff:fe5b:51c%em0 prefixlen 64 scopeid 0x4 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:13:21:5b:05:1d inet 10.10.10.14 netmask 0xffffff00 broadcast 10.10.10.255 inet6 fe80::213:21ff:fe5b:51d%em1 prefixlen 64 scopeid 0x5 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 nd6 options=21 ZEEV> Many thanks Anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 11:13:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168A3106566B for ; Thu, 30 Jun 2011 11:13:23 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id AD6438FC08 for ; Thu, 30 Jun 2011 11:13:22 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id p5UBDm1t001082; Thu, 30 Jun 2011 13:13:48 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id p5UBDmJh001081; Thu, 30 Jun 2011 13:13:48 +0200 (CEST) (envelope-from mlfbsd) Date: Thu, 30 Jun 2011 13:13:48 +0200 From: Olivier Houchard To: Hans Petter Selasky Message-ID: <20110630111348.GA111@ci0.org> References: <201106301122.36155.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106301122.36155.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 30 Jun 2011 11:22:02 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 11:13:23 -0000 On Thu, Jun 30, 2011 at 11:22:36AM +0200, Hans Petter Selasky wrote: > Hi, > > Trying to cross build ARM fails in the following way on 8-stable: > > 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 > > make toolchain TARGET=arm > > Is this perhaps also an issue in 9-current? > > Any clues? > Hi Hans Peter, Not sure if it is your problem, but I think it should be make toolchain TARGET_ARCH=arm Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 11:26:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF117106566B for ; Thu, 30 Jun 2011 11:26:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8D98FC0C for ; Thu, 30 Jun 2011 11:26:34 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=SJA03SmFjIOBaRUqQpAxZTuC3Mg0Qr8luS0qYjfHCY4= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=JEpRC5FsCwkA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=ChsiAOgWrHde61Gll_UA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 146941523; Thu, 30 Jun 2011 13:26:33 +0200 From: Hans Petter Selasky To: Olivier Houchard Date: Thu, 30 Jun 2011 13:24:49 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106301122.36155.hselasky@c2i.net> <20110630111348.GA111@ci0.org> In-Reply-To: <20110630111348.GA111@ci0.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106301324.49236.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 11:26:35 -0000 On Thursday 30 June 2011 13:13:48 Olivier Houchard wrote: > On Thu, Jun 30, 2011 at 11:22:36AM +0200, Hans Petter Selasky wrote: > > Hi, > > > > Trying to cross build ARM fails in the following way on 8-stable: > > > > 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 > > > > make toolchain TARGET=arm > > > > Is this perhaps also an issue in 9-current? > > > > Any clues? > > Hi Hans Peter, > > > Not sure if it is your problem, but I think it should be > make toolchain TARGET_ARCH=arm > Using "make toolchain TARGET_ARCH=arm" gives the same error code. Tracing down the issue: /usr/include/machine/endian.h #define __byte_swap_int_var(x) \ __extension__ ({ register __uint32_t __X = (x); \ __asm ("bswap %0" : "+r" (__X)); \ __X; }) r0 looks like an ARM register passed to a non-arm assembler. I'm going to try: "make toolchains" And see how that works out. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 12:06:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F181065672; Thu, 30 Jun 2011 12:06:35 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7B8D8FC17; Thu, 30 Jun 2011 12:06:34 +0000 (UTC) Received: by bwa20 with SMTP id 20so2576311bwa.13 for ; Thu, 30 Jun 2011 05:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ApbmueIqT/KDAA7SCw19tv3udanLVaSDAbmWRmfdQgk=; b=pGamJThGmmZ1LMcNTtnEatzHtBcyAg4uW8eEvE9p/NKHSMPtLs5OXB5ginX96o3ewz B61LOU/06IXFTfrL3yWeVZGd25zpu0SqW5e4fCkFfQvMnFPOz9Y7yvf2dV1oX+LK5GFf ZL1n9T4yJdU1oyEepUcav3Qs6/nKihqkz8En8= Received: by 10.204.177.141 with SMTP id bi13mr1837485bkb.203.1309434251597; Thu, 30 Jun 2011 04:44:11 -0700 (PDT) Received: from [172.29.1.142] (altimet-gw.cs2.dp.wnet.ua [217.20.178.249]) by mx.google.com with ESMTPS id c13sm2024339bkc.2.2011.06.30.04.44.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 04:44:10 -0700 (PDT) Message-ID: <4E0C62B8.5090802@gmail.com> Date: Thu, 30 Jun 2011 14:49:12 +0300 From: Vitaly Magerya User-Agent: Thunderbird MIME-Version: 1.0 To: Antony Mawer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kern/143370: splash_txt ASCII splash screen module 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, 30 Jun 2011 12:06:35 -0000 Antony Mawer wrote: > Not sure if this is the right place to post it -- about 6 years ago I > put together a module which displays an ASCII splash screen on boot > (rather than the graphical splash_pcx and splash_bmp modules). As a user, I think this is rather cool; at least it is more useful for me than bmp/pcx splash modules, as I don't want to load vesa. Hm... Can you center the image if the display size is other than 80x25? Or try to temporarily change the video mode? It looks a bit misplaced in 80x50. Also, this would be 2x as cool if you could animate the splash. For example, if the supplied bitmap is 80x50, you could treat that as 2 frames, and cycle through them periodically (I assume that splash modules work the same way as saved modules do: the main function is called a few times per second, so you can update the screen there). BTW, in txt_init you currently check for data_size <= 0; you should also check for data_size < BIN_IMAGE_WIDTH * BIN_IMAGE_HEIGHT * 2, since if the bitmap is smaller, you'll draw garbage on the screen. > I have uploaded two sample boot splash screens at > http://www.mawer.org/freebsd/freebsd1.bin and > http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced > using TheDraw and saving in its Binary file format, which consists of > a sequence of 2 byte pairs. The first byte in a pair is the character > to draw on the screen, and the second is the colour/display attributes > to draw the character with. As a side note, these images can also be made from video buffer dumps that vidcontrol produces like this: vidcontrol -p < /dev/ttyv0 | tail -c +13 > screenshot.bin (Substitute ttyv0 for the tty you want to take a picture of; the tty should be in 80x25 mode). From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 12:11:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20641065672 for ; Thu, 30 Jun 2011 12:11:07 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id AE1AF8FC0C for ; Thu, 30 Jun 2011 12:11:07 +0000 (UTC) Received: from [192.168.135.103] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p5UCB61a047613 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 Jun 2011 05:11:07 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4E0C67EC.8020609@feral.com> Date: Thu, 30 Jun 2011 05:11:24 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Thu, 30 Jun 2011 05:11:07 -0700 (PDT) Subject: Re: isp(4) timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:11:08 -0000 On 6/30/2011 3:25 AM, Anton Shterenlikht wrote: > I see in my logs: > > isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ isp_plogx:2122) > isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) > isp0: Chan 0 PLOGI 0x010500 failed > isp0: Polled Mailbox Command (0x64) Timeout (250000us) (started @ isp_getpdb:2307) > isp0: Mailbox Command 'GET PORT DATABASE' failed (TIMEOUT) More details please. These errors indicate failures to execute commands that try and figure out what's on a fabric and then log into devices on the fabric. Knowing what hardware you have (QLogic card version), what FreeBSD release you are running, would help. A verbose dmesg would be useful. From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 14:53:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F9D0106568A for ; Thu, 30 Jun 2011 14:53:46 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from ns2.bafirst.com (ns2.bafirst.com [97.67.198.91]) by mx1.freebsd.org (Postfix) with ESMTP id 1531A8FC1C for ; Thu, 30 Jun 2011 14:53:45 +0000 (UTC) Received: from unixmania.com ([189.251.17.30]) by ns2.bafirst.com with esmtp; Thu, 30 Jun 2011 09:43:41 -0500 id 000DA804.4E0C8B9E.00007B3B Received: from localhost (localhost [127.0.0.1]) (uid 80) by unixmania.com with local; Thu, 30 Jun 2011 09:43:41 -0500 id 000CF6E7.4E0C8B9D.0000ECCB Received: from dsl-189-251-65-236-dyn.prod-infinitum.com.mx (dsl-189-251-65-236-dyn.prod-infinitum.com.mx [189.251.65.236]) by econet.encontacto.net (Horde Framework) with HTTP; Thu, 30 Jun 2011 09:43:41 -0500 Message-ID: <20110630094341.38064xcui4cdd2n4@econet.encontacto.net> Date: Thu, 30 Jun 2011 09:43:41 -0500 From: eculp To: dg17@penx.com References: <20110629073105.17922wqmo8yonl6o@econet.encontacto.net> <1309355420.68251.8.camel@btw.pki2.com> In-Reply-To: <1309355420.68251.8.camel@btw.pki2.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (5.0-cvs) X-Remote-Browser: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20100101 Firefox/5.0 X-IMP-Server: 189.251.17.30 X-Originating-IP: 189.251.65.236 X-Originating-User: eculp@encontacto.net Cc: freebsd-current Subject: Re: Opinion on using AMD Phenom II x6 1090t with Gigabyte 890BPA-UD3H and 8GB DDR-3 as a WebServer. 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, 30 Jun 2011 14:53:46 -0000 Quoting Dennis Glatting : > On Wed, 2011-06-29 at 07:31 -0500, eculp wrote: >> I just saw this box that is being promoted as a gaming machine at a >> great price and am considering it as a web-server. >> >> In addition to having no information on the CPU as a server lack of >> comfort with 6 cores and memory 8GB of memory that I am having a >> problem with. I am not a gamer but I have always assumed that a >> gaming machine needs the most aggressive hardware. I have also seen >> this processor with 12 GB rather than 8 which, in my ignorance sounds >> better. >> >> Any opinions and guidance are appreciated. >> > > I have been moving away from Gigabyte however I do have a similar board: > > =09MB GIGABYTE GA-870A-UD3 RT This one is GA-890BPA-UD3G that also has RealTek 811D 10/100/1000 Mbit =20 that I doubt will be a limitation. I'll stick in another card anyway. =20 I also like that has is sata3 and usb 3 so it seems to be up to date. > > My key complaint about Gigabyte is the ReatTek Ethernet chips. Realtek > doesn't publish chip specs and therefore the drivers under FreeBSD/Linux > are so-so (i.e., they work but not performance optimized and forget > about anything but the default MTU). > > On my board I hate the South Bridge chip, which is useless for RAID. > > I am also unable to install VMWare ESXi, my last ditch attempt to find a > use for my board. There appears to be a hardware incompatibility while > installing (i.e., not during the probe sequence, rather after that > sequence then onto installation). > Thanks a lot for your suggestions and point of view. I'm begining to =20 think that this may be too much machine but comming down doesn't save =20 much so I will probably give it a try. ed > > > From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 15:43:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444A0106566C for ; Thu, 30 Jun 2011 15:43:15 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 312A78FC08 for ; Thu, 30 Jun 2011 15:43:14 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id 79FF71009C20 for ; Thu, 30 Jun 2011 08:26:13 -0700 (PDT) Date: Thu, 30 Jun 2011 08:26:13 -0700 (PDT) From: Tim Gustafson To: freebsd-current@freebsd.org Message-ID: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <576562817.159786.1309446593826.JavaMail.root@mail-01.cse.ucsc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Subject: FreeBSD 9 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, 30 Jun 2011 15:43:15 -0000 Hi, I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. I have noticed two snafus that I thought I'd send to the group just as feedback: -------------------------------------------------------------------------------- 1. net-snmp fails to compile with the following error: -------------------------------------------------------------------------------- /bin/sh ../../libtool --mode=compile cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c -o mibII/tcpTable.lo mibII/tcpTable.c libtool: compile: cc -I../../include -I. -I../../agent -I../../agent/mibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=freebsd9 -c mibII/tcpTable.c -fPIC -DPIC -o mibII/.libs/tcpTable.o mibII/tcpTable.c:94: error: field 'pcb' has incomplete type mibII/tcpTable.c: In function 'tcpTable_load': mibII/tcpTable.c:866: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: dereferencing pointer to incomplete type mibII/tcpTable.c:868: error: invalid application of 'sizeof' to incomplete type 'struct xinpgen' mibII/tcpTable.c:872: error: dereferencing pointer to incomplete type mibII/tcpTable.c:876: error: dereferencing pointer to incomplete type mibII/tcpTable.c:877: error: invalid application of 'sizeof' to incomplete type 'struct inpcb' mibII/tcpTable.c:881: error: dereferencing pointer to incomplete type -------------------------------------------------------------------------------- 2. secondary IP addresses on network interfaces don't seem to be working -------------------------------------------------------------------------------- In my rc.conf, I have: ifconfig_bce0="1.2.3.4 netmask 255.255.252.0" ifconfig_bce0_alias0="1.2.3.5 netmask 255.255.255.255" but when the machine reboots, it only gets its primary IP address. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:11:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D94C106564A for ; Thu, 30 Jun 2011 16:11:48 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id AB3758FC14 for ; Thu, 30 Jun 2011 16:11:47 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D6E5D40030 for ; Thu, 30 Jun 2011 18:11:46 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id CC80B4002E; Thu, 30 Jun 2011 18:11:46 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,FREEMAIL_FROM autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 4E2E44002B; Thu, 30 Jun 2011 18:11:46 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id BD492119C08; Thu, 30 Jun 2011 18:11:15 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 90BE012B1E5; Thu, 30 Jun 2011 18:11:15 +0200 (CEST) Message-ID: <4E0CA021.60009@gmail.com> Date: Thu, 30 Jun 2011 18:11:13 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Tim Gustafson References: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 16:11:48 -0000 On 2011-06-30 17:26, Tim Gustafson wrote: > Hi, > > I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for the LSI SAS2008 controller. I've also built the system as a ZFS-root box, and I have to say that I'm quite happy with the disk performance: we're getting about 500MB/s write and 675MB/s read. All in all, I'm very happy with FreeBSD 9. > > I have noticed two snafus that I thought I'd send to the group just as feedback: > > -------------------------------------------------------------------------------- > 2. secondary IP addresses on network interfaces don't seem to be working > -------------------------------------------------------------------------------- > > In my rc.conf, I have: > > ifconfig_bce0="1.2.3.4 netmask 255.255.252.0" > ifconfig_bce0_alias0="1.2.3.5 netmask 255.255.255.255" > > but when the machine reboots, it only gets its primary IP address. > I think you need something along the line of ifconfig_bce0_alias0="inet 1.2.3.5 netmask ...", notice the 'inet', since aliasN can be used for both inet and inet6. HTH! -- Niclas From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:21:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9325106566C for ; Thu, 30 Jun 2011 16:21:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6290E8FC12 for ; Thu, 30 Jun 2011 16:21:46 +0000 (UTC) Received: by qwc9 with SMTP id 9so1646553qwc.13 for ; Thu, 30 Jun 2011 09:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sTaeh0NmBhKEXOxjFXXNr1fBCGSc7Io+RuMmYyq4dEQ=; b=rIbphEjGyl9wq/EUpwqovnVsJXnPXRcbioDOtyZoUFTnqddM81jNuJ8VBXHQqXd+iO /POu8BIgl7zQP5c+rRs6uQgHvylPXU2XKUwBdDnl9YtBRzv4hwOTrcPrgDj85cVdHjB0 J265ot3hIn/QSGth2cmpqV+h7MRLTKOZH0MLk= MIME-Version: 1.0 Received: by 10.229.29.84 with SMTP id p20mr1710125qcc.61.1309450905453; Thu, 30 Jun 2011 09:21:45 -0700 (PDT) Received: by 10.229.73.141 with HTTP; Thu, 30 Jun 2011 09:21:45 -0700 (PDT) In-Reply-To: <4E0CA021.60009@gmail.com> References: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> <4E0CA021.60009@gmail.com> Date: Thu, 30 Jun 2011 20:21:45 +0400 Message-ID: From: Sergey Kandaurov To: Niclas Zeising Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tim Gustafson , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 16:21:46 -0000 On 30 June 2011 20:11, Niclas Zeising wrote: > On 2011-06-30 17:26, Tim Gustafson wrote: >> Hi, >> >> I've installed FreeBSD 9 on a new server because 8.2 doesn't have suppor= t for the LSI SAS2008 controller. =A0I've also built the system as a ZFS-ro= ot box, and I have to say that I'm quite happy with the disk performance: w= e're getting about 500MB/s write and 675MB/s read. =A0All in all, I'm very = happy with FreeBSD 9. >> >> I have noticed two snafus that I thought I'd send to the group just as f= eedback: >> >> ------------------------------------------------------------------------= -------- >> 2. secondary IP addresses on network interfaces don't seem to be working >> ------------------------------------------------------------------------= -------- >> >> In my rc.conf, I have: >> >> ifconfig_bce0=3D"1.2.3.4 netmask 255.255.252.0" >> ifconfig_bce0_alias0=3D"1.2.3.5 netmask 255.255.255.255" >> >> but when the machine reboots, it only gets its primary IP address. >> > > I think you need something along the line of ifconfig_bce0_alias0=3D"inet > 1.2.3.5 netmask ...", notice the 'inet', since aliasN can be used for > both inet and inet6. > HTH! Exactly. Since SVN rev 197139 you need to explicitly specify the protocol family before address in the ifconfig_IF_alias=3D"" string. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:23:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F6D6106564A for ; Thu, 30 Jun 2011 16:23:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 073C18FC15 for ; Thu, 30 Jun 2011 16:23:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p5UGNFgO017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 19:23:16 +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.4/8.14.4) with ESMTP id p5UGNFv9098078; Thu, 30 Jun 2011 19:23:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p5UGNFo3098077; Thu, 30 Jun 2011 19:23:15 +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: Thu, 30 Jun 2011 19:23:15 +0300 From: Kostik Belousov To: x11@freebsd.org Message-ID: <20110630162315.GV48734@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6cv90ZHrlxJiM48h" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Intel GPU kernel driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:23:20 -0000 --6cv90ZHrlxJiM48h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Please remove current@ when replying.] I created the first code drop for the ongoing GEM/KMS project. Please note that this is not an end-user release, and even _not_ a call for testing. The project is not finished yet, and I expect quite more efforts from me even after the scheduled project end, and from ports/x11 people, before the driver and usermode infrastructure will be ready for the general public consumption. That said, the patch is only of use for you now if you want to review, debug or otherwise help the project. The driver is known to be unstable, some parts are missing, some (esp. VM changes) are under the discussion and propably will be changed. If you have fix or useful bug analisys or suggestions for improvements, you are welcome. I will not answer to the support requests for this code now, please do not waste your time asking for it. The pointers to the patches, useful hints for debugging and bug reporting, and some notes are at the http://wiki.freebsd.org/Intel_GPU. I will maintain this page further. Current patch is ~50KLOC, it took quite an efforts to bring the code to the state where there is something to debug. Thanks for everybody who waited for it, and please be patient while the further work is done. --6cv90ZHrlxJiM48h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4MovMACgkQC3+MBN1Mb4i1SgCbBMCrSa0ayyHkjndiGs1R2wo3 SU8AoPL/7Sk+xyXOhhOMlHf60hEwS9AL =1brR -----END PGP SIGNATURE----- --6cv90ZHrlxJiM48h-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:44:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19554106566C for ; Thu, 30 Jun 2011 16:44:44 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D72D98FC13 for ; Thu, 30 Jun 2011 16:44:43 +0000 (UTC) Received: by iwr19 with SMTP id 19so2880581iwr.13 for ; Thu, 30 Jun 2011 09:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eFeVVloWdrUz9U52YlVmU/nTvpkT3Y5lRIyGbajbQEc=; b=gbHfwvMXfQLFo9ZvacTbR3OVokrEVxYnPxlxedsDbCRbKVS7kmlCpszd/Nyb/acD04 FLjSIdVriEXcSQKPBPOlOr9wWrUz8N3Ky8U6kZCTfL5i30PW51scJ6fX1zmHy9MCCkMt Ra0sdD/bVWcI1v7ogQ47V73NZsR0FTHoEsqPQ= Received: by 10.42.200.133 with SMTP id ew5mr2283587icb.182.1309450452404; Thu, 30 Jun 2011 09:14:12 -0700 (PDT) Received: from [192.168.1.100] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id d8sm2307011icy.21.2011.06.30.09.14.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 09:14:11 -0700 (PDT) Message-ID: <4E0CA0D0.6050500@gmail.com> Date: Thu, 30 Jun 2011 11:14:08 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hans Petter Selasky References: <201106301122.36155.hselasky@c2i.net> In-Reply-To: <201106301122.36155.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 16:44:44 -0000 On 6/30/2011 4:22 AM, Hans Petter Selasky wrote: > Hi, > > Trying to cross build ARM fails in the following way on 8-stable: > > 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 > > make toolchain TARGET=arm > > Is this perhaps also an issue in 9-current? > > Any clues? > > cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-float - > D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - > I/usr/src/lib/libstand/../libz -std=gnu99 -c > /usr/src/lib/libstand/../libc/net/ntoh.c > {standard input}: Assembler messages: > {standard input}:27: Error: bad instruction `bswap r0' > {standard input}:53: Error: bad instruction `bswap r0' > and you also said: > Tracing down the issue: > > /usr/include/machine/endian.h > > #define __byte_swap_int_var(x) \ > __extension__ ({ register __uint32_t __X = (x); \ > __asm ("bswap %0" : "+r" (__X)); \ > __X; }) > > r0 looks like an ARM register passed to a non-arm assembler. I'm going to try: > Looks like you have an ARM compiler/assembler because the assembler rejects the i386/amd64 "bswap" assembly command. Does anyone remember if the cross compiler has the cross include paths compiled into them or should there be a "-I" in the compile command to correctly expand the "#include " ? I thought the cross path was compiled into the cross compiler. You manually test the "cc" command with the included "-I" option. --Mark From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:57:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31ECD106567A for ; Thu, 30 Jun 2011 16:57:13 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id EF0928FC16 for ; Thu, 30 Jun 2011 16:57:12 +0000 (UTC) Received: from Uller.local (static-74-109-127-34.phlapa.fios.verizon.net [74.109.127.34]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id p5UGZbAh009640 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 Jun 2011 12:35:37 -0400 (EDT) (envelope-from sean@coreitpro.com) Message-ID: <4E0CA5D4.4010002@coreitpro.com> Date: Thu, 30 Jun 2011 12:35:32 -0400 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> In-Reply-To: <4E0B8CBC.8080601@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 30 Jun 2011 16:57:13 -0000 > Maybe i'm missing something but creating/removing large number of files > in one directory on tmpfs was very slow for me. That was long ago and > ZFS was in so i'll try to retest... I decided to torture test tmpfs with bonnie++ on one of my machines and the machine wedged. I can ping it but that's about it. Originally I was in favor of removing the warning, but now, not so much. -- Sean Collins Core IT Pro, LLC www.coreitpro.com From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 16:59:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 373F6106566B for ; Thu, 30 Jun 2011 16:59:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED2E38FC19 for ; Thu, 30 Jun 2011 16:59:05 +0000 (UTC) Received: by vws18 with SMTP id 18so2449201vws.13 for ; Thu, 30 Jun 2011 09:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Avh9YHgd17ZilBoKLfiVfmYglK0ww2WNA5tmb/HkpfY=; b=Hu0JLEcDJUdwONNgeViOyNM1NkCbMcEOnfbCXiV4sGAzWc18pdM2NfRdsAh4tPOWMd bzKCGpe/q5JIwkrsks6vu+1avSQHv2K/e2Y9omaFLiq+hNOIoWLM4UI9YEzGkgjiS9RN 2OZV+kYpxeorU2LIvS9se/aPjsefJ2Q/YYb+Q= MIME-Version: 1.0 Received: by 10.221.13.196 with SMTP id pn4mr842362vcb.73.1309453144884; Thu, 30 Jun 2011 09:59:04 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Thu, 30 Jun 2011 09:59:04 -0700 (PDT) In-Reply-To: <4E0CA0D0.6050500@gmail.com> References: <201106301122.36155.hselasky@c2i.net> <4E0CA0D0.6050500@gmail.com> Date: Thu, 30 Jun 2011 09:59:04 -0700 Message-ID: From: Garrett Cooper To: Mark Tinguely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 16:59:06 -0000 On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely wro= te: > On 6/30/2011 4:22 AM, Hans Petter Selasky wrote: >> >> Hi, >> >> Trying to cross build ARM fails in the following way on 8-stable: >> >> 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 >> >> make toolchain TARGET=3Darm >> >> Is this perhaps also an issue in 9-current? >> >> Any clues? >> >> cc -O -pipe =A0-ffreestanding -Wformat -I/usr/src/lib/libstand -msoft-fl= oat >> - >> D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - >> I/usr/src/lib/libstand/../libz -std=3Dgnu99 =A0-c >> /usr/src/lib/libstand/../libc/net/ntoh.c >> {standard input}: Assembler messages: >> {standard input}:27: Error: bad instruction `bswap r0' >> {standard input}:53: Error: bad instruction `bswap r0' >> > > and you also said: > >> Tracing down the issue: >> >> /usr/include/machine/endian.h >> >> #define __byte_swap_int_var(x) \ >> __extension__ ({ register __uint32_t __X =3D (x); \ >> =A0 =A0__asm ("bswap %0" : "+r" (__X)); \ >> =A0 =A0__X; }) >> >> r0 looks like an ARM register passed to a non-arm assembler. I'm going t= o >> try: >> > > Looks like you have an ARM compiler/assembler because the assembler rejec= ts > the i386/amd64 "bswap" assembly command. > > Does anyone remember if the cross compiler has the cross include paths > compiled into them or should there be a "-I" in the compile command to > correctly expand the "#include " ? I thought the cross > path was compiled into the cross compiler. > > You manually test the "cc" command with the included "-I" option. Adding -v to the command line might yield more interesting results in tracking down the culprit header. -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:02:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28DD106564A for ; Thu, 30 Jun 2011 17:02:57 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A122E8FC18 for ; Thu, 30 Jun 2011 17:02:57 +0000 (UTC) Received: by vxg33 with SMTP id 33so2470275vxg.13 for ; Thu, 30 Jun 2011 10:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+ud8KdR7+/go6JzJ6avVBJU6J3X+PzBdO14HsQ63rfg=; b=BVxXP0mrW8oleHJTtclRkh9qbkJ9IEO8U2UHhNVuFk/Kzk1vt4T47aieGYzSqAyyES 0etjKXwql5RCm3QZrLI6/S5iRJZ6nBnHJRU+U5bikZhVvB5rNH7iYj3M8XNLFUOq4SZL fByj+rMntxrSqNzZVlo3kmI9ZsYVsMhJupe3A= MIME-Version: 1.0 Received: by 10.220.59.193 with SMTP id m1mr76640vch.38.1309453376800; Thu, 30 Jun 2011 10:02:56 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Thu, 30 Jun 2011 10:02:56 -0700 (PDT) In-Reply-To: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> References: <576562817.159786.1309446593826.JavaMail.root@mail-01.cse.ucsc.edu> <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> Date: Thu, 30 Jun 2011 10:02:56 -0700 Message-ID: From: Garrett Cooper To: Tim Gustafson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 17:02:58 -0000 On Thu, Jun 30, 2011 at 8:26 AM, Tim Gustafson wrote: > Hi, > > I've installed FreeBSD 9 on a new server because 8.2 doesn't have support= for the LSI SAS2008 controller. =A0I've also built the system as a ZFS-roo= t box, and I have to say that I'm quite happy with the disk performance: we= 're getting about 500MB/s write and 675MB/s read. =A0All in all, I'm very h= appy with FreeBSD 9. > > I have noticed two snafus that I thought I'd send to the group just as fe= edback: > > -------------------------------------------------------------------------= ------- > 1. net-snmp fails to compile with the following error: > -------------------------------------------------------------------------= ------- > > /bin/sh ../../libtool --mode=3Dcompile cc -I../../include -I. -I../../age= nt -I../../agent/mibgroup =A0-I../../snmplib -I/usr/include =A0 -O2 -pipe -= fno-strict-aliasing -Ufreebsd9 -Dfreebsd9=3Dfreebsd9 -c -o mibII/tcpTable.l= o mibII/tcpTable.c > libtool: compile: =A0cc -I../../include -I. -I../../agent -I../../agent/m= ibgroup -I../../snmplib -I/usr/include -O2 -pipe -fno-strict-aliasing -Ufre= ebsd9 -Dfreebsd9=3Dfreebsd9 -c mibII/tcpTable.c =A0-fPIC -DPIC -o mibII/.li= bs/tcpTable.o > mibII/tcpTable.c:94: error: field 'pcb' has incomplete type > mibII/tcpTable.c: In function 'tcpTable_load': > mibII/tcpTable.c:866: error: dereferencing pointer to incomplete type > mibII/tcpTable.c:868: error: dereferencing pointer to incomplete type > mibII/tcpTable.c:868: error: invalid application of 'sizeof' to incomplet= e type 'struct xinpgen' > mibII/tcpTable.c:872: error: dereferencing pointer to incomplete type > mibII/tcpTable.c:876: error: dereferencing pointer to incomplete type > mibII/tcpTable.c:877: error: invalid application of 'sizeof' to incomplet= e type 'struct inpcb' > mibII/tcpTable.c:881: error: dereferencing pointer to incomplete type Someone already filed a PR for this ( http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/158266 ) and I'm working on cleaning up the autoconf tests to work properly for $WORK so we can upgrade to 5.6.1.1. The problem is caused by the recent netinet / net content shuffling and the fact that the autoconf tests for net-snmp are broken (and a number of includes on files). Unfortunately the upstream maintainers used a sledgehammer approach for all of the BSDs to detect how headers were supposed to be #include'd, and there's a lot of namespace pollution involved. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:20:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D78C1065675 for ; Thu, 30 Jun 2011 17:20:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB7ED8FC1E for ; Thu, 30 Jun 2011 17:20:09 +0000 (UTC) Received: by iwr19 with SMTP id 19so2918923iwr.13 for ; Thu, 30 Jun 2011 10:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qUwIr1UCJG/26riQd8xtbwfMXjS6r1Y6aBx/jzD90Z4=; b=WAcBgJBMkZ8OUgJOEQ4t+7E6QMfazJYOBdqprrxZxvyCNHmkPDUmBbO2AUYjSV+a28 ki2EG2P/MN86hziA8jRWgwU75JMmmyBsHQFX7dc4rAfHG9FgzylKe5wdjz+5Cjnoz03l n3fiq1GdfcYMlVo4/8KeMKximE8omI3nTmdfE= Received: by 10.42.168.137 with SMTP id w9mr2065719icy.121.1309454409025; Thu, 30 Jun 2011 10:20:09 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id e23sm1331460ibe.6.2011.06.30.10.20.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 10:20:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 30 Jun 2011 10:19:14 -0700 From: YongHyeon PYUN Date: Thu, 30 Jun 2011 10:19:14 -0700 To: Andrey Smagin Message-ID: <20110630171914.GA12124@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: AX88772A AX88772B chipset differences? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:20:10 -0000 On Thu, Jun 30, 2011 at 02:44:48PM +0400, Andrey Smagin wrote: > I have card based on AX88772B. I tried patch axe driver for vendor and device IDs. card detected, set up link, but no data received. What else need for patch in this driver ? Anybody have datasheet ? ASIX requires a login account to get the data sheet so it's not publicly available to open source developers. AFAIK the difference between AX88772A and AX88772B is IPv4/IPv6 checksum offloading support of AX88772B. The introduction of checksum offloading means they might have changed its RX header format which in turn makes current RX handler to not work. The other difference would be more advanced power saving used in AX8877B but it wouldn't be much difference to axe(4) driver once PHY is correctly woken in initialization phase. Could you show me your diff and verbose boot output to know PHY model and EEPROM data? From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:23:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D44D106564A for ; Thu, 30 Jun 2011 17:23:02 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id EFC038FC14 for ; Thu, 30 Jun 2011 17:23:01 +0000 (UTC) Received: from sa-nc-common2-75.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p5UH5gtm011031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 10:05:48 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> Date: Thu, 30 Jun 2011 10:05:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110630102544.GA97559@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: isp(4) timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:23:02 -0000 On Jun 30, 2011, at 3:25 AM, Anton Shterenlikht wrote: > I see in my logs: >=20 > isp0: Polled Mailbox Command (0x54) Timeout (500000us) (started @ = isp_plogx:2122) > isp0: Mailbox Command 'EXECUTE IOCB A64' failed (TIMEOUT) This is most likely caused by a loss of interrupt handling. Be it masked interrupts or the inability to have the interrupt thread running. I have some important improvements in the pipeline that significantly improve stability. I'm doing a final test and then I'll commit. It may address the issue as a side-effect. FYI, --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:40:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 475AF106564A for ; Thu, 30 Jun 2011 17:40:04 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 30C6E8FC16 for ; Thu, 30 Jun 2011 17:40:03 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id D1AA21009C04; Thu, 30 Jun 2011 10:40:03 -0700 (PDT) Date: Thu, 30 Jun 2011 10:40:03 -0700 (PDT) From: Tim Gustafson To: Niclas Zeising Message-ID: <2021750843.160454.1309455603717.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <4E0CA021.60009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 17:40:04 -0000 > I think you need something along the line of > ifconfig_bce0_alias0="inet 1.2.3.5 netmask ...", notice the > 'inet', since aliasN can be used for both inet and inet6. Got it, thanks! I assume that's also recommended for the primary interface as well? I've added the "inet" prefix to both lines and it is working. Thanks! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:50:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CEA7106566C for ; Thu, 30 Jun 2011 17:50:05 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id B72228FC08 for ; Thu, 30 Jun 2011 17:50:04 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id F31B84002D for ; Thu, 30 Jun 2011 19:50:03 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E883A40030; Thu, 30 Jun 2011 19:50:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,FREEMAIL_FROM autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 07D7C4002D; Thu, 30 Jun 2011 19:50:02 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id AFBD8119C08; Thu, 30 Jun 2011 19:50:02 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 8D3FF12B1E5; Thu, 30 Jun 2011 19:50:02 +0200 (CEST) Message-ID: <4E0CB749.7000602@gmail.com> Date: Thu, 30 Jun 2011 19:50:01 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Tim Gustafson References: <2021750843.160454.1309455603717.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <2021750843.160454.1309455603717.JavaMail.root@mail-01.cse.ucsc.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 17:50:05 -0000 On 2011-06-30 19:40, Tim Gustafson wrote: >> I think you need something along the line of >> ifconfig_bce0_alias0="inet 1.2.3.5 netmask ...", notice the >> 'inet', since aliasN can be used for both inet and inet6. > > Got it, thanks! > > I assume that's also recommended for the primary interface as well? I've added the "inet" prefix to both lines and it is working. Thanks! > I don't know if it's recommended or not, there's a ifconfig_ifN_ipv6, at least in current, as well. But it definitely does not hurt. :) Glad to be able to help! -- Niclas From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 17:54:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B44D106564A for ; Thu, 30 Jun 2011 17:54:41 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8DB8FC14 for ; Thu, 30 Jun 2011 17:54:41 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id E53091009C20; Thu, 30 Jun 2011 10:54:40 -0700 (PDT) Date: Thu, 30 Jun 2011 10:54:40 -0700 (PDT) From: Tim Gustafson To: Garrett Cooper Message-ID: <551282154.160535.1309456480698.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 30 Jun 2011 17:54:42 -0000 > Someone already filed a PR for this ( > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158266 ) and I'm > working on cleaning up the autoconf tests to work properly for $WORK > so we can upgrade to 5.6.1.1. > > The problem is caused by the recent netinet / net content shuffling > and the fact that the autoconf tests for net-snmp are broken (and a > number of includes on files). Unfortunately the upstream maintainers > used a sledgehammer approach for all of the BSDs to detect how headers > were supposed to be #include'd, and there's a lot of namespace > pollution involved. Thanks! I've just installed the binary package for now which is working. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 18:56:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1BEC1065672 for ; Thu, 30 Jun 2011 18:56:41 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7989F8FC19 for ; Thu, 30 Jun 2011 18:56:41 +0000 (UTC) Received: by iwr19 with SMTP id 19so3018708iwr.13 for ; Thu, 30 Jun 2011 11:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mgE5OtFB6FXWqN+XA6fP/oDf/15eDlFJnNCUPzsmMI8=; b=WkfzdqGo/+RxSGMgAx6yaaET/BL7Bejy6gFEpBMVReetenKsKxgBn0UReUCy/np1TK vtbgrFTnwPKj/N0tT2UjretBTdS3I7Ry55doLLKhbBSpEwnO9MOguk0drT3QG+VjspAF 4cS8E30khv5V+JI+8otR9lB6YHq+Nw6rB3Rnc= Received: by 10.42.133.6 with SMTP id f6mr593006ict.230.1309460200521; Thu, 30 Jun 2011 11:56:40 -0700 (PDT) Received: from sidhe.local ([75.101.87.90]) by mx.google.com with ESMTPS id x4sm590076ibm.59.2011.06.30.11.56.37 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 11:56:38 -0700 (PDT) Message-ID: <4E0CC6E8.2040708@gmail.com> Date: Thu, 30 Jun 2011 11:56:40 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: eculp References: <20110629073105.17922wqmo8yonl6o@econet.encontacto.net> <1309355420.68251.8.camel@btw.pki2.com> <20110630094341.38064xcui4cdd2n4@econet.encontacto.net> In-Reply-To: <20110630094341.38064xcui4cdd2n4@econet.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dg17@penx.com, freebsd-current Subject: Re: Opinion on using AMD Phenom II x6 1090t with Gigabyte 890BPA-UD3H and 8GB DDR-3 as a WebServer. 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, 30 Jun 2011 18:56:41 -0000 On 06/30/11 07:43, eculp wrote: > Quoting Dennis Glatting : > >> On Wed, 2011-06-29 at 07:31 -0500, eculp wrote: >>> I just saw this box that is being promoted as a gaming machine at a >>> great price and am considering it as a web-server. >>> >>> In addition to having no information on the CPU as a server lack of >>> comfort with 6 cores and memory 8GB of memory that I am having a >>> problem with. I am not a gamer but I have always assumed that a >>> gaming machine needs the most aggressive hardware. I have also seen >>> this processor with 12 GB rather than 8 which, in my ignorance sounds >>> better. >>> >>> Any opinions and guidance are appreciated. >>> >> >> I have been moving away from Gigabyte however I do have a similar board: >> >> MB GIGABYTE GA-870A-UD3 RT > > This one is GA-890BPA-UD3G that also has RealTek 811D 10/100/1000 Mbit > that I doubt will be a limitation. I'll stick in another card anyway. > I also like that has is sata3 and usb 3 so it seems to be up to date. > >> >> My key complaint about Gigabyte is the ReatTek Ethernet chips. Realtek >> doesn't publish chip specs and therefore the drivers under FreeBSD/Linux >> are so-so (i.e., they work but not performance optimized and forget >> about anything but the default MTU). >> >> On my board I hate the South Bridge chip, which is useless for RAID. >> >> I am also unable to install VMWare ESXi, my last ditch attempt to find a >> use for my board. There appears to be a hardware incompatibility while >> installing (i.e., not during the probe sequence, rather after that >> sequence then onto installation). >> > Thanks a lot for your suggestions and point of view. I'm begining to > think that this may be too much machine but comming down doesn't save > much so I will probably give it a try. > > ed >> >> >> > > _______________________________________________ > 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" > A gaming machine needs aggressive hardware, yes, but no one *really* cares if it freezes up once a month. You get what you pay for mostly, so beware of RAM quality, disks, obscure and unfixed BIOS issues, power supply woes etc. I'd really recommend running disk redundancy if it's going to be a single webserver. I think the AMD Thubans can do ECC, right? Might be a good idea for reliability. Especially if you run /var/www on a malloc'd md disk. If you have a few of them in failover, these issues are a bit less, so long as they all don't break at once :). For what it's worth, I have a RealTek 8169 that works great on 9-current. Never had issues with performance or mtu. VLANs work fine. Transfer over CIFs is disk limited at 65mb/s. Will it be fine? Yes. Will it buildworld pretty fast? Yes. Could it leave you "up a creek" at 3 am 2 months after the 1 year warranty expires? Yes. Depends on expectations, of course. Matt From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 19:44:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3122D106564A; Thu, 30 Jun 2011 19:44:48 +0000 (UTC) (envelope-from eng.mufic@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 069C28FC15; Thu, 30 Jun 2011 19:44:47 +0000 (UTC) Received: by pzk27 with SMTP id 27so2821142pzk.13 for ; Thu, 30 Jun 2011 12:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=G5rF1BNBz9Cb9v/b6ahpjSx3N3GqJ/5SPXsET6X14o8=; b=o0sOBT2cs3JEGG34Vj4R0aGHzzu9lrRvhNnRQVfWKoR3n6rBiN2Uza2IJmkqbdMimC ZdTzUSnunDg14bi+QDrqbsVY+JDUk4w7afaSpPR8LSLKsNIFvv5Rh8bhg9MyBCBZph9v ChF+hg81CvwsdOeTAUl6vmufdyeBjXFG1F90g= MIME-Version: 1.0 Received: by 10.68.42.135 with SMTP id o7mr528504pbl.190.1309463087450; Thu, 30 Jun 2011 12:44:47 -0700 (PDT) Sender: eng.mufic@gmail.com Received: by 10.68.41.36 with HTTP; Thu, 30 Jun 2011 12:44:47 -0700 (PDT) Date: Thu, 30 Jun 2011 22:44:47 +0300 X-Google-Sender-Auth: GWAGcwpNEuVzklMRPCyI301pmbs Message-ID: From: Mohammed Farrag To: freebsd-hackers@freebsd.org, freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD is a summer course in Ain Shams University 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, 30 Jun 2011 19:44:48 -0000 Hello FreeBSDers, After the starting of FreeBSD handbook translation, ArabBSD could attract Ain Shams University which is one of the most important universities in Egypt and Arab World to offer Free Summer Course for FreeBSD Administration and FreeBSD development. The course will start by the July 10th. Tutorials about the Course will be uploaded. This course will be instructed by Mohammed Farrag, ArabBSD CEO and FreeBSD Contributor Regards, -- Mohammed * * From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 20:44:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B82106564A for ; Thu, 30 Jun 2011 20:44:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id E61A58FC08 for ; Thu, 30 Jun 2011 20:44:23 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=D/a7r8P9hO61Jx2CeejZiK+y1MY0zppvClPbOUfMbas= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=JEpRC5FsCwkA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=pGLkceISAAAA:8 a=6JQqYPQwwgW2Taaj8GcA:9 a=tqiCYB_TxGZDk59RDAcA:7 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 146718799; Thu, 30 Jun 2011 22:44:21 +0200 From: Hans Petter Selasky To: Garrett Cooper Date: Thu, 30 Jun 2011 22:42:36 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201106301122.36155.hselasky@c2i.net> <4E0CA0D0.6050500@gmail.com> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106302242.36741.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 20:44:24 -0000 On Thursday 30 June 2011 18:59:04 Garrett Cooper wrote: > On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely wrote: > > On 6/30/2011 4:22 AM, Hans Petter Selasky wrote: > >> Hi, > >> > >> Trying to cross build ARM fails in the following way on 8-stable: > >> > >> 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 > >> > >> make toolchain TARGET=arm > >> > >> Is this perhaps also an issue in 9-current? > >> > >> Any clues? > >> > >> cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand > >> -msoft-float - > >> D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - > >> I/usr/src/lib/libstand/../libz -std=gnu99 -c > >> /usr/src/lib/libstand/../libc/net/ntoh.c > >> {standard input}: Assembler messages: > >> {standard input}:27: Error: bad instruction `bswap r0' > >> {standard input}:53: Error: bad instruction `bswap r0' > > > > and you also said: > >> Tracing down the issue: > >> > >> /usr/include/machine/endian.h > >> > >> #define __byte_swap_int_var(x) \ > >> __extension__ ({ register __uint32_t __X = (x); \ > >> __asm ("bswap %0" : "+r" (__X)); \ > >> __X; }) > >> > >> r0 looks like an ARM register passed to a non-arm assembler. I'm going > >> to > > > >> try: > > Looks like you have an ARM compiler/assembler because the assembler > > rejects the i386/amd64 "bswap" assembly command. > > > > Does anyone remember if the cross compiler has the cross include paths > > compiled into them or should there be a "-I" in the compile command to > > correctly expand the "#include " ? I thought the cross > > path was compiled into the cross compiler. > > > > You manually test the "cc" command with the included "-I" option. > > Adding -v to the command line might yield more interesting results in > tracking down the culprit header. > -Garrett I can add that: make toolchains succeeded. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 21:10:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03931106566B for ; Thu, 30 Jun 2011 21:10:01 +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 920228FC0C for ; Thu, 30 Jun 2011 21:10:01 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5UL23UE000440 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 15:02:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 30 Jun 2011 15:01:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106301122.36155.hselasky@c2i.net> <4E0CA0D0.6050500@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 30 Jun 2011 15:02:05 -0600 (MDT) Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Crossbuild failure on 8-stable 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, 30 Jun 2011 21:10:02 -0000 Shouldn't that be 'make kernel-toolchain'? Warner On Jun 30, 2011, at 10:59 AM, Garrett Cooper wrote: > On Thu, Jun 30, 2011 at 9:14 AM, Mark Tinguely = wrote: >> On 6/30/2011 4:22 AM, Hans Petter Selasky wrote: >>>=20 >>> Hi, >>>=20 >>> Trying to cross build ARM fails in the following way on 8-stable: >>>=20 >>> 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Jun 29 13:09:23 UTC 2011 >>>=20 >>> make toolchain TARGET=3Darm >>>=20 >>> Is this perhaps also an issue in 9-current? >>>=20 >>> Any clues? >>>=20 >>> cc -O -pipe -ffreestanding -Wformat -I/usr/src/lib/libstand = -msoft-float >>> - >>> D_STANDALONE -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY - >>> I/usr/src/lib/libstand/../libz -std=3Dgnu99 -c >>> /usr/src/lib/libstand/../libc/net/ntoh.c >>> {standard input}: Assembler messages: >>> {standard input}:27: Error: bad instruction `bswap r0' >>> {standard input}:53: Error: bad instruction `bswap r0' >>>=20 >>=20 >> and you also said: >>=20 >>> Tracing down the issue: >>>=20 >>> /usr/include/machine/endian.h >>>=20 >>> #define __byte_swap_int_var(x) \ >>> __extension__ ({ register __uint32_t __X =3D (x); \ >>> __asm ("bswap %0" : "+r" (__X)); \ >>> __X; }) >>>=20 >>> r0 looks like an ARM register passed to a non-arm assembler. I'm = going to >>> try: >>>=20 >>=20 >> Looks like you have an ARM compiler/assembler because the assembler = rejects >> the i386/amd64 "bswap" assembly command. >>=20 >> Does anyone remember if the cross compiler has the cross include = paths >> compiled into them or should there be a "-I" in the compile command = to >> correctly expand the "#include " ? I thought the = cross >> path was compiled into the cross compiler. >>=20 >> You manually test the "cc" command with the included "-I" option. >=20 > Adding -v to the command line might yield more interesting results in > tracking down the culprit header. > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 21:34:56 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8131065675 for ; Thu, 30 Jun 2011 21:34:56 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 87D6F8FC15 for ; Thu, 30 Jun 2011 21:34:56 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p5ULYttg084805; Thu, 30 Jun 2011 17:34:55 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p5ULYtEo084804; Thu, 30 Jun 2011 17:34:55 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 30 Jun 2011 17:34:55 -0400 From: David Schultz To: Eric McCorkle Message-ID: <20110630213455.GA84724@zim.MIT.EDU> Mail-Followup-To: Eric McCorkle , freebsd-current@freebsd.org References: <4E07EBA2.70500@shadowsun.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E07EBA2.70500@shadowsun.net> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Clang buildworld failure due to multiple definitions of __isnanf 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, 30 Jun 2011 21:34:56 -0000 On Sun, Jun 26, 2011, Eric McCorkle wrote: > I've both seen reports and experienced make buildworld with clang > failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what > fails), because lint1 is statically linked, and there is a definition of > __isnanf in both libc and libm. GCC, on the other hand, builds just fine. > > The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from > math.h. After some investigation, I figured out what's going on. > math.h includes a macro version of isnan, which expands out to an > expression that calls isnan, __isnanl, and __isnanf. GCC seems to treat > all of these as builtin functions, and implements them with its code > generator, rather than generating calls. Clang, on the other hand, does > not, which leaves calls to __isnanf in the resulting object file, which > will result in multiple definitions at link time. __isnanf is in both libraries for compatibility reasons. We can't remove it from libc because some historical programs that don't link against libm expect it to be there. We might be able to remove it from libm, but this would entail introducing a FBSD_1.2 version of the symbol in libc. Does your toolchain support symbol versioning? The libc symbol has version FBSD_1.0, while the libm version is FBSD_1.2. > A better solution, I think, is to modify math.h with something like this: > > #ifdef __clang__ > #define isnan(n) __builtin_isnan(n) > ... > #endif That breaks -fno-builtin, which is helpful sometimes (especially when the compiler builtins are bogus.) It also does nothing but paper over the problem... It would be nice to have a way to let the compiler use the builtin version of isnan() if -fbuiltin is enabled. The macro definitions are needed when the builtin is disabled or doesn't exist, but they have the unfortunate side-effect of preventing the builtin from being used at all, even when it is available. From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 22:34:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F74106566B; Thu, 30 Jun 2011 22:34:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A64A98FC12; Thu, 30 Jun 2011 22:34:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p5UMYgcP091024; Thu, 30 Jun 2011 18:34:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p5UMYgPF091023; Thu, 30 Jun 2011 22:34:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 30 Jun 2011 22:34:42 GMT Message-Id: <201106302234.p5UMYgPF091023@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Thu, 30 Jun 2011 22:34:44 -0000 TB --- 2011-06-30 21:40:13 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-30 21:40:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-30 21:40:13 - cleaning the object tree TB --- 2011-06-30 21:40:31 - cvsupping the source tree TB --- 2011-06-30 21:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-30 21:40:45 - building world TB --- 2011-06-30 21:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-30 21:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-30 21:40:45 - TARGET=sparc64 TB --- 2011-06-30 21:40:45 - TARGET_ARCH=sparc64 TB --- 2011-06-30 21:40:45 - TZ=UTC TB --- 2011-06-30 21:40:45 - __MAKE_CONF=/dev/null TB --- 2011-06-30 21:40:45 - cd /src TB --- 2011-06-30 21:40:45 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 30 21:40:45 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-30 22:34:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-30 22:34:42 - ERROR: failed to build world TB --- 2011-06-30 22:34:42 - 2453.42 user 603.88 system 3268.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 30 23:01:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704F7106566C; Thu, 30 Jun 2011 23:01:11 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8398FC1E; Thu, 30 Jun 2011 23:01:10 +0000 (UTC) Received: by vws18 with SMTP id 18so2769751vws.13 for ; Thu, 30 Jun 2011 16:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DiNo8aiyCVTWmTP9Q7dyIS/SA6xCIbbRHA0bogi95hE=; b=T0Kzs2vbPdHMd4y0rKmoSdzTqk8QY2D67Txcgf0GIOav2YzuH7opmhyA7fwxEphlsR +/Ngv25fGAvlgUpENd1SSdTfDPDd6paTrmeWooOadd3ON4dYfiqDy2ZistYZyXQfOczP FAOJ1OBLR+n2Ft3YRVy2lIsdZeaBASym/RmGI= MIME-Version: 1.0 Received: by 10.221.13.196 with SMTP id pn4mr977716vcb.73.1309474870212; Thu, 30 Jun 2011 16:01:10 -0700 (PDT) Received: by 10.220.92.201 with HTTP; Thu, 30 Jun 2011 16:01:10 -0700 (PDT) In-Reply-To: <201106302234.p5UMYgPF091023@freebsd-current.sentex.ca> References: <201106302234.p5UMYgPF091023@freebsd-current.sentex.ca> Date: Thu, 30 Jun 2011 16:01:10 -0700 Message-ID: From: Garrett Cooper To: dfr@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [head tinderbox] failure on sparc64/sparc64 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, 30 Jun 2011 23:01:11 -0000 On Thu, Jun 30, 2011 at 3:34 PM, FreeBSD Tinderbox wrote: > TB --- 2011-06-30 21:40:13 - tinderbox 2.7 running on freebsd-current.sen= tex.ca > TB --- 2011-06-30 21:40:13 - starting HEAD tinderbox run for sparc64/spar= c64 > TB --- 2011-06-30 21:40:13 - cleaning the object tree > TB --- 2011-06-30 21:40:31 - cvsupping the source tree > TB --- 2011-06-30 21:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/sparc64/sparc64/supfile > TB --- 2011-06-30 21:40:45 - building world > TB --- 2011-06-30 21:40:45 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-06-30 21:40:45 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-06-30 21:40:45 - TARGET=3Dsparc64 > TB --- 2011-06-30 21:40:45 - TARGET_ARCH=3Dsparc64 > TB --- 2011-06-30 21:40:45 - TZ=3DUTC > TB --- 2011-06-30 21:40:45 - __MAKE_CONF=3D/dev/null > TB --- 2011-06-30 21:40:45 - cd /src > TB --- 2011-06-30 21:40:45 - /usr/bin/make -B buildworld >>>> World build started on Thu Jun 30 21:40:45 UTC 2011 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything > [...] > cc -O2 -pipe =A0-DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD966= 0_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -= DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl= -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/= loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loa= der/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libsta= nd/ -ffreestanding -std=3Dgnu99 =A0-c /src/sys/boot/sparc64/loader/../../co= mmon/devopen.c > cc -O2 -pipe =A0-DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD966= 0_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -= DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl= -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/= loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loa= der/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libsta= nd/ -ffreestanding -std=3Dgnu99 =A0-c /src/sys/boot/sparc64/loader/../../co= mmon/disk.c > /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openm= br': > /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR= ' undeclared (first use in this function) > /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undecl= ared identifier is reported only once > /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each fun= ction it appears in.) > /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_print= bsdslice': > /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR= ' undeclared (first use in this function) > *** Error code 1 > > Stop in /src/sys/boot/sparc64/loader. > *** Error code 1 > > Stop in /src/sys/boot/sparc64. > *** Error code 1 > > Stop in /src/sys/boot. > *** Error code 1 > > Stop in /src/sys. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 It looks like r223695 broke sparc64: $ grep -B 3 -r LABELSECTOR /usr/include/ /usr/include/sys/disklabel.h-/* XXX these should be defined per controller (or drive) elsewhere, not here! */ /usr/include/sys/disklabel.h-#if defined(__i386__) || defined(__amd64__) || defined(__arm__) || \ /usr/include/sys/disklabel.h- defined(__ia64__) || defined(__powerpc__) || defined(__mips__) /usr/include/sys/disklabel.h:#define LABELSECTOR 1 /* sector containing label */ Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 04:08:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E6D1065670 for ; Fri, 1 Jul 2011 04:08:52 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id DCBD88FC0C for ; Fri, 1 Jul 2011 04:08:51 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward4.mail.yandex.net (Yandex) with ESMTP id 19A7B501F0B; Fri, 1 Jul 2011 08:08:50 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1309493330; bh=ViIp7UuvAb9Tj/Qja+GlrDKZ/7HD2crbA+wWeqR/6OY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZwOV1GaXczGAU5XKlLVsaO/qR+j5mIdaDeef3TNEHhHXOvwy4UWMlmV8dipNWlkMH 6FhfzXBDAwm/eHZOIZVWj2L0kCBrjhH7yHxN2NFygQXP04evxeRIZGplNlEd2+VdC4 P11t+KAK6nN5z0sJoMqBuoouG6N/N8yIwlvIwOC0= Received: from [127.0.0.1] (unknown [77.72.136.146]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id BED915D100B0; Fri, 1 Jul 2011 08:08:49 +0400 (MSD) Message-ID: <4E0D4851.7020005@yandex.ru> Date: Fri, 01 Jul 2011 08:08:49 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Tim Gustafson References: <2021750843.160454.1309455603717.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <2021750843.160454.1309455603717.JavaMail.root@mail-01.cse.ucsc.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Yandex-Spam: 1 Cc: Niclas Zeising , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 01 Jul 2011 04:08:52 -0000 On 30.06.2011 21:40, Tim Gustafson wrote: >> I think you need something along the line of ifconfig_bce0_alias0="inet 1.2.3.5 netmask ...", >> notice the 'inet', since aliasN can be used for both inet and inet6. > > Got it, thanks! > > I assume that's also recommended for the primary interface as well? I've added the "inet" prefix > to both lines and it is working. Thanks! There is also ipv4_addrs_IF variable, you can use it: ipv4_addrs_bce0="1.2.3.4/22 1.2.3.5/32" -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 04:26:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFFA106564A; Fri, 1 Jul 2011 04:26:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 011128FC19; Fri, 1 Jul 2011 04:25:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p614PxdS064847; Fri, 1 Jul 2011 00:25:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p614Pw9H064838; Fri, 1 Jul 2011 04:25:58 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 04:25:58 GMT Message-Id: <201107010425.p614Pw9H064838@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Fri, 01 Jul 2011 04:26:00 -0000 TB --- 2011-07-01 03:30:49 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 03:30:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 03:30:49 - cleaning the object tree TB --- 2011-07-01 03:30:58 - cvsupping the source tree TB --- 2011-07-01 03:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 03:31:11 - building world TB --- 2011-07-01 03:31:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 03:31:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 03:31:11 - TARGET=sparc64 TB --- 2011-07-01 03:31:11 - TARGET_ARCH=sparc64 TB --- 2011-07-01 03:31:11 - TZ=UTC TB --- 2011-07-01 03:31:11 - __MAKE_CONF=/dev/null TB --- 2011-07-01 03:31:11 - cd /src TB --- 2011-07-01 03:31:11 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 03:31:12 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 04:25:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 04:25:58 - ERROR: failed to build world TB --- 2011-07-01 04:25:58 - 2500.08 user 607.30 system 3308.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 05:01:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4B8510665F7 for ; Fri, 1 Jul 2011 05:01:37 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id 83C2B8FC12 for ; Fri, 1 Jul 2011 05:01:37 +0000 (UTC) Received: from Uller.local (c-76-99-53-162.hsd1.pa.comcast.net [76.99.53.162]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id p6151ar9034816 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2011 01:01:36 -0400 (EDT) (envelope-from sean@coreitpro.com) Message-ID: <4E0D54AA.7000808@coreitpro.com> Date: Fri, 01 Jul 2011 01:01:30 -0400 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> <4E0CA5D4.4010002@coreitpro.com> In-Reply-To: <4E0CA5D4.4010002@coreitpro.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 01 Jul 2011 05:01:37 -0000 Ugh - bonnie++ creates a file that is twice the size of available memory, and I have 16G of swap available. While ZFS already had most of the memory wired for ARC. I shouldn't be surprised that the box was printing "swap zone exhausted" I'm an idiot. Can we replace the warning message with one about dumb operators? ;) -- Sean Collins Core IT Pro, LLC www.coreitpro.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 06:42:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E675106566B for ; Fri, 1 Jul 2011 06:42:31 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 17BB88FC12 for ; Fri, 1 Jul 2011 06:42:31 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 6E7EB59E78; Fri, 1 Jul 2011 08:42:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <4E0D54AA.7000808@coreitpro.com> Date: Fri, 1 Jul 2011 08:42:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> <4E0CA5D4.4010002@coreitpro.com> <4E0D54AA.7000808@coreitpro.com> To: Sean M. Collins X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 01 Jul 2011 06:42:31 -0000 Am 01.07.2011 um 07:01 schrieb Sean M. Collins: > Ugh - bonnie++ creates a file that is twice the size of available > memory, and I have 16G of swap available. While ZFS already had most = of > the memory wired for ARC. I shouldn't be surprised that the box was > printing "swap zone exhausted" The box shouldn't wedge in this situation. If tmpfs can create a memory = starvation situation on the kernel level, it is not production ready. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 10:19:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704A8106564A; Fri, 1 Jul 2011 10:19:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 411A98FC0A; Fri, 1 Jul 2011 10:19:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p61AJ9RV026010; Fri, 1 Jul 2011 06:19:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p61AJ91N025987; Fri, 1 Jul 2011 10:19:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 10:19:09 GMT Message-Id: <201107011019.p61AJ91N025987@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Fri, 01 Jul 2011 10:19:10 -0000 TB --- 2011-07-01 09:23:48 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 09:23:48 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 09:23:48 - cleaning the object tree TB --- 2011-07-01 09:23:56 - cvsupping the source tree TB --- 2011-07-01 09:23:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 09:24:10 - building world TB --- 2011-07-01 09:24:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 09:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 09:24:10 - TARGET=sparc64 TB --- 2011-07-01 09:24:10 - TARGET_ARCH=sparc64 TB --- 2011-07-01 09:24:10 - TZ=UTC TB --- 2011-07-01 09:24:10 - __MAKE_CONF=/dev/null TB --- 2011-07-01 09:24:10 - cd /src TB --- 2011-07-01 09:24:10 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 09:24:12 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 10:19:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 10:19:09 - ERROR: failed to build world TB --- 2011-07-01 10:19:09 - 2503.76 user 605.66 system 3320.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 11:52:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2DEC1065675 for ; Fri, 1 Jul 2011 11:52:35 +0000 (UTC) (envelope-from ti.bugmenot@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 683158FC13 for ; Fri, 1 Jul 2011 11:52:34 +0000 (UTC) Received: by gyf3 with SMTP id 3so1660940gyf.13 for ; Fri, 01 Jul 2011 04:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=zgbu3hf/Q5tZNRC7q5GClR/Qfy5kyI5NPHUuLaOW/Gs=; b=uVH4nQ6O6Zq8u3s/43MK7JQAPx3k+7lI4Kya3ako/1FgwkqLylbJdCeeFkGSYHrI5y fMpCXrAbJRmkK2dlITKrPb1QbE7Z1rFy7hWGm1/sQcBlX+0Yfd0JoJ/dfAMEpqCvl/LM C6Y6ZldP/ncivd0+qhEbWbduG1F9LPQHbBrzM= MIME-Version: 1.0 Received: by 10.236.185.169 with SMTP id u29mr4164799yhm.108.1309519295193; Fri, 01 Jul 2011 04:21:35 -0700 (PDT) Sender: ti.webdev@gmail.com X-Google-Sender-Delegation: ti.webdev@gmail.com Received: by 10.147.82.1 with HTTP; Fri, 1 Jul 2011 04:21:35 -0700 (PDT) Date: Fri, 1 Jul 2011 17:21:35 +0600 X-Google-Sender-Auth: W-UceNYx7nGU_TKXGi_j3CSLwQA Message-ID: From: ti bugmenot To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 11:52:35 -0000 I met with the same problem. I do not know how to solve this problem: http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022022.html % uname -a FreeBSD td.local 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r223706M: Fri Jul 1 16:50:12 YEKT 2011 root@td.local:/usr/obj/usr/src/sys/TI amd64 % dmesg ugen5.2: at usbus5 ugen6.2: at usbus6 ukbd0: on usbus5 kbd2 at ukbd0 ukbd2: on usbus6 ums0: on usbus5 kbd3 at ukbd2 ums0: 8 buttons and [XYZT] coordinates ID=1 ums1: on usbus6 ums1: 16 buttons and [XYZT] coordinates ID=0 % usbconfig -u 6 -a 2 dump_device_desc dump_curr_config_desc ugen6.2: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x09da idProduct = 0x054f bcdDevice = 0x0102 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0000 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x003b bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0001 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x11 RAW dump: 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x84, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0003 wMaxPacketSize = 0x000c bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0003 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x0002 iInterface = 0x0000 Additional Descriptor bLength = 0x09 bDescriptorType = 0x21 bDescriptorSubType = 0x11 RAW dump: 0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x57, 0x08 | 0x00 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0003 wMaxPacketSize = 0x0008 bInterval = 0x0001 bRefresh = 0x0000 bSynchAddress = 0x0000 ---------- Not work: #define UKBD_NKEYCODE 8 ---------- Not work: if (sc->sc_kbd_id != 0) { /* check and remove HID ID byte */ usbd_copy_out(pc, 0, &id, 1); if (id != sc->sc_kbd_id) { DPRINTF("wrong HID ID\n"); goto tr_setup; } offset = 1; len--; } else { offset = 0; } + if (len == 12) { + offset += 2; + len -= 2; + } + if (len == 11) { + offset += 1; + len -= 1; + } From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 12:07:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228E4106566B for ; Fri, 1 Jul 2011 12:07:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id A8B468FC12 for ; Fri, 1 Jul 2011 12:07:28 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yfIOS+81wnQIz0UwZPDdWOvE/jQxEvyI9Z1xC25I9wc= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=dq2f58wT9zoA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=i1vy5U1fkvM8fQN9xZYA:9 a=wPNLvfGTeEIA:10 a=LhOa-flM-ecA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 148303357; Fri, 01 Jul 2011 14:07:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 1 Jul 2011 14:05:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107011405.41569.hselasky@c2i.net> Cc: ti bugmenot Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 12:07:29 -0000 On Friday 01 July 2011 13:21:35 ti bugmenot wrote: > I met with the same problem. I do not know how to solve this problem: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022022.html > Hi, Our USB keyboard driver is very simple and does not parse the HID descriptors of the keyboard. Maybe that is the reason it is not working. Try to set the "UQ_KBD_BOOTPROTO" for your keyboard. usbconfig -d X.Y add_quirk UQ_KBD_BOOTPROTO Replug keyboard. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 14:15:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0EB1065670 for ; Fri, 1 Jul 2011 14:15:03 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A74758FC18 for ; Fri, 1 Jul 2011 14:15:03 +0000 (UTC) Received: by iyb11 with SMTP id 11so3870578iyb.13 for ; Fri, 01 Jul 2011 07:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TmE//XBqrwdk00o0hyY4jZhttzyeRWUuU9l7KG0x0to=; b=Zj7GguIE6Alq9tonPIym3Tqx4yQO62ChgNvflnpQufQsrDqJ8yFuvDSnRGbUoM+MIy CFHlSXbwOlEWgiBa2RcgFkSnR1kHEB6IUdBC3r8aB74yP94ET/mcJ8B87Sbf4pAXk15K lN7OykP/jGr8LMnYfaDi2lk8oL3j17rKQS894= Received: by 10.231.81.139 with SMTP id x11mr2809883ibk.143.1309529703088; Fri, 01 Jul 2011 07:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.38.5 with HTTP; Fri, 1 Jul 2011 07:14:43 -0700 (PDT) In-Reply-To: <201107011405.41569.hselasky@c2i.net> References: <201107011405.41569.hselasky@c2i.net> From: Eir Nym Date: Fri, 1 Jul 2011 18:14:43 +0400 Message-ID: To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, ti bugmenot Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:15:03 -0000 On 1 July 2011 16:05, Hans Petter Selasky wrote: > On Friday 01 July 2011 13:21:35 ti bugmenot wrote: >> I met with the same problem. I do not know how to solve this problem: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022022.html >> > > Hi, > > Our USB keyboard driver is very simple and does not parse the HID descriptors > of the keyboard. Maybe that is the reason it is not working. > > > Try to set the "UQ_KBD_BOOTPROTO" for your keyboard. > > usbconfig -d X.Y add_quirk UQ_KBD_BOOTPROTO > > Replug keyboard. > I have same with MS USB keyboard (only numlock, capslock are working). r221858 doesn't have this bug(?) -- Eir Nym > --HPS > _______________________________________________ > 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 1 14:18:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B8A106566B for ; Fri, 1 Jul 2011 14:18:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1108FC12 for ; Fri, 1 Jul 2011 14:18:58 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=EIZfbDsN8gr1c4B7uGrP4foh/gtfZ6zZRee2cLtKwTU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=dq2f58wT9zoA:10 a=WQU8e4WWZSUA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=5WVfNpf-Oamf3Cj9xQQA:9 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 147937927; Fri, 01 Jul 2011 16:18:57 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 1 Jul 2011 16:17:12 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201107011405.41569.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107011617.12268.hselasky@c2i.net> Cc: Eir Nym , ti bugmenot Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:18:59 -0000 On Friday 01 July 2011 16:14:43 Eir Nym wrote: > On 1 July 2011 16:05, Hans Petter Selasky wrote: > > On Friday 01 July 2011 13:21:35 ti bugmenot wrote: > >> I met with the same problem. I do not know how to solve this problem: > >> > >> http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022022.h > >> tml > > > > Hi, > > > > Our USB keyboard driver is very simple and does not parse the HID > > descriptors of the keyboard. Maybe that is the reason it is not working. > > > > > > Try to set the "UQ_KBD_BOOTPROTO" for your keyboard. > > > > usbconfig -d X.Y add_quirk UQ_KBD_BOOTPROTO > > > > Replug keyboard. > > I have same with MS USB keyboard (only numlock, capslock are working). > r221858 doesn't have this bug(?) What happens if you unload ums ? Maybe there is a driver conflict? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 14:29:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD641065672 for ; Fri, 1 Jul 2011 14:29:51 +0000 (UTC) (envelope-from hhasenbe@techfak.uni-bielefeld.de) Received: from smarthost.TechFak.Uni-Bielefeld.DE (smarthost.TechFak.Uni-Bielefeld.DE [129.70.137.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF9F8FC1B for ; Fri, 1 Jul 2011 14:29:51 +0000 (UTC) Received: from [129.70.104.75] (navy.spectrum.uni-bielefeld.de [129.70.104.75]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hhasenbe) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 7361BA0; Fri, 1 Jul 2011 16:13:55 +0200 (CEST) Message-ID: <4E0DD61F.10007@techfak.uni-bielefeld.de> Date: Fri, 01 Jul 2011 16:13:51 +0200 From: Hendrik Hasenbein User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: Tim Gustafson References: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <841737947.159814.1309447573370.JavaMail.root@mail-01.cse.ucsc.edu> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92CC51D98B9161D584CAA0D1" Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 01 Jul 2011 14:29:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92CC51D98B9161D584CAA0D1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30.06.2011 17:26, Tim Gustafson wrote: > Hi, >=20 > I've installed FreeBSD 9 on a new server because 8.2 doesn't have > support for the LSI SAS2008 controller. I've also built the system > as a ZFS-root box, and I have to say that I'm quite happy with the > disk performance: we're getting about 500MB/s write and 675MB/s read. > All in all, I'm very happy with FreeBSD 9. Hi, it is nice that you give 9 a chance, but there is LSI SAS2008 support in 8.2, too. mata ne, Hendrik --------------enig92CC51D98B9161D584CAA0D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4N1iMACgkQytd3dYHoMPVODwCZAYCHfDWCMDPJ8RSr6C9dvEEZ klMAnjm2pmrOD5bL/bP73S+PA33L9bZQ =uI6h -----END PGP SIGNATURE----- --------------enig92CC51D98B9161D584CAA0D1-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 14:44:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C42106566C for ; Fri, 1 Jul 2011 14:44:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id CAF118FC1B for ; Fri, 1 Jul 2011 14:44:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=Ki88u+3nwejNRg6MOseuLmL2vomBRNHvHPpCRMZep5s= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=dq2f58wT9zoA:10 a=WQU8e4WWZSUA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=5WVfNpf-Oamf3Cj9xQQA:9 a=QEXdDO2ut3YA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 147098551; Fri, 01 Jul 2011 16:44:14 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 1 Jul 2011 16:42:30 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201107011405.41569.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107011642.30180.hselasky@c2i.net> Cc: Eir Nym , ti bugmenot Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 14:44:17 -0000 On Friday 01 July 2011 16:14:43 Eir Nym wrote: > On 1 July 2011 16:05, Hans Petter Selasky wrote: > > On Friday 01 July 2011 13:21:35 ti bugmenot wrote: > >> I met with the same problem. I do not know how to solve this problem: > >> > >> http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022022.h > >> tml > > > > Hi, > > > > Our USB keyboard driver is very simple and does not parse the HID > > descriptors of the keyboard. Maybe that is the reason it is not working. > > > > > > Try to set the "UQ_KBD_BOOTPROTO" for your keyboard. > > > > usbconfig -d X.Y add_quirk UQ_KBD_BOOTPROTO > > > > Replug keyboard. > > I have same with MS USB keyboard (only numlock, capslock are working). > r221858 doesn't have this bug(?) > Try to dump the HID descriptor of your device: usbconfig -d X.Y do_request 0x81 0x06 0x2200 0 0x100 That might be helpful. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 14:45:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A7C31065672 for ; Fri, 1 Jul 2011 14:45:01 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 066388FC1D for ; Fri, 1 Jul 2011 14:45:00 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id 9B9BD777C004; Fri, 1 Jul 2011 07:45:00 -0700 (PDT) Date: Fri, 1 Jul 2011 07:45:00 -0700 (PDT) From: Tim Gustafson To: Hendrik Hasenbein Message-ID: <449419606.162806.1309531500527.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: <4E0DD61F.10007@techfak.uni-bielefeld.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 01 Jul 2011 14:45:01 -0000 > it is nice that you give 9 a chance, but there is LSI SAS2008 support > in 8.2, too. I tried booting off an 8.2 release disc and it did not see the controller. I don't have a dmesg from booting off that disc so I can't offer much more detail other than what I have in my dmesg now: mps0: port 0xfc00-0xfcff mem 0xef5f0000-0xef5fffff,0xef580000-0xef5bffff irq 44 at device 0.0 on pci1 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 15:33:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E454C1065673 for ; Fri, 1 Jul 2011 15:33:46 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id A76358FC08 for ; Fri, 1 Jul 2011 15:33:46 +0000 (UTC) Received: from Uller.local (static-74-109-127-34.phlapa.fios.verizon.net [74.109.127.34]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id p61FXj3n063009 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2011 11:33:46 -0400 (EDT) (envelope-from sean@coreitpro.com) Message-ID: <4E0DE8D6.3090806@coreitpro.com> Date: Fri, 01 Jul 2011 11:33:42 -0400 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> <4E0CA5D4.4010002@coreitpro.com> <4E0D54AA.7000808@coreitpro.com> <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> In-Reply-To: <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 01 Jul 2011 15:33:47 -0000 On 7/1/11 2:42 AM, Stefan Bethke wrote: > The box shouldn't wedge in this situation. If tmpfs can create > a memory starvation situation on the kernel level, it is not production ready. The full message was "swap zone exhausted, increase kern.maxswzone" - I guess that actual swap wasn't exhausted, but just space for metadata. So in tmpfs' defense, AMD64 boots with a kern.maxswzone of 32MB like i386, which only allows ~7 GB of swap to be allocated. I'll see if I can get the machine to wedge again, then increase kern.maxswzone, and repeat. -- Sean Collins Core IT Pro, LLC www.coreitpro.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 16:08:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C98106566B; Fri, 1 Jul 2011 16:08:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 74FC68FC12; Fri, 1 Jul 2011 16:08:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p61G81VN085948; Fri, 1 Jul 2011 12:08:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p61G81mm085922; Fri, 1 Jul 2011 16:08:01 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 16:08:01 GMT Message-Id: <201107011608.p61G81mm085922@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on 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: Fri, 01 Jul 2011 16:08:02 -0000 TB --- 2011-07-01 15:12:58 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 15:12:58 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 15:12:58 - cleaning the object tree TB --- 2011-07-01 15:13:06 - cvsupping the source tree TB --- 2011-07-01 15:13:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 15:13:20 - building world TB --- 2011-07-01 15:13:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 15:13:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 15:13:20 - TARGET=sparc64 TB --- 2011-07-01 15:13:20 - TARGET_ARCH=sparc64 TB --- 2011-07-01 15:13:20 - TZ=UTC TB --- 2011-07-01 15:13:20 - __MAKE_CONF=/dev/null TB --- 2011-07-01 15:13:20 - cd /src TB --- 2011-07-01 15:13:20 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 15:13:20 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 16:08:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 16:08:01 - ERROR: failed to build world TB --- 2011-07-01 16:08:01 - 2499.77 user 607.25 system 3302.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 16:33:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9625106564A for ; Fri, 1 Jul 2011 16:33:18 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 618398FC0A for ; Fri, 1 Jul 2011 16:33:18 +0000 (UTC) Received: by wyg24 with SMTP id 24so3205351wyg.13 for ; Fri, 01 Jul 2011 09:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5RKE3R8q19ule7CoYWwgzEHOFrB3dzfqNRDKBzOfPRw=; b=AIycsbMh+C/yNIaH4ESLI0tQXiPJhJF7Xn7aYSKL/X9UlgmJzXIRxiQ7pgogHoiykF UBrjYNumuWHHZ6eUwXU5tl0vIhTqCEnsQrcXG/ahYXfkLnF1e13eAetItxIEhE3A/0IJ w+rnUBB6gvLsRW/pZR3hrwo2ztLa/w0i2SVaA= MIME-Version: 1.0 Received: by 10.216.133.194 with SMTP id q44mr3059373wei.56.1309536297611; Fri, 01 Jul 2011 09:04:57 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.135.169 with HTTP; Fri, 1 Jul 2011 09:04:57 -0700 (PDT) In-Reply-To: <449419606.162806.1309531500527.JavaMail.root@mail-01.cse.ucsc.edu> References: <4E0DD61F.10007@techfak.uni-bielefeld.de> <449419606.162806.1309531500527.JavaMail.root@mail-01.cse.ucsc.edu> Date: Fri, 1 Jul 2011 09:04:57 -0700 X-Google-Sender-Auth: jkU2H1uDsodzj_p5r8eBmmX1RUY Message-ID: From: Artem Belevich To: Tim Gustafson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hendrik Hasenbein , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 01 Jul 2011 16:33:18 -0000 On Fri, Jul 1, 2011 at 7:45 AM, Tim Gustafson wrote: >> it is nice that you give 9 a chance, but there is LSI SAS2008 support >> in 8.2, too. > > I tried booting off an 8.2 release disc and it did not see the controller= . More specifically, it's in 8.2-STABLE. mps driver was MFC'ed on Feb 18th, 2011. It didn't make it into 8.2-RELEASE. Try mfsBSD image from http://mfsbsd.vx.sk/ -- it may work better. --Artem > > I don't have a dmesg from booting off that disc so I can't offer much mor= e detail other than what I have in my dmesg now: > > mps0: port 0xfc00-0xfcff mem 0xef5f0000-0xef5fffff,0xef5800= 00-0xef5bffff irq 44 at device 0.0 on pci1 > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D- > Tim Gustafson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tjg@soe.ucsc.edu > Baskin School of Engineering =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 831-459-5354 > UC Santa Cruz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Baskin Engineering 317B > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D- > _______________________________________________ > 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 1 16:34:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509BA106564A for ; Fri, 1 Jul 2011 16:34:27 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.154.0.151]) by mx1.freebsd.org (Postfix) with ESMTP id DEB908FC16 for ; Fri, 1 Jul 2011 16:34:26 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Qcgfg-0005ch-RX for current@freebsd.org; Fri, 01 Jul 2011 18:34:24 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qcgff-0000dX-MN for current@freebsd.org; Fri, 01 Jul 2011 18:34:23 +0200 Message-Id: To: current@freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Fri, 01 Jul 2011 18:34:23 +0200 Cc: Subject: cvsup servers broken? 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, 01 Jul 2011 16:34:27 -0000 Hi I've been seeing this all day: # cvsup -L2 /root/supfile-cvs Parsing supfile "/root/supfile-cvs" Connecting to cvsup6.freebsd.org Connected to cvsup6.freebsd.org Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection cvsroot-common/cvs Updating collection src-all/cvs Updating collection ports-all/cvs Detailer failed: Premature EOF from server Will retry at 18:32:04 Which coincides with: (Timestamps UTC+0200) 18:27:12.004603 IP 41.154.88.19.52564 > 128.205.32.24.5999: Flags [.], ack 102802, win 8225, options [nop,nop,TS val 3651903 ecr 3047757560], length 1400 18:27:12.006713 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14659685, win 8225, options [nop,nop,TS val 3047757730 ecr 3651472], length 0 18:27:12.145079 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14662485, win 8050, options [nop,nop,TS val 3047757867 ecr 3651688], length 10 18:27:12.157567 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [.], ack 14663885, win 8225, options [nop,nop,TS val 3047757880 ecr 3651688], length 0 18:27:12.245335 IP 41.154.88.19.52564 > 128.205.32.24.5999: Flags [P.], ack 102812, win 8225, options [nop,nop,TS val 3652146 ecr 3047757867], length 342 18:27:12.578479 IP 128.205.32.24.5999 > 41.154.88.19.52564: Flags [R], seq 1059787102, win 0, length 0 It looks like the server is just exiting. I've tested cvsup4 and cvsup5 as well. Is cvsup deprecated these days or has something else broken it? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 16:52:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6255106566B for ; Fri, 1 Jul 2011 16:52:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 12E0D8FC12 for ; Fri, 1 Jul 2011 16:52:47 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=7KD0iiTHYGd0xbPMAUtcJ3OZoqPCTpa2X22hnPESm4A= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=dq2f58wT9zoA:10 a=WQU8e4WWZSUA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=C16scZYFqgoEGfmZZv4A:9 a=wPNLvfGTeEIA:10 a=vfCPAtCtVIxylwUumPIA:9 a=U_hLN8PZESYswqhnplgA:7 a=j-x2Y7PY75qzyMru:21 a=IARwyfoek68CsnTg:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 145793342; Fri, 01 Jul 2011 18:52:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 1 Jul 2011 18:51:00 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_0rfDO3KV9PQSXCz" Message-Id: <201107011851.00989.hselasky@c2i.net> Cc: ti bugmenot Subject: Re: keyboard driver problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:52:48 -0000 --Boundary-00=_0rfDO3KV9PQSXCz Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Can you try the attached patch and report back? Please also send me your HID descriptor: usbconfig -d X.Y do_request 0x81 0x06 0x2200 0 0x100 --HPS --Boundary-00=_0rfDO3KV9PQSXCz Content-Type: text/x-patch; charset="iso-8859-1"; name="usb_keyboard_hid_compliance.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usb_keyboard_hid_compliance.diff" === input/ukbd.c ================================================================== --- input/ukbd.c (revision 223581) +++ input/ukbd.c (local) @@ -108,9 +108,10 @@ #define UKBD_IN_BUF_SIZE (2*(UKBD_NMOD + (2*UKBD_NKEYCODE))) /* bytes */ #define UKBD_IN_BUF_FULL (UKBD_IN_BUF_SIZE / 2) /* bytes */ #define UKBD_NFKEY (sizeof(fkey_tab)/sizeof(fkey_tab[0])) /* units */ +#define UKBD_OUT_BUF_SIZE 16 /* bytes */ struct ukbd_data { - uint8_t modifiers; + uint16_t modifiers; #define MOD_CONTROL_L 0x01 #define MOD_CONTROL_R 0x10 #define MOD_SHIFT_L 0x02 @@ -119,9 +120,10 @@ #define MOD_ALT_R 0x40 #define MOD_WIN_L 0x08 #define MOD_WIN_R 0x80 - uint8_t reserved; +/* internal */ +#define MOD_EJECT 0x0100 +#define MOD_FN 0x0200 uint8_t keycode[UKBD_NKEYCODE]; - uint8_t exten[8]; }; enum { @@ -137,6 +139,18 @@ fkeytab_t sc_fkeymap[UKBD_NFKEY]; struct hid_location sc_loc_apple_eject; struct hid_location sc_loc_apple_fn; + struct hid_location sc_loc_ctrl_l; + struct hid_location sc_loc_ctrl_r; + struct hid_location sc_loc_shift_l; + struct hid_location sc_loc_shift_r; + struct hid_location sc_loc_alt_l; + struct hid_location sc_loc_alt_r; + struct hid_location sc_loc_win_l; + struct hid_location sc_loc_win_r; + struct hid_location sc_loc_events; + struct hid_location sc_loc_numlock; + struct hid_location sc_loc_capslock; + struct hid_location sc_loc_scrolllock; struct usb_callout sc_callout; struct ukbd_data sc_ndata; struct ukbd_data sc_odata; @@ -155,30 +169,60 @@ uint32_t sc_buffered_char[2]; #endif uint32_t sc_flags; /* flags */ -#define UKBD_FLAG_COMPOSE 0x0001 -#define UKBD_FLAG_POLLING 0x0002 -#define UKBD_FLAG_SET_LEDS 0x0004 -#define UKBD_FLAG_ATTACHED 0x0010 -#define UKBD_FLAG_GONE 0x0020 -#define UKBD_FLAG_APPLE_EJECT 0x0040 -#define UKBD_FLAG_APPLE_FN 0x0080 -#define UKBD_FLAG_APPLE_SWAP 0x0100 -#define UKBD_FLAG_TIMER_RUNNING 0x0200 +#define UKBD_FLAG_COMPOSE 0x00000001 +#define UKBD_FLAG_POLLING 0x00000002 +#define UKBD_FLAG_SET_LEDS 0x00000004 +#define UKBD_FLAG_ATTACHED 0x00000010 +#define UKBD_FLAG_GONE 0x00000020 +#define UKBD_FLAG_APPLE_EJECT 0x00000040 +#define UKBD_FLAG_APPLE_FN 0x00000080 +#define UKBD_FLAG_APPLE_SWAP 0x00000100 +#define UKBD_FLAG_TIMER_RUNNING 0x00000200 +#define UKBD_FLAG_CTRL_L 0x00000400 +#define UKBD_FLAG_CTRL_R 0x00000800 +#define UKBD_FLAG_SHIFT_L 0x00001000 +#define UKBD_FLAG_SHIFT_R 0x00002000 +#define UKBD_FLAG_ALT_L 0x00004000 +#define UKBD_FLAG_ALT_R 0x00008000 +#define UKBD_FLAG_WIN_L 0x00010000 +#define UKBD_FLAG_WIN_R 0x00020000 +#define UKBD_FLAG_EVENTS 0x00040000 +#define UKBD_FLAG_NUMLOCK 0x00080000 +#define UKBD_FLAG_CAPSLOCK 0x00100000 +#define UKBD_FLAG_SCROLLLOCK 0x00200000 int sc_mode; /* input mode (K_XLATE,K_RAW,K_CODE) */ int sc_state; /* shift/lock key state */ int sc_accents; /* accent key index (> 0) */ int sc_poll_tick_last; + int sc_led_size; + int sc_kbd_size; uint16_t sc_inputs; uint16_t sc_inputhead; uint16_t sc_inputtail; + uint16_t sc_modifiers; uint8_t sc_leds; /* store for async led requests */ uint8_t sc_iface_index; uint8_t sc_iface_no; + uint8_t sc_id_apple_eject; + uint8_t sc_id_apple_fn; + uint8_t sc_id_ctrl_l; + uint8_t sc_id_ctrl_r; + uint8_t sc_id_shift_l; + uint8_t sc_id_shift_r; + uint8_t sc_id_alt_l; + uint8_t sc_id_alt_r; + uint8_t sc_id_win_l; + uint8_t sc_id_win_r; + uint8_t sc_id_event; + uint8_t sc_id_numlock; + uint8_t sc_id_capslock; + uint8_t sc_id_scrolllock; + uint8_t sc_id_events; uint8_t sc_kbd_id; - uint8_t sc_led_id; + uint8_t sc_poll_detected; }; @@ -558,11 +602,10 @@ { struct ukbd_softc *sc = usbd_xfer_softc(xfer); struct usb_page_cache *pc; + uint8_t buffer[32]; uint8_t i; uint8_t offset; uint8_t id; - uint8_t apple_fn; - uint8_t apple_eject; int len; usbd_xfer_status(xfer, &len, NULL, NULL, NULL); @@ -586,67 +629,142 @@ } offset = 1; len--; + if (len == 0) { + DPRINTF("zero length data\n"); + goto tr_setup; + } } else { offset = 0; } - if (len > sizeof(sc->sc_ndata)) { - len = sizeof(sc->sc_ndata); - } + if (len > sizeof(buffer)) + len = sizeof(buffer); - if (len) { - memset(&sc->sc_ndata, 0, sizeof(sc->sc_ndata)); - usbd_copy_out(pc, offset, &sc->sc_ndata, len); + /* get data */ + usbd_copy_out(pc, offset, buffer, len); - if ((sc->sc_flags & UKBD_FLAG_APPLE_EJECT) && - hid_get_data((uint8_t *)&sc->sc_ndata, - len, &sc->sc_loc_apple_eject)) - apple_eject = 1; - else - apple_eject = 0; + /* clear temporary storage */ + memset(&sc->sc_ndata, 0, sizeof(sc->sc_ndata)); - if ((sc->sc_flags & UKBD_FLAG_APPLE_FN) && - hid_get_data((uint8_t *)&sc->sc_ndata, - len, &sc->sc_loc_apple_fn)) - apple_fn = 1; + /* scan through HID data */ + if ((sc->sc_flags & UKBD_FLAG_APPLE_EJECT) && + (id == sc->sc_id_apple_eject)) { + if (hid_get_data(buffer, len, &sc->sc_loc_apple_eject)) + sc->sc_modifiers |= MOD_EJECT; else - apple_fn = 0; -#ifdef USB_DEBUG - DPRINTF("apple_eject=%u apple_fn=%u\n", - apple_eject, apple_fn); + sc->sc_modifiers &= ~MOD_EJECT; + } + if ((sc->sc_flags & UKBD_FLAG_APPLE_FN) && + (id == sc->sc_id_apple_fn)) { + if (hid_get_data(buffer, len, &sc->sc_loc_apple_fn)) + sc->sc_modifiers |= MOD_FN; + else + sc->sc_modifiers &= ~MOD_FN; + } + if ((sc->sc_flags & UKBD_FLAG_CTRL_L) && + (id == sc->sc_id_ctrl_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_ctrl_l)) + sc-> sc_modifiers |= MOD_CONTROL_L; + else + sc-> sc_modifiers &= ~MOD_CONTROL_L; + } + if ((sc->sc_flags & UKBD_FLAG_CTRL_R) && + (id == sc->sc_id_ctrl_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_ctrl_r)) + sc->sc_modifiers |= MOD_CONTROL_R; + else + sc->sc_modifiers &= ~MOD_CONTROL_R; + } + if ((sc->sc_flags & UKBD_FLAG_SHIFT_L) && + (id == sc->sc_id_shift_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_shift_l)) + sc->sc_modifiers |= MOD_SHIFT_L; + else + sc->sc_modifiers &= ~MOD_SHIFT_L; + } + if ((sc->sc_flags & UKBD_FLAG_SHIFT_R) && + (id == sc->sc_id_shift_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_shift_r)) + sc->sc_modifiers |= MOD_SHIFT_R; + else + sc->sc_modifiers &= ~MOD_SHIFT_R; + } + if ((sc->sc_flags & UKBD_FLAG_ALT_L) && + (id == sc->sc_id_alt_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_alt_l)) + sc->sc_modifiers |= MOD_ALT_L; + else + sc->sc_modifiers &= ~MOD_ALT_L; + } + if ((sc->sc_flags & UKBD_FLAG_ALT_R) && + (id == sc->sc_id_alt_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_alt_r)) + sc->sc_modifiers |= MOD_ALT_R; + else + sc->sc_modifiers &= ~MOD_ALT_R; + } + if ((sc->sc_flags & UKBD_FLAG_WIN_L) && + (id == sc->sc_id_win_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_win_l)) + sc->sc_modifiers |= MOD_WIN_L; + else + sc->sc_modifiers &= ~MOD_WIN_L; + } + if ((sc->sc_flags & UKBD_FLAG_WIN_R) && + (id == sc->sc_id_win_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_win_r)) + sc->sc_modifiers |= MOD_WIN_R; + else + sc->sc_modifiers &= ~MOD_WIN_R; + } - if (sc->sc_ndata.modifiers) { - DPRINTF("mod: 0x%04x\n", sc->sc_ndata.modifiers); + sc->sc_ndata.modifiers = sc->sc_modifiers; + + if ((sc->sc_flags & UKBD_FLAG_EVENTS) && + (id == sc->sc_id_events)) { + i = sc->sc_loc_events.count; + if (i > UKBD_NKEYCODE) + i = UKBD_NKEYCODE; + if (i > len) + i = len; + while (i--) { + sc->sc_ndata.keycode[i] = + hid_get_data(buffer + i, len - i, + &sc->sc_loc_events); } + } + +#ifdef USB_DEBUG + DPRINTF("modifiers = 0x%04x\n", (int)sc->sc_modifiers); + for (i = 0; i < UKBD_NKEYCODE; i++) { + if (sc->sc_ndata.keycode[i]) { + DPRINTF("[%d] = 0x%02x\n", + (int)i, (int)sc->sc_ndata.keycode[i]); + } + } +#endif + if (sc->sc_modifiers & MOD_FN) { for (i = 0; i < UKBD_NKEYCODE; i++) { - if (sc->sc_ndata.keycode[i]) { - DPRINTF("[%d] = %d\n", i, sc->sc_ndata.keycode[i]); - } + sc->sc_ndata.keycode[i] = + ukbd_apple_fn(sc->sc_ndata.keycode[i]); } -#endif /* USB_DEBUG */ + } - if (apple_fn) { - for (i = 0; i < UKBD_NKEYCODE; i++) { - sc->sc_ndata.keycode[i] = - ukbd_apple_fn(sc->sc_ndata.keycode[i]); - } + if (sc->sc_flags & UKBD_FLAG_APPLE_SWAP) { + for (i = 0; i < UKBD_NKEYCODE; i++) { + sc->sc_ndata.keycode[i] = + ukbd_apple_swap(sc->sc_ndata.keycode[i]); } + } - if (sc->sc_flags & UKBD_FLAG_APPLE_SWAP) { - for (i = 0; i < UKBD_NKEYCODE; i++) { - sc->sc_ndata.keycode[i] = - ukbd_apple_swap(sc->sc_ndata.keycode[i]); - } - } + ukbd_interrupt(sc); - ukbd_interrupt(sc); - - if (!(sc->sc_flags & UKBD_FLAG_TIMER_RUNNING)) { - if (ukbd_any_key_pressed(sc)) { - ukbd_start_timer(sc); - } + if (!(sc->sc_flags & UKBD_FLAG_TIMER_RUNNING)) { + if (ukbd_any_key_pressed(sc)) { + ukbd_start_timer(sc); } } + case USB_ST_SETUP: tr_setup: if (sc->sc_inputs < UKBD_IN_BUF_FULL) { @@ -674,7 +792,10 @@ { struct usb_device_request req; struct usb_page_cache *pc; - uint8_t buf[2]; + uint8_t buf[UKBD_OUT_BUF_SIZE]; + uint8_t id; + uint8_t any; + int len; struct ukbd_softc *sc = usbd_xfer_softc(xfer); #ifdef USB_DEBUG @@ -685,37 +806,79 @@ switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: case USB_ST_SETUP: - if (sc->sc_flags & UKBD_FLAG_SET_LEDS) { - sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; + if (!(sc->sc_flags & UKBD_FLAG_SET_LEDS)) + break; + sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; - req.bmRequestType = UT_WRITE_CLASS_INTERFACE; - req.bRequest = UR_SET_REPORT; - USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); - req.wIndex[0] = sc->sc_iface_no; - req.wIndex[1] = 0; - req.wLength[1] = 0; + req.bmRequestType = UT_WRITE_CLASS_INTERFACE; + req.bRequest = UR_SET_REPORT; + USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); + req.wIndex[0] = sc->sc_iface_no; + req.wIndex[1] = 0; + req.wLength[1] = 0; - /* check if we need to prefix an ID byte */ - if (sc->sc_led_id != 0) { - req.wLength[0] = 2; - buf[0] = sc->sc_led_id; - buf[1] = sc->sc_leds; - } else { - req.wLength[0] = 1; - buf[0] = sc->sc_leds; - buf[1] = 0; - } + memset(buf, 0, sizeof(buf)); - pc = usbd_xfer_get_frame(xfer, 0); - usbd_copy_in(pc, 0, &req, sizeof(req)); + id = 0; + any = 0; + + /* Assumption: All led bits must be in the same ID. */ + + if ((sc->sc_flags & UKBD_FLAG_NUMLOCK) && + (sc->sc_leds & NLKED)) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_numlock, 1); + id = sc->sc_id_numlock; + any = 1; + } + + if ((sc->sc_flags & UKBD_FLAG_SCROLLLOCK) && + (sc->sc_leds & SLKED)) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_scrolllock, 1); + id = sc->sc_id_scrolllock; + any = 1; + } + + if ((sc->sc_flags & UKBD_FLAG_CAPSLOCK) && + (sc->sc_leds & CLKED)) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_capslock, 1); + id = sc->sc_id_capslock; + any = 1; + } + + /* if no leds, nothing to do */ + if (!any) + break; + + /* range check output report length */ + len = sc->sc_led_size; + if (len > (UKBD_OUT_BUF_SIZE - 1)) + len = (UKBD_OUT_BUF_SIZE - 1); + + /* check if we need to prefix an ID byte */ + if (id != 0) { + req.wLength[0] = 1 + len; + buf[0] = id; pc = usbd_xfer_get_frame(xfer, 1); usbd_copy_in(pc, 0, buf, sizeof(buf)); + usbd_xfer_set_frame_len(xfer, 1, 1 + len); + } else { + req.wLength[0] = len; + pc = usbd_xfer_get_frame(xfer, 1); + usbd_copy_in(pc, 0, buf + 1, sizeof(buf) - 1); + usbd_xfer_set_frame_len(xfer, 1, len); + } - usbd_xfer_set_frame_len(xfer, 0, sizeof(req)); - usbd_xfer_set_frame_len(xfer, 1, req.wLength[0]); - usbd_xfer_set_frames(xfer, 2); - usbd_transfer_submit(xfer); - } + /* setup control request last */ + pc = usbd_xfer_get_frame(xfer, 0); + usbd_copy_in(pc, 0, &req, sizeof(req)); + usbd_xfer_set_frame_len(xfer, 0, sizeof(req)); + + /* start data transfer */ + usbd_xfer_set_frames(xfer, 2); + usbd_transfer_submit(xfer); break; default: /* Error */ @@ -739,7 +902,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* Control pipe */ .direction = UE_DIR_ANY, - .bufsize = sizeof(struct usb_device_request) + 8, + .bufsize = sizeof(struct usb_device_request) + UKBD_OUT_BUF_SIZE, .callback = &ukbd_set_leds_callback, .timeout = 1000, /* 1 second */ }, @@ -880,43 +1043,129 @@ err = usbd_req_get_hid_desc(uaa->device, NULL, &hid_ptr, &hid_len, M_TEMP, uaa->info.bIfaceIndex); if (err == 0) { - uint8_t apple_keys = 0; - uint8_t temp_id; + /* check if there is an ID byte */ + sc->sc_kbd_size = hid_report_size(hid_ptr, hid_len, + hid_input, &sc->sc_kbd_id); + /* investigate if this is an Apple Keyboard */ if (hid_locate(hid_ptr, hid_len, HID_USAGE2(HUP_CONSUMER, HUG_APPLE_EJECT), hid_input, 0, &sc->sc_loc_apple_eject, &flags, - &temp_id)) { + &sc->sc_id_apple_eject)) { if (flags & HIO_VARIABLE) sc->sc_flags |= UKBD_FLAG_APPLE_EJECT | UKBD_FLAG_APPLE_SWAP; DPRINTFN(1, "Found Apple eject-key\n"); - apple_keys = 1; - sc->sc_kbd_id = temp_id; } if (hid_locate(hid_ptr, hid_len, HID_USAGE2(0xFFFF, 0x0003), hid_input, 0, &sc->sc_loc_apple_fn, &flags, - &temp_id)) { + &sc->sc_id_apple_fn)) { if (flags & HIO_VARIABLE) sc->sc_flags |= UKBD_FLAG_APPLE_FN; DPRINTFN(1, "Found Apple FN-key\n"); - apple_keys = 1; - sc->sc_kbd_id = temp_id; } - if (apple_keys == 0) { - /* - * Assume the first HID ID contains the - * keyboard data - */ - hid_report_size(hid_ptr, hid_len, - hid_input, &sc->sc_kbd_id); + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE0), + hid_input, 0, &sc->sc_loc_ctrl_l, &flags, + &sc->sc_id_ctrl_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CTRL_L; + DPRINTFN(1, "Found left control\n"); } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE4), + hid_input, 0, &sc->sc_loc_ctrl_r, &flags, + &sc->sc_id_ctrl_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CTRL_R; + DPRINTFN(1, "Found right control\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE1), + hid_input, 0, &sc->sc_loc_shift_l, &flags, + &sc->sc_id_shift_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SHIFT_L; + DPRINTFN(1, "Found left shift\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE5), + hid_input, 0, &sc->sc_loc_shift_r, &flags, + &sc->sc_id_shift_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SHIFT_R; + DPRINTFN(1, "Found right shift\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE2), + hid_input, 0, &sc->sc_loc_alt_l, &flags, + &sc->sc_id_alt_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_ALT_L; + DPRINTFN(1, "Found left alt\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE6), + hid_input, 0, &sc->sc_loc_alt_r, &flags, + &sc->sc_id_alt_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_ALT_R; + DPRINTFN(1, "Found right alt\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE3), + hid_input, 0, &sc->sc_loc_win_l, &flags, + &sc->sc_id_win_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_WIN_L; + DPRINTFN(1, "Found left GUI\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE7), + hid_input, 0, &sc->sc_loc_win_r, &flags, + &sc->sc_id_win_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_WIN_R; + DPRINTFN(1, "Found right GUI\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0x00), + hid_input, 0, &sc->sc_loc_events, &flags, + &sc->sc_id_events)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_EVENTS; + DPRINTFN(1, "Found right keyboard events\n"); + } - /* investigate if we need an ID-byte for the leds */ - hid_report_size(hid_ptr, hid_len, hid_output, &sc->sc_led_id); + sc->sc_led_size = hid_report_size(hid_ptr, hid_len, + hid_output, NULL); + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x01), + hid_output, 0, &sc->sc_loc_numlock, &flags, + &sc->sc_id_numlock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_NUMLOCK; + DPRINTFN(1, "Found keyboard numlock\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x02), + hid_output, 0, &sc->sc_loc_capslock, &flags, + &sc->sc_id_capslock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CAPSLOCK; + DPRINTFN(1, "Found keyboard capslock\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x03), + hid_output, 0, &sc->sc_loc_scrolllock, &flags, + &sc->sc_id_scrolllock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SCROLLLOCK; + DPRINTFN(1, "Found keyboard scrolllock\n"); + } free(hid_ptr, M_TEMP); } @@ -1468,10 +1717,6 @@ static int ukbd_ioctl(keyboard_t *kbd, u_long cmd, caddr_t arg) { - /* translate LED_XXX bits into the device specific bits */ - static const uint8_t ledmap[8] = { - 0, 2, 1, 3, 4, 6, 5, 7, - }; struct ukbd_softc *sc = kbd->kb_data; int i; @@ -1547,10 +1792,11 @@ #endif case KDSETLED: /* set keyboard LED */ /* NOTE: lock key state in "sc_state" won't be changed */ - if (*(int *)arg & ~LOCK_MASK) { + if (*(int *)arg & ~LOCK_MASK) return (EINVAL); - } + i = *(int *)arg; + /* replace CAPS LED with ALTGR LED for ALTGR keyboards */ if (sc->sc_mode == K_XLATE && kbd->kb_keymap->n_keys > ALTGR_OFFSET) { @@ -1559,9 +1805,9 @@ else i &= ~CLKED; } - if (KBD_HAS_DEVICE(kbd)) { - ukbd_set_leds(sc, ledmap[i & LED_MASK]); - } + if (KBD_HAS_DEVICE(kbd)) + ukbd_set_leds(sc, i); + KBD_LED_VAL(kbd) = *(int *)arg; break; case KDGKBSTATE: /* get lock key state */ === usb_hid.c ================================================================== --- usb_hid.c (revision 223581) +++ usb_hid.c (local) @@ -702,6 +702,43 @@ } /*------------------------------------------------------------------------* + * hid_put_data + *------------------------------------------------------------------------*/ +void +hid_put_data_unsigned(uint8_t *buf, usb_size_t len, + struct hid_location *loc, unsigned int value) +{ + uint32_t hpos = loc->pos; + uint32_t hsize = loc->size; + uint64_t data; + uint64_t mask; + uint32_t rpos; + uint8_t n; + + DPRINTFN(11, "hid_put_data: loc %d/%d = %u\n", hpos, hsize, value); + + /* Range check and limit */ + if (hsize == 0) + return; + if (hsize > 32) + hsize = 32; + + /* Put data in a safe way */ + rpos = (hpos / 8); + n = (hsize + 7) / 8; + data = ((uint64_t)value) << (hpos % 8); + mask = ((1ULL << hsize) - 1ULL) << (hpos % 8); + rpos += n; + while (n--) { + rpos--; + if (rpos < len) { + buf[rpos] &= ~(mask >> (8 * n)); + buf[rpos] |= (data >> (8 * n)); + } + } +} + +/*------------------------------------------------------------------------* * hid_is_collection *------------------------------------------------------------------------*/ int === usbhid.h ================================================================== --- usbhid.h (revision 223581) +++ usbhid.h (local) @@ -233,6 +233,8 @@ struct hid_location *loc); uint32_t hid_get_data_unsigned(const uint8_t *buf, usb_size_t len, struct hid_location *loc); +void hid_put_data_unsigned(uint8_t *buf, usb_size_t len, + struct hid_location *loc, unsigned int value); int hid_is_collection(const void *desc, usb_size_t size, uint32_t usage); struct usb_hid_descriptor *hid_get_descriptor_from_usb( struct usb_config_descriptor *cd, --Boundary-00=_0rfDO3KV9PQSXCz-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 17:10:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ECEC106564A; Fri, 1 Jul 2011 17:10:23 +0000 (UTC) (envelope-from tjg@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5819C8FC0C; Fri, 1 Jul 2011 17:10:23 +0000 (UTC) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mail-01.cse.ucsc.edu (Postfix) with ESMTP id 446871009C1C; Fri, 1 Jul 2011 10:10:23 -0700 (PDT) Date: Fri, 1 Jul 2011 10:10:23 -0700 (PDT) From: Tim Gustafson To: Artem Belevich Message-ID: <1427345072.163222.1309540223239.JavaMail.root@mail-01.cse.ucsc.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.114.49.22] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 ([unknown])/6.0.9_GA_2686) Cc: Hendrik Hasenbein , freebsd-current@freebsd.org Subject: Re: FreeBSD 9 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, 01 Jul 2011 17:10:23 -0000 > More specifically, it's in 8.2-STABLE. mps driver was MFC'ed on > Feb 18th, 2011. It didn't make it into 8.2-RELEASE. > > Try mfsBSD image from http://mfsbsd.vx.sk/ -- it may work better. That's what I used. I used the zpool 15 versions though; maybe the zpool 28 version had the new driver on it? At any rate, 9 is working for now, except for the net-snmp compilation problem which I got around by using the binary package. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 19:15:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB87C106566B for ; Fri, 1 Jul 2011 19:15:35 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDF78FC12 for ; Fri, 1 Jul 2011 19:15:35 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p61JFUcV090899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Jul 2011 21:15:30 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1309547731; bh=Lyn4U3END1KrY4w4W5mGaJh5AtUoijSpf4WdJgp9OsI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Y7eg8fVvt8h0sMIKml1j2DZo+x8HZyngT0ygUcjnAAmBZYwcjy/JiPsuhfVmWmdPS 2opkLpC774f7U2C8odqlIRVPlFWDG/+r3DzGCEGCcfF8jhaaNYcaotpAi7TYe2xQfP DfIxXmhxZWWD/GY/xsgWMbKNx9FW7TIDKWrm2SRg= Date: Fri, 1 Jul 2011 21:15:30 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: "Sean M. Collins" Message-ID: <20110701191530.GA76888@acme.spoerlein.net> Mail-Followup-To: "Sean M. Collins" , freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> <4E0CA5D4.4010002@coreitpro.com> <4E0D54AA.7000808@coreitpro.com> <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> <4E0DE8D6.3090806@coreitpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0DE8D6.3090806@coreitpro.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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, 01 Jul 2011 19:15:35 -0000 On Fri, 01.07.2011 at 11:33:42 -0400, Sean M. Collins wrote: > On 7/1/11 2:42 AM, Stefan Bethke wrote: > > The box shouldn't wedge in this situation. If tmpfs can create > > a memory starvation situation on the kernel level, it is not > production ready. > > The full message was "swap zone exhausted, increase kern.maxswzone" - I > guess that actual swap wasn't exhausted, but just space for metadata. So > in tmpfs' defense, AMD64 boots with a kern.maxswzone of 32MB like i386, > which only allows ~7 GB of swap to be allocated. > > I'll see if I can get the machine to wedge again, then increase > kern.maxswzone, and repeat. You just cannot use them both, yet. On amd64 with 8GB of RAM and a ZFS volume that is a couple of hundred G (and world-readable) - Run with tmpfs /tmp - Wait overnight for /etc/periodic/weekly/310.locate to kick in - Come back next morning and have 0 bytes free in /tmp Exporting the pool might bring the memory back, but with open files on the pool and of course in /tmp (think Xorg ...) this is impractical. Uli From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 19:48:11 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F63B106564A for ; Fri, 1 Jul 2011 19:48:11 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6A78FC12 for ; Fri, 1 Jul 2011 19:48:11 +0000 (UTC) Received: by iwr19 with SMTP id 19so4203912iwr.13 for ; Fri, 01 Jul 2011 12:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gLswCcuhbAejkGqsyPquyeab/2Ve85SmGTrVC9dLSGw=; b=fa+ln7B2GkOws5gzTUOadd5DfKemngfb3oWTD68I/tzHcWCV3vhokB6p5w6Ru6m/Wd 4H44Yn4iqZb32CziN/RNnKVSCQpYfhOi1V2hxGOVfbwQIsJGh6Jfa+l2XXDsc5p1QGWg +uGR/bJS2kqGKNjM+07cEi7XQoGyre8vK5pBg= Received: by 10.42.133.8 with SMTP id f8mr4181029ict.176.1309547867441; Fri, 01 Jul 2011 12:17:47 -0700 (PDT) Received: from sidhe.local (adsl-67-118-230-86.dsl.pltn13.pacbell.net [67.118.230.86]) by mx.google.com with ESMTPS id vn4sm3620558icb.19.2011.07.01.12.17.45 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 12:17:46 -0700 (PDT) Message-ID: <4E0E1D59.3030003@gmail.com> Date: Fri, 01 Jul 2011 12:17:45 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: cvsup servers broken? 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, 01 Jul 2011 19:48:11 -0000 On 07/01/11 09:34, Ian FREISLICH wrote: > Hi > > I've been seeing this all day: > > # cvsup -L2 /root/supfile-cvs > Parsing supfile "/root/supfile-cvs" > Connecting to cvsup6.freebsd.org > Connected to cvsup6.freebsd.org > Server software version: SNAP_16_1h > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > Updating collection cvsroot-common/cvs > Updating collection src-all/cvs > Updating collection ports-all/cvs > Detailer failed: Premature EOF from server > Will retry at 18:32:04 > > Which coincides with: > (Timestamps UTC+0200) > > 18:27:12.004603 IP 41.154.88.19.52564> 128.205.32.24.5999: Flags [.], ack 102802, win 8225, options [nop,nop,TS val 3651903 ecr 3047757560], length 1400 > 18:27:12.006713 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14659685, win 8225, options [nop,nop,TS val 3047757730 ecr 3651472], length 0 > 18:27:12.145079 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14662485, win 8050, options [nop,nop,TS val 3047757867 ecr 3651688], length 10 > 18:27:12.157567 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [.], ack 14663885, win 8225, options [nop,nop,TS val 3047757880 ecr 3651688], length 0 > 18:27:12.245335 IP 41.154.88.19.52564> 128.205.32.24.5999: Flags [P.], ack 102812, win 8225, options [nop,nop,TS val 3652146 ecr 3047757867], length 342 > 18:27:12.578479 IP 128.205.32.24.5999> 41.154.88.19.52564: Flags [R], seq 1059787102, win 0, length 0 > > It looks like the server is just exiting. I've tested cvsup4 and > cvsup5 as well. Is cvsup deprecated these days or has something > else broken it? > > Ian > Try csup instead of cvsup...I've found it works better. Any possibility of network issues? Matt From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 21:39:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95226106564A for ; Fri, 1 Jul 2011 21:39:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id C4A088FC0C for ; Fri, 1 Jul 2011 21:39:45 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=0STrgBBJ/IeSzGUncdVPgrlXwYQACyAaeTEJnWJdz8Q= c=1 sm=1 a=MJ63iGgHgREA:10 a=WQU8e4WWZSUA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=R-fRjeMW755gxisK39sA:9 a=wPNLvfGTeEIA:10 a=CnuchBDJuRzQ9eq4VLYA:9 a=YjJZ-iFMVzoRQOpC61sA:7 a=Q6Yl5AZvrmpC8v4Q:21 a=2wKaK2ZcSrg8eobX:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 147862413; Fri, 01 Jul 2011 23:39:43 +0200 To: freebsd-current@freebsd.org From: Hans Petter Selasky X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-15?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-15?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= Date: Fri, 1 Jul 2011 23:37:27 +0200 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Y4jDOcGOYSEM/eW" Message-Id: <201107012337.28047.hselasky@c2i.net> Cc: ti bugmenot Subject: Re: keyboard driver problem? (new patch) 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, 01 Jul 2011 21:39:46 -0000 --Boundary-00=_Y4jDOcGOYSEM/eW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Found some bugs in my intial patch. Try this new one. --HPS --Boundary-00=_Y4jDOcGOYSEM/eW Content-Type: text/x-patch; charset="ISO-8859-1"; name="usb_keyboard_hid_compliance.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="usb_keyboard_hid_compliance.diff" === ukbd.c ================================================================== --- ukbd.c (revision 223581) +++ ukbd.c (local) @@ -108,9 +108,10 @@ #define UKBD_IN_BUF_SIZE (2*(UKBD_NMOD + (2*UKBD_NKEYCODE))) /* bytes */ #define UKBD_IN_BUF_FULL (UKBD_IN_BUF_SIZE / 2) /* bytes */ #define UKBD_NFKEY (sizeof(fkey_tab)/sizeof(fkey_tab[0])) /* units */ +#define UKBD_OUT_BUF_SIZE 16 /* bytes */ struct ukbd_data { - uint8_t modifiers; + uint16_t modifiers; #define MOD_CONTROL_L 0x01 #define MOD_CONTROL_R 0x10 #define MOD_SHIFT_L 0x02 @@ -119,9 +120,10 @@ #define MOD_ALT_R 0x40 #define MOD_WIN_L 0x08 #define MOD_WIN_R 0x80 - uint8_t reserved; +/* internal */ +#define MOD_EJECT 0x0100 +#define MOD_FN 0x0200 uint8_t keycode[UKBD_NKEYCODE]; - uint8_t exten[8]; }; enum { @@ -137,6 +139,18 @@ fkeytab_t sc_fkeymap[UKBD_NFKEY]; struct hid_location sc_loc_apple_eject; struct hid_location sc_loc_apple_fn; + struct hid_location sc_loc_ctrl_l; + struct hid_location sc_loc_ctrl_r; + struct hid_location sc_loc_shift_l; + struct hid_location sc_loc_shift_r; + struct hid_location sc_loc_alt_l; + struct hid_location sc_loc_alt_r; + struct hid_location sc_loc_win_l; + struct hid_location sc_loc_win_r; + struct hid_location sc_loc_events; + struct hid_location sc_loc_numlock; + struct hid_location sc_loc_capslock; + struct hid_location sc_loc_scrolllock; struct usb_callout sc_callout; struct ukbd_data sc_ndata; struct ukbd_data sc_odata; @@ -155,30 +169,60 @@ uint32_t sc_buffered_char[2]; #endif uint32_t sc_flags; /* flags */ -#define UKBD_FLAG_COMPOSE 0x0001 -#define UKBD_FLAG_POLLING 0x0002 -#define UKBD_FLAG_SET_LEDS 0x0004 -#define UKBD_FLAG_ATTACHED 0x0010 -#define UKBD_FLAG_GONE 0x0020 -#define UKBD_FLAG_APPLE_EJECT 0x0040 -#define UKBD_FLAG_APPLE_FN 0x0080 -#define UKBD_FLAG_APPLE_SWAP 0x0100 -#define UKBD_FLAG_TIMER_RUNNING 0x0200 +#define UKBD_FLAG_COMPOSE 0x00000001 +#define UKBD_FLAG_POLLING 0x00000002 +#define UKBD_FLAG_SET_LEDS 0x00000004 +#define UKBD_FLAG_ATTACHED 0x00000010 +#define UKBD_FLAG_GONE 0x00000020 +#define UKBD_FLAG_APPLE_EJECT 0x00000040 +#define UKBD_FLAG_APPLE_FN 0x00000080 +#define UKBD_FLAG_APPLE_SWAP 0x00000100 +#define UKBD_FLAG_TIMER_RUNNING 0x00000200 +#define UKBD_FLAG_CTRL_L 0x00000400 +#define UKBD_FLAG_CTRL_R 0x00000800 +#define UKBD_FLAG_SHIFT_L 0x00001000 +#define UKBD_FLAG_SHIFT_R 0x00002000 +#define UKBD_FLAG_ALT_L 0x00004000 +#define UKBD_FLAG_ALT_R 0x00008000 +#define UKBD_FLAG_WIN_L 0x00010000 +#define UKBD_FLAG_WIN_R 0x00020000 +#define UKBD_FLAG_EVENTS 0x00040000 +#define UKBD_FLAG_NUMLOCK 0x00080000 +#define UKBD_FLAG_CAPSLOCK 0x00100000 +#define UKBD_FLAG_SCROLLLOCK 0x00200000 int sc_mode; /* input mode (K_XLATE,K_RAW,K_CODE) */ int sc_state; /* shift/lock key state */ int sc_accents; /* accent key index (> 0) */ int sc_poll_tick_last; + int sc_led_size; + int sc_kbd_size; uint16_t sc_inputs; uint16_t sc_inputhead; uint16_t sc_inputtail; + uint16_t sc_modifiers; uint8_t sc_leds; /* store for async led requests */ uint8_t sc_iface_index; uint8_t sc_iface_no; + uint8_t sc_id_apple_eject; + uint8_t sc_id_apple_fn; + uint8_t sc_id_ctrl_l; + uint8_t sc_id_ctrl_r; + uint8_t sc_id_shift_l; + uint8_t sc_id_shift_r; + uint8_t sc_id_alt_l; + uint8_t sc_id_alt_r; + uint8_t sc_id_win_l; + uint8_t sc_id_win_r; + uint8_t sc_id_event; + uint8_t sc_id_numlock; + uint8_t sc_id_capslock; + uint8_t sc_id_scrolllock; + uint8_t sc_id_events; uint8_t sc_kbd_id; - uint8_t sc_led_id; + uint8_t sc_poll_detected; }; @@ -558,11 +602,10 @@ { struct ukbd_softc *sc = usbd_xfer_softc(xfer); struct usb_page_cache *pc; + uint8_t buffer[32]; uint8_t i; uint8_t offset; uint8_t id; - uint8_t apple_fn; - uint8_t apple_eject; int len; usbd_xfer_status(xfer, &len, NULL, NULL, NULL); @@ -580,73 +623,145 @@ if (sc->sc_kbd_id != 0) { /* check and remove HID ID byte */ usbd_copy_out(pc, 0, &id, 1); - if (id != sc->sc_kbd_id) { - DPRINTF("wrong HID ID\n"); + offset = 1; + len--; + if (len == 0) { + DPRINTF("zero length data\n"); goto tr_setup; } - offset = 1; - len--; } else { offset = 0; + id = 0; } - if (len > sizeof(sc->sc_ndata)) { - len = sizeof(sc->sc_ndata); - } + if (len > sizeof(buffer)) + len = sizeof(buffer); - if (len) { - memset(&sc->sc_ndata, 0, sizeof(sc->sc_ndata)); - usbd_copy_out(pc, offset, &sc->sc_ndata, len); + /* get data */ + usbd_copy_out(pc, offset, buffer, len); - if ((sc->sc_flags & UKBD_FLAG_APPLE_EJECT) && - hid_get_data((uint8_t *)&sc->sc_ndata, - len, &sc->sc_loc_apple_eject)) - apple_eject = 1; - else - apple_eject = 0; + /* clear temporary storage */ + memset(&sc->sc_ndata, 0, sizeof(sc->sc_ndata)); - if ((sc->sc_flags & UKBD_FLAG_APPLE_FN) && - hid_get_data((uint8_t *)&sc->sc_ndata, - len, &sc->sc_loc_apple_fn)) - apple_fn = 1; + /* scan through HID data */ + if ((sc->sc_flags & UKBD_FLAG_APPLE_EJECT) && + (id == sc->sc_id_apple_eject)) { + if (hid_get_data(buffer, len, &sc->sc_loc_apple_eject)) + sc->sc_modifiers |= MOD_EJECT; else - apple_fn = 0; -#ifdef USB_DEBUG - DPRINTF("apple_eject=%u apple_fn=%u\n", - apple_eject, apple_fn); + sc->sc_modifiers &= ~MOD_EJECT; + } + if ((sc->sc_flags & UKBD_FLAG_APPLE_FN) && + (id == sc->sc_id_apple_fn)) { + if (hid_get_data(buffer, len, &sc->sc_loc_apple_fn)) + sc->sc_modifiers |= MOD_FN; + else + sc->sc_modifiers &= ~MOD_FN; + } + if ((sc->sc_flags & UKBD_FLAG_CTRL_L) && + (id == sc->sc_id_ctrl_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_ctrl_l)) + sc-> sc_modifiers |= MOD_CONTROL_L; + else + sc-> sc_modifiers &= ~MOD_CONTROL_L; + } + if ((sc->sc_flags & UKBD_FLAG_CTRL_R) && + (id == sc->sc_id_ctrl_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_ctrl_r)) + sc->sc_modifiers |= MOD_CONTROL_R; + else + sc->sc_modifiers &= ~MOD_CONTROL_R; + } + if ((sc->sc_flags & UKBD_FLAG_SHIFT_L) && + (id == sc->sc_id_shift_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_shift_l)) + sc->sc_modifiers |= MOD_SHIFT_L; + else + sc->sc_modifiers &= ~MOD_SHIFT_L; + } + if ((sc->sc_flags & UKBD_FLAG_SHIFT_R) && + (id == sc->sc_id_shift_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_shift_r)) + sc->sc_modifiers |= MOD_SHIFT_R; + else + sc->sc_modifiers &= ~MOD_SHIFT_R; + } + if ((sc->sc_flags & UKBD_FLAG_ALT_L) && + (id == sc->sc_id_alt_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_alt_l)) + sc->sc_modifiers |= MOD_ALT_L; + else + sc->sc_modifiers &= ~MOD_ALT_L; + } + if ((sc->sc_flags & UKBD_FLAG_ALT_R) && + (id == sc->sc_id_alt_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_alt_r)) + sc->sc_modifiers |= MOD_ALT_R; + else + sc->sc_modifiers &= ~MOD_ALT_R; + } + if ((sc->sc_flags & UKBD_FLAG_WIN_L) && + (id == sc->sc_id_win_l)) { + if (hid_get_data(buffer, len, &sc->sc_loc_win_l)) + sc->sc_modifiers |= MOD_WIN_L; + else + sc->sc_modifiers &= ~MOD_WIN_L; + } + if ((sc->sc_flags & UKBD_FLAG_WIN_R) && + (id == sc->sc_id_win_r)) { + if (hid_get_data(buffer, len, &sc->sc_loc_win_r)) + sc->sc_modifiers |= MOD_WIN_R; + else + sc->sc_modifiers &= ~MOD_WIN_R; + } - if (sc->sc_ndata.modifiers) { - DPRINTF("mod: 0x%04x\n", sc->sc_ndata.modifiers); + sc->sc_ndata.modifiers = sc->sc_modifiers; + + if ((sc->sc_flags & UKBD_FLAG_EVENTS) && + (id == sc->sc_id_events)) { + i = sc->sc_loc_events.count; + if (i > UKBD_NKEYCODE) + i = UKBD_NKEYCODE; + if (i > len) + i = len; + while (i--) { + sc->sc_ndata.keycode[i] = + hid_get_data(buffer + i, len - i, + &sc->sc_loc_events); } + } + +#ifdef USB_DEBUG + DPRINTF("modifiers = 0x%04x\n", (int)sc->sc_modifiers); + for (i = 0; i < UKBD_NKEYCODE; i++) { + if (sc->sc_ndata.keycode[i]) { + DPRINTF("[%d] = 0x%02x\n", + (int)i, (int)sc->sc_ndata.keycode[i]); + } + } +#endif + if (sc->sc_modifiers & MOD_FN) { for (i = 0; i < UKBD_NKEYCODE; i++) { - if (sc->sc_ndata.keycode[i]) { - DPRINTF("[%d] = %d\n", i, sc->sc_ndata.keycode[i]); - } + sc->sc_ndata.keycode[i] = + ukbd_apple_fn(sc->sc_ndata.keycode[i]); } -#endif /* USB_DEBUG */ + } - if (apple_fn) { - for (i = 0; i < UKBD_NKEYCODE; i++) { - sc->sc_ndata.keycode[i] = - ukbd_apple_fn(sc->sc_ndata.keycode[i]); - } + if (sc->sc_flags & UKBD_FLAG_APPLE_SWAP) { + for (i = 0; i < UKBD_NKEYCODE; i++) { + sc->sc_ndata.keycode[i] = + ukbd_apple_swap(sc->sc_ndata.keycode[i]); } + } - if (sc->sc_flags & UKBD_FLAG_APPLE_SWAP) { - for (i = 0; i < UKBD_NKEYCODE; i++) { - sc->sc_ndata.keycode[i] = - ukbd_apple_swap(sc->sc_ndata.keycode[i]); - } - } + ukbd_interrupt(sc); - ukbd_interrupt(sc); - - if (!(sc->sc_flags & UKBD_FLAG_TIMER_RUNNING)) { - if (ukbd_any_key_pressed(sc)) { - ukbd_start_timer(sc); - } + if (!(sc->sc_flags & UKBD_FLAG_TIMER_RUNNING)) { + if (ukbd_any_key_pressed(sc)) { + ukbd_start_timer(sc); } } + case USB_ST_SETUP: tr_setup: if (sc->sc_inputs < UKBD_IN_BUF_FULL) { @@ -674,7 +789,10 @@ { struct usb_device_request req; struct usb_page_cache *pc; - uint8_t buf[2]; + uint8_t buf[UKBD_OUT_BUF_SIZE]; + uint8_t id; + uint8_t any; + int len; struct ukbd_softc *sc = usbd_xfer_softc(xfer); #ifdef USB_DEBUG @@ -685,37 +803,84 @@ switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: case USB_ST_SETUP: - if (sc->sc_flags & UKBD_FLAG_SET_LEDS) { - sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; + if (!(sc->sc_flags & UKBD_FLAG_SET_LEDS)) + break; + sc->sc_flags &= ~UKBD_FLAG_SET_LEDS; - req.bmRequestType = UT_WRITE_CLASS_INTERFACE; - req.bRequest = UR_SET_REPORT; - USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); - req.wIndex[0] = sc->sc_iface_no; - req.wIndex[1] = 0; - req.wLength[1] = 0; + req.bmRequestType = UT_WRITE_CLASS_INTERFACE; + req.bRequest = UR_SET_REPORT; + USETW2(req.wValue, UHID_OUTPUT_REPORT, 0); + req.wIndex[0] = sc->sc_iface_no; + req.wIndex[1] = 0; + req.wLength[1] = 0; - /* check if we need to prefix an ID byte */ - if (sc->sc_led_id != 0) { - req.wLength[0] = 2; - buf[0] = sc->sc_led_id; - buf[1] = sc->sc_leds; - } else { - req.wLength[0] = 1; - buf[0] = sc->sc_leds; - buf[1] = 0; + memset(buf, 0, sizeof(buf)); + + id = 0; + any = 0; + + /* Assumption: All led bits must be in the same ID. */ + + if (sc->sc_flags & UKBD_FLAG_NUMLOCK) { + if (sc->sc_leds & NLKED) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_numlock, 1); } + id = sc->sc_id_numlock; + any = 1; + } - pc = usbd_xfer_get_frame(xfer, 0); - usbd_copy_in(pc, 0, &req, sizeof(req)); + if (sc->sc_flags & UKBD_FLAG_SCROLLLOCK) { + if (sc->sc_leds & SLKED) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_scrolllock, 1); + } + id = sc->sc_id_scrolllock; + any = 1; + } + + if (sc->sc_flags & UKBD_FLAG_CAPSLOCK) { + if (sc->sc_leds & CLKED) { + hid_put_data_unsigned(buf + 1, sizeof(buf) - 1, + &sc->sc_loc_capslock, 1); + } + id = sc->sc_id_capslock; + any = 1; + } + + /* if no leds, nothing to do */ + if (!any) + break; + + /* range check output report length */ + len = sc->sc_led_size; + if (len > (UKBD_OUT_BUF_SIZE - 1)) + len = (UKBD_OUT_BUF_SIZE - 1); + + /* check if we need to prefix an ID byte */ + if (id != 0) { + req.wLength[0] = 1 + len; + buf[0] = id; pc = usbd_xfer_get_frame(xfer, 1); usbd_copy_in(pc, 0, buf, sizeof(buf)); + usbd_xfer_set_frame_len(xfer, 1, 1 + len); + } else { + req.wLength[0] = len; + pc = usbd_xfer_get_frame(xfer, 1); + usbd_copy_in(pc, 0, buf + 1, sizeof(buf) - 1); + usbd_xfer_set_frame_len(xfer, 1, len); + } - usbd_xfer_set_frame_len(xfer, 0, sizeof(req)); - usbd_xfer_set_frame_len(xfer, 1, req.wLength[0]); - usbd_xfer_set_frames(xfer, 2); - usbd_transfer_submit(xfer); - } + DPRINTF("len=%d, id=%d\n", len, id); + + /* setup control request last */ + pc = usbd_xfer_get_frame(xfer, 0); + usbd_copy_in(pc, 0, &req, sizeof(req)); + usbd_xfer_set_frame_len(xfer, 0, sizeof(req)); + + /* start data transfer */ + usbd_xfer_set_frames(xfer, 2); + usbd_transfer_submit(xfer); break; default: /* Error */ @@ -739,7 +904,7 @@ .type = UE_CONTROL, .endpoint = 0x00, /* Control pipe */ .direction = UE_DIR_ANY, - .bufsize = sizeof(struct usb_device_request) + 8, + .bufsize = sizeof(struct usb_device_request) + UKBD_OUT_BUF_SIZE, .callback = &ukbd_set_leds_callback, .timeout = 1000, /* 1 second */ }, @@ -880,43 +1045,131 @@ err = usbd_req_get_hid_desc(uaa->device, NULL, &hid_ptr, &hid_len, M_TEMP, uaa->info.bIfaceIndex); if (err == 0) { - uint8_t apple_keys = 0; - uint8_t temp_id; + /* check if there is an ID byte */ + sc->sc_kbd_size = hid_report_size(hid_ptr, hid_len, + hid_input, &sc->sc_kbd_id); + /* investigate if this is an Apple Keyboard */ if (hid_locate(hid_ptr, hid_len, HID_USAGE2(HUP_CONSUMER, HUG_APPLE_EJECT), hid_input, 0, &sc->sc_loc_apple_eject, &flags, - &temp_id)) { + &sc->sc_id_apple_eject)) { if (flags & HIO_VARIABLE) sc->sc_flags |= UKBD_FLAG_APPLE_EJECT | UKBD_FLAG_APPLE_SWAP; DPRINTFN(1, "Found Apple eject-key\n"); - apple_keys = 1; - sc->sc_kbd_id = temp_id; } if (hid_locate(hid_ptr, hid_len, HID_USAGE2(0xFFFF, 0x0003), hid_input, 0, &sc->sc_loc_apple_fn, &flags, - &temp_id)) { + &sc->sc_id_apple_fn)) { if (flags & HIO_VARIABLE) sc->sc_flags |= UKBD_FLAG_APPLE_FN; DPRINTFN(1, "Found Apple FN-key\n"); - apple_keys = 1; - sc->sc_kbd_id = temp_id; } - if (apple_keys == 0) { - /* - * Assume the first HID ID contains the - * keyboard data - */ - hid_report_size(hid_ptr, hid_len, - hid_input, &sc->sc_kbd_id); + /* figure out some keys */ + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE0), + hid_input, 0, &sc->sc_loc_ctrl_l, &flags, + &sc->sc_id_ctrl_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CTRL_L; + DPRINTFN(1, "Found left control\n"); } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE4), + hid_input, 0, &sc->sc_loc_ctrl_r, &flags, + &sc->sc_id_ctrl_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CTRL_R; + DPRINTFN(1, "Found right control\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE1), + hid_input, 0, &sc->sc_loc_shift_l, &flags, + &sc->sc_id_shift_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SHIFT_L; + DPRINTFN(1, "Found left shift\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE5), + hid_input, 0, &sc->sc_loc_shift_r, &flags, + &sc->sc_id_shift_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SHIFT_R; + DPRINTFN(1, "Found right shift\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE2), + hid_input, 0, &sc->sc_loc_alt_l, &flags, + &sc->sc_id_alt_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_ALT_L; + DPRINTFN(1, "Found left alt\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE6), + hid_input, 0, &sc->sc_loc_alt_r, &flags, + &sc->sc_id_alt_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_ALT_R; + DPRINTFN(1, "Found right alt\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE3), + hid_input, 0, &sc->sc_loc_win_l, &flags, + &sc->sc_id_win_l)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_WIN_L; + DPRINTFN(1, "Found left GUI\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0xE7), + hid_input, 0, &sc->sc_loc_win_r, &flags, + &sc->sc_id_win_r)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_WIN_R; + DPRINTFN(1, "Found right GUI\n"); + } + /* figure out event buffer */ + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_KEYBOARD, 0x00), + hid_input, 0, &sc->sc_loc_events, &flags, + &sc->sc_id_events)) { + sc->sc_flags |= UKBD_FLAG_EVENTS; + DPRINTFN(1, "Found keyboard events\n"); + } - /* investigate if we need an ID-byte for the leds */ - hid_report_size(hid_ptr, hid_len, hid_output, &sc->sc_led_id); + /* figure out leds on keyboard */ + sc->sc_led_size = hid_report_size(hid_ptr, hid_len, + hid_output, NULL); + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x01), + hid_output, 0, &sc->sc_loc_numlock, &flags, + &sc->sc_id_numlock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_NUMLOCK; + DPRINTFN(1, "Found keyboard numlock\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x02), + hid_output, 0, &sc->sc_loc_capslock, &flags, + &sc->sc_id_capslock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_CAPSLOCK; + DPRINTFN(1, "Found keyboard capslock\n"); + } + if (hid_locate(hid_ptr, hid_len, + HID_USAGE2(HUP_LEDS, 0x03), + hid_output, 0, &sc->sc_loc_scrolllock, &flags, + &sc->sc_id_scrolllock)) { + if (flags & HIO_VARIABLE) + sc->sc_flags |= UKBD_FLAG_SCROLLLOCK; + DPRINTFN(1, "Found keyboard scrolllock\n"); + } free(hid_ptr, M_TEMP); } @@ -1468,10 +1721,6 @@ static int ukbd_ioctl(keyboard_t *kbd, u_long cmd, caddr_t arg) { - /* translate LED_XXX bits into the device specific bits */ - static const uint8_t ledmap[8] = { - 0, 2, 1, 3, 4, 6, 5, 7, - }; struct ukbd_softc *sc = kbd->kb_data; int i; @@ -1547,10 +1796,11 @@ #endif case KDSETLED: /* set keyboard LED */ /* NOTE: lock key state in "sc_state" won't be changed */ - if (*(int *)arg & ~LOCK_MASK) { + if (*(int *)arg & ~LOCK_MASK) return (EINVAL); - } + i = *(int *)arg; + /* replace CAPS LED with ALTGR LED for ALTGR keyboards */ if (sc->sc_mode == K_XLATE && kbd->kb_keymap->n_keys > ALTGR_OFFSET) { @@ -1559,9 +1809,9 @@ else i &= ~CLKED; } - if (KBD_HAS_DEVICE(kbd)) { - ukbd_set_leds(sc, ledmap[i & LED_MASK]); - } + if (KBD_HAS_DEVICE(kbd)) + ukbd_set_leds(sc, i); + KBD_LED_VAL(kbd) = *(int *)arg; break; case KDGKBSTATE: /* get lock key state */ --Boundary-00=_Y4jDOcGOYSEM/eW-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 2 07:27:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5ADF1065672; Sat, 2 Jul 2011 07:27:43 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 73C3E8FC0C; Sat, 2 Jul 2011 07:27:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QcucA-0005ro-An>; Sat, 02 Jul 2011 09:27:42 +0200 Received: from e178019114.adsl.alicedsl.de ([85.178.19.114] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QcucA-00036c-82>; Sat, 02 Jul 2011 09:27:42 +0200 Message-ID: <4E0EC86E.9050608@zedat.fu-berlin.de> Date: Sat, 02 Jul 2011 09:27:42 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110630 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.19.114 Cc: Subject: devel/subversion: svn: Couldn't perform atomic initialization 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, 02 Jul 2011 07:27:43 -0000 Hello. Since two days now I realize on several recently ports-updated servers a failure of the subversion server running on those servers. Sneaking around the internet I found several issues exactly targeting this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed in sqlite-3.7.7.2. At this very moment, our subversion servers in question has all recently been updated and it seems, they all fail the same way. Does anyone also realize this behaviour shown below when commiting? Is there a workaround? Any help or hint is appreciated. Thanks in advance, Oliver Transmitting file data .svn: Commit failed (details follow): svn: Couldn't perform atomic initialization svn: database schema has changed svn: Your commit message was left in a temporary file: From owner-freebsd-current@FreeBSD.ORG Sat Jul 2 08:22:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C4B1065676 for ; Sat, 2 Jul 2011 08:22:03 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.154.0.151]) by mx1.freebsd.org (Postfix) with ESMTP id 19E898FC0A for ; Sat, 2 Jul 2011 08:22:02 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1QcvSi-0004se-QF; Sat, 02 Jul 2011 10:22:00 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QcvSg-000JfG-Ho; Sat, 02 Jul 2011 10:21:58 +0200 Message-Id: To: Matt From: Ian FREISLICH In-Reply-To: <4E0E1D59.3030003@gmail.com> References: <4E0E1D59.3030003@gmail.com> X-Attribution: BOFH Date: Sat, 02 Jul 2011 10:21:58 +0200 Cc: current@freebsd.org Subject: Re: cvsup servers broken? 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, 02 Jul 2011 08:22:04 -0000 Matt wrote: > On 07/01/11 09:34, Ian FREISLICH wrote: > > It looks like the server is just exiting. I've tested cvsup4 and > > cvsup5 as well. Is cvsup deprecated these days or has something > > else broken it? > > > Try csup instead of cvsup...I've found it works better. Any possibility > of network issues? csup gets into an infinite loop near the end of the ports tree and starts growing in memory consumption. I killed it after it grew to about 500M resident. The following is a ktrace snippet after it stalls: 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) The first part of csup's stack trace. It appears to be corrupted with several null frames, and is very, very deep. (gdb) bt #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 #2 0x2832b7ea in isatty () from /lib/libc.so.7 #3 0x08051832 in fnmatch () #4 0x08051906 in fnmatch () #5 0x08052135 in fnmatch () #6 0x08059c19 in fnmatch () #7 0x08059a76 in fnmatch () #8 0x0804c1ff in ?? () #9 0x28c11380 in ?? () #10 0x2845f402 in ?? () [mini] /usr/home/ianf # procstat -f 75390 PID COMM FD T V FLAGS REF OFFSET PRO NAME 75390 csup text v r r------- - - - /usr/bin/csup 75390 csup ctty v c rw------ - - - /dev/pts/1 75390 csup cwd v d r------- - - - /usr/src 75390 csup root v d r------- - - - / 75390 csup 0 v c rw------ 14 10464115 - /dev/pts/1 75390 csup 1 v c rw------ 14 10464115 - /dev/pts/1 75390 csup 2 v c rw------ 14 10464115 - /dev/pts/1 75390 csup 3 s - rw------ 2 0 TCP 10.0.2.67:19238 128.205.32.24:5999 75390 csup 4 v r r------- 1 0 - /usr/home/ncvs/ports/x11/wbar/Makefile,v 75390 csup 5 v r r------- 1 1023 - /var/db/sup/ports-all/checkouts 75390 csup 6 v r r------- 1 24492073 - /var/db/sup/ports-all/checkouts 75390 csup 7 v r -w------ 1 24491389 - /var/db/sup/ports-all/#cvs.csup-75390.0 filedescriptor 4's directory listing: [mini] /usr/home/ncvs/ports/x11/wbar # ls -la total 24 drwxr-xr-x 3 root wheel 512 Jul 1 07:21 . drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. -r--r--r-- 1 root wheel 0 Feb 8 22:51 Makefile,v -r--r--r-- 1 root wheel 0 Mar 19 14:38 distinfo,v drwxr-xr-x 2 root wheel 512 Jul 1 07:21 files -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-descr,v -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-plist,v After removing the zero sized files, csup continued until it hit x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was also zero sized. Having deleted all the zero files, both cvsup and csup complete their run. So, why does it fail so absurdly on this condition? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sat Jul 2 15:46:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D93FC106566B for ; Sat, 2 Jul 2011 15:46:59 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from nm12-vm3.bullet.mail.ne1.yahoo.com (nm12-vm3.bullet.mail.ne1.yahoo.com [98.138.91.142]) by mx1.freebsd.org (Postfix) with SMTP id 856498FC08 for ; Sat, 2 Jul 2011 15:46:59 +0000 (UTC) Received: from [98.138.90.49] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jul 2011 15:33:48 -0000 Received: from [98.138.226.126] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jul 2011 15:33:48 -0000 Received: from [127.0.0.1] by smtp205.mail.ne1.yahoo.com with NNFMP; 02 Jul 2011 15:33:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309620828; bh=ykZcubFOrFN9Yo1+CN7Vz0eTaUEaTsp6/czrq6nMQ5c=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=LtKnXrtthHNUwiFO0b1APQ2+J8HUi0epDjzIo9x6RzGx5yuF4aXZno5FDgzTSGUdZu0QoHgq3SQWjvawhhsln99xpCVj7XinD0bN6GBADyyagWuKYC33MSTL8rUq8KcQpXOJWagxqRKJ9JGlEEeDp8pL/7XLCbQw2JXyuYdxHPw= X-Yahoo-Newman-Id: 203580.47124.bm@smtp205.mail.ne1.yahoo.com Received: from [192.168.0.10] (vassilis.laganakos@82.26.1.108 with plain) by smtp205.mail.ne1.yahoo.com with SMTP; 02 Jul 2011 08:33:47 -0700 PDT X-Yahoo-SMTP: 1OHIhCeswBBeEv7nZbHf0yvkrPBhfPima6axnFX6oQ-- X-YMail-OSG: SoBKk2wVM1nXwDHms4mAIt3.upaHahvwClum9XGVXOGyJVw R8oye7.ER6j1_oPzK.1fWJ8agw68fLuUw_o4XGYo3C.ES.FgqwLC2zZNFMSb ZjX.uMcWqMkf6.1l5MTWKupAGtiHrt_q1Ly4O4BglL9c1dRbktA.dLALN1Vg Z4LWeGuvK01qmIewQ9DSpedxNKzRUZYFpWc9CauXZUfN8w87cHmVSf1yIzph czk.wfhCMAcLhXpn6RcfqECokaNPatTKTC0kaTk3IWh2Ped.FkhDkUQESgRg CjeZsLdwvXtjogC4efSSmTTQMZVMvvreBUS96TFWsDlKuUBOLgHH6m4zfls1 ZOdV1_ss3HxWeFhxkJh7UiTmzyeiQIyMCUrEJeTjTeweMSywENXmADkdICO6 FMi4P8CerH3.R7nQkSGk7QIczT0hQX67_s_c27nbwOSoxsmS3GfoW.wArMQ6 51a3FkHh5WJNn60q4lnKui6AD2Y2HOO1d17A.Eab3wkZ62MIEjyHJX1aI9Lz ok89LRaIgdjdnWuxnp.CeND6sSNRQTMYBYeg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E0F3A53.3040309@yahoo.com> Date: Sat, 02 Jul 2011 16:33:39 +0100 From: Vassilis Laganakos User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110630 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038 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, 02 Jul 2011 15:46:59 -0000 Hello, I am facing the same problems as Holger here: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html although CVSup dies in gmtime_r in libc.so.7: ... Updating collection src-all/cvs Edit src/UPDATING Program received signal SIGSEGV, Segmentation fault. 0x000000002ca10fb9 in gmtime_r () from /lib/libc.so.7 ... See full gdb backtrace at: http://www.pastie.org/pastes/2154271 So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7 with debugging symbols to find out what is going wrong there. Any quick ideas on how to correct this, or if someone else is seeing this issue? Thanks, Vassilis L. From owner-freebsd-current@FreeBSD.ORG Sat Jul 2 19:15:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B96910656AB; Sat, 2 Jul 2011 19:15:52 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 996C98FC1A; Sat, 2 Jul 2011 19:15:51 +0000 (UTC) Received: by qyk30 with SMTP id 30so477594qyk.13 for ; Sat, 02 Jul 2011 12:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=AnQlRddHLy9qT5vwuRjxxkVKEj7G1u/aM4x8Lvqqybs=; b=b/4AUPUIUiAq6x+MbC5h2XodF0mvsGyorNPtLBijGtFmonOs4dYsIopVesogx4ZKQh obVv8+16s2hS7048lTyBb3LzCAtjLU+m3zOdAWHqabRYaHKKScoPo3Qu8qia7x30euVt DvlRmnDc/TqazVl72LPHSIrtpdqU5zZ2pmgKw= Received: by 10.224.137.212 with SMTP id x20mr3730162qat.48.1309632321593; Sat, 02 Jul 2011 11:45:21 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id u10sm236748qct.21.2011.07.02.11.45.19 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 11:45:20 -0700 (PDT) Date: Sat, 2 Jul 2011 14:45:13 -0400 From: Alexander Kabaev To: "Hartmann, O." Message-ID: <20110702144513.5c5b9f75@kan.dnsalias.net> In-Reply-To: <4E0EC86E.9050608@zedat.fu-berlin.de> References: <4E0EC86E.9050608@zedat.fu-berlin.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eLCFLU41i_AWTsBqDFMYbwD"; protocol="application/pgp-signature" Cc: FreeBSD Current , FreeBSD Stable Subject: Re: devel/subversion: svn: Couldn't perform atomic initialization 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, 02 Jul 2011 19:15:52 -0000 --Sig_/eLCFLU41i_AWTsBqDFMYbwD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 02 Jul 2011 09:27:42 +0200 "Hartmann, O." wrote: > Hello. > Since two days now I realize on several recently ports-updated > servers a failure of the subversion server running on those servers. > Sneaking around the internet I found several issues exactly targeting > this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed > in sqlite-3.7.7.2. At this very moment, our subversion servers in > question has all recently been updated and it seems, they all fail > the same way. Does anyone also realize this behaviour shown below > when commiting? >=20 > Is there a workaround? Any help or hint is appreciated. >=20 > Thanks in advance, > Oliver >=20 > Transmitting file data .svn: Commit failed (details follow): > svn: Couldn't perform atomic initialization > svn: database schema has changed > svn: Your commit message was left in a temporary file: >=20 Update database/sqlite3 port to the 3.7.7.1 version committed today. --=20 Alexander Kabaev --Sig_/eLCFLU41i_AWTsBqDFMYbwD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iD8DBQFOD2c+Q6z1jMm+XZYRAr4OAJwL5BHanHJGgFPsn6FdsqBPye2JXwCfYswL u/+5f/EOSY6TOzF02WMcqLE= =OyLi -----END PGP SIGNATURE----- --Sig_/eLCFLU41i_AWTsBqDFMYbwD-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 2 23:47:51 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DAAB106566C for ; Sat, 2 Jul 2011 23:47:51 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ixe-mta-27.emailfiltering.com (ixe-mta-27-tx.emailfiltering.com [194.116.199.158]) by mx1.freebsd.org (Postfix) with ESMTP id 92E7F8FC12 for ; Sat, 2 Jul 2011 23:47:50 +0000 (UTC) Received: from mail-gw5.york.ac.uk ([144.32.129.29]) by ixe-mta-27.emailfiltering.com with emfmta (version 4.8.2.32) by TLS id 1166051390 for ianf@clue.co.za;fd9a97a483630c4a; Sun, 03 Jul 2011 00:36:24 +0100 Received: from ury.york.ac.uk ([144.32.108.81]:53383) by mail-gw5.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Qd9ja-0000Ga-Ou; Sun, 03 Jul 2011 00:36:22 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1Qd9ja-0003rt-Hq; Sun, 03 Jul 2011 00:36:22 +0100 Date: Sun, 3 Jul 2011 00:36:22 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@"ury.york.ac.uk." To: Ian FREISLICH In-Reply-To: Message-ID: References: <4E0E1D59.3030003@gmail.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: Matt , current@freebsd.org Subject: Re: cvsup servers broken? 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, 02 Jul 2011 23:47:51 -0000 On Sat, 2 Jul 2011, Ian FREISLICH wrote: > Matt wrote: > > On 07/01/11 09:34, Ian FREISLICH wrote: > > > It looks like the server is just exiting. I've tested cvsup4 and > > > cvsup5 as well. Is cvsup deprecated these days or has something > > > else broken it? > > > > > Try csup instead of cvsup...I've found it works better. Any possibility > > of network issues? > > csup gets into an infinite loop near the end of the ports tree and > starts growing in memory consumption. I killed it after it grew > to about 500M resident. The following is a ktrace snippet after > it stalls: > > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > 75390 csup RET ioctl -1 errno 25 Inappropriate ioctl for device > 75390 csup CALL ioctl(0x4,TIOCGETA,0xbf5fac60) > > The first part of csup's stack trace. It appears to be corrupted > with several null frames, and is very, very deep. > > (gdb) bt > #0 0x2832c1f3 in ioctl () from /lib/libc.so.7 > #1 0x2832bdbc in tcgetattr () from /lib/libc.so.7 > #2 0x2832b7ea in isatty () from /lib/libc.so.7 > #3 0x08051832 in fnmatch () > #4 0x08051906 in fnmatch () > #5 0x08052135 in fnmatch () > #6 0x08059c19 in fnmatch () > #7 0x08059a76 in fnmatch () > #8 0x0804c1ff in ?? () > #9 0x28c11380 in ?? () > #10 0x2845f402 in ?? () > > [mini] /usr/home/ianf # procstat -f 75390 > PID COMM FD T V FLAGS REF OFFSET PRO NAME > 75390 csup text v r r------- - - - /usr/bin/csup > 75390 csup ctty v c rw------ - - - /dev/pts/1 > 75390 csup cwd v d r------- - - - /usr/src > 75390 csup root v d r------- - - - / > 75390 csup 0 v c rw------ 14 10464115 - /dev/pts/1 > 75390 csup 1 v c rw------ 14 10464115 - /dev/pts/1 > 75390 csup 2 v c rw------ 14 10464115 - /dev/pts/1 > 75390 csup 3 s - rw------ 2 0 TCP 10.0.2.67:19238 128.205.32.24:5999 > 75390 csup 4 v r r------- 1 0 - /usr/home/ncvs/ports/x11/wbar/Makefile,v > 75390 csup 5 v r r------- 1 1023 - /var/db/sup/ports-all/checkouts > 75390 csup 6 v r r------- 1 24492073 - /var/db/sup/ports-all/checkouts > 75390 csup 7 v r -w------ 1 24491389 - /var/db/sup/ports-all/#cvs.csup-75390.0 > > filedescriptor 4's directory listing: > > [mini] /usr/home/ncvs/ports/x11/wbar # ls -la > total 24 > drwxr-xr-x 3 root wheel 512 Jul 1 07:21 . > drwxr-xr-x 694 root wheel 14848 Jun 28 16:29 .. > -r--r--r-- 1 root wheel 0 Feb 8 22:51 Makefile,v > -r--r--r-- 1 root wheel 0 Mar 19 14:38 distinfo,v > drwxr-xr-x 2 root wheel 512 Jul 1 07:21 files > -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-descr,v > -r--r--r-- 1 root wheel 0 Feb 8 22:51 pkg-plist,v > > After removing the zero sized files, csup continued until it hit > x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was > also zero sized. Having deleted all the zero files, both cvsup and > csup complete their run. I don't think you'll get much interest in fixing cvsup, but if you can recreate this at will with csup and haven't had a response in a few days, could you please submit a PR? Thanks, Gavin