From owner-freebsd-stable@FreeBSD.ORG Sun Aug 15 08:02: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 DBFF11065693 for ; Sun, 15 Aug 2010 08:02:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A2D428FC12 for ; Sun, 15 Aug 2010 08:02:27 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4915273098; Sun, 15 Aug 2010 10:13:07 +0200 (CEST) Date: Sun, 15 Aug 2010 10:13:07 +0200 From: Luigi Rizzo To: Michael BlackHeart Message-ID: <20100815081307.GA35891@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R: ppp default route uses wrong Netif (with pppoe) 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, 15 Aug 2010 08:02:27 -0000 On Thu, Aug 12, 2010 at 07:31:32PM +0400, Michael BlackHeart wrote: > As I understand this isn't a bug but a mistype or misunderstand of config ( > see man ppp.conf ) > > I'm running myself 8.0, 8.1 and currently 8.STABLE with pppoe in this way > and never have a problem as many peolpe do. > Look in listing > > > my-provider: > > set line PPPoE:nfe0 > > Here's some "set line" and should be "set device" like this: sorry it wasn't that. I checked the source code, "set line" and "set device" are perfect equivalent and they end up calling the same code. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Sun Aug 15 19:37:06 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 E41301065673 for ; Sun, 15 Aug 2010 19:37:05 +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 CA56A8FC18 for ; Sun, 15 Aug 2010 19:37:05 +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 o7FJb3SE005452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Aug 2010 12:37:04 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DA6461CC3A; Sun, 15 Aug 2010 12:37:03 -0700 (PDT) To: Roland Smith In-reply-to: Your message of "Sun, 15 Aug 2010 00:07:40 +0200." <20100814220740.GA64697@slackbox.erewhon.net> Date: Sun, 15 Aug 2010 12:37:03 -0700 From: "Kevin Oberman" Message-Id: <20100815193703.DA6461CC3A@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-15_07:2010-08-15, 2010-08-15, 1970-01-01 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-1008150144 Cc: stable@freebsd.org Subject: Re: Inconsistent IO performance 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, 15 Aug 2010 19:37:06 -0000 > Date: Sun, 15 Aug 2010 00:07:40 +0200 > From: Roland Smith > Sender: owner-freebsd-stable@freebsd.org > > On Sat, Aug 14, 2010 at 02:36:31AM +0200, Roland Smith wrote: > > On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote: > > > > Both figures seem quite low to me? I cannot exactly reproduce your test, > > > > because I don't have an empty second disk handy, but doing > > > > > > > > dd if=/dev/zero bs=1m count=100 of=/tmp/foo > > > > > > With a total write size of 100MB, aren't you just testing speed of > > > writing into cache RAM this way? I think you need to write amounts > > > dramatically greater than the total size of the RAM to get values which > > > appropriately measure disk speed. > > > > > This also supports that theory - off the top of my head, maximum > > > theoretical possible write throughput to a similarly sized 7200rpm > > > drive should be 70MB/s (buffer to disk data transfer rate according to > > > WDC's specs.) > > > > Ok, so I tried this; > > > > dd if=/dev/zero of=/tmp/foo bs=10M count=1000 > > > > 10485760000 bytes transferred in 138.304953 secs (75816229 bytes/sec) > > 10485760000 bytes transferred in 139.125501 secs (75369073 bytes/sec) > > 10485760000 bytes transferred in 136.149871 secs (77016305 bytes/sec) > > > > Which is around 72 MiB/s with filesystem overhead, which sounds about > > right. The drive was making plenty of noise. The point is that it is _way_ > > more than the 18-22 MiB/s on a raw disk that Kevin is getting. > > > > I'll try the same on my laptop topmorrow and see what that gets me. This desktop > > machine is ICH7 with ata(4), laptop is ICH9 with ahci(4). > > Figures from the laptop running 8.1-RELEASE amd64, ahci driver with the > following harddisk; > > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > > Running the same test; > > dd if=/dev/zero of=/tmp/foo bs=10M count=1000 > > Gives the following results. > > 10485760000 bytes transferred in 122.625997 secs (85510090 bytes/sec) > 10485760000 bytes transferred in 126.081170 secs (83166741 bytes/sec) > 10485760000 bytes transferred in 126.101845 secs (83153105 bytes/sec) > > Which is about 10% faster than on the desktop. OK. It's pretty clear that disk IO is terrible on this system. I suspect it's the SATA/PATA converter that is the throttle. In any case, nothing is going to help much when the best sequential read speed is only 34 MB/sec. I suppose something in the ATA driver may be an issue, but I doubt it will improve. I still have no explanation for the variation. It's not vibration. Some of my best times were while the system was sitting in my trunk while commuting from my home to work. So have some of the worst. I can only hope that my next laptop, which should have ACHI, will improve the situation. I'll probably be getting a new laptop in the spring, so it won't be too long. Almost time to start trying to figure out what to buy. Thanks to everyone who made suggestions and offered ideas. -- 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 Sun Aug 15 21:11: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 D90B11065674 for ; Sun, 15 Aug 2010 21:11:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 912738FC1B for ; Sun, 15 Aug 2010 21:11:02 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAEr0Z0yDaFvO/2dsb2JhbACDFZ4hqBiRG4EmgyJzBIli X-IronPort-AV: E=Sophos;i="4.55,372,1278302400"; d="scan'208";a="90600401" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 15 Aug 2010 17:10:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 99EABB3E95; Sun, 15 Aug 2010 17:11:01 -0400 (EDT) Date: Sun, 15 Aug 2010 17:11:01 -0400 (EDT) From: Rick Macklem To: Mark Morley Message-ID: <100704493.650386.1281906661597.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100812175029.76D811065696@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [137.207.32.112] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (zclient/6.0.7_GA_2476.RHEL4) Cc: FreeBSD Stable Subject: Re: NFS stalling on 8.1-STABLE 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, 15 Aug 2010 21:11:02 -0000 > Hi all, > > I have five front end web servers that all mount their content from the same server via NFS. If I stress the link on any one of the machines (eg: copy a large directory with a lot of files to/from the mounted file system) the client will pause. That is, all processes trying to access that mount will freeze. The log files with hundreds or thousands of nfs server not responding / is alive again messages. After 60 seconds it returns to normal, unless the load is still there in which case it continues to pause. > The 60sec delay suggests that the client is doing a TCP reconnect. I'd suggest that you look at a packet trace in wireshark (it knows how to decode NFS packets) and see if there are new TCP connections (SYN, SYN-ACK,...) being made. If that is what is happening, I suspect it is NIC driver related, but it is really hard to say. If you can try a network interface of a different type (not em) that will check to see if it is an em(4) issue. Alternately, you could try turning off the TSO and checksum offload stuff for the em(4) and see if that helps. > This has only started happening since I upgraded the client machines to 8.1-STABLE (previously four of them were 8.0 and one was 7.3). The server is 7.1-RELEASE-p11. No other changes have taken place in terms of hardware or software or mount options, etc. > There were some client side fixes between 8.0 and 8.1, but I don't think any of those have caused a regression w.r.t. connections. There is a problem w.r.t. the nfsd getting in a loop, but that wouldn't recover after 60sec. (If it happens, the server has to be rebooted. There is a fix for this at: http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch but I don't think it is what you are seeing.) rick From owner-freebsd-stable@FreeBSD.ORG Sun Aug 15 22:30:30 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 4EBF51065694 for ; Sun, 15 Aug 2010 22:30:30 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr18.xs4all.nl (smtp-vbr18.xs4all.nl [194.109.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id BFC948FC0C for ; Sun, 15 Aug 2010 22:30:29 +0000 (UTC) Received: from slackbox.erewhon.net (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr18.xs4all.nl (8.13.8/8.13.8) with ESMTP id o7FMUO5w060676; Mon, 16 Aug 2010 00:30:25 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.erewhon.net (Postfix, from userid 1001) id 7377ABA98; Mon, 16 Aug 2010 00:30:24 +0200 (CEST) Date: Mon, 16 Aug 2010 00:30:24 +0200 From: Roland Smith To: Kevin Oberman Message-ID: <20100815223024.GA38722@slackbox.erewhon.net> References: <20100814220740.GA64697@slackbox.erewhon.net> <20100815193703.DA6461CC3A@ptavv.es.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20100815193703.DA6461CC3A@ptavv.es.net> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stable@freebsd.org Subject: Re: Inconsistent IO performance 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, 15 Aug 2010 22:30:30 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 15, 2010 at 12:37:03PM -0700, Kevin Oberman wrote: > OK. It's pretty clear that disk IO is terrible on this system. I suspect > it's the SATA/PATA converter that is the throttle. In any case, > I still have no explanation for the variation. It's not vibration. Some > of my best times were while the system was sitting in my trunk while > commuting from my home to work. So have some of the worst. If the performance is craptastic due to the SATA/PATA convertor, could that also not be a good explanation for the variation? With the different speeds= on the two busses, there might well be variation between the time it takes for commands to get through (altough one would expect that to even out over tim= e). Of course to test that you'd have to hook up a harddisk that doesn't need t= he convertor... If that improves the situation, you've found the problem. > I can only hope that my next laptop, which should have ACHI, will improve > the situation. I'll probably be getting a new laptop in the spring, so > it won't be too long. Almost time to start trying to figure out what to > buy.=20 Well, looking at my laptop's figures, it is possible to get good throughput. If you get a system with ICH9 chipset (so you can use ahci(4)), and a 7200 RPM harddisk, and you should be able to reproduce my figures, I think. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxoaoAACgkQEnfvsMMhpyXwGQCePhFfk8MSj3SpJOT4df8hQ7wl WUQAnjhvQCTJgAyXQYnD5Pl+PqiGZB/Y =jJdi -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 06:35: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 05B2F1065672 for ; Mon, 16 Aug 2010 06:35:54 +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 9A6798FC12 for ; Mon, 16 Aug 2010 06:35:52 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta01.westchester.pa.mail.comcast.net with comcast id uub21e00117dt5G51ubtNH; Mon, 16 Aug 2010 06:35:53 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta13.westchester.pa.mail.comcast.net with comcast id uubr1e0093LrwQ23ZubsvX; Mon, 16 Aug 2010 06:35:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 350CA9B425; Sun, 15 Aug 2010 23:35:50 -0700 (PDT) Date: Sun, 15 Aug 2010 23:35:50 -0700 From: Jeremy Chadwick To: Mark Morley Message-ID: <20100816063550.GA35083@icarus.home.lan> References: <20100812175029.76D811065696@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812175029.76D811065696@hub.freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: NFS stalling on 8.1-STABLE 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, 16 Aug 2010 06:35:54 -0000 On Thu, Aug 12, 2010 at 10:35:49AM -0700, Mark Morley wrote: > I have five front end web servers that all mount their content from > the same server via NFS. If I stress the link on any one of the > machines (eg: copy a large directory with a lot of files to/from the > mounted file system) the client will pause. That is, all processes > trying to access that mount will freeze. The log files with hundreds > or thousands of nfs server not responding / is alive again messages. > After 60 seconds it returns to normal, unless the load is still there > in which case it continues to pause. > > This has only started happening since I upgraded the client machines > to 8.1-STABLE (previously four of them were 8.0 and one was 7.3). The > server is 7.1-RELEASE-p11. No other changes have taken place in terms > of hardware or software or mount options, etc. > > All nics involved are gigabit em cards, and they are on a private > network (web access to the boxes is via an external interface). Are there any indications in dmesg that the NIC is responsible, e.g. interface down/up, etc.? Does switching to UDP-based NFS solve the problem for you? What OS version (uname -a) and NIC are used on the NFS server? Can you please provide the following output from one of the client machines running 8.1-STABLE with gigE em(4)? You can X-out machine names, MAC addresses, and IP addresses/netblocks if need be. * uname -a * ifconfig emX (where X is the interface number which would be used for NFS) * netstat -idn -I emX * pciconf -lvc (provide only the data for emX please) * vmstat -i * sysctl hw.pci * As root, run "sysctl dev.em.X.stats=1" then do "dmesg" and provide the output for NIC statistics (will start with "emX:") 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 Mon Aug 16 06:37: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 ECFF01065695 for ; Mon, 16 Aug 2010 06:37:09 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 651748FC28 for ; Mon, 16 Aug 2010 06:37:09 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7G6b5FH024498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 16:37:06 +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 o7G6b4Ti004974; Mon, 16 Aug 2010 16:37:04 +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 o7G6b4aG004973; Mon, 16 Aug 2010 16:37:04 +1000 (EST) (envelope-from peter) Date: Mon, 16 Aug 2010 16:37:04 +1000 From: Peter Jeremy To: Andreas Mayer Message-ID: <20100816063704.GB1612@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: 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: zfs destroy snapshot doesn't free space 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, 16 Aug 2010 06:37:10 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Aug-13 16:51:24 +0200, Andreas Mayer wrote: >If I take a snapshot again, this snapshot also references 623G. > >What can I do to reclaim this space? I have to do this before I can >set a quota (I have set quotas for all other file systems now :) ). Does a reboot resolve the problem? --=20 Peter Jeremy --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxo3I8ACgkQ/opHv/APuIeeQACgjU3m0tmjKwcK163g0C75EJAP 8dMAnRuNHYfxEml0OzKKgAxUy3CjYQk1 =b7UT -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 13:03: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 49F7D106566B for ; Mon, 16 Aug 2010 13:03:39 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F104C8FC08 for ; Mon, 16 Aug 2010 13:03:38 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OkzLj-0003S3-V3 for freebsd-stable@freebsd.org; Mon, 16 Aug 2010 15:03:35 +0200 Received: from 89-164-107-156.dsl.iskon.hr ([89.164.107.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2010 15:03:35 +0200 Received: from ivoras by 89-164-107-156.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2010 15:03:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 16 Aug 2010 15:03:23 +0200 Lines: 14 Message-ID: References: <20100813160109.8BDDA1CC3A@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-107-156.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 In-Reply-To: <20100813160109.8BDDA1CC3A@ptavv.es.net> Subject: Re: Inconsistent IO performance 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, 16 Aug 2010 13:03:39 -0000 On 13.8.2010 18:01, Kevin Oberman wrote: > For some time I have seen very odd issues with IO performance on > 8-Stable. Going back to November of last year when 8.0 was released, I > see variations of up to 22% in identical operations. This is not a > degradation as the performance moves up and down. In 8.0-8.1 span of time there was some work on the ata driver to make it use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this will involve changing and recompiling the kernel but if you want to try something and the hardware is SATA you might try the new AHCI driver ("ada"). http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 14:46: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 8EB031065695; Mon, 16 Aug 2010 14:46:39 +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 74E428FC1B; Mon, 16 Aug 2010 14:46:39 +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 o7GEkcDJ004241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Aug 2010 07:46:38 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4ACF81CC3A; Mon, 16 Aug 2010 07:46:38 -0700 (PDT) To: Ivan Voras In-reply-to: Your message of "Mon, 16 Aug 2010 15:03:23 +0200." Date: Mon, 16 Aug 2010 07:46:38 -0700 From: "Kevin Oberman" Message-Id: <20100816144638.4ACF81CC3A@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-08-16_02:2010-08-16, 2010-08-16, 1970-01-01 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-1008160092 Cc: freebsd-stable@freebsd.org Subject: Re: Inconsistent IO performance 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, 16 Aug 2010 14:46:39 -0000 > From: Ivan Voras > Date: Mon, 16 Aug 2010 15:03:23 +0200 > Sender: owner-freebsd-stable@freebsd.org > > On 13.8.2010 18:01, Kevin Oberman wrote: > > For some time I have seen very odd issues with IO performance on > > 8-Stable. Going back to November of last year when 8.0 was released, I > > see variations of up to 22% in identical operations. This is not a > > degradation as the performance moves up and down. > > In 8.0-8.1 span of time there was some work on the ata driver to make it > use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this > will involve changing and recompiling the kernel but if you want to try > something and the hardware is SATA you might try the new AHCI driver > ("ada"). > > http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html Thanks. I appreciate the suggestion. I am running a 8-Stable kernel from August 9, so I think I should be OK on this. IS there a requirement to set some parameter in the kernel config to take advantage of this? While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any SATA connections. Both SATA ports a run to a SATA/PATA converter chip and the only 2 physical connections available are PATA. I am assuming that this is because 2.5 in. SATA drives were pretty much unavailable when this system was shipped. This was the last of the T43 series and was dropped from the product line by Lenovo about a month after I got it, to be replaced by T60 systems running Core2 chips and using SATA drives. Just lousy timing almost 4 years ago. Thanks again! -- 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 Aug 16 15:31: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 620B810656A6 for ; Mon, 16 Aug 2010 15:31:56 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id ED4558FC15 for ; Mon, 16 Aug 2010 15:31:55 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 5307A6B1829 for ; Mon, 16 Aug 2010 19:14:00 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 4F4CD2848C for ; Mon, 16 Aug 2010 19:15:18 +0400 (MSD) From: Alexey Tarasov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Aug 2010 19:15:16 +0400 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 15:31:56 -0000 Hello. I have a couple of Supermicro servers which got the similar kernel panic = with all FreeBSD versions I tried since 6.4. Now I want to investigate into the problem. The servers get into panic with similar workload: file server with a lot = of files and connections. Web server software is nginx. File system is = UFS+GJOURNAL. Outgoing traffic on each server is ~10 MB/s. I think it is not software problem, because when I've installed Linux = with such configuration there were no kernel panics. Here is the short overview of the hardware: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf65 Family =3D f Model =3D 6 = Stepping =3D 5 = Features=3D0xbfebfbff Features2=3D0xe59d= AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2054619136 (1959 MB) DMESG: http://lexasoft.ru/m/dmesg.txt CORE: http://lexasoft.ru/m/core.txt Fatal trap 1: privileged instruction fault while in kernel mode cpuid =3D 1; apic id =3D 01 instruction pointer =3D 0x20:0xffffff8040d2cc83 stack pointer =3D 0x28:0xffffff8040d2ca80 frame pointer =3D 0x28:0xffffff0060c0b740 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 9388 (nginx) trap number =3D 1 panic: privileged instruction fault cpuid =3D 1 Uptime: 17d15h48m49s Physical memory: 2032 MB Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 = 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 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 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 174 158 142 126 110 94 78 62 46 30 14 (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80590c59 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff8059108c in panic (fmt=3D0xffffffff80951fc4 "%s") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff80878fd8 in trap_fatal (frame=3D0xffffff0060c0b740, = eva=3DVariable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0xffffffff808799ea in trap (frame=3D0xffffff8040d2c9d0) at /usr/src/sys/amd64/amd64/trap.c:644 #5 0xffffffff8085f983 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xffffff8040d2cc83 in ?? () #7 0xffffff8040d2cb50 in ?? () #8 0xffffff8040d2caf0 in ?? () #9 0xffffff8040d2cbf0 in ?? () #10 0xffffff0060c0b740 in ?? () #11 0xffffffff80b83c60 in sysent () #12 0xffffff8040d2cc80 in ?? () #13 0xffffff8040d2cae0 in ?? () #14 0xffffffff8059c431 in bintime (bt=3D0xffffffff80ad3140) at /usr/src/sys/kern/kern_tc.c:200 Previous frame inner to this frame (corrupt stack?) (kgdb)=20 -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"= From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 15: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 DE84D1065674 for ; Mon, 16 Aug 2010 15:33:18 +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 C1A568FC16 for ; Mon, 16 Aug 2010 15:33:18 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta04.emeryville.ca.mail.comcast.net with comcast id v0kj1e00C1eYJf8A43ZJYZ; Mon, 16 Aug 2010 15:33:18 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.emeryville.ca.mail.comcast.net with comcast id v3ZH1e0023LrwQ2013ZHgC; Mon, 16 Aug 2010 15:33:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ABCD89B425; Mon, 16 Aug 2010 08:33:16 -0700 (PDT) Date: Mon, 16 Aug 2010 08:33:16 -0700 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20100816153316.GA58985@icarus.home.lan> References: <20100816144638.4ACF81CC3A@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100816144638.4ACF81CC3A@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Inconsistent IO performance 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, 16 Aug 2010 15:33:19 -0000 On Mon, Aug 16, 2010 at 07:46:38AM -0700, Kevin Oberman wrote: > > From: Ivan Voras > > Date: Mon, 16 Aug 2010 15:03:23 +0200 > > Sender: owner-freebsd-stable@freebsd.org > > > > On 13.8.2010 18:01, Kevin Oberman wrote: > > > For some time I have seen very odd issues with IO performance on > > > 8-Stable. Going back to November of last year when 8.0 was released, I > > > see variations of up to 22% in identical operations. This is not a > > > degradation as the performance moves up and down. > > > > In 8.0-8.1 span of time there was some work on the ata driver to make it > > use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this > > will involve changing and recompiling the kernel but if you want to try > > something and the hardware is SATA you might try the new AHCI driver > > ("ada"). > > > > http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > > Thanks. I appreciate the suggestion. I am running a 8-Stable kernel > from August 9, so I think I should be OK on this. IS there a requirement > to set some parameter in the kernel config to take advantage of this? > > While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any > SATA connections. Both SATA ports a run to a SATA/PATA converter chip > and the only 2 physical connections available are PATA. I am assuming > that this is because 2.5 in. SATA drives were pretty much unavailable > when this system was shipped. This was the last of the T43 series and > was dropped from the product line by Lenovo about a month after I got > it, to be replaced by T60 systems running Core2 chips and using SATA > drives. > > Just lousy timing almost 4 years ago. I should expand on what Kevin's stated (I read what was written 3 or 4 times over and it didn't jive; "if there's no physical SATA connections, why is a SATA/PATA converter in use?"). The T43 is a bizarre beast. The ICH6-M chipset uses SATA, but is physically wired to a custom PCB/adapter that serves a couple different purposes: - Converts a 2.5" PATA hard disk connector into SATA (meaning, the laptop actually uses 2.5" PATA hard disks). thinkwiki.org refers to this as a "SATA-to-PATA bridge" (controller-to-disk), while I tend to look at it as a PATA-to-SATA bridge (disk-to-controller). - Integrates a "middle-man" ASIC that supposedly intercepts ATA commands, in addition to doing some drive model string verification (requiring folks to purchase IBM-sanctioned drives). - The system BIOS knows of the PCB/adapter and, somehow, queries it to verifies its existence. I imagine it sends some vendor-centric ATA commands which the ASIC intercepts. Supposedly people have tried removing (desoldering) the adapter in attempt to use standard SATA disks and destroyed their systems in the process. As Kevin stated, the ICH6-M doesn't support AHCI, so using ahci.ko isn't an option in his case. It's possible that the adapter in question is going/has gone bad, is doing something awful, or the underlying drive itself has degraded in some way which SMART doesn't see (ex. on-disk cache going bad; wouldn't surprise me in this case). -- | 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 Aug 16 15:37: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 3296610656A8 for ; Mon, 16 Aug 2010 15:37:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id C521B8FC17 for ; Mon, 16 Aug 2010 15:37:16 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id v2sy1e0060ldTLk5D3dGZA; Mon, 16 Aug 2010 15:37:16 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.westchester.pa.mail.comcast.net with comcast id v3dE1e0083LrwQ23Q3dFbs; Mon, 16 Aug 2010 15:37:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 39CD69B425; Mon, 16 Aug 2010 08:37:13 -0700 (PDT) Date: Mon, 16 Aug 2010 08:37:13 -0700 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20100816153713.GA60071@icarus.home.lan> References: <20100816144638.4ACF81CC3A@ptavv.es.net> <20100816153316.GA58985@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100816153316.GA58985@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Inconsistent IO performance 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, 16 Aug 2010 15:37:18 -0000 On Mon, Aug 16, 2010 at 08:33:16AM -0700, Jeremy Chadwick wrote: > On Mon, Aug 16, 2010 at 07:46:38AM -0700, Kevin Oberman wrote: > > > From: Ivan Voras > > > Date: Mon, 16 Aug 2010 15:03:23 +0200 > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > On 13.8.2010 18:01, Kevin Oberman wrote: > > > > For some time I have seen very odd issues with IO performance on > > > > 8-Stable. Going back to November of last year when 8.0 was released, I > > > > see variations of up to 22% in identical operations. This is not a > > > > degradation as the performance moves up and down. > > > > > > In 8.0-8.1 span of time there was some work on the ata driver to make it > > > use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this > > > will involve changing and recompiling the kernel but if you want to try > > > something and the hardware is SATA you might try the new AHCI driver > > > ("ada"). > > > > > > http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > > > > Thanks. I appreciate the suggestion. I am running a 8-Stable kernel > > from August 9, so I think I should be OK on this. IS there a requirement > > to set some parameter in the kernel config to take advantage of this? > > > > While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any > > SATA connections. Both SATA ports a run to a SATA/PATA converter chip > > and the only 2 physical connections available are PATA. I am assuming > > that this is because 2.5 in. SATA drives were pretty much unavailable > > when this system was shipped. This was the last of the T43 series and > > was dropped from the product line by Lenovo about a month after I got > > it, to be replaced by T60 systems running Core2 chips and using SATA > > drives. > > > > Just lousy timing almost 4 years ago. > > I should expand on what Kevin's stated (I read what was written 3 or 4 > times over and it didn't jive; "if there's no physical SATA connections, > why is a SATA/PATA converter in use?"). > > The T43 is a bizarre beast. The ICH6-M chipset uses SATA, but is > physically wired to a custom PCB/adapter that serves a couple different > purposes: > > - Converts a 2.5" PATA hard disk connector into SATA (meaning, the > laptop actually uses 2.5" PATA hard disks). thinkwiki.org refers to > this as a "SATA-to-PATA bridge" (controller-to-disk), while I tend to > look at it as a PATA-to-SATA bridge (disk-to-controller). > > - Integrates a "middle-man" ASIC that supposedly intercepts ATA > commands, in addition to doing some drive model string verification > (requiring folks to purchase IBM-sanctioned drives). > > - The system BIOS knows of the PCB/adapter and, somehow, queries it to > verifies its existence. I imagine it sends some vendor-centric ATA > commands which the ASIC intercepts. Supposedly people have tried > removing (desoldering) the adapter in attempt to use standard SATA > disks and destroyed their systems in the process. > > As Kevin stated, the ICH6-M doesn't support AHCI, so using ahci.ko isn't > an option in his case. Strike that -- according to the Intel ICH6 specification, AHCI is supported on the ICH6-M and ICH6R: http://www.intel.com/assets/pdf/datasheet/301473.pdf The T43 might not offer this capability (not sure if it's available via the system BIOS) though. Skimming Google results in mixed responses, with some focus on ACPI DSDT and some mention of "old BIOSes supporting it [AHCI] but newer ones removing it". Weird. -- | 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 | > > It's possible that the adapter in question is going/has gone bad, is > doing something awful, or the underlying drive itself has degraded in > some way which SMART doesn't see (ex. on-disk cache going bad; wouldn't > surprise me in this case). > > -- > | 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 Aug 16 18:48: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 3CBA9106564A for ; Mon, 16 Aug 2010 18:48:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB4A8FC1D for ; Mon, 16 Aug 2010 18:48:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7GImIIC009390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 21:48:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7GImIOC020553; Mon, 16 Aug 2010 21:48:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7GImIC4020551; Mon, 16 Aug 2010 21:48:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Aug 2010 21:48:18 +0300 From: Kostik Belousov To: Alexey Tarasov Message-ID: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ian02MSQ7xDzAZO2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS,URIBL_SBL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 18:48:24 -0000 --Ian02MSQ7xDzAZO2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 16, 2010 at 07:15:16PM +0400, Alexey Tarasov wrote: > Hello. >=20 > I have a couple of Supermicro servers which got the similar kernel panic = with all FreeBSD versions I tried since 6.4. > Now I want to investigate into the problem. > The servers get into panic with similar workload: file server with a lot = of files and connections. Web server software is nginx. File system is UFS+= GJOURNAL. Outgoing traffic on each server is ~10 MB/s. > I think it is not software problem, because when I've installed Linux wit= h such configuration there were no kernel panics. >=20 > Here is the short overview of the hardware: >=20 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf65 Family =3D f Model =3D 6 Step= ping =3D 5 > Features=3D0xbfebfbff > Features2=3D0xe59d > AMD Features=3D0x20100800 > AMD Features2=3D0x1 > TSC: P-state invariant > real memory =3D 2147483648 (2048 MB) > avail memory =3D 2054619136 (1959 MB) >=20 > DMESG: http://lexasoft.ru/m/dmesg.txt >=20 > CORE: http://lexasoft.ru/m/core.txt >=20 > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > instruction pointer =3D 0x20:0xffffff8040d2cc83 > stack pointer =3D 0x28:0xffffff8040d2ca80 > frame pointer =3D 0x28:0xffffff0060c0b740 > 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 9388 (nginx) > trap number =3D 1 > panic: privileged instruction fault > cpuid =3D 1 > Uptime: 17d15h48m49s > Physical memory: 2032 MB > Dumping 1485 MB: 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 >=20 >=20 > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff80590c59 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff8059108c in panic (fmt=3D0xffffffff80951fc4 "%s") > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff80878fd8 in trap_fatal (frame=3D0xffffff0060c0b740, eva=3DV= ariable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #4 0xffffffff808799ea in trap (frame=3D0xffffff8040d2c9d0) > at /usr/src/sys/amd64/amd64/trap.c:644 > #5 0xffffffff8085f983 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #6 0xffffff8040d2cc83 in ?? () > #7 0xffffff8040d2cb50 in ?? () > #8 0xffffff8040d2caf0 in ?? () > #9 0xffffff8040d2cbf0 in ?? () > #10 0xffffff0060c0b740 in ?? () > #11 0xffffffff80b83c60 in sysent () > #12 0xffffff8040d2cc80 in ?? () > #13 0xffffff8040d2cae0 in ?? () > #14 0xffffffff8059c431 in bintime (bt=3D0xffffffff80ad3140) > at /usr/src/sys/kern/kern_tc.c:200 > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? --Ian02MSQ7xDzAZO2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxph/EACgkQC3+MBN1Mb4iCtwCgkruZk3ZiAn21vgCC5UM4EduC tJYAoOML5tJ4Tz01wOkcv21fzT96AmXS =u7lT -----END PGP SIGNATURE----- --Ian02MSQ7xDzAZO2-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:21: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 49F2D106566B for ; Mon, 16 Aug 2010 19:21:18 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id D61558FC1D for ; Mon, 16 Aug 2010 19:21:17 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id A1A306B1829; Mon, 16 Aug 2010 23:19:57 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id BDC392848C; Mon, 16 Aug 2010 23:21:15 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> Date: Mon, 16 Aug 2010 23:21:15 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, Alexey Tarasov Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 19:21:18 -0000 Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: >>=20 > The backtrace make absolutely no sense. I would not trust kgdb anyway. >=20 > Compile ddb in and do backtrace in console on the panic. Also, = disassemble > the kernel at the fault address. I am very curious which instruction = causes > this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xffffff0060c0b700 to 0xffffff0060c0b780: 0xffffff0060c0b700: add %al,(%rax) 0xffffff0060c0b702: add %al,(%rax) 0xffffff0060c0b704: add %al,(%rax) 0xffffff0060c0b706: add %al,(%rax) 0xffffff0060c0b708: add %al,(%rax) 0xffffff0060c0b70a: add %al,(%rax) 0xffffff0060c0b70c: add %al,(%rax) 0xffffff0060c0b70e: add %al,(%rax) 0xffffff0060c0b710: or %dh,0xffffffffffffffc2(%rax) 0xffffff0060c0b713: cmp $0xff,%bh 0xffffff0060c0b716: (bad) =20 0xffffff0060c0b717: incl (%rax) 0xffffff0060c0b719: add %al,(%rcx) 0xffffff0060c0b71b: add %cl,%bh 0xffffff0060c0b71d: pop %rsp 0xffffff0060c0b71e: out %al,(%dx) 0xffffff0060c0b71f: pop %rdx 0xffffff0060c0b720: or $0x0,%al 0xffffff0060c0b722: add %al,(%rax) 0xffffff0060c0b724: or %al,%fs:(%rax) 0xffffff0060c0b727: add %ah,%bl 0xffffff0060c0b729: int3 =20 0xffffff0060c0b72a: (bad) =20 0xffffff0060c0b72b: add %cl,%bh 0xffffff0060c0b72d: pop %rsp 0xffffff0060c0b72e: out %al,(%dx) 0xffffff0060c0b72f: pop %rdx 0xffffff0060c0b730: iret =20 0xffffff0060c0b731: pop %rsp 0xffffff0060c0b732: out %al,(%dx) 0xffffff0060c0b733: pop %rdx 0xffffff0060c0b734: rex xor $0x9f105aee,%eax 0xffffff0060c0b73a: add %al,(%rax) 0xffffff0060c0b73c: add %al,(%rax) 0xffffff0060c0b73e: add %al,(%rax) 0xffffff0060c0b740: rex pop %rdi 0xffffff0060c0b742: retq $0xff80 0xffffff0060c0b745: (bad) =20 0xffffff0060c0b746: (bad) =20 0xffffff0060c0b747: incl (%rax) 0xffffff0060c0b749: push %rax 0xffffff0060c0b74a: loop 0xffffff0060c0b78e 0xffffff0060c0b74c: add %bh,%bh 0xffffff0060c0b74e: (bad) =20 0xffffff0060c0b74f: incl (%rax) 0xffffff0060c0b751: add %al,(%rax) 0xffffff0060c0b753: add %al,(%rax) 0xffffff0060c0b755: add %al,(%rax) 0xffffff0060c0b757: add %dl,(%rax) 0xffffff0060c0b759: push %rax 0xffffff0060c0b75a: loop 0xffffff0060c0b79e 0xffffff0060c0b75c: add %bh,%bh 0xffffff0060c0b75e: (bad) =20 0xffffff0060c0b75f: incl (%rax) 0xffffff0060c0b761: add %al,(%rax) 0xffffff0060c0b763: add %al,(%rax) 0xffffff0060c0b765: add %al,(%rax) 0xffffff0060c0b767: add %bl,%al 0xffffff0060c0b769: pop %rdi 0xffffff0060c0b76a: retq $0xff80 0xffffff0060c0b76d: (bad) =20 0xffffff0060c0b76e: (bad) =20 0xffffff0060c0b76f: incl (%rax) 0xffffff0060c0b771: add %al,(%rax) 0xffffff0060c0b773: add %al,(%rax) 0xffffff0060c0b775: add %al,(%rax) 0xffffff0060c0b777: add %al,0x290c55(%rax) 0xffffff0060c0b77d: (bad) =20 0xffffff0060c0b77e: (bad) =20 0xffffff0060c0b77f: incl (%rax) -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:31: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 1715E1065675 for ; Mon, 16 Aug 2010 19:31:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 697418FC0C for ; Mon, 16 Aug 2010 19:31:15 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7GJVCEa012561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 22:31:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7GJVCVb020907; Mon, 16 Aug 2010 22:31:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7GJVC82020906; Mon, 16 Aug 2010 22:31:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Aug 2010 22:31:12 +0300 From: Kostik Belousov To: Alexey Tarasov Message-ID: <20100816193112.GV2396@deviant.kiev.zoral.com.ua> References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKLejDDV6gCqJAZ/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 19:31:17 -0000 --HKLejDDV6gCqJAZ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: > Hello Kostik! >=20 > On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: >=20 > >>=20 > > The backtrace make absolutely no sense. I would not trust kgdb anyway. > >=20 > > Compile ddb in and do backtrace in console on the panic. Also, disassem= ble > > the kernel at the fault address. I am very curious which instruction ca= uses > > this. This is stock GENERIC on the bare metal booted, right ? >=20 > Yes, stock GENERIC. >=20 > Please, check this out: >=20 > Dump of assembler code from 0xffffff0060c0b700 to 0xffffff0060c0b780: Would be nice if you keep all requested data in one place, so that we do not need to search for the old mails to see the context. According to your previous mail, the fault happen at the address instruction pointer =3D 0x20:0xffffff8040d2cc83 Your disassembled the stack instead. Please just do disass 0xffffff8040d2cc83,0xffffff8040d2cca0 in kgdb. But also, I want to see the backtrace and disassembly output from ddb. --HKLejDDV6gCqJAZ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxpkgAACgkQC3+MBN1Mb4jwMgCg9z90HSPV3bShg6g3qHLvziQ4 MVAAn2PcgyHKrGios8KhLh1FaUXxA0tU =am9r -----END PGP SIGNATURE----- --HKLejDDV6gCqJAZ/-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:35: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 DCCB7106566B for ; Mon, 16 Aug 2010 19:35:39 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id A0A778FC16 for ; Mon, 16 Aug 2010 19:35:39 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id E985B6B195F; Mon, 16 Aug 2010 23:34:19 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 00A0B2848C; Mon, 16 Aug 2010 23:35:37 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <20100816193112.GV2396@deviant.kiev.zoral.com.ua> Date: Mon, 16 Aug 2010 23:35:36 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> <20100816193112.GV2396@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, Alexey Tarasov Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 19:35:39 -0000 On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: > On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: >> Hello Kostik! >>=20 >> On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: >>=20 >>>>=20 >>> The backtrace make absolutely no sense. I would not trust kgdb = anyway. >>>=20 >>> Compile ddb in and do backtrace in console on the panic. Also, = disassemble >>> the kernel at the fault address. I am very curious which instruction = causes >>> this. This is stock GENERIC on the bare metal booted, right ? >>=20 >> Yes, stock GENERIC. >>=20 >> Please, check this out: >>=20 >> Dump of assembler code from 0xffffff0060c0b700 to 0xffffff0060c0b780: >=20 > Would be nice if you keep all requested data in one place, so that > we do not need to search for the old mails to see the context. >=20 > According to your previous mail, the fault happen at the > address > instruction pointer =3D 0x20:0xffffff8040d2cc83 > Your disassembled the stack instead. Please just do > disass 0xffffff8040d2cc83,0xffffff8040d2cca0 > in kgdb. >=20 > But also, I want to see the backtrace and disassembly output from ddb. (kgdb) disass 0xffffff8040d2cc83,0xffffff8040d2cca0 No function contains specified address. I will build kernel with DDB tomorrow, install it on some servers and = wait for the panic occurs. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:39: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 55638106578C for ; Mon, 16 Aug 2010 19:39:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1A71E8FC0C for ; Mon, 16 Aug 2010 19:39:51 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7GJdmp5013056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 22:39:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7GJdmSx020984; Mon, 16 Aug 2010 22:39:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7GJdmkN020983; Mon, 16 Aug 2010 22:39:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Aug 2010 22:39:48 +0300 From: Kostik Belousov To: Alexey Tarasov Message-ID: <20100816193948.GW2396@deviant.kiev.zoral.com.ua> References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> <20100816193112.GV2396@deviant.kiev.zoral.com.ua> <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QgvTbcZPsSS/HkXe" Content-Disposition: inline In-Reply-To: <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 19:39:53 -0000 --QgvTbcZPsSS/HkXe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: >=20 > On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: >=20 > > On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: > >> Hello Kostik! > >>=20 > >> On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: > >>=20 > >>>>=20 > >>> The backtrace make absolutely no sense. I would not trust kgdb anyway. > >>>=20 > >>> Compile ddb in and do backtrace in console on the panic. Also, disass= emble > >>> the kernel at the fault address. I am very curious which instruction = causes > >>> this. This is stock GENERIC on the bare metal booted, right ? > >>=20 > >> Yes, stock GENERIC. > >>=20 > >> Please, check this out: > >>=20 > >> Dump of assembler code from 0xffffff0060c0b700 to 0xffffff0060c0b780: > >=20 > > Would be nice if you keep all requested data in one place, so that > > we do not need to search for the old mails to see the context. > >=20 > > According to your previous mail, the fault happen at the > > address > > instruction pointer =3D 0x20:0xffffff8040d2cc83 > > Your disassembled the stack instead. Please just do > > disass 0xffffff8040d2cc83,0xffffff8040d2cca0 > > in kgdb. > >=20 > > But also, I want to see the backtrace and disassembly output from ddb. >=20 > (kgdb) disass 0xffffff8040d2cc83,0xffffff8040d2cca0 > No function contains specified address. Err, it seems that old gdb accepts only spaces. Please try disass 0xffffff8040d2cc83 0xffffff8040d2cca0 instead. >=20 > I will build kernel with DDB tomorrow, install it on some servers and wai= t for the panic occurs. Ok. Did you checked for such things as rootkits ? --QgvTbcZPsSS/HkXe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxplAQACgkQC3+MBN1Mb4jUsQCeNQ3M0fU46t1VMQL0vyYblSo8 oDAAn3WlQRDs/HffApdzE8ZCWANCaf4Y =9Nxj -----END PGP SIGNATURE----- --QgvTbcZPsSS/HkXe-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:43: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 932FF1065697 for ; Mon, 16 Aug 2010 19:43:42 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 555D28FC1E for ; Mon, 16 Aug 2010 19:43:42 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id BA80E6B183A; Mon, 16 Aug 2010 23:42:22 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id A9ECD2848C; Mon, 16 Aug 2010 23:43:40 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <20100816193948.GW2396@deviant.kiev.zoral.com.ua> Date: Mon, 16 Aug 2010 23:43:39 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4212B9F7-9B4B-466F-8AB8-2DCCAC50E52E@lexasoft.ru> References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> <20100816193112.GV2396@deviant.kiev.zoral.com.ua> <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> <20100816193948.GW2396@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, Alexey Tarasov Subject: Re: STABLE kernel panic: privileged instruction fault 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, 16 Aug 2010 19:43:42 -0000 On Aug 16, 2010, at 11:39 PM, Kostik Belousov wrote: > On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: >>=20 >> On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: >>=20 >>> On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: >>>> Hello Kostik! >>>>=20 >>>> On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: >>>>=20 >>>>>>=20 >>>>> The backtrace make absolutely no sense. I would not trust kgdb = anyway. >>>>>=20 >>>>> Compile ddb in and do backtrace in console on the panic. Also, = disassemble >>>>> the kernel at the fault address. I am very curious which = instruction causes >>>>> this. This is stock GENERIC on the bare metal booted, right ? >>>>=20 >>>> Yes, stock GENERIC. >>>>=20 >>>> Please, check this out: >>>>=20 >>>> Dump of assembler code from 0xffffff0060c0b700 to = 0xffffff0060c0b780: >>>=20 >>> Would be nice if you keep all requested data in one place, so that >>> we do not need to search for the old mails to see the context. >>>=20 >>> According to your previous mail, the fault happen at the >>> address >>> instruction pointer =3D 0x20:0xffffff8040d2cc83 >>> Your disassembled the stack instead. Please just do >>> disass 0xffffff8040d2cc83,0xffffff8040d2cca0 >>> in kgdb. >>>=20 >>> But also, I want to see the backtrace and disassembly output from = ddb. >>=20 >> (kgdb) disass 0xffffff8040d2cc83,0xffffff8040d2cca0 >> No function contains specified address. > Err, it seems that old gdb accepts only spaces. Please try > disass 0xffffff8040d2cc83 0xffffff8040d2cca0 instead. (kgdb) disass 0xffffff8040d2cc83 0xffffff8040d2cca0 Dump of assembler code from 0xffffff8040d2cc83 to 0xffffff8040d2cca0: 0xffffff8040d2cc83: (bad) =20 0xffffff8040d2cc84: (bad) =20 0xffffff8040d2cc85: jg 0xffffff8040d2cc87 0xffffff8040d2cc87: add %al,(%rax) 0xffffff8040d2cc89: add %al,(%rax) 0xffffff8040d2cc8b: add %al,(%rax) 0xffffff8040d2cc8d: add %al,(%rax) 0xffffff8040d2cc8f: add %al,(%rax) 0xffffff8040d2cc91: add %al,(%rax) 0xffffff8040d2cc93: add %al,(%rax) 0xffffff8040d2cc95: add %al,(%rax) 0xffffff8040d2cc97: add %al,(%rcx) 0xffffff8040d2cc99: add %al,(%rax) 0xffffff8040d2cc9b: add %al,(%rax) 0xffffff8040d2cc9d: add %al,(%rax) 0xffffff8040d2cc9f: add %al,(%rax) End of assembler dump. >=20 >>=20 >> I will build kernel with DDB tomorrow, install it on some servers and = wait for the panic occurs. > Ok. Did you checked for such things as rootkits ? I am noticing such panics only on this model of supermicro servers for a = long! time under FreeBSD. This servers were tested on huge workload under Linux and there were no = problems. I've installed and run chkrootkit now, there are no rootkits. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 21:07: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 BF2CD10656AA for ; Mon, 16 Aug 2010 21:07:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 68EA38FC0A for ; Mon, 16 Aug 2010 21:07:12 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7GL77V5094081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Aug 2010 17:07:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7GL76pA080191; Mon, 16 Aug 2010 17:07:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008162107.o7GL76pA080191@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Aug 2010 17:07:11 -0400 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20100702193654.GD10862@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 16 Aug 2010 21:07:12 -0000 Hi Jack, FYI, I am still seeing this same problem on RELENG_8 (code as of today). Unfortunately I cant try Pyun's patch since the underlying code has changed since then. em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c pci3: on pcib3 em4: port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci3 em4: Using MSI interrupt em4: [FILTER] em4: Ethernet address: 00:15:17:ed:3e:c4 ---Mike At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > Hi Jack, > > Just a followup to the email below. I now saw what appears > > to be the same problem on RELENG_8, but on a different nic and with > > VLANs. So not sure if this is a general em problem, a problem > > specific to some em NICs, or a TSO problem in general. The issue > > seemed to be triggered when I added a new vlan based on > > > > em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > chip=0x109a8086 rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > > pci14: on pcib5 > > em3: port 0x6000-0x601f > > mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > em3: Using MSI interrupt > > em3: [FILTER] > > em3: Ethernet address: 00:30:48:9f:eb:81 > > > > em3: flags=8943 > > metric 0 mtu 1500 > > options=2098 > > ether 00:30:48:9f:eb:81 > > inet 10.255.255.254 netmask 0xfffffffc broadcast 10.255.255.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > I had to disable tso, rxcsum and txsum in order to see the devices on > > the other side of the two vlans trunked off em3. Unfortunately, the > > other sides were switches 100km and 500km away so I didnt have any > > tcpdump capabilities to diagnose the issue. I had already created > > one vlan off this NIC and all was fine. A few weeks later, I added a > > new one and I could no longer telnet into the remote switches from > > the local machine.... But, I could telnet into the switches from > > machines not on the problem box. Hence, it would appear to be a > > general TSO issue no ? I disabled tso on the nic (I didnt disable > > net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > always ping the remote devices, but no tcp services. I then > > remembered this issue from before, so I tried disabling tso on the > > NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > then telnet into the remote devices. > > > > This newly observed issue was from a buildworld on Mon Jun 14 > > 11:29:12 EDT 2010. > > > > I will try and recreate the issue locally again to see if I can > > trigger the problem on demand. Any thoughts on what it might be ? > > Perhaps an issue specific to certain em nics ? > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 >I'm not sure whether you're seeing the same issue though. >I didn't have chance to try latest em(4) on stable/7. -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 21:32: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 2E94A1065670; Mon, 16 Aug 2010 21:32:31 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1000:b::599b]) by mx1.freebsd.org (Postfix) with ESMTP id 659E78FC12; Mon, 16 Aug 2010 21:32:30 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o7GLWOvJ020879; Tue, 17 Aug 2010 00:32:25 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4C69AE22.2030201@ukr.net> Date: Tue, 17 Aug 2010 00:31:14 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Performance AMD Phenom II X6 1090T 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, 16 Aug 2010 21:32:31 -0000 Is there anyone using AMD Phenom II X6 1090T? What can you say about it's performance? Have you any tasks that use all 6-cores? Does it balance workload between all 6 cores properly? I am interested how it will work specifically under 8.1-RELEASE and 9.0-CURRENT. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 11:08: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 BFC421065679 for ; Tue, 17 Aug 2010 11:08:44 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 82E038FC13 for ; Tue, 17 Aug 2010 11:08:44 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlK27-000EJy-2r for freebsd-stable@freebsd.org; Tue, 17 Aug 2010 13:08:43 +0200 Date: Tue, 17 Aug 2010 13:08:43 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1748218706.20100817130843@nitronet.pl> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Subject: Crash in dummynet. 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, 17 Aug 2010 11:08:44 -0000 Hello list, I'm observing recurring crashes with dummynet on 8.1-RELEASE. Abnormal things being done on the system are: /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"` being done every minute. There are over 2000 pipes in the system. Anyway, to the point: is there any resource I could read as to how to prepare the system to catch correct debugging info at next crash? What other helpful information may I provide? Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 11:36: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 5A11210656A5 for ; Tue, 17 Aug 2010 11:36:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2159E8FC18 for ; Tue, 17 Aug 2010 11:36:32 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6C60773098; Tue, 17 Aug 2010 13:47:17 +0200 (CEST) Date: Tue, 17 Aug 2010 13:47:17 +0200 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20100817114717.GA65273@onelab2.iet.unipi.it> References: <1748218706.20100817130843@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1748218706.20100817130843@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Crash in dummynet. 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, 17 Aug 2010 11:36:34 -0000 On Tue, Aug 17, 2010 at 01:08:43PM +0200, Pawel Tyll wrote: > Hello list, > > I'm observing recurring crashes with dummynet on 8.1-RELEASE. > Abnormal things being done on the system are: > /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"` being done > every minute. > There are over 2000 pipes in the system. > > Anyway, to the point: is there any resource I could read as to how to > prepare the system to catch correct debugging info at next crash? What > other helpful information may I provide? a backtrace and the detailed version of the ipfw+dummynet files will help cheers luigi From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 15:10: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 B50CA1065673 for ; Tue, 17 Aug 2010 15:10:02 +0000 (UTC) (envelope-from drsweetlips@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A78D8FC17 for ; Tue, 17 Aug 2010 15:10:02 +0000 (UTC) Received: by gxk24 with SMTP id 24so3162963gxk.13 for ; Tue, 17 Aug 2010 08:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SXduBkTVcZ7CYLg4Erp56Dt7Jv8m+l13t2MfzOtzm9g=; b=rteIIbiolBmo2TaoHR8FBr5rnl4Ajj56RPjGKkgKu4iSMhhnvYdl7jTxMGA+P7xsff R+90063pwcZDz/Ru8UEAEqOFobsyytSgzJ3dbgPQ2cjcPS+NWCUSEUM7tMe+9zCiF7KB 5As9VLGgHDo4DwgokHfWQk4HUJGbeOaYnFQRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=GGZZ19LW1Nw1THuUlEXkMcAF4pOeLgNhaqj4D8So8QhJR+3KuX2PvMrovVUXbZ4NDY ekvhhKtnp7qI6Mg0esZFCBQNuIjPgzlRYNnBfMRLvLNtWcVKPgAzG39+dTrgladTKKVU ZmDIyZPTm1XdblyLqD9ue+6BX85dPM7e6gSoU= Received: by 10.100.171.16 with SMTP id t16mr7685105ane.83.1282057801558; Tue, 17 Aug 2010 08:10:01 -0700 (PDT) Received: from [192.168.1.4] (rrcs-24-227-59-150.se.biz.rr.com [24.227.59.150]) by mx.google.com with ESMTPS id p16sm104908anh.35.2010.08.17.08.10.00 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 08:10:00 -0700 (PDT) Message-ID: <4C6AA647.50906@gmail.com> Date: Tue, 17 Aug 2010 11:09:59 -0400 From: FOSS Deluxe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100817120025.9034510657C2@hub.freebsd.org> In-Reply-To: <20100817120025.9034510657C2@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: freebsd-stable Digest, Vol 370, Issue 2 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, 17 Aug 2010 15:10:02 -0000 Well in normal use user applications are the ones that put the load on the CPU. The kernel is pretty much lightweight in size and work when non kernel intensive tasks are at hand (like gigabit links in the networks, etc). The good news is that the kernel will have its own core to play with. On 08/17/2010 08:00 AM, freebsd-stable-request@freebsd.org wrote: > Send freebsd-stable mailing list submissions to > freebsd-stable@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > or, via email, send a message with subject or body 'help' to > freebsd-stable-request@freebsd.org > > You can reach the person managing the list at > freebsd-stable-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-stable digest..." > > > Today's Topics: > > 1. Re: Inconsistent IO performance (Ivan Voras) > 2. Re: Inconsistent IO performance (Kevin Oberman) > 3. STABLE kernel panic: privileged instruction fault (Alexey Tarasov) > 4. Re: Inconsistent IO performance (Jeremy Chadwick) > 5. Re: Inconsistent IO performance (Jeremy Chadwick) > 6. Re: STABLE kernel panic: privileged instruction fault > (Kostik Belousov) > 7. Re: STABLE kernel panic: privileged instruction fault > (Alexey Tarasov) > 8. Re: STABLE kernel panic: privileged instruction fault > (Kostik Belousov) > 9. Re: STABLE kernel panic: privileged instruction fault > (Alexey Tarasov) > 10. Re: STABLE kernel panic: privileged instruction fault > (Kostik Belousov) > 11. Re: STABLE kernel panic: privileged instruction fault > (Alexey Tarasov) > 12. Re: RELENG_7 em problems (and RELENG_8) (Mike Tancsa) > 13. Performance AMD Phenom II X6 1090T (Vladislav V. Prodan) > 14. Crash in dummynet. (Pawel Tyll) > 15. Re: Crash in dummynet. (Luigi Rizzo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Aug 2010 15:03:23 +0200 > From: Ivan Voras > Subject: Re: Inconsistent IO performance > To:freebsd-stable@freebsd.org > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > On 13.8.2010 18:01, Kevin Oberman wrote: >> For some time I have seen very odd issues with IO performance on >> 8-Stable. Going back to November of last year when 8.0 was released, I >> see variations of up to 22% in identical operations. This is not a >> degradation as the performance moves up and down. > In 8.0-8.1 span of time there was some work on the ata driver to make it > use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this > will involve changing and recompiling the kernel but if you want to try > something and the hardware is SATA you might try the new AHCI driver > ("ada"). > > http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > > > > > ------------------------------ > > Message: 2 > Date: Mon, 16 Aug 2010 07:46:38 -0700 > From: "Kevin Oberman" > Subject: Re: Inconsistent IO performance > To: Ivan Voras > Cc:freebsd-stable@freebsd.org > Message-ID:<20100816144638.4ACF81CC3A@ptavv.es.net> > >> From: Ivan Voras >> Date: Mon, 16 Aug 2010 15:03:23 +0200 >> Sender:owner-freebsd-stable@freebsd.org >> >> On 13.8.2010 18:01, Kevin Oberman wrote: >>> For some time I have seen very odd issues with IO performance on >>> 8-Stable. Going back to November of last year when 8.0 was released, I >>> see variations of up to 22% in identical operations. This is not a >>> degradation as the performance moves up and down. >> In 8.0-8.1 span of time there was some work on the ata driver to make it >> use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this >> will involve changing and recompiling the kernel but if you want to try >> something and the hardware is SATA you might try the new AHCI driver >> ("ada"). >> >> http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > Thanks. I appreciate the suggestion. I am running a 8-Stable kernel > from August 9, so I think I should be OK on this. IS there a requirement > to set some parameter in the kernel config to take advantage of this? > > While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any > SATA connections. Both SATA ports a run to a SATA/PATA converter chip > and the only 2 physical connections available are PATA. I am assuming > that this is because 2.5 in. SATA drives were pretty much unavailable > when this system was shipped. This was the last of the T43 series and > was dropped from the product line by Lenovo about a month after I got > it, to be replaced by T60 systems running Core2 chips and using SATA > drives. > > Just lousy timing almost 4 years ago. > > Thanks again! From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 15:18: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 857AD1065679 for ; Tue, 17 Aug 2010 15:18:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38FF48FC1C for ; Tue, 17 Aug 2010 15:18:18 +0000 (UTC) Received: by qwg5 with SMTP id 5so7108895qwg.13 for ; Tue, 17 Aug 2010 08:18: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=XbD5/zhSSOgpEE8uYnhYMCtHsNKExPEd1IB9uNrFKa4=; b=jtT1TxYn+renv/HfwRBSXHjbCxqyr3X0YaEhwildbFBHW1WeBKdOmMF0moioScFocH 4hboPSL54VkUvEel4px/diGvwUaRuulbS0QIZMiQqnTmg+hVj4aA8+1uaDl8wOXY5WrG YJU66/Zc3lL1Kq35DZxF/mZlh5Pi+DNFlSaDg= 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=VSHwB4LnPOQZg2WcnHhhZ26tuUuLWxjE7FsBxVT3zsiqDLTpxjUV7az2DQAo/94Dih PnnhGT4zIgQ7hqfgNx5IoTSEDf5IDYI9lLQFnvAxUIv26Ouszw+7b+qrhpdD/gFQS4ft IbpNNFfmxFiZ1hWh5jIXZ1dDm6T9qW4zJMKIc= MIME-Version: 1.0 Received: by 10.224.72.195 with SMTP id n3mr4429053qaj.152.1282058298025; Tue, 17 Aug 2010 08:18:18 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Tue, 17 Aug 2010 08:18:17 -0700 (PDT) In-Reply-To: References: <201006301726.o5UHQl7n011935@svn.freebsd.org> <4C2BBC1F.6020405@elischer.org> Date: Tue, 17 Aug 2010 19:18:17 +0400 Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jack F Vogel , freebsd-stable Subject: Re: svn commit: r209611 - head/sys/dev/e1000 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, 17 Aug 2010 15:18:19 -0000 On 1 July 2010 02:13, Jack Vogel wrote: > On Wed, Jun 30, 2010 at 2:50 PM, Julian Elischer wro= te: > >> On 6/30/10 10:26 AM, Jack F Vogel wrote: >> >>> Author: jfv >>> Date: Wed Jun 30 17:26:47 2010 >>> New Revision: 209611 >>> URL: http://svn.freebsd.org/changeset/base/209611 >>> >>> Log: >>> =A0 SR-IOV support added to igb >>> >>> =A0 What this provides is support for the 'virtual function' >>> =A0 interface that a FreeBSD VM may be assigned from a host >>> =A0 like KVM on Linux, or newer versions of Xen with such >>> =A0 support. >>> >>> =A0 When the guest is set up with the capability, a special >>> =A0 limited function 82576 PCI device is present in its virtual >>> =A0 PCI space, so with this driver installed in the guest that >>> =A0 device will be detected and function nearly like the bare >>> =A0 metal, as it were. >>> >>> =A0 The interface is only allowed a single queue in this configuration >>> =A0 however initial performance tests have looked very good. >>> >>> =A0 Enjoy!! >>> >>> >> do these extra devices turn up in a standard ifconfig output? >> in other words, can we assign them to jails using vimage? >> >> > They only show up if configured in the PF host, for instance if using Lin= ux > and KVM (I did develop and test > with Fedora 13) you must load the igb driver there specifying that you wa= nt > vf's created and how many. > Next in the management of the guest you need to assign one of these vf > devices to the guest. After you > do all that and load this igb driver then yes, it will look just like a > standard igbX device. > Hi, Jack. I set up qemu-kvm on openSUSE 11.3 with 82576 PCI device as you described. Guest fails to attach with: igb0: mem 0xf2060000-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 igb0: Unable to allocate bus resource: interrupt device_attach: igb0 attach returned 6 igb0@pci0:0:5:0: class=3D0x020000 card=3D0xa03c8086 chip=3D0x10ca808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet cap 11[40] =3D MSI-X supports 3 messages in map 0x1c Did I missed something? --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 16:27: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 26F111065697 for ; Tue, 17 Aug 2010 16:27:05 +0000 (UTC) (envelope-from jfvogel@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 A6A698FC20 for ; Tue, 17 Aug 2010 16:27:03 +0000 (UTC) Received: by wyj26 with SMTP id 26so9007152wyj.13 for ; Tue, 17 Aug 2010 09:27:03 -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=7uxbsH0nTBZN5kQY6hnOSTCuCVmgeJZbcJagjK18APo=; b=HG09kJWoUzsS5lwLWB14CT2iup0zKflDSGYuT2p2NeG7YR/XpNsYBqUK0sj3Kpiv1n AmG+zb4GvwOjhG0prhaBi1kzG6T/YMz3Pk495EvNq425yyqHq4rY+rgYOoXc1zFzjPGQ /pBjOnJwJkp5wzyCaRoKS5/qJDjegdgA0AulE= 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=bTUK5rLvtUWgAXhkrJ6pksWGXrRy2efJRfEvZJcHP4L8sBwkxCcyAeILGFkX7C7n+D knndxpXma6BTuEjgJQygHV29c6cn7ziJEg2DLKgkOTB5giVi5ttfhPgPoSIoXS7SdXBY NUxRRKVuwjyiP5SjIXUy4+EZrIjjLGe4WWtMk= MIME-Version: 1.0 Received: by 10.227.145.148 with SMTP id d20mr6074943wbv.117.1282062423131; Tue, 17 Aug 2010 09:27:03 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 17 Aug 2010 09:27:01 -0700 (PDT) In-Reply-To: References: <201006301726.o5UHQl7n011935@svn.freebsd.org> <4C2BBC1F.6020405@elischer.org> Date: Tue, 17 Aug 2010 09:27:01 -0700 Message-ID: From: Jack Vogel To: pluknet Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , freebsd-stable Subject: Re: svn commit: r209611 - head/sys/dev/e1000 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, 17 Aug 2010 16:27:05 -0000 Cool the first person to actually try and use it :) Yes, there's one key thing you have to do right now that's not documented, because of the simplistic PCI structure the guest has the kernel blacklists it from using MSIX. SO, what you need to do is set the honor_blacklist (that's not the complete string, use sysctl -a |grep blacklist to find it) and set that to 0. It needs to be set at boot. That should get you running. Jack On Tue, Aug 17, 2010 at 8:18 AM, pluknet wrote: > On 1 July 2010 02:13, Jack Vogel wrote: > > On Wed, Jun 30, 2010 at 2:50 PM, Julian Elischer >wrote: > > > >> On 6/30/10 10:26 AM, Jack F Vogel wrote: > >> > >>> Author: jfv > >>> Date: Wed Jun 30 17:26:47 2010 > >>> New Revision: 209611 > >>> URL: http://svn.freebsd.org/changeset/base/209611 > >>> > >>> Log: > >>> SR-IOV support added to igb > >>> > >>> What this provides is support for the 'virtual function' > >>> interface that a FreeBSD VM may be assigned from a host > >>> like KVM on Linux, or newer versions of Xen with such > >>> support. > >>> > >>> When the guest is set up with the capability, a special > >>> limited function 82576 PCI device is present in its virtual > >>> PCI space, so with this driver installed in the guest that > >>> device will be detected and function nearly like the bare > >>> metal, as it were. > >>> > >>> The interface is only allowed a single queue in this configuration > >>> however initial performance tests have looked very good. > >>> > >>> Enjoy!! > >>> > >>> > >> do these extra devices turn up in a standard ifconfig output? > >> in other words, can we assign them to jails using vimage? > >> > >> > > They only show up if configured in the PF host, for instance if using > Linux > > and KVM (I did develop and test > > with Fedora 13) you must load the igb driver there specifying that you > want > > vf's created and how many. > > Next in the management of the guest you need to assign one of these vf > > devices to the guest. After you > > do all that and load this igb driver then yes, it will look just like a > > standard igbX device. > > > > Hi, Jack. > > I set up qemu-kvm on openSUSE 11.3 > with 82576 PCI device as you described. > > Guest fails to attach with: > igb0: mem > 0xf2060000-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 > igb0: Unable to allocate bus resource: interrupt > device_attach: igb0 attach returned 6 > > igb0@pci0:0:5:0: class=0x020000 card=0xa03c8086 chip=0x10ca8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 11[40] = MSI-X supports 3 messages in map 0x1c > > Did I missed something? > > -- > wbr, > pluknet > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 17:45: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 6BD3F10656A9 for ; Tue, 17 Aug 2010 17:45:42 +0000 (UTC) (envelope-from mark@islandnet.com) Received: from cluster2.islandnet.com (cluster.islandnet.com [199.175.106.51]) by mx1.freebsd.org (Postfix) with ESMTP id 558998FC29 for ; Tue, 17 Aug 2010 17:45:42 +0000 (UTC) Received: from [199.175.106.221] (port=19193 helo=helpdesk.islandnet.com) by blade2.islandnet.com with SMTP id 1OlQE6-000OvL-7F ; Tue, 17 Aug 2010 10:45:30 -0700 From: Mark Morley To: Rick Macklem Date: Tue, 17 Aug 2010 10:46:00 -0700 X-Priority: 3 X-Mailer: Islandnet.com Helpdesk Webmail Message-Id: <9c4ecm1t.1282067160@helpdesk.islandnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable , Mark Morley Subject: Re: NFS stalling on 8.1-STABLE 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, 17 Aug 2010 17:45:42 -0000 On Sun, 15 Aug 2010 17:11:01 -0400 (EDT) Rick Macklem wrote: >> Hi all, >> >> I have five front end web servers that all mount their content from the same server via NFS. If I stress the link on any one of the machines (eg: copy a large directory with a lot of files to/from the mounted file system) the client will pause. That is, all processes trying to access that mount will freeze. The log files with hundreds or thousands of nfs server not responding / is alive again messages. After 60 seconds it returns to normal, unless the load is still there in which case it continues to pause. >> > >The 60sec delay suggests that the client is doing a TCP reconnect. I'd suggest that you >look at a packet trace in wireshark (it knows how to decode NFS packets) and see if >there are new TCP connections (SYN, SYN-ACK,...) being made. If that is what is >happening, I suspect it is NIC driver related, but it is really hard to say. I'll try this if/when it happens again. >If you can try a network interface of a different type (not em) that will check to >see if it is an em(4) issue. Unfortunately I don't have any non-em cards around. >Alternately, you could try turning off the TSO and checksum offload stuff for the >em(4) and see if that helps. Hmm, interesting. The four machines that seem to be working (so far) have these enabled by default. The fifth one has checksums enabled, but not TSO. Doesn't appear to support it. I also tried switching from TCP to UDP. This seems to be working (so far) on four of the clients (which happen to be identical load balanced machines), but on the fifth one (which serves a different purpose) I'm getting something really weird. Instead of locking up periodically as before, it's actually losing the mount. For example, a 'df' doesn't include the mounted system. If I try to access the mounted system (with 'ls' for example) I get an "Input / output error" message. I can remount it, but only after I force a dismount. Mark From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 17:53: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 99ECA1065693 for ; Tue, 17 Aug 2010 17:53:47 +0000 (UTC) (envelope-from mark@islandnet.com) Received: from cluster4.islandnet.com (cluster.islandnet.com [199.175.106.53]) by mx1.freebsd.org (Postfix) with ESMTP id 847198FC14 for ; Tue, 17 Aug 2010 17:53:47 +0000 (UTC) Received: from [199.175.106.221] (port=26380 helo=helpdesk.islandnet.com) by blade4.islandnet.com with SMTP id 1OlQLq-000BV4-Fl ; Tue, 17 Aug 2010 10:53:30 -0700 From: Mark Morley To: Jeremy Chadwick Date: Tue, 17 Aug 2010 10:54:04 -0700 X-Priority: 3 X-Mailer: Islandnet.com Helpdesk Webmail Message-Id: <9c4ecm1t.1282067644@helpdesk.islandnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable , Mark Morley Subject: Re: NFS stalling on 8.1-STABLE 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, 17 Aug 2010 17:53:47 -0000 On Sun, 15 Aug 2010 23:35:50 -0700 Jeremy Chadwick wrote: >On Thu, Aug 12, 2010 at 10:35:49AM -0700, Mark Morley wrote: >> I have five front end web servers that all mount their content from >> the same server via NFS. If I stress the link on any one of the >> machines (eg: copy a large directory with a lot of files to/from the >> mounted file system) the client will pause. That is, all processes >> trying to access that mount will freeze. The log files with hundreds >> or thousands of nfs server not responding / is alive again messages. >> After 60 seconds it returns to normal, unless the load is still there >> in which case it continues to pause. >> >> This has only started happening since I upgraded the client machines >> to 8.1-STABLE (previously four of them were 8.0 and one was 7.3). The >> server is 7.1-RELEASE-p11. No other changes have taken place in terms >> of hardware or software or mount options, etc. >> >> All nics involved are gigabit em cards, and they are on a private >> network (web access to the boxes is via an external interface). > >Are there any indications in dmesg that the NIC is responsible, e.g. >interface down/up, etc.? No, nothing like that. >Does switching to UDP-based NFS solve the problem for you? Trying that now for the past 24 hours or so. Four of the machine seem ok so far, but the fifth one has started dropping the mount entirely. Access to it gives an "Input / output error" message. Forcing a dismount and remounting brings it back. >What OS version (uname -a) and NIC are used on the NFS server? FreeBSD xxx 7.1-RELEASE-p11 FreeBSD 7.1-RELEASE-p11 #0: Wed May 26 03:20:59 PDT 2010 root@xxx:/usr/obj/usr/src/sys/CUSTOM i386 NICs are em >Can you please provide the following output from one of the client >machines running 8.1-STABLE with gigE em(4)? You can X-out machine >names, MAC addresses, and IP addresses/netblocks if need be. > >* uname -a FreeBSD xxx 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Jul 27 16:27:44 PDT 2010 root@xxx:/usr/obj/usr/src/sys/CUSTOM amd64 >* ifconfig emX (where X is the interface number which would be > used for NFS) em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:0e:0c:85:d5:0d inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 1000baseT status: active >* netstat -idn -I emX Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:0e:0c:85:d5:0d 39913814 2 0 39949943 0 0 0 em0 1500 192.168.1.0/2 192.168.1.30 39944016 - - 39949664 - - - >* pciconf -lvc (provide only the data for emX please) em0@pci0:1:6:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >* vmstat -i interrupt total rate irq1: atkbd0 239 0 irq16: em0 36746591 883 irq18: em1 12658607 304 irq21: ohci0 2 0 irq22: ehci0 528002 12 irq23: atapci1 2334936 56 cpu0: timer 83207296 2000 cpu1: timer 83207289 2000 Total 218682962 5256 >* sysctl hw.pci hw.pci.usb_early_takeover: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.default_vgapci_unit: -1 hw.pci.host_mem_start: 2147483648 hw.pci.mcfg: 1 >* As root, run "sysctl dev.em.X.stats=1" then do "dmesg" and > provide the output for NIC statistics (will start with "emX:") em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 52 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 1 em0: Crc errors = 1 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 54 em0: XON Xmtd = 0 em0: XOFF Rcvd = 54 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 39915088 em0: Good Packets Xmtd = 39951839 Mark From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 18:52: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 094401065693 for ; Tue, 17 Aug 2010 18:52:13 +0000 (UTC) (envelope-from pyunyh@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 CA7CF8FC20 for ; Tue, 17 Aug 2010 18:52:12 +0000 (UTC) Received: by pwj4 with SMTP id 4so3067899pwj.13 for ; Tue, 17 Aug 2010 11:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=EyAooA8wp8pqD/IBdVC+YT0dbxNHY3zWHKnHoiSJLuQ=; b=yHGi3nvmM9uAhqP12Ja4pN6JYGBCcFrwUPIeU4tDC83ZcMUGvbf9ROz0yWQ3WB6aGY V/Tt0pR5S9ES7faUkGp3f83/xD0uw0VFFMO4cGo5I0CE/XtZEjonVrtc1XAFST5QkVEi pc+3vy/c196UHUlxWIxIcM7JspPNBOGcVSsTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rbyQefnx6eWi3heUu2qXR499qetO13v5ju94HBZZSOi6o6UqilxkQl8mV/J2Vh8H8L YZO5r7OH3NOW8qDPIWOjGOYCjHDhaRStjeCkDM4Qoylp+VCLzFeQu3JPrIsDrUyaewsS ROtnTbEczZQcYYU3o3+0RNLOexKbvDu4eNyrY= Received: by 10.114.25.5 with SMTP id 5mr8357293way.78.1282071132283; Tue, 17 Aug 2010 11:52:12 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d35sm14853458waa.9.2010.08.17.11.52.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 11:52:09 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 11:52:08 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 11:52:08 -0700 To: Mike Tancsa Message-ID: <20100817185208.GA6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008162107.o7GL76pA080191@lava.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:52:13 -0000 On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > Hi Jack, > FYI, I am still seeing this same problem on RELENG_8 (code > as of today). Unfortunately I cant try Pyun's patch since the > underlying code has changed since then. > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > pci3: on pcib3 > em4: port 0x1000-0x101f > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci3 > em4: Using MSI interrupt > em4: [FILTER] > em4: Ethernet address: 00:15:17:ed:3e:c4 > Here is updated patch for HEAD and stable/8. http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch It seems to work as expected under my limited environments. If you're using multiple Tx queues with em(4) it would be better to disable Tx checksum offloading as driver always have to create a new checksum context for each frame. This will effectively disable pipelined Tx data DMA which in turn greatly slows down Tx performance for small sized frames. The reason driver have to create a new checksum context when it uses multiple Tx queues comes from hardware limitation. The controller tracks only for the last context descriptor that was written such that driver does not know the state of checksum context configured in other Tx queue. Hope this helps. > > > ---Mike > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > >> Hi Jack, > >> Just a followup to the email below. I now saw what appears > >> to be the same problem on RELENG_8, but on a different nic and with > >> VLANs. So not sure if this is a general em problem, a problem > >> specific to some em NICs, or a TSO problem in general. The issue > >> seemed to be triggered when I added a new vlan based on > >> > >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > >> chip=0x109a8086 rev=0x00 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > >> class = network > >> subclass = ethernet > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > >> > >> pci14: on pcib5 > >> em3: port 0x6000-0x601f > >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > >> em3: Using MSI interrupt > >> em3: [FILTER] > >> em3: Ethernet address: 00:30:48:9f:eb:81 > >> > >> em3: flags=8943 > >> metric 0 mtu 1500 > >> options=2098 > >> ether 00:30:48:9f:eb:81 > >> inet 10.255.255.254 netmask 0xfffffffc broadcast 10.255.255.255 > >> media: Ethernet autoselect (1000baseT ) > >> status: active > >> > >> I had to disable tso, rxcsum and txsum in order to see the devices on > >> the other side of the two vlans trunked off em3. Unfortunately, the > >> other sides were switches 100km and 500km away so I didnt have any > >> tcpdump capabilities to diagnose the issue. I had already created > >> one vlan off this NIC and all was fine. A few weeks later, I added a > >> new one and I could no longer telnet into the remote switches from > >> the local machine.... But, I could telnet into the switches from > >> machines not on the problem box. Hence, it would appear to be a > >> general TSO issue no ? I disabled tso on the nic (I didnt disable > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > >> always ping the remote devices, but no tcp services. I then > >> remembered this issue from before, so I tried disabling tso on the > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > >> then telnet into the remote devices. > >> > >> This newly observed issue was from a buildworld on Mon Jun 14 > >> 11:29:12 EDT 2010. > >> > >> I will try and recreate the issue locally again to see if I can > >> trigger the problem on demand. Any thoughts on what it might be ? > >> Perhaps an issue specific to certain em nics ? > >> > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > >I'm not sure whether you're seeing the same issue though. > >I didn't have chance to try latest em(4) on stable/7. > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:05: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 BC496106564A for ; Tue, 17 Aug 2010 19:05:58 +0000 (UTC) (envelope-from jfvogel@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 487B68FC20 for ; Tue, 17 Aug 2010 19:05:57 +0000 (UTC) Received: by wwb24 with SMTP id 24so5280180wwb.31 for ; Tue, 17 Aug 2010 12:05:57 -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=r/ngFD3+CQuUpQ51sFERZi+GnWI1/WUVQm9BfHEj13k=; b=bRQdD7SI8xskVle9kWZD6gf98rcrzQVlNsyfC5QZdD7TdgtuhykwdEStJWWY5Uk99E fSihqKhncnebhGwtCsCydgg1F8MpSJDRbNhiJJg3mu8dnQx9S/UYwu3yAWj++5Gevmjc h1++IkZQpn0cIgHD4cGPQ1eIlOwbgWnJ6AOsQ= 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=sCSvRvfrLlMdbAcC/QxtzmXRo62zrJgrrMLa3Sw+RVHqupL6AwBtbEsVCszm2OGGYH u0ETqORBD9SW/OmGsZiXYkhTrauLFTJZfUXrS1FGL77XEvsywhG+rbedOpi83B8/8Uq6 vJ9bAbM6Hnz3SdEBv04mx4GWx6YuZgvJSbCFI= MIME-Version: 1.0 Received: by 10.216.159.6 with SMTP id r6mr1115386wek.55.1282071957063; Tue, 17 Aug 2010 12:05:57 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 17 Aug 2010 12:05:56 -0700 (PDT) In-Reply-To: <20100817185208.GA6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> Date: Tue, 17 Aug 2010 12:05:56 -0700 Message-ID: From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 17 Aug 2010 19:05:58 -0000 Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it should automagically disable CSUM? Jack On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon wrote: > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > Hi Jack, > > FYI, I am still seeing this same problem on RELENG_8 (code > > as of today). Unfortunately I cant try Pyun's patch since the > > underlying code has changed since then. > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > pci3: on pcib3 > > em4: port 0x1000-0x101f > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on > pci3 > > em4: Using MSI interrupt > > em4: [FILTER] > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > Here is updated patch for HEAD and stable/8. > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > It seems to work as expected under my limited environments. If > you're using multiple Tx queues with em(4) it would be better to > disable Tx checksum offloading as driver always have to create a > new checksum context for each frame. This will effectively disable > pipelined Tx data DMA which in turn greatly slows down Tx > performance for small sized frames. The reason driver have to > create a new checksum context when it uses multiple Tx queues comes > from hardware limitation. The controller tracks only for the last > context descriptor that was written such that driver does not know > the state of checksum context configured in other Tx queue. > Hope this helps. > > > > > > > ---Mike > > > > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > >> Hi Jack, > > >> Just a followup to the email below. I now saw what appears > > >> to be the same problem on RELENG_8, but on a different nic and with > > >> VLANs. So not sure if this is a general em problem, a problem > > >> specific to some em NICs, or a TSO problem in general. The issue > > >> seemed to be triggered when I added a new vlan based on > > >> > > >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > >> chip=0x109a8086 rev=0x00 hdr=0x00 > > >> vendor = 'Intel Corporation' > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > >> class = network > > >> subclass = ethernet > > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > >> > > >> pci14: on pcib5 > > >> em3: port 0x6000-0x601f > > >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > >> em3: Using MSI interrupt > > >> em3: [FILTER] > > >> em3: Ethernet address: 00:30:48:9f:eb:81 > > >> > > >> em3: flags=8943 > > >> metric 0 mtu 1500 > > >> options=2098 > > >> ether 00:30:48:9f:eb:81 > > >> inet 10.255.255.254 netmask 0xfffffffc broadcast > 10.255.255.255 > > >> media: Ethernet autoselect (1000baseT ) > > >> status: active > > >> > > >> I had to disable tso, rxcsum and txsum in order to see the devices on > > >> the other side of the two vlans trunked off em3. Unfortunately, the > > >> other sides were switches 100km and 500km away so I didnt have any > > >> tcpdump capabilities to diagnose the issue. I had already created > > >> one vlan off this NIC and all was fine. A few weeks later, I added a > > >> new one and I could no longer telnet into the remote switches from > > >> the local machine.... But, I could telnet into the switches from > > >> machines not on the problem box. Hence, it would appear to be a > > >> general TSO issue no ? I disabled tso on the nic (I didnt disable > > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > >> always ping the remote devices, but no tcp services. I then > > >> remembered this issue from before, so I tried disabling tso on the > > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > >> then telnet into the remote devices. > > >> > > >> This newly observed issue was from a buildworld on Mon Jun 14 > > >> 11:29:12 EDT 2010. > > >> > > >> I will try and recreate the issue locally again to see if I can > > >> trigger the problem on demand. Any thoughts on what it might be ? > > >> Perhaps an issue specific to certain em nics ? > > >> > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > > >I'm not sure whether you're seeing the same issue though. > > >I didn't have chance to try latest em(4) on stable/7. > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:14: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 A513B1065696 for ; Tue, 17 Aug 2010 19:14:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 71F6E8FC12 for ; Tue, 17 Aug 2010 19:14:24 +0000 (UTC) Received: by pxi17 with SMTP id 17so3072938pxi.13 for ; Tue, 17 Aug 2010 12:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=0mB8bcFGb6PBmp0c9BWwGBXHJYlSF9Wb7PhGJ/VfqV8=; b=m1keV2rD/2Dulxrf0TcIUu1qFySCj4YqTypPKY+/um9aj+qREAlR3SFh0vpQgIwWAo W4ZX2Q1Gm7+4kocbondQFiz/vMa8PZFD2j83XqquHMqZeWDo7EclPM/ZnAFUGYFb43oM sYSP14A4Bz9slo7F/3Lz7tkfzsvLfO1/BIg3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Riggm0MI4RPEk2hJhCkdwxeAeYtl2WlbYG2n9wJ6aYxOghzUwPRtccfMZhg1/5yRxw 0SX3eXVXxFk+PYfnZXqnFQQxLRNvl7mTMxkZRK586anqpTo26MdWphy0vEHUFHjKQFaQ /ZLE/PFG8/x8V9OYKJwX1O6fe2VxoEYitHnh4= Received: by 10.142.172.5 with SMTP id u5mr6125561wfe.148.1282072463690; Tue, 17 Aug 2010 12:14:23 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v38sm10077891wfh.0.2010.08.17.12.14.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 12:14:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 12:14:20 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 12:14:20 -0700 To: Mike Tancsa Message-ID: <20100817191420.GB6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100817185208.GA6482@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:14:24 -0000 On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote: > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > Hi Jack, > > FYI, I am still seeing this same problem on RELENG_8 (code > > as of today). Unfortunately I cant try Pyun's patch since the > > underlying code has changed since then. > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > rev=0x00 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > class = network > > subclass = ethernet > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > pci3: on pcib3 > > em4: port 0x1000-0x101f > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci3 > > em4: Using MSI interrupt > > em4: [FILTER] > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > Here is updated patch for HEAD and stable/8. > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > It seems to work as expected under my limited environments. If > you're using multiple Tx queues with em(4) it would be better to > disable Tx checksum offloading as driver always have to create a > new checksum context for each frame. This will effectively disable > pipelined Tx data DMA which in turn greatly slows down Tx > performance for small sized frames. The reason driver have to > create a new checksum context when it uses multiple Tx queues comes > from hardware limitation. The controller tracks only for the last > context descriptor that was written such that driver does not know > the state of checksum context configured in other Tx queue. > Hope this helps. > For igb(4) controllers, it seems we also need a way to avoid creating a new checksum context for every Tx frame as we did in em(4). Unlike em(4) controllers, igb(4) seems to maintain context per queue such that we can safely reuse previously configured context for a queue. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:34: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 AB5971065670 for ; Tue, 17 Aug 2010 19:34:41 +0000 (UTC) (envelope-from jfvogel@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 364508FC16 for ; Tue, 17 Aug 2010 19:34:40 +0000 (UTC) Received: by wwb24 with SMTP id 24so5312575wwb.31 for ; Tue, 17 Aug 2010 12:34:40 -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=ATRMAzH2t7nVc47vnJd65aQMUTPKJNAOH7/wNogqT68=; b=VqU9UxlOwddUuvXOCCHDVd/FbpuS26SUm171ZqT6HrZDWxBZ6T51zmAw6m2L/2utw9 GIjgxzw/+aQ2QkfWDnof6vZXPMOxjvYsQ1sB9/YXlqkW2MJD/6WApQ65tCRaoDyw+pXI +zfOosNdh7ejkiGCDRHXkmGR0aebGFRO7QDA8= 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=o2GEEm7nHmKdh4soT7noX/2Grv42HS0Isc+FSzNOZiU4EQgb1vx1rclLc3jKpONA2X iE95hPRVR/q9vwJsDxxUzc/X3XKruWxlPgPUxd2FZEIm2Qw+A0h7P4HgePAPMNpMhSqf HhMogitQF0e8JwlhsMsmsCZb99+U6CvRMwKcA= MIME-Version: 1.0 Received: by 10.216.179.20 with SMTP id g20mr6067584wem.45.1282073671292; Tue, 17 Aug 2010 12:34:31 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 17 Aug 2010 12:34:31 -0700 (PDT) In-Reply-To: <20100817191420.GB6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <20100817191420.GB6482@michelle.cdnetworks.com> Date: Tue, 17 Aug 2010 12:34:31 -0700 Message-ID: From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 17 Aug 2010 19:34:41 -0000 I believe the requirement of a context descriptor for most frames in the igb driver is just the way the hardware works, I've looked over the Linux driver again and it looks like they require the same. I don't believe its a big deal, just the added descriptor for the frame. Jack On Tue, Aug 17, 2010 at 12:14 PM, Pyun YongHyeon wrote: > On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote: > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > > Hi Jack, > > > FYI, I am still seeing this same problem on RELENG_8 (code > > > as of today). Unfortunately I cant try Pyun's patch since the > > > underlying code has changed since then. > > > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > > rev=0x00 hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > pci3: on pcib3 > > > em4: port 0x1000-0x101f > > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on > pci3 > > > em4: Using MSI interrupt > > > em4: [FILTER] > > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > > > > Here is updated patch for HEAD and stable/8. > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > > It seems to work as expected under my limited environments. If > > you're using multiple Tx queues with em(4) it would be better to > > disable Tx checksum offloading as driver always have to create a > > new checksum context for each frame. This will effectively disable > > pipelined Tx data DMA which in turn greatly slows down Tx > > performance for small sized frames. The reason driver have to > > create a new checksum context when it uses multiple Tx queues comes > > from hardware limitation. The controller tracks only for the last > > context descriptor that was written such that driver does not know > > the state of checksum context configured in other Tx queue. > > Hope this helps. > > > > For igb(4) controllers, it seems we also need a way to avoid > creating a new checksum context for every Tx frame as we did in > em(4). Unlike em(4) controllers, igb(4) seems to maintain context > per queue such that we can safely reuse previously configured > context for a queue. > _______________________________________________ > 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 Aug 17 19:35: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 7C0851065670 for ; Tue, 17 Aug 2010 19:35:35 +0000 (UTC) (envelope-from pyunyh@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 206798FC1F for ; Tue, 17 Aug 2010 19:35:34 +0000 (UTC) Received: by ywk9 with SMTP id 9so3344666ywk.13 for ; Tue, 17 Aug 2010 12:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=K4L+WmgomDt0Y+FV7QbuLg7kJfo0L0C24k1LlBNQYPA=; b=V6HFVvQTuGknpvlkuEBqcxXRPxQXiRuacAUrs2ZOrVHAbVmFGb9shWiOFSUWK9tVIa UUrk2nfHbVjcl52zp63M3gw8zilNOcHWlnoCV+sfiRsqkDnKwx6eUjFpykQsw60bK4cC a5y3quwnZ+wuolhQ29Tb50zDyofIOAO89ITAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=s+sfw9EXwPYAtpcSTFsFk1vkFADM4C8HrsgYKmrcaIcvKV3sTfkh3LO6AuJxCZul+v GTCgYHpRCGIxR+ltzPvIXdkvVSq5xLRItQMOIEDGA8A2yKu6KyWrbZIufVQfPpw40aQQ Y4C2u2TksCI4tFojC/Y6YWi7NBC76uI3eyJqw= Received: by 10.231.177.25 with SMTP id bg25mr7360559ibb.154.1282073733697; Tue, 17 Aug 2010 12:35:33 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r3sm6427486ibk.13.2010.08.17.12.35.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 12:35:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 12:35:31 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 12:35:31 -0700 To: Jack Vogel Message-ID: <20100817193531.GC6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:35:35 -0000 On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote: > Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it > should automagically disable CSUM? > I don't have 82574 controller to test but it may depend on how pipelined Tx data DMA works. If 82574 can still pipeline Tx data DMA when a new context is written it would be better to enable checksum offloading. If em(4) uses single Tx queue, we can safely enable checksum offloading, I guess. > Jack > > > On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon wrote: > > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > > Hi Jack, > > > FYI, I am still seeing this same problem on RELENG_8 (code > > > as of today). Unfortunately I cant try Pyun's patch since the > > > underlying code has changed since then. > > > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > > rev=0x00 hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > > class = network > > > subclass = ethernet > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > pci3: on pcib3 > > > em4: port 0x1000-0x101f > > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on > > pci3 > > > em4: Using MSI interrupt > > > em4: [FILTER] > > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > > > > Here is updated patch for HEAD and stable/8. > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > > It seems to work as expected under my limited environments. If > > you're using multiple Tx queues with em(4) it would be better to > > disable Tx checksum offloading as driver always have to create a > > new checksum context for each frame. This will effectively disable > > pipelined Tx data DMA which in turn greatly slows down Tx > > performance for small sized frames. The reason driver have to > > create a new checksum context when it uses multiple Tx queues comes > > from hardware limitation. The controller tracks only for the last > > context descriptor that was written such that driver does not know > > the state of checksum context configured in other Tx queue. > > Hope this helps. > > > > > > > > > > > ---Mike > > > > > > > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > > >> Hi Jack, > > > >> Just a followup to the email below. I now saw what appears > > > >> to be the same problem on RELENG_8, but on a different nic and with > > > >> VLANs. So not sure if this is a general em problem, a problem > > > >> specific to some em NICs, or a TSO problem in general. The issue > > > >> seemed to be triggered when I added a new vlan based on > > > >> > > > >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > > >> chip=0x109a8086 rev=0x00 hdr=0x00 > > > >> vendor = 'Intel Corporation' > > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > > >> class = network > > > >> subclass = ethernet > > > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > >> > > > >> pci14: on pcib5 > > > >> em3: port 0x6000-0x601f > > > >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > > >> em3: Using MSI interrupt > > > >> em3: [FILTER] > > > >> em3: Ethernet address: 00:30:48:9f:eb:81 > > > >> > > > >> em3: flags=8943 > > > >> metric 0 mtu 1500 > > > >> options=2098 > > > >> ether 00:30:48:9f:eb:81 > > > >> inet 10.255.255.254 netmask 0xfffffffc broadcast > > 10.255.255.255 > > > >> media: Ethernet autoselect (1000baseT ) > > > >> status: active > > > >> > > > >> I had to disable tso, rxcsum and txsum in order to see the devices on > > > >> the other side of the two vlans trunked off em3. Unfortunately, the > > > >> other sides were switches 100km and 500km away so I didnt have any > > > >> tcpdump capabilities to diagnose the issue. I had already created > > > >> one vlan off this NIC and all was fine. A few weeks later, I added a > > > >> new one and I could no longer telnet into the remote switches from > > > >> the local machine.... But, I could telnet into the switches from > > > >> machines not on the problem box. Hence, it would appear to be a > > > >> general TSO issue no ? I disabled tso on the nic (I didnt disable > > > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > > >> always ping the remote devices, but no tcp services. I then > > > >> remembered this issue from before, so I tried disabling tso on the > > > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > > >> then telnet into the remote devices. > > > >> > > > >> This newly observed issue was from a buildworld on Mon Jun 14 > > > >> 11:29:12 EDT 2010. > > > >> > > > >> I will try and recreate the issue locally again to see if I can > > > >> trigger the problem on demand. Any thoughts on what it might be ? > > > >> Perhaps an issue specific to certain em nics ? > > > >> > > > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > > > >I'm not sure whether you're seeing the same issue though. > > > >I didn't have chance to try latest em(4) on stable/7. > > > > > > -------------------------------------------------------------------- > > > Mike Tancsa, tel +1 519 651 3400 > > > Sentex Communications, mike@sentex.net > > > Providing Internet since 1994 www.sentex.net > > > Cambridge, Ontario Canada www.sentex.net/mike > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:37: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 E0181106564A for ; Tue, 17 Aug 2010 19:37:06 +0000 (UTC) (envelope-from jfvogel@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 492ED8FC17 for ; Tue, 17 Aug 2010 19:37:06 +0000 (UTC) Received: by wwb24 with SMTP id 24so5315332wwb.31 for ; Tue, 17 Aug 2010 12:37:05 -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=wxwtlXcYTaxsRWVu4c2srrVtmBf0GTxG1SCF6xgqcyA=; b=sm1pKUQlWrX3pZ4GJXR5MlSZ/d+pFbV/LlfX0tOInCDowy0P7Ss9b4NfzSFM9dF6E+ 2aEKHX7K2phTnk/Cs3xGlBOnRPyEjRJb7TetfsoTk0iG5YajRlfDdUfOuX6IB+h3ToAf Dy29kzJY7jrh8DHfKZwrTBe4ttCo6tjCNtSjU= 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=LWjRI8VNudCfLF4u6uDjQcEULwpnTEdUFmoCz2XQLbejMu5IlvVavUbUgFXkaIJbCP edFgn8gtkjJ9K7rrlfcyHLZsjBmsCWk4AFIS1d6M1/kD7FHtGHXORXWNydH8U+s5/UuJ tjsGJrf4JSZhsXhH3EOivzaZ2g6wxpDfanZYI= MIME-Version: 1.0 Received: by 10.216.21.206 with SMTP id r56mr1149689wer.31.1282073825088; Tue, 17 Aug 2010 12:37:05 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 17 Aug 2010 12:37:04 -0700 (PDT) In-Reply-To: <20100817193531.GC6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <20100817193531.GC6482@michelle.cdnetworks.com> Date: Tue, 17 Aug 2010 12:37:04 -0700 Message-ID: From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 17 Aug 2010 19:37:07 -0000 Well we do of course, i'll have my test engineer try it both ways and see what looks better. Let you know... Jack On Tue, Aug 17, 2010 at 12:35 PM, Pyun YongHyeon wrote: > On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote: > > Hmmm, interesting, I'll have to have some testing done, maybe for the 574 > it > > should automagically disable CSUM? > > > > I don't have 82574 controller to test but it may depend on how > pipelined Tx data DMA works. If 82574 can still pipeline Tx data > DMA when a new context is written it would be better to enable > checksum offloading. If em(4) uses single Tx queue, we can safely > enable checksum offloading, I guess. > > > Jack > > > > > > On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon > wrote: > > > > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > > > Hi Jack, > > > > FYI, I am still seeing this same problem on RELENG_8 (code > > > > as of today). Unfortunately I cant try Pyun's patch since the > > > > underlying code has changed since then. > > > > > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > > > rev=0x00 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > > > class = network > > > > subclass = ethernet > > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > message > > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > > > pci3: on pcib3 > > > > em4: port 0x1000-0x101f > > > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 > on > > > pci3 > > > > em4: Using MSI interrupt > > > > em4: [FILTER] > > > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > > > > > > > Here is updated patch for HEAD and stable/8. > > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > > > > > It seems to work as expected under my limited environments. If > > > you're using multiple Tx queues with em(4) it would be better to > > > disable Tx checksum offloading as driver always have to create a > > > new checksum context for each frame. This will effectively disable > > > pipelined Tx data DMA which in turn greatly slows down Tx > > > performance for small sized frames. The reason driver have to > > > create a new checksum context when it uses multiple Tx queues comes > > > from hardware limitation. The controller tracks only for the last > > > context descriptor that was written such that driver does not know > > > the state of checksum context configured in other Tx queue. > > > Hope this helps. > > > > > > > > > > > > > > > ---Mike > > > > > > > > > > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > > > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > > > >> Hi Jack, > > > > >> Just a followup to the email below. I now saw what appears > > > > >> to be the same problem on RELENG_8, but on a different nic and > with > > > > >> VLANs. So not sure if this is a general em problem, a problem > > > > >> specific to some em NICs, or a TSO problem in general. The issue > > > > >> seemed to be triggered when I added a new vlan based on > > > > >> > > > > >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > > > >> chip=0x109a8086 rev=0x00 hdr=0x00 > > > > >> vendor = 'Intel Corporation' > > > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > > > >> class = network > > > > >> subclass = ethernet > > > > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 > message > > > > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link > x1(x1) > > > > >> > > > > >> pci14: on pcib5 > > > > >> em3: port > 0x6000-0x601f > > > > >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > > > >> em3: Using MSI interrupt > > > > >> em3: [FILTER] > > > > >> em3: Ethernet address: 00:30:48:9f:eb:81 > > > > >> > > > > >> em3: flags=8943 > > > > >> metric 0 mtu 1500 > > > > >> > options=2098 > > > > >> ether 00:30:48:9f:eb:81 > > > > >> inet 10.255.255.254 netmask 0xfffffffc broadcast > > > 10.255.255.255 > > > > >> media: Ethernet autoselect (1000baseT ) > > > > >> status: active > > > > >> > > > > >> I had to disable tso, rxcsum and txsum in order to see the devices > on > > > > >> the other side of the two vlans trunked off em3. Unfortunately, > the > > > > >> other sides were switches 100km and 500km away so I didnt have any > > > > >> tcpdump capabilities to diagnose the issue. I had already created > > > > >> one vlan off this NIC and all was fine. A few weeks later, I > added a > > > > >> new one and I could no longer telnet into the remote switches from > > > > >> the local machine.... But, I could telnet into the switches from > > > > >> machines not on the problem box. Hence, it would appear to be a > > > > >> general TSO issue no ? I disabled tso on the nic (I didnt disable > > > > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > > > >> always ping the remote devices, but no tcp services. I then > > > > >> remembered this issue from before, so I tried disabling tso on the > > > > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > > > >> then telnet into the remote devices. > > > > >> > > > > >> This newly observed issue was from a buildworld on Mon Jun 14 > > > > >> 11:29:12 EDT 2010. > > > > >> > > > > >> I will try and recreate the issue locally again to see if I can > > > > >> trigger the problem on demand. Any thoughts on what it might be ? > > > > >> Perhaps an issue specific to certain em nics ? > > > > >> > > > > > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > > > > >I'm not sure whether you're seeing the same issue though. > > > > >I didn't have chance to try latest em(4) on stable/7. > > > > > > > > -------------------------------------------------------------------- > > > > Mike Tancsa, tel +1 519 651 3400 > > > > Sentex Communications, mike@sentex.net > > > > Providing Internet since 1994 www.sentex.net > > > > Cambridge, Ontario Canada > www.sentex.net/mike > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:47: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 F3A6D1065672 for ; Tue, 17 Aug 2010 19:47:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE1EA8FC20 for ; Tue, 17 Aug 2010 19:47:08 +0000 (UTC) Received: by pxi17 with SMTP id 17so3086431pxi.13 for ; Tue, 17 Aug 2010 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=cKj1v7SfYJA0syLOfC0UEwdha5SiYrFggZN6zNFbiOQ=; b=GueN+npk2VzWNsQaqpkJ4PHHmY53LhURDYACdAHRZjNaOI8nJM7u9IYxmYD6Fp1Gf/ aQCvJ60mBcJbFZM/t6lqUAYqiyZOmx2uLKlCWIrfROKV7QyT/XhRnH457acb4Wb1UHHR JwApFAPnkGoSwVJMIC8m22jNxN7YHwG1lb53w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TjVps/TdmVjRQByn4WiVWDLHFCZ7zplzaTF2BQJV5vDLO2tGjoWUWjIgQUXpTCNyMx PD71WBukPo2GnH/vb8iIImDGdSfteZlvqwntwiJbQnBKxDo01eJeUxoa3F2/63KG2Vgp 5W1yVXNyHPWFfhwL1f4r3pnG4DJRXTRP3Gov4= Received: by 10.142.253.12 with SMTP id a12mr6166628wfi.251.1282074428294; Tue, 17 Aug 2010 12:47:08 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v38sm10106822wfh.12.2010.08.17.12.47.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 12:47:06 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 12:47:05 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 12:47:05 -0700 To: Jack Vogel Message-ID: <20100817194705.GD6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <20100817191420.GB6482@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:47:09 -0000 On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote: > I believe the requirement of a context descriptor for most frames in the igb > driver > is just the way the hardware works, I've looked over the Linux driver again > and it > looks like they require the same. I don't believe its a big deal, just the > added > descriptor for the frame. > Setting up context does not cost much. The real cost comes from stopping requesting DMA for next packet whenever a new context is written. AFAIK Linux always added a new checksum context. I don't know whether Linux cares about the cost of refilling pipeline or measured the performance differences. FreeBSD noticed the difference on em(4) controllers and took appropriate action to take full advantage of the hardware feature, I think. I have to experiment how igb(4) works when it is told to reuse configured context(both checksum and TSO context). > Jack > > > On Tue, Aug 17, 2010 at 12:14 PM, Pyun YongHyeon wrote: > > > On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote: > > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > > > Hi Jack, > > > > FYI, I am still seeing this same problem on RELENG_8 (code > > > > as of today). Unfortunately I cant try Pyun's patch since the > > > > underlying code has changed since then. > > > > > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > > > rev=0x00 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > > > class = network > > > > subclass = ethernet > > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > > > pci3: on pcib3 > > > > em4: port 0x1000-0x101f > > > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on > > pci3 > > > > em4: Using MSI interrupt > > > > em4: [FILTER] > > > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > > > > > > > Here is updated patch for HEAD and stable/8. > > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > > > > It seems to work as expected under my limited environments. If > > > you're using multiple Tx queues with em(4) it would be better to > > > disable Tx checksum offloading as driver always have to create a > > > new checksum context for each frame. This will effectively disable > > > pipelined Tx data DMA which in turn greatly slows down Tx > > > performance for small sized frames. The reason driver have to > > > create a new checksum context when it uses multiple Tx queues comes > > > from hardware limitation. The controller tracks only for the last > > > context descriptor that was written such that driver does not know > > > the state of checksum context configured in other Tx queue. > > > Hope this helps. > > > > > > > For igb(4) controllers, it seems we also need a way to avoid > > creating a new checksum context for every Tx frame as we did in > > em(4). Unlike em(4) controllers, igb(4) seems to maintain context > > per queue such that we can safely reuse previously configured > > context for a queue. > > _______________________________________________ > > 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 Aug 17 19:55: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 E16131065673 for ; Tue, 17 Aug 2010 19:55:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C92D8FC15 for ; Tue, 17 Aug 2010 19:55:11 +0000 (UTC) Received: by ewy26 with SMTP id 26so4002327ewy.13 for ; Tue, 17 Aug 2010 12:55: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; bh=0IsMyrs2NyDkfiIyTFarJ4djPN9m5VvEKiuJgBFqOQ8=; b=AugaH0RSrorhpNufeOoc7bT/90N2j1uk5vLgOkp39c5zAqyHabyKy6jc7D3U5NsRGV FQH28kNs9UGuRka3WUBpXMQjq7vGOLXji5YwlTgtQzb0RCEvKghpYqpivBMvdmw07tlR 0iTKgsJFB8HC1TZ3UfelXWfsoeyAEY7wH0gio= 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=tXnX8QiS/s33iA7uJ33qcFZH8UJenPnk+4kX5vDYCZIwABSDnZLYXcR/3aAWUBk7D6 rdlUsMT95tRNKpsKCw1vSXe3ExRAAIvgaQwuV8cGYP6KqLWkLbxp0yq9D53pOluN8ry/ Q/kG2Q0hPMMxHM1tEQ/HXq6ojs1mYhNATajoA= MIME-Version: 1.0 Received: by 10.216.3.83 with SMTP id 61mr1149407weg.110.1282074910955; Tue, 17 Aug 2010 12:55:10 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Tue, 17 Aug 2010 12:55:08 -0700 (PDT) In-Reply-To: <20100817194705.GD6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <20100817191420.GB6482@michelle.cdnetworks.com> <20100817194705.GD6482@michelle.cdnetworks.com> Date: Tue, 17 Aug 2010 12:55:08 -0700 Message-ID: From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 17 Aug 2010 19:55:13 -0000 The guy who worries about the Linux driver's performance is in my team, and he's a very good engineer, and we're talking about the hardware's DMA, so its not an OS issue, thus I'm not saying I'm sure, but I'm dubious about this, at least when we're talking about igb. But hey, I'm willing to be proven wrong :) Jack On Tue, Aug 17, 2010 at 12:47 PM, Pyun YongHyeon wrote: > On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote: > > I believe the requirement of a context descriptor for most frames in the > igb > > driver > > is just the way the hardware works, I've looked over the Linux driver > again > > and it > > looks like they require the same. I don't believe its a big deal, just > the > > added > > descriptor for the frame. > > > > Setting up context does not cost much. The real cost comes from > stopping requesting DMA for next packet whenever a new context > is written. > AFAIK Linux always added a new checksum context. I don't know > whether Linux cares about the cost of refilling pipeline or > measured the performance differences. FreeBSD noticed the > difference on em(4) controllers and took appropriate action to take > full advantage of the hardware feature, I think. > I have to experiment how igb(4) works when it is told to reuse > configured context(both checksum and TSO context). > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:55: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 A6F0310656B9 for ; Tue, 17 Aug 2010 19:55:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 498C98FC17 for ; Tue, 17 Aug 2010 19:55:13 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7HJt7Sl092151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Aug 2010 15:55:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7HJt67T087902; Tue, 17 Aug 2010 15:55:06 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008171955.o7HJt67T087902@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Aug 2010 15:55:12 -0400 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20100817185208.GA6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) 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, 17 Aug 2010 19:55:13 -0000 At 02:52 PM 8/17/2010, Pyun YongHyeon wrote: >Here is updated patch for HEAD and stable/8. >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > >It seems to work as expected under my limited environments. If Thanks! The patch applies cleanly and all works as expected now! I am no longer able to trigger the bug. I just use the stock unmodified driver normally, so no multi queues # vmstat -i interrupt total rate irq256: em0 149 0 irq257: em1 3 0 irq259: em3 971 2 irq260: ahci0 1520 3 em3: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:xx:xx:xx inet6 fe80::215:17ff:fexx:xxxx%em3 prefixlen 64 scopeid 0x4 inet 192.168.xx.xx netmask 0xffffff00 broadcast 192.168.xx.xx nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active em3@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c patch < em.csum_tso.20100817.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/e1000/if_em.c |=================================================================== |--- sys/dev/e1000/if_em.c (revision 211398) |+++ sys/dev/e1000/if_em.c (working copy) -------------------------- Patching file sys/dev/e1000/if_em.c using Plan A... Hunk #1 succeeded at 237. Hunk #2 succeeded at 1730. Hunk #3 succeeded at 1759. Hunk #4 succeeded at 1930. Hunk #5 succeeded at 3148. Hunk #6 succeeded at 3351. Hunk #7 succeeded at 3533. Hunk #8 succeeded at 3590. Hunk #9 succeeded at 3603. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/dev/e1000/if_em.h |=================================================================== |--- sys/dev/e1000/if_em.h (revision 211398) |+++ sys/dev/e1000/if_em.h (working copy) -------------------------- Patching file sys/dev/e1000/if_em.h using Plan A... Hunk #1 succeeded at 284. done ---Mike >you're using multiple Tx queues with em(4) it would be better to >disable Tx checksum offloading as driver always have to create a >new checksum context for each frame. This will effectively disable >pipelined Tx data DMA which in turn greatly slows down Tx >performance for small sized frames. The reason driver have to >create a new checksum context when it uses multiple Tx queues comes >from hardware limitation. The controller tracks only for the last >context descriptor that was written such that driver does not know >the state of checksum context configured in other Tx queue. >Hope this helps. > > > > > > > ---Mike > > > > > > At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > > >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > > >> Hi Jack, > > >> Just a followup to the email below. I now saw what appears > > >> to be the same problem on RELENG_8, but on a different nic and with > > >> VLANs. So not sure if this is a general em problem, a problem > > >> specific to some em NICs, or a TSO problem in general. The issue > > >> seemed to be triggered when I added a new vlan based on > > >> > > >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > > >> chip=0x109a8086 rev=0x00 hdr=0x00 > > >> vendor = 'Intel Corporation' > > >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > > >> class = network > > >> subclass = ethernet > > >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > >> > > >> pci14: on pcib5 > > >> em3: port 0x6000-0x601f > > >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > > >> em3: Using MSI interrupt > > >> em3: [FILTER] > > >> em3: Ethernet address: 00:30:48:9f:eb:81 > > >> > > >> em3: flags=8943 > > >> metric 0 mtu 1500 > > >> options=2098 > > >> ether 00:30:48:9f:eb:81 > > >> inet 10.255.255.254 netmask 0xfffffffc broadcast 10.255.255.255 > > >> media: Ethernet autoselect (1000baseT ) > > >> status: active > > >> > > >> I had to disable tso, rxcsum and txsum in order to see the devices on > > >> the other side of the two vlans trunked off em3. Unfortunately, the > > >> other sides were switches 100km and 500km away so I didnt have any > > >> tcpdump capabilities to diagnose the issue. I had already created > > >> one vlan off this NIC and all was fine. A few weeks later, I added a > > >> new one and I could no longer telnet into the remote switches from > > >> the local machine.... But, I could telnet into the switches from > > >> machines not on the problem box. Hence, it would appear to be a > > >> general TSO issue no ? I disabled tso on the nic (I didnt disable > > >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > > >> always ping the remote devices, but no tcp services. I then > > >> remembered this issue from before, so I tried disabling tso on the > > >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > > >> then telnet into the remote devices. > > >> > > >> This newly observed issue was from a buildworld on Mon Jun 14 > > >> 11:29:12 EDT 2010. > > >> > > >> I will try and recreate the issue locally again to see if I can > > >> trigger the problem on demand. Any thoughts on what it might be ? > > >> Perhaps an issue specific to certain em nics ? > > >> > > > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > > >I'm not sure whether you're seeing the same issue though. > > >I didn't have chance to try latest em(4) on stable/7. > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 20:00: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 7F6F01065697 for ; Tue, 17 Aug 2010 20:00:23 +0000 (UTC) (envelope-from pyunyh@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 4AA228FC0C for ; Tue, 17 Aug 2010 20:00:23 +0000 (UTC) Received: by pwj4 with SMTP id 4so3096022pwj.13 for ; Tue, 17 Aug 2010 13:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=L9kgUMAQXiWEIfQwH3tzTyxCxb6sfxfLM0/pU0vnQdA=; b=FmvqS0zW8T3iBDu5Z46xxbZqOA8mnMD7mSp6uN5k/2YjCFyrbdgnAwFzZdqY73NGtz jhbBVGlI6frC6NocdIaNfPpMCZcqwGHXrcuY73LfuThGjWMby917WNLcCaOuv7GjMWM4 escDliDZ+tlRvor0ke7Awotp4vZ/agGy8jmDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=VmSo+q7af0b5EibClEpyLoQG34Er85D2QjlP0m+DxNzQs9n99WYLtGGcFmyUIrhMSJ zUKQLWxclnfmNqkXdrMY6O/FEM/IofpnVyAzDXcZICmUk7jnXRsnwFPO4pppPyO4B39x 99rVEbzLPJkhGpBhHU+KoeylEi2GjjEtCX2Po= Received: by 10.142.204.17 with SMTP id b17mr6271563wfg.74.1282075222747; Tue, 17 Aug 2010 13:00:22 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n2sm10120981wfl.13.2010.08.17.13.00.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 13:00:21 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 13:00:20 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 13:00:20 -0700 To: Mike Tancsa Message-ID: <20100817200020.GE6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <201008171955.o7HJt67T087902@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008171955.o7HJt67T087902@lava.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:00:23 -0000 On Tue, Aug 17, 2010 at 03:55:12PM -0400, Mike Tancsa wrote: > At 02:52 PM 8/17/2010, Pyun YongHyeon wrote: > > >Here is updated patch for HEAD and stable/8. > >http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > >It seems to work as expected under my limited environments. If > > Thanks! The patch applies cleanly and all works as expected now! I am > no longer able to trigger the bug. I just use the stock unmodified > driver normally, so no multi queues > Glad to hear that. Thanks for testing! > # vmstat -i > interrupt total rate > irq256: em0 149 0 > irq257: em1 3 0 > irq259: em3 971 2 > irq260: ahci0 1520 3 > > > > em3: flags=8843 metric 0 mtu 1500 > options=219b > ether 00:15:17:xx:xx:xx > inet6 fe80::215:17ff:fexx:xxxx%em3 prefixlen 64 scopeid 0x4 > inet 192.168.xx.xx netmask 0xffffff00 broadcast 192.168.xx.xx > nd6 options=3 > media: Ethernet autoselect (100baseTX ) > status: active > > > em3@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > patch < em.csum_tso.20100817.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/dev/e1000/if_em.c > |=================================================================== > |--- sys/dev/e1000/if_em.c (revision 211398) > |+++ sys/dev/e1000/if_em.c (working copy) > -------------------------- > Patching file sys/dev/e1000/if_em.c using Plan A... > Hunk #1 succeeded at 237. > Hunk #2 succeeded at 1730. > Hunk #3 succeeded at 1759. > Hunk #4 succeeded at 1930. > Hunk #5 succeeded at 3148. > Hunk #6 succeeded at 3351. > Hunk #7 succeeded at 3533. > Hunk #8 succeeded at 3590. > Hunk #9 succeeded at 3603. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/dev/e1000/if_em.h > |=================================================================== > |--- sys/dev/e1000/if_em.h (revision 211398) > |+++ sys/dev/e1000/if_em.h (working copy) > -------------------------- > Patching file sys/dev/e1000/if_em.h using Plan A... > Hunk #1 succeeded at 284. > done > > ---Mike > > > >you're using multiple Tx queues with em(4) it would be better to > >disable Tx checksum offloading as driver always have to create a > >new checksum context for each frame. This will effectively disable > >pipelined Tx data DMA which in turn greatly slows down Tx > >performance for small sized frames. The reason driver have to > >create a new checksum context when it uses multiple Tx queues comes > >from hardware limitation. The controller tracks only for the last > >context descriptor that was written such that driver does not know > >the state of checksum context configured in other Tx queue. > >Hope this helps. > > > >> > >> > >> ---Mike > >> > >> > >> At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: > >> >On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: > >> >> Hi Jack, > >> >> Just a followup to the email below. I now saw what appears > >> >> to be the same problem on RELENG_8, but on a different nic and with > >> >> VLANs. So not sure if this is a general em problem, a problem > >> >> specific to some em NICs, or a TSO problem in general. The issue > >> >> seemed to be triggered when I added a new vlan based on > >> >> > >> >> em3@pci0:14:0:0: class=0x020000 card=0x109a15d9 > >> >> chip=0x109a8086 rev=0x00 hdr=0x00 > >> >> vendor = 'Intel Corporation' > >> >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > >> >> class = network > >> >> subclass = ethernet > >> >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 > >> >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > >> >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > >> >> > >> >> pci14: on pcib5 > >> >> em3: port 0x6000-0x601f > >> >> mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 > >> >> em3: Using MSI interrupt > >> >> em3: [FILTER] > >> >> em3: Ethernet address: 00:30:48:9f:eb:81 > >> >> > >> >> em3: flags=8943 > >> >> metric 0 mtu 1500 > >> >> options=2098 > >> >> ether 00:30:48:9f:eb:81 > >> >> inet 10.255.255.254 netmask 0xfffffffc broadcast > >10.255.255.255 > >> >> media: Ethernet autoselect (1000baseT ) > >> >> status: active > >> >> > >> >> I had to disable tso, rxcsum and txsum in order to see the devices on > >> >> the other side of the two vlans trunked off em3. Unfortunately, the > >> >> other sides were switches 100km and 500km away so I didnt have any > >> >> tcpdump capabilities to diagnose the issue. I had already created > >> >> one vlan off this NIC and all was fine. A few weeks later, I added a > >> >> new one and I could no longer telnet into the remote switches from > >> >> the local machine.... But, I could telnet into the switches from > >> >> machines not on the problem box. Hence, it would appear to be a > >> >> general TSO issue no ? I disabled tso on the nic (I didnt disable > >> >> net.inet.tcp.tso as I forgot about that).. Still nothing. I could > >> >> always ping the remote devices, but no tcp services. I then > >> >> remembered this issue from before, so I tried disabling tso on the > >> >> NIC. Still nothing. Then I disabled rxcsum and txcsum and I could > >> >> then telnet into the remote devices. > >> >> > >> >> This newly observed issue was from a buildworld on Mon Jun 14 > >> >> 11:29:12 EDT 2010. > >> >> > >> >> I will try and recreate the issue locally again to see if I can > >> >> trigger the problem on demand. Any thoughts on what it might be ? > >> >> Perhaps an issue specific to certain em nics ? > >> >> > >> > > >> >http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > >> >I'm not sure whether you're seeing the same issue though. > >> >I didn't have chance to try latest em(4) on stable/7. > >> > >> -------------------------------------------------------------------- > >> Mike Tancsa, tel +1 519 651 3400 > >> Sentex Communications, mike@sentex.net > >> Providing Internet since 1994 www.sentex.net > >> Cambridge, Ontario Canada www.sentex.net/mike > >> > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 20:27: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 E370710656A9 for ; Tue, 17 Aug 2010 20:27:44 +0000 (UTC) (envelope-from bfrancom@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 976588FC22 for ; Tue, 17 Aug 2010 20:27:44 +0000 (UTC) Received: by qwg5 with SMTP id 5so7469824qwg.13 for ; Tue, 17 Aug 2010 13:27: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:date:message-id :subject:from:to:content-type; bh=lGQXQ51A03OJQxnReClcyTmoKfMW1/+wHF6mD9eDuX8=; b=VYdRjabUcd3KF1IsBuX3L26uHQC7GDqtupp2zqsm9A8asrl6wj/dOy0zYRzN8cFiAD Br+K9PaQCk3zYprLrPhShcwaQSAaD+lrp/6FTzw4ErzbGKuNrNU3Hn5L/K4pBnqZSQBe U4RNeHr2AMKBeoVj97f3GrtcyzYnDDrK+35Qs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HXxxhreLN8kA+Wgc/qWu+WB6XBDt/0KWxX1z5/WZ8+epgNf82A4/UEOiUCs4zE9bma TStlfK3pVPBd7bGk/+AobF5oLD63zLibSkeHTSoL1deprNfCI5xKuBPxtCy9ZnlGYq8x BCEAe31uml7WNYxl/b/+1dOAOMJFwnqLNL7bk= MIME-Version: 1.0 Received: by 10.229.184.196 with SMTP id cl4mr5146444qcb.190.1282075075631; Tue, 17 Aug 2010 12:57:55 -0700 (PDT) Received: by 10.229.231.146 with HTTP; Tue, 17 Aug 2010 12:57:55 -0700 (PDT) Date: Tue, 17 Aug 2010 12:57:55 -0700 Message-ID: From: Benjamin Francom To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Soekris Sysinstall FTP & NFS Failure 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, 17 Aug 2010 20:27:45 -0000 Hello all, I have a Soekris net5501, and need some assistance with the installation [FreeBSD 8.1]. I've configured a PXE environment with TFTP, and NFS, and I can boot and get into sysinstall. After going through the initial configuration, slices, setting the IP address (DHCP), and proceeding with an FTP installation, it fails. It's like it cannot see the ftp site. I've also tried NFS with the same problem. lqqqqqqqqqqqqqqqqqqqqqqqqq Message qqqqqqqqqqqqqqqqqqqqqqqqqqk xInstallation completed with some errors. You may wish to x xscroll through the debugging messages on VTY1 with the x xscroll-lock feature. You can also choose "No" at the next x xprompt and go back into the installation menus to retry x xwhichever operations have failed. x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq(100%)qqu x [ OK ] x mqqqqqqqqqqqqqqqqqq[ Press enter or space ]qqqqqqqqqqqqqqqqqqj I have confirmed that FTP and NFS are both working. Since this is a headless serial connection, and I can't see what VTY1 says, what would the best way to diagnose this be? Is there a way to redirect the output somewhere? Thanks, -Ben -- Benjamin Francom Information Technology Executive http://www.benjaminfran.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 22:12: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 8A7C51065674 for ; Tue, 17 Aug 2010 22:12:36 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 684458FC15 for ; Tue, 17 Aug 2010 22:12:36 +0000 (UTC) Received: from unknown (client-86-31-88-103.midd.adsl.virginmedia.com [86.31.88.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 02AF85F65; Tue, 17 Aug 2010 21:52:58 +0000 (UTC) Date: Tue, 17 Aug 2010 22:53:01 +0100 From: Bruce Cran To: Benjamin Francom Message-ID: <20100817225301.00001f83@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Soekris Sysinstall FTP & NFS Failure 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, 17 Aug 2010 22:12:36 -0000 On Tue, 17 Aug 2010 12:57:55 -0700 Benjamin Francom wrote: > Hello all, > > I have a Soekris net5501, and need some assistance with the > installation [FreeBSD 8.1]. I've configured a PXE environment with > TFTP, and NFS, and I can boot and get into sysinstall. After going > through the initial configuration, slices, setting the IP address > (DHCP), and proceeding with an FTP installation, it fails. It's like > it cannot see the ftp site. I've also tried NFS with the same > problem. As far as I can tell, netinstall is broken on all recent releases. Using a static IP address seems to get further in that you don't get an immediate error, but instead you get returned to the list of FTP servers after a minute. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 22:17: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 63E121065670 for ; Tue, 17 Aug 2010 22:17:34 +0000 (UTC) (envelope-from amvandemore@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 1046F8FC13 for ; Tue, 17 Aug 2010 22:17:33 +0000 (UTC) Received: by qyk4 with SMTP id 4so1608879qyk.13 for ; Tue, 17 Aug 2010 15:17:33 -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=ymJW1pahlqqOprCSbebDwjh7IOMezccExHOUqWW4Akc=; b=Ck2PL34WjZtQ9OZ06t2lajW1+GM37QcTwOhiXi+8R7/fpoeD79xhmhCOg35nhA7R3a wlce+Abo3vIWrCD4WFaWjXI8aLKol8GbqDzOohh2SwdEn9IH76pkr1m2kqJhf1HghsqS PAJ1+6f4UB0nt2OTVejBENMtLsKE2JRqhDqfk= 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=FEZ95THkDkNeE/orwBRdq/M/SPA/gtXB5Y1JugYLMmLKWliivCvez2FieUiXmf6Ahl GTxW02uN4b+S7cTLyutALOycL6wcR9aGtiao3DAVwrTo9ExCTO1AlFIJstDTXmU3rhT9 +IUHSCdiZo6CKQ2Fq8S6npGE0KPxBTeAqJC98= MIME-Version: 1.0 Received: by 10.224.20.9 with SMTP id d9mr4718737qab.364.1282083453348; Tue, 17 Aug 2010 15:17:33 -0700 (PDT) Received: by 10.229.25.72 with HTTP; Tue, 17 Aug 2010 15:17:33 -0700 (PDT) In-Reply-To: <20100817225301.00001f83@unknown> References: <20100817225301.00001f83@unknown> Date: Tue, 17 Aug 2010 17:17:33 -0500 Message-ID: From: Adam Vande More To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Benjamin Francom Subject: Re: Soekris Sysinstall FTP & NFS Failure 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, 17 Aug 2010 22:17:34 -0000 On Tue, Aug 17, 2010 at 4:53 PM, Bruce Cran wrote: > As far as I can tell, netinstall is broken on all recent releases. > Using a static IP address seems to get further in that you don't get an > immediate error, but instead you get returned to the list of FTP > servers after a minute. > Works for me, perhaps you need to use passive ftp? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 23:04: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 CB87C10656A9 for ; Tue, 17 Aug 2010 23:04:46 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 47D888FC1C for ; Tue, 17 Aug 2010 23:04:45 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7HLFArt010123 for ; Wed, 18 Aug 2010 07:15:10 +1000 Received: from maxwell.mencon.com.au (c122-107-224-152.mckinn3.vic.optusnet.com.au [122.107.224.152]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7HLF7Bs022561; Wed, 18 Aug 2010 07:15:08 +1000 Received: from [203.2.73.72] (chief.mencon.com.au [203.2.73.72]) by maxwell.mencon.com.au (Postfix) with ESMTP id 5A72E5E20; Wed, 18 Aug 2010 07:15:07 +1000 (EST) Message-ID: <4C6AFBDB.90905@menhennitt.com.au> Date: Wed, 18 Aug 2010 07:15:07 +1000 From: Graham Menhennitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Benjamin Francom References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Soekris Sysinstall FTP & NFS Failure 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, 17 Aug 2010 23:04:46 -0000 On 18/08/10 05:57, Benjamin Francom wrote: > Hello all, > > I have a Soekris net5501, and need some assistance with the installation > [FreeBSD 8.1]. I've configured a PXE environment with TFTP, and NFS, and I > can boot and get into sysinstall. After going through the initial > configuration, slices, setting the IP address (DHCP), and proceeding with an > FTP installation, it fails. It's like it cannot see the ftp site. I've > > G'day Ben, It does work - I've done it a number of times. I presume that you've seen my guide at http://menhennitt.com.au/wordpress/2009/07/05/installing-freebsd-on-a-soekris-net5501-using-pxe-and-dnsmasq#more-14 and Jeremy's at http://jdc.parodius.com/freebsd/pxeboot_serial_install_8.html Also, there's a Soekris mailing list that often has stuff that's more Soekris specific - http://lists.soekris.com/mailman/listinfo/soekris-tech I seem to remember having the same problem that you're having at one stage, but unfortunately, I can't remember the solution. Hope this helps, Graham From owner-freebsd-stable@FreeBSD.ORG Wed Aug 18 02: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 96FE81065672 for ; Wed, 18 Aug 2010 02:27:41 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2FB8FC16 for ; Wed, 18 Aug 2010 02:27:40 +0000 (UTC) Received: by yxe42 with SMTP id 42so4320yxe.13 for ; Tue, 17 Aug 2010 19:27:40 -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:content-type:content-transfer-encoding; bh=eVa40gS3b8h2y55szKO9eZ2YwuaGlaunIsdVDG5WSJw=; b=q2K+/w7e45RjuOFEpnKKV74QnLa/Mi825tZ06vu5GWsNiGkoDQKYK+6INlQIHb0/tj zHeaCIHJhE5vVM4CL1m4r5L7hUAKECgi8ZZjjQWkql7PJJzygXmUmFOHWa0x723jqHwz XxF+RTQ5WF5aeO7z/6HIhOrhoKKMwZfu+SkrI= 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:content-type :content-transfer-encoding; b=C4C0fOs4FE1NBWopdAS5UsyeOjmsBEMDKkIs/7akIhOyzgW54uHlpMojdseCv6Jzv/ Kcqjg4+DMQrDW9uB4CTzZclHs27vvNEisdNP5zkJy9kYinl4LtcXYcNTpgfqNGr1VUsB 3FNTOtAYOwf5qmALjtAmA3xJjk4K6LIYlXLa4= Received: by 10.151.132.15 with SMTP id j15mr7900711ybn.351.1282098460102; Tue, 17 Aug 2010 19:27:40 -0700 (PDT) Received: from centel.dataix.local ([99.190.82.4]) by mx.google.com with ESMTPS id q1sm724669ybk.8.2010.08.17.19.27.38 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 19:27:39 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C6B4519.1010601@DataIX.net> Date: Tue, 17 Aug 2010 22:27:37 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: FOSS Deluxe References: <20100817120025.9034510657C2@hub.freebsd.org> <4C6AA647.50906@gmail.com> In-Reply-To: <4C6AA647.50906@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: freebsd-stable Digest, Vol 370, Issue 2 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, 18 Aug 2010 02:27:41 -0000 What ? You must have missed the following suggestion/request: Might also help if it was not top-posted. ;) When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-stable digest..." On 08/17/2010 11:09, FOSS Deluxe wrote: > Well in normal use user applications are the ones that put the load on > the CPU. The kernel is pretty much lightweight in size and work when non > kernel intensive tasks are at hand (like gigabit links in the networks, > etc). The good news is that the kernel will have its own core to play with. > > On 08/17/2010 08:00 AM, freebsd-stable-request@freebsd.org wrote: >> Send freebsd-stable mailing list submissions to >> freebsd-stable@freebsd.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> or, via email, send a message with subject or body 'help' to >> freebsd-stable-request@freebsd.org >> >> You can reach the person managing the list at >> freebsd-stable-owner@freebsd.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of freebsd-stable digest..." >> >> >> Today's Topics: >> >> 1. Re: Inconsistent IO performance (Ivan Voras) >> 2. Re: Inconsistent IO performance (Kevin Oberman) >> 3. STABLE kernel panic: privileged instruction fault (Alexey Tarasov) >> 4. Re: Inconsistent IO performance (Jeremy Chadwick) >> 5. Re: Inconsistent IO performance (Jeremy Chadwick) >> 6. Re: STABLE kernel panic: privileged instruction fault >> (Kostik Belousov) >> 7. Re: STABLE kernel panic: privileged instruction fault >> (Alexey Tarasov) >> 8. Re: STABLE kernel panic: privileged instruction fault >> (Kostik Belousov) >> 9. Re: STABLE kernel panic: privileged instruction fault >> (Alexey Tarasov) >> 10. Re: STABLE kernel panic: privileged instruction fault >> (Kostik Belousov) >> 11. Re: STABLE kernel panic: privileged instruction fault >> (Alexey Tarasov) >> 12. Re: RELENG_7 em problems (and RELENG_8) (Mike Tancsa) >> 13. Performance AMD Phenom II X6 1090T (Vladislav V. Prodan) >> 14. Crash in dummynet. (Pawel Tyll) >> 15. Re: Crash in dummynet. (Luigi Rizzo) -- jhell,v From owner-freebsd-stable@FreeBSD.ORG Wed Aug 18 10:52: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 7398010656A6; Wed, 18 Aug 2010 10:52:04 +0000 (UTC) (envelope-from pluknet@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 116E28FC15; Wed, 18 Aug 2010 10:52:03 +0000 (UTC) Received: by qyk4 with SMTP id 4so478082qyk.13 for ; Wed, 18 Aug 2010 03:52:03 -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=+u5QtstdWV2lICYoEwZkBuA72ZcLbPJLNKQ6yFXVcy0=; b=FJ41GXoEyc7aIK1BeYwgC4ltz5djbQ/b6KaVPfgP9nauhazyE0WWO+jTEeduazlCOC lzL7z73mIEezRjIHn4/8E5OXQivgkAK7K7qgM2+Qhxv71SIlitbZZcInlajfvS9TjZ96 xQJe7gXwNOE76qg/HJ4rjLQMS+BcaMHYxJhWI= 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=N2mtW5QTVZHqdyye3b7i3MSae3dvikijr919r1+89jBpm0db7c/tMFBRHqgj3WWN5D CsZQ83jkjBpYTk1nd9N9CfX9s1UKomIvQCPA5FkI8nBXYLPbFuYzxttOD0UT9RVVaoGq RRZJLtWnw81+Q7m7tcQi6KvsWLSYZSTeIwt+8= MIME-Version: 1.0 Received: by 10.229.11.8 with SMTP id r8mr475404qcr.236.1282128722633; Wed, 18 Aug 2010 03:52:02 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Wed, 18 Aug 2010 03:52:02 -0700 (PDT) In-Reply-To: References: <201006301726.o5UHQl7n011935@svn.freebsd.org> <4C2BBC1F.6020405@elischer.org> Date: Wed, 18 Aug 2010 14:52:02 +0400 Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jack F Vogel , freebsd-stable Subject: Re: svn commit: r209611 - head/sys/dev/e1000 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, 18 Aug 2010 10:52:04 -0000 On 17 August 2010 20:27, Jack Vogel wrote: > Cool the first person to actually try and use it :) > > Yes, there's one key thing you have to do right now that's not > documented, because of the simplistic PCI structure the guest > has the kernel blacklists it from using MSIX. SO, what you need > to do is set the honor_blacklist (that's not the complete string, > use sysctl -a |grep blacklist to find it) and set that to 0. It needs > to be set at boot. > > That should get you running. > > Jack > Nice, thanks! It works! > > On Tue, Aug 17, 2010 at 8:18 AM, pluknet wrote: >> >> Hi, Jack. >> >> I set up qemu-kvm on openSUSE 11.3 >> =A0with 82576 PCI device as you described. >> >> Guest fails to attach with: >> igb0: mem >> 0xf2060000-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 >> igb0: Unable to allocate bus resource: interrupt >> device_attach: igb0 attach returned 6 >> >> igb0@pci0:0:5:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0xa03c8086 chip= =3D0x10ca8086 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> =A0 =A0cap 11[40] =3D MSI-X supports 3 messages in map 0x1c >> >> Did =A0I missed something? >> --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Aug 18 12:24: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 632D51065674 for ; Wed, 18 Aug 2010 12:24:26 +0000 (UTC) (envelope-from drsweetlips@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1A22F8FC1C for ; Wed, 18 Aug 2010 12:24:25 +0000 (UTC) Received: by gwj23 with SMTP id 23so197774gwj.13 for ; Wed, 18 Aug 2010 05:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DEa39KEd1WaDddTN9sNNDKBkUsku155PS4VioLHmf18=; b=p8mu1AdCQF6gB0K1sBh6/jS++mLxZLM+cgiEN2bBS4uwvi2zLx1RUiHVo/fiWc5hdd PhcPIq00UDBzUGzkeB9iosfqS+DWngDcs3a/klWpniufDcSwZKPc+g3GFnpdFMFSSatw e+Bk8GfTvvrwAui0qGlEq/aKDDj1iQaR8vBjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Yet3JUIUJ/95rmDS82Srtn2P3L5kvGmyO0+VF4No5vsnd0LskJUpz1e+2HNifK1XBB iBbfBnNelo2KkB8KhR521s7FC8PurBCZZr5EhegPjUJWY7r7X7ZlIL2dhUDhD0yDiRbH 4+jngza/x4oYZWn3ZKOd75azJk49vztRC7UJY= Received: by 10.100.177.1 with SMTP id z1mr9295394ane.187.1282134265289; Wed, 18 Aug 2010 05:24:25 -0700 (PDT) Received: from [192.168.1.4] (rrcs-24-227-59-150.se.biz.rr.com [24.227.59.150]) by mx.google.com with ESMTPS id w6sm380294anb.3.2010.08.18.05.24.24 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 05:24:24 -0700 (PDT) Message-ID: <4C6BD0F7.5090906@gmail.com> Date: Wed, 18 Aug 2010 08:24:23 -0400 From: FOSS Deluxe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: jhell References: <20100817120025.9034510657C2@hub.freebsd.org> <4C6AA647.50906@gmail.com> <4C6B4519.1010601@DataIX.net> In-Reply-To: <4C6B4519.1010601@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Performance AMD Phenom II X6 1090T 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, 18 Aug 2010 12:24:26 -0000 Yes, I agree. That was due to human error and me not paying enough attention to what I was doing. Pretty embarrassing :) From owner-freebsd-stable@FreeBSD.ORG Wed Aug 18 17:52:04 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 AB5351065672; Wed, 18 Aug 2010 17:52:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 68E528FC1F; Wed, 18 Aug 2010 17:52:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7IHq3AN053155; Wed, 18 Aug 2010 13:52:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7IHpXcB051998; Wed, 18 Aug 2010 17:51:33 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Aug 2010 17:51:33 GMT Message-Id: <201008181751.o7IHpXcB051998@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:52:04 -0000 TB --- 2010-08-18 17:13:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 17:13:51 - starting RELENG_8_1 tinderbox run for powerpc/powerpc TB --- 2010-08-18 17:13:51 - cleaning the object tree TB --- 2010-08-18 17:14:31 - cvsupping the source tree TB --- 2010-08-18 17:14:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/powerpc/powerpc/supfile TB --- 2010-08-18 17:50:48 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-08-18 17:50:48 - ERROR: unable to cvsup the source tree TB --- 2010-08-18 17:50:48 - 1.03 user 26.21 system 2216.83 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Wed Aug 18 18:36:09 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 ED4DB1065693; Wed, 18 Aug 2010 18:36:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A76CC8FC08; Wed, 18 Aug 2010 18:36:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7IIa82P079407; Wed, 18 Aug 2010 14:36:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7II89Xh097952; Wed, 18 Aug 2010 18:08:09 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Aug 2010 18:08:09 GMT Message-Id: <201008181808.o7II89Xh097952@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:36:10 -0000 TB --- 2010-08-18 17:29:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 17:29:31 - starting RELENG_8_1 tinderbox run for sparc64/sparc64 TB --- 2010-08-18 17:29:31 - cleaning the object tree TB --- 2010-08-18 17:30:17 - cvsupping the source tree TB --- 2010-08-18 17:30:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/sparc64/sparc64/supfile TB --- 2010-08-18 18:07:24 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-08-18 18:07:24 - ERROR: unable to cvsup the source tree TB --- 2010-08-18 18:07:24 - 0.87 user 29.69 system 2273.53 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 09:45: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 3E871106566B; Thu, 19 Aug 2010 09:45:15 +0000 (UTC) (envelope-from pluknet@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 CF5368FC13; Thu, 19 Aug 2010 09:45:14 +0000 (UTC) Received: by qyk4 with SMTP id 4so1822736qyk.13 for ; Thu, 19 Aug 2010 02:45: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:cc:content-type; bh=e/36LS1DPOh3+e/nCC+EocH+njFg8hb/gng+uAs/moY=; b=AQg3lxt1ebZjT6H/j4VipRy9D6xOHo8f1FTmwxl0t+lQPbeQ5z3FuO1butcTPOItg7 yiIsx6bMMRFMlsblAJxovK87RG13K5nQCS5xARIjyy5QBcWZp97u32d9KXu8rMIx7RIx UVjYuxLjkfVi20e06RV6bk/BjksBVcMSrM45c= 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=Vs/XWQlNBO150I7p/2oz2/9WJpM20B1sNMps3U/q3oXfYa7oHosS6+D8YZLi3n1ju3 uUoQwNwtsonB62jJgp1m3d0SQVvMz076cMbDL3g5J9+AMOEX5Q9ZDQxtcYOxxCgLW9mb sYb1avPuf3XPpWKBurrqXjmBmEZhfNZ4OzFkI= MIME-Version: 1.0 Received: by 10.224.28.144 with SMTP id m16mr6305900qac.357.1282211113873; Thu, 19 Aug 2010 02:45:13 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 02:45:13 -0700 (PDT) In-Reply-To: References: <201006301726.o5UHQl7n011935@svn.freebsd.org> <4C2BBC1F.6020405@elischer.org> Date: Thu, 19 Aug 2010 13:45:13 +0400 Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , freebsd-stable Subject: Re: svn commit: r209611 - head/sys/dev/e1000 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, 19 Aug 2010 09:45:15 -0000 On 18 August 2010 14:52, pluknet wrote: > On 17 August 2010 20:27, Jack Vogel wrote: >> Cool the first person to actually try and use it :) >> >> Yes, there's one key thing you have to do right now that's not >> documented, because of the simplistic PCI structure the guest >> has the kernel blacklists it from using MSIX. SO, what you need >> to do is set the honor_blacklist (that's not the complete string, >> use sysctl -a |grep blacklist to find it) and set that to 0. It needs >> to be set at boot. >> >> That should get you running. >> >> Jack >> > > Nice, thanks! > > It works! > By the way, Sometimes after boot I have to kldreload if_igb.ko several times until watchdog go to sleep, so traffic starts flowing. igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 1, hw tdt = 1 igb0: TX(0) desc avail = 1023,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 6, hw tdt = 6 igb0: TX(0) desc avail = 1018,Next TX to Clean = 0 igb0: detached igb0: mem 0xf2020000-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP stray irq0 stray irq0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 stray irq0 stray irq0 too many stray irq 0's: not logging anymore igb0: promiscuous mode enabled igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 28, hw tdt = 28 igb0: TX(0) desc avail = 996,Next TX to Clean = 0 igb0: promiscuous mode disabled igb0: detached igb0: mem 0xf2020000-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.1 dev.igb.0.%driver: igb dev.igb.0.%location: slot=4 function=0 handle=\_SB_.PCI0.S4__ dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10ca subvendor=0x8086 subdevice=0xa03c class=0x020000 dev.igb.0.%parent: pci0 dev.igb.0.nvm: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.device_control: 0 dev.igb.0.rx_control: 0 dev.igb.0.interrupt_mask: 0 dev.igb.0.extended_int_mask: 0 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 58976 dev.igb.0.fc_low_water: 58960 dev.igb.0.queue0.txd_head: 424 dev.igb.0.queue0.txd_tail: 424 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 186 dev.igb.0.queue0.rxd_head: 758 dev.igb.0.queue0.rxd_tail: 758 dev.igb.0.queue0.rx_packets: 4855 dev.igb.0.queue0.rx_bytes: 316295 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.txd_head: 0 dev.igb.0.queue1.txd_tail: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 0 dev.igb.0.queue1.rxd_head: 0 dev.igb.0.queue1.rxd_tail: 1023 dev.igb.0.queue1.rx_packets: 0 dev.igb.0.queue1.rx_bytes: 0 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.good_pkts_recvd: 0 dev.igb.0.mac_stats.good_pkts_txd: 0 dev.igb.0.mac_stats.good_octets_recvd: 0 dev.igb.0.mac_stats.good_octest_txd: 0 dev.igb.0.mac_stats.mcast_pkts_recvd: 0 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 13:00: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 EC22410657BA for ; Thu, 19 Aug 2010 13:00:24 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id A57208FC3C for ; Thu, 19 Aug 2010 13:00:24 +0000 (UTC) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Om4Cg-000EAX-PN; Thu, 19 Aug 2010 14:26:42 +0200 From: Heinrich Rebehn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Aug 2010 14:33:11 +0200 To: freebsd-stable@freebsd.org Message-Id: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: ROOT MOUNT ERROR when booting from zfs 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, 19 Aug 2010 13:00:25 -0000 Hi all, i am getting the error message in $subject when trying to boot from zfs. I followed the instructions found in: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror Before posting all config details and asking what i might have done = wrong: Is there any possibility to get a more detailed error message = than just ROOT MOUNT ERROR? e.g. zpool not found | zpool could not be = imported | illegal mount options | etc The kernel reports that it is trying to mount from zfs:zroot, which is = correct. The zfs kernel module is being loaded. -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax : -3341 From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 16:24: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 A25F71065673 for ; Thu, 19 Aug 2010 16:24:06 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE018FC13 for ; Thu, 19 Aug 2010 16:24:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0L7E00GE9O43FW50@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 19 Aug 2010 17:24:03 +0200 (CEST) Received: from kg-v2.kg4.no ([80.203.92.226]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0L7E00NB0O422LA1@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 19 Aug 2010 17:24:03 +0200 (CEST) Date: Thu, 19 Aug 2010 17:24:02 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100819172402.a171387c.torfinn.ingolfsen@broadpark.no> In-reply-to: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> References: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ROOT MOUNT ERROR when booting from zfs 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, 19 Aug 2010 16:24:06 -0000 On Thu, 19 Aug 2010 14:33:11 +0200 Heinrich Rebehn wrote: > Hi all, > > i am getting the error message in $subject when trying to boot from zfs. > I followed the instructions found in: > > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror > > Before posting all config details and asking what i might have done wrong: Is there any possibility to get a more detailed error message than just ROOT MOUNT ERROR? e.g. zpool not found | zpool could not be imported | illegal mount options | etc You have tried verbose boot? If not, try it and see if you get more information. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 16:39: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 6AD2E1065841; Thu, 19 Aug 2010 16:39:17 +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 848D48FC20; Thu, 19 Aug 2010 16:39:16 +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 TAA12188; Thu, 19 Aug 2010 19:39:13 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6D5E31.9000701@icyb.net.ua> Date: Thu, 19 Aug 2010 19:39:13 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: pluknet References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, 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: Thu, 19 Aug 2010 16:39:17 -0000 on 10/08/2010 19:55 pluknet said the following: > On 16 July 2010 19:47, Jung-uk Kim wrote: >> 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 >> > > > Hi. > > Just checked on Xen HVM with 3 cores. > 1) 8.1 unmodified: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 1 package(s) x 3 core(s) > > 2) 8.1 + patch > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. Can you debug, e.g. with printfs, what exactly goes wrong? I wonder if in this case code follows some unusual/unexpected path. BTW, could you please also provide CPU name/model/features as detected by the kernel? Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 16:55: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 945021065672; Thu, 19 Aug 2010 16:55:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EA2C88FC08; Thu, 19 Aug 2010 16:55:58 +0000 (UTC) Received: by ewy26 with SMTP id 26so1664266ewy.13 for ; Thu, 19 Aug 2010 09:55:57 -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=NCz2SAb2+/+eatDvxMJUAtoahMdhNdrxS+M9yUfcgsA=; b=ciiqdJ08DU+9ZN6d1txdX4Jn7fRGxcTyb54trwc4OZlhRkF3f1ErsLP2ZjVLQSBnPY 5emZY2gJqQJRKNQoqgOq5fbLqdo8JIeahABSFbFTIjjXXQwPC9YWk/5CU1irDLy52boq 2g8hAEyuepflRTmmv64FUYO59ZbcL8VI8FSxY= 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=ZIk2/30qpNVYuQULIYIRa1rOO6vqAFoSsAZtTFo8P3G0HAINTHKhOCCObpnef1vEJl B41gIeTI20YBYw2fy6yD2Z1b3dNOB3ZWRpJzdaA8uvM5Osh8WE9bxfpHx8pr7Q+Jzvwv znQ0t7px4UW/914UJvEM6t7a8XUAPnT/9aguQ= MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr113675wei.13.1282236957668; Thu, 19 Aug 2010 09:55:57 -0700 (PDT) Received: by 10.216.48.6 with HTTP; Thu, 19 Aug 2010 09:55:57 -0700 (PDT) In-Reply-To: References: <201006301726.o5UHQl7n011935@svn.freebsd.org> <4C2BBC1F.6020405@elischer.org> Date: Thu, 19 Aug 2010 09:55:57 -0700 Message-ID: From: Jack Vogel To: pluknet Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , freebsd-stable Subject: Re: svn commit: r209611 - head/sys/dev/e1000 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, 19 Aug 2010 16:55:59 -0000 On Thu, Aug 19, 2010 at 2:45 AM, pluknet wrote: > > By the way, > > Sometimes after boot I have to kldreload if_igb.ko several > times until watchdog go to sleep, so traffic starts flowing. > Hmmm, the intention is that the VF always be single queue, but I see the code I used to limit it is broken, so you are getting two queues. For now near the top of if_igb.c set igb_num_queues = 1; I believe that will get rid of the watchdogs. Jack From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 16:56: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 A471810656D1; Thu, 19 Aug 2010 16:56:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 541328FC1D; Thu, 19 Aug 2010 16:56:45 +0000 (UTC) Received: by qyk8 with SMTP id 8so1613771qyk.13 for ; Thu, 19 Aug 2010 09:56:44 -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=Ed+8A2n3IQ9Hiyq1NdTbmRoDO4hVTQSKgH3Fo1ys7M0=; b=DwhqcgXMqhlWhcJ+4/veuFnRhMm2+K6SD6c8O04SB/NhgogaTGj367ezPDjMmAj1V7 Z6QnwPWBYk77GHQm25IKYB8aXZljXlXSEeJjPKpQkmKnN1VMOXCboyPf2JEluM3zHlFH Pkxz5SoZH9/UalPGOObGXw4y/LjcZ6OaT911o= 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=OqqwS8+0YXzzXY7yHbsxFRXOB4Bh2hb+tLz91VodyC4MLtWaMpSPAjDloX4euAMYUW fRUGfBwLACZnWk3r/L0bDi3RRlY8I1UV6rnOeM9bljQuavjG0OmRI4qFsUn0MfYV+sTY E/LfsKLZt+PZ+Enwvyj8AbHCmvFb+A8E0TI70= MIME-Version: 1.0 Received: by 10.224.62.217 with SMTP id y25mr76863qah.193.1282237004637; Thu, 19 Aug 2010 09:56:44 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 09:56:43 -0700 (PDT) In-Reply-To: <4C6D5E31.9000701@icyb.net.ua> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> Date: Thu, 19 Aug 2010 20:56:43 +0400 Message-ID: From: pluknet To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, 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: Thu, 19 Aug 2010 16:56:48 -0000 On 19 August 2010 20:39, Andriy Gapon wrote: > on 10/08/2010 19:55 pluknet said the following: >> On 16 July 2010 19:47, Jung-uk Kim wrote: >>> 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 >>> >> >> >> Hi. >> >> Just checked on Xen HVM with 3 cores. >> 1) 8.1 unmodified: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 1 package(s) x 3 core(s) >> >> 2) 8.1 + patch >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> WARNING: Non-uniform processors. >> WARNING: Using suboptimal topology. > > Can you debug, e.g. with printfs, what exactly goes wrong? > I wonder if in this case code follows some unusual/unexpected path. Sorry, I'm a bit busy right now. I hope to debug this somewhere in the next week. > BTW, could you please also provide CPU name/model/features as detected by the kernel? Sure. CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0x1781fbbf Features2=0x80982201> TSC: P-state invariant real memory = 4194304000 (4000 MB) avail memory = 3932786688 (3750 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 2 cpu2 (AP/HT): APIC ID: 4 Just a thought. # HTT might somehow correlate with current maxcpus limit (32). > > Thanks! -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 17:26:17 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 23BE6106566B; Thu, 19 Aug 2010 17:26:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: pluknet Date: Thu, 19 Aug 2010 13:26:08 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C6D5E31.9000701@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008191326.09822.jkim@FreeBSD.org> 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, 19 Aug 2010 17:26:17 -0000 On Thursday 19 August 2010 12:56 pm, pluknet wrote: > On 19 August 2010 20:39, Andriy Gapon wrote: > > on 10/08/2010 19:55 pluknet said the following: > >> On 16 July 2010 19:47, Jung-uk Kim wrote: > >>> 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 > >> > >> Hi. > >> > >> Just checked on Xen HVM with 3 cores. > >> 1) 8.1 unmodified: > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 1 package(s) x 3 core(s) > >> > >> 2) 8.1 + patch > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >> WARNING: Non-uniform processors. > >> WARNING: Using suboptimal topology. > > > > Can you debug, e.g. with printfs, what exactly goes wrong? > > I wonder if in this case code follows some unusual/unexpected > > path. > > Sorry, I'm a bit busy right now. > I hope to debug this somewhere in the next week. > > > BTW, could you please also provide CPU name/model/features as > > detected by the kernel? > > Sure. > CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz > 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 > Model = 1a Stepping = 5 > Features=0x1781fbbfE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x80982201> > TSC: P-state invariant > real memory = 4194304000 (4000 MB) > avail memory = 3932786688 (3750 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 2 > cpu2 (AP/HT): APIC ID: 4 > > Just a thought. > # HTT might somehow correlate with current maxcpus limit (32). One thing I am not sure is whether those CPUID instructions are executed on *real* CPUs or translated in HVM. On top of that, I am not even sure they will be executed on *correct* cores. I bet they won't. If that's the case, we should add exception for virtualized environment as we did for default HZ. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 17:27: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 3993C10656A8; Thu, 19 Aug 2010 17:27:26 +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 5359C8FC1A; Thu, 19 Aug 2010 17:27:24 +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 UAA12970; Thu, 19 Aug 2010 20:27:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6D697A.5050302@icyb.net.ua> Date: Thu, 19 Aug 2010 20:27:22 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: pluknet References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, 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: Thu, 19 Aug 2010 17:27:26 -0000 on 19/08/2010 19:56 pluknet said the following: > CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 > Features=0x1781fbbf > Features2=0x80982201> > TSC: P-state invariant > real memory = 4194304000 (4000 MB) > avail memory = 3932786688 (3750 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 2 > cpu2 (AP/HT): APIC ID: 4 Thanks! BTW, what does Intel's code report? Jung-uk's convenience script: http://people.freebsd.org/~jkim/cpu_topology-12212009.sh -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 17:46: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 A23C61065675 for ; Thu, 19 Aug 2010 17:46:27 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id 627FF8FC25 for ; Thu, 19 Aug 2010 17:46:27 +0000 (UTC) Received: from ant2005.ant.uni-bremen.de ([134.102.176.250] helo=[10.8.1.9]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Om95m-000FUZ-H3; Thu, 19 Aug 2010 19:39:54 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Heinrich Rebehn In-Reply-To: <20100819172402.a171387c.torfinn.ingolfsen@broadpark.no> Date: Thu, 19 Aug 2010 19:46:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> <20100819172402.a171387c.torfinn.ingolfsen@broadpark.no> To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.1081) Cc: Heinrich Rebehn , freebsd-stable@freebsd.org Subject: Re: ROOT MOUNT ERROR when booting from zfs 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, 19 Aug 2010 17:46:27 -0000 On 19.08.2010, at 17:24, Torfinn Ingolfsen wrote: > On Thu, 19 Aug 2010 14:33:11 +0200 > Heinrich Rebehn wrote: >=20 >> Hi all, >>=20 >> i am getting the error message in $subject when trying to boot from = zfs. >> I followed the instructions found in: >>=20 >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror >>=20 >> Before posting all config details and asking what i might have done = wrong: Is there any possibility to get a more detailed error message = than just ROOT MOUNT ERROR? e.g. zpool not found | zpool could not be = imported | illegal mount options | etc >=20 > You have tried verbose boot? > If not, try it and see if you get more information. > --=20 > Regards, > Torfinn Ingolfsen Yes, i have tried. I did get a flurry of information, but nothing = related to the kernel not being able to mount the root fs. In the meanwhile, i have redone the installation and for some reason it = is working now. Probably the pool cache was missing.. :-) Now i have another problem: The root fs on on a 4-disk zfs mirror. I am testing under VMware fusion = using virtual scsi disks. In order to test redundancy, i removed the = first disk and booting failed. The loader reports: error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot If i remove any other of the 3 disks instead, booting works fine. Is the = pool's configuration only stored on the first disk? Do i have to = replicate it to the other disks by hand? -Heinrich From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 17:50: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 0F1BA1065672 for ; Thu, 19 Aug 2010 17:50:51 +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 583F68FC20 for ; Thu, 19 Aug 2010 17:50:49 +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 UAA13273; Thu, 19 Aug 2010 20:50:36 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6D6EEC.8000709@icyb.net.ua> Date: Thu, 19 Aug 2010 20:50:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Heinrich Rebehn References: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> <20100819172402.a171387c.torfinn.ingolfsen@broadpark.no> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: ROOT MOUNT ERROR when booting from zfs 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, 19 Aug 2010 17:50:51 -0000 on 19/08/2010 20:46 Heinrich Rebehn said the following: > Now i have another problem: > > The root fs on on a 4-disk zfs mirror. I am testing under VMware fusion using > virtual scsi disks. In order to test redundancy, i removed the first disk and > booting failed. The loader reports: > > error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba 32 error > 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot > > If i remove any other of the 3 disks instead, booting works fine. Is the pool's > configuration only stored on the first disk? Do i have to replicate it to the > other disks by hand? Fix for this has been recently MFC-ed to stable/8. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 18:04: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 E9CCC1065675 for ; Thu, 19 Aug 2010 18:04:23 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id A843B8FC14 for ; Thu, 19 Aug 2010 18:04:23 +0000 (UTC) Received: from ant2005.ant.uni-bremen.de ([134.102.176.250] helo=[10.8.1.9]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Om9N8-000FaP-Fh; Thu, 19 Aug 2010 19:57:50 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Heinrich Rebehn In-Reply-To: <4C6D6EEC.8000709@icyb.net.ua> Date: Thu, 19 Aug 2010 20:04:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B106B44-1353-426D-BBD8-821C1F88C5F8@ant.uni-bremen.de> <20100819172402.a171387c.torfinn.ingolfsen@broadpark.no> <4C6D6EEC.8000709@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: Heinrich Rebehn , freebsd-stable@freebsd.org Subject: Re: ROOT MOUNT ERROR when booting from zfs 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, 19 Aug 2010 18:04:24 -0000 On 19.08.2010, at 19:50, Andriy Gapon wrote: > on 19/08/2010 20:46 Heinrich Rebehn said the following: >> Now i have another problem: >>=20 >> The root fs on on a 4-disk zfs mirror. I am testing under VMware = fusion using >> virtual scsi disks. In order to test redundancy, i removed the first = disk and >> booting failed. The loader reports: >>=20 >> error 1 lba 32 error 1 lba 1 error 1 lba 32 error 1 lba 1 error 1 lba = 32 error >> 1 lba 1 error 1 lba 32 error 1 lba 1 No ZFS pools located, can't boot >>=20 >> If i remove any other of the 3 disks instead, booting works fine. Is = the pool's >> configuration only stored on the first disk? Do i have to replicate = it to the >> other disks by hand? >=20 > Fix for this has been recently MFC-ed to stable/8. >=20 > --=20 > Andriy Gapon Great! Thanks to all FreeBSD developers! --Heinrich From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 19:16: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 43F3A1065674; Thu, 19 Aug 2010 19:16:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CEE808FC1A; Thu, 19 Aug 2010 19:15:59 +0000 (UTC) Received: by qyk8 with SMTP id 8so1778237qyk.13 for ; Thu, 19 Aug 2010 12:15:59 -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=YH77jJglMVEzXos/RoPo/yPHu90se93AD51Qice/zaE=; b=ZMfUXSt8XGyGXMtB6iaw9pxCqMPSMMaDvXLFoN5b8Fom2BH0AGz5tgQHLgO1hNMXBH ALXV4VtgY7+v5qsKxQKK5py86F2n9vUwTNcixumjEbjmt4j9hZSyBFHHeaVRXj6kPoV0 kTAHAvLVdDWjLo4HAtccK4n/BqO328whT+7zs= 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=Wa7MYQ6GWcBFnRA4n2/boADDWuWnoVM1l7LFWg2d32r88S7q0VJLyHvFLCNd8Ymtki HA99mWitGfmGt0pSKC6aWOk2QrHF+uqu/CukWv0w9sGVaeIewbrmLzgMn/sC/lnDjPD+ kmuZSn2zaTC1fEyM/R7kwywMkMsZ94La4KPKs= MIME-Version: 1.0 Received: by 10.229.190.69 with SMTP id dh5mr251358qcb.95.1282245359010; Thu, 19 Aug 2010 12:15:59 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 12:15:58 -0700 (PDT) In-Reply-To: <4C6D697A.5050302@icyb.net.ua> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> <4C6D697A.5050302@icyb.net.ua> Date: Thu, 19 Aug 2010 23:15:58 +0400 Message-ID: From: pluknet To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, 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: Thu, 19 Aug 2010 19:16:00 -0000 On 19 August 2010 21:27, Andriy Gapon wrote: > on 19/08/2010 19:56 pluknet said the following: >> CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 E5520 =A0@ 2.27GHz (2763.1= 2-MHz 686-class CPU) >> =A0 Origin =3D "GenuineIntel" =A0Id =3D 0x106a5 =A0Family =3D 6 =A0Model= =3D 1a =A0Stepping =3D 5 >> =A0 Features=3D0x1781fbbf >> =A0 Features2=3D0x80982201> >> =A0 TSC: P-state invariant >> real memory =A0=3D 4194304000 (4000 MB) >> avail memory =3D 3932786688 (3750 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> =A0cpu0 (BSP): APIC ID: =A00 >> =A0cpu1 (AP/HT): APIC ID: =A02 >> =A0cpu2 (AP/HT): APIC ID: =A04 > > Thanks! > BTW, what does Intel's code report? > Jung-uk's convenience script: > http://people.freebsd.org/~jkim/cpu_topology-12212009.sh > Software visible enumeration in the system: Number of logical processors visible to the OS: 3 Number of logical processors visible to this process: 3 Number of processor cores visible to this process: 3 Number of physical packages visible to this process: 1 Hierarchical counts by levels of processor topology: # of cores in package 0 visible to this process: 3 . 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 Pkg-aggregated: P:0 --> 7 APIC ID listings from affinity masks OS cpu 0, Affinity mask 01 - apic id 0 OS cpu 1, Affinity mask 02 - apic id 2 OS cpu 2, Affinity mask 04 - apic id 4 Package 0 Cache and Thread details L1D is Level 1 Data cache, size(KBytes)=3D 32, Cores/cache=3D 1, Caches/pa= ckage=3D 3 L1I is Level 1 Instruction cache, size(KBytes)=3D 32, Cores/cache=3D 1, Caches/package=3D 3 L2 is Level 2 Unified cache, size(KBytes)=3D 256, Cores/cache=3D 1, Caches/package=3D 3 L3 is Level 3 Unified cache, size(KBytes)=3D 8192, Cores/cache=3D 1, Caches/package=3D 3 +----+----+----+ Cache | L1D| L1D| L1D| Size | 32K| 32K| 32K| OScpu#| 0| 1| 2| Core | c0| c1| c2| AffMsk| 1| 2| 4| +----+----+----+ Cache | L1I| L1I| L1I| Size | 32K| 32K| 32K| +----+----+----+ Cache | L2| L2| L2| Size |256K|256K|256K| +----+----+----+ Cache | L3| L3| L3| Size | 8M| 8M| 8M| +----+----+----+ Combined socket AffinityMask=3D 0x7 --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 19:30: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 7997A106567A; Thu, 19 Aug 2010 19:30:53 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 11F7A8FC16; Thu, 19 Aug 2010 19:30:52 +0000 (UTC) Received: by qyk8 with SMTP id 8so1796183qyk.13 for ; Thu, 19 Aug 2010 12:30:52 -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=dUsPozIt5rOyuiBphv56i3lxp3TGdUXt0f85oCOlL0c=; b=gbercTiCxYA76hR0PWvoyzJWm+gJ0hNlR7L0rYjGpi60INpe8J/nsBYICKtuhp2Itr UKFkaBD6SNuAwZ2outx7Ll/XjNL4gLYy+ixuC2YBlKkHAQKLZkvZRLFaiDN8hZvNW6dH knUqiyYxcLOfM2wzKaFmb0cmLPcW3+wW3cYXw= 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=oyaYmPs/KzS7OT+xA+YK4J5y5rqbaJxHjsT2PLph3fyeXtUTYy5ObO2M4+cBmEmu+L HOpL3yUoRHExDyS0f2L8m9iVHRoEcBO0E7CDMxnNH/c+WZ0WwIAsp09GksU5RT97AvDd 41TGMROIe3ioc7vSiCWtYvyQCnZB7qIqTjE10= MIME-Version: 1.0 Received: by 10.229.248.84 with SMTP id mf20mr294767qcb.16.1282246252098; Thu, 19 Aug 2010 12:30:52 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 12:30:51 -0700 (PDT) In-Reply-To: <201008191326.09822.jkim@FreeBSD.org> References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <4C6D5E31.9000701@icyb.net.ua> <201008191326.09822.jkim@FreeBSD.org> Date: Thu, 19 Aug 2010 23:30:51 +0400 Message-ID: From: pluknet To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 19 Aug 2010 19:30:53 -0000 On 19 August 2010 21:26, Jung-uk Kim wrote: > On Thursday 19 August 2010 12:56 pm, pluknet wrote: >> On 19 August 2010 20:39, Andriy Gapon wrote: >> > on 10/08/2010 19:55 pluknet said the following: >> >> On 16 July 2010 19:47, Jung-uk Kim wrote: >> >>> 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 >> >> >> >> Hi. >> >> >> >> Just checked on Xen HVM with 3 cores. >> >> 1) 8.1 unmodified: >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> >> FreeBSD/SMP: 1 package(s) x 3 core(s) >> >> >> >> 2) 8.1 + patch >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> >> WARNING: Non-uniform processors. >> >> WARNING: Using suboptimal topology. >> > >> > Can you debug, e.g. with printfs, what exactly goes wrong? >> > I wonder if in this case code follows some unusual/unexpected >> > path. >> >> Sorry, I'm a bit busy right now. >> I hope to debug this somewhere in the next week. >> >> > BTW, could you please also provide CPU name/model/features as >> > detected by the kernel? >> >> Sure. >> CPU: Intel(R) Xeon(R) CPU =A0 =A0 =A0 =A0 =A0 E5520 =A0@ 2.27GHz (2763.1= 2-MHz >> 686-class CPU) Origin =3D "GenuineIntel" =A0Id =3D 0x106a5 =A0Family =3D= 6 >> Model =3D 1a =A0Stepping =3D 5 >> Features=3D0x1781fbbf>E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> >> Features2=3D0x80982201> >> TSC: P-state invariant >> real memory =A0=3D 4194304000 (4000 MB) >> avail memory =3D 3932786688 (3750 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >> =A0cpu0 (BSP): APIC ID: =A00 >> =A0cpu1 (AP/HT): APIC ID: =A02 >> =A0cpu2 (AP/HT): APIC ID: =A04 >> >> Just a thought. >> =A0# HTT might somehow correlate with current maxcpus limit (32). > > One thing I am not sure is whether those CPUID instructions are > executed on *real* CPUs or translated in HVM. I may add only that of Features2 presents only in Xen HVM environment, and its role is afaik to indicate a Xen guest mode. There is no any mention of this bit in the latest Intel doc (ie it's reserved/unused). Also, at least NetBSD has a special handling of this bit. See commit log for CPUID2_RAZ in sys/arch/x86/include/specialreg.h, 1.37 FWIW RAZ states for "reserved and zero" or so. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 20:27: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 8B67410657DA for ; Thu, 19 Aug 2010 20:27:03 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4E28C8FC21 for ; Thu, 19 Aug 2010 20:27:03 +0000 (UTC) Received: from smtp5.server.rpi.edu (localhost.localdomain [127.0.0.1]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o7JJJt8B014926 for ; Thu, 19 Aug 2010 15:20:15 -0400 Received: (from defang@localhost) by smtp5.server.rpi.edu (8.13.1/8.13.0/Submit) id o7JJJM4k014758 for freebsd-stable@freebsd.org; Thu, 19 Aug 2010 15:19:22 -0400 Received: from [128.113.124.121] (gilead.netel.rpi.edu [128.113.124.121]) by smtp5.server.rpi.edu (envelope-sender ) (MIMEDefang) with ESMTP id o7JJJKwl014750; Thu, 19 Aug 2010 15:19:22 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C659B4C.50207@rpi.edu> References: <4C659B4C.50207@rpi.edu> Date: Thu, 19 Aug 2010 15:19:20 -0400 To: Robert Healey , freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.00 () [Hold at 15.00] 22490(-25) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225 Cc: Subject: Re: Problem with mxge on RELENG_8_1 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, 19 Aug 2010 20:27:03 -0000 At 3:21 PM -0400 8/13/10, Robert Healey wrote: > >I recently updated the central file server/router systems for a >pair of research clusters from RELENG_8_0 to RELENG_8_1. After >following the proper procedures, the network throughput when >pulling files from both machines via mxge0 is 200KB/s or less. >Before the update, 50MB/s was the normal rate. > >Doing some testing, with the 8.1 kernel booted, I can upload >files to the server over the 10G link with scp or NFS at the >expected rates. I can fetch files from the Internet using >this server as the NAT gateway also at the expected rates. >Retrieving files from the server over mxge, the throughput >falls to 200KB/s. Retrieving files from the server from the >onboard Broadcom NIC, rates are as to be expected from gigabit. >With 8.0, everything works as expected. > >Hardware Config 1: >Dell Poweredge R610 with 2 Xeon E5530 @ 2.4 GHz, hyperthread >disabled and 24GB RAM. Onboard interface is bce. Disk is >attached via a PERC 6/E. Internal cluster switch is Dell >Powerconnect 6248P. This switch sees excessive large packets >on the 10G connection on 8.1, but not 8.0. > >Hardware Config 2: >HP Proliant DL 320G6 with 1 Xeon E5540 @ 2.53GHz, hyperthread >enabled and 8GB RAM. Onboard interface is bge. Disk is >attached via a HP Smart Array P212. Internal cluster switch >is an HP Procurve 2910al. It does not see any packet errors >from the 10G link. You're seeing the performance problems with both scp and NFS? Could you get some tcpdumps of a file transfer with both setups (8.0 vs 8.1), just to see if something very odd jumps out? If I'm reading this right, file transfers work at expected speeds if the file is going *to* the server, but you see the slowdown when you're pulling files *from* the server. That sounds similar to a problem with a duplex-mismatch, except of course that you shouldn't be getting into duplex issues on a gigabit network. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 22:12:38 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 3EFFA1065695; Thu, 19 Aug 2010 22:12:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: pluknet Date: Thu, 19 Aug 2010 18:12:27 -0400 User-Agent: KMail/1.6.2 References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201008191326.09822.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201008191812.30334.jkim@FreeBSD.org> 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, 19 Aug 2010 22:12:38 -0000 On Thursday 19 August 2010 03:30 pm, pluknet wrote: > On 19 August 2010 21:26, Jung-uk Kim wrote: > > On Thursday 19 August 2010 12:56 pm, pluknet wrote: > >> On 19 August 2010 20:39, Andriy Gapon wrote: > >> > on 10/08/2010 19:55 pluknet said the following: > >> >> On 16 July 2010 19:47, Jung-uk Kim wrote: > >> >>> 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 > >> >> > >> >> Hi. > >> >> > >> >> Just checked on Xen HVM with 3 cores. > >> >> 1) 8.1 unmodified: > >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> >> FreeBSD/SMP: 1 package(s) x 3 core(s) > >> >> > >> >> 2) 8.1 + patch > >> >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >> >> WARNING: Non-uniform processors. > >> >> WARNING: Using suboptimal topology. > >> > > >> > Can you debug, e.g. with printfs, what exactly goes wrong? > >> > I wonder if in this case code follows some unusual/unexpected > >> > path. > >> > >> Sorry, I'm a bit busy right now. > >> I hope to debug this somewhere in the next week. > >> > >> > BTW, could you please also provide CPU name/model/features as > >> > detected by the kernel? > >> > >> Sure. > >> CPU: Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz > >> (2763.12-MHz 686-class CPU) Origin = "GenuineIntel"  Id = > >> 0x106a5  Family = 6 Model = 1a  Stepping = 5 > >> Features=0x1781fbbf >>,PG E,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT> > >> Features2=0x80982201> > >> TSC: P-state invariant > >> real memory  = 4194304000 (4000 MB) > >> avail memory = 3932786688 (3750 MB) > >> ACPI APIC Table: > >> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs > >> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads > >>  cpu0 (BSP): APIC ID:  0 > >>  cpu1 (AP/HT): APIC ID:  2 > >>  cpu2 (AP/HT): APIC ID:  4 > >> > >> Just a thought. > >>  # HTT might somehow correlate with current maxcpus limit (32). > > > > One thing I am not sure is whether those CPUID instructions are > > executed on *real* CPUs or translated in HVM. > > I may add only that of Features2 presents only in Xen > HVM environment, and its role is afaik to indicate a Xen guest > mode. There is no any mention of this bit in the latest Intel doc > (ie it's reserved/unused). Ah, that means the HVM is actually translating the instruction, not running directly on the CPU. That means, we cannot use any CPUID instructions for topology detection in HVM. And I bet all MSRs will be translated as well. It is not just HVM, but also any emulations and virtualizations in general. Actually, CPU topology detection does nothing in these environments because hypervisor or whatever will do memory translations and stuff unless some "hints" are given by guest or "ballooning" is done for virtual devices and resources. Usually, this kind of problem is handled by VM-specific device drivers, e.g., VirtualBox Guest Additions, VMware Tools, etc. In theory, Xen domU should do much better job than these tools because it is specifically modified to handle these problems without losing performance. > Also, at least NetBSD has a special handling of this bit. > See commit log for CPUID2_RAZ in sys/arch/x86/include/specialreg.h, > 1.37 FWIW RAZ states for "reserved and zero" or so. Hmm... Interesting. But we should never rely on an undocumented bit to identify HVM or whatever. Thanks for the info, Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 03:49: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 1B1221065672 for ; Fri, 20 Aug 2010 03:49:18 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id ECD9E8FC19 for ; Fri, 20 Aug 2010 03:49:17 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1OmIFm-0006eN-01 for freebsd-stable@freebsd.org; Thu, 19 Aug 2010 20:26:50 -0700 Message-ID: <29488441.post@talk.nabble.com> Date: Thu, 19 Aug 2010 20:26:49 -0700 (PDT) From: live_up2012 To: freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: balosatom@yahoo.com References: X-Mailman-Approved-At: Fri, 20 Aug 2010 05:00:46 +0000 Subject: Re: Resizing GPT partitions 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, 20 Aug 2010 03:49:18 -0000 There is a good software can solve your problem--Partition Manager. You needn't worry about anything wrong at all; it can help you easily http://www.extend-partition.com/help/how-to-resize-partition.html resize partition without data loss. And I want to tell you, this software is free for use. So, I think this is your best choice. -- View this message in context: http://old.nabble.com/Resizing-GPT-partitions-tp28820639p29488441.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 06:25: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 688061065694; Fri, 20 Aug 2010 06:25:41 +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 725EC8FC15; Fri, 20 Aug 2010 06:25:40 +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 JAA22544; Fri, 20 Aug 2010 09:25:37 +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 1OmL2n-0001MI-1u; Fri, 20 Aug 2010 09:25:37 +0300 Message-ID: <4C6E1FDF.8050708@icyb.net.ua> Date: Fri, 20 Aug 2010 09:25:35 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: pluknet , Jung-uk Kim References: <201007141414.o6EEEUx9014690@lurza.secnetix.de> <201007141755.04690.jkim@FreeBSD.org> <4C3FB73F.7070502@freebsd.org> <201007161147.56242.jkim@FreeBSD.org> <4C6D5E31.9000701@icyb.net.ua> <4C6D697A.5050302@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 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: Fri, 20 Aug 2010 06:25:41 -0000 on 19/08/2010 22:15 pluknet said the following: > On 19 August 2010 21:27, Andriy Gapon wrote: >> on 19/08/2010 19:56 pluknet said the following: >>> CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2763.12-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 >>> Features=0x1781fbbf >>> Features2=0x80982201> >>> TSC: P-state invariant >>> real memory = 4194304000 (4000 MB) >>> avail memory = 3932786688 (3750 MB) >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs >>> FreeBSD/SMP: 0 package(s) x 1 core(s) x 32 HTT threads >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP/HT): APIC ID: 2 >>> cpu2 (AP/HT): APIC ID: 4 >> Thanks! >> BTW, what does Intel's code report? >> Jung-uk's convenience script: >> http://people.freebsd.org/~jkim/cpu_topology-12212009.sh >> > > Software visible enumeration in the system: > Number of logical processors visible to the OS: 3 > Number of logical processors visible to this process: 3 > Number of processor cores visible to this process: 3 > Number of physical packages visible to this process: 1 > > Hierarchical counts by levels of processor topology: > # of cores in package 0 visible to this process: 3 . So, original Intel code detects the topology correctly. Jung-uk, despite what you said in the parallel followup, I think that this demonstrates that there is a flaw in your patch as compared to the logic in the Intel-provided code. FWIW, I was surprised to see a loop in topo_probe_0x4 - I don't see such a loop in Intel's code. Also, (level == 1 && cpu_logical == logical * cores) verification might be a suspect too. It may be OK for real hardware, but emulated hardware may stick to minimal compatibility required. > 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 > > Pkg-aggregated: > P:0 --> 7 > > > APIC ID listings from affinity masks > OS cpu 0, Affinity mask 01 - apic id 0 > OS cpu 1, Affinity mask 02 - apic id 2 > OS cpu 2, Affinity mask 04 - apic id 4 > > > Package 0 Cache and Thread details > L1D is Level 1 Data cache, size(KBytes)= 32, Cores/cache= 1, Caches/package= 3 > L1I is Level 1 Instruction cache, size(KBytes)= 32, Cores/cache= 1, > Caches/package= 3 > L2 is Level 2 Unified cache, size(KBytes)= 256, Cores/cache= 1, > Caches/package= 3 > L3 is Level 3 Unified cache, size(KBytes)= 8192, Cores/cache= 1, > Caches/package= 3 > +----+----+----+ > Cache | L1D| L1D| L1D| > Size | 32K| 32K| 32K| > OScpu#| 0| 1| 2| > Core | c0| c1| c2| > AffMsk| 1| 2| 4| > +----+----+----+ > > Cache | L1I| L1I| L1I| > Size | 32K| 32K| 32K| > +----+----+----+ > > Cache | L2| L2| L2| > Size |256K|256K|256K| > +----+----+----+ > > Cache | L3| L3| L3| > Size | 8M| 8M| 8M| > +----+----+----+ > > Combined socket AffinityMask= 0x7 > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 10:30: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 33BA21065693 for ; Fri, 20 Aug 2010 10:30:09 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id ED3868FC0C for ; Fri, 20 Aug 2010 10:30:08 +0000 (UTC) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OmOkz-000Kvw-QK; Fri, 20 Aug 2010 12:23:29 +0200 From: Heinrich Rebehn Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 12:30:07 +0200 To: freebsd-stable@freebsd.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: ZFS performance question 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, 20 Aug 2010 10:30:09 -0000 Hi all, After setting up our new server (Intel Q9550 CPU, 8GB RAM, 4 x = ST31000340NS) i did a bonnie++ benchmark on the zfs raidz that i created = on 4 partitions on the 4 disks. root@antsrv4 [/data/nocompression] # bonnie++ -u root -d . Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 ------Sequential Output------ --Sequential Input- = --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- = --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP = /sec %CP antsrv4.ant.uni 16G 94 81 151823 39 100780 27 303 99 239853 30 = 148.3 4 Latency 4733ms 6051ms 8173ms 37504us 917ms = 1030ms Version 1.96 ------Sequential Create------ --------Random = Create-------- antsrv4.ant.uni-bre -Create-- --Read--- -Delete-- -Create-- --Read--- = -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP = /sec %CP 16 24183 97 +++++ +++ 21715 98 17209 98 +++++ +++ = 21291 97 Latency 19779us 128us 162us 39671us 38us = 77us = 1.96,1.96,antsrv4.ant.uni-bremen.de,1,1282303232,16G,,94,81,151823,39,1007= 80,27,303,99,239853,30,148.3,4,16,,,,,24183,97,+++++,+++,21715,98,17209,98= ,+++++,+++,21291,97, = 733ms,6051ms,8173ms,37504us,917ms,1030ms,19779us,128us,162us,39671us,38us,= 77us I am somewhat concerned about the numbers for per-char-output and = per-char-input. In fact, i have never before seen that low numbers in a = bonnie test. Using a single disk with UFS yields about 6 times as much. I know that this is not crucial for a normal file server, but i want to = rule out any configuration errors. Is this normal for ZFS?. Disks are accessed using ahci. I did not = attempt any tuning yet. BTW: Running OpenSolaris on the same hardware yields 110306 for = per-char-write and 94698 for per-char-read. --Heinrich Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax : -3341 From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 11:12: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 E782F10656A3 for ; Fri, 20 Aug 2010 11:12:10 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB4C68FC17 for ; Fri, 20 Aug 2010 11:12:10 +0000 (UTC) Received: by iwn36 with SMTP id 36so3283284iwn.13 for ; Fri, 20 Aug 2010 04:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.172.83 with SMTP id k19mr1356046ibz.114.1282301299264; Fri, 20 Aug 2010 03:48:19 -0700 (PDT) Received: by 10.231.176.140 with HTTP; Fri, 20 Aug 2010 03:48:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Aug 2010 12:48:19 +0200 Message-ID: From: Olivier Smedts To: Heinrich Rebehn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: ZFS performance question 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, 20 Aug 2010 11:12:11 -0000 2010/8/20 Heinrich Rebehn : > Hi all, > > After setting up our new server (Intel Q9550 CPU, 8GB RAM, 4 x ST31000340= NS) i did a bonnie++ benchmark on the zfs raidz that i created on 4 partiti= ons on the 4 disks. > > root@antsrv4 [/data/nocompression] # bonnie++ -u root -d . > Using uid:0, gid:0. > Writing a byte at a time...done > Writing intelligently...done > Rewriting...done > Reading a byte at a time...done > Reading intelligently...done > start 'em...done...done...done...done...done... > Create files in sequential order...done. > Stat files in sequential order...done. > Delete files in sequential order...done. > Create files in random order...done. > Stat files in random order...done. > Delete files in random order...done. > Version =A01.96 =A0 =A0 =A0 ------Sequential Output------ --Sequential In= put- --Random- > Concurrency =A0 1 =A0 =A0 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block= -- --Seeks-- > Machine =A0 =A0 =A0 =A0Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec= %CP =A0/sec %CP > antsrv4.ant.uni 16G =A0 =A094 =A081 151823 =A039 100780 =A027 =A0 303 =A0= 99 239853 =A030 148.3 =A0 4 > Latency =A0 =A0 =A0 =A0 =A0 =A0 =A04733ms =A0 =A06051ms =A0 =A08173ms =A0= 37504us =A0 =A0 917ms =A0 =A01030ms > Version =A01.96 =A0 =A0 =A0 ------Sequential Create------ --------Random = Create-------- > antsrv4.ant.uni-bre -Create-- --Read--- -Delete-- -Create-- --Read--- -De= lete-- > =A0 =A0 =A0 =A0 =A0 =A0 =A0files =A0/sec %CP =A0/sec %CP =A0/sec %CP =A0/= sec %CP =A0/sec %CP =A0/sec %CP > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 16 24183 =A097 +++++ +++ 21715 =A098 1720= 9 =A098 +++++ +++ 21291 =A097 > Latency =A0 =A0 =A0 =A0 =A0 =A0 19779us =A0 =A0 128us =A0 =A0 162us =A0 3= 9671us =A0 =A0 =A038us =A0 =A0 =A077us > 1.96,1.96,antsrv4.ant.uni-bremen.de,1,1282303232,16G,,94,81,151823,39,100= 780,27,303,99,239853,30,148.3,4,16,,,,,24183,97,+++++,+++,21715,98,17209,98= ,+++++,+++,21291,97, 733ms,6051ms,8173ms,37504us,917ms,1030ms,19779us,128us= ,162us,39671us,38us,77us > > > I am somewhat concerned about the numbers for per-char-output and per-cha= r-input. In fact, i have never before seen that low numbers in a bonnie tes= t. Using a single disk with UFS yields about 6 times as much. > > > I know that this is not crucial for a normal file server, but i want to r= ule out any configuration errors. > > Is this normal for ZFS?. Disks are accessed using ahci. I did not attempt= any tuning yet. Can you try without AHCI ? http://www.phoronix.com/scan.php?page=3Darticle&item=3Dfreebsd_zfs_cam&num= =3D5 > BTW: Running OpenSolaris on the same hardware yields 110306 for per-char-= write and 94698 for per-char-read. > > --Heinrich > > > Heinrich Rebehn > > University of Bremen > Physics / Electrical and Electronics Engineering > - Department of Telecommunications - > > Phone : +49/421/218-62394 > Fax =A0 : =A0 =A0 =A0 =A0 =A0 =A0-3341 > > > > > > _______________________________________________ > 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 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 12: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 3DEA31065674 for ; Fri, 20 Aug 2010 12:08:56 +0000 (UTC) (envelope-from n.kalpazanov@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC48E8FC16 for ; Fri, 20 Aug 2010 12:08:55 +0000 (UTC) Received: by vws7 with SMTP id 7so3403389vws.13 for ; Fri, 20 Aug 2010 05:08:55 -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=mq6UMrJYVnkyvkAo9OXJ1c28CMTG43hkbgoY7EMsSC8=; b=XUh8pRw2dOpJ9DirTkHMSVIEShW1sYjG8fEzjasaLQYd0oOrJsFzUd4FbcvfjEhYtP OmICKGq5+IM1nmfOxqWfbzfPJV/ZkZ1lTj5zvmHbzyDG5FUua0wftZtp194aUG50Fbpz JQoJ28EMreHhckliz3E3OVGipRfJ9zn3DqGmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MBw4wKY7Omtuf1O/XJWTDUDoo1fIRn2QZj8reN9ojYG7Cs8Mw1wdvP20Ig1ECFzX7N nuyUUVohsfY0LMJX3vUZm1f8lujSDBHZH9gFeJjDsE2tpWwnoXjzClGB9ByrTIon6hVa MptIdoCcl/ugEQrwH7XYvDqmxVmTBs7OXVY5U= MIME-Version: 1.0 Received: by 10.220.46.17 with SMTP id h17mr762639vcf.174.1282304661025; Fri, 20 Aug 2010 04:44:21 -0700 (PDT) Received: by 10.220.194.136 with HTTP; Fri, 20 Aug 2010 04:44:20 -0700 (PDT) Date: Fri, 20 Aug 2010 13:44:20 +0200 Message-ID: From: Nikola Kalpazanov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: P811B Quad Port NIC problem. 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, 20 Aug 2010 12:08:56 -0000 Hi, First I want to start with the note that I know Realtek is no good, yet I will appreciate any assistance that you may provide. here are details of the problem: P811B is 4 port Ethernet card with built-in mini-PCI slot where I have attached Atheros 802.11a/b/g/n Wireless PCI Adapter (AR5416). That also requires to disable 4th port from the jumpers on the card. I have installed FreeBSD 8.1-RELEASE i386 pciconf -vlb pcib6@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x814812d8 rev=0x00 hdr=0x01 vendor = 'Pericom Semiconductor' class = bridge subclass = PCI-PCI rl0@pci0:6:8:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139D)' class = network subclass = ethernet bar [14] = type Memory, range 32, base 0xe0110200, size 256, enabled rl1@pci0:6:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139D)' class = network subclass = ethernet bar [14] = type Memory, range 32, base 0xe0110100, size 256, enabled rl2@pci0:6:10:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139D)' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [14] = type Memory, range 32, base 0xe0110000, size 256, enabled ath0@pci0:6:11:0: class=0x028000 card=0x2071168c chip=0x0023168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g/n Wireless PCI Adapter (AR5416)' class = network bar [10] = type Memory, range 32, base 0xe0100000, size 65536, enabled dmesg rl0: port 0x1200-0x12ff mem 0xe0110200-0xe01102ff irq 21 at device 8.0 on pci6 rl0: reset never completed! rl0: unknown device ID: ffff assuming 8139 rl0: MII without any phy! device_attach: rl0 attach returned 6 rl1: port 0x1100-0x11ff mem 0xe0110100-0xe01101ff irq 22 at device 9.0 on pci6 rl1: reset never completed! rl1: unknown device ID: ffff assuming 8139 rl1: MII without any phy! device_attach: rl1 attach returned 6 rl2: port 0x1000-0x10ff mem 0xe0110000-0xe01100ff irq 23 at device 10.0 on pci6 miibus1: on rl2 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: Ethernet address: 00:06:4f:67:08:f5 rl2: [ITHREAD] rl2: link state changed to DOWN ath0 works fine rl2 works fine rl0 and rl1 don't and of course as you may suspect they are missing from ifconfig -a if I remove the miniPCI Atheros and enable 4th port it is the same picture but this time 4th port rl3 works fine and rl0, rl1, and rl2 don't in the same way. Any suggestions will be much appreciated. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 12:12: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 B58261065698 for ; Fri, 20 Aug 2010 12:12:58 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id 768928FC1C for ; Fri, 20 Aug 2010 12:12:58 +0000 (UTC) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OmQMU-000MFg-IX; Fri, 20 Aug 2010 14:06:18 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Heinrich Rebehn In-Reply-To: Date: Fri, 20 Aug 2010 14:12:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Olivier Smedts X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org Subject: Re: ZFS performance question 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, 20 Aug 2010 12:12:58 -0000 On 20.08.2010, at 12:48, Olivier Smedts wrote: > 2010/8/20 Heinrich Rebehn : >> Hi all, >>=20 >> After setting up our new server (Intel Q9550 CPU, 8GB RAM, 4 x = ST31000340NS) i did a bonnie++ benchmark on the zfs raidz that i created = on 4 partitions on the 4 disks. >>=20 >> root@antsrv4 [/data/nocompression] # bonnie++ -u root -d . >> Using uid:0, gid:0. >> Writing a byte at a time...done >> Writing intelligently...done >> Rewriting...done >> Reading a byte at a time...done >> Reading intelligently...done >> start 'em...done...done...done...done...done... >> Create files in sequential order...done. >> Stat files in sequential order...done. >> Delete files in sequential order...done. >> Create files in random order...done. >> Stat files in random order...done. >> Delete files in random order...done. >> Version 1.96 ------Sequential Output------ --Sequential Input- = --Random- >> Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- = --Seeks-- >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP = /sec %CP >> antsrv4.ant.uni 16G 94 81 151823 39 100780 27 303 99 239853 = 30 148.3 4 >> Latency 4733ms 6051ms 8173ms 37504us 917ms = 1030ms >> Version 1.96 ------Sequential Create------ --------Random = Create-------- >> antsrv4.ant.uni-bre -Create-- --Read--- -Delete-- -Create-- --Read--- = -Delete-- >> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP = /sec %CP >> 16 24183 97 +++++ +++ 21715 98 17209 98 +++++ +++ = 21291 97 >> Latency 19779us 128us 162us 39671us 38us = 77us >> = 1.96,1.96,antsrv4.ant.uni-bremen.de,1,1282303232,16G,,94,81,151823,39,1007= 80,27,303,99,239853,30,148.3,4,16,,,,,24183,97,+++++,+++,21715,98,17209,98= ,+++++,+++,21291,97, = 733ms,6051ms,8173ms,37504us,917ms,1030ms,19779us,128us,162us,39671us,38us,= 77us >>=20 >>=20 >> I am somewhat concerned about the numbers for per-char-output and = per-char-input. In fact, i have never before seen that low numbers in a = bonnie test. Using a single disk with UFS yields about 6 times as much. >>=20 >>=20 >> I know that this is not crucial for a normal file server, but i want = to rule out any configuration errors. >>=20 >> Is this normal for ZFS?. Disks are accessed using ahci. I did not = attempt any tuning yet. >=20 > Can you try without AHCI ? > = http://www.phoronix.com/scan.php?page=3Darticle&item=3Dfreebsd_zfs_cam&num= =3D5 Hmm, that looks impressive, but: root@antsrv4 [/data/nocompression] # bonnie++ -u root -d . Using uid:0, gid:0. [snip] Delete files in random order...done. Version 1.96 ------Sequential Output------ --Sequential Input- = --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- = --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP = /sec %CP antsrv4.ant.uni 16G 107 99 152759 39 118765 33 304 99 227534 29 = 137.4 4 Latency 216ms 6110ms 6436ms 108ms 717ms = 784ms Version 1.96 ------Sequential Create------ --------Random = Create-------- antsrv4.ant.uni-bre -Create-- --Read--- -Delete-- -Create-- --Read--- = -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP = /sec %CP 16 23264 94 +++++ +++ 20417 96 24430 97 +++++ +++ = 20866 97 Latency 20142us 138us 3506us 19454us 128us = 77us = 1.96,1.96,antsrv4.ant.uni-bremen.de,1,1282317527,16G,,107,99,152759,39,118= 765,33,304,99,227534,29,137.4,4,16,,,,,23264,94,+++++,+++,20417,96,24430,9= 7,+++++,+++,20866,97,216ms,6110ms,6436ms,108ms,717ms,784ms,20142us,138us,3= 506us,19454us,128us,77us Almost no difference. Only the create rate increased. root@antsrv4 [/data/nocompression] # kldstat Id Refs Address Size Name 1 9 0xffffffff80100000 d6aa98 kernel 2 1 0xffffffff80e6b000 19eb18 zfs.ko 3 2 0xffffffff8100a000 3868 opensolaris.ko root@antsrv4 [/data/nocompression] # ls /dev/ada* ls: /dev/ada*: No such file or directory -Heinrich >=20 >> BTW: Running OpenSolaris on the same hardware yields 110306 for = per-char-write and 94698 for per-char-read. >>=20 >=20 >=20 >=20 > --=20 > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ >=20 > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." > _______________________________________________ > 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" Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-62394 Fax : -3341 From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 12:53: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 7ACB31065670 for ; Fri, 20 Aug 2010 12:53:00 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1400:b::27e9]) by mx1.freebsd.org (Postfix) with ESMTP id E56828FC15 for ; Fri, 20 Aug 2010 12:52:59 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o7KCqssq083566 for ; Fri, 20 Aug 2010 15:52:54 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4C6E7AA3.8090000@ukr.net> Date: Fri, 20 Aug 2010 15:52:51 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: ZFS performance question 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, 20 Aug 2010 12:53:00 -0000 20.08.2010 15:12, Heinrich Rebehn wrote: > root@antsrv4 [/data/nocompression] # kldstat #kldstat -v From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 14:00:50 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 083831065695 for ; Fri, 20 Aug 2010 14:00:50 +0000 (UTC) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.freebsd.org (Postfix) with ESMTP id A1FE08FC0A for ; Fri, 20 Aug 2010 14:00:49 +0000 (UTC) Received: from ant2005.ant.uni-bremen.de ([134.102.176.250] helo=[10.8.1.9]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OmS2q-000MeA-Nf; Fri, 20 Aug 2010 15:54:09 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/mixed; boundary=Apple-Mail-2--937030194 From: Heinrich Rebehn In-Reply-To: <4C6E7AA3.8090000@ukr.net> Date: Fri, 20 Aug 2010 16:00:47 +0200 Message-Id: <4B66C07C-EBDE-4E98-A82D-AF2108573F26@ant.uni-bremen.de> References: <4C6E7AA3.8090000@ukr.net> To: Vladislav V. Prodan X-Mailer: Apple Mail (2.1081) Cc: Heinrich Rebehn , freebsd-stable@freebsd.org Subject: Re: ZFS performance question 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, 20 Aug 2010 14:00:50 -0000 --Apple-Mail-2--937030194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 20.08.2010, at 14:52, Vladislav V. Prodan wrote: > 20.08.2010 15:12, Heinrich Rebehn wrote: >> root@antsrv4 [/data/nocompression] # kldstat > > #kldstat -v --Apple-Mail-2--937030194 Content-Disposition: attachment; filename=kldstat-v.txt Content-Type: text/plain; name="kldstat-v.txt" Content-Transfer-Encoding: quoted-printable Id Refs Address Size Name 1 9 0xffffffff80100000 d6aa98 kernel (/boot/kernel/kernel) Contains modules: Id Name 93 ataraid 340 if_lo 407 elf32 328 shell 327 elf64 313 pseudofs 280 uether 341 if_tun 339 if_gif 342 if_vlan 350 mld 349 igmp 337 if_faith 332 sysvmsg 333 sysvsem 335 sem 334 sysvshm 356 nfslockd 351 nfs_common 355 nfssvc 354 nfsserver 360 krpc 361 ufs 312 procfs 352 nfs 311 msdosfs 310 devfs 326 cd9660 6 cam 63 ata 16 sa 15 pass 13 ada 322 g_part_mbr 321 g_part_gpt 320 g_part_ebr 319 g_part_bsd 10 probe 12 ch 14 da 7 xpt 11 cd 8 aprobe 17 ses 9 pmp 221 pci/ppc 220 isa/ppc 219 acpi/ppc 218 ppbus/ppi 113 pci/dc 217 ppc/ppbus 216 ppbus/lpt 112 dc/miibus 215 ppbus/plip 214 pci/pcn 213 pcn/miibus 111 pccard/cs 212 pci/vgapci 211 pci/pcib 210 pcib/pci 110 isa/cs 53 alc/miibus 52 ahc 109 cpu/ichss 51 ahd 108 pci/ciss 50 pci/ahd 209 pci/isab 208 pci/ignore_pci 207 pci/hostb 206 pci/fixup_pci 205 pci/cbb 49 pci/ahc_pci 48 isa/ahc_isa 204 isa/cbb 47 pccard/aic 22 nexus/acpi 31 pcib/acpi_pci 107 cbb/cardbus 106 pci/bt 105 isa/bt 203 pcic/pccard 411 cpu/p4tcc 410 cpu/hwpstate 202 cbb/pccard 201 null 409 cpu/est 408 cpu/powernow 200 pci/nge 199 nge/miibus 104 pci/bge 103 bge/miibus 20 pci/aacch 406 isa/vga 405 vgapci/vgapm 198 pci/mskc 404 isa/sc 403 isa/atrtc 402 acpi/atrtc 401 scrndr-vga 400 scterm-scteken 197 mskc/msk 196 msk/miibus 102 pci/bfe 399 pci/nfe 398 nfe/miibus 101 bfe/miibus 397 pci/hptrr 396 pci/hptmv 395 pccard/fdc 394 isa/fdc 393 acpi/fdc 392 fdc/fd 391 io 100 pci/bce 390 isa/ed 193 pci/mpt 99 bce/miibus 389 atkbdc/psm 388 isa/psmcpnp 387 acpi/psmcpnp 46 pci/age 386 isa/atkbdc 385 acpi/atkbdc 384 atkbdc/atkbd 383 pci/arcmsr 382 hostb/agp_via 381 hostb/agp_intel 380 vgapci/agp_i810 379 hostb/agp_amd64 45 age/miibus 190 pci/mly 378 legacy/pcib 377 isa/pcibus_pnp 376 isa/atdma 375 acpi/atdma 374 legacy/isa 189 pci/mlx 188 mlx/mlxd 373 isa/attimer 372 acpi/attimer 187 miibus/xmphy 186 miibus/ukphy 185 miibus/truephy 371 root/nexus 370 nexus/ram 369 isa/sysresource 184 miibus/tlphy 183 miibus/tdkphy 182 miibus/smcphy 181 miibus/ruephy 180 miibus/rlphy 179 miibus/rgephy 178 miibus/qsphy 177 miibus/pnaphy 176 miibus/nsphyter 175 miibus/nsphy 368 nexus/legacy 367 legacy/cpu 174 miibus/nsgphy 173 miibus/mlphy 366 pci/ioapic 365 nexus/apic 172 miibus/lxtphy 364 acpi/fpupnp 171 miibus/jmphy 170 miibus/ip1000phy 169 miibus/inphy 168 miibus/icsphy 167 miibus/gentbi 166 miibus/xlphy 165 miibus/e1000phy 164 miibus/ciphy 163 miibus/brgphy 162 miibus/bmtphy 363 root/nexus_acpi 161 miibus/axphy 160 miibus/atphy 159 miibus/amphy 158 miibus/acphy 157 mfi/mfid 156 pci/mfi 44 pci/ae 98 pci/ath 43 ae/miibus 30 acpi/acpi_lid 155 mem 42 pci/adw 41 pci/adv 97 ata/ast 153 pci/lge 152 lge/miibus 40 acpi/acpi_timer 151 pci/le 96 ata/afd 150 kbdmux 39 cpu/acpi_throttle 95 ata/acd 149 pci/jme 329 cpu/cpufreq 148 jme/miibus 147 pci/ixgbe 38 acpi/acpi_tz 94 ad/subdisk 29 acpi/acpi_isab 92 ata/ad 91 pci/ata_via 90 pci/ata_sis 89 pci/ata_sii 88 pci/ata_serverworks 146 pci/isp 145 pci/ips 144 ips/ipsd 87 pci/ata_promise 143 pci/iir 86 pci/ata_nvidia 142 pci/ida 325 isa/orm 141 ida/idad 324 isab/isa 323 eisab/isa 140 pci/hptiop 139 pci/fxp 138 fxp/miibus 359 pci/rl 358 cardbus/rl 357 rl/miibus 85 pci/ata_netcell 84 pci/ata_national 137 firewire/fwip 83 pci/ata_micron 82 pci/ata_marvell 81 pci/ata_jmicron 80 pci/ata_ite 136 firewire/fwe 135 pci/fwohci 353 nfslock 79 pci/ata_intel 78 pci/ata_highpoint 77 pci/ata_cyrix 76 pci/ata_cypress 134 fwohci/firewire 133 pccard/fe 132 exca 131 pccard/ex 130 isa/ex 129 pccard/ep 128 isa/ep 75 pci/ata_cenatek 127 pci/et 126 et/miibus 74 pci/ata_ati 73 pci/ata_amd 72 pci/ata_adaptec 71 pci/ata_ali 125 pci/igb 70 pci/ata_acard 69 pci/ata_ahci 68 atapci/ata_ahci_ata 25 acpi/acpi_cmbat 309 pci/xl 308 xl/miibus 307 pccard/xe 306 pci/wi 305 pccard/wi 304 pci/wb 303 wb/miibus 302 watchdog 301 pci/vx 300 pci/vr 299 vr/miibus 67 pci/atapci 298 pci/vge 297 vge/miibus 66 atapci/ata 296 uhub/ums 65 isa/ata 64 pccard/ata 295 uhub/ukbd 294 uhub/uhid 124 pci/lem 37 acpi/acpi_smbat 36 acpi/acpi_sysresource 293 uhub/uvscom 292 uhub/uvisor 291 uhub/uslcom 290 uhub/uplcom 289 uhub/ulpt 288 uhub/uipaq 287 uhub/uftdi 286 uhub/ubsa 285 uhub/uark 284 uhub/zyd 283 uhub/ural 28 acpi/acpi_hpet 282 uhub/uath 281 uhub/rum 279 uhub/udav 278 udav/miibus 277 uhub/rue 276 rue/miibus 275 uhub/kue 274 uhub/cue 273 uhub/cdce 272 uhub/axe 271 axe/miibus 270 uhub/aue 269 aue/miibus 24 acpi/acpi_button 19 aac/aacd 268 usbus/uhub 267 uhub/uhub 35 cpu/acpi_perf 23 acpi/acpi_acad 34 pci/acpi_pcib 62 pci/an 61 pccard/an 123 pci/em 60 isa/an 33 acpi/acpi_pcib 59 pci/amr 58 amr/amrd 266 uhub/usb_linux 265 uhub/urio 18 aac/aacp 264 uhub/umass 57 pci/amd 263 ohci/usbus 262 uhci/usbus 261 ehci/usbus 260 at91_udp/usbus 259 uss820/usbus 258 pci/uhci 27 acpi/acpi_ec 21 pci/aac 257 pci/ohci 56 pci/ale 256 pci/ehci 55 ale/miibus 26 acpi/cpu 32 acpi/acpi_pci_link 122 pci/ed 121 pccard/ed 255 pci/uart 254 pccard/uart 253 isa/uart 252 acpi/uart 120 ed/miibus 251 pci/txp 250 pci/tx 249 tx/miibus 248 pci/twe 247 twe/twed 119 pci/dpt 118 pci/de 246 pci/twa 245 pci/trm 244 pci/tl 243 tl/miibus 242 pci/ti 117 dcons 241 pci/sym 240 pci/stge 239 stge/miibus 238 pci/ste 237 ste/miibus 236 pccard/sn 235 isa/sn 54 pci/alc 234 pci/skc 233 skc/sk 232 sk/miibus 231 pci/sis 230 sis/miibus 229 pci/sge 228 sge/miibus 227 pci/sf 226 sf/miibus 116 firewire/dcons_crom 115 miibus/pnphy 225 pci/re 224 re/miibus 114 miibus/dcphy 223 random 222 pci/ral 194 mpt_raid 195 mpt_user 192 mpt_cam 315 g_disk 314 g_dev 317 g_label 348 wlan_sta 330 rootbus 316 g_vfs 191 mpt_core 331 firmware 154 g_md 362 g_class 347 wlan 318 g_part 346 wlan_wep 345 wlan_tkip 344 wlan_ccmp 343 wlan_amrr 338 if_firewire 336 ether 412 x86bios 2 1 0xffffffff80e6b000 19eb18 zfs.ko (/boot/kernel/zfs.ko) Contains modules: Id Name 2 zfsctrl 3 zfs 5 zfs_vdev 4 zfs_zvol 3 2 0xffffffff8100a000 3868 opensolaris.ko = (/boot/kernel/opensolaris.ko) Contains modules: Id Name 1 opensolaris --Apple-Mail-2--937030194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > 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" > --Apple-Mail-2--937030194-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 13:47:38 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 7AD43106566B for ; Fri, 20 Aug 2010 13:47:38 +0000 (UTC) (envelope-from mi+thunw@aldan.algebra.com) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF108FC27 for ; Fri, 20 Aug 2010 13:47:38 +0000 (UTC) Received: from [192.168.1.9] ([unknown] [173.70.194.135]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L7G00AY4BIQ8720@vms173009.mailsrvcs.net> for stable@FreeBSD.org; Fri, 20 Aug 2010 07:47:20 -0500 (CDT) Message-id: <4C6E790C.6060909@aldan.algebra.com> Date: Fri, 20 Aug 2010 08:46:04 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-version: 1.0 To: stable@FreeBSD.org X-Mailman-Approved-At: Fri, 20 Aug 2010 14:06:58 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Strange buildworld error (uuid_*) 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, 20 Aug 2010 13:47:38 -0000 Hello! With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now boots nicely. I'd like to make another round of buildworld/buildkernel -- using the existing tools... That, however, breaks in the most unexpected place: /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xad5): In function `bd_opendisk': : undefined reference to `uuid_is_nil' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xf62): In function `bd_opendisk': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0xf8a): In function `bd_opendisk': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x10fe): In function `bd_opendisk': : undefined reference to `uuid_is_nil' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x160a): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x16b2): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x1701): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x18cd): In function `bd_print': : undefined reference to `uuid_equal' /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(biosdisk.o)(.text+0x19ba): In function `bd_print': : undefined reference to `uuid_equal' *** Error code 1 1 error Any suggestions? Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 17:40: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 9B2021065672 for ; Fri, 20 Aug 2010 17:40:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 668E18FC21 for ; Fri, 20 Aug 2010 17:40:25 +0000 (UTC) Received: by pvg4 with SMTP id 4so1476848pvg.13 for ; Fri, 20 Aug 2010 10:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=kdSrWnXVairwgK7b0iczBf2sSqHD1GUV6mbEkrvlbI4=; b=t30nZVPmKjnop1r2TNauChoDmXm9yC9r69kjsl3pnR+eS+Bm5qByqqWAUPomdyBIvZ MeFBeJnsPJDFHxax0yby6Ww5e4Xw6WsvuFMQbostIb+GwYYKSeyFrzzOiWLNKwluwmHh TqwA5dduKQxNSOEUp0Uz9hmVaK0rnC+dtDlq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=a5M5dSrORK7UiY6xI+QfHDtwudR0wYOxgtX9KzOeVPBPmnfeWrbXw2HrZm/7IexoZK QAGjC4opns2CYTnJjY2ChxsSQ/1A0iJ4cHKoDBICMrd+Ht3424xxOOYKWLwELogYZJQE ujCmwiElCQMhw/d/w6LQHdTgADHERAt11TsdY= Received: by 10.142.201.5 with SMTP id y5mr1376712wff.130.1282326024993; Fri, 20 Aug 2010 10:40:24 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v38sm3516411wfh.0.2010.08.20.10.40.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 10:40:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 20 Aug 2010 10:40:22 -0700 From: Pyun YongHyeon Date: Fri, 20 Aug 2010 10:40:22 -0700 To: Nikola Kalpazanov Message-ID: <20100820174022.GA21062@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: P811B Quad Port NIC problem. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:40:25 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 20, 2010 at 01:44:20PM +0200, Nikola Kalpazanov wrote: > Hi, > > First I want to start with the note that I know Realtek is no good, > yet I will appreciate any assistance that you may provide. > > here are details of the problem: > > P811B is 4 port Ethernet card with built-in mini-PCI slot where I have > attached Atheros 802.11a/b/g/n Wireless PCI Adapter (AR5416). > That also requires to disable 4th port from the jumpers on the card. > > I have installed FreeBSD 8.1-RELEASE i386 > > pciconf -vlb > > pcib6@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x814812d8 > rev=0x00 hdr=0x01 > vendor = 'Pericom Semiconductor' > class = bridge > subclass = PCI-PCI > rl0@pci0:6:8:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > (RTL-8139/8139C/8139D)' > class = network > subclass = ethernet > bar [14] = type Memory, range 32, base 0xe0110200, size 256, enabled > rl1@pci0:6:9:0: class=0x020000 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > (RTL-8139/8139C/8139D)' > class = network > subclass = ethernet > bar [14] = type Memory, range 32, base 0xe0110100, size 256, enabled > rl2@pci0:6:10:0: class=0x020000 card=0x813910ec chip=0x813910ec > rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Realtek RTL8139 Family PCI Fast Ethernet NIC > (RTL-8139/8139C/8139D)' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled > bar [14] = type Memory, range 32, base 0xe0110000, size 256, enabled > ath0@pci0:6:11:0: class=0x028000 card=0x2071168c chip=0x0023168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = '802.11a/b/g/n Wireless PCI Adapter (AR5416)' > class = network > bar [10] = type Memory, range 32, base 0xe0100000, size 65536, enabled > > > > dmesg > > rl0: port 0x1200-0x12ff mem > 0xe0110200-0xe01102ff irq 21 at device 8.0 on pci6 > rl0: reset never completed! > rl0: unknown device ID: ffff assuming 8139 > rl0: MII without any phy! > device_attach: rl0 attach returned 6 > rl1: port 0x1100-0x11ff mem > 0xe0110100-0xe01101ff irq 22 at device 9.0 on pci6 > rl1: reset never completed! > rl1: unknown device ID: ffff assuming 8139 > rl1: MII without any phy! > device_attach: rl1 attach returned 6 > rl2: port 0x1000-0x10ff mem > 0xe0110000-0xe01100ff irq 23 at device 10.0 on pci6 > miibus1: on rl2 > rlphy0: PHY 0 on miibus1 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl2: Ethernet address: 00:06:4f:67:08:f5 > rl2: [ITHREAD] > rl2: link state changed to DOWN > > > ath0 works fine > rl2 works fine > > rl0 and rl1 don't and of course as you may suspect they are missing > from ifconfig -a > > if I remove the miniPCI Atheros and enable 4th port it is the same > picture but this time 4th port rl3 works fine and rl0, rl1, and rl2 > don't in the same way. > > Any suggestions will be much appreciated. What makes me wonder is that both pci0:6:8:0 and pci0:6:9:0 has no I/O BAR. I never saw these kind of thing on rl(4) controllers. And I can't explain how rl(4) could successfully map the I/O with non-existing I/O BAR. Anyway would you try attached patch and let me know whether it makes any difference? Also add the following line to /boot/device.hints to have rl(4) use memory mapped mapping. hint.rl.0.prefer_iomap="0" --x+6KMIRAuhnl3hBn Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rl.map.diff" Index: sys/pci/if_rl.c =================================================================== --- sys/pci/if_rl.c (revision 211528) +++ sys/pci/if_rl.c (working copy) @@ -225,14 +225,6 @@ static void rl_setwol(struct rl_softc *); static void rl_clrwol(struct rl_softc *); -#ifdef RL_USEIOSPACE -#define RL_RES SYS_RES_IOPORT -#define RL_RID RL_PCI_LOIO -#else -#define RL_RES SYS_RES_MEMORY -#define RL_RID RL_PCI_LOMEM -#endif - static device_method_t rl_methods[] = { /* Device interface */ DEVMETHOD(device_probe, rl_probe), @@ -806,7 +798,7 @@ struct sysctl_ctx_list *ctx; struct sysctl_oid_list *children; int error = 0, hwrev, i, pmc, rid; - int unit; + int prefer_iomap, unit; uint16_t rl_did = 0; char tn[32]; @@ -828,10 +820,31 @@ pci_enable_busmaster(dev); - /* Map control/status registers. */ - rid = RL_RID; - sc->rl_res = bus_alloc_resource_any(dev, RL_RES, &rid, RF_ACTIVE); + /* + * Map control/status registers. + * Default to using PIO access for this driver. On SMP systems, + * there appear to be problems with memory mapped mode: it looks + * like doing too many memory mapped access back to back in rapid + * succession can hang the bus. I'm inclined to blame this on + * crummy design/construction on the part of RealTek. Memory + * mapped mode does appear to work on uniprocessor systems though. + */ + prefer_iomap = 1; + resource_int_value(device_get_name(sc->rl_dev), + device_get_unit(sc->rl_dev), "prefer_iomap", &prefer_iomap); + if (prefer_iomap) { + sc->rl_res_id = PCIR_BAR(0); + sc->rl_res_type = SYS_RES_IOPORT; + sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, + &sc->rl_res_id, RF_ACTIVE); + } + if (prefer_iomap == 0 || sc->rl_res == NULL) { + sc->rl_res_id = PCIR_BAR(1); + sc->rl_res_type = SYS_RES_MEMORY; + sc->rl_res = bus_alloc_resource_any(dev, sc->rl_res_type, + &sc->rl_res_id, RF_ACTIVE); + } if (sc->rl_res == NULL) { device_printf(dev, "couldn't map ports/memory\n"); error = ENXIO; @@ -1029,7 +1042,8 @@ if (sc->rl_irq[0]) bus_release_resource(dev, SYS_RES_IRQ, 0, sc->rl_irq[0]); if (sc->rl_res) - bus_release_resource(dev, RL_RES, RL_RID, sc->rl_res); + bus_release_resource(dev, sc->rl_res_type, sc->rl_res_id, + sc->rl_res); if (ifp) if_free(ifp); --x+6KMIRAuhnl3hBn-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 18:28: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 88D4E1065695 for ; Fri, 20 Aug 2010 18:28:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 478AB8FC13 for ; Fri, 20 Aug 2010 18:28:41 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7KIScaT077265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2010 14:28:38 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7KISb5V012106 for ; Fri, 20 Aug 2010 14:28:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008201828.o7KISb5V012106@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Aug 2010 14:28:37 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Subject: RELENG_8 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: Fri, 20 Aug 2010 18:28:41 -0000 The box is a moderately busy LNS running mpd5. I have another box running the same load that has not crashed so I am wondering if its hardware or this box is just "lucky" ? Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1378af fault code = supervisor read, page not present instruction pointer = 0x20:0xc5ba1190 stack pointer = 0x28:0xe79b784c frame pointer = 0x28:0xe79b7864 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 33060 (mpd5) trap number = 12 panic: page fault cpuid = 1 Uptime: 2d4h49m17s Physical memory: 2036 MB Dumping 228 MB:panic: bufwrite: buffer is not busy??? cpuid = 1 213 197 181 165 149 133 117 101 85 69 53 37 21 5 (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06b0ac3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc06b0d29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc092239c in trap_fatal (frame=0xe79b780c, eva=1276079) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0922620 in trap_pfault (frame=0xe79b780c, usermode=0, eva=1276079) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0922f0c in trap (frame=0xe79b780c) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0904a9c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5ba1190 in ng_ID2noderef (ID=64998) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:811 #8 0xc5ba192b in ng_path2noderef (here=0xc5f3f180, address=0xcac2a800 "[fde6]:", destp=0xe79b7ac0, lasthook=0xe79b7abc) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1679 #9 0xc5ba1d40 in ng_address_path (here=0xc5f3f180, item=0xc5c597c0, address=0xcac2a800 "[fde6]:", retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3536 #10 0xc5b9c662 in ngc_send (so=0xc56e380c, flags=0, m=0xcaee6800, addr=0xca8baca0, control=0x0, td=0xc6298780) at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:296 #11 0xc07111aa in sosend_generic (so=0xc56e380c, addr=0xca8baca0, uio=0xe79b7be8, top=0xcaee6800, control=0x0, flags=0, td=0xc6298780) at /usr/src/sys/kern/uipc_socket.c:1260 #12 0xc070d40f in sosend (so=0xc56e380c, addr=0xca8baca0, uio=0xe79b7be8, top=0x0, control=0x0, flags=0, td=0xc6298780) at /usr/src/sys/kern/uipc_socket.c:1304 #13 0xc0714a47 in kern_sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:788 #14 0xc0714c81 in sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:724 #15 0xc0714d98 in sendto (td=0xc6298780, uap=0xe79b7cf8) at /usr/src/sys/kern/uipc_syscalls.c:840 #16 0xc09228fa in syscall (frame=0xe79b7d38) at /usr/src/sys/i386/i386/trap.c:1111 #17 0xc0904b01 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ---Mike From owner-freebsd-stable@FreeBSD.ORG Fri Aug 20 21:05: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 93AC51065675 for ; Fri, 20 Aug 2010 21:05:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 522D58FC0A for ; Fri, 20 Aug 2010 21:05:03 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7KL50jq089641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2010 17:05:00 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7KL4xi8012899 for ; Fri, 20 Aug 2010 17:04:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008202104.o7KL4xi8012899@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Aug 2010 17:04:59 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Subject: RELENG_8 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: Fri, 20 Aug 2010 21:05:03 -0000 The box is a moderately busy LNS running mpd5. I have another box running the same load that has not crashed so I am wondering if its hardware or this box is just "lucky" ? its crashed a couple of times now, but the watchdog rebooted it prior to the dump being written out. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1378af fault code = supervisor read, page not present instruction pointer = 0x20:0xc5ba1190 stack pointer = 0x28:0xe79b784c frame pointer = 0x28:0xe79b7864 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 33060 (mpd5) trap number = 12 panic: page fault cpuid = 1 Uptime: 2d4h49m17s Physical memory: 2036 MB Dumping 228 MB:panic: bufwrite: buffer is not busy??? cpuid = 1 213 197 181 165 149 133 117 101 85 69 53 37 21 5 (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06b0ac3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc06b0d29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc092239c in trap_fatal (frame=0xe79b780c, eva=1276079) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0922620 in trap_pfault (frame=0xe79b780c, usermode=0, eva=1276079) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0922f0c in trap (frame=0xe79b780c) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0904a9c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc5ba1190 in ng_ID2noderef (ID=64998) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:811 #8 0xc5ba192b in ng_path2noderef (here=0xc5f3f180, address=0xcac2a800 "[fde6]:", destp=0xe79b7ac0, lasthook=0xe79b7abc) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1679 #9 0xc5ba1d40 in ng_address_path (here=0xc5f3f180, item=0xc5c597c0, address=0xcac2a800 "[fde6]:", retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3536 #10 0xc5b9c662 in ngc_send (so=0xc56e380c, flags=0, m=0xcaee6800, addr=0xca8baca0, control=0x0, td=0xc6298780) at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:296 #11 0xc07111aa in sosend_generic (so=0xc56e380c, addr=0xca8baca0, uio=0xe79b7be8, top=0xcaee6800, control=0x0, flags=0, td=0xc6298780) at /usr/src/sys/kern/uipc_socket.c:1260 #12 0xc070d40f in sosend (so=0xc56e380c, addr=0xca8baca0, uio=0xe79b7be8, top=0x0, control=0x0, flags=0, td=0xc6298780) at /usr/src/sys/kern/uipc_socket.c:1304 #13 0xc0714a47 in kern_sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:788 #14 0xc0714c81 in sendit (td=0xc6298780, s=24, mp=0xe79b7c5c, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:724 #15 0xc0714d98 in sendto (td=0xc6298780, uap=0xe79b7cf8) at /usr/src/sys/kern/uipc_syscalls.c:840 #16 0xc09228fa in syscall (frame=0xe79b7d38) at /usr/src/sys/i386/i386/trap.c:1111 #17 0xc0904b01 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:264 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ---Mike From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 04:17: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 0E4961065674 for ; Sat, 21 Aug 2010 04:17:13 +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 BE2D58FC19 for ; Sat, 21 Aug 2010 04:17:12 +0000 (UTC) Received: by iwn36 with SMTP id 36so4167658iwn.13 for ; Fri, 20 Aug 2010 21:17:11 -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:x-enigmail-version :content-type; bh=CGy8YKOXHoajvxNjv3odTB9qRw/0RZZBLVUEdTKaY/k=; b=fc5SUGr6UGsvBzNvt2madbkyAI61DmKs0VS5l07DthD595sjWzNFS+jWHbpNTiviBo H6wsgsx/rpgk12doHKH/s3YtX7p5BeeTkmtAgJT+cLSCIG/tzOBhMC9p9k5VClPMC+aN 4wav4B8+0oABN36r8OZKXBealfk3BjVvfW7kA= 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 :x-enigmail-version:content-type; b=Hvjo94O/QHZ6qr+pE5Omsui0DA9CPGNHbMNa46THxj+gM0EDeG6eGQL7b9Lt8MFUbe agmy0gv9SDkz4j0rXNK5y+aSrALRnGhA9cdoq0X8XC7CqB34Mz0NWtIAQWIcT0tMqCoD V97hGl98MiD5frY5F0gOlHU0lTREwRetzOMAM= Received: by 10.231.15.68 with SMTP id j4mr2530287iba.184.1282364231123; Fri, 20 Aug 2010 21:17:11 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id j2sm3264981iba.6.2010.08.20.21.17.08 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 21:17:10 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C6F5344.6040808@DataIX.net> Date: Sat, 21 Aug 2010 00:17:08 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Alexander Leidinger X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------080104090904040603090909" Cc: FreeBSD Stable Subject: Fwd: daily run output 800.scrub-zfs fixups 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, 21 Aug 2010 04:17:13 -0000 This is a multi-part message in MIME format. --------------080104090904040603090909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Alexander, Attached is a fix for one problem and one slight overlook for 800.scrub-zfs. The first & second change was probably just an oversight but none the less they both give a false impression of actions taken. Change1: ${daily_scrub_zfs_default_threshold=30} is missng the ':' which would ultimately reset the users supplied value in periodic.conf to 30. Change2: ${_scrub_diff} -le ${_pool_threshold} would cause the scrub to be run on the day after the threshold was met. So I changed '-le' -> '-lt' which causes it to be run on the 30th day instead of the 31st day. Regards & Thank you again for merging this to stable/8. PS: If you would like a PR filed for this I can do that just let me know. -------- Original Message -------- Subject: xxxxxx.dataix.local daily run output Date: Fri, 20 Aug 2010 03:18:09 -0400 (EDT) From: Superuser Root To: root@xxxxxx.dataix.local ...snip... Scrubbing of zfs pools: skipping scrubbing of pool 'exports': last scrubbing is 30 days ago, threshold is set to 30 days -- End of daily output -- --------------080104090904040603090909 Content-Type: text/x-patch; name="800.scrub-zfs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="800.scrub-zfs.diff" Index: etc/periodic/daily/800.scrub-zfs =================================================================== --- etc/periodic/daily/800.scrub-zfs (revision 211527) +++ etc/periodic/daily/800.scrub-zfs (working copy) @@ -11,7 +11,7 @@ source_periodic_confs fi -: ${daily_scrub_zfs_default_threshold=30} +: ${daily_scrub_zfs_default_threshold:=30} case "$daily_scrub_zfs_enable" in [Yy][Ee][Ss]) @@ -53,7 +53,7 @@ # Now minus last scrub (both in seconds) converted to days. _scrub_diff=$(expr -e \( $(date +%s) - \ $(date -j -f %F.%T ${_last_scrub} +%s) \) / 60 / 60 / 24) - if [ ${_scrub_diff} -le ${_pool_threshold} ]; then + if [ ${_scrub_diff} -lt ${_pool_threshold} ]; then echo " skipping scrubbing of pool '${pool}':" echo " last scrubbing is ${_scrub_diff} days ago, threshold is set to ${_pool_threshold} days" continue --------------080104090904040603090909 Content-Type: text/plain; name="800.scrub-zfs.diff.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="800.scrub-zfs.diff.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAABAgAGBQJMb07lAAoJEJBXh4mJ2FR+OF8H/RVSV15D0q2JSYjPrjr0dFSR +dD+GOOU4ZZr5cP1oNsodIbc2CiYia6Y/TUVT39WiHF9+Pu/r9EiYG9fxvTVfeIY pHgW5nrrDDnZU8oRNb/2k7vhwaPMXm5UUw9TlqtOL+Cx3ZpprBE2/I8sRrJutOoo Hf5BaVDosmumJtEykI9Xg4Hkwdq18v+FIBVwxPWb0f0aUwnV9OS9XfCM3Quf50OF ba+94EZH/2gQvGrFHb2jH9c2tYZXvtzEpSuFRFEHrbNPVpO6jjPBIQHN9xvmJwD/ 2Pih6QXBIN7cfwvXpEzzbLSlIMHv7bc8Ushi1/0voIi932JJQr5/VY6DwmQvkRU= =M7Vr -----END PGP SIGNATURE----- --------------080104090904040603090909-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 07:54: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 5C1E41065670 for ; Sat, 21 Aug 2010 07:54:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 434558FC13 for ; Sat, 21 Aug 2010 07:54:13 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta08.emeryville.ca.mail.comcast.net with comcast id wvrb1e0010b6N64A8vuDY6; Sat, 21 Aug 2010 07:54:13 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta03.emeryville.ca.mail.comcast.net with comcast id wvuC1e0033LrwQ28PvuDUe; Sat, 21 Aug 2010 07:54:13 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 713589B425; Sat, 21 Aug 2010 00:54:12 -0700 (PDT) Date: Sat, 21 Aug 2010 00:54:12 -0700 From: Jeremy Chadwick To: Mark Morley Message-ID: <20100821075412.GA37192@icarus.home.lan> References: <20100816063550.GA35083@icarus.home.lan> <9c4ecm1t.1282067644@helpdesk.islandnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c4ecm1t.1282067644@helpdesk.islandnet.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable , Jack Vogel Subject: Re: NFS stalling on 8.1-STABLE 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, 21 Aug 2010 07:54:14 -0000 On Tue, Aug 17, 2010 at 10:54:04AM -0700, Mark Morley wrote: > On Sun, 15 Aug 2010 23:35:50 -0700 Jeremy Chadwick wrote: > >On Thu, Aug 12, 2010 at 10:35:49AM -0700, Mark Morley wrote: > >> I have five front end web servers that all mount their content from > >> the same server via NFS. If I stress the link on any one of the > >> machines (eg: copy a large directory with a lot of files to/from the > >> mounted file system) the client will pause. That is, all processes > >> trying to access that mount will freeze. The log files with hundreds > >> or thousands of nfs server not responding / is alive again messages. > >> After 60 seconds it returns to normal, unless the load is still there > >> in which case it continues to pause. > >> > >> This has only started happening since I upgraded the client machines > >> to 8.1-STABLE (previously four of them were 8.0 and one was 7.3). The > >> server is 7.1-RELEASE-p11. No other changes have taken place in terms > >> of hardware or software or mount options, etc. > >> > >> All nics involved are gigabit em cards, and they are on a private > >> network (web access to the boxes is via an external interface). > > > >Are there any indications in dmesg that the NIC is responsible, e.g. > >interface down/up, etc.? > > No, nothing like that. > > >Does switching to UDP-based NFS solve the problem for you? > > Trying that now for the past 24 hours or so. Four of the machine seem ok so far, but the fifth one has started dropping the mount entirely. Access to it gives an "Input / output error" message. Forcing a dismount and remounting brings it back. > > >What OS version (uname -a) and NIC are used on the NFS server? > > FreeBSD xxx 7.1-RELEASE-p11 FreeBSD 7.1-RELEASE-p11 #0: Wed May 26 03:20:59 PDT 2010 > root@xxx:/usr/obj/usr/src/sys/CUSTOM i386 > > NICs are em > > >Can you please provide the following output from one of the client > >machines running 8.1-STABLE with gigE em(4)? You can X-out machine > >names, MAC addresses, and IP addresses/netblocks if need be. > > > >* uname -a > > FreeBSD xxx 8.1-STABLE FreeBSD 8.1-STABLE #0: Tue Jul 27 16:27:44 PDT 2010 > root@xxx:/usr/obj/usr/src/sys/CUSTOM amd64 > > >* ifconfig emX (where X is the interface number which would be > > used for NFS) > > em0: flags=8843 metric 0 mtu 1500 > options=209b > ether 00:0e:0c:85:d5:0d > inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet 1000baseT > status: active > > >* netstat -idn -I emX > > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > em0 1500 00:0e:0c:85:d5:0d 39913814 2 0 39949943 0 0 0 > em0 1500 192.168.1.0/2 192.168.1.30 39944016 - - 39949664 - - - > > >* pciconf -lvc (provide only the data for emX please) > > em0@pci0:1:6:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > > >* vmstat -i > > interrupt total rate > irq1: atkbd0 239 0 > irq16: em0 36746591 883 > irq18: em1 12658607 304 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm ignoring em1 because em0 is the one which has the NFS traffic, and em1 could in fact be a different model of Intel NIC (it's very common for server vendors to include two different models of NIC on the same board; sure, both em(4), but different models), so I'm staying focused on em0. The interrupt rate here looks quite high for a system that may not be doing anything (I don't know for sure). Can you provide output from "netstat -I em0 -n -b 1" and let it run for about 60 seconds? This should be done both when NFS is UDP-only, as well as when NFS is TCP-only. I'm curious what kind of network throughput you're seeing (in attempt to correlate it with high interrupt rates). If network I/O is very low yet the interrupt rate is very high, the problem may be a driver bug or something with PCI configuration/initialisation. I'm also CC'ing Jack Vogel of Intel, who may have some insight to what's going on here. > irq21: ohci0 2 0 > irq22: ehci0 528002 12 > irq23: atapci1 2334936 56 > cpu0: timer 83207296 2000 > cpu1: timer 83207289 2000 > Total 218682962 5256 > > >* sysctl hw.pci > > hw.pci.usb_early_takeover: 1 > hw.pci.honor_msi_blacklist: 1 > hw.pci.enable_msix: 1 > hw.pci.enable_msi: 1 > hw.pci.do_power_resume: 1 > hw.pci.do_power_nodriver: 0 > hw.pci.enable_io_modes: 1 > hw.pci.default_vgapci_unit: -1 > hw.pci.host_mem_start: 2147483648 > hw.pci.mcfg: 1 > > >* As root, run "sysctl dev.em.X.stats=1" then do "dmesg" and > > provide the output for NIC statistics (will start with "emX:") > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 52 > em0: Missed Packets = 0 > em0: Receive No Buffers = 0 > em0: Receive Length Errors = 0 > em0: Receive errors = 1 > em0: Crc errors = 1 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 0 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 54 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 54 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 39915088 > em0: Good Packets Xmtd = 39951839 -- | 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 Aug 21 20:08: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 76AE61065672 for ; Sat, 21 Aug 2010 20:08:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3518E8FC08 for ; Sat, 21 Aug 2010 20:08:33 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3AB23.dip.t-dialin.net [87.179.171.35]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4B20B84400C; Sat, 21 Aug 2010 21:51:01 +0200 (CEST) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 53D0F154C; Sat, 21 Aug 2010 21:50:55 +0200 (CEST) Date: Sat, 21 Aug 2010 21:50:52 +0200 From: Alexander Leidinger To: jhell Message-ID: <20100821215052.000030f1@unknown> In-Reply-To: <4C6F5344.6040808@DataIX.net> References: <4C6F5344.6040808@DataIX.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4B20B84400C.A2CF8 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1283025062.59047@ewcJUXyabt8vWtDJtFf4KQ X-EBL-Spam-Status: No Cc: FreeBSD Stable Subject: Re: daily run output 800.scrub-zfs fixups 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, 21 Aug 2010 20:08:34 -0000 On Sat, 21 Aug 2010 00:17:08 -0400 jhell wrote: > > Hi Alexander, > > Attached is a fix for one problem and one slight overlook for > 800.scrub-zfs. > > The first & second change was probably just an oversight but none the > less they both give a false impression of actions taken. > > Change1: > ${daily_scrub_zfs_default_threshold=30} is missng the ':' > which would ultimately reset the users supplied value in > periodic.conf to 30. I will have a look at this. > Change2: > ${_scrub_diff} -le ${_pool_threshold} would cause the scrub > to be run on the day after the threshold was met. So I changed '-le' > -> '-lt' which causes it to be run on the 30th day instead of the > 31st day. This depends how you define threshold... I had number of days between scrubs in my mind. Now it depends what I wrote in the man page, if it tells what I had in mind (I don't remember, I have to look at it myself, but I'm not a native english speaker, so I may have not wrote it good enough). This is not set in stone, if the majority of people want something else, I'm surely not in the way. Bye, Alexander. > -------- Original Message -------- > Subject: xxxxxx.dataix.local daily run output > Date: Fri, 20 Aug 2010 03:18:09 -0400 (EDT) > From: Superuser Root > To: root@xxxxxx.dataix.local > > ...snip... > > Scrubbing of zfs pools: > skipping scrubbing of pool 'exports': > last scrubbing is 30 days ago, threshold is set to 30 days > > -- End of daily output -- > From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 20:29: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 DBC011065694 for ; Sat, 21 Aug 2010 20:29:47 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6228FC13 for ; Sat, 21 Aug 2010 20:29:47 +0000 (UTC) Received: by yxe42 with SMTP id 42so1973481yxe.13 for ; Sat, 21 Aug 2010 13:29:46 -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:content-type; bh=i+VdIkVfqyTrz0f4OmwI6WE/xyfOy3GgxlhrU85PzxI=; b=irdTeQQhH5fZtiOcXD1vo+GFRxf6+fBQJE2Ogu2q135QFSX6EYEmEtbDwZw+izmQXE 71g7xccQ8+AFIfGr3iHw0WHXk5zy9oGaIGRDOTt3LX51jb4qS98/5kcizItnxa7IGBXj UPbThhOnG/HDTFbvOkFKmPtZV/9JUdF6Z1gqk= 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:content-type; b=JmdrzYhWJa8w/bktnK09e8OFDNe1pLNVltk5YZLjxuaer2pAn4mzerb4yCG2ZEmrGa fS95uOiW2ySKSI3xp1Wn47Li7CpQypsTf2qVj9mnnPuxfchyrLl7GTuxZftjnADXJozP PvECnK7zjwTU1ZQDTjQUQwv2ZRSTvZOagCLkA= Received: by 10.101.212.16 with SMTP id o16mr3448096anq.113.1282422586751; Sat, 21 Aug 2010 13:29:46 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id h5sm7207286anb.8.2010.08.21.13.29.45 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Aug 2010 13:29:45 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C703737.3020007@DataIX.net> Date: Sat, 21 Aug 2010 16:29:43 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Alexander Leidinger References: <4C6F5344.6040808@DataIX.net> <20100821215052.000030f1@unknown> In-Reply-To: <20100821215052.000030f1@unknown> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------030703000401080309080401" Cc: FreeBSD Stable Subject: Re: daily run output 800.scrub-zfs fixups 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, 21 Aug 2010 20:29:47 -0000 This is a multi-part message in MIME format. --------------030703000401080309080401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/21/2010 15:50, Alexander Leidinger wrote: > On Sat, 21 Aug 2010 00:17:08 -0400 jhell wrote: > >> >> Hi Alexander, >> >> Attached is a fix for one problem and one slight overlook for >> 800.scrub-zfs. >> >> The first & second change was probably just an oversight but none the >> less they both give a false impression of actions taken. >> >> Change1: >> ${daily_scrub_zfs_default_threshold=30} is missng the ':' >> which would ultimately reset the users supplied value in >> periodic.conf to 30. > > I will have a look at this. > >> Change2: >> ${_scrub_diff} -le ${_pool_threshold} would cause the scrub >> to be run on the day after the threshold was met. So I changed '-le' >> -> '-lt' which causes it to be run on the 30th day instead of the >> 31st day. > > This depends how you define threshold... I had number of days between > scrubs in my mind. Now it depends what I wrote in the man page, if it > tells what I had in mind (I don't remember, I have to look at it > myself, but I'm not a native english speaker, so I may have not wrote > it good enough). > I believe that people in this case would think that if they set the threshold to 12 days that its going to run on the same day that the threshold was expired and not the 13th. Usually when thresholds are met the commands are fired that same instance and not a day later. > This is not set in stone, if the majority of people want something > else, I'm surely not in the way. > Also I just noticed another confusing message 'at least for me' that said "starting first scrubbing (after reboot) of pool 'exports'". I read that like it is going to scrub the pool after the next reboot. I actually had to open up the script to double check that was not the case. The new attached patch changes the message to "starting scrub of pool 'pool'" so there is no confusion of when the scrub is actually going to happen. Regards, -- jhell,v --------------030703000401080309080401 Content-Type: text/x-patch; name="800.scrub-zfs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="800.scrub-zfs.diff" Index: etc/periodic/daily/800.scrub-zfs =================================================================== --- etc/periodic/daily/800.scrub-zfs (revision 211527) +++ etc/periodic/daily/800.scrub-zfs (working copy) @@ -11,7 +11,7 @@ source_periodic_confs fi -: ${daily_scrub_zfs_default_threshold=30} +: ${daily_scrub_zfs_default_threshold:=30} case "$daily_scrub_zfs_enable" in [Yy][Ee][Ss]) @@ -53,7 +53,7 @@ # Now minus last scrub (both in seconds) converted to days. _scrub_diff=$(expr -e \( $(date +%s) - \ $(date -j -f %F.%T ${_last_scrub} +%s) \) / 60 / 60 / 24) - if [ ${_scrub_diff} -le ${_pool_threshold} ]; then + if [ ${_scrub_diff} -lt ${_pool_threshold} ]; then echo " skipping scrubbing of pool '${pool}':" echo " last scrubbing is ${_scrub_diff} days ago, threshold is set to ${_pool_threshold} days" continue @@ -65,11 +65,11 @@ echo " scrubbing of pool '${pool}' already in progress, skipping:" ;; *"none requested"*) - echo " starting first scrubbing (after reboot) of pool '${pool}':" + echo " starting scrub of pool '${pool}':" zpool scrub ${pool} ;; *) - echo " starting scrubbing of pool '${pool}':" + echo " starting scrub of pool '${pool}':" zpool scrub ${pool} ;; esac --------------030703000401080309080401-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 20:52: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 1EE2F1065694 for ; Sat, 21 Aug 2010 20:52:15 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id DF6E98FC1A for ; Sat, 21 Aug 2010 20:52:14 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 56BDC95BD2 for ; Sat, 21 Aug 2010 20:33:30 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 22:33:24 +0200 Message-Id: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> To: FreeBSD Stable Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: ichwd causes freeze instead of reset 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, 21 Aug 2010 20:52:15 -0000 Hi, somewhat foolishly, I activated watchdogd and ichwd on a remote box, and = while testing it (by suspending watchdogd), apparently the watchdog = triggered. But instead of resetting, the machine does not react anymore = on the serial console. I will have to wait until Monday to get physical = access, so it might be hanging or just switched itself off; I have no = way of telling right now. ichwd probes as: ichwd0: on isa0 ichwd0: Intel ICH7 watchdog timer (ICH7 or equivalent) ppc0: cannot reserve I/O port range (not sure why ppc0 is getting involved at that point.) FreeBSD lokschuppen.zs64.net 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #30: = Thu Jul 15 12:58:20 UTC 2010 = root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 Once the box is up again, is it worthwile trying ichwd again, should I = try and use SW_WATCHDOG, or forget about it? Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 21:02: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 26BCB1065697 for ; Sat, 21 Aug 2010 21:02:45 +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 7133E8FC14 for ; Sat, 21 Aug 2010 21:02:44 +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 AAA20898; Sun, 22 Aug 2010 00:02:41 +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 1OmvD7-000794-Ge; Sun, 22 Aug 2010 00:02:41 +0300 Message-ID: <4C703EF0.3010700@icyb.net.ua> Date: Sun, 22 Aug 2010 00:02:40 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Stefan Bethke References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> In-Reply-To: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: ichwd causes freeze instead of reset 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, 21 Aug 2010 21:02:45 -0000 on 21/08/2010 23:33 Stefan Bethke said the following: > Hi, > > somewhat foolishly, I activated watchdogd and ichwd on a remote box, and > while testing it (by suspending watchdogd), apparently the watchdog > triggered. But instead of resetting, the machine does not react anymore on > the serial console. I will have to wait until Monday to get physical access, > so it might be hanging or just switched itself off; I have no way of telling > right now. > > ichwd probes as: ichwd0: on isa0 ichwd0: Intel > ICH7 watchdog timer (ICH7 or equivalent) ppc0: cannot reserve I/O port range > > (not sure why ppc0 is getting involved at that point.) > > FreeBSD lokschuppen.zs64.net 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #30: Thu > Jul 15 12:58:20 UTC 2010 > root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 > > Once the box is up again, is it worthwile trying ichwd again, should I try > and use SW_WATCHDOG, or forget about it? Just test it more while having physical access before making any conclusions. There could be a number of radically different possibilities ranging from hardware peculiarities to configuration problems to pilot errors to etc. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 21:09: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 0676110656AA for ; Sat, 21 Aug 2010 21:09:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA208FC15 for ; Sat, 21 Aug 2010 21:09:29 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 2AB2395CA0; Sat, 21 Aug 2010 21:09:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <4C703EF0.3010700@icyb.net.ua> Date: Sat, 21 Aug 2010 23:09:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> <4C703EF0.3010700@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Stable Subject: Re: ichwd causes freeze instead of reset 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, 21 Aug 2010 21:09:30 -0000 Am 21.08.2010 um 23:02 schrieb Andriy Gapon: > on 21/08/2010 23:33 Stefan Bethke said the following: >> Hi, >>=20 >> somewhat foolishly, I activated watchdogd and ichwd on a remote box, = and >> while testing it (by suspending watchdogd), apparently the watchdog >> triggered. But instead of resetting, the machine does not react = anymore on >> the serial console. I will have to wait until Monday to get physical = access, >> so it might be hanging or just switched itself off; I have no way of = telling >> right now. >>=20 >> ichwd probes as: ichwd0: on isa0 ichwd0: = Intel >> ICH7 watchdog timer (ICH7 or equivalent) ppc0: cannot reserve I/O = port range >>=20 >> (not sure why ppc0 is getting involved at that point.) >>=20 >> FreeBSD lokschuppen.zs64.net 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE = #30: Thu >> Jul 15 12:58:20 UTC 2010 >> root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 >>=20 >> Once the box is up again, is it worthwile trying ichwd again, should = I try >> and use SW_WATCHDOG, or forget about it? >=20 > Just test it more while having physical access before making any = conclusions. > There could be a number of radically different possibilities ranging = from > hardware peculiarities to configuration problems to pilot errors to = etc. I guess what I'm looking for is some confirmation that ichwd is working = properly on this particular hardware: Asus Pundit P4 P5G41 with a G41 = chipset. Below are pciconv -lvb and dmesg: hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x836d1043 = chip=3D0x2e308086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D HOST-PCI vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x836d1043 = chip=3D0x2e328086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel G41 express graphics = (PCIVEN_8086&DEV_2E32&SUBSYS_31031565&REV_033&115)' class =3D display subclass =3D VGA bar [10] =3D type Memory, range 64, base 0xfe400000, size 4194304, = enabled bar [18] =3D type Prefetchable Memory, range 64, base 0xe0000000, = size 268435456, enabled bar [20] =3D type I/O Port, range 32, base 0xbc00, size 8, = enabled vgapci1@pci0:0:2:1: class=3D0x038000 card=3D0x836d1043 = chip=3D0x2e338086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D display bar [10] =3D type Memory, range 64, base 0xfe800000, size 1048576, = enabled none0@pci0:0:27:0: class=3D0x040300 card=3D0x82fe1043 = chip=3D0x27d88086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'IDT High Definition Audio Driver (BA101897)' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xfe3f8000, size 16384, = enabled pcib1@pci0:0:28:0: class=3D0x060400 card=3D0x81791043 = chip=3D0x27d08086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) PCIe Root Port' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:28:2: class=3D0x060400 card=3D0x81791043 = chip=3D0x27d48086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) PCIe Root Port' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:28:3: class=3D0x060400 card=3D0x81791043 = chip=3D0x27d68086 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) PCIe Root Port' class =3D bridge subclass =3D PCI-PCI uhci0@pci0:0:29:0: class=3D0x0c0300 card=3D0x81791043 = chip=3D0x27c88086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) USB Universal Host Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0xb400, size 32, = enabled uhci1@pci0:0:29:1: class=3D0x0c0300 card=3D0x81791043 = chip=3D0x27c98086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) USB Universal Host Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0xb480, size 32, = enabled uhci2@pci0:0:29:2: class=3D0x0c0300 card=3D0x81791043 = chip=3D0x27ca8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) USB Universal Host Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0xb800, size 32, = enabled uhci3@pci0:0:29:3: class=3D0x0c0300 card=3D0x81791043 = chip=3D0x27cb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) USB Universal Host Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0xb880, size 32, = enabled ehci0@pci0:0:29:7: class=3D0x0c0320 card=3D0x81791043 = chip=3D0x27cc8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) USB 2.0 Enhanced Host = Controller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe3f7c00, size 1024, = enabled pcib4@pci0:0:30:0: class=3D0x060401 card=3D0x81791043 = chip=3D0x244e8086 rev=3D0xe1 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub = Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x81791043 = chip=3D0x27b88086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82801GB/GR (ICH7 Family) LPC Interface = Controller - 27B8 (945GL)' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:31:1: class=3D0x01018a card=3D0x81791043 = chip=3D0x27df8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801G (ICH7 Family) Ultra ATA Storage Controller' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] =3D type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x374, size 1, enabled bar [20] =3D type I/O Port, range 32, base 0xffa0, size 16, = enabled atapci1@pci0:0:31:2: class=3D0x01018f card=3D0x81791043 = chip=3D0x27c08086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801GB/GR/GH (ICH7 Family) Serial ATA Storage = Controller' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0xb080, size 8, = enabled bar [14] =3D type I/O Port, range 32, base 0xb000, size 4, = enabled bar [18] =3D type I/O Port, range 32, base 0xac00, size 8, = enabled bar [1c] =3D type I/O Port, range 32, base 0xa880, size 4, = enabled bar [20] =3D type I/O Port, range 32, base 0xa800, size 16, = enabled none1@pci0:0:31:3: class=3D0x0c0500 card=3D0x81791043 = chip=3D0x27da8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel[R] 82801G (ICH7 Family) C- 27DA (82801G)' class =3D serial bus subclass =3D SMBus bar [20] =3D type I/O Port, range 32, base 0x400, size 32, enabled em0@pci0:3:0:0: class=3D0x020000 card=3D0xa01f8086 chip=3D0x10d38086 = rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82574L Gigabit Ethernet Controller (82574L)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xfebe0000, size 131072, = enabled bar [14] =3D type Memory, range 32, base 0xfeb00000, size 524288, = enabled bar [18] =3D type I/O Port, range 32, base 0xec00, size 32, = enabled bar [1c] =3D type Memory, range 32, base 0xfebdc000, size 16384, = enabled re0@pci0:2:0:0: class=3D0x020000 card=3D0x82c61043 chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class =3D network subclass =3D ethernet bar [10] =3D type I/O Port, range 32, base 0xd800, size 256, = enabled bar [18] =3D type Prefetchable Memory, range 64, base 0xfdfff000, = size 4096, enabled bar [20] =3D type Prefetchable Memory, range 64, base 0xfdfe0000, = size 65536, enabled none2@pci0:1:0:0: class=3D0x0c0010 card=3D0x34011106 = chip=3D0x34011106 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies, Inc.' class =3D serial bus subclass =3D FireWire bar [10] =3D type Memory, range 64, base 0xfe9fe800, size 2048, = enabled bar [18] =3D type I/O Port, range 32, base 0xc800, size 256, = enabled none3@pci0:1:0:1: class=3D0x018000 card=3D0x401a1106 = chip=3D0x401a1106 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies, Inc.' class =3D mass storage bar [10] =3D type Memory, range 64, base 0xfe9ff000, size 2048, = enabled none4@pci0:1:0:2: class=3D0x080501 card=3D0x401b1106 = chip=3D0x401b1106 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies, Inc.' class =3D base peripheral subclass =3D SD host controller bar [10] =3D type Memory, range 64, base 0xfe9ffc00, size 256, = enabled 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-PRERELEASE #30: Thu Jul 15 12:58:20 UTC 2010 root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.65-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 6 Model =3D 17 = Stepping =3D 6 = Features=3D0xbfebfbff = Features2=3D0x8e39d AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 4080877568 (3891 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 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fed1c000, 4000 (3) failed acpi0: reservation of fed20000, 70000 (3) failed acpi0: reservation of ffc00000, 300000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of f0000000, 4000000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddd00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xCC, should be 0xCB = (20100331/tbutils-354) cpu1: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xbc00-0xbc07 mem = 0xfe400000-0xfe7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 32764k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfe800000-0xfe8fffff at device = 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 em0: port 0xec00-0xec1f mem = 0xfebe0000-0xfebfffff,0xfeb00000-0xfeb7ffff,0xfebdc000-0xfebdffff irq 16 = at device 0.0 on pci3 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1b:21:50:0b:f0 pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 re0: port = 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at = device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto re0: Ethernet address: 00:26:18:d5:2c:23 re0: [FILTER] pcib3: irq 19 at device 28.3 on pci0 pci1: on pcib3 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) pci1: at device 0.2 (no driver = attached) uhci0: port 0xb400-0xb41f irq = 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup =3D 0x2f00 usbus0: on uhci0 uhci1: port 0xb480-0xb49f irq = 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup =3D 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq = 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup =3D 0x2f00 usbus2: on uhci2 uhci3: port 0xb880-0xb89f irq = 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup =3D 0x2f00 usbus3: on uhci3 ehci0: mem = 0xfe3f7c00-0xfe3f7fff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port = 0xb080-0xb087,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa80f = irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (115200,n,8,1) orm0: at iomem 0xcc800-0xcd7ff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 ZFS filesystem version 3 ZFS storage pool version 14 Timecounters tick every 1.000 msec 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 ad4: 953869MB at ata2-master UDMA100 SATA 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 SMP: AP CPU #1 Launched! Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 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 ufs:/dev/ad4s1a ugen0.2: at usbus0 uftdi0: on usbus0 =20 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 21:24: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 D1B041065679 for ; Sat, 21 Aug 2010 21:24:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 70FF98FC16 for ; Sat, 21 Aug 2010 21:24:20 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7LLOHmI043923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2010 17:24:17 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7LLOGJP021031; Sat, 21 Aug 2010 17:24:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008212124.o7LLOGJP021031@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Aug 2010 17:24:18 -0400 To: Stefan Bethke , Andriy Gapon From: Mike Tancsa In-Reply-To: <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> <4C703EF0.3010700@icyb.net.ua> <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: FreeBSD Stable Subject: Re: ichwd causes freeze instead of reset 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, 21 Aug 2010 21:24:20 -0000 At 05:09 PM 8/21/2010, Stefan Bethke wrote: >I guess what I'm looking for is some confirmation that ichwd is >working properly on this particular hardware: Asus Pundit P4 P5G41 >with a G41 chipset. > Dont know about that particular MB implementation, but I have a number of various ICH7 based boards where ichwd works as expected. The freeze could some something as simple as the box is waiting for keyboard input at the BIOS prompt, or the BIOS option after a watchdog reset is to power off.... However, I have only seen that option in later boards. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 21:31: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 C82081065693 for ; Sat, 21 Aug 2010 21:31:06 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id 903148FC22 for ; Sat, 21 Aug 2010 21:31:06 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B58C095CF3; Sat, 21 Aug 2010 21:30:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <201008212124.o7LLOGJP021031@lava.sentex.ca> Date: Sat, 21 Aug 2010 23:30:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> <4C703EF0.3010700@icyb.net.ua> <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> <201008212124.o7LLOGJP021031@lava.sentex.ca> To: Mike Tancsa X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Stable , Andriy Gapon Subject: Re: ichwd causes freeze instead of reset 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, 21 Aug 2010 21:31:06 -0000 Am 21.08.2010 um 23:24 schrieb Mike Tancsa: > At 05:09 PM 8/21/2010, Stefan Bethke wrote: >=20 >> I guess what I'm looking for is some confirmation that ichwd is = working properly on this particular hardware: Asus Pundit P4 P5G41 with = a G41 chipset. >>=20 >=20 > Dont know about that particular MB implementation, but I have a number = of various ICH7 based boards where ichwd works as expected. The freeze = could some something as simple as the box is waiting for keyboard input = at the BIOS prompt, or the BIOS option after a watchdog reset is to = power off.... However, I have only seen that option in later boards. Thanks, I'll check that out Monday morning. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 21:33: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 A54961065695 for ; Sat, 21 Aug 2010 21:33:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 89BF18FC19 for ; Sat, 21 Aug 2010 21:33:20 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta02.emeryville.ca.mail.comcast.net with comcast id x9Hz1e0031bwxycA29ZLf4; Sat, 21 Aug 2010 21:33:20 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.emeryville.ca.mail.comcast.net with comcast id x9ZK1e0063LrwQ28e9ZK68; Sat, 21 Aug 2010 21:33:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 103A59B425; Sat, 21 Aug 2010 14:33:19 -0700 (PDT) Date: Sat, 21 Aug 2010 14:33:19 -0700 From: Jeremy Chadwick To: Stefan Bethke Message-ID: <20100821213319.GA58973@icarus.home.lan> References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> <4C703EF0.3010700@icyb.net.ua> <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable , Andriy Gapon Subject: Re: ichwd causes freeze instead of reset 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, 21 Aug 2010 21:33:21 -0000 On Sat, Aug 21, 2010 at 11:09:04PM +0200, Stefan Bethke wrote: > Am 21.08.2010 um 23:02 schrieb Andriy Gapon: > > > on 21/08/2010 23:33 Stefan Bethke said the following: > >> Hi, > >> > >> somewhat foolishly, I activated watchdogd and ichwd on a remote box, and > >> while testing it (by suspending watchdogd), apparently the watchdog > >> triggered. But instead of resetting, the machine does not react anymore on > >> the serial console. I will have to wait until Monday to get physical access, > >> so it might be hanging or just switched itself off; I have no way of telling > >> right now. > >> > >> ichwd probes as: ichwd0: on isa0 ichwd0: Intel > >> ICH7 watchdog timer (ICH7 or equivalent) ppc0: cannot reserve I/O port range > >> > >> (not sure why ppc0 is getting involved at that point.) > >> > >> FreeBSD lokschuppen.zs64.net 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #30: Thu > >> Jul 15 12:58:20 UTC 2010 > >> root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 > >> > >> Once the box is up again, is it worthwile trying ichwd again, should I try > >> and use SW_WATCHDOG, or forget about it? > > > > Just test it more while having physical access before making any conclusions. > > There could be a number of radically different possibilities ranging from > > hardware peculiarities to configuration problems to pilot errors to etc. > > I guess what I'm looking for is some confirmation that ichwd is working properly on this particular hardware: Asus Pundit P4 P5G41 with a G41 chipset. > > Below are pciconv -lvb and dmesg: > > hostb0@pci0:0:0:0: class=0x060000 card=0x836d1043 chip=0x2e308086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:0:2:0: class=0x030000 card=0x836d1043 chip=0x2e328086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel G41 express graphics (PCIVEN_8086&DEV_2E32&SUBSYS_31031565&REV_033&115)' > class = display > subclass = VGA > bar [10] = type Memory, range 64, base 0xfe400000, size 4194304, enabled > bar [18] = type Prefetchable Memory, range 64, base 0xe0000000, size 268435456, enabled > bar [20] = type I/O Port, range 32, base 0xbc00, size 8, enabled > vgapci1@pci0:0:2:1: class=0x038000 card=0x836d1043 chip=0x2e338086 rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > class = display > bar [10] = type Memory, range 64, base 0xfe800000, size 1048576, enabled > none0@pci0:0:27:0: class=0x040300 card=0x82fe1043 chip=0x27d88086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'IDT High Definition Audio Driver (BA101897)' > class = multimedia > subclass = HDA > bar [10] = type Memory, range 64, base 0xfe3f8000, size 16384, enabled > pcib1@pci0:0:28:0: class=0x060400 card=0x81791043 chip=0x27d08086 rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:28:2: class=0x060400 card=0x81791043 chip=0x27d48086 rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:28:3: class=0x060400 card=0x81791043 chip=0x27d68086 rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCIe Root Port' > class = bridge > subclass = PCI-PCI > uhci0@pci0:0:29:0: class=0x0c0300 card=0x81791043 chip=0x27c88086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0xb400, size 32, enabled > uhci1@pci0:0:29:1: class=0x0c0300 card=0x81791043 chip=0x27c98086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0xb480, size 32, enabled > uhci2@pci0:0:29:2: class=0x0c0300 card=0x81791043 chip=0x27ca8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0xb800, size 32, enabled > uhci3@pci0:0:29:3: class=0x0c0300 card=0x81791043 chip=0x27cb8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0xb880, size 32, enabled > ehci0@pci0:0:29:7: class=0x0c0320 card=0x81791043 chip=0x27cc8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xfe3f7c00, size 1024, enabled > pcib4@pci0:0:30:0: class=0x060401 card=0x81791043 chip=0x244e8086 rev=0xe1 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:31:0: class=0x060100 card=0x81791043 chip=0x27b88086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82801GB/GR (ICH7 Family) LPC Interface Controller - 27B8 (945GL)' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:31:1: class=0x01018a card=0x81791043 chip=0x27df8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled > bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled > bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled > bar [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled > atapci1@pci0:0:31:2: class=0x01018f card=0x81791043 chip=0x27c08086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' > class = mass storage > subclass = ATA > bar [10] = type I/O Port, range 32, base 0xb080, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xac00, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xa880, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xa800, size 16, enabled > none1@pci0:0:31:3: class=0x0c0500 card=0x81791043 chip=0x27da8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel[R] 82801G (ICH7 Family) C- 27DA (82801G)' > class = serial bus > subclass = SMBus > bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled > em0@pci0:3:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xfebe0000, size 131072, enabled > bar [14] = type Memory, range 32, base 0xfeb00000, size 524288, enabled > bar [18] = type I/O Port, range 32, base 0xec00, size 32, enabled > bar [1c] = type Memory, range 32, base 0xfebdc000, size 16384, enabled > re0@pci0:2:0:0: class=0x020000 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled > bar [18] = type Prefetchable Memory, range 64, base 0xfdfff000, size 4096, enabled > bar [20] = type Prefetchable Memory, range 64, base 0xfdfe0000, size 65536, enabled > none2@pci0:1:0:0: class=0x0c0010 card=0x34011106 chip=0x34011106 rev=0x00 hdr=0x00 > vendor = 'VIA Technologies, Inc.' > class = serial bus > subclass = FireWire > bar [10] = type Memory, range 64, base 0xfe9fe800, size 2048, enabled > bar [18] = type I/O Port, range 32, base 0xc800, size 256, enabled > none3@pci0:1:0:1: class=0x018000 card=0x401a1106 chip=0x401a1106 rev=0x00 hdr=0x00 > vendor = 'VIA Technologies, Inc.' > class = mass storage > bar [10] = type Memory, range 64, base 0xfe9ff000, size 2048, enabled > none4@pci0:1:0:2: class=0x080501 card=0x401b1106 chip=0x401b1106 rev=0x00 hdr=0x00 > vendor = 'VIA Technologies, Inc.' > class = base peripheral > subclass = SD host controller > bar [10] = type Memory, range 64, base 0xfe9ffc00, size 256, enabled > > 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-PRERELEASE #30: Thu Jul 15 12:58:20 UTC 2010 > root@lokschuppen.zs64.net:/usr/obj/usr/src/sys/EISENBOOT amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.65-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 > Features=0xbfebfbff > Features2=0x8e39d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 4080877568 (3891 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 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of fed1c000, 4000 (3) failed > acpi0: reservation of fed20000, 70000 (3) failed > acpi0: reservation of ffc00000, 300000 (3) failed > acpi0: reservation of fec00000, 1000 (3) failed > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of f0000000, 4000000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, ddd00000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0xCC, should be 0xCB (20100331/tbutils-354) > cpu1: on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0xbc00-0xbc07 mem 0xfe400000-0xfe7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: detected 32764k stolen memory > agp0: aperture size is 256M > vgapci1: mem 0xfe800000-0xfe8fffff at device 2.1 on pci0 > pci0: at device 27.0 (no driver attached) > pcib1: irq 16 at device 28.0 on pci0 > pci3: on pcib1 > em0: port 0xec00-0xec1f mem 0xfebe0000-0xfebfffff,0xfeb00000-0xfeb7ffff,0xfebdc000-0xfebdffff irq 16 at device 0.0 on pci3 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:1b:21:50:0b:f0 > pcib2: irq 18 at device 28.2 on pci0 > pci2: on pcib2 > re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:26:18:d5:2c:23 > re0: [FILTER] > pcib3: irq 19 at device 28.3 on pci0 > pci1: on pcib3 > pci1: at device 0.0 (no driver attached) > pci1: at device 0.1 (no driver attached) > pci1: at device 0.2 (no driver attached) > uhci0: port 0xb400-0xb41f irq 23 at device 29.0 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x2f00 > usbus0: on uhci0 > uhci1: port 0xb480-0xb49f irq 19 at device 29.1 on pci0 > uhci1: [ITHREAD] > uhci1: LegSup = 0x2f00 > usbus1: on uhci1 > uhci2: port 0xb800-0xb81f irq 18 at device 29.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup = 0x2f00 > usbus2: on uhci2 > uhci3: port 0xb880-0xb89f irq 16 at device 29.3 on pci0 > uhci3: [ITHREAD] > uhci3: LegSup = 0x2f00 > usbus3: on uhci3 > ehci0: mem 0xfe3f7c00-0xfe3f7fff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > atapci1: port 0xb080-0xb087,0xb000-0xb003,0xac00-0xac07,0xa880-0xa883,0xa800-0xa80f irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (115200,n,8,1) > orm0: at iomem 0xcc800-0xcd7ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > 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 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > 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 > ZFS filesystem version 3 > ZFS storage pool version 14 > Timecounters tick every 1.000 msec > 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 > ad4: 953869MB at ata2-master UDMA100 SATA > 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 > SMP: AP CPU #1 Launched! > Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 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 ufs:/dev/ad4s1a > ugen0.2: at usbus0 > uftdi0: on usbus0 This dmesg + pciconf -lvc doesn't show any signs of ichwd in use. I can confirm that ichwd(4) works fine on the following system types: - Supermicro SuperServer 5015M-T+ (Intel ICH7R-based) - Supermicro SuperServer 5015B-MT (Intel ICH9R-based) - Supermicro X7SBA motherboard (Intel ICH9R-based) - Supermicro X7SBL-LN2 motherboard (Intel ICH9R-based) The Asus P5G41 looks like a workstation-class board[1]. I wouldn't be surprised if certain configuration bits aren't being set by the system BIOS or during the manufacturing process by Asus for this reason. All in all, I really wouldn't worry about ichwd(4) not working for you. If your system randomly locks up, you try to investigate the root cause and solve it. Hardware watchdogs are usually a server-focused feature. Regarding SW_WATCHDOG, it doesn't work on SMP systems, which yours is. So don't bother. [1]: http://commercial.asus.com/product/detail/18 -- | 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 Aug 21 21:37: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 A00671065670 for ; Sat, 21 Aug 2010 21:37:15 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (unknown [IPv6:2607:f3e0:80:80::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9158FC15 for ; Sat, 21 Aug 2010 21:37:15 +0000 (UTC) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.4/8.14.4) with ESMTP id o7LLbCwn044351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2010 17:37:12 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o7LLbBKP021092; Sat, 21 Aug 2010 17:37:11 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201008212137.o7LLbBKP021092@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Aug 2010 17:37:11 -0400 To: Andriy Gapon From: Mike Tancsa In-Reply-To: <201008212124.o7LLOGJP021031@lava.sentex.ca> References: <2EF737B3-0FC2-425A-9CE6-07129C12D5B5@lassitu.de> <4C703EF0.3010700@icyb.net.ua> <03633C32-1E0F-49DF-8B3B-83FEECE345E3@lassitu.de> <201008212124.o7LLOGJP021031@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 205.211.164.50 Cc: FreeBSD Stable Subject: Re: i5 boards and ichwd 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, 21 Aug 2010 21:37:15 -0000 Speaking of ichwd, has anyone gotten ichwd to work with Intel's S3420GPC boards? http://www.intel.com/p/en_US/support/highlights/server/s3420gp isab0@pci0:0:31:0: class=0x060100 card=0x34ec8086 chip=0x3b148086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 16) Intel cap 1 version 1 I tried adding #define DEVICEID_3420 0x3b14 to the driver, but no luck ichwd module loaded ichwd0: on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ppc0: parallel port not found. CPU: Intel(R) Core(TM) i5 CPU S 750 @ 2.40GHz (2399.99-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 2585460736 (2465 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ---Mike At 05:24 PM 8/21/2010, Mike Tancsa wrote: >At 05:09 PM 8/21/2010, Stefan Bethke wrote: > >>I guess what I'm looking for is some confirmation that ichwd is >>working properly on this particular hardware: Asus Pundit P4 P5G41 >>with a G41 chipset. > >Dont know about that particular MB implementation, but I have a >number of various ICH7 based boards where ichwd works as >expected. The freeze could some something as simple as the box is >waiting for keyboard input at the BIOS prompt, or the BIOS option >after a watchdog reset is to power off.... However, I have only seen >that option in later boards. > > ---Mike > > > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike@sentex.net >Providing Internet since 1994 www.sentex.net >Cambridge, Ontario Canada www.sentex.net/mike > >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 22:04: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 0BEC61065672 for ; Sat, 21 Aug 2010 22:04:37 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 40C908FC12 for ; Sat, 21 Aug 2010 22:04:36 +0000 (UTC) Received: from [2a01:348:132:51::10] (helo=carrick-users) by carrick.bishnet.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmwB1-0001mg-EE for freebsd-stable@FreeBSD.org; Sat, 21 Aug 2010 23:04:35 +0100 Received: (from tdb@localhost) by carrick-users (8.14.4/8.14.4/Submit) id o7LM4Z4J006861 for freebsd-stable@FreeBSD.org; Sat, 21 Aug 2010 23:04:35 +0100 (BST) (envelope-from tdb) Date: Sat, 21 Aug 2010 23:04:35 +0100 From: Tim Bishop To: freebsd-stable@FreeBSD.org Message-ID: <20100821220435.GA6208@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: 8.1R ZFS almost locking up system 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, 21 Aug 2010 22:04:37 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems that ZFS gets in to an almost unresponsive state. Last time it did it (two weeks ago) I couldn't even log in, although the system was up, this time I could manage a reboot but couldn't stop any applications (they were likely hanging on I/O). Here's some details I collected prior to reboot. The zpool output, including iostat and gstat for the disks: # zpool status pool: pool0 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4s3 ONLINE 0 0 0 ad6s3 ONLINE 0 0 0 errors: No known data errors # zpool iostat -v 5 ... capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- pool0 117G 16.7G 248 114 865K 269K mirror 117G 16.7G 248 114 865K 269K ad4s3 - - 43 56 2.47M 269K ad6s3 - - 39 56 2.41M 269K ---------- ----- ----- ----- ----- ----- ----- # gstat ... L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1 48 48 3042 9.8 0 0 0.0 47.6| ad4 0 38 38 2406 10.5 0 0 0.0 39.5| ad6 0 0 0 0 0.0 0 0 0.0 0.0| ad4s1 0 0 0 0 0.0 0 0 0.0 0.0| ad4s2 1 48 48 3042 9.8 0 0 0.0 47.6| ad4s3 0 0 0 0 0.0 0 0 0.0 0.0| ad6s1 0 0 0 0 0.0 0 0 0.0 0.0| ad6s2 0 38 38 2406 11.8 0 0 0.0 44.4| ad6s3 I've seen this before when I've had poor ZFS performance. There's more I/O on the disks than on the pool itself. It's not particularly busy though. A few items from top, including zfskern: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs At some point during this process my zfs snapshots have been failing to complete: root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d It all seems to point at ZFS getting to the point of being almost unresponsive. It's been exactly two weeks since the last time this happened and therefore the last reboot, so it'll be interesting to see if the same happens again after the same period of time. I noticed this given in a few other ZFS related messages: vfs.worklist_len: 15 I have attached all (hopefully) ZFS-related sysctl output. Finally, the reboot log: Aug 21 22:13:06 server kernel: Aug 21 22:13:06 server reboot: rebooted by tdb Aug 21 22:19:47 server kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Aug 21 22:19:47 server kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop... Aug 21 22:19:48 server kernel: done Aug 21 22:19:48 server kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Aug 21 22:20:03 server kernel: Aug 21 22:20:03 server kernel: Syncing disks, vnodes remaining...14 Aug 21 22:20:48 server kernel: timed out Aug 21 22:21:55 server kernel: Waiting (max 60 seconds) for system process `vnlru' to stop... Aug 21 22:22:39 server kernel: 1 Aug 21 22:22:55 server kernel: timed out Aug 21 22:22:55 server kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop... I've undoubtedly missed some important information, so please let me know if there's anything more useful I can collect next time (I'm quite sure it'll happen again). Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=sysctl-zfs-out vfs.zfs.l2c_only_size: 0 vfs.zfs.mfu_ghost_data_lsize: 40245248 vfs.zfs.mfu_ghost_metadata_lsize: 87331328 vfs.zfs.mfu_ghost_size: 127576576 vfs.zfs.mfu_data_lsize: 99885056 vfs.zfs.mfu_metadata_lsize: 146944 vfs.zfs.mfu_size: 101330432 vfs.zfs.mru_ghost_data_lsize: 181200896 vfs.zfs.mru_ghost_metadata_lsize: 25819648 vfs.zfs.mru_ghost_size: 207020544 vfs.zfs.mru_data_lsize: 351579136 vfs.zfs.mru_metadata_lsize: 0 vfs.zfs.mru_size: 419203072 vfs.zfs.anon_data_lsize: 0 vfs.zfs.anon_metadata_lsize: 0 vfs.zfs.anon_size: 16982016 vfs.zfs.l2arc_norw: 1 vfs.zfs.l2arc_feed_again: 1 vfs.zfs.l2arc_noprefetch: 0 vfs.zfs.l2arc_feed_min_ms: 200 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 2 vfs.zfs.l2arc_write_boost: 8388608 vfs.zfs.l2arc_write_max: 8388608 vfs.zfs.arc_meta_limit: 162276480 vfs.zfs.arc_meta_used: 167108904 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 81138240 vfs.zfs.arc_max: 649105920 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.check_hostid: 1 vfs.zfs.recover: 0 vfs.zfs.txg.write_limit_override: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.zio.use_uma: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 14 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.zfetchstats.hits: 0 kstat.zfs.misc.zfetchstats.misses: 0 kstat.zfs.misc.zfetchstats.colinear_hits: 0 kstat.zfs.misc.zfetchstats.colinear_misses: 0 kstat.zfs.misc.zfetchstats.stride_hits: 0 kstat.zfs.misc.zfetchstats.stride_misses: 0 kstat.zfs.misc.zfetchstats.reclaim_successes: 0 kstat.zfs.misc.zfetchstats.reclaim_failures: 0 kstat.zfs.misc.zfetchstats.streams_resets: 0 kstat.zfs.misc.zfetchstats.streams_noresets: 0 kstat.zfs.misc.zfetchstats.bogus_streams: 0 kstat.zfs.misc.arcstats.hits: 268465432 kstat.zfs.misc.arcstats.misses: 68288918 kstat.zfs.misc.arcstats.demand_data_hits: 96018646 kstat.zfs.misc.arcstats.demand_data_misses: 29346057 kstat.zfs.misc.arcstats.demand_metadata_hits: 172436107 kstat.zfs.misc.arcstats.demand_metadata_misses: 38917800 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 10679 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 25061 kstat.zfs.misc.arcstats.mru_hits: 50140760 kstat.zfs.misc.arcstats.mru_ghost_hits: 3740247 kstat.zfs.misc.arcstats.mfu_hits: 218317059 kstat.zfs.misc.arcstats.mfu_ghost_hits: 25731748 kstat.zfs.misc.arcstats.allocated: 74130663 kstat.zfs.misc.arcstats.deleted: 40615278 kstat.zfs.misc.arcstats.stolen: 31781579 kstat.zfs.misc.arcstats.recycle_miss: 26118118 kstat.zfs.misc.arcstats.mutex_miss: 69832 kstat.zfs.misc.arcstats.evict_skip: 315025656 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 1987022682112 kstat.zfs.misc.arcstats.evict_l2_ineligible: 63680512 kstat.zfs.misc.arcstats.hash_elements: 44157 kstat.zfs.misc.arcstats.hash_elements_max: 206842 kstat.zfs.misc.arcstats.hash_collisions: 24859197 kstat.zfs.misc.arcstats.hash_chains: 9616 kstat.zfs.misc.arcstats.hash_chain_max: 22 kstat.zfs.misc.arcstats.p: 40774359 kstat.zfs.misc.arcstats.c: 628821360 kstat.zfs.misc.arcstats.c_min: 81138240 kstat.zfs.misc.arcstats.c_max: 649105920 kstat.zfs.misc.arcstats.size: 628128200 kstat.zfs.misc.arcstats.hdr_size: 10035104 kstat.zfs.misc.arcstats.data_size: 537511936 kstat.zfs.misc.arcstats.other_size: 80581160 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 4236474 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 62188 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 16993 kstat.zfs.misc.vdev_cache_stats.hits: 27480802 kstat.zfs.misc.vdev_cache_stats.misses: 10351041 --J2SCkAp4GZ/dPZZf-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 21 22:56: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 8F27610656A8 for ; Sat, 21 Aug 2010 22:56:30 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 3C93F8FC0C for ; Sat, 21 Aug 2010 22:56:29 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o7LMOTHQ097456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2010 17:24:29 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o7LMOTHo019385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2010 17:24:29 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o7LMOTh9019384; Sat, 21 Aug 2010 17:24:29 -0500 (CDT) (envelope-from dan) Date: Sat, 21 Aug 2010 17:24:29 -0500 From: Dan Nelson To: Tim Bishop Message-ID: <20100821222429.GB73221@dan.emsphone.com> References: <20100821220435.GA6208@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100821220435.GA6208@carrick-users.bishnet.net> X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sat, 21 Aug 2010 17:24:30 -0500 (CDT) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1R ZFS almost locking up system 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, 21 Aug 2010 22:56:30 -0000 In the last episode (Aug 21), Tim Bishop said: > I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems > that ZFS gets in to an almost unresponsive state. Last time it did it > (two weeks ago) I couldn't even log in, although the system was up, this > time I could manage a reboot but couldn't stop any applications (they > were likely hanging on I/O). Could your pool be very close to full? Zfs will throttle itself when it's almost out of disk space. I know it's "saved" me from filling up my filesystems a couple times :) > A few items from top, including zfskern: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 5 root 4 -8 - 0K 60K zio->i 0 54:38 3.47% zfskern > 91775 70 1 44 0 53040K 31144K tx->tx 1 2:11 0.00% postgres > 39661 tdb 1 44 0 55776K 32968K tx->tx 0 0:39 0.00% mutt > 14828 root 1 47 0 14636K 1572K tx->tx 1 0:03 0.00% zfs > 11188 root 1 51 0 14636K 1572K tx->tx 0 0:03 0.00% zfs > > At some point during this process my zfs snapshots have been failing to > complete: > > root 5 0.8 0.0 0 60 ?? DL 7Aug10 54:43.83 [zfskern] > root 8265 0.0 0.0 14636 1528 ?? D 10:00AM 0:03.12 zfs snapshot -r pool0@2010-08-21_10:00:01--1d > root 11188 0.0 0.1 14636 1572 ?? D 11:00AM 0:02.93 zfs snapshot -r pool0@2010-08-21_11:00:01--1d > root 14828 0.0 0.1 14636 1572 ?? D 12:00PM 0:03.04 zfs snapshot -r pool0@2010-08-21_12:00:00--1d > root 17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r pool0@2010-08-21_13:00:01--1d > root 20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r pool0@2010-08-21_14:00:01--1d procstat -k on some of these processes might help to pinpoint what part of the zfs code they're all waiting in. -- Dan Nelson dnelson@allantgroup.com