From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 03:04:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35F3C1065673 for ; Sun, 11 Jul 2010 03:04:59 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0A64B8FC1C for ; Sun, 11 Jul 2010 03:04:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 6E6215093D for ; Sun, 11 Jul 2010 04:04:58 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvBlOC1N4gdq for ; Sun, 11 Jul 2010 04:04:57 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id EED4C5089E for ; Sun, 11 Jul 2010 04:04:56 +0100 (BST) Message-ID: <4C3934D9.3030501@langille.org> Date: Sat, 10 Jul 2010 23:04:57 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Authentication tried for XXX with correct key but not from a permitted host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 03:04:59 -0000 This is more for the record than asking a specific question. Today I upgraded a system to FreeBSD 8.1-PRERELEASE. Then I started seeing these messages when I ssh to said box with an ssh-agent enabled connection: Jul 11 03:43:06 ngaio sshd[30290]: Authentication tried for dan with correct key but not from a permitted host (host=laptop.example.org, ip=10.0.0.100). Jul 11 03:43:07 ngaio sshd[30290]: Authentication tried for dan with correct key but not from a permitted host (host=laptop.example.org, ip=10.0.0.100). Jul 11 03:43:07 ngaio sshd[30290]: Accepted publickey for dan from 10.0.0.100 port 53525 ssh2 My questions were: 1 - how do I set a permitted host? 2 - why is the message logged twice? That asked, I know if I move the key to the top of the ~/.ssh/authorized_keys file, the message is no longer logged. Further investigation reveals that if a line of the form: from="10..etc" appears before the key being used to log in, the message will appear. Solution: move the from= line to the bottom of the file. Ugly, but it works. -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 07:45:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1BCE106566B for ; Sun, 11 Jul 2010 07:45:01 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 57A5F8FC12 for ; Sun, 11 Jul 2010 07:45:01 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o6B7ikGG067482 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 11 Jul 2010 08:44:55 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4C397668.6060904@infracaninophile.co.uk> Date: Sun, 11 Jul 2010 08:44:40 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C3934D9.3030501@langille.org> In-Reply-To: <4C3934D9.3030501@langille.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB0580895971B966953610BFB" X-Virus-Scanned: clamav-milter 0.96.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_40,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: Authentication tried for XXX with correct key but not from a permitted host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 07:45:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB0580895971B966953610BFB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/07/2010 04:04:57, Dan Langille wrote: > That asked, I know if I move the key to the top of the > ~/.ssh/authorized_keys file, the message is no longer logged. Further > investigation reveals that if a line of the form: >=20 > from=3D"10..etc" >=20 > appears before the key being used to log in, the message will appear. Usually the from=3D'10.0.0.100' tag should be inserted at the beginning o= f the line for each key it should affect. It shouldn't do anything on a line on its own -- in fact that should be a syntax error. The behaviour you're seeing sounds like something new: it isn't what sshd(8) describes in the section on AUTHORIZED_KEYS FILE FORMAT. This new behaviour sounds as if it could be quite useful for easing the management of complicated authorised_keys files, but I'd have expected some sort of notice somewhere. I can't see anything relevant in the release notes for OpenSSH for versions 5.0, 5.1, 5.3, 5.3, 5.4 or 5.5 [Eg. http://www.openssh.org/txt/release-5.4 -- 8.1-PRERELEASE has OpenSSH 5.4p1 bundled]. Nor anything in any of the ssh(1), ssh_config(1), sshd(8), sshd_config(8) man pages. Maybe it's a bug, but one that has fortuitously useful effects. Cheers, Mathew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigB0580895971B966953610BFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5dm4ACgkQ8Mjk52CukIzKLwCghPzYo8Wva0y18HT8J1alkRvi sJkAn2ctpzzAtC2sn3ILSNcHY4LsGdnr =X+pL -----END PGP SIGNATURE----- --------------enigB0580895971B966953610BFB-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 15:43:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 791A7106566B for ; Sun, 11 Jul 2010 15:43:52 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp1.sbb.rs (smtp1.sbb.rs [89.216.2.33]) by mx1.freebsd.org (Postfix) with ESMTP id E48098FC14 for ; Sun, 11 Jul 2010 15:43:51 +0000 (UTC) Received: from localhost (cable-94-189-181-102.dynamic.sbb.rs [94.189.181.102]) by smtp1.sbb.rs (8.14.0/8.14.0) with ESMTP id o6BFhnbg030902 for ; Sun, 11 Jul 2010 17:43:49 +0200 Date: Sun, 11 Jul 2010 17:43:49 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20100711154349.GA1247@pilgrim.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -2.0 Subject: dmg handling X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 15:43:52 -0000 Howdy! I got a file made on mac, sized at 142 mb and with dmg extension. It is a dump of 4 gb SD card with firmware upgrade files. File says: disk1s1.dmg: VAX COFF executable not stripped So, compressed. The file system on that original card is ext3. Linux people use dmg2img utility to decompress and then mount it with options like: mount -o loop -t hfsplus image dir If correct, I could try to bunzip2 it first, then rsync to sheevaplug node (ubuntu on it) and mount finally. The final step would be to write that ima- ge to new SD card and use it to upgrade the gadget. I was sure that simple dd would suffice, but more I read, more I see it's wrong. I also assume that I cannot write that image to smaller, 2 gb SD card. Any idea what to do in this situation? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 18:44:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 109BF1065673 for ; Sun, 11 Jul 2010 18:44:14 +0000 (UTC) (envelope-from ricky@csua.berkeley.edu) Received: from mail.CSUA.Berkeley.EDU (mail.CSUA.Berkeley.EDU [128.32.112.223]) by mx1.freebsd.org (Postfix) with ESMTP id F25A38FC1B for ; Sun, 11 Jul 2010 18:44:13 +0000 (UTC) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [10.1.1.4]) by mail.CSUA.Berkeley.EDU (Postfix) with ESMTP id 0C1E32E0C2 for ; Sun, 11 Jul 2010 11:23:01 -0700 (PDT) Received: from ricky by soda.CSUA.Berkeley.EDU with local (Exim 4.69) (envelope-from ) id 1OY1DE-0005qU-8q for freebsd-stable@freebsd.org; Sun, 11 Jul 2010 11:25:12 -0700 Date: Sun, 11 Jul 2010 11:25:12 -0700 From: Richard Lee To: freebsd-stable@freebsd.org Message-ID: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 18:44:14 -0000 This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. The closest I found by Googling was this: http://forums.freebsd.org/showthread.php?t=9935 And it talks about all kinds of little tweaks, but in the end, the only thing that actually works is the stupid 1-line perl code that forces the kernal to free the memory allocated to (non-zfs) disk cache, which is the "Inact"ive memory in "top." I have a 4-disk raidz pool, but that's unlikely to matter. Try to copy large files from non-zfs disk to zfs disk. FreeBSD will cache the data read from non-zfs disk in memory, and free memory will go down. This is as expected, obviously. Once there's very little free memory, one would expect whatever is more important to kick out the cached data (Inact) and make memory available. But when almost all of the memory is taken by disk cache (of non-zfs file system), ZFS disks start threshing like mad and the write throughput goes down in 1-digit MB/second. I believe it should be extremely easy to duplicate. Just plug in a big USB drive formatted in UFS (msdosfs will likely do the same), and copy large files from that USB drive to zfs pool. Right after clean boot, gstat will show something like 20+MB/s movement from USB device (da*), and occasional bursts of activity on zpool devices at very high rate. Once free memory is exhausted, zpool devices will change to constant low-speed activity, with disks threshing about constantly. I tried enabling/disabling prefetch, messing with vnode counts, zfs.vdev.min/max_pending, etc. The only thing that works is that stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the activity to that seen right after a clean boot. It doesn't last very long, though, as the disk cache again consumes all the memory. Copying files between zfs devices doesn't seem to affect anything. I understand zfs subsystem has its own memory/cache management. Can a zfs expert please comment on this? And is there a way to force the kernel to not cache non-zfs disk data? --rich From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 19:46:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60FCF1065676 for ; Sun, 11 Jul 2010 19:46:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from stith.flb.omnilan.net (stith.flb.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D6B518FC19 for ; Sun, 11 Jul 2010 19:46:05 +0000 (UTC) Received: from titan.lan.flb.omnilan.net (titan.lan.flb.omnilan.net [172.21.1.150]) (authenticated bits=0) by stith.flb.omnilan.net (8.13.8/8.13.8) with ESMTP id o6BJk5mk076003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jul 2010 21:46:05 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4C3A1F72.2040303@omnilan.de> Date: Sun, 11 Jul 2010 21:45:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: FreeBSD Stable , wxs@freebsd.org, mtm@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2ED1EE57AEA2B702AC55986" Cc: Subject: syslogs altlog_proglist and isc-dhcpd logging for FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 19:46:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2ED1EE57AEA2B702AC55986 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, since isc-dhcpd-4.1.1 promised ipv6, I wanted to replace my existing=20 DHCP servers with this new version. I'm running chrooted. My problem was with logging. dhcpd is very noisy and setting "log-facility local1" in dhcpd.conf=20 doesn't work out of the box (*) because of the chrooted environment. But some good guys already coded everything which is needed to have=20 dhcpd logging with chrooted. - syslogd has the -l switch which enables to place an additional log=20 socket into the chrooted enivronment. - /etc/rc.d/syslogd already knows about this and has the variable=20 altlog_proglist, which checks for possible chrooted daemons The problems are: - /etc/rc.d/syslogd has the altlog_proglist hard coded - /etc/rc.d/syslogd checks for daemons in rc.conf which have flags=20 any_chrootdir, but rc.d/isc-dhcpd uses dhcpd_rootdir. So here's the view simple lines that make dhcpd logging working with=20 individula log-facility configs: --- etc/rc.d/syslogd 2009-09-06 02:47:31.000000000 +0200 +++ etc/rc.d/syslogd 2010-07-11 21:27:46.477366986 +0200 @@ -1,6 +1,6 @@ #!/bin/sh # -# $FreeBSD: src/etc/rc.d/syslogd,v 1.13.2.1 2009/08/03 08:13:06=20 kensmith Exp $ +# $FreeBSD: src/etc/rc.d/syslogd,v 1.13.2.1.4.1 2010/06/14 02:09:06=20 kensmith Exp $ # # PROVIDE: syslogd @@ -19,7 +19,9 @@ sockfile=3D"/var/run/syslogd.sockets" evalargs=3D"rc_flags=3D\"\`set_socketlist\` \$rc_flags\"" -altlog_proglist=3D"named" + +load_rc_config $name +altlog_proglist=3D${syslogd_altlog_proglist:-"named"} syslogd_precmd() { --- etc/defaults/rc.conf 2009-11-01 15:08:40.000000000 +0100 +++ etc/defaults/rc.conf 2010-07-11 21:30:04.373974162 +0200 @@ -255,6 +255,7 @@ syslogd_enable=3D"YES" # Run syslog daemon (or NO). syslogd_program=3D"/usr/sbin/syslogd" # path to syslogd, if you want a = different one. syslogd_flags=3D"-s" # Flags to syslogd (if enabled). +syslogd_altlog_proglist=3D"named" # Check vor chrooted daemons and place= =20 additional socket inetd_enable=3D"NO" # Run the network daemon dispatcher (YES/NO). inetd_program=3D"/usr/sbin/inetd" # path to inetd, if you want a=20 different one. inetd_flags=3D"-wW -C 60" # Optional flags to inetd --- etc/rc.d/isc-dhcpd.orig 2010-07-08 13:03:45.000000000 +0200 +++ etc/rc.d/isc-dhcpd 2010-07-11 20:41:36.000000000 +0200 @@ -32,7 +32,7 @@ dhcpd_chroot_enable=3D${dhcpd_chroot_enable:-"NO"} # runs chrooted? dhcpd_devfs_enable=3D${dhcpd_devfs_enable:-"YES"} # devfs if available= ? -dhcpd_rootdir=3D${dhcpd_rootdir:-/var/db/${name}} # directory to run in= +dhcpd_rootdir=3D${dhcpd_chrootdir:-/var/db/${name}} # directory to run = in # dhcpd_includedir=3D"" # directory for included config files safe_run () # rc command [args...] Is it possible to get these changes into base system? @wxs Any objections changing dhacpd_rootdir into dhcpd_chrootdir variable= ? Shall I file a PR? Thanks, -Harry P.S.: For the records, here another possibility to make dhcpd use=20 different syslog facility in chrooted environmen: (*) Chaging the syslog facility of dhcpd with "log-facility local7;" in=20 dhcpd.conf doesn't work for chrooted dhcpd. At startup, it uses the local datagram syslogd socket /dev/log=20 (/var/run/syslog.sockets). The syslog facility change is done after changeroot took place, so in=20 the chrooted environment there is no syslogd reachable. To change the default syslog facility from LOG_DAEMON to LOG_LOCAL7 add=20 the following to the ports Makefile: CONFIGURE_ENV=3D CPPFLAGS=3D"-DDHCPD_LOG_FACILITY=3DLOG_LOCAL7 ...... *s= nip* --------------enigB2ED1EE57AEA2B702AC55986 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkw6H3sACgkQLDqVQ9VXb8iubwCeIiq+oH7zVIoVXWKVfCDgNOpo l2oAn2NTWQplEjHBTT9JFmoW6l94Ef4E =OWsE -----END PGP SIGNATURE----- --------------enigB2ED1EE57AEA2B702AC55986-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 20:08:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5A51065676; Sun, 11 Jul 2010 20:08:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1038B8FC0C; Sun, 11 Jul 2010 20:08:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6BK3Qro020493; Sun, 11 Jul 2010 14:03:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Jul 2010 14:03:44 -0600 (MDT) Message-Id: <20100711.140344.239525524663396359.imp@bsdimp.com> To: yanefbsd@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: re@freebsd.org, tom@hur.st, freebsd-usb@freebsd.org, freebsd-stable@freebsd.org, mi+thun@aldan.algebra.com, freebsd@jdc.parodius.com Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 20:08:37 -0000 In message: Garrett Cooper writes: : On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. wrote: : > 07.07.2010 14:59, Jeremy Chadwick ???????(??): : >>> : >>> =A0 =A0 =A0FREEBSD_COMPAT7 kernel option is, apparently, a requir= ement (and : >>> =A0 =A0 =A0thus not an "option") -- the kernel-config files, that= worked with : >>> =A0 =A0 =A07.x, break without this option in them (in addition to= all the : >>> =A0 =A0 =A0nuisance, that's documented in UPDATING -- which, some= how, makes : >>> =A0 =A0 =A0the breakage acceptable). config(8) would not warn abo= ut this, but : >>> =A0 =A0 =A0kernel build fails. : >>> : >> : >> We don't use this option (meaning it's removed from our kernels). = =A0It's : >> definitely not required. =A0All it does is ensure your kernel can : >> comprehend executables/binaries built on 7.x. : >> : > : > Attached is the kernel config-file (i386), that worked fine under 7= .x. The : > kernel-compile will break (some *freebsd7* structs undefined), with= out the : > COMPAT_FREEBSD7 option. Try it for yourself... : = : options SYSVSHM # SYSV-style shared memory : options SYSVMSG # SYSV-style message queues : options SYSVSEM # SYSV-style semaphores : = : Those require COMPAT_FREEBSD7. This does seem like a bug: : = : static struct syscall_helper_data shm_syscalls[] =3D { : SYSCALL_INIT_HELPER(shmat), : SYSCALL_INIT_HELPER(shmctl), : SYSCALL_INIT_HELPER(shmdt), : SYSCALL_INIT_HELPER(shmget), : #if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \ : defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7) : SYSCALL_INIT_HELPER(freebsd7_shmctl), : #endif : = : The check should be for COMPAT_FREEBSD7 only I would think. : = : Apart from that, everything else should work without it I would think= .= You would think that, but you'd be wrong. In general, if you have COMPAT_FREEBSDx defined, you need all COMPAT_FREEBSDy for y > x defined. The reason for this is that we name the compat shim for the version where it was removed, but it is needed for all prior versions. freebsd7_shmctl is needed to emulate the earlier versions as well... This is why we'd like to move to something more like COMPAT_MIN_FREEBSD=3Dz, but there's hooks into the config system and syscall tables that make it tricky... Warner From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 20:48:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214A41065674 for ; Sun, 11 Jul 2010 20:48:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id C4C6D8FC17 for ; Sun, 11 Jul 2010 20:47:59 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id gkVc1e0030Fqzac52knzdw; Sun, 11 Jul 2010 20:47:59 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta08.westchester.pa.mail.comcast.net with comcast id gkny1e0073LrwQ23Uknz7r; Sun, 11 Jul 2010 20:47:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 736629B425; Sun, 11 Jul 2010 13:47:57 -0700 (PDT) Date: Sun, 11 Jul 2010 13:47:57 -0700 From: Jeremy Chadwick To: Richard Lee Message-ID: <20100711204757.GA81084@icarus.home.lan> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 20:48:00 -0000 On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: > This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. > > The closest I found by Googling was this: > http://forums.freebsd.org/showthread.php?t=9935 > > And it talks about all kinds of little tweaks, but in the end, the > only thing that actually works is the stupid 1-line perl code that > forces the kernal to free the memory allocated to (non-zfs) disk > cache, which is the "Inact"ive memory in "top." > > I have a 4-disk raidz pool, but that's unlikely to matter. > > Try to copy large files from non-zfs disk to zfs disk. FreeBSD will > cache the data read from non-zfs disk in memory, and free memory will > go down. This is as expected, obviously. > > Once there's very little free memory, one would expect whatever is > more important to kick out the cached data (Inact) and make memory > available. > > But when almost all of the memory is taken by disk cache (of non-zfs > file system), ZFS disks start threshing like mad and the write > throughput goes down in 1-digit MB/second. > > I believe it should be extremely easy to duplicate. Just plug in a > big USB drive formatted in UFS (msdosfs will likely do the same), and > copy large files from that USB drive to zfs pool. > > Right after clean boot, gstat will show something like 20+MB/s > movement from USB device (da*), and occasional bursts of activity on > zpool devices at very high rate. Once free memory is exhausted, zpool > devices will change to constant low-speed activity, with disks > threshing about constantly. > > I tried enabling/disabling prefetch, messing with vnode counts, > zfs.vdev.min/max_pending, etc. The only thing that works is that > stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the > activity to that seen right after a clean boot. It doesn't last very > long, though, as the disk cache again consumes all the memory. > > Copying files between zfs devices doesn't seem to affect anything. > > I understand zfs subsystem has its own memory/cache management. > Can a zfs expert please comment on this? > > And is there a way to force the kernel to not cache non-zfs disk data? I believe you may be describing two separate issues: 1) ZFS using a lot of memory but not freeing it as you expect 2) Lack of disk I/O scheduler For (1), try this in /boot/loader.conf and reboot: # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma="0" For (2), may try gsched_rr: http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 21:02:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA050106564A for ; Sun, 11 Jul 2010 21:02:12 +0000 (UTC) (envelope-from ssanbeg@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78AFB8FC19 for ; Sun, 11 Jul 2010 21:02:12 +0000 (UTC) Received: by pwj9 with SMTP id 9so1721439pwj.13 for ; Sun, 11 Jul 2010 14:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:x-mimeole:thread-index; bh=nKg7bzq89P4P6z8SfaUF/il0uY8TgRgf6Al+64sAcQY=; b=fJzsfLNlSeX+mpc9Q8MWR3aYqDfZomz7cBcCHfqStQdTebA9acngEYtXZx9HqNTJlD HnVVruuVRYsruiV2/lt0HTy/2VFJuY2ZtFBybtUnI5dxOcOEybkqPt7utNSmwZP1tMoB rE20CQCtdNotuKPFwSYhWmBHLsVuPm/5m7oZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :thread-index; b=NJQsfiLXCmvrrYbEOsQ9SE4+XwBIxXVaAhkiZtgsUoBpZrImvpF7oBQUJZ7Izux7W7 oYtp7OpayRBITeUsLHKY44XEtE7u0gWom2miPnY7EEl51fkcPI0uPWIxIm1lazig2aqd iWA7UG/0r16hjVPOgKMZz2hqPZnVsBIuS0sA4= Received: by 10.114.171.3 with SMTP id t3mr5920069wae.196.1278882131750; Sun, 11 Jul 2010 14:02:11 -0700 (PDT) Received: from sunrise (pool-98-117-108-60.sttlwa.fios.verizon.net [98.117.108.60]) by mx.google.com with ESMTPS id d39sm56074930wam.16.2010.07.11.14.02.10 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 14:02:10 -0700 (PDT) From: "Scott Sanbeg" To: References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> In-Reply-To: <20100711204757.GA81084@icarus.home.lan> Date: Sun, 11 Jul 2010 14:02:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Thread-Index: AcshOseOnXpcAhRvR7uDLVQkhOX1OgAATHag Subject: RE: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 21:02:12 -0000 Using Jeremy's suggestion as follows: 1) ZFS using a lot of memory but not freeing it as you expect For (1), try this in /boot/loader.conf and reboot: vfs.zfs.zio.use_uma="0" ... works like a charm for me. Thank you. Scott -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Jeremy Chadwick Sent: Sunday, July 11, 2010 1:48 PM To: Richard Lee Cc: freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: > This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. > > The closest I found by Googling was this: > http://forums.freebsd.org/showthread.php?t=9935 > > And it talks about all kinds of little tweaks, but in the end, the > only thing that actually works is the stupid 1-line perl code that > forces the kernal to free the memory allocated to (non-zfs) disk > cache, which is the "Inact"ive memory in "top." > > I have a 4-disk raidz pool, but that's unlikely to matter. > > Try to copy large files from non-zfs disk to zfs disk. FreeBSD will > cache the data read from non-zfs disk in memory, and free memory will > go down. This is as expected, obviously. > > Once there's very little free memory, one would expect whatever is > more important to kick out the cached data (Inact) and make memory > available. > > But when almost all of the memory is taken by disk cache (of non-zfs > file system), ZFS disks start threshing like mad and the write > throughput goes down in 1-digit MB/second. > > I believe it should be extremely easy to duplicate. Just plug in a > big USB drive formatted in UFS (msdosfs will likely do the same), and > copy large files from that USB drive to zfs pool. > > Right after clean boot, gstat will show something like 20+MB/s > movement from USB device (da*), and occasional bursts of activity on > zpool devices at very high rate. Once free memory is exhausted, zpool > devices will change to constant low-speed activity, with disks > threshing about constantly. > > I tried enabling/disabling prefetch, messing with vnode counts, > zfs.vdev.min/max_pending, etc. The only thing that works is that > stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the > activity to that seen right after a clean boot. It doesn't last very > long, though, as the disk cache again consumes all the memory. > > Copying files between zfs devices doesn't seem to affect anything. > > I understand zfs subsystem has its own memory/cache management. > Can a zfs expert please comment on this? > > And is there a way to force the kernel to not cache non-zfs disk data? I believe you may be describing two separate issues: 1) ZFS using a lot of memory but not freeing it as you expect 2) Lack of disk I/O scheduler For (1), try this in /boot/loader.conf and reboot: # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma="0" For (2), may try gsched_rr: http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view= markup -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ 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 Sun Jul 11 21:28:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 526A8106564A; Sun, 11 Jul 2010 21:28:42 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 102E18FC17; Sun, 11 Jul 2010 21:28:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so4989690iwn.13 for ; Sun, 11 Jul 2010 14:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=mMaxb3gQoGjAXgAn/bjqj6eJLweRv5m+nfMN3MchSiQ=; b=aqCFafCANfbwrQ99K90G/D59iyC8h/297Ntjv3kWoBFylA3mqikeOJm5lhyIcK/5bv G+/Y7QDuQjFQaoZn4FV1kNV87lSbWIUY/87Ty8ZKyHhEQXarkNjm0/QHqGkCejPBk3Pr 4lJw7iv28KAmMMiAMtiotKTeF0gSotHqai6fQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ciQszKmWC4nToc8FqMd+xTlxW/VSTP3nWj/y0spyBLT4g2eEUUU3B1DThibhX/NVXh fknwh5YwMklTzvqmBu+wLEQhUwu9bbSM7wUpWENOnmNFqGu+g36fi6KBP+ODWE3ok7Sz sxkyX9UGFxOFSa6w1IMDoVKkyZW39Xzpm5k9w= MIME-Version: 1.0 Received: by 10.231.31.202 with SMTP id z10mr13628653ibc.191.1278882232786; Sun, 11 Jul 2010 14:03:52 -0700 (PDT) Received: by 10.231.192.147 with HTTP; Sun, 11 Jul 2010 14:03:52 -0700 (PDT) Date: Sun, 11 Jul 2010 14:03:52 -0700 Message-ID: From: Garrett Cooper To: multimedia@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: More buzzing fun with snd_emu10kx - but now with more determinism! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 21:28:42 -0000 Getting back to the thread I brought up before (with my now dead email address): http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-06/msg00036.html , I now have a more deterministic testcase for this issue. The problem appears to be with vchan-related code. If I start up 4+ applications on my machine that access the audio device, all goes wonky on the 4+ allocation (I was stress testing the nvidia driver to see whether or not it'd break with multiple instances of vlc, and stumbled on this by accident). So pushing the number of consumers of the audio subsystem forces a breakdown somewhere (even though the number of available hardware vchans is set to 16). I'll continue to look into this further as time permits. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 21:38:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCFC1065670 for ; Sun, 11 Jul 2010 21:38:55 +0000 (UTC) (envelope-from nukunuku@sbcglobal.net) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by mx1.freebsd.org (Postfix) with SMTP id 8AAFB8FC21 for ; Sun, 11 Jul 2010 21:38:55 +0000 (UTC) Received: (qmail 13277 invoked from network); 11 Jul 2010 21:12:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:Date:To:Cc:Subject:Message-ID:References:Mime-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:From; b=1IKnr5WWHG3Q3Te8Q86dqkrE7izfr5KMCOoLlCTf3MAuhwUz5GdDMNrdea6yjL8sEe8Q3MNtAWpwggPl7gXWDLWVDMEv1D7thPQrtsuc8eTfO7AD0P8MrA/MLAbvYS6hNyy2ASNTIyJeSHoloriY6XlXrSL8zhede2X4NJh79Io= ; Received: from adsl-75-55-221-181.dsl.pltn13.sbcglobal.net (nukunuku@75.55.221.181 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 11 Jul 2010 14:12:14 -0700 PDT X-Yahoo-SMTP: xGthgDWswBCB1BOngQs2nXHlo9uxxXfMF1J0xzNHmECJ9rs- X-YMail-OSG: Jw9_mP4VM1leCVL4zMGVkvgddQZonriWnrdBiP0908._0S6smW.fkJerQxI3yc_u58etZG6P2pgnuC8.0mMpiGPO2DD8kh7W3DYCOCP2YsSGsv78i9_VDpKBECDRn8QY6n1iF89rUu9pl1hkQZInUXrGCBh6uHAMAEVNUARqGi9h75rW8VEMPtv18EUfNCiCxwvYERLLCeVuruICDd8bn0o_XmVKMJOI_JdbHvI56QXKO6LWxXNTPDnlNP4klpp3la84JQTxWTlG9D0r5jq42_egd8dLx4AX.W3R X-Yahoo-Newman-Property: ymail-3 Received: by catsspat.iriomote (Postfix, from userid 1001) id E18782F; Sun, 11 Jul 2010 14:12:13 -0700 (PDT) Date: Sun, 11 Jul 2010 14:12:13 -0700 To: Jeremy Chadwick Message-ID: <20100711211213.GA36377@catsspat.iriomote> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100711204757.GA81084@icarus.home.lan> User-Agent: Mutt/1.4.2.2i From: nukunuku@sbcglobal.net (Richard Lee) Cc: freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 21:38:55 -0000 On Sun, Jul 11, 2010 at 01:47:57PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: > > This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. > > > > The closest I found by Googling was this: > > http://forums.freebsd.org/showthread.php?t=9935 > > > > And it talks about all kinds of little tweaks, but in the end, the > > only thing that actually works is the stupid 1-line perl code that > > forces the kernal to free the memory allocated to (non-zfs) disk > > cache, which is the "Inact"ive memory in "top." > > > > I have a 4-disk raidz pool, but that's unlikely to matter. > > > > Try to copy large files from non-zfs disk to zfs disk. FreeBSD will > > cache the data read from non-zfs disk in memory, and free memory will > > go down. This is as expected, obviously. > > > > Once there's very little free memory, one would expect whatever is > > more important to kick out the cached data (Inact) and make memory > > available. > > > > But when almost all of the memory is taken by disk cache (of non-zfs > > file system), ZFS disks start threshing like mad and the write > > throughput goes down in 1-digit MB/second. > > > > I believe it should be extremely easy to duplicate. Just plug in a > > big USB drive formatted in UFS (msdosfs will likely do the same), and > > copy large files from that USB drive to zfs pool. > > > > Right after clean boot, gstat will show something like 20+MB/s > > movement from USB device (da*), and occasional bursts of activity on > > zpool devices at very high rate. Once free memory is exhausted, zpool > > devices will change to constant low-speed activity, with disks > > threshing about constantly. > > > > I tried enabling/disabling prefetch, messing with vnode counts, > > zfs.vdev.min/max_pending, etc. The only thing that works is that > > stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the > > activity to that seen right after a clean boot. It doesn't last very > > long, though, as the disk cache again consumes all the memory. > > > > Copying files between zfs devices doesn't seem to affect anything. > > > > I understand zfs subsystem has its own memory/cache management. > > Can a zfs expert please comment on this? > > > > And is there a way to force the kernel to not cache non-zfs disk data? > > I believe you may be describing two separate issues: > > 1) ZFS using a lot of memory but not freeing it as you expect > 2) Lack of disk I/O scheduler > > For (1), try this in /boot/loader.conf and reboot: > > # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA > # on 2010/05/24. > # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html > vfs.zfs.zio.use_uma="0" > > For (2), may try gsched_rr: > > http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never touched it. And in my case, Wired memory is stable at around 1GB. It's the Inact memory that takes off, but only if reading from non-zfs file system. Without other file systems, I can keep moving files around and see no adverse slowdown. I can also scp huge files from another system into the zfs machine, and it doesn't affect memory usage (as reported by top), nor does it affect performance. As for gsched_rr, I don't believe this is related. There is only ONE access to the zfs devices (4 sata drives), which is purely a sequential write. The external USB HDD (UFS2) is a completely different device, and is doing purely sequential read. There is only one "cp" process doing anything at all. The FreeBSD system files aren't on either of these devices, either not that it's doing anything with the disk during this time. --rich From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 21:45:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68804106566C for ; Sun, 11 Jul 2010 21:45:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 15A0A8FC20 for ; Sun, 11 Jul 2010 21:45:48 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id gl4p1e00A0vyq2s58llpuJ; Sun, 11 Jul 2010 21:45:49 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta05.westchester.pa.mail.comcast.net with comcast id glln1e00E3LrwQ23Rllois; Sun, 11 Jul 2010 21:45:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9F7459B425; Sun, 11 Jul 2010 14:45:46 -0700 (PDT) Date: Sun, 11 Jul 2010 14:45:46 -0700 From: Jeremy Chadwick To: Richard Lee Message-ID: <20100711214546.GA81873@icarus.home.lan> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> <20100711211213.GA36377@catsspat.iriomote> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100711211213.GA36377@catsspat.iriomote> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 21:45:49 -0000 On Sun, Jul 11, 2010 at 02:12:13PM -0700, Richard Lee wrote: > On Sun, Jul 11, 2010 at 01:47:57PM -0700, Jeremy Chadwick wrote: > > On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: > > > This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. > > > > > > The closest I found by Googling was this: > > > http://forums.freebsd.org/showthread.php?t=9935 > > > > > > And it talks about all kinds of little tweaks, but in the end, the > > > only thing that actually works is the stupid 1-line perl code that > > > forces the kernal to free the memory allocated to (non-zfs) disk > > > cache, which is the "Inact"ive memory in "top." > > > > > > I have a 4-disk raidz pool, but that's unlikely to matter. > > > > > > Try to copy large files from non-zfs disk to zfs disk. FreeBSD will > > > cache the data read from non-zfs disk in memory, and free memory will > > > go down. This is as expected, obviously. > > > > > > Once there's very little free memory, one would expect whatever is > > > more important to kick out the cached data (Inact) and make memory > > > available. > > > > > > But when almost all of the memory is taken by disk cache (of non-zfs > > > file system), ZFS disks start threshing like mad and the write > > > throughput goes down in 1-digit MB/second. > > > > > > I believe it should be extremely easy to duplicate. Just plug in a > > > big USB drive formatted in UFS (msdosfs will likely do the same), and > > > copy large files from that USB drive to zfs pool. > > > > > > Right after clean boot, gstat will show something like 20+MB/s > > > movement from USB device (da*), and occasional bursts of activity on > > > zpool devices at very high rate. Once free memory is exhausted, zpool > > > devices will change to constant low-speed activity, with disks > > > threshing about constantly. > > > > > > I tried enabling/disabling prefetch, messing with vnode counts, > > > zfs.vdev.min/max_pending, etc. The only thing that works is that > > > stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the > > > activity to that seen right after a clean boot. It doesn't last very > > > long, though, as the disk cache again consumes all the memory. > > > > > > Copying files between zfs devices doesn't seem to affect anything. > > > > > > I understand zfs subsystem has its own memory/cache management. > > > Can a zfs expert please comment on this? > > > > > > And is there a way to force the kernel to not cache non-zfs disk data? > > > > I believe you may be describing two separate issues: > > > > 1) ZFS using a lot of memory but not freeing it as you expect > > 2) Lack of disk I/O scheduler > > > > For (1), try this in /boot/loader.conf and reboot: > > > > # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA > > # on 2010/05/24. > > # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html > > vfs.zfs.zio.use_uma="0" > > > > For (2), may try gsched_rr: > > > > http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup > > > > -- > > | Jeremy Chadwick jdc@parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never > touched it. Okay, just checking, because the default did change at one point, as the link in my /boot/loader.conf denotes. Here's further confirmation (same thread), the first confirming on i386, the second confirming on amd64: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057168.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057239.html > And in my case, Wired memory is stable at around 1GB. It's > the Inact memory that takes off, but only if reading from non-zfs file > system. Without other file systems, I can keep moving files around and > see no adverse slowdown. I can also scp huge files from another system > into the zfs machine, and it doesn't affect memory usage (as reported by > top), nor does it affect performance. Let me get this straight: The system has ZFS enabled (kernel module loaded), with a 4-disk raidz1 pool defined and used in the past (Wired being @ 1GB, due to ARC). The same system also has UFS2 filesystems. The ZFS pool vdevs consist of their own dedicated disks, and the UFS2 filesystems also have their own disk (which appears to be USB-based). When any sort of read I/O is done on the UFS2 filesystems, Inact skyrockets, and as a result this impacts performance of ZFS. If this is correct: can you remove USB from the picture and confirm the problem still happens? This is the first I've heard of the UFS caching mechanism "spiraling out of control". By the way, all the "stupid perl 1-liner" does is make a process with an extremely large SIZE, and RES will grow to match it (more or less). The intention is to cause the VM to force a swap-out + free of memory by stressing the VM. Using 'x1500000000', you'll find something like this: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 82353 jdc 1 76 0 1443M 1068M STOP 1 0:01 10.69% perl5.10.1 With use of 'x9999999999', you'll see something like this (note SIZE): PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 82535 jdc 1 56 0 9549M 881M STOP 1 0:01 7.28% perl5.10.1 (I'm quite aware of what this does in perl, just noting that for posterity). Be aware this can impact all processes on the machine, specifically idle processes will be swapped out resulting in loss of convenient things such as display of the fully-qualified path to the program and their environment (e.g. ARGV arguments). You'll see them as "" (note the brackets), I believe. > As for gsched_rr, I don't believe this is related. There is only ONE > access to the zfs devices (4 sata drives), which is purely a sequential > write. You're correct, my apologies. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 11 22:28:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5946C106566C for ; Sun, 11 Jul 2010 22:28:20 +0000 (UTC) (envelope-from nukunuku@sbcglobal.net) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by mx1.freebsd.org (Postfix) with SMTP id 361F18FC19 for ; Sun, 11 Jul 2010 22:28:19 +0000 (UTC) Received: (qmail 55941 invoked from network); 11 Jul 2010 22:28:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Received:Date:To:Cc:Subject:Message-ID:References:Mime-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:From; b=5IJ5Ftsdw8BV8fEHxqe6EtNGqnlA1GxdYMKgU+dUTAY5zxn4oKbEersis234c7O0dNxKi9VRI4ASiYS+YNBWzG2JozYuU0yNFvrWCDEjrNlMNvVhVhHD7PHXx8nQs3KS+RWT0y0rgrTlRznZbjMBzm/Su3Yoa3gkdIldHswYMPE= ; Received: from adsl-75-55-221-181.dsl.pltn13.sbcglobal.net (nukunuku@75.55.221.181 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 11 Jul 2010 15:28:19 -0700 PDT X-Yahoo-SMTP: xGthgDWswBCB1BOngQs2nXHlo9uxxXfMF1J0xzNHmECJ9rs- X-YMail-OSG: DKxo5D4VM1kY5Xl_yB78ML2LeZD4bKTTXVdV4wh46FoYOcARp7f4btmweyaToqxAj9DShhvULSQAwTN9xEEvGdJcJXn7Jpg.YYaMbnWNkocUokX5TbznFLve3p11wltLHuoPOSTzaCFESbhMbVrRNbhBA2Z9_E3AJtb5IWuJMRb52fbOJYNCGwyeAhgeqyyqvtBFGIsD27iapqGlQiWm0_Uz6urLWVUoED6uEcWmQd9HThWy2_JOtjPryHn7buHGr5V8oiHjxHGMA2aZ2YE4akp.0YkMaQbVCUx4 X-Yahoo-Newman-Property: ymail-3 Received: by catsspat.iriomote (Postfix, from userid 1001) id 9C7012F; Sun, 11 Jul 2010 15:28:18 -0700 (PDT) Date: Sun, 11 Jul 2010 15:28:18 -0700 To: Jeremy Chadwick Message-ID: <20100711222818.GA37207@catsspat.iriomote> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> <20100711211213.GA36377@catsspat.iriomote> <20100711214546.GA81873@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100711214546.GA81873@icarus.home.lan> User-Agent: Mutt/1.4.2.2i From: nukunuku@sbcglobal.net (Richard Lee) Cc: freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jul 2010 22:28:20 -0000 On Sun, Jul 11, 2010 at 02:45:46PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 11, 2010 at 02:12:13PM -0700, Richard Lee wrote: > > On Sun, Jul 11, 2010 at 01:47:57PM -0700, Jeremy Chadwick wrote: > > > On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: > > > > This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. > > > > > > > > The closest I found by Googling was this: > > > > http://forums.freebsd.org/showthread.php?t=9935 > > > > > > > > And it talks about all kinds of little tweaks, but in the end, the > > > > only thing that actually works is the stupid 1-line perl code that > > > > forces the kernal to free the memory allocated to (non-zfs) disk > > > > cache, which is the "Inact"ive memory in "top." > > > > > > > > I have a 4-disk raidz pool, but that's unlikely to matter. > > > > > > > > Try to copy large files from non-zfs disk to zfs disk. FreeBSD will > > > > cache the data read from non-zfs disk in memory, and free memory will > > > > go down. This is as expected, obviously. > > > > > > > > Once there's very little free memory, one would expect whatever is > > > > more important to kick out the cached data (Inact) and make memory > > > > available. > > > > > > > > But when almost all of the memory is taken by disk cache (of non-zfs > > > > file system), ZFS disks start threshing like mad and the write > > > > throughput goes down in 1-digit MB/second. > > > > > > > > I believe it should be extremely easy to duplicate. Just plug in a > > > > big USB drive formatted in UFS (msdosfs will likely do the same), and > > > > copy large files from that USB drive to zfs pool. > > > > > > > > Right after clean boot, gstat will show something like 20+MB/s > > > > movement from USB device (da*), and occasional bursts of activity on > > > > zpool devices at very high rate. Once free memory is exhausted, zpool > > > > devices will change to constant low-speed activity, with disks > > > > threshing about constantly. > > > > > > > > I tried enabling/disabling prefetch, messing with vnode counts, > > > > zfs.vdev.min/max_pending, etc. The only thing that works is that > > > > stupid perl 1-liner (perl -e '$x="x"x1500000000'), which returns the > > > > activity to that seen right after a clean boot. It doesn't last very > > > > long, though, as the disk cache again consumes all the memory. > > > > > > > > Copying files between zfs devices doesn't seem to affect anything. > > > > > > > > I understand zfs subsystem has its own memory/cache management. > > > > Can a zfs expert please comment on this? > > > > > > > > And is there a way to force the kernel to not cache non-zfs disk data? > > > > > > I believe you may be describing two separate issues: > > > > > > 1) ZFS using a lot of memory but not freeing it as you expect > > > 2) Lack of disk I/O scheduler > > > > > > For (1), try this in /boot/loader.conf and reboot: > > > > > > # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA > > > # on 2010/05/24. > > > # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html > > > vfs.zfs.zio.use_uma="0" > > > > > > For (2), may try gsched_rr: > > > > > > http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup > > > > > > -- > > > | Jeremy Chadwick jdc@parodius.com | > > > | Parodius Networking http://www.parodius.com/ | > > > | UNIX Systems Administrator Mountain View, CA, USA | > > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never > > touched it. > > Okay, just checking, because the default did change at one point, as the > link in my /boot/loader.conf denotes. Here's further confirmation (same > thread), the first confirming on i386, the second confirming on amd64: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057168.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057239.html > > > And in my case, Wired memory is stable at around 1GB. It's > > the Inact memory that takes off, but only if reading from non-zfs file > > system. Without other file systems, I can keep moving files around and > > see no adverse slowdown. I can also scp huge files from another system > > into the zfs machine, and it doesn't affect memory usage (as reported by > > top), nor does it affect performance. > > Let me get this straight: > > The system has ZFS enabled (kernel module loaded), with a 4-disk raidz1 > pool defined and used in the past (Wired being @ 1GB, due to ARC). The > same system also has UFS2 filesystems. The ZFS pool vdevs consist of > their own dedicated disks, and the UFS2 filesystems also have their own > disk (which appears to be USB-based). Yes, correct. I have: ad4 (An old 200GB SATA UFS2 main system drive) ad8, ad10, ad12, ad14 (1TB SATA drives) part of raidz1 and nothing else da0 is an external USB disk (1TB), but I don't think it's related to USB. Status looks like this: state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM uchuu ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 errors: No known data errors > When any sort of read I/O is done on the UFS2 filesystems, Inact > skyrockets, and as a result this impacts performance of ZFS. > > If this is correct: can you remove USB from the picture and confirm the > problem still happens? This is the first I've heard of the UFS caching > mechanism "spiraling out of control". To isolate away USB involvement, I did the following. Without any USB drive attached at all, I copied a large 7GB file from zfs pool to the system drive (internal ad4 UFS2). This alone caused the Inact memory to top out since it's caching whatever is to/from normal file system. Despite Inact memory usage topping out, I didn't notice any slow down in copying *from* zfs to UFS drive (ad4), but I'm not 100% sure. It certainly wasn't obvious if there were any effect. Maybe zfs reads aren't as badly affected. Now, I copied that large file from ad4 back to zpool (somewhere else from where the original file was, of course), and this *was* noticeably affected. It started out similarly (ad4 reading near its max platter speed 40-50MB/s), and zfs pool doing burst writes that are of higher bandwidth. This didn't last very long, though, possibly because memory is already fully consumed (or close to it). It switched to the ad4 read slowing down to below 20MB/s, and zfs write becoming constant and slower, too, instead of quick bursty write behavior. Note I was watching it using gstat. It wasn't as slow as USB drive -> zfs, but that may just be due to USB overhead. While this was happening, I ran that perl code to force the kernel to give up some memory, and it went back to speedy behavior, again until the UFS caching took all the memory. It's as if the kernel doesn't know to throw away Inact memory stuff based on its own internal activity (zfs activity), even though a user processing asking for memory makes it throw them out in an instant. But that's not a qualified statement, of course. Just thinking out loud. --rich From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 03:08:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75DD11065676 for ; Mon, 12 Jul 2010 03:08:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B6B18FC13 for ; Mon, 12 Jul 2010 03:08:55 +0000 (UTC) Received: by iwn35 with SMTP id 35so5214581iwn.13 for ; Sun, 11 Jul 2010 20:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gWpcMzoXu6+YFhINnvuEyLve/+6OFt6VPgtDN03/XRs=; b=B3zCt8v0HZ5yH7P0zbWtXD9sgl3XipkYsxw3OfFHiEwYErsu/hnqhjdE33NUTELGSF eqGmNq9ofR9DJxOwipxeCE1yjMKY26IspKVgcBlsRgg1V8R/5FNipm77bs7Qu/fBNwax Nv4QPzMOyrWHCULRRy6F66AdcSt9ONfl2dSUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X0QaiclDveotwz8vWuFjg3d694sYxGIBPzfPZvHuCe1zsvLIOI0G92LVE6GvTz4Vh6 L2UaPyIULvnGvXMg9I/sRDidwTofC0N3WUJBPm8AaR7S/JMFPGEws/YV3aj+r9E65lAF GHKs/RE2akOvGi1acE/VpEaZnGfEw02N+T11s= MIME-Version: 1.0 Received: by 10.231.12.76 with SMTP id w12mr12945845ibw.87.1278904134068; Sun, 11 Jul 2010 20:08:54 -0700 (PDT) Received: by 10.231.37.11 with HTTP; Sun, 11 Jul 2010 20:08:54 -0700 (PDT) In-Reply-To: <20100711222818.GA37207@catsspat.iriomote> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> <20100711211213.GA36377@catsspat.iriomote> <20100711214546.GA81873@icarus.home.lan> <20100711222818.GA37207@catsspat.iriomote> Date: Sun, 11 Jul 2010 20:08:54 -0700 Message-ID: From: Freddie Cash To: Richard Lee Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 03:08:55 -0000 Search the archives for the -stable, -current, and -fs mailing lists from the past 3 months. There are patches floating around to fix this. The ZFS code that monitors memory pressure currently only monitors the "free" amount, and completely ignores the "inact" and other "not actually in use" amounts. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 03:19:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2501106564A for ; Mon, 12 Jul 2010 03:19:58 +0000 (UTC) (envelope-from A.J.Caines@halplant.com) Received: from triton.bsd-unix.net (triton.bsd-unix.net [209.8.43.226]) by mx1.freebsd.org (Postfix) with ESMTP id C65598FC0C for ; Mon, 12 Jul 2010 03:19:58 +0000 (UTC) Received: from triton.bsd-unix.net (localhost [127.0.0.1]) by triton.bsd-unix.net (Postfix) with ESMTP id E4C119B434 for ; Sun, 11 Jul 2010 23:19:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at bsd-unix.net Received: from triton.bsd-unix.net ([127.0.0.1]) by triton.bsd-unix.net (triton.bsd-unix.net.bsd-unix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 84FYl39eOGyS for ; Sun, 11 Jul 2010 23:19:57 -0400 (EDT) Received: from hal10000.halplant.com (ip68-105-188-179.dc.dc.cox.net [68.105.188.179]) (Authenticated sender: ajc) by triton.bsd-unix.net (Postfix) with ESMTPSA id B69C69B425 for ; Sun, 11 Jul 2010 23:19:57 -0400 (EDT) Message-ID: <4C3A8A2A.3030609@halplant.com> Date: Sun, 11 Jul 2010 23:21:14 -0400 From: "Andrew J. Caines" Organization: H.A.L. Plant User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100706 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: More buzzing fun with snd_emu10kx - but now with more determinism! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 03:19:59 -0000 On 07/11/2010 17:03, Garrett Cooper wrote: > The problem appears to be with vchan-related code. If I start up 4+ > applications on my machine that access the audio device, all goes > wonky on the 4+ allocation I can confirm this behaviour, which seems odd with hw.snd.maxautovchans defaulting to 16. It does not appear to be affected by increasing dev.pcm.0.play.vchans up fron the default of 2 (as I apparently did at some point up to 7.x), though reading sound(4) it's clear I don't fully understand vchans. A problem I encountered with snd_emu10kx in a clean 8.1RC2 install which was not present in any previous version is a faint rapid mechanical clicking sound adjustable with the "cd" mixer setting. The only non-default audio setting I have is in loader.conf: hint.emu10kx.0.multichannel_disabled="1" hint.emu10kx.1.disabled="1" pcm0: on emu10kx0 pcm0: pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: on emu10kx0 (4p:2v/1r:1v) default snddev flags=0x2e2 [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000004 interrupts 726, underruns 0, feed 5, ready 0 [b:4096/2048/2|bs:4096/2048/2] channel flags=0x2100 ... -- -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 06:02:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5821065675 for ; Mon, 12 Jul 2010 06:02:53 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76A6A8FC1F for ; Mon, 12 Jul 2010 06:02:53 +0000 (UTC) Received: by iwn35 with SMTP id 35so5355088iwn.13 for ; Sun, 11 Jul 2010 23:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=nh6ex/2xZqdbLEcVBrmploOSeIBPLOwM4T+xgYN8Sms=; b=ZdLei6VQv4xxIPPPzaKQ9m64viFsIAtET5jMRSfNfzZ39074GqVbUa/4aZzQ0w+8ko rDPKKMcK7AjcdXd2kj58xNZ8/F+HOpGfGPLnyIPHd4OO3YfNVe0rc/R5lNlkKT/rZ9X0 BvXYhNJ2zkq2966pGvnSIKsBM1bz2qwPhM0g8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=THYWWPWiwDmVaTsLNVYPbyGQgJup+mLAGXpRz119I21qQP/j6MvrMUjq3PGDgg9J1n 0IbAKViPJpO/EybCSa7sUFBlOXnxUsMjZn/Erl5UGFvakT3WsgxqNdVFqj2bzkoebuk9 dK19X4Yg3D5uk7MyDUlRYrfMAt5XBPQqSoLS4= Received: by 10.231.185.142 with SMTP id co14mr14025485ibb.97.1278914572298; Sun, 11 Jul 2010 23:02:52 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id h8sm18047533ibk.15.2010.07.11.23.02.50 (version=SSLv3 cipher=RC4-MD5); Sun, 11 Jul 2010 23:02:51 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C3AB00C.9070905@dataix.net> Date: Mon, 12 Jul 2010 02:02:52 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Freddie Cash References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> <20100711211213.GA36377@catsspat.iriomote> <20100711214546.GA81873@icarus.home.lan> <20100711222818.GA37207@catsspat.iriomote> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 06:02:53 -0000 On 07/11/2010 23:08, Freddie Cash wrote: > Search the archives for the -stable, -current, and -fs mailing lists > from the past 3 months. There are patches floating around to fix > this. The ZFS code that monitors memory pressure currently only > monitors the "free" amount, and completely ignores the "inact" and > other "not actually in use" amounts. > AFAIR, any of the patches that were around were either incomplete or inconsistent & were good attempts to solve the problem but turned out in the end to not effect the problem in a positive or negative way. I may be wrong as it seems the problem has a few variables that determine its effect in different cases, usage, hardware mixture & implementation. If there is one thing that I have been seeing more of was the perl hack that gets every process on your system to swap-out to free RAM for use by ZFS or whatever its intention. perl -e '$x = "x" x 1000000;' It might be a good thing to mention this on the ZFS tuning section of the wiki for reference. Regards & Good Luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 06:43:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174B31065672 for ; Mon, 12 Jul 2010 06:43:56 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2E18FC14 for ; Mon, 12 Jul 2010 06:43:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOpUOkyWZZrw/2dsb2JhbACgNnGrZoZtLohYhScE Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Jul 2010 16:13:54 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 0AB165C97; Mon, 12 Jul 2010 16:43:53 +1000 (EST) Date: Mon, 12 Jul 2010 16:43:53 +1000 From: Emil Mikulic To: Jeremy Chadwick Message-ID: <20100712064352.GC50043@dmr.ath.cx> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100711204757.GA81084@icarus.home.lan> <20100711211213.GA36377@catsspat.iriomote> <20100711214546.GA81873@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100711214546.GA81873@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 06:43:56 -0000 On Sun, Jul 11, 2010 at 02:45:46PM -0700, Jeremy Chadwick wrote: > On Sun, Jul 11, 2010 at 02:12:13PM -0700, Richard Lee wrote: > > vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never > > touched it. > > Okay, just checking, because the default did change at one point And changed back (to zero) in rev 209261: http://article.gmane.org/gmane.os.freebsd.devel.cvs/395961 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 09:38:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B04106566C for ; Mon, 12 Jul 2010 09:38:26 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id B41A38FC21 for ; Mon, 12 Jul 2010 09:38:25 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6C9cKco027947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 19:38:21 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6C9cIjb027946; Mon, 12 Jul 2010 19:38:18 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6C9cISh027945; Mon, 12 Jul 2010 19:38:18 +1000 (EST) (envelope-from peter) Date: Mon, 12 Jul 2010 19:38:18 +1000 From: Peter Jeremy To: Richard Lee Message-ID: <20100712093818.GA27693@server.vk2pj.dyndns.org> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 09:38:26 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-11 11:25:12 -0700, Richard Lee wrote: >But when almost all of the memory is taken by disk cache (of non-zfs >file system), ZFS disks start threshing like mad and the write >throughput goes down in 1-digit MB/second. It can go a lot lower than that... Yes, this is a known problem. The underlying problem is a disconnect between the ZFS cache (ARC) and the VM cache used by everything else, preventing ZFS reclaiming RAM from the VM cache. For several months, I was running a regular cron job that was a slightly fancier version of the perl one-liner. I have been using the attached arc.patch1 based on a patch written by Artem Belevich (see http://pastebin.com/ZCkzkWcs ) for about a month. I have had reasonable success with it (and junked my cronjob) but have managed to wedge my system a couple of times whilst doing zfs send|recv. Whilst looking at that diff, I just noticed a nasty signed/unsigned bug that could bite in low memory conditions and have revised it to arc.patch2 (untested as yet). Independently, Martin Matuska committed r209227 that corrects a number of ARC bugs reported on OpenSolaris. Whilst this patch doesn't add checks on "inactive" or "cache", some quick checks suggest it also helps (though I need to do further checks). See http://people.freebsd.org/~mm/patches/zfs/head-12636.patch --=20 Peter Jeremy --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw64okACgkQ/opHv/APuIcWowCgiBc5ro8DGQfGRq4aafxxeUuu 6uUAn0IoSIvaaEfKUDncom1IrQ5NUakn =V4R+ -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 09:39:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F13FB106566C for ; Mon, 12 Jul 2010 09:39:41 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9308FC24 for ; Mon, 12 Jul 2010 09:39:41 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o6C9db9q032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 19:39:38 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o6C9dYRl027963; Mon, 12 Jul 2010 19:39:34 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o6C9dXlr027962; Mon, 12 Jul 2010 19:39:33 +1000 (EST) (envelope-from peter) Date: Mon, 12 Jul 2010 19:39:33 +1000 From: Peter Jeremy To: Richard Lee Message-ID: <20100712093933.GA27950@server.vk2pj.dyndns.org> References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100712093818.GA27693@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <20100712093818.GA27693@server.vk2pj.dyndns.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 09:39:42 -0000 --mojUlQ0s9EVzWg2t Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-12 19:38:18 +1000, Peter Jeremy = wrote: >I have been using the attached arc.patch1 based on a patch written by >Artem Belevich (see http://pastebin.com/ZCkzkWcs ) >for about a month. I have had reasonable success with it (and junked >my cronjob) but have managed to wedge my system a couple of times >whilst doing zfs send|recv. Whilst looking at that diff, I just >noticed a nasty signed/unsigned bug that could bite in low memory >conditions and have revised it to arc.patch2 (untested as yet). Let try actually attaching those patches... Sorry. --=20 Peter Jeremy --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arc.patch1" Content-Transfer-Encoding: quoted-printable Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/ncvs/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.= c,v retrieving revision 1.22.2.6 diff -u -r1.22.2.6 arc.c --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 24 May 2010 20:09:= 40 -0000 1.22.2.6 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 12 Jun 2010 21:04:= 13 -0000 @@ -183,10 +183,15 @@ int zfs_arc_shrink_shift =3D 0; int zfs_arc_p_min_shift =3D 0; =20 +uint64_t zfs_arc_bp_active; +uint64_t zfs_arc_bp_inactive; + TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max); TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min); TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit); TUNABLE_INT("vfs.zfs.mdcomp_disable", &zfs_mdcomp_disable); +TUNABLE_QUAD("vfs.zfs.arc_bp_active", &zfs_arc_bp_active); +TUNABLE_QUAD("vfs.zfs.arc_bp_inactive", &zfs_arc_bp_inactive); SYSCTL_DECL(_vfs_zfs); SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_max, CTLFLAG_RDTUN, &zfs_arc_max, 0, "Maximum ARC size"); @@ -195,6 +200,11 @@ SYSCTL_INT(_vfs_zfs, OID_AUTO, mdcomp_disable, CTLFLAG_RDTUN, &zfs_mdcomp_disable, 0, "Disable metadata compression"); =20 +SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_active, CTLFLAG_RW|CTLFLAG_TUN, &zf= s_arc_bp_active, 0, + "Start ARC backpressure if active memory is below this limit"); +SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_inactive, CTLFLAG_RW|CTLFLAG_TUN, &= zfs_arc_bp_inactive, 0, + "Start ARC backpressure if inactive memory is below this limit"); + /* * Note that buffers can be in one of 6 states: * ARC_anon - anonymous (discussed below) @@ -2103,7 +2113,6 @@ } =20 static int needfree =3D 0; - static int arc_reclaim_needed(void) { @@ -2112,20 +2121,58 @@ #endif =20 #ifdef _KERNEL - if (needfree) - return (1); + /* We've grown too much, */ if (arc_size > arc_c_max) return (1); + + /* Pagedaemon is stuck, let's free something right away */ + if (vm_pageout_pages_needed) + return 1; + + /* Check if inactive list have grown too much */ + if ( zfs_arc_bp_inactive + && (ptoa((uintmax_t)cnt.v_inactive_count) > zfs_arc_bp_inactive)) { + /* tell pager to reap 1/2th of inactive queue*/ + atomic_add_int(&vm_pageout_deficit, cnt.v_inactive_count/2); + pagedaemon_wakeup(); + return needfree; + } + + /* Same for active list... */ + if ( zfs_arc_bp_active + && (ptoa((uintmax_t)cnt.v_active_count) > zfs_arc_bp_active)) { + atomic_add_int(&vm_pageout_deficit, cnt.v_active_count/2); + pagedaemon_wakeup(); + return needfree; + } + +=09 + /* Old style behavior -- ARC gives up memory whenever page daemon asks.. = */ + if (needfree) + return 1; + + /* + We got here either because active/inactive lists are + getting short or because we've been called during voluntary + ARC size checks. Kind of gray area... + */ + + /* If we didn't reach our minimum yet, don't rush to give memory up..*/ if (arc_size <=3D arc_c_min) return (0); =20 + /* If we're really short on memory now, give it up. */ + if (vm_page_count_min()) { + return (1); + } +=09 /* - * If pages are needed or we're within 2048 pages - * of needing to page need to reclaim + * If we're within 2048 pages of pagedaemon start, reclaim... */ - if (vm_pages_needed || (vm_paging_target() > -2048)) + if (vm_pages_needed && (vm_paging_target() > -2048)) return (1); =20 + #if 0 /* * take 'desfree' extra pages, so we reclaim sooner, rather than later @@ -2169,8 +2216,6 @@ return (1); #endif #else - if (kmem_used() > (kmem_size() * 3) / 4) - return (1); #endif =20 #else @@ -2279,7 +2324,7 @@ if (arc_eviction_list !=3D NULL) arc_do_user_evicts(); =20 - if (arc_reclaim_needed()) { + if (needfree) { needfree =3D 0; #ifdef _KERNEL wakeup(&needfree); @@ -3611,10 +3656,15 @@ { #ifdef _KERNEL uint64_t inflight_data =3D arc_anon->arcs_size; - uint64_t available_memory =3D ptoa((uintmax_t)cnt.v_free_count); + uint64_t available_memory; static uint64_t page_load =3D 0; static uint64_t last_txg =3D 0; =20 + /* How much memory is potentially available */ + available_memory =3D ptoa((uintmax_t)cnt.v_free_count); + available_memory +=3D ptoa((uintmax_t)cnt.v_cache_count); + available_memory -=3D ptoa((uintmax_t)cnt.v_free_min); + =20 #if 0 #if defined(__i386) available_memory =3D --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arc.patch2" Content-Transfer-Encoding: quoted-printable Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/ncvs/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.= c,v retrieving revision 1.22.2.6 diff -u -r1.22.2.6 arc.c --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 24 May 2010 20:09:= 40 -0000 1.22.2.6 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 12 Jul 2010 09:21:= 31 -0000 @@ -183,10 +183,15 @@ int zfs_arc_shrink_shift =3D 0; int zfs_arc_p_min_shift =3D 0; =20 +uint64_t zfs_arc_bp_active; +uint64_t zfs_arc_bp_inactive; + TUNABLE_QUAD("vfs.zfs.arc_max", &zfs_arc_max); TUNABLE_QUAD("vfs.zfs.arc_min", &zfs_arc_min); TUNABLE_QUAD("vfs.zfs.arc_meta_limit", &zfs_arc_meta_limit); TUNABLE_INT("vfs.zfs.mdcomp_disable", &zfs_mdcomp_disable); +TUNABLE_QUAD("vfs.zfs.arc_bp_active", &zfs_arc_bp_active); +TUNABLE_QUAD("vfs.zfs.arc_bp_inactive", &zfs_arc_bp_inactive); SYSCTL_DECL(_vfs_zfs); SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_max, CTLFLAG_RDTUN, &zfs_arc_max, 0, "Maximum ARC size"); @@ -195,6 +200,11 @@ SYSCTL_INT(_vfs_zfs, OID_AUTO, mdcomp_disable, CTLFLAG_RDTUN, &zfs_mdcomp_disable, 0, "Disable metadata compression"); =20 +SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_active, CTLFLAG_RW|CTLFLAG_TUN, &zf= s_arc_bp_active, 0, + "Start ARC backpressure if active memory is below this limit"); +SYSCTL_QUAD(_vfs_zfs, OID_AUTO, arc_bp_inactive, CTLFLAG_RW|CTLFLAG_TUN, &= zfs_arc_bp_inactive, 0, + "Start ARC backpressure if inactive memory is below this limit"); + /* * Note that buffers can be in one of 6 states: * ARC_anon - anonymous (discussed below) @@ -2103,7 +2113,6 @@ } =20 static int needfree =3D 0; - static int arc_reclaim_needed(void) { @@ -2112,20 +2121,58 @@ #endif =20 #ifdef _KERNEL - if (needfree) - return (1); + /* We've grown too much, */ if (arc_size > arc_c_max) return (1); + + /* Pagedaemon is stuck, let's free something right away */ + if (vm_pageout_pages_needed) + return 1; + + /* Check if inactive list have grown too much */ + if ( zfs_arc_bp_inactive + && (ptoa((uintmax_t)cnt.v_inactive_count) > zfs_arc_bp_inactive)) { + /* tell pager to reap 1/2th of inactive queue*/ + atomic_add_int(&vm_pageout_deficit, cnt.v_inactive_count/2); + pagedaemon_wakeup(); + return needfree; + } + + /* Same for active list... */ + if ( zfs_arc_bp_active + && (ptoa((uintmax_t)cnt.v_active_count) > zfs_arc_bp_active)) { + atomic_add_int(&vm_pageout_deficit, cnt.v_active_count/2); + pagedaemon_wakeup(); + return needfree; + } + +=09 + /* Old style behavior -- ARC gives up memory whenever page daemon asks.. = */ + if (needfree) + return 1; + + /* + We got here either because active/inactive lists are + getting short or because we've been called during voluntary + ARC size checks. Kind of gray area... + */ + + /* If we didn't reach our minimum yet, don't rush to give memory up..*/ if (arc_size <=3D arc_c_min) return (0); =20 + /* If we're really short on memory now, give it up. */ + if (vm_page_count_min()) { + return (1); + } +=09 /* - * If pages are needed or we're within 2048 pages - * of needing to page need to reclaim + * If we're within 2048 pages of pagedaemon start, reclaim... */ - if (vm_pages_needed || (vm_paging_target() > -2048)) + if (vm_pages_needed && (vm_paging_target() > -2048)) return (1); =20 + #if 0 /* * take 'desfree' extra pages, so we reclaim sooner, rather than later @@ -2169,8 +2216,6 @@ return (1); #endif #else - if (kmem_used() > (kmem_size() * 3) / 4) - return (1); #endif =20 #else @@ -2279,7 +2324,7 @@ if (arc_eviction_list !=3D NULL) arc_do_user_evicts(); =20 - if (arc_reclaim_needed()) { + if (needfree) { needfree =3D 0; #ifdef _KERNEL wakeup(&needfree); @@ -3611,10 +3656,17 @@ { #ifdef _KERNEL uint64_t inflight_data =3D arc_anon->arcs_size; - uint64_t available_memory =3D ptoa((uintmax_t)cnt.v_free_count); + uint64_t available_memory; static uint64_t page_load =3D 0; static uint64_t last_txg =3D 0; =20 + /* How much memory is potentially available */ + available_memory =3D (uint64_t)cnt.v_free_count + cnt.v_cache_count; + if (available_memory > cnt.v_free_min) + available_memory =3D ptoa(available_memory - cnt.v_free_min); + else + available_memory =3D 0; + #if 0 #if defined(__i386) available_memory =3D --RnlQjJ0d97Da+TV1-- --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw64tUACgkQ/opHv/APuIdaZACfbuBNLVzG4Ktjw5uy5rmh1xrz PHIAmQFCVsVKV8DQg2BrlcwJulbXST89 =coqu -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 09:55:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1DC91065679 for ; Mon, 12 Jul 2010 09:55:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA80D8FC23 for ; Mon, 12 Jul 2010 09:55:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA16845; Mon, 12 Jul 2010 12:55:11 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OYFjC-000Gkv-Pq; Mon, 12 Jul 2010 12:55:10 +0300 Message-ID: <4C3AE67D.9050401@icyb.net.ua> Date: Mon, 12 Jul 2010 12:55:09 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Peter Jeremy References: <20100711182511.GA21063@soda.CSUA.Berkeley.EDU> <20100712093818.GA27693@server.vk2pj.dyndns.org> <20100712093933.GA27950@server.vk2pj.dyndns.org> In-Reply-To: <20100712093933.GA27950@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 09:55:19 -0000 on 12/07/2010 12:39 Peter Jeremy said the following: > /* > - * If pages are needed or we're within 2048 pages > - * of needing to page need to reclaim > + * If we're within 2048 pages of pagedaemon start, reclaim... > */ > - if (vm_pages_needed || (vm_paging_target() > -2048)) > + if (vm_pages_needed && (vm_paging_target() > -2048)) I am not sure that what comment says is actually what the code checks. For both pre-patch and post-patch versions. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 15:08:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE7BA1065673 for ; Thu, 8 Jul 2010 15:08:06 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 58D7B8FC12 for ; Thu, 8 Jul 2010 15:08:06 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o68F85V3009967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 11:08:05 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o68F84R1015866; Thu, 8 Jul 2010 11:08:05 -0400 Message-ID: <4C35E9D4.8080007@aldan.algebra.com> Date: Thu, 08 Jul 2010 11:08:04 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> In-Reply-To: <20100708135353.GA43460@icarus.home.lan> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 12 Jul 2010 11:33:56 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2010 15:08:06 -0000 08.07.2010 09:53, Jeremy Chadwick ÎÁÐÉÓÁ×(ÌÁ): > Then don't modify loader.conf. Instead, once the "Welcome to FreeBSD!" > portion of loader appears, press "6" to shell to the loader prompt > and type: > > set vfs.root.mountfrom="ufs:/dev/md0" > boot > Yes, that works... It just should not be necessary. Red Hat's "kickstart" does not require one to extract CD-images to fiddle with a couple of lines, and FreeBSD comes tantalizingly close to offer the same functionality. Just not quite :-( -mi From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 18:28:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEE1106566C for ; Thu, 8 Jul 2010 18:28:12 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0998FC1A for ; Thu, 8 Jul 2010 18:28:11 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o68IS98F018033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 14:28:10 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o68IS93Y018965; Thu, 8 Jul 2010 14:28:09 -0400 Message-ID: <4C3618B9.8010202@aldan.algebra.com> Date: Thu, 08 Jul 2010 14:28:09 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> In-Reply-To: <20100708164022.GA46433@icarus.home.lan> X-Mailman-Approved-At: Mon, 12 Jul 2010 11:34:17 +0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2010 18:28:12 -0000 08.07.2010 12:40, Jeremy Chadwick напиÑав(ла): >>> set vfs.root.mountfrom="ufs:/dev/md0" >>> > >boot >>> >> > Yes, that works... It just should not be necessary. >> > Okay, so let me get this straight. First the complaint was that you had > to modify loader.conf, which involved extracting the CD image, editing > the file, yadda yadda. Now that you've been shown you don't have to > edit loader.conf, the complaint is "it shouldn't be necessary".:-) > No, I initially complained, that I had to fiddle with loader's options at boot-time (item 8 -- instead of setting mountfrom, I set init to sysinstall -- don't recall the exact syntax). You then claimed, that you /can't reproduce/ my problem -- and referred me to your instructions (nice ones, BTW, even for those, who don't need serial-port install), where you explain, how to perform the install via netboot. I pointed out, that your recipe is not a valid counter-example, because -- instead of fiddling with loader's options at boot-time, you fiddle with the loader.conf (and have to extract the entire CD/DVD-image to do that one-line change). One way or the other, some -- very minor -- manual changes are required... It is, of course, an accepted fact, that installing (or upgrading) an OS would require fiddling, but this particular little aspect can be eliminated, I think... > The bottom line: the PXE booting framework in FreeBSD could be improved. > Even Randi would agree with this point, I think. I perfectly understand -- and am not complaining -- about substantial work not done in any particular area. It is the little things, that could've been done with negligible /marginal/ cost, that are my target. RedHat's "kickstart " can do an entire install based on pre-configured rules. Implementing something like that for FreeBSD would, probably, take quite a bit of effort. But being able to just boot straight into install from a CD (or CD-image) across the LAN doesn't seem very complicated, considering, how close we already are... Yes, it is important to me. No, I can not do it myself. I do, what I can in my area of expertise. If this area is not being improved for lack of time/resources, then fine... But I don't think, that's the case, for it seems to me, that the developers, who can do this little improvement, simply don't see a need for it. Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 22:10:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D41E41065673 for ; Thu, 8 Jul 2010 22:10:52 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 95B7A8FC15 for ; Thu, 8 Jul 2010 22:10:52 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o68MAnxC026399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 18:10:49 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o68MAmkG022124; Thu, 8 Jul 2010 18:10:48 -0400 Message-ID: <4C364CE8.6050104@aldan.algebra.com> Date: Thu, 08 Jul 2010 18:10:48 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Peter Jeremy References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> In-Reply-To: <20100708210611.GA34250@server.vk2pj.dyndns.org> X-Mailman-Approved-At: Mon, 12 Jul 2010 11:34:51 +0000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2010 22:10:52 -0000 08.07.2010 17:06, Peter Jeremy ÎÁÐÉÓÁ×(ÌÁ): > On 2010-Jul-07 14:22:22 -0400, "Mikhail T." wrote: > >> In no particular order: >> >> 1. A picture, that one of the systems was displaying at boot (and >> then used as a screen-saver), stopped showing properly. The >> colors are right, but the picture is distorted beyond recognition. >> The relevant part of loader.conf is: >> >> splash_pcx_load="YES" >> vesa_load="YES" >> bitmap_load="YES" >> bitmap_name="/boot/187426-9-quokka-dreaming.pcx" >> > It's a bit difficult to provide any useful input without some idea > of what the picture should and does look like. Can you please post > the actual bitmap as well as a picture of your screen showing the > problem. > I don't want to post it publicly for copyright reasons. I can e-mail it to you (or anyone else) directly, though. >> 3. Likewise, having "device ugen" breaks config(8) -- another >> undocumented incompatibility. >> > Can you please advise where it is documented that "device ugen" > is valid in a FreeBSD-8 config file? > It was a valid device for FreeBSD-7. The UPDATING-file enumerates a number of things, that need to be changed, when updating to 8, but the removal of "ugen" is not mentioned there. >> 5. One of the upgraded systems would repeatedly hang at boot, until I >> disabled the on-board firewire-device through the BIOS... It was >> not a problem under 7.x, although I don't know, whether the device >> actually worked. >> > I haven't seen this on any of my systems. Can you please provide > details of your motherboard, BIOS and the output from a verbose boot > up to the hang. Is there a BIOS update available and have you tried > installing it? > No BIOS updates :-( I can e-mail boot's output to you directly (please, confirm interest). It would be with the device disabled though, because the boot never completes, if it is enabled. >> 6. Despite the reported improvements in the USB area, my USB keyboard >> /still/ does not work during boot. It during POST and then after >> the booting is complete. But in single-user mode -- no... Had to >> fish-out the PS2 keyboard... >> > I have had similar problems on one of my USB-only desktops. In my > case, moving the keyboard to a different USB port solved the problem. > All I can suggest is to work your way through all the USB ports you > have available and see if they all behavee the same. > I'll try that next time I reboot this system. Thanks, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 22:16:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57D21106566C for ; Thu, 8 Jul 2010 22:16:47 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 032C08FC13 for ; Thu, 8 Jul 2010 22:16:46 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o68MGfj2027541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jul 2010 18:16:41 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o68MGekb023716; Thu, 8 Jul 2010 18:16:40 -0400 Message-ID: <4C364E48.4000202@aldan.algebra.com> Date: Thu, 08 Jul 2010 18:16:40 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Lucas Holt References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> <4C3644D1.6000407@foolishgames.com> In-Reply-To: <4C3644D1.6000407@foolishgames.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 12 Jul 2010 11:35:03 +0000 Cc: freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jul 2010 22:16:47 -0000 08.07.2010 17:36, Lucas Holt ÎÁÐÉÓÁ×(ÌÁ): > Most of us work on open source for free in our own time, and it's > impossible to test every possible configuration before a release. I tested several particular configurations -- on several machines -- and reported the overlooked issues. I didn't write a pamphlet, and I didn't post it to Slashdot as evidence of "BSD is dying" -- I reported it to the developers. No need to get defensive -- or call it "rant". Whoever is in a position to fix a particular problem, can now do that... -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:25:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A188106566C; Mon, 12 Jul 2010 12:25:56 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 435A98FC15; Mon, 12 Jul 2010 12:25:56 +0000 (UTC) Received: from [77.109.131.203] (port=60477 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYI54-0005Vs-UD; Mon, 12 Jul 2010 14:25:55 +0200 Mime-Version: 1.0 (Apple Message framework v1078) From: Markus Gebert In-Reply-To: Date: Mon, 12 Jul 2010 14:25:54 +0200 Message-Id: <591666AA-E6CA-4478-9E96-3A2D558BD6B4@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> To: alc@freebsd.org X-Mailer: Apple Mail (2.1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:25:56 -0000 On 10.07.2010, at 19:37, Alan Cox wrote: > On Fri, Jul 9, 2010 at 6:53 PM, Markus Gebert = wrote: > [snip] >=20 > Yes, this hardware comes from Sun directly, but getting Sun (/Oracle) = support for this issue is gonna be tough. FreeBSD is unsupported, and in = a short test we couldn't reproduce the problem with a Linux kernel. = While I agree that a hardware issue has always been and still is a = possibility to be considered, the fact that we tested this on two = machines remains as well as the fact that 6.x, 7.x do not show the = behavior. Another possibility is of course, that the X4100 is prone to = such issues and somehow 6.x and 7.x have workarounds we're not aware of = or just do something different in way so that this issue does not get = triggered. >=20 >=20 > 8.1 is our first release to have the driver for configuring and = reporting machine check exceptions enabled by default. Prior to 8.1, = you had to explicitly enable the driver at boot time. I was aware of that, but I don't think that it might be the cause. = Disabling MCA just makes the reporting go away, but the MCE and = subsequent fatal trap remain. With default BIOS settings, the OS does = not even get a chance to panic, the system just forces a reset before = the OS could do anything. And, as far as I can tell, that did not happen = on previous stable branches. Don't know though wether MCA changes the situation even when disabled in = loader.conf (hw.mca.enabled=3D0). I just checked our 7.2 setup, and MCA = does not seem to be in an 7.2 kernel, so I guess this was added to 8.0 = and activated by default in 8.1. To be honest, we did not check, wether = 8.0 shows the same behavior, but I guess running 8.1 with = hw.mca.enabled=3D0 should pretty much give the same situation as far as = MCA is concerned. Is there a way to get rid of MCA completely? (as opposed to just = "turning it off" via loader.conf) Markus From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:32:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD7D1065670 for ; Mon, 12 Jul 2010 12:32:20 +0000 (UTC) (envelope-from antinix@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 02AE78FC0C for ; Mon, 12 Jul 2010 12:32:19 +0000 (UTC) Received: by wwb31 with SMTP id 31so134628wwb.31 for ; Mon, 12 Jul 2010 05:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=THU/AYAjNlIRzl++nXD5FDF2zHsNpVljbyH7J/ynaYo=; b=wUxPLrBAuZ7N45BmPehits2/G/S0QrMvXpTvayZySd+83xrUqaLXNfh2qMIf/4TJ/J xdyh83wnDlZ2db67fAvNCGI96thSdPtNOmtxR0SYC+dmJkmwgHkr7DrBTiDfWFjDST9Y wU45vLgqpugj99GZcO4ifku/BLGz8njkXVKps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=mj6dJ0bSehT5nIRl+BcZRc6pWgVq/3ouly08L/Et3SPRiwJ0iTjdux25WCzGuTOwY6 jAqb3Wlw8ootUIJK28edFOGXP8sqZMnWNvSfX8TGZD0cjWMPRXsNIJaT03Kg8bkVqfwf nHMiyRmyIEvMNq2GUPQ8w/E181XB81QOIiI1g= Received: by 10.227.148.17 with SMTP id n17mr12590704wbv.19.1278937938265; Mon, 12 Jul 2010 05:32:18 -0700 (PDT) MIME-Version: 1.0 Sender: antinix@gmail.com Received: by 10.216.45.194 with HTTP; Mon, 12 Jul 2010 05:31:58 -0700 (PDT) From: Andrei Kolu Date: Mon, 12 Jul 2010 15:31:58 +0300 X-Google-Sender-Auth: zLpDo_Zcts_opKQzsOTEi2JXw0w Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: bogus DSCP value for ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:32:20 -0000 Hi! I am testing FreeBSD 8.1-RC2 amd64 networking stuff and notice one strange DSCP message with wireshark: ------------------------------------ Internet Protocol, Src: 192.168.1.111 (192.168.1.111), Dst: 192.168.1.101 (192.168.1.101) Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) 0001 00.. = Differentiated Services Codepoint: Unknown (0x04) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Transmission Control Protocol, Src Port: ssh (22), Dst Port: attachmate-s2s (2419), Seq: 2902917, Ack: 29842, Len: 132 ------------------------------------ There is no firewall enabled. Only thing I changed (should have no effect) was: "net.inet.tcp.ecn.enable: 1" From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:41:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8731106566B; Mon, 12 Jul 2010 12:41:53 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3438FC08; Mon, 12 Jul 2010 12:41:53 +0000 (UTC) Received: from [77.109.131.203] (port=60539 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYIKW-0006iZ-47; Mon, 12 Jul 2010 14:41:52 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> Date: Mon, 12 Jul 2010 14:41:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:41:53 -0000 On 10.07.2010, at 01:53, Markus Gebert wrote: >> I'm curious if disabling USB legacy support in the BIOS causes it to = still die=20 >> even with ehci not loaded. If so, then the SMI# for the ehci = controller must=20 >> somehow prevent the issue, perhaps by triggering frequently enough to = slow the=20 >> rate of I/O requests down? >=20 >=20 > I disabled usb legacy support in the BIOS and booted a kernel with = usb+ohci+ukbd+ums but without ehci. Unfortunately, I cannot reproduce = the MCE. Well, the situation has changed. Machine died over the weekend running = our test load with above kernel configuration. It seems that not having = ehci in the kernel at boot just makes the MCE much more unlikely to = occur, but it occurs. With ehci, I can panic the machine within a = minute, without ehci it seems to take at least hours. Still, I don't get = why not having the ehci driver in the kernel should have any effect, = especially because nothing is attached to it. Panic message: ---- MCA: Bank 4, Status 0xb400004000030c2b MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 MCA: CPU 2 UNCOR BUSLG Observer WR I/O MCA: Address 0xfd00000000 panic: blockable sleep lock (sleep mutex) 128 @ = /usr/src/sys/vm/uma_core.c:1992 cpuid =3D 2 KDB: enter: panic [thread pid 12 tid 100039 ] Stopped at kdb_enter+0x3d: movq $0,0x69ccb0(%rip) ---- Don't know, why it's not a fatal trap 28 this time despite an MCE was = detected. Seen this before though, also with kernels that have ehci and = with usb legacy support, so seeing a different panic this time seems not = related to the way the kernel was configured. Maybe a symptom? Or may it = even be useful? If yes, what should I pull out of DDB? In the meantime, I'll try harder to reproduce the MCE on current... Markus From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:51:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEF7F1065673 for ; Mon, 12 Jul 2010 12:51:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6AE8FC14 for ; Mon, 12 Jul 2010 12:51:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3EA3246B03; Mon, 12 Jul 2010 08:51:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 387158A04E; Mon, 12 Jul 2010 08:51:53 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 12 Jul 2010 08:40:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> In-Reply-To: <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007120840.30966.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 08:51:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Markus Gebert Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:51:54 -0000 On Friday, July 09, 2010 7:53:39 pm Markus Gebert wrote: > > I'm curious if disabling USB legacy support in the BIOS causes it to still die > > even with ehci not loaded. If so, then the SMI# for the ehci controller must > > somehow prevent the issue, perhaps by triggering frequently enough to slow the > > rate of I/O requests down? > > > I disabled usb legacy support in the BIOS and booted a kernel with usb+ohci+ukbd+ums but without ehci. Unfortunately, I cannot reproduce the MCE. Ok, that kills that theory then. > Just to get you right: your theory is that when we don't load the ehci driver, then the ehci-controller isn't taken over during boot and therefore handled through SMM so that SMIs might occur often enough to throttle the system just enough to not let the problem appear? I'm not very familiar with usb legacy support and SMM, but why would ehci be handled through SMM when the only usb devices (the virtual keyboard and mouse) actually sit on ohci? And why would disabling legacy support help getting more SMIs to throttle the system? As I unterstand this, and I might be terribly wrong, legacy support is what would cause SMIs in the first place. 1) Yes. 2) Many of the legacy USB emulations are very dumb and are polled rather than interrupt driven. Thus, if legacy USB support is enabled, then a timer kicks off an SMI# every so often (at least once a second on some machines, perhaps even more frequent) that polls the USB bus for any device attach/detach events. I think it might also poll attached keyboards that way as well. 3) I thought that disabling legacy USB but _not_ loading ehci would case it to break the same way that loading ehci causes it to break as it would turn off the SMI#'s that loading ehci also disables. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:51:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 153491065670; Mon, 12 Jul 2010 12:51:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D8CC28FC15; Mon, 12 Jul 2010 12:51:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8A18546B5B; Mon, 12 Jul 2010 08:51:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A087C8A04F; Mon, 12 Jul 2010 08:51:54 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Mon, 12 Jul 2010 08:48:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <591666AA-E6CA-4478-9E96-3A2D558BD6B4@hostpoint.ch> In-Reply-To: <591666AA-E6CA-4478-9E96-3A2D558BD6B4@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007120848.48162.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 08:51:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: alc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:51:56 -0000 On Monday, July 12, 2010 8:25:54 am Markus Gebert wrote: > > On 10.07.2010, at 19:37, Alan Cox wrote: > > > On Fri, Jul 9, 2010 at 6:53 PM, Markus Gebert wrote: > > [snip] > > > > Yes, this hardware comes from Sun directly, but getting Sun (/Oracle) support for this issue is gonna be tough. FreeBSD is unsupported, and in a short test we couldn't reproduce the problem with a Linux kernel. While I agree that a hardware issue has always been and still is a possibility to be considered, the fact that we tested this on two machines remains as well as the fact that 6.x, 7.x do not show the behavior. Another possibility is of course, that the X4100 is prone to such issues and somehow 6.x and 7.x have workarounds we're not aware of or just do something different in way so that this issue does not get triggered. > > > > > > 8.1 is our first release to have the driver for configuring and reporting machine check exceptions enabled by default. Prior to 8.1, you had to explicitly enable the driver at boot time. > > > I was aware of that, but I don't think that it might be the cause. Disabling MCA just makes the reporting go away, but the MCE and subsequent fatal trap remain. With default BIOS settings, the OS does not even get a chance to panic, the system just forces a reset before the OS could do anything. And, as far as I can tell, that did not happen on previous stable branches. Hmm with mca disabled in the loader you should not be getting any MCE's at all as we don't enable the MCE interrupt in the CPU in that case. Are you disabling it in the BIOS rather than loader.conf? > Don't know though wether MCA changes the situation even when disabled in loader.conf (hw.mca.enabled=0). I just checked our 7.2 setup, and MCA does not seem to be in an 7.2 kernel, so I guess this was added to 8.0 and activated by default in 8.1. To be honest, we did not check, wether 8.0 shows the same behavior, but I guess running 8.1 with hw.mca.enabled=0 should pretty much give the same situation as far as MCA is concerned. 7.3 has MCA support, but disabled by default. > Is there a way to get rid of MCA completely? (as opposed to just "turning it off" via loader.conf) Turning it off in loader.conf does get rid of it completely as it prevents us from initializing the MSRs. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 12:51:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31EF1106566C for ; Mon, 12 Jul 2010 12:51:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0193C8FC17 for ; Mon, 12 Jul 2010 12:51:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A81C246B17; Mon, 12 Jul 2010 08:51:56 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DAA068A050; Mon, 12 Jul 2010 08:51:55 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Mon, 12 Jul 2010 08:51:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007120851.35529.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 08:51:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 12:51:57 -0000 On Monday, July 12, 2010 8:41:51 am Markus Gebert wrote: > > On 10.07.2010, at 01:53, Markus Gebert wrote: > > >> I'm curious if disabling USB legacy support in the BIOS causes it to still die > >> even with ehci not loaded. If so, then the SMI# for the ehci controller must > >> somehow prevent the issue, perhaps by triggering frequently enough to slow the > >> rate of I/O requests down? > > > > > > I disabled usb legacy support in the BIOS and booted a kernel with usb+ohci+ukbd+ums but without ehci. Unfortunately, I cannot reproduce the MCE. > > > Well, the situation has changed. Machine died over the weekend running our test load with above kernel configuration. It seems that not having ehci in the kernel at boot just makes the MCE much more unlikely to occur, but it occurs. With ehci, I can panic the machine within a minute, without ehci it seems to take at least hours. Still, I don't get why not having the ehci driver in the kernel should have any effect, especially because nothing is attached to it. Ok, so maybe the SMI# interrupts do play a role somehow, at least as far as altering the timing. > Panic message: > > ---- > MCA: Bank 4, Status 0xb400004000030c2b > MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 > MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 > MCA: CPU 2 UNCOR BUSLG Observer WR I/O > MCA: Address 0xfd00000000 > panic: blockable sleep lock (sleep mutex) 128 @ /usr/src/sys/vm/uma_core.c:1992 > cpuid = 2 > KDB: enter: panic > [thread pid 12 tid 100039 ] > Stopped at kdb_enter+0x3d: movq $0,0x69ccb0(%rip) > ---- > > Don't know, why it's not a fatal trap 28 this time despite an MCE was detected. Seen this before though, also with kernels that have ehci and with usb legacy support, so seeing a different panic this time seems not related to the way the kernel was configured. Maybe a symptom? Or may it even be useful? If yes, what should I pull out of DDB? > > In the meantime, I'll try harder to reproduce the MCE on current... Well, it panic'd trying to malloc something in a non-safe place, because the machine check can happen at any time like an NMI. The panic was caused by the MCE however. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 13:57:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15201065677; Mon, 12 Jul 2010 13:57:32 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 638808FC19; Mon, 12 Jul 2010 13:57:32 +0000 (UTC) Received: from [77.109.131.203] (port=60716 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYJVh-000DBb-VD; Mon, 12 Jul 2010 15:57:29 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <201007120851.35529.jhb@freebsd.org> Date: Mon, 12 Jul 2010 15:57:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> <201007120851.35529.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 13:57:32 -0000 On 12.07.2010, at 14:51, John Baldwin wrote: >> Well, the situation has changed. Machine died over the weekend = running our=20 >> test load with above kernel configuration. It seems that not having = ehci in=20 >> the kernel at boot just makes the MCE much more unlikely to occur, = but it=20 >> occurs. With ehci, I can panic the machine within a minute, without = ehci it=20 >> seems to take at least hours. Still, I don't get why not having the = ehci=20 >> driver in the kernel should have any effect, especially because = nothing is=20 >> attached to it. >=20 > Ok, so maybe the SMI# interrupts do play a role somehow, at least as = far as=20 > altering the timing. Hm, if I've understood your other email correctly, disabling usb legacy = support should get rid of SMIs just as well as loading the ehci driver. = What I tested was kernel with ehci (panic within a minute) versus kernel = without ehci (panic within hours), but both cases with usb legacy = support disabled in BIOS. So, again, if I understand this correctly, the = "SMI rate" should have been the same in both cases, because usb legacy = support was turned off entirely, and therefore loading or not loading = ehci should not impact the SMI rate. If this should be the case, why = would there be an altering of timings between these two test cases? Since SMM is out the the OS' control, I guess there's no good way to = track SMIs? Markus= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 13:57:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0001106564A; Mon, 12 Jul 2010 13:57:59 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 8254E8FC12; Mon, 12 Jul 2010 13:57:59 +0000 (UTC) Received: from [77.109.131.203] (port=60716 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYJWA-000DBb-TI; Mon, 12 Jul 2010 15:57:58 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <201007120848.48162.jhb@freebsd.org> Date: Mon, 12 Jul 2010 15:57:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44C2C747-5AD8-4B29-B83F-35FCFD3F5858@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <591666AA-E6CA-4478-9E96-3A2D558BD6B4@hostpoint.ch> <201007120848.48162.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 13:57:59 -0000 On 12.07.2010, at 14:48, John Baldwin wrote: > Hmm with mca disabled in the loader you should not be getting any = MCE's at all=20 > as we don't enable the MCE interrupt in the CPU in that case. Are you=20= > disabling it in the BIOS rather than loader.conf? I disabled it in loader.conf, just tested again, you're right, it just = reboots in that case. > 7.3 has MCA support, but disabled by default. IIRC we also tested 7.3 without being able to reproduce, but I'm not = sure (didn't do all the tests myself). But I guess we can rule out MCA at this point, since we just get a = forced reboot instead of a panic, right? Markus From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:01:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 455801065670 for ; Mon, 12 Jul 2010 15:01:51 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADB88FC1E for ; Mon, 12 Jul 2010 15:01:51 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o6CF1lrY019321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jul 2010 08:01:47 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 542BE1CC0D; Mon, 12 Jul 2010 08:01:47 -0700 (PDT) To: Andrei Kolu In-reply-to: Your message of "Mon, 12 Jul 2010 15:31:58 +0300." Date: Mon, 12 Jul 2010 08:01:47 -0700 From: "Kevin Oberman" Message-Id: <20100712150147.542BE1CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-12_02:2010-02-06, 2010-07-12, 2010-07-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007120067 Cc: freebsd-stable@freebsd.org Subject: Re: bogus DSCP value for ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:01:51 -0000 > From: Andrei Kolu > Date: Mon, 12 Jul 2010 15:31:58 +0300 > Sender: owner-freebsd-stable@freebsd.org > > Hi! > > I am testing FreeBSD 8.1-RC2 amd64 networking stuff and notice one > strange DSCP message with wireshark: > ------------------------------------ > Internet Protocol, Src: 192.168.1.111 (192.168.1.111), Dst: > 192.168.1.101 (192.168.1.101) > Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) > 0001 00.. = Differentiated Services Codepoint: Unknown (0x04) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > > Transmission Control Protocol, Src Port: ssh (22), Dst Port: > attachmate-s2s (2419), Seq: 2902917, Ack: 29842, Len: 132 > ------------------------------------ > > There is no firewall enabled. Only thing I changed (should have no > effect) was: "net.inet.tcp.ecn.enable: 1" > _______________________________________________ I don't know why Wireshark does not understand this, but it is defined in RFC2474 as Class Selector 2 or simply IP precedence of 2 (of 7). If you add the ECN bit, you have Assured Forwarding at IP priority 2. Whether you pass or respond to the DSCP bits is, of course, a personal choice, but there is nothing unusual with this and ssh has bee setting the bit for a long time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:08:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D2B1065960 for ; Mon, 12 Jul 2010 15:08:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF988FC20 for ; Mon, 12 Jul 2010 15:08:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F1F9946B89; Mon, 12 Jul 2010 11:08:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 01D608A04E; Mon, 12 Jul 2010 11:08:37 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Mon, 12 Jul 2010 11:05:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007120848.48162.jhb@freebsd.org> <44C2C747-5AD8-4B29-B83F-35FCFD3F5858@hostpoint.ch> In-Reply-To: <44C2C747-5AD8-4B29-B83F-35FCFD3F5858@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007121105.13592.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 11:08:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:08:45 -0000 On Monday, July 12, 2010 9:57:58 am Markus Gebert wrote: > > On 12.07.2010, at 14:48, John Baldwin wrote: > > > > Hmm with mca disabled in the loader you should not be getting any MCE's at all > > as we don't enable the MCE interrupt in the CPU in that case. Are you > > disabling it in the BIOS rather than loader.conf? > > I disabled it in loader.conf, just tested again, you're right, it just reboots in that case. > > > > 7.3 has MCA support, but disabled by default. > > IIRC we also tested 7.3 without being able to reproduce, but I'm not sure (didn't do all the tests myself). > > But I guess we can rule out MCA at this point, since we just get a forced reboot instead of a panic, right? Yes. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:08:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CC791065976 for ; Mon, 12 Jul 2010 15:08:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 18D888FC21 for ; Mon, 12 Jul 2010 15:08:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BFFFE46B85; Mon, 12 Jul 2010 11:08:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 041558A04F; Mon, 12 Jul 2010 11:08:41 -0400 (EDT) From: John Baldwin To: Markus Gebert Date: Mon, 12 Jul 2010 11:06:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007120851.35529.jhb@freebsd.org> <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> In-Reply-To: <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007121106.59454.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 12 Jul 2010 11:08:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:08:46 -0000 On Monday, July 12, 2010 9:57:29 am Markus Gebert wrote: > > On 12.07.2010, at 14:51, John Baldwin wrote: > > >> Well, the situation has changed. Machine died over the weekend running our > >> test load with above kernel configuration. It seems that not having ehci in > >> the kernel at boot just makes the MCE much more unlikely to occur, but it > >> occurs. With ehci, I can panic the machine within a minute, without ehci it > >> seems to take at least hours. Still, I don't get why not having the ehci > >> driver in the kernel should have any effect, especially because nothing is > >> attached to it. > > > > Ok, so maybe the SMI# interrupts do play a role somehow, at least as far as > > altering the timing. > > Hm, if I've understood your other email correctly, disabling usb legacy support should get rid of SMIs just as well as loading the ehci driver. What I tested was kernel with ehci (panic within a minute) versus kernel without ehci (panic within hours), but both cases with usb legacy support disabled in BIOS. So, again, if I understand this correctly, the "SMI rate" should have been the same in both cases, because usb legacy support was turned off entirely, and therefore loading or not loading ehci should not impact the SMI rate. If this should be the case, why would there be an altering of timings between these two test cases? Oh, I didn't know that USB legacy support was disabled in both cases. That should disable all the SMIs in both cases as you say. Are you using Cx states other than C1 for the CPUs at all? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:23:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B52A1065670; Mon, 12 Jul 2010 15:23:25 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3908FC1C; Mon, 12 Jul 2010 15:23:25 +0000 (UTC) Received: from [77.109.131.203] (port=60981 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYKqq-000KKP-44; Mon, 12 Jul 2010 17:23:24 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <201007121106.59454.jhb@freebsd.org> Date: Mon, 12 Jul 2010 17:23:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4615FFAA-F78B-475E-B40B-CC33791F1D23@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007120851.35529.jhb@freebsd.org> <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> <201007121106.59454.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:23:25 -0000 On 12.07.2010, at 17:06, John Baldwin wrote: > Are you using Cx states other than C1 for the CPUs at all? Not sure how to find out, but I did not change anything in the BIOS = settings (if even possible) or through sysctl regarding cpu idle modes. = Anyway, here's what I found: # sysctl machdep.idle machdep.idle_available machdep.idle: amdc1e machdep.idle_available: spin, amdc1e, hlt, acpi,=20 Not sure if "amdc1e" qualifies for something "other than C1". I tried = "hlt" once, which didn't make a difference IIRC. And if that's not what = you needed, here's more: # sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2786 dev.cpu.0.freq_levels: 2786/95000 2587/81800 2388/69811 2189/58977 = 1990/49240 1791/44316 995/22525 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=3D\_PR_.P002 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=3D\_PR_.P003 dev.cpu.2.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/0 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 500us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=3D\_PR_.P004 dev.cpu.3.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/0 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 500us Markus= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:40:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC5A61065670 for ; Mon, 12 Jul 2010 15:40:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 76F8B8FC13 for ; Mon, 12 Jul 2010 15:40:38 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id h0i61e00816LCl05C3gewG; Mon, 12 Jul 2010 15:40:38 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta06.westchester.pa.mail.comcast.net with comcast id h3gd1e00G3LrwQ23S3geJ0; Mon, 12 Jul 2010 15:40:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 39C239B425; Mon, 12 Jul 2010 08:40:36 -0700 (PDT) Date: Mon, 12 Jul 2010 08:40:36 -0700 From: Jeremy Chadwick To: Markus Gebert Message-ID: <20100712154036.GA13481@icarus.home.lan> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007120851.35529.jhb@freebsd.org> <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> <201007121106.59454.jhb@freebsd.org> <4615FFAA-F78B-475E-B40B-CC33791F1D23@hostpoint.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4615FFAA-F78B-475E-B40B-CC33791F1D23@hostpoint.ch> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable , John Baldwin Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:40:38 -0000 On Mon, Jul 12, 2010 at 05:23:23PM +0200, Markus Gebert wrote: > > On 12.07.2010, at 17:06, John Baldwin wrote: > > > Are you using Cx states other than C1 for the CPUs at all? > > Not sure how to find out, but I did not change anything in the BIOS settings (if even possible) or through sysctl regarding cpu idle modes. Anyway, here's what I found: > > # sysctl machdep.idle machdep.idle_available > machdep.idle: amdc1e > machdep.idle_available: spin, amdc1e, hlt, acpi, > > Not sure if "amdc1e" qualifies for something "other than C1". I tried "hlt" once, which didn't make a difference IIRC. And if that's not what you needed, here's more: > > # sysctl dev.cpu > [...] > dev.cpu.0.freq_levels: 2786/95000 2587/81800 2388/69811 2189/58977 1990/49240 1791/44316 995/22525 > dev.cpu.0.cx_supported: C1/0 > dev.cpu.0.cx_lowest: C1 > [...] cx_supported indicates your CPU only supports C1 and not lower power-saving states (C2/C3/C4, etc.). Non-C1 states can sometimes do "interesting" things when it comes to interrupt handling. I believe your system may support the C1E state (given what machdep.idle_available shows), but that's often controlled by the system BIOS (on both Intel and AMD processors, but I'm trying to focus on AMD here). C1E, as far as I know, is the same as C1 state except can save a little bit more power. I believe neither C1 nor C1E do anything with interrupts, instead just halting the core when idle/not in use. HLT mode, at least on multi-core AMD CPUs, equates to C1E. Shot in the dark: you're not running powerd(8) on this system are you? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 15:43:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68763106566C for ; Mon, 12 Jul 2010 15:43:19 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF578FC14 for ; Mon, 12 Jul 2010 15:43:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id C962A25EFDC; Mon, 12 Jul 2010 11:43:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSjzhQL7n2Os; Mon, 12 Jul 2010 11:43:17 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 3B03725EFD4; Mon, 12 Jul 2010 11:43:17 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 35E8C705E4; Mon, 12 Jul 2010 11:43:17 -0400 (EDT) Date: Mon, 12 Jul 2010 11:43:17 -0400 From: Adam McDougall To: Markus Gebert Message-ID: <20100712154316.GD15784@egr.msu.edu> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:43:19 -0000 I also get MCE on x4100m2 when causing significant disk activity in mpt while also downloading through em0 or em1. I was not able to trigger it while using nfe, however nfe locked up on me during normal DNS server traffic so that was a wash. What seemed to work for me was to add an Intel PCIE nic to the server and use it instead of the onboard NICS. For whatever reason I never experienced this problem until using ZFS. I triggered it by downloading a 200m tgz file via http repeatedly over gigabit and it would reliably crash within a minute or two. I ordered a dozen nics for probably around $20 each and was satisfied with this workaround given the age of the servers. I'm pinched on time for work so I often don't get around to reporting issues where I've found a workaround, I'm glad you can get that started. On Fri, Jul 09, 2010 at 05:26:00PM +0200, Markus Gebert wrote: Hi Summary: With FreeBSD 8.1-RC2 we get an MCE (fatal trap 28) on a Sun X4100M2 when putting load on mpt and em. Initially thinking of a hardware problem, and after many tests, we're able to avoid the panic by not compiling the usb stack into the kernel. We cannot reproduce the problem on 6.x, 7.x or, as it seems right now, even CURRENT. long story: We're in the process of testing FreeBSD 8.1-RC2 for future deployment on our servers. When testing on a Sun X4100M2 we have encountered strange behavior: Under medium load, the test machine would reboot itself (hardware-triggered) without panic and spit out errors like "hypertransport sync flood error on last boot" during POST (or complain about fatal PCI errors). Thinking our test machine could have bad hardware, we replaced RAM, which didn't help. We've also put the same load on a second X4100M2, getting the same results. Both test machines had been in production before, happily running 6.4. We have at least 35 X4100M2 running on 6.4 in production, and another 15 running on 7.2, all of them not showing this problem at all. So we started thinking this problem could be software-related or at least triggered by software. After altering a BIOS setting to not reboot in case of a hypertransport flood, we finally managed to get an MCE reported by MCA and a fatal trap 28: -- MCA: Bank 4, Status 0xb400004000030c2b MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 MCA: CPU 2 UNCOR BUSLG Observer WR I/O MCA: Address 0xfd00000000 Fatal trap 28: machine check trap while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff80876506 stack pointer = 0x28:0xffffff800004ab50 frame pointer = 0x28:0xffffff800004ab60 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 11 (idle: cpu2) trap number = 28 panic: machine check trap cpuid = 2 Uptime: 3m9s -- Still, this may suggest a hardware problem. A 8.1 kernel with debug options didn't bring any more information. When WITNESS kicked in, it seemed random and to be symptom rather than cause. The same goes for DDB backtraces, random and most probably worthless. I guess that's expected with this kind of panic. So we fell back on trial&error and ruling out stuff that is new in FreeBSD 8. What we've learned so far: - we cannot reproduce with 6.x, 7.x - upgrading system firmware and lsi logic raidcontroller firmware did not help - disabling superpages does not help - disabling MCA does not help - although zfs scrub is part of a good way to reproduce the panic, we can also reproduce it with UFS, so zfs seems to be off the hook - best way to reproduce: put load on em (wget a large file) AND mpt (cp a large file, or run zpool scrub), panic within less than a minute - only putting load on em OR mpt does not reliably reproduce the panic - putting load on nfe and mpt does not reliably reproduce the panic - buildkernel with -j8 always runs through just fine - em and mpt sit on the same pci bus - so far, we couldn't reproduce the panic on CURRENT At this point we thought of a bug in either em, mpt or pci code, but weren't able to find anything in the svn commit logs that could explain what we were seeing. It's hard though to find something so unspecific... Out of despair, we tried to rule out the new usb stack. We kicked everything usb-related out of our kernel config, and with this usb-less kernel, the MCEs disappered! So, although the way to reproduce is to put load on load em and mpt, the real trigger seems to be usb, which gets no load at all. The only devices there are the iLOM virtual mouse and keyboard and we did not use the graphical remote console during our tests (iLOM serial console only). We tried to break this down further and learned: - not 100% sure, but loading the necessary usb modules (ohci, ehci, ukbd, ums) after boot (manually with kldload) seems fine, no panic so far when trying to reproduce like this - a kernel with only ohci, ukbd and ums compiled-in is fine - a kernel with only ehci compiled-in makes us able to reproduce the panic - so ehci being there on kernel boot seems to have some kind of relevance - we see no changes to the ehci code from 8.1 to CURRENT that could make the problem go away, so the cause could be elsewhere (pci code?) and ehci is just a trigger At this point we're stuck and need help from someone with more insight. The test system will be available for a while, so if you need us to run more tests, we're happy to do that. We maybe could also provide remote access to such a system if necessary. Although we have workaround now, that works for us, it would still be great to see this fixed. I guess we're not the only ones out there using X4100M2s with FreeBSD. About the test setup: - Sun X4100M2 - tested with 4 and 16 GB RAM - two PCIe nfe interfaces - two PCI-X em interfaces - one PCI-X mpt controller, non-raid mode, two disks (da), gpt-partioned, zfs mirror, boot from zfs - one OHCI controller with iLOM virtual keyboard and virtual mouse attached - one EHCI controller with nothing attached More information about the system below. Any help appreciated. Markus # uname -a FreeBSD XX.hostpoint.ch 8.1-RC2 FreeBSD 8.1-RC2 #4: Fri Jul 9 16:53:56 CEST 2010 root@XX.hostpoint.ch:/usr/obj/usr/src/sys/YY amd64 # cpuinfo Machine class: amd64 CPU Model: Dual-Core AMD Opteron(tm) Processor 2220 Number of CPUs: 4 # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON # pciconf -lv none0@pci0:0:0:0: class=0x058000 card=0x00000000 chip=0x005e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Memory Controller' class = memory isab0@pci0:0:1:0: class=0x060100 card=0xcb8410de chip=0x005110de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 ISA Bridge' class = bridge subclass = PCI-ISA none1@pci0:0:1:1: class=0x0c0500 card=0xcb8410de chip=0x005210de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 SMBus' class = serial bus subclass = SMBus ohci0@pci0:0:2:0: class=0x0c0310 card=0xcb84108e chip=0x005a10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:2:1: class=0x0c0320 card=0xcb84108e chip=0x005b10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 USB 2.0 Controller' class = serial bus subclass = USB atapci0@pci0:0:6:0: class=0x01018a card=0xcb8410de chip=0x005310de rev=0xf2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Parallel ATA Controller' class = mass storage subclass = ATA pcib1@pci0:0:9:0: class=0x060401 card=0x00000000 chip=0x005c10de rev=0xf2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCI Bridge' class = bridge subclass = PCI-PCI nfe0@pci0:0:10:0: class=0x068000 card=0xcb8410de chip=0x005710de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA Network Bus Enumerator (CK804)' class = bridge pcib2@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:0:12:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib4@pci0:0:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib5@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI hostb4@pci0:0:25:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb5@pci0:0:25:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hostb6@pci0:0:25:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hostb7@pci0:0:25:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI vgapci0@pci0:1:3:0: class=0x030000 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA none2@pci0:128:0:0: class=0x058000 card=0x00000000 chip=0x005e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Memory Controller' class = memory none3@pci0:128:1:0: class=0x058000 card=0xcb8410de chip=0x00d310de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce4 Memory Controller' class = memory nfe1@pci0:128:10:0: class=0x068000 card=0xcb8410de chip=0x005710de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA Network Bus Enumerator (CK804)' class = bridge pcib7@pci0:128:11:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib8@pci0:128:12:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib9@pci0:128:13:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xf3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib10@pci0:128:14:0: class=0x060400 card=0x00000000 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce4 PCIe Bridge' class = bridge subclass = PCI-PCI pcib11@pci0:128:16:0: class=0x060400 card=0x00000000 chip=0x74581022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'PCI-X Bridge (AMD-8132)' class = bridge subclass = PCI-PCI ioapic0@pci0:128:16:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'PCI-X IOAPIC (AMD-8132)' class = base peripheral subclass = interrupt controller pcib12@pci0:128:17:0: class=0x060400 card=0x00000000 chip=0x74581022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'PCI-X Bridge (AMD-8132)' class = bridge subclass = PCI-PCI ioapic1@pci0:128:17:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'PCI-X IOAPIC (AMD-8132)' class = base peripheral subclass = interrupt controller em0@pci0:134:1:0: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class = network subclass = ethernet em1@pci0:134:1:1: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class = network subclass = ethernet mpt0@pci0:134:2:0: class=0x010000 card=0x30601000 chip=0x00501000 rev=0x02 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 4-port with 1064 -StorPort' class = mass storage subclass = SCSI # cat /usr/src/sys/amd64/conf/YY include GENERIC ident YY options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed (other version with no usb or no ehci could be provided if necessary) verbose boot: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009bc00 SMAP type=02 base=000000000009bc00 len=0000000000004400 SMAP type=02 base=00000000000e6000 len=000000000001a000 SMAP type=01 base=0000000000100000 len=00000000dbea0000 SMAP type=01 base=00000000dbfae000 len=0000000000002000 SMAP type=03 base=00000000dbfb0000 len=000000000000e000 SMAP type=04 base=00000000dbfbe000 len=0000000000032000 SMAP type=02 base=00000000dbff0000 len=0000000000010000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff700000 len=0000000000900000 SMAP type=01 base=0000000100000000 len=0000000324000000 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RC2 #4: Fri Jul 9 16:53:56 CEST 2010 root@XX.hostpoint.ch:/usr/obj/usr/src/sys/YY amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81204000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81204250. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff812048f8. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff81204f28. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2792595272 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2220 (2792.60-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x000000000123f000 - 0x00000000dbf9ffff, 3671461888 bytes (896353 pages) 0x00000000dbfae000 - 0x00000000dbfaffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x0000000404dd5fff, 12966518784 bytes (3165654 pages) avail memory = 16551731200 (15784 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x010000-0x01ffff at 0xffffff800004a000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0effff at 0xffffff00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa040 00024 (v2 SUN ) ACPI: XSDT 0xdbfb0100 00094 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: FACP 0xdbfb0290 000F4 (v3 SUN X4200 M2 00000104 MSFT 00000097) ACPI: DSDT 0xdbfb0510 0702A (v1 SUN X4200 M2 00000104 INTL 20050624) ACPI: FACS 0xdbfbe000 00040 ACPI: APIC 0xdbfb0390 000B0 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SPCR 0xdbfb0440 00050 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SLIT 0xdbfb0490 00030 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SPMI 0xdbfb04c0 00041 (v5 SUN OEMSPMI 00000104 MSFT 00000097) ACPI: OEMB 0xdbfbe040 00063 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SRAT 0xdbfb7540 00110 (v1 AMD FAM_F_10 00000002 AMD 00000001) ACPI: HPET 0xdbfb7650 00038 (v1 SUN OEMHPET0 00000104 MSFT 00000097) ACPI: IPET 0xdbfb7690 00038 (v1 SUN OEMHPET1 00000104 MSFT 00000097) ACPI: EINJ 0xdbfb76d0 00130 (v1 AMIER AMI_EINJ 04000909 MSFT 00000097) ACPI: BERT 0xdbfb7860 00030 (v1 AMIER AMI_BERT 04000909 MSFT 00000097) ACPI: ERST 0xdbfb7890 001B0 (v1 AMIER AMI_ERST 04000909 MSFT 00000097) ACPI: HEST 0xdbfb7a40 000A8 (v1 AMIER AMI_HEST 04000909 MSFT 00000097) ACPI: SSDT 0xdbfb7af0 00574 (v1 A M I POWERNOW 00000001 AMD 00000001) MADT: Found IO APIC ID 15, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 16, Interrupt 48 at 0xfeafd000 ioapic1: Changing APIC ID to 16 ioapic1: WARNING: intbase 48 != expected base 24 MADT: Found IO APIC ID 17, Interrupt 56 at 0xfeafc000 ioapic2: Changing APIC ID to 17 ioapic2: WARNING: intbase 56 != expected base 55 MADT: Found IO APIC ID 14, Interrupt 24 at 0xfeaff000 ioapic3: WARNING: intbase 24 != expected base 63 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 ioapic3 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard ioapic1 irqs 48-54 on motherboard ioapic2 irqs 56-62 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000031000 pa 0x4000 AcpiOsDerivePciId: \_SB_.PCI0.MAP0.CFG_ -> bus 0 dev 24 func 1 unknown: I/O range not supported AcpiOsDerivePciId: \_SB_.PCI0.SBRG.BAR0 -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \_SB_.PCIB.IO84.BAR1 -> bus 128 dev 1 func 0 AcpiOsDerivePciId: \_SB_.PCIC.IO42.BAR2 -> bus 255 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dbf00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 3 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x005e, revid=0xa3 domain=0, bus=0, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0051, revid=0xf3 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0052, revid=0xa2 domain=0, bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x9200, size 5, enabled map[20]: type I/O Port, range 32, base 0x400, size 6, enabled map[24]: type I/O Port, range 32, base 0x440, size 6, enabled found-> vendor=0x10de, dev=0x005a, revid=0xa2 domain=0, bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3ff000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \_SB_.LUS0:0) pci_link5: Picked IRQ 20 with weight 0 pcib0: slot 2 INTA routed to irq 20 via \_SB_.LUS0 found-> vendor=0x10de, dev=0x005b, revid=0xa3 domain=0, bus=0, slot=2, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3fec00, size 8, enabled pcib0: matched entry for 0.2.INTB (src \_SB_.LUS2:0) pci_link7: Picked IRQ 21 with weight 0 pcib0: slot 2 INTB routed to irq 21 via \_SB_.LUS2 found-> vendor=0x10de, dev=0x0053, revid=0xf2 domain=0, bus=0, slot=6, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x9100, size 4, enabled found-> vendor=0x10de, dev=0x005c, revid=0xf2 domain=0, bus=0, slot=9, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0057, revid=0xf3 domain=0, bus=0, slot=10, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3fd000, size 12, enabled map[14]: type I/O Port, range 32, base 0xdc00, size 3, enabled pcib0: matched entry for 0.10.INTA (src \_SB_.LKLN:0) pci_link8: Picked IRQ 22 with weight 0 pcib0: slot 10 INTA routed to irq 22 via \_SB_.LKLN found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=0, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=0, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=0, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=25, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=25, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=25, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=25, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe3ff000-0xfe3fffff irq 20 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe3ff000 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe3fec00-0xfe3fecff irq 21 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe3fec00 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] ehci0: Doorbell workaround enabled usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9100-0x910f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9100 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 ata1: [MPSAFE] ata1: [ITHREAD] pcib1: at device 9.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc200000-0xfe2fffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x4752, revid=0x27 domain=0, bus=1, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type I/O Port, range 32, base 0xc800, size 8, enabled pcib1: requested I/O range 0xc800-0xc8ff: in range map[18]: type Memory, range 32, base 0xfe2ff000, size 12, enabled pcib1: requested memory range 0xfe2ff000-0xfe2fffff: good pcib1: matched entry for 1.3.INTA (src \_SB_.LNKA:0) pci_link0: Picked IRQ 16 with weight 0 pcib1: slot 3 INTA routed to irq 16 via \_SB_.LNKA vgapci0: port 0xc800-0xc8ff mem 0xfd000000-0xfdffffff,0xfe2ff000-0xfe2fffff irq 16 at device 3.0 on pci1 nfe0: port 0xdc00-0xdc07 mem 0xfe3fd000-0xfe3fdfff irq 22 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe3fd000 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:14:4f:8d:fe:ea ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 53 nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pcib2: could not get PCI interrupt routing table for \_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 12.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pcib3: could not get PCI interrupt routing table for \_SB_.PCI0.P0P3 - AE_NOT_FOUND pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: at device 13.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: at device 14.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pcib6: on acpi0 pci128: on pcib6 pci128: domain=0, physical bus=128 found-> vendor=0x10de, dev=0x005e, revid=0xa3 domain=0, bus=128, slot=0, func=0 class=05-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x00d3, revid=0xf3 domain=0, bus=128, slot=1, func=0 class=05-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[14]: type Memory, range 32, base 0xfeaff000, size 12, enabled found-> vendor=0x10de, dev=0x0057, revid=0xf3 domain=0, bus=128, slot=10, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeafe000, size 12, enabled map[14]: type I/O Port, range 32, base 0xfc00, size 3, enabled pcib6: matched entry for 128.10.INTA (src \_SB_.LK2N:0) pci_link23: Picked IRQ 44 with weight 0 pcib6: slot 10 INTA routed to irq 44 via \_SB_.LK2N found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=128, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=128, slot=12, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xf3 domain=0, bus=128, slot=13, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x005d, revid=0xa3 domain=0, bus=128, slot=14, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0046, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x1022, dev=0x7458, revid=0x12 domain=0, bus=128, slot=16, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0156, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7459, revid=0x12 domain=0, bus=128, slot=16, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Memory, range 64, base 0xfeafd000, size 12, enabled found-> vendor=0x1022, dev=0x7458, revid=0x12 domain=0, bus=128, slot=17, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0157, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7459, revid=0x12 domain=0, bus=128, slot=17, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Memory, range 64, base 0xfeafc000, size 12, enabled pci128: at device 0.0 (no driver attached) pci128: at device 1.0 (no driver attached) nfe1: port 0xfc00-0xfc07 mem 0xfeafe000-0xfeafefff irq 44 at device 10.0 on pci128 nfe1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafe000 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: bpf attached nfe1: Ethernet address: 00:14:4f:8d:fe:eb ioapic3: routing intpin 20 (PCI IRQ 44) to lapic 0 vector 54 nfe1: [MPSAFE] nfe1: [FILTER] pcib7: at device 11.0 on pci128 pcib7: domain 0 pcib7: secondary bus 129 pcib7: subordinate bus 129 pcib7: I/O decode 0x0-0x0 pcib7: no prefetched decode pcib7: could not get PCI interrupt routing table for \_SB_.PCIB.BR5B - AE_NOT_FOUND pci129: on pcib7 pci129: domain=0, physical bus=129 pcib8: at device 12.0 on pci128 pcib8: domain 0 pcib8: secondary bus 130 pcib8: subordinate bus 130 pcib8: I/O decode 0x0-0x0 pcib8: no prefetched decode pcib8: could not get PCI interrupt routing table for \_SB_.PCIB.BR5C - AE_NOT_FOUND pci130: on pcib8 pci130: domain=0, physical bus=130 pcib9: at device 13.0 on pci128 pcib9: domain 0 pcib9: secondary bus 131 pcib9: subordinate bus 131 pcib9: I/O decode 0x0-0x0 pcib9: no prefetched decode pci131: on pcib9 pci131: domain=0, physical bus=131 pcib10: at device 14.0 on pci128 pcib10: domain 0 pcib10: secondary bus 132 pcib10: subordinate bus 132 pcib10: I/O decode 0x0-0x0 pcib10: no prefetched decode pci132: on pcib10 pci132: domain=0, physical bus=132 pcib11: at device 16.0 on pci128 pcib11: domain 0 pcib11: secondary bus 133 pcib11: subordinate bus 133 pcib11: I/O decode 0x0-0x0 pcib11: no prefetched decode pci133: on pcib11 pci133: domain=0, physical bus=133 pcib12: at device 17.0 on pci128 pcib12: domain 0 pcib12: secondary bus 134 pcib12: subordinate bus 134 pcib12: I/O decode 0xe000-0xefff pcib12: memory decode 0xfe500000-0xfe9fffff pcib12: no prefetched decode pci134: on pcib12 pci134: domain=0, physical bus=134 found-> vendor=0x8086, dev=0x1010, revid=0x03 domain=0, bus=134, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9e0000, size 17, enabled pcib12: requested memory range 0xfe9e0000-0xfe9fffff: good map[20]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib12: requested I/O range 0xec00-0xec3f: in range pcib12: matched entry for 134.1.INTA pcib12: slot 1 INTA hardwired to IRQ 56 found-> vendor=0x8086, dev=0x1010, revid=0x03 domain=0, bus=134, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9c0000, size 17, enabled pcib12: requested memory range 0xfe9c0000-0xfe9dffff: good map[20]: type I/O Port, range 32, base 0xe800, size 6, enabled pcib12: requested I/O range 0xe800-0xe83f: in range pcib12: matched entry for 134.1.INTB pcib12: slot 1 INTB hardwired to IRQ 57 found-> vendor=0x1000, dev=0x0050, revid=0x02 domain=0, bus=134, slot=2, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x48 (2160 ns), mingnt=0x40 (16000 ns), maxlat=0x0a (2500 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0xe400, size 8, enabled pcib12: requested I/O range 0xe400-0xe4ff: in range map[14]: type Memory, range 64, base 0xfe9bc000, size 14, enabled pcib12: requested memory range 0xfe9bc000-0xfe9bffff: good map[1c]: type Memory, range 64, base 0xfe9a0000, size 16, enabled pcib12: requested memory range 0xfe9a0000-0xfe9affff: good pcib12: matched entry for 134.2.INTA pcib12: slot 2 INTA hardwired to IRQ 58 em0: port 0xec00-0xec3f mem 0xfe9e0000-0xfe9fffff irq 56 at device 1.0 on pci134 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9e0000 em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xec00 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 0 vector 55 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:14:4f:8d:fe:ec em1: port 0xe800-0xe83f mem 0xfe9c0000-0xfe9dffff irq 57 at device 1.1 on pci134 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9c0000 em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe800 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 0 vector 56 em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:14:4f:8d:fe:ed mpt0: port 0xe400-0xe4ff mem 0xfe9bc000-0xfe9bffff,0xfe9a0000-0xfe9affff irq 58 at device 2.0 on pci134 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfe9bc000 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 0 vector 57 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: MPI Version=1.5.20.0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc9fff,0xca000-0xcb7ff,0xcb800-0xcc7ff,0xcc800-0xcd7ff,0xd3800-0xd47ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices powernow0: on cpu0 powernow1: on cpu1 powernow2: on cpu2 powernow3: on cpu3 Device configuration finished. Reducing kern.maxvnodes 1031944 -> 100000 procfs registered ZFS filesystem version 3 ZFS storage pool version 14 lapic: Divisor 2, Frequency 99735545 Hz Timecounter "TSC" frequency 2792595272 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to accept, logging disabled ipfw0: bpf attached lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00010000 ata0: New devices: 00010000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting UDMA33 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 1654KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable caddy, unlocked acd0: Medium: no/blank disc ata1: Identifying devices: 00000000 ata1: New devices: 00000000 uhub0: 7 ports with 7 removable, self powered uhub1: 7 ports with 7 removable, self powered (probe71:mpt0:1:8:0): Error 22, Unretryable error (probe72:mpt0:1:9:0): Error 22, Unretryable error (probe73:mpt0:1:10:0): Error 22, Unretryable error (probe74:mpt0:1:11:0): Error 22, Unretryable error (probe75:mpt0:1:12:0): Error 22, Unretryable error (probe76:mpt0:1:13:0): Error 22, Unretryable error (probe63:mpt0:1:0:0): Error 22, Unretryable error (probe64:mpt0:1:1:0): Error 22, Unretryable error (probe65:mpt0:1:2:0): Error 22, Unretryable error (probe66:mpt0:1:3:0): Error 22, Unretryable error (probe67:mpt0:1:4:0): Error 22, Unretryable error (probe68:mpt0:1:5:0): Error 22, Unretryable error (probe69:mpt0:1:6:0): Error 22, Unretryable error (probe70:mpt0:1:7:0): Error 22, Unretryable error pass0 at mpt0 bus 0 scbus0 target 2 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number 18216LAX 3NP16LAX pass0: 300.000MB/s transfers pass0: Command Queueing enabled da0 at mpt0 bus 0 scbus0 target 2 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number 18216LAX 3NP16LAX da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 scbus0 target 3 lun 0 da1: Fixed Direct Access SCSI-5 device da1: Serial Number 16216D68 3NP16D68 da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM: new disk da0 GEOM: new disk da1 pass1 at mpt0 bus 0 scbus0 target 3 lun 0 pass1: Fixed Direct Access SCSI-5 device pass1: Serial Number 16216D68 3NP16D68 pass1: 300.000MB/s transfers pass1: Command Queueing enabled ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 (folaopwitca0b:l er oculteiannge ri nsttpairnt e4d ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 3 vector 48 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 2 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 49 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 1 vector 50 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 2 vector 50 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 3 vector 50 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot_______________________________________________ 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 Jul 12 15:52:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED2A106566B; Mon, 12 Jul 2010 15:52:39 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 43D778FC13; Mon, 12 Jul 2010 15:52:39 +0000 (UTC) Received: from [77.109.131.203] (port=61054 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYLJ7-000LqB-Tj; Mon, 12 Jul 2010 17:52:37 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <20100712154036.GA13481@icarus.home.lan> Date: Mon, 12 Jul 2010 17:52:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0904AF9E-C14C-4A98-B395-CC1EB4A84393@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007120851.35529.jhb@freebsd.org> <0CF6CF2B-907C-42EF-B57E-DF50F0564455@hostpoint.ch> <201007121106.59454.jhb@freebsd.org> <4615FFAA-F78B-475E-B40B-CC33791F1D23@hostpoint.ch> <20100712154036.GA13481@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable , John Baldwin Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 15:52:40 -0000 On 12.07.2010, at 17:40, Jeremy Chadwick wrote: > cx_supported indicates your CPU only supports C1 and not lower > power-saving states (C2/C3/C4, etc.). Non-C1 states can sometimes do > "interesting" things when it comes to interrupt handling. I believe > your system may support the C1E state (given what = machdep.idle_available > shows), but that's often controlled by the system BIOS (on both Intel > and AMD processors, but I'm trying to focus on AMD here). C1E, as far > as I know, is the same as C1 state except can save a little bit more > power. >=20 > I believe neither C1 nor C1E do anything with interrupts, instead just > halting the core when idle/not in use. HLT mode, at least on = multi-core > AMD CPUs, equates to C1E. I see. > Shot in the dark: you're not running powerd(8) on this system are you? No, I'm not. But once in our long series of trial&error, I tried to = enabled it, just to see wether it would trigger something. It didn't, = but the system was not loaded at that time. But I just remebered that I once tried to reproduce the problem with = kern.smp.disabled=3D1 in loader.conf, but with the test load running = only on the BSP, the problem did not seem to occur. Don't know if this = is any of any help though. Markus= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 16:08:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008BC1065674 for ; Mon, 12 Jul 2010 16:08:56 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id B8E5F8FC1C for ; Mon, 12 Jul 2010 16:08:55 +0000 (UTC) Received: from [77.109.131.203] (port=61079 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYLYs-000MKb-Ea; Mon, 12 Jul 2010 18:08:54 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <20100712154316.GD15784@egr.msu.edu> Date: Mon, 12 Jul 2010 18:08:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA1E184-D9FF-4093-A6D9-18AF6DDC7407@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <20100712154316.GD15784@egr.msu.edu> To: Adam McDougall X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 16:08:56 -0000 On 12.07.2010, at 17:43, Adam McDougall wrote: > I also get MCE on x4100m2 when causing significant disk activity in = mpt > while also downloading through em0 or em1. Could you reproduce this on 6.x or 7.x? Because whatever we try here, we = simply couldn't so far. A short test with Ubuntu also didn't show any = sing of problems. > I was not able to trigger it > while using nfe, however nfe locked up on me during normal DNS server > traffic so that was a wash. We had issues with nfe pre-8.x, that's why we have been using the em = nics, which seem to be part of the problem now in 8.x. > What seemed to work for me was to add an > Intel PCIE nic to the server and use it instead of the onboard NICS. Thanks for the hint. > For whatever reason I never experienced this problem until using ZFS. We were able to reproduce it with UFS on 8.x. with just one disks (no = gmirror), but I guess it's easier to trigger with ZFS especially in an = mirror setup. > I triggered it by downloading a 200m tgz file via http repeatedly > over gigabit and it would reliably crash within a minute or two. Our test case is basically: 1. fetch a large file using wget over em0 (100mbit link seems enough) 2. cp a large file locally to stress mpt 3. wait for MCE > I ordered a dozen nics for probably around $20 each and was satisfied > with this workaround given the age of the servers. I'm pinched on = time > for work so I often don't get around to reporting issues where I've > found a workaround, I'm glad you can get that started.=20 "Glad" we're not the only ones :-) Markus From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 17:03:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E721065672 for ; Mon, 12 Jul 2010 17:03:06 +0000 (UTC) (envelope-from antinix@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7CA8FC0A for ; Mon, 12 Jul 2010 17:03:05 +0000 (UTC) Received: by wwb31 with SMTP id 31so237853wwb.31 for ; Mon, 12 Jul 2010 10:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=zuikBW05b+iTX+1lMWQj9/L88sDMk21xdgw1TCV+PkY=; b=g+ZTPN5py2pIcmXjlAM/y9vFb3jp5oGWr4PttY2yK7LrgfspCAiSE1FjxsAOp5d8cz VPMnrn04pAIo/nqD+ODfZ9iCXsyVrYibaWnrthAVDzU0rRkKNfcWwAsgcID2FXPD8uUD 17JUUNmxdnFsDYqzWAL7t237hCyN4fdXeI4Pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=JL85uoaas38sOVZmC3ave/ERcNpuTUKiGToehUe6NjiY+rtEu9JSdyFpRQTlM/EHRu fdkPIrJirDfacE9I4EeliYewe0oacFKZk1By9HdsiZiZWbK/urvHncvS/va0L/jm1M0K 8GXqeGmoLvf6z18sji4IHhEGwj9sNFk7x15gQ= Received: by 10.216.159.202 with SMTP id s52mr8883154wek.33.1278954184211; Mon, 12 Jul 2010 10:03:04 -0700 (PDT) MIME-Version: 1.0 Sender: antinix@gmail.com Received: by 10.216.45.194 with HTTP; Mon, 12 Jul 2010 10:02:44 -0700 (PDT) In-Reply-To: <20100712150147.542BE1CC0D@ptavv.es.net> References: <20100712150147.542BE1CC0D@ptavv.es.net> From: Andrei Kolu Date: Mon, 12 Jul 2010 20:02:44 +0300 X-Google-Sender-Auth: HxKXOz0QypAFQ256L89Qdyv8f5k Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: bogus DSCP value for ssh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 17:03:06 -0000 2010/7/12 Kevin Oberman : >> From: Andrei Kolu >> Date: Mon, 12 Jul 2010 15:31:58 +0300 >> Sender: owner-freebsd-stable@freebsd.org >> >> Hi! >> >> I am testing FreeBSD 8.1-RC2 amd64 networking stuff and notice one >> strange DSCP message with wireshark: >> ------------------------------------ >> Internet Protocol, Src: 192.168.1.111 (192.168.1.111), Dst: >> 192.168.1.101 (192.168.1.101) >> Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) >> 0001 00.. = Differentiated Services Codepoint: Unknown (0x04) >> .... ..0. = ECN-Capable Transport (ECT): 0 >> .... ...0 = ECN-CE: 0 >> >> Transmission Control Protocol, Src Port: ssh (22), Dst Port: >> attachmate-s2s (2419), Seq: 2902917, Ack: 29842, Len: 132 >> ------------------------------------ >> >> There is no firewall enabled. Only thing I changed (should have no >> effect) was: "net.inet.tcp.ecn.enable: 1" >> _______________________________________________ > > I don't know why Wireshark does not understand this, but it is defined > in RFC2474 as Class Selector 2 or simply IP precedence of 2 (of 7). > > If you add the ECN bit, you have Assured Forwarding at IP priority 2. > > Whether you pass or respond to the DSCP bits is, of course, a personal > choice, but there is nothing unusual with this and ssh has bee setting > the bit for a long time. > -- My calculations (X is not used and always zero): 000|100|00 421|21X|00 ---------------- 000|200|00 11= high drop probability 10= medium drop probability 01= low drop probability So "Per-hop behavior" is 000binary= 0decimal and "Drop probability" is 10 binary=2 decimal="Medium drop probability". There is no such a DSCP drop probability value as 4 in existence. I think Wireshark is incorrect but how it is possible to define 000100 at all is beyound me- 000000 is "best effort" already. It is AF02? Yet another bogus priority value? Correct me if I'm wrong. Andrei From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 17:12:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0BC9106566B for ; Mon, 12 Jul 2010 17:12:02 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5268FC08 for ; Mon, 12 Jul 2010 17:12:02 +0000 (UTC) Received: by ywf9 with SMTP id 9so325535ywf.13 for ; Mon, 12 Jul 2010 10:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xfd/6hSqkTgx9beWM840xxI0aGVb2QrO6ceZmFXFhDI=; b=RFs6unZCWHFkJY8A1Q3yZBsr+D5ptvoX4A53dNx89RS36TPLdK2wCH0J8CekTj9xBC UJqNhR/xb+0NkJ2O9RcFsiRiewnF7OdOLwErjCltNd7ljfOo81LTsil5n0dInM+QCQoG wVwpOLXBZRkcGrlnnKF12KbzxYQCGUQrfKkgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZohtYRabhs4ODWs/hEMbXDi2oWTKR6mvM1wY+8ogG7gTi50slzf4KgM1sLbdiesoYI 7FI+8pJzMwMyTt88Uqsszc7rgqYnaqB/+5i+Gnj4FS0RJaX6DZxt3WUrYSqDTbdkG90T RrnxmhyGuahp+iSXWlVjhe5Q1ArUq3dFeJi9g= MIME-Version: 1.0 Received: by 10.229.182.5 with SMTP id ca5mr8548584qcb.98.1278954721316; Mon, 12 Jul 2010 10:12:01 -0700 (PDT) Received: by 10.229.86.12 with HTTP; Mon, 12 Jul 2010 10:11:48 -0700 (PDT) In-Reply-To: <4C3618B9.8010202@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> Date: Mon, 12 Jul 2010 12:11:48 -0500 Message-ID: From: Adam Vande More To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 17:12:02 -0000 On Thu, Jul 8, 2010 at 1:28 PM, Mikhail T. > wrote: > > RedHat's "kickstart < > http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html>" > can do an entire install based on pre-configured rules. Implementing > something like that for FreeBSD would, probably, take quite a bit of effort. > But being able to just boot straight into install from a CD (or CD-image) > across the LAN doesn't seem very complicated, considering, how close we > already are... > Automated installations have existed on FreeBSD for a long time. You can do this either via netboot or CD based media. Also rolling your own FreeBSD media with custom changes is trivial compared the linux distro's I'm familar with. I haven't used kickstart but I will say the FreeBSD method is easier to work with than the Debian FIA method. Plus there are many post-install configuration utilites like puppet to further automate stuff. This page is pretty well out of date, but the concepts remain the same. You can look at the work MFSBSD has done if you interested and there are more up to date howto floating around the www. http://www.freebsd.org/doc/en/articles/pxe/article.html You can find a sample install.cfg at /usr/src/usr.sbin/sysinstall/install.cfg Roll it into your media and make sure sysinstall is configed to use it. It's really that simple. There may certain aspects of this type of thing which make it more complicated, like installing custom packages, FW setup, etc. but the framework is simpler than many other OS's IMO. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 17:37:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C14106564A for ; Mon, 12 Jul 2010 17:37:31 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id E7D848FC1D for ; Mon, 12 Jul 2010 17:37:30 +0000 (UTC) Received: from mail.timeinc.net (timeinc2-lm25.websys.aol.com [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6CHbTLp006427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 13:37:29 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6CHbTN0026014; Mon, 12 Jul 2010 13:37:29 -0400 Message-ID: <4C3B52D9.9060602@aldan.algebra.com> Date: Mon, 12 Jul 2010 13:37:29 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Adam Vande More References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 17:37:31 -0000 12.07.2010 13:11, Adam Vande More wrote: > Roll it into your media You lost me right here... Rolling one's own media (for every release and release-candidate) may be Ok for someone in charge of making, at least, several installations per week. For someone like myself, who just wanted to use a downloaded CD-image straight (without burning it first), there is got to be a way to use the FreeBSD-distributed images... I'm not asking for the full power offered by "kickstart" et al, I just want the booting image to be a little bit smarter than it already is and do The Right Thing^TM regardless of whether it is booting from the local CD-ROM or remotely. Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 17:49:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C90106564A; Mon, 12 Jul 2010 17:49:10 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id CAB1A8FC1E; Mon, 12 Jul 2010 17:49:09 +0000 (UTC) Received: from mail.timeinc.net (timeinc2-lm25.websys.aol.com [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6CHn9l8008966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 13:49:09 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6CHn9gn030312; Mon, 12 Jul 2010 13:49:09 -0400 Message-ID: <4C3B5594.5050607@aldan.algebra.com> Date: Mon, 12 Jul 2010 13:49:08 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <20100711.140344.239525524663396359.imp@bsdimp.com> In-Reply-To: <20100711.140344.239525524663396359.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: des@freebsd.org Subject: sshd would not start (another 8.x grudge) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 17:49:10 -0000 The sshd would not start after the upgrade from 7.x to 8.1 on one of the systems: Starting sshd. cipher_encrypt: bad plaintext length 553 /etc/rc.d/sshd: WARNING: failed to start sshd Archiving the 3-year old /etc/ssh/ssh_host_rsa_key and having it recreated solved the immediate problem, but the connecting clients weren't happy about it... If anyone is interested, the old ssh_host_rsa_key is available by direct e-mail. -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 18:22:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 179861065673 for ; Mon, 12 Jul 2010 18:22:17 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id C54668FC1E for ; Mon, 12 Jul 2010 18:22:16 +0000 (UTC) Received: from MotorBookMKII.local (91-64-52-77-dynip.superkabel.de [91.64.52.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 8307AB03B6; Mon, 12 Jul 2010 20:22:14 +0200 (CEST) Message-ID: <4C3B5D55.5090107@kernel32.de> Date: Mon, 12 Jul 2010 20:22:13 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Adam Vande More References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mikhail T." , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 18:22:17 -0000 Hi Adam, Am 12.07.10 19:11, schrieb Adam Vande More: > > Automated installations have existed on FreeBSD for a long time. You can do > this either via netboot or CD based media. Also rolling your own FreeBSD > media with custom changes is trivial compared the linux distro's I'm familar > with. I haven't used kickstart but I will say the FreeBSD method is easier > to work with than the Debian FIA method. Plus there are many post-install > configuration utilites like puppet to further automate stuff. > I actually like the principle of FAI configspace that much, that a colleague of mine and myself ported the underlying FAI to OpenBSD. I tend to say, that configuring a server with FAI is way easier than with puppet. I'd love to pxeboot a minimal freebsd with a ramdisk and a base set of utilities to use FAI there too, however, my last attempts of doing that with FreeBSD failed. But your opinion may vary, of course :) > This page is pretty well out of date, but the concepts remain the same. You > can look at the work MFSBSD has done if you interested and there are more up > to date howto floating around the www. > humm... what is MFSBSD? Cheers, Marian From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 18:25:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6C6E1065670 for ; Mon, 12 Jul 2010 18:25:05 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6029D8FC19 for ; Mon, 12 Jul 2010 18:25:05 +0000 (UTC) Received: from MotorBookMKII.local (91-64-52-77-dynip.superkabel.de [91.64.52.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 421C7B03F1; Mon, 12 Jul 2010 20:25:04 +0200 (CEST) Message-ID: <4C3B5DFF.7050900@kernel32.de> Date: Mon, 12 Jul 2010 20:25:03 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Mikhail T." References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> <4C3B52D9.9060602@aldan.algebra.com> In-Reply-To: <4C3B52D9.9060602@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 18:25:05 -0000 Am 12.07.10 19:37, schrieb Mikhail T.: > 12.07.2010 13:11, Adam Vande More wrote: >> Roll it into your media > You lost me right here... Rolling one's own media (for every release > and release-candidate) may be Ok for someone in charge of making, at > least, several installations per week. > > For someone like myself, who just wanted to use a downloaded CD-image > straight (without burning it first), there is got to be a way to use > the FreeBSD-distributed images... I'm not asking for the full power > offered by "kickstart" et al, I just want the booting image to be a > little bit smarter than it already is and do The Right Thing^TM > regardless of whether it is booting from the local CD-ROM or remotely. > hm, I second that. While I fully understand that the iso images purpose is _not_ doing a netinstall, I'd like to have a downloadable image which is easy pxebootable and just drops into a shell. Ideally it does a dhcp request, if successful starts a sshd and if not has video and serial output enabled. Did anybody actually stripped down a FreeBSD to do just that? I read my way through the pxeboot articles and the handbook section of netbooting and everything... however, it really sounds a bit overcomplicated to do a "make release" and stuff. No offense ment, obviously :) best, Marian From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 19:58:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F0D21065673 for ; Mon, 12 Jul 2010 19:58:59 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 4559B8FC19 for ; Mon, 12 Jul 2010 19:58:58 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.4/8.14.3) with ESMTP id o6CJwwIB016352; Mon, 12 Jul 2010 13:58:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.4/8.14.3/Submit) with ESMTP id o6CJwsaX016349; Mon, 12 Jul 2010 13:58:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 12 Jul 2010 13:58:54 -0600 (MDT) From: Warren Block To: Marian Hettwer In-Reply-To: <4C3B5DFF.7050900@kernel32.de> Message-ID: References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> <4C3B52D9.9060602@aldan.algebra.com> <4C3B5DFF.7050900@kernel32.de> 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.2.5 (wonkity.com [127.0.0.1]); Mon, 12 Jul 2010 13:58:58 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 19:58:59 -0000 On Mon, 12 Jul 2010, Marian Hettwer wrote: > While I fully understand that the iso images purpose is _not_ doing a > netinstall, I'd like to have a downloadable image which is easy pxebootable > and just drops into a shell. Ideally it does a dhcp request, if successful > starts a sshd and if not has video and serial output enabled. > > Did anybody actually stripped down a FreeBSD to do just that? > I read my way through the pxeboot articles and the handbook section of > netbooting and everything... however, it really sounds a bit overcomplicated > to do a "make release" and stuff. No offense ment, obviously :) Not that I've done it (yet), but NanoBSD looks like it would handle the stripping-down part and setting up the md devices pretty painlessly. The only part that remains would be to customize the booting process, which shouldn't be terrible. It's possible to take the livefs memstick image and remove some of the parts that are not needed. But you'll also have to modify the mfsroot image to add /etc, /bin, /sbin, /usr, and by the time that's all done, NanoBSD is likely the easier path. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 20:14:05 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F0B81065674 for ; Mon, 12 Jul 2010 20:14:05 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 14FFD8FC24 for ; Mon, 12 Jul 2010 20:14:04 +0000 (UTC) Received: from mail.timeinc.net (timeinc2-lm25.websys.aol.com [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o6CKE4Ts005292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 16:14:04 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o6CKE4or016268; Mon, 12 Jul 2010 16:14:04 -0400 Message-ID: <4C3B778C.9040109@aldan.algebra.com> Date: Mon, 12 Jul 2010 16:14:04 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: blanka x Subject: panic: __lockmgr_args: recursing on non recursive lockmgr ntnode @ (null):0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 20:14:05 -0000 A laptop I'm helping configure (remotely) just crashed under me... Upon reboot I found the following in the messages file (quite amazed, that the message got there, actually): Jul 12 22:06:01 s syslogd: kernel boot file is /boot/kernel/kernel Jul 12 22:06:01 s kernel: panic: __lockmgr_args: recursing on non recursive lockmgr *ntnode* @ (null):0 Jul 12 22:06:01 s kernel: Jul 12 22:06:01 s kernel: cpuid = 0 Jul 12 22:06:01 s kernel: Uptime: 6h10m53s Jul 12 22:06:01 s kernel: Cannot dump. Device not defined or unavailable. Jul 12 22:06:01 s kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jul 12 22:06:01 s kernel: Rebooting... Jul 12 22:06:01 s kernel: cpu_reset: Stopping other CPUs The system just finished installing a new port of OpenOffice and cleaning up WRKSRC afterwards (a huge collection of files), and was running /etc/periodic/weekly/310.locate explicitly, when the crash happened. Is this something, that's already solved and I just need to upgrade? The current kernel is: FreeBSD 8.1-PRERELEASE #0: Wed Jul 7 19:04:57 CEST 2010, i386. 4 CPUs (Full dmesg.boot available upon request.) Does the "ntnode" above point to the NTFS filesystems on this laptop? The laptop uses Windows' swap-file as its own swap (via md(4)) and uses Windows' TrueType fonts as well... Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 20:35:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC80D106566C for ; Mon, 12 Jul 2010 20:35:59 +0000 (UTC) (envelope-from batrick@batbytes.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B46518FC1E for ; Mon, 12 Jul 2010 20:35:59 +0000 (UTC) Received: by iwn35 with SMTP id 35so6243386iwn.13 for ; Mon, 12 Jul 2010 13:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.8.212 with SMTP id j20mr2420481icj.20.1278965559362; Mon, 12 Jul 2010 13:12:39 -0700 (PDT) Received: by 10.231.172.20 with HTTP; Mon, 12 Jul 2010 13:12:39 -0700 (PDT) Date: Mon, 12 Jul 2010 16:12:39 -0400 Message-ID: From: Patrick Donnelly To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: 8.0-Release Writes Go Beyond HD Capacity X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 20:35:59 -0000 Hi List, I brought a question to the freebsd-questions list [1] about write problem I was experiencing when writing directly to a hard drive device. The workflow is: fd = open("/dev/ad1", O_WRONLY|O_SYNC); write(fd, buf, BUFSIZ); /* loop until drive full error (write(...) == -1) */ close(fd); On my box with 8.0 Release, the write loop will constantly return 0 (nothing written) after I reach the end of the hard drive capacity. After discussion in the earlier linked thread [1] and a look at the specification [2], I think this may be a bug in the implementation. Shouldn't write return an error code? [1] http://lists.freebsd.org/pipermail/freebsd-questions/2010-July/218628.html [2] http://www.opengroup.org/onlinepubs/000095399/functions/write.html -- - Patrick Donnelly From owner-freebsd-stable@FreeBSD.ORG Mon Jul 12 23:23:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC97B1065672 for ; Mon, 12 Jul 2010 23:23:51 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8063F8FC0A for ; Mon, 12 Jul 2010 23:23:51 +0000 (UTC) Received: by iwn35 with SMTP id 35so6432617iwn.13 for ; Mon, 12 Jul 2010 16:23:51 -0700 (PDT) Received: by 10.231.161.80 with SMTP id q16mr13949031ibx.142.1278975685888; Mon, 12 Jul 2010 16:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.148.9 with HTTP; Mon, 12 Jul 2010 16:01:02 -0700 (PDT) In-Reply-To: <4C397668.6060904@infracaninophile.co.uk> References: <4C3934D9.3030501@langille.org> <4C397668.6060904@infracaninophile.co.uk> From: Eitan Adler Date: Mon, 12 Jul 2010 19:01:02 -0400 Message-ID: To: Matthew Seaman Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Authentication tried for XXX with correct key but not from a permitted host X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jul 2010 23:23:51 -0000 > Maybe it's a bug, but one that has fortuitously useful effects. Bugs are undocumented features. -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 09:16:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62EDE1065676 for ; Tue, 13 Jul 2010 09:16:05 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABD78FC08 for ; Tue, 13 Jul 2010 09:16:04 +0000 (UTC) Received: from vhoffman.lon.namesco.net (238.68-246-213.ippool.namesco.net [213.246.68.238]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id o6D9G1SN075535 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2010 10:16:02 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4C3C2ED0.3060802@unsane.co.uk> Date: Tue, 13 Jul 2010 10:16:00 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> <4C3618B9.8010202@aldan.algebra.com> <4C3B5D55.5090107@kernel32.de> In-Reply-To: <4C3B5D55.5090107@kernel32.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: net-booting the install disks (Re: 8.x grudges) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 09:16:05 -0000 On 12/07/2010 19:22, Marian Hettwer wrote: > Hi Adam, > > Am 12.07.10 19:11, schrieb Adam Vande More: >> >> Automated installations have existed on FreeBSD for a long time. You >> can do >> this either via netboot or CD based media. Also rolling your own >> FreeBSD >> media with custom changes is trivial compared the linux distro's I'm >> familar >> with. I haven't used kickstart but I will say the FreeBSD method is >> easier >> to work with than the Debian FIA method. Plus there are many >> post-install >> configuration utilites like puppet to further automate stuff. >> > I actually like the principle of FAI configspace that much, that a > colleague of mine and myself ported the underlying FAI to OpenBSD. > I tend to say, that configuring a server with FAI is way easier than > with puppet. > > I'd love to pxeboot a minimal freebsd with a ramdisk and a base set of > utilities to use FAI there too, however, my last attempts of doing > that with FreeBSD failed. > > But your opinion may vary, of course :) > >> This page is pretty well out of date, but the concepts remain the >> same. You >> can look at the work MFSBSD has done if you interested and there are >> more up >> to date howto floating around the www. >> > humm... what is MFSBSD? http://mfsbsd.vx.sk/ (maybe also see http://www.freebsd.org/doc/en/articles/remote-install/preparation.html) Basicly a set of scripts to build a small customised bsd that can run from a memory backed disk (tftp bootable i believe.) I still haven't had an excuse to try it properly but it looks pretty cool. Vince > > Cheers, > Marian > _______________________________________________ > 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 Jul 13 10:18:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7EC5106567A for ; Tue, 13 Jul 2010 10:18:10 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD328FC2F for ; Tue, 13 Jul 2010 10:18:10 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 09D3E1FFC34; Tue, 13 Jul 2010 10:18:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 88A3784550; Tue, 13 Jul 2010 12:15:54 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Mikhail T." References: <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <20100711.140344.239525524663396359.imp@bsdimp.com> <4C3B5594.5050607@aldan.algebra.com> Date: Tue, 13 Jul 2010 12:15:54 +0200 In-Reply-To: <4C3B5594.5050607@aldan.algebra.com> (Mikhail T.'s message of "Mon, 12 Jul 2010 13:49:08 -0400") Message-ID: <86lj9foffp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: sshd would not start (another 8.x grudge) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 10:18:10 -0000 "Mikhail T." writes: > cipher_encrypt: bad plaintext length 553 I am 99% certain this is a configuration issue. Please ask on the OpenSSH mailing lists or comp.security.ssh. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 14:02:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 990DE1065675; Tue, 13 Jul 2010 14:02:07 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 48BE68FC1B; Tue, 13 Jul 2010 14:02:07 +0000 (UTC) Received: from [77.109.131.203] (port=65479 helo=ch4buk-en0.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OYg3i-000G1B-3B; Tue, 13 Jul 2010 16:02:06 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: Date: Tue, 13 Jul 2010 16:02:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 14:02:07 -0000 On 12.07.2010, at 14:41, Markus Gebert wrote: > In the meantime, I'll try harder to reproduce the MCE on current... Well, I can't. It's been running the test load for almost 24 hours = without any sign of problems. The kernel config is the same as under = 8.1, GENERIC+ipfw (USB not excluded!). Our 8.1 test config includes the = CURRENT debug options, so as far as I can tell we should be testing = under the same conditions. Yet I don't know wether CURRENT includes any = additional debug magic I'm not aware of, which could slow the system = down an prevent the issue from occurring. Another difference to our primary 8.1 test machine is that we didn't use = ZFS on CURRENT. But since we are able to crash 8.1 with UFS, I don't = think this will matter. Still I'm going to try to get together a CURRENT = ZFS setup on the second machine. But, so far, bottom line seems to be: - no problems on 6.x, 7.x and CURRENT - no problems on Linux (that was only a short test though) - crash within a minute on 8.1 (with ehci in the kernel) Unfortunately, I have not been able to get anything useful out the svn = commit logs, which could explain this. Maybe someone else has an idea = what could have changed between 7 and 8 to break it, and again between 8 = and CURRENT to magically fix it again. Markus= From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 17:01:37 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8CF1065674 for ; Tue, 13 Jul 2010 17:01:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id AD62F8FC0A for ; Tue, 13 Jul 2010 17:01:36 +0000 (UTC) Received: from park.js.berklix.net (p549A6272.dip.t-dialin.net [84.154.98.114]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6DH1YXS030400 for ; Tue, 13 Jul 2010 17:01:34 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6DH1O8b006085 for ; Tue, 13 Jul 2010 19:01:24 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6DH1JxF009213 for ; Tue, 13 Jul 2010 19:01:24 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007131701.o6DH1JxF009213@fire.js.berklix.net> To: stable@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Tue, 13 Jul 2010 19:01:19 +0200 Sender: jhs@berklix.com Cc: Subject: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 17:01:37 -0000 Hi stable@, with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso sysinstall failed to correctly repartition a previously partitioned disc. fdisk however correctly wrote the new slices to the disk, but sysinstall did not pick up the new slices, so we had to enter fixit & overwrite beginning of disk with dd if=/dev/zero of=/dev/ad0 bs=1024 count=100 PS sysinstall saw /dev/ad0 & /dev/ad0a Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 18:01:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A51C71065672 for ; Tue, 13 Jul 2010 18:01:43 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 671808FC19 for ; Tue, 13 Jul 2010 18:01:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c47:e921:2c91:2d2b] (unknown [IPv6:2001:7b8:3a7:0:c47:e921:2c91:2d2b]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 319325C59; Tue, 13 Jul 2010 20:01:42 +0200 (CEST) Message-ID: <4C3CAA05.6080800@andric.com> Date: Tue, 13 Jul 2010 20:01:41 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100710 Lanikai/3.1.1pre MIME-Version: 1.0 To: "Julian H. Stacey" References: <201007131701.o6DH1JxF009213@fire.js.berklix.net> In-Reply-To: <201007131701.o6DH1JxF009213@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 18:01:43 -0000 On 2010-07-13 19:01, Julian H. Stacey wrote: > with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso > sysinstall failed to correctly repartition a previously partitioned disc. > fdisk however correctly wrote the new slices to the disk, > but sysinstall did not pick up the new slices, so we had to enter fixit > & overwrite beginning of disk with > dd if=/dev/zero of=/dev/ad0 bs=1024 count=100 > PS sysinstall saw /dev/ad0 & /dev/ad0a Were those partitions 'dangerously dedicated' and created by an older (pre-8.x) sysinstall? From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 19:19:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28711065670 for ; Tue, 13 Jul 2010 19:19:14 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from stith.flb.omnilan.net (stith.flb.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 462D88FC0A for ; Tue, 13 Jul 2010 19:19:13 +0000 (UTC) Received: from titan.lan.flb.omnilan.net (titan.lan.flb.omnilan.net [172.21.1.150]) (authenticated bits=0) by stith.flb.omnilan.net (8.13.8/8.13.8) with ESMTP id o6DJIwfp038958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 21:18:58 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4C3CBC1E.9030106@omnilan.de> Date: Tue, 13 Jul 2010 21:18:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Jack Vogel References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A2474E38D16E5C401F067CE" Cc: Brandon Gooch , "Brian A. Seklecki" , freebsd-stable , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 19:19:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A2474E38D16E5C401F067CE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jack Vogel schrieb am 18.06.2010 20:01 (localtime): > Yes, the commits today are slated to get into 8.1, at least that's my > understanding. >=20 > Jack Hello, is this still on the to-merge-before-8.1-RELEASE list? Thanks, -Harry =2E.. >>> Adding Jack Vogel of Intel to the CC list, as he's been working on em= (4) >>> as of late. >> Brian, I have no idea if this will help or not, but... >> >> Jack just committed bits to the Intel drivers (em(4) ixgbe(4)), will >> you have a chance to test a new build? I'm trying to find an unused >> system ATM to test on myself, but it may take me a day or to. >> >> BTW, it appears Jack may be trying to get the fixes (and features) >> into 8.1-RELEASE, let's hope that it happens :) >> >> -Brandon --------------enig4A2474E38D16E5C401F067CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkw8vB4ACgkQLDqVQ9VXb8gPjwCfcWyC50w6Bpy774SfrN6F6K4t W8MAnAmG2P5GZpXCu99f7DJxpWP8HW9w =xnAb -----END PGP SIGNATURE----- --------------enig4A2474E38D16E5C401F067CE-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 20:28:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5861065673 for ; Tue, 13 Jul 2010 20:28:39 +0000 (UTC) (envelope-from henrik@kaarposoft.dk) Received: from pqueuea.post.tele.dk (pqueuea.post.tele.dk [193.162.153.9]) by mx1.freebsd.org (Postfix) with ESMTP id 24EC68FC17 for ; Tue, 13 Jul 2010 20:28:38 +0000 (UTC) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by pqueuea.post.tele.dk (Postfix) with ESMTP id A5802DBCCD for ; Tue, 13 Jul 2010 22:10:28 +0200 (CEST) Received: from [192.168.99.150] (x1-6-00-00-24-cc-93-b4.k874.webspeed.dk [87.52.11.120]) by pfepb.post.tele.dk (Postfix) with ESMTP id A7A1BF8401F; Tue, 13 Jul 2010 22:10:25 +0200 (CEST) Message-ID: <4C3CC831.7040005@kaarposoft.dk> Date: Tue, 13 Jul 2010 22:10:25 +0200 From: Henrik /KaarPoSoft User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mamalos@eng.auth.gr Subject: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 20:28:39 -0000 Dear All, I have a problem: ldapsearch results in "Segmentation fault" under openldap-2.4.23 with cyrus-sasl-2.1.23. A thread for similar issues was started by George Mamalakis back in february: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html but I find no solution / conclusion from this thread, hence I post here... I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with freebsd-update, and ports updated with "portsnap fetch update". Kerberos installed from packages, configured, and seems to work OK. It seems that there are no package for openldap server with GSSAPI/SASL, so I have build and installed cyrus-sasl2, openldap24-server (with sasl configured) and openldap24-sasl-client from ports. Those are the port versions: # $FreeBSD: ports/security/cyrus-sasl2/Makefile,v 1.141 2009/08/02 19:35:25 mezz Exp $ # $FreeBSD: ports/net/openldap24-server/Makefile,v 1.181 2010/07/01 19:04:42 delphij Exp $ According to the distinfo files, those are the upstream versions: openldap-2.4.23 cyrus-sasl-2.1.23 which, as far as I can see, are the latest stable. Trying LDAP I get a segfault: $ ldapsearch SASL/GSSAPI authentication started Segmentation fault (core dumped) Here is the backtrace from gdb: #0 0x283225c7 in free () from /lib/libc.so.7 #1 0x28654b42 in gss_release_buffer () from /usr/lib/libgssapi.so.10 #2 0x28654512 in gss_release_name () from /usr/lib/libgssapi.so.10 #3 0x28650e69 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 #4 0x28648a0f in gssapi_client_mech_step () from /usr/local/lib/sasl2/libgssapiv2.so.2 #5 0x280ef4b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 #6 0x28440200 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0xbfbfe208 in ?? () #10 0xbfbfe1f4 in ?? () #11 0xbfbfe204 in ?? () #12 0x28446860 in ?? () #13 0x280ef3fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2 #14 0xbfbfe148 in ?? () #15 0x280f0135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2 #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0xbfbfe208 in ?? () #19 0xbfbfe1f4 in ?? () #20 0xbfbfe204 in ?? () #21 0x72408f2d in ?? () #22 0x283b1ad8 in ?? () from /lib/libc.so.7 #23 0x00000000 in ?? () #24 0x283b1730 in __stderrp () from /lib/libc.so.7 #25 0xbfbfe118 in ?? () #26 0x28392114 in vfprintf () from /lib/libc.so.7 Previous frame inner to this frame (corrupt stack?) I tried "valgrind ldapsearch" which produces thousands of issues, ending with: ==59479== Invalid free() / delete / delete[] ==59479== at 0x59B95: free (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==59479== by 0x911B41: gss_release_buffer (in /usr/lib/libgssapi.so.10) ==59479== by 0x911511: ??? (in /usr/lib/libgssapi.so.10) ==59479== by 0x90DE68: gss_init_sec_context (in /usr/lib/libgssapi.so.10) ==59479== by 0x905A0E: gssapi_client_mech_step (in /usr/local/lib/sasl2/libgssapiv2.so.2) ==59479== by 0xAF4B0: sasl_client_step (in /usr/local/lib/libsasl2.so.2) ==59479== by 0xB0134: sasl_client_start (in /usr/local/lib/libsasl2.so.2) ==59479== by 0x70C46: ldap_int_sasl_bind (in /usr/local/lib/libldap-2.4.so.7) ==59479== by 0x73935: ldap_sasl_interactive_bind_s (in /usr/local/lib/libldap-2.4.so.7) ==59479== by 0x80505E6: ??? (in /usr/local/bin/ldapsearch) ==59479== by 0x804D695: ??? (in /usr/local/bin/ldapsearch) ==59479== by 0x804A7D8: ??? (in /usr/local/bin/ldapsearch) ==59479== Address 0x4e2c0 is not stack'd, malloc'd or (recently) free'd ==59479== ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2529638944 for mech unknown) /var/log/messages has: slapd[1146]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) The first message is from the LDAP server. Even if it has some problem, it should not lead the client to segfault. Any comments, hints or suggestions would be most appreciated! /Henrik From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 21:07:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59ADC106566B for ; Tue, 13 Jul 2010 21:07:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0388FC0C for ; Tue, 13 Jul 2010 21:07:31 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta07.emeryville.ca.mail.comcast.net with comcast id hQyp1e0020x6nqcA7Z7XBg; Tue, 13 Jul 2010 21:07:31 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta12.emeryville.ca.mail.comcast.net with comcast id hZ7W1e0083LrwQ28YZ7Wgq; Tue, 13 Jul 2010 21:07:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 08C239B425; Tue, 13 Jul 2010 14:07:30 -0700 (PDT) Date: Tue, 13 Jul 2010 14:07:30 -0700 From: Jeremy Chadwick To: Henrik /KaarPoSoft Message-ID: <20100713210729.GA11943@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3CC831.7040005@kaarposoft.dk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mamalos@eng.auth.gr, freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 21:07:32 -0000 On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: > Dear All, > > I have a problem: ldapsearch results in "Segmentation fault" under > openldap-2.4.23 with cyrus-sasl-2.1.23. > > A thread for similar issues was started by George Mamalakis back in > february: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html > but I find no solution / conclusion from this thread, hence I post here... > > I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with > freebsd-update, and ports updated with "portsnap fetch update". > > Kerberos installed from packages, configured, and seems to work OK. > > It seems that there are no package for openldap server with > GSSAPI/SASL, so I have build and installed cyrus-sasl2, > openldap24-server (with sasl configured) and openldap24-sasl-client > from ports. > > Those are the port versions: > # $FreeBSD: ports/security/cyrus-sasl2/Makefile,v 1.141 2009/08/02 > 19:35:25 mezz Exp $ > # $FreeBSD: ports/net/openldap24-server/Makefile,v 1.181 2010/07/01 > 19:04:42 delphij Exp $ > > According to the distinfo files, those are the upstream versions: > openldap-2.4.23 > cyrus-sasl-2.1.23 > which, as far as I can see, are the latest stable. > > Trying LDAP I get a segfault: > > $ ldapsearch > SASL/GSSAPI authentication started > Segmentation fault (core dumped) I know absolutely nothing about GSSAPI and have very little experience with LDAP. But I'll take a shot at this: > Here is the backtrace from gdb: > > #0 0x283225c7 in free () from /lib/libc.so.7 > #1 0x28654b42 in gss_release_buffer () from /usr/lib/libgssapi.so.10 > #2 0x28654512 in gss_release_name () from /usr/lib/libgssapi.so.10 > #3 0x28650e69 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 > #4 0x28648a0f in gssapi_client_mech_step () from > /usr/local/lib/sasl2/libgssapiv2.so.2 > #5 0x280ef4b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 The problem looks like it may be that gss_release_buffer() is passing free() an invalid pointer (which may be coming from other functions up the stack). Without debugging symbols enabled this is a bit difficult to track down. Since free() is in the call stack, I would say buffer->value contains a pointer that is incorrect (e.g. out of process addressing scope). It could also be that buffer itself points to something invalid. > /var/log/messages has: > slapd[1146]: OTP unavailable because can't read/write key database > /etc/opiekeys: Permission denied > kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) > > The first message is from the LDAP server. Even if it has some > problem, it should not lead the client to segfault. I agree. If I was to build a test box from scratch, can you tell me how to set up all the necessary software/etc. to mimic your environment so that I could try to reproduce this? Reviewing the source isn't enough, I'd have to actually build a debug version of libgssapi to track it down. Alternatively I can try to step you through how to debug this using gdb, but again, lack of debugging symbols makes this annoying. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 21:10:24 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC69106566B for ; Tue, 13 Jul 2010 21:10:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 069568FC0A for ; Tue, 13 Jul 2010 21:10:23 +0000 (UTC) Received: from park.js.berklix.net (p549A2EEF.dip.t-dialin.net [84.154.46.239]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6DL9eaK042357; Tue, 13 Jul 2010 21:09:41 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6DL9W11007211; Tue, 13 Jul 2010 23:09:32 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6DL9Nb2011189; Tue, 13 Jul 2010 23:09:28 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007132109.o6DL9Nb2011189@fire.js.berklix.net> To: Dimitry Andric From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 13 Jul 2010 20:01:41 +0200." <4C3CAA05.6080800@andric.com> Date: Tue, 13 Jul 2010 23:09:23 +0200 Sender: jhs@berklix.com Cc: stable@freebsd.org Subject: Re: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 21:10:24 -0000 Hi, Reference: > From: Dimitry Andric > Date: Tue, 13 Jul 2010 20:01:41 +0200 > Message-id: <4C3CAA05.6080800@andric.com> Dimitry Andric wrote: > On 2010-07-13 19:01, Julian H. Stacey wrote: > > with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso > > sysinstall failed to correctly repartition a previously partitioned disc. > > fdisk however correctly wrote the new slices to the disk, > > but sysinstall did not pick up the new slices, so we had to enter fixit > > & overwrite beginning of disk with > > dd if=/dev/zero of=/dev/ad0 bs=1024 count=100 > > PS sysinstall saw /dev/ad0 & /dev/ad0a > > Were those partitions 'dangerously dedicated' Yes probably, I can't be certain though, as recent FreeBSD fudges /aliases ad0s1a to ad0a if s1 is active fdisk slice. > and created by an older > (pre-8.x) sysinstall? Yes definately. Most Probably on my 8.0-rel i386 laptop Definately not on the laptop I was trying with 8.1-RC2. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 13 21:26:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB9E106564A for ; Tue, 13 Jul 2010 21:26:20 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id F10B88FC16 for ; Tue, 13 Jul 2010 21:26:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c47:e921:2c91:2d2b] (unknown [IPv6:2001:7b8:3a7:0:c47:e921:2c91:2d2b]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DE0065C59; Tue, 13 Jul 2010 23:26:18 +0200 (CEST) Message-ID: <4C3CD9FA.5090801@andric.com> Date: Tue, 13 Jul 2010 23:26:18 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100710 Lanikai/3.1.1pre MIME-Version: 1.0 To: "Julian H. Stacey" References: <201007132109.o6DL9Nb2011189@fire.js.berklix.net> In-Reply-To: <201007132109.o6DL9Nb2011189@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2010 21:26:20 -0000 On 2010-07-13 23:09, Julian H. Stacey wrote: >> Were those partitions 'dangerously dedicated' > > Yes probably, I can't be certain though, as recent FreeBSD fudges /aliases > ad0s1a to ad0a if s1 is active fdisk slice. IIRC, in FreeBSD before 8 you got both ad0s1a and ad0a in /dev, when you had DD partitions, but since GEOM_BSD was replaced by GEOM_PART_BSD this is no longer the case. As far as I have tried out, it is no longer possible to use sysinstall to actually install on a DD partition, neither with 8.1 nor with -current. Sysinstall simply does not allow you to directly label a 'raw' disk, you must make an MBR partition first. I usually just start a fixit shell from the DVD, run bsdlabel directly on the target device, newfs it, and unpack the distributions myself... > Yes definately. Most Probably on my 8.0-rel i386 laptop > Definately not on the laptop I was trying with 8.1-RC2. Did that latter laptop also show the same problem? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 00:05:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1C7106566C for ; Wed, 14 Jul 2010 00:05:53 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3718FC19 for ; Wed, 14 Jul 2010 00:05:52 +0000 (UTC) Received: from park.js.berklix.net (p549A2EEF.dip.t-dialin.net [84.154.46.239]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o6E05MGX048713; Wed, 14 Jul 2010 00:05:27 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o6E05FCs007869; Wed, 14 Jul 2010 02:05:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o6E055fB013517; Wed, 14 Jul 2010 02:05:15 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201007140005.o6E055fB013517@fire.js.berklix.net> To: Dimitry Andric From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 13 Jul 2010 23:26:18 +0200." <4C3CD9FA.5090801@andric.com> Date: Wed, 14 Jul 2010 02:05:05 +0200 Sender: jhs@berklix.com Cc: stable@freebsd.org Subject: Re: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 00:05:53 -0000 Dimitry Andric wrote: > On 2010-07-13 23:09, Julian H. Stacey wrote: > >> Were those partitions 'dangerously dedicated' > > > > Yes probably, I can't be certain though, as recent FreeBSD fudges /aliases > > ad0s1a to ad0a if s1 is active fdisk slice. > > IIRC, in FreeBSD before 8 you got both ad0s1a and ad0a in /dev, when you > had DD partitions, but since GEOM_BSD was replaced by GEOM_PART_BSD this > is no longer the case. OK, I havent read up on GEOM_PART_BSD beyond I think noticing config inserts it in kernel, without needing to be in config file. > As far as I have tried out, it is no longer possible to use sysinstall > to actually install on a DD partition, neither with 8.1 nor with > -current. Sysinstall simply does not allow you to directly label a > 'raw' disk, you must make an MBR partition first. > > I usually just start a fixit shell from the DVD, run bsdlabel > directly on the target device, newfs it, and unpack the distributions > myself... Yes, sounds reasonable, what I'd do for an external, (but as this disk is for laptop internal, I'm happy to use fdisk to give me a 2nd rescue boot). > > Yes definately. Most Probably on my 8.0-rel i386 laptop > > Definately not on the laptop I was trying with 8.1-RC2. > > Did that latter laptop also show the same problem? No , my Toshiba Satellite S5100-603 running i386 8.0-rel had no problem labelling (via external USB enclosure) discs inc the disk I then Installed inside the Novatech today to install with 8.1-RC2. What was preventing FreeBSD-8.1-RC2 install on the Novatech Laptop was a BIOS boot sector protect mechanism which seemed strangely labelled: The BIOS ("Insyde Software SCU") had option "Security -> Hard Disk Boot Sector" with 2 states available: not ticked, or underscore. We had previously left it as Underscore, wrongly assuming that meant no boot sector protection. it actually means silently discard boot sector changes I think. Now it's ticked, (which we had wrongl assumed meant boot sector protect) it allowed install & boot from disc of FreeBSD (after complaint on first boot (but not on subsequent boots) of boot sector content change. Thanks for your help :-) Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text. Not HTML, Not quoted-printable, Not Base64. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 05:31:19 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94EE91065672 for ; Wed, 14 Jul 2010 05:31:19 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8D28FC08 for ; Wed, 14 Jul 2010 05:31:19 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward5.mail.yandex.net (Yandex) with ESMTP id 53F83B60002; Wed, 14 Jul 2010 09:31:17 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1279085477; bh=RpUr8Y4uJc8XG/B3e1AO7+fkQM+D0V9IdUDOBQgcYbc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=kSJIDjFoDFkMtb4XqYy/3SGIiyLEKiNpuEdw9aEOjx2nrvBaV1gQ+alYLSBf4AArx o99GIck+kNiS+jCTKhCmahHHRGmuiSNv5/5DkGE4dIsa6ZJoyrrKCUqldHNccSIqi5 a2nBBH9p8GXFNnnF1WwHx2rJbsyCJzWUeLoMQ3aQ= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp2.mail.yandex.net (Yandex) with ESMTPSA id 1211F5280A3; Wed, 14 Jul 2010 09:31:17 +0400 (MSD) Message-ID: <4C3D4BA0.4020502@yandex.ru> Date: Wed, 14 Jul 2010 09:31:12 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Dimitry Andric References: <201007132109.o6DL9Nb2011189@fire.js.berklix.net> <4C3CD9FA.5090801@andric.com> In-Reply-To: <4C3CD9FA.5090801@andric.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig895B05137A82E0D28AAF8897" X-Yandex-TimeMark: 1279085477 X-Yandex-Spam: 1 X-Yandex-Front: smtp2.mail.yandex.net Cc: "Julian H. Stacey" , stable@freebsd.org Subject: Re: sysistall bsdlabel failure with amd64 FreeBSD-8.1-RC2-amd64-dvd1.iso X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 05:31:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig895B05137A82E0D28AAF8897 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 14.07.2010 1:26, Dimitry Andric wrote: > I usually just start a fixit shell from the DVD, run bsdlabel > directly on the target device, newfs it, and unpack the distributions > myself... I think better suggestion will be use gpart(8) instead of fdisk/bsdlabel.= --=20 WBR, Andrey V. Elsukov --------------enig895B05137A82E0D28AAF8897 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJMPUukAAoJEAHF6gQQyKF6rFQH/jtODOZhnNYtlURKNjBFVdcj kGTWxEbbGyU3at++aW3HkpWXUKBHMu454uMemFZORpa0FZN+rwdiZEh9l4tOnGzy LJhXyn2s9NeyhbpzbgRj3ch7ApwgqrOrbgnyPNKO8mGeDQdkjlFWU0N2qlrnYeO8 ISMhfQDuyBAYL+EpCbWGynFxRL7fzOW5uzyOgqVoyc1z0EFIXsrRp2ci7MdISGKg Uia3oCGMbLGB38h9Sb6DHIO7sXccnEO4MHOMefE6WRoEskmVc/zVVRk8JnsG2Wl2 p8S+wztV5e/N3dw2XvVgvC/h5BDSwO/BtU2k7sBtOZLUt4GAe8/m66O1u/W0Xbw= =Ey8M -----END PGP SIGNATURE----- --------------enig895B05137A82E0D28AAF8897-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 08:42:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E89D106567A for ; Wed, 14 Jul 2010 08:42:37 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id D23008FC1F for ; Wed, 14 Jul 2010 08:42:36 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id AB1B21CC69; Wed, 14 Jul 2010 11:42:35 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net AB1B21CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279096955; bh=G8/74z/ATjRDKdlFm7e6JkXRTo4SwhzqonYn19uu5Tw=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tNs1C5PDu+UYvxB0npGdc7NUGGaEvalwU9kMYXeGCC347jtugs5H6ZIeSnmgI+x9R n86t9kQLm5ed/kML8fkQ2AJ1haVyvLF3zRywqmbKIZrUkj8jTYMxXV7bpQ/1G7RKFs VfPwJNE4PSrxjDDeXTzQIMj3m402/C+OxfWlqF5E= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6V2IWLz1CjM0; Wed, 14 Jul 2010 11:42:32 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 540751CC67; Wed, 14 Jul 2010 11:42:32 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 540751CC67 Message-ID: <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" , "Henrik /KaarPoSoft" References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> In-Reply-To: <20100713210729.GA11943@icarus.home.lan> Date: Wed, 14 Jul 2010 11:42:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@freebsd.org, mamalos@eng.auth.gr Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 08:42:37 -0000 >> I have a problem: ldapsearch results in "Segmentation fault" under >> openldap-2.4.23 with cyrus-sasl-2.1.23 >> >> A thread for similar issues was started by George Mamalakis back in >> february: >> = http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.ht= ml >> but I find no solution / conclusion from this thread, hence I post=20 >> here... >> >> I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with >> freebsd-update, and ports updated with "portsnap fetch update". >> >> Kerberos installed from packages, configured, and seems to work OK. I had similar issue with 8-RELEASE and cyrus-sasl2 with=20 cyrus-saslauthd linked against system kerberos. (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat=20 Jun 12 00:39:22 EEST 2010=20 root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) The problem manifested itself with pretty much the same backtrace when=20 using cyradm tool for administering cyrus mailboxes and due time=20 constraints I solved my issue by removing all the gssapi plugin libs=20 from /usr/local/lib/sasl2, so my solution isn't really applicable in=20 your case. my /etc/hosts file for the server in question contains only localhost=20 entry + entry for one IP so George's solution didnt help with my=20 problem. >> /var/log/messages has: >> slapd[1146]: OTP unavailable because can't read/write key database >> /etc/opiekeys: Permission denied >> kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core=20 >> dumped) >> >> The first message is from the LDAP server. Even if it has some >> problem, it should not lead the client to segfault. > > I agree. > > If I was to build a test box from scratch, can you tell me how to=20 > set up > all the necessary software/etc. to mimic your environment so that I > could try to reproduce this? Reviewing the source isn't enough, I'd > have to actually build a debug version of libgssapi to track it=20 > down. > Alternatively I can try to step you through how to debug this using=20 > gdb, > but again, lack of debugging symbols makes this annoying. I'd say that based on present evidence there is something broken in=20 gssapi/sasl interaction, but due my need of getting the server=20 functional quickly I didn't dig much further in the issue myself,=20 although I really don't know how to enable generating debugging=20 symbols for ports either - Which was another reason for not digging=20 deeper in the problem. I wonder if using dovecot-sasl would work with ldap and if it has the=20 same issue as cyrus-sasl - athough it doesn't seem to be available as=20 separate port. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 08:57:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C555106566C for ; Wed, 14 Jul 2010 08:57:08 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id C3E9D8FC08 for ; Wed, 14 Jul 2010 08:57:07 +0000 (UTC) Received: from [155.207.33.29] (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o6E8v5tX073773 for ; Wed, 14 Jul 2010 11:57:06 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <4C3D7BD9.5020503@eng.auth.gr> Date: Wed, 14 Jul 2010 11:56:57 +0300 From: George Mamalakis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> In-Reply-To: <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 08:57:08 -0000 On 14/7/2010 11:42 πμ, Reko Turja wrote: >>> I have a problem: ldapsearch results in "Segmentation fault" under >>> openldap-2.4.23 with cyrus-sasl-2.1.23 >>> >>> A thread for similar issues was started by George Mamalakis back in >>> february: >>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html >>> >>> but I find no solution / conclusion from this thread, hence I post >>> here... >>> >>> I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with >>> freebsd-update, and ports updated with "portsnap fetch update". >>> >>> Kerberos installed from packages, configured, and seems to work OK. > > I had similar issue with 8-RELEASE and cyrus-sasl2 with > cyrus-saslauthd linked against system kerberos. > > (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat > Jun 12 00:39:22 EEST 2010 root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) > > The problem manifested itself with pretty much the same backtrace when > using cyradm tool for administering cyrus mailboxes and due time > constraints I solved my issue by removing all the gssapi plugin libs > from /usr/local/lib/sasl2, so my solution isn't really applicable in > your case. > > my /etc/hosts file for the server in question contains only localhost > entry + entry for one IP so George's solution didnt help with my problem. > >>> /var/log/messages has: >>> slapd[1146]: OTP unavailable because can't read/write key database >>> /etc/opiekeys: Permission denied >>> kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core >>> dumped) >>> >>> The first message is from the LDAP server. Even if it has some >>> problem, it should not lead the client to segfault. >> >> I agree. >> >> If I was to build a test box from scratch, can you tell me how to set up >> all the necessary software/etc. to mimic your environment so that I >> could try to reproduce this? Reviewing the source isn't enough, I'd >> have to actually build a debug version of libgssapi to track it down. > >> Alternatively I can try to step you through how to debug this using gdb, >> but again, lack of debugging symbols makes this annoying. > > I'd say that based on present evidence there is something broken in > gssapi/sasl interaction, but due my need of getting the server > functional quickly I didn't dig much further in the issue myself, > although I really don't know how to enable generating debugging > symbols for ports either - Which was another reason for not digging > deeper in the problem. > > I wonder if using dovecot-sasl would work with ldap and if it has the > same issue as cyrus-sasl - athough it doesn't seem to be available as > separate port. > > -Reko > _______________________________________________ > 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" > Hello guys, I am glad that somebody brought this issue back, since despite my last email regarding the same issue on 25/02/2010 saying that there must be something wrong with the function gss_release_buffer(void *a, void *b), the issue got forgotten. The problem would not persist in amd64, so I stopped looking it further myself. Whoever wants to see more information on this issue, search the subject field of this list for: openldap client GSSAPI authentication segfaults in fbsd8stable i386 I hope that a remedy to this issue will be yielded this time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 09:32:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E450F1065670 for ; Wed, 14 Jul 2010 09:32:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id CA5F08FC15 for ; Wed, 14 Jul 2010 09:32:10 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta09.emeryville.ca.mail.comcast.net with comcast id hlUy1e0011GXsucA9lYAjU; Wed, 14 Jul 2010 09:32:10 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta07.emeryville.ca.mail.comcast.net with comcast id hlY81e0053LrwQ28UlY8dm; Wed, 14 Jul 2010 09:32:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 356359B425; Wed, 14 Jul 2010 02:32:08 -0700 (PDT) Date: Wed, 14 Jul 2010 02:32:08 -0700 From: Jeremy Chadwick To: George Mamalakis Message-ID: <20100714093208.GA29938@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <4C3D7BD9.5020503@eng.auth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C3D7BD9.5020503@eng.auth.gr> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 09:32:11 -0000 On Wed, Jul 14, 2010 at 11:56:57AM +0300, George Mamalakis wrote: > On 14/7/2010 11:42 πμ, Reko Turja wrote: > >>>I have a problem: ldapsearch results in "Segmentation fault" under > >>>openldap-2.4.23 with cyrus-sasl-2.1.23 > >>> > >>>A thread for similar issues was started by George Mamalakis back in > >>>february: > >>>http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html > >>> > >>>but I find no solution / conclusion from this thread, hence I > >>>post here... > >>> > >>>I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with > >>>freebsd-update, and ports updated with "portsnap fetch update". > >>> > >>>Kerberos installed from packages, configured, and seems to work OK. > > > >I had similar issue with 8-RELEASE and cyrus-sasl2 with > >cyrus-saslauthd linked against system kerberos. > > > >(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: > >Sat Jun 12 00:39:22 EEST 2010 > >root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) > > > >The problem manifested itself with pretty much the same backtrace > >when using cyradm tool for administering cyrus mailboxes and due > >time constraints I solved my issue by removing all the gssapi > >plugin libs from /usr/local/lib/sasl2, so my solution isn't really > >applicable in your case. > > > >my /etc/hosts file for the server in question contains only > >localhost entry + entry for one IP so George's solution didnt help > >with my problem. > > > >>>/var/log/messages has: > >>>slapd[1146]: OTP unavailable because can't read/write key database > >>>/etc/opiekeys: Permission denied > >>>kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 > >>>(core dumped) > >>> > >>>The first message is from the LDAP server. Even if it has some > >>>problem, it should not lead the client to segfault. > >> > >>I agree. > >> > >>If I was to build a test box from scratch, can you tell me how to set up > >>all the necessary software/etc. to mimic your environment so that I > >>could try to reproduce this? Reviewing the source isn't enough, I'd > >>have to actually build a debug version of libgssapi to track it down. > > > >>Alternatively I can try to step you through how to debug this using gdb, > >>but again, lack of debugging symbols makes this annoying. > > > >I'd say that based on present evidence there is something broken > >in gssapi/sasl interaction, but due my need of getting the server > >functional quickly I didn't dig much further in the issue myself, > >although I really don't know how to enable generating debugging > >symbols for ports either - Which was another reason for not > >digging deeper in the problem. > > > >I wonder if using dovecot-sasl would work with ldap and if it has > >the same issue as cyrus-sasl - athough it doesn't seem to be > >available as separate port. > > > >-Reko > > Hello guys, > > I am glad that somebody brought this issue back, since despite my > last email regarding the same issue on 25/02/2010 saying that there > must be something wrong with the function gss_release_buffer(void > *a, void *b), the issue got forgotten. The problem would not persist > in amd64, so I stopped looking it further myself. Whoever wants to > see more information on this issue, search the subject field of this > list for: openldap client GSSAPI authentication segfaults in > fbsd8stable i386 > > I hope that a remedy to this issue will be yielded this time. Like I said -- if someone can step me through setting everything up (configurations, whatever ports/packages need to be installed, etc.) to mimic their setup so that I can reproduce the problem, I'll put in the time to track it down. This would be on a dedicated/freshly installed machine (RELENG_8 running under VMware Workstation) to rule out any other oddities. It's the LDAP + any quirky GSSAPI or Cyrus stuff that I don't have experience with. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 09:38:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EFB31065670 for ; Wed, 14 Jul 2010 09:38:32 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 11EB38FC0C for ; Wed, 14 Jul 2010 09:38:31 +0000 (UTC) Received: from [155.207.33.29] (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o6E9cUQV090803 for ; Wed, 14 Jul 2010 12:38:30 +0300 (EEST) (envelope-from mamalos@eng.auth.gr) Message-ID: <4C3D858E.8060208@eng.auth.gr> Date: Wed, 14 Jul 2010 12:38:22 +0300 From: George Mamalakis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <4C3D7BD9.5020503@eng.auth.gr> <20100714093208.GA29938@icarus.home.lan> In-Reply-To: <20100714093208.GA29938@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 09:38:32 -0000 On 14/7/2010 12:32 μμ, Jeremy Chadwick wrote: > On Wed, Jul 14, 2010 at 11:56:57AM +0300, George Mamalakis wrote: > >> On 14/7/2010 11:42 πμ, Reko Turja wrote: >> >>>>> I have a problem: ldapsearch results in "Segmentation fault" under >>>>> openldap-2.4.23 with cyrus-sasl-2.1.23 >>>>> >>>>> A thread for similar issues was started by George Mamalakis back in >>>>> february: >>>>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html >>>>> >>>>> but I find no solution / conclusion from this thread, hence I >>>>> post here... >>>>> >>>>> I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with >>>>> freebsd-update, and ports updated with "portsnap fetch update". >>>>> >>>>> Kerberos installed from packages, configured, and seems to work OK. >>>>> >>> I had similar issue with 8-RELEASE and cyrus-sasl2 with >>> cyrus-saslauthd linked against system kerberos. >>> >>> (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: >>> Sat Jun 12 00:39:22 EEST 2010 >>> root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) >>> >>> The problem manifested itself with pretty much the same backtrace >>> when using cyradm tool for administering cyrus mailboxes and due >>> time constraints I solved my issue by removing all the gssapi >>> plugin libs from /usr/local/lib/sasl2, so my solution isn't really >>> applicable in your case. >>> >>> my /etc/hosts file for the server in question contains only >>> localhost entry + entry for one IP so George's solution didnt help >>> with my problem. >>> >>> >>>>> /var/log/messages has: >>>>> slapd[1146]: OTP unavailable because can't read/write key database >>>>> /etc/opiekeys: Permission denied >>>>> kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 >>>>> (core dumped) >>>>> >>>>> The first message is from the LDAP server. Even if it has some >>>>> problem, it should not lead the client to segfault. >>>>> >>>> I agree. >>>> >>>> If I was to build a test box from scratch, can you tell me how to set up >>>> all the necessary software/etc. to mimic your environment so that I >>>> could try to reproduce this? Reviewing the source isn't enough, I'd >>>> have to actually build a debug version of libgssapi to track it down. >>>> >>> >>>> Alternatively I can try to step you through how to debug this using gdb, >>>> but again, lack of debugging symbols makes this annoying. >>>> >>> I'd say that based on present evidence there is something broken >>> in gssapi/sasl interaction, but due my need of getting the server >>> functional quickly I didn't dig much further in the issue myself, >>> although I really don't know how to enable generating debugging >>> symbols for ports either - Which was another reason for not >>> digging deeper in the problem. >>> >>> I wonder if using dovecot-sasl would work with ldap and if it has >>> the same issue as cyrus-sasl - athough it doesn't seem to be >>> available as separate port. >>> >>> -Reko >>> >> Hello guys, >> >> I am glad that somebody brought this issue back, since despite my >> last email regarding the same issue on 25/02/2010 saying that there >> must be something wrong with the function gss_release_buffer(void >> *a, void *b), the issue got forgotten. The problem would not persist >> in amd64, so I stopped looking it further myself. Whoever wants to >> see more information on this issue, search the subject field of this >> list for: openldap client GSSAPI authentication segfaults in >> fbsd8stable i386 >> >> I hope that a remedy to this issue will be yielded this time. >> > Like I said -- if someone can step me through setting everything up > (configurations, whatever ports/packages need to be installed, etc.) to > mimic their setup so that I can reproduce the problem, I'll put in the > time to track it down. This would be on a dedicated/freshly installed > machine (RELENG_8 running under VMware Workstation) to rule out any > other oddities. > > It's the LDAP + any quirky GSSAPI or Cyrus stuff that I don't have > experience with. > > Unfortunately I have no time this week. I will be able to look at it and send you a quick howto for openldap/cyrus/heimdal on Saturday. If somebody else is able to do it sooner, it would be great. Please, install it on i386 image, since amd64 didn't seem to have any problems on my installation (at least on February). Thank you for your time and effort. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 14:14:49 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C351065672 for ; Wed, 14 Jul 2010 14:14:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6735A8FC15 for ; Wed, 14 Jul 2010 14:14:49 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6EEEUe8014691; Wed, 14 Jul 2010 16:14:47 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6EEEUx9014690; Wed, 14 Jul 2010 16:14:30 +0200 (CEST) (envelope-from olli) Date: Wed, 14 Jul 2010 16:14:30 +0200 (CEST) Message-Id: <201007141414.o6EEEUx9014690@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Wed, 14 Jul 2010 16:14:47 +0200 (CEST) Cc: Subject: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 14:14:50 -0000 In a machine installed yesterday, 8.1-PRERELEASE doesn't seem to detect the number of CPU packages vs. cores per package correctly: | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 | [...] | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) | Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 | Features=0xbfebfbff | Features2=0x40ce3bd | AMD Features=0x20000800 | AMD Features2=0x1 | TSC: P-state invariant | real memory = 34359738368 (32768 MB) | avail memory = 33151377408 (31615 MB) | ACPI APIC Table: | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs | FreeBSD/SMP: 1 package(s) x 8 core(s) | 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: 6 | cpu7 (AP): APIC ID: 7 | ioapic1 irqs 24-47 on motherboard | ioapic0 irqs 0-23 on motherboard I'm pretty sure that this is a 2 x 4 machine (2 CPU packages with 4 cores per package), not 1 x 8. That's what the BIOS displays during POST. I'm not sure if this is just a "cosmetic" issue, or if this is a critical thing ... I could imagine that performance might be sub-optimal if the CPU topology isn't detected correctly, but I'm not sure if FreeBSD can take advantage of the topology. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A misleading benchmark test can accomplish in minutes what years of good engineering can never do." -- Dilbert (2009-03-02) From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 14:15:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7A321065673 for ; Wed, 14 Jul 2010 14:15:15 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id F2FD58FC0A for ; Wed, 14 Jul 2010 14:15:14 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.3/8.14.3) with ESMTP id o6EDoncF095051; Wed, 14 Jul 2010 15:50:49 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) by mailhost.frm2.tum.de (8.14.3/8.14.3) with ESMTP id o6EDon3S095047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jul 2010 15:50:49 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: from hades.admin.frm2 (localhost [127.0.0.1]) by hades.admin.frm2 (8.14.3/8.14.3) with ESMTP id o6EDonok043693; Wed, 14 Jul 2010 15:50:49 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: (from jpulz@localhost) by hades.admin.frm2 (8.14.3/8.14.3/Submit) id o6EDomhI043692; Wed, 14 Jul 2010 15:50:48 +0200 (CEST) (envelope-from jpulz) Date: Wed, 14 Jul 2010 15:50:48 +0200 (CEST) From: Joerg Pulz To: freebsd-stable@freebsd.org In-Reply-To: <4C3CC831.7040005@kaarposoft.dk> Message-ID: References: <4C3CC831.7040005@kaarposoft.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mailhost.frm2.tum.de [129.187.179.12]); Wed, 14 Jul 2010 15:50:49 +0200 (CEST) Cc: mamalos@eng.auth.gr, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 14:15:15 -0000 On Tue, 13 Jul 2010, Henrik /KaarPoSoft wrote: > Dear All, > > I have a problem: ldapsearch results in "Segmentation fault" under > openldap-2.4.23 with cyrus-sasl-2.1.23. > > A thread for similar issues was started by George Mamalakis back in february: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html > but I find no solution / conclusion from this thread, hence I post here... > > I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with freebsd-update, > and ports updated with "portsnap fetch update". > > Kerberos installed from packages, configured, and seems to work OK. > > It seems that there are no package for openldap server with GSSAPI/SASL, so I > have build and installed cyrus-sasl2, openldap24-server (with sasl > configured) and openldap24-sasl-client from ports. > > Those are the port versions: > # $FreeBSD: ports/security/cyrus-sasl2/Makefile,v 1.141 2009/08/02 19:35:25 > mezz Exp $ > # $FreeBSD: ports/net/openldap24-server/Makefile,v 1.181 2010/07/01 19:04:42 > delphij Exp $ > > According to the distinfo files, those are the upstream versions: > openldap-2.4.23 > cyrus-sasl-2.1.23 > which, as far as I can see, are the latest stable. > > Trying LDAP I get a segfault: > > $ ldapsearch > SASL/GSSAPI authentication started > Segmentation fault (core dumped) > > Here is the backtrace from gdb: > > #0 0x283225c7 in free () from /lib/libc.so.7 > #1 0x28654b42 in gss_release_buffer () from /usr/lib/libgssapi.so.10 > #2 0x28654512 in gss_release_name () from /usr/lib/libgssapi.so.10 > #3 0x28650e69 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 > #4 0x28648a0f in gssapi_client_mech_step () from > /usr/local/lib/sasl2/libgssapiv2.so.2 > #5 0x280ef4b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > #6 0x28440200 in ?? () > #7 0x00000000 in ?? () > #8 0x00000000 in ?? () > #9 0xbfbfe208 in ?? () > #10 0xbfbfe1f4 in ?? () > #11 0xbfbfe204 in ?? () > #12 0x28446860 in ?? () > #13 0x280ef3fe in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > #14 0xbfbfe148 in ?? () > #15 0x280f0135 in sasl_client_start () from /usr/local/lib/libsasl2.so.2 > #16 0x00000000 in ?? () > #17 0x00000000 in ?? () > #18 0xbfbfe208 in ?? () > #19 0xbfbfe1f4 in ?? () > #20 0xbfbfe204 in ?? () > #21 0x72408f2d in ?? () > #22 0x283b1ad8 in ?? () from /lib/libc.so.7 > #23 0x00000000 in ?? () > #24 0x283b1730 in __stderrp () from /lib/libc.so.7 > #25 0xbfbfe118 in ?? () > #26 0x28392114 in vfprintf () from /lib/libc.so.7 > Previous frame inner to this frame (corrupt stack?) > > I tried "valgrind ldapsearch" which produces thousands of issues, ending > with: > > ==59479== Invalid free() / delete / delete[] > ==59479== at 0x59B95: free (in > /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) > ==59479== by 0x911B41: gss_release_buffer (in /usr/lib/libgssapi.so.10) > ==59479== by 0x911511: ??? (in /usr/lib/libgssapi.so.10) > ==59479== by 0x90DE68: gss_init_sec_context (in /usr/lib/libgssapi.so.10) > ==59479== by 0x905A0E: gssapi_client_mech_step (in > /usr/local/lib/sasl2/libgssapiv2.so.2) > ==59479== by 0xAF4B0: sasl_client_step (in /usr/local/lib/libsasl2.so.2) > ==59479== by 0xB0134: sasl_client_start (in /usr/local/lib/libsasl2.so.2) > ==59479== by 0x70C46: ldap_int_sasl_bind (in > /usr/local/lib/libldap-2.4.so.7) > ==59479== by 0x73935: ldap_sasl_interactive_bind_s (in > /usr/local/lib/libldap-2.4.so.7) > ==59479== by 0x80505E6: ??? (in /usr/local/bin/ldapsearch) > ==59479== by 0x804D695: ??? (in /usr/local/bin/ldapsearch) > ==59479== by 0x804A7D8: ??? (in /usr/local/bin/ldapsearch) > ==59479== Address 0x4e2c0 is not stack'd, malloc'd or (recently) free'd > ==59479== > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous > failure (see text) (unknown mech-code 2529638944 for mech unknown) > > /var/log/messages has: > slapd[1146]: OTP unavailable because can't read/write key database > /etc/opiekeys: Permission denied > kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) > > The first message is from the LDAP server. Even if it has some problem, it > should not lead the client to segfault. > > Any comments, hints or suggestions would be most appreciated! Dear Henrik, just a guess from my side. You said, that you installed and configured Kerberos from packages (i guess from ports or a prebuilt package). Did you by any chance set HEIMDAL_HOME=/usr before building and installing the kerberos port? Did you set HEIMDAL_HOME to point to the place where the package/port got installed (e.g. HEIMDAL_HOME=/usr/local) before building the cyrus-sasl2 port? Did you set HEIMDAL_HOME to anything at all? Please take a look at ${PORTSDIR}/security/cyrus-sasl2/Makefile to see the logic behind the kerberos selection. The valgrind and gdb output above shows that /usr/lib/libgssapi.so.10 is used at runtime which comes out of the FreeBSD base system not out of your installed kerberos port/package. Maybe there is something messed up that kerberos from ports/package was used during build of cyrus-sasl2 but the base kerberos libs are used at runtime or vice versa. In any case, this is just one thing i would double check before deeper debugging. Kind regards Joerg -- The beginning is the most important part of the work. -Plato From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 14:33:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72741065687 for ; Wed, 14 Jul 2010 14:33:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C37A8FC13 for ; Wed, 14 Jul 2010 14:33:19 +0000 (UTC) Received: by wyf22 with SMTP id 22so1588151wyf.13 for ; Wed, 14 Jul 2010 07:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q9g8rMdJx+a40ZOTVUhQ5HAEifSv5ovAg4GEPMZ2aZA=; b=TlgJx2BgY9P8fVSapxTctsb1QT37sxDXxw1jqp1w74+p7fWTjSYfMVt22HYa+zzR8b 2p/ydfO1jArC3zsekWxmGtJm/YQfTT42vRSVwaaqZ8g1VpuaqfmBG58J5vGgypwR262X HPe3GlL1VXe/z9JPL9Fbuap1qb8809SXPYn1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VImX6T6ObUSg9oaKKfMOvNFLzbsgx/hEKVuCy+884UPc6tLdBol3FaeDYKqA1a3Btj HHORDH9+Y7gxoBU+wybWVqcPxYlp46CKZjUBNOmvT0dM1NmAIjeEXMdssRawdvkDhB0s QpYVuPrmYETn7y5NZpNiID4WA9rmq0gk2kkNo= MIME-Version: 1.0 Received: by 10.216.145.194 with SMTP id p44mr5001530wej.82.1279117998407; Wed, 14 Jul 2010 07:33:18 -0700 (PDT) Received: by 10.216.137.23 with HTTP; Wed, 14 Jul 2010 07:33:18 -0700 (PDT) In-Reply-To: <201007141414.o6EEEUx9014690@lurza.secnetix.de> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> Date: Wed, 14 Jul 2010 18:33:18 +0400 Message-ID: From: pluknet To: Oliver Fromme Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 14:33:19 -0000 On 14 July 2010 18:14, Oliver Fromme wrote: > In a machine installed yesterday, 8.1-PRERELEASE doesn't > seem to detect the number of CPU packages vs. cores per > package correctly: > > =A0| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 > =A0| [...] > =A0| CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 L5408 =A0@ 2.13GHz (21= 33.42-MHz K8-class CPU) > =A0| =A0 Origin =3D "GenuineIntel" =A0Id =3D 0x1067a =A0Family =3D 6 =A0M= odel =3D 17 =A0Stepping =3D 10 > =A0| =A0 Features=3D0xbfebfbff > =A0| =A0 Features2=3D0x40ce3bd > =A0| =A0 AMD Features=3D0x20000800 > =A0| =A0 AMD Features2=3D0x1 > =A0| =A0 TSC: P-state invariant > =A0| real memory =A0=3D 34359738368 (32768 MB) > =A0| avail memory =3D 33151377408 (31615 MB) > =A0| ACPI APIC Table: > =A0| FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > =A0| FreeBSD/SMP: 1 package(s) x 8 core(s) > =A0| =A0cpu0 (BSP): APIC ID: =A00 > =A0| =A0cpu1 (AP): APIC ID: =A01 > =A0| =A0cpu2 (AP): APIC ID: =A02 > =A0| =A0cpu3 (AP): APIC ID: =A03 > =A0| =A0cpu4 (AP): APIC ID: =A04 > =A0| =A0cpu5 (AP): APIC ID: =A05 > =A0| =A0cpu6 (AP): APIC ID: =A06 > =A0| =A0cpu7 (AP): APIC ID: =A07 > =A0| ioapic1 irqs 24-47 on motherboard > =A0| ioapic0 irqs 0-23 on motherboard > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > with 4 cores per package), not 1 x 8. =A0That's what the BIOS > displays during POST. > Hi, can you show kern.sched.topology_spec ? It would clarify things a bit. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 14:44:22 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A90A1065674 for ; Wed, 14 Jul 2010 14:44:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id B704D8FC29 for ; Wed, 14 Jul 2010 14:44:21 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6EEi5Mp016146; Wed, 14 Jul 2010 16:44:20 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6EEi5uk016145; Wed, 14 Jul 2010 16:44:05 +0200 (CEST) (envelope-from olli) Date: Wed, 14 Jul 2010 16:44:05 +0200 (CEST) Message-Id: <201007141444.o6EEi5uk016145@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, pluknet@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Wed, 14 Jul 2010 16:44:20 +0200 (CEST) Cc: Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 14:44:22 -0000 pluknet wrote: > On 14 July 2010 18:14, Oliver Fromme wrote: > > In a machine installed yesterday, 8.1-PRERELEASE doesn't > > seem to detect the number of CPU packages vs. cores per > > package correctly: > > > >  | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 > >  | [...] > >  | CPU: Intel(R) Xeon(R) CPU           L5408  @ 2.13GHz (2133.42-MHz K8-class CPU) > >  |   Origin = "GenuineIntel"  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10 > >  |   Features=0xbfebfbff > >  |   Features2=0x40ce3bd > >  |   AMD Features=0x20000800 > >  |   AMD Features2=0x1 > >  |   TSC: P-state invariant > >  | real memory  = 34359738368 (32768 MB) > >  | avail memory = 33151377408 (31615 MB) > >  | ACPI APIC Table: > >  | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >  | FreeBSD/SMP: 1 package(s) x 8 core(s) > >  |  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:  6 > >  |  cpu7 (AP): APIC ID:  7 > >  | ioapic1 irqs 24-47 on motherboard > >  | ioapic0 irqs 0-23 on motherboard > > > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > > with 4 cores per package), not 1 x 8.  That's what the BIOS > > displays during POST. > > > > Hi, can you show kern.sched.topology_spec ? > It would clarify things a bit. Sure: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3, 4, 5, 6, 7 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Blogging: Never before have so many people with so little to say said so much to so few. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 14:57:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B58051065677 for ; Wed, 14 Jul 2010 14:57:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 62A7E8FC18 for ; Wed, 14 Jul 2010 14:57:25 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id hnRg1e00227AodY58qxSgE; Wed, 14 Jul 2010 14:57:26 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.westchester.pa.mail.comcast.net with comcast id hqxR1e00F3LrwQ23fqxRLn; Wed, 14 Jul 2010 14:57:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C84BF9B425; Wed, 14 Jul 2010 07:57:23 -0700 (PDT) Date: Wed, 14 Jul 2010 07:57:23 -0700 From: Jeremy Chadwick To: Oliver Fromme Message-ID: <20100714145723.GA38060@icarus.home.lan> References: <201007141444.o6EEi5uk016145@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201007141444.o6EEi5uk016145@lurza.secnetix.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pluknet@gmail.com, freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 14:57:26 -0000 On Wed, Jul 14, 2010 at 04:44:05PM +0200, Oliver Fromme wrote: > pluknet wrote: > > On 14 July 2010 18:14, Oliver Fromme wrote: > > > In a machine installed yesterday, 8.1-PRERELEASE doesn't > > > seem to detect the number of CPU packages vs. cores per > > > package correctly: > > > > > >  | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 > > >  | [...] > > >  | CPU: Intel(R) Xeon(R) CPU           L5408  @ 2.13GHz (2133.42-MHz K8-class CPU) > > >  |   Origin = "GenuineIntel"  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10 > > >  |   Features=0xbfebfbff > > >  |   Features2=0x40ce3bd > > >  |   AMD Features=0x20000800 > > >  |   AMD Features2=0x1 > > >  |   TSC: P-state invariant > > >  | real memory  = 34359738368 (32768 MB) > > >  | avail memory = 33151377408 (31615 MB) > > >  | ACPI APIC Table: > > >  | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > >  | FreeBSD/SMP: 1 package(s) x 8 core(s) > > >  |  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:  6 > > >  |  cpu7 (AP): APIC ID:  7 > > >  | ioapic1 irqs 24-47 on motherboard > > >  | ioapic0 irqs 0-23 on motherboard > > > > > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > > > with 4 cores per package), not 1 x 8.  That's what the BIOS > > > displays during POST. > > > > > > > Hi, can you show kern.sched.topology_spec ? > > It would clarify things a bit. > > Sure: > > > > 0, 1, 2, 3, 4, 5, 6, 7 > > > > 0, 1, 2, 3, 4, 5, 6, 7 > > > > > Can you also provide the output of "acpidump -dt"? This will probably be quite long (possibly 300KB or more), so you may want to put it up on the web somewhere. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 15:13:09 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAB441065674 for ; Wed, 14 Jul 2010 15:13:09 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3167E8FC26 for ; Wed, 14 Jul 2010 15:13:09 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6EFCqAa017278; Wed, 14 Jul 2010 17:13:07 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6EFCqYD017276; Wed, 14 Jul 2010 17:12:52 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007141512.o6EFCqYD017276@lurza.secnetix.de> To: freebsd@jdc.parodius.com (Jeremy Chadwick) Date: Wed, 14 Jul 2010 17:12:52 +0200 (CEST) In-Reply-To: <20100714145723.GA38060@icarus.home.lan> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Wed, 14 Jul 2010 17:13:08 +0200 (CEST) Cc: pluknet@gmail.com, freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 15:13:09 -0000 Jeremy Chadwick wrote: > Can you also provide the output of "acpidump -dt"? This will probably > be quite long (possibly 300KB or more), so you may want to put it up on > the web somewhere. http://www.secnetix.de/olli/tmp/acpidump-dt.txt Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 16:49:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72402106566B for ; Wed, 14 Jul 2010 16:49:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C82508FC16 for ; Wed, 14 Jul 2010 16:49:12 +0000 (UTC) Received: by wyf22 with SMTP id 22so36759wyf.13 for ; Wed, 14 Jul 2010 09:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=owDPtaVSM/2PXB6XvCSLOsItZInYymqakakfDCgQ5JA=; b=ZargHBRnTsaiimLWAj66h8NQqrkNd0/Bj6oTmhT7e7UEmdMnv86ZYARbK+m4k+v1VI DoLX2tUMFwSEaOa/8XU+f6+F+c7gTx8cx2MZum7PY41R8U7FjZMTg1vOueOvBpQlrjPa MB1lGNdPB3Huyvlb/ctFjK9Qp3fR4u62Qy7TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Yn/ObHCWCrBdzH5RptFF5mz88bmiDPntIECrTFkA5mNxrS8kt6kCURrVc/nNtAKZQd qVrmX7MjsDHcb0U/6GATGXEpHRzU/C3eeAWFz3U70mp43iYtW+BHGWqlUDKj/bo8cn5q VRSHGnXUOVU7ZZrmRYeTJfTB7ETqd/1mZY3gE= MIME-Version: 1.0 Received: by 10.227.154.77 with SMTP id n13mr6972915wbw.190.1279126150828; Wed, 14 Jul 2010 09:49:10 -0700 (PDT) Received: by 10.216.137.23 with HTTP; Wed, 14 Jul 2010 09:49:10 -0700 (PDT) In-Reply-To: <20090719215224.GA2271@triton.kn-bremen.de> References: <20090719215224.GA2271@triton.kn-bremen.de> Date: Wed, 14 Jul 2010 20:49:10 +0400 Message-ID: From: pluknet To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: new umass panic on 7-stable built today X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 16:49:13 -0000 On 20 July 2009 01:52, Juergen Lock wrote: > Hi! > > =A0So I wanted to use an usb key on this freshly updated 7-stable box, > and got a panic just after plugging it in: :( > > zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 > ... > umass0: on uhub5 > umass0:1:0:-1: Attached to scbus1 > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x290 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not = present > instruction pointer =A0 =A0 =3D 0x8:0xffffffff804d67d4 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xffffff8085487da0 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xffffff8085487de0 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 38 (usb5) > trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > trap_fatal() at trap_fatal+0x2b3 > trap_pfault() at trap_pfault+0x294 > trap() at trap+0x312 > calltrap() at calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff804d67d4, rsp =3D 0xffffff8085487da0, rbp= =3D 0xffffff8085487de0 --- > usb_transfer_complete() at usb_transfer_complete+0x1d4 > bus_dmamap_load() at bus_dmamap_load+0x314 > usbd_transfer() at usbd_transfer+0xee > usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f > usbd_do_request_flags() at usbd_do_request_flags+0x25 > usbd_get_string_desc() at usbd_get_string_desc+0x9b > usbd_get_string() at usbd_get_string+0x83 > uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 > devaddq() at devaddq+0xd5 > device_attach() at device_attach+0x13a > usbd_new_device() at usbd_new_device+0x821 > uhub_explore() at uhub_explore+0x1bd > usb_discover() at usb_discover+0x38 > usb_event_thread() at usb_event_thread+0x8a > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8085488d30, rbp =3D 0 --- > Uptime: 1m1s > Physical memory: 8176 MB > Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4= 414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4= 174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3= 934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3= 694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3= 454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3= 214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2= 974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2= 734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2= 494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2= 254 2238 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2= 014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1= 774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1= 534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1= 294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1= 054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 = 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478= 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 17= 4 158 142 126 110 94 78 62 46 30 14 > > Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/k= ernel/umass.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/umass.ko > #0 =A0doadump () at pcpu.h:195 > 195 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (t= d)); > (kgdb) bt > #0 =A0doadump () at pcpu.h:195 > #1 =A00xffffffff80567248 in boot (howto=3D260) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 > #2 =A00xffffffff805676ac in panic (fmt=3DVariable "fmt" is not available. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 > #3 =A00xffffffff8082f953 in trap_fatal (frame=3D0xc, eva=3DVariable "eva"= is not available. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 > #4 =A00xffffffff8082fd34 in trap_pfault (frame=3D0xffffff8085487cf0, user= mode=3D0) > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 > #5 =A00xffffffff808306e2 in trap (frame=3D0xffffff8085487cf0) > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 > #6 =A00xffffffff80819cce in calltrap () > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 > #7 =A00xffffffff804d67d4 in usb_transfer_complete (xfer=3D0xffffff00046b1= 000) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 > #8 =A00xffffffff80815bf4 in bus_dmamap_load (dmat=3D0xffffff0004499880, > =A0 =A0map=3D0xffffff000478ec00, buf=3D0xffffff8085487fe0, buflen=3D0, > =A0 =A0callback=3D0xffffffff804d68b0 , > =A0 =A0callback_arg=3D0xffffff00046b1000, flags=3D0) > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/busdma_machdep.c:738 > #9 =A00xffffffff804d6f2e in usbd_transfer (xfer=3D0xffffff00046b1000) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:312 > #10 0xffffffff804d717f in usbd_do_request_flags_pipe (dev=3D0xffffff00047= 51600, > ---Type to continue, or q to quit--- > =A0 =A0pipe=3D0xffffff000474cd80, req=3D0xffffff8085487f80, data=3D0xffff= ff8085487fe0, > =A0 =A0flags=3DVariable "flags" is not available. > ) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1100 > #11 0xffffffff804d72b5 in usbd_do_request_flags (dev=3DVariable "dev" is = not available. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1070 > #12 0xffffffff804d518b in usbd_get_string_desc (dev=3D0xffffff0004751600,= sindex=3DVariable "sindex" is not available. > > ) at /usr/home/nox/src72s2/src/sys/dev/usb/usb_subr.c:171 > #13 0xffffffff804d6473 in usbd_get_string (dev=3D0xffffff0004751600, si= =3D3, > =A0 =A0buf=3D0xffffff8085488160 "", len=3D128) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1353 > #14 0xffffffff804cdb49 in uhub_child_pnpinfo_str (cbdev=3DVariable "cbdev= " is not available. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/uhub.c:658 > #15 0xffffffff80590ce5 in devaddq (type=3D0xffffffff8090dccf "+", > =A0 =A0what=3D0xffffff00046b0000 "umass0 vendor=3D0x0325 product=3D0xac02= devclass=3D0x00 devsubclass=3D0x00 release=3D0x1100 sernum=3D\"AA040127001= 52689\" intclass=3D0x08 intsubclass=3D0x06", dev=3D0xffffff00046c0200) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/subr_bus.c:625 > #16 0xffffffff805914ba in device_attach (dev=3D0xffffff00046c0200) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/subr_bus.c:668 > #17 0xffffffff804d5b41 in usbd_new_device (parent=3D0xffffff00044a0200, > =A0 =A0bus=3D0xffffff0004472000, depth=3DVariable "depth" is not availabl= e. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb_subr.c:926 > #18 0xffffffff804cd79d in uhub_explore (dev=3D0xffffff00044a0300) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/uhub.c:523 > ---Type to continue, or q to quit--- > #19 0xffffffff804d23e8 in usb_discover (v=3DVariable "v" is not available= . > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb.c:724 > #20 0xffffffff804d33aa in usb_event_thread (arg=3DVariable "arg" is not a= vailable. > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb.c:440 > #21 0xffffffff8054115f in fork_exit ( > =A0 =A0callout=3D0xffffffff804d3320 , arg=3D0xffffff000= 44b1580, > =A0 =A0frame=3D0xffffff8085488c80) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_fork.c:811 > #22 0xffffffff8081a0ae in fork_trampoline () > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:554 > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000001 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > ---Type to continue, or q to quit--- > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000000000 in ?? () > #43 0x0000000000000000 in ?? () > #44 0x0000000000000000 in ?? () > #45 0x0000000000000000 in ?? () > #46 0x0000000000000000 in ?? () > #47 0x0000000000d84000 in ?? () > #48 0x0000000000000001 in ?? () > #49 0xffffffff80bba848 in sleepq_chains () > #50 0xffffff00044a5720 in ?? () > #51 0xffffff00044a5a70 in ?? () > #52 0xffffff8085487da0 in ?? () > #53 0xffffff8085487d38 in ?? () > #54 0xffffff00044a5720 in ?? () > #55 0xffffffff8058b01e in sched_switch (td=3D0x0, newtd=3DCannot access m= emory at address 0xffffffffffffffa8 > ) > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/sched_ule.c:1938 > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 7 > #7 =A00xffffffff804d67d4 in usb_transfer_complete (xfer=3D0xffffff00046b1= 000) > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 > 949 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE_HEAD(&pipe->que= ue, next); > (kgdb) p pipe > $1 =3D 0xffffff000474cd80 > (kgdb) p *pipe > $2 =3D {iface =3D 0x0, device =3D 0xffffff0004751600, endpoint =3D 0xffff= ff0004751638, > =A0refcnt =3D 1, running =3D 0 '\0', aborting =3D 0 '\0', queue =3D {stqh= _first =3D 0x0, > =A0 =A0stqh_last =3D 0xffffff000474cda0}, next =3D {le_next =3D 0x0, le_p= rev =3D 0x0}, > =A0intrxfer =3D 0x0, repeat =3D 0 '\0', interval =3D -1, methods =3D 0xff= ffffff80afbf00} > (kgdb) q > zsh triton# > > =A0Suggestions/patches welcome... > > =A0Thanx, > =A0 =A0 =A0 =A0Juergen Hi, Wow, a year passed until today I attached almost the same keyboard on 7.3-RELEASE amd64 and faced panic with the same backtrace. Is there maybe some *cough* specific handling need with this vendor? db> bt Tracing pid 47 tid 100047 td 0xffffff0006c54740 usb_transfer_complete() at usb_transfer_complete+0x1d4 bus_dmamap_load() at bus_dmamap_load+0x314 usbd_transfer() at usbd_transfer+0xee usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f usbd_do_request_flags() at usbd_do_request_flags+0x25 usbd_get_string_desc() at usbd_get_string_desc+0x9b usbd_get_string() at usbd_get_string+0x83 uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 devaddq() at devaddq+0xd5 device_attach() at device_attach+0x13a usbd_new_device() at usbd_new_device+0x816 uhub_explore() at uhub_explore+0x1bd usb_discover() at usb_discover+0x38 usb_event_thread() at usb_event_thread+0x8a fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8161196d30, rbp =3D 0 --- db> show msgbuf msgbufp =3D 0xffffffff80e20fe0 magic =3D 63062, size =3D 65504, r=3D 44209, w =3D 44746, ptr =3D 0xffffffff80e11000, cksum=3D 3347961 umass0: on uhub2 Fatal trap 12: page fault while in kernel mode cpuid =3D 4; apic id =3D 04 fault virtual address =3D 0x290 fault code =3D supervisor read data, page not present instruction pointer =3D 0x8:0xffffffff804a9d44 stack pointer =3D 0x10:0xffffff8161195db0 frame pointer =3D 0x10:0xffffff8161195df0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 47 (usb2) --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 17:32:09 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98C7B10656AE for ; Wed, 14 Jul 2010 17:32:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3EE8FC16 for ; Wed, 14 Jul 2010 17:32:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA13079; Wed, 14 Jul 2010 20:31:59 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C3DF48E.1070502@icyb.net.ua> Date: Wed, 14 Jul 2010 20:31:58 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Oliver Fromme References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> In-Reply-To: <201007141414.o6EEEUx9014690@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 17:32:09 -0000 on 14/07/2010 17:14 Oliver Fromme said the following: > In a machine installed yesterday, 8.1-PRERELEASE doesn't > seem to detect the number of CPU packages vs. cores per > package correctly: > > | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 > | [...] > | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz (2133.42-MHz K8-class CPU) > | Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 > | Features=0xbfebfbff > | Features2=0x40ce3bd > | AMD Features=0x20000800 > | AMD Features2=0x1 > | TSC: P-state invariant > | real memory = 34359738368 (32768 MB) > | avail memory = 33151377408 (31615 MB) > | ACPI APIC Table: > | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > | FreeBSD/SMP: 1 package(s) x 8 core(s) > | 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: 6 > | cpu7 (AP): APIC ID: 7 > | ioapic1 irqs 24-47 on motherboard > | ioapic0 irqs 0-23 on motherboard > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > with 4 cores per package), not 1 x 8. That's what the BIOS > displays during POST. > > I'm not sure if this is just a "cosmetic" issue, or if this > is a critical thing ... I could imagine that performance > might be sub-optimal if the CPU topology isn't detected > correctly, but I'm not sure if FreeBSD can take advantage > of the topology. Could you please try to do the following? 1. Fetch topo-12212009.tar from the top of this page: http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ 2. Untar it and apply this patch to the code: http://people.freebsd.org/~avg/cpu-topology.diff 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) 4. Run cpu_topology64.out and report back its output. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 19:12:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97B021065675; Wed, 14 Jul 2010 19:12:29 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id CBB148FC0A; Wed, 14 Jul 2010 19:12:28 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 1E83A1E001E0; Wed, 14 Jul 2010 21:12:27 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o6EJ9iCk016868; Wed, 14 Jul 2010 21:09:44 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o6EJ9iJG016867; Wed, 14 Jul 2010 21:09:44 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Wed, 14 Jul 2010 21:09:44 +0200 To: pluknet Message-ID: <20100714190944.GA15927@triton8.kn-bremen.de> References: <20090719215224.GA2271@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Juergen Lock , freebsd-usb@freebsd.org Subject: Re: new umass panic on 7-stable built today X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 19:12:29 -0000 On Wed, Jul 14, 2010 at 08:49:10PM +0400, pluknet wrote: > On 20 July 2009 01:52, Juergen Lock wrote: > > Hi! > > > > =A0So I wanted to use an usb key on this freshly updated 7-stable box, > > and got a panic just after plugging it in: :( > > > > zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9 > > ... > > umass0: on uhub5 > > umass0:1:0:-1: Attached to scbus1 > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =A0 =3D 0x290 > > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page no= t present > > instruction pointer =A0 =A0 =3D 0x8:0xffffffff804d67d4 > > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xffffff8085487da0 > > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xffffff8085487de0 > > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0= x1b > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long = 1, def32 0, gran 1 > > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D= 0 > > current process =A0 =A0 =A0 =A0 =3D 38 (usb5) > > trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 > > panic: page fault > > cpuid =3D 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > panic() at panic+0x182 > > trap_fatal() at trap_fatal+0x2b3 > > trap_pfault() at trap_pfault+0x294 > > trap() at trap+0x312 > > calltrap() at calltrap+0x8 > > --- trap 0xc, rip =3D 0xffffffff804d67d4, rsp =3D 0xffffff8085487da0, r= bp =3D 0xffffff8085487de0 --- > > usb_transfer_complete() at usb_transfer_complete+0x1d4 > > bus_dmamap_load() at bus_dmamap_load+0x314 > > usbd_transfer() at usbd_transfer+0xee > > usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f > > usbd_do_request_flags() at usbd_do_request_flags+0x25 > > usbd_get_string_desc() at usbd_get_string_desc+0x9b > > usbd_get_string() at usbd_get_string+0x83 > > uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 > > devaddq() at devaddq+0xd5 > > device_attach() at device_attach+0x13a > > usbd_new_device() at usbd_new_device+0x821 > > uhub_explore() at uhub_explore+0x1bd > > usb_discover() at usb_discover+0x38 > > usb_event_thread() at usb_event_thread+0x8a > > fork_exit() at fork_exit+0x11f > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip =3D 0, rsp =3D 0xffffff8085488d30, rbp =3D 0 --- > > Uptime: 1m1s > > Physical memory: 8176 MB > > Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430= 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190= 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950= 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710= 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470= 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230= 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990= 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750= 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510= 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270= 2254 2238 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030= 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790= 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550= 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 > 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 11= 50 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894= 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 59= 0 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 2= 86 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 > > > > Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot= /kernel/umass.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/umass.ko > > #0 =A0doadump () at pcpu.h:195 > > 195 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movq %%gs:0,%0" : "=3Dr" = (td)); > > (kgdb) bt > > #0 =A0doadump () at pcpu.h:195 > > #1 =A00xffffffff80567248 in boot (howto=3D260) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418 > > #2 =A00xffffffff805676ac in panic (fmt=3DVariable "fmt" is not availabl= e. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574 > > #3 =A00xffffffff8082f953 in trap_fatal (frame=3D0xc, eva=3DVariable "ev= a" is not available. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756 > > #4 =A00xffffffff8082fd34 in trap_pfault (frame=3D0xffffff8085487cf0, us= ermode=3D0) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672 > > #5 =A00xffffffff808306e2 in trap (frame=3D0xffffff8085487cf0) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443 > > #6 =A00xffffffff80819cce in calltrap () > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218 > > #7 =A00xffffffff804d67d4 in usb_transfer_complete (xfer=3D0xffffff00046= b1000) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 > > #8 =A00xffffffff80815bf4 in bus_dmamap_load (dmat=3D0xffffff0004499880, > > =A0 =A0map=3D0xffffff000478ec00, buf=3D0xffffff8085487fe0, buflen=3D0, > > =A0 =A0callback=3D0xffffffff804d68b0 , > > =A0 =A0callback_arg=3D0xffffff00046b1000, flags=3D0) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/busdma_machdep.c:738 > > #9 =A00xffffffff804d6f2e in usbd_transfer (xfer=3D0xffffff00046b1000) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:312 > > #10 0xffffffff804d717f in usbd_do_request_flags_pipe (dev=3D0xffffff000= 4751600, > > ---Type to continue, or q to quit--- > > =A0 =A0pipe=3D0xffffff000474cd80, req=3D0xffffff8085487f80, data=3D0xff= ffff8085487fe0, > > =A0 =A0flags=3DVariable "flags" is not available. > > ) at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1100 > > #11 0xffffffff804d72b5 in usbd_do_request_flags (dev=3DVariable "dev" i= s not available. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1070 > > #12 0xffffffff804d518b in usbd_get_string_desc (dev=3D0xffffff000475160= 0, sindex=3DVariable "sindex" is not available. > > > > ) at /usr/home/nox/src72s2/src/sys/dev/usb/usb_subr.c:171 > > #13 0xffffffff804d6473 in usbd_get_string (dev=3D0xffffff0004751600, si= =3D3, > > =A0 =A0buf=3D0xffffff8085488160 "", len=3D128) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:1353 > > #14 0xffffffff804cdb49 in uhub_child_pnpinfo_str (cbdev=3DVariable "cbd= ev" is not available. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/uhub.c:658 > > #15 0xffffffff80590ce5 in devaddq (type=3D0xffffffff8090dccf "+", > > =A0 =A0what=3D0xffffff00046b0000 "umass0 vendor=3D0x0325 product=3D0xac= 02 devclass=3D0x00 devsubclass=3D0x00 release=3D0x1100 sernum=3D\"AA0401270= 0152689\" intclass=3D0x08 intsubclass=3D0x06", dev=3D0xffffff00046c0200) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/subr_bus.c:625 > > #16 0xffffffff805914ba in device_attach (dev=3D0xffffff00046c0200) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/subr_bus.c:668 > > #17 0xffffffff804d5b41 in usbd_new_device (parent=3D0xffffff00044a0200, > > =A0 =A0bus=3D0xffffff0004472000, depth=3DVariable "depth" is not availa= ble. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb_subr.c:926 > > #18 0xffffffff804cd79d in uhub_explore (dev=3D0xffffff00044a0300) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/uhub.c:523 > > ---Type to continue, or q to quit--- > > #19 0xffffffff804d23e8 in usb_discover (v=3DVariable "v" is not availab= le. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb.c:724 > > #20 0xffffffff804d33aa in usb_event_thread (arg=3DVariable "arg" is not= available. > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usb.c:440 > > #21 0xffffffff8054115f in fork_exit ( > > =A0 =A0callout=3D0xffffffff804d3320 , arg=3D0xffffff0= 0044b1580, > > =A0 =A0frame=3D0xffffff8085488c80) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/kern_fork.c:811 > > #22 0xffffffff8081a0ae in fork_trampoline () > > =A0 =A0at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:554 > > #23 0x0000000000000000 in ?? () > > #24 0x0000000000000000 in ?? () > > #25 0x0000000000000001 in ?? () > > #26 0x0000000000000000 in ?? () > > #27 0x0000000000000000 in ?? () > > #28 0x0000000000000000 in ?? () > > #29 0x0000000000000000 in ?? () > > #30 0x0000000000000000 in ?? () > > #31 0x0000000000000000 in ?? () > > #32 0x0000000000000000 in ?? () > > #33 0x0000000000000000 in ?? () > > #34 0x0000000000000000 in ?? () > > #35 0x0000000000000000 in ?? () > > ---Type to continue, or q to quit--- > > #36 0x0000000000000000 in ?? () > > #37 0x0000000000000000 in ?? () > > #38 0x0000000000000000 in ?? () > > #39 0x0000000000000000 in ?? () > > #40 0x0000000000000000 in ?? () > > #41 0x0000000000000000 in ?? () > > #42 0x0000000000000000 in ?? () > > #43 0x0000000000000000 in ?? () > > #44 0x0000000000000000 in ?? () > > #45 0x0000000000000000 in ?? () > > #46 0x0000000000000000 in ?? () > > #47 0x0000000000d84000 in ?? () > > #48 0x0000000000000001 in ?? () > > #49 0xffffffff80bba848 in sleepq_chains () > > #50 0xffffff00044a5720 in ?? () > > #51 0xffffff00044a5a70 in ?? () > > #52 0xffffff8085487da0 in ?? () > > #53 0xffffff8085487d38 in ?? () > > #54 0xffffff00044a5720 in ?? () > > #55 0xffffffff8058b01e in sched_switch (td=3D0x0, newtd=3DCannot access= memory at address 0xffffffffffffffa8 > > ) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/kern/sched_ule.c:1938 > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) fr 7 > > #7 =A00xffffffff804d67d4 in usb_transfer_complete (xfer=3D0xffffff00046= b1000) > > =A0 =A0at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949 > > 949 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE_HEAD(&pipe->q= ueue, next); > > (kgdb) p pipe > > $1 =3D 0xffffff000474cd80 > > (kgdb) p *pipe > > $2 =3D {iface =3D 0x0, device =3D 0xffffff0004751600, endpoint =3D 0xff= ffff0004751638, > > =A0refcnt =3D 1, running =3D 0 '\0', aborting =3D 0 '\0', queue =3D {st= qh_first =3D 0x0, > > =A0 =A0stqh_last =3D 0xffffff000474cda0}, next =3D {le_next =3D 0x0, le= _prev =3D 0x0}, > > =A0intrxfer =3D 0x0, repeat =3D 0 '\0', interval =3D -1, methods =3D 0x= ffffffff80afbf00} > > (kgdb) q > > zsh triton# > > > > =A0Suggestions/patches welcome... > > > > =A0Thanx, > > =A0 =A0 =A0 =A0Juergen >=20 > Hi, Hi! >=20 > Wow, a year passed until today I attached almost the same keyboard Mine was a flashkey tho... > on 7.3-RELEASE amd64 and faced panic with the same backtrace. > Is there maybe some *cough* specific handling need with this vendor? >=20 > db> bt > Tracing pid 47 tid 100047 td 0xffffff0006c54740 > usb_transfer_complete() at usb_transfer_complete+0x1d4 > bus_dmamap_load() at bus_dmamap_load+0x314 > usbd_transfer() at usbd_transfer+0xee > usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f > usbd_do_request_flags() at usbd_do_request_flags+0x25 > usbd_get_string_desc() at usbd_get_string_desc+0x9b > usbd_get_string() at usbd_get_string+0x83 > uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9 > devaddq() at devaddq+0xd5 > device_attach() at device_attach+0x13a > usbd_new_device() at usbd_new_device+0x816 > uhub_explore() at uhub_explore+0x1bd > usb_discover() at usb_discover+0x38 > usb_event_thread() at usb_event_thread+0x8a > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8161196d30, rbp =3D 0 --- > db> show msgbuf > msgbufp =3D 0xffffffff80e20fe0 > magic =3D 63062, size =3D 65504, r=3D 44209, w =3D 44746, ptr =3D > 0xffffffff80e11000, cksum=3D 3347961 > umass0: on uhub2 >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0x290 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x8:0xffffffff804a9d44 > stack pointer =3D 0x10:0xffffff8161195db0 > frame pointer =3D 0x10:0xffffff8161195df0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 47 (usb2) Anyway, that panic was the nail in the coffin for 7, I updated that box to 8 after I got no response to that posting. (which has hps' new usb stack that seems to work much better, but that probably also means 7's usb stack has kinda been eol'd...) Cheers, Juergen From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 19:18:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 999AA10656DB for ; Wed, 14 Jul 2010 19:18:24 +0000 (UTC) (envelope-from henrik@kaarposoft.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.freebsd.org (Postfix) with ESMTP id 344F98FC1D for ; Wed, 14 Jul 2010 19:18:23 +0000 (UTC) Received: from [192.168.99.150] (x1-6-00-00-24-cc-93-b4.k874.webspeed.dk [87.52.11.120]) by pfepb.post.tele.dk (Postfix) with ESMTP id 7A60CF8403A; Wed, 14 Jul 2010 21:18:22 +0200 (CEST) Message-ID: <4C3E0D7D.5020305@kaarposoft.dk> Date: Wed, 14 Jul 2010 21:18:21 +0200 From: Henrik /KaarPoSoft User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jeremy Chadwick , freebsd-stable@freebsd.org References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> In-Reply-To: <20100713210729.GA11943@icarus.home.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mamalos@eng.auth.gr Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 19:18:24 -0000 On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: >> I have a problem: ldapsearch results in "Segmentation fault" under >> openldap-2.4.23 with cyrus-sasl-2.1.23. >> [...] >> Jeremy Chadwick wrote: > If I was to build a test box from scratch, can you tell me how to set up > all the necessary software/etc. to mimic your environment so that I > could try to reproduce this? Reviewing the source isn't enough, I'd > have to actually build a debug version of libgssapi to track it down. > Jeremy, I would really appreciate your going through this! Thank you very much in advance. Here is what I did: FreeBSD 8.0 vanilla install hostname: srv02.example.lan freebsd-update fetch freebsd-update install Create self-signed "CA" cert, and create SSL cert for LDAP signed by this. References: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssl.html http://forums.freebsd.org/showthread.php?t=6490 http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php pkg_add -r heimdal cat >> /etc/rc.conf kerberos5_server_enable="YES" kadmind5_server_enable="YES" cat > /etc/krb5.conf [libdefaults] default_realm = EXAMPLE.LAN kstash kadmin -l kadmin> init EXAMPLE.LAN kadmin> add TestOne kadmin> list "*" /etc/rc.d/kerberos start /etc/rc.d/kadmind start Add to nameserver: kerberos.example.lan CNAME srv02.example.lan ldap.example.lan CNAME srv02.example.lan _kerberos IN TXT kerberos.example.lan _kerberos._udp.example.lan. IN SRV 0 0 88 kerberos.example.lan. _kerberos._tcp.example.lan. IN SRV 0 0 88 kerberos.example.lan. _kerberos-adm._tcp.example.lan. IN SRV 0 0 749 kerberos.example.lan. _kpasswd._udp.example.lan. IN SRV 0 0 464 kerberos.example.lan. cd /usr/ports portsnap fetch portsnap extract (and subsequently portsnap fetch update) cd /usr/ports/security/cyrus-sasl2 make config [X] Berkeley DB [X] /dev/urandom make make install cd /usr/ports/net/openldap24-sasl-client make make install cd /usr/ports/net/openldap24-server make config [x] SASL make cat >> /etc/rc.conf slapd_enable="YES" slapd_flags="-h ldaps:///" touch /var/db/openldap-data/DB_CONFIG srv02# diff /usr/local/etc/openldap/slapd.conf.ORIG /usr/local/etc/openldap/slapd.conf 48a50,80 > > ####################################################################### > # EXAMPLE > ####################################################################### > > #=# Shemas we need > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > > #=# Logging > loglevel stats stats2 shell parse ACL config filter BER conns > > > #=# GSSAPI mapping > #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > #=# http://www.openldap.org/doc/admin24/sasl.html#Mapping Authentication Identities > > authz-regexp > uid=([^,]*),cn=example.lan,cn=gssapi,cn=auth > uid=$1,ou=Users,dc=example,dc=lan > > > #=# LDAP over TSL (SSL) > #=# http://www.openldap.org/doc/admin24/tls.html > > security ssf=128 > TLSCertificateFile /etc/exampleCA/certs/ldap.pem > TLSCertificateKeyFile /etc/exampleCA/private/ldap.pem > TLSCACertificateFile /etc/exampleCA/certs/example.pem > 54,55c86,93 < suffix "dc=my-domain,dc=com" < rootdn "cn=Manager,dc=my-domain,dc=com" --- > > #=# The example Network > suffix "dc=example,dc=lan" > > #=# The rootdn user, authenticated by Kerberos > #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > rootdn "uid=LDAProot,cn=example.lan,cn=gssapi,cn=auth" > 59c97,99 < rootpw secret --- > > #=# Since rootdn is authenticated by Kerberos, we do not need rootpw > #rootpw secret 65a106 Add domain and a few users with slapadd cat >> /usr/local/etc/openldap/ldap.conf base dc=example,dc=lan uri ldaps://ldap.example.lan/ tls_cacert /etc/exampleCA/cacert.pem From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 19:57:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0AC106566B for ; Wed, 14 Jul 2010 19:57:23 +0000 (UTC) (envelope-from henrik@kaarposoft.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.freebsd.org (Postfix) with ESMTP id D82F78FC12 for ; Wed, 14 Jul 2010 19:57:22 +0000 (UTC) Received: from [192.168.99.150] (x1-6-00-00-24-cc-93-b4.k874.webspeed.dk [87.52.11.120]) by pfepb.post.tele.dk (Postfix) with ESMTP id E6EB0F8401C; Wed, 14 Jul 2010 21:57:21 +0200 (CEST) Message-ID: <4C3E16A1.8070909@kaarposoft.dk> Date: Wed, 14 Jul 2010 21:57:21 +0200 From: Henrik /KaarPoSoft User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Joerg Pulz , freebsd-stable@freebsd.org References: <4C3CC831.7040005@kaarposoft.dk> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: mamalos@eng.auth.gr Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 19:57:23 -0000 Joerg Pulz wrote: > On Tue, 13 Jul 2010, Henrik /KaarPoSoft wrote: > >> Dear All, >> >> I have a problem: ldapsearch results in "Segmentation fault" under >> openldap-2.4.23 with cyrus-sasl-2.1.23. >> >> [...] > > Dear Henrik, > > just a guess from my side. > > You said, that you installed and configured Kerberos from packages (i > guess from ports or a prebuilt package). > Did you by any chance set HEIMDAL_HOME=/usr before building and > installing the kerberos port? > > Did you set HEIMDAL_HOME to point to the place where the package/port > got installed (e.g. HEIMDAL_HOME=/usr/local) before building the > cyrus-sasl2 port? > > Did you set HEIMDAL_HOME to anything at all? Please take a look at > ${PORTSDIR}/security/cyrus-sasl2/Makefile to see the logic behind the > kerberos selection. > > The valgrind and gdb output above shows that /usr/lib/libgssapi.so.10 > is used at runtime which comes out of the FreeBSD base system not out > of your installed kerberos port/package. Maybe there is something > messed up that kerberos from ports/package was used during build of > cyrus-sasl2 but the base kerberos libs are used at runtime or vice versa. > > In any case, this is just one thing i would double check before deeper > debugging. Joerg, thank you very much for your input - most appreciated! I simply installed heimdal with pkg_add -r heimdal I did not set HEIMDAL_HOME at any point. "env" shows that HEIMDAL_HOME is not set. So according to /usr/ports/security/cyrus-sasl2/Makefile I guess we would have CONFIGURE_ARGS+=--enable-gssapi but no --with-gss_impl=heimdal To be on the safe side, I tried cd /usr/ports/security/cyrus-sasl2/ make clean export HEIMDAL_HOME=/usr make (during make I noticed a few cc ... -DKRB5_HEIMDAL ...) ldapsarch still coredumps with gss_init_sec_context () from /usr/lib/libgssapi.so.10 I noticed that I have libgssapi's - no clue why: srv02# ls /usr/lib/libgss* /usr/lib/libgssapi.a /usr/lib/libgssapi_krb5.a /usr/lib/libgssapi_krb5_p.a /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libgssapi_spnego.a /usr/lib/libgssapi_spnego_p.a /usr/lib/libgssapi.so /usr/lib/libgssapi_krb5.so /usr/lib/libgssapi_ntlm.a /usr/lib/libgssapi_ntlm_p.a /usr/lib/libgssapi_spnego.so /usr/lib/libgssapi.so.10 /usr/lib/libgssapi_krb5.so.10 /usr/lib/libgssapi_ntlm.so /usr/lib/libgssapi_p.a /usr/lib/libgssapi_spnego.so.10 srv02# ls /usr/local/lib/libgss* /usr/local/lib/libgssapi.a /usr/local/lib/libgssapi.la /usr/local/lib/libgssapi.so /usr/local/lib/libgssapi.so.2 Next I tried pkg_delete heimdal-1.0.1_1 and then srv02# ls /usr/local/bin/k* ls: No match. srv02# ls /usr/bin/k* /usr/bin/kadmin /usr/bin/kdump /usr/bin/keylogout /usr/bin/killall /usr/bin/klist /usr/bin/krb5-config /usr/bin/ktrace /usr/bin/kdestroy /usr/bin/keylogin /usr/bin/kgdb /usr/bin/kinit /usr/bin/kpasswd /usr/bin/ksu /usr/bin/ktrdump srv02# ls /usr/lib/libgss* /usr/lib/libgssapi.a /usr/lib/libgssapi_krb5.a /usr/lib/libgssapi_krb5_p.a /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libgssapi_spnego.a /usr/lib/libgssapi_spnego_p.a /usr/lib/libgssapi.so /usr/lib/libgssapi_krb5.so /usr/lib/libgssapi_ntlm.a /usr/lib/libgssapi_ntlm_p.a /usr/lib/libgssapi_spnego.so /usr/lib/libgssapi.so.10 /usr/lib/libgssapi_krb5.so.10 /usr/lib/libgssapi_ntlm.so /usr/lib/libgssapi_p.a /usr/lib/libgssapi_spnego.so.10 srv02# ls /usr/local/lib/libgss* ls: No match. so it would seem that the /usr/local heimdal is now gone, but some heimdal is still left in /usr ? looking at a different partition with a vanilla FreeBSD install I find the same files in /usr/lib and /usr/bin. maybe I did not have to install kerberos package at all ? I will play a bit more with this, but any more input would still be appreciated... /Henrik From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 19:58:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A63D31065670 for ; Wed, 14 Jul 2010 19:58:56 +0000 (UTC) (envelope-from henrik@kaarposoft.dk) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6B77B8FC1A for ; Wed, 14 Jul 2010 19:58:56 +0000 (UTC) Received: from [192.168.99.150] (x1-6-00-00-24-cc-93-b4.k874.webspeed.dk [87.52.11.120]) by pfepa.post.tele.dk (Postfix) with ESMTP id BF9A2A5001A; Wed, 14 Jul 2010 21:58:53 +0200 (CEST) Message-ID: <4C3E16FE.1040101@kaarposoft.dk> Date: Wed, 14 Jul 2010 21:58:54 +0200 From: Henrik /KaarPoSoft User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: George Mamalakis , freebsd-stable@freebsd.org References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <4C3D7BD9.5020503@eng.auth.gr> <20100714093208.GA29938@icarus.home.lan> <4C3D858E.8060208@eng.auth.gr> In-Reply-To: <4C3D858E.8060208@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 19:58:56 -0000 George Mamalakis wrote: > Unfortunately I have no time this week. I will be able to look at it > and send you a quick howto for openldap/cyrus/heimdal on Saturday. If > somebody else is able to do it sooner, it would be great. Please, > install it on i386 image, since amd64 didn't seem to have any problems > on my installation (at least on February). > That would be most appreciated! - Looking forward to the weekend ((-; /Henrik From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 21:14:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2781C1065679 for ; Wed, 14 Jul 2010 21:14:53 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id A13418FC0A for ; Wed, 14 Jul 2010 21:14:52 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id AE47D1CC69; Thu, 15 Jul 2010 00:14:51 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net AE47D1CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279142091; bh=vgYUKC2stKsphx5k+ThuB62rKPqPqcqHz7/sXKpwLQ0=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=f6HxRD5wxssuXPZU+JH0hRBvau+h9QMPtBQ2w5lydQnYsrUADsANFYdwRtYoP//z5 Dwzpz9KWf5W6v067QeefKwGQcZbiBDApY080bfmFaPWEuiEt9U41oy7J7eMeXz6G8c lfLmHm/y30S/8RUZU1tgRtVZgLt8oEuyEdqF4PqA= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gGYAs91Ig1Aq; Thu, 15 Jul 2010 00:14:46 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 51E4C1CC67; Thu, 15 Jul 2010 00:14:44 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 51E4C1CC67 Message-ID: <008D0251AE4F4A2DBAA1369410565B61@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" , "Henrik /KaarPoSoft" References: <4C3CC831.7040005@kaarposoft.dk><20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> In-Reply-To: <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> Date: Thu, 15 Jul 2010 00:14:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 21:14:53 -0000 > I had similar issue with 8-RELEASE and cyrus-sasl2 with = cyrus-saslauthd linked against system kerberos. > > (uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat = Jun 12 00:39:22 EEST 2010=20 > root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) > > The problem manifested itself with pretty much the same backtrace when = using cyradm tool for administering cyrus=20 > mailboxes and due time constraints I solved my issue by removing all = the gssapi plugin libs from /usr/local/lib/sasl2,=20 > so my solution isn't really applicable in your case. After building perl, cyrus-sasl2 and userland/kernel with debug symbols I was able to get the following backtrace. #0 free (ptr=3D0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 3889 arena_dalloc(chunk->arena, chunk, ptr); [New Thread 286ae140 (LWP 100273)] (gdb) bt #0 free (ptr=3D0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 #1 0x2899ed32 in gss_release_buffer (minor_status=3D0xbfbfe4b8, = buffer=3D0x280871cc) at=20 /usr/src/lib/libgssapi/gss_release_buffer.c:41 #2 0x2899e6e2 in _gss_mg_error (m=3D0x28a86480, maj=3D851968, min=3D2) = at /usr/src/lib/libgssapi/gss_display_status.c:240 #3 0x2899afd9 in gss_init_sec_context (minor_status=3D0xbfbfe5a4, = initiator_cred_handle=3D0x0, context_handle=3D0x28630164, target_name=3D0x2861b380, input_mech_type=3D0x0, req_flags=3D58, = time_req=3D0, input_chan_bindings=3D0x0, input_token=3D0x0, actual_mech_type=3D0x0, output_token=3D0xbfbfe5a8, = ret_flags=3D0xbfbfe594, time_rec=3D0x0) at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 #4 0x289936c9 in gssapi_client_mech_step (conn_context=3D0x28630160, = params=3D0x28a97080, serverin=3D0x0, serverinlen=3D0, prompt_need=3D0xbfbfe8b0, clientout=3D0xbfbfe8ac, = clientoutlen=3D0xbfbfe8a8, oparams=3D0x28a95860) at gssapi.c:1418 #5 0x285810f6 in sasl_client_step (conn=3D0x28a95000, serverin=3D0x0, = serverinlen=3D0, prompt_need=3D0xbfbfe8b0,=20 clientout=3D0xbfbfe8ac, clientoutlen=3D0xbfbfe8a8) at client.c:655 #6 0x28580ef7 in sasl_client_start (conn=3D0x28a95000, = mechlist=3D0x2861b360 "GSSAPI DIGEST-MD5 CRAM-MD5 ",=20 prompt_need=3D0xbfbfe8b0, clientout=3D0xbfbfe8ac, clientoutlen=3D0xbfbfe8a8, = mech=3D0xbfbfe8b8) at client.c:603 #7 0x2856a94c in imclient_authenticate () from = /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #8 0x28566f5e in XS_Cyrus__IMAP__authenticate () from=20 /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #9 0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888 #10 0x281878bc in Perl_runops_debug () at dump.c:1968 #11 0x280d80a9 in S_run_body (oldscope=3D1) at perl.c:2431 #12 0x280d7535 in perl_run (my_perl=3D0x28601100) at perl.c:2349 #13 0x08048930 in main (argc=3D6, argv=3D0xbfbfec44, env=3D0xbfbfec60) = at perlmain.c:117 I'm complete GDB-idjit though so any help in getting usable information from the following trace would be appreciated - I have the dump etc. stored away for further digging of course. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 21:41:09 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3143D106567A; Wed, 14 Jul 2010 21:41:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 14 Jul 2010 17:40:47 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C3DF48E.1070502@icyb.net.ua> In-Reply-To: <4C3DF48E.1070502@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007141740.55798.jkim@FreeBSD.org> Cc: Oliver Fromme , Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 21:41:09 -0000 On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: > on 14/07/2010 17:14 Oliver Fromme said the following: > > In a machine installed yesterday, 8.1-PRERELEASE doesn't > > seem to detect the number of CPU packages vs. cores per > > > > package correctly: > > | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC > > | 2010 [...] > > | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz > > | (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = > > | 0x1067a Family = 6 Model = 17 Stepping = 10 > > | Features=0xbfebfbff > |P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE > > |2,SS,HTT,TM,PBE> > > | Features2=0x40ce3bd > |X16,xTPR,PDCM,DCA,SSE4.1,XSAVE> AMD > > | Features=0x20000800 > > | AMD Features2=0x1 > > | TSC: P-state invariant > > | real memory = 34359738368 (32768 MB) > > | avail memory = 33151377408 (31615 MB) > > | ACPI APIC Table: > > | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > | FreeBSD/SMP: 1 package(s) x 8 core(s) > > | 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: 6 > > | cpu7 (AP): APIC ID: 7 > > | ioapic1 irqs 24-47 on motherboard > > | ioapic0 irqs 0-23 on motherboard > > > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > > with 4 cores per package), not 1 x 8. That's what the BIOS > > displays during POST. > > > > I'm not sure if this is just a "cosmetic" issue, or if this > > is a critical thing ... I could imagine that performance > > might be sub-optimal if the CPU topology isn't detected > > correctly, but I'm not sure if FreeBSD can take advantage > > of the topology. > > Could you please try to do the following? > 1. Fetch topo-12212009.tar from the top of this page: > http://software.intel.com/en-us/articles/intel-64-architecture-proc >essor-topology-enumeration/ 2. Untar it and apply this patch to the > code: > http://people.freebsd.org/~avg/cpu-topology.diff > 3. Compile it by running sh mk_64.sh (supposing you have amd64 > system installed) 4. Run cpu_topology64.out and report back its > output. It's funny that I actually wrote a convenience script (and cleaned up today): http://people.freebsd.org/~jkim/cpu_topology-12212009.sh BTW, current topology detection code is not optimal for some Intel processors if my memory serves. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 21:48:20 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B8E71065714; Wed, 14 Jul 2010 21:48:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D86A78FC13; Wed, 14 Jul 2010 21:48:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA16856; Thu, 15 Jul 2010 00:48:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OZ9oO-000Odr-QR; Thu, 15 Jul 2010 00:48:16 +0300 Message-ID: <4C3E309F.2030100@icyb.net.ua> Date: Thu, 15 Jul 2010 00:48:15 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C3DF48E.1070502@icyb.net.ua> <201007141740.55798.jkim@FreeBSD.org> In-Reply-To: <201007141740.55798.jkim@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Oliver Fromme , freebsd-stable@FreeBSD.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 21:48:20 -0000 on 15/07/2010 00:40 Jung-uk Kim said the following: > It's funny that I actually wrote a convenience script (and cleaned up > today): > > http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > > BTW, current topology detection code is not optimal for some Intel > processors if my memory serves. Indeed. Your patch looks so much cleaner too. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jul 14 21:55:14 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4BA031065688; Wed, 14 Jul 2010 21:55:14 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 14 Jul 2010 17:55:03 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C3DF48E.1070502@icyb.net.ua> <201007141740.55798.jkim@FreeBSD.org> In-Reply-To: <201007141740.55798.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007141755.04690.jkim@FreeBSD.org> Cc: Oliver Fromme , Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jul 2010 21:55:14 -0000 On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: > On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: > > on 14/07/2010 17:14 Oliver Fromme said the following: > > > In a machine installed yesterday, 8.1-PRERELEASE doesn't > > > seem to detect the number of CPU packages vs. cores per > > > > > > package correctly: > > > | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC > > > | 2010 [...] > > > | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz > > > | (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = > > > | 0x1067a Family = 6 Model = 17 Stepping = 10 > > > | Features=0xbfebfbff > > |SE > > > | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, > > > |SSE 2,SS,HTT,TM,PBE> > > > | Features2=0x40ce3bd > > |,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE> AMD > > > | Features=0x20000800 > > > | AMD Features2=0x1 > > > | TSC: P-state invariant > > > | real memory = 34359738368 (32768 MB) > > > | avail memory = 33151377408 (31615 MB) > > > | ACPI APIC Table: > > > | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > > | FreeBSD/SMP: 1 package(s) x 8 core(s) > > > | 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: 6 > > > | cpu7 (AP): APIC ID: 7 > > > | ioapic1 irqs 24-47 on motherboard > > > | ioapic0 irqs 0-23 on motherboard > > > > > > I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > > > with 4 cores per package), not 1 x 8. That's what the BIOS > > > displays during POST. > > > > > > I'm not sure if this is just a "cosmetic" issue, or if this > > > is a critical thing ... I could imagine that performance > > > might be sub-optimal if the CPU topology isn't detected > > > correctly, but I'm not sure if FreeBSD can take advantage > > > of the topology. > > > > Could you please try to do the following? > > 1. Fetch topo-12212009.tar from the top of this page: > > http://software.intel.com/en-us/articles/intel-64-architecture-pr > >oc essor-topology-enumeration/ 2. Untar it and apply this patch to > > the code: > > http://people.freebsd.org/~avg/cpu-topology.diff > > 3. Compile it by running sh mk_64.sh (supposing you have amd64 > > system installed) 4. Run cpu_topology64.out and report back its > > output. > > It's funny that I actually wrote a convenience script (and cleaned > up today): > > http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > > BTW, current topology detection code is not optimal for some Intel > processors if my memory serves. Surprisingly, I found a patch I wrote last year from /tmp of my desktop and it is still applied cleanly. 8-) Just in case, it is available from here: http://people.freebsd.org/~jkim/mp_machdep.diff It is applicable to both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't been used for more than a year, so it may not work at all. ;-) Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 10:22:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16FBB106566C for ; Thu, 15 Jul 2010 10:22:51 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A14568FC0C for ; Thu, 15 Jul 2010 10:22:50 +0000 (UTC) Received: by wwc33 with SMTP id 33so2060863wwc.31 for ; Thu, 15 Jul 2010 03:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DkmA3dho4RYJ/HgBFZfgk6v35mTHZ38Qm3v3rBZrNDk=; b=vAhcpQmsWDWOD3AuTXr2n7+4LouRs1ZNkR70jnLRyCHd/ETq9blNV9Kx4tT9OMUrlZ 6kB5oYviMiffsKhwLpH0PYlr26rS4CoUzSxarfig1g1/XhjavRHBNrUH8RkiRtt2RHRC TMDubMoadXPMcM4LiVtztbCuhSeAKyMLe+uN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jcHHcknk288SiJ9/9oP9t3gufjGtYr+vxAN3JV2eCWsP82gKFfzsp6rZYoWB38qmrH xcD6XxQ0SipjCeSyEH4YJgODPeI3TqH00sukQz8F+ihQ3E8H5J2SmLUeT1Q9vICgN2Dk OD4Dbs+em0xLd+HcMLtnifsQIcAOfz+GsQdmg= MIME-Version: 1.0 Received: by 10.227.129.84 with SMTP id n20mr17489003wbs.61.1279189369362; Thu, 15 Jul 2010 03:22:49 -0700 (PDT) Received: by 10.216.137.23 with HTTP; Thu, 15 Jul 2010 03:22:49 -0700 (PDT) In-Reply-To: <201007141414.o6EEEUx9014690@lurza.secnetix.de> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> Date: Thu, 15 Jul 2010 14:22:49 +0400 Message-ID: From: pluknet To: Oliver Fromme Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 10:22:51 -0000 On 14 July 2010 18:14, Oliver Fromme wrote: > In a machine installed yesterday, 8.1-PRERELEASE doesn't > seem to detect the number of CPU packages vs. cores per > package correctly: > > =A0| FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC 2010 > =A0| [...] > =A0| CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 L5408 =A0@ 2.13GHz (21= 33.42-MHz K8-class CPU) > =A0| =A0 Origin =3D "GenuineIntel" =A0Id =3D 0x1067a =A0Family =3D 6 =A0M= odel =3D 17 =A0Stepping =3D 10 > =A0| =A0 Features=3D0xbfebfbff > =A0| =A0 Features2=3D0x40ce3bd > =A0| =A0 AMD Features=3D0x20000800 > =A0| =A0 AMD Features2=3D0x1 > =A0| =A0 TSC: P-state invariant > =A0| real memory =A0=3D 34359738368 (32768 MB) > =A0| avail memory =3D 33151377408 (31615 MB) > =A0| ACPI APIC Table: > =A0| FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > =A0| FreeBSD/SMP: 1 package(s) x 8 core(s) Just for the reference, I collected CPU detection from various branches. 6.4 Cores per package: 4 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 7.3 Cores per package: 4 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs 8.1-rc FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) Indeed, looks like a regression. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 11:58:36 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C881065670 for ; Thu, 15 Jul 2010 11:58:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB2A48FC15 for ; Thu, 15 Jul 2010 11:58:35 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6FBwJ7F066824; Thu, 15 Jul 2010 13:58:34 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6FBwJI8066822; Thu, 15 Jul 2010 13:58:19 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007151158.o6FBwJI8066822@lurza.secnetix.de> To: avg@icyb.net.ua (Andriy Gapon) Date: Thu, 15 Jul 2010 13:58:19 +0200 (CEST) In-Reply-To: <4C3DF48E.1070502@icyb.net.ua> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 15 Jul 2010 13:58:34 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 11:58:36 -0000 Andriy Gapon wrote: > Could you please try to do the following? > 1. Fetch topo-12212009.tar from the top of this page: > http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ > 2. Untar it and apply this patch to the code: > http://people.freebsd.org/~avg/cpu-topology.diff > 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) > 4. Run cpu_topology64.out and report back its output. Ok, did that. This tool seems to get it right, i.e. it detects 2 packages with 4 cores each. Here's the output: Software visible enumeration in the system: Number of logical processors visible to the OS: 8 Number of logical processors visible to this process: 8 Number of processor cores visible to this process: 8 Number of physical packages visible to this process: 2 Hierarchical counts by levels of processor topology: # of cores in package 0 visible to this process: 4 . # of cores in package 1 visible to this process: 4 . Affinity masks per SMT thread, per core, per package: Individual: P:0, C:0, T:0 --> 1 Core-aggregated: P:0, C:0 --> 1 Individual: P:0, C:1, T:0 --> 2 Core-aggregated: P:0, C:1 --> 2 Individual: P:0, C:2, T:0 --> 4 Core-aggregated: P:0, C:2 --> 4 Individual: P:0, C:3, T:0 --> 8 Core-aggregated: P:0, C:3 --> 8 Pkg-aggregated: P:0 --> f Individual: P:1, C:0, T:0 --> 10 Core-aggregated: P:1, C:0 --> 10 Individual: P:1, C:1, T:0 --> 20 Core-aggregated: P:1, C:1 --> 20 Individual: P:1, C:2, T:0 --> 40 Core-aggregated: P:1, C:2 --> 40 Individual: P:1, C:3, T:0 --> 80 Core-aggregated: P:1, C:3 --> 80 Pkg-aggregated: P:1 --> f0 APIC ID listings from affinity masks OS cpu 0, Affinity mask 0001 - apic id 0 OS cpu 1, Affinity mask 0002 - apic id 1 OS cpu 2, Affinity mask 0004 - apic id 2 OS cpu 3, Affinity mask 0008 - apic id 3 OS cpu 4, Affinity mask 0010 - apic id 4 OS cpu 5, Affinity mask 0020 - apic id 5 OS cpu 6, Affinity mask 0040 - apic id 6 OS cpu 7, Affinity mask 0080 - apic id 7 Package 0 Cache and Thread details Box Description: Cache is cache level designator Size is cache size OScpu# is cpu # as seen by OS Core is core#[_thread# if > 1 thread/core] inside socket AffMsk is AffinityMask(extended hex) for core and thread CmbMsk is Combined AffinityMask(extended hex) for hw threads sharing cache CmbMsk will differ from AffMsk if > 1 hw_thread/cache Extended Hex replaces trailing zeroes with 'z#' where # is number of zeroes (so '8z5' is '0x800000') L1D is Level 1 Data cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= 4 L1I is Level 1 Instruction cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= 4 L2 is Level 2 Unified cache, size(KBytes)= 6144, Cores/cache= 2, Caches/package= 2 +----+----+----+----+ Cache | L1D| L1D| L1D| L1D| Size | 32K| 32K| 32K| 32K| OScpu#| 0| 1| 2| 3| Core | c0| c1| c2| c3| AffMsk| 1| 2| 4| 8| +----+----+----+----+ Cache | L1I| L1I| L1I| L1I| Size | 32K| 32K| 32K| 32K| +----+----+----+----+ Cache | L2 | L2 | Size | 6M | 6M | CmbMsk| 3 | c | +---------+---------+ Combined socket AffinityMask= 0xf Package 1 Cache and Thread details Box Description: Cache is cache level designator Size is cache size OScpu# is cpu # as seen by OS Core is core#[_thread# if > 1 thread/core] inside socket AffMsk is AffinityMask(extended hex) for core and thread CmbMsk is Combined AffinityMask(extended hex) for hw threads sharing cache CmbMsk will differ from AffMsk if > 1 hw_thread/cache Extended Hex replaces trailing zeroes with 'z#' where # is number of zeroes (so '8z5' is '0x800000') +----+----+----+----+ Cache | L1D| L1D| L1D| L1D| Size | 32K| 32K| 32K| 32K| OScpu#| 4| 5| 6| 7| Core | c0| c1| c2| c3| AffMsk| 10| 20| 40| 80| +----+----+----+----+ Cache | L1I| L1I| L1I| L1I| Size | 32K| 32K| 32K| 32K| +----+----+----+----+ Cache | L2 | L2 | Size | 6M | 6M | CmbMsk| 30 | c0 | +---------+---------+ Combined socket AffinityMask= 0xf0 -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 12:03:15 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8647E1065686 for ; Thu, 15 Jul 2010 12:03:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D3F4F8FC0A for ; Thu, 15 Jul 2010 12:03:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA29759; Thu, 15 Jul 2010 15:03:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C3EF8FA.4080005@icyb.net.ua> Date: Thu, 15 Jul 2010 15:03:06 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Oliver Fromme References: <201007151158.o6FBwJI8066822@lurza.secnetix.de> In-Reply-To: <201007151158.o6FBwJI8066822@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 12:03:15 -0000 on 15/07/2010 14:58 Oliver Fromme said the following: > Andriy Gapon wrote: > > Could you please try to do the following? > > 1. Fetch topo-12212009.tar from the top of this page: > > http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ > > 2. Untar it and apply this patch to the code: > > http://people.freebsd.org/~avg/cpu-topology.diff > > 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) > > 4. Run cpu_topology64.out and report back its output. > > Ok, did that. This tool seems to get it right, i.e. it > detects 2 packages with 4 cores each. Here's the output: Great! So perhaps you can now test jkim's patch posted in this thread? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 12:05:37 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E5B1065674 for ; Thu, 15 Jul 2010 12:05:37 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD198FC18 for ; Thu, 15 Jul 2010 12:05:37 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6FC5LTK067418; Thu, 15 Jul 2010 14:05:36 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6FC5LXY067416; Thu, 15 Jul 2010 14:05:21 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007151205.o6FC5LXY067416@lurza.secnetix.de> To: avg@icyb.net.ua (Andriy Gapon) Date: Thu, 15 Jul 2010 14:05:20 +0200 (CEST) In-Reply-To: <4C3EF8FA.4080005@icyb.net.ua> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 15 Jul 2010 14:05:36 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 12:05:37 -0000 Andriy Gapon wrote: > on 15/07/2010 14:58 Oliver Fromme said the following: > > Andriy Gapon wrote: > > > Could you please try to do the following? > > > 1. Fetch topo-12212009.tar from the top of this page: > > > http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ > > > 2. Untar it and apply this patch to the code: > > > http://people.freebsd.org/~avg/cpu-topology.diff > > > 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) > > > 4. Run cpu_topology64.out and report back its output. > > > > Ok, did that. This tool seems to get it right, i.e. it > > detects 2 packages with 4 cores each. Here's the output: > > Great! > So perhaps you can now test jkim's patch posted in this thread? Sure, the kernel is being compiled right now ... -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 12:27:41 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE768106564A for ; Thu, 15 Jul 2010 12:27:41 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE788FC0C for ; Thu, 15 Jul 2010 12:27:41 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6FCROw1068669; Thu, 15 Jul 2010 14:27:40 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6FCROGd068668; Thu, 15 Jul 2010 14:27:24 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007151227.o6FCROGd068668@lurza.secnetix.de> To: avg@icyb.net.ua (Andriy Gapon) Date: Thu, 15 Jul 2010 14:27:24 +0200 (CEST) In-Reply-To: <4C3EF8FA.4080005@icyb.net.ua> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 15 Jul 2010 14:27:40 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 12:27:41 -0000 Andriy Gapon wrote: > on 15/07/2010 14:58 Oliver Fromme said the following: > > Andriy Gapon wrote: > > > Could you please try to do the following? > > > 1. Fetch topo-12212009.tar from the top of this page: > > > http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ > > > 2. Untar it and apply this patch to the code: > > > http://people.freebsd.org/~avg/cpu-topology.diff > > > 3. Compile it by running sh mk_64.sh (supposing you have amd64 system installed) > > > 4. Run cpu_topology64.out and report back its output. > > > > Ok, did that. This tool seems to get it right, i.e. it > > detects 2 packages with 4 cores each. Here's the output: > > Great! > So perhaps you can now test jkim's patch posted in this thread? Unfortunately, it didn't change. Kernel output during boot is still the same; it displays 1 package x 8 cores. Best regards Oliver PS: "make kernel -j 10" took exactly 8 minutes on this box. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 12:36:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9C6106567F for ; Thu, 15 Jul 2010 12:36:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id C4AA48FC1B for ; Thu, 15 Jul 2010 12:36:33 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta12.emeryville.ca.mail.comcast.net with comcast id iCWb1e0040mlR8UACCcZpU; Thu, 15 Jul 2010 12:36:33 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.emeryville.ca.mail.comcast.net with comcast id iCcX1e0053LrwQ28XCcXe6; Thu, 15 Jul 2010 12:36:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0AD0E9B425; Thu, 15 Jul 2010 05:36:31 -0700 (PDT) Date: Thu, 15 Jul 2010 05:36:31 -0700 From: Jeremy Chadwick To: Henrik /KaarPoSoft Message-ID: <20100715123631.GA69253@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <4C3E0D7D.5020305@kaarposoft.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3E0D7D.5020305@kaarposoft.dk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mamalos@eng.auth.gr, freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 12:36:34 -0000 On Wed, Jul 14, 2010 at 09:18:21PM +0200, Henrik /KaarPoSoft wrote: > On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: > >>I have a problem: ldapsearch results in "Segmentation fault" under > >>openldap-2.4.23 with cyrus-sasl-2.1.23. > >>[...] > > Jeremy Chadwick wrote: > >If I was to build a test box from scratch, can you tell me how to set up > >all the necessary software/etc. to mimic your environment so that I > >could try to reproduce this? Reviewing the source isn't enough, I'd > >have to actually build a debug version of libgssapi to track it down. > Jeremy, I would really appreciate your going through this! > Thank you very much in advance. > > Here is what I did: > > > FreeBSD 8.0 vanilla install > hostname: srv02.example.lan > > freebsd-update fetch > freebsd-update install > > Create self-signed "CA" cert, and create SSL cert for LDAP signed by this. > References: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssl.html > http://forums.freebsd.org/showthread.php?t=6490 > http://www.freebsdmadeeasy.com/tutorials/freebsd/create-a-ca-with-openssl.php > > pkg_add -r heimdal > > cat >> /etc/rc.conf > kerberos5_server_enable="YES" > kadmind5_server_enable="YES" > > cat > /etc/krb5.conf > [libdefaults] > default_realm = EXAMPLE.LAN > > kstash > > kadmin -l > kadmin> init EXAMPLE.LAN > kadmin> add TestOne > kadmin> list "*" > > /etc/rc.d/kerberos start > /etc/rc.d/kadmind start > > Add to nameserver: > > kerberos.example.lan CNAME srv02.example.lan > ldap.example.lan CNAME srv02.example.lan > _kerberos IN TXT kerberos.example.lan > _kerberos._udp.example.lan. IN SRV 0 0 88 kerberos.example.lan. > _kerberos._tcp.example.lan. IN SRV 0 0 88 kerberos.example.lan. > _kerberos-adm._tcp.example.lan. IN SRV 0 0 749 kerberos.example.lan. > _kpasswd._udp.example.lan. IN SRV 0 0 464 kerberos.example.lan. > > cd /usr/ports > portsnap fetch > portsnap extract > > (and subsequently portsnap fetch update) > > cd /usr/ports/security/cyrus-sasl2 > make config > [X] Berkeley DB > [X] /dev/urandom > make > make install > > cd /usr/ports/net/openldap24-sasl-client > make > make install > > cd /usr/ports/net/openldap24-server > make config > [x] SASL > make > > cat >> /etc/rc.conf > slapd_enable="YES" > slapd_flags="-h ldaps:///" > > touch /var/db/openldap-data/DB_CONFIG > > srv02# diff /usr/local/etc/openldap/slapd.conf.ORIG > /usr/local/etc/openldap/slapd.conf > 48a50,80 > > > > ####################################################################### > > # EXAMPLE > > ####################################################################### > > > > #=# Shemas we need > > include /usr/local/etc/openldap/schema/cosine.schema > > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/inetorgperson.schema > > > > #=# Logging > > loglevel stats stats2 shell parse ACL config filter BER conns > > > > > > #=# GSSAPI mapping > > #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > #=# http://www.openldap.org/doc/admin24/sasl.html#Mapping > Authentication Identities > > > > authz-regexp > > uid=([^,]*),cn=example.lan,cn=gssapi,cn=auth > > uid=$1,ou=Users,dc=example,dc=lan > > > > > > #=# LDAP over TSL (SSL) > > #=# http://www.openldap.org/doc/admin24/tls.html > > > > security ssf=128 > > TLSCertificateFile /etc/exampleCA/certs/ldap.pem > > TLSCertificateKeyFile /etc/exampleCA/private/ldap.pem > > TLSCACertificateFile /etc/exampleCA/certs/example.pem > > > 54,55c86,93 > < suffix "dc=my-domain,dc=com" > < rootdn "cn=Manager,dc=my-domain,dc=com" > --- > > > > #=# The example Network > > suffix "dc=example,dc=lan" > > > > #=# The rootdn user, authenticated by Kerberos > > #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > rootdn "uid=LDAProot,cn=example.lan,cn=gssapi,cn=auth" > > > 59c97,99 > < rootpw secret > --- > > > > #=# Since rootdn is authenticated by Kerberos, we do not need rootpw > > #rootpw secret > 65a106 > > Add domain and a few users with slapadd > > cat >> /usr/local/etc/openldap/ldap.conf > base dc=example,dc=lan > uri ldaps://ldap.example.lan/ > tls_cacert /etc/exampleCA/cacert.pem Thank you for this. I'm in the process of building the machine with debugging symbols on libraries/binaries now (DEBUG_FLAGS=-g3 -ggdb in src.conf). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 12:38:42 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 894DD106567B for ; Thu, 15 Jul 2010 12:38:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B95C88FC23 for ; Thu, 15 Jul 2010 12:38:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA00786; Thu, 15 Jul 2010 15:38:34 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C3F0149.1070500@icyb.net.ua> Date: Thu, 15 Jul 2010 15:38:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Oliver Fromme References: <201007151227.o6FCROGd068668@lurza.secnetix.de> In-Reply-To: <201007151227.o6FCROGd068668@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 12:38:42 -0000 on 15/07/2010 15:27 Oliver Fromme said the following: > Unfortunately, it didn't change. Kernel output during boot > is still the same; it displays 1 package x 8 cores. If you are sure that everything is done correctly (patch really applied, kernel really rebuilt and reinstalled, and reboot was to the new kernel), then perhaps jkim would be interested in this issue. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 15:14:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F7A81065677 for ; Thu, 15 Jul 2010 15:14:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 35A038FC1D for ; Thu, 15 Jul 2010 15:14:38 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta07.emeryville.ca.mail.comcast.net with comcast id iDJh1e0041HpZEsA7FEe8y; Thu, 15 Jul 2010 15:14:38 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta14.emeryville.ca.mail.comcast.net with comcast id iFEZ1e00A3LrwQ28aFEaPF; Thu, 15 Jul 2010 15:14:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 26EEB9B425; Thu, 15 Jul 2010 08:14:33 -0700 (PDT) Date: Thu, 15 Jul 2010 08:14:33 -0700 From: Jeremy Chadwick To: Henrik /KaarPoSoft Message-ID: <20100715151433.GA71946@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <4C3E0D7D.5020305@kaarposoft.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3E0D7D.5020305@kaarposoft.dk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mamalos@eng.auth.gr, freebsd-stable@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 15:14:39 -0000 On Wed, Jul 14, 2010 at 09:18:21PM +0200, Henrik /KaarPoSoft wrote: > On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote: > >>I have a problem: ldapsearch results in "Segmentation fault" under > >>openldap-2.4.23 with cyrus-sasl-2.1.23. > >>[...] > > Jeremy Chadwick wrote: > >If I was to build a test box from scratch, can you tell me how to set up > >all the necessary software/etc. to mimic your environment so that I > >could try to reproduce this? Reviewing the source isn't enough, I'd > >have to actually build a debug version of libgssapi to track it down. > Jeremy, I would really appreciate your going through this! > Thank you very much in advance. > > Here is what I did: > > [...] Before I get started, I should note that the system I'm testing on was built with the following two features in src.conf and make.conf; the lesser is for world, the lesser for world, respectively. /etc/src.conf: DEBUG_FLAGS=-g3 -ggdb /etc/make.conf: CFLAGS+=-g3 -ggdb > [...] I did not create a CA + self-signed SSL cert at this point, I save that for later (see bottom), where I've also run into a complexity. > cat > /etc/krb5.conf > [libdefaults] > default_realm = EXAMPLE.LAN > > kstash At this point kstash asked for a "Master Key" and for me to validate it. I just hit enter at both prompts. I don't know if that's correct (I'm not familiar with Kerberos administration). > kadmin -l > kadmin> init EXAMPLE.LAN At this point I was prompted for "Realm max ticket life" and "Realm max renewable ticket life". I chose the defaults of unlimited. > kadmin> add TestOne At this point I was prompted for numerous parameters (max ticket life, max renewable life, principle expiration time, password expiration time, attributes, and a password + verification). I hit enter at all the prompts. > kadmin> list "*" For me, this returned: TestOne default kadmin/admin kadmin/hprop hadmin/changepw changepw/kerberos krbtgt/EXAMPLE.LAN > cd /usr/ports/security/cyrus-sasl2 > make config > [X] Berkeley DB > [X] /dev/urandom > make > make install During the configure stage a warning caught my eye: checking for crypt in -lcrypt... yes configure: WARNING: The system type is not recognized. If you believe that CyberSafe GSSAPI works on this platform, please update the configure script checking gssapi.h usability... yes checking gssapi.h presence... yes checking for gssapi.h... yes checking for res_search in -lresolv... no checking for gss_unwrap in -lgssapi... yes checking GSSAPI... with implementation heimdal checking for res_search in -lresolv... (cached) no checking for gsskrb5_register_acceptor_identity... no checking to use mutexes aroung GSS calls... no Just noting that here for posterity. It may be safe. I simply don't know. > cd /usr/ports/net/openldap24-sasl-client > make > make install At this point I was prompted for OPTIONS, and SASL (for "Cyrus SASL 2 Support") was not checked, so I checked it. This seems strange; a port called "sasl-client" asking me if I want SASL support? Seems like that should be implied given the port name -- could be a stub port issue. I just hope I chose the right option. > cd /usr/ports/net/openldap24-server > make config > [x] SASL > make At this point OPTIONS already had SASL checked, so I went with that. I also kept the default options, which were all unchecked except the following: FETCH, TCP_WRAPPERS, SEQMOD, SYNCPROV, and DYNAMIC_BACKENDS. I should point out that this port pulled in db46-4.6.21.4, while the security/cyrus-sasl2 port pulled in db41-4.1.25_4. I don't think this will be a problem since I don't see any SleepyCat/Oracle DB calls in the stack trace. Just noting it here for posterity. Next, during the configure phase (since we're discussing cyrus-sasl2), I saw this: checking sasl/sasl.h usability... yes checking sasl/sasl.h presence... yes checking for sasl/sasl.h... yes checking sasl.h usability... no checking sasl.h presence... no checking for sasl.h... no checking for sasl_client_init in -lsasl2... yes checking Cyrus SASL library version... yes checking for sasl_version... yes checking fetch(3) library... yes checking for crypt... no checking for crypt in -lcrypt... yes I also did "make install" after "make". > cat >> /etc/rc.conf > slapd_enable="YES" > slapd_flags="-h ldaps:///" > > touch /var/db/openldap-data/DB_CONFIG > > srv02# diff /usr/local/etc/openldap/slapd.conf.ORIG /usr/local/etc/openldap/slapd.conf This is where things got a little wild (I hate contextual diffs). I added the following lines to slapd.conf before the "BDB database definitions" section: ####################################################################### # EXAMPLE ####################################################################### #=# Shemas we need include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #=# Logging loglevel stats stats2 shell parse ACL config filter BER conns #=# GSSAPI mapping #=# http://www.openldap.org/doc/admin24/sasl.html#GSSAPI #=# http://www.openldap.org/doc/admin24/sasl.html#Mapping Authentication Identities authz-regexp uid=([^,]*),cn=example.lan,cn=gssapi,cn=auth uid=$1,ou=Users,dc=example,dc=lan #=# LDAP over TSL (SSL) #=# http://www.openldap.org/doc/admin24/tls.html security ssf=128 TLSCertificateFile /etc/certs/new.crt TLSCertificateKeyFile /etc/certs/myca.key TLSCACertificateFile /etc/certs/new.crt Note that my TLS* lines are changed. See bottom of the mail. Then I modified the following already-existing lines to contain the following (which should match your diff): suffix "dc=example,dc=lan" rootdn "uid=LDAProot,cn=example.lan,cn=gssapi,cn=auth" Finally, I commented out the "rootpw secret" line. > [...] > cat >> /usr/local/etc/openldap/ldap.conf > base dc=example,dc=lan > uri ldaps://ldap.example.lan/ > tls_cacert /etc/exampleCA/cacert.pem I modified tls_cacert above in my configuration to look like this (keep reading): tls_cacert /etc/certs/myca.key At this point your steps end, so I took an educated guess. Note that I'm familiar with creating SSL certificates + requests, but getting them signed by a CA is something I usually rely upon a public CA for, not creating my own CA and self-signing my certs, so I may have gotten something wrong here. I followed this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssl.html What's confusing here is that your configuration refers to 4 separate PEMs: /etc/exampleCA/certs/ldap.pem /etc/exampleCA/private/ldap.pem /etc/exampleCA/certs/example.pem /etc/exampleCA/cacert.pem The FreeBSD documentation, for self-signed certs, only refers to two (new.crt and myca.key). I made the assumption that in this test setup I'm working with, I actually want to do the following: # mkdir /etc/certs # cd /etc/certs # openssl dsaparam -rand -genkey -out myRSA.key 1024 # openssl gendsa -des3 -out myca.key myRSA.key [...entered in a 4 character PEM key of "abcd"...] # openssl req -new -x509 -days 365 -key myca.key -out new.crt [...] Common Name (eg, YOUR name) []:ldap.example.lan [...] # /usr/local/etc/rc.d/slapd start Starting slapd. /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd syslog shows this is the error: Jul 15 08:08:47 testbox slapd[61084]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 15 2010 07:31:07) $ root@testbox.example.lan:/usr/ports/net/openldap24-server/work/openldap-2.4.23/servers/slapd Jul 15 08:08:48 testbox slapd[61084]: line 65 (authz-regexp) Jul 15 08:08:48 testbox slapd[61084]: /usr/local/etc/openldap/slapd.conf: line 65: keyword missing argument If you'd rather set all of this stuff up yourself (vs. me fiddling around with it, since I really don't know how to configure all of this), I can provide you root-level SSH access to the testbox and can let you build + configure everything yourself. Just let me know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 15:17:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E7E11065672 for ; Thu, 15 Jul 2010 15:17:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 155498FC19 for ; Thu, 15 Jul 2010 15:17:48 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta05.emeryville.ca.mail.comcast.net with comcast id iDQu1e0031afHeLA5FHoyA; Thu, 15 Jul 2010 15:17:48 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta17.emeryville.ca.mail.comcast.net with comcast id iFHm1e00N3LrwQ28dFHn5Z; Thu, 15 Jul 2010 15:17:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BEDCA9B425; Thu, 15 Jul 2010 08:17:46 -0700 (PDT) Date: Thu, 15 Jul 2010 08:17:46 -0700 From: Jeremy Chadwick To: Henrik /KaarPoSoft Message-ID: <20100715151746.GA73853@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <4C3E0D7D.5020305@kaarposoft.dk> <20100715151433.GA71946@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100715151433.GA71946@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, mamalos@eng.auth.gr Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 15:17:49 -0000 On Thu, Jul 15, 2010 at 08:14:33AM -0700, Jeremy Chadwick wrote: > Before I get started, I should note that the system I'm testing on was > built with the following two features in src.conf and make.conf; > the lesser is for world, the lesser for world, respectively. > > /etc/src.conf: DEBUG_FLAGS=-g3 -ggdb > /etc/make.conf: CFLAGS+=-g3 -ggdb This should have read "the lesser is the world, the latter is for ports". -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 16:22:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3539A1065676 for ; Thu, 15 Jul 2010 16:22:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id D37E18FC18 for ; Thu, 15 Jul 2010 16:22:53 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta15.westchester.pa.mail.comcast.net with comcast id iBR81e0031ei1Bg5FGNt3c; Thu, 15 Jul 2010 16:22:53 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.westchester.pa.mail.comcast.net with comcast id iGNs1e00C3LrwQ23kGNsKQ; Thu, 15 Jul 2010 16:22:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1EC0E9B425; Thu, 15 Jul 2010 09:22:51 -0700 (PDT) Date: Thu, 15 Jul 2010 09:22:51 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100715162251.GA73929@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008D0251AE4F4A2DBAA1369410565B61@rivendell> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 16:22:54 -0000 On Thu, Jul 15, 2010 at 12:14:58AM +0300, Reko Turja wrote: > >I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked against system kerberos. > > > >(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: > >Sat Jun 12 00:39:22 EEST 2010 > >root@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386) > > > >The problem manifested itself with pretty much the same backtrace > >when using cyradm tool for administering cyrus mailboxes and due > >time constraints I solved my issue by removing all the gssapi > >plugin libs from /usr/local/lib/sasl2, so my solution isn't really > >applicable in your case. > > After building perl, cyrus-sasl2 and userland/kernel with debug symbols > I was able to get the following backtrace. > > #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 > 3889 arena_dalloc(chunk->arena, chunk, ptr); > [New Thread 286ae140 (LWP 100273)] > (gdb) bt > #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 > #1 0x2899ed32 in gss_release_buffer (minor_status=0xbfbfe4b8, > buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 > #2 0x2899e6e2 in _gss_mg_error (m=0x28a86480, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240 > #3 0x2899afd9 in gss_init_sec_context (minor_status=0xbfbfe5a4, initiator_cred_handle=0x0, context_handle=0x28630164, > target_name=0x2861b380, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0, > actual_mech_type=0x0, output_token=0xbfbfe5a8, ret_flags=0xbfbfe594, time_rec=0x0) > at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 > #4 0x289936c9 in gssapi_client_mech_step (conn_context=0x28630160, params=0x28a97080, serverin=0x0, serverinlen=0, > prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, oparams=0x28a95860) at gssapi.c:1418 > #5 0x285810f6 in sasl_client_step (conn=0x28a95000, serverin=0x0, > serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, > clientoutlen=0xbfbfe8a8) at client.c:655 > #6 0x28580ef7 in sasl_client_start (conn=0x28a95000, > mechlist=0x2861b360 "GSSAPI DIGEST-MD5 CRAM-MD5 ", > prompt_need=0xbfbfe8b0, > clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, mech=0xbfbfe8b8) at client.c:603 > #7 0x2856a94c in imclient_authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so > #8 0x28566f5e in XS_Cyrus__IMAP__authenticate () from > /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so > #9 0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888 > #10 0x281878bc in Perl_runops_debug () at dump.c:1968 > #11 0x280d80a9 in S_run_body (oldscope=1) at perl.c:2431 > #12 0x280d7535 in perl_run (my_perl=0x28601100) at perl.c:2349 > #13 0x08048930 in main (argc=6, argv=0xbfbfec44, env=0xbfbfec60) at perlmain.c:117 > > I'm complete GDB-idjit though so any help in getting usable information > from the following trace would be appreciated - I have the dump etc. > stored away for further digging of course. The dump is only useful if it's used on that exact system it came from, so don't rebuild any of the software/etc. until we get this figured out. The code in question: src/lib/libgssapi/gss_display_status.c 186 struct mg_thread_ctx { 187 gss_OID mech; 188 OM_uint32 maj_stat; 189 OM_uint32 min_stat; 190 gss_buffer_desc maj_error; 191 gss_buffer_desc min_error; 192 }; ... 231 void 232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj, OM_uint32 min) 233 { 234 OM_uint32 major_status, minor_status; 235 OM_uint32 message_content; 236 struct mg_thread_ctx *mg; 237 238 mg = &last_error_context; 239 240 gss_release_buffer(&minor_status, &mg->maj_error); 241 gss_release_buffer(&minor_status, &mg->min_error); src/lib/libgssapi/gss_release_buffer.c 34 OM_uint32 35 gss_release_buffer(OM_uint32 *minor_status, 36 gss_buffer_t buffer) 37 { 38 39 *minor_status = 0; 40 if (buffer->value) 41 free(buffer->value); src/include/gssapi/gssapi.h 106 typedef struct gss_buffer_desc_struct { 107 size_t length; 108 void *value; 109 } gss_buffer_desc, *gss_buffer_t; So I'm going to take a shot in the dark at this one, with some supporting evidence. It looks like gss_release_buffer.c:40 is improper/incomplete -- it's only checking to see if the pointer is non-NULL, and then blindly calls free(). It doesn't bother to check to see if buffer->length is non-zero. It seems gss_release_buffer() is basically mindless about what it frees anyway, which is bad design given the complexity of this thing. Well, some MIT Kerberos dudes complained about it too, and solved it by adding "magic numbers" to the structure so that you can tell what "type" of buffer it is: http://krbdev.mit.edu/rt/Ticket/Display.html?id=2145 The patch/code there is in no way shape or form compatible with what we have in our repo... but I did notice something interesting in their gss_release_buffer() routine/diff which correlates with my idea: - if ((buffer->length) && - (buffer->value)) { They're checking both buffer->length *and* buffer->value. We're not. That said, can you please execute the following in gdb and provide the output? (gdb) p/x gss_release_buffer.c::buffer->value (gdb) p/x gss_release_buffer.c::buffer->length Furthermore, relevant bug (PR 144754) indicates there's an easier way to induce this problem, so I'm going to see if I can reproduce it here locally. It's almost certainly the same problem but induced via a slightly different context. http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html I'll report back once I poke around with that. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 16:46:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BCB1065672 for ; Thu, 15 Jul 2010 16:46:19 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id 546DE8FC1A for ; Thu, 15 Jul 2010 16:46:18 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Thu, 15 Jul 2010 12:46:18 -0400 id 00017026.000000004C3F3B5A.00015B39 From: "Brian A. Seklecki" To: Harald Schmalzbauer In-Reply-To: <4C3CBC1E.9030106@omnilan.de> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> Organization: Collaborative Fusion, Inc. Date: Thu, 15 Jul 2010 12:46:17 -0400 Message-ID: <1279212377.31311.144.camel@soundwave> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_blackout-88889-1279212378-0001-2" X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) Cc: freebsd-stable , Steve Polyack , Brandon Gooch , Sean McAfee , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 16:46:19 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_blackout-88889-1279212378-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-07-13 at 21:18 +0200, Harald Schmalzbauer wrote: > Jack Vogel schrieb am 18.06.2010 20:01 (localtime): > > Yes, the commits today are slated to get into 8.1, at least that's my > > understanding. > >=20 > > Jack >=20 > Hello, is this still on the to-merge-before-8.1-RELEASE list? Its hard to say; Not sure this issue was ever given a PR reference number? Jack's commit didn't mention one. It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/e1000/if_em.c?view=3Dlo= g 8.1 forked in SVN on June 14: http://svn.freebsd.org/viewvc/base/releng/8.1/sys/dev/e1000/if_em.c?view=3D= log The change hasn't been MFC/RFP'd to releng/8.1/*, yet; Jack I'd get ahold of the releng officer ASAP at this point. ~BAS --=_blackout-88889-1279212378-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkw/O1kACgkQCne6BNDQ+R8GngCfQdXgYl0Z3IFFv+huwPRA7Gvq wrEAn3ZIXBXXtBG77oRh2A+b/pr7yDrv =LVWp -----END PGP SIGNATURE----- --=_blackout-88889-1279212378-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 16:50:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9F201065670 for ; Thu, 15 Jul 2010 16:50:03 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAD88FC22 for ; Thu, 15 Jul 2010 16:50:03 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Thu, 15 Jul 2010 12:50:03 -0400 id 00017278.000000004C3F3C3B.0001022E From: "Brian A. Seklecki" To: Harald Schmalzbauer , Michael Tuexen In-Reply-To: <1279212377.31311.144.camel@soundwave> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> Organization: Collaborative Fusion, Inc. Date: Thu, 15 Jul 2010 12:50:02 -0400 Message-ID: <1279212602.31311.151.camel@soundwave> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_skyhopper-66094-1279212603-0001-2" X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) Cc: freebsd-stable , Steve Polyack , Brandon Gooch , Sean McAfee , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 16:50:03 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_skyhopper-66094-1279212603-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > It may have gone in before the RELENG_8_1 tag/branch occurred? SVN > r209309 >=20 > Jacks's change went into stable/8 on June 18: >=20 Also, did anyone provide feedback on SVN r209959 to head/sys/dev/e1000/if_em.c ? =20 It's saying "8.1 MFC", so you might want to ask people to test that on stable/8 then expedite the 8.1 MFC as well. ~BAS --=_skyhopper-66094-1279212603-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkw/PDoACgkQCne6BNDQ+R/Q6QCfXhRaGvo3bw8+2Wr9HVZam2Ck XoQAn0pHn3APxpQRIIBW/IcrrHqRcgQO =y1A2 -----END PGP SIGNATURE----- --=_skyhopper-66094-1279212603-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 16:57:27 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6989106566B; Thu, 15 Jul 2010 16:57:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 27B0F8FC0A; Thu, 15 Jul 2010 16:57:26 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6FGv9u1080711; Thu, 15 Jul 2010 18:57:25 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6FGv97V080710; Thu, 15 Jul 2010 18:57:09 +0200 (CEST) (envelope-from olli) Date: Thu, 15 Jul 2010 18:57:09 +0200 (CEST) Message-Id: <201007151657.o6FGv97V080710@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, avg@icyb.net.ua, jkim@FreeBSD.ORG In-Reply-To: <4C3F0149.1070500@icyb.net.ua> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 15 Jul 2010 18:57:25 +0200 (CEST) Cc: Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 16:57:27 -0000 Andriy Gapon wrote: > on 15/07/2010 15:27 Oliver Fromme said the following: > > Unfortunately, it didn't change. Kernel output during boot > > is still the same; it displays 1 package x 8 cores. > > If you are sure that everything is done correctly (patch really applied, kernel > really rebuilt and reinstalled, and reboot was to the new kernel), then perhaps > jkim would be interested in this issue. Yes, I'm sure, I even added some printf() so I can be sure that the patched code is actually executed. Here is what happens in sys/amd64/amd64/mp_machdep.c: In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is called. But the cpuid 0xb instruction doesn't seem to return useful data: All values are zero already in the first level, so cpu_cores remains 0. Back in topo_probe(), there is a fallback if cpu_cores is stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 which is wrong. I patched topo_probe() so it calls topo_probe_0x4() after topo_probe_0xb() if cpu_cores is still 0. I think this is a better fallback procedure. With this patch, cpu_cores gets the value 4 which is the correct one, finally: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) This is the patch, it's against jkim's patched version: @@ -265,7 +268,7 @@ else if (cpu_vendor_id == CPU_VENDOR_INTEL) { if (cpu_high >= 0xb) topo_probe_0xb(); - else if (cpu_high >= 0x4) + if (cpu_high >= 0x4 && cpu_cores == 0) topo_probe_0x4(); } if (cpu_cores == 0) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 17:13:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A42421065688 for ; Thu, 15 Jul 2010 17:13:07 +0000 (UTC) (envelope-from masoom.shaikh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 27F0C8FC19 for ; Thu, 15 Jul 2010 17:13:06 +0000 (UTC) Received: by gyd8 with SMTP id 8so919126gyd.13 for ; Thu, 15 Jul 2010 10:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=YPWt8CrR0C3iPO1HntyZxCH3P1kj02UFtS+X3ZM8uc8=; b=Xpp7mYvWYl71gKJ2/17gRh3o3nlrR/Ay/98Kob9XQMMP3A0MOhlluo39j9ySTlzw70 dpf33UbsDH+VPHrGWDg0bsTtp2yNvSrl2tjrjP+x6x8nvJKRvTSNb4vk6saFqBo/iJ80 Jr5lJQpR2OFjIe9ed5mhOzYNHHnkxv0eAndHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tgNmpDACU+319oExjdDhdjiNuean1a9+572zZ47FAmxLAWhJGJ4vCnxrM/moYBuWik /M5ergmNxse5ebAYbgmrze6sJ0IuMgCJEHcHdTdOuD339PwYnsstShg9/I6eHAay3O/A NAHOjyGVD3dLTveGvLIsJdAvLDcOX87+vfSgM= MIME-Version: 1.0 Received: by 10.90.119.19 with SMTP id r19mr69192agc.82.1279213986183; Thu, 15 Jul 2010 10:13:06 -0700 (PDT) Received: by 10.90.65.16 with HTTP; Thu, 15 Jul 2010 10:13:05 -0700 (PDT) Date: Thu, 15 Jul 2010 17:13:05 +0000 Message-ID: From: Masoom Shaikh To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD RELEASE-8.0-p3 panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 17:13:07 -0000 Howdy, here is the image of my FreeBSD panic http://images.cjb.net/d64f4.jpg the error says RAM parity error(not visible in pic). but I have following reasons to believed it could be wrong 1. I have 1GB of RAM, with two chips of 512MB each. It panics even if I boot with only 512MB of total RAM. i.e. one chip removed. It panics for both chips individually. 2. I tried replacing my both 512MB chips with two 512MB chips from my friends laptop, it still panics with exact same error. RAM parity error, it is very unlikely that his chips have this problem. He runs Ubuntu on those chips and Windows7 with no issues whatsoever. 3. Windows7 operates on this(my) laptop just fine. sometimes it take 3-4 attempts to boot it, since it panics the moment KDM tries to load. But once running it runs few hours if I do not subject it to load. Even moderate load like browsing some multimedia content websites, e.g. youtube or some site with lots of flash based ads or even some javascript heavy page like GMail etc... It appears the moment I start subjecting the machine to load, mem usage increases and it hits the part of RAM which might possibly have parity error. have a look at the pic, the frame pointer is always remains same 0xffffffff803f1ef1. I have already asked, and again ask, is there a way to ask FreeBSD to "ignore" some part of RAM ? how do I zero in on the exact point of failure ? I am aware, just too many variables are here, some wild guesses ? I am very sorry for my feeble OS debugging skills if any, but FreeBSD has nothing to do with my day job, it is just a hobby for me. I sincerely want it to work. regards, Masoom Shaikh From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 17:29:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8749B1065678 for ; Thu, 15 Jul 2010 17:29:12 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id D8CCE8FC20 for ; Thu, 15 Jul 2010 17:29:11 +0000 (UTC) Received: from [192.168.1.190] (p508FC88F.dip.t-dialin.net [80.143.200.143]) by mail-n.franken.de (Postfix) with ESMTP id 1F6D81C0C0BD4; Thu, 15 Jul 2010 19:29:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <1279212602.31311.151.camel@soundwave> Date: Thu, 15 Jul 2010 19:31:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> To: bseklecki@collaborativefusion.com X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable , Steve Polyack , Brandon Gooch , Sean McAfee , Harald Schmalzbauer , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 17:29:12 -0000 On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >=20 >> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN >> r209309 >>=20 >> Jacks's change went into stable/8 on June 18: >>=20 >=20 > Also, did anyone provide feedback on SVN r209959 to > head/sys/dev/e1000/if_em.c ? =20 >=20 > It's saying "8.1 MFC", so you might want to ask people to test that on > stable/8 then expedite the 8.1 MFC as well. Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from = stable/8 anyway. There is no need for re@ approval to MFC it into stable/8. Best regards Michael >=20 > ~BAS From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 17:48:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEF651065673 for ; Thu, 15 Jul 2010 17:48:25 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id B1A468FC0A for ; Thu, 15 Jul 2010 17:48:25 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Thu, 15 Jul 2010 13:41:33 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::2 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@freebsd.org X-SMFBL: ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc= Message-ID: <4C3F49E8.9090201@comcast.net> Date: Thu, 15 Jul 2010 13:48:24 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100707 Thunderbird/3.0.5 MIME-Version: 1.0 To: Michael Tuexen References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> In-Reply-To: <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Harald Schmalzbauer , Jack Vogel , bseklecki@collaborativefusion.com, Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 17:48:26 -0000 On 07/15/10 13:31, Michael Tuexen wrote: > On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: > > >> >>> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN >>> r209309 >>> >>> Jacks's change went into stable/8 on June 18: >>> >>> >> Also, did anyone provide feedback on SVN r209959 to >> head/sys/dev/e1000/if_em.c ? >> >> It's saying "8.1 MFC", so you might want to ask people to test that on >> stable/8 then expedite the 8.1 MFC as well. >> > Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from stable/8 anyway. > There is no need for re@ approval to MFC it into stable/8. > As Brian stated, the change has already been MFC'd into stable/8 (June 18th) with the following comment from Jack: "MFC to RELENG8.1 asap" Steve > Best regards > Michael > >> ~BAS >> > _______________________________________________ > 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 Thu Jul 15 17:53:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7E91065677; Thu, 15 Jul 2010 17:53:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 132D98FC12; Thu, 15 Jul 2010 17:53:43 +0000 (UTC) Received: by qyk7 with SMTP id 7so187477qyk.13 for ; Thu, 15 Jul 2010 10:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4Da7GHhrb+Nnbdx4Sxx+X9Og+gKNDG5s0/yvQ2xOIUA=; b=c96KmpvZiAJiuMGpQExJEwwalShvuSDBaix/mEAG9G14r9EuHowxkE8WO830opB3HL d5zRTp5F4uQdlHOm9DTiXPB+9FyG6q9KXi/+1yGONsmcy91hK71NoNUfrXvmd2JxE1Ig GEGsdQREv/d7vNF9maSO52yWBaonunGrKX5j8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t4NCafi/0BlGguwoHZ4jZZ9gdfzpqXBpDg9dJkcIVciWvIjkfxr5KYT98rs0ZiL3su ot+t1jDOvEZNar87+v630/4/swkCTUBxVh8cRDJ+t++deevF5W72U7jUgEwt5viLoX4D hTpfMQZ2IRtG6gV6uKuS8Ha9wk9Eja5bvHnAs= MIME-Version: 1.0 Received: by 10.224.36.207 with SMTP id u15mr5482065qad.332.1279216423050; Thu, 15 Jul 2010 10:53:43 -0700 (PDT) Received: by 10.229.220.5 with HTTP; Thu, 15 Jul 2010 10:53:42 -0700 (PDT) In-Reply-To: <4C3F49E8.9090201@comcast.net> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> Date: Thu, 15 Jul 2010 10:53:42 -0700 Message-ID: From: Jack Vogel To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Harald Schmalzbauer , Michael Tuexen , bseklecki@collaborativefusion.com, Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 17:53:44 -0000 The fact that I WISH it to be MFC'd doesn't mean that I am actually given permission to do so. Jack On Thu, Jul 15, 2010 at 10:48 AM, Steve Polyack wrote: > On 07/15/10 13:31, Michael Tuexen wrote: > >> On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >> >> >> >>> >>> >>>> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN >>>> r209309 >>>> >>>> Jacks's change went into stable/8 on June 18: >>>> >>>> >>>> >>> Also, did anyone provide feedback on SVN r209959 to >>> head/sys/dev/e1000/if_em.c ? >>> >>> It's saying "8.1 MFC", so you might want to ask people to test that on >>> stable/8 then expedite the 8.1 MFC as well. >>> >>> >> Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from >> stable/8 anyway. >> There is no need for re@ approval to MFC it into stable/8. >> >> > > As Brian stated, the change has already been MFC'd into stable/8 (June > 18th) with the following comment from Jack: > > "MFC to RELENG8.1 asap" > > > Steve > >> Best regards >> Michael >> >> >>> ~BAS >>> >>> >> _______________________________________________ >> 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 Thu Jul 15 17:56:21 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611DD1065673; Thu, 15 Jul 2010 17:56:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 758A58FC19; Thu, 15 Jul 2010 17:56:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA05479; Thu, 15 Jul 2010 20:56:12 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C3F4BBB.30606@icyb.net.ua> Date: Thu, 15 Jul 2010 20:56:11 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Oliver Fromme References: <201007151657.o6FGv97V080710@lurza.secnetix.de> In-Reply-To: <201007151657.o6FGv97V080710@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG, jkim@FreeBSD.ORG Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 17:56:21 -0000 on 15/07/2010 19:57 Oliver Fromme said the following: > In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is > called. But the cpuid 0xb instruction doesn't seem to > return useful data: All values are zero already in the > first level, so cpu_cores remains 0. > > Back in topo_probe(), there is a fallback if cpu_cores is > stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 > which is wrong. > > I patched topo_probe() so it calls topo_probe_0x4() after > topo_probe_0xb() if cpu_cores is still 0. I think this > is a better fallback procedure. With this patch, cpu_cores > gets the value 4 which is the correct one, finally: > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) Thank you for debugging this issue! Not sure if this is the best patch that there can be, but its direction is definitely correct. As the Intel document says (translated to our x86 mp_machdep.c terms): if cpu_high >= 0xb then we should execute cpuid_count(0xb, 0, p) and examine EBX value (p[1]), only if it's non-zero should we proceed with topo_probe_0xb(), otherwise we should fall back to topo_probe_0x4, etc. I think that your addition achieves this effect, perhaps just not as explicitly as I would preferred. Jung-uk, what do you think? > > This is the patch, it's against jkim's patched version: > @@ -265,7 +268,7 @@ > else if (cpu_vendor_id == CPU_VENDOR_INTEL) { > if (cpu_high >= 0xb) > topo_probe_0xb(); > - else if (cpu_high >= 0x4) > + if (cpu_high >= 0x4 && cpu_cores == 0) > topo_probe_0x4(); > } > if (cpu_cores == 0) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 17:57:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 581541065672; Thu, 15 Jul 2010 17:57:04 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1EC8FC27; Thu, 15 Jul 2010 17:57:03 +0000 (UTC) Received: from [192.168.2.161] (soundwave.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.161]) by relay.admin.pitbpa0.priv.collaborativefusion.com with esmtp; Thu, 15 Jul 2010 13:57:02 -0400 id 0001703E.000000004C3F4BEE.000170DE From: "Brian A. Seklecki" To: Steve Polyack In-Reply-To: <4C3F49E8.9090201@comcast.net> References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> Organization: Collaborative Fusion, Inc. Date: Thu, 15 Jul 2010 13:57:01 -0400 Message-ID: <1279216621.31311.232.camel@soundwave> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=_blackout-94430-1279216622-0001-2" X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Harald Schmalzbauer , Michael Tuexen , Jack Vogel , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@collaborativefusion.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:57:04 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_blackout-94430-1279216622-0001-2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > As Brian stated, the change has already been MFC'd into stable/8 (June= =20 > 18th) with the following comment from Jack: >=20 > "MFC to RELENG8.1 asap" >=20 I also dont see the issue listed on: http://wiki.freebsd.org/Releng/8.1TODO If someone can put it on there, even if the RELENG engineer doesn't handle it before the release, at least Dell users will be informed. ~BAS --=_blackout-94430-1279216622-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkw/S+0ACgkQCne6BNDQ+R+ZawCbBnhKdef0IMcVJdfO0Ll7BKtb 4ZAAnR4L2pkHMWAZAB0vhsYl1FN9Bvyf =mfOw -----END PGP SIGNATURE----- --=_blackout-94430-1279216622-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 18:16:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F35731065679 for ; Thu, 15 Jul 2010 18:16:19 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id C22858FC18 for ; Thu, 15 Jul 2010 18:16:18 +0000 (UTC) Received: from [192.168.1.190] (p508FC88F.dip.t-dialin.net [80.143.200.143]) by mail-n.franken.de (Postfix) with ESMTP id 225E21C0B4607; Thu, 15 Jul 2010 20:16:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <4C3F49E8.9090201@comcast.net> Date: Thu, 15 Jul 2010 20:18:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> <4C3CBC1E.9030106@omnilan.de> <1279212377.31311.144.camel@soundwave> <1279212602.31311.151.camel@soundwave> <84875A93-3851-476E-8F2E-A7008CA6BD5C@FreeBSD.org> <4C3F49E8.9090201@comcast.net> To: Steve Polyack X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable , Brandon Gooch , Sean McAfee , Harald Schmalzbauer , Jack Vogel , bseklecki@collaborativefusion.com, Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 18:16:20 -0000 On Jul 15, 2010, at 7:48 PM, Steve Polyack wrote: > On 07/15/10 13:31, Michael Tuexen wrote: >> On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >>=20 >> =20 >>> =20 >>>> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN >>>> r209309 >>>>=20 >>>> Jacks's change went into stable/8 on June 18: >>>>=20 >>>> =20 >>> Also, did anyone provide feedback on SVN r209959 to >>> head/sys/dev/e1000/if_em.c ? >>>=20 >>> It's saying "8.1 MFC", so you might want to ask people to test that = on >>> stable/8 then expedite the 8.1 MFC as well. >>> =20 >> Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come = from stable/8 anyway. >> There is no need for re@ approval to MFC it into stable/8. >> =20 >=20 > As Brian stated, the change has already been MFC'd into stable/8 (June = 18th) with the following comment from Jack: >=20 > "MFC to RELENG8.1 asap" Not sure if we talk about the same. r209959 was on July 12th and it was = a commit to head and not stable/8. Best regards Michael >=20 >=20 > Steve >> Best regards >> Michael >> =20 >>> ~BAS >>> =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 >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 18:16:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABDF41065674 for ; Thu, 15 Jul 2010 18:16:46 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 561578FC1A for ; Thu, 15 Jul 2010 18:16:46 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 8BD081CC69; Thu, 15 Jul 2010 21:16:45 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 8BD081CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279217805; bh=gkU0DKL8FR+ePMpD4bIpTSDT9+XIbbu7J70s6qt+UbA=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zyq462UFPgn288n6QCx6P4DgoIvzl8tNMsgUiXQmsNmKS3Q7nAPY8f/wj1e5mbaqg FG9DT9qsi8oxjiWSLP2UH3/xlmhojujcCSYJf4pfT7bV/QDkoPgRMI47Pfccty4PnE voNAkz2jQTsXQdQANynQWxYYDlyNwG9PVGEWTlO0= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 14v531JzcxhH; Thu, 15 Jul 2010 21:16:42 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 609001CC67; Thu, 15 Jul 2010 21:16:40 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 609001CC67 Message-ID: <4C9CB3EBD919471A85D3E6B282D9F827@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> In-Reply-To: <20100715162251.GA73929@icarus.home.lan> Date: Thu, 15 Jul 2010 21:16:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 18:16:46 -0000 -------------------------------------------------- From: "Jeremy Chadwick" Sent: Thursday, July 15, 2010 7:22 PM To: "Reko Turja" Cc: "Henrik /KaarPoSoft" ;=20 Subject: Re: openldap client GSSAPI authentication segfaults in=20 fbsd8stablei386 > That said, can you please execute the following in gdb and provide > the output? > > (gdb) p/x gss_release_buffer.c::buffer->value > (gdb) p/x gss_release_buffer.c::buffer->length Those gave syntax error, but going to frame 1 and printing the values=20 gives the following: (gdb) f 1 #1 0x2899ed12 in gss_release_buffer (minor_status=3D0xbfbfe4b8,=20 buffer=3D0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 41 free(buffer->value); (gdb) p/x buffer->length $1 =3D 0x0 (gdb) p/x gss_release_buffer.c::buffer->length A syntax error in expression, near `::buffer->length'. (gdb) p/x buffer->value $2 =3D 0x280871c0 Hope this helps - definitely looks like the issue you are suspecting. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 18:45:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818841065678 for ; Thu, 15 Jul 2010 18:45:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 51BEE8FC1C for ; Thu, 15 Jul 2010 18:45:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DFD1846B09; Thu, 15 Jul 2010 14:45:52 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D66A28A04E; Thu, 15 Jul 2010 14:45:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 15 Jul 2010 13:33:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007151333.39738.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Jul 2010 14:45:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Masoom Shaikh Subject: Re: FreeBSD RELEASE-8.0-p3 panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 18:45:53 -0000 On Thursday, July 15, 2010 1:13:05 pm Masoom Shaikh wrote: > Howdy, > > here is the image of my FreeBSD panic > http://images.cjb.net/d64f4.jpg > > the error says RAM parity error(not visible in pic). but I have > following reasons to believed it could be wrong > > 1. I have 1GB of RAM, with two chips of 512MB each. It panics even if > I boot with only 512MB of total RAM. i.e. one chip removed. It panics > for both chips individually. > 2. I tried replacing my both 512MB chips with two 512MB chips from my > friends laptop, it still panics with exact same error. RAM parity > error, it is very unlikely that his chips have this problem. He runs > Ubuntu on those chips and Windows7 with no issues whatsoever. > 3. Windows7 operates on this(my) laptop just fine. > > sometimes it take 3-4 attempts to boot it, since it panics the moment > KDM tries to load. But once running it runs few hours if I do not > subject it to load. Even moderate load like browsing some multimedia > content websites, e.g. youtube or some site with lots of flash based > ads or even some javascript heavy page like GMail etc... It appears > the moment I start subjecting the machine to load, mem usage increases > and it hits the part of RAM which might possibly have parity error. > > have a look at the pic, the frame pointer is always remains same > 0xffffffff803f1ef1. I have already asked, and again ask, is there a > way to ask FreeBSD to "ignore" some part of RAM ? how do I zero in on > the exact point of failure ? I am aware, just too many variables are > here, some wild guesses ? > > I am very sorry for my feeble OS debugging skills if any, but FreeBSD > has nothing to do with my day job, it is just a hobby for me. I > sincerely want it to work. There is a tunable you can set in the loader (vm.blacklist) to a list of physical addresses of pages that should be ignored. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 18:45:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB78106567D; Thu, 15 Jul 2010 18:45:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7CD0E8FC1E; Thu, 15 Jul 2010 18:45:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2B84B46B35; Thu, 15 Jul 2010 14:45:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4CD378A04F; Thu, 15 Jul 2010 14:45:53 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 15 Jul 2010 14:32:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201007151657.o6FGv97V080710@lurza.secnetix.de> <4C3F4BBB.30606@icyb.net.ua> In-Reply-To: <4C3F4BBB.30606@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007151432.25052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Jul 2010 14:45:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Oliver Fromme , Andriy Gapon , jkim@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 18:45:54 -0000 On Thursday, July 15, 2010 1:56:11 pm Andriy Gapon wrote: > on 15/07/2010 19:57 Oliver Fromme said the following: > > In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is > > called. But the cpuid 0xb instruction doesn't seem to > > return useful data: All values are zero already in the > > first level, so cpu_cores remains 0. > > > > Back in topo_probe(), there is a fallback if cpu_cores is > > stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 > > which is wrong. > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > topo_probe_0xb() if cpu_cores is still 0. I think this > > is a better fallback procedure. With this patch, cpu_cores > > gets the value 4 which is the correct one, finally: > > > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > FreeBSD/SMP: 2 package(s) x 4 core(s) > > Thank you for debugging this issue! > Not sure if this is the best patch that there can be, but its direction is > definitely correct. > As the Intel document says (translated to our x86 mp_machdep.c terms): > if cpu_high >= 0xb then we should execute cpuid_count(0xb, 0, p) and examine EBX > value (p[1]), only if it's non-zero should we proceed with topo_probe_0xb(), > otherwise we should fall back to topo_probe_0x4, etc. > > I think that your addition achieves this effect, perhaps just not as explicitly as > I would preferred. Maybe have topo_probe_0xb() explicitly call topo_probe_0x4() if EBX is 0? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 19:07:43 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8C828106566B; Thu, 15 Jul 2010 19:07:42 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andriy Gapon Date: Thu, 15 Jul 2010 15:07:32 -0400 User-Agent: KMail/1.6.2 References: <201007151657.o6FGv97V080710@lurza.secnetix.de> <4C3F4BBB.30606@icyb.net.ua> In-Reply-To: <4C3F4BBB.30606@icyb.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007151507.33998.jkim@FreeBSD.org> Cc: freebsd-stable@FreeBSD.ORG, Oliver Fromme Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 19:07:43 -0000 On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > on 15/07/2010 19:57 Oliver Fromme said the following: > > In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is > > called. But the cpuid 0xb instruction doesn't seem to > > return useful data: All values are zero already in the > > first level, so cpu_cores remains 0. > > > > Back in topo_probe(), there is a fallback if cpu_cores is > > stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 > > which is wrong. > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > topo_probe_0xb() if cpu_cores is still 0. I think this > > is a better fallback procedure. With this patch, cpu_cores > > gets the value 4 which is the correct one, finally: > > > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > FreeBSD/SMP: 2 package(s) x 4 core(s) > > Thank you for debugging this issue! > Not sure if this is the best patch that there can be, but its > direction is definitely correct. > As the Intel document says (translated to our x86 mp_machdep.c > terms): if cpu_high >= 0xb then we should execute cpuid_count(0xb, > 0, p) and examine EBX value (p[1]), only if it's non-zero should we > proceed with topo_probe_0xb(), otherwise we should fall back to > topo_probe_0x4, etc. > > I think that your addition achieves this effect, perhaps just not > as explicitly as I would preferred. > > Jung-uk, what do you think? Yes, you're right. Please try new patch: http://people.freebsd.org/~jkim/mp_machdep2.diff Thanks, Jung-uk Kim > > This is the patch, it's against jkim's patched version: > > @@ -265,7 +268,7 @@ > > else if (cpu_vendor_id == CPU_VENDOR_INTEL) { > > if (cpu_high >= 0xb) > > topo_probe_0xb(); > > - else if (cpu_high >= 0x4) > > + if (cpu_high >= 0x4 && cpu_cores == 0) > > topo_probe_0x4(); > > } > > if (cpu_cores == 0) From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 19:18:26 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6D713106567B; Thu, 15 Jul 2010 19:18:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Thu, 15 Jul 2010 15:18:15 -0400 User-Agent: KMail/1.6.2 References: <201007151657.o6FGv97V080710@lurza.secnetix.de> <4C3F4BBB.30606@icyb.net.ua> <201007151507.33998.jkim@FreeBSD.org> In-Reply-To: <201007151507.33998.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007151518.17012.jkim@FreeBSD.org> Cc: Oliver Fromme , Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 19:18:26 -0000 On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote: > On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > > on 15/07/2010 19:57 Oliver Fromme said the following: > > > In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is > > > called. But the cpuid 0xb instruction doesn't seem to > > > return useful data: All values are zero already in the > > > first level, so cpu_cores remains 0. > > > > > > Back in topo_probe(), there is a fallback if cpu_cores is > > > stil 0: It assigns mp_ncpu to cpu_cores, so it gets 8 > > > which is wrong. > > > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > > topo_probe_0xb() if cpu_cores is still 0. I think this > > > is a better fallback procedure. With this patch, cpu_cores > > > gets the value 4 which is the correct one, finally: > > > > > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > > FreeBSD/SMP: 2 package(s) x 4 core(s) > > > > Thank you for debugging this issue! > > Not sure if this is the best patch that there can be, but its > > direction is definitely correct. > > As the Intel document says (translated to our x86 mp_machdep.c > > terms): if cpu_high >= 0xb then we should execute > > cpuid_count(0xb, 0, p) and examine EBX value (p[1]), only if it's > > non-zero should we proceed with topo_probe_0xb(), otherwise we > > should fall back to topo_probe_0x4, etc. > > > > I think that your addition achieves this effect, perhaps just not > > as explicitly as I would preferred. > > > > Jung-uk, what do you think? > > Yes, you're right. Please try new patch: > > http://people.freebsd.org/~jkim/mp_machdep2.diff I uploaded the patch again, it's compile-tested this now. Sorry, if anyone has downloaded it few minutes ago. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 20:02:05 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A15C106566C; Thu, 15 Jul 2010 20:02:05 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E0A608FC1E; Thu, 15 Jul 2010 20:02:04 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6FK1mPk088946; Thu, 15 Jul 2010 22:02:03 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6FK1mGq088944; Thu, 15 Jul 2010 22:01:48 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007152001.o6FK1mGq088944@lurza.secnetix.de> To: jkim@FreeBSD.org (Jung-uk Kim) Date: Thu, 15 Jul 2010 22:01:48 +0200 (CEST) In-Reply-To: <201007151507.33998.jkim@FreeBSD.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Thu, 15 Jul 2010 22:02:03 +0200 (CEST) Cc: freebsd-stable@FreeBSD.org, Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 20:02:05 -0000 Jung-uk Kim wrote: > On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > > on 15/07/2010 19:57 Oliver Fromme said the following: > > > I patched topo_probe() so it calls topo_probe_0x4() after > > > topo_probe_0xb() if cpu_cores is still 0. I think this > > > is a better fallback procedure. With this patch, cpu_cores > > > gets the value 4 which is the correct one, finally: > > [...] > > I think that your addition achieves this effect, perhaps just not > > as explicitly as I would preferred. > > > > Jung-uk, what do you think? > > Yes, you're right. Please try new patch: > > http://people.freebsd.org/~jkim/mp_machdep2.diff Thank you! I will have access to that particular machine on Monday again, so testing the new patch will have to wait until Monday. But from looking at your patch it should have the same result as my simpler patch, so it should work fine. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer From owner-freebsd-stable@FreeBSD.ORG Thu Jul 15 21:22:15 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4464C106564A for ; Thu, 15 Jul 2010 21:22:15 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by mx1.freebsd.org (Postfix) with ESMTP id A848B8FC1C for ; Thu, 15 Jul 2010 21:22:14 +0000 (UTC) Received: from kloboucek (holub.ics.muni.cz [147.251.23.83]) (authenticated user=hopet@META bits=0) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id o6FL2DV3031292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Jul 2010 23:02:13 +0200 From: "Petr Holub" To: Date: Thu, 15 Jul 2010 23:02:12 +0200 Message-ID: <031b01cb2460$fece89c0$fc6b9d40$@muni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcskYPrZUR8uVTaZRQOL1c4GFwIpTA== Content-Language: cs x-cr-hashedpuzzle: ANzE DRId DU0W Eydj E+94 FfQg Fu8H GhOE G6OZ HTXl HVoz Hvni If4z Inrh JEj1 JZvt; 1; cwB0AGEAYgBsAGUAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {37593455-8EBD-4AC1-8C2A-04D5168DCB24}; aABvAHAAZQB0AEAAaQBjAHMALgBtAHUAbgBpAC4AYwB6AA==; Thu, 15 Jul 2010 21:02:05 GMT; dQBwAGQAYQB0AGUAIABvAG4AIABrAGUAcgBuAC8AMQA0ADUAMAA2ADQAPwA= x-cr-puzzleid: {37593455-8EBD-4AC1-8C2A-04D5168DCB24} X-Muni-Spam-TestIP: 147.251.23.83 X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Virus-Test: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Thu, 15 Jul 2010 23:02:13 +0200 (CEST) Cc: Subject: update on kern/145064? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jul 2010 21:22:15 -0000 Dear stable list, is there any update on bug hunting of the issue described here? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing the same problem with the Marvell SATA driver. Therefore, PC BSD is not installable on my machine as it deterministically panics on boot. The same machine runs FreeBSD 7.3 just fine. Thanks, Petr From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 01:34:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B821065676; Fri, 16 Jul 2010 01:34:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 694188FC13; Fri, 16 Jul 2010 01:34:58 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6G1Ytfq028810; Fri, 16 Jul 2010 01:34:56 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C3FB73F.7070502@freebsd.org> Date: Fri, 16 Jul 2010 09:34:55 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C3DF48E.1070502@icyb.net.ua> <201007141740.55798.jkim@FreeBSD.org> <201007141755.04690.jkim@FreeBSD.org> In-Reply-To: <201007141755.04690.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Oliver Fromme , freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 01:34:58 -0000 Jung-uk Kim wrote: > On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: >> On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: >>> on 14/07/2010 17:14 Oliver Fromme said the following: >>>> In a machine installed yesterday, 8.1-PRERELEASE doesn't >>>> seem to detect the number of CPU packages vs. cores per >>>> >>>> package correctly: >>>> | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC >>>> | 2010 [...] >>>> | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz >>>> | (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = >>>> | 0x1067a Family = 6 Model = 17 Stepping = 10 >>>> | Features=0xbfebfbff>>> |SE >>>> | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, >>>> |SSE 2,SS,HTT,TM,PBE> >>>> | Features2=0x40ce3bd>>> |,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE> AMD >>>> | Features=0x20000800 >>>> | AMD Features2=0x1 >>>> | TSC: P-state invariant >>>> | real memory = 34359738368 (32768 MB) >>>> | avail memory = 33151377408 (31615 MB) >>>> | ACPI APIC Table: >>>> | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >>>> | FreeBSD/SMP: 1 package(s) x 8 core(s) >>>> | 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: 6 >>>> | cpu7 (AP): APIC ID: 7 >>>> | ioapic1 irqs 24-47 on motherboard >>>> | ioapic0 irqs 0-23 on motherboard >>>> >>>> I'm pretty sure that this is a 2 x 4 machine (2 CPU packages >>>> with 4 cores per package), not 1 x 8. That's what the BIOS >>>> displays during POST. >>>> >>>> I'm not sure if this is just a "cosmetic" issue, or if this >>>> is a critical thing ... I could imagine that performance >>>> might be sub-optimal if the CPU topology isn't detected >>>> correctly, but I'm not sure if FreeBSD can take advantage >>>> of the topology. >>> Could you please try to do the following? >>> 1. Fetch topo-12212009.tar from the top of this page: >>> http://software.intel.com/en-us/articles/intel-64-architecture-pr >>> oc essor-topology-enumeration/ 2. Untar it and apply this patch to >>> the code: >>> http://people.freebsd.org/~avg/cpu-topology.diff >>> 3. Compile it by running sh mk_64.sh (supposing you have amd64 >>> system installed) 4. Run cpu_topology64.out and report back its >>> output. >> It's funny that I actually wrote a convenience script (and cleaned >> up today): >> >> http://people.freebsd.org/~jkim/cpu_topology-12212009.sh >> >> BTW, current topology detection code is not optimal for some Intel >> processors if my memory serves. > > Surprisingly, I found a patch I wrote last year from /tmp of my > desktop and it is still applied cleanly. 8-) > > Just in case, it is available from here: > > http://people.freebsd.org/~jkim/mp_machdep.diff > > It is applicable to both sys/amd64/amd64/mp_machdep.c and > sys/i386/i386/mp_machdep.c. I have to warn you, though, it hasn't > been used for more than a year, so it may not work at all. ;-) > > Jung-uk Kim Do you have patch for i386 branch ? I want to test. On my Pentium-D machine: $ sysctl kern.sched.topology_spec kern.sched.topology_spec: 0, 1 0, 1 it seems the kernel thinks that the Pentuim-D is sharing L2 cache, but in fact, the design of the Pentium Ds was simply two P4 cores sitting side by side. They do not share anything and they basically work independently. Regards, David Xu From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 06:46:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9254D106564A; Fri, 16 Jul 2010 06:46:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE0F8FC08; Fri, 16 Jul 2010 06:46:34 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o6G6kIWu014458; Fri, 16 Jul 2010 08:46:33 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o6G6kI1H014456; Fri, 16 Jul 2010 08:46:18 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201007160646.o6G6kI1H014456@lurza.secnetix.de> To: davidxu@freebsd.org (David Xu) Date: Fri, 16 Jul 2010 08:46:18 +0200 (CEST) In-Reply-To: <4C3FB73F.7070502@freebsd.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (lurza.secnetix.de [127.0.0.1]); Fri, 16 Jul 2010 08:46:34 +0200 (CEST) Cc: freebsd-stable@freebsd.org, Andriy Gapon , Jung-uk Kim , ivoras@freebsd.org Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 06:46:35 -0000 David Xu wrote: > Do you have patch for i386 branch ? I want to test. > On my Pentium-D machine: > > $ sysctl kern.sched.topology_spec > kern.sched.topology_spec: > > 0, 1 > > > > 0, 1 > > > > > > > it seems the kernel thinks that the Pentuim-D is sharing L2 cache, > but in fact, the design of the Pentium Ds was simply two P4 cores > sitting side by side. They do not share anything and they basically work > independently. Same thing on my intel Atom 330 board at home: 0, 1, 2, 3 0, 1, 2, 3 0, 1 HTT group 2, 3 HTT group The intel Atom 330 consists of two "Diamondville" dies on one package, each with its own 512 KB of L2 cache. There is no L3 cache, or any other shared cache. (Or maybe I misinterpret the XML output; I think that the "level" and "cache-level" numbers are confusing.) BTW, I noticed that the indentation problem (newline before "") is already fixed in -current, 5 weeks ago. Any plan to MFC this? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 07:13:58 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9921065673 for ; Fri, 16 Jul 2010 07:13:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 103178FC19 for ; Fri, 16 Jul 2010 07:13:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA14261; Fri, 16 Jul 2010 10:13:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OZf7J-0005E7-TB; Fri, 16 Jul 2010 10:13:53 +0300 Message-ID: <4C4006B1.1070604@icyb.net.ua> Date: Fri, 16 Jul 2010 10:13:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Petr Holub References: <031b01cb2460$fece89c0$fc6b9d40$@muni.cz> In-Reply-To: <031b01cb2460$fece89c0$fc6b9d40$@muni.cz> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: update on kern/145064? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 07:13:58 -0000 on 16/07/2010 00:02 Petr Holub said the following: > Dear stable list, > > is there any update on bug hunting of the issue described here? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/145064 > I've attempted to install PC BSD 8.1-RC1 on my desktop and I'm facing > the same problem with the Marvell SATA driver. Therefore, PC BSD is > not installable on my machine as it deterministically panics on > boot. The same machine runs FreeBSD 7.3 just fine. I guess that your best bet is to directly ping mav@ in case he missed the PR and this thread. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 07:55:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89FBE1065677 for ; Fri, 16 Jul 2010 07:55:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA018FC16 for ; Fri, 16 Jul 2010 07:55:28 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta04.emeryville.ca.mail.comcast.net with comcast id iXvT1e00117UAYkA4XvT1s; Fri, 16 Jul 2010 07:55:27 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta13.emeryville.ca.mail.comcast.net with comcast id iXvR1e0083LrwQ28ZXvSy8; Fri, 16 Jul 2010 07:55:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A55AD9B425; Fri, 16 Jul 2010 00:55:25 -0700 (PDT) Date: Fri, 16 Jul 2010 00:55:25 -0700 From: Jeremy Chadwick To: Oliver Fromme Message-ID: <20100716075525.GA96403@icarus.home.lan> References: <201007151507.33998.jkim@FreeBSD.org> <201007152001.o6FK1mGq088944@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007152001.o6FK1mGq088944@lurza.secnetix.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org, Andriy Gapon , Jung-uk Kim Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 07:55:29 -0000 On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote: > > Jung-uk Kim wrote: > > On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > > > on 15/07/2010 19:57 Oliver Fromme said the following: > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > > > topo_probe_0xb() if cpu_cores is still 0. I think this > > > > is a better fallback procedure. With this patch, cpu_cores > > > > gets the value 4 which is the correct one, finally: > > > [...] > > > I think that your addition achieves this effect, perhaps just not > > > as explicitly as I would preferred. > > > > > > Jung-uk, what do you think? > > > > Yes, you're right. Please try new patch: > > > > http://people.freebsd.org/~jkim/mp_machdep2.diff > > Thank you! > > I will have access to that particular machine on Monday again, > so testing the new patch will have to wait until Monday. > But from looking at your patch it should have the same result > as my simpler patch, so it should work fine. I have a general question for everyone involved in this thread (which is highly educational/interesting -- thank you for all the info!): Does the problem reported affect actual performance/behaviour of FreeBSD kernel-wise at all, or is it just a cosmetical issue with regards to showing how many cores/threads there are? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 08:36:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D86E51065676 for ; Fri, 16 Jul 2010 08:36:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 828408FC28 for ; Fri, 16 Jul 2010 08:36:20 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id iYXX1e00216LCl054YcL01; Fri, 16 Jul 2010 08:36:20 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta06.westchester.pa.mail.comcast.net with comcast id iYcK1e0013LrwQ23SYcKHS; Fri, 16 Jul 2010 08:36:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA15E9B425; Fri, 16 Jul 2010 01:36:17 -0700 (PDT) Date: Fri, 16 Jul 2010 01:36:17 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100716083617.GA97981@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100715162251.GA73929@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Reko Turja , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 08:36:21 -0000 On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote: > Furthermore, relevant bug (PR 144754) indicates there's an easier way to > induce this problem, so I'm going to see if I can reproduce it here > locally. It's almost certainly the same problem but induced via a > slightly different context. > > http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html > > I'll report back once I poke around with that. I've tried to reproduce what's in the PR and can't. Running cyradm works fine: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15 Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package testbox# cyradm cyradm> I should note this machine **does** have Kerberos installed as part of the FreeBSD base system (meaning src.conf does not contain WITHOUT_KERBEROS). Mikhail, is there something I need to configure within cyrus-imapd23 first? Three things to note: 1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf. 2) I have not started the imapd service. 3) /var/log/all.log shows the following errors (but the daemon starts anyway): Jul 15 23:25:25 testbox master[46529]: process started Jul 15 23:25:25 testbox master[46530]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: dbenv->open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: dbenv->open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: writing /var/imap/db/skipstamp: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: writing /var/imap/db/skipstamp: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on skiplist Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: init() on skiplist Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: recovering cyrus databases Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: IOERROR: creating directory /var/imap: Permission denied Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: IOERROR: creating directory /var/imap: Permission denied Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: opening /var/imap: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46530]: DBERROR: opening /var/imap: cyrusdb error Jul 15 23:25:25 testbox master[46529]: process 46530 exited, status 75 Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: process 46530 exited, status 75 Jul 15 23:25:25 testbox master[46529]: unable to create lmtpunix listener socket: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox master[46529]: unable to create lmtpunix listener socket: No such file or directory Jul 15 23:25:25 testbox master[46529]: ready for work Jul 15 23:25:25 testbox master[46531]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: /var/imap/db/__db.001: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: dbenv->open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: dbenv->open '/var/imap/db' failed: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: init() on berkeley Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: reading /var/imap/db/skipstamp, assuming the worst: No such file or directory Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: reading /var/imap/db/skipstamp, assuming the worst: No such file or directory Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: checkpointing cyrus databases Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: archiving database file: /var/imap/annotations.db Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: error opening /var/imap/annotations.db for reading Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error archiving database file: /var/imap/annotations.db Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error archiving database file: /var/imap/annotations.db Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: DB_ENV->log_archive interface requires an environment configured for the logging subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: DB_ENV->log_archive interface requires an environment configured for the logging subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: archiving database file: /var/imap/mailboxes.db Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: error opening /var/imap/mailboxes.db for reading Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error archiving database file: /var/imap/mailboxes.db Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error archiving database file: /var/imap/mailboxes.db Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: DB_ENV->log_archive interface requires an environment configured for the logging subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: couldn't checkpoint: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: sync /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR db4: DB_ENV->log_archive interface requires an environment configured for the logging subsystem Jul 15 23:25:25 testbox master[46529]: process 46531 exited, status 1 Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: error listing log files: Invalid argument Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox kernel: Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: DBERROR: archive /var/imap/db: cyrusdb error Jul 15 23:25:25 testbox ctl_cyrusdb[46531]: done checkpointing cyrus databases Let me know as I'm doing my best to track this down. Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 08:56:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3573A1065674 for ; Fri, 16 Jul 2010 08:56:23 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id C9CFC8FC1B for ; Fri, 16 Jul 2010 08:56:22 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 43ECA1CC69; Fri, 16 Jul 2010 11:56:21 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 43ECA1CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279270581; bh=nEobQzm81W2PxaDgc5EeHXetrVKaHcLaN1ZTmabKoh4=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=L2toedyvHc98QPdJVEGpMV7OwjZPXQwl+uJMzYsLg/KHjXujSDYaOTXYHWjWduivd b6s3qiS6Vu2kVccbloFv4le2ohMc2PVbYP28k1eVQgRROStRhCgbxYw/rZMkJvZBAt qAIUvanma3htE9o6h44mRdCrj2GPjCY0EYQ2U6JA= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VeaNpPIFYlrp; Fri, 16 Jul 2010 11:56:18 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id C404C1CC67; Fri, 16 Jul 2010 11:56:15 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net C404C1CC67 Message-ID: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" , "Mikhail T." References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> In-Reply-To: <20100716083617.GA97981@icarus.home.lan> Date: Fri, 16 Jul 2010 11:56:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 08:56:23 -0000 > On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote: >> Furthermore, relevant bug (PR 144754) indicates there's an easier=20 >> way to >> induce this problem, so I'm going to see if I can reproduce it here >> locally. It's almost certainly the same problem but induced via a >> slightly different context. >> >> = http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html >> >> I'll report back once I poke around with that. > testbox# cyradm > cyradm> Try giving command cyradm localhost instead - the cyradm without=20 connection starts, but trying to connect to the local server triggers=20 the bug. Or you can give 'server localhost' instead from the cyradm=20 command line. > I should note this machine **does** have Kerberos installed as part=20 > of > the FreeBSD base system (meaning src.conf does not contain > WITHOUT_KERBEROS). Similar as my setup - kerberos isn't excluded even if it's not really=20 used. > Mikhail, is there something I need to configure within cyrus-imapd23 > first? Three things to note: > > 1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf. > 2) I have not started the imapd service. > 3) /var/log/all.log shows the following errors (but the daemon=20 > starts > anyway): > Let me know as I'm doing my best to track this down. Thanks. Another datapoint that might or might not have some connection with=20 the issue is that in _gss_mg_error (m=3D0x28a86480, maj=3D851968, = min=3D2)=20 at /usr/src/lib/libgssapi/gss_display_status.c void 232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,=20 OM_uint32 min) 233 { 234 OM_uint32 major_status, minor_status; 235 OM_uint32 message_content; 236 struct mg_thread_ctx *mg; 237 238 mg =3D &last_error_context; 239 240 gss_release_buffer(&minor_status, &mg->maj_error); 241 gss_release_buffer(&minor_status, &mg->min_error); 242 243 mg->mech =3D &m->gm_mech_oid; 244 mg->maj_stat =3D maj; when I give following comands, gdb tells me: (gdb) p last_error_context Cannot find thread-local variables on this target (gdb) p &last_error_context Cannot find thread-local variables on this target (gdb) p mg No symbol "mg" in current context. (gdb) Thank you very much for your effort in the issue! -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:11:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6602E1065675 for ; Fri, 16 Jul 2010 09:11:33 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1B4E8FC1E for ; Fri, 16 Jul 2010 09:11:32 +0000 (UTC) Received: by fxm13 with SMTP id 13so1009651fxm.13 for ; Fri, 16 Jul 2010 02:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UaBB+/RDNC4B8qfyAZUj6ACXiRHaJBFcS80CquSg91c=; b=Fg8jJheKMuosZ2pBfBa0XzC3SBy4YR8UWg2e5dY1QdUyqvzycv2SuZP5IiRFktl4Lb 0i0Tw9GP75Cv7d+bLOjmagDa5y575XPYpL8rLq43K8LynJdk/AvLtZi1Cpuo/9OMs96M yHw9LeE+zvxQy0lAnzxOcYYIwM7ss6BoOudTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bpho+vlcYYBz918ZbhHrCPXhCz6rkyFk1g9UKj891XItAT4FipNUGRjnLWbDjqCFAC jaRp1rBNrhspe+ugAIegnL9ikcJvbwGl1/wXI7ypMffaC8ZCZziLkf2PEUxrEgJ/lO9+ sxZJpfqLNsVYTcnZ4oBxNsKVJzfB4FEQtefJA= MIME-Version: 1.0 Received: by 10.223.121.193 with SMTP id i1mr388000far.77.1279271491770; Fri, 16 Jul 2010 02:11:31 -0700 (PDT) Received: by 10.223.114.16 with HTTP; Fri, 16 Jul 2010 02:11:31 -0700 (PDT) Date: Fri, 16 Jul 2010 11:11:31 +0200 Message-ID: From: Cristiano Deana To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: bgpd tuning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:11:33 -0000 Hi, I'm setting up a (future) 8.1 box to run as bgpd. I know in 8.x there are some improvements in networking, has someone any advice to tuning this machine? bgpd, routing only. CPU: Intel(R) Xeon(R) CPU 5130 @ 2.00GHz (1995.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 real memory = 2147483648 (2048 MB) avail memory = 2055630848 (1960 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 thanks in advance -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:15:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D8CC1065675 for ; Fri, 16 Jul 2010 09:15:53 +0000 (UTC) (envelope-from gausus@gausus.net) Received: from dagobah.intersec.pl (dagobah.intersec.pl [91.192.226.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABCD8FC24 for ; Fri, 16 Jul 2010 09:15:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dagobah.intersec.pl (Postfix) with ESMTP id 18CEB254002; Fri, 16 Jul 2010 11:15:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at intersec.pl Received: from dagobah.intersec.pl ([127.0.0.1]) by localhost (dagobah.intersec.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTCCqevrFW3x; Fri, 16 Jul 2010 11:15:50 +0200 (CEST) Received: from loken.local (cable.intersec.pl [85.222.122.69]) by dagobah.intersec.pl (Postfix) with ESMTP id A6090254001; Fri, 16 Jul 2010 11:15:50 +0200 (CEST) Message-ID: <4C402346.1000008@gausus.net> Date: Fri, 16 Jul 2010 11:15:50 +0200 From: Maciej Jan Broniarz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Cristiano Deana References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List Subject: Re: bgpd tuning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:15:53 -0000 W dniu 10-07-16 11:11, Cristiano Deana pisze: Hi, > I'm setting up a (future) 8.1 box to run as bgpd. > I know in 8.x there are some improvements in networking, has someone > any advice to tuning this machine? > > bgpd, routing only. How many peerings will You have, and how many prefixes You intend to receive? What is the estimated total bandwidth. mjb From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:22:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29551065674 for ; Fri, 16 Jul 2010 09:22:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4D0C38FC1C for ; Fri, 16 Jul 2010 09:22:11 +0000 (UTC) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id iZLY1e0040SCNGk5BZNCDm; Fri, 16 Jul 2010 09:22:12 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.westchester.pa.mail.comcast.net with comcast id iZNB1e0013LrwQ23VZNBa8; Fri, 16 Jul 2010 09:22:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B885C9B425; Fri, 16 Jul 2010 02:22:09 -0700 (PDT) Date: Fri, 16 Jul 2010 02:22:09 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716092209.GA99001@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:22:12 -0000 On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote: > Another datapoint that might or might not have some connection with > the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2) > at /usr/src/lib/libgssapi/gss_display_status.c > > void > 232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj, > OM_uint32 min) > 233 { > 234 OM_uint32 major_status, minor_status; > 235 OM_uint32 message_content; > 236 struct mg_thread_ctx *mg; > 237 > 238 mg = &last_error_context; > 239 > 240 gss_release_buffer(&minor_status, &mg->maj_error); > 241 gss_release_buffer(&minor_status, &mg->min_error); > 242 > 243 mg->mech = &m->gm_mech_oid; > 244 mg->maj_stat = maj; > > when I give following comands, gdb tells me: > > (gdb) p last_error_context > Cannot find thread-local variables on this target > (gdb) p &last_error_context > Cannot find thread-local variables on this target > (gdb) p mg > No symbol "mg" in current context. > (gdb) I'm not sure if you're familiar with C or not. This is because gdb's context is at the wrong frame. In the backtrace you provided originally, you'd need to do: (gdb) frame 2 To look at the variables associated with gss_display_status.c. last_error_context could be an exported variable (you'd need to look through the source to find out where it's declared), so you might have to print it with its source filename referenced. The print command I gave you before (p/x filename.c::variable) didn't work, and that's a surprise since the gdb documentation I read says it should. Also be aware that mg is a struct, so "p mg" won't tell you much, other than whether or not it's null. You're probably more interested in members of the struct, such as mg->maj_error and mg->min_error, and other struct members. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:25:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6FD1065676 for ; Fri, 16 Jul 2010 09:25:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id BDFFC8FC1C for ; Fri, 16 Jul 2010 09:25:14 +0000 (UTC) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id iZQd1e0010QuhwU5CZRE3X; Fri, 16 Jul 2010 09:25:14 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta02.westchester.pa.mail.comcast.net with comcast id iZRD1e0023LrwQ23NZREbJ; Fri, 16 Jul 2010 09:25:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 783329B425; Fri, 16 Jul 2010 02:25:12 -0700 (PDT) Date: Fri, 16 Jul 2010 02:25:12 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716092512.GA99365@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:25:15 -0000 On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote: > >On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote: > >>Furthermore, relevant bug (PR 144754) indicates there's an > >>easier way to > >>induce this problem, so I'm going to see if I can reproduce it here > >>locally. It's almost certainly the same problem but induced via a > >>slightly different context. > >> > >>http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html > >> > >>I'll report back once I poke around with that. > > >testbox# cyradm > >cyradm> > > Try giving command cyradm localhost instead - the cyradm without > connection starts, but trying to connect to the local server > triggers the bug. Or you can give 'server localhost' instead from > the cyradm command line. This doesn't help. The problem is that Cyrus imapd is completely freaking out, continually dying and re-forking itself, with my kernel message buffer filling rapidly + all.log filling. So, there is further configuration of this daemon that's needed (meaning it does not work "straight out of the box"), and I need those configuration details. Proof -- note the imapd pid changing constantly: testbox# ps -auxw | grep cyrus cyrus 46529 5.0 0.4 22376 3920 ?? Rs 11:25PM 0:05.36 /usr/local/cyrus/bin/master -d cyrus 51859 0.0 0.4 22376 3920 ?? R 12:14AM 0:00.00 /usr/local/cyrus/bin/master -d testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.43 /usr/local/cyrus/bin/master -d cyrus 51928 0.0 0.3 22512 3572 ?? R 12:15AM 0:00.02 imapd testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.55 /usr/local/cyrus/bin/master -d cyrus 52046 0.0 0.1 1560 1360 ?? R 12:15AM 0:00.00 imapd testbox# ps -auxw | grep cyrus cyrus 46529 6.0 0.4 22376 3920 ?? Ss 11:25PM 0:05.61 /usr/local/cyrus/bin/master -d cyrus 52114 0.0 0.1 1560 1360 ?? R 12:15AM 0:00.00 imapd -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:25:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2A681065677 for ; Fri, 16 Jul 2010 09:25:15 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 729078FC0A for ; Fri, 16 Jul 2010 09:25:15 +0000 (UTC) Received: by fxm13 with SMTP id 13so1016908fxm.13 for ; Fri, 16 Jul 2010 02:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=gsVPZKSIqnGyYyxfn+6+4b8KWurrbCopgUkHXqQZYek=; b=o9Ln54J0aYn4uXhweGrxzLqeS1Vc2mJu1DeoMyaVoL4lk7ZHI4uiI7QQaelJHF3P+h D5AtMTgFfe26o3lzbUb/6InpWcV89z1/ZFvq0a/GuDGu4LSiA/uBQbbpVnydBer6aLyQ tN9+Vcx5zVEvETuSMTrj1Wfs5kXjIcFQx4MtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SzHUGp1JBMRaVi/69uRjkRk/XO8BNmhFwXqVVWttZrSQ9cTsQVhhN5jOg7K3l6QXq+ 1ZKHyjNH1E3ep4Ee0o5nglex9a0S0DHVj1+OudEdNbM3DEW+tNuWqVCCqqOp5dQHlx16 88v3l+5F3v1WY6wycW3R82OVs9zCdju5r2gZg= MIME-Version: 1.0 Received: by 10.223.124.9 with SMTP id s9mr397459far.91.1279272314234; Fri, 16 Jul 2010 02:25:14 -0700 (PDT) Received: by 10.223.114.16 with HTTP; Fri, 16 Jul 2010 02:25:14 -0700 (PDT) In-Reply-To: <4C402346.1000008@gausus.net> References: <4C402346.1000008@gausus.net> Date: Fri, 16 Jul 2010 11:25:14 +0200 Message-ID: From: Cristiano Deana To: Maciej Jan Broniarz , FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: bgpd tuning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:25:16 -0000 On Fri, Jul 16, 2010 at 11:15 AM, Maciej Jan Broniarz wrote: >> I'm setting up a (future) 8.1 box to run as bgpd. >> I know in 8.x there are some improvements in networking, has someone >> any advice to tuning this machine? >> >> bgpd, routing only. > > > How many peerings will You have, and how many prefixes You intend to > receive? What is the estimated total bandwidth. 30 peering + 1 route server, 320k prefixes, 200M bw. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:43:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83D31065679 for ; Fri, 16 Jul 2010 09:43:25 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 404338FC0C for ; Fri, 16 Jul 2010 09:43:25 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 644C41CC69; Fri, 16 Jul 2010 12:43:24 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 644C41CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279273404; bh=Qsg9huemlkV9vmGCi9AFsidMeLLiP0pdJMekNAV3H1w=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=V+5mC03Xu0dxSBCTzYOvKZivls86U+EWEYE0s0ExYUWdITADcn+CMNxCAqlzUsrd1 PG3oqT7l3bMDUXy6ir/hQjLX69TEd0ivzyhu8+s/SC4mO0z3SyERTQpfyidgeT0Sbi QgX904EToX3gUumVlkDAMr/PqyHnwHqq/pS1ZR6U= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Pm8lc6zqhehO; Fri, 16 Jul 2010 12:43:20 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 9D2BB1CC67; Fri, 16 Jul 2010 12:43:20 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 9D2BB1CC67 Message-ID: From: "Reko Turja" To: "Jeremy Chadwick" References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> In-Reply-To: <20100716092512.GA99365@icarus.home.lan> Date: Fri, 16 Jul 2010 12:43:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:43:26 -0000 > This doesn't help. The problem is that Cyrus imapd is completely > freaking out, continually dying and re-forking itself, with my=20 > kernel > message buffer filling rapidly + all.log filling. So, there is=20 > further > configuration of this daemon that's needed (meaning it does not work > "straight out of the box"), and I need those configuration details. Below is the relevant parts of my config that should get you going: my /usr/local/etc/cyrus.conf: START { # do not delete this entry! recover cmd=3D"ctl_cyrusdb -r" # this is only necessary if using idled for IMAP IDLE idled cmd=3D"idled" } # UNIX sockets start with a slash and are put into /var/imap/socket SERVICES { # add or remove based on preferences imap cmd=3D"imapd -C /usr/local/etc/imapd.conf" = listen=3D"imap"=20 prefork=3D0 # pop3 cmd=3D"pop3d" listen=3D"pop3" prefork=3D0 # pop3s cmd=3D"pop3d -s" listen=3D"pop3s" prefork=3D0 sieve cmd=3D"timsieved" listen=3D"sieve" prefork=3D0 # at least one LMTP is required for delivery # lmtp cmd=3D"lmtpd" listen=3D"lmtp" prefork=3D0 lmtpunix cmd=3D"/usr/local/cyrus/bin/lmtpd"=20 listen=3D"/var/imap/socket/lmtp" prefork=3D0 # this is only necessary if using notifications notify cmd=3D"notifyd" listen=3D"/var/imap/socket/notify"=20 proto=3D"udp" prefork=3D1 } EVENTS { # this is required checkpoint cmd=3D"ctl_cyrusdb -c" period=3D30 # this is only necessary if using duplicate delivery suppression delprune cmd=3D"cyr_expire -E 3" at=3D0400 # this is only necessary if caching TLS sessions tlsprune cmd=3D"tls_prune" period=3D1440 } And /usr/local/etc/imapd.conf # # $FreeBSD: ports/mail/cyrus-imapd2/files/imapd.conf,v 1.8 2002/08/08=20 14:06:48 ume Exp $ # # Sample configurations file for Cyrus IMAPd # Most lines in this file are commented; in this case the default is=20 used. # The commented lines (usually) contain the default value configdirectory: /var/imap partition-default: /usr/local/imap unixhierarchysep: yes lmtp_downcase_rcpt: yes imap_allowanonymouslogin: no sieve_allowanonymouslogin: no imap_allowplaintext: no sieve_allowplaintext: yes imapidresponse: yes admins: cyrus toor autocreatequota: -128 duplicatesuppression: yes sendmail: /usr/local/sbin/sendmail postmaster: postmaster sieve_maxscripts: 15 sasl_maximum_layer: 256 sasl_minimum_layer: 0 sasl_pwcheck_method: saslauthd sasl_auto_transition: yes lmtpsocket: /var/imap/socket/lmtp idlesocket: /var/imap/socket/idle notifysocket: /var/imap/socket/notify # # EOF In addition, check that you have the following directories created +=20 run the mkimap for creating the rest of directories/db's Create the configuration directory specified by the "configdirectory"=20 option in "imapd.conf." The configuration directory is similar in=20 concept to the "/usr/lib/news" directory. It stores information about=20 the IMAP server as a whole. This document uses the configuration directory "/var/imap" in its=20 examples. This directory should be owned by the cyrus user and group=20 and should not permit access to other users. cd /var mkdir imap chown cyrus imap chgrp mail imap chmod 750 imap Create the default partition directories specified in the=20 "/etc/imapd.conf" file. This document uses a default partition directory of "/var/spool/imap"=20 in the following example: cd /var/spool mkdir imap chown cyrus imap chgrp mail imap chmod 750 imap Change to the Cyrus user and use the tool "tools/mkimap" to create the=20 rest of the directories (subdirectories of the directories you just=20 created). su cyrus tools/mkimap exit Hope this helps -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 09:51:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E391065672 for ; Fri, 16 Jul 2010 09:51:41 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 065158FC14 for ; Fri, 16 Jul 2010 09:51:41 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 353E11CC69; Fri, 16 Jul 2010 12:51:40 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 353E11CC69 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279273900; bh=HTFIYSQYiB5qNspXdWdg5KAblS1sqdUmfstBH6QL/wY=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sSu3ZCouRpWJBn8O0OYM6g8szDI4P964npd8c4KmFQvbog2AyB9jOOMEOjAm78DuV t3mo9Q2AGfJAz0x8EppDstysu4cLReXQqQI3QgVFSpZU86loKZ632PkxFvf6aMD1T2 VgO45HONd3SsWqC7K/DHO3E086skWgEGqouEMOyQ= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RbDhlTaZSg9J; Fri, 16 Jul 2010 12:51:36 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 972851CC67; Fri, 16 Jul 2010 12:51:36 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 972851CC67 Message-ID: <94382A43AE5842FD9571AE05688F09D8@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092209.GA99001@icarus.home.lan> In-Reply-To: <20100716092209.GA99001@icarus.home.lan> Date: Fri, 16 Jul 2010 12:51:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 09:51:41 -0000 >> void >> 232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj, >> OM_uint32 min) >> 233 { >> 234 OM_uint32 major_status, minor_status; >> 235 OM_uint32 message_content; >> 236 struct mg_thread_ctx *mg; >> 237 >> 238 mg =3D &last_error_context; >> 239 >> 240 gss_release_buffer(&minor_status, &mg->maj_error); >> 241 gss_release_buffer(&minor_status, &mg->min_error); >> 242 >> 243 mg->mech =3D &m->gm_mech_oid; >> 244 mg->maj_stat =3D maj; >> >> when I give following comands, gdb tells me: >> >> (gdb) p last_error_context >> Cannot find thread-local variables on this target >> (gdb) p &last_error_context >> Cannot find thread-local variables on this target >> (gdb) p mg >> No symbol "mg" in current context. >> (gdb) > > I'm not sure if you're familiar with C or not. > > This is because gdb's context is at the wrong frame. In the=20 > backtrace > you provided originally, you'd need to do: > > (gdb) frame 2 > > To look at the variables associated with gss_display_status.c. > > last_error_context could be an exported variable (you'd need to look > through the source to find out where it's declared), so you might=20 > have > to print it with its source filename referenced. The print command=20 > I > gave you before (p/x filename.c::variable) didn't work, and that's a > surprise since the gdb documentation I read says it should. > > Also be aware that mg is a struct, so "p mg" won't tell you much,=20 > other > than whether or not it's null. You're probably more interested in > members of the struct, such as mg->maj_error and mg->min_error, and > other struct members. I gave f 2 before entering the commands above, and unless I'm much=20 mistaken, 'p mg' should at least give the pointer to the start of the=20 struct in question, so 'No symbol "mg" in current context' is mildly=20 interesting reply from GDB :) If I understand the code in question=20 right the last_error_context's address should be copied to mg for=20 accessing the error structure defined elsewhere in the scope of the=20 while. the definition is in same file and is as follows: 176 #if defined(__sparc64__) || defined(__arm__) ||=20 defined(__mips__) 177 178 /* 179 * These platforms don't support TLS on FreeBSD - threads will=20 just 180 * have to step on each other's error values for now. 181 */ 182 #define __thread 183 184 #endif 185 186 struct mg_thread_ctx { 187 gss_OID mech; 188 OM_uint32 maj_stat; 189 OM_uint32 min_stat; 190 gss_buffer_desc maj_error; 191 gss_buffer_desc min_error; 192 }; 193 static __thread struct mg_thread_ctx last_error_context -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 11:04:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD34F1065675 for ; Fri, 16 Jul 2010 11:04:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 866B88FC08 for ; Fri, 16 Jul 2010 11:04:29 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id iajo1e0071wpRvQ51b4Wkn; Fri, 16 Jul 2010 11:04:30 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.westchester.pa.mail.comcast.net with comcast id ib4U1e00T3LrwQ23eb4V66; Fri, 16 Jul 2010 11:04:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 861A49B425; Fri, 16 Jul 2010 04:04:27 -0700 (PDT) Date: Fri, 16 Jul 2010 04:04:27 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716110427.GA1939@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 11:04:30 -0000 On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote: > >This doesn't help. The problem is that Cyrus imapd is completely > >freaking out, continually dying and re-forking itself, with my > >kernel > >message buffer filling rapidly + all.log filling. So, there is > >further > >configuration of this daemon that's needed (meaning it does not work > >"straight out of the box"), and I need those configuration details. > > Below is the relevant parts of my config that should get you going: > [...] Thanks. Most of this worked, except the following: > And /usr/local/etc/imapd.conf > [...] > partition-default: /usr/local/imap > [...] > Change to the Cyrus user and use the tool "tools/mkimap" to create > the rest of the directories (subdirectories of the directories you > just created). > su cyrus > tools/mkimap > exit I changed partition-default to /var/spool/imap, which I think is what was needed, otherwise mkimap complained about being unable to create /usr/local/imap. Also, for the su portion, I had to do: # su cyrus % cd /usr/local/cyrus % bin/mkimap Which worked. I hope this was the right thing to do. However, upon startup, I now see the following in all.log: Jul 16 03:56:12 testbox master[1521]: process started Jul 16 03:56:12 testbox master[1522]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 Which is true: testbox# find /usr/local -name "idled" -follow -ls testbox# I'm not sure if this feature is needed for reproducing the crash, so I modified cyrus.conf and commented the line out, then restarted imapd, which got me: Jul 16 04:00:22 testbox master[1594]: process started Jul 16 04:00:22 testbox master[1595]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases Jul 16 04:00:22 testbox master[1594]: ready for work Jul 16 04:00:22 testbox master[1596]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb Jul 16 04:00:22 testbox master[1597]: about to exec /usr/local/cyrus/bin/notifyd Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/annotations.db Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/mailboxes.db Jul 16 04:00:22 testbox notify[1597]: executed Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0 testbox# ps -auxw | grep cyrus cyrus 1594 0.0 0.4 22376 3916 ?? Ss 4:00AM 0:00.01 /usr/local/cyrus/bin/master -d cyrus 1597 0.0 0.4 53292 4412 ?? I 4:00AM 0:00.01 notifyd testbox# sockstat -l | grep cyrus cyrus notifyd 1597 4 dgram /var/imap/socket/notify cyrus master 1594 7 tcp4 *:143 *:* cyrus master 1594 10 tcp4 *:4190 *:* cyrus master 1594 13 stream /var/imap/socket/lmtp cyrus master 1594 16 dgram /var/imap/socket/notify Then for the final test: testbox# cyradm cyradm> quit testbox# cyradm localhost Password: Where I hit enter/blank, which got me: Login disabled. cyradm: cannot authenticate to server with as root testbox# And no sign of a crash. So what's next? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 11:10:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFF40106566B for ; Fri, 16 Jul 2010 11:10:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 689D78FC21 for ; Fri, 16 Jul 2010 11:10:03 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ib401e0021ei1Bg5BbA310; Fri, 16 Jul 2010 11:10:03 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.westchester.pa.mail.comcast.net with comcast id ibA21e0013LrwQ23kbA24z; Fri, 16 Jul 2010 11:10:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D4FFD9B425; Fri, 16 Jul 2010 04:10:00 -0700 (PDT) Date: Fri, 16 Jul 2010 04:10:00 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716111000.GA2501@icarus.home.lan> References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100716110427.GA1939@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 11:10:03 -0000 On Fri, Jul 16, 2010 at 04:04:27AM -0700, Jeremy Chadwick wrote: > On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote: > > >This doesn't help. The problem is that Cyrus imapd is completely > > >freaking out, continually dying and re-forking itself, with my > > >kernel > > >message buffer filling rapidly + all.log filling. So, there is > > >further > > >configuration of this daemon that's needed (meaning it does not work > > >"straight out of the box"), and I need those configuration details. > > > > Below is the relevant parts of my config that should get you going: > > [...] > > Thanks. Most of this worked, except the following: > > > And /usr/local/etc/imapd.conf > > [...] > > partition-default: /usr/local/imap > > [...] > > Change to the Cyrus user and use the tool "tools/mkimap" to create > > the rest of the directories (subdirectories of the directories you > > just created). > > su cyrus > > tools/mkimap > > exit > > I changed partition-default to /var/spool/imap, which I think is what > was needed, otherwise mkimap complained about being unable to create > /usr/local/imap. > > Also, for the su portion, I had to do: > > # su cyrus > % cd /usr/local/cyrus > % bin/mkimap > > Which worked. I hope this was the right thing to do. > > However, upon startup, I now see the following in all.log: > > Jul 16 03:56:12 testbox master[1521]: process started > Jul 16 03:56:12 testbox master[1522]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb > Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: recovering cyrus databases > Jul 16 03:56:12 testbox ctl_cyrusdb[1522]: done recovering cyrus databases > Jul 16 03:56:12 testbox master[1523]: about to exec /usr/local/cyrus/bin/idled > Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory > Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1523]: can't exec /usr/local/cyrus/bin/idled for startup: No such file or directory > Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 > Jul 16 03:56:12 testbox kernel: Jul 16 03:56:12 testbox master[1521]: process 1523 exited, status 71 > > Which is true: > > testbox# find /usr/local -name "idled" -follow -ls > testbox# > > I'm not sure if this feature is needed for reproducing the crash, so I > modified cyrus.conf and commented the line out, then restarted imapd, > which got me: > > Jul 16 04:00:22 testbox master[1594]: process started > Jul 16 04:00:22 testbox master[1595]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb > Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: recovering cyrus databases > Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/mailboxes.db (0 records, 144 bytes) in 0 seconds > Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: skiplist: checkpointed /var/imap/annotations.db (0 records, 144 bytes) in 0 seconds > Jul 16 04:00:22 testbox ctl_cyrusdb[1595]: done recovering cyrus databases > Jul 16 04:00:22 testbox master[1594]: ready for work > Jul 16 04:00:22 testbox master[1596]: about to exec /usr/local/cyrus/bin/ctl_cyrusdb > Jul 16 04:00:22 testbox master[1597]: about to exec /usr/local/cyrus/bin/notifyd > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: checkpointing cyrus databases > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/annotations.db > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving database file: /var/imap/mailboxes.db > Jul 16 04:00:22 testbox notify[1597]: executed > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: archiving log file: /var/imap/db/log.0000000001 > Jul 16 04:00:22 testbox ctl_cyrusdb[1596]: done checkpointing cyrus databases > Jul 16 04:00:22 testbox master[1594]: process 1596 exited, status 0 > > testbox# ps -auxw | grep cyrus > cyrus 1594 0.0 0.4 22376 3916 ?? Ss 4:00AM 0:00.01 /usr/local/cyrus/bin/master -d > cyrus 1597 0.0 0.4 53292 4412 ?? I 4:00AM 0:00.01 notifyd > > testbox# sockstat -l | grep cyrus > cyrus notifyd 1597 4 dgram /var/imap/socket/notify > cyrus master 1594 7 tcp4 *:143 *:* > cyrus master 1594 10 tcp4 *:4190 *:* > cyrus master 1594 13 stream /var/imap/socket/lmtp > cyrus master 1594 16 dgram /var/imap/socket/notify > > Then for the final test: > > testbox# cyradm > cyradm> quit > testbox# cyradm localhost > Password: > > Where I hit enter/blank, which got me: > > Login disabled. > cyradm: cannot authenticate to server with as root > testbox# > > And no sign of a crash. > > So what's next? I forgot to check all.log. It contains errors. Hopefully someone will know what to do about this: Jul 16 04:03:50 testbox imap[1619]: executed Jul 16 04:03:50 testbox imap[1619]: accepted connection Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox perl: DIGEST-MD5 client step 2 Jul 16 04:04:00 testbox imap[1619]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-17): One time use of a plaintext password will enable requested mechanism for user: no secret in database] Jul 16 04:04:03 testbox perl: NTLM client step 1 Jul 16 04:04:03 testbox imap[1619]: NTLM server step 1 Jul 16 04:04:03 testbox imap[1619]: client flags: 207 Jul 16 04:04:03 testbox perl: NTLM client step 2 Jul 16 04:04:03 testbox perl: No worthy mechs found Jul 16 04:04:03 testbox kernel: Jul 16 04:04:03 testbox perl: No worthy mechs found But like I said, no segfault/crash. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 11:14:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D8D1065675 for ; Fri, 16 Jul 2010 11:14:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E35598FC1B for ; Fri, 16 Jul 2010 11:14:30 +0000 (UTC) Received: by wyf22 with SMTP id 22so1964718wyf.13 for ; Fri, 16 Jul 2010 04:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AHQRacwMmc/LlHig0RdHRi3M5opOjK4Zx5yplfXk8Gs=; b=fnTzjucZ5zqAb4BPRTW1Mt4PgsNVk6WwZeuFVhn8NuRJtNsyQf45VV/vlWPB4WNRom ymwFmMM6FhzLNiNA6Bf5aK7Txn+g2+WN+reyLPbcffKYaBnMVsdUQU++XVl1zpmmKDSp KiNtCWLjByHFA/NuHT16iqTQQn6MpvieT/0YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f4wXOEC311OE26W/zJ+32bVv1CGm9fo3XDJeXbyRx72c3PhJ9U269Yhf7RcfG58AWV FqslLQL7pM2IkfC639/y0Ad/oppUydHTdWfi7HwhGrRg9zjQBkgNm4M8lx7q6WCNcERq uk5V9eJKF2YzFQMqj/Kqwczb7l/hzhXAgysEk= MIME-Version: 1.0 Received: by 10.227.136.17 with SMTP id p17mr804069wbt.54.1279278869331; Fri, 16 Jul 2010 04:14:29 -0700 (PDT) Received: by 10.216.137.23 with HTTP; Fri, 16 Jul 2010 04:14:29 -0700 (PDT) In-Reply-To: <201007151518.17012.jkim@FreeBSD.org> References: <201007151657.o6FGv97V080710@lurza.secnetix.de> <4C3F4BBB.30606@icyb.net.ua> <201007151507.33998.jkim@FreeBSD.org> <201007151518.17012.jkim@FreeBSD.org> Date: Fri, 16 Jul 2010 15:14:29 +0400 Message-ID: From: pluknet To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oliver Fromme , freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 11:14:31 -0000 On 15 July 2010 23:18, Jung-uk Kim wrote: > On Thursday 15 July 2010 03:07 pm, Jung-uk Kim wrote: >> On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: >> > on 15/07/2010 19:57 Oliver Fromme said the following: >> > > In topo_probe(), cpu_high is 0xd, so topo_probe_0xb() is >> > > called. =A0But the cpuid 0xb instruction doesn't seem to >> > > return useful data: =A0All values are zero already in the >> > > first level, so cpu_cores remains 0. >> > > >> > > Back in topo_probe(), there is a fallback if cpu_cores is >> > > stil 0: =A0It assigns mp_ncpu to cpu_cores, so it gets 8 >> > > which is wrong. >> > > >> > > I patched topo_probe() so it calls topo_probe_0x4() after >> > > topo_probe_0xb() if cpu_cores is still 0. =A0I think this >> > > is a better fallback procedure. =A0With this patch, cpu_cores >> > > gets the value 4 which is the correct one, finally: >> > > >> > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> > > FreeBSD/SMP: 2 package(s) x 4 core(s) >> > >> > Thank you for debugging this issue! >> > Not sure if this is the best patch that there can be, but its >> > direction is definitely correct. >> > As the Intel document says (translated to our x86 mp_machdep.c >> > terms): if cpu_high >=3D 0xb then we should execute >> > cpuid_count(0xb, 0, p) and examine EBX value (p[1]), only if it's >> > non-zero should we proceed with topo_probe_0xb(), otherwise we >> > should fall back to topo_probe_0x4, etc. >> > >> > I think that your addition achieves this effect, perhaps just not >> > as explicitly as I would preferred. >> > >> > Jung-uk, what do you think? >> >> Yes, you're right. =A0Please try new patch: >> >> http://people.freebsd.org/~jkim/mp_machdep2.diff > > I uploaded the patch again, it's compile-tested this now. > Just tried with the patch against 8.1-rc2. 2x E5520 - OK, no changes FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads 2x E5440 - now OK FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) 1x 5050 - OK, no changes FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 11:33:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78CFE106566B for ; Fri, 16 Jul 2010 11:33:20 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 19DE38FC0C for ; Fri, 16 Jul 2010 11:33:20 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 496C51CC5A; Fri, 16 Jul 2010 14:33:19 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 496C51CC5A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279279999; bh=W9COeVc+Q5FjLVIwn+8VmcR1UF8LKi/pIVjwMFMbq+c=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dRXOKF0/hCh6vhAWlLijtv4U3Ilgw59ywW2gs0u+Ik05i9diSiomFKzT92jqFFDwf PHzmIe2HkzsFg8gRqhDYlWyvq/51uAcVDXhfB1K6+oc64aUK/2BT5zwmToSBZxQ1rj 91w88XFc03ozzliGnZ6AX/xHcpFDgWYL11oGmKy0= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g+uru+ctxA52; Fri, 16 Jul 2010 14:33:16 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id DB2241CC59; Fri, 16 Jul 2010 14:33:15 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net DB2241CC59 Message-ID: <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" References: <4C3CC831.7040005@kaarposoft.dk> <20100713210729.GA11943@icarus.home.lan> <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> In-Reply-To: <20100716111000.GA2501@icarus.home.lan> Date: Fri, 16 Jul 2010 14:33:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 11:33:20 -0000 >> Thanks. Most of this worked, except the following: [SNIP] >> Which worked. I hope this was the right thing to do. My bad there, I was slightly pressed for time and did not check if=20 default cyrus documentation was sane in freebsd context - what you did=20 was quite correct. >> However, upon startup, I now see the following in all.log: [SNIP] >> I'm not sure if this feature is needed for reproducing the crash,=20 >> so I >> modified cyrus.conf and commented the line out, then restarted=20 >> imapd, >> which got me: Yep, idled can be disabled as far as I'm aware, so nothing drastic=20 there either. >> Then for the final test: >> >> testbox# cyradm >> cyradm> quit >> testbox# cyradm localhost >> Password: >> >> Where I hit enter/blank, which got me: >> >> Login disabled. >> cyradm: cannot authenticate to server with as root >> testbox# >> >> And no sign of a crash. >> >> So what's next? > > I forgot to check all.log. It contains errors. Hopefully someone=20 > will > know what to do about this: > > Jul 16 04:03:50 testbox imap[1619]: executed > Jul 16 04:03:50 testbox imap[1619]: accepted connection > Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't=20 > read/write key database /etc/opiekeys: Permission denied > Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox imap[1619]:=20 > OTP unavailable because can't read/write key database /etc/opiekeys:=20 > Permission denied > Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure=20 > (see text) (unknown mech-code 2 for mech unknown) > Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox perl: GSSAPI=20 > Error: Miscellaneous failure (see text) (unknown mech-code 2 for=20 > mech unknown) > Jul 16 04:03:50 testbox perl: DIGEST-MD5 client step 2 > Jul 16 04:04:00 testbox imap[1619]: badlogin: localhost [127.0.0.1]=20 > DIGEST-MD5 [SASL(-17): One time use of a plaintext password will=20 > enable requested mechanism for user: no secret in database] > Jul 16 04:04:03 testbox perl: NTLM client step 1 > Jul 16 04:04:03 testbox imap[1619]: NTLM server step 1 > Jul 16 04:04:03 testbox imap[1619]: client flags: 207 > Jul 16 04:04:03 testbox perl: NTLM client step 2 > Jul 16 04:04:03 testbox perl: No worthy mechs found > Jul 16 04:04:03 testbox kernel: Jul 16 04:04:03 testbox perl: No=20 > worthy mechs found You can move the surplus mechs (libopie*, libntlm*) from=20 /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled check that you have the following in /etc/rc.conf and restart=20 saslauthd afterwards saslauthd_enable=3D"YES" saslauthd_flags=3D"-a pam" -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 12:24:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3C86106566C for ; Fri, 16 Jul 2010 12:24:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9F78FC17 for ; Fri, 16 Jul 2010 12:24:48 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id ib4T1e0060Fqzac5EcQp9z; Fri, 16 Jul 2010 12:24:49 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta08.westchester.pa.mail.comcast.net with comcast id icQn1e0043LrwQ23UcQocs; Fri, 16 Jul 2010 12:24:49 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8843A9B425; Fri, 16 Jul 2010 05:24:46 -0700 (PDT) Date: Fri, 16 Jul 2010 05:24:46 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716122446.GA3241@icarus.home.lan> References: <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 12:24:49 -0000 On Fri, Jul 16, 2010 at 02:33:17PM +0300, Reko Turja wrote: > You can move the surplus mechs (libopie*, libntlm*) from > /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled To deal with this in a more clean manner, I rebuilt security/cyrus-sasl23 with the following OPTIONS unchecked: OTP NTLM > check that you have the following in /etc/rc.conf and restart > saslauthd afterwards > > saslauthd_enable="YES" > saslauthd_flags="-a pam" saslauthd isn't in use/installed on this system: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15 Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package Same situation: testbox# cyradm localhost Password: Login disabled. cyradm: cannot authenticate to server with as root all.log: Jul 16 05:13:19 testbox master[10873]: about to exec /usr/local/cyrus/bin/imapd Jul 16 05:13:19 testbox imap[10873]: executed Jul 16 05:13:19 testbox imap[10873]: accepted connection Jul 16 05:13:19 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:13:19 testbox kernel: Jul 16 05:13:19 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:13:19 testbox perl: DIGEST-MD5 client step 2 Jul 16 05:13:20 testbox imap[10873]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-17): One time use of a plaintext password will enable requested mechanism for user: no secret in database] Jul 16 05:13:23 testbox perl: No worthy mechs found Jul 16 05:13:23 testbox kernel: Jul 16 05:13:23 testbox perl: No worthy mechs found It looks like authentication isn't working, probably because I haven't added any users into the SASL authentication DB. I believe saslauthd can also solve this (allowing use of things like /etc/master.passwd for authentication, as well as other frameworks), but it doesn't look like it's required. When I did "make install" for security/cyrus-sasl23, I saw this message near the end: You can use sasldb2 for authentication, to add users use: saslpasswd2 -c username So I tried doing exactly that: testbox# saslpasswd2 -c root Password: Again (for verification): testbox# Now let's try cyradm again. Note that at this point I *have not* entered a password below: testbox# cyradm localhost Password: I immediately see this in syslog: Jul 16 05:19:47 testbox imap[10881]: accepted connection Jul 16 05:19:47 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 05:19:47 testbox perl: DIGEST-MD5 client step 2 Now if I enter the correct password, I get a new prompt: localhost> And syslog then shows: Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: No such file or directory Jul 16 05:21:06 testbox perl: DIGEST-MD5 client step 3 Jul 16 05:21:06 testbox imap[10881]: login: localhost [127.0.0.1] root DIGEST-MD5 User logged in Jul 16 05:21:06 testbox imap[10881]: IOERROR: opening /var/imap/user_deny.db: No such file or directory So it looks like SASL-wise things are functioning correctly, but GSSAPI isn't in use (you can see from the error it spits out above). I think we need the OP of the PR[1], Mikhail T., to chime in here with his setup. [1]: http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 12:58:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23580106566B for ; Fri, 16 Jul 2010 12:58:05 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id BE6448FC1D for ; Fri, 16 Jul 2010 12:58:04 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id DEB2C1CC67; Fri, 16 Jul 2010 15:58:03 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net DEB2C1CC67 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279285083; bh=xng4RZ90mrO29TC9j8O5I3jyLn/I5hzXFkCAhnGW6/8=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nWIrZBfK7ejc5Ax6RmLSseg/6/RSDqjRVnzVMDPGveoZ3r2rLVB8MT0W6aXuQVgjP PbMkml8YI9P81cZePdXL3qnWnBeBioUVC0EAY83vlignwKqVir4sKwViFNceyMJtVI 6j1a2eDJ//EQzowizkmRGWq9xuxajr62a7+hKY4s= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yRvfAHg1Eeie; Fri, 16 Jul 2010 15:58:02 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id DBBF11CC5A; Fri, 16 Jul 2010 15:58:01 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net DBBF11CC5A Message-ID: From: "Reko Turja" To: "Jeremy Chadwick" References: <0228E401B70A4023A6F86A2ADAE59EF9@rivendell> <008D0251AE4F4A2DBAA1369410565B61@rivendell> <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> In-Reply-To: <20100716122446.GA3241@icarus.home.lan> Date: Fri, 16 Jul 2010 15:58:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 12:58:05 -0000 > I think we need the OP of the PR[1], Mikhail T., to chime in here=20 > with his > setup. While waiting, can you test the following: In the=20 /usr/local/etc/imapd.conf file comment out #sasl_pwcheck_method: saslauthd and add below it: sasl_mech_list: gssapi pam plain -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 13:04:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBA191065676 for ; Fri, 16 Jul 2010 13:04:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 65A5C8FC0C for ; Fri, 16 Jul 2010 13:04:33 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o6GD4VH6025538; Fri, 16 Jul 2010 09:04:31 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201007161304.o6GD4VH6025538@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Jul 2010 09:04:39 -0400 To: Cristiano Deana , From: Mike Tancsa In-Reply-To: References: <4C402346.1000008@gausus.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: bgpd tuning X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 13:04:34 -0000 At 05:25 AM 7/16/2010, Cristiano Deana wrote: >30 peering + 1 route server, 320k prefixes, 200M bw. For 8.x, make sure you turn off flowtables. It does not do well with a full view. ---Mike From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 13:51:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B494B1065670 for ; Fri, 16 Jul 2010 13:51:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0368FC15 for ; Fri, 16 Jul 2010 13:51:04 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id icTf1e0051uE5Es51dr5z4; Fri, 16 Jul 2010 13:51:05 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta16.westchester.pa.mail.comcast.net with comcast id idr41e0053LrwQ23cdr4h6; Fri, 16 Jul 2010 13:51:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B0D1B9B425; Fri, 16 Jul 2010 06:51:02 -0700 (PDT) Date: Fri, 16 Jul 2010 06:51:02 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100716135102.GA5625@icarus.home.lan> References: <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 13:51:05 -0000 On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote: > >I think we need the OP of the PR[1], Mikhail T., to chime in here > >with his > >setup. > > While waiting, can you test the following: In the > /usr/local/etc/imapd.conf file comment out > > #sasl_pwcheck_method: saslauthd > > and add below it: > > sasl_mech_list: gssapi pam plain Thanks -- I did so + restarted imapd, and now we have: testbox# cyradm localhost Login disabled. cyradm: cannot authenticate to server with as root Jul 16 06:46:02 testbox master[11087]: about to exec /usr/local/cyrus/bin/imapd Jul 16 06:46:02 testbox imap[11087]: executed Jul 16 06:46:02 testbox imap[11087]: accepted connection Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 06:46:02 testbox perl: No worthy mechs found Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: No worthy mechs found -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 15:48:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4E243106564A; Fri, 16 Jul 2010 15:48:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: David Xu Date: Fri, 16 Jul 2010 11:47:39 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> In-Reply-To: <4C3FB73F.7070502@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007161147.56242.jkim@FreeBSD.org> Cc: Oliver Fromme , freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 15:48:04 -0000 On Thursday 15 July 2010 09:34 pm, David Xu wrote: > Jung-uk Kim wrote: > > On Wednesday 14 July 2010 05:40 pm, Jung-uk Kim wrote: > >> On Wednesday 14 July 2010 01:31 pm, Andriy Gapon wrote: > >>> on 14/07/2010 17:14 Oliver Fromme said the following: > >>>> In a machine installed yesterday, 8.1-PRERELEASE doesn't > >>>> seem to detect the number of CPU packages vs. cores per > >>>> > >>>> package correctly: > >>>> | FreeBSD 8.1-PRERELEASE-20100713 #0: Tue Jul 13 19:51:18 UTC > >>>> | 2010 [...] > >>>> | CPU: Intel(R) Xeon(R) CPU L5408 @ 2.13GHz > >>>> | (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = > >>>> | 0x1067a Family = 6 Model = 17 Stepping = 10 > >>>> | Features=0xbfebfbff >>>> |, SE > >>>> | P,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE > >>>> |, SSE 2,SS,HTT,TM,PBE> > >>>> | Features2=0x40ce3bd >>>> |3 ,C X16,xTPR,PDCM,DCA,SSE4.1,XSAVE> AMD > >>>> | Features=0x20000800 > >>>> | AMD Features2=0x1 > >>>> | TSC: P-state invariant > >>>> | real memory = 34359738368 (32768 MB) > >>>> | avail memory = 33151377408 (31615 MB) > >>>> | ACPI APIC Table: > >>>> | FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > >>>> | FreeBSD/SMP: 1 package(s) x 8 core(s) > >>>> | 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: 6 > >>>> | cpu7 (AP): APIC ID: 7 > >>>> | ioapic1 irqs 24-47 on motherboard > >>>> | ioapic0 irqs 0-23 on motherboard > >>>> > >>>> I'm pretty sure that this is a 2 x 4 machine (2 CPU packages > >>>> with 4 cores per package), not 1 x 8. That's what the BIOS > >>>> displays during POST. > >>>> > >>>> I'm not sure if this is just a "cosmetic" issue, or if this > >>>> is a critical thing ... I could imagine that performance > >>>> might be sub-optimal if the CPU topology isn't detected > >>>> correctly, but I'm not sure if FreeBSD can take advantage > >>>> of the topology. > >>> > >>> Could you please try to do the following? > >>> 1. Fetch topo-12212009.tar from the top of this page: > >>> http://software.intel.com/en-us/articles/intel-64-architecture- > >>>pr oc essor-topology-enumeration/ 2. Untar it and apply this > >>> patch to the code: > >>> http://people.freebsd.org/~avg/cpu-topology.diff > >>> 3. Compile it by running sh mk_64.sh (supposing you have amd64 > >>> system installed) 4. Run cpu_topology64.out and report back its > >>> output. > >> > >> It's funny that I actually wrote a convenience script (and > >> cleaned up today): > >> > >> http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > >> > >> BTW, current topology detection code is not optimal for some > >> Intel processors if my memory serves. > > > > Surprisingly, I found a patch I wrote last year from /tmp of my > > desktop and it is still applied cleanly. 8-) > > > > Just in case, it is available from here: > > > > http://people.freebsd.org/~jkim/mp_machdep.diff > > > > It is applicable to both sys/amd64/amd64/mp_machdep.c and > > sys/i386/i386/mp_machdep.c. I have to warn you, though, it > > hasn't been used for more than a year, so it may not work at all. > > ;-) > > > > Jung-uk Kim > > Do you have patch for i386 branch ? I want to test. The patch should apply fine on both sys/amd64/amd64/mp_machdep.c and sys/i386/i386/mp_machdep.c. http://people.freebsd.org/~jkim/mp_machdep2.diff > On my Pentium-D machine: > > $ sysctl kern.sched.topology_spec > kern.sched.topology_spec: > > 0, 1 > > > > 0, 1 > > > > > > > it seems the kernel thinks that the Pentuim-D is sharing L2 cache, > but in fact, the design of the Pentium Ds was simply two P4 cores > sitting side by side. They do not share anything and they basically > work independently. cpu_topo() in mp_machdep.c is not that smart to distinguish whether two cores in one package is sharing L2 cache or not: /* * Only HTT no multi-core. */ if (cpu_logical > 1 && cpu_cores == 1) return (smp_topo_1level(CG_SHARE_L1, cpu_logical, cg_flags)); /* * Only multi-core no HTT. */ if (cpu_cores > 1 && cpu_logical == 1) return (smp_topo_1level(CG_SHARE_L2, cpu_cores, cg_flags)); /* * Both HTT and multi-core. */ return (smp_topo_2level(CG_SHARE_L2, cpu_cores, CG_SHARE_L1, cpu_logical, cg_flags)); In other words, if one package contains multiple cores, it is *assumed* sharing L2 cache. The same is true for HTT/SMT case (i.e., assumed sharing L1 cache). It does not care about L3 cache at all. Yes, we need some improvement in this area. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 18:52:45 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 0ADE3106566C; Fri, 16 Jul 2010 18:52:45 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 16 Jul 2010 14:52:35 -0400 User-Agent: KMail/1.6.2 References: <201007151507.33998.jkim@FreeBSD.org> <201007152001.o6FK1mGq088944@lurza.secnetix.de> <20100716075525.GA96403@icarus.home.lan> In-Reply-To: <20100716075525.GA96403@icarus.home.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007161452.37538.jkim@FreeBSD.org> Cc: Oliver Fromme , Andriy Gapon , Jeremy Chadwick Subject: Re: 8.1-PRERELEASE: CPU packages not detected correctly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 18:52:45 -0000 On Friday 16 July 2010 03:55 am, Jeremy Chadwick wrote: > On Thu, Jul 15, 2010 at 10:01:48PM +0200, Oliver Fromme wrote: > > Jung-uk Kim wrote: > > > On Thursday 15 July 2010 01:56 pm, Andriy Gapon wrote: > > > > on 15/07/2010 19:57 Oliver Fromme said the following: > > > > > I patched topo_probe() so it calls topo_probe_0x4() after > > > > > topo_probe_0xb() if cpu_cores is still 0. I think this > > > > > is a better fallback procedure. With this patch, > > > > > cpu_cores gets the value 4 which is the correct one, > > > > > finally: > > > > > > > > [...] > > > > I think that your addition achieves this effect, perhaps > > > > just not as explicitly as I would preferred. > > > > > > > > Jung-uk, what do you think? > > > > > > Yes, you're right. Please try new patch: > > > > > > http://people.freebsd.org/~jkim/mp_machdep2.diff > > > > Thank you! > > > > I will have access to that particular machine on Monday again, > > so testing the new patch will have to wait until Monday. > > But from looking at your patch it should have the same result > > as my simpler patch, so it should work fine. > > I have a general question for everyone involved in this thread > (which is highly educational/interesting -- thank you for all the > info!): > > Does the problem reported affect actual performance/behaviour of > FreeBSD kernel-wise at all, or is it just a cosmetical issue with > regards to showing how many cores/threads there are? Theoretically there is behavioral changes from scheduler. jeff@ should be able to tell you more about this. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 19:00:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A7D71065672 for ; Fri, 16 Jul 2010 19:00:51 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A07F8FC18 for ; Fri, 16 Jul 2010 19:00:50 +0000 (UTC) Received: by bwz12 with SMTP id 12so1524108bwz.13 for ; Fri, 16 Jul 2010 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jnWVx5Od50KI1XUd6djQ/LkqyLUKI8w/7ou7izTVSgQ=; b=elq4PXmhU1Pcm1VebbNkFsBGSqGXLx7SvZWFub3lwYkYY28ucwhDyi9JGdFruL6ShQ zqhpP7s26EthVRucmwAKZjZ2um5unCjqKnn4eMDRNno1VQsuOQJYBH1coYmJittmbdF5 xZTsBJ+pR7WEC3L21D7F2taLe4l7itcGj1R8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fO2t4sGS1t/bNsLL+oR6G+5SzwNTrS/E001y0ZxMVlu/XIGKvISpQ9hSaxmPLvQFv9 jap4j2yD77sAY9AdU2YGSEgzGk3b2JXMHG9oZ+4xFNl+odNaelMAPM+7A4vx5YRjmgVH rUrpBrYaMpmcSZ5YRI8uzCp8+8HzrgBQJwysE= MIME-Version: 1.0 Received: by 10.204.100.132 with SMTP id y4mr1253636bkn.117.1279306849254; Fri, 16 Jul 2010 12:00:49 -0700 (PDT) Received: by 10.204.118.83 with HTTP; Fri, 16 Jul 2010 12:00:49 -0700 (PDT) In-Reply-To: <877004.53626.qm@web59106.mail.re1.yahoo.com> References: <877004.53626.qm@web59106.mail.re1.yahoo.com> Date: Fri, 16 Jul 2010 21:00:49 +0200 Message-ID: From: David DEMELIER To: paradox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 19:00:51 -0000 2010/6/19 paradox : >>On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: >>> Hi there, >>> >>> I was so happy to see that VESA is available for amd64, but >>> unfortunately it does not work really well for me. Take a look at >>> this picture : >>> >>> http://img717.imageshack.us/img717/7311/dsc00399h.jpg >>> >>> My laptop is a 15,6" so the best resolution is 1366x768, I tried >>> this >>> >>> : vidcontrol MODE_496. As you can see on the picture all the lines >>> : are >>> >>> completely everywhere, if I mouse the cursor they move away (I'm >>> not drunk!). >>> >>> I have SC_PIXEL_MODE in my kernel config. >>> >>> The console terminal is okay until I don't excess 1280x960x32 video >>> mode. >>> >>> Do you have any idea to fix this ? >> >>It is kinda known problem. =C2=A0If the mode has larger bytes per scan li= ne >>than the minimum, few characters per line are lost when the screen is >>scrolled up or down, i.e., framebuffer copies of whole screen. =C2=A0When >>you move the mouse onto the line, entire line is redrawn and >>restored. =C2=A0That's what you are seeing. =C2=A0Ed might have a better = idea >>how to fix it (CC'ed). >> >>Jung-uk Kim > > this is incorrent calculate the scan lines in the vesa driver > Jung-uk Kim should to fix it > But Jung-uk Kim said Ed' should fix it so we are in an infinite loop :- --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 19:20:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD181065675 for ; Fri, 16 Jul 2010 19:20:18 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from web59103.mail.re1.yahoo.com (web59103.mail.re1.yahoo.com [66.196.101.14]) by mx1.freebsd.org (Postfix) with SMTP id 3E1458FC08 for ; Fri, 16 Jul 2010 19:20:18 +0000 (UTC) Received: (qmail 67980 invoked by uid 60001); 16 Jul 2010 19:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279308017; bh=8qsgKDOVewiPymt+f8Qu/twBOKr53/lRgE9ULmTwnpw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y08wJX9ncwuMrWjkQ5rNRkdpFiFF6BIVqJYogCI60UGJxUYsUb3Yhps+kUCqi1aLxIN7kEEVu7zxh8KxCriwGRFVpmqfItFJDjizvOt0u0QcmpP4G8gvD3ZuyNN4oYaNriDIboIOjdTNyJEtMxr/f5jfeIX5H47ZjZ3dZ1bIKxE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lCrSXDYJ6Ecp+tQNvzPSDKCU7cVNMD3EJEaIazudypfXhdL0cu0BpSgH4dv8ukOdrL6CzH7KW2z/A1VQ4dlzFhQ0cFUqVb2FTc1Psbh1VXfv+qdLQMZJNED1JAmePtNmbJA1pWoiRbSSNWjILUzHf2jWmeMwAFDTkUBoKOOR5Hw=; Message-ID: <625522.67259.qm@web59103.mail.re1.yahoo.com> X-YMail-OSG: ya_viaEVM1m08JCdGPj5.UkTiC.RuoznONiqkqmeJ_pvs7a I9Dcw4iEjOpfVMoakYPEPQPM.qcEi8OmpwIW2ZlNoagOrNOZsZgumv2tK0Rs qbrRKTPUoOxMX.sgzktcEijfcP8_DpWkYXBDPyOo3PpdDyOgiXpf72KoWhaz zDBkp9B17BIMnaBae5ELMrLuJrvjD7xkKkpsdDpMDuYQ6mrCCdedqszRHGRx 5P.ersPLAexXXMTLxi7FzEALKIDl9n1qDOwqNm2hnoszmXb44w2E2GjpbidZ RggoCGAL8HQ-- Received: from [95.109.133.194] by web59103.mail.re1.yahoo.com via HTTP; Fri, 16 Jul 2010 12:20:17 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.104.276605 Date: Fri, 16 Jul 2010 12:20:17 -0700 (PDT) From: paradox To: David DEMELIER In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 19:20:18 -0000 can you set less resolution? is the same bug? as example MODE_277 need more verbose information > >>On Wednesday 02 June 2010 04:25 pm, David DEMELIER > wrote: > >>> Hi there, > >>> > >>> I was so happy to see that VESA is available > for amd64, but > >>> unfortunately it does not work really well for > me. Take a look at > >>> this picture : > >>> > >>> http://img717.imageshack.us/img717/7311/dsc00399h.jpg > >>> > >>> My laptop is a 15,6" so the best resolution is > 1366x768, I tried > >>> this > >>> > >>> : vidcontrol MODE_496. As you can see on the > picture all the lines > >>> : are > >>> > >>> completely everywhere, if I mouse the cursor > they move away (I'm > >>> not drunk!). > >>> > >>> I have SC_PIXEL_MODE in my kernel config. > >>> > >>> The console terminal is okay until I don't > excess 1280x960x32 video > >>> mode. > >>> > >>> Do you have any idea to fix this ? > >> > >>It is kinda known problem. =A0If the mode has larger > bytes per scan line > >>than the minimum, few characters per line are lost > when the screen is > >>scrolled up or down, i.e., framebuffer copies of > whole screen. =A0When > >>you move the mouse onto the line, entire line is > redrawn and > >>restored. =A0That's what you are seeing. =A0Ed might > have a better idea > >>how to fix it (CC'ed). > >> > >>Jung-uk Kim > > > > this is incorrent calculate the scan lines in the vesa > driver > > Jung-uk Kim should to fix it > > >=20 > But Jung-uk Kim said Ed' should fix it so we are in an > infinite loop :- >=20 > --=20 > Demelier David > =0A=0A=0A From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 19:23:02 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E4FE8106566C; Fri, 16 Jul 2010 19:23:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 16 Jul 2010 15:22:42 -0400 User-Agent: KMail/1.6.2 References: <877004.53626.qm@web59106.mail.re1.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201007161522.54572.jkim@FreeBSD.org> Cc: David DEMELIER Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 19:23:02 -0000 On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: > 2010/6/19 paradox : > >>On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: > >>> Hi there, > >>> > >>> I was so happy to see that VESA is available for amd64, but > >>> unfortunately it does not work really well for me. Take a look > >>> at this picture : > >>> > >>> http://img717.imageshack.us/img717/7311/dsc00399h.jpg > >>> > >>> My laptop is a 15,6" so the best resolution is 1366x768, I > >>> tried this > >>> > >>> : vidcontrol MODE_496. As you can see on the picture all the > >>> : lines are > >>> > >>> completely everywhere, if I mouse the cursor they move away > >>> (I'm not drunk!). > >>> > >>> I have SC_PIXEL_MODE in my kernel config. > >>> > >>> The console terminal is okay until I don't excess 1280x960x32 > >>> video mode. > >>> > >>> Do you have any idea to fix this ? > >> > >>It is kinda known problem. ��If the mode has larger bytes per > >> scan line than the minimum, few characters per line are lost > >> when the screen is scrolled up or down, i.e., framebuffer copies > >> of whole screen. ��When you move the mouse onto the line, entire > >> line is redrawn and restored. ��That's what you are seeing. ��Ed > >> might have a better idea how to fix it (CC'ed). > >> > >>Jung-uk Kim > > > > this is incorrent calculate the scan lines in the vesa driver > > Jung-uk Kim should to fix it > > But Jung-uk Kim said Ed' should fix it so we are in an infinite > loop :- No, I didn't say that. What I meant was "Ed may be a better qualified person to fix syscons vs. terminal emulator interaction issues." :-( Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 23:18:43 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 130B01065675; Fri, 16 Jul 2010 23:18:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 16 Jul 2010 19:18:30 -0400 User-Agent: KMail/1.6.2 References: <877004.53626.qm@web59106.mail.re1.yahoo.com> <201007161522.54572.jkim@FreeBSD.org> In-Reply-To: <201007161522.54572.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_IjOQMTqa4EQrJwW" Message-Id: <201007161918.32195.jkim@FreeBSD.org> Cc: David DEMELIER Subject: Re: Strange video mode output with VESA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 23:18:43 -0000 --Boundary-00=_IjOQMTqa4EQrJwW Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline On Friday 16 July 2010 03:22 pm, Jung-uk Kim wrote: > On Friday 16 July 2010 03:00 pm, David DEMELIER wrote: > > 2010/6/19 paradox : > > >>On Wednesday 02 June 2010 04:25 pm, David DEMELIER wrote: > > >>> Hi there, > > >>> > > >>> I was so happy to see that VESA is available for amd64, but > > >>> unfortunately it does not work really well for me. Take a > > >>> look at this picture : > > >>> > > >>> http://img717.imageshack.us/img717/7311/dsc00399h.jpg > > >>> > > >>> My laptop is a 15,6" so the best resolution is 1366x768, I > > >>> tried this > > >>> > > >>> : vidcontrol MODE_496. As you can see on the picture all the > > >>> : lines are > > >>> > > >>> completely everywhere, if I mouse the cursor they move away > > >>> (I'm not drunk!). > > >>> > > >>> I have SC_PIXEL_MODE in my kernel config. > > >>> > > >>> The console terminal is okay until I don't excess 1280x960x32 > > >>> video mode. > > >>> > > >>> Do you have any idea to fix this ? > > >> > > >>It is kinda known problem. å ì™ì˜™If the mode has larger bytes per > > >> scan line than the minimum, few characters per line are lost > > >> when the screen is scrolled up or down, i.e., framebuffer > > >> copies of whole screen. å ì™ì˜™When you move the mouse onto the > > >> line, entire line is redrawn and restored. å ì™ì˜™That's what you > > >> are seeing. å ì™ì˜™Ed might have a better idea how to fix it > > >> (CC'ed). > > >> > > >>Jung-uk Kim > > > > > > this is incorrent calculate the scan lines in the vesa driver > > > Jung-uk Kim should to fix it > > > > But Jung-uk Kim said Ed' should fix it so we are in an infinite > > loop :- > > No, I didn't say that. What I meant was "Ed may be a better > qualified person to fix syscons vs. terminal emulator interaction > issues." :-( Can you please try the attached patch? --Boundary-00=_IjOQMTqa4EQrJwW Content-Type: text/plain; charset="utf-8"; name="scvgarndr.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="scvgarndr.c.diff" --- sys/dev/syscons/scvgarndr.c 2010-03-24 11:40:18.000000000 -0400 +++ sys/dev/syscons/scvgarndr.c 2010-07-16 19:05:12.000000000 -0400 @@ -728,12 +728,15 @@ vm_offset_t e; u_char *f; u_short col1, col2, color; - int line_width, pixel_size; + int line_width, off_width; + int font_size, pixel_size; int i, j, k; int a; line_width = scp->sc->adp->va_line_width; pixel_size = scp->sc->adp->va_info.vi_pixel_size; + off_width = line_width - scp->xpixel * pixel_size; + font_size = scp->font_size; d = VIDEO_MEMORY_POS(scp, from, 8 * pixel_size); @@ -752,9 +755,9 @@ } e = d; - f = &(scp->font[sc_vtb_getc(&scp->vtb, i) * scp->font_size]); + f = &(scp->font[sc_vtb_getc(&scp->vtb, i) * font_size]); - for (j = 0; j < scp->font_size; ++j, ++f) { + for (j = 0; j < font_size; ++j, ++f) { for (k = 0; k < 8; ++k) { color = *f & (1 << (7 - k)) ? col1 : col2; vga_drawpxl(e + pixel_size * k, color); @@ -766,8 +769,8 @@ d += 8 * pixel_size; if ((i % scp->xsize) == scp->xsize - 1) - d += scp->xoff * 16 * pixel_size + - (scp->font_size - 1) * line_width; + d += off_width + scp->xoff * pixel_size * font_size + + (font_size - 1) * line_width; } } --Boundary-00=_IjOQMTqa4EQrJwW-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 16 23:30:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B9B106566C for ; Fri, 16 Jul 2010 23:30:48 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 5B1208FC12 for ; Fri, 16 Jul 2010 23:30:47 +0000 (UTC) Received: (qmail invoked by alias); 16 Jul 2010 23:30:45 -0000 Received: from e180219233.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.180.219.233] by mail.gmx.com (mp-eu005) with SMTP; 17 Jul 2010 01:30:45 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1+IneJgiO+IzRH2PhAmoDbVI1BnVn1gSe6lG4DsD/ /C8STLn6SvmihY Received: by myhost.mydomain.de (Postfix, from userid 1001) id 0AA7491C3; Sat, 17 Jul 2010 01:30:44 +0200 (CEST) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Sat, 17 Jul 2010 01:30:25 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RC1; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6127825.jy1zcbCnie"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007170130.44701.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 Subject: interrupt issues 8_RELENG from two days ago X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jul 2010 23:30:48 -0000 --nextPart6127825.jy1zcbCnie Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, having upgraded my laptop to a recent 8_RELENG from an earlier 8_RELENG fro= m =20 the time of the 8.0 release, I find it behaves very strangely. When booting devd hangs often until cancelled with ctrl+c. Sometimes it seems that pending work is waiting for disk activity until it = is=20 kicked off. I noticed this when setting up the keycodes for zsh and the=20 duration for reading each key differed significantly depending whether ther= e=20 was disk activity or not. This happens as well in X as in console. I tried disabling powerd, setting kern.hz to 100 and using the timers ACPI- =46AST (default), HPET, i8254 and TSC - no change so far. I am not sure if it is because an ancient configuration setting I had in pl= ace=20 earlier and that I am missing now or whether this is due to a code change. However, I am at a loss and would appreciate further input on the matter. D= ue=20 to the upcoming release I am posting to -stable just to get this tracked in= =20 case this is the symptom of some obscure bug. Thank you in advance & Regards Christof This is vmstat -i: % vmstat -i = =20 ~ interrupt total rate irq1: atkbd0 28 0 irq9: acpi0 173 0 irq12: psm0 17 0 irq14: ata0 3009 8 irq16: wpi0 uhci3+ 5516 15 irq18: uhci2 14 0 irq21: fwohci0 2 0 irq22: bfe0 sdhci0 608 1 irq23: uhci0 ehci0 2 0 cpu0: timer 18165 51 irq256: hdac0 17 0 cpu1: timer 17986 50 Total 45537 127 this is dmesg: % dmesg = =20 ~ Copyright (c) 1992-2010 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. =46reeBSD is a registered trademark of The FreeBSD Foundation. =46reeBSD 8.1-PRERELEASE #0: Thu Jul 15 14:29:16 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz (1662.52-MHz K8-class= =20 CPU) Origin =3D "GenuineIntel" Id =3D 0x6f6 Family =3D 6 Model =3D f Stepp= ing =3D 6 Features=3D0xbfebfbff Features2=3D0xe39d AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 2684354560 (2560 MB) avail memory =3D 2562097152 (2443 MB) ACPI APIC Table: =46reeBSD/SMP: Multiprocessor System Detected: 2 CPUs =46reeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem=20 0xd8100000-0xd817ffff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at= =20 device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 o= n=20 pci0 hdac0: mem=20 0xd8240000-0xd8243fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 wpi0: mem 0xd4000000-0xd4000fff irq 16 at=20 device 0.0 on pci2 wpi0: Driver Revision 20071127 wpi0: Hardware Revision (0x1) adding chan 1 (2412MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 2 adding chan 2 (2417MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 4 adding chan 3 (2422MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 6 adding chan 4 (2427MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 8 adding chan 5 (2432MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 10 adding chan 6 (2437MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 12 adding chan 7 (2442MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 14 adding chan 8 (2447MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 16 adding chan 9 (2452MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 18 adding chan 10 (2457MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 20 adding chan 11 (2462MHz) flags=3D0x2b maxpwr=3D15 passive=3D0, offset 22 adding chan 12 (2467MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 24 adding chan 13 (2472MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 26 adding chan 34 (5170MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 27 adding chan 36 (5180MHz) flags=3D0xab maxpwr=3D15 passive=3D0, offset 28 adding chan 38 (5190MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 29 adding chan 40 (5200MHz) flags=3D0xab maxpwr=3D15 passive=3D0, offset 30 adding chan 42 (5210MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 31 adding chan 44 (5220MHz) flags=3D0xab maxpwr=3D15 passive=3D0, offset 32 adding chan 46 (5230MHz) flags=3D0x21 maxpwr=3D15 passive=3D1, offset 33 adding chan 48 (5240MHz) flags=3D0xab maxpwr=3D15 passive=3D0, offset 34 adding chan 52 (5260MHz) flags=3D0xb1 maxpwr=3D15 passive=3D1, offset 35 adding chan 56 (5280MHz) flags=3D0xb1 maxpwr=3D15 passive=3D1, offset 36 adding chan 60 (5300MHz) flags=3D0xb1 maxpwr=3D15 passive=3D1, offset 37 adding chan 64 (5320MHz) flags=3D0xb1 maxpwr=3D15 passive=3D1, offset 38 adding chan 100 (5500MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 39 adding chan 104 (5520MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 40 adding chan 108 (5540MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 41 adding chan 112 (5560MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 42 adding chan 116 (5580MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 43 adding chan 120 (5600MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 44 adding chan 124 (5620MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 45 adding chan 128 (5640MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 46 adding chan 132 (5660MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 47 adding chan 136 (5680MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 48 adding chan 140 (5700MHz) flags=3D0xb1 maxpwr=3D16 passive=3D1, offset 49 power group 0: chan=3D1 maxpwr=3D45 temp=3D-176 sample 0: index=3D13 power=3D42 sample 1: index=3D29 power=3D30 sample 2: index=3D47 power=3D11 sample 3: index=3D58 power=3D0 sample 4: index=3D77 power=3D-18 power group 1: chan=3D44 maxpwr=3D50 temp=3D-180 sample 0: index=3D12 power=3D42 sample 1: index=3D19 power=3D35 sample 2: index=3D32 power=3D22 sample 3: index=3D43 power=3D11 sample 4: index=3D77 power=3D-21 power group 2: chan=3D64 maxpwr=3D48 temp=3D-179 sample 0: index=3D12 power=3D41 sample 1: index=3D20 power=3D34 sample 2: index=3D33 power=3D21 sample 3: index=3D44 power=3D11 sample 4: index=3D77 power=3D-19 power group 3: chan=3D116 maxpwr=3D47 temp=3D-178 sample 0: index=3D12 power=3D36 sample 1: index=3D20 power=3D28 sample 2: index=3D36 power=3D11 sample 3: index=3D48 power=3D1 sample 4: index=3D77 power=3D-26 power group 4: chan=3D153 maxpwr=3D47 temp=3D-176 sample 0: index=3D10 power=3D35 sample 1: index=3D20 power=3D23 sample 2: index=3D32 power=3D11 sample 3: index=3D42 power=3D3 sample 4: index=3D77 power=3D-28 wpi0: Regulatory Domain: MoW2 wpi0: Hardware Type: B wpi0: Hardware Revision: ? wpi0: SKU does support 802.11a wpi0: [ITHREAD] pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23= at=20 device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 19= at=20 device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 18= at=20 device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1880-0x189f irq 16= at=20 device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xd8444000-0xd84443f= f=20 irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 = at=20 device 5.0 on pci5 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:13:77:27:90:3a bfe0: [ITHREAD] cbb0: at device 9.0 on pci5 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:01:03:a6:22 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:03:a6:22 fwe0: Ethernet address: 02:00:f0:03:a6:22 fwip0: on firewire0 fwip0: Firewire address: 00:00:f0:41:01:03:a6:22 @ 0xfffe00000000, S400,=20 maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x9ab44000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER=20 mode sdhci0: mem 0xd8002800-0xd80028ff at device 9.2 on pci5 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is=20 present; to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.c= onf. ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 10.000 msec vboxdrv: fAsync=3D0 offMin=3D0x122 offMax=3D0x398 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 cbb0: Unsupported card type detected ad0: 95396MB at ata0-master UDMA100=20 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 ugen4.1: at usbus4 uhub4: on usbus4 hdac0: HDA Codec #0: Analog Devices AD1986A hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) hdac0: hdac_widget_connection_parse: nid=3D18 WARNING: zero cnid entnum=3D4= j=3D2=20 index=3D0 entries=3D8 found=3D2 res=3D0x21002211 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from zfs:zroot/root ugen2.2: at usbus2 vboxnet0: Ethernet address: 0a:00:27:00:00:00 wlan0: Ethernet address: 00:18:de:24:c6:7c wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 microcode alive notification version 10e02 alive 1 microcode alive notification version 10e02 alive 1 wpi_newstate: INIT -> SCAN flags 0x0 wpi_newstate: SCAN -> AUTH flags 0x0 config chan 3 flags 8005 cck f ofdm 15 wpi_newstate: AUTH -> ASSOC flags 0x0 wpi_newstate: ASSOC -> RUN flags 0x0 config chan 3 flags 8015 wpi0: need multicast update callback wpi0: need multicast update callback wpi0: need multicast update callback WARNING: attempt to domain_add(bluetooth) after domainfinalize() drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart6127825.jy1zcbCnie Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEABECAAYFAkxA66QACgkQpZfyPAmdZJmL6ACgmHQy6o7A9QV/2zert8aQwOdI c5kAn1n5lq+3RbvVxipvluBwV4X9y2i1 =ulTX -----END PGP SIGNATURE----- --nextPart6127825.jy1zcbCnie-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 06:56:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4ADD106564A for ; Sat, 17 Jul 2010 06:56:12 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2CAF48FC1E for ; Sat, 17 Jul 2010 06:56:11 +0000 (UTC) Received: from mailhost.frm2.tum.de (localhost [127.0.0.1]) by mailhost.frm2.tum.de (8.14.3/8.14.3) with ESMTP id o6H6u35H094854; Sat, 17 Jul 2010 08:56:03 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) by mailhost.frm2.tum.de (8.14.3/8.14.3) with ESMTP id o6H6twlV094850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jul 2010 08:55:58 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: from hades.admin.frm2 (localhost [127.0.0.1]) by hades.admin.frm2 (8.14.3/8.14.3) with ESMTP id o6H6twZf033061; Sat, 17 Jul 2010 08:55:58 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: (from jpulz@localhost) by hades.admin.frm2 (8.14.3/8.14.3/Submit) id o6H6tvnw033060; Sat, 17 Jul 2010 08:55:57 +0200 (CEST) (envelope-from jpulz) Date: Sat, 17 Jul 2010 08:55:54 +0200 (CEST) From: Joerg Pulz To: Jeremy Chadwick In-Reply-To: <20100716135102.GA5625@icarus.home.lan> Message-ID: References: <20100715162251.GA73929@icarus.home.lan> <20100716083617.GA97981@icarus.home.lan> <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mailhost.frm2.tum.de [129.187.179.12]); Sat, 17 Jul 2010 08:55:58 +0200 (CEST) Cc: Reko Turja , "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 06:56:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 16 Jul 2010, Jeremy Chadwick wrote: > On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote: >>> I think we need the OP of the PR[1], Mikhail T., to chime in here >>> with his >>> setup. >> >> While waiting, can you test the following: In the >> /usr/local/etc/imapd.conf file comment out >> >> #sasl_pwcheck_method: saslauthd >> >> and add below it: >> >> sasl_mech_list: gssapi pam plain > > Thanks -- I did so + restarted imapd, and now we have: > > testbox# cyradm localhost > Login disabled. > cyradm: cannot authenticate to server with as root > > Jul 16 06:46:02 testbox master[11087]: about to exec /usr/local/cyrus/bin/imapd > Jul 16 06:46:02 testbox imap[11087]: executed > Jul 16 06:46:02 testbox imap[11087]: accepted connection > Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) > Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) > Jul 16 06:46:02 testbox perl: No worthy mechs found > Jul 16 06:46:02 testbox kernel: Jul 16 06:46:02 testbox perl: No worthy mechs found Jeremy, i followed this thread so far and searched a little bit about the issue. I also tested on my machines and came to an interesting point. First my setup is pretty straight forward. Set HEIMDAL_HOME=/usr . Build security/cyrus-sasl2 (OPTIONS don't matter i think). Build net/openldap24-sasl-client (select SASL OPTION) If you don't have any accessible LDAP server on your net (OpenLDAP or Windows AD doesn't matter) you have to build and just start one for yourself. Afterwards just try the following command: ldapsearch -Ygssapi -h Now the interesting point. On my amd64 system i get this after executing the above command: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) While on my i386 system i get this: SASL/GSSAPI authentication started Segmentation fault (core dumped) A quick look at the gdb bt of the core file looks like this: #0 0x28310ef5 in free () from /lib/libc.so.7 #1 0x283fc972 in gss_release_buffer () from /usr/lib/libgssapi.so.10 #2 0x283fc37e in gss_release_name () from /usr/lib/libgssapi.so.10 #3 0x283f8da9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 #4 0x283f1a0b in gssapi_client_mech_step () from /usr/local/lib/sasl2/libgssapiv2.so.2 #5 0x280ed4f4 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 So i think i've hit the same bug all others are experiencing. It looks like it is a i386 speciality but it can also be pure luck an amd64. I found at least one other report on the net which looks very similar to what i see. i386 == Segmentation fault, amd64 == Error message. Jeremy, is your test system running on amd64 or i386? Kind regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMQVP9SPOsGF+KA+MRAn3OAJ4r5fqAoOjpMWBvEdHKAE9h8cROFgCfU/DI Hm8AsO4vdgGCdWUgdJ6mRTs= =nTdu -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 13:41:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CBBB1065677 for ; Sat, 17 Jul 2010 13:41:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFD68FC1A for ; Sat, 17 Jul 2010 13:41:51 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id j06b1e0010EZKEL581hsWk; Sat, 17 Jul 2010 13:41:52 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta01.westchester.pa.mail.comcast.net with comcast id j1hq1e0013LrwQ23M1hrVR; Sat, 17 Jul 2010 13:41:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 322509B425; Sat, 17 Jul 2010 06:41:49 -0700 (PDT) Date: Sat, 17 Jul 2010 06:41:49 -0700 From: Jeremy Chadwick To: Joerg Pulz Message-ID: <20100717134149.GA40907@icarus.home.lan> References: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Reko Turja , "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 13:41:53 -0000 On Sat, Jul 17, 2010 at 08:55:54AM +0200, Joerg Pulz wrote: > i followed this thread so far and searched a little bit about the issue. > I also tested on my machines and came to an interesting point. > First my setup is pretty straight forward. > > Set HEIMDAL_HOME=/usr . > Build security/cyrus-sasl2 (OPTIONS don't matter i think). > Build net/openldap24-sasl-client (select SASL OPTION) > > If you don't have any accessible LDAP server on your net (OpenLDAP > or Windows AD doesn't matter) you have to build and just start one > for yourself. > > Afterwards just try the following command: > > ldapsearch -Ygssapi -h > > Now the interesting point. > On my amd64 system i get this after executing the above command: > > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Miscellaneous failure (see text) (unknown mech-code 2 for mech > unknown) > > While on my i386 system i get this: > > SASL/GSSAPI authentication started > Segmentation fault (core dumped) > > A quick look at the gdb bt of the core file looks like this: > > #0 0x28310ef5 in free () from /lib/libc.so.7 > #1 0x283fc972 in gss_release_buffer () from /usr/lib/libgssapi.so.10 > #2 0x283fc37e in gss_release_name () from /usr/lib/libgssapi.so.10 > #3 0x283f8da9 in gss_init_sec_context () from /usr/lib/libgssapi.so.10 > #4 0x283f1a0b in gssapi_client_mech_step () > from /usr/local/lib/sasl2/libgssapiv2.so.2 > #5 0x280ed4f4 in sasl_client_step () from /usr/local/lib/libsasl2.so.2 > > So i think i've hit the same bug all others are experiencing. > It looks like it is a i386 speciality but it can also be pure luck > an amd64. > I found at least one other report on the net which looks very > similar to what i see. i386 == Segmentation fault, amd64 == Error > message. > > Jeremy, is your test system running on amd64 or i386? The test system is amd64. I'm not doubting the issue may be more apparent/easier to occur on i386, but "pure luck on amd64" is a bit surprising. I'll build an i386 version of my testbox and start the procedure over again. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 14:00:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6EB0106566B for ; Sat, 17 Jul 2010 14:00:37 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2508FC08 for ; Sat, 17 Jul 2010 14:00:36 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 728401CC5A; Sat, 17 Jul 2010 17:00:31 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 728401CC5A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279375231; bh=Oqh2TPqlqx1HH04WnnLaDmTF0BpRatjx8i68apr1ulg=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=s0gXI68KYafQnaK+SDbUtDIHyrSHDdZZDLzMwG3/B9TUCqclLawAaibGrKfBQDloB Ko5AUz8SmePgtaDurP2zVDWnQCjBc9RVifXI7denWWVGSXEI57WSIYEcSY8sAD8q4M TJjSQGmj3jUCc6zOxK7XmghkupHq/lLfHLrEEdUo= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hfO6VXXnSDRS; Sat, 17 Jul 2010 17:00:25 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 16D341CC59; Sat, 17 Jul 2010 17:00:23 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 16D341CC59 Message-ID: <677C8B72CF414265A0819E4824212BB5@rivendell> From: "Reko Turja" To: "Jeremy Chadwick" , "Joerg Pulz" References: <3FE6787E5CAC4C108C031CA6C8044FE4@rivendell> <20100716092512.GA99365@icarus.home.lan> <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> In-Reply-To: <20100717134149.GA40907@icarus.home.lan> Date: Sat, 17 Jul 2010 17:00:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 14:00:37 -0000 > I'll build an i386 version of my testbox and start the procedure=20 > over > again. Just installed cyrus for testing into another i386 system and hit the=20 same exact bug. I wonder if this is the reason for the problem we're=20 encountering: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138929 "This patch updates the heimdal-1.0.1_1 port to heimdal-1.2.1. It=20 "works for me" on 7.2/i386 and 8.0/i386 and passes portlint. I needed to upgrade to Heimdal 1.2.1 on 8.0-BETA2 (base Heimdal is 1.1.0) to get GSSAPI authenticaion to work (through SASL) for the OpenLDAP server." -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 14:41:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DC0D106566B for ; Sat, 17 Jul 2010 14:41:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id F1B198FC12 for ; Sat, 17 Jul 2010 14:41:23 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta12.emeryville.ca.mail.comcast.net with comcast id j2al1e0041Y3wxoAC2hPTr; Sat, 17 Jul 2010 14:41:23 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id j2hL1e0083LrwQ28b2hMLL; Sat, 17 Jul 2010 14:41:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C5A7B9B425; Sat, 17 Jul 2010 07:41:20 -0700 (PDT) Date: Sat, 17 Jul 2010 07:41:20 -0700 From: Jeremy Chadwick To: Reko Turja Message-ID: <20100717144120.GA42230@icarus.home.lan> References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <677C8B72CF414265A0819E4824212BB5@rivendell> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft , Joerg Pulz Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 14:41:24 -0000 On Sat, Jul 17, 2010 at 05:00:15PM +0300, Reko Turja wrote: > >I'll build an i386 version of my testbox and start the procedure > >over > >again. > > Just installed cyrus for testing into another i386 system and hit > the same exact bug. I wonder if this is the reason for the problem > we're encountering: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=138929 > > "This patch updates the heimdal-1.0.1_1 port to heimdal-1.2.1. It > "works > for me" on 7.2/i386 and 8.0/i386 and passes portlint. I needed to > upgrade to Heimdal 1.2.1 on 8.0-BETA2 (base Heimdal is 1.1.0) to get > GSSAPI authenticaion to work (through SASL) for the OpenLDAP server." Heimdal is a Kerberos thing. My test amd64 system I've been working on *does not* have security/heimdal installed. As stated a couple times before, these are the ports on the test box: testbox# pkg_info cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer) db41-4.1.25_4 The Berkeley DB package, revision 4.1 libtool-2.2.6b Generic shared library support script perl-5.10.1_1 Practical Extraction and Report Language portaudit-0.5.15 Checks installed ports against a list of security vulnerabi rsync-3.0.7 A network file distribution/synchronization utility vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package Furthermore, on this system Kerberos is not configured/set up. (I attempted to that following Henrik/KaarPoSoft's instructions but got stuck in a few places, so I reverted back to the above setup. This is why virtual machines + VM snapshot capability are useful. :-) ) The problem really looks to be with GSSAPI, which is part of the base system (src/lib/libgssapi). If I can reproduce the problem on the test i386 system I'm building, which will have the same port + configuration as the test amd64 system, then I would say it's purely a GSSAPI thing regardless if you're using GSSAPI w/ SASL or GSSAPI w/ Kerberos. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 15:51:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB0CD1065670 for ; Sat, 17 Jul 2010 15:51:38 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id 00B208FC16 for ; Sat, 17 Jul 2010 15:51:37 +0000 (UTC) Received: (qmail 19660 invoked by uid 509); 17 Jul 2010 15:24:56 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 17 Jul 2010 15:24:56 -0000 Date: Sat, 17 Jul 2010 18:24:55 +0300 From: Alex Kozlov To: freebsd-stable@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20100717152455.GA61987@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 15:51:38 -0000 Hi, stable After updating my buildbox from 26 April 8-STABLE to 8.1-RC2 I constantly getting SIGEPIPE portsnap: Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 27 patches.....10....20... done. Applying patches... done. Fetching 3 new ports or files... done. sort: write failed: standard output: Broken pipe sort: write error Removing old files and directories... done. sudo make -C /usr/ports/converters/ascii2binary: ===> Patching for ascii2binary-2.13_2 ===> Applying FreeBSD patches for ascii2binary-2.13_2 ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe - found ===> Configuring for ascii2binary-2.13_2 Does anyone know something about this issue? -- Adios From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 16:58:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD8DA1065674 for ; Sat, 17 Jul 2010 16:58:33 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep12.mx.upcmail.net (fep12.mx.upcmail.net [62.179.121.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4018FC12 for ; Sat, 17 Jul 2010 16:58:32 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100717165830.IHRO20209.viefep12-int.chello.at@edge02.upcmail.net> for ; Sat, 17 Jul 2010 18:58:30 +0200 Received: from pinky ([80.57.226.230]) by edge02.upcmail.net with edge id j4yU1e00o4ytFy8024yVm2; Sat, 17 Jul 2010 18:58:30 +0200 X-SourceIP: 80.57.226.230 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <20100717152455.GA61987@ravenloft.kiev.ua> Date: Sat, 17 Jul 2010 18:58:29 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20100717152455.GA61987@ravenloft.kiev.ua> User-Agent: Opera Mail/10.60 (Win32) X-Cloudmark-Analysis: v=1.1 cv=K3uBg944YaUT+Qsu6bWO0a0V3uPy4DQNslbdoMCD4tw= c=1 sm=0 a=Ct-iyLsJvVsA:10 a=-e8MBd7zOhoA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=bFfxWCLNKFQGeyWqipkA:9 a=q2WMS5cvvacNrsL9C1UA:7 a=oxhysVJWUPc7kwZZ5CLZe-CsQAQA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 16:58:33 -0000 Try rebuilding bash or sh or whatever you are using as shell. I'm not sure though. Ronald. On Sat, 17 Jul 2010 17:24:55 +0200, Alex Kozlov wrote: > Hi, stable > > After updating my buildbox from 26 April 8-STABLE > to 8.1-RC2 I constantly getting SIGEPIPE > > portsnap: > Fetching 4 metadata patches... done. > Applying metadata patches... done. > Fetching 0 metadata files... done. > Fetching 27 patches.....10....20... done. > Applying patches... done. > Fetching 3 new ports or files... done. > sort: write failed: standard output: Broken pipe > sort: write error > Removing old files and directories... done. > > sudo make -C /usr/ports/converters/ascii2binary: > ===> Patching for ascii2binary-2.13_2 > ===> Applying FreeBSD patches for ascii2binary-2.13_2 > ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing > output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > grep: writing output: Broken pipe > - found > ===> Configuring for ascii2binary-2.13_2 > > Does anyone know something about this issue? > > > -- > Adios > _______________________________________________ > 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 Sat Jul 17 18:15:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F36106564A for ; Sat, 17 Jul 2010 18:15:48 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 2097B8FC0C for ; Sat, 17 Jul 2010 18:15:48 +0000 (UTC) Received: from nsx.b1c1l1.com (nsx.b1c1l1.com [IPv6:2001:470:83fb:0:250:8dff:fe9a:f666]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id ACF835C29; Sat, 17 Jul 2010 11:15:47 -0700 (PDT) Message-ID: <4C41F34E.2030309@b1c1l1.com> Date: Sat, 17 Jul 2010 11:15:42 -0700 From: Benjamin Lee User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100628 Thunderbird/3.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> In-Reply-To: <20100717144120.GA42230@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig19FEAF607A023730C8B7BBA2" Cc: Reko Turja , "Mikhail T." , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 18:15:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig19FEAF607A023730C8B7BBA2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/17/2010 07:41 AM, Jeremy Chadwick wrote: > The problem really looks to be with GSSAPI, which is part of the base > system (src/lib/libgssapi). >=20 > If I can reproduce the problem on the test i386 system I'm building, > which will have the same port + configuration as the test amd64 system,= > then I would say it's purely a GSSAPI thing regardless if you're using > GSSAPI w/ SASL or GSSAPI w/ Kerberos. Can you try reproducing the issue on 8-STABLE? I recently submitted a Heimdal patch against 8.1-STABLE and 9.0-CURRENT that resolves some libgssapi-related issues: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/147454 The patch breaks ABI, so you'll have to rebuild libgssapi-dependent applications. --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enig19FEAF607A023730C8B7BBA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMQfNTAAoJEHBW16CPoSMC/qMQAIHxmffrF4xUSP69zsinANt4 v3FJr7e8EYtoJS4P+YMA8jm3Q8T6sTexGJgCTvPY5H5P2qjOlnPxGVKeWrxwBJxn lKO5tDKGIv5Aq///fMkX8jVwWpJR2jfgz5ElrHDQqEM5FY9MSTqjT0PqHFJaWkk9 sTvlJw+luurLvq5pUrv3qJXGOxX5/YdHI4KeICrnQZBBJHXbWK5oLaEpQJMhfReh uy+3NjbFEYwwm8gFgiNcnDuOA5xSCe4cfOldfZa6mLhU4PQlUU8s39LWMNiiMbyU UOJQzPLcm/jH2cpU0zDtII6Zet0u6k6vhVOlvZexPgLVoBX/3mcqeV/hobOWHw0k ed12b71LHoU0JCLRT/GCRDtlBwi+Boq6tbB3p5903JiZooziOW8Wb7Do0/CTKxFr tMKdYqcRBv74lZ0sNzXKDFtFhtNu/uKF+kqKl8lTmW/bSJAWTUAHvFYXWfi7Xob2 1aT9SVyRr6Z7+P5JS1gZxepQNl5pEVNTyIHzYEoNxDjI5fI1ngNjnZi71aWTWpLd YM200fgSPCVruMrla5Q/S59b0/jSRLTFnQbddS1wWxLG/amgpAu6bMOgFQSXQ/xs fOwEe5pICe3kcPpKp5Pq+/LA+wgoihrQY5t57iKFkCHxHPbVWNNobnXdItZwjQpp /HiQG1abDT6M659e+RVn =m+L6 -----END PGP SIGNATURE----- --------------enig19FEAF607A023730C8B7BBA2-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 18:31:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B32421065674 for ; Sat, 17 Jul 2010 18:31:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3868FC16 for ; Sat, 17 Jul 2010 18:31:02 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta08.westchester.pa.mail.comcast.net with comcast id j5Te1e0020Fqzac586X3sd; Sat, 17 Jul 2010 18:31:03 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta08.westchester.pa.mail.comcast.net with comcast id j6X11e0073LrwQ23U6X1jh; Sat, 17 Jul 2010 18:31:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 12D3E9B425; Sat, 17 Jul 2010 11:31:00 -0700 (PDT) Date: Sat, 17 Jul 2010 11:31:00 -0700 From: Jeremy Chadwick To: Benjamin Lee Message-ID: <20100717183100.GA47506@icarus.home.lan> References: <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C41F34E.2030309@b1c1l1.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Reko Turja , "Mikhail T." , freebsd-stable@freebsd.org, Henrik /KaarPoSoft , Joerg Pulz Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 18:31:03 -0000 On Sat, Jul 17, 2010 at 11:15:42AM -0700, Benjamin Lee wrote: > On 07/17/2010 07:41 AM, Jeremy Chadwick wrote: > > The problem really looks to be with GSSAPI, which is part of the base > > system (src/lib/libgssapi). > > > > If I can reproduce the problem on the test i386 system I'm building, > > which will have the same port + configuration as the test amd64 system, > > then I would say it's purely a GSSAPI thing regardless if you're using > > GSSAPI w/ SASL or GSSAPI w/ Kerberos. > > Can you try reproducing the issue on 8-STABLE? As the thread has stated, I can't reproduce the problem on RELENG_8 amd64, but I'm still working on building the test i386 box to see if I can reproduce the issue. Please be aware the issue supposedly can be reproduced *without* use of Kerberos/Heimdal. > I recently submitted a Heimdal patch against 8.1-STABLE and 9.0-CURRENT > that resolves some libgssapi-related issues: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 > > The patch breaks ABI, so you'll have to rebuild libgssapi-dependent > applications. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 18:35:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED941065672 for ; Sat, 17 Jul 2010 18:35:23 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3188FC17 for ; Sat, 17 Jul 2010 18:35:22 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:43538 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OaCEL-0001oF-Us for freebsd-stable@freebsd.org; Sat, 17 Jul 2010 20:35:22 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Markus Gebert In-Reply-To: <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> Date: Sat, 17 Jul 2010 20:35:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> <9DCFE2F6-D7CB-49CB-8EBC-06C1E5EBB727@hostpoint.ch> To: freebsd-stable X-Mailer: Apple Mail (2.1078) Subject: Re: 8.1-RC2 MCE caused by some LAPIC/clock changes? (was: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 18:35:23 -0000 On 13.07.2010, at 16:02, Markus Gebert wrote: > Unfortunately, I have not been able to get anything useful out the svn = commit logs, which could explain this. Maybe someone else has an idea = what could have changed between 7 and 8 to break it, and again between 8 = and CURRENT to magically fix it again. I tracked this down further. I couldn't easily downgrade my 8.1 = installation to see when the problem was introduced because the zpool = version used is 14. So I tried to figure out, when the problem was = solved in CURRENT. I started with the first possible revision that can boot off my v14 pool = (r201143, Dec 28, zfs v14 commit). With this revision, I was able to = trigger the MCE. Then I took some later revision (rev206010, Apr 1, chosen randomly), and = I couldn't reproduce the problem. I started narrowing the revisions down = until I found out, that while on r202386 I'm still able to trigger the = MCE, r202387 seems to solve the problem on CURRENT: http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D202387 Since John Baldwin mentioned this problem could be timing related, it = seems reasonable, that a clock-related change could be fix it. But this = commit seems to have been MFC'd to 8-STABLE and 8.1 (at least as far as = I can tell) along with some other changes to amd64 specific code. I = thought that maybe these other changes that have been MFC'd could have = reintroduced the problem later on, but so far I could not reproduce the = problem with newer CURRENT revisions. So, I actually nailed this one = done to a single commit on CURRENT, but still cannot tell what the = actual difference is compared to 8-STABLE/8.1. Any ideas how to proceed? Markus= From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 19:28:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D514106567A for ; Sat, 17 Jul 2010 19:28:15 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from hosting.nash.net.ua (hosting.nash.net.ua [193.151.252.10]) by mx1.freebsd.org (Postfix) with SMTP id CDF708FC0C for ; Sat, 17 Jul 2010 19:28:14 +0000 (UTC) Received: (qmail 12938 invoked by uid 509); 17 Jul 2010 19:28:13 -0000 Received: from ravenloft.kiev.ua (94.244.131.95) by hosting.nash.net.ua with SMTP; 17 Jul 2010 19:28:13 -0000 Date: Sat, 17 Jul 2010 22:27:40 +0300 From: Alex Kozlov To: Ronald Klop , freebsd-stable@freebsd.org, spam@rm-rf.kiev.ua Message-ID: <20100717192740.GA87392@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 19:28:15 -0000 On Sat, Jul 17, 2010 at 06:58:29PM +0200, Ronald Klop wrote: > Try rebuilding bash or sh or whatever you are using as shell. I'm not sure > though. I done only preliminary testing, but replacing /bin/sh by one from 8.0-RELEASE seems to help. Thanks. Now I will try to find particular commit that broke sh. -- Adios From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 22:11:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C973106567C for ; Sat, 17 Jul 2010 22:11:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 240B28FC1A for ; Sat, 17 Jul 2010 22:11:52 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 13C2E35A835; Sun, 18 Jul 2010 00:11:51 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id F40641721D; Sun, 18 Jul 2010 00:11:50 +0200 (CEST) Date: Sun, 18 Jul 2010 00:11:50 +0200 From: Jilles Tjoelker To: Alex Kozlov Message-ID: <20100717221150.GA18562@stack.nl> References: <20100717152455.GA61987@ravenloft.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100717152455.GA61987@ravenloft.kiev.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: SIGEPIPE after update to 8.1-RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 22:11:52 -0000 On Sat, Jul 17, 2010 at 06:24:55PM +0300, Alex Kozlov wrote: > After updating my buildbox from 26 April 8-STABLE > to 8.1-RC2 I constantly getting SIGEPIPE > portsnap: > Fetching 4 metadata patches... done. > Applying metadata patches... done. > Fetching 0 metadata files... done. > Fetching 27 patches.....10....20... done. > Applying patches... done. > Fetching 3 new ports or files... done. > sort: write failed: standard output: Broken pipe > sort: write error > Removing old files and directories... done. > sudo make -C /usr/ports/converters/ascii2binary: > ===> Patching for ascii2binary-2.13_2 > ===> Applying FreeBSD patches for ascii2binary-2.13_2 > ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing output: Broken pipe > grep: writing output: Broken pipe [snip repetition] > - found > ===> Configuring for ascii2binary-2.13_2 > Does anyone know something about this issue? This looks more like the absence of SIGPIPE than an inappropriate SIGPIPE. I can reproduce both of those error messages by running the commands with SIGPIPE ignored. grep(1) seems to behave strangely on write errors, not aborting, for example yes | { trap '' PIPE; grep -v foo; echo $? >&2; } | : prints an endless stream of error messages. Note that sh(1) silently ignores attempts to change the disposition of signals that were ignored on entry to the shell, so a trap - PIPE is unlikely to help you. Similarly, SIGPIPE may be blocked (masked). Few programs expect this. The -i and -j options in procstat should be helpful in finding what exactly is wrong with SIGPIPE. (These options are relatively new, but should be in 8.1.) -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sat Jul 17 22:37:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F176106566C for ; Sat, 17 Jul 2010 22:37:05 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id C7ABE8FC0C for ; Sat, 17 Jul 2010 22:37:04 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id E6F921CC5A; Sun, 18 Jul 2010 01:37:03 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net E6F921CC5A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1279406223; bh=DJIndMaw/QvPMXzK9TJaTmyyKxoALbhw/cTCEd/LakU=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OqSvofeeQjNTUDcJUoaauW0IBKweMo4O4KlDZ8Wilw9rYzwGdS3pN+gYgtMOHuaVU P7h2fjaWxq3bi+Ze27VCMjK7EBYO1awVh0yoWZa84Y9kHIiddsMMASJmuASDpkeicI oc5WhSHRJytqU5nct9T85CJBDFUVShyHQcxrhYXY= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 287VpMmOvpIs; Sun, 18 Jul 2010 01:37:01 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 2C03E1CC59; Sun, 18 Jul 2010 01:37:01 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 2C03E1CC59 Message-ID: From: "Reko Turja" To: "Benjamin Lee" , "Jeremy Chadwick" References: <20100716110427.GA1939@icarus.home.lan> <20100716111000.GA2501@icarus.home.lan> <7AD0E8F6044245DEA6C218A28F08FB99@rivendell> <20100716122446.GA3241@icarus.home.lan> <20100716135102.GA5625@icarus.home.lan> <20100717134149.GA40907@icarus.home.lan> <677C8B72CF414265A0819E4824212BB5@rivendell> <20100717144120.GA42230@icarus.home.lan> <4C41F34E.2030309@b1c1l1.com> In-Reply-To: <4C41F34E.2030309@b1c1l1.com> Date: Sun, 18 Jul 2010 01:37:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Joerg Pulz , Henrik /KaarPoSoft Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jul 2010 22:37:05 -0000 >Can you try reproducing the issue on 8-STABLE? > > I recently submitted a Heimdal patch against 8.1-STABLE and > 9.0-CURRENT that resolves some libgssapi-related issues: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/147454 > > The patch breaks ABI, so you'll have to rebuild libgssapi-dependent > applications. When linking cyrus-sasl2 against gssapi library from either the 1.0.1=20 official port or the inofficial 1.2.1 patchset cyradm works as=20 expected and it logs a message from gssapi/kerberos telling that no=20 KDC's are available - which is to be expected on a system that isn't=20 using gssapi/kerberos in authenticating. So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday=20 the 5th is clearly some kind of regression as system gsslib doesn't=20 seem to recognize the mech used or segfaults. Benjamin, can you clarify how to apply your patch against the source=20 tree - I tried 'patch < the_patchset.diff' in /usr/src but it just=20 created a bunch of files in the /usr/src which I think isn't the=20 intention. -Reko=20