From owner-freebsd-stable@FreeBSD.ORG Sun Jan 26 01:55:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4318E696 for ; Sun, 26 Jan 2014 01:55:05 +0000 (UTC) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F26931AC7 for ; Sun, 26 Jan 2014 01:55:04 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7Ew5-0000LV-5f for freebsd-stable@freebsd.org; Sun, 26 Jan 2014 01:54:57 +0000 Date: Sun, 26 Jan 2014 01:54:57 +0000 From: John To: freebsd-stable@freebsd.org Subject: problems with canon lide110 scanner on freebsd 10-R Message-ID: <20140126015456.GA1147@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 01:55:05 -0000 Hello freebsd-stable I'm not sure if this is an OS problem or a port problem. I've installed xsane and am trying to get a canon lide 110 usb scanner working. The kernel is generic apart from the addition of GEOM_CONCAT and cputemp and the removal of cpufreq and fdc. In rc.conf, both hal and devd are enabled. If I plug the scanner into a USB port, I get this in /var/log/messages: Jan 26 01:30:41 potato kernel: ugen4.3: at usbus4 Jan 26 01:30:41 potato devd: Executing 'env LD_PRELOAD=/usr/local/lib/libhal.so:/usr/local/lib/libdbus-1.so:/usr/local/lib/libcuse4bsd.so /usr/local/etc/rc.d/webcamd start ugen4.3' Jan 26 01:30:41 potato devd: Executing 'logger Unknown USB device: vendor 0x04a9 product 0x1909 bus uhub3' Jan 26 01:30:41 potato root: Unknown USB device: vendor 0x04a9 product 0x1909 bus uhub3 As root, if I then do sane-find-scanner as per the handbook, in /var/log/messages, this happens: Jan 26 01:34:12 potato kernel: ata2: FAILURE - odd-sized DMA transfer attempt 5 % 2 Jan 26 01:34:12 potato kernel: ata2: setting up DMA failed Jan 26 01:34:12 potato kernel: ata2: FAILURE - odd-sized DMA transfer attempt 5 % 2 Jan 26 01:34:12 potato kernel: ata2: setting up DMA failed sometimes it lock up at this point requiring a hard reset then fsck -y sane-find-scanner output is here: # sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. (nothing else happens) If I ctrl-c this multiple times, the root prompt returns after about five minutes. Some time after, the following appears in /var/log/messages: Jan 26 01:47:29 potato kernel: ata2: already running! Can anyone help? I don't know how to debug this further :( -- John From owner-freebsd-stable@FreeBSD.ORG Sun Jan 26 03:02:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 454C68C3 for ; Sun, 26 Jan 2014 03:02:51 +0000 (UTC) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0233D10B7 for ; Sun, 26 Jan 2014 03:02:50 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7Fza-0009aj-VQ for freebsd-stable@freebsd.org; Sun, 26 Jan 2014 03:02:38 +0000 Date: Sun, 26 Jan 2014 03:02:38 +0000 From: John To: freebsd-stable@freebsd.org Subject: Re: problems with canon lide110 scanner on freebsd 10-R Message-ID: <20140126030238.GA36817@potato.growveg.org> References: <20140126015456.GA1147@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140126015456.GA1147@potato.growveg.org> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 03:02:51 -0000 On Sun, Jan 26, 2014 at 01:54:57AM +0000, John wrote: > Hello freebsd-stable > > I'm not sure if this is an OS problem or a port problem. I've installed > xsane and am trying to get a canon lide 110 usb scanner working. The > kernel is generic apart from the addition of GEOM_CONCAT and cputemp and > the removal of cpufreq and fdc. In rc.conf, both hal and devd are > enabled. Sorry for the noise - it was software that was at issue. -- John From owner-freebsd-stable@FreeBSD.ORG Sun Jan 26 04:39:47 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71465523; Sun, 26 Jan 2014 04:39:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFB11674; Sun, 26 Jan 2014 04:39:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,721,1384318800"; d="scan'208";a="91072334" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Jan 2014 23:39:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 68C79B3F49; Sat, 25 Jan 2014 23:39:45 -0500 (EST) Date: Sat, 25 Jan 2014 23:39:45 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <1716898514.16343391.1390711185414.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: on 9.2-stable nfs/zfs and 10g hang MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Adrian Chadd , FreeBSD stable , Luigi Rizzo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 04:39:47 -0000 Daniel Braniss wrote: >=20 >=20 >=20 > On Jan 18, 2014, at 6:13 PM, Adrian Chadd < adrian@freebsd.org > > wrote: >=20 >=20 > Hi! >=20 > Please try reducing the size down to 32k but leave TSO enabled. >=20 > did so, it worked ok, but took longer: > with TSO disabled: 14834.61 real 609.29 user 1996.90 sys > with TSO + 32k: 15714.46 real 639.98 user 1828.07 sys >=20 I just might have an idea why TSO breaks for rsize/wsize=3D65536 for NFS. (Note that I know diddly about these drivers and am going on what I've seen in the last few minutes of looking at them.) When the rsize/wsize is set to 64K, NFS will generate a list of about 32 mbuf clusters. The krpc may add more for the RPC header, then this list is handed to TCP via sosend(). I'm not sure what TCP does with it when TSO is enabled, but hopefully you guys do? What I am wondering about is...can the mbuf list exceed the scatter size the driver handles (IXGBE_82599_SCATTER is 32)? The code in the .._xmit() function seems to try and m_defrag() it once and then throws it away. (If it is thrown away, that would be pretty disastrous for NFS.) Could this be happening? Can IXGBE_82599_SCATTER be increased or is it a hardware limit? Sorry, if this is total bunk, since I know diddly about this, rick >=20 >=20 > It's 9.2, so there may be some bugfixes that haven't been backported > from 10 or -HEAD. Would you be able to try a -HEAD snapshot here? >=20 > ENOTIME :-). >=20 >=20 >=20 > What's the NFS server and hosts? I saw the core.txt.16 that says > "ix0/ix1" so I can glean the basic chipset family but which NIC in > particular is it? What would people need to try and reproduce it? >=20 > The hosts involved are Dell 720/710 > the 10G card are Intel >=20 >=20 > ix0@pci0:5:0:0: class=3D0x020000 card=3D0x7a118086 chip=3D0x10fb8086 > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class =3D network > subclass =3D ethernet >=20 >=20 > the server is exporting a big ZFS file system, which is served via 2 > raid controllers: >=20 >=20 >=20 > mfi1@pci0:65:0:0: class=3D0x010400 card=3D0x1f2d1028 chip=3D0x005b1000 > rev=3D0x05 hdr=3D0x00 > vendor =3D 'LSI Logic / Symbios Logic' > device =3D 'MegaRAID SAS 2208 [Thunderbolt]' > class =3D mass storage > subclass =3D RAID > mfi2@pci0:66:0:0: class=3D0x010400 card=3D0x1f151028 chip=3D0x00791000 > rev=3D0x05 hdr=3D0x00 > vendor =3D 'LSI Logic / Symbios Logic' > device =3D 'MegaRAID SAS 2108 [Liberator]' > class =3D mass storage > subclass =3D RAID >=20 >=20 > - just had the driver card lying around- >=20 >=20 > I will try a divergent client, which has a Broadcom Nic later. >=20 >=20 > Q: is the TSO bug in the NIC/driver or in the kernel or both? >=20 >=20 > cheers > danny >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -a >=20 >=20 > On 18 January 2014 03:24, Daniel Braniss < danny@cs.huji.ac.il > > wrote: >=20 >=20 >=20 > On Jan 17, 2014, at 4:47 PM, Rick Macklem < rmacklem@uoguelph.ca > > wrote: >=20 >=20 >=20 > Daniel Braniss wrote: >=20 >=20 > hi all, >=20 > All was going ok till I decided to connect this host via a 10g nic > and very soon it started > to hang. Running multiple make buildworlds from other hosts connected > via 10g and > using both src and obj on the server via tcp/nfs did ok. but running > find =E2=80=A6 -exec md5 {} + (the find finds over 6M files) > from another host (at 10g) will hang it very quickly. >=20 > If I wait a while (can=E2=80=99t be more specific) it sometimes recovers = - > but my users are not very > patient :-) >=20 > This suggests that an RPC request/reply gets dropped in a way that > TCP > doesn't recover. Eventually (after up to about 15min, I think?) the > TCP > connection will be shut down and a new TCP connection started, with a > retry of outstanding RPCs. >=20 >=20 >=20 > I will soon try the same experiment using the old 1G nic, but in the > meantime, if someone > could shed some light would be very helpful >=20 > I=E2=80=99m attaching core.txt, but if it doesn=E2=80=99t make it, it=E2= =80=99s also > available at: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt.16 >=20 > You might try disabling TSO on the net interface. There are been > issues > with TSO for segments around 64K in the past (or use > rsize=3D32768,wsize=3D32768 > options on the client mount, to avoid RPCs over about 32K in size). >=20 > BINGO! disabling tso did it. I=E2=80=99ll try reducing the packet size la= ter. > some numbers: > there where some 7*10^6 files > doing it locally (the find + md5) took about 3hs, > via nfs at 1g took 11 hrs. > at 10g it took 4 hrs. >=20 > thanks! > danny >=20 >=20 >=20 >=20 > Beyond that, capturing a packet trace for the case that hangs easily > and > looking at what goes on near the end of it in wireshark might give > you > a hint about what is going on. >=20 > rick >=20 >=20 >=20 > thanks, > danny > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Sun Jan 26 18:32:38 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9605068F for ; Sun, 26 Jan 2014 18:32:38 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C90E1F52 for ; Sun, 26 Jan 2014 18:32:38 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id t10so1823336eei.21 for ; Sun, 26 Jan 2014 10:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=qBhwSnF1h9rzjKCivEhT5k0S17uJ92/81r4pK9F/xOU=; b=yJn4FnB/e/ByhQeBgcqIuc/OoBeyVnV5/RzlW1Yd7aXGTixQpKSnPIHDJZq7EuWypF ZJnih4rddw+KnDK9/GmLgTbGvfqWgfUfPuvcX3ZKeAsAXTzbLVT4IipIJQWn/qc2scbi ffoUCF+i6vZcQyX5Tbq1fmxokXlaZqPAkFC0s5Z5hoc8nZd0OTuzmLiIYcjlUOrb38/o C/LYBFYnx0hy0r7YOzHiPnqBJKNgwdIIqRrJ/kOd7DZUJgUNz+umpK7h+MXZ/YGdZ9B1 sPeCY7hnuaB9OBdwDKFLBI0gXwd7k/NCIZR8bxtXc7hTLCroCZp/MTyHPH9U4KW1nDBM 04vg== X-Received: by 10.14.104.133 with SMTP id i5mr21378214eeg.16.1390761156232; Sun, 26 Jan 2014 10:32:36 -0800 (PST) Received: from localhost (p5491004D.dip0.t-ipconnect.de. [84.145.0.77]) by mx.google.com with ESMTPSA id a8sm26223890eeo.3.2014.01.26.10.32.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 26 Jan 2014 10:32:35 -0800 (PST) Sender: Thomas Zander Date: Sun, 26 Jan 2014 19:32:21 +0100 From: Thomas Zander To: stable@freebsd.org Subject: 10-STABLE is cutting the mustard Message-ID: <20140126183221.GA1934@marvin2011.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-KeyID: 0xC85996CD X-PGP-URL: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8DD48929C85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 18:32:38 -0000 Folks, today I scrubbed my pools for the first time since the upgrade from 9 to 10 last week, and I have to say: This ... scan: scrub repaired 0 in with 0 errors on Sun Jan 26 17:33:54 2014 ... is awesome. The drastic performance increase in AES-NI probably plays a big role here. These alone would make an update worthwhile, but overall, from what I observe so far, 10 is a very solid release. Kudos! Riggs From owner-freebsd-stable@FreeBSD.ORG Sun Jan 26 21:19:57 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC32570F for ; Sun, 26 Jan 2014 21:19:57 +0000 (UTC) Received: from mail1.yamagi.org (yugo.yamagi.org [84.201.39.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80CBD1B24 for ; Sun, 26 Jan 2014 21:19:56 +0000 (UTC) Received: from p579a6fb8.dip0.t-ipconnect.de ([87.154.111.184] helo=happy.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W7Wn4-0007Gn-QU; Sun, 26 Jan 2014 21:58:52 +0100 Date: Sun, 26 Jan 2014 21:58:45 +0100 From: Yamagi Burmeister To: amarat@li.ru Subject: Re: 10.0, csh history merge broken? Message-Id: <20140126215845.3b62debf03dade433622e9ba@yamagi.org> In-Reply-To: <52E0E917.3060403@li.ru> References: <52E0E917.3060403@li.ru> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 21:19:57 -0000 Hello, this is a long standing problem. There are no locks in the csh / tcsh history merging code, thus it's racy between several shell instances. When enough shells are closed at the same time and your machine is fast enough, chances are high that several merges occure at the same time and break your ~/.history. I have this code in my ~/.logout to create a backup: # Create a backup of the history cp ${histfile} ${histfile}.bak # Create a backup of the directory stack cp ${dirsfile} ${dirsfile}.bak Please note that it is only reliable when there's only one login-shell running. Otherwise you'll need some more magic. The root cause was fixes upstream in december last year by adding the new "lock" option. If it's set, the history merge is serialized between all shell instances. The commit is here: https://github.com/tcsh-org/tcsh/commit/bb6ea8e92179d3c1b574764977f6f5e2d2ecd1e0 You'll need this one too: https://github.com/tcsh-org/tcsh/commit/0684fcc55321f6f0fca5263a5071cbe64704f1fe Maybe it would be a good idea to cherry pick those two revisions and merge then into FreeBSD, until a new tcsh version is released. Regards, Yamagi On Thu, 23 Jan 2014 14:04:07 +0400 "Marat N.Afanasyev" wrote: > as root while several user csh were running, after reboot user .history > file was corrupted: > > #+1360668026 > less /etc/ma#+136066#+136cd /usr/grep KERB * > #+1360668067 > cd /usr/src/contrib/bind9/##+1360668073ggrep -i kerboros * > #+1360668076 > grep -iR kerboros * > #+1360704099 > cd /usr/ports/www/mod_pag#+136084#+136fetch -oman sudoers > #+1361372281 > cd /usr/ports/editors/openoffice-3-devel/ > #+1361690297 > telnet 19#+13617995m#+man uh#+1#+13617995m#+man xh#+1#+13617995a#+man ehci -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 00:43:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AB94377 for ; Mon, 27 Jan 2014 00:43:50 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 223C01D7C for ; Mon, 27 Jan 2014 00:43:49 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id s0R0hQAc077742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Jan 2014 01:43:27 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id s0R0hQb5012712 for ; Mon, 27 Jan 2014 01:43:26 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.7/8.14.7/Submit) id s0R0hQR0012711 for freebsd-stable@freebsd.org; Mon, 27 Jan 2014 01:43:26 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Mon, 27 Jan 2014 01:43:25 +0100 From: Wolfgang Zenker To: freebsd-stable@freebsd.org Subject: endless ATA probe loop Thinkpad T42p / FreeBSD 10-STABLE Message-ID: <20140127004325.GA12412@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Mon, 27 Jan 2014 01:43:27 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 00:43:50 -0000 Hi, after updating a Thinkpad T42p to 10-STABLE r261177 the laptop no longer boots because of an endless ATA probe loop trying to ATAPI_IDENTIFY the cd drive. A 10-STABLE installation built around January 2nd also failed the ATA probe but continued to boot after exhausting the retries, while the new version gets to the message (aprobe0:ata1:0:1:0): Error 5, Retries exhausted but then tries the probe again, never finishing the boot process. Is there a way to get around this? Wolfgang From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 02:55:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96857379; Mon, 27 Jan 2014 02:55:33 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A749159D; Mon, 27 Jan 2014 02:55:33 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id x10so5163805pdj.36 for ; Sun, 26 Jan 2014 18:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hBgNdKu4FrKaYGcaoyQVXoP+HNBX1f3vPf+WjLMtosI=; b=ZM1e6YyU321nKcV/a6wR13AesL6uoytAjs8ZIHaaHpbYXedV5AW+FCPhW0+BgOHtcB 4EDvPVpA9pkI7jgsrp1Ih7OwCGBPUrzTBYwVacc3m3TxyB6i8zKaCXTUBdsbIPd8BLUH gguh2D4vI6ir9m3o0/wcwnA/qFyJwMcE+Pd8ONaMEjRLkuqYEHCv5VVxe8R9h2mRgQoN 0u/UeJVbR5t3JJbq+APqC7auutabOCCvB0OVmbUbXu666xuF2zIi5Yt5qml7/vqwMyUU xNtSdbphmYgPJ5KQSzo6D8MlT3QHcx1sKY1F1uADLg31Tj3Kgue/0zyCyTi4/yLbAPTG B1PQ== MIME-Version: 1.0 X-Received: by 10.68.224.34 with SMTP id qz2mr28247172pbc.84.1390791333031; Sun, 26 Jan 2014 18:55:33 -0800 (PST) Received: by 10.68.27.105 with HTTP; Sun, 26 Jan 2014 18:55:32 -0800 (PST) Date: Sun, 26 Jan 2014 21:55:32 -0500 Message-ID: Subject: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Jason Unovitch To: freebsd-java@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 02:55:33 -0000 Evening FreeBSD Java/Stable, Anybody out there seeing any issues with Java performance on FreeBSD 10? I've recently updated my home NAS box from 9.2-RELEASE-p3 to 10.0-RELEASE and simply cannot get my Serviio media center jail using OpenJDK6 to stay running without getting some kind of Java crash. To be fair, the Java crashes haven't just been confined to 10.0 as I've been dealing with some kind of issue for months now and could use the insight. With FreeBSD 9.2-RELEASE, b27_8 is the last release that worked absolutely solid. However, reverting to an older version doesn't seem to resolve my issues on 10.0 like it did for 9.2. So as for this weekend, I just went to FreeBSD 10 and can't seem to get it to run on either the current b30 version or b27_8 version that worked well for me before. Here is a description of the symptoms I've seen over the past 3 months: - OpenJDK6 b28/FreeBSD 9.2 - I would get this error message after around 18-24 hours of starting the Java. kernel: sonewconn: pcb 0xfffffe0068969188: Listen queue overflow: 76 already in queue awaiting acceptance Also on b28, if I removed my library and had it search through all my media files, it would lock up after an hour. I don't have the exact error message but the Java process would hit whatever the "kern.maxfilesperproc" sysctl was set to and would not be able to read in new files. It would appear the the former error from opening and not closing sockets could be triggered much faster from opening and closing files in my media library. - OpenJDK b29/FreeBSD 9.2 - I had 3 kernel panics from the VM bug that came up. I immediately reverted back to b27_8 and didn't try again after the errata fix was released since I was planning on just moving to 10.0. - OpenJDK b30 and b27_8/FreeBSD 10.0, I've seen multiple crashes with various messages. The headers from the 10 error files I have follow. One of these was built with GCC4.8 just to give that a try. All others with system default Clang. Any thoughts or ideas? I'm going to try some of the other Java versions and if that fails a dedicated jail running FreeBSD 9.2 on my 10.0 host replicating the versions that worked for me prior. Note, I have the full dump messages for all of these crashes below for anybody interested. Respectfully, Jason Unovitch # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000801c3d429, pid=80584, tid=101388 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x43d429] +0x2bc019 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000801da6553, pid=82439, tid=34410369024 # # JRE version: 6.0_32-b27 # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x5a6553] JVM_FindSignal+0xb4373 # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x0000000801c8b413, pid=91659, tid=100649 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x48b413] AsyncGetCallTrace+0x57393 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000803989a3e, pid=91970, tid=101485 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # J org.apache.derby.impl.store.raw.data.StoredPage.releaseExclusive()V # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000000000000, pid=93147, tid=34410372096 # # JRE version: 6.0_32-b27 # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x74c5cf] JVM_handle_bsd_signal+0x11becf # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x000000080392492a, pid=95509, tid=101328 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # J java.lang.ThreadLocal.getMap(Ljava/lang/Thread;)Ljava/lang/ThreadLocal$ThreadLocalMap; # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000801f2474d, pid=79598, tid=100707 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x72474d] JVM_handle_bsd_signal+0x81a4d # From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 03:40:29 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CBA8C37 for ; Mon, 27 Jan 2014 03:40:29 +0000 (UTC) Received: from smtp.mail.witopia.net (prod00.mail.witopia.net [74.115.160.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2E31978 for ; Mon, 27 Jan 2014 03:40:28 +0000 (UTC) Received: from magrathea.distal.com (pool-108-31-29-11.washdc.fios.verizon.net [108.31.29.11]) (Authenticated sender: cross@witopia.net) by smtp.mail.witopia.net (Postfix) with ESMTPSA id 85016197 for ; Mon, 27 Jan 2014 03:33:48 +0000 (UTC) From: Chris Ross Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Advertising a specific address and/or port range for ftpd Message-Id: Date: Sun, 26 Jan 2014 22:33:46 -0500 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 03:40:29 -0000 I am migrating some server functionality from a NetBSD host to a newly = built FreeBSD (stable/10) host. One of the functions of this server is = accepting authenticated FTP connections to receive data files. The = NetBSD ftpd has a configuration file (ftpd.conf) that allows, amongst = other things, setting the "advertised address" and "port range" to be = used for PASV connections (and assumedly EPSV, for port range). Is any = of this possible with the base ftpd in FreeBSD 10? If not, is there a = well-known suggested port that can be configured to perform this way? = Running ftpd out of inetd would be fine, but I could run it as a = long-lived service if that's strongly recommended. Thanks. - Chris From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 07:07:44 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5E10D63; Mon, 27 Jan 2014 07:07:44 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18F1E17AA; Mon, 27 Jan 2014 07:07:40 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0R6fZE9077377; Mon, 27 Jan 2014 08:41:35 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0R6fYfX077201; Mon, 27 Jan 2014 06:41:34 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 27 Jan 2014 06:41:34 GMT Message-Id: <201401270641.s0R6fYfX077201@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 07:07:44 -0000 TB --- 2014-01-27 03:10:35 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-27 03:10:35 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-27 03:10:35 - starting RELENG_10 tinderbox run for armv6/arm TB --- 2014-01-27 03:10:35 - cleaning the object tree TB --- 2014-01-27 03:10:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-27 03:11:28 - At svn revision 261201 TB --- 2014-01-27 03:11:29 - building world TB --- 2014-01-27 03:11:29 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 03:11:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 03:11:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 03:11:29 - SRCCONF=/dev/null TB --- 2014-01-27 03:11:29 - TARGET=arm TB --- 2014-01-27 03:11:29 - TARGET_ARCH=armv6 TB --- 2014-01-27 03:11:29 - TZ=UTC TB --- 2014-01-27 03:11:29 - __MAKE_CONF=/dev/null TB --- 2014-01-27 03:11:29 - cd /src TB --- 2014-01-27 03:11:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 27 03:11:40 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 27 06:38:18 UTC 2014 TB --- 2014-01-27 06:38:18 - generating LINT kernel config TB --- 2014-01-27 06:38:18 - cd /src/sys/arm/conf TB --- 2014-01-27 06:38:18 - /usr/bin/make -B LINT TB --- 2014-01-27 06:38:18 - cd /src/sys/arm/conf TB --- 2014-01-27 06:38:18 - /usr/sbin/config -m LINT TB --- 2014-01-27 06:38:18 - skipping LINT kernel TB --- 2014-01-27 06:38:18 - cd /src/sys/arm/conf TB --- 2014-01-27 06:38:18 - /usr/sbin/config -m AC100 TB --- 2014-01-27 06:38:18 - building AC100 kernel TB --- 2014-01-27 06:38:18 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 06:38:18 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 06:38:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 06:38:18 - SRCCONF=/dev/null TB --- 2014-01-27 06:38:18 - TARGET=arm TB --- 2014-01-27 06:38:18 - TARGET_ARCH=armv6 TB --- 2014-01-27 06:38:18 - TZ=UTC TB --- 2014-01-27 06:38:18 - __MAKE_CONF=/dev/null TB --- 2014-01-27 06:38:18 - cd /src TB --- 2014-01-27 06:38:18 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Mon Jan 27 06:38:19 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AC100 completed on Mon Jan 27 06:41:30 UTC 2014 TB --- 2014-01-27 06:41:30 - cd /src/sys/arm/conf TB --- 2014-01-27 06:41:30 - /usr/sbin/config -m ARMADAXP TB --- 2014-01-27 06:41:30 - building ARMADAXP kernel TB --- 2014-01-27 06:41:30 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 06:41:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 06:41:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 06:41:30 - SRCCONF=/dev/null TB --- 2014-01-27 06:41:30 - TARGET=arm TB --- 2014-01-27 06:41:30 - TARGET_ARCH=armv6 TB --- 2014-01-27 06:41:30 - TZ=UTC TB --- 2014-01-27 06:41:30 - __MAKE_CONF=/dev/null TB --- 2014-01-27 06:41:30 - cd /src TB --- 2014-01-27 06:41:30 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP >>> Kernel build for ARMADAXP started on Mon Jan 27 06:41:30 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/arm.armv6/src/tmp/legacy/usr/sbin:/obj/arm.armv6/src/tmp/legacy/usr/bin:/obj/arm.armv6/src/tmp/legacy/usr/games:/obj/arm.armv6/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/arm.armv6/src/sys/ARMADAXP/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-27 06:41:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-27 06:41:33 - ERROR: failed to build ARMADAXP kernel TB --- 2014-01-27 06:41:33 - 9486.70 user 3131.92 system 12657.99 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-armv6-arm.full From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 08:55:54 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75F9D97E for ; Mon, 27 Jan 2014 08:55:54 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BCD51FA4 for ; Mon, 27 Jan 2014 08:55:54 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id rd3so5652785pab.30 for ; Mon, 27 Jan 2014 00:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1r6ne3nBUU5WhNk2oUvaBM9wl42BwVXbgZIsrXZDiiQ=; b=uOkswcZzdnhdAk8nNSDmIhbiheMdExursmMZWETxLFv/zgS/yo8X7TeSS4kRgmVHgx +ezYUCADMEB1lugP0G175kDSMdw4d535ObN+oBcZTjz4GOQvPNERAXfUCINBAKIaVb1M WcWymbu0+Zs8iImVpEVF345J/Bybshssalves5XaeyRqE3qZrJy4kdHAxU6mabhjxZ6g 8AQjNA8DDjmuBjWxRCTKqSRRIPfq/noLwWBN5/g7UWuK6NTrfvurNA6Bx3sPZNHEHVkJ vT2Lt8QFPmS4U9sgUr6vPM7FsYMn1b39UiaW0fIvTuMmRRjjMAwGihlvP6nkoRw3Qn+G ZcDQ== MIME-Version: 1.0 X-Received: by 10.68.209.193 with SMTP id mo1mr29524306pbc.38.1390812953354; Mon, 27 Jan 2014 00:55:53 -0800 (PST) Received: by 10.68.234.42 with HTTP; Mon, 27 Jan 2014 00:55:53 -0800 (PST) In-Reply-To: <20140126215845.3b62debf03dade433622e9ba@yamagi.org> References: <52E0E917.3060403@li.ru> <20140126215845.3b62debf03dade433622e9ba@yamagi.org> Date: Mon, 27 Jan 2014 10:55:53 +0200 Message-ID: Subject: Re: 10.0, csh history merge broken? From: Alexander Yerenkow To: Yamagi Burmeister Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: stable@freebsd.org, amarat@li.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 08:55:54 -0000 >Maybe it would be a good idea to cherry pick those two revisions and >merge then into FreeBSD, until a new tcsh version is released. I think this is must, since currently any regular shutdown can break login ability (if server is high loaded + history file is broken and big enough). I have now locked history file with chflags until fix will come. -- Regards, Alexander Yerenkow From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 12:16:13 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B70CE96D; Mon, 27 Jan 2014 12:16:13 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ECBED1247; Mon, 27 Jan 2014 12:16:09 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0RCG56w095545; Mon, 27 Jan 2014 14:16:05 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0RCG3Ng095286; Mon, 27 Jan 2014 12:16:03 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 27 Jan 2014 12:16:03 GMT Message-Id: <201401271216.s0RCG3Ng095286@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 12:16:13 -0000 TB --- 2014-01-27 10:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-27 10:40:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-27 10:40:44 - starting RELENG_10 tinderbox run for mips64/mips TB --- 2014-01-27 10:40:44 - cleaning the object tree TB --- 2014-01-27 10:40:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-27 10:41:35 - At svn revision 261208 TB --- 2014-01-27 10:41:36 - building world TB --- 2014-01-27 10:41:36 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 10:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 10:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 10:41:36 - SRCCONF=/dev/null TB --- 2014-01-27 10:41:36 - TARGET=mips TB --- 2014-01-27 10:41:36 - TARGET_ARCH=mips64 TB --- 2014-01-27 10:41:36 - TZ=UTC TB --- 2014-01-27 10:41:36 - __MAKE_CONF=/dev/null TB --- 2014-01-27 10:41:36 - cd /src TB --- 2014-01-27 10:41:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jan 27 10:41:47 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 27 12:06:28 UTC 2014 TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m ADM5120 TB --- 2014-01-27 12:06:28 - skipping ADM5120 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m ALCHEMY TB --- 2014-01-27 12:06:28 - skipping ALCHEMY kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AP121 TB --- 2014-01-27 12:06:28 - skipping AP121 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AP91 TB --- 2014-01-27 12:06:28 - skipping AP91 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AP93 TB --- 2014-01-27 12:06:28 - skipping AP93 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AP94 TB --- 2014-01-27 12:06:28 - skipping AP94 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AP96 TB --- 2014-01-27 12:06:28 - skipping AP96 kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AR71XX_BASE TB --- 2014-01-27 12:06:28 - skipping AR71XX_BASE kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AR724X_BASE TB --- 2014-01-27 12:06:28 - skipping AR724X_BASE kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AR91XX_BASE TB --- 2014-01-27 12:06:28 - skipping AR91XX_BASE kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AR933X_BASE TB --- 2014-01-27 12:06:28 - skipping AR933X_BASE kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m AR934X_BASE TB --- 2014-01-27 12:06:28 - skipping AR934X_BASE kernel TB --- 2014-01-27 12:06:28 - cd /src/sys/mips/conf TB --- 2014-01-27 12:06:28 - /usr/sbin/config -m BERI_DE4_BASE TB --- 2014-01-27 12:06:28 - building BERI_DE4_BASE kernel TB --- 2014-01-27 12:06:28 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 12:06:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 12:06:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 12:06:28 - SRCCONF=/dev/null TB --- 2014-01-27 12:06:28 - TARGET=mips TB --- 2014-01-27 12:06:28 - TARGET_ARCH=mips64 TB --- 2014-01-27 12:06:28 - TZ=UTC TB --- 2014-01-27 12:06:28 - __MAKE_CONF=/dev/null TB --- 2014-01-27 12:06:28 - cd /src TB --- 2014-01-27 12:06:28 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Mon Jan 27 12:06:28 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_BASE completed on Mon Jan 27 12:11:10 UTC 2014 TB --- 2014-01-27 12:11:10 - cd /src/sys/mips/conf TB --- 2014-01-27 12:11:10 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2014-01-27 12:11:10 - building BERI_DE4_MDROOT kernel TB --- 2014-01-27 12:11:10 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 12:11:10 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 12:11:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 12:11:10 - SRCCONF=/dev/null TB --- 2014-01-27 12:11:10 - TARGET=mips TB --- 2014-01-27 12:11:10 - TARGET_ARCH=mips64 TB --- 2014-01-27 12:11:10 - TZ=UTC TB --- 2014-01-27 12:11:10 - __MAKE_CONF=/dev/null TB --- 2014-01-27 12:11:10 - cd /src TB --- 2014-01-27 12:11:10 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Mon Jan 27 12:11:10 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Mon Jan 27 12:16:00 UTC 2014 TB --- 2014-01-27 12:16:00 - cd /src/sys/mips/conf TB --- 2014-01-27 12:16:00 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2014-01-27 12:16:01 - building BERI_DE4_SDROOT kernel TB --- 2014-01-27 12:16:01 - CROSS_BUILD_TESTING=YES TB --- 2014-01-27 12:16:01 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-27 12:16:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-27 12:16:01 - SRCCONF=/dev/null TB --- 2014-01-27 12:16:01 - TARGET=mips TB --- 2014-01-27 12:16:01 - TARGET_ARCH=mips64 TB --- 2014-01-27 12:16:01 - TZ=UTC TB --- 2014-01-27 12:16:01 - __MAKE_CONF=/dev/null TB --- 2014-01-27 12:16:01 - cd /src TB --- 2014-01-27 12:16:01 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Mon Jan 27 12:16:01 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools [...] yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /src/sys/dev/aic7xxx/aicasm/aicasm_macro_gram.y cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/BERI_DE4_SDROOT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-27 12:16:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-27 12:16:02 - ERROR: failed to build BERI_DE4_SDROOT kernel TB --- 2014-01-27 12:16:02 - 4026.05 user 1976.26 system 5718.35 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-mips64-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 13:22:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF189651 for ; Mon, 27 Jan 2014 13:22:02 +0000 (UTC) Received: from smtp.lamaiziere.net (net.lamaiziere.net [37.59.62.186]) by mx1.freebsd.org (Postfix) with ESMTP id 94DA017C4 for ; Mon, 27 Jan 2014 13:22:02 +0000 (UTC) Received: from mr185083.univ-rennes1.fr (mr185083.univ-rennes1.fr [129.20.185.83]) by smtp.lamaiziere.net (Postfix) with ESMTPA id A0A9729C3; Mon, 27 Jan 2014 14:13:50 +0100 (CET) Received: from mr185083 (localhost [127.0.0.1]) by mr185083.univ-rennes1.fr (Postfix) with ESMTP id 5240170DC; Mon, 27 Jan 2014 14:13:50 +0100 (CET) Date: Mon, 27 Jan 2014 14:13:50 +0100 From: Patrick Lamaiziere To: Chris Ross , freebsd-stable@freebsd.org Subject: Re: Advertising a specific address and/or port range for ftpd Message-ID: <20140127141350.768fccea@mr185083> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (smtp.lamaiziere.net [0.0.0.0]); Mon, 27 Jan 2014 14:13:50 +0100 (CET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:22:02 -0000 Le Sun, 26 Jan 2014 22:33:46 -0500, Chris Ross a écrit : > I am migrating some server functionality from a NetBSD host to a > newly built FreeBSD (stable/10) host. One of the functions of this > server is accepting authenticated FTP connections to receive data > files. The NetBSD ftpd has a configuration file (ftpd.conf) that > allows, amongst other things, setting the "advertised address" and > "port range" to be used for PASV connections (and assumedly EPSV, for > port range). Is any of this possible with the base ftpd in FreeBSD > 10? If not, is there a well-known suggested port that can be > configured to perform this way? Running ftpd out of inetd would be > fine, but I could run it as a long-lived service if that's strongly > recommended. I don't know for the base ftpd, pure-ftpd has these features. I use it since years without any problem. It also provides virtual users and is IMO very easy to configure. Regards, From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 13:26:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0569F77F; Mon, 27 Jan 2014 13:26:01 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C77B01811; Mon, 27 Jan 2014 13:26:00 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so5852923pbb.7 for ; Mon, 27 Jan 2014 05:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7TwSL9DXHELUx0EFBC+BC6iLd6P4BgmmNw2q2PxIZQI=; b=pnlYsaMCvhS1Gx4Wbt2f8LnaD9V7aECok9i5J7xZb18U6tkcXu3MuEonTsMqBpDBxM k1z5PdHuMFgSdEwJ/Bir/bWnD+kUTooS9SIYE0lTJia+CnUcubxAdEtGE80MohXbrzmA oThKz6bua37h8hp2R7/niVYE9NRpvI3TAY/Ngg58zVur0ngshSZ7PlKHzx03AU5ZPTNg cX1DItcN/te6HUGDL6TfS0lJu3dNGTJHnNpTCZQBI+wtl8gyocmTx8pGR21r4yjDqubB /cI2RYNJ9vStkmO2lVLanf7+6Tw8Lbf0sDhB/7adJTnXNv2Jyk9cgOj64DkAcOGTMZjd /vgw== MIME-Version: 1.0 X-Received: by 10.66.14.41 with SMTP id m9mr30300193pac.123.1390829158470; Mon, 27 Jan 2014 05:25:58 -0800 (PST) Received: by 10.70.88.101 with HTTP; Mon, 27 Jan 2014 05:25:58 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Jan 2014 08:25:58 -0500 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Kenneth Culver To: Jason Unovitch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:26:01 -0000 I have seen similar issues with ps3mediaserver and openjdk7. It crashes and dumps core if I try to do anything that stresses it (like fastforwarding more than 1.5x on my ps3). I have been working around it but it is annoying. Ken On Sunday, January 26, 2014, Jason Unovitch wrote: > Evening FreeBSD Java/Stable, > Anybody out there seeing any issues with Java performance on FreeBSD > 10? I've recently updated my home NAS box from 9.2-RELEASE-p3 to > 10.0-RELEASE and simply cannot get my Serviio media center jail using > OpenJDK6 to stay running without getting some kind of Java crash. To > be fair, the Java crashes haven't just been confined to 10.0 as I've > been dealing with some kind of issue for months now and could use the > insight. With FreeBSD 9.2-RELEASE, b27_8 is the last release that > worked absolutely solid. However, reverting to an older version > doesn't seem to resolve my issues on 10.0 like it did for 9.2. So as > for this weekend, I just went to FreeBSD 10 and can't seem to get it > to run on either the current b30 version or b27_8 version that worked > well for me before. > > Here is a description of the symptoms I've seen over the past 3 months: > > - OpenJDK6 b28/FreeBSD 9.2 - I would get this error message after > around 18-24 hours of starting the Java. > > kernel: sonewconn: pcb 0xfffffe0068969188: Listen queue overflow: 76 > already in queue awaiting acceptance > > Also on b28, if I removed my library and had it search through all my > media files, it would lock up after an hour. I don't have the exact > error message but the Java process would hit whatever the > "kern.maxfilesperproc" sysctl was set to and would not be able to read > in new files. It would appear the the former error from opening and > not closing sockets could be triggered much faster from opening and > closing files in my media library. > > - OpenJDK b29/FreeBSD 9.2 - I had 3 kernel panics from the VM bug that > came up. I immediately reverted back to b27_8 and didn't try again > after the errata fix was released since I was planning on just moving > to 10.0. > > - OpenJDK b30 and b27_8/FreeBSD 10.0, I've seen multiple crashes with > various messages. The headers from the 10 error files I have follow. > One of these was built with GCC4.8 just to give that a try. All > others with system default Clang. > > Any thoughts or ideas? I'm going to try some of the other Java > versions and if that fails a dedicated jail running FreeBSD 9.2 on my > 10.0 host replicating the versions that worked for me prior. > > Note, I have the full dump messages for all of these crashes below for > anybody interested. > > Respectfully, Jason Unovitch > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000801c3d429, pid=80584, tid=101388 > # > # JRE version: 6.0_32-b30 > # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x43d429] +0x2bc019 > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000801da6553, pid=82439, tid=34410369024 > # > # JRE version: 6.0_32-b27 > # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x5a6553] JVM_FindSignal+0xb4373 > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x0000000801c8b413, pid=91659, tid=100649 > # > # JRE version: 6.0_32-b30 > # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x48b413] AsyncGetCallTrace+0x57393 > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000803989a3e, pid=91970, tid=101485 > # > # JRE version: 6.0_32-b30 > # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # J org.apache.derby.impl.store.raw.data.StoredPage.releaseExclusive()V > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=93147, tid=34410372096 > # > # JRE version: 6.0_32-b27 > # Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x74c5cf] JVM_handle_bsd_signal+0x11becf > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x000000080392492a, pid=95509, tid=101328 > # > # JRE version: 6.0_32-b30 > # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # J > java.lang.ThreadLocal.getMap(Ljava/lang/Thread;)Ljava/lang/ThreadLocal$ThreadLocalMap; > # > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000801f2474d, pid=79598, tid=100707 > # > # JRE version: 6.0_32-b30 > # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x72474d] JVM_handle_bsd_signal+0x81a4d > # > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 13:48:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D95F93C9 for ; Mon, 27 Jan 2014 13:48:17 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 979A719CE for ; Mon, 27 Jan 2014 13:48:17 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W7mXo-0003pJ-Gy for freebsd-stable@freebsd.org; Mon, 27 Jan 2014 14:48:08 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Advertising a specific address and/or port range for ftpd References: <20140127141350.768fccea@mr185083> Date: Mon, 27 Jan 2014 14:48:07 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <20140127141350.768fccea@mr185083> User-Agent: Opera Mail/12.16 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: 51a43cd7ff6838d9e9bce89dbcde6c26 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:48:17 -0000 On Mon, 27 Jan 2014 14:13:50 +0100, Patrick Lamaiziere = wrote: > Le Sun, 26 Jan 2014 22:33:46 -0500, > Chris Ross a =E9crit : > >> I am migrating some server functionality from a NetBSD host to a >> newly built FreeBSD (stable/10) host. One of the functions of this >> server is accepting authenticated FTP connections to receive data >> files. The NetBSD ftpd has a configuration file (ftpd.conf) that >> allows, amongst other things, setting the "advertised address" and >> "port range" to be used for PASV connections (and assumedly EPSV, for= >> port range). Is any of this possible with the base ftpd in FreeBSD >> 10? If not, is there a well-known suggested port that can be >> configured to perform this way? Running ftpd out of inetd would be >> fine, but I could run it as a long-lived service if that's strongly >> recommended. > > I don't know for the base ftpd, pure-ftpd has these features. I use > it since years without any problem. It also provides virtual users and= > is IMO very easy to configure. I guess it gets less useful to have (and support) a ftp server in base. Ronald. From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 13:59:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06A91762 for ; Mon, 27 Jan 2014 13:59:49 +0000 (UTC) Received: from owa.bsquare.com (firewall.bsquare.com [206.165.213.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA4201A97 for ; Mon, 27 Jan 2014 13:59:48 +0000 (UTC) Received: from [10.150.16.15] (10.150.16.15) by BREAL.camelot.bsquare.com (192.168.100.67) with Microsoft SMTP Server id 14.3.123.3; Mon, 27 Jan 2014 05:58:41 -0800 Message-ID: <52E66612.9080009@bsquare.com> Date: Mon, 27 Jan 2014 13:58:42 +0000 From: Mike Pumford User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: Subject: Re: Advertising a specific address and/or port range for ftpd References: <20140127141350.768fccea@mr185083> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.150.16.15] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 13:59:49 -0000 Ronald Klop wrote: > On Mon, 27 Jan 2014 14:13:50 +0100, Patrick Lamaiziere > wrote: > >> Le Sun, 26 Jan 2014 22:33:46 -0500, >> Chris Ross a écrit : >> >>> I am migrating some server functionality from a NetBSD host to a >>> newly built FreeBSD (stable/10) host. One of the functions of this >>> server is accepting authenticated FTP connections to receive data >>> files. The NetBSD ftpd has a configuration file (ftpd.conf) that >>> allows, amongst other things, setting the "advertised address" and >>> "port range" to be used for PASV connections (and assumedly EPSV, for >>> port range). Is any of this possible with the base ftpd in FreeBSD >>> 10? If not, is there a well-known suggested port that can be >>> configured to perform this way? Running ftpd out of inetd would be >>> fine, but I could run it as a long-lived service if that's strongly >>> recommended. Last time I checked (which admittedly was a couple of years ago the netbsd FTP daemon was in ports (as nbftpd) so you could just install that and migrate the config. Mike From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 21:03:43 2014 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAE45A85; Mon, 27 Jan 2014 21:03:43 +0000 (UTC) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) by mx1.freebsd.org (Postfix) with ESMTP id 96A9010D5; Mon, 27 Jan 2014 21:03:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:From:Date; bh=DPGIbzCt1XvUMy2AuPIu6jBTm9vvnRfQb4mkHW/rfNo=; b=mq3+vBA/5nGWf2sGpUyHfUWn/f/09/KIBRaoHJLsMm+LR96+ecIjjFtksphGCwyZDccbY5RhR7cNmWshUcMLw34LdnrJMJGC5hpAq9ka2P6w5bvJYk916xdtOmuYy0ZOp7g1hhropt23bLMfUCpsFaV6/it9gq/OnJ67+3MepTQ=; Received: from iglou3.iglou.com ([192.107.41.6]:64039 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1W7tLD-0000Fq-VV by authid with igloumta_auth; Mon, 27 Jan 2014 16:03:35 -0500 Received: from shell1.iglou.com ([192.107.41.17]:49832 helo=shell1) by mail.iglou.com with esmtps (TLS cipher TLSv1:AES256-SHA:256) (Exim MTA/8.19.3) (envelope-from ) id 1W7tLD-00044N-KL; Mon, 27 Jan 2014 16:03:35 -0500 Date: Mon, 27 Jan 2014 16:03:35 -0500 (EST) From: Darrel X-X-Sender: levitch@shell1 To: Ryan Steinmetz Subject: Re: freeradius3 dhcp.dictionary error In-Reply-To: <20140124231625.GB33923@exodus.zi0r.com> Message-ID: References: <20140122195843.GA901@exodus.zi0r.com> <20140122210752.GA35660@exodus.zi0r.com> <20140122223636.GA68486@exodus.zi0r.com> <20140124231625.GB33923@exodus.zi0r.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Originating-IP: 192.107.41.17 X-IgLou-Customer: 3cb6f76205bd20f518810676a67a982b Cc: FreeBSD-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 21:03:43 -0000 > > Darrel, > > Please try the attached patch. > > Thanks! > -r > Been out of town, Ryan. Probably tomorrow. D From owner-freebsd-stable@FreeBSD.ORG Mon Jan 27 21:14:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1255FB for ; Mon, 27 Jan 2014 21:14:05 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA3F011F4 for ; Mon, 27 Jan 2014 21:14:05 +0000 (UTC) Received: from blazon-pc.rw.local ([78.84.244.14]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0Lskbn-1VAajM1PZJ-012KmV for ; Mon, 27 Jan 2014 22:08:53 +0100 Message-ID: <52E6CB2B.9040208@mail.com> Date: Mon, 27 Jan 2014 23:10:03 +0200 From: Jeff Tipton User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121030 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re:regression: msk0 watchdog timeout and interrupt storm X-Provags-ID: V03:K0:i2Sr6mMUjXYHC7w3h7qyO3b+v0bfON8veImpMpU8pF+4AYhRn4N ta/ZFaZ4HiCyoE8Vww7q+Zz3MNFelR+bgJJoty9Y85NC8bgSndqZALIFUWaCa7I9HgG9FnJ nmvu3cATyv8W2yXdEJ/wCAfbDJFBdK2aFjEW9WrM0zXnNaWi5eDWAUTn0Izl5aI5nUL3Lr8 Ws/oLkkfNKQFN0JaMV95Q== Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 21:14:05 -0000 Hi, I also have this problem on Samsung N220 netbook, except I don't have any "interrupt storm" messages. When it boots up, it works a couple of minutes, and then "msk0: watchdog timeout" message appears. And, yes, the fastest way to reproduce the error is to try to copy a file via scp (even a 6MB file is enough). uname -a FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 pciconf -lcv [..] mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab rev=0x00 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8040 PCI-E Fast Ethernet Controller' class = network subclass = ethernet cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L0s/L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[130] = Serial 1 f0d173ffff542400 I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just fine there. I also tried to change if_mskreg.h as Curtis suggested, recompiled the kernel but it didn't help; nothing changed :( Jeff From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 03:45:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD4C0DAE for ; Tue, 28 Jan 2014 03:45:19 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C09011E9 for ; Tue, 28 Jan 2014 03:45:19 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id k19so10958824igc.5 for ; Mon, 27 Jan 2014 19:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=dXLI4gnGEa7nGRr1S97Ns6kiWxCaTNIYtHHyM6CESe0=; b=Dv4wef4BGKASc756H3+SUy/Rxdn+GY1RuMBD4zaRkc4uCsMixr9tYgU/ksRfyQL3IN GzluYtg6xGP/zzNRJxQ5NxR+3SyjcdglJHP3f94biFwtTN/fr7oyu7VEhHHq2PseiwxX bQ6ckd/mav19QCvbF4rGF7iAy9UTPN8xUWANs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=dXLI4gnGEa7nGRr1S97Ns6kiWxCaTNIYtHHyM6CESe0=; b=BnD0VFtKGNJC9Tj+xaziJKpJBrgPidXR3Mkd1xlM2KqiunvbF+o/lrHtEXEpvUe0MZ n7aJWXV/fG3TUJIVgUdzd7vBSw4Do5Uha+HacWZerYBnwp9nKyWCpBqLpNEeUMp76L0u BN9KD0xsUS81tfkXUY6ae54fTWckGK5a47O5ap3JSEUMtogzQhneUfacUn9ruWkAc/gb dXBySJrWUDZrXkCf2FUPkl9GFGxBkDiRLuFKoBgvY41YimV0OJj2NC4B1CmTpz8Ik/lB KIwnZ2HwJ8qFABE5mY1aYX6e84Xgc0cfge2IESA4KTlphWaGsSUQFqFs/CRS1ti0xQmV oqIA== X-Gm-Message-State: ALoCoQm6bSBohwiDgEYygeYCj3a9e/uuPtyHdY7g+3UXg9I465sfml7gfEEaGarkPRa5/d90dD3D X-Received: by 10.42.123.199 with SMTP id t7mr4860482icr.45.1390880718314; Mon, 27 Jan 2014 19:45:18 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id l7sm50663166igx.2.2014.01.27.19.45.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 19:45:17 -0800 (PST) Subject: FreeBSD 10-STABLE/PowerPC nullfs regression From: Jason Hellenthal Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4DDB4272-081C-4871-8DBF-3C849C0711CD; protocol="application/pkcs7-signature" X-Mailer: iPhone Mail (11B554a) Message-Id: <78AD0F38-AB7B-4724-A8B1-1705D77A0E62@dataix.net> Date: Mon, 27 Jan 2014 22:45:14 -0500 To: "[FreeBSD Stable]" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 03:45:19 -0000 --Apple-Mail-4DDB4272-081C-4871-8DBF-3C849C0711CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Anyone noticed under the subject listed details that nullfs has taken a dive= ? The Mac G4 I have is barely stable and I can't even get it to produce a cras= h dump let alone hold pressure on a filesystem in RW for greater than 10 min= utes. It would seem that a memory exhaustion may be present here but I'm not= certain. I've tried about everything I can think of to produce further info= but it's all failed. The configuration is just generic and use nullfs in a similar fashion as you= would find with ZFS to mount from a UFS drive RW onto another like the foll= owing mount point . . .=20 =46rom UFS to UFS non-journaled on both sides. /export/usr/obj /usr/obj nullfs rw 0 0 While I have other mount points using nullfs for RO configuration like src a= nd ports specifically using it to keep stuff clean. /export/usr/src /usr/src ro 0 0 This all worked on 8.X and 9.X branches flawlessly for a long time but here o= n 10.X it is rather obscure. Thanks for any insight. PS: yeah I know .. Symlinks would suffice for the RW ops but that's not the= point. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN= --Apple-Mail-4DDB4272-081C-4871-8DBF-3C849C0711CD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEyODAzNDUxNlowIwYJKoZIhvcN AQkEMRYEFLEj5EhDOlj+VIJOYNPiYJFY+mECMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAc+b6TZt7W4ODXfxxZBhU YNMpyMdXcA839zni9DxleyRUivnqJd3QYJxCQktlpmA5fWTG+Bs1tePZ3XUf9WqXUeEa7zl10UYl aT2FvSi65Zg4qd/vUEgQw74WHWz8MxTj4G+1hxeoAiX98mh49eh/IYMUYUfzuwIXGxxZtwQjwr3Y K5G3GAazfxpW0PmuA8Yxc60K+Rygpf16Pj4TCW2m7YgBqL2a3d1UBRxXNSnc4uTcvFRq8iOFnrCJ d8ab7+GzXJYWGUhJygpKJ/q89DjzAVvDGK3j1sWG45BkcW5pv89P4E3gRKOP314pINaqJm6JlqjD K+333vUT9hGWxwVQuQAAAAAAAA== --Apple-Mail-4DDB4272-081C-4871-8DBF-3C849C0711CD-- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 07:16:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DB55410; Tue, 28 Jan 2014 07:16:30 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13D411F79; Tue, 28 Jan 2014 07:16:30 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id v10so6187pde.27 for ; Mon, 27 Jan 2014 23:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jidnN1AOVCs5gApHG0S758txJYP83NXFxdZ2ktXNrcc=; b=rI+UjxrboKupplerj6VzQ2iqL2GlIgTb5bu2p3otJbJFWT2G1elOfYj4wwnTEOE/4b FbGyq4kUwqytUYKTbTJSl3kynG7q0GQAkqPo29uXJSJfvjGynM005liVp4SGE5ffoEOs hcl/t1Wn9fLFkz/NxAeUwQG13FzqL/Dbd4kBoPw+I1H7LiHqvG41keX41bEdLy2/L9Zt yzXMpLVIiDkfxDHV32qyj8v8efzPWiUIXhC2x32rhHPvf2gC7gVvip7O1PUMrsgozYOP IVdonCCR9X9NuWwBVor5yBk8C4oBFF/3RFVX75qajBJ+t5MRQAikwCMhLL/oJUu+WUyN TOWg== MIME-Version: 1.0 X-Received: by 10.68.17.41 with SMTP id l9mr34537285pbd.76.1390893389565; Mon, 27 Jan 2014 23:16:29 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Mon, 27 Jan 2014 23:16:29 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Jan 2014 23:16:29 -0800 X-Google-Sender-Auth: jptXVLNSRrkg1vJWTsayoNjq9UY Message-ID: Subject: Re: IWN hangs periodically on 10.0RC3 From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Stable Mailing List , Lars Engels X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:16:30 -0000 On Fri, Jan 10, 2014 at 9:51 PM, Kevin Oberman wrote: > On Fri, Jan 10, 2014 at 9:37 AM, Adrian Chadd wrote: > >> .. when you see it hang, does anything get logged in dmesg (eg a >> firmware panic) ? >> >> Try recompiling your kernel with: >> >> IEEE80211_DEBUG >> IWN_DEBUG >> >> That way it can be debugged :) >> >> The first thing I'd check is whether there's more fun races going on >> in the crypto code - try wlandebug +crypto . >> >> >> -a >> > > I just sent a message about issues I am seeing with my IWN to wireless@. > Then I saw these responses. Sorry. > > As far as logs go, I wee a number if cases of the following sequence: > Jan 1 18:00:12 rogue dbus[1451]: [system] Activating service > name='org.freedesktop.PackageKit' (using servicehelper) > Jan 1 18:00:12 rogue dbus[1451]: [system] Successfully activated service > 'org.freedesktop.PackageKit' > Jan 1 18:28:56 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-DISCONNECTED > bssid=00:26:b8:67:c3:2d reason=0 > Jan 1 18:28:56 rogue kernel: wlan0: link state changed to DOWN > Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Trying to associate with > 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) > Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Associated with > 00:26:b8:67:c3:2d > Jan 1 18:28:59 rogue kernel: wlan0: link state changed to UP > Jan 1 18:28:59 rogue dhclient[652]: send_packet: No buffer space available > Jan 1 18:28:59 rogue devd: Executing '/etc/rc.d/dhclient quietstart wlan0' > Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: WPA: Key negotiation > completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] > Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-CONNECTED - > Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] > Jan 1 18:29:02 rogue dhclient: New IP Address (wlan0): 192.168.1.5 > Jan 1 18:29:02 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 > Jan 1 18:29:02 rogue dhclient: New Broadcast Address (wlan0): > 192.168.1.255 > Jan 1 18:29:02 rogue dhclient: New Routers (wlan0): 192.168.1.1 > > So it seems that the bounce is happening fairly often, but the system > usually recovers. It seems to be pretty consistently 2-3 time4s a day. > Note that the dbus messages about packagekit always immediately precede > the link going down. > > Every tthe or four of these fail to recover: > Jan 3 14:09:05 rogue kernel: wlan0: link state changed to DOWN > Jan 3 14:09:56 rogue ntpd[1303]: sendto(198.129.254.218) (fd=25): Network > is down > Jan 3 14:10:15 rogue ntpd[1303]: sendto(208.79.18.86) (fd=25): Network is > down > Jan 3 14:10:29 rogue ntpd[1303]: sendto(198.124.252.90) (fd=25): Network > is down > Jan 3 14:10:49 rogue ntpd[1303]: sendto(198.55.111.5) (fd=25): Network is > down > Jan 3 14:11:00 rogue ntpd[1303]: sendto(192.95.38.104) (fd=25): Network > is down > Jan 3 14:14:02 rogue ntpd[1303]: sendto(198.129.252.38) (fd=25): Network > is down > Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, val=0, > arg_len=0]: Operation not supported > Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, val=0, > arg_len=0]: Operation not supported > Jan 3 14:14:12 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-TERMINATING > Jan 3 14:14:12 rogue dhclient[652]: connection closed > Jan 3 14:14:12 rogue dhclient[652]: exiting. > Jan 3 14:14:12 rogue wpa_supplicant[67153]: Successfully initialized > wpa_supplicant > Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Trying to associate > with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) > Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Associated with > 00:26:b8:67:c3:2d > Jan 3 14:14:16 rogue kernel: wlan0: link state changed to UP > Jan 3 14:14:16 rogue devd: Executing '/etc/rc.d/dhclient quietstart wlan0' > Jan 3 14:14:16 rogue dhclient[67191]: send_packet: No buffer space > available > Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: WPA: Key negotiation > completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] > Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: CTRL-EVENT-CONNECTED - > Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] > Jan 3 14:14:18 rogue dhclient: New IP Address (wlan0): 192.168.1.5 > Jan 3 14:14:18 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 > Jan 3 14:14:18 rogue dhclient: New Broadcast Address (wlan0): > 192.168.1.255 > Jan 3 14:14:18 rogue dhclient: New Routers (wlan0): 192.168.1.1 > > The restart took place when I restarted the interface about 5 minutes > after it went down and, as you can see, it came up normally. I'll admit > that I am completely baffled by the dbus/packagekit tie-in as I can't see > what packagekit would do to touch the network. > > I'll be building a new kernel with debug shortly. > > In my other message (to wireless) I also mentioned the (possibly > unrelated) issue of poor performance and and periodic sub-second > connectivity drops. > > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > I was about to send a report that removing bgscan fixed the issue, but, then it happened again. Nothing new in the log from prior cases. Any other flags to I should try to set in wlandebug? state? assoc? I'll admit that I have no idea which might be helpful. One thing I seem to have failed to post is the ifconfig after the failure: wlan0: flags=8c43 metric 0 mtu 1500 ether a0:88:b4:c6:ad:28 inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 7 (2442 MHz 11g) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF txpower 15 bmiss 10 scanvalid 60 protmode CTS wme roaming MANUAL Note: My AP is on channel 6. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 07:51:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA2C9EB2; Tue, 28 Jan 2014 07:51:10 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9102011AD; Tue, 28 Jan 2014 07:51:10 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e01d:156b:782f:c36]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C03BB4AC2D; Tue, 28 Jan 2014 11:51:08 +0400 (MSK) Date: Tue, 28 Jan 2014 11:51:04 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <976149194.20140128115104@serebryakov.spb.ru> To: freebsd-stable@freebsd.org, hackers@FreeBSD.org Subject: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:51:10 -0000 Hello, All. I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is VGN-SZ340P, Merom generation of Core2, ~2007). It allows to select "USB Hard drive" or "USB Optical Drive" as boot device, but it writes "No operating system" in both cases. I've checked memstick and found, that it doesn't have MBR (it looks like /dev/da4a). I've added MBR, one slice, mbr bootcode, make this slice active, and dump memstick image to /dev/da4s1. My desktop boots from this memstick without problems, laptop says "No boot code". Unfortunately, this Laptop has broken CD-ROM (and it looks like by DVD-RW drive in desktop is disgunctional too, I've tried to do something with it 4 years ago). Maybe, somebody has experience of booting such old Sony Vaio from FreeBSD memstick and here is some trick to do this? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 11:08:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A9ACE93 for ; Tue, 28 Jan 2014 11:08:49 +0000 (UTC) Received: from grape.a1.org.uk (grape.a1.org.uk [46.20.239.120]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB721126 for ; Tue, 28 Jan 2014 11:08:48 +0000 (UTC) Received: from grape.a1.org.uk (grape.a1.org.uk [46.20.239.120]) (Authenticated sender: private) by grape.a1.org.uk (Mail M) with ESMTPSA id 930537F8D7 for ; Tue, 28 Jan 2014 11:02:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=a1.org.uk; s=mail; t=1390906968; bh=hD4LaR6ogC9/NjQWa5Ke22+ZzbpLSKTZDOlW8jCopK0=; h=Date:From:To:Subject:References:In-Reply-To; b=RDilfCwkERrs65/YcSrvFklcORo5LYjZlPDzHBGN8y22SuK4iz5N8aqvKUyayiTTA aLI1a4vGmHhNklsYRqjCD4X1Yj2412vzMD9gsJQsQDyGGiXUNEf2PmhGxviGz+2qlb ivoiCh0ktBuUju1jVX0hhZlKaLclDyCrwNG3FgrE= Received: from grape.a1.org.uk (grape.a1.org.uk [46.20.239.120]) by mail.a1.org.uk (Webmail) with HTTP; Tue, 28 Jan 2014 11:02:48 +0000 Date: Tue, 28 Jan 2014 11:02:48 +0000 Message-ID: <20140128110248.Horde.MbimUBauknlS545YF3OAIRA@mail.a1.org.uk> From: Bap To: freebsd-stable@freebsd.org Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? References: <976149194.20140128115104@serebryakov.spb.ru> In-Reply-To: <976149194.20140128115104@serebryakov.spb.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.23) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 11:08:49 -0000 Quoting Lev Serebryakov : > Hello, All. > > I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is > VGN-SZ340P, Merom generation of Core2, ~2007). > > It allows to select "USB Hard drive" or "USB Optical Drive" as boot device, > but it writes "No operating system" in both cases. > > I've checked memstick and found, that it doesn't have MBR (it looks like > /dev/da4a). I've added MBR, one slice, mbr bootcode, make this slice > active, and dump memstick image to /dev/da4s1. My desktop boots from this > memstick without problems, laptop says "No boot code". > > Unfortunately, this Laptop has broken CD-ROM (and it looks like by DVD-RW > drive in desktop is disgunctional too, I've tried to do something with it 4 > years ago). > > Maybe, somebody has experience of booting such old Sony Vaio from FreeBSD > memstick and here is some trick to do this? Not sure about a Vaio, but I have many machines that will not boot from larger memory sticks. Creating a 1G partion on a big stick and dd-ing onto that works for those machines. HTH, Bap > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 12:16:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C0C8E33 for ; Tue, 28 Jan 2014 12:16:02 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3EAC3167A for ; Tue, 28 Jan 2014 12:16:01 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1W87aC-0006zV-Sf for freebsd-stable@freebsd.org; Tue, 28 Jan 2014 04:16:00 -0800 Date: Tue, 28 Jan 2014 04:16:00 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1390911360834-5880684.post@n5.nabble.com> Subject: .sujournal strangeness after (?) upgrading to 10-STABLE MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 12:16:02 -0000 Unfortunately, I had my first reboot. Not trusting journal (I've enabled it on all filesystems some time ago) I did full few fscks between reboots in single user mode. Unsurprisingly, there were some inconsistencies in / and /var _but_ checking tunefs -p, actually SU+J was disabled there (on all other filesystems it was still enabled)! I don't know how that happened, previously I just didn't trust SU+J enough and did fsck anyway, I hope that explains inconsistencies. For some time I couldn't enable SU+J again, because of .sujournal actaully present both in / and /var - so there was evidence I really enabled it but somehow it disabled itself? Anyway, using chflags 0 I've removed both journals and after fsck was successful in enabling both journals again by tunefs -j enable (/ after a reboot with "read only fs modified" error). However, that new journals (initial ones were created somewhere on 9-STABLE I think) bear an actual date of enabling them- in difference to the old ones, that have just a start of Unix epoch (1970). Is it intended behaviour? /tmp $ ls -lioF .sujournal 3 -r-------- 1 root wheel schg,sunlnk,nodump,opaque 33554432 1 sty 1970 .su /tmp $ cd /var /var $ ls -lioF .sujournal 4 -r-------- 1 root wheel schg,sunlnk,nodump,opaque 33554432 28 sty 02:06 .su -- View this message in context: http://freebsd.1045724.n5.nabble.com/sujournal-strangeness-after-upgrading-to-10-STABLE-tp5880684.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 14:31:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FCA465F; Tue, 28 Jan 2014 14:31:10 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B72D12E6; Tue, 28 Jan 2014 14:31:10 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wp18so453693obc.22 for ; Tue, 28 Jan 2014 06:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vIzjs6KSOgtOizj4tNbtwkJrgtO7M9WX5B9NHiVkSOU=; b=ciJkHEf8ar2cErRuzXADysOGmciO0DkZVdvLR1SThNruENJ24ZkbTAHgqPlVWKByuN 0Bnp0OrmzHQT0H3PgUOw9zApYM2BWukNqK4Z2OEkN1x6Bbg3sD9gW3EoGPGn0NFW8HE2 8VjsroLazRcBE8wxoW9O/t8ldk82n58J3AVu/lPjPVA5LKr7uUWywS7Fov9jPNwsWH3e Kxby3OmMHNiIiTRrD0ZtCdTWimLxwg2y7RskXoBGUXofvoqsRz3wfYuSFM/KiVpj4g8M d4Rl5Sk8PkCr3qOk5qEbTS00itkNna5A2y5Z6h5azZnlBUmgGn2aUVZ0HR2Z4hIQI5bp KyWQ== MIME-Version: 1.0 X-Received: by 10.60.50.202 with SMTP id e10mr1329572oeo.39.1390919469445; Tue, 28 Jan 2014 06:31:09 -0800 (PST) Received: by 10.76.156.34 with HTTP; Tue, 28 Jan 2014 06:31:09 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 18:31:09 +0400 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: "Sevan / Venture37" To: "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 14:31:10 -0000 Jason, A couple of questions, Are you using packages or building from ports? If you're building, what does your /etc/make.conf I've been suffering from sigsegv issues for a few weeks now on my server running -current which I build world/ports on myself. I looked to see if the problems are there in 10.0-RELEASE & 11.0-CURRENT using the official packages & install CD & the problem did not manifest on either environments. I'm currently working backwards on my aforementioned server, reverting changes to find where the problem is introduced. Sevan From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 14:54:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E51963B; Tue, 28 Jan 2014 14:54:14 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74B4B14FE; Tue, 28 Jan 2014 14:54:13 +0000 (UTC) Received: from park.js.berklix.net (p5DCBCD50.dip0.t-ipconnect.de [93.203.205.80]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s0SErqtR040839; Tue, 28 Jan 2014 14:53:52 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s0SEo1qK049748; Tue, 28 Jan 2014 15:50:02 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s0SEnajv096005; Tue, 28 Jan 2014 15:49:48 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201401281449.s0SEnajv096005@fire.js.berklix.net> To: freebsd-stable@freebsd.org Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 28 Jan 2014 11:02:48 GMT." <20140128110248.Horde.MbimUBauknlS545YF3OAIRA@mail.a1.org.uk> Date: Tue, 28 Jan 2014 15:49:36 +0100 Cc: Bap , Lev Serebryakov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 14:54:14 -0000 Bap wrote: > Quoting Lev Serebryakov : > > Hello, All. > > > > I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is > > VGN-SZ340P, Merom generation of Core2, ~2007). > > > > It allows to select "USB Hard drive" or "USB Optical Drive" as boot device, > > but it writes "No operating system" in both cases. > > > > I've checked memstick and found, that it doesn't have MBR (it looks like > > /dev/da4a). I've added MBR, one slice, mbr bootcode, make this slice > > active, and dump memstick image to /dev/da4s1. My desktop boots from this > > memstick without problems, laptop says "No boot code". > > > > Unfortunately, this Laptop has broken CD-ROM (and it looks like by DVD-RW > > drive in desktop is disgunctional too, I've tried to do something with it 4 > > years ago). > > > > Maybe, somebody has experience of booting such old Sony Vaio from FreeBSD > > memstick and here is some trick to do this? > > Not sure about a Vaio, but I have many machines that will not boot > from larger memory sticks. > > Creating a 1G partion on a big stick and dd-ing onto that works for > those machines. Ah, glad you mentioned that, (as I too have made large bootable FS's on USB, but only tested on amd64 so far & had forgotten i386 limits) Some non PCs also dont want more than 2G SDRAM, eg SDRAM player car radio transmitter http://www.berklix.com/~jhs/txt/renkforce-fm-16.html it plays from 2G SDRAM with an MBR & FAT, but the manual says <= 2G. I suppose 32 bit CPUs will freak at/above 4G = 4,294,967,296 & what with cavalier mixing on int / unsigned, above 2G may be tempring fate. http://www.cnet.com/laptops/sony-vaio-vgn-sz340/4505-3121_7-32328541.html Intel Core 2 Duo T7200 / 2.0 GHz http://www.intel.com/content/www/us/en/search.html?keyword=T7200 http://ark.intel.com/products/27255/Intel-Core2-Duo-Processor-T7200-4M-Cache-2_00-GHz-667-MHz-FSB?wapkw=t7200 Instruction Set 64-bit Hmm, so that's not the reason Lev is hanging then. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 15:20:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F149229E for ; Tue, 28 Jan 2014 15:20:55 +0000 (UTC) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9DE1740 for ; Tue, 28 Jan 2014 15:20:54 +0000 (UTC) Received: from mail.athenadistribution.com ([80.15.193.119]) by mwinf5d62 with ME id KTLt1n0022b1akY03TLthX; Tue, 28 Jan 2014 16:20:53 +0100 Received: from [192.168.100.126] ([192.168.100.126] RDNS failed) by mail.athenadistribution.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Jan 2014 16:20:52 +0100 Message-ID: <52E7CAD3.4030404@athenadistribution.com> Date: Tue, 28 Jan 2014 16:20:51 +0100 From: Florian Millet User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jung-uk Kim , freebsd-stable@freebsd.org Subject: Re: vesa.ko do not load with ASpeed AST2300 chipset References: <52E27479.9090002@athenadistribution.com> <52E2AE74.5020004@FreeBSD.org> In-Reply-To: <52E2AE74.5020004@FreeBSD.org> X-OriginalArrivalTime: 28 Jan 2014 15:20:52.0702 (UTC) FILETIME=[88473FE0:01CF1C3C] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 15:20:56 -0000 Athena Distribution Athena Distribution - Millet Florian Le 24/01/2014 19:18, Jung-uk Kim a écrit : > On 2014-01-24 09:11:05 -0500, Florian Millet wrote: > > Hello everyone, > > > I stumbled into a problem with a gigabyte motherboard (GA-6PXSV3), > > more specifically the integrated video chipset on it. The chipset > > is a ASpeed AST2300 and supposedly handle up to a resolution of > > 1920x1200. ( for reference : > > http://www.aspeedtech.com/products.php?fPath=20&rId=200 ) My > > problem is not under X.org but in console mode, the vesa.ko module > > refuses to load with this chipset giving me a : > > > module_register_init: MOD_LOAD (vesa, 0xffffffff81214000, 0) error > > 19 > > > When trying to see which resolution I can use in console mode with > > `vidcontrol -i mode` I get only one line : > > > 3 (0x003) 0x00000001 T 80x25 8x8 0xb80000 32k 32k > > 0x00000000 32k > > > Unfortunately recompiling with VESA_DEBUG=1 does not yield any > > more information as to why it refuses to load (compiled in kernel > > or as a module). Enabling the define MODE_TABLE_BROKEN in > > /usr/src/sys/dev/fb/vesa.c changes nothing. This problem has been > > confirmed on FreeBSD 10/STABLE and 9.2/RELEASE. > > > I tried to flash the vbios to the latest version but their utility > > tells me it is impossible since the version installed is > > "invalidate" ... > > > `pciconf -lv` gives me : vgapci0@pci0:8:0:0: class=0x030000 > > card=0x20001458 chip=0x20001a03 rev=0x21 hdr=0x00 vendor = > > 'ASPEED Technology, Inc.' device = 'ASPEED Graphics Family' > > class = display subclass = VGA > > > Does anyone has an idea as to why I can't have any other resolution > > in console mode ? I can give access to the machine via ssh if it > > helps debugging the problem. > I believe they officially support FreeBSD. > > http://www.aspeedtech.com/support.php > > Jung-uk Kim Hello, You are correct there _is_ some support on their part for FreeBSD. Unfortunately these drivers are only for X. My problem is in console/text mode (I do not have X on this machine nor do I want to). Does this problem come from only an unrecognized card or the problem is deeper and more complicated ? --- Florian Millet Athena Distribution From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 16:32:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 786A694F; Tue, 28 Jan 2014 16:32:37 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28DDB1E63; Tue, 28 Jan 2014 16:32:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0SGWZQU049840; Tue, 28 Jan 2014 09:32:35 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0SGWZQu049837; Tue, 28 Jan 2014 09:32:35 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 28 Jan 2014 09:32:35 -0700 (MST) From: Warren Block To: Lev Serebryakov Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? In-Reply-To: <976149194.20140128115104@serebryakov.spb.ru> Message-ID: References: <976149194.20140128115104@serebryakov.spb.ru> 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 IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 28 Jan 2014 09:32:36 -0700 (MST) Cc: hackers@FreeBSD.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:32:37 -0000 On Tue, 28 Jan 2014, Lev Serebryakov wrote: > Hello, All. > > I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is > VGN-SZ340P, Merom generation of Core2, ~2007). > > It allows to select "USB Hard drive" or "USB Optical Drive" as boot device, > but it writes "No operating system" in both cases. > > I've checked memstick and found, that it doesn't have MBR (it looks like > /dev/da4a). I've added MBR, one slice, mbr bootcode, make this slice > active, and dump memstick image to /dev/da4s1. My desktop boots from this > memstick without problems, laptop says "No boot code". On MBR/BSDlabel, a second chunk of bootcode must be written inside the BSD partition also. Nicolas Geniteau just posted this very nice procedure for converting a memory stick to MBR/BSDlabel. I have not tried it yet, but it does write that additional bootcode. http://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255841.html From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 16:42:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E944161; Tue, 28 Jan 2014 16:42:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6112F1F68; Tue, 28 Jan 2014 16:42:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e01d:156b:782f:c36]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id D3BA14AC31; Tue, 28 Jan 2014 20:42:43 +0400 (MSK) Date: Tue, 28 Jan 2014 20:42:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1777063285.20140128204239@serebryakov.spb.ru> To: Warren Block Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? In-Reply-To: References: <976149194.20140128115104@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@FreeBSD.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:42:46 -0000 Hello, Warren. You wrote 28 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 20:32:35: >> I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is >> VGN-SZ340P, Merom generation of Core2, ~2007). >> >> It allows to select "USB Hard drive" or "USB Optical Drive" as boot devi= ce, >> but it writes "No operating system" in both cases. >> >> I've checked memstick and found, that it doesn't have MBR (it looks like >> /dev/da4a). I've added MBR, one slice, mbr bootcode, make this slice >> active, and dump memstick image to /dev/da4s1. My desktop boots from this >> memstick without problems, laptop says "No boot code". WB> On MBR/BSDlabel, a second chunk of bootcode must be written inside the= =20 WB> BSD partition also. Nicolas Geniteau just posted this very nice=20 WB> procedure for converting a memory stick to MBR/BSDlabel. I have not=20 WB> tried it yet, but it does write that additional bootcode. WB> http://lists.freebsd.org/pipermail/freebsd-questions/2014-January/25584= 1.html I tried this too... It looks like this old Laptop / BIOS wants to see special USB Floppy / USB Optical drive device, not generic "umass" one. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 16:43:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41620343 for ; Tue, 28 Jan 2014 16:43:45 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 00C4A1F8A for ; Tue, 28 Jan 2014 16:43:44 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e01d:156b:782f:c36]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 324334AC32; Tue, 28 Jan 2014 20:43:38 +0400 (MSK) Date: Tue, 28 Jan 2014 20:43:34 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <855767227.20140128204334@serebryakov.spb.ru> To: Bap Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? In-Reply-To: <20140128110248.Horde.MbimUBauknlS545YF3OAIRA@mail.a1.org.uk> References: <976149194.20140128115104@serebryakov.spb.ru> <20140128110248.Horde.MbimUBauknlS545YF3OAIRA@mail.a1.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:43:45 -0000 Hello, Bap. You wrote 28 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 15:02:48: B> Not sure about a Vaio, but I have many machines that will not boot B> from larger memory sticks. I have 1G memstick, no luck. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 16:44:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8762A43F for ; Tue, 28 Jan 2014 16:44:49 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4475E1F9F for ; Tue, 28 Jan 2014 16:44:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e01d:156b:782f:c36]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2D6164AC32; Tue, 28 Jan 2014 20:44:48 +0400 (MSK) Date: Tue, 28 Jan 2014 20:44:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <406713137.20140128204444@serebryakov.spb.ru> To: "Julian H. Stacey" Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? In-Reply-To: <201401281449.s0SEnajv096005@fire.js.berklix.net> References: Your message "Tue, 28 Jan 2014 11:02:48 GMT." <20140128110248.Horde.MbimUBauknlS545YF3OAIRA@mail.a1.org.uk> <201401281449.s0SEnajv096005@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bap , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:44:49 -0000 Hello, Julian. You wrote 28 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 18:49:36: JHS> I suppose 32 bit CPUs will freak at/above 4G =3D 4,294,967,296 JHS> & what with cavalier mixing on int / unsigned, above 2G may be temprin= g fate. It boots from installed WinXP and works fine. And it is equipped with (only, sigh) 2G of RAM. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 17:35:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF95575C for ; Tue, 28 Jan 2014 17:35:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C634114FD for ; Tue, 28 Jan 2014 17:35:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9DE16B946; Tue, 28 Jan 2014 12:35:21 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Processes are incorrectly marked as swapped out Date: Tue, 28 Jan 2014 11:42:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <2D47B79E-C171-4B91-B0AB-4DD2212770C6@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401281142.10317.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:21 -0500 (EST) Cc: Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:23 -0000 On Thursday, January 23, 2014 8:02:29 am Ronald Klop wrote: > On Thu, 23 Jan 2014 13:19:36 +0100, Dmitry Sivachenko > wrote: > > > Hello! > > > > After upgrade from stable/9 to stable/10 I see the following regression. > > Some processes are marked as swapped out in top(1) output: > > > > 1436 root 1 43 0 16524K 0K nanslp 14 1:14 0.00% > > > > 1381 smmsp 1 20 0 23988K 0K pause 18 0:04 0.00% > > > 99348 mitya 1 21 0 23492K 0K pause 16 0:00 0.00% > > > > > > ps(1) also shows them as swapped out (W as second character in state > > field): > > 1381 - IWs 0:00.00 sendmail: Queue runner at 00:30:00 for > > /var/spool/clie > > 1436 - IWs 0:00.00 /usr/sbin/cron -s > > 80231 - IWs 0:00.00 /usr/local/sbin/collectdmon -c > > /usr/local/sbin/coll > > 99348 1 IWs 0:00.00 -csh (csh) > > > > Though swapinfo reports that zero swap is used and even if I turn swap > > completely off (swapoff -a) > > the output of both top(1) and ps(1) does not change: these processes are > > still marked as swapped out. > > The code of an application can get removed from memory, because there > still is an image of it in the executable on disk. It can be 'swapped' in > by reading the executable again. The program is memory mapped (mmap). > See VN PAGER vs SWAP PAGER in 'systat -vm'. However, a swapped out process always uses swap (for kernel stacks), so this seems like a real bug. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 17:35:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16E4886C; Tue, 28 Jan 2014 17:35:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78EA31500; Tue, 28 Jan 2014 17:35:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66150B9CA; Tue, 28 Jan 2014 12:35:24 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: 10.0, csh history merge broken? Date: Tue, 28 Jan 2014 11:47:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E0E917.3060403@li.ru> <20140126215845.3b62debf03dade433622e9ba@yamagi.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401281147.15801.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:24 -0500 (EST) Cc: stable@freebsd.org, Alexander Yerenkow , Yamagi Burmeister , amarat@li.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:27 -0000 On Monday, January 27, 2014 3:55:53 am Alexander Yerenkow wrote: > >Maybe it would be a good idea to cherry pick those two revisions and > >merge then into FreeBSD, until a new tcsh version is released. > > I think this is must, since currently any regular shutdown can break login > ability (if server is high loaded + history file is broken and big enough). > I have now locked history file with chflags until fix will come. These changes are already present in HEAD (FreeBSD 11) and will probably be merged by the next 10 release. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 17:57:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 7DEE254A; Tue, 28 Jan 2014 17:57:05 +0000 (UTC) Message-ID: <52E7EF70.7020200@FreeBSD.org> Date: Tue, 28 Jan 2014 12:57:04 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Florian Millet , freebsd-stable@freebsd.org Subject: Re: vesa.ko do not load with ASpeed AST2300 chipset References: <52E27479.9090002@athenadistribution.com> <52E2AE74.5020004@FreeBSD.org> <52E7CAD3.4030404@athenadistribution.com> In-Reply-To: <52E7CAD3.4030404@athenadistribution.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:57:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-28 10:20:51 -0500, Florian Millet wrote: > Athena Distribution > > Athena Distribution - Millet Florian Le 24/01/2014 19:18, Jung-uk > Kim a écrit : >> On 2014-01-24 09:11:05 -0500, Florian Millet wrote: >>> Hello everyone, >> >>> I stumbled into a problem with a gigabyte motherboard >>> (GA-6PXSV3), more specifically the integrated video chipset on >>> it. The chipset is a ASpeed AST2300 and supposedly handle up to >>> a resolution of 1920x1200. ( for reference : >>> http://www.aspeedtech.com/products.php?fPath=20&rId=200 ) My >>> problem is not under X.org but in console mode, the vesa.ko >>> module refuses to load with this chipset giving me a : >> >>> module_register_init: MOD_LOAD (vesa, 0xffffffff81214000, 0) >>> error 19 >> >>> When trying to see which resolution I can use in console mode >>> with `vidcontrol -i mode` I get only one line : >> >>> 3 (0x003) 0x00000001 T 80x25 8x8 0xb80000 32k 32k >>> 0x00000000 32k >> >>> Unfortunately recompiling with VESA_DEBUG=1 does not yield any >>> more information as to why it refuses to load (compiled in >>> kernel or as a module). Enabling the define MODE_TABLE_BROKEN >>> in /usr/src/sys/dev/fb/vesa.c changes nothing. This problem has >>> been confirmed on FreeBSD 10/STABLE and 9.2/RELEASE. >> >>> I tried to flash the vbios to the latest version but their >>> utility tells me it is impossible since the version installed >>> is "invalidate" ... >> >>> `pciconf -lv` gives me : vgapci0@pci0:8:0:0: class=0x030000 >>> card=0x20001458 chip=0x20001a03 rev=0x21 hdr=0x00 vendor = >>> 'ASPEED Technology, Inc.' device = 'ASPEED Graphics Family' >>> class = display subclass = VGA >> >>> Does anyone has an idea as to why I can't have any other >>> resolution in console mode ? I can give access to the machine >>> via ssh if it helps debugging the problem. >> I believe they officially support FreeBSD. >> >> http://www.aspeedtech.com/support.php >> >> Jung-uk Kim > Hello, > > You are correct there _is_ some support on their part for FreeBSD. > Unfortunately these drivers are only for X. My problem is in > console/text mode (I do not have X on this machine nor do I want > to). No, I didn't mean it. I'm just saying you may want to directly contact ASPEED because they officially support FreeBSD, it seems. (Hint: I saw support e-mail address in one of these downloadable files on the support site.) For example, they even have video BIOS flasher for FreeBSD. > Does this problem come from only an unrecognized card or the > problem is deeper and more complicated ? I believe it's a video BIOS issue. Probably you need to flash it with the latest video BIOS first. If it does not work, please let them know about it. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJS5+9wAAoJEHyflib82/FGKlQH/i6hRZ7/da+R7MPUqgHaSWDM leiSs2luG5X0+S+bQ1iWKgvKgj3ZT9ZPCrc5aEguoGvyK4yXLOCJD43Ux62YYaWH KAzopof3dpi9ty5GMLCY7EfjpLpyTboR7tIz5eaD0YMilViv0zFVyfnpDZfWfKDc rQlfEtKy04ocb+ctr8WKjoqUbZ7IrGhJ+1oanFrItk/Yw0s1H3i5Q4kz3qMpm5CM VbZm537KweiAJ43rpI8Ksl6n0QcRN5F8OkASlC4Occ1JDEHlIzj+CNkHDaRWd6rh lbHOZJNy6xMeKokMHXfS3aMNRnnaa0T7nyxZL3JmhMVbMl0aYBvLCg++MYc6WvE= =hk6N -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 19:35:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5959068A; Tue, 28 Jan 2014 19:35:30 +0000 (UTC) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26B7511D9; Tue, 28 Jan 2014 19:35:30 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id uo5so783135pbc.27 for ; Tue, 28 Jan 2014 11:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G8CsgyUJz0bcY6ShxIfpG1fiMp4X+l/Wi8srBlwohlM=; b=VuqrXTYt4Xrwd12BdYzkCZbUb42vjz6Did4dKknLp3rxrwvdCzzZLg/YHU8a0lgOY0 IXSi0req9Pk1AB+ttCIAD7VEF9Z4+kf/CM1GTzgCzCV6Grz1dXGq+0S67CqM2Hjb0+BC OXQxxIT5cbwvsBbmpjoCohy5u6tXnsmG72Ff8SvzyWlHhrpFC2/6OurRf8ycT5RqVFD0 QGBygaDUj7w+AVTNWAylrPSlUW3AeDbOOc0hO+9KSJ/g9A9+nyvlj2LHxOqZ+Hs5gaad I7oKZHH9eRG4Eq8ynSDzsy1zzMt9iCLKFr2uK2DKVrBeLr0cJtkybS/a2fSsNV7dGlCT nbYw== MIME-Version: 1.0 X-Received: by 10.68.224.34 with SMTP id qz2mr3516530pbc.84.1390937726920; Tue, 28 Jan 2014 11:35:26 -0800 (PST) Received: by 10.70.88.101 with HTTP; Tue, 28 Jan 2014 11:35:26 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 14:35:26 -0500 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Kenneth Culver To: "Sevan / Venture37" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:35:30 -0000 I built from ports, I'm running 10.0-STABLE, but the problems were occurring on 10.0-RELEASE as well. On Tue, Jan 28, 2014 at 9:31 AM, Sevan / Venture37 wrote: > Jason, > A couple of questions, > Are you using packages or building from ports? > If you're building, what does your /etc/make.conf > > I've been suffering from sigsegv issues for a few weeks now on my > server running -current which I build world/ports on myself. > I looked to see if the problems are there in 10.0-RELEASE & > 11.0-CURRENT using the official packages & install CD & the problem > did not manifest on either environments. > I'm currently working backwards on my aforementioned server, reverting > changes to find where the problem is introduced. > > > Sevan > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 19:52:53 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34256B79; Tue, 28 Jan 2014 19:52:53 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B40401327; Tue, 28 Jan 2014 19:52:52 +0000 (UTC) Received: from park.js.berklix.net (p5DCBCD50.dip0.t-ipconnect.de [93.203.205.80]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s0SJq2UQ052868; Tue, 28 Jan 2014 19:52:31 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s0SJmDn6089443; Tue, 28 Jan 2014 20:48:14 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s0SJlVbG035982; Tue, 28 Jan 2014 20:48:11 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201401281948.s0SJlVbG035982@fire.js.berklix.net> To: lev@FreeBSD.org Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 28 Jan 2014 20:44:44 +0400." <406713137.20140128204444@serebryakov.spb.ru> Date: Tue, 28 Jan 2014 20:47:31 +0100 Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:52:53 -0000 For my best guess, skim down to **** Lev Serebryakov wrote: > Hello, Julian. > You wrote 28 ÑÐ½Ð²Ð°Ñ€Ñ 2014 г., 18:49:36: > > JHS> I suppose 32 bit CPUs will freak at/above 4G = 4,294,967,296 > JHS> & what with cavalier mixing on int / unsigned, above 2G may be tempring fate. > It boots from installed WinXP and works fine. Could it be you have a 32/64 bit mismatch ? Or an MD5 error. Or a flakey USB sector ? ... but I recall you said stick is OK on another PC. I suggest post exactly what [little] you see through the boot procedure, then maybe someone can identify whats going wrong. /boot/loader.conf boot_verbose="yes" but I suppose you'r not getting that far. So How about '?' to boot ? see man boot. Maybe the laptop also has a pcmcia card (for eg a cdrom) or an ethernet pxe boot ? Or try an older Free/Net BSD ? Even back to venerable 4.11 (umm well, maybe not that old with USB as 4.11 has no USB I recall, but it probably supports pcmcia cd boot) ... or find a friend to loan a usb cdrom drive ... Once you have any sort of FreeBSD on you'll know a lot more. Or try a Linux such as maybe Knoppix & see what that shows. A friend last year tried a USB stick I'd made with an MBR, & though it worked for me, it didnt for him, I suspect in a similar way as for you - I think 'cos the major numbers of the usb or hard drive were off by one - one can set that manually from keyboard at boot man boot (or maybe it was off by 4 ?) ... There's also some mess between MBRs, & device naming ( eg on my sata box new names /dev/ada[01]s[1-4] versus older /dev/ad[46]s[1-4] ) , I recently wrote new boot sectors on a disc on a box & now have disparity on mount names, example: /dev/ada1s1a on / (ufs, NFS exported, local) /dev/ada0s2a on /ad4s2 (ufs, local) /dev/ada0s2d on /ad4s2/var (ufs, local, soft-updates) /dev/ada0s2e on /ad4s2/tmp (ufs, local, soft-updates) /dev/ada0s2f on /ad4s2/usr (ufs, local, soft-updates) /dev/ada0s3a on /ad4s3 (ufs, NFS exported, local) /dev/ada0s3d on /ad4s3/var (ufs, NFS exported, local, soft-updates) /dev/ada0s3e on /ad4s3/tmp (ufs, NFS exported, local, soft-updates) /dev/ada0s3f on /ad4s3/usr (ufs, NFS exported, local, soft-updates) /dev/ada0s4a on /ad4s4 (ufs, NFS exported, local, soft-updates) /dev/ada1s1d on /var (ufs, NFS exported, local, soft-updates) /dev/ada1s1e on /tmp (ufs, NFS exported, local, soft-updates) /dev/ada1s1f on /usr (ufs, NFS exported, local, soft-updates) /dev/ada1s2a on /ad6s2 (ufs, NFS exported, local) /dev/ada1s2d on /ad6s2/var (ufs, NFS exported, local, soft-updates) /dev/ada1s2e on /ad6s2/tmp (ufs, NFS exported, local, soft-updates) /dev/ada1s2f on /ad6s2/usr (ufs, NFS exported, local, soft-updates) /dev/ada1s3a on /ad6s3 (ufs, NFS exported, local) /dev/ada1s3d on /ad6s3/var (ufs, NFS exported, local) /dev/ada1s3e on /ad6s3/usr (ufs, NFS exported, local) /dev/ada1s4a on /ad6s4 (ufs, NFS exported, local, soft-updates) My new 9.2 failed to boot until I told it root was no longer (per for my 9.1) ad6s3 but was now (for my 9.2) ada1s1 see man boot (8) for naming, eg Default: 0:ad(0,a)/boot/loader Probably the bit to fix is in your USB stick, try /boot/loader.conf mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" **** vfs.root.mountfrom="ufs:/dev/da0s1a" Unless like my friend last year, maybe you have some internal USB stick or some such, consuming da0, so your external usb stick may appear as da1, as I think happened to him. > And it is equipped with > (only, sigh) 2G of RAM. My 9.1 desktop has 1G, my 10 lap 3G, & my gate host 40M, you'll survive :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 20:35:31 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBD56BCE for ; Tue, 28 Jan 2014 20:35:31 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id AE9E216FE for ; Tue, 28 Jan 2014 20:35:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e01d:156b:782f:c36]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DBC274AC3A; Wed, 29 Jan 2014 00:35:29 +0400 (MSK) Date: Wed, 29 Jan 2014 00:35:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <649629564.20140129003525@serebryakov.spb.ru> To: "Julian H. Stacey" Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? In-Reply-To: <201401281948.s0SJlVbG035982@fire.js.berklix.net> References: Your message "Tue, 28 Jan 2014 20:44:44 +0400." <406713137.20140128204444@serebryakov.spb.ru> <201401281948.s0SJlVbG035982@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:35:32 -0000 Hello, Julian. You wrote 28 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 23:47:31: JHS> but I suppose you'r not getting that far. JHS> So How about '?' to boot ? see man boot. No "freebsd-related" boot messages shows. Laptop shows same message "No operating system" with empty USB flash, without USB flash at all (if I disable booting from internal HDD), with USB flash without MBR (dd if=3D/FreeBSD-10.0-RELEASE-i386-memstick.img of=3D/dev/da4) with USB flash= with MBR (make mbr, install bootcode and dd if=3D/FreeBSD-10.0-RELEASE-i386-memstick.img of=3D/dev/da4s1)... What make me think, that this is impossible, that "Boot menu" (called with ESC button on ealry boot stage) shows "USB Optical drive" and "USB Hard Drive" in any of these cases. BIOS messages shows USB stick detected properly, but boot menuy shows these two items, even if there is no USB flash! JHS> Maybe the laptop also has a pcmcia card (for eg a cdrom) or an JHS> ethernet pxe boot ? PXE boot should be my next stop in this battle! I could open case (unscrew about 20 screws) and attach HDD to desktop, but it looks not a fair play! :))) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 22:37:38 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD5339D1 for ; Tue, 28 Jan 2014 22:37:38 +0000 (UTC) Received: from smtp.syd.comcen.com.au (smtp.syd.comcen.com.au [203.23.236.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47BCB1119 for ; Tue, 28 Jan 2014 22:37:37 +0000 (UTC) Received: from hummer.af.speednet.com.au (115-69-4-237.dyn.comcen.net.au [115.69.4.237]) by smtp.syd.comcen.com.au (8.13.4/8.12.9) with ESMTP id s0SMXZeJ064656 for ; Wed, 29 Jan 2014 09:33:35 +1100 (EST) Received: from snuggles.af.speednet.com.au (snuggles.af.speednet.com.au [172.22.2.2]) by hummer.af.speednet.com.au (8.14.5/8.14.5) with ESMTP id s0SMXU6Z026108 for ; Wed, 29 Jan 2014 08:33:30 +1000 (EST) (envelope-from andyf@andyit.com.au) Message-ID: <52E8303A.9020501@andyit.com.au> Date: Wed, 29 Jan 2014 08:33:30 +1000 From: Andy Farkas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120614 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Processes are incorrectly marked as swapped out References: <2D47B79E-C171-4B91-B0AB-4DD2212770C6@gmail.com> <201401281142.10317.jhb@freebsd.org> In-Reply-To: <201401281142.10317.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.088, required 4, AWL -0.18, BAYES_20 -0.01, RDNS_DYNAMIC 0.10) X-comcen-MailScanner-From: andyf@andyit.com.au X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 22:37:38 -0000 On 29/01/14 02:42, John Baldwin wrote: > On Thursday, January 23, 2014 8:02:29 am Ronald Klop wrote: >> On Thu, 23 Jan 2014 13:19:36 +0100, Dmitry Sivachenko >> wrote: >> >>> Hello! >>> >>> After upgrade from stable/9 to stable/10 I see the following regression. >>> Some processes are marked as swapped out in top(1) output: >>> >>> 1436 root 1 43 0 16524K 0K nanslp 14 1:14 0.00% >>> >>> 1381 smmsp 1 20 0 23988K 0K pause 18 0:04 0.00% >>> >> 99348 mitya 1 21 0 23492K 0K pause 16 0:00 0.00% >>> >>> >>> ps(1) also shows them as swapped out (W as second character in state >>> field): >>> 1381 - IWs 0:00.00 sendmail: Queue runner at 00:30:00 for >>> /var/spool/clie >>> 1436 - IWs 0:00.00 /usr/sbin/cron -s >>> 80231 - IWs 0:00.00 /usr/local/sbin/collectdmon -c >>> /usr/local/sbin/coll >>> 99348 1 IWs 0:00.00 -csh (csh) >>> >>> Though swapinfo reports that zero swap is used and even if I turn swap >>> completely off (swapoff -a) >>> the output of both top(1) and ps(1) does not change: these processes are >>> still marked as swapped out. >> The code of an application can get removed from memory, because there >> still is an image of it in the executable on disk. It can be 'swapped' in >> by reading the executable again. The program is memory mapped (mmap). >> See VN PAGER vs SWAP PAGER in 'systat -vm'. > However, a swapped out process always uses swap (for kernel stacks), so this > seems like a real bug. > Probably not related, but on a VirtualBox VM guest running: FreeBSD 10.0-STABLE (GENERIC) #0 r261215: Tue Jan 28 18:13:37 EST 2014 having been freshly rebooted: % uptime 7:59AM up 43 secs, 2 users, load averages: 0.79, 0.30, 0.11 I see this strange anomaly in the "TIME" column of top(1): % top -CHSb -otime | grep swap 0 root -16 0 0K 160K swapin 0 47.8H 0.00% kernel{swapper} No swap is being used (of ~3GB). Filesystem is UFS. Possibly a formatting error although earlier values have been 45.4H & 47.2H with reboots in between. -andyf From owner-freebsd-stable@FreeBSD.ORG Tue Jan 28 23:57:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA303C45; Tue, 28 Jan 2014 23:57:02 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8F8361783; Tue, 28 Jan 2014 23:57:02 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so1705097qcy.39 for ; Tue, 28 Jan 2014 15:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I94BemUdRokfzDx/5l130dyyFA1Pvm/yatxS9SQmS1c=; b=Ez/l2nEv72nE9OzM0ESSx1lD8imPeNPyDF4a99JSGvIlA3c5QZu4gpyNETxF+Zc/N2 s/PIgvA0+trIwksgGvxB15rN0jeS7J8HA1rW42ILxDPaW505qcKjbDpMjd/sZ/X3uPYi X23aT1QDmBrhBigh7ke0c8mVhYzuZFl0Vwir3QFkKQuyDMJrO//pLSqjsymQVnrdXdq9 EkXHQeu6JyrewgKey6Z12cYpTcpny2wZ4T09Kz9kfnsfMietGY5BDv1iyS6zjBcAkBMm rgwy+FVdpGYdWfrv8pJKS264G8F0FTVc94Kd2Ku75LpaOuvV4yKToGj3n6k23Z7KHNwM Dezw== MIME-Version: 1.0 X-Received: by 10.224.122.208 with SMTP id m16mr7131914qar.55.1390953421727; Tue, 28 Jan 2014 15:57:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 28 Jan 2014 15:57:01 -0800 (PST) Received: by 10.224.52.8 with HTTP; Tue, 28 Jan 2014 15:57:01 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 15:57:01 -0800 X-Google-Sender-Auth: 6TrbDJYSxfdA29JOgbel_cu9Bb8 Message-ID: Subject: Re: IWN hangs periodically on 10.0RC3 From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-wireless@freebsd.org, FreeBSD Stable Mailing List , Lars Engels X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:57:03 -0000 What's in dmesg? Did the firmware panic? Adrian On Jan 28, 2014 2:16 AM, "Kevin Oberman" wrote: > On Fri, Jan 10, 2014 at 9:51 PM, Kevin Oberman wrote: > >> On Fri, Jan 10, 2014 at 9:37 AM, Adrian Chadd wrote: >> >>> .. when you see it hang, does anything get logged in dmesg (eg a >>> firmware panic) ? >>> >>> Try recompiling your kernel with: >>> >>> IEEE80211_DEBUG >>> IWN_DEBUG >>> >>> That way it can be debugged :) >>> >>> The first thing I'd check is whether there's more fun races going on >>> in the crypto code - try wlandebug +crypto . >>> >>> >>> -a >>> >> >> I just sent a message about issues I am seeing with my IWN to wireless@. >> Then I saw these responses. Sorry. >> >> As far as logs go, I wee a number if cases of the following sequence: >> Jan 1 18:00:12 rogue dbus[1451]: [system] Activating service >> name='org.freedesktop.PackageKit' (using servicehelper) >> Jan 1 18:00:12 rogue dbus[1451]: [system] Successfully activated service >> 'org.freedesktop.PackageKit' >> Jan 1 18:28:56 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-DISCONNECTED >> bssid=00:26:b8:67:c3:2d reason=0 >> Jan 1 18:28:56 rogue kernel: wlan0: link state changed to DOWN >> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Trying to associate >> with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) >> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Associated with >> 00:26:b8:67:c3:2d >> Jan 1 18:28:59 rogue kernel: wlan0: link state changed to UP >> Jan 1 18:28:59 rogue dhclient[652]: send_packet: No buffer space >> available >> Jan 1 18:28:59 rogue devd: Executing '/etc/rc.d/dhclient quietstart >> wlan0' >> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: WPA: Key negotiation >> completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] >> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-CONNECTED - >> Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] >> Jan 1 18:29:02 rogue dhclient: New IP Address (wlan0): 192.168.1.5 >> Jan 1 18:29:02 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 >> Jan 1 18:29:02 rogue dhclient: New Broadcast Address (wlan0): >> 192.168.1.255 >> Jan 1 18:29:02 rogue dhclient: New Routers (wlan0): 192.168.1.1 >> >> So it seems that the bounce is happening fairly often, but the system >> usually recovers. It seems to be pretty consistently 2-3 time4s a day. >> Note that the dbus messages about packagekit always immediately precede >> the link going down. >> >> Every tthe or four of these fail to recover: >> Jan 3 14:09:05 rogue kernel: wlan0: link state changed to DOWN >> Jan 3 14:09:56 rogue ntpd[1303]: sendto(198.129.254.218) (fd=25): >> Network is down >> Jan 3 14:10:15 rogue ntpd[1303]: sendto(208.79.18.86) (fd=25): Network >> is down >> Jan 3 14:10:29 rogue ntpd[1303]: sendto(198.124.252.90) (fd=25): Network >> is down >> Jan 3 14:10:49 rogue ntpd[1303]: sendto(198.55.111.5) (fd=25): Network >> is down >> Jan 3 14:11:00 rogue ntpd[1303]: sendto(192.95.38.104) (fd=25): Network >> is down >> Jan 3 14:14:02 rogue ntpd[1303]: sendto(198.129.252.38) (fd=25): Network >> is down >> Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Operation not supported >> Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, >> val=0, arg_len=0]: Operation not supported >> Jan 3 14:14:12 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-TERMINATING >> Jan 3 14:14:12 rogue dhclient[652]: connection closed >> Jan 3 14:14:12 rogue dhclient[652]: exiting. >> Jan 3 14:14:12 rogue wpa_supplicant[67153]: Successfully initialized >> wpa_supplicant >> Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Trying to associate >> with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) >> Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Associated with >> 00:26:b8:67:c3:2d >> Jan 3 14:14:16 rogue kernel: wlan0: link state changed to UP >> Jan 3 14:14:16 rogue devd: Executing '/etc/rc.d/dhclient quietstart >> wlan0' >> Jan 3 14:14:16 rogue dhclient[67191]: send_packet: No buffer space >> available >> Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: WPA: Key negotiation >> completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] >> Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: CTRL-EVENT-CONNECTED >> - Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] >> Jan 3 14:14:18 rogue dhclient: New IP Address (wlan0): 192.168.1.5 >> Jan 3 14:14:18 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 >> Jan 3 14:14:18 rogue dhclient: New Broadcast Address (wlan0): >> 192.168.1.255 >> Jan 3 14:14:18 rogue dhclient: New Routers (wlan0): 192.168.1.1 >> >> The restart took place when I restarted the interface about 5 minutes >> after it went down and, as you can see, it came up normally. I'll admit >> that I am completely baffled by the dbus/packagekit tie-in as I can't see >> what packagekit would do to touch the network. >> >> I'll be building a new kernel with debug shortly. >> >> In my other message (to wireless) I also mentioned the (possibly >> unrelated) issue of poor performance and and periodic sub-second >> connectivity drops. >> >> -- >> R. Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com >> > > I was about to send a report that removing bgscan fixed the issue, but, > then it happened again. Nothing new in the log from prior cases. Any other > flags to I should try to set in wlandebug? state? assoc? I'll admit that I > have no idea which might be helpful. > > One thing I seem to have failed to post is the ifconfig after the failure: > wlan0: flags=8c43 metric 0 > mtu 1500 > ether a0:88:b4:c6:ad:28 > inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid "" channel 7 (2442 MHz 11g) > country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF > txpower 15 bmiss 10 scanvalid 60 protmode CTS wme roaming MANUAL > > Note: My AP is on channel 6. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 01:13:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EFEB7B7; Wed, 29 Jan 2014 01:13:44 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B69D91D91; Wed, 29 Jan 2014 01:13:43 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id w7so967224lbi.41 for ; Tue, 28 Jan 2014 17:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JpLITmjXcEBrlEln+JEr3Aq0/aBvpLzGU0VkgslcW6U=; b=s2RiJoTdIn9CHmUwGMVisZHSSvP9+tHQ4ZQLq8Ruvk9rwChoyLGGtoGj8VDllk0Q8Q lvMpWFdPnyBhSIQA4DCdwUJd0ko6RzZpRqeFVJJeRvuVaf7Ttgm+kVpYf78H7Oy3Oqst NrmEfmAqbtqV1FV9b/ETRxDGntWmm5I7ORdSfQ2LotSeQfhIRzIxPqKEsNJgQYoQNTCs itSfWtfZUtE5eNcqKKGtIMZrEHEq2KbEqVK6r+zWitpZgflo92kRKXItZnVKotn4GNdh iBjyoRzIk6o3j8T1kVEc9JY6sZTHSFPs3kJPfwtKm7um93GhPanIzgqhq4WKesj+sM4G EKng== MIME-Version: 1.0 X-Received: by 10.153.7.137 with SMTP id dc9mr3077384lad.25.1390958021653; Tue, 28 Jan 2014 17:13:41 -0800 (PST) Received: by 10.112.89.168 with HTTP; Tue, 28 Jan 2014 17:13:41 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 09:13:41 +0800 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Huang Wen Hui To: Kenneth Culver Content-Type: multipart/mixed; boundary=001a113462a4c751f004f111a61e X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Sevan / Venture37 , "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huanghwh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 01:13:44 -0000 --001a113462a4c751f004f111a61e Content-Type: text/plain; charset=UTF-8 Hi, I got the same problem on FreeBSD 10, disable Background Compilation seems to fixed this problem. Please try this patch: --- work/hotspot/src/cpu/x86/vm/c1_globals_x86.hpp.orig 2014-01-28 09:01:59.000000000 +0800 +++ work/hotspot/src/cpu/x86/vm/c1_globals_x86.hpp 2014-01-28 09:02:49.000000000 +0800 @@ -32,7 +32,7 @@ // (see c1_globals.hpp) #ifndef TIERED -define_pd_global(bool, BackgroundCompilation, true ); +define_pd_global(bool, BackgroundCompilation, false); define_pd_global(bool, UseTLAB, true ); define_pd_global(bool, ResizeTLAB, true ); define_pd_global(bool, InlineIntrinsics, true ); --- work/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp.orig 2014-01-28 09:02:06.000000000 +0800 +++ work/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp 2014-01-28 09:04:34.000000000 +0800 @@ -31,7 +31,7 @@ // Sets the default values for platform dependent flags used by the server compiler. // (see c2_globals.hpp). Alpha-sorted. -define_pd_global(bool, BackgroundCompilation, true); +define_pd_global(bool, BackgroundCompilation, false); define_pd_global(bool, UseTLAB, true); define_pd_global(bool, ResizeTLAB, true); define_pd_global(bool, CICompileOSR, true); Cheers, Huang Wen Hui 2014-01-29 Kenneth Culver > I built from ports, I'm running 10.0-STABLE, but the problems were > occurring on 10.0-RELEASE as well. > > > On Tue, Jan 28, 2014 at 9:31 AM, Sevan / Venture37 >wrote: > > > Jason, > > A couple of questions, > > Are you using packages or building from ports? > > If you're building, what does your /etc/make.conf > > > > I've been suffering from sigsegv issues for a few weeks now on my > > server running -current which I build world/ports on myself. > > I looked to see if the problems are there in 10.0-RELEASE & > > 11.0-CURRENT using the official packages & install CD & the problem > > did not manifest on either environments. > > I'm currently working backwards on my aforementioned server, reverting > > changes to find where the problem is introduced. > > > > > > Sevan > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" > --001a113462a4c751f004f111a61e Content-Type: text/plain; charset=US-ASCII; name="openjdk6_batch.diff" Content-Disposition: attachment; filename="openjdk6_batch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hqzwh4cg0 LS0tIHdvcmsvaG90c3BvdC9zcmMvY3B1L3g4Ni92bS9jMV9nbG9iYWxzX3g4Ni5ocHAub3JpZwky MDE0LTAxLTI4IDA5OjAxOjU5LjAwMDAwMDAwMCArMDgwMAorKysgd29yay9ob3RzcG90L3NyYy9j cHUveDg2L3ZtL2MxX2dsb2JhbHNfeDg2LmhwcAkyMDE0LTAxLTI4IDA5OjAyOjQ5LjAwMDAwMDAw MCArMDgwMApAQCAtMzIsNyArMzIsNyBAQAogLy8gKHNlZSBjMV9nbG9iYWxzLmhwcCkKIAogI2lm bmRlZiBUSUVSRUQKLWRlZmluZV9wZF9nbG9iYWwoYm9vbCwgQmFja2dyb3VuZENvbXBpbGF0aW9u LCAgICAgICAgdHJ1ZSApOworZGVmaW5lX3BkX2dsb2JhbChib29sLCBCYWNrZ3JvdW5kQ29tcGls YXRpb24sICAgICAgICBmYWxzZSk7CiBkZWZpbmVfcGRfZ2xvYmFsKGJvb2wsIFVzZVRMQUIsICAg ICAgICAgICAgICAgICAgICAgIHRydWUgKTsKIGRlZmluZV9wZF9nbG9iYWwoYm9vbCwgUmVzaXpl VExBQiwgICAgICAgICAgICAgICAgICAgdHJ1ZSApOwogZGVmaW5lX3BkX2dsb2JhbChib29sLCBJ bmxpbmVJbnRyaW5zaWNzLCAgICAgICAgICAgICB0cnVlICk7Ci0tLSB3b3JrL2hvdHNwb3Qvc3Jj L2NwdS94ODYvdm0vYzJfZ2xvYmFsc194ODYuaHBwLm9yaWcJMjAxNC0wMS0yOCAwOTowMjowNi4w MDAwMDAwMDAgKzA4MDAKKysrIHdvcmsvaG90c3BvdC9zcmMvY3B1L3g4Ni92bS9jMl9nbG9iYWxz X3g4Ni5ocHAJMjAxNC0wMS0yOCAwOTowNDozNC4wMDAwMDAwMDAgKzA4MDAKQEAgLTMxLDcgKzMx LDcgQEAKIC8vIFNldHMgdGhlIGRlZmF1bHQgdmFsdWVzIGZvciBwbGF0Zm9ybSBkZXBlbmRlbnQg ZmxhZ3MgdXNlZCBieSB0aGUgc2VydmVyIGNvbXBpbGVyLgogLy8gKHNlZSBjMl9nbG9iYWxzLmhw cCkuICBBbHBoYS1zb3J0ZWQuCiAKLWRlZmluZV9wZF9nbG9iYWwoYm9vbCwgQmFja2dyb3VuZENv bXBpbGF0aW9uLCAgICAgICAgdHJ1ZSk7CitkZWZpbmVfcGRfZ2xvYmFsKGJvb2wsIEJhY2tncm91 bmRDb21waWxhdGlvbiwgICAgICAgIGZhbHNlKTsKIGRlZmluZV9wZF9nbG9iYWwoYm9vbCwgVXNl VExBQiwgICAgICAgICAgICAgICAgICAgICAgdHJ1ZSk7CiBkZWZpbmVfcGRfZ2xvYmFsKGJvb2ws IFJlc2l6ZVRMQUIsICAgICAgICAgICAgICAgICAgIHRydWUpOwogZGVmaW5lX3BkX2dsb2JhbChi b29sLCBDSUNvbXBpbGVPU1IsICAgICAgICAgICAgICAgICB0cnVlKTsK --001a113462a4c751f004f111a61e-- From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 06:09:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72EEFECF; Wed, 29 Jan 2014 06:09:15 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 373961362; Wed, 29 Jan 2014 06:09:15 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id w10so1309427pde.35 for ; Tue, 28 Jan 2014 22:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vsIrK6vdLeM0AM+OsxBQJBkn7zdq/u9sLXueZtZhCKg=; b=F1QZOaTmgxm3hpsuN7X+4csZRA4Bt6RHTlfssB5cFIcSUYq1PtsiZ4Qz85SETNuhZs 2my2GZ336hNSde4N00fwZZTHpU5O58sF9Wi6WbyCPpxzvChkjneTZ97budWzC+qc31cw LeVBUgpFcRqIW0HDQDs7wdCtSbUV7P9oWPkbfjyvRs93MtA3NWVfOLD/kP/Au2Xyy5Oo SLGeKZDLtJXQ2SXE3rqZkaiEq54E3oZTD6dmEEw/+UptOlRUijvRGy2k+N7VmTqrDbyT 62ldk1JI8VU6j0ED7zqqwgEyfn0blSi8JVnbEdA6/94zZ9YFq695Sk2aSYOMJYpNuKR+ IYJQ== MIME-Version: 1.0 X-Received: by 10.68.218.65 with SMTP id pe1mr5971592pbc.1.1390975754801; Tue, 28 Jan 2014 22:09:14 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Tue, 28 Jan 2014 22:09:14 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 22:09:14 -0800 X-Google-Sender-Auth: _jeyDwpqls-2VJSrr8EwwsqlXr4 Message-ID: Subject: Re: IWN hangs periodically on 10.0RC3 From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Wireless , FreeBSD Stable Mailing List , Lars Engels X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 06:09:15 -0000 On Tue, Jan 28, 2014 at 3:57 PM, Adrian Chadd wrote: > What's in dmesg? Did the firmware panic? > > Adrian > pci3: on pcib2 iwn0: mem 0xf2400000-0xf2401fff irq 17 at device 0.0 on pci3 [...] wlan0: Ethernet address: a0:88:b4:c6:ad:28 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled These are the only entries that look even a bit related to the wireless. Let me know if you want the whole thing. No indication I see of a firmware panic in either dmesg or var/log/messages. [EOF] > On Jan 28, 2014 2:16 AM, "Kevin Oberman" wrote: > >> On Fri, Jan 10, 2014 at 9:51 PM, Kevin Oberman wrote: >> >>> On Fri, Jan 10, 2014 at 9:37 AM, Adrian Chadd wrote: >>> >>>> .. when you see it hang, does anything get logged in dmesg (eg a >>>> firmware panic) ? >>>> >>>> Try recompiling your kernel with: >>>> >>>> IEEE80211_DEBUG >>>> IWN_DEBUG >>>> >>>> That way it can be debugged :) >>>> >>>> The first thing I'd check is whether there's more fun races going on >>>> in the crypto code - try wlandebug +crypto . >>>> >>>> >>>> -a >>>> >>> >>> I just sent a message about issues I am seeing with my IWN to wireless@. >>> Then I saw these responses. Sorry. >>> >>> As far as logs go, I wee a number if cases of the following sequence: >>> Jan 1 18:00:12 rogue dbus[1451]: [system] Activating service >>> name='org.freedesktop.PackageKit' (using servicehelper) >>> Jan 1 18:00:12 rogue dbus[1451]: [system] Successfully activated >>> service 'org.freedesktop.PackageKit' >>> Jan 1 18:28:56 rogue wpa_supplicant[620]: wlan0: >>> CTRL-EVENT-DISCONNECTED bssid=00:26:b8:67:c3:2d reason=0 >>> Jan 1 18:28:56 rogue kernel: wlan0: link state changed to DOWN >>> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Trying to associate >>> with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) >>> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: Associated with >>> 00:26:b8:67:c3:2d >>> Jan 1 18:28:59 rogue kernel: wlan0: link state changed to UP >>> Jan 1 18:28:59 rogue dhclient[652]: send_packet: No buffer space >>> available >>> Jan 1 18:28:59 rogue devd: Executing '/etc/rc.d/dhclient quietstart >>> wlan0' >>> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: WPA: Key negotiation >>> completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] >>> Jan 1 18:28:59 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-CONNECTED - >>> Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] >>> Jan 1 18:29:02 rogue dhclient: New IP Address (wlan0): 192.168.1.5 >>> Jan 1 18:29:02 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 >>> Jan 1 18:29:02 rogue dhclient: New Broadcast Address (wlan0): >>> 192.168.1.255 >>> Jan 1 18:29:02 rogue dhclient: New Routers (wlan0): 192.168.1.1 >>> >>> So it seems that the bounce is happening fairly often, but the system >>> usually recovers. It seems to be pretty consistently 2-3 time4s a day. >>> Note that the dbus messages about packagekit always immediately precede >>> the link going down. >>> >>> Every tthe or four of these fail to recover: >>> Jan 3 14:09:05 rogue kernel: wlan0: link state changed to DOWN >>> Jan 3 14:09:56 rogue ntpd[1303]: sendto(198.129.254.218) (fd=25): >>> Network is down >>> Jan 3 14:10:15 rogue ntpd[1303]: sendto(208.79.18.86) (fd=25): Network >>> is down >>> Jan 3 14:10:29 rogue ntpd[1303]: sendto(198.124.252.90) (fd=25): >>> Network is down >>> Jan 3 14:10:49 rogue ntpd[1303]: sendto(198.55.111.5) (fd=25): Network >>> is down >>> Jan 3 14:11:00 rogue ntpd[1303]: sendto(192.95.38.104) (fd=25): Network >>> is down >>> Jan 3 14:14:02 rogue ntpd[1303]: sendto(198.129.252.38) (fd=25): >>> Network is down >>> Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, >>> val=0, arg_len=0]: Operation not supported >>> Jan 3 14:14:12 rogue wpa_supplicant[620]: ioctl[SIOCS80211, op=26, >>> val=0, arg_len=0]: Operation not supported >>> Jan 3 14:14:12 rogue wpa_supplicant[620]: wlan0: CTRL-EVENT-TERMINATING >>> Jan 3 14:14:12 rogue dhclient[652]: connection closed >>> Jan 3 14:14:12 rogue dhclient[652]: exiting. >>> Jan 3 14:14:12 rogue wpa_supplicant[67153]: Successfully initialized >>> wpa_supplicant >>> Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Trying to associate >>> with 00:26:b8:67:c3:2d (SSID='babcom' freq=2437 MHz) >>> Jan 3 14:14:16 rogue wpa_supplicant[67154]: wlan0: Associated with >>> 00:26:b8:67:c3:2d >>> Jan 3 14:14:16 rogue kernel: wlan0: link state changed to UP >>> Jan 3 14:14:16 rogue devd: Executing '/etc/rc.d/dhclient quietstart >>> wlan0' >>> Jan 3 14:14:16 rogue dhclient[67191]: send_packet: No buffer space >>> available >>> Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: WPA: Key negotiation >>> completed with 00:26:b8:67:c3:2d [PTK=CCMP GTK=CCMP] >>> Jan 3 14:14:17 rogue wpa_supplicant[67154]: wlan0: CTRL-EVENT-CONNECTED >>> - Connection to 00:26:b8:67:c3:2d completed [id=1 id_str=] >>> Jan 3 14:14:18 rogue dhclient: New IP Address (wlan0): 192.168.1.5 >>> Jan 3 14:14:18 rogue dhclient: New Subnet Mask (wlan0): 255.255.255.0 >>> Jan 3 14:14:18 rogue dhclient: New Broadcast Address (wlan0): >>> 192.168.1.255 >>> Jan 3 14:14:18 rogue dhclient: New Routers (wlan0): 192.168.1.1 >>> >>> The restart took place when I restarted the interface about 5 minutes >>> after it went down and, as you can see, it came up normally. I'll admit >>> that I am completely baffled by the dbus/packagekit tie-in as I can't see >>> what packagekit would do to touch the network. >>> >>> I'll be building a new kernel with debug shortly. >>> >>> In my other message (to wireless) I also mentioned the (possibly >>> unrelated) issue of poor performance and and periodic sub-second >>> connectivity drops. >>> >>> -- >>> R. Kevin Oberman, Network Engineer, Retired >>> E-mail: rkoberman@gmail.com >>> >> >> I was about to send a report that removing bgscan fixed the issue, but, >> then it happened again. Nothing new in the log from prior cases. Any other >> flags to I should try to set in wlandebug? state? assoc? I'll admit that I >> have no idea which might be helpful. >> >> One thing I seem to have failed to post is the ifconfig after the failure: >> wlan0: flags=8c43 metric >> 0 mtu 1500 >> ether a0:88:b4:c6:ad:28 >> inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 >> nd6 options=29 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >> ssid "" channel 7 (2442 MHz 11g) >> country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF >> txpower 15 bmiss 10 scanvalid 60 protmode CTS wme roaming MANUAL >> >> Note: My AP is on channel 6. >> -- >> R. Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com >> > -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 07:16:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75E3AB06 for ; Wed, 29 Jan 2014 07:16:23 +0000 (UTC) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50DCA188B for ; Wed, 29 Jan 2014 07:16:23 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id um1so1423170pbc.33 for ; Tue, 28 Jan 2014 23:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9yt7XzuotbZZXOCLcF1ht6RyrIvYqzlfPpMbTpaHWRw=; b=qE9htRkU2atbTLM7yKWpZg1vDRmREjGpXKc/TpDDuOPKIFPLa+780HPSz5Pt+sA8x2 b8xo7wsZNAIWntoaeSKaA76tjGZRBA5vgnMyV6yr+3Tgt6/e0CvhqMD76i6ujW5hibvg JmHIq4TDWKVNCy7x7DABPf8ExwiucfXkOSHrZHN9os65dGpp1Vgc50E0+XxwXYNWO5cW Z14PgDTSzqBXDDiuo7uDuThHu8cwBCtahyazveVNdbhLoRRLVIlZJs4kidtXdMDDQUnB kLwyYkzQFIvYtPqz1D0dgvlbBzTzJxN2hh5jG13CTe4Ah59e98l/OOJ2wDpa3zMUTjOw sdUg== MIME-Version: 1.0 X-Received: by 10.68.171.229 with SMTP id ax5mr6222333pbc.125.1390979782442; Tue, 28 Jan 2014 23:16:22 -0800 (PST) Received: by 10.66.142.167 with HTTP; Tue, 28 Jan 2014 23:16:22 -0800 (PST) Date: Wed, 29 Jan 2014 08:16:22 +0100 Message-ID: Subject: Poudriere and CCache in FreeBSD 10-RELEASE From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 07:16:23 -0000 On FreeBSD 10.0-RELEASE, what I did was: ATTEMPT A: =A71. Installed ccache and dialog4ports from pkg(ng) repos with 'pkg install ccache'. =A72 Appended 'CCACHE_DIR=3D/var/cache/ccache' to /usr/local/etc/poudriere.= conf' ATTEMPT B: =A74. Then I appended the following three lines to /etc/make.conf to mount ccache to tmpfs WRKDIRPREFIX=3D/ccache WITH_CCACHE_BUILD=3Dyes CCACHE_COMPRESS=3Dyes =A75 Appended 'none /ccache tmpfs rw,size=3D4294967296 0 0' to /etc/fstab' and mounted /compcache. =A76 Replaced CCACHE_DIR=3D/ccache' to /usr/local/etc/poudriere.conf' In both cases, 'ccache -s' shows no hits: # ccache -s cache directory /root/.ccache cache hit (direct) 0 cache hit (preprocessed) 0 cache miss 0 files in cache 0 cache size 0 Kbytes max cache size 1.0 Gbytes Is there a specific way to use CCACHE with Poudriere in FreeBSD 10-RELEASE? What did I miss? Thanks! /zenny From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 08:06:37 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21445C7F; Wed, 29 Jan 2014 08:06:37 +0000 (UTC) Received: from mail1.yamagi.org (yugo.yamagi.org [84.201.39.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D59221CFD; Wed, 29 Jan 2014 08:06:36 +0000 (UTC) Received: from [212.48.125.110] (helo=lennart.pwag-local.de) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W8QAC-0005Hn-QZ; Wed, 29 Jan 2014 09:06:26 +0100 Date: Wed, 29 Jan 2014 09:06:24 +0100 From: Yamagi Burmeister To: jhb@freebsd.org Subject: Re: 10.0, csh history merge broken? Message-Id: <20140129090624.615af8881fe6df55c9663b5c@yamagi.org> In-Reply-To: <201401281147.15801.jhb@freebsd.org> References: <52E0E917.3060403@li.ru> <20140126215845.3b62debf03dade433622e9ba@yamagi.org> <201401281147.15801.jhb@freebsd.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, yerenkow@gmail.com, freebsd-stable@freebsd.org, amarat@li.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 08:06:37 -0000 On Tue, 28 Jan 2014 11:47:15 -0500 John Baldwin wrote: > On Monday, January 27, 2014 3:55:53 am Alexander Yerenkow wrote: > > >Maybe it would be a good idea to cherry pick those two revisions and > > >merge then into FreeBSD, until a new tcsh version is released. > > > > I think this is must, since currently any regular shutdown can break login > > ability (if server is high loaded + history file is broken and big enough). > > I have now locked history file with chflags until fix will come. > > These changes are already present in HEAD (FreeBSD 11) and will probably > be merged by the next 10 release. Really? As far as I can see the last commit to head/contrib/tcsh was the update to 6.18.01 one 22/02/2012 by mp@. While 6.18.01 featured a new, much faster history merge logic which minimized the race window, the root cause wasn't solve. Only the two upstream commits (from 08/12/2013 and 11/12/2013) linked above brought real locking to the merge process, serializing it between several tcsh instances. -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 10:39:43 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D7D7CC1 for ; Wed, 29 Jan 2014 10:39:43 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA22D18EC for ; Wed, 29 Jan 2014 10:39:42 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fa1so1615180pad.27 for ; Wed, 29 Jan 2014 02:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=S26SuBNNmwRYELYZ3NvfhC87quk8At9ciAneBs413bE=; b=dH70gat3GlAGAbdjIF+SgeaWJcoi1x+ZtmA6uW3xBSOTB4SLPl91Qm5vbLcpGbR0Ka C89TzzOW+FLdUtVB/FHrRgM3XMqOf3uwq67tDFTRn7veI+IUBwm3tAjbMKWRek4tc6dk C+UTG8GCe7z0b6XHw8DJio5iNgkEwtaimqRH42mCAv1cvDQMhKmhSeJk9eVLrCtUoEE6 wzpltsGw1hqTWYZWfJsobyk91cIa0BxjcLbKcpJfSwR2W7DYrnsvbvZy3VnZ2OqlsnDs T1Hz8mSZBXns7hELptZeHzEbqWZSqy0G85qt0wd+vQE1MHlL6jcA7jLiLu5RvlHZX2qh ZaMQ== MIME-Version: 1.0 X-Received: by 10.66.246.229 with SMTP id xz5mr7130734pac.119.1390991982611; Wed, 29 Jan 2014 02:39:42 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 02:39:42 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 11:39:42 +0100 Message-ID: Subject: Fwd: Poudriere and CCache in FreeBSD 10-RELEASE From: Zenny To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:39:43 -0000 On FreeBSD 10.0-RELEASE, what I did was: ATTEMPT A: =A71. Installed ccache and dialog4ports from pkg(ng) repos with 'pkg install ccache'. =A72 Appended 'CCACHE_DIR=3D/var/cache/ccache' to /usr/local/etc/poudriere.= conf' ATTEMPT B: =A74. Then I appended the following three lines to /etc/make.conf to mount ccache to tmpfs WRKDIRPREFIX=3D/ccache WITH_CCACHE_BUILD=3Dyes CCACHE_COMPRESS=3Dyes =A75 Appended 'none /ccache tmpfs rw,size=3D4294967296 0 0' to /etc/fstab' and mounted /compcache. =A76 Replaced CCACHE_DIR=3D/ccache' to /usr/local/etc/poudriere.conf' In both cases, 'ccache -s' shows no hits: # ccache -s cache directory /root/.ccache cache hit (direct) 0 cache hit (preprocessed) 0 cache miss 0 files in cache 0 cache size 0 Kbytes max cache size 1.0 Gbytes Is there a specific way to use CCACHE with Poudriere in FreeBSD 10-RELEASE with clang? What did I miss? Thanks! /zenny From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 10:43:08 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CF95F66 for ; Wed, 29 Jan 2014 10:43:08 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 305DE197D for ; Wed, 29 Jan 2014 10:43:08 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id un15so1602627pbc.32 for ; Wed, 29 Jan 2014 02:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2s3vEEvvczJyXNiCVIGehgEdDfdJGlE+DEglpWRA23A=; b=p5+ZHAY43V6iooaFKNc6GeZbnAp681x9c51XSx2XAcdLazMsKrW7TxFVLKbQBQKh4Z 1tovRSi1eMEbwtpB11o8+Y4XmRmvYID8mb7giNVeCP/zz8+G6+lasExB15K5ynyN8LjA PANOZjWBzP0yQOb3qkVEYZG+2V3wLBfNXiW1L75hNJST1ZpM95JJ5dMJr40enAgD/dmA BvFSaaJOcb05B9VdW8xrXtyPYS9OiXaae/DuE8TkReZGhOuQAAw8k9cdhVPYbBm6LXe8 0TRI1KdWJjTcfuqMqCIrQKs6e5vzqVVIC8wr2ZQT/8IzU1IJQiTqCYf+8E+Sgr3iB9S4 Q5hQ== MIME-Version: 1.0 X-Received: by 10.66.175.4 with SMTP id bw4mr7240668pac.56.1390992187862; Wed, 29 Jan 2014 02:43:07 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 02:43:07 -0800 (PST) Date: Wed, 29 Jan 2014 11:43:07 +0100 Message-ID: Subject: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Zenny To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:43:08 -0000 Hi: The mouse and keyboard stops responding after gdm starts. (on all occasions gdm and gnome enabled in rc.conf with or without moused, hal and dbus enabled). The xorg 1.7.7 worked with a black border all over screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 The card is: vgapci0@pci0:1:0:0: class=0x030000 card=0x04611043 chip=0x67791002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'Caicos [Radeon HD 6450]' class = display subclass = VGA The only thing that I could see in the attached log (line 109-126): [ 38.408] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 38.428] (II) Module mouse: vendor="X.Org Foundation" [ 38.441] compiled for 1.7.7, module version = 1.9.0 [ 38.463] Module class: X.Org XInput Driver [ 38.474] ABI class: X.Org XInput driver, version 7.0 [ 38.486] (EE) module ABI major version (7) doesn't match the server's version (16) [ 38.497] (II) UnloadModule: "mouse" [ 38.508] (II) Unloading mouse [ 38.519] (EE) Failed to load module "mouse" (module requirement mismatch, 0) [ 38.530] (II) LoadModule: "kbd" [ 38.553] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 38.564] (II) Module kbd: vendor="X.Org Foundation" [ 38.575] compiled for 1.7.7, module version = 1.8.0 [ 38.597] Module class: X.Org XInput Driver [ 38.608] ABI class: X.Org XInput driver, version 7.0 [ 38.619] (EE) module ABI major version (7) doesn't match the server's version (16) [ 38.630] (II) UnloadModule: "kbd" [ 38.642] (II) Unloading kbd There is no xorg.conf created. Can someone tell me what makes the kbd and mouse modules keeps on getting unloaded?! Thanks! /z From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 11:04:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 186E7629 for ; Wed, 29 Jan 2014 11:04:06 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD2961B01 for ; Wed, 29 Jan 2014 11:04:05 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so1615290pbb.7 for ; Wed, 29 Jan 2014 03:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qZ2EY4hZt0I+MZLYy2Chlv0hYKsvpZdXdMUJUX1bwPU=; b=NDo5tMf9jAKW/SfC0auxCmaAbD3EkqhyTo7+EAlETeO/XMcuTkje4zpUqun/gIUXDb F5Wms3WLHUdCvUKrJcjCxykOsaww0YRMm4a2OCdb/3ZXFPyjodYi7jIglsgbHEtXCHUb K2RGowGwUmLRSPQFPrh/umVJTio3zNdWvEzVgy2+L4tGMF3ZNNV8uCByyb9cTTkQrYYT F2+PeJdrac0VBnc1GFsSr5Rye0CeUs6o/s5fV4QMlJ3qQzrl2AytAgsMOl3XX5kjdu2B Zx2zPb+xEXqgCiz1p2MMic7yRPtFnJZrk7MAqqxwcgWQRI56zsTyNrKNviMdNhnQD8e7 vwPg== MIME-Version: 1.0 X-Received: by 10.66.121.164 with SMTP id ll4mr7416355pab.48.1390993445441; Wed, 29 Jan 2014 03:04:05 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 03:04:05 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 12:04:05 +0100 Message-ID: Subject: Fwd: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:04:06 -0000 Hi: The mouse and keyboard stops responding after gdm starts. (on all occasions gdm and gnome enabled in rc.conf with or without moused, hal and dbus enabled). The xorg 1.7.7 worked with a black border all over screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 The card is: vgapci0@pci0:1:0:0: class=0x030000 card=0x04611043 chip=0x67791002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'Caicos [Radeon HD 6450]' class = display subclass = VGA The only thing that I could see in the attached log (line 109-126): [ 38.408] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 38.428] (II) Module mouse: vendor="X.Org Foundation" [ 38.441] compiled for 1.7.7, module version = 1.9.0 [ 38.463] Module class: X.Org XInput Driver [ 38.474] ABI class: X.Org XInput driver, version 7.0 [ 38.486] (EE) module ABI major version (7) doesn't match the server's version (16) [ 38.497] (II) UnloadModule: "mouse" [ 38.508] (II) Unloading mouse [ 38.519] (EE) Failed to load module "mouse" (module requirement mismatch, 0) [ 38.530] (II) LoadModule: "kbd" [ 38.553] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 38.564] (II) Module kbd: vendor="X.Org Foundation" [ 38.575] compiled for 1.7.7, module version = 1.8.0 [ 38.597] Module class: X.Org XInput Driver [ 38.608] ABI class: X.Org XInput driver, version 7.0 [ 38.619] (EE) module ABI major version (7) doesn't match the server's version (16) [ 38.630] (II) UnloadModule: "kbd" [ 38.642] (II) Unloading kbd There is no xorg.conf created. Can someone tell me what makes the kbd and mouse modules keeps on getting unloaded?! Thanks! /z From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 11:23:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BB63E71 for ; Wed, 29 Jan 2014 11:23:56 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA9F1D87 for ; Wed, 29 Jan 2014 11:23:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=VAlDUZI6SdVImIDSfrU7OEHvc9lEtiO7Ur8SEUEopr4=; b=iYCe0z7G1741U/uxPT1M5WXZsjGEKVI4ewhtyVOL4zpYx9hocBZnwt3JAISg0P1RbSkkuItmSxzvevS0AGmkbCmZRapTHC2OpuoBNbQ+YmmdV1V/sbvXMxIb73iWVB21wokVDx7U1JhSbZ2ILJIRtnJbsOgw17ht2BTNmp+c4Js=; Received: from [39.196.10.7] (port=14445 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1W8TFJ-0000YW-Rw; Wed, 29 Jan 2014 04:23:55 -0700 Date: Wed, 29 Jan 2014 19:23:41 +0800 From: Erich Dollansky To: Zenny Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts Message-ID: <20140129192341.6a729f2f@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:23:56 -0000 Hi, On Wed, 29 Jan 2014 12:04:05 +0100 Zenny wrote: > The mouse and keyboard stops responding after gdm starts. (on all > occasions gdm and gnome enabled in rc.conf with or without moused, hal > and dbus enabled). The xorg 1.7.7 worked with a black border all over > screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 > compiling hal helped for me in a situation like this. Erich From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 12:08:59 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 412CA313 for ; Wed, 29 Jan 2014 12:08:59 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE9571149 for ; Wed, 29 Jan 2014 12:08:58 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id c6so1362352lan.25 for ; Wed, 29 Jan 2014 04:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8OK3Z0obDWdPoVcq7rMCaA+g/c1dUCncyK7jRbfW3Lk=; b=tYGJ14RVBeS9E9cXxmvEYUgBZztuknIP88AltO5YSvNeslHuTVZd2RrTRlSq8C3eIV X1x5Bg94URQKVdEbVZP8mb7tYIwsdKoJ42jNqiw+wWy8CI5QJUKhSaXXxBWp1z8nr8Zp tXEC3oz9La4j+MUXcq+aoenNLmxreRTtRtViVIPJiw9252M18uT1ZQuGTnRwsIAiBgxB J80bqvWRkuSxiH8yeMbR6exKO/kMZIcYPtTQ3FC2vNcBaXouoq5ttm8ib84/r1wJ7cwc ma0AE6Jac5K5wCoEDAVRENGzJc6BQGCTv+LK+v2frwv2hMIm1CZs9e33Q4GUHRRWzbVM buRg== MIME-Version: 1.0 X-Received: by 10.152.228.172 with SMTP id sj12mr1452890lac.32.1390997336725; Wed, 29 Jan 2014 04:08:56 -0800 (PST) Received: by 10.112.0.205 with HTTP; Wed, 29 Jan 2014 04:08:56 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 12:08:56 +0000 Message-ID: Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Tom Evans To: Zenny Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:08:59 -0000 On Wed, Jan 29, 2014 at 10:43 AM, Zenny wrote: > Hi: > > The mouse and keyboard stops responding after gdm starts. (on all > occasions gdm and gnome enabled in rc.conf with or without moused, hal > and dbus enabled). The xorg 1.7.7 worked with a black border all over > screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 > > The card is: > > vgapci0@pci0:1:0:0: class=0x030000 card=0x04611043 chip=0x67791002 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices [AMD] nee ATI' > device = 'Caicos [Radeon HD 6450]' > class = display > subclass = VGA > > > > The only thing that I could see in the attached log (line 109-126): > > [ 38.408] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > [ 38.428] (II) Module mouse: vendor="X.Org Foundation" > [ 38.441] compiled for 1.7.7, module version = 1.9.0 > [ 38.463] Module class: X.Org XInput Driver > [ 38.474] ABI class: X.Org XInput driver, version 7.0 > [ 38.486] (EE) module ABI major version (7) doesn't match the > server's version (16) > [ 38.497] (II) UnloadModule: "mouse" > [ 38.508] (II) Unloading mouse > [ 38.519] (EE) Failed to load module "mouse" (module requirement > mismatch, 0) > [ 38.530] (II) LoadModule: "kbd" > [ 38.553] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so > [ 38.564] (II) Module kbd: vendor="X.Org Foundation" > [ 38.575] compiled for 1.7.7, module version = 1.8.0 > [ 38.597] Module class: X.Org XInput Driver > [ 38.608] ABI class: X.Org XInput driver, version 7.0 > [ 38.619] (EE) module ABI major version (7) doesn't match the > server's version (16) > [ 38.630] (II) UnloadModule: "kbd" > [ 38.642] (II) Unloading kbd > > > There is no xorg.conf created. Can someone tell me what makes the kbd > and mouse modules keeps on getting unloaded?! Thanks! > This seems pretty clear, doesn't it? You previously had xorg 1.7.7 installed, you upgraded to xorg 1.12.4 and when you start X, the log file informs you that your mouse and keyboard drivers are compiled for xorg 1.7.7, will not work with this version, and are unloaded. Recompile and reinstall the appropriate drivers. You might also want to verify your process for upgrading packages - poudriere is a system for building up to date packages, it is not an update tool. Using poudriere correctly with the appropriate update tool should make it impossible for this scenario to happen, so there is probably something wrong with your process. You can verify it by listing it out here. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 12:11:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86B6D43C for ; Wed, 29 Jan 2014 12:11:40 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF9111C0 for ; Wed, 29 Jan 2014 12:11:39 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z5so1376183lbh.36 for ; Wed, 29 Jan 2014 04:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0NRK9MIR5FND+LnlDpmkagzUOsPHiCC5hqulSxGuGow=; b=HWsUSi59kl6o3IEoOdh0duBOZYfudElyR8FGQr2GczuIlIKZP52bMrabZYMAk7jykN KOxmu3ilCPl0qFkBtiZTmhp0GMcbmkl3nEnVZPdSeO5sSz7qus87aX/XiJ5a1biBCXep GyqZ5gik72itexONUiiLmBEpqOMpekYlS5nN0L1tCgXOpf0kj0JkYXMGkUgf6QUKwxpn G8IOp2DoiTD14ItXCoj0EI3o+x84ZvIqlYKnfLzLytT0zfPNcEsPlhuwrsWquc4Iqmi1 rau+w6sFZU6wx1r8i+dQp76gyFWbcA6C862iORAc+U9stQh4mCCzUjdSDKXtaqekorI0 hHow== MIME-Version: 1.0 X-Received: by 10.152.26.135 with SMTP id l7mr852916lag.43.1390997497931; Wed, 29 Jan 2014 04:11:37 -0800 (PST) Received: by 10.112.0.205 with HTTP; Wed, 29 Jan 2014 04:11:37 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 12:11:37 +0000 Message-ID: Subject: Re: Poudriere and CCache in FreeBSD 10-RELEASE From: Tom Evans To: Zenny Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:11:40 -0000 On Wed, Jan 29, 2014 at 7:16 AM, Zenny wrote: > On FreeBSD 10.0-RELEASE, what I did was: > > ATTEMPT A: > =C2=A71. Installed ccache and dialog4ports from pkg(ng) repos with 'pkg > install ccache'. > =C2=A72 Appended 'CCACHE_DIR=3D/var/cache/ccache' to /usr/local/etc/poudr= iere.conf' ^^^^^^^^^^^^^ > > ATTEMPT B: > =C2=A74. Then I appended the following three lines to /etc/make.conf to > mount ccache to tmpfs > WRKDIRPREFIX=3D/ccache > WITH_CCACHE_BUILD=3Dyes > CCACHE_COMPRESS=3Dyes > =C2=A75 Appended 'none /ccache tmpfs rw,size=3D4294967296 0 0' to /etc/fs= tab' > and mounted /compcache. > =C2=A76 Replaced CCACHE_DIR=3D/ccache' to /usr/local/etc/poudriere.conf' ^^^^^^^^^^^ > > In both cases, 'ccache -s' shows no hits: > > # ccache -s > cache directory /root/.ccache ^^^^^^^^^ Are you sure it isn't working, and not that you are inspecting a different cache directory? Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 12:19:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C12D35C6 for ; Wed, 29 Jan 2014 12:19:30 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 989231213 for ; Wed, 29 Jan 2014 12:19:30 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ld10so1712176pab.10 for ; Wed, 29 Jan 2014 04:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VNwN8962g8UQKHwUtCv6QH2LLHQrFrm6do8nr6QB6KQ=; b=ljJTbRqxLrDL0NOrK/P5nDdKuopLgUkXKgPGRcHFO7H33w0YItYSCZrN9PViTUxrL5 clSmrMBsajVPOEfMHX4npma0EDFnBSWcFZCVXmldF54oxS4F+Yd6g5Y2ecgxujFQjv6F EZrUQhV675C7BlBOsA0Qsnqj5P0jp8Xaklns/A4NHHANtdzcmo6BMkOhzb8i/ihuINl9 Dm6jHDOgK+Ny6RHLO4DiGNZWAxCueQfjX4nmU+2mlC1SahWcrUSRiZuto4ntAuZD0xAQ jfX8bBCPD0XE7ogt3TW1wmxTLXYBUY+NjGIEM2DI3co/mQq5qSBdAvb5pfzoFubKG0vO ZUNA== MIME-Version: 1.0 X-Received: by 10.66.162.74 with SMTP id xy10mr7744188pab.4.1390997970235; Wed, 29 Jan 2014 04:19:30 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 04:19:30 -0800 (PST) In-Reply-To: <20140129192341.6a729f2f@X220.alogt.com> References: <20140129192341.6a729f2f@X220.alogt.com> Date: Wed, 29 Jan 2014 13:19:30 +0100 Message-ID: Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Zenny To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:19:30 -0000 I did compile hal using poudriere and upgraded. Still the problem persists. On 1/29/14, Erich Dollansky wrote: > Hi, > > On Wed, 29 Jan 2014 12:04:05 +0100 > Zenny wrote: > >> The mouse and keyboard stops responding after gdm starts. (on all >> occasions gdm and gnome enabled in rc.conf with or without moused, hal >> and dbus enabled). The xorg 1.7.7 worked with a black border all over >> screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 >> > compiling hal helped for me in a situation like this. > > Erich > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 12:39:17 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91CFDF07 for ; Wed, 29 Jan 2014 12:39:17 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 695071384 for ; Wed, 29 Jan 2014 12:39:17 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fa1so1711061pad.13 for ; Wed, 29 Jan 2014 04:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=atFtOFsz+tAowJIuE7lQwWR61oC5lMxLAvEID4SobOo=; b=0qk3IvnY9xDoOSpk67xs2xKrjcYNKXI5fiLyxfACnEhdb/EoyCnaQ3fABsyVES+AzT rFeeDM7ZFdp8Ye6sOzbrCYUg5GG83gQeeYEY5/b1c8y3G+nEcRhwGBW1YHnP3pzJoCqN 1+PHszwIDwbc8tOqB/LHFGGAt9ybosirfSlFaAe1acXGks38Wq0CaRRl8P8gvG5eXaLb upt4XQNFc4v5ccOoLGcFxdvnTmrgO9oZ3mKab2o9cqVWx1kI9fjRMKRa1BvSVwKXrnPl 81xYfONdlLX+uohMObv4vZwv61HKCS0IePylYG1yB7s+ESm83H6iQ3UxUS/YGtVdKCcZ RzgA== MIME-Version: 1.0 X-Received: by 10.68.171.229 with SMTP id ax5mr7637556pbc.125.1390999157131; Wed, 29 Jan 2014 04:39:17 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 04:39:17 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 13:39:17 +0100 Message-ID: Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Zenny To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 12:39:17 -0000 On 1/29/14, Tom Evans wrote: > On Wed, Jan 29, 2014 at 10:43 AM, Zenny wrote: >> Hi: >> >> The mouse and keyboard stops responding after gdm starts. (on all >> occasions gdm and gnome enabled in rc.conf with or without moused, hal >> and dbus enabled). The xorg 1.7.7 worked with a black border all over >> screen, so used poudiere to upgrade to xorg-server-1.12.4_4,1 >> >> The card is: >> >> vgapci0@pci0:1:0:0: class=0x030000 card=0x04611043 chip=0x67791002 >> rev=0x00 hdr=0x00 >> vendor = 'Advanced Micro Devices [AMD] nee ATI' >> device = 'Caicos [Radeon HD 6450]' >> class = display >> subclass = VGA >> >> >> >> The only thing that I could see in the attached log (line 109-126): >> >> [ 38.408] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so >> [ 38.428] (II) Module mouse: vendor="X.Org Foundation" >> [ 38.441] compiled for 1.7.7, module version = 1.9.0 >> [ 38.463] Module class: X.Org XInput Driver >> [ 38.474] ABI class: X.Org XInput driver, version 7.0 >> [ 38.486] (EE) module ABI major version (7) doesn't match the >> server's version (16) >> [ 38.497] (II) UnloadModule: "mouse" >> [ 38.508] (II) Unloading mouse >> [ 38.519] (EE) Failed to load module "mouse" (module requirement >> mismatch, 0) >> [ 38.530] (II) LoadModule: "kbd" >> [ 38.553] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so >> [ 38.564] (II) Module kbd: vendor="X.Org Foundation" >> [ 38.575] compiled for 1.7.7, module version = 1.8.0 >> [ 38.597] Module class: X.Org XInput Driver >> [ 38.608] ABI class: X.Org XInput driver, version 7.0 >> [ 38.619] (EE) module ABI major version (7) doesn't match the >> server's version (16) >> [ 38.630] (II) UnloadModule: "kbd" >> [ 38.642] (II) Unloading kbd >> >> >> There is no xorg.conf created. Can someone tell me what makes the kbd >> and mouse modules keeps on getting unloaded?! Thanks! >> > > This seems pretty clear, doesn't it? You previously had xorg 1.7.7 > installed, you upgraded to xorg 1.12.4 and when you start X, the log > file informs you that your mouse and keyboard drivers are compiled for > xorg 1.7.7, will not work with this version, and are unloaded. > > Recompile and reinstall the appropriate drivers. I recompiled accordingly and upgraded the drivers too as my poudriere.list has: Thanks Tom for your response. x11/xorg x11/xinit x11-drivers/xf86-video-ati x11-drivers/xf86-video-radeonhd x11-drivers/xf86-input-keyboard x11-drivers/xf86-input-mouse x11-drivers/xorg-drivers x11-fonts/webfonts x11-fonts/ubuntu-font www/linux-f10-flashplugin11 ports-mgmt/poudriere graphics/libdrm graphics/dri graphics/libGL sysutils/hal > > You might also want to verify your process for upgrading packages - > poudriere is a system for building up to date packages, it is not an > update tool. Using poudriere correctly with the appropriate update > tool should make it impossible for this scenario to happen, so there > is probably something wrong with your process. You can verify it by > listing it out here. FYI, poudriere.conf reads: ZPOOL=zroot FREEBSD_HOST=ftp://ftp.freebsd.org RESOLV_CONF=/etc/resolv.conf BASEFS=/usr/local/poudriere USE_TMPFS=yes DISTFILES_CACHE=/usr/ports/distfiles POUDRIERE_DATA=${BASEFS}/data CHECK_CHANGED_OPTIONS=verbose CHECK_CHANGED_DEPS=yes PKG_REPO_SIGNING_KEY=/usr/local/etc/ssl/keys/pkg.key WRKDIR_ARCHIVE_FORMAT=txz NOLINUX=yes /etc/make.conf reads: WITH_NEW_XORG=yes WITH_KMS=yes WITH_GALLIUM=yes MAKE_JOBS_UNSAFE=yes /usr/local/etc/poudriere.d/10-amd64-make.conf has: WITH_NEW_XORG="yes" WITH_KMS="yes" Did I miss something? > > Cheers > > Tom > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 14:20:31 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66B9B163 for ; Wed, 29 Jan 2014 14:20:31 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 161021DE2 for ; Wed, 29 Jan 2014 14:20:30 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0TEKTTI060318; Wed, 29 Jan 2014 07:20:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0TEKTp5060315; Wed, 29 Jan 2014 07:20:29 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 29 Jan 2014 07:20:29 -0700 (MST) From: Warren Block To: Zenny Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts In-Reply-To: Message-ID: References: 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 IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 29 Jan 2014 07:20:29 -0700 (MST) Cc: Tom Evans , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:20:31 -0000 On Wed, 29 Jan 2014, Zenny wrote: > x11/xorg > x11/xinit > x11-drivers/xf86-video-ati > x11-drivers/xf86-video-radeonhd Do not install radeonhd, it is obsolete. The radeon driver in xf86-video-ati works for all the Radeon cards that are supported. > x11-drivers/xf86-input-keyboard > x11-drivers/xf86-input-mouse > x11-drivers/xorg-drivers > x11-fonts/webfonts > x11-fonts/ubuntu-font > www/linux-f10-flashplugin11 > ports-mgmt/poudriere > graphics/libdrm > graphics/dri > graphics/libGL > sysutils/hal HAL and dbus should probably be recompiled together. X can be prevented from using hal at all by setting Option "AutoAddDevices" "Off" in ServerLayout. The wiki has a section on installing or upgrading to the KMS drivers: https://wiki.freebsd.org/Graphics#Installing_KMS_Ports From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 14:23:09 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84A3B4EC for ; Wed, 29 Jan 2014 14:23:09 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D23A1E7A for ; Wed, 29 Jan 2014 14:23:08 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so1518960lbj.3 for ; Wed, 29 Jan 2014 06:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7c/PMgHOzmM5dhXqitTOa+g6ZCKi+Zv8JRYYePI/gi8=; b=nfdp7eIRTbUGG9vTLTOeGHnLwupYHipkHU9Vlop4ktBhbMppVSxtnGzvbXK6+cagkz iiR8wc8ERft+urfRavW2neVWEqA5YmybfzHCywcgD1xaIhlqAHn9bpkhTE7b1xTUchls L/DmFqFhX5J9sBmNsalgDf+06ajSRk+AmqyKjJlMWR+G3z2mMUv3k/G8ETi8HgE6h/lA f1HX1FJM5pcEQfZdztPjXoU7FvdfzpuDIomq1kBQoBPTNuzO+q3UqQLMIgW6WU6kkY7B EY+y0XdK6i/fVb7GSoYO8EHqt6iLXtYgTbSXg/tx0xXFOARJTC7LiR3R/UQEv5LnPSy/ B/UA== MIME-Version: 1.0 X-Received: by 10.112.45.108 with SMTP id l12mr5438237lbm.21.1391005387108; Wed, 29 Jan 2014 06:23:07 -0800 (PST) Received: by 10.112.0.205 with HTTP; Wed, 29 Jan 2014 06:23:07 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 14:23:07 +0000 Message-ID: Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Tom Evans To: Zenny Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:23:09 -0000 On Wed, Jan 29, 2014 at 12:39 PM, Zenny wrote: > FYI, poudriere.conf reads: > > ZPOOL=zroot > FREEBSD_HOST=ftp://ftp.freebsd.org > RESOLV_CONF=/etc/resolv.conf > BASEFS=/usr/local/poudriere > USE_TMPFS=yes > DISTFILES_CACHE=/usr/ports/distfiles > POUDRIERE_DATA=${BASEFS}/data > CHECK_CHANGED_OPTIONS=verbose > CHECK_CHANGED_DEPS=yes > PKG_REPO_SIGNING_KEY=/usr/local/etc/ssl/keys/pkg.key > WRKDIR_ARCHIVE_FORMAT=txz > NOLINUX=yes > > /etc/make.conf reads: > > WITH_NEW_XORG=yes > WITH_KMS=yes > WITH_GALLIUM=yes > MAKE_JOBS_UNSAFE=yes > > /usr/local/etc/poudriere.d/10-amd64-make.conf has: > > WITH_NEW_XORG="yes" > WITH_KMS="yes" > > Did I miss something? poudriere is a package builder, it is not a package installer. How you are installing and upgrading your packages - you do not have WITH_PKGNG set, for instance, so are you using portupgrade or portmaster? Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 14:35:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EFA0BD9 for ; Wed, 29 Jan 2014 14:35:19 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3E7B1FE4 for ; Wed, 29 Jan 2014 14:35:18 +0000 (UTC) Received: from blazon-pc.rw.local ([78.84.244.14]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0MMSxU-1WCMm92vHi-008Jav for ; Wed, 29 Jan 2014 15:35:11 +0100 Message-ID: <52E911E8.2090104@mail.com> Date: Wed, 29 Jan 2014 16:36:24 +0200 From: Jeff Tipton User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121030 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: regression: msk0 watchdog timeout and interrupt storm References: <52E6CB2B.9040208@mail.com> In-Reply-To: <52E6CB2B.9040208@mail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qZ5U5kqVABg8RcoOv/VsVNWT3KDDDUro8CqDZ+cS9PDJGDuFm3z Ze5NjADv0RQ6SiCDxzGN/3wX2/y9scvfP5ccHXyDlI+0zOlKGwbMcrd9bidEvKfCkhQV8et mcTTGhJgyEXQlDVS/+szYC3UUjSeItI3P7/O1kk1ZnXHyDuw4bgyXTWkAe5YXOBQ+qtEqB+ SOAH0hAVSxovQflpHvkxQ== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 14:35:19 -0000 On 01/27/2014 23:10, Jeff Tipton wrote: > Hi, > > I also have this problem on Samsung N220 netbook, except I don't have > any "interrupt storm" messages. When it boots up, it works a couple of > minutes, and then "msk0: watchdog timeout" message appears. And, yes, > the fastest way to reproduce the error is to try to copy a file via > scp (even a 6MB file is enough). > > uname -a > > FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 > 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC > amd64 > > pciconf -lcv > [..] > > mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab > rev=0x00 hdr=0x00 > vendor = 'Marvell Technology Group Ltd.' > device = '88E8040 PCI-E Fast Ethernet Controller' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link > x1(x1) > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected > ecap 0003[130] = Serial 1 f0d173ffff542400 > > I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just > fine there. > > I also tried to change if_mskreg.h as Curtis suggested, recompiled the > kernel but it didn't help; nothing changed :( > > Jeff > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" And, yes, I also found out that after having been booted into 10.0, if I immediately reboot into 9.2, msk0 doesn't work there either; no "watchdof timeout" messages, though; but ifconfig shows "no carrier"; restarting interface or netif service doesn't help. I had to switch the netbook off completely and take the battery out for some minutes, and only then it finally worked in 9.2 again. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 18:36:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB8D4BFE; Wed, 29 Jan 2014 18:36:16 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA07C1811; Wed, 29 Jan 2014 18:36:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86BF3B9C8; Wed, 29 Jan 2014 13:36:15 -0500 (EST) From: John Baldwin To: Yamagi Burmeister Subject: Re: 10.0, csh history merge broken? Date: Wed, 29 Jan 2014 12:14:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E0E917.3060403@li.ru> <201401281147.15801.jhb@freebsd.org> <20140129090624.615af8881fe6df55c9663b5c@yamagi.org> In-Reply-To: <20140129090624.615af8881fe6df55c9663b5c@yamagi.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401291214.56887.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Jan 2014 13:36:15 -0500 (EST) Cc: stable@freebsd.org, yerenkow@gmail.com, freebsd-stable@freebsd.org, amarat@li.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:36:17 -0000 On Wednesday, January 29, 2014 3:06:24 am Yamagi Burmeister wrote: > On Tue, 28 Jan 2014 11:47:15 -0500 > John Baldwin wrote: > > > On Monday, January 27, 2014 3:55:53 am Alexander Yerenkow wrote: > > > >Maybe it would be a good idea to cherry pick those two revisions and > > > >merge then into FreeBSD, until a new tcsh version is released. > > > > > > I think this is must, since currently any regular shutdown can break login > > > ability (if server is high loaded + history file is broken and big enough). > > > I have now locked history file with chflags until fix will come. > > > > These changes are already present in HEAD (FreeBSD 11) and will probably > > be merged by the next 10 release. > > Really? As far as I can see the last commit to head/contrib/tcsh was > the update to 6.18.01 one 22/02/2012 by mp@. While 6.18.01 featured a > new, much faster history merge logic which minimized the race window, > the root cause wasn't solve. Only the two upstream commits (from > 08/12/2013 and 11/12/2013) linked above brought real locking to the > merge process, serializing it between several tcsh instances. Bah, somehow I had thought I had seen the 'lock' keyword in tcsh on my HEAD box, but I don't see it there now. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 18:39:56 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07122E55 for ; Wed, 29 Jan 2014 18:39:56 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D15511857 for ; Wed, 29 Jan 2014 18:39:55 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id rr13so2093649pbb.7 for ; Wed, 29 Jan 2014 10:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DfEHTg1BdUBtwEjelOQbCPUypFW+IE4rQjEG7XBhbEM=; b=DqTb4BwxynOkhkDoKDCMA1cBaN5gjtUI7HHyKaJe/kKhw6DuYeDsj2RRtONzwns8jd bfN9Ybww89PV3+27mhwiDEZeLVnt2pcVfdHv1bp1r+P3aJsIpdCY3HdXjfLLvTTDhKlv 17DKqCxw2+RUFmlScLvyCJPmDAGK3qMMLlHSvPYfp8YgzHSHXxBHdanfDrKfGTCIQ5gG mtryztU2Sp95XzP6aW0KB7NZmShH1YtnON8jlzZu9ApEOhGnjKrDOkZm+Qe8bTsP5m53 YwQF5PrLG1s9CBygmxi1LACD51h85F27+0CGjkDZ0/YGDWyiaNfx8g4UMwl5Cq1XL4EQ O47Q== MIME-Version: 1.0 X-Received: by 10.66.121.164 with SMTP id ll4mr9873400pab.48.1391020795481; Wed, 29 Jan 2014 10:39:55 -0800 (PST) Received: by 10.66.142.167 with HTTP; Wed, 29 Jan 2014 10:39:55 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 19:39:55 +0100 Message-ID: Subject: Re: FreeBSD 10.0-RELEASE: mouse and kbd freezes after gdm starts From: Zenny To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:39:56 -0000 SOLVED: This seems to be an issue discussed here: https://github.com/freebsd/pkg/issues/347 And it is solved by running: pkg clean -ya to disable cache. #pkg update #pkg upgrade #pkg install -f xf86-input-keyboard xf86-input-keyboard SOLVED. Thanks to everyone for the inputs. On 1/29/14, Tom Evans wrote: > On Wed, Jan 29, 2014 at 12:39 PM, Zenny wrote: >> FYI, poudriere.conf reads: >> >> ZPOOL=zroot >> FREEBSD_HOST=ftp://ftp.freebsd.org >> RESOLV_CONF=/etc/resolv.conf >> BASEFS=/usr/local/poudriere >> USE_TMPFS=yes >> DISTFILES_CACHE=/usr/ports/distfiles >> POUDRIERE_DATA=${BASEFS}/data >> CHECK_CHANGED_OPTIONS=verbose >> CHECK_CHANGED_DEPS=yes >> PKG_REPO_SIGNING_KEY=/usr/local/etc/ssl/keys/pkg.key >> WRKDIR_ARCHIVE_FORMAT=txz >> NOLINUX=yes >> >> /etc/make.conf reads: >> >> WITH_NEW_XORG=yes >> WITH_KMS=yes >> WITH_GALLIUM=yes >> MAKE_JOBS_UNSAFE=yes >> >> /usr/local/etc/poudriere.d/10-amd64-make.conf has: >> >> WITH_NEW_XORG="yes" >> WITH_KMS="yes" >> >> Did I miss something? > > poudriere is a package builder, it is not a package installer. How you > are installing and upgrading your packages - you do not have > WITH_PKGNG set, for instance, so are you using portupgrade or > portmaster? > > Cheers > > Tom > From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 18:45:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04F6A7E; Wed, 29 Jan 2014 18:45:12 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 960A218E7; Wed, 29 Jan 2014 18:45:10 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TIj8Be046913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 13:45:09 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0TIj8Xk046910; Wed, 29 Jan 2014 13:45:08 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 13:45:08 -0500 From: Garrett Wollman To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: stable/9 mps(4) rev 254938 == BOOM! X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 13:45:09 -0500 (EST) Cc: scottl@freebsd.org, ken@freebsd.org, hselasky@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:45:12 -0000 I've been trying to puzzle out why the USB stack hits a GPF during boot on 9-stable on one of my machines (which runs 9.2 just fine), and by trial and error I've found that it is actually caused by r254938, which is a mega-MFC of mps(4) driver changes, even though the fault always occurs at the same place in a harmless USB subroutine. Details below; config available on request. -GAWollman Here is a verbose boot from r254938, with the crash: OK set debug.debugger_on_panic=1 OK boot -v Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009c800 SMAP type=02 base=000000000009c800 len=0000000000003800 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=00000000bf660000 SMAP type=01 base=00000000bf76e000 len=0000000000002000 SMAP type=03 base=00000000bf770000 len=000000000000e000 SMAP type=04 base=00000000bf77e000 len=0000000000052000 SMAP type=02 base=00000000bf7d0000 len=0000000000010000 SMAP type=02 base=00000000bf7ec000 len=0000000000014000 SMAP type=02 base=00000000bf800000 len=0000000000800000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffc00000 len=0000000000400000 SMAP type=01 base=0000000100000000 len=0000001340000000 Table 'FACP' at 0xbf770290 Table 'APIC' at 0xbf770390 APIC: Found table at 0xbf770390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 16 ACPI ID 4: enabled SMP: Added CPU 16 (AP) MADT: Found CPU APIC ID 18 ACPI ID 5: enabled SMP: Added CPU 18 (AP) MADT: Found CPU APIC ID 20 ACPI ID 6: enabled SMP: Added CPU 20 (AP) MADT: Found CPU APIC ID 32 ACPI ID 7: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 8: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 9: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 48 ACPI ID 10: enabled SMP: Added CPU 48 (AP) MADT: Found CPU APIC ID 50 ACPI ID 11: enabled SMP: Added CPU 50 (AP) MADT: Found CPU APIC ID 52 ACPI ID 12: enabled SMP: Added CPU 52 (AP) MADT: Found CPU APIC ID 1 ACPI ID 13: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 14: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 15: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 17 ACPI ID 16: enabled SMP: Added CPU 17 (AP) MADT: Found CPU APIC ID 19 ACPI ID 17: enabled SMP: Added CPU 19 (AP) MADT: Found CPU APIC ID 21 ACPI ID 18: enabled SMP: Added CPU 21 (AP) MADT: Found CPU APIC ID 33 ACPI ID 19: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 20: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 21: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 49 ACPI ID 22: enabled SMP: Added CPU 49 (AP) MADT: Found CPU APIC ID 51 ACPI ID 23: enabled SMP: Added CPU 51 (AP) MADT: Found CPU APIC ID 53 ACPI ID 24: enabled SMP: Added CPU 53 (AP) Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-PRERELEASE #14 r254938M: Wed Jan 29 12:29:49 EST 2014 wollman@xyz.csail.mit.edu:/usr/obj/usr/src-9-stable/sys/CSAIL amd64 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81480000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81480270. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff81480958. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff81480fc8. Calibrating TSC clock ... TSC clock: 2933495320 Hz CPU: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (2933.50-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 0x6 Model = 0x2c Stepping = 2 Features=0xbfebfbff Features2=0x29ee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 85899345920 (81920 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000098fff, 561152 bytes (137 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x00000000014ac000 - 0x00000000bf75ffff, 3190505472 bytes (778932 pages) 0x00000000bf76e000 - 0x00000000bf76ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x00000013a7c71fff, 80124256256 bytes (19561586 pages) avail memory = 83076120576 (79227 MB) INTR: Adding local APIC 0 as a target Event timer "LAPIC" quality 600 ACPI APIC Table: <081711 APIC1011> INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 16 as a target INTR: Adding local APIC 17 as a target INTR: Adding local APIC 18 as a target INTR: Adding local APIC 19 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 21 as a target INTR: Adding local APIC 32 as a target INTR: Adding local APIC 33 as a target INTR: Adding local APIC 34 as a target INTR: Adding local APIC 35 as a target INTR: Adding local APIC 36 as a target INTR: Adding local APIC 37 as a target INTR: Adding local APIC 48 as a target INTR: Adding local APIC 49 as a target INTR: Adding local APIC 50 as a target INTR: Adding local APIC 51 as a target INTR: Adding local APIC 52 as a target INTR: Adding local APIC 53 as a target FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 16 cpu7 (AP): APIC ID: 17 cpu8 (AP): APIC ID: 18 cpu9 (AP): APIC ID: 19 cpu10 (AP): APIC ID: 20 cpu11 (AP): APIC ID: 21 cpu12 (AP): APIC ID: 32 cpu13 (AP): APIC ID: 33 cpu14 (AP): APIC ID: 34 cpu15 (AP): APIC ID: 35 cpu16 (AP): APIC ID: 36 cpu17 (AP): APIC ID: 37 cpu18 (AP): APIC ID: 48 cpu19 (AP): APIC ID: 49 cpu20 (AP): APIC ID: 50 cpu21 (AP): APIC ID: 51 cpu22 (AP): APIC ID: 52 cpu23 (AP): APIC ID: 53 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff80003ad000 x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 13 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 14 APIC: CPU 4 has ACPI ID 3 APIC: CPU 5 has ACPI ID 15 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 16 APIC: CPU 8 has ACPI ID 5 APIC: CPU 9 has ACPI ID 17 APIC: CPU 10 has ACPI ID 6 APIC: CPU 11 has ACPI ID 18 APIC: CPU 12 has ACPI ID 7 APIC: CPU 13 has ACPI ID 19 APIC: CPU 14 has ACPI ID 8 APIC: CPU 15 has ACPI ID 20 APIC: CPU 16 has ACPI ID 9 APIC: CPU 17 has ACPI ID 21 APIC: CPU 18 has ACPI ID 10 APIC: CPU 19 has ACPI ID 22 APIC: CPU 20 has ACPI ID 11 APIC: CPU 21 has ACPI ID 23 APIC: CPU 22 has ACPI ID 12 APIC: CPU 23 has ACPI ID 24 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ULE: setup cpu 8 ULE: setup cpu 9 ULE: setup cpu 10 ULE: setup cpu 11 ULE: setup cpu 12 ULE: setup cpu 13 ULE: setup cpu 14 ULE: setup cpu 15 ULE: setup cpu 16 ULE: setup cpu 17 ULE: setup cpu 18 ULE: setup cpu 19 ULE: setup cpu 20 ULE: setup cpu 21 ULE: setup cpu 22 ULE: setup cpu 23 ACPI: RSDP 0xfadb0 00024 (v02 ACPIAM) ACPI: XSDT 0xbf770100 0008C (v01 081711 XSDT1011 20110817 MSFT 00000097) ACPI: FACP 0xbf770290 000F4 (v03 081711 FACP1011 20110817 MSFT 00000097) ACPI: DSDT 0xbf7705d0 05DDD (v01 Z99Q3 Z99Q3A03 00000A03 INTL 20051117) ACPI: FACS 0xbf77e000 00040 ACPI: APIC 0xbf770390 001AE (v01 081711 APIC1011 20110817 MSFT 00000097) ACPI: SPCR 0xbf770540 00050 (v01 081711 SPCR1011 20110817 MSFT 00000097) ACPI: MCFG 0xbf770590 0003C (v01 081711 OEMMCFG 20110817 MSFT 00000097) ACPI: SSDT 0xbf77a5d0 0002A (v01 OEM_ID OEMTBLID 00000001 INTL 20051117) ACPI: OEMB 0xbf77e040 00083 (v01 081711 OEMB1011 20110817 MSFT 00000097) ACPI: SRAT 0xbf77a600 00250 (v01 081711 OEMSRAT 00000001 INTL 00000001) ACPI: HPET 0xbf77a850 00038 (v01 081711 OEMHPET 20110817 MSFT 00000097) ACPI: SSDT 0xbf7857b0 00363 (v01 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf77a890 00130 (v01 AMIER AMI_EINJ 20110817 MSFT 00000097) ACPI: BERT 0xbf77aa20 00030 (v01 AMIER AMI_BERT 20110817 MSFT 00000097) ACPI: ERST 0xbf77aa50 001B0 (v01 AMIER AMI_ERST 20110817 MSFT 00000097) ACPI: HEST 0xbf77ac00 000A8 (v01 AMIER ABC_HEST 20110817 MSFT 00000097) MADT: Found IO APIC ID 6, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 7, Interrupt 24 at 0xfec8a000 ioapic1: Changing APIC ID to 7 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic16: Routing NMI -> LINT1 lapic16: LINT1 trigger: edge lapic16: LINT1 polarity: high lapic18: Routing NMI -> LINT1 lapic18: LINT1 trigger: edge lapic18: LINT1 polarity: high lapic20: Routing NMI -> LINT1 lapic20: LINT1 trigger: edge lapic20: LINT1 polarity: high lapic32: Routing NMI -> LINT1 lapic32: LINT1 trigger: edge lapic32: LINT1 polarity: high lapic34: Routing NMI -> LINT1 lapic34: LINT1 trigger: edge lapic34: LINT1 polarity: high lapic36: Routing NMI -> LINT1 lapic36: LINT1 trigger: edge lapic36: LINT1 polarity: high lapic48: Routing NMI -> LINT1 lapic48: LINT1 trigger: edge lapic48: LINT1 polarity: high lapic50: Routing NMI -> LINT1 lapic50: LINT1 trigger: edge lapic50: LINT1 polarity: high lapic52: Routing NMI -> LINT1 lapic52: LINT1 trigger: edge lapic52: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic5: Routing NMI -> LINT1 lapic5: LINT1 trigger: edge lapic5: LINT1 polarity: high lapic17: Routing NMI -> LINT1 lapic17: LINT1 trigger: edge lapic17: LINT1 polarity: high lapic19: Routing NMI -> LINT1 lapic19: LINT1 trigger: edge lapic19: LINT1 polarity: high lapic21: Routing NMI -> LINT1 lapic21: LINT1 trigger: edge lapic21: LINT1 polarity: high lapic33: Routing NMI -> LINT1 lapic33: LINT1 trigger: edge lapic33: LINT1 polarity: high lapic35: Routing NMI -> LINT1 lapic35: LINT1 trigger: edge lapic35: LINT1 polarity: high lapic37: Routing NMI -> LINT1 lapic37: LINT1 trigger: edge lapic37: LINT1 polarity: high lapic49: Routing NMI -> LINT1 lapic49: LINT1 trigger: edge lapic49: LINT1 polarity: high lapic51: Routing NMI -> LINT1 lapic51: LINT1 trigger: edge lapic51: LINT1 polarity: high lapic53: Routing NMI -> LINT1 lapic53: LINT1 trigger: edge lapic53: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 firmware: 't4fw_cfg' version 0: 2917 bytes loaded at 0xffffffff80d4bf64 firmware: 't4fw_cfg_uwire' version 0: 20576 bytes loaded at 0xffffffff80d4cac9 firmware: 't4fw' version 0: 478208 bytes loaded at 0xffffffff80d51b29 firmware: 't5fw_cfg' version 0: 3111 bytes loaded at 0xffffffff80dc6804 firmware: 't5fw' version 0: 460800 bytes loaded at 0xffffffff80dc742b firmware: 'isp_1040' version 1: 22944 bytes loaded at 0xffffffff80934c00 ispfw: registered firmware firmware: 'isp_1040_it' version 1: 32942 bytes loaded at 0xffffffff8093a5a0 ispfw: registered firmware firmware: 'isp_1080' version 1: 31350 bytes loaded at 0xffffffff80942660 ispfw: registered firmware firmware: 'isp_1080_it' version 1: 40644 bytes loaded at 0xffffffff8094a0e0 ispfw: registered firmware firmware: 'isp_12160' version 1: 28050 bytes loaded at 0xffffffff80953fc0 ispfw: registered firmware firmware: 'isp_12160_it' version 1: 40604 bytes loaded at 0xffffffff8095ad60 ispfw: registered firmware firmware: 'isp_2100' version 1: 76770 bytes loaded at 0xffffffff80964c00 ispfw: registered firmware firmware: 'isp_2200' version 1: 77214 bytes loaded at 0xffffffff80977800 ispfw: registered firmware firmware: 'isp_2300' version 1: 113630 bytes loaded at 0xffffffff8098a5a0 ispfw: registered firmware firmware: 'isp_2322' version 1: 120466 bytes loaded at 0xffffffff809a6180 ispfw: registered firmware firmware: 'isp_2400' version 1: 178924 bytes loaded at 0xffffffff809c7380 ispfw: registered firmware firmware: 'isp_2400_multi' version 1: 195276 bytes loaded at 0xffffffff809ffde0 ispfw: registered firmware firmware: 'isp_2500' version 1: 141884 bytes loaded at 0xffffffff80a3d2e0 ispfw: registered firmware firmware: 'isp_2500_multi' version 1: 166508 bytes loaded at 0xffffffff80a6ee40 ispfw: registered firmware cpuctl: access to MSR registers/cpuid info. io: nfslock: pseudo-device crypto: null: random: kbd: new array size 4 kbd1 at kbdmux0 mem: smbios0: at iomem 0xfbe70-0xfbe8e on motherboard smbios0: Version: 2.5 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 aesni0: on motherboard crypto: assign aesni0 driver id 1, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 crypto: aesni0 registers alg 22 flags 0 maxoplen 0 acpi0: <081711 XSDT1011> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed cpu0: Processor \_PR_.P001 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x35, should be 0x32 (20110527/tbutils-282) ACPI: SSDT 0xbf77e0d0 0603C (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0603C (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf784110 00C88 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00C88 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: SSDT 0xbf784da0 00A0A (v01 PmRef Cpu0Tst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00A0A (v01 PmRef Cpu0Tst 00003000 INTL 20051117) cpu1: Processor \_PR_.P002 (ACPI ID 2) -> APIC ID 2 cpu1: on acpi0 cpu2: Processor \_PR_.P003 (ACPI ID 3) -> APIC ID 4 cpu2: on acpi0 cpu3: Processor \_PR_.P004 (ACPI ID 4) -> APIC ID 6 cpu3: on acpi0 cpu4: Processor \_PR_.P005 (ACPI ID 5) -> APIC ID 8 cpu4: on acpi0 cpu5: Processor \_PR_.P006 (ACPI ID 6) -> APIC ID 10 cpu5: on acpi0 cpu6: Processor \_PR_.P007 (ACPI ID 7) -> APIC ID 12 cpu6: on acpi0 cpu7: Processor \_PR_.P008 (ACPI ID 8) -> APIC ID 14 cpu7: on acpi0 cpu8: Processor \_PR_.P009 (ACPI ID 9) -> APIC ID 16 cpu8: on acpi0 cpu9: Processor \_PR_.P010 (ACPI ID 10) -> APIC ID 18 cpu9: on acpi0 cpu10: Processor \_PR_.P011 (ACPI ID 11) -> APIC ID 20 cpu10: on acpi0 cpu11: Processor \_PR_.P012 (ACPI ID 12) -> APIC ID 22 cpu11: on acpi0 cpu12: Processor \_PR_.P013 (ACPI ID 13) -> APIC ID 1 cpu12: on acpi0 cpu13: Processor \_PR_.P014 (ACPI ID 14) -> APIC ID 3 cpu13: on acpi0 cpu14: Processor \_PR_.P015 (ACPI ID 15) -> APIC ID 5 cpu14: on acpi0 cpu15: Processor \_PR_.P016 (ACPI ID 16) -> APIC ID 7 cpu15: on acpi0 cpu16: Processor \_PR_.P017 (ACPI ID 17) -> APIC ID 9 cpu16: on acpi0 cpu17: Processor \_PR_.P018 (ACPI ID 18) -> APIC ID 11 cpu17: on acpi0 cpu18: Processor \_PR_.P019 (ACPI ID 19) -> APIC ID 13 cpu18: on acpi0 cpu19: Processor \_PR_.P020 (ACPI ID 20) -> APIC ID 15 cpu19: on acpi0 cpu20: Processor \_PR_.P021 (ACPI ID 21) -> APIC ID 17 cpu20: on acpi0 cpu21: Processor \_PR_.P022 (ACPI ID 22) -> APIC ID 19 cpu21: on acpi0 cpu22: Processor \_PR_.P023 (ACPI ID 23) -> APIC ID 21 cpu22: on acpi0 cpu23: Processor \_PR_.P024 (ACPI ID 24) -> APIC ID 23 cpu23: on acpi0 ACPI: Processor \_PR_.P025 (ACPI ID 25) ignored ACPI: Processor \_PR_.P026 (ACPI ID 26) ignored ACPI: Processor \_PR_.P027 (ACPI ID 27) ignored ACPI: Processor \_PR_.P028 (ACPI ID 28) ignored ACPI: Processor \_PR_.P029 (ACPI ID 29) ignored ACPI: Processor \_PR_.P030 (ACPI ID 30) ignored ACPI: Processor \_PR_.P031 (ACPI ID 31) ignored ACPI: Processor \_PR_.P032 (ACPI ID 32) ignored attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) hpet0: t3: irqs 0x00f01000 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 51 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xca1 pcib0: decoding 4 range 0xca4-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xdffff pcib0: decoding 3 range 0xc0000000-0xdfffffff pcib0: decoding 3 range 0xf0000000-0xfed8ffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x22 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0140, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x22 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x22 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x22 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x22 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342d, revid=0x22 domain=0, bus=0, slot=19, func=0 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfec8a000, size 12, enabled pcib0: allocated type 3 (0xfec8a000-0xfec8afff) for rid 10 of pci0:0:19:0 found-> vendor=0x8086, dev=0x342e, revid=0x22 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x22 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x22 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x22 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:26:1 pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:2 pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdf3d6000, size 10, enabled pcib0: allocated type 3 (0xdf3d6000-0xdf3d63ff) for rid 10 of pci0:0:26:7 pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: allocated type 4 (0xb400-0xb41f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[20]: type I/O Port, range 32, base 0x7c00, size 5, enabled pcib0: allocated type 4 (0x7c00-0x7c1f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdf3d4000, size 10, enabled pcib0: allocated type 3 (0xdf3d4000-0xdf3d43ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1b (6750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a20, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0045, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x7880, size 3, enabled pcib0: allocated type 4 (0x7880-0x7887) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x7800, size 2, enabled pcib0: allocated type 4 (0x7800-0x7803) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x7480, size 3, enabled pcib0: allocated type 4 (0x7480-0x7487) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x7400, size 2, enabled pcib0: allocated type 4 (0x7400-0x7403) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x7080, size 4, enabled pcib0: allocated type 4 (0x7080-0x708f) for rid 20 of pci0:0:31:2 map[24]: type I/O Port, range 32, base 0x7000, size 4, enabled pcib0: allocated type 4 (0x7000-0x700f) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xdf3d2000, size 8, enabled pcib0: allocated type 3 (0xdf3d2000-0xdf3d20ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a26, revid=0x00 domain=0, bus=0, slot=31, func=5 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0045, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x6880, size 3, enabled pcib0: allocated type 4 (0x6880-0x6887) for rid 10 of pci0:0:31:5 map[14]: type I/O Port, range 32, base 0x6800, size 2, enabled pcib0: allocated type 4 (0x6800-0x6803) for rid 14 of pci0:0:31:5 map[18]: type I/O Port, range 32, base 0x6480, size 3, enabled pcib0: allocated type 4 (0x6480-0x6487) for rid 18 of pci0:0:31:5 map[1c]: type I/O Port, range 32, base 0x6400, size 2, enabled pcib0: allocated type 4 (0x6400-0x6403) for rid 1c of pci0:0:31:5 map[20]: type I/O Port, range 32, base 0x6080, size 4, enabled pcib0: allocated type 4 (0x6080-0x608f) for rid 20 of pci0:0:31:5 map[24]: type I/O Port, range 32, base 0x6000, size 4, enabled pcib0: allocated type 4 (0x6000-0x600f) for rid 24 of pci0:0:31:5 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0x8000-0x8fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xdf200000-0xdf2fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x8000-0x8fff pcib1: memory decode 0xdf200000-0xdf2fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1000, dev=0x0072, revid=0x03 domain=0, bus=1, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0x8000, size 8, enabled pcib1: allocated I/O port range (0x8000-0x80ff) for rid 10 of pci0:1:0:0 map[14]: type Memory, range 64, base 0xdf23c000, size 14, enabled pcib1: allocated memory range (0xdf23c000-0xdf23ffff) for rid 14 of pci0:1:0:0 map[1c]: type Memory, range 64, base 0xdf240000, size 18, enabled pcib1: allocated memory range (0xdf240000-0xdf27ffff) for rid 1c of pci0:1:0:0 pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 28 mps0: port 0x8000-0x80ff mem 0xdf23c000-0xdf23ffff,0xdf240000-0xdf27ffff irq 28 at device 0.0 on pci1 mps0: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps0: IOCCapabilities: 185c mps0: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 mps0: using IRQ 256 for MSI-X pcib2: at device 3.0 on pci0 pcib0: allocated type 4 (0x9000-0x9fff) for rid 1c of pcib2 pcib0: allocated type 3 (0xdee00000-0xdeffffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: prefetched decode 0xdee00000-0xdeffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10fb, revid=0x01 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 64 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xdef80000, size 19, enabled pcib2: allocated prefetch range (0xdef80000-0xdeffffff) for rid 10 of pci0:2:0:0 map[18]: type I/O Port, range 32, base 0x9c00, size 5, enabled pcib2: allocated I/O port range (0x9c00-0x9c1f) for rid 18 of pci0:2:0:0 map[20]: type Prefetchable Memory, range 64, base 0xdef7c000, size 14, enabled pcib2: allocated prefetch range (0xdef7c000-0xdef7ffff) for rid 20 of pci0:2:0:0 pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 24 found-> vendor=0x8086, dev=0x10fb, revid=0x01 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 64 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xdee80000, size 19, enabled pcib2: allocated prefetch range (0xdee80000-0xdeefffff) for rid 10 of pci0:2:0:1 map[18]: type I/O Port, range 32, base 0x9880, size 5, enabled pcib2: allocated I/O port range (0x9880-0x989f) for rid 18 of pci0:2:0:1 map[20]: type Prefetchable Memory, range 64, base 0xdee7c000, size 14, enabled pcib2: allocated prefetch range (0xdee7c000-0xdee7ffff) for rid 20 of pci0:2:0:1 pcib2: matched entry for 2.0.INTB pcib2: slot 0 INTB hardwired to IRQ 34 ix0: port 0x9c00-0x9c1f mem 0xdef80000-0xdeffffff,0xdef7c000-0xdef7ffff irq 24 at device 0.0 on pci2 ix0: attempting to allocate 9 MSI-X vectors (64 supported) msi: routing MSI-X IRQ 257 to local APIC 0 vector 53 msi: routing MSI-X IRQ 258 to local APIC 0 vector 54 msi: routing MSI-X IRQ 259 to local APIC 0 vector 55 msi: routing MSI-X IRQ 260 to local APIC 0 vector 56 msi: routing MSI-X IRQ 261 to local APIC 0 vector 57 msi: routing MSI-X IRQ 262 to local APIC 0 vector 58 msi: routing MSI-X IRQ 263 to local APIC 0 vector 59 msi: routing MSI-X IRQ 264 to local APIC 0 vector 60 msi: routing MSI-X IRQ 265 to local APIC 0 vector 61 ix0: using IRQs 257-265 for MSI-X ix0: Using MSIX interrupts with 9 vectors ix0: bpf attached ix0: Ethernet address: 04:7d:7b:a5:87:32 ix0: PCI Express Bus: Speed 5.0GT/s Width x4 ix1: port 0x9880-0x989f mem 0xdee80000-0xdeefffff,0xdee7c000-0xdee7ffff irq 34 at device 0.1 on pci2 ix1: attempting to allocate 9 MSI-X vectors (64 supported) msi: routing MSI-X IRQ 266 to local APIC 0 vector 62 msi: routing MSI-X IRQ 267 to local APIC 0 vector 63 msi: routing MSI-X IRQ 268 to local APIC 0 vector 64 msi: routing MSI-X IRQ 269 to local APIC 0 vector 65 msi: routing MSI-X IRQ 270 to local APIC 0 vector 66 msi: routing MSI-X IRQ 271 to local APIC 0 vector 67 msi: routing MSI-X IRQ 272 to local APIC 0 vector 68 msi: routing MSI-X IRQ 273 to local APIC 0 vector 69 msi: routing MSI-X IRQ 274 to local APIC 0 vector 70 ix1: using IRQs 266-274 for MSI-X ix1: Using MSIX interrupts with 9 vectors ix1: bpf attached ix1: Ethernet address: 04:7d:7b:a5:87:33 ix1: PCI Express Bus: Speed 5.0GT/s Width x4 pcib3: at device 7.0 on pci0 pcib0: allocated type 4 (0xa000-0xafff) for rid 1c of pcib3 pcib0: allocated type 3 (0xdf400000-0xdf4fffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xa000-0xafff pcib3: memory decode 0xdf400000-0xdf4fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1000, dev=0x0064, revid=0x02 domain=0, bus=3, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0xa000, size 8, enabled pcib3: allocated I/O port range (0xa000-0xa0ff) for rid 10 of pci0:3:0:0 map[14]: type Memory, range 64, base 0xdf43c000, size 14, enabled pcib3: allocated memory range (0xdf43c000-0xdf43ffff) for rid 14 of pci0:3:0:0 map[1c]: type Memory, range 64, base 0xdf440000, size 18, enabled pcib3: allocated memory range (0xdf440000-0xdf47ffff) for rid 1c of pci0:3:0:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 30 mps1: port 0xa000-0xa0ff mem 0xdf43c000-0xdf43ffff,0xdf440000-0xdf47ffff irq 30 at device 0.0 on pci3 mps1: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps1: IOCCapabilities: 1285c mps1: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 275 to local APIC 0 vector 71 mps1: using IRQ 275 for MSI-X pcib4: at device 9.0 on pci0 pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib4 pcib0: allocated type 3 (0xdf500000-0xdf5fffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xdf500000-0xdf5fffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1000, dev=0x0064, revid=0x02 domain=0, bus=4, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib4: allocated I/O port range (0xc000-0xc0ff) for rid 10 of pci0:4:0:0 map[14]: type Memory, range 64, base 0xdf53c000, size 14, enabled pcib4: allocated memory range (0xdf53c000-0xdf53ffff) for rid 14 of pci0:4:0:0 map[1c]: type Memory, range 64, base 0xdf540000, size 18, enabled pcib4: allocated memory range (0xdf540000-0xdf57ffff) for rid 1c of pci0:4:0:0 pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 32 mps2: port 0xc000-0xc0ff mem 0xdf53c000-0xdf53ffff,0xdf540000-0xdf57ffff irq 32 at device 0.0 on pci4 mps2: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps2: IOCCapabilities: 1285c mps2: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 276 to local APIC 0 vector 72 mps2: using IRQ 276 for MSI-X pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 73 uhci0: LegSup = 0x2400 usbus0 on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xb880-0xb89f irq 22 at device 26.1 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 74 uhci1: LegSup = 0x2400 usbus1 on uhci1 usbus1: bpf attached uhci1: usbpf: Attached uhci2: port 0xb800-0xb81f irq 21 at device 26.2 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 75 uhci2: LegSup = 0x2400 usbus2 on uhci2 usbus2: bpf attached uhci2: usbpf: Attached ehci0: mem 0xdf3d6000-0xdf3d63ff irq 20 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 usbus3: bpf attached ehci0: usbpf: Attached pcib5: irq 17 at device 28.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib5 pcib0: allocated type 3 (0xdf600000-0xdf6fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xdf600000-0xdf6fffff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x10c9, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 10 messages in map 0x1c map[10]: type Memory, range 32, base 0xdf6e0000, size 17, enabled pcib5: allocated memory range (0xdf6e0000-0xdf6fffff) for rid 10 of pci0:5:0:0 map[14]: type Memory, range 32, base 0xdf6c0000, size 17, enabled pcib5: allocated memory range (0xdf6c0000-0xdf6dffff) for rid 14 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib5: allocated I/O port range (0xdc00-0xdc1f) for rid 18 of pci0:5:0:0 map[1c]: type Memory, range 32, base 0xdf69c000, size 14, enabled pcib5: allocated memory range (0xdf69c000-0xdf69ffff) for rid 1c of pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10c9, revid=0x01 domain=0, bus=5, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 10 messages in map 0x1c map[10]: type Memory, range 32, base 0xdf660000, size 17, enabled pcib5: allocated memory range (0xdf660000-0xdf67ffff) for rid 10 of pci0:5:0:1 map[14]: type Memory, range 32, base 0xdf640000, size 17, enabled pcib5: allocated memory range (0xdf640000-0xdf65ffff) for rid 14 of pci0:5:0:1 map[18]: type I/O Port, range 32, base 0xd880, size 5, enabled pcib5: allocated I/O port range (0xd880-0xd89f) for rid 18 of pci0:5:0:1 map[1c]: type Memory, range 32, base 0xdf61c000, size 14, enabled pcib5: allocated memory range (0xdf61c000-0xdf61ffff) for rid 1c of pci0:5:0:1 pcib5: matched entry for 5.0.INTB pcib5: slot 0 INTB hardwired to IRQ 17 igb0: port 0xdc00-0xdc1f mem 0xdf6e0000-0xdf6fffff,0xdf6c0000-0xdf6dffff,0xdf69c000-0xdf69ffff irq 16 at device 0.0 on pci5 igb0: attempting to allocate 9 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 277 to local APIC 0 vector 76 msi: routing MSI-X IRQ 278 to local APIC 0 vector 77 msi: routing MSI-X IRQ 279 to local APIC 0 vector 78 msi: routing MSI-X IRQ 280 to local APIC 0 vector 79 msi: routing MSI-X IRQ 281 to local APIC 0 vector 80 msi: routing MSI-X IRQ 282 to local APIC 0 vector 81 msi: routing MSI-X IRQ 283 to local APIC 0 vector 82 msi: routing MSI-X IRQ 284 to local APIC 0 vector 83 msi: routing MSI-X IRQ 285 to local APIC 0 vector 84 igb0: using IRQs 277-285 for MSI-X igb0: Using MSIX interrupts with 9 vectors igb0: bpf attached igb0: Ethernet address: 04:7d:7b:a5:c5:c2 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0xd880-0xd89f mem 0xdf660000-0xdf67ffff,0xdf640000-0xdf65ffff,0xdf61c000-0xdf61ffff irq 17 at device 0.1 on pci5 igb1: attempting to allocate 9 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 286 to local APIC 0 vector 85 msi: routing MSI-X IRQ 287 to local APIC 0 vector 86 msi: routing MSI-X IRQ 288 to local APIC 0 vector 87 msi: routing MSI-X IRQ 289 to local APIC 0 vector 88 msi: routing MSI-X IRQ 290 to local APIC 0 vector 89 msi: routing MSI-X IRQ 291 to local APIC 0 vector 90 msi: routing MSI-X IRQ 292 to local APIC 0 vector 91 msi: routing MSI-X IRQ 293 to local APIC 0 vector 92 msi: routing MSI-X IRQ 294 to local APIC 0 vector 93 igb1: using IRQs 286-294 for MSI-X igb1: Using MSIX interrupts with 9 vectors igb1: bpf attached igb1: Ethernet address: 04:7d:7b:a5:c5:c3 igb1: Bound queue 0 to cpu 8 igb1: Bound queue 1 to cpu 9 igb1: Bound queue 2 to cpu 10 igb1: Bound queue 3 to cpu 11 igb1: Bound queue 4 to cpu 12 igb1: Bound queue 5 to cpu 13 igb1: Bound queue 6 to cpu 14 igb1: Bound queue 7 to cpu 15 uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: LegSup = 0x2400 usbus4 on uhci3 usbus4: bpf attached uhci3: usbpf: Attached uhci4: port 0xb400-0xb41f irq 22 at device 29.1 on pci0 uhci4: LegSup = 0x2400 usbus5 on uhci4 usbus5: bpf attached uhci4: usbpf: Attached uhci5: port 0x7c00-0x7c1f irq 21 at device 29.2 on pci0 uhci5: LegSup = 0x2400 usbus6 on uhci5 usbus6: bpf attached uhci5: usbpf: Attached ehci1: mem 0xdf3d4000-0xdf3d43ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 usbus7: bpf attached ehci1: usbpf: Attached pcib6: at device 30.0 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib6 pcib0: allocated type 3 (0xdf700000-0xdfffffff) for rid 20 of pcib6 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xe000-0xefff pcib6: memory decode 0xdf700000-0xdfffffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci6: on pcib6 pci6: domain=0, physical bus=6 found-> vendor=0x1a03, dev=0x2000, revid=0x10 domain=0, bus=6, slot=11, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf800000, size 23, enabled pcib6: allocated memory range (0xdf800000-0xdfffffff) for rid 10 of pci0:6:11:0 map[14]: type Memory, range 32, base 0xdf7e0000, size 17, enabled pcib6: allocated memory range (0xdf7e0000-0xdf7fffff) for rid 14 of pci0:6:11:0 map[18]: type I/O Port, range 32, base 0xec00, size 7, enabled pcib6: allocated I/O port range (0xec00-0xec7f) for rid 18 of pci0:6:11:0 pcib6: matched entry for 6.11.INTA pcib6: slot 11 INTA hardwired to IRQ 16 vgapci0: port 0xec00-0xec7f mem 0xdf800000-0xdfffffff,0xdf7e0000-0xdf7fffff irq 16 at device 11.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x7880-0x7887,0x7800-0x7803,0x7480-0x7487,0x7400-0x7403,0x7080-0x708f,0x7000-0x700f irq 18 at device 31.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 94 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ichsmb0: port 0x400-0x41f mem 0xdf3d2000-0xdf3d20ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 atapci1: port 0x6880-0x6887,0x6800-0x6803,0x6480-0x6487,0x6400-0x6403,0x6080-0x608f,0x6000-0x600f irq 19 at device 31.5 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 95 ata4: at channel 0 on atapci1 ata5: at channel 1 on atapci1 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 96 uart0: fast interrupt uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 97 uart1: fast interrupt qpi0: on motherboard pcib7: pcibus 255 on qpi0 pci255: on pcib7 pci255: domain=0, physical bus=255 found-> vendor=0x8086, dev=0x2c70, revid=0x02 domain=0, bus=255, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d81, revid=0x02 domain=0, bus=255, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d90, revid=0x02 domain=0, bus=255, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d91, revid=0x02 domain=0, bus=255, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d92, revid=0x02 domain=0, bus=255, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d93, revid=0x02 domain=0, bus=255, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d94, revid=0x02 domain=0, bus=255, slot=2, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d95, revid=0x02 domain=0, bus=255, slot=2, func=5 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d98, revid=0x02 domain=0, bus=255, slot=3, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d99, revid=0x02 domain=0, bus=255, slot=3, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9a, revid=0x02 domain=0, bus=255, slot=3, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9c, revid=0x02 domain=0, bus=255, slot=3, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da0, revid=0x02 domain=0, bus=255, slot=4, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da1, revid=0x02 domain=0, bus=255, slot=4, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da2, revid=0x02 domain=0, bus=255, slot=4, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da3, revid=0x02 domain=0, bus=255, slot=4, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da8, revid=0x02 domain=0, bus=255, slot=5, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da9, revid=0x02 domain=0, bus=255, slot=5, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2daa, revid=0x02 domain=0, bus=255, slot=5, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2dab, revid=0x02 domain=0, bus=255, slot=5, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db0, revid=0x02 domain=0, bus=255, slot=6, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db1, revid=0x02 domain=0, bus=255, slot=6, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db2, revid=0x02 domain=0, bus=255, slot=6, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db3, revid=0x02 domain=0, bus=255, slot=6, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib8: pcibus 254 on qpi0 pci254: on pcib8 pci254: domain=0, physical bus=254 found-> vendor=0x8086, dev=0x2c70, revid=0x02 domain=0, bus=254, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d81, revid=0x02 domain=0, bus=254, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d90, revid=0x02 domain=0, bus=254, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d91, revid=0x02 domain=0, bus=254, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d92, revid=0x02 domain=0, bus=254, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d93, revid=0x02 domain=0, bus=254, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d94, revid=0x02 domain=0, bus=254, slot=2, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d95, revid=0x02 domain=0, bus=254, slot=2, func=5 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d98, revid=0x02 domain=0, bus=254, slot=3, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d99, revid=0x02 domain=0, bus=254, slot=3, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9a, revid=0x02 domain=0, bus=254, slot=3, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9c, revid=0x02 domain=0, bus=254, slot=3, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da0, revid=0x02 domain=0, bus=254, slot=4, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da1, revid=0x02 domain=0, bus=254, slot=4, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da2, revid=0x02 domain=0, bus=254, slot=4, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da3, revid=0x02 domain=0, bus=254, slot=4, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da8, revid=0x02 domain=0, bus=254, slot=5, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da9, revid=0x02 domain=0, bus=254, slot=5, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2daa, revid=0x02 domain=0, bus=254, slot=5, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2dab, revid=0x02 domain=0, bus=254, slot=5, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db0, revid=0x02 domain=0, bus=254, slot=6, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db1, revid=0x02 domain=0, bus=254, slot=6, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db2, revid=0x02 domain=0, bus=254, slot=6, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db3, revid=0x02 domain=0, bus=254, slot=6, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi0: wakeup code va 0xffffff945aa36000 pa 0x90000 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 4 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 4 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 4 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 4 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 4 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 4 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 4 of orm0 isa_probe_children: disabling PnP devices ichwd0 on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 pcib0: allocated type 3 (0xfed1f410-0xfed1f413) for rid 0 of isab0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices ichwd0 at port 0x830-0x837,0x860-0x87f on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 pcib0: allocated type 3 (0xfed1f410-0xfed1f413) for rid 0 of isab0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcd7ff,0xcd800-0xce7ff,0xce800-0xcf7ff on isa0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 pcib0: allocated type 4 (0x3d0-0x3db) for rid 0 of vga0 pcib0: allocated type 3 (0xb8000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbdc0: at port 0x60,0x64 on isa0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 98 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Setting TjMax=96 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=96 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Setting TjMax=96 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Setting TjMax=96 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 coretemp4: Setting TjMax=96 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 coretemp5: Setting TjMax=96 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 coretemp6: Setting TjMax=96 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 coretemp7: Setting TjMax=96 est7: on cpu7 p4tcc7: on cpu7 coretemp8: on cpu8 coretemp8: Setting TjMax=96 est8: on cpu8 p4tcc8: on cpu8 coretemp9: on cpu9 coretemp9: Setting TjMax=96 est9: on cpu9 p4tcc9: on cpu9 coretemp10: on cpu10 coretemp10: Setting TjMax=96 est10: on cpu10 p4tcc10: on cpu10 coretemp11: on cpu11 coretemp11: Setting TjMax=96 est11: on cpu11 p4tcc11: on cpu11 coretemp12: on cpu12 coretemp12: Setting TjMax=96 est12: on cpu12 p4tcc12: on cpu12 coretemp13: on cpu13 coretemp13: Setting TjMax=96 est13: on cpu13 p4tcc13: on cpu13 coretemp14: on cpu14 coretemp14: Setting TjMax=96 est14: on cpu14 p4tcc14: on cpu14 coretemp15: on cpu15 coretemp15: Setting TjMax=96 est15: on cpu15 p4tcc15: on cpu15 coretemp16: on cpu16 coretemp16: Setting TjMax=96 est16: on cpu16 p4tcc16: on cpu16 coretemp17: on cpu17 coretemp17: Setting TjMax=96 est17: on cpu17 p4tcc17: on cpu17 coretemp18: on cpu18 coretemp18: Setting TjMax=96 est18: on cpu18 p4tcc18: on cpu18 coretemp19: on cpu19 coretemp19: Setting TjMax=96 est19: on cpu19 p4tcc19: on cpu19 coretemp20: on cpu20 coretemp20: Setting TjMax=96 est20: on cpu20 p4tcc20: on cpu20 coretemp21: on cpu21 coretemp21: Setting TjMax=96 est21: on cpu21 p4tcc21: on cpu21 coretemp22: on cpu22 coretemp22: Setting TjMax=96 est22: on cpu22 p4tcc22: on cpu22 coretemp23: on cpu23 coretemp23: Setting TjMax=96 est23: on cpu23 p4tcc23: on cpu23 Device configuration finished. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) lapic: Divisor 2, Frequency 66670376 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining crypto: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled ipfw0: bpf attached lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ata2: SATA reset: ports status=0x00 ata2: p0: SATA connect timeout status=00000000 ata2: p1: SATA connect timeout status=00000000 ipmi0: IPMI device rev. 1, firmware rev. 1.03, version 2.0 ata3: SATA reset: ports status=0x00 ata3: p0: SATA connect timeout status=00000000 ata3: p1: SATA connect timeout status=00000000 ipmi0: Number of channels 2 ipmi0: Attached watchdog uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ata4: SATA reset: ports status=0x00 ata4: p0: SATA connect timeout status=00000000 ugen3.2: at usbus3 uhub8: on usbus3 ata5: SATA reset: ports status=0x00 ata5: p0: SATA connect timeout status=00000000 (probe0:mps0:0:11:0): Down reving Protocol Version from 4 to 0? (probe1:mps0:0:12:0): Down reving Protocol Version from 4 to 0? (probe2:mps0:0:13:0): Down reving Protocol Version from 4 to 0? (probe3:mps0:0:14:0): Down reving Protocol Version from 4 to 0? uhub8: 3 ports with 3 removable, self powered (probe4:mps0:0:15:0): Down reving Protocol Version from 4 to 0? (probe5:mps0:0:16:0): Down reving Protocol Version from 4 to 0? failure at /usr/src-9-stable/sys/dev/mps/mps_sas_lsi.c:667/mpssas_add_device()! Could not get ID for device with handle 0x0010 mpssas_fw_work: failed to add device with handle 0x10 (probe6:mps2:0:16:0): Down reving Protocol Version from 4 to 0? (probe7:mps1:0:16:0): Down reving Protocol Version from 4 to 0? (probe8:mps2:0:17:0): Down reving Protocol Version from 4 to 0? (probe9:mps1:0:17:0): Down reving Protocol Version from 4 to 0? (probe10:mps2:0:18:0): Down reving Protocol Version from 4 to 0? (probe11:mps1:0:18:0): Down reving Protocol Version from 4 to 0? (probe12:mps2:0:19:0): Down reving Protocol Version from 4 to 0? (probe13:mps1:0:19:0): Down reving Protocol Version from 4 to 0? (probe14:mps2:0:20:0): Down reving Protocol Version from 4 to 0? (probe15:mps1:0:20:0): Down reving Protocol Version from 4 to 0? (probe16:mps2:0:21:0): Down reving Protocol Version from 4 to 0? (probe17:mps1:0:21:0): Down reving Protocol Version from 4 to 0? (probe18:mps2:0:22:0): Down reving Protocol Version from 4 to 0? (probe19:mps1:0:22:0): Down reving Protocol Version from 4 to 0? (probe20:mps2:0:23:0): Down reving Protocol Version from 4 to 0? (probe21:mps1:0:23:0): Down reving Protocol Version from 4 to 0? (probe22:mps2:0:24:0): Down reving Protocol Version from 4 to 0? (probe23:mps1:0:24:0): Down reving Protocol Version from 4 to 0? (probe24:mps2:0:25:0): Down reving Protocol Version from 4 to 0? (probe25:mps1:0:25:0): Down reving Protocol Version from 4 to 0? (probe26:mps2:0:26:0): Down reving Protocol Version from 4 to 0? (probe27:mps1:0:26:0): Down reving Protocol Version from 4 to 0? (probe28:mps2:0:27:0): Down reving Protocol Version from 4 to 0? (probe29:mps1:0:27:0): Down reving Protocol Version from 4 to 0? (probe30:mps2:0:28:0): Down reving Protocol Version from 4 to 0? (probe31:mps1:0:28:0): Down reving Protocol Version from 4 to 0? (probe32:mps2:0:29:0): Down reving Protocol Version from 4 to 0? (probe33:mps1:0:29:0): Down reving Protocol Version from 4 to 0? (probe34:mps2:0:30:0): Down reving Protocol Version from 4 to 0? (probe35:mps1:0:30:0): Down reving Protocol Version from 4 to 0? (probe36:mps2:0:31:0): Down reving Protocol Version from 4 to 0? (probe37:mps1:0:31:0): Down reving Protocol Version from 4 to 0? (probe38:mps2:0:32:0): Down reving Protocol Version from 4 to 0? (probe39:mps1:0:32:0): Down reving Protocol Version from 4 to 0? (probe40:mps2:0:33:0): Down reving Protocol Version from 4 to 0? Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff804ce7f9 stack pointer = 0x28:0xffffff945a7fe9e0 frame pointer = 0x28:0xffffff945a7fe9f0 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 = 15 (usbus6) [ thread pid 15 tid 100177 ] Stopped at usbd_get_hr_func+0x29: movq 0x4f0(%rdx),%rax db> bt Tracing pid 15 tid 100177 td 0xfffffe000fb9e490 usbd_get_hr_func() at usbd_get_hr_func+0x29/frame 0xffffff945a7fe9f0 usbd_do_request_flags() at usbd_do_request_flags+0x18e/frame 0xffffff945a7feaa0 usbd_req_get_port_status() at usbd_req_get_port_status+0x43/frame 0xffffff945a7fead0 uhub_read_port_status() at uhub_read_port_status+0x2d/frame 0xffffff945a7feb10 uhub_explore() at uhub_explore+0xc5/frame 0xffffff945a7feb80 usb_bus_explore() at usb_bus_explore+0xcb/frame 0xffffff945a7febb0 usb_process() at usb_process+0xd3/frame 0xffffff945a7febe0 fork_exit() at fork_exit+0x11f/frame 0xffffff945a7fec30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff945a7fec30 --- trap 0, rip = 0, rsp = 0xffffff945a7fecf0, rbp = 0 --- I think usbd_get_hr_func() is just an innocent bystander here, although it's odd how consistent the crash is. A verbose boot from 9.2, where it works, is available on request. From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 18:59:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AF9D465; Wed, 29 Jan 2014 18:59:27 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0189C19CA; Wed, 29 Jan 2014 18:59:26 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id F0EFA17FC8D; Wed, 29 Jan 2014 19:59:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id E72EF8F81BD; Wed, 29 Jan 2014 20:00:10 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdl8Y78qmjWZ; Wed, 29 Jan 2014 20:00:10 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 1517E8F81AD; Wed, 29 Jan 2014 20:00:10 +0100 (CET) Message-ID: <52E94FC2.1010901@bitfrost.no> Date: Wed, 29 Jan 2014 20:00:18 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: stable/9 mps(4) rev 254938 == BOOM! References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> In-Reply-To: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org, ken@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:59:27 -0000 On 01/29/14 19:45, Garrett Wollman wrote: > I've been trying to puzzle out why the USB stack hits a GPF during > boot on 9-stable on one of my machines (which runs 9.2 just fine), and > by trial and error I've found that it is actually caused by r254938, > which is a mega-MFC of mps(4) driver changes, even though the fault > always occurs at the same place in a harmless USB subroutine. Details > below; config available on request. > > -GAWollman Hi, To me this sounds like someone is writing outside their assigned area. options DEBUG_REDZONE Maybe some change that should have been MFC'ed did not get MFC'ed. I think you can copy the mps driver from -current just keeping the following deltas intact: - - if (curthread->td_no_sleeping != 0) + + if(curthread->td_pflags & TDP_NOSLEEPING) sleep_flags = NO_SLEEP; --HPS From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 19:57:19 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41A6AF3D for ; Wed, 29 Jan 2014 19:57:19 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B67DF1FA9 for ; Wed, 29 Jan 2014 19:57:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0TJvA10005488 for ; Wed, 29 Jan 2014 23:57:10 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Wed, 29 Jan 2014 23:57:10 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Subject: upgrade_checks fails on stable/10 in parallel builds? Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Wed, 29 Jan 2014 23:57:10 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 19:57:19 -0000 Colleagues, after upgrading my builder to stable/10 I'm getting consistent errors like --- upgrade_checks --- A failure has been detected in another branch of the parallel make make[1]: stopped in /FreeBSD/pristine/src.9.2 *** [upgrade_checks] Error code 2 make: stopped in /FreeBSD/pristine/src.9.2 1 error make: stopped in /FreeBSD/pristine/src.9.2 in case of using -j when invoking buildworld make -DNO_CLEAN upgrade_checks (without -j) rebuilds (f)make fine, and then parallel buildworld seems to work fine. Any thoughts? I'd tried to look at Makefiles, but lost in the middle ;) Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 21:37:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C786B21F; Wed, 29 Jan 2014 21:37:18 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 803CF1826; Wed, 29 Jan 2014 21:37:18 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TLbDKS006717; Wed, 29 Jan 2014 16:37:13 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s0TLbD5G006716; Wed, 29 Jan 2014 16:37:13 -0500 (EST) (envelope-from wollman) Date: Wed, 29 Jan 2014 16:37:13 -0500 (EST) Message-Id: <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> From: wollman@csail.mit.edu To: hps@bitfrost.no Subject: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <52E94FC2.1010901@bitfrost.no> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 16:37:13 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-scsi@freebsd.org, ken@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 21:37:18 -0000 In article <52E94FC2.1010901@bitfrost.no>, hps@bitfrost.no writes: >To me this sounds like someone is writing outside their assigned area. > >options DEBUG_REDZONE hselasky@ nails it! The mps(4) changes in stable/9 r254938 reliably cause a GPF during boot in non-debugging kernels, but adding DEBUG_REDZONE is sufficient to prevent the fault. Whichever heap allocation is being overrun does *not* ever get freed: there are no redzone messages on the console. (It also boots much faster with the new probing code, which is certainly a plus for debugging.) I can confirm that the tip of stable/9 (r261256) also works with DEBUG_REDZONE and fails without it. Only trouble is that I need to do performance testing, which DEBUG_REDZONE is not exactly going to help with. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 21:54:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B62D4932 for ; Wed, 29 Jan 2014 21:54:35 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36E0E19A0 for ; Wed, 29 Jan 2014 21:54:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0TLsW9n008121 for ; Thu, 30 Jan 2014 01:54:32 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 01:54:32 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org Subject: Re: upgrade_checks fails on stable/10 in parallel builds? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 01:54:32 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 21:54:35 -0000 On Wed, 29 Jan 2014, Dmitry Morozovsky wrote: > make -DNO_CLEAN upgrade_checks (without -j) rebuilds (f)make fine, and then > parallel buildworld seems to work fine. Well, I spoken too soon: on second phase, the buildworld chokes on libstdc++. Moreover, subsequent make goes further, not deterministic on failing. Will try to test more thoughly tomorrow... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 22:16:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48AF654D; Wed, 29 Jan 2014 22:16:45 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09AE71B41; Wed, 29 Jan 2014 22:16:43 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id s0TMFEhD048604; Wed, 29 Jan 2014 15:15:14 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id s0TMFEMR048603; Wed, 29 Jan 2014 15:15:14 -0700 (MST) (envelope-from ken) Date: Wed, 29 Jan 2014 15:15:14 -0700 From: "Kenneth D. Merry" To: wollman@csail.mit.edu Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> User-Agent: Mutt/1.4.2i Cc: hps@bitfrost.no, freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 22:16:45 -0000 On Wed, Jan 29, 2014 at 16:37:13 -0500, wollman@csail.mit.edu wrote: > In article <52E94FC2.1010901@bitfrost.no>, hps@bitfrost.no writes: > >To me this sounds like someone is writing outside their assigned area. > > > >options DEBUG_REDZONE > > hselasky@ nails it! The mps(4) changes in stable/9 r254938 reliably > cause a GPF during boot in non-debugging kernels, but adding > DEBUG_REDZONE is sufficient to prevent the fault. Whichever heap > allocation is being overrun does *not* ever get freed: there are no > redzone messages on the console. (It also boots much faster with the > new probing code, which is certainly a plus for debugging.) > > I can confirm that the tip of stable/9 (r261256) also works with > DEBUG_REDZONE and fails without it. Only trouble is that I need to do > performance testing, which DEBUG_REDZONE is not exactly going to help > with. Hmm. What does vmstat -m show for the mps malloc bucket? Are you booting off of the controller? If not, could you try building mps as a module and unloading it? Perhaps the memory would get freed when the module is unloaded and the redzone code would show where the problem is. How many drives do you have in the system, and how many of them are SAS vs. SATA? I haven't seen this problem, but it may be that we've gotten lucky or don't have the particular set of factors that you have. We have tested with more than 200 drives connected, but they were all SAS. I'll take a look and see if I can see anything that looks suspicious. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 22:47:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 782B05F3; Wed, 29 Jan 2014 22:47:54 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AE671EDB; Wed, 29 Jan 2014 22:47:54 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TMlq0a049321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 17:47:53 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0TMlqfF049318; Wed, 29 Jan 2014 17:47:52 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.34072.966571.408714@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 17:47:52 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 17:47:53 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 22:47:54 -0000 < said: > Hmm. What does vmstat -m show for the mps malloc bucket? mps 237 1996K - 1005 512,1024,2048 One of these is probably getting corrupted: USBdev 44 23K - 44 512,1024 USB 75 154K - 78 512,4096 (The 512 and 1024 would ultimately come out of the same page for either malloc type.) > Are you booting off of the controller? Yes, all the storage controllers in this machine are mps. (There's SATA on the motherboard but it's not wired to anything.) > How many drives do you have in the system, and how many of them are SAS vs. > SATA? 98 drives, of which 92 are dual-pathed, all SAS, for a total of 198 da(4) instances. Thanks for taking a look... I'm happy to try adding some additional debugging if it would be helpful. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Wed Jan 29 23:49:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 103DFDFB; Wed, 29 Jan 2014 23:49:30 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA9B1159B; Wed, 29 Jan 2014 23:49:29 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.7/8.14.7) with ESMTP id s0TNnLfu024480 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Jan 2014 17:49:21 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52E99381.5050803@tundraware.com> Date: Wed, 29 Jan 2014 17:49:21 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, FreeBSD Hardware Mailing List Subject: Need Help With MCA Code References: <52E73717.3000503@tundraware.com> In-Reply-To: <52E73717.3000503@tundraware.com> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 29 Jan 2014 17:49:21 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s0TNnLfu024480 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 23:49:30 -0000 Resending in hopes that people on one of the other lists will have some insight here: On 01/27/2014 10:50 PM, Tim Daneliuk wrote: > I am running 9.2 stable i386 r261207. As noted earlier: > >> I just replaced mobo/CPU on FBSD server (Gigabyte Z-87-D3HP with >> an Intel i3-4130). I am not overclocking ... but I continue to see this sort of thing: > >> MCA: CPU 0 COR (1) internal parity error > > Dmesg shows: > >> MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 0 >> MCA: CPU 0 COR (1) internal parity error >> MCA: Bank 0, Status 0x90000040000f0005 >> MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000_ > > I've swapped CPUs (i5). I've fiddled with an endless supply of > mobo settings. I've switched power supplies. I've moved mem > sticks around .... No joy. > > So, I dug through the sources and found this: > > > > mca_log(const struct mca_record *rec) > { > uint16_t mca_error; > > printf("MCA: Bank %d, Status 0x%016llx\n", rec->mr_bank, > (long long)rec->mr_status); > printf("MCA: Global Cap 0x%016llx, Status 0x%016llx\n", > (long long)rec->mr_mcg_cap, (long long)rec->mr_mcg_status); > printf("MCA: Vendor \"%s\", ID 0x%x, APIC ID %d\n", cpu_vendor, > rec->mr_cpu_id, rec->mr_apic_id); > printf("MCA: CPU %d ", rec->mr_cpu); > if (rec->mr_status & MC_STATUS_UC) > printf("UNCOR "); > else { > printf("COR "); > if (rec->mr_mcg_cap & MCG_CAP_CMCI_P) > printf("(%lld) ", ((long long)rec->mr_status & > MC_STATUS_COR_COUNT) >> 38); > } > > > It looks like the trailing else clause is kicking out the error but I am > unclear what the error means, beyond the fact that it appears to be a parity > error somewhere within the CPU's internal memory (cache?). Is this error > getting corrected? Is this benign, Should I get a different mobo? > > Um .... Haaaaalp :) I have now tried different motherboards, CPUs, memory, and power supplies and this error is still showing up now and then. This points strongly to either FreeBSD bogus reporting, or these errors being benign. It's hard to believe that the exact same error might occur with completely different hardware ... unless it's being caused by the case. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 00:05:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A98F77A; Thu, 30 Jan 2014 00:05:51 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04BC917EE; Thu, 30 Jan 2014 00:05:50 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0U05n0R049891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 19:05:49 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0U05nVd049888; Wed, 29 Jan 2014 19:05:49 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.38749.179621.454579@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 19:05:49 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 19:05:49 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 00:05:51 -0000 < said: > Are you booting off of the controller? If not, could you try building mps > as a module and unloading it? Perhaps the memory would get freed when the > module is unloaded and the redzone code would show where the problem is. I built a memory-stick image and tried this. No redzone messages, but the driver leaks 18 allocations (142336 bytes). -GAWollman From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 00:44:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B587C55; Thu, 30 Jan 2014 00:44:18 +0000 (UTC) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B92F01D9F; Thu, 30 Jan 2014 00:44:17 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id h14so1279860eaj.35 for ; Wed, 29 Jan 2014 16:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=OPjS0nzmwIu7+wAedNB6S8QMubkyH00jRh3NT3Qd7aA=; b=0vZYroMJMd/5QiS5KnZBVHm09HPDtKACcbb/pbPn043Q1TILZFrFUI+A1+UydZgsH8 L1mnEjA27St9xHT8ZleKm5oRgL8BREH92vCVF6hJcpM8sKMl4TH3RgmlUANKkkT++v7d guJRWBtXaVlrflFcr0QskYz/lapYGpBigHMu/i5zUMipkfvV7Fp+qEJqsD2Pn6c9HMFL kPWXfkq+Q7Zto1s3SQumu5dfQ+z0bfVLJMHZHJReopRUwYMTrcRS/jtF/7WGs1yS6x+Y 5gPhr7vEdqYn8607qBoVa8vEiP4m1mqrSOLOF2Nl7tlp5H8o3eXaTylz9ygzWk+Ngt5e 0CGw== X-Received: by 10.14.6.5 with SMTP id 5mr7315287eem.51.1391042655387; Wed, 29 Jan 2014 16:44:15 -0800 (PST) Received: from [10.29.77.47] (dab-ell1-h-1-2.dab.02.net. [82.132.236.222]) by mx.google.com with ESMTPSA id z49sm15460468eeo.10.2014.01.29.16.44.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Jan 2014 16:44:14 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <52B72D09-62E0-4D36-9D56-F45D4D223382@gmail.com> X-Mailer: iPhone Mail (9B208) From: Sevan / Venture37 Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" Date: Thu, 30 Jan 2014 00:44:03 +0000 To: "huanghwh@gmail.com" Cc: Kenneth Culver , "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 00:44:18 -0000 On 29 Jan 2014, at 01:13, Huang Wen Hui wrote: > I got the same problem on FreeBSD 10, disable Background Compilation seems= to fixed this problem. Patched & rebuild openjdk6, I was able to complete the opennms built process= so I thought I'd restart it to double check, build process froze with java p= rocess in a state of uwait. Aborted after 4 hours & restarted once more. Sevan= From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 01:16:47 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E29F5E52; Thu, 30 Jan 2014 01:16:47 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E89E10B5; Thu, 30 Jan 2014 01:16:47 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id jy13so1770956veb.13 for ; Wed, 29 Jan 2014 17:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ln/N761Yr6Ts5XX4hhkl8Na3C4UCqb1lYvC+H9bJt3Y=; b=QTDrdd6PllPNzknG2qx6JQ8Bq4grr7lB3HGU8Z8vHgZxaWXV0vGgnqg8NHVdmd0/m5 Xa7w0U4vHWJi+/yGvfKlx80OV16KvA/4vtbrgVGt1iTsY5ywLhslBt+NRQ1Ddc4prNo4 oCHigCDR6dX7kKJrBdXjpc4QZKF2LETK/ZBwf1wHqpH4pydPLls8PFdCpEGr3pkcJIHF 6vq9nJbls8XwdZZhhohdwB6Ril4vx4/5TZAC57XJLPJ+wfhz9LrBcT7IrwnyaKUT/sjP nRVIjgBVHiArBkw2Fq5J33kapDbjI3hrtnMiVLKLB6QuJJFNFqL+OjrGqzGwYE2JNbZE fAUQ== MIME-Version: 1.0 X-Received: by 10.58.7.1 with SMTP id f1mr9046050vea.15.1391044606680; Wed, 29 Jan 2014 17:16:46 -0800 (PST) Received: by 10.59.10.99 with HTTP; Wed, 29 Jan 2014 17:16:46 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Jan 2014 20:16:46 -0500 Message-ID: Subject: Re: freebsd-stable Digest, Vol 549, Issue 2 From: Jason Unovitch To: freebsd-stable@freebsd.org, freebsd-java@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 01:16:48 -0000 Bottom line up front, the disabling BackgroundCompliation didn't prevent crashes on either OpenJDK6 or OpenJDK7. I've found that Serviio is reliable on OpenJDK7 as long as it isn't pushed. It's been running for about 48 hours based off the current version in ports (openjdk-7.25.15_2,1). On the other hand, it is unreliable and crashes when attempting to parse through media directories looking for files to add to its database. It is reliable while reading in images but when it gets to videos and it is forking off ffmpegs to get thumbnails it eventually crashes. To answer earlier question regarding make.conf, this is it. I do compile all my own packages mainly to turn a few knobs for Nginx/RoR/PHP and some ffmpeg knobs for Serviio. The only global one is stack protection. WITH_SSP_PORTS=yes php5_SET+=FPM ffmpeg_SET+=RTMP X11GRAB FAAC LAME AMR_NB AMR_WB ASS DEFAULT_VERSIONS= ruby=1.9 perl5=5.16 rubygem-passenger_UNSET+=APACHE22 rubygem-passenger_SET+=NGINX nginx_SET+=PASSENGER HTTP_SSL The first set below is on OpenJDK6. On the first it ran for a few hours until it went through all the image additions. It crashed on video. The ones that follow crash quickly because it picks up looking through videos. # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000800a4dfb8, pid=38507, tid=100590 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libthr.so.3+0x12fb8] operator->+0x88 OS:BSD uname:FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 rlimit: STACK 524288k, CORE infinity, NPROC 19558, NOFILE 470934, AS infinity load average:1.67 1.07 0.98 CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, tsc, tscinvbit Memory: 4k page, physical 16744408k(732520k free), swap 4194304k(3092044k free) vm_info: OpenJDK 64-Bit Server VM (23.25-b01) for bsd-amd64 JRE (1.6.0_32-b30), built on Jan 29 2014 17:44:56 by "root" with gcc 4.2.1 Compatible FreeBSD Clang 3.3 (tags/RELEASE_33/final 183502) time: Wed Jan 29 20:02:10 2014 elapsed time: 7283 seconds # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000800d04f5d, pid=54278, tid=101331 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libc.so.7+0xa4f5d] short+0x7f2d OS:BSD uname:FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 rlimit: STACK 524288k, CORE infinity, NPROC 19558, NOFILE 470934, AS infinity load average:4.82 4.06 2.83 CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, tsc, tscinvbit Memory: 4k page, physical 16744408k(854608k free), swap 4194304k(3101492k free) vm_info: OpenJDK 64-Bit Server VM (23.25-b01) for bsd-amd64 JRE (1.6.0_32-b30), built on Jan 29 2014 17:44:56 by "root" with gcc 4.2.1 Compatible FreeBSD Clang 3.3 (tags/RELEASE_33/final 183502) time: Wed Jan 29 20:28:36 2014 elapsed time: 414 seconds # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x00000008039f8194, pid=82303, tid=101252 # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # J java.io.File.listFiles(Ljava/io/FileFilter;)[Ljava/io/File; # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (safepoint.cpp:687), pid=83838, tid=100192 # fatal error: Deadlock in safepoint code. Should have called back to the VM before blocking. # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Core dump written. Default location: //core or core.83838 # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (compileBroker.cpp:311), pid=7314, tid=100516 # guarantee(_code_handle != NULL) failed: # # JRE version: 6.0_32-b30 # Java VM: OpenJDK 64-Bit Server VM (23.25-b01 mixed mode bsd-amd64 compressed oops) # Core dump written. Default location: //core or core.7314 This is on OpenJDK7 with the same patched Background Compilation patch. # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000803c4b8b5, pid=82769, tid=35219752960 # # JRE version: OpenJDK Runtime Environment (7.0-b18) (build 1.7.0_45-b18) # Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops) # Problematic frame: # J java.util.regex.Pattern.matcher(Ljava/lang/CharSequence;)Ljava/util/regex/Matcher; OS:BSDuname:FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 rlimit: STACK 524288k, CORE infinity, NPROC 19558, NOFILE 470934, AS infinity load average:0.69 0.50 0.43 CPU:total 4 (4 cTo answer earlier question regarding make.conf, this is it. I do compile all my own packages mainly to turn a few knobs for Nginx/RoR/PHP and some ffmpeg knobs for Serviio. The only global one is stack protection. WITH_SSP_PORTS=yes php5_SET+=FPM ffmpeg_SET+=RTMP X11GRAB FAAC LAME AMR_NB AMR_WB ASS DEFAULT_VERSIONS= ruby=1.9 perl5=5.16 rubygem-passenger_UNSET+=APACHE22 rubygem-passenger_SET+=NGINX nginx_SET+=PASSENGER HTTP_SSLores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, tsc, tscinvbit /proc/cpuinfo: Memory: 4k page, physical 2609044k(652261k free) /proc/meminfo: vm_info: OpenJDK 64-Bit Server VM (24.45-b08) for bsd-amd64 JRE (1.7.0_45-b18), built on Jan 29 2014 21:14:23 by "root" with gcc 4.6.4 time: Wed Jan 29 22:25:26 2014 elapsed time: 41 seconds # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000800d0d49d, pid=15794, tid=34410443776 # # JRE version: 7.0-b15 # Java VM: OpenJDK 64-Bit Server VM (23.21-b01 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libc.so.7+0xac49d] __free+0x29d OS:BSDuname:FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 rlimit: STACK 524288k, CORE infinity, NPROC 19558, NOFILE 470934, AS infinity load average:1.08 1.19 1.21 CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 42 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, tsc, tscinvbit /proc/cpuinfo: Memory: 4k page, physical 1959320k(489830k free) /proc/meminfo: vm_info: OpenJDK 64-Bit Server VM (23.21-b01) for bsd-amd64 JRE (1.7.0_25-b15), built on Jan 27 2014 23:27:55 by "root" with gcc 4.6.4 time: Tue Jan 28 03:44:19 2014 elapsed time: 5332 seconds Respectfully, Jason Unovitch > From: Huang Wen Hui > > Content-Type: text/plain; charset="utf-8" > > Hi, > I got the same problem on FreeBSD 10, disable Background Compilation seems > to fixed this problem. > Please try this patch: > > --- work/hotspot/src/cpu/x86/vm/c1_globals_x86.hpp.orig 2014-01-28 > 09:01:59.000000000 +0800 > +++ work/hotspot/src/cpu/x86/vm/c1_globals_x86.hpp 2014-01-28 > 09:02:49.000000000 +0800 > @@ -32,7 +32,7 @@ > // (see c1_globals.hpp) > > #ifndef TIERED > -define_pd_global(bool, BackgroundCompilation, true ); > +define_pd_global(bool, BackgroundCompilation, false); > define_pd_global(bool, UseTLAB, true ); > define_pd_global(bool, ResizeTLAB, true ); > define_pd_global(bool, InlineIntrinsics, true ); > --- work/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp.orig 2014-01-28 > 09:02:06.000000000 +0800 > +++ work/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp 2014-01-28 > 09:04:34.000000000 +0800 > @@ -31,7 +31,7 @@ > // Sets the default values for platform dependent flags used by the server > compiler. > // (see c2_globals.hpp). Alpha-sorted. > > -define_pd_global(bool, BackgroundCompilation, true); > +define_pd_global(bool, BackgroundCompilation, false); > define_pd_global(bool, UseTLAB, true); > define_pd_global(bool, ResizeTLAB, true); > define_pd_global(bool, CICompileOSR, true); > > > Cheers, > > Huang Wen Hui > > > 2014-01-29 Kenneth Culver > >> I built from ports, I'm running 10.0-STABLE, but the problems were >> occurring on 10.0-RELEASE as well. >> >> >> On Tue, Jan 28, 2014 at 9:31 AM, Sevan / Venture37 > >wrote: >> >> > Jason, >> > A couple of questions, >> > Are you using packages or building from ports? >> > If you're building, what does your /etc/make.conf >> > >> > I've been suffering from sigsegv issues for a few weeks now on my >> > server running -current which I build world/ports on myself. >> > I looked to see if the problems are there in 10.0-RELEASE & >> > 11.0-CURRENT using the official packages & install CD & the problem >> > did not manifest on either environments. >> > I'm currently working backwards on my aforementioned server, reverting >> > changes to find where the problem is introduced. >> > >> > >> > Sevan >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " >> > >> _______________________________________________ >> freebsd-java@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-java >> To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" >> From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 02:32:31 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 601455B4 for ; Thu, 30 Jan 2014 02:32:31 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 345ED16A2 for ; Thu, 30 Jan 2014 02:32:31 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id C21C333C19; Wed, 29 Jan 2014 21:24:11 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id D876839841; Wed, 29 Jan 2014 21:24:09 -0500 (EST) From: Lowell Gilbert To: Dmitry Morozovsky Subject: Re: upgrade_checks fails on stable/10 in parallel builds? References: Date: Wed, 29 Jan 2014 21:24:09 -0500 In-Reply-To: (Dmitry Morozovsky's message of "Wed, 29 Jan 2014 23:57:10 +0400 (MSK)") Message-ID: <44mwietdfa.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: freebsd-stable@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 02:32:31 -0000 Dmitry Morozovsky writes: > Colleagues, > > after upgrading my builder to stable/10 I'm getting consistent errors like > > --- upgrade_checks --- > A failure has been detected in another branch of the parallel make > > make[1]: stopped in /FreeBSD/pristine/src.9.2 > *** [upgrade_checks] Error code 2 > > make: stopped in /FreeBSD/pristine/src.9.2 > 1 error > > make: stopped in /FreeBSD/pristine/src.9.2 > > in case of using -j when invoking buildworld > > make -DNO_CLEAN upgrade_checks (without -j) rebuilds (f)make fine, and then > parallel buildworld seems to work fine. > > Any thoughts? I'd tried to look at Makefiles, but lost in the middle ;) Make sure you try going all the way through the build without the -j option. If you haven't already tried that, it's possible that the problem would occur there too, and the parallel build is just obscuring the output, not actually failing in a different place. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 03:59:54 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06C49BC8; Thu, 30 Jan 2014 03:59:54 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C9C01DB0; Thu, 30 Jan 2014 03:59:52 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0U3xgkI015081; Thu, 30 Jan 2014 05:59:42 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0U3xg6U014906; Thu, 30 Jan 2014 03:59:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 30 Jan 2014 03:59:42 GMT Message-Id: <201401300359.s0U3xg6U014906@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 03:59:54 -0000 TB --- 2014-01-30 00:00:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-30 00:00:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-30 00:00:43 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-30 00:00:43 - cleaning the object tree TB --- 2014-01-30 00:00:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-30 00:01:36 - At svn revision 261278 TB --- 2014-01-30 00:01:37 - building world TB --- 2014-01-30 00:01:37 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 00:01:37 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 00:01:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 00:01:37 - SRCCONF=/dev/null TB --- 2014-01-30 00:01:37 - TARGET=i386 TB --- 2014-01-30 00:01:37 - TARGET_ARCH=i386 TB --- 2014-01-30 00:01:37 - TZ=UTC TB --- 2014-01-30 00:01:37 - __MAKE_CONF=/dev/null TB --- 2014-01-30 00:01:37 - cd /src TB --- 2014-01-30 00:01:37 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 30 00:01:48 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 30 03:35:43 UTC 2014 TB --- 2014-01-30 03:35:43 - generating LINT kernel config TB --- 2014-01-30 03:35:43 - cd /src/sys/i386/conf TB --- 2014-01-30 03:35:43 - /usr/bin/make -B LINT TB --- 2014-01-30 03:35:43 - cd /src/sys/i386/conf TB --- 2014-01-30 03:35:43 - /usr/sbin/config -m LINT TB --- 2014-01-30 03:35:43 - building LINT kernel TB --- 2014-01-30 03:35:43 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 03:35:43 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 03:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 03:35:43 - SRCCONF=/dev/null TB --- 2014-01-30 03:35:43 - TARGET=i386 TB --- 2014-01-30 03:35:43 - TARGET_ARCH=i386 TB --- 2014-01-30 03:35:43 - TZ=UTC TB --- 2014-01-30 03:35:43 - __MAKE_CONF=/dev/null TB --- 2014-01-30 03:35:43 - cd /src TB --- 2014-01-30 03:35:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 30 03:35:43 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-30 03:59:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-30 03:59:41 - ERROR: failed to build LINT kernel TB --- 2014-01-30 03:59:41 - 10817.62 user 3456.04 system 14337.83 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 09:50:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5057F6A7 for ; Thu, 30 Jan 2014 09:50:17 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D694B1828 for ; Thu, 30 Jan 2014 09:50:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0U9oEOX025899 for ; Thu, 30 Jan 2014 13:50:14 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 13:50:14 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org Subject: building stable/8 on stable/10 host: is it supported? Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 13:50:14 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 09:50:17 -0000 Colleagues, looking into troubles with my builder I found more things: while on stable/9 host, it seamlessly builds all stable versions from 10 to 6. stable/4 had to be built in stable/6 jail Now, after upgrade builder host system to stable/10, I can no longer build stable/8 and older (this in on fresh stable/10 jail, without /usr/obj *and* without -j, which prevents from succeeding upgrade_checks): c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/FreeBSD/src.8/gnu/usr.bin/gperf -c /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:165:5: warning: add explicit braces to avoid dangling else [-Wdangling-else] for (KeywordExt_List *temp = _head; temp; temp = temp->rest()) ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: note: expanded from macro 'for' #define for if (0) ; else for ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:417:15: warning: add explicit braces to avoid dangling else [-Wdangling-else] for (int i3 = imax; i3 >= 0; i3--) ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: note: expanded from macro 'for' #define for if (0) ; else for ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:415:11: warning: add explicit braces to avoid dangling else [-Wdangling-else] for (int i2 = imax; i2 >= -1; i2--) ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: note: expanded from macro 'for' #define for if (0) ; else for ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:1638:5: warning: add explicit braces to avoid dangling else [-Wdangling-else] for (unsigned int c = 0; c < _alpha_size; c++) ^ /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: note: expanded from macro 'for' #define for if (0) ; else for ^ 4 warnings generated. c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/FreeBSD/src.8/gnu/usr.bin/gperf -c /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/FreeBSD/src.8/gnu/usr.bin/gperf -c /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/FreeBSD/src.8/gnu/usr.bin/gperf -c /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc make: don't know how to make /usr/lib/libstdc++.a. Stop *** Error code 2 Stop in /FreeBSD/src.8. *** Error code 1 Stop in /FreeBSD/src.8. *** Error code 1 Stop. make: stopped in /FreeBSD/src.8 Thoughts? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 09:52:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67E3A81B for ; Thu, 30 Jan 2014 09:52:16 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DABEE18B7 for ; Thu, 30 Jan 2014 09:52:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0U9qDWO025986 for ; Thu, 30 Jan 2014 13:52:13 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 13:52:13 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@freebsd.org Subject: Re: upgrade_checks fails on stable/10 in parallel builds? In-Reply-To: <44mwietdfa.fsf@lowell-desk.lan> Message-ID: References: <44mwietdfa.fsf@lowell-desk.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 13:52:13 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 09:52:16 -0000 On Wed, 29 Jan 2014, Lowell Gilbert wrote: > > after upgrading my builder to stable/10 I'm getting consistent errors like > > > > --- upgrade_checks --- > > A failure has been detected in another branch of the parallel make > > > > make[1]: stopped in /FreeBSD/pristine/src.9.2 > > *** [upgrade_checks] Error code 2 > > > > make: stopped in /FreeBSD/pristine/src.9.2 > > 1 error > > > > make: stopped in /FreeBSD/pristine/src.9.2 > > > > in case of using -j when invoking buildworld > > > > make -DNO_CLEAN upgrade_checks (without -j) rebuilds (f)make fine, and then > > parallel buildworld seems to work fine. > > > > Any thoughts? I'd tried to look at Makefiles, but lost in the middle ;) > > Make sure you try going all the way through the build without the -j > option. If you haven't already tried that, it's possible that the > problem would occur there too, and the parallel build is just obscuring > the output, not actually failing in a different place. See above, I *did* test this. However, on contemporary systems, and knowing current FreeBSD world/kernel build times, working -j on the widest combination of build environments is vital, as for me. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 09:53:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75404944 for ; Thu, 30 Jan 2014 09:53:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DB7718D3 for ; Thu, 30 Jan 2014 09:53:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=osq0U2gHELldiBnFEfTpnVF21cN++FmYx8mntOTV1IA=; b=McMDw8xMpz+8np/ohFjVxTRzPduWHLGYz+tg31XwKvx+OAuc8KaLi/a84skqGyB2D0LBu/L8B+q002JtL9ouF9eICayMPC1DCudqTwgvJUoGO6/WGR2oqEZS1SAVI1ewNqbtKnPPaJWKyI4jgeOSspktm+jyDgcyfIXCTaDAcWM=; Received: from [39.200.40.79] (port=18840 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1W8oJO-001gHR-5m; Thu, 30 Jan 2014 02:53:31 -0700 Date: Thu, 30 Jan 2014 17:53:17 +0800 From: Erich Dollansky To: Dmitry Morozovsky Subject: Re: building stable/8 on stable/10 host: is it supported? Message-ID: <20140130175317.6c854f50@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 09:53:32 -0000 On Thu, 30 Jan 2014 13:50:14 +0400 (MSK) Dmitry Morozovsky wrote: > Colleagues, > > looking into troubles with my builder I found more things: > > while on stable/9 host, it seamlessly builds all stable versions from > 10 to 6. stable/4 had to be built in stable/6 jail > > Now, after upgrade builder host system to stable/10, I can no longer > build stable/8 and older (this in on fresh stable/10 jail, > without /usr/obj *and* without -j, which prevents from succeeding > upgrade_checks): > > c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include > -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/FreeBSD/src.8/gnu/usr.bin/gperf -c > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:165:5: > warning: add explicit braces to avoid dangling else > [-Wdangling-else] > for (KeywordExt_List *temp = _head; temp; temp = temp->rest()) > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: > note: expanded from macro 'for' > #define for if (0) ; else for > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:417:15: > warning: add explicit braces to avoid dangling else > [-Wdangling-else] > for (int i3 = imax; i3 >= 0; i3--) > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: > note: expanded from macro 'for' > #define for if (0) ; else for > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:415:11: > warning: add explicit braces to avoid dangling else > [-Wdangling-else] > for (int i2 = imax; i2 >= -1; i2--) > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: > note: expanded from macro 'for' > #define for if (0) ; else for > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:1638:5: > warning: add explicit braces to avoid dangling else > [-Wdangling-else] > for (unsigned int c = 0; c < _alpha_size; c++) > ^ > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc:39:22: > note: expanded from macro 'for' > #define for if (0) ; else for > ^ > 4 warnings generated. > c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include > -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/FreeBSD/src.8/gnu/usr.bin/gperf -c > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc > c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include > -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/FreeBSD/src.8/gnu/usr.bin/gperf -c > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib/getline.cc > c++ -O2 -pipe -I/usr/obj/FreeBSD/src.8/tmp/legacy/usr/include > -I/FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/FreeBSD/src.8/gnu/usr.bin/gperf -c > /FreeBSD/src.8/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc > make: don't know how to make /usr/lib/libstdc++.a. Stop > *** Error code 2 > > Stop in /FreeBSD/src.8. > *** Error code 1 > > Stop in /FreeBSD/src.8. > *** Error code 1 > > Stop. > make: stopped in /FreeBSD/src.8 > are you using gcc? 10 uses normally clang. Erich From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 09:56:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7D8FAB1 for ; Thu, 30 Jan 2014 09:56:26 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 297AD1903 for ; Thu, 30 Jan 2014 09:56:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0U9uKGY026109; Thu, 30 Jan 2014 13:56:20 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 13:56:20 +0400 (MSK) From: Dmitry Morozovsky To: Erich Dollansky Subject: Re: building stable/8 on stable/10 host: is it supported? In-Reply-To: <20140130175317.6c854f50@X220.alogt.com> Message-ID: References: <20140130175317.6c854f50@X220.alogt.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 13:56:20 +0400 (MSK) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 09:56:26 -0000 On Thu, 30 Jan 2014, Erich Dollansky wrote: > > looking into troubles with my builder I found more things: > > > > while on stable/9 host, it seamlessly builds all stable versions from > > 10 to 6. stable/4 had to be built in stable/6 jail > > > > Now, after upgrade builder host system to stable/10, I can no longer > > build stable/8 and older (this in on fresh stable/10 jail, > > without /usr/obj *and* without -j, which prevents from succeeding > > upgrade_checks): > > [snip] > > make: don't know how to make /usr/lib/libstdc++.a. Stop > > *** Error code 2 > > > > Stop in /FreeBSD/src.8. > > *** Error code 1 > > > > Stop in /FreeBSD/src.8. > > *** Error code 1 > > > > Stop. > > make: stopped in /FreeBSD/src.8 > > > are you using gcc? > > 10 uses normally clang. Well, I thought buildtools and cross-tools targets should take care of that, aren't they? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 10:21:14 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45944464 for ; Thu, 30 Jan 2014 10:21:14 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36A1E1B55 for ; Thu, 30 Jan 2014 10:21:13 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s0UAKon3095167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jan 2014 19:21:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s0UAKlSb036390; Thu, 30 Jan 2014 19:20:49 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 30 Jan 2014 19:18:54 +0900 (JST) Message-Id: <20140130.191854.1571220137154550209.hrs@allbsd.org> To: marck@rinet.ru Subject: Re: building stable/8 on stable/10 host: is it supported? From: Hiroki Sato In-Reply-To: References: <20140130175317.6c854f50@X220.alogt.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jan_30_19_18_54_2014_444)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Thu, 30 Jan 2014 19:21:01 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: erichsfreebsdlist@alogt.com, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 10:21:14 -0000 ----Security_Multipart(Thu_Jan_30_19_18_54_2014_444)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dmitry Morozovsky wrote in : ma> On Thu, 30 Jan 2014, Erich Dollansky wrote: ma> ma> > > looking into troubles with my builder I found more things: ma> > > ma> > > while on stable/9 host, it seamlessly builds all stable versions from ma> > > 10 to 6. stable/4 had to be built in stable/6 jail ma> > > ma> > > Now, after upgrade builder host system to stable/10, I can no longer ma> > > build stable/8 and older (this in on fresh stable/10 jail, ma> > > without /usr/obj *and* without -j, which prevents from succeeding ma> > > upgrade_checks): ma> > > ma> ma> [snip] ma> ma> > > make: don't know how to make /usr/lib/libstdc++.a. Stop ma> > > *** Error code 2 ma> > > ma> > > Stop in /FreeBSD/src.8. ma> > > *** Error code 1 ma> > > ma> > > Stop in /FreeBSD/src.8. ma> > > *** Error code 1 ma> > > ma> > > Stop. ma> > > make: stopped in /FreeBSD/src.8 ma> > > ma> > are you using gcc? ma> > ma> > 10 uses normally clang. ma> ma> Well, I thought buildtools and cross-tools targets should take care of that, ma> aren't they? Currently stable/8 does not build on a box running 10 or later because several commits to fix build errors at the toolchain bootstrapping stages due to the toolchain migration were not MFC'd yet. For stable/8, try the following patch: http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch.diff -- Hiroki ----Security_Multipart(Thu_Jan_30_19_18_54_2014_444)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlLqJw4ACgkQTyzT2CeTzy1uBwCgtPQld4nEEp0wrQATu7VbnT8h i0wAmwTjKu4hrDb3mU0vtSj8wg1t8cKq =bsg8 -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jan_30_19_18_54_2014_444)---- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 10:36:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE875D0E; Thu, 30 Jan 2014 10:36:26 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 245E41D8D; Thu, 30 Jan 2014 10:36:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0UAaLgH027757; Thu, 30 Jan 2014 14:36:21 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 14:36:21 +0400 (MSK) From: Dmitry Morozovsky To: Hiroki Sato Subject: Re: building stable/8 on stable/10 host: is it supported? In-Reply-To: <20140130.191854.1571220137154550209.hrs@allbsd.org> Message-ID: References: <20140130175317.6c854f50@X220.alogt.com> <20140130.191854.1571220137154550209.hrs@allbsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 14:36:21 +0400 (MSK) Cc: erichsfreebsdlist@alogt.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 10:36:26 -0000 Hiroki-san, On Thu, 30 Jan 2014, Hiroki Sato wrote: > ma> > > looking into troubles with my builder I found more things: > ma> > > > ma> > > while on stable/9 host, it seamlessly builds all stable versions from > ma> > > 10 to 6. stable/4 had to be built in stable/6 jail > ma> > > > ma> > > Now, after upgrade builder host system to stable/10, I can no longer > ma> > > build stable/8 and older (this in on fresh stable/10 jail, > ma> > > without /usr/obj *and* without -j, which prevents from succeeding > ma> > > upgrade_checks): > ma> > > > ma> > ma> [snip] > ma> > ma> > > make: don't know how to make /usr/lib/libstdc++.a. Stop > ma> > > *** Error code 2 > ma> > > > ma> > > Stop in /FreeBSD/src.8. > ma> > > *** Error code 1 > ma> > > > ma> > > Stop in /FreeBSD/src.8. > ma> > > *** Error code 1 > ma> > > > ma> > > Stop. > ma> > > make: stopped in /FreeBSD/src.8 > ma> > > > ma> > are you using gcc? > ma> > > ma> > 10 uses normally clang. > ma> > ma> Well, I thought buildtools and cross-tools targets should take care of that, > ma> aren't they? > > Currently stable/8 does not build on a box running 10 or later > because several commits to fix build errors at the toolchain > bootstrapping stages due to the toolchain migration were not MFC'd > yet. For stable/8, try the following patch: > > http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch.diff Thanks a lot, will try and report! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 11:30:03 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86DC012C; Thu, 30 Jan 2014 11:30:03 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE009118B; Thu, 30 Jan 2014 11:30:02 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0UBTw0q090262; Thu, 30 Jan 2014 13:29:58 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0UBTwLT090114; Thu, 30 Jan 2014 11:29:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 30 Jan 2014 11:29:58 GMT Message-Id: <201401301129.s0UBTwLT090114@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 11:30:03 -0000 TB --- 2014-01-30 07:30:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-30 07:30:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-30 07:30:43 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-30 07:30:43 - cleaning the object tree TB --- 2014-01-30 07:31:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-30 07:31:45 - At svn revision 261282 TB --- 2014-01-30 07:31:46 - building world TB --- 2014-01-30 07:31:46 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 07:31:46 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 07:31:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 07:31:46 - SRCCONF=/dev/null TB --- 2014-01-30 07:31:46 - TARGET=i386 TB --- 2014-01-30 07:31:46 - TARGET_ARCH=i386 TB --- 2014-01-30 07:31:46 - TZ=UTC TB --- 2014-01-30 07:31:46 - __MAKE_CONF=/dev/null TB --- 2014-01-30 07:31:46 - cd /src TB --- 2014-01-30 07:31:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 30 07:31:57 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 30 11:06:02 UTC 2014 TB --- 2014-01-30 11:06:02 - generating LINT kernel config TB --- 2014-01-30 11:06:02 - cd /src/sys/i386/conf TB --- 2014-01-30 11:06:02 - /usr/bin/make -B LINT TB --- 2014-01-30 11:06:02 - cd /src/sys/i386/conf TB --- 2014-01-30 11:06:02 - /usr/sbin/config -m LINT TB --- 2014-01-30 11:06:02 - building LINT kernel TB --- 2014-01-30 11:06:02 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 11:06:02 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 11:06:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 11:06:02 - SRCCONF=/dev/null TB --- 2014-01-30 11:06:02 - TARGET=i386 TB --- 2014-01-30 11:06:02 - TARGET_ARCH=i386 TB --- 2014-01-30 11:06:02 - TZ=UTC TB --- 2014-01-30 11:06:02 - __MAKE_CONF=/dev/null TB --- 2014-01-30 11:06:02 - cd /src TB --- 2014-01-30 11:06:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 30 11:06:03 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-30 11:29:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-30 11:29:57 - ERROR: failed to build LINT kernel TB --- 2014-01-30 11:29:57 - 10828.25 user 3453.30 system 14353.85 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 12:27:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90DFBCAD for ; Thu, 30 Jan 2014 12:27:33 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69AE01631 for ; Thu, 30 Jan 2014 12:27:33 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kx10so3037828pab.21 for ; Thu, 30 Jan 2014 04:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZDtlN3wlhamllDOoxo6v+T/Olb+RchDiQ+uyWHcE5W0=; b=Nfo85TcDkN7Y+ikJY+PYr68f9bykXI5QZPgw5UtNZ8ZI2C9K2gnk2kFdzGDWBWjFJT uhKzYExGuQ2FJZ1dJ0TvnzepdoENkU0VBOEQGHk+WVX7w9HmSdozplZcCOObDW6iz2v0 JfjBO3ng/bPsFPFdPMYK6wepjekcnz8RKSxiUHDLLDrqZ+n11Lttpcc2JH2nXKMDy7yX Dl1eaQfCGJ0XIM1SU4erjSGq8AxoNtlt0P3xBwrTSsNBIHoThz3WJZl130mmBbmDLkta u9oaVSIhaVFd9U8m+iQ2nWnVXlc0b5BbZj8ctX7jgluwwAZLFGCVnj812gK1XlCaWfwj kQ6Q== MIME-Version: 1.0 X-Received: by 10.68.189.5 with SMTP id ge5mr14027733pbc.42.1391084853068; Thu, 30 Jan 2014 04:27:33 -0800 (PST) Received: by 10.66.142.167 with HTTP; Thu, 30 Jan 2014 04:27:33 -0800 (PST) Date: Thu, 30 Jan 2014 13:27:33 +0100 Message-ID: Subject: Sound not working with ALC889 in FreeBSD 10 From: Zenny To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 12:27:33 -0000 Sound is not working in FreeBSD-10 with GENERIC kernel. I checked the available online resources and handbook ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sound-setup.html). I have appended snd_hda_enable="YES" in/boot/loader.conf $ pciconf -lv | grep -i audio device = 'Caicos HDMI Audio [Radeon HD 6400 Series]' $ cat /dev/sndstat Installed devices: pcm0: (play) pcm1: (play/rec) default pcm2: (play/rec) pcm3: (play) pcm4: (play) $ dmesg | grep pcm pcm0: at nid 3 on hdaa0 pcm1: at nid 20,22,21,23 and 24,26 on hdaa1 pcm2: at nid 27 and 25 on hdaa1 pcm3: at nid 30 on hdaa1 pcm4: at nid 17 on hdaa1 $ grep -Rn snd /etc/sysctl.conf 16:hw.snd.default_unit=1 $ mixer Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 57:57 Mixer line is currently set to 1:1 Mixer mic is currently set to 67:67 Mixer mix is currently set to 35:35 Mixer rec is currently set to 35:35 Mixer igain is currently set to 0:0 Mixer ogain is currently set to 100:100 Also tried to append /boot/device.hints with line , but with no luck. Any inputs appreciated! Thanks! /z From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 12:53:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFA5359B; Thu, 30 Jan 2014 12:53:41 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B077187F; Thu, 30 Jan 2014 12:53:41 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so3080531pbc.2 for ; Thu, 30 Jan 2014 04:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qPBcZhwbZnDqMMlZKMnIlL+WKAjEBvA6s83BJX6qvk8=; b=i7o18/5xgkcNYHeUgMILilKnZsu4XxqutVRcDG2jWPWh2psNs58Qi5SrTuxYeaD9kr JFDDtmHE80k6/jo19rsJi4bR3xqnncQvhNDYmBXwSBzq1tCLf+y2//aNKrJt7VIq4giy 5fBdrHztIOj3hXv6ZEGHuNJUBtV+l92eoqtYDHLy27AV2g5/U7sKG1+3zjjDLOs7DRf8 5BkP2yjrPTAtX8QPcczzC+H7htYaicmoUda5KBUwXj8kEy2Zf1u3gJ2twtI7I2bP4XAf VtsEfVliSQ7BgI9u4HQJMZlzXicPXehTRXp093GMEwvn3Y57o65zz5NH0F6cmGLKbcjC UJAg== MIME-Version: 1.0 X-Received: by 10.66.227.104 with SMTP id rz8mr14268330pac.74.1391086421062; Thu, 30 Jan 2014 04:53:41 -0800 (PST) Received: by 10.70.88.101 with HTTP; Thu, 30 Jan 2014 04:53:41 -0800 (PST) In-Reply-To: <52B72D09-62E0-4D36-9D56-F45D4D223382@gmail.com> References: <52B72D09-62E0-4D36-9D56-F45D4D223382@gmail.com> Date: Thu, 30 Jan 2014 07:53:41 -0500 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Kenneth Culver To: "Sevan / Venture37" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "huanghwh@gmail.com" , "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 12:53:41 -0000 Disabling background compilation fixed my issues. On Wednesday, January 29, 2014, Sevan / Venture37 wrote: > On 29 Jan 2014, at 01:13, Huang Wen Hui > > wrote: > > > I got the same problem on FreeBSD 10, disable Background Compilation > seems to fixed this problem. > > Patched & rebuild openjdk6, I was able to complete the opennms built > process so I thought I'd restart it to double check, build process froze > with java process in a state of uwait. > Aborted after 4 hours & restarted once more. > > Sevan From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 13:51:56 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38E658EF; Thu, 30 Jan 2014 13:51:56 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EFBD1EF2; Thu, 30 Jan 2014 13:51:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s0UDplWN034561; Thu, 30 Jan 2014 17:51:47 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 30 Jan 2014 17:51:47 +0400 (MSK) From: Dmitry Morozovsky To: Hiroki Sato Subject: Re: building stable/8 on stable/10 host: is it supported? In-Reply-To: Message-ID: References: <20140130175317.6c854f50@X220.alogt.com> <20140130.191854.1571220137154550209.hrs@allbsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 30 Jan 2014 17:51:47 +0400 (MSK) Cc: erichsfreebsdlist@alogt.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 13:51:56 -0000 On Thu, 30 Jan 2014, Dmitry Morozovsky wrote: > Hiroki-san, [snip] > > Currently stable/8 does not build on a box running 10 or later > > because several commits to fix build errors at the toolchain > > bootstrapping stages due to the toolchain migration were not MFC'd > > yet. For stable/8, try the following patch: > > > > http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch.diff > > Thanks a lot, will try and report! amd64 world/kernel built successfully, thanks again. However, cross-build to TARGET=i386 chokes on aicasm module: ./aicasm -nostdinc -I. -I/FreeBSD/pristine/src.8/sys -I/FreeBSD/pristine/src.8/sys/contrib/altq -I/FreeBSD/pristine/src.8/sys/contrib/ipfilter -I/FreeBSD/pristine/src.8/sys/contrib/pf -I/FreeBSD/pristine/src.8/sys/dev/ath -I/FreeBSD/pristine/src.8/sys/dev/ath/ath_hal -I/FreeBSD/pristine/src.8/sys/contrib/ngatm -I/FreeBSD/pristine/src.8/sys/dev/twa -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD/support -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs -I/FreeBSD/pristine/src.8/sys/dev/cxgb -I/FreeBSD/pristine/src.8/sys/dev/cxgbe -I/FreeBSD/pristine/src.8/sys/cam/scsi -I/FreeBSD/pristine/src.8/sys/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx_osm.h /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq ./aicasm: Stopped at file /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq, line 53 - Undefined symbol code referenced ./aicasm: Removing aic79xx_seq.h due to error ./aicasm: Removing aic79xx_reg.h due to error *** Signal 11 Stop in /usr/obj/i386/FreeBSD/pristine/src.8/sys/GENERIC. *** Error code 1 Stop in /FreeBSD/pristine/src.8. *** Error code 1 Stop. make: stopped in /FreeBSD/pristine/src.8 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 14:21:43 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EB35E9C for ; Thu, 30 Jan 2014 14:21:43 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F450117A for ; Thu, 30 Jan 2014 14:21:41 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 7319012CB3A3; Thu, 30 Jan 2014 15:21:33 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 4.1403] X-CRM114-CacheID: sfid-20140130_15213_B1C6D208 X-CRM114-Status: UNSURE (4.1403) This message is 'unsure'; please train it! X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jan 30 15:21:33 2014 X-DSPAM-Confidence: 0.9944 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52ea5fed867271168920850 X-DSPAM-Factors: 27, From*"Nagy, Attila" , 0.00182, ports, 0.00194, >+>, 0.00319, >+>, 0.00319, (), 0.00377, (), 0.00377, const, 0.00479, const, 0.00479, fault, 0.00479, fault, 0.00479, #0, 0.00585, #0, 0.00585, Received*online.co.hu+[195.228.243.99]), 0.00657, I+haven't, 0.00657, Received*[195.228.243.99]), 0.00657, debugging, 0.00657, debugging, 0.00657, x11, 0.00657, x11, 0.00657, Received*online.co.hu, 0.00657, Received*(japan.t, 0.00657, Received*(japan.t+online.co.hu, 0.00657, terminated, 0.00657, terminated, 0.00657, Received*from+japan.t, 0.00875, malloc, 0.00875, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id CD50E12CB397 for ; Thu, 30 Jan 2014 15:21:29 +0100 (CET) Message-ID: <52EA5FE9.2040607@fsn.hu> Date: Thu, 30 Jan 2014 15:21:29 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: stable@freebsd.org Subject: thunderbird and firefox crashes on stable/10 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 14:21:43 -0000 Hi, After upgrading my desktop to stable/10, currently at r260900, firefox and thunderbird crashes very often. Here's a recent backtrace from firefox: Core was generated by `firefox'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc++.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /usr/local/lib/firefox/libmozalloc.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox/libmozalloc.so Reading symbols from /usr/local/lib/firefox/libxul.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox/libxul.so Reading symbols from /usr/local/lib/libffi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libffi.so.6 Reading symbols from /usr/local/lib/libicui18n.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicui18n.so.50 Reading symbols from /usr/local/lib/libicuuc.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicuuc.so.50 Reading symbols from /usr/local/lib/libicudata.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicudata.so.50 Reading symbols from /usr/local/lib/nss/libssl3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libssl3.so.1 Reading symbols from /usr/local/lib/nss/libsmime3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libsmime3.so.1 Reading symbols from /usr/local/lib/nss/libnss3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnss3.so.1 Reading symbols from /usr/local/lib/nss/libnssutil3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssutil3.so.1 Reading symbols from /usr/local/lib/libcairo.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcairo.so.2 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libsqlite3.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libsqlite3.so.8 Reading symbols from /usr/local/lib/libjpeg.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libjpeg.so.11 Reading symbols from /usr/local/lib/libpng15.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng15.so.15 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/local/lib/libhunspell-1.3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libhunspell-1.3.so.0 Reading symbols from /usr/local/lib/event2/libevent-2.0.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/event2/libevent-2.0.so.6 Reading symbols from /usr/local/lib/libvpx.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvpx.so.1 Reading symbols from /usr/local/lib/libpixman-1.so.30...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpixman-1.so.30 Reading symbols from /usr/local/lib/libv4l2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4l2.so.0 Reading symbols from /usr/local/lib/libasound.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libasound.so.2 Reading symbols from /usr/local/lib/libplds4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplds4.so.1 Reading symbols from /usr/local/lib/libplc4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplc4.so.1 Reading symbols from /usr/local/lib/libnspr4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libnspr4.so.1 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libatk-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.0 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/local/lib/libpango-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libintl.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libXt.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXt.so.6 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /lib/libkvm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libkvm.so.6 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/local/lib/libxcb-shm.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-shm.so.0 Reading symbols from /usr/local/lib/libxcb-render.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-render.so.0 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libpthread-stubs.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 Reading symbols from /usr/lib/librpcsvc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /usr/local/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libGL.so.1 Reading symbols from /usr/local/lib/libv4lconvert.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4lconvert.so.0 Reading symbols from /usr/local/lib/libharfbuzz.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libharfbuzz.so.0 Reading symbols from /usr/local/lib/libgraphite2.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgraphite2.so.3 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libpcre.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.3 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libX11-xcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11-xcb.so.1 Reading symbols from /usr/local/lib/libxcb-glx.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-glx.so.0 Reading symbols from /usr/local/lib/libdrm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/lib/i18n/libiconv_std.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libiconv_std.so.4 Reading symbols from /usr/lib/i18n/libUTF1632.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libUTF1632.so.4 Reading symbols from /usr/lib/i18n/libmapper_646.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libmapper_646.so.4 Reading symbols from /usr/lib/i18n/libUTF8.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libUTF8.so.4 Reading symbols from /usr/local/lib/libgnomeui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomeui-2.so.0 Reading symbols from /usr/local/lib/libbonoboui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonoboui-2.so.0 Reading symbols from /usr/local/lib/libgnomecanvas-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/local/lib/libgailutil.so.18...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgailutil.so.18 Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 Reading symbols from /usr/local/lib/libgnome-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-2.so.0 Reading symbols from /usr/local/lib/libcanberra.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcanberra.so.0 Reading symbols from /usr/local/lib/libvorbisfile.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbisfile.so.6 Reading symbols from /usr/local/lib/libvorbis.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbis.so.4 Reading symbols from /usr/local/lib/libogg.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libogg.so.8 Reading symbols from /usr/local/lib/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libltdl.so.7 Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-2.so.0 Reading symbols from /usr/local/lib/libbonobo-activation.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 Reading symbols from /usr/local/lib/libORBitCosNaming-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 Reading symbols from /usr/local/lib/libgnomevfs-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomevfs-2.so.0 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /usr/local/lib/libdbus-glib-1.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-glib-1.so.2 Reading symbols from /usr/local/lib/libssl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libssl.so.8 Reading symbols from /usr/local/lib/libcrypto.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcrypto.so.8 Reading symbols from /usr/local/lib/libgconf-2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgconf-2.so.4 Reading symbols from /usr/local/lib/libORBit-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBit-2.so.0 Reading symbols from /usr/local/lib/libgnome-keyring.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-keyring.so.0 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libgcrypt.so.19...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.19 Reading symbols from /usr/local/lib/libgpg-error.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpopt.so.0 Reading symbols from /usr/local/lib/firefox/components/libmozgnome.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox/components/libmozgnome.so Reading symbols from /usr/local/lib/firefox/browser/components/libbrowsercomps.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/firefox/browser/components/libbrowsercomps.so Reading symbols from /usr/local/lib/gtk-2.0/2.10.0/engines/libclearlooks.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gtk-2.0/2.10.0/engines/libclearlooks.so Reading symbols from /usr/local/lib/pango/1.8.0/modules/pango-basic-fc.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/pango/1.8.0/modules/pango-basic-fc.so Reading symbols from /usr/local/lib/nss/libsoftokn3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libsoftokn3.so.1 Reading symbols from /usr/local/lib/nss/libnssdbm3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssdbm3.so.1 Reading symbols from /usr/local/lib/nss/libfreebl3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libfreebl3.so.1 Reading symbols from /usr/local/lib/nss/libnssckbi.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssckbi.so Reading symbols from /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so Reading symbols from /usr/local/lib/libXss.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXss.so.1 Reading symbols from /usr/local/lib/gio/modules/libgvfsdbus.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgvfsdbus.so Reading symbols from /usr/local/lib/libgvfscommon.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgvfscommon.so.0 Reading symbols from /usr/local/lib/gio/modules/libgioremote-volume-monitor.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgioremote-volume-monitor.so Reading symbols from /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so Reading symbols from /usr/local/lib/librsvg-2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/librsvg-2.so.2 Reading symbols from /usr/local/lib/libcroco-0.6.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcroco-0.6.so.3 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008011bb28a in thr_kill () from /lib/libc.so.7 [New Thread 815189400 (LWP 100602/RunProcess)] [New Thread 828ed7000 (LWP 100140/firefox)] [New Thread 828c6bc00 (LWP 101298/firefox)] [New Thread 82dd2e800 (LWP 101114/StreamTrans #10132)] [New Thread 828ed4400 (LWP 100977/ImageDecoder #1831)] [New Thread 815189800 (LWP 100609/DNS Resolver #704)] [New Thread 81518b400 (LWP 100485/SSL Cert #1782)] [New Thread 821d2f400 (LWP 100474/DNS Resolver #703)] [New Thread 82507ec00 (LWP 101174/firefox)] [New Thread 826fd3400 (LWP 100952/firefox)] [New Thread 815189000 (LWP 100737/mozStorage #9)] [New Thread 82507f000 (LWP 101514/MediaManager)] [New Thread 820a21c00 (LWP 101513/mozStorage #8)] [New Thread 818e99000 (LWP 100722/mozStorage #7)] [New Thread 820ab4000 (LWP 100714/DOM Worker)] [New Thread 821d2e800 (LWP 100711/mozStorage #6)] [New Thread 82162f800 (LWP 101507/Image Scaler)] [New Thread 8328e7400 (LWP 101501/mozStorage #5)] [New Thread 821d33000 (LWP 101488/Proxy Resolution)] [New Thread 82e0af800 (LWP 101248/URL Classifier)] [New Thread 828c72800 (LWP 101050/mozStorage #4)] [New Thread 8286aa800 (LWP 101044/localStorage DB)] [New Thread 826c92c00 (LWP 100969/mozStorage #3)] [New Thread 826c8ec00 (LWP 100726/mozStorage #2)] [New Thread 826aae800 (LWP 100712/mozStorage #1)] [New Thread 815180800 (LWP 100703/HTML5 Parser)] [New Thread 82006f000 (LWP 100700/Cache I/O)] [New Thread 818e99400 (LWP 100698/DOM Worker)] [New Thread 818552800 (LWP 100695/DOM Worker)] [New Thread 815182400 (LWP 100691/Analysis Helper)] [New Thread 815182000 (LWP 100680/Analysis Helper)] [New Thread 8174d2800 (LWP 100679/Cert Verify)] [New Thread 8160b4000 (LWP 100678/Timer)] [New Thread 815182c00 (LWP 100677/Hang Monitor)] [New Thread 81517fc00 (LWP 100675/JS Watchdog)] [New Thread 81517f400 (LWP 100674/JS GC Helper)] [New Thread 81517e800 (LWP 100673/Socket Thread)] [New Thread 80180e400 (LWP 100652/Gecko_IOThread)] [New Thread 80180dc00 (LWP 100647/firefox)] [New Thread 801802400 (LWP 100154/firefox)] (gdb) bt #0 0x00000008011bb28a in thr_kill () from /lib/libc.so.7 #1 0x00000008022cd055 in XRE_InstallX11ErrorHandler () from /usr/local/lib/firefox/libxul.so #2 0x0000000800f393f6 in swapcontext () from /lib/libthr.so.3 #3 0x0000000800f38ff3 in sigaction () from /lib/libthr.so.3 #4 #5 0x0000000803aa108a in JS::UnmarkGrayGCThingRecursively () from /usr/local/lib/firefox/libxul.so #6 0x0000000803aa1542 in JS::UnmarkGrayGCThingRecursively () from /usr/local/lib/firefox/libxul.so #7 0x0000000803aa0865 in JS_IterateCompartments () from /usr/local/lib/firefox/libxul.so #8 0x0000000803aa06fb in JS_IterateCompartments () from /usr/local/lib/firefox/libxul.so #9 0x0000000803b5ca9e in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #10 0x0000000803b5b24a in js::AutoMaybeTouchDeadZones::~AutoMaybeTouchDeadZones () from /usr/local/lib/firefox/libxul.so #11 0x0000000803b58714 in js_RemoveRoot () from /usr/local/lib/firefox/libxul.so #12 0x0000000802b24e86 in js::BaseProxyHandler::finalizeInBackground () from /usr/local/lib/firefox/libxul.so #13 0x0000000802b2a693 in js::BaseProxyHandler::finalizeInBackground () from /usr/local/lib/firefox/libxul.so ---Type to continue, or q to quit--- #14 0x0000000802b1fa97 in js::BaseProxyHandler::finalizeInBackground () from /usr/local/lib/firefox/libxul.so #15 0x0000000802b21627 in js::BaseProxyHandler::finalizeInBackground () from /usr/local/lib/firefox/libxul.so #16 0x0000000802b18f1a in js::BaseProxyHandler::finalizeInBackground () from /usr/local/lib/firefox/libxul.so #17 0x000000080357ba60 in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #18 0x000000080353dd45 in std::__1::__tree, std::__1::allocator >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type, std::__1::__map_value_compare, std::__1::allocator >, std::__1::map, std::__1::allocator >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type, std::__1::less to continue, or q to quit--- char>, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type> >::destroy () from /usr/local/lib/firefox/libxul.so #19 0x000000080357aeed in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #20 0x00000008098d8a1a in PR_GetThreadName () from /usr/local/lib/libplds4.so.1 #21 0x0000000800f344a4 in pthread_create () from /lib/libthr.so.3 #22 0x0000000000000000 in ?? () And one from thunderbird: Core was generated by `thunderbird'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc++.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /usr/local/lib/thunderbird/libldap60.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/libldap60.so Reading symbols from /usr/local/lib/thunderbird/libprldap60.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/libprldap60.so Reading symbols from /usr/local/lib/libplds4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplds4.so.1 Reading symbols from /usr/local/lib/libplc4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libplc4.so.1 Reading symbols from /usr/local/lib/libnspr4.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libnspr4.so.1 Reading symbols from /usr/local/lib/thunderbird/libldif60.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/libldif60.so Reading symbols from /usr/local/lib/thunderbird/libmozalloc.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/libmozalloc.so Reading symbols from /usr/local/lib/thunderbird/libxul.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/libxul.so Reading symbols from /usr/local/lib/libffi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libffi.so.6 Reading symbols from /usr/local/lib/libicui18n.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicui18n.so.50 Reading symbols from /usr/local/lib/libicuuc.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicuuc.so.50 Reading symbols from /usr/local/lib/libicudata.so.50...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libicudata.so.50 Reading symbols from /usr/local/lib/nss/libssl3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libssl3.so.1 Reading symbols from /usr/local/lib/nss/libsmime3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libsmime3.so.1 Reading symbols from /usr/local/lib/nss/libnss3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnss3.so.1 Reading symbols from /usr/local/lib/nss/libnssutil3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssutil3.so.1 Reading symbols from /usr/local/lib/libcairo.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcairo.so.2 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libsqlite3.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libsqlite3.so.8 Reading symbols from /usr/local/lib/libjpeg.so.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libjpeg.so.11 Reading symbols from /usr/local/lib/libpng15.so.15...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng15.so.15 Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/local/lib/libhunspell-1.3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libhunspell-1.3.so.0 Reading symbols from /usr/local/lib/event2/libevent-2.0.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/event2/libevent-2.0.so.6 Reading symbols from /usr/local/lib/libvpx.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvpx.so.1 Reading symbols from /usr/local/lib/libpixman-1.so.30...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpixman-1.so.30 Reading symbols from /usr/local/lib/libv4l2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4l2.so.0 Reading symbols from /usr/local/lib/libasound.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libasound.so.2 Reading symbols from /usr/local/lib/libdbus-glib-1.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-glib-1.so.2 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libintl.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libatk-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.0 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/local/lib/libpango-1.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/local/lib/libstartup-notification-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libstartup-notification-1.so.0 Reading symbols from /usr/local/lib/libXt.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXt.so.6 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /lib/libkvm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libkvm.so.6 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/local/lib/libxcb-shm.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-shm.so.0 Reading symbols from /usr/local/lib/libxcb-render.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-render.so.0 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libpthread-stubs.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpthread-stubs.so.0 Reading symbols from /usr/lib/librpcsvc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /usr/local/lib/libv4lconvert.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libv4lconvert.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libpcre.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.3 Reading symbols from /usr/local/lib/libharfbuzz.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libharfbuzz.so.0 Reading symbols from /usr/local/lib/libgraphite2.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgraphite2.so.3 Reading symbols from /usr/local/lib/libxcb-util.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-util.so.1 Reading symbols from /usr/local/lib/libX11-xcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11-xcb.so.1 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/lib/i18n/libiconv_std.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libiconv_std.so.4 Reading symbols from /usr/lib/i18n/libUTF8.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libUTF8.so.4 Reading symbols from /usr/lib/i18n/libmapper_646.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libmapper_646.so.4 Reading symbols from /usr/local/lib/libgnomeui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomeui-2.so.0 Reading symbols from /usr/local/lib/libbonoboui-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonoboui-2.so.0 Reading symbols from /usr/local/lib/libgnomecanvas-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomecanvas-2.so.0 Reading symbols from /usr/local/lib/libgailutil.so.18...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgailutil.so.18 Reading symbols from /usr/local/lib/libart_lgpl_2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libart_lgpl_2.so.5 Reading symbols from /usr/local/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libGL.so.1 Reading symbols from /usr/local/lib/libgnome-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-2.so.0 Reading symbols from /usr/local/lib/libcanberra.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcanberra.so.0 Reading symbols from /usr/local/lib/libvorbisfile.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbisfile.so.6 Reading symbols from /usr/local/lib/libvorbis.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvorbis.so.4 Reading symbols from /usr/local/lib/libogg.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libogg.so.8 Reading symbols from /usr/local/lib/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libltdl.so.7 Reading symbols from /usr/local/lib/libbonobo-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-2.so.0 Reading symbols from /usr/local/lib/libbonobo-activation.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libbonobo-activation.so.4 Reading symbols from /usr/local/lib/libORBitCosNaming-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBitCosNaming-2.so.0 Reading symbols from /usr/local/lib/libgnomevfs-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnomevfs-2.so.0 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /usr/local/lib/libssl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libssl.so.8 Reading symbols from /usr/local/lib/libcrypto.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcrypto.so.8 Reading symbols from /usr/local/lib/libgconf-2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgconf-2.so.4 Reading symbols from /usr/local/lib/libORBit-2.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libORBit-2.so.0 Reading symbols from /usr/local/lib/libgnome-keyring.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgnome-keyring.so.0 Reading symbols from /usr/local/lib/libgcrypt.so.19...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgcrypt.so.19 Reading symbols from /usr/local/lib/libgpg-error.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgpg-error.so.0 Reading symbols from /usr/local/lib/libpopt.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpopt.so.0 Reading symbols from /usr/local/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libxcb-glx.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-glx.so.0 Reading symbols from /usr/local/lib/libdrm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/lib/i18n/libUTF1632.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i18n/libUTF1632.so.4 Reading symbols from /usr/local/lib/thunderbird/components/libmozgnome.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/components/libmozgnome.so Reading symbols from /usr/local/lib/thunderbird/components/libdbusservice.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/thunderbird/components/libdbusservice.so Reading symbols from /usr/local/lib/gtk-2.0/2.10.0/engines/libclearlooks.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gtk-2.0/2.10.0/engines/libclearlooks.so Reading symbols from /usr/local/lib/pango/1.8.0/modules/pango-basic-fc.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/pango/1.8.0/modules/pango-basic-fc.so Reading symbols from /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so Reading symbols from /usr/local/lib/libXss.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXss.so.1 Reading symbols from /usr/local/lib/gio/modules/libgvfsdbus.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgvfsdbus.so Reading symbols from /usr/local/lib/libgvfscommon.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgvfscommon.so.0 Reading symbols from /usr/local/lib/gio/modules/libgioremote-volume-monitor.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libgioremote-volume-monitor.so Reading symbols from /usr/local/lib/nss/libsoftokn3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libsoftokn3.so.1 Reading symbols from /usr/local/lib/nss/libnssdbm3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssdbm3.so.1 Reading symbols from /usr/local/lib/nss/libfreebl3.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libfreebl3.so.1 Reading symbols from /usr/local/lib/nss/libnssckbi.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/nss/libnssckbi.so Reading symbols from /usr/local/lib/gio/modules/libdconfsettings.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gio/modules/libdconfsettings.so Reading symbols from /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so Reading symbols from /usr/local/lib/librsvg-2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/librsvg-2.so.2 Reading symbols from /usr/local/lib/libcroco-0.6.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcroco-0.6.so.3 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000008011b928a in thr_kill () from /lib/libc.so.7 [New Thread 82451c800 (LWP 101585/thunderbird)] [New Thread 81fa90400 (LWP 100805/thunderbird)] [New Thread 85ecf2000 (LWP 100552/DOM Worker)] [New Thread 85ecf1800 (LWP 100823/thunderbird)] [New Thread 818209800 (LWP 100590/thunderbird)] [New Thread 82a739c00 (LWP 100697/thunderbird)] [New Thread 81f042800 (LWP 101378/thunderbird)] [New Thread 816198400 (LWP 101516/thunderbird)] [New Thread 820532000 (LWP 101515/thunderbird)] [New Thread 820ae7000 (LWP 101301/thunderbird)] [New Thread 820ae7c00 (LWP 101232/thunderbird)] [New Thread 820173000 (LWP 101500/thunderbird)] [New Thread 8297f1000 (LWP 101446/thunderbird)] [New Thread 856856400 (LWP 100587/thunderbird)] [New Thread 85684e800 (LWP 101434/thunderbird)] [New Thread 82b0fac00 (LWP 101431/thunderbird)] [New Thread 820203000 (LWP 101409/mozStorage #6)] [New Thread 82b0f1000 (LWP 100523/mozStorage #5)] [New Thread 829ddc000 (LWP 100745/localStorage DB)] [New Thread 822424400 (LWP 101383/MediaManager)] [New Thread 829c6cc00 (LWP 101363/Cache I/O)] [New Thread 829c6e400 (LWP 101349/mozStorage #4)] [New Thread 82a1e4400 (LWP 101321/mozStorage #3)] [New Thread 829a27c00 (LWP 100449/mozStorage #2)] [New Thread 823c37400 (LWP 101130/Proxy Resolution)] [New Thread 823c36800 (LWP 101126/thunderbird)] [New Thread 823c35c00 (LWP 101072/thunderbird)] [New Thread 822dbe400 (LWP 101071/URL Classifier)] [New Thread 822dbe000 (LWP 100623/Cert Verify)] [New Thread 81fa17000 (LWP 101058/mozStorage #1)] [New Thread 81820cc00 (LWP 101055/HTML5 Parser)] [New Thread 816da9c00 (LWP 100763/Timer)] [New Thread 816191000 (LWP 100740/Hang Monitor)] [New Thread 81618e800 (LWP 100643/JS Watchdog)] [New Thread 81618d800 (LWP 100641/thunderbird)] [New Thread 81618dc00 (LWP 100624/JS GC Helper)] [New Thread 81618d000 (LWP 100612/Socket Thread)] [New Thread 80180e400 (LWP 100521/Gecko_IOThread)] [New Thread 80180dc00 (LWP 100513/thunderbird)] [New Thread 801802400 (LWP 100155/thunderbird)] (gdb) bt #0 0x00000008011b928a in thr_kill () from /lib/libc.so.7 #1 0x000000080302aa8b in XRE_InstallX11ErrorHandler () from /usr/local/lib/thunderbird/libxul.so #2 0x0000000800f373f6 in swapcontext () from /lib/libthr.so.3 #3 0x0000000800f36ff3 in sigaction () from /lib/libthr.so.3 #4 #5 0x0000000800f37f3a in pthread_mutex_lock () from /lib/libthr.so.3 #6 0x00000008011edb83 in sbrk () from /lib/libc.so.7 #7 0x00000008011d93e8 in syscall () from /lib/libc.so.7 #8 0x00000008011f5417 in malloc () from /lib/libc.so.7 #9 0x0000000809328c14 in mallocWithAlarm () from /usr/local/lib/libsqlite3.so.8 #10 0x000000080931dcf0 in sqlite3DbMallocRaw () from /usr/local/lib/libsqlite3.so.8 #11 0x000000080931b200 in sqlite3VdbeMemGrow () from /usr/local/lib/libsqlite3.so.8 #12 0x00000008093bd6d0 in allocateCursor () from /usr/local/lib/libsqlite3.so.8 #13 0x00000008093b063f in sqlite3VdbeExec () from /usr/local/lib/libsqlite3.so.8 #14 0x000000080931a018 in sqlite3_step () from /usr/local/lib/libsqlite3.so.8 #15 0x0000000803da0658 in std::__1::basic_filebuf >::basic_filebuf () from /usr/local/lib/thunderbird/libxul.so #16 0x0000000803d9be3d in std::__1::basic_filebuf >::basic_filebuf () from /usr/local/lib/thunderbird/libxul.so ---Type to continue, or q to quit--- #17 0x0000000803d9bcfb in std::__1::basic_filebuf >::basic_filebuf () from /usr/local/lib/thunderbird/libxul.so #18 0x0000000803d9c8ad in std::__1::basic_filebuf >::basic_filebuf () from /usr/local/lib/thunderbird/libxul.so #19 0x00000008046cc9be in XRE_AddJarManifestLocation () from /usr/local/lib/thunderbird/libxul.so #20 0x000000080468bc09 in std::__1::__tree, std::__1::allocator >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type, std::__1::__map_value_compare, std::__1::allocator >, std::__1::map, std::__1::allocator >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator to continue, or q to quit--- r> >, std::__1::basic_string, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, std::__1::basic_string, std::__1::allocator > > > >::__value_type> >::destroy () from /usr/local/lib/thunderbird/libxul.so #21 0x00000008046cbdad in XRE_AddJarManifestLocation () from /usr/local/lib/thunderbird/libxul.so #22 0x0000000801d59a1a in PR_GetThreadName () from /usr/local/lib/libplds4.so.1 #23 0x0000000800f324a4 in pthread_create () from /lib/libthr.so.3 #24 0x0000000000000000 in ?? () Both of them are at their latest versions from actual ports tree. I haven't seen this on stable/9. From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 18:00:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 78D27D00; Thu, 30 Jan 2014 18:00:27 +0000 (UTC) Message-ID: <52EA933B.6030307@FreeBSD.org> Date: Thu, 30 Jan 2014 13:00:27 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kenneth Culver , Sevan / Venture37 Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" References: <52B72D09-62E0-4D36-9D56-F45D4D223382@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "huanghwh@gmail.com" , "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:00:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-30 07:53:41 -0500, Kenneth Culver wrote: > Disabling background compilation fixed my issues. > > On Wednesday, January 29, 2014, Sevan / Venture37 > wrote: > >> On 29 Jan 2014, at 01:13, Huang Wen Hui > > wrote: >> >>> I got the same problem on FreeBSD 10, disable Background >>> Compilation >> seems to fixed this problem. >> >> Patched & rebuild openjdk6, I was able to complete the opennms >> built process so I thought I'd restart it to double check, build >> process froze with java process in a state of uwait. Aborted >> after 4 hours & restarted once more. We are well aware of this problem and trying hard to fix it ATM. However, debugging process is very slow because I cannot reproduce the problem at all. ale@ is providing some core dumps and I am trying to figure out what's happening. I know some objects are getting free()'ed earlier than expected, which is ultimately causing SIGSEGV or SIGBUS *later*. So, I need more information. Please send the following information *privately*. grep -B 3 -C 8 CPU: /var/run/dmesg.boot cd /usr/ports/java/openjdk6 && make -V CC -V CFLAGS -V CXX -V CXXFLAGS In the mean time, it seems disabling background compilation (-Xbatch) significantly reduces chance of crashes as you already found out. Obviously, disabling JIT compilation (-Xint) should always work. Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJS6pM6AAoJEHyflib82/FGV3cIAJUr0Ra1+Dfeuj/cOmKsWfF4 ETn5eZWoN/Fpw+wUbLXyy47WyssL3yEYykXNBhaAKUEoTlFy8wQ6+ovJw83bSaSk dvxg7ZGfAh/Q8MD8pxRSFnkn+SNVOmu4hVp3RyYFMWnz1ml5MRUF3yt7Da3XIwum a2Yxn78K1Q1Rq1bbwSS9caRK+UbVH1SzSHTUUc3M+hoLbP08vhJXhENQNEd1YRxc AxHwM3SO6rX5Ff6jv6bZyylZd6l4GJ8KXxCitlnhWNkyS2vh8iA62scVq8KUiNdt XNV/P0nKfXPOh+sSPTxRaWoFrFJHzYimaihANWq6X2lO5yz8ee70VWt8akDCWEY= =GMnm -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 18:59:45 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F916390; Thu, 30 Jan 2014 18:59:45 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B52D21A26; Thu, 30 Jan 2014 18:59:44 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0UIxebS069698; Thu, 30 Jan 2014 20:59:40 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0UIxd71069586; Thu, 30 Jan 2014 18:59:39 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 30 Jan 2014 18:59:39 GMT Message-Id: <201401301859.s0UIxd71069586@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 18:59:45 -0000 TB --- 2014-01-30 15:00:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-30 15:00:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-30 15:00:42 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-30 15:00:42 - cleaning the object tree TB --- 2014-01-30 15:01:39 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-30 15:01:45 - At svn revision 261289 TB --- 2014-01-30 15:01:46 - building world TB --- 2014-01-30 15:01:46 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 15:01:46 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 15:01:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 15:01:46 - SRCCONF=/dev/null TB --- 2014-01-30 15:01:46 - TARGET=i386 TB --- 2014-01-30 15:01:46 - TARGET_ARCH=i386 TB --- 2014-01-30 15:01:46 - TZ=UTC TB --- 2014-01-30 15:01:46 - __MAKE_CONF=/dev/null TB --- 2014-01-30 15:01:46 - cd /src TB --- 2014-01-30 15:01:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 30 15:01:57 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 30 18:35:38 UTC 2014 TB --- 2014-01-30 18:35:38 - generating LINT kernel config TB --- 2014-01-30 18:35:38 - cd /src/sys/i386/conf TB --- 2014-01-30 18:35:38 - /usr/bin/make -B LINT TB --- 2014-01-30 18:35:38 - cd /src/sys/i386/conf TB --- 2014-01-30 18:35:38 - /usr/sbin/config -m LINT TB --- 2014-01-30 18:35:38 - building LINT kernel TB --- 2014-01-30 18:35:38 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 18:35:38 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 18:35:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 18:35:38 - SRCCONF=/dev/null TB --- 2014-01-30 18:35:38 - TARGET=i386 TB --- 2014-01-30 18:35:38 - TARGET_ARCH=i386 TB --- 2014-01-30 18:35:38 - TZ=UTC TB --- 2014-01-30 18:35:38 - __MAKE_CONF=/dev/null TB --- 2014-01-30 18:35:38 - cd /src TB --- 2014-01-30 18:35:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 30 18:35:38 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-30 18:59:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-30 18:59:38 - ERROR: failed to build LINT kernel TB --- 2014-01-30 18:59:38 - 10816.16 user 3442.55 system 14336.69 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Jan 30 20:47:52 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914692B6; Thu, 30 Jan 2014 20:47:52 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-03.shaw.ca [64.59.136.139]) by mx1.freebsd.org (Postfix) with ESMTP id 55BD01398; Thu, 30 Jan 2014 20:47:51 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=ryrf5q5p6c4dCQYR2lAej91p2ozDt6sfPnRAuS/Q8hc= c=1 sm=1 a=UVcHzDrGFPwA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=2ZXkF38bAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=VpqCP0fW7iNGqdgOsJoA:9 a=CjuIK1q_8ugA:10 a=XB88bQRR1OQA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 30 Jan 2014 13:47:44 -0700 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 222AF9BCD; Thu, 30 Jan 2014 12:47:43 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.7/8.14.7) with ESMTP id s0UKliXK005726; Thu, 30 Jan 2014 12:47:44 -0800 (PST) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201401302047.s0UKliXK005726@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: stable@freebsd.org, i386@freebsd.org Subject: Re: [releng_10 tinderbox] failure on i386/i386 In-Reply-To: Message from FreeBSD Tinderbox of "Thu, 30 Jan 2014 18:59:39 +0000." <201401301859.s0UIxd71069586@worker01.tb.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 2014 12:47:44 -0800 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Cy Schubert List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 20:47:52 -0000 In message <201401301859.s0UIxd71069586@worker01.tb.des.no>, FreeBSD Tinderbox writes: > TB --- 2014-01-30 15:00:42 - tinderbox 2.20 running on worker01.tb.des.no > TB --- 2014-01-30 15:00:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBS > D 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daem > onology.net:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2014-01-30 15:00:42 - starting RELENG_10 tinderbox run for i386/i386 > TB --- 2014-01-30 15:00:42 - cleaning the object tree > TB --- 2014-01-30 15:01:39 - /usr/local/bin/svn stat --no-ignore /src > TB --- 2014-01-30 15:01:45 - At svn revision 261289 > TB --- 2014-01-30 15:01:46 - building world > TB --- 2014-01-30 15:01:46 - CROSS_BUILD_TESTING=YES > TB --- 2014-01-30 15:01:46 - MAKEOBJDIRPREFIX=/obj > TB --- 2014-01-30 15:01:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-01-30 15:01:46 - SRCCONF=/dev/null > TB --- 2014-01-30 15:01:46 - TARGET=i386 > TB --- 2014-01-30 15:01:46 - TARGET_ARCH=i386 > TB --- 2014-01-30 15:01:46 - TZ=UTC > TB --- 2014-01-30 15:01:46 - __MAKE_CONF=/dev/null > TB --- 2014-01-30 15:01:46 - cd /src > TB --- 2014-01-30 15:01:46 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> World build started on Thu Jan 30 15:01:57 UTC 2014 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Thu Jan 30 18:35:38 UTC 2014 > TB --- 2014-01-30 18:35:38 - generating LINT kernel config > TB --- 2014-01-30 18:35:38 - cd /src/sys/i386/conf > TB --- 2014-01-30 18:35:38 - /usr/bin/make -B LINT > TB --- 2014-01-30 18:35:38 - cd /src/sys/i386/conf > TB --- 2014-01-30 18:35:38 - /usr/sbin/config -m LINT > TB --- 2014-01-30 18:35:38 - building LINT kernel > TB --- 2014-01-30 18:35:38 - CROSS_BUILD_TESTING=YES > TB --- 2014-01-30 18:35:38 - MAKEOBJDIRPREFIX=/obj > TB --- 2014-01-30 18:35:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-01-30 18:35:38 - SRCCONF=/dev/null > TB --- 2014-01-30 18:35:38 - TARGET=i386 > TB --- 2014-01-30 18:35:38 - TARGET_ARCH=i386 > TB --- 2014-01-30 18:35:38 - TZ=UTC > TB --- 2014-01-30 18:35:38 - __MAKE_CONF=/dev/null > TB --- 2014-01-30 18:35:38 - cd /src > TB --- 2014-01-30 18:35:38 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Thu Jan 30 18:35:38 UTC 2014 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd. > h:73: > /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different > kind of symbol > extern cpu_tick_f *cpu_ticks; > ^ > ./machine/cpu.h:86:10: note: previous definition is here > return (cpu_ticks()); > ^ > 2 errors generated. > *** Error code 1 > > Stop. > bmake[1]: stopped in /obj/i386.i386/src/sys/LINT > *** Error code 1 > > Stop. > bmake: stopped in /src > *** [buildkernel] Error code 1 > > Stop in /src. > TB --- 2014-01-30 18:59:38 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2014-01-30 18:59:38 - ERROR: failed to build LINT kernel > TB --- 2014-01-30 18:59:38 - 10816.16 user 3442.55 system 14336.69 real Haven't tested this yet but this should fix 10-STABLE and -CURRENT. Index: acpi_wakeup.c =================================================================== --- acpi_wakeup.c (revision 261221) +++ acpi_wakeup.c (working copy) @@ -43,7 +43,9 @@ #include #include +#ifdef __amd64__ #include +#endif #include #include #include -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 00:33:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07532914; Fri, 31 Jan 2014 00:33:57 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9425A164B; Fri, 31 Jan 2014 00:33:56 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id s0V0XhRn012850; Thu, 30 Jan 2014 17:33:43 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id s0V0XguJ012849; Thu, 30 Jan 2014 17:33:42 -0700 (MST) (envelope-from ken) Date: Thu, 30 Jan 2014 17:33:42 -0700 From: "Kenneth D. Merry" To: Garrett Wollman Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <20140131003342.GA11755@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <21225.38749.179621.454579@khavrinen.csail.mit.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 00:33:57 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 29, 2014 at 19:05:49 -0500, Garrett Wollman wrote: > < said: > > > Are you booting off of the controller? If not, could you try building mps > > as a module and unloading it? Perhaps the memory would get freed when the > > module is unloaded and the redzone code would show where the problem is. > > I built a memory-stick image and tried this. No redzone messages, but > the driver leaks 18 allocations (142336 bytes). The attached patch should fix the leaked allocations. I'm CCing Steve and Kashyap at LSI so that they can verify that this is the right place to do the mapping shutdown. I don't know yet why that particular change is causing problems. Perhaps it just moved things around and exposed an existing problem. The fact that the redzone code doesn't expose any problems makes it more likely that it is a problem other than a heap overflow. Since it is consistent, is there any chance you could hook up remote gdb to the box and poke around when it crashes? Perhaps you'll see something interesting that will point to the problem. Ken -- Kenneth Merry ken@FreeBSD.ORG --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mps_memory_leak.20140130.txt" ==== //depot/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c#8 - /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c ==== *** /tmp/tmp.75208.67 Thu Jan 30 17:13:27 2014 --- /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c Thu Jan 30 17:12:59 2014 *************** *** 1621,1626 **** --- 1621,1629 ---- /* Turn off the watchdog */ mps_lock(sc); sc->mps_flags |= MPS_FLAGS_SHUTDOWN; + + mps_mapping_exit(sc); + mps_unlock(sc); /* Lock must not be held for this */ callout_drain(&sc->periodic); --bg08WKrSYDhXBjb5-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 02:29:47 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDF88AD7; Fri, 31 Jan 2014 02:29:46 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECB41F4C; Fri, 31 Jan 2014 02:29:45 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0V2Tfep048346; Fri, 31 Jan 2014 04:29:41 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0V2Tfi2048284; Fri, 31 Jan 2014 02:29:41 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Jan 2014 02:29:41 GMT Message-Id: <201401310229.s0V2Tfi2048284@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 02:29:47 -0000 TB --- 2014-01-30 22:30:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-30 22:30:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-30 22:30:42 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-30 22:30:42 - cleaning the object tree TB --- 2014-01-30 22:31:40 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-30 22:31:47 - At svn revision 261303 TB --- 2014-01-30 22:31:48 - building world TB --- 2014-01-30 22:31:48 - CROSS_BUILD_TESTING=YES TB --- 2014-01-30 22:31:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-30 22:31:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-30 22:31:48 - SRCCONF=/dev/null TB --- 2014-01-30 22:31:48 - TARGET=i386 TB --- 2014-01-30 22:31:48 - TARGET_ARCH=i386 TB --- 2014-01-30 22:31:48 - TZ=UTC TB --- 2014-01-30 22:31:48 - __MAKE_CONF=/dev/null TB --- 2014-01-30 22:31:48 - cd /src TB --- 2014-01-30 22:31:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 30 22:31:58 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 31 02:05:44 UTC 2014 TB --- 2014-01-31 02:05:44 - generating LINT kernel config TB --- 2014-01-31 02:05:44 - cd /src/sys/i386/conf TB --- 2014-01-31 02:05:44 - /usr/bin/make -B LINT TB --- 2014-01-31 02:05:44 - cd /src/sys/i386/conf TB --- 2014-01-31 02:05:44 - /usr/sbin/config -m LINT TB --- 2014-01-31 02:05:44 - building LINT kernel TB --- 2014-01-31 02:05:44 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 02:05:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 02:05:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 02:05:44 - SRCCONF=/dev/null TB --- 2014-01-31 02:05:44 - TARGET=i386 TB --- 2014-01-31 02:05:44 - TARGET_ARCH=i386 TB --- 2014-01-31 02:05:44 - TZ=UTC TB --- 2014-01-31 02:05:44 - __MAKE_CONF=/dev/null TB --- 2014-01-31 02:05:44 - cd /src TB --- 2014-01-31 02:05:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 31 02:05:45 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-31 02:29:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-31 02:29:40 - ERROR: failed to build LINT kernel TB --- 2014-01-31 02:29:40 - 10833.03 user 3457.57 system 14338.07 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 08:23:47 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D9EA510 for ; Fri, 31 Jan 2014 08:23:47 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B89C167F for ; Fri, 31 Jan 2014 08:23:47 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id m12so9006080iga.1 for ; Fri, 31 Jan 2014 00:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=OHZ9cCQtcMKrBqc90xPhiObjLbaM8nMdCCMILnRyq4Q=; b=ImK7e1rxG7fIcfE5f2fsTJqNtyNLjGUpuAbTfKuMBzoshx1mWdQyjPl62j+J0YqWvv G88Exvi69iphaG3L1lLI2PbfK9V1U7++dbHqUrcdWGi5bG6//osKzNaMfUl2FlQ82oyK 96NyZi7UOo+9I9TXQ7Gn1rtz65E4ScXfRiea0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=OHZ9cCQtcMKrBqc90xPhiObjLbaM8nMdCCMILnRyq4Q=; b=AdNe+SDKaR87QKNhdJ3/hbKFRtpzCnTl+Gh9AMgSoxiAA98o99QodVD8PSJCDIXEzq XCI0gOEwtsO4WnVyh2jFC2AxHRBSkk9lzMXjw0trdtYPaTPyj8PCPq0EfM2oGRa4d6ER qnz0RF0eMNJiJ6rwqsyzMCrqNQ17MgFzwj+Qgav1H1tURbn0u8TWVUpw+rYnzSGDIDAM o81fxsRgPHVsJktsfPE5UDfJ/Muf8BbuInhjcih1n9pq6Y0N9Yid1vZqHEfsnazt1RJ2 8v0XinUI4UAAKTfIt3NyiRD+o98I/tDvECBpU5lhAHR04NW4yxr/Af+oauLhkkGKDJSg U4wg== X-Gm-Message-State: ALoCoQnfOSH8H79KDuf45e8yK49cBpNehs+J9n/DVIXnHVmEkr3jnbd8Y3m1D1FivqG3jSl6mm8V X-Received: by 10.42.96.196 with SMTP id k4mr5740989icn.5.1391156626797; Fri, 31 Jan 2014 00:23:46 -0800 (PST) Received: from [172.31.35.12] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id t4sm88336504igm.10.2014.01.31.00.23.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 00:23:44 -0800 (PST) Subject: Sendmail/sasl2 LDADD. LDFLAGS FreeBSD 10-STABLE From: Jason Hellenthal Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-83DEFB7C-6E8E-4DB3-9966-3C5F57EBA707; protocol="application/pkcs7-signature" X-Mailer: iPhone Mail (11B554a) Message-Id: <62BE46C5-FEC6-481B-A0AE-06D594489953@dataix.net> Date: Fri, 31 Jan 2014 03:23:42 -0500 To: "[FreeBSD Stable]" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 08:23:47 -0000 --Apple-Mail-83DEFB7C-6E8E-4DB3-9966-3C5F57EBA707 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It appears make.conf and src.conf settings are not being passed through to t= he build of sendmail and related utilities. Could someone look into this further ? I have no further time that I can spe= nd with it. Specifically I had to add -L/usr/local/lib manually to the Makefile LDADDFLA= GS because -lsasl2 could not be found. Or is there another way that we are d= oing this with base OpenSSL ? Thank you. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN= --Apple-Mail-83DEFB7C-6E8E-4DB3-9966-3C5F57EBA707 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEzMTA4MjM0M1owIwYJKoZIhvcN AQkEMRYEFIz2HCXayWArvDW2DX2qUlRJjER3MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAcRy8IuDyXtHQ5RGWI25Z S18Bl2O2jCfXIzSWtEeX9tk+JydOF/zdzrNCR5JW7KYwlVMRifM4thfrGkleoN2l9w1FhquDpjIK hgBzRwMP6x3nLckH6bOz3+F0Xus2oeLSvs1e+FLf/W3iGyKqSpXcKy1qP9zT5NiRPRsN6sVSi+bV Es4DPZyUV27t5LPqDAC6+pEzrhxWVDgD0VK2j8AvWsHBZZhp5k/NUSRNa1wFW8rM9DuOmLtY7ZrP 26+6bM1nXY1PowdcVkADkSyRRMQwRlIol02QAU/w2tlryu33XgPeZRmqEvm1obCCN/1RRprMExc9 JO5wd2Qi3yCuDGWEAwAAAAAAAA== --Apple-Mail-83DEFB7C-6E8E-4DB3-9966-3C5F57EBA707-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 09:04:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BD802D6; Fri, 31 Jan 2014 09:04:50 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58C331926; Fri, 31 Jan 2014 09:04:49 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so3274043lbv.10 for ; Fri, 31 Jan 2014 01:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6FDK17fXWuV4uKepEnTlgsP5Y84mcD7qdW8DEbat0pk=; b=zmK0ou2t5WkIgFDgmEVHiE8lcpJl43DxgC0LQjH84nbffuaZCDK/xSnAgYjAHAz2ri ltwVIa9uSKFzK/JeotCJvbbJunWrKGWscdyNZubrWdo3zCeKEQoF0hpHtPMYAYzQK+8j i6ynvpYXoEmWiJ3BgHPH/NiOMWgLu2ktd0QljC8HVAkel2Adh1QmP0cj2+s/uhvvshAA v/0EDv2HVdATgQmZ9s7sGnMMwqln+IP3mOChQQKoTf7tq67vLL2TbYi9KL2UqAIwH9/Q 1/fcdT1j+qfQy4WnU9O13UnyqT8hby95Jng30NCn1qWBuuzoy+8zeKrTr87yzh22y0mG 3jFQ== MIME-Version: 1.0 X-Received: by 10.152.88.82 with SMTP id be18mr12814768lab.3.1391159087220; Fri, 31 Jan 2014 01:04:47 -0800 (PST) Received: by 10.112.89.168 with HTTP; Fri, 31 Jan 2014 01:04:47 -0800 (PST) In-Reply-To: <52EA933B.6030307@FreeBSD.org> References: <52B72D09-62E0-4D36-9D56-F45D4D223382@gmail.com> <52EA933B.6030307@FreeBSD.org> Date: Fri, 31 Jan 2014 17:04:47 +0800 Message-ID: Subject: Re: openjdk6 - FreeBSD 10.0-RELEASE - dies with "exited on signal 6" From: Huang Wen Hui To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Kenneth Culver , Sevan / Venture37 , "freebsd-stable@freebsd.org" , "freebsd-java@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: huanghwh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 09:04:50 -0000 I have a system hit this kind of problem very often while building java/jboss72, I can give you access for debugging if you need. Thanks, Huang Wen Hui 2014-01-31 Jung-uk Kim : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2014-01-30 07:53:41 -0500, Kenneth Culver wrote: > > Disabling background compilation fixed my issues. > > > > On Wednesday, January 29, 2014, Sevan / Venture37 > > wrote: > > > >> On 29 Jan 2014, at 01:13, Huang Wen Hui >> > wrote: > >> > >>> I got the same problem on FreeBSD 10, disable Background > >>> Compilation > >> seems to fixed this problem. > >> > >> Patched & rebuild openjdk6, I was able to complete the opennms > >> built process so I thought I'd restart it to double check, build > >> process froze with java process in a state of uwait. Aborted > >> after 4 hours & restarted once more. > > We are well aware of this problem and trying hard to fix it ATM. > However, debugging process is very slow because I cannot reproduce the > problem at all. ale@ is providing some core dumps and I am trying to > figure out what's happening. I know some objects are getting > free()'ed earlier than expected, which is ultimately causing SIGSEGV > or SIGBUS *later*. So, I need more information. Please send the > following information *privately*. > > grep -B 3 -C 8 CPU: /var/run/dmesg.boot > cd /usr/ports/java/openjdk6 && make -V CC -V CFLAGS -V CXX -V CXXFLAGS > > In the mean time, it seems disabling background compilation (-Xbatch) > significantly reduces chance of crashes as you already found out. > Obviously, disabling JIT compilation (-Xint) should always work. > > Thanks, > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) > > iQEcBAEBAgAGBQJS6pM6AAoJEHyflib82/FGV3cIAJUr0Ra1+Dfeuj/cOmKsWfF4 > ETn5eZWoN/Fpw+wUbLXyy47WyssL3yEYykXNBhaAKUEoTlFy8wQ6+ovJw83bSaSk > dvxg7ZGfAh/Q8MD8pxRSFnkn+SNVOmu4hVp3RyYFMWnz1ml5MRUF3yt7Da3XIwum > a2Yxn78K1Q1Rq1bbwSS9caRK+UbVH1SzSHTUUc3M+hoLbP08vhJXhENQNEd1YRxc > AxHwM3SO6rX5Ff6jv6bZyylZd6l4GJ8KXxCitlnhWNkyS2vh8iA62scVq8KUiNdt > XNV/P0nKfXPOh+sSPTxRaWoFrFJHzYimaihANWq6X2lO5yz8ee70VWt8akDCWEY= > =GMnm > -----END PGP SIGNATURE----- > From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 10:00:06 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FCD12BF; Fri, 31 Jan 2014 10:00:06 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 852191EF0; Fri, 31 Jan 2014 10:00:05 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0V9xsmJ025334; Fri, 31 Jan 2014 11:59:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0V9xsRe025206; Fri, 31 Jan 2014 09:59:54 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Jan 2014 09:59:54 GMT Message-Id: <201401310959.s0V9xsRe025206@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:00:06 -0000 TB --- 2014-01-31 06:00:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-31 06:00:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-31 06:00:43 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-31 06:00:43 - cleaning the object tree TB --- 2014-01-31 06:01:41 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-31 06:01:47 - At svn revision 261314 TB --- 2014-01-31 06:01:48 - building world TB --- 2014-01-31 06:01:48 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 06:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 06:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 06:01:48 - SRCCONF=/dev/null TB --- 2014-01-31 06:01:48 - TARGET=i386 TB --- 2014-01-31 06:01:48 - TARGET_ARCH=i386 TB --- 2014-01-31 06:01:48 - TZ=UTC TB --- 2014-01-31 06:01:48 - __MAKE_CONF=/dev/null TB --- 2014-01-31 06:01:48 - cd /src TB --- 2014-01-31 06:01:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 31 06:01:59 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 31 09:35:56 UTC 2014 TB --- 2014-01-31 09:35:56 - generating LINT kernel config TB --- 2014-01-31 09:35:56 - cd /src/sys/i386/conf TB --- 2014-01-31 09:35:56 - /usr/bin/make -B LINT TB --- 2014-01-31 09:35:56 - cd /src/sys/i386/conf TB --- 2014-01-31 09:35:56 - /usr/sbin/config -m LINT TB --- 2014-01-31 09:35:56 - building LINT kernel TB --- 2014-01-31 09:35:56 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 09:35:56 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 09:35:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 09:35:56 - SRCCONF=/dev/null TB --- 2014-01-31 09:35:56 - TARGET=i386 TB --- 2014-01-31 09:35:56 - TARGET_ARCH=i386 TB --- 2014-01-31 09:35:56 - TZ=UTC TB --- 2014-01-31 09:35:56 - __MAKE_CONF=/dev/null TB --- 2014-01-31 09:35:56 - cd /src TB --- 2014-01-31 09:35:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 31 09:35:56 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-31 09:59:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-31 09:59:53 - ERROR: failed to build LINT kernel TB --- 2014-01-31 09:59:53 - 10826.23 user 3446.59 system 14349.85 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 10:35:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C000E6C for ; Fri, 31 Jan 2014 10:35:06 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E03211DD for ; Fri, 31 Jan 2014 10:35:05 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1W9BR4-0002lI-MD for freebsd-stable@freebsd.org; Fri, 31 Jan 2014 02:34:58 -0800 Date: Fri, 31 Jan 2014 02:34:58 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1391164498680-5881745.post@n5.nabble.com> In-Reply-To: <52EA5FE9.2040607@fsn.hu> References: <52EA5FE9.2040607@fsn.hu> Subject: Re: thunderbird and firefox crashes on stable/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:35:06 -0000 www/firefox here (10.0-STABLE #0 r261219) behaves identically to stable/9 (sometimes waits on exit, but that's all), but I don't have thunderbird installed. -- View this message in context: http://freebsd.1045724.n5.nabble.com/thunderbird-and-firefox-crashes-on-stable-10-tp5881526p5881745.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 13:33:42 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326678C8; Fri, 31 Jan 2014 13:33:42 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1799114B; Fri, 31 Jan 2014 13:33:41 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id s0VDXewE004776; Fri, 31 Jan 2014 05:33:40 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id s0VDXenY004775; Fri, 31 Jan 2014 05:33:40 -0800 (PST) (envelope-from david) Date: Fri, 31 Jan 2014 05:33:40 -0800 From: David Wolfskill To: stable@freebsd.org, i386@freebsd.org Subject: Re: [releng_10 tinderbox] failure on i386/i386 Message-ID: <20140131133340.GH1620@albert.catwhisker.org> References: <201401301859.s0UIxd71069586@worker01.tb.des.no> <201401302047.s0UKliXK005726@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LiQwW4YX+w4axhAx" Content-Disposition: inline In-Reply-To: <201401302047.s0UKliXK005726@slippy.cwsent.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 13:33:42 -0000 --LiQwW4YX+w4axhAx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 30, 2014 at 12:47:44PM -0800, Cy Schubert wrote: > In message <201401301859.s0UIxd71069586@worker01.tb.des.no>, FreeBSD=20 > Tinderbox > writes: > > ... > > >>> Kernel build for LINT started on Thu Jan 30 18:35:38 UTC 2014 > > >>> stage 1: configuring the kernel > > >>> stage 2.1: cleaning up the object tree > > >>> stage 2.2: rebuilding the object tree > > >>> stage 2.3: build tools > > >>> stage 3.1: making dependencies > > >>> stage 3.2: building everything > > [...] > > In file included from /src/sys/contrib/dev/acpica/include/platform/acfr= eebsd. > > h:73: > > /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as diff= erent=20 > > kind of symbol > > extern cpu_tick_f *cpu_ticks; > > ^ > > ./machine/cpu.h:86:10: note: previous definition is here > > return (cpu_ticks()); > > ^ > > 2 errors generated. > > *** Error code 1 > >=20 > > Stop. > > bmake[1]: stopped in /obj/i386.i386/src/sys/LINT > > *** Error code 1 > >=20 > > Stop. > > bmake: stopped in /src > > *** [buildkernel] Error code 1 > >=20 > > Stop in /src. > > TB --- 2014-01-30 18:59:38 - WARNING: /usr/bin/make returned exit code = 1=20 > > TB --- 2014-01-30 18:59:38 - ERROR: failed to build LINT kernel > > TB --- 2014-01-30 18:59:38 - 10816.16 user 3442.55 system 14336.69 real >=20 >=20 > Haven't tested this yet but this should fix 10-STABLE and -CURRENT. >=20 > Index: acpi_wakeup.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 > --- acpi_wakeup.c (revision 261221) > +++ acpi_wakeup.c (working copy) > @@ -43,7 +43,9 @@ > #include > =20 > #include > +#ifdef __amd64__ > #include > +#endif > #include > #include > #include > ... I encountered the above in my GENERIC-based laptop kernel ("CANARY"), and Cy's suggested fix does allow me to build, install, and boot a new kernel that seems to work: FreeBSD g1-251.catwhisker.org 10.0-STABLE FreeBSD 10.0-STABLE #1144 r26131= 3M/261318:1000702: Fri Jan 31 05:10:02 PST 2014 root@g1-251.catwhisker.= org:/common/S3/obj/usr/src/sys/CANARY i386 Yesterday, I had updated sources to stable/10 @r261288; today, @r261313 (as depicted above). Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --LiQwW4YX+w4axhAx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJS66YzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7OmkP/1vcjeRwxZHFirxjKLYVDHv7 GoaurAnXaFF6k6khXJJCA0yLyU9TJIN8Oq2VdIdRtrj6xeEKEoYiQRjEK4JKaIMQ 4eR+nwxhGTtIMW2CFDIVYnlGkNO1zpjrC4bkSdcfDHLK4NWWPjw93QI1/R+m8eHC QDJAcEVN+ibHZ8+MIFu+r2zWioruzKr2axGqSWzFD+gYOb7HwbAq3o0QssioJDTg P5tqH/c+YbOtnjRrYSOdAyn1vDMLdWYOIEyTrq3VlznTipSfiGBmK/EkwPE7iZLj UkTNgAPc1zUdlkeDa/B9UhWL4K7HeUa5FpbOKc7anVjULUUvpBkwK6dx9y3xkY2T xwMiEjBX47LPiHACL12eh5jV9ZQqQOT87T16pt1n1fZ5m9U7Bl10z/aeiQ+Crgyx oYRiltHaxx7rTD7NLEH7tx8A2OH3Fm077EXtqsp+VSIxDtB3B7G8lrr+v/kFQ/wz H7NYOCwAUTb3lc/mwEvBLr9t7rMEzZ8JHkLoJi3fcMXypQug/y1EVWHTvmVYSiM6 +I7kaxDtjnhbP/RYd/qx0ahc5kuTkgsJPL5SqsyRcaLUAdCM8kX9qIVoPIlJyycU 5bSN5vmGfr6kcIfJ826NNBy7qfMm+BEL6B+1lOh/P/lv2w1jscIYSFwuCcRXQn9T vDwdS7uEErYsW8crDGjl =Awiz -----END PGP SIGNATURE----- --LiQwW4YX+w4axhAx-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 14:07:06 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58999110; Fri, 31 Jan 2014 14:07:06 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83D64139D; Fri, 31 Jan 2014 14:07:04 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0VE71Id045320; Fri, 31 Jan 2014 16:07:01 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0VE71WL045125; Fri, 31 Jan 2014 14:07:01 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Jan 2014 14:07:01 GMT Message-Id: <201401311407.s0VE71WL045125@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:07:06 -0000 TB --- 2014-01-31 13:30:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-31 13:30:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-31 13:30:42 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-01-31 13:30:42 - cleaning the object tree TB --- 2014-01-31 13:30:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-31 13:31:29 - At svn revision 261320 TB --- 2014-01-31 13:31:30 - building world TB --- 2014-01-31 13:31:30 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 13:31:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 13:31:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 13:31:30 - SRCCONF=/dev/null TB --- 2014-01-31 13:31:30 - TARGET=arm TB --- 2014-01-31 13:31:30 - TARGET_ARCH=arm TB --- 2014-01-31 13:31:30 - TZ=UTC TB --- 2014-01-31 13:31:30 - __MAKE_CONF=/dev/null TB --- 2014-01-31 13:31:30 - cd /src TB --- 2014-01-31 13:31:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 31 13:31:41 UTC 2014 >>> 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 [...] ranlib libclangparse.a ===> lib/clang/libclangsema (all) c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp -o AnalysisBasedWarnings.o /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h: In member function 'bool clang::RecursiveASTVisitor::TraverseStmt(clang::Stmt*) [with Derived = ::FallthroughMapper]': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h:523: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangsema *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-01-31 14:07:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-31 14:07:00 - ERROR: failed to build world TB --- 2014-01-31 14:07:00 - 1685.69 user 495.98 system 2178.22 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 14:57:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B52B5DBD for ; Fri, 31 Jan 2014 14:57:28 +0000 (UTC) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2974A179C for ; Fri, 31 Jan 2014 14:57:27 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so3567977lbv.10 for ; Fri, 31 Jan 2014 06:57:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=gRl6vUUEyBmcbrPCC/v2FXnIDsGUK+MXbdYEm/6P13M=; b=PiyTDRzgiIcPyeg6mIpVWmJskpW1HSiti88WthaaDRsvAd9baXGJQChohVZYvhCUf7 TxTOrIwZF6uphNByc+ZGy7epIHc9SWDAxe5KzYbL24uxpJhTF4X24DVrebWUT7kGg/He +AutgV7XMN5YqN60lCXHyWXAev4qMxCo9kf28IZAAJE148EqJf9s8T6AsDs5DlPZMTqs SBCf3UxtXBYmlDE5keqvydVpHgwnfuZEggZ38rQ89POk+IS7T12qNsei5OqIZYyUY8ll gcjBfvw8qZEbn8kygRApuK9FBm61raQ8RCoHLtXW146byW8QFOwFV3Wvrbv3HbdQGM00 vNHw== X-Gm-Message-State: ALoCoQlwm6ZCHmKIhMfu7BLHqScPX1iOzFckYKb9rplIsIgBUAcZ4zj5VkcPZ1OiJ6kS76ViQ3rw X-Received: by 10.112.45.108 with SMTP id l12mr2145926lbm.21.1391180240458; Fri, 31 Jan 2014 06:57:20 -0800 (PST) Received: from zealot.ksu.ru (128-74-226-136.broadband.corbina.ru. [128.74.226.136]) by mx.google.com with ESMTPSA id sv5sm10516342lbb.9.2014.01.31.06.57.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 06:57:18 -0800 (PST) Message-ID: <52EBB9CC.2080802@li.ru> Date: Fri, 31 Jan 2014 18:57:16 +0400 From: "Marat N.Afanasyev" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: John Baldwin , Yamagi Burmeister Subject: Re: 10.0, csh history merge broken? References: <52E0E917.3060403@li.ru> <201401281147.15801.jhb@freebsd.org> <20140129090624.615af8881fe6df55c9663b5c@yamagi.org> <201401291214.56887.jhb@freebsd.org> In-Reply-To: <201401291214.56887.jhb@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000008090707040002030406" Cc: stable@freebsd.org, yerenkow@gmail.com, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:57:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000008090707040002030406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable John Baldwin wrote: > On Wednesday, January 29, 2014 3:06:24 am Yamagi Burmeister wrote: >> On Tue, 28 Jan 2014 11:47:15 -0500 >> John Baldwin wrote: >> >>> On Monday, January 27, 2014 3:55:53 am Alexander Yerenkow wrote: >>>> >Maybe it would be a good idea to cherry pick those two revisions = and >>>> >merge then into FreeBSD, until a new tcsh version is released. >>>> >>>> I think this is must, since currently any regular shutdown can break= > login >>>> ability (if server is high loaded + history file is broken and big > enough). >>>> I have now locked history file with chflags until fix will come. >>> >>> These changes are already present in HEAD (FreeBSD 11) and will proba= bly >>> be merged by the next 10 release. >> >> Really? As far as I can see the last commit to head/contrib/tcsh was >> the update to 6.18.01 one 22/02/2012 by mp@. While 6.18.01 featured a >> new, much faster history merge logic which minimized the race window, >> the root cause wasn't solve. Only the two upstream commits (from >> 08/12/2013 and 11/12/2013) linked above brought real locking to the >> merge process, serializing it between several tcsh instances. > > Bah, somehow I had thought I had seen the 'lock' keyword in tcsh on my > HEAD box, but I don't see it there now. > So, can we hope to have these patches appear in HEAD and MFC to, at=20 least, -stable soon? ;) --=20 SY, Marat --------------ms000008090707040002030406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMaTCC Bi0wggUVoAMCAQICAwdtsTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDgyOTA4MDMxM1oXDTE0MDgyOTE5MzcxNlowTzEZMBcGA1UE DRMQSXNDMTY0SkczZHE1UlBFUTEVMBMGA1UEAwwMYW1hcmF0QGxpLnJ1MRswGQYJKoZIhvcN AQkBFgxhbWFyYXRAbGkucnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8T/yW /tVUT1pvIpPVHAgMjikWgAqQrAJPY6W6wKMzPl8XzW3UwpGfzgfeLoG7J2J1t9DujQYf3qqm LWEHgj5FRv6P+9ohdOyH0OqMbG76lz5ONqNcavPdE3//fQEXSxB2SQv1qUp1Dsd522Oavx1r svWlQEkLOnv2ac2mXS86W5kyJ27Pq/6fIgxrNAziKqMm51C3FGDBUn0mofzm3+FcMA4IMOyH kpe+M+iotZaU1OD5bWq4ISH85UioOV3B2OqL0cGM3UmuUJ4Qgi9iMgGPbmsIYQ6+A5LRM1py 8u5Nckt3gSYTvdKHN6dJGcg2Z+Ja0jW+XEvKo5Z+366/Zs6xAgMBAAGjggLSMIICzjAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYD VR0OBBYEFOakEwEDLMFWYaXweQ5/FydTI94RMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMBcGA1UdEQQQMA6BDGFtYXJhdEBsaS5ydTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADtRgWXP13dZs31xY7lDiP2P8jxM05AH SOwd7Fjx6wd/zMF+NMzYKWKiPCU4grfXM5FdMvc+E17QjXFc2Acp8ERx9xbeP1YUys1eXjvK Cpo01/GXoAsnfA2p6Qrc5AVtNhrPkuqB3VrIz+ihRJtEvWHOSuHjMqmEzAAYKaCaaLMCe+j3 Yj1pnTDQXprASuQ7UlBZ9myAFppZPylRdO8pYb4M8qR93steYSwA8TdWWqKzbr7sdaatLpbt WVrjjzIp54s5Psd5hY5lHPYAL6Nx1MJYjk80v7Xh3VSbqndbOCyb1Ix699Y5DF7+B9Yq9Jrl ju8WOgP6QF/u5MegLDB7xsAwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKn u8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxah NvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//j diSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGt MIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYB BQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYI KwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBS MCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwEC ATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0G CSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY 1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7 Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQo CRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTi pgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQg WI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8 MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2N iy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhd GwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwdtsTAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAxMzEx NDU3MTZaMCMGCSqGSIb3DQEJBDEWBBTkc4k1qJSoyETk5mWtLCfZ8ifIMzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB22xMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMHbbEwDQYJKoZIhvcNAQEBBQAEggEAXT3uk77BGRzVE5IoMZKIXXIWKhYENmzJuklTlazK xcZ0yg884ClwdLrLs8XkQH0IY/QU10x19SMQ7w9yxkaytRI2p3CJHVonDjd2j5YBV9Xc04aY JxGUvKuTQWNf/u5ctxdk3KhvxLklILlLNah3uhmF6ej4uNlKhGvLlShDRWw1Oz5X1j/hqrRA LjViJ0nqtrUU3zYneLPUaJlsSRKqXFJZX7+NkeHXVy1DyKZ8uFLXIowkeXRE616sZZm/WNy4 knq9A36BWHE+v35syAul2MyGgfIEpjVNLySWr9xFhIhiqpFOjlzxCjNaCOIFYMlWlwk33v41 UNTj+vYE4ZSUqwAAAAAAAA== --------------ms000008090707040002030406-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 17:22:41 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA582931; Fri, 31 Jan 2014 17:22:41 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A00215D8; Fri, 31 Jan 2014 17:22:40 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0VHMajU035287; Fri, 31 Jan 2014 19:22:36 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0VHMawM035123; Fri, 31 Jan 2014 17:22:36 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Jan 2014 17:22:36 GMT Message-Id: <201401311722.s0VHMawM035123@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:22:41 -0000 TB --- 2014-01-31 13:30:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-31 13:30:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-31 13:30:42 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-01-31 13:30:42 - cleaning the object tree TB --- 2014-01-31 13:31:37 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-31 13:31:43 - At svn revision 261320 TB --- 2014-01-31 13:31:44 - building world TB --- 2014-01-31 13:31:44 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 13:31:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 13:31:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 13:31:44 - SRCCONF=/dev/null TB --- 2014-01-31 13:31:44 - TARGET=i386 TB --- 2014-01-31 13:31:44 - TARGET_ARCH=i386 TB --- 2014-01-31 13:31:44 - TZ=UTC TB --- 2014-01-31 13:31:44 - __MAKE_CONF=/dev/null TB --- 2014-01-31 13:31:44 - cd /src TB --- 2014-01-31 13:31:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 31 13:31:55 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Jan 31 16:59:15 UTC 2014 TB --- 2014-01-31 16:59:15 - generating LINT kernel config TB --- 2014-01-31 16:59:15 - cd /src/sys/i386/conf TB --- 2014-01-31 16:59:15 - /usr/bin/make -B LINT TB --- 2014-01-31 16:59:15 - cd /src/sys/i386/conf TB --- 2014-01-31 16:59:15 - /usr/sbin/config -m LINT TB --- 2014-01-31 16:59:15 - building LINT kernel TB --- 2014-01-31 16:59:15 - CROSS_BUILD_TESTING=YES TB --- 2014-01-31 16:59:15 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-31 16:59:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-31 16:59:15 - SRCCONF=/dev/null TB --- 2014-01-31 16:59:15 - TARGET=i386 TB --- 2014-01-31 16:59:15 - TARGET_ARCH=i386 TB --- 2014-01-31 16:59:15 - TZ=UTC TB --- 2014-01-31 16:59:15 - __MAKE_CONF=/dev/null TB --- 2014-01-31 16:59:15 - cd /src TB --- 2014-01-31 16:59:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 31 16:59:15 UTC 2014 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol extern cpu_tick_f *cpu_ticks; ^ ./machine/cpu.h:86:10: note: previous definition is here return (cpu_ticks()); ^ 2 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/i386.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-01-31 17:22:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-31 17:22:35 - ERROR: failed to build LINT kernel TB --- 2014-01-31 17:22:35 - 10728.14 user 3152.49 system 13913.16 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 17:26:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43EC8BE1 for ; Fri, 31 Jan 2014 17:26:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4EA1614 for ; Fri, 31 Jan 2014 17:26:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EB3CCB97A; Fri, 31 Jan 2014 12:26:03 -0500 (EST) From: John Baldwin To: "Marat N.Afanasyev" Subject: Re: 10.0, csh history merge broken? Date: Fri, 31 Jan 2014 12:18:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E0E917.3060403@li.ru> <201401291214.56887.jhb@freebsd.org> <52EBB9CC.2080802@li.ru> In-Reply-To: <52EBB9CC.2080802@li.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401311218.07914.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 31 Jan 2014 12:26:04 -0500 (EST) Cc: yerenkow@gmail.com, freebsd-stable@freebsd.org, Yamagi Burmeister X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:26:05 -0000 On Friday, January 31, 2014 9:57:16 am Marat N.Afanasyev wrote: > John Baldwin wrote: > > On Wednesday, January 29, 2014 3:06:24 am Yamagi Burmeister wrote: > >> On Tue, 28 Jan 2014 11:47:15 -0500 > >> John Baldwin wrote: > >> > >>> On Monday, January 27, 2014 3:55:53 am Alexander Yerenkow wrote: > >>>> >Maybe it would be a good idea to cherry pick those two revisions and > >>>> >merge then into FreeBSD, until a new tcsh version is released. > >>>> > >>>> I think this is must, since currently any regular shutdown can break > > login > >>>> ability (if server is high loaded + history file is broken and big > > enough). > >>>> I have now locked history file with chflags until fix will come. > >>> > >>> These changes are already present in HEAD (FreeBSD 11) and will probably > >>> be merged by the next 10 release. > >> > >> Really? As far as I can see the last commit to head/contrib/tcsh was > >> the update to 6.18.01 one 22/02/2012 by mp@. While 6.18.01 featured a > >> new, much faster history merge logic which minimized the race window, > >> the root cause wasn't solve. Only the two upstream commits (from > >> 08/12/2013 and 11/12/2013) linked above brought real locking to the > >> merge process, serializing it between several tcsh instances. > > > > Bah, somehow I had thought I had seen the 'lock' keyword in tcsh on my > > HEAD box, but I don't see it there now. > > > So, can we hope to have these patches appear in HEAD and MFC to, at > least, -stable soon? ;) Try asking mp@FreeBSD.org as he did the last tcsh import. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 17:26:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BA6CBE2; Fri, 31 Jan 2014 17:26:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 325401615; Fri, 31 Jan 2014 17:26:06 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E4DCB945; Fri, 31 Jan 2014 12:26:05 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Need Help With MCA Code Date: Fri, 31 Jan 2014 12:22:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52E73717.3000503@tundraware.com> <52E99381.5050803@tundraware.com> In-Reply-To: <52E99381.5050803@tundraware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401311222.12136.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 31 Jan 2014 12:26:05 -0500 (EST) Cc: Tim Daneliuk , FreeBSD Hardware Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:26:06 -0000 On Wednesday, January 29, 2014 6:49:21 pm Tim Daneliuk wrote: > Resending in hopes that people on one of the other lists will have some insight here: > > On 01/27/2014 10:50 PM, Tim Daneliuk wrote: > > I am running 9.2 stable i386 r261207. As noted earlier: > > > >> I just replaced mobo/CPU on FBSD server (Gigabyte Z-87-D3HP with > >> an Intel i3-4130). I am not overclocking ... but I continue to see this sort of thing: > > > >> MCA: CPU 0 COR (1) internal parity error > > > > Dmesg shows: > > > >> MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 0 > >> MCA: CPU 0 COR (1) internal parity error > >> MCA: Bank 0, Status 0x90000040000f0005 > >> MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000_ > > > > I've swapped CPUs (i5). I've fiddled with an endless supply of > > mobo settings. I've switched power supplies. I've moved mem > > sticks around .... No joy. > > > > So, I dug through the sources and found this: > > > > > > > > mca_log(const struct mca_record *rec) > > { > > uint16_t mca_error; > > > > printf("MCA: Bank %d, Status 0x%016llx\n", rec->mr_bank, > > (long long)rec->mr_status); > > printf("MCA: Global Cap 0x%016llx, Status 0x%016llx\n", > > (long long)rec->mr_mcg_cap, (long long)rec->mr_mcg_status); > > printf("MCA: Vendor \"%s\", ID 0x%x, APIC ID %d\n", cpu_vendor, > > rec->mr_cpu_id, rec->mr_apic_id); > > printf("MCA: CPU %d ", rec->mr_cpu); > > if (rec->mr_status & MC_STATUS_UC) > > printf("UNCOR "); > > else { > > printf("COR "); > > if (rec->mr_mcg_cap & MCG_CAP_CMCI_P) > > printf("(%lld) ", ((long long)rec->mr_status & > > MC_STATUS_COR_COUNT) >> 38); > > } > > > > > > It looks like the trailing else clause is kicking out the error but I am > > unclear what the error means, beyond the fact that it appears to be a parity > > error somewhere within the CPU's internal memory (cache?). Is this error > > getting corrected? Is this benign, Should I get a different mobo? > > > > Um .... Haaaaalp :) > > > I have now tried different motherboards, CPUs, memory, and power supplies and > this error is still showing up now and then. > > This points strongly to either FreeBSD bogus reporting, or these errors being > benign. It's hard to believe that the exact same error might occur with > completely different hardware ... unless it's being caused by the case. Are they all the same model CPU? Since it is a corrected error you can probably ignore it, but it is not bogus reporting. FreeBSD only reports these errors because they show up in registers on your CPU. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 17:26:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C15EBE3; Fri, 31 Jan 2014 17:26:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E244E1616; Fri, 31 Jan 2014 17:26:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DB9CEB958; Fri, 31 Jan 2014 12:26:07 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org, i386@freebsd.org Subject: Re: [releng_10 tinderbox] failure on i386/i386 Date: Fri, 31 Jan 2014 12:22:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401300359.s0U3xg6U014906@worker01.tb.des.no> In-Reply-To: <201401300359.s0U3xg6U014906@worker01.tb.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401311222.36037.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 31 Jan 2014 12:26:08 -0500 (EST) Cc: FreeBSD Tinderbox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:26:09 -0000 On Wednesday, January 29, 2014 10:59:42 pm FreeBSD Tinderbox wrote: > TB --- 2014-01-30 00:00:43 - tinderbox 2.20 running on worker01.tb.des.no > TB --- 2014-01-30 00:00:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2014-01-30 00:00:43 - starting RELENG_10 tinderbox run for i386/i386 > TB --- 2014-01-30 00:00:43 - cleaning the object tree > TB --- 2014-01-30 00:00:43 - /usr/local/bin/svn stat --no-ignore /src > TB --- 2014-01-30 00:01:36 - At svn revision 261278 > TB --- 2014-01-30 00:01:37 - building world > TB --- 2014-01-30 00:01:37 - CROSS_BUILD_TESTING=YES > TB --- 2014-01-30 00:01:37 - MAKEOBJDIRPREFIX=/obj > TB --- 2014-01-30 00:01:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-01-30 00:01:37 - SRCCONF=/dev/null > TB --- 2014-01-30 00:01:37 - TARGET=i386 > TB --- 2014-01-30 00:01:37 - TARGET_ARCH=i386 > TB --- 2014-01-30 00:01:37 - TZ=UTC > TB --- 2014-01-30 00:01:37 - __MAKE_CONF=/dev/null > TB --- 2014-01-30 00:01:37 - cd /src > TB --- 2014-01-30 00:01:37 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> World build started on Thu Jan 30 00:01:48 UTC 2014 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> World build completed on Thu Jan 30 03:35:43 UTC 2014 > TB --- 2014-01-30 03:35:43 - generating LINT kernel config > TB --- 2014-01-30 03:35:43 - cd /src/sys/i386/conf > TB --- 2014-01-30 03:35:43 - /usr/bin/make -B LINT > TB --- 2014-01-30 03:35:43 - cd /src/sys/i386/conf > TB --- 2014-01-30 03:35:43 - /usr/sbin/config -m LINT > TB --- 2014-01-30 03:35:43 - building LINT kernel > TB --- 2014-01-30 03:35:43 - CROSS_BUILD_TESTING=YES > TB --- 2014-01-30 03:35:43 - MAKEOBJDIRPREFIX=/obj > TB --- 2014-01-30 03:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2014-01-30 03:35:43 - SRCCONF=/dev/null > TB --- 2014-01-30 03:35:43 - TARGET=i386 > TB --- 2014-01-30 03:35:43 - TARGET_ARCH=i386 > TB --- 2014-01-30 03:35:43 - TZ=UTC > TB --- 2014-01-30 03:35:43 - __MAKE_CONF=/dev/null > TB --- 2014-01-30 03:35:43 - cd /src > TB --- 2014-01-30 03:35:43 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Thu Jan 30 03:35:43 UTC 2014 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > In file included from /src/sys/contrib/dev/acpica/include/platform/acfreebsd.h:73: > /src/sys/sys/systm.h:306:20: error: redefinition of 'cpu_ticks' as different kind of symbol > extern cpu_tick_f *cpu_ticks; > ^ > ./machine/cpu.h:86:10: note: previous definition is here > return (cpu_ticks()); > ^ My fault, will fix in a bit. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 17:49:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C26AD6E; Fri, 31 Jan 2014 17:49:06 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E273F1871; Fri, 31 Jan 2014 17:49:05 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.7/8.14.7) with ESMTP id s0VHmg1H024802 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 31 Jan 2014 11:48:42 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52EBE1FA.2040603@tundraware.com> Date: Fri, 31 Jan 2014 11:48:42 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Baldwin , freebsd-stable@freebsd.org Subject: Re: Need Help With MCA Code References: <52E73717.3000503@tundraware.com> <52E99381.5050803@tundraware.com> <201401311222.12136.jhb@freebsd.org> In-Reply-To: <201401311222.12136.jhb@freebsd.org> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Fri, 31 Jan 2014 11:48:42 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s0VHmg1H024802 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Hardware Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:49:06 -0000 On 01/31/2014 11:22 AM, John Baldwin wrote: > On Wednesday, January 29, 2014 6:49:21 pm Tim Daneliuk wrote: >> Resending in hopes that people on one of the other lists will have some insight here: >> >> On 01/27/2014 10:50 PM, Tim Daneliuk wrote: >>> I am running 9.2 stable i386 r261207. As noted earlier: >>> >>>> I just replaced mobo/CPU on FBSD server (Gigabyte Z-87-D3HP with >>>> an Intel i3-4130). I am not overclocking ... but I continue to see this sort of thing: >>> >>>> MCA: CPU 0 COR (1) internal parity error >>> >>> Dmesg shows: >>> >>>> MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 0 >>>> MCA: CPU 0 COR (1) internal parity error >>>> MCA: Bank 0, Status 0x90000040000f0005 >>>> MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000_ >>> >>> I've swapped CPUs (i5). I've fiddled with an endless supply of >>> mobo settings. I've switched power supplies. I've moved mem >>> sticks around .... No joy. >>> >>> So, I dug through the sources and found this: >>> >>> >>> >>> mca_log(const struct mca_record *rec) >>> { >>> uint16_t mca_error; >>> >>> printf("MCA: Bank %d, Status 0x%016llx\n", rec->mr_bank, >>> (long long)rec->mr_status); >>> printf("MCA: Global Cap 0x%016llx, Status 0x%016llx\n", >>> (long long)rec->mr_mcg_cap, (long long)rec->mr_mcg_status); >>> printf("MCA: Vendor \"%s\", ID 0x%x, APIC ID %d\n", cpu_vendor, >>> rec->mr_cpu_id, rec->mr_apic_id); >>> printf("MCA: CPU %d ", rec->mr_cpu); >>> if (rec->mr_status & MC_STATUS_UC) >>> printf("UNCOR "); >>> else { >>> printf("COR "); >>> if (rec->mr_mcg_cap & MCG_CAP_CMCI_P) >>> printf("(%lld) ", ((long long)rec->mr_status & >>> MC_STATUS_COR_COUNT) >> 38); >>> } >>> >>> >>> It looks like the trailing else clause is kicking out the error but I am >>> unclear what the error means, beyond the fact that it appears to be a parity >>> error somewhere within the CPU's internal memory (cache?). Is this error >>> getting corrected? Is this benign, Should I get a different mobo? >>> >>> Um .... Haaaaalp :) >> >> >> I have now tried different motherboards, CPUs, memory, and power supplies and >> this error is still showing up now and then. >> >> This points strongly to either FreeBSD bogus reporting, or these errors being >> benign. It's hard to believe that the exact same error might occur with >> completely different hardware ... unless it's being caused by the case. > > Are they all the same model CPU? Since it is a corrected error you can > probably ignore it, but it is not bogus reporting. FreeBSD only reports > these errors because they show up in registers on your CPU. > It's looking like this is an artifact of running 9.2-STABLE i386 on that hardware. I just installed 10-STABLE x64 and am beating the hardware to death and have yet to see an MCA check. It *is* possible the 9.2 install is boogered up (I went to grad school to learn how to say that), so I am pursuing a full rebuild of the server. While painful, this will also finally move this machine to x64 which is long overdue. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 19:53:31 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F2A82F8; Fri, 31 Jan 2014 19:53:31 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37022132F; Fri, 31 Jan 2014 19:53:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W9K9Z-0000V1-IR; Fri, 31 Jan 2014 19:53:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s0VJrPMe060361; Fri, 31 Jan 2014 12:53:26 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/eqz4FWOyD1bTsDwyCAGFb Subject: Re: building stable/8 on stable/10 host: is it supported? From: Ian Lepore To: Dmitry Morozovsky In-Reply-To: References: <20140130175317.6c854f50@X220.alogt.com> <20140130.191854.1571220137154550209.hrs@allbsd.org> Content-Type: multipart/mixed; boundary="=-l8aceLeNDO9lFJx2kg10" Date: Fri, 31 Jan 2014 12:53:25 -0700 Message-ID: <1391198005.13026.14.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: erichsfreebsdlist@alogt.com, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 19:53:31 -0000 --=-l8aceLeNDO9lFJx2kg10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 2014-01-30 at 17:51 +0400, Dmitry Morozovsky wrote: > On Thu, 30 Jan 2014, Dmitry Morozovsky wrote: > > > Hiroki-san, > > [snip] > > > > Currently stable/8 does not build on a box running 10 or later > > > because several commits to fix build errors at the toolchain > > > bootstrapping stages due to the toolchain migration were not MFC'd > > > yet. For stable/8, try the following patch: > > > > > > http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch.diff > > > > Thanks a lot, will try and report! > > amd64 world/kernel built successfully, thanks again. > > However, cross-build to TARGET=i386 chokes on aicasm module: > > ./aicasm -nostdinc -I. -I/FreeBSD/pristine/src.8/sys > -I/FreeBSD/pristine/src.8/sys/contrib/altq > -I/FreeBSD/pristine/src.8/sys/contrib/ipfilter > -I/FreeBSD/pristine/src.8/sys/contrib/pf -I/FreeBSD/pristine/src.8/sys/dev/ath > -I/FreeBSD/pristine/src.8/sys/dev/ath/ath_hal > -I/FreeBSD/pristine/src.8/sys/contrib/ngatm > -I/FreeBSD/pristine/src.8/sys/dev/twa > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD/support > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs -I/FreeBSD/pristine/src.8/sys/dev/cxgb > -I/FreeBSD/pristine/src.8/sys/dev/cxgbe -I/FreeBSD/pristine/src.8/sys/cam/scsi > -I/FreeBSD/pristine/src.8/sys/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p > aic79xx_reg_print.c -i /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx_osm.h > /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq > ./aicasm: Stopped at file /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq, > line 53 - Undefined symbol code referenced > ./aicasm: Removing aic79xx_seq.h due to error > ./aicasm: Removing aic79xx_reg.h due to error > *** Signal 11 > > Stop in /usr/obj/i386/FreeBSD/pristine/src.8/sys/GENERIC. > *** Error code 1 > > Stop in /FreeBSD/pristine/src.8. > *** Error code 1 > > Stop. > make: stopped in /FreeBSD/pristine/src.8 Some time in 2013 the build process for aicasm got broken for the cross-build case (it builds with the wrong compiler and header files). I fixed it late in 2013 with a series of botched attempts that fixed it in some case and broke it for some other case. Eventually it got fixed for all cases except apparently the old-school kernel compile method of running make from the sys/config dir. Now it has been fixed on head by just nuking aicasm and checking in some firmware binary blob instead. I'm not sure whether it makes sense to mfc that binary-blob fix to stable branches or not. I've distilled the end result of my build mechanism changes down to a patch against stable-8, I'll attach it to this mail. It lets me build amd64 and arm on this i386 machine, so I think it'll let you build i386 on an amd64 host. -- Ian --=-l8aceLeNDO9lFJx2kg10 Content-Disposition: attachment; filename="aicasm_stab8.diff" Content-Type: text/x-patch; name="aicasm_stab8.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 261326) +++ Makefile.inc1 (working copy) @@ -250,6 +250,21 @@ XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} \ TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ -DWITHOUT_GDB +# kernel-tools stage +KTMAKEENV= INSTALL="sh ${.CURDIR}/tools/install.sh" \ + PATH=${BPATH}:${PATH} \ + WORLDTMP=${WORLDTMP} \ + VERSION="${VERSION}" \ + COMPILER_TYPE=${COMPILER_TYPE} +KTMAKE= TOOLS_PREFIX=${WORLDTMP} MAKEOBJDIRPREFIX=${WORLDTMP} \ + ${KTMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 \ + DESTDIR= \ + BOOTSTRAPPING=${OSRELDATE} \ + SSP_CFLAGS= \ + -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ + -DNO_PIC -DNO_PROFILE -DNO_SHARED \ + -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD + # world stage WMAKEENV= ${CROSSENV} \ _SHLIBDIRPREFIX=${WORLDTMP} \ @@ -403,6 +418,7 @@ _cross-tools: @echo ">>> stage 3: cross tools" @echo "--------------------------------------------------------------" ${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools + ${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools _includes: @echo @echo "--------------------------------------------------------------" @@ -776,20 +792,7 @@ buildkernel: @echo "--------------------------------------------------------------" @echo ">>> stage 2.3: build tools" @echo "--------------------------------------------------------------" - cd ${KRNLOBJDIR}/${_kernel}; \ - PATH=${BPATH}:${PATH} \ - MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ - -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile -# XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. -.if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists(${KERNSRCDIR}/modules) -.for target in obj depend all - cd ${KERNSRCDIR}/modules/aic7xxx/aicasm; \ - PATH=${BPATH}:${PATH} \ - MAKEOBJDIRPREFIX=${KRNLOBJDIR}/${_kernel}/modules \ - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF ${target} -.endfor -.endif + ${_+_}cd ${.CURDIR}; ${KTMAKE} kernel-tools .if !defined(NO_KERNELDEPEND) @echo @echo "--------------------------------------------------------------" @@ -1003,10 +1006,6 @@ bootstrap-tools: # # build-tools: Build special purpose build tools # -.if defined(MODULES_WITH_WORLD) && exists(${KERNSRCDIR}/modules) -_aicasm= sys/modules/aic7xxx/aicasm -.endif - .if !defined(NO_SHARE) _share= share/syscons/scrnmaps .endif @@ -1027,7 +1026,6 @@ build-tools: lib/ncurses/ncurses \ lib/ncurses/ncursesw \ ${_share} \ - ${_aicasm} \ usr.bin/awk \ lib/libmagic \ usr.sbin/sysinstall @@ -1047,6 +1045,23 @@ build-tools: .endfor # +# kernel-tools: Build kernel-building tools +# +kernel-tools: .MAKE + mkdir -p ${MAKEOBJDIRPREFIX}/usr + mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \ + -p ${MAKEOBJDIRPREFIX}/usr >/dev/null +.for _tool in \ + sys/dev/aic7xxx/aicasm + ${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all,install)"; \ + cd ${.CURDIR}/${_tool} && \ + ${MAKE} DIRPRFX=${_tool}/ obj && \ + ${MAKE} DIRPRFX=${_tool}/ depend && \ + ${MAKE} DIRPRFX=${_tool}/ all && \ + ${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install +.endfor + +# # cross-tools: Build cross-building tools # .if ${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} < 800035 Index: sys/modules/aic7xxx/ahc/Makefile =================================================================== --- sys/modules/aic7xxx/ahc/Makefile (revision 261326) +++ sys/modules/aic7xxx/ahc/Makefile (working copy) @@ -15,13 +15,10 @@ REG_PRINT_OPT= -p aic7xxx_reg_print.c .endif BEFORE_DEPEND = ${GENSRCS} -../aicasm/aicasm: ${.CURDIR}/../../../dev/aci7xxx/aicasm/*.[chyl] - ( cd ${.CURDIR}/../aicasm; ${MAKE} aicasm; ) - ${GENSRCS}: \ ${.CURDIR}/../../../dev/aic7xxx/aic7xxx.{reg,seq} \ - ${.CURDIR}/../../../cam/scsi/scsi_message.h ../aicasm/aicasm - ../aicasm/aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ + ${.CURDIR}/../../../cam/scsi/scsi_message.h + aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ -I${.CURDIR}/../../../dev/aic7xxx \ -o aic7xxx_seq.h -r aic7xxx_reg.h \ ${REG_PRINT_OPT} \ Index: sys/modules/aic7xxx/ahd/Makefile =================================================================== --- sys/modules/aic7xxx/ahd/Makefile (revision 261326) +++ sys/modules/aic7xxx/ahd/Makefile (working copy) @@ -15,13 +15,10 @@ REG_PRINT_OPT= -p aic79xx_reg_print.c .endif BEFORE_DEPEND= ${GENSRCS} -../aicasm/aicasm: ${.CURDIR}/../../../dev/aic7xxx/aicasm/*.[chyl] - ( cd ${.CURDIR}/../aicasm; ${MAKE} aicasm; ) - ${GENSRCS}: \ ${.CURDIR}/../../../dev/aic7xxx/aic79xx.{reg,seq} \ - ${.CURDIR}/../../../cam/scsi/scsi_message.h ../aicasm/aicasm - ../aicasm/aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ + ${.CURDIR}/../../../cam/scsi/scsi_message.h + aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ -I${.CURDIR}/../../../dev/aic7xxx \ -o aic79xx_seq.h -r aic79xx_reg.h \ ${REG_PRINT_OPT} \ Index: sys/modules/aic7xxx/Makefile =================================================================== --- sys/modules/aic7xxx/Makefile (revision 261326) +++ sys/modules/aic7xxx/Makefile (working copy) @@ -1,6 +1,6 @@ # $FreeBSD$ -SUBDIR= aicasm ahc ahd +SUBDIR= ahc ahd .include Index: sys/conf/files =================================================================== --- sys/conf/files (revision 261326) +++ sys/conf/files (working copy) @@ -9,44 +9,39 @@ acpi_quirks.h optional acpi \ compile-with "${AWK} -f $S/tools/acpi_quirks2h.awk $S/dev/acpica/acpi_quirks" \ no-obj no-implicit-rule before-depend \ clean "acpi_quirks.h" -aicasm optional ahc | ahd \ - dependency "$S/dev/aic7xxx/aicasm/*.[chyl]" \ - compile-with "CC='${CC}' ${MAKE} -f $S/dev/aic7xxx/aicasm/Makefile MAKESRCPATH=$S/dev/aic7xxx/aicasm" \ - no-obj no-implicit-rule \ - clean "aicasm* y.tab.h" aic7xxx_seq.h optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic7xxx_seq.h" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg.h optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic7xxx_reg.h" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg_print.c optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule local \ clean "aic7xxx_reg_print.c" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg_print.o optional ahc ahc_reg_pretty_print \ compile-with "${NORMAL_C}" \ no-implicit-rule local aic79xx_seq.h optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic79xx_seq.h" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg.h optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic79xx_reg.h" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg_print.c optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule local \ clean "aic79xx_reg_print.c" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg_print.o optional ahd pci ahd_reg_pretty_print \ compile-with "${NORMAL_C}" \ no-implicit-rule local Index: sys/dev/aic7xxx/aicasm/Makefile =================================================================== --- sys/dev/aic7xxx/aicasm/Makefile (revision 261326) +++ sys/dev/aic7xxx/aicasm/Makefile (working copy) @@ -15,7 +15,7 @@ SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS} CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g} DPADD= ${LIBL} LDADD= -ll -WARNS?= 6 +WARNS?= 0 # Correct path for kernel builds # Don't rely on the kernel's .depend file @@ -24,13 +24,7 @@ LDADD= -ll DEPENDFILE= .depend_aicasm .endif -.if ${CC} == "icc" -CFLAGS+= -restrict -NOSTDINC= -X -.else -NOSTDINC= -nostdinc -.endif -CFLAGS+= ${NOSTDINC} -I/usr/include -I. +CFLAGS+= -I${.CURDIR} .ifdef MAKESRCPATH CFLAGS+= -I${MAKESRCPATH} .endif @@ -44,4 +38,8 @@ YFLAGS+= -t -v LFLAGS+= -d .endif +BINDIR=/usr/bin + +build-tools: ${PROG} + .include --=-l8aceLeNDO9lFJx2kg10-- From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 20:48:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A23F3A7; Fri, 31 Jan 2014 20:48:12 +0000 (UTC) Received: from yip.org (pi.yip.org [206.248.142.170]) by mx1.freebsd.org (Postfix) with ESMTP id 41DAB178B; Fri, 31 Jan 2014 20:48:11 +0000 (UTC) Received: by yip.org (Postfix, from userid 1001) id D607F39825; Fri, 31 Jan 2014 15:41:05 -0500 (EST) Date: Fri, 31 Jan 2014 15:41:04 -0500 From: Bob K To: Lev Serebryakov Subject: Re: Did somebody boot old Sony Vaio laptop from FreeBSD memstick successfully? Message-ID: <20140131204103.GH89915@yip.org> References: <976149194.20140128115104@serebryakov.spb.ru> <1777063285.20140128204239@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1777063285.20140128204239@serebryakov.spb.ru> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Warren Block , hackers@FreeBSD.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 20:48:12 -0000 On Tue, Jan 28, 2014 at 08:42:39PM +0400, Lev Serebryakov wrote: > Hello, Warren. > You wrote 28 ???????????? 2014 ??., 20:32:35: > > >> I'm trying to install FreeBSD 10-R (i386) on old Sony Vaio laptop (it is > >> VGN-SZ340P, Merom generation of Core2, ~2007). > >> > >> It allows to select "USB Hard drive" or "USB Optical Drive" as boot device, > >> but it writes "No operating system" in both cases. [...] > I tried this too... It looks like this old Laptop / BIOS wants to see > special USB Floppy / USB Optical drive device, not generic "umass" one. Hi Lev, According to http://community.sony.com/t5/VAIO-Upgrade-Backup-Recovery/VAIO-VGN-NR110E-how-to-boot-from-a-USB-stick/td-p/65819 there may be settings in your BIOS that look like Advanced -> External Drive Boot. Maybe that's the issue? Regards, -Bob -- Bob | It's pretty good, if you don't think about it. From owner-freebsd-stable@FreeBSD.ORG Fri Jan 31 21:24:21 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4B98315; Fri, 31 Jan 2014 21:24:21 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62B6B1A93; Fri, 31 Jan 2014 21:24:20 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s0VLNueo034748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Feb 2014 06:24:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s0VLNrw3097971; Sat, 1 Feb 2014 06:23:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 01 Feb 2014 06:23:38 +0900 (JST) Message-Id: <20140201.062338.1549211642350100193.hrs@allbsd.org> To: ian@FreeBSD.org Subject: Re: building stable/8 on stable/10 host: is it supported? From: Hiroki Sato In-Reply-To: <1391198005.13026.14.camel@revolution.hippie.lan> References: <1391198005.13026.14.camel@revolution.hippie.lan> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Feb__1_06_23_38_2014_177)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 01 Feb 2014 06:24:08 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: erichsfreebsdlist@alogt.com, freebsd-stable@FreeBSD.org, marck@rinet.ru X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 21:24:21 -0000 ----Security_Multipart(Sat_Feb__1_06_23_38_2014_177)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Lepore wrote in <1391198005.13026.14.camel@revolution.hippie.lan>: ia> On Thu, 2014-01-30 at 17:51 +0400, Dmitry Morozovsky wrote: ia> > On Thu, 30 Jan 2014, Dmitry Morozovsky wrote: ia> > ia> > > Hiroki-san, ia> > ia> > [snip] ia> > ia> > > > Currently stable/8 does not build on a box running 10 or later ia> > > > because several commits to fix build errors at the toolchain ia> > > > bootstrapping stages due to the toolchain migration were not MFC'd ia> > > > yet. For stable/8, try the following patch: ia> > > > ia> > > > http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch.diff ia> > > ia> > > Thanks a lot, will try and report! ia> > ia> > amd64 world/kernel built successfully, thanks again. ia> > ia> > However, cross-build to TARGET=i386 chokes on aicasm module: ia> > ia> > ./aicasm -nostdinc -I. -I/FreeBSD/pristine/src.8/sys ia> > -I/FreeBSD/pristine/src.8/sys/contrib/altq ia> > -I/FreeBSD/pristine/src.8/sys/contrib/ipfilter ia> > -I/FreeBSD/pristine/src.8/sys/contrib/pf -I/FreeBSD/pristine/src.8/sys/dev/ath ia> > -I/FreeBSD/pristine/src.8/sys/dev/ath/ath_hal ia> > -I/FreeBSD/pristine/src.8/sys/contrib/ngatm ia> > -I/FreeBSD/pristine/src.8/sys/dev/twa ia> > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD ia> > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs/FreeBSD/support ia> > -I/FreeBSD/pristine/src.8/sys/gnu/fs/xfs -I/FreeBSD/pristine/src.8/sys/dev/cxgb ia> > -I/FreeBSD/pristine/src.8/sys/dev/cxgbe -I/FreeBSD/pristine/src.8/sys/cam/scsi ia> > -I/FreeBSD/pristine/src.8/sys/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p ia> > aic79xx_reg_print.c -i /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx_osm.h ia> > /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq ia> > ./aicasm: Stopped at file /FreeBSD/pristine/src.8/sys/dev/aic7xxx/aic79xx.seq, ia> > line 53 - Undefined symbol code referenced ia> > ./aicasm: Removing aic79xx_seq.h due to error ia> > ./aicasm: Removing aic79xx_reg.h due to error ia> > *** Signal 11 ia> > ia> > Stop in /usr/obj/i386/FreeBSD/pristine/src.8/sys/GENERIC. ia> > *** Error code 1 ia> > ia> > Stop in /FreeBSD/pristine/src.8. ia> > *** Error code 1 ia> > ia> > Stop. ia> > make: stopped in /FreeBSD/pristine/src.8 ia> ia> Some time in 2013 the build process for aicasm got broken for the ia> cross-build case (it builds with the wrong compiler and header files). ia> I fixed it late in 2013 with a series of botched attempts that fixed it ia> in some case and broke it for some other case. Eventually it got fixed ia> for all cases except apparently the old-school kernel compile method of ia> running make from the sys/config dir. Now it has been fixed on head by ia> just nuking aicasm and checking in some firmware binary blob instead. ia> I'm not sure whether it makes sense to mfc that binary-blob fix to ia> stable branches or not. ia> ia> I've distilled the end result of my build mechanism changes down to a ia> patch against stable-8, I'll attach it to this mail. It lets me build ia> amd64 and arm on this i386 machine, so I think it'll let you build i386 ia> on an amd64 host. Great, I was about to send a patchset including changes in r260401[*] but I think your change should be sufficient. [*] http://people.allbsd.org/~hrs/FreeBSD/stable-8-patch-20140201-1.diff -- Hiroki ----Security_Multipart(Sat_Feb__1_06_23_38_2014_177)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlLsFFoACgkQTyzT2CeTzy2QMACeMjguOvjcbYSOVIokmhSj9WOc c4IAoLW2l8rPmifY6/VrkPLrxjKV0NCf =vigN -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Feb__1_06_23_38_2014_177)---- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 05:34:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1979315D for ; Sat, 1 Feb 2014 05:34:20 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD1721FA7 for ; Sat, 1 Feb 2014 05:34:19 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id hl1so865764igb.1 for ; Fri, 31 Jan 2014 21:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=noDCEGnLBabZ7ba4Jc9inAAdMdDbHd522p5IBvZU7ds=; b=G5EHxpidooSfn1Mw8la530LiyuMQOyXJvddE0j8jE2xQlT8FB1xghRjZv5tsNIJWbW +zZhUHoGXtVrKN9fk/t6gdN8oqqjK0ptm38ILc2itM8SjhicoN8mQ/sj9Mx67R+1Z44J 2+aXDDbc6WmEx17vFU1CMzRop2dw/tVnmDvGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition; bh=noDCEGnLBabZ7ba4Jc9inAAdMdDbHd522p5IBvZU7ds=; b=cxwwWX1lWJ7lhBVOkEBKkrPvNRs4rn/iign0/75umUrtgYIVNNK+Yg5kuC2IIHw94C 6JHePdfzM+QSE58Ro55gbknUiv2OyAqfNRV6+RpMkeuS/fcYvgkV3xy14FdNFYZUopkk urOpFz82EWIeIhi5iMVfwnhzcEk4xBwuK5s1t02x6a8mtJKBE3JDz54iMy8WmVWVKa+q HKq064Qs0p44v9+8OCLy0BtPIpT6AmgL10pB270sM0H7TzIFGn0yKm/gqYrQq2m2i8u7 PrqNcSvGB67IJjoOIg5EudW2DcJZkitcv8mNGGudmXm60Oc84Ixjp7aInD6G5a+q4ETY qI8g== X-Gm-Message-State: ALoCoQmIAxyLbaCRGuBRzuGITCH2NNPChY4OypgRwroOinr11mJ3s05f4ukM28OGPxpboL7cnZeJ X-Received: by 10.43.98.202 with SMTP id cp10mr18480238icc.28.1391232859188; Fri, 31 Jan 2014 21:34:19 -0800 (PST) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id f2sm5003660igt.6.2014.01.31.21.34.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2014 21:34:18 -0800 (PST) Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.7/8.14.7) with ESMTP id s115YFiD008102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 1 Feb 2014 00:34:16 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.7/8.14.7/Submit) id s115YFMZ008095 for freebsd-stable@freebsd.org; Sat, 1 Feb 2014 00:34:15 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Sat, 1 Feb 2014 00:34:15 -0500 From: jhellenthal@dataix.net To: freebsd-stable@freebsd.org Subject: FreeBSD 10-STABLE periodic/security/800-loginfail Message-ID: <20140201053415.GA26828@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 05:34:20 -0000 It seems that AFAIK is missing a pattern to match "not allowed" entries in auth.log I would like to propose the following channges upon this subject... Initially I would like to see patterns be more specific and case sensitive. * This is due to many pattern matching problems like invalid_userauth_request matching case insensitive pattern "invalid" that was meant to catch "Invalid login" but does not provide any useful information when relayed to the user. I would like to see the egrep statement inturn changed to (grep -E). * This is just a nit-pick for portability sake. Also move away from storing the pattern matching statically in the 800-loginfail file directly. * Store somewhere else like /etc/periodic/security/loginpatterns * Include the ability to allow users to pattern match on /etc/userpatterns (whatever you wanna call it...) * If may be used further by other user aided scripts to parse logs too. I would suggest the following patterns to match on to begin with. * "User.*.from.*.not.allowed" * "Invalid.user.*.from." * "authentication.error.for.illegal.user.*.from" * "Did.not.receive.identification.string.from" I am sure there are plenty of other patterns to match on but this takes care of sshd and most system level logs AFAIA Wrapping this up though my main concern is getting rid of what is not useful to someone or anyone in the form of an email like the input_useraut_request messages. I personally would rather see where it started at along with the ip-address and parse the logs later if I am concerned about one of those entries. -- - (2^(N-1)) JJH48-ARIN From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 06:09:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 577873CD for ; Sat, 1 Feb 2014 06:09:22 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF1811199 for ; Sat, 1 Feb 2014 06:09:21 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1W9TlO-00073Q-Cq for freebsd-stable@freebsd.org; Sat, 01 Feb 2014 06:09:10 +0000 Date: Sat, 1 Feb 2014 07:09:12 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Tuning kern.maxswzone Message-ID: <20140201070912.00007971@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 06:09:22 -0000 What should be a simple adjustment has become a real head scratcher. This mysterious tunable is barely documented and the results I'm seeing while experimenting are just more confusing. Apologies for the length, I just spent half the evening trying to tune this value. I have two low-end boxes that I recently put 10-RC1 on and wanted to update to 10-STABLE. The hardware is rather dated and by modern standards one could call is pathetic, but it's still way more than what I started on with FreeBSD 3.x so I expect to still be able to build world, it just might take a while. I starting having hangs just trying to do a svn checkout on one of the two boxes. The only difference is RAM, so I figured a low memory problem was wedging something, and the one with a little less memory kept spraying this message about increasing kern.maxswzone so I figured I should look into it. And thus I opened the can of worms. The common wisdom is that minimum swap should be twice RAM, until you get to several GB and then maybe only equal to RAM. Using a little extra if you can spare the disk space was generally considered extra insurance and a heavily loaded sever might have 4x as much swap as RAM. Tuning(7) almost says the more the merrier. I was not expecting to hit a maximum, though it makes sense that must be one of some sort. These two boxes are Via C3-800 CPU with room for 2 PC133 DIMMs. Using the compatible memory I have on hand (the only larger sticks are ECC but the chipset rejects those), puts one box at 256MB and the other at 384MB, which should not be all that bad. The harddrives are marketed as 36GB, real capacity is 34GB, so I assigned an even 2GB to swap and 32GB to UFS volumes. I was going to do 1GB swap as more than sufficient, but 2GB made nice even numbers, and it gives more room for tmpfs mounted /tmp to spill into swap in the case I toss some rather large file there. According to what I've read, the default limit on swap is 8x the RAM capacity. The kernel structures to track swap pages are apparently not dynamically allocated when swap is mounted so it's a kernel tunable. 2GB is exactly 8x 256MB so I should be just fine, except I keep seeing messages at boot that state "warning: total configured swap (524287 pages) exceeds maximum recommended amount (481376 pages). warning: increase kern.maxswzone or reduce amount of swap." Well, turns out the calculation of RAM is not physical memory but available memory. 8MB of RAM is allocated to UMA video memory, so memtest86 shows only 248MB rather than 256MB. The kernel image also takes some RAM which is considered not-available. The boot messages state physical RAM is 256MB, available RAM is 233MB. 233MB/256MB = 91% and of course 481376 pages / 524287 pages = 91.8%, confirmation the available number is used rather than physical. That makes sense where there is substantial difference, but for the general case where the difference is small, it just results in a headache when the admin multiplies physical RAM by 8 to arrive at a swap size that will be just large enough to trigger a warning during boot. Obvious course of action is to increase it, just needs to know to what value. Quick search finds no docs on the meaning of the tunable (no mention in man pages, nothing found searching the wiki and website), only a few old forum and mailing list posts asking about it and replies that essentially say to turn it up until the message goes away, with the suggestion to start by adding the difference. No exact math is available, just rough estimates of how much RAM should be needed for some amount of swap, so my first guess was low by a factor of 10 and I saw the number of usable swap pages go way down. I tried the other way, multiply the default value by 1.09 to add the 9% it's short. I put that value in but no change to the boot messages. I tried increasing again, no change. I tried setting something silly high and then it panics on boot. So, I figure maybe I should take the number from the other box, the one with 384MB physical RAM, and just try using that. With 358MB available, it should have sufficient kernel resources to track 2.8GB of swap space with default settings. I look at the number it reports for kern.maxswzone, expecting to find something larger by about 50% than what the box with less RAM had defaulted to. Surprise, the numbers are the exactly same! I looked not twice but thrice with fresh reboots on each to see the default is indeed identical. What does kern.maxswzone actually do and what does it's number even mean? Supposedly it's a number in bytes of some memory structure used to track swap pages. In what little I could find on the topic, it's mentioned that there should be enough for twice as many pages of swap as there will actually be used, but it's not clear if that doubling is accounted for in the warning message. One old mailing list message mentions setting this up to 32MB for 20GB of swap, which would be about 1.5MB of memory per GB of swap. If that number were right, my 2GB of swap would need 3MB of kernel memory, which seems ok. The default value of kern.maxswzone on both boxes is 36175872, which is 34.5MB! That seems like an awful lot, 15% of the available memory would be used to track what is swapped out to disk. Aside from the question of why that is so much larger than the expected 8x, why am I getting the message about not enough when it appears to be ample? I started cutting the number down, dividing by half until I saw it actually do something. It was when I finally got down to about 5MB that I saw some impact (though that's still double what the estimates suggest, so maybe the warning does include the doubling for safety). With some actual number of usable swap pages, I calculated it's approximately 17.25 bytes per page. From that I calculated that it should be slightly over 8MB for the 481376 pages. I started trying numbers around there, quickly established endpoints, and started bisecting the area. Booting with kern.maxswzone=8302000 showed 480928 pages of usable swap and with kern.maxswzone=8303000 showed 481376 pages, so it goes in chunks and the threshold should be between those points. While trying to bisect to an exact number, I wound up all the way back to 8302000 with 481376 pages. So, I stopped there as it's not entirely consistent. Looking through the logs for a month, I can see the number varied a little bit across boots with no changes to configuration. It's probably on the edge and something as simple as the difference in state from the BIOS and boot loader depending on whether its a cold or warm boot, soft or hard reset, etc can knock it down a chunk seemingly at random. So, as best I can tell, the actual effective number used for kern.maxswzone is indeed approximately 8x available RAM. If there is some need to turn it down (using substantially less swap) then that is possible, but turning it up (as suggested by the warning message) is not possible. Setting any value higher does not appear to actually increase the number of swap pages that can be used. Worse, it might actually be increasing some allocation in the kernel without the additional memory being used. If the number were just ignored over the 8x RAM limit, then I don't think I would have gotten the panic when I set maxswzone to something over 40MB (which isn't that much above the default). This seems so strange that I really hope I'm somehow completely off base, and I do hope someone can shed light on this situation and reveal some glaring mistake I've made. At first I ignored the warning, too much swap, BAH, but I had to start digging when I hit strange problems I couldn't ignore on one box that differs from the otherwise identical box only by amount of RAM and thus swap space ratio. To cut a longer story short, I switched from cvsup to svnup to svn while going from 9-STABLE to 10. I accidentally made a mess, I forgot to clear /usr/src before doing the svn checkout. Unlike sup, svn won't just overwrite, it tracks all those existing files as conflicts to resolve after it has fetched everything. Rather than answer a few thousand prompts, I decided the prudent thing was rm -r * and checkout fresh. Imagine my surprise when I find that rm hangs on the box with less RAM. Ctrl-c stopped rm about 5min later, with no disk activity, but then I couldn't execute commands, so I reboot. Try it again and I see it deletes a few files (with disk activity) and then goes through more (but no disk activity) and seems to stick. I can't login to another console once that happens. I booted a mfsbsd CD to poke it from another angle and found I could delete everything rather rapidly, though rm did seem to be using a lot of memory. Several times the rm blew up with out of memory errors, sometimes taking sh or even getty with it so I had to relogin several times and even reboot once (after init blew out) to get all of /usr/src deleted. Booting up mfsbsd with it's monster md leaves about 30MB free on this system, which is relatively tiny, but in 4.x days I was building world on a P60 with 32MB RAM so I can't imagine how rm could need more than that. So why would the mfsbsd instance with far less memory be able to delete the files? The key difference that comes to mind is mfsbsd is not trying to use swap, so if excess swap could make allocations hang for minutes rather than instantly fail, the normal system would look hung under pressure. With /usr/src cleared (and after running fsck) I booted back into 10-PRERELEASE to try to fetch the 10-STABLE sources again. I started svnlite co and find it hung shortly thereafter. I tried a few times but each time I see it does a couple hundred files at best and just stops. When it stops, I can't login to another terminal. If I have a spare console logged in, I can't run anything. After a few tries, I manged to catch it where I had top running in one VT, started the checkout, and then switched back just in time. I never could even get top up with rm running (it probably blows over some limit faster). When the checkout hangs, the state of svnlite is "kmem a" according to top. I can only guess that is short for kmem alloc, I guess some syscall is waiting on an allocation that will never happen because something already is using or has leaked everything that could satisfy that allocation. It looks like activity on too many files within a short period runs something out. Now things get real messy, as completely separately from this I just started seeing issues at 10-RELEASE with hangs in "kmem a" state on a few boxes with much more memory (RAM >= to the swap space on these two). I'm going to write up the "kmem a" hangs in a separate email as I believe that to be a separate issue which made me look closer at this warning which then ended up raising more questions. This kern.maxswzone warning seems to be unsolvable because the tunable can't be turned up effectively, it seems to have some non-useful side effect, and it may be exacerbating another issue causing the "kmem a" hang to be more prevalent (to the point I wonder if I could make it through another buildworld once I somehow get sources onto the drive). From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 06:20:41 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0D8253F; Sat, 1 Feb 2014 06:20:41 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6224123C; Sat, 1 Feb 2014 06:20:40 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s116KaIM005400; Sat, 1 Feb 2014 08:20:36 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s116KavU005285; Sat, 1 Feb 2014 06:20:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 1 Feb 2014 06:20:36 GMT Message-Id: <201402010620.s116KavU005285@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 06:20:41 -0000 TB --- 2014-02-01 04:30:32 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-01 04:30:32 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-01 04:30:32 - starting RELENG_10 tinderbox run for powerpc64/powerpc TB --- 2014-02-01 04:30:32 - cleaning the object tree TB --- 2014-02-01 04:30:32 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-01 04:31:20 - At svn revision 261342 TB --- 2014-02-01 04:31:21 - building world TB --- 2014-02-01 04:31:21 - CROSS_BUILD_TESTING=YES TB --- 2014-02-01 04:31:21 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-01 04:31:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-01 04:31:21 - SRCCONF=/dev/null TB --- 2014-02-01 04:31:21 - TARGET=powerpc TB --- 2014-02-01 04:31:21 - TARGET_ARCH=powerpc64 TB --- 2014-02-01 04:31:21 - TZ=UTC TB --- 2014-02-01 04:31:21 - __MAKE_CONF=/dev/null TB --- 2014-02-01 04:31:21 - cd /src TB --- 2014-02-01 04:31:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 1 04:31:31 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/PointerSubChecker.cpp -o PointerSubChecker.o c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp -o PthreadLockChecker.o c++ -O2 -pipe -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers -I. -I/src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp -o RetainCountChecker.o /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp: In member function 'void::RetainCountChecker::processObjCLiterals(clang::ento::CheckerContext&, const clang::Expr*) const': /src/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp:2714: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/lib/clang/libclangstaticanalyzercheckers *** Error code 1 Stop. bmake[4]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-01 06:20:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-01 06:20:35 - ERROR: failed to build world TB --- 2014-02-01 06:20:35 - 5098.35 user 1628.52 system 6602.66 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 06:51:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64015838 for ; Sat, 1 Feb 2014 06:51:08 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 208831482 for ; Sat, 1 Feb 2014 06:51:08 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id uq10so2508966igb.0 for ; Fri, 31 Jan 2014 22:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version; bh=+UjO3mxJ7eRQOYduZ+ehY9kcwTpS3QCzxOteeerlmqg=; b=PSphsXUCY08GObBD174yJfzeSJdvPaqfCHDMmiIdcMUQvZUr1y5umYloNzUcvAz/lU cPE66INq8UNbKn8RFHUe4YC7Jh2hn6lYsZP34it17C4VC79Ej6vvjNneFriB7O85wrcK 1uG/EgjdaFpJJonVzwxI7v0T2FYLr/sO2lh2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=+UjO3mxJ7eRQOYduZ+ehY9kcwTpS3QCzxOteeerlmqg=; b=EVAEn8A3hVqKKuYlOgBJdxZEbJ5B30CLkiCM6H8gBdBQJ/NWvxAGfcD8wmeWAbgKwh JVY19AGubgadgPpGZu6xzGhRTpKWYZNXaiRk7TgRAh/h75rrBfcuJ0oCmW6IrQxelgFY 9MWqbRpQFzDEgFhGJ/smrDNWvHV3biCyEaKZJtdfCp+Rq0CCu7NNU4cd4xo/wRKFaUeO SI4Mhp3d2V0z6qxJv1CMJnuYuXwXGWrXK791cUNpluNvrD9PrVg8qXdoa+FINpIrCDE1 vemWkCNE/ug9BjLZjeq/5yDMp6oA/lHstaVoNzJdBf+QStSs227Q6QrGAc9m/6eWsFqA KsFw== X-Gm-Message-State: ALoCoQlOrJBu5y6MehPcTJmYtjqWe14YobHO614AEb3bwnBTcWYXSSrylP1r05a3jq6YHyRew8+R X-Received: by 10.42.142.129 with SMTP id s1mr17862564icu.30.1391237467551; Fri, 31 Jan 2014 22:51:07 -0800 (PST) Received: from [172.31.35.13] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id t4sm5534880igm.10.2014.01.31.22.51.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 22:51:06 -0800 (PST) Subject: Re: Sendmail/sasl2 LDADD. LDFLAGS FreeBSD 10-STABLE References: <62BE46C5-FEC6-481B-A0AE-06D594489953@dataix.net> From: Jason Hellenthal Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B106AD4C-A50F-4E67-A186-951321F0E0C7; protocol="application/pkcs7-signature" X-Mailer: iPhone Mail (11B554a) In-Reply-To: <62BE46C5-FEC6-481B-A0AE-06D594489953@dataix.net> Message-Id: <34D2896D-68D0-4582-9D72-E6728EA9B64A@dataix.net> Date: Sat, 1 Feb 2014 01:51:04 -0500 To: "[FreeBSD Stable]" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 06:51:08 -0000 --Apple-Mail-B106AD4C-A50F-4E67-A186-951321F0E0C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Embarrassing !!! Ignore this . . .=20 Lowercase s on SENDMAIL_LDFLAGS went unnoticed and looked daily close to an u= ppercase s on my terminal. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 31, 2014, at 3:23, Jason Hellenthal wrote:= >=20 > It appears make.conf and src.conf settings are not being passed through to= the build of sendmail and related utilities. >=20 > Could someone look into this further ? I have no further time that I can s= pend with it. >=20 > Specifically I had to add -L/usr/local/lib manually to the Makefile LDADDFL= AGS because -lsasl2 could not be found. Or is there another way that we are d= oing this with base OpenSSL ? >=20 > Thank you. >=20 > --=20 > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN --Apple-Mail-B106AD4C-A50F-4E67-A186-951321F0E0C7 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIwMTA2NTEwNlowIwYJKoZIhvcN AQkEMRYEFBkgQ/Dgy2rJ/oEcjzgSJeZRyY2FMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAQBGhXoNs5UnHevj52R9U IXjVST7dVP/+X/t+uaNi1Sm6QQv7OtCtMtR4hwUqS8MDCyLqNBZVa97S81JMpHaiDk6/8TzHs6gI +TSRaO3SXtKN4/Rv9aob0LVLEky1PeRS8VsXLtQUrG1Boi9263UECFU1ZmjuU9+JJYmUwystKeh/ 9slGBhm3nn9kMD9or4f1ydaNbEticmatV7KFUzDnVD7Ya6EHemAlgdQ+SNfoET3Mj860x+UO8huB 6h3pXkxwmJB+TO/os+wwrvvik5+Z0EiRRhA+jH2tE9e7zEwHw2PyZ/KINFHYbGOmrDn3Q+wlZq+a lr3SZZU3HimFfTLosAAAAAAAAA== --Apple-Mail-B106AD4C-A50F-4E67-A186-951321F0E0C7-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 19:15:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5527A874 for ; Sat, 1 Feb 2014 19:15:09 +0000 (UTC) Received: from ln.servalan.com (ln.servalan.com [IPv6:2600:3c00::f03c:91ff:fe96:62f5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B7FC1681 for ; Sat, 1 Feb 2014 19:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=servalan.com; s=rsadkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:From:References:Subject:Cc:To; bh=Yw4e7OS8LWbYk/beiYXnId3bAWJjHzp5stxjKzsY7JQ=; b=Qu8RNpCyP2M/KskIULtyiTuTW6ZTcmjESDX7REASGMHplBhXjy7x+mwnOnuAcrI7r+1qPC1Yz6np8VH+2lGd462mk2GWUvijdabq1zcJRObbWEo53BfqSnfwZ9mhxtaKQQI91zFT/FxU9736yvbCgtG1ZX+AApEMafGi++pMAeA=; Received: from uucp by ln.servalan.com with local-rmail (Exim 4.76) (envelope-from ) id 1W9g20-00017J-5V for freebsd-stable@freebsd.org; Sat, 01 Feb 2014 13:15:08 -0600 Received: from rmtodd by servalan.servalan.com with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1W9fqW-000B0K-He; Sat, 01 Feb 2014 13:03:16 -0600 To: Matthew Rezny Subject: Re: Tuning kern.maxswzone References: <20140201070912.00007971@unknown> From: Richard Todd Date: Sat, 01 Feb 2014 13:03:15 -0600 In-Reply-To: <20140201070912.00007971@unknown> (Matthew Rezny's message of "Sat, 1 Feb 2014 07:09:12 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 19:15:09 -0000 Matthew Rezny writes: > So, as best I can tell, the actual effective number used for > kern.maxswzone is indeed approximately 8x available RAM. If there is > some need to turn it down (using substantially less swap) then that is > possible, but turning it up (as suggested by the warning message) is > not possible. Setting any value higher does not appear to actually Yeah, IIRC I ran into that when configing some VMs with really big swap space for benefit of tmpfs. This is the quick hack I used to get around that, you might give it a try. # HG changeset patch # Parent e4dd7df011139e2b224835aa6e330c90afcf9a55 patch swap_pager to unconditionally use maxswzone tunable if it is set -- helpful for our tbvm VMs with large swap space for tmpfs diff -r e4dd7df01113 sys/vm/swap_pager.c --- a/sys/vm/swap_pager.c Wed Feb 20 00:15:49 2013 -0600 +++ b/sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600 @@ -546,7 +546,7 @@ * is typically limited to around 32MB by default. */ n = cnt.v_page_count / 2; - if (maxswzone && n > maxswzone / sizeof(struct swblock)) + if (maxswzone) n = maxswzone / sizeof(struct swblock); n2 = n; swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), NULL, NULL, Also, > With /usr/src cleared (and after running fsck) I booted back into > 10-PRERELEASE to try to fetch the 10-STABLE sources again. I started > svnlite co and find it hung shortly thereafter. I tried a few times but > each time I see it does a couple hundred files at best and just stops. > When it stops, I can't login to another terminal. If I have a spare > console logged in, I can't run anything. After a few tries, I manged to > catch it where I had top running in one VT, started the checkout, and > then switched back just in time. I never could even get top up with rm > running (it probably blows over some limit faster). When the checkout > hangs, the state of svnlite is "kmem a" according to top. I can only > guess that is short for kmem alloc, I guess some syscall is waiting on > an allocation that will never happen because something already is using > or has leaked everything that could satisfy that allocation. It looks > like activity on too many files within a short period runs something > out. No, it's just a new bit of debugging code that causes the system to spend lots of CPU time verifying integrity of some of its internal data structures, especially on wimpy hardware (e.g., my dual PII/400 box, which is where I noticed this recently.) You'll find if you're patient that it isn't a complete hang, it will actually get work done in between the debug passes. Set sysctl debug.vmem_check=0 to disable the check. This is I think completely independent from the maxswzone stuff, it's just you were seeing it for the first time since the debug code in question was only recently added to 10-STABLE. Richard From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 19:31:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9117C40 for ; Sat, 1 Feb 2014 19:31:16 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 586A717C8 for ; Sat, 1 Feb 2014 19:31:15 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1W9gHV-000Ap4-Q8 for freebsd-stable@freebsd.org; Sat, 01 Feb 2014 19:31:10 +0000 Date: Sat, 1 Feb 2014 20:31:12 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Processes hang in state "kmem a", system hang follows Message-ID: <20140201203112.0000210c@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 19:31:16 -0000 I'm seeing rather strange behavior from 10.0 on i386 thus far. This is another long message, so if you want the summary without back-story, skip to the end. Sometimes it's hard to include relevant details without feeling like I'm rambling. I'm seeing rather strange behavior from 10.0 on i386 thus far. I started with FreeBSD not long before 4.0 release and ran 4.x releases on i386 and Alpha for a long time. I tried the 5.x releases and had nothing but trouble so stuck with 4.x through that time. The Alpha never did move off 4.x before it got retired, but some of my i386 boxes made it onto 6.x and then sat there until they were taken out of active use. For years, FreeBSD 4.x and 6.x was the reliable OS I used for everything but my desktop (which had been OS X). More recently I started using FreeBSD 8 on amd64 with ZFS and quickly moved on to 9 as soon as 9.0 was released. At the same time, i386 hardware retired from desktop roles but suitable for network services got 8.x installed on UFS. I had rather good experience with 9-STABLE on amd64 running with ZFS. For the most part it's solid, ZFS support is much better than the sorry state Apple left it in before abandoning it on OS X, though I did get a few kernel panics when simply connecting disks that contained zpools from OS X. Due to both compilation speed difference and the fact older hardware tends to be in more entrenched roles, I left my i386 systems out of the ZFS and 9.x experiments. I did also try 9.x on my one ppc64 box at various times to see if that might be a good way to utilize hardware Apple dropped support for years prior. The state on ppc64 varied between panic on boot to being able to buildworld but an idle system left for a few days would randomly go zombie, console freezes but clearly there is some system activity and it responds to ping but might not take a ssh connection, which I chalked up to the experimental state of the port. I did see console freezes on i386 boxes booted from a 9.1 mfsbsd image but never investigated because I was just using it to image and erase disks on old machines where I considered the hardware suspect. In the last couple months I've been moving my amd64 systems to 10, starting during the RCs and keeping up such that they are now all 10-STABLE. The transition was fairly smooth and they are running quite well. Even one box that has prior chipset and BIOS, which was panicking with an early 10-BETA is now running 10.0-RELEASE with KMS. All very impressive. So, time to start migrating some i386 boxes I figure. I had recently moved a number of them to 9.2 and figured I should just go ahead and move everything up to 10.0 at close to the same time if possible. I had seen no problems with 9.2 or 9-STABLE on the i386 boxes that I was preparing to upgrade, I already sorted out one Clang bug that affected a few (but less worse than a similar GCC bug that remains unfixed) since I had switched compilers when going to 9. Since I started moving i386 boxes to 10.0, I've had nothing but strange problems. Last night I wrote a message about kern.maxswzone, something I started getting warnings about on one particular box when I put 9.2 on it but which I didn't try to do anything about until now. I wrote that message with this one in mind, mentioning that I would have another about processes hanging. That one came first because it has at least some hard numbers and not so much subjective feelings of performance and reliability. Between then and now, the pattern struck me, all my early successes with 10 were amd64, and now all the i386 boxes I've upgraded are barely functional. I have 4 i386 boxes that I tried to put 10.0 on in the past week with various degrees of fail. There are 2 sets within the four, two are the low-end C3 boxes with 256MB and 384MB RAM described in my prior message to the list. The other two are Pentium4 systems, one with 2GB RAM and the other with 3GB, substantially bigger disks, decent GPU, etc. In other words, two are ancient and two are merely a little dated but still very usable. This faster pair I will mention first, then I will return to the slow pair. All these boxes are things I use around the house for network services or as essentially terminals in other rooms (kitchen pc to look up stuff, bedroom pc to watch movies, etc). The i386 boxes that run important services (externally facing network services, routing/firewall, etc) and being left two a second round once all issues are sorted out on these lower-importance boxes first. The P4s had 9-STABLE installed on UFS volumes. I did the switch from csup to svnup to pull the 10.0 sources, did the buildworld/kernel and install on both and all looked good. Before I went on to reinstall packages or anything else, I decided now might be a good time to try switching from UFS to ZFS, everything in /home was already backed up. So far I had only tried ZFS on amd64 due to early reports of flakiness on i386 related to exhausting kernel memory. In the couple years since initial support, the ZFS code has gotten better integrated, more people have tried it, some tuning guides have been written, and I've seen reports of it being used on boxes with 512MB RAM. Most of my i386 boxes in server roles have 2GB and it would be nice to migrate those to ZFS if possible. Best to test on these boxes first and try tuning if needed. I booted both P4 boxes from mfsbsd CD, mounted the existing UFS volums, tar the whole mess and drop the uncompressed tar on my file server. On the server, I fired off xz to compresses the tar file to speed the restore (or so I thought) while I prepared the machines. I setup the zpools in the normal way I'd done all my amd64 boxes. One P4 box has a single disk, the other has two, so one is a single vdev pool and the other is multiple, which adds a little variety for testing. Aside from vdevs, the pool properties, filesystems and their properties are all identical to how I've been setting up my other ZFS boxes. LZ4 on most filesystems, gzip or none on a few, sha256 hashes entirely, no dedupe, pretty normal. With the pools configured and mounted on /zroot, I scp the tar.xz file for each box into /tmp (which is tmpfs), and try tar xjpvf in /zroot. After initial good progress, both boxes seemed to hang at about the same time. Disk activity stops, tar is sitting there as if it's going to do something, but no further progress on either when left for an hour. I started top on both boxes and notice that the tar process on each is in the state "kmem a" and the resident memory allocation on each is exactly the same (around 750MB). My first thought was that I used too much RAM with the 500MB tar.xz file in tmpfs. One box says 800MB free and the other says 1800MB free but maybe there is a shortage of kernel memory. I can't seem to kill tar, so I just reboot each, clear the zpools to try from a fresh state again, mount the swap before filling /tmp this time, then attempt another extract. No joy, it stops the same way, with the exact same memory allocation, and each box is stopped on the exact same file as where each stopped on the first attempt. The free memory reports are the same as before, no sawp is being used, whatever is running out must be non-pageable. The next thing I try is decoupling the stages. The tar process is growing so large because it has to decompress lzma which requires a huge dictionary. I figure maybe the heavy disk I/O is causing buffers/cache to contend with the process in some way. Reboot again for a fresh start, scp the .tar.xz to /zroot/tmp, xz -d so it's just a plain tar, then tar xpvf in /zroot and both complete without error. Set the mointpoint to / for each zroot and reboot into the running system. That was strange but solvable. I don't know what the "kmem a" state is but I can guess it's probably short for something like "kmem alloc" which would suggest to me the process is waiting on a kernel allocation. So I figure I've got some tuning to do and a hung process isn't as bad as the kernel panics others had reported on i386 under heavy I/O load (e.g. rsync) with default settings. After all, the boot messages include two warnings about tuning ZFS memory on i386. In order to do the tuning, I need some reproducible load, and buildworld is good for that. So, first thing is switch from svnup to svnlite that is now in base and use that to get 10-STABLE sources. I do the rm -r on /usr/src and /usr/ports and then fire off the svnlite co for each. I find that the slowness of svn checkout is due to network latency and running the two in parallel doesn't create I/O contention on either disk or network. While the P4s are fetching their sources, I go to deal with the pair of Via C3 boxes that I had taken to 10-PRERELEASE just a week prior and was ready to upgrade to 10-STABLE. Since that upgrade, they sat unused waiting for an impending MFC so I could do away with a local patch. As mentioned in my other message, I made a mistake here on my first attempt, I forgot to clear the existing /usr/src and /usr/ports before starting the svnlite checkout. After realizing my mistake, I did the now larger (as it includes a .svn dir) rm -r of those dirs to start fresh. That's when I hit the problem with rm hanging on one box. Without repeating all the details, I had to boot mfsbsd to do the rm on the one box with only 256MB RAM, but what difference that made is simply inexplicable. Once I had gotten that straightened out, I started off the svnlite checkout fresh. On the box with 384MB, the completed with only one restart for network dropout (common since it takes 2-3 hours per checkout). On the box with 256MB (which had previously fully checked out and gotten to the point where it wanted to prompt me for the conflict on every file in the tree), svnlite could only do a hundred files or so before it seemed to hang in the same way as rm. Running just one instance on /usr/src without the parallel checkout on /usr/ports made no difference. When rm was hanging, I might be able to kill it (after several minutes wait) and reboot or the console might lock. When svnlite hung, I could not login but I might be able to run a command on another VT. I was able to catch that svnlite is getting stuck in the state "kmem a". Hmmm... the same state that tar was getting stuck in on the other boxes. How were those doing now? I look back at the P4s, which should be done as it's been a few hours spent on the C3 boxes. They are sitting there in the middle of checkout not making any visible progress. Ctrl-c doesn't work, I can't switch VTs, even ctrl-alt-del seems to not work. Seems like the consoles are hung in a way eerily similar to what I'd seen from 9.x on non-amd64 platforms (both ppc64 and i386). I attempted to initiate an ssh connection into each of the P4s and then walked off for a minute for refreshment. When I came back, expecting to find a login prompt or a timeout, I found the ssh attempts timed out and the two boxes had rebooted. I don't know if the ctrl-alt-del finally registered or if the incoming ssh connection pushed them over the edge. I wasn't there to see and the logs for both stop sometime before the hang. With both rebooted, I do a svnlite cleanup in /usr/src and /usr/pots or both, then fire off the svnlite co for each directory on both boxes. While those were running, I started digging into the kern.maxswzone tunable on the C3 box with less RAM. The box with more RAM was able to do the rm, svn checkout of both src and ports in parallel, and showed no obvious sign of trouble, though I hadn't started a buildworld yet. The box with less RAM was failing all over the place and the only obvious difference was the warning about that tunable. After I wasted hours figuring out the value is already sufficient but is apparently reduced after it's set, so it can't be effectively turned up, only down, I wrote my previous message to this list on that topic specifically and then went to bed. This morning I got up and was already thinking about the correlation, that 10 is a disaster on all my i386 boxes thus far. The first thing I checked was the P4 boxes. Both completed the svn checkout on both src and ports, good sign. However, the box with 3GB RAM has the message "vm_thread_new: kstack allocation failed" repeated about a dozen times, bad sign. First thing I do is try to run top to see what the size of ARC is, free RAM, etc. "No more processes." Uh Oh, that's no good at all, can't even run top. Curiously, the box with less RAM, only 2GB, has no messages so I try to start top on it to see what it's state is. Nothing happens when I push return, the cursor is just sitting there after top. On another VT, reboot gets the same response, none, cursor just sits. I can't type but I can switch VTs and scroll, until I do ctrl-alt-del, then every key press after that is a beep. Back on the once that said no processes left for top, reboot gets the same non-response. ctrl-alt-del doesn't beep, it just spits out the ^[[3~ typical of a dead console. Ugh, not even a reset button to punch on these P4 boxes. So, svnlite checkout is a real strain that can bring a system to it's knees. I'm not sure if this should be regarded as horrible inefficiency or as a means of checking the box before launching into a buildworld (as if that wasn't enough strain to uncover most problems). While 10.0 is good on amd64, it seems a disaster on i386. Processes hang in this "kmem a" state it doesn't take much more to get the box to livelock. I've only seen the "kmem a" state a few times as most other times I can't inspect anything before the box is locked too hard to do anything. In some cases I'm not sure there's even a way to get the box shutdown clean as the most trivial of things lock it up hard. It's not even required to do anything. When I was experimenting with kern.maxswzone last night I rebooted one box a few dozen times, so if I didn't need to look at systcl output I just hit ctrl-alt-del at the login prompt. Once the console died right then, it had just booted and ctrl-alt-del was met with a beep and then it's hung, have to punch reset. I'm guessing the console dies as a result of total wedging of I/O systems following heavy disk I/O. The cause is not just ZFS because the C3 boxes are UFS. The problem is not just the excess swap on the smallest box because I see the same sort of troubles on the box with the most RAM. Some kernel resource seems to be exhausted regardless of how much RAM or swap is present. I'm going to try buildworld on 3 of these to see what happens. For the fourth, I still need to get sources onto the disk before I can even attempt that. I'm not sure what to expect. It might be instant miserable failure, or it might actually run a long time since the I/O load is in bursts with lots of recovery time between. It'll take a few hours to see if the P4s succeed. It'll take two days to see a C3 succeed. Maybe by that time, someone will get through all I've written and have some useful suggestion for debugging. To me, it's rather hard to debug since I have little hint where to start, when the problem manifests any logging stops, and the box is in a state where it is essentially unobservable without a JTAG to jump in and directly inspect the state of it's world. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 20:44:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D905385B; Sat, 1 Feb 2014 20:44:21 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 746F01D13; Sat, 1 Feb 2014 20:44:21 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.7/8.14.7) with ESMTP id s11Ki7K5011538 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 1 Feb 2014 14:44:07 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52ED5C97.8030503@tundraware.com> Date: Sat, 01 Feb 2014 14:44:07 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Followup On Recent MCA Madness. WAS: Need Help With MCA Code References: <52E73717.3000503@tundraware.com> <52E99381.5050803@tundraware.com> <201401311222.12136.jhb@freebsd.org> <52EBE1FA.2040603@tundraware.com> In-Reply-To: <52EBE1FA.2040603@tundraware.com> 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.4.3 (ozzie.tundraware.com [75.145.138.73]); Sat, 01 Feb 2014 14:44:07 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s11Ki7K5011538 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Hardware Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 20:44:21 -0000 On 01/31/2014 11:48 AM, Tim Daneliuk wrote: > On 01/31/2014 11:22 AM, John Baldwin wrote: >> On Wednesday, January 29, 2014 6:49:21 pm Tim Daneliuk wrote: >>> Resending in hopes that people on one of the other lists will have some insight here: >>> >>> On 01/27/2014 10:50 PM, Tim Daneliuk wrote: >>>> I am running 9.2 stable i386 r261207. As noted earlier: >>>> >>>>> I just replaced mobo/CPU on FBSD server (Gigabyte Z-87-D3HP with >>>>> an Intel i3-4130). I am not overclocking ... but I continue to see this sort of thing: >>>> >>>>> MCA: CPU 0 COR (1) internal parity error >>>> >>>> Dmesg shows: >>>> >>>>> MCA: Vendor "GenuineIntel", ID 0x306c3, APIC ID 0 >>>>> MCA: CPU 0 COR (1) internal parity error >>>>> MCA: Bank 0, Status 0x90000040000f0005 >>>>> MCA: Global Cap 0x0000000000000c07, Status 0x0000000000000000_ >>>> >>>> I've swapped CPUs (i5). I've fiddled with an endless supply of >>>> mobo settings. I've switched power supplies. I've moved mem >>>> sticks around .... No joy. >>>> This got resolved when I did a completely fresh install of FBSD 10 on the server. This made the MCAs go away. I therefore conclude that there were one of several possible root causes: - FreeBSD i386 doesn't play nice with Haswell parts - FreeBSD 9.2-STABLE i386 doesn't place nice with Haswell parts - My FreeBSD 9.2-STABLE i386 instance was corrupted somehow My belief is that it is mostly likely the last culprit, absent someone confirming that the first two are possibilities. The good thing that came out of this is that I finally upgraded this server in some important ways: - 64 bit - FreeBSD 10 - Latest bind 9 Now, if I could just figure out how to get stock X to run at 1920x1080 on HD4600 graphics. Apparently neither the intel of vesa drivers know how to do this, or at least I've had no luck with it. The intel driver doesn't even recognize the hardware as something it supports. "X on a server?" you say? Yes, for intermittent use of fluxbox to run a bunch of xterms. ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Sat Feb 1 21:16:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF0CB55D for ; Sat, 1 Feb 2014 21:16:17 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54DFD1F36 for ; Sat, 1 Feb 2014 21:16:16 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1W9hv9-000MkJ-6i; Sat, 01 Feb 2014 21:16:11 +0000 Date: Sat, 1 Feb 2014 22:16:12 +0100 From: Matthew Rezny To: Richard Todd Subject: Re: Tuning kern.maxswzone Message-ID: <20140201221612.00001897@unknown> In-Reply-To: References: <20140201070912.00007971@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 21:16:17 -0000 On Sat, 01 Feb 2014 13:03:15 -0600 Richard Todd wrote: > Matthew Rezny writes: > > > So, as best I can tell, the actual effective number used for > > kern.maxswzone is indeed approximately 8x available RAM. If there is > > some need to turn it down (using substantially less swap) then that > > is possible, but turning it up (as suggested by the warning > > message) is not possible. Setting any value higher does not appear > > to actually > > Yeah, IIRC I ran into that when configing some VMs with > really big swap space for benefit of tmpfs. This is the quick hack > I used to get around that, you might give it a try. > > # HG changeset patch > # Parent e4dd7df011139e2b224835aa6e330c90afcf9a55 > patch swap_pager to unconditionally use maxswzone tunable if it is > set -- helpful for our tbvm VMs with large swap space for tmpfs > > diff -r e4dd7df01113 sys/vm/swap_pager.c > --- a/sys/vm/swap_pager.c Wed Feb 20 00:15:49 2013 -0600 > +++ b/sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600 > @@ -546,7 +546,7 @@ > * is typically limited to around 32MB by default. > */ > n = cnt.v_page_count / 2; > - if (maxswzone && n > maxswzone / sizeof(struct swblock)) > + if (maxswzone) > n = maxswzone / sizeof(struct swblock); > n2 = n; > swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), > NULL, NULL, > Thank you for pointing me in the right direction. Now that I'm looking at the right file, I don't know how I failed to find it myself with grep. The logic here is rather obviously flawed, the maxswzone value is only used if it is less than the calculated default. If there is some reason to not allow adjusting this up, then the warning message is incorrect. Either way, something should change and I guess I should file a PR on this one. At least I can see the warning is taking the doubling for safety into account, so for my particular case with an overrun under 10% it should probably be ok to put fixing this on the back burner. > Also, > > > With /usr/src cleared (and after running fsck) I booted back into > > 10-PRERELEASE to try to fetch the 10-STABLE sources again. I started > > svnlite co and find it hung shortly thereafter. I tried a few times > > but each time I see it does a couple hundred files at best and just > > stops. When it stops, I can't login to another terminal. If I have > > a spare console logged in, I can't run anything. After a few tries, > > I manged to catch it where I had top running in one VT, started the > > checkout, and then switched back just in time. I never could even > > get top up with rm running (it probably blows over some limit > > faster). When the checkout hangs, the state of svnlite is "kmem a" > > according to top. I can only guess that is short for kmem alloc, I > > guess some syscall is waiting on an allocation that will never > > happen because something already is using or has leaked everything > > that could satisfy that allocation. It looks like activity on too > > many files within a short period runs something out. > > No, it's just a new bit of debugging code that causes the system > to spend lots of CPU time verifying integrity of some of its internal > data structures, especially on wimpy hardware (e.g., my dual PII/400 > box, which is where I noticed this recently.) You'll find if you're > patient that it isn't a complete hang, it will actually get work done > in between the debug passes. Set sysctl debug.vmem_check=0 to disable > the check. This is I think completely independent from the maxswzone > stuff, it's just you were seeing it for the first time since the > debug code in question was only recently added to 10-STABLE. > If only it were that simple. I'm not yet on 10-STABLE, I'm struggling to get the sources to reach that point. These C3 boxes are 10-PRERELEASE so I don't yet have this debug.vmem_check to tweak. sysctl says unknown oid when I query it. I tried setting it from loader prompt but still says unknown oid and I see no change in behavior. Also, I'm not seeing anything using lots of CPU time. If I start off top on another VT before I start svnlite, then I have a decent chance of seeing what goes on until the situation becomes dire. svnlite starts off moving quick and using lots of CPU time (>50%) for the first hundred files or so, then it halts in the "kmem a" state and CPU is completely idle. It sits there for a while, and eventually does something more. Each time the stop is longer and less work is done in the interval between stops. Eventually the process appears to hang completely in that I can leave it for half a day and no more progress is made. The rm process could go longer in this state with still some visible progress since it's operation is sufficiently simple to actually observe it managed to do something, whereas svnlite might do something occasionally but it's not enough to get to the next file in the list. With each burst and wait cycle, I see a spray in dmesg saying calcru: runtime went backwards [lots] for {all processes}. If I hit ctrl-C and wait, it'll interrupt svnlite the next time it would do something other than wait. It can easily take 10 min for that to happen, meaning the wait period is long enough to consider the process as not effectively running. If I let it go long enough, it gets to a state where it never exits on ctrl-c (or at least it'd take more hours than I've been willing to wait). In this last attempt, I let it go for 5 min, pushed ctrl-c, waited another 10 min, then tried ctrl-alt-del and that just beeps so the attempt to interrupt the process resulted in total I/O lockup to the point key presses are not handled. That last one was enough to finally require manual fsck on reboot (which should be a testament to the resiliency of UFS as I've pushed the reset button a hundred times in the past day and a half). > Richard > > Thank you for taking the time to respond. It's now clear the maxswzone is just a red herring, the real issue are the apparent hangs which I'm seeing on several more boxes. The mystery is why the one box with slightly more RAM seems ok, but a couple boxes with far more RAM are not ok. That will probably be answered when I figure out what the cause is.