From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 04:00:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E288A405 for ; Sun, 31 Mar 2013 04:00:30 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id A52CD86D for ; Sun, 31 Mar 2013 04:00:30 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ha11so1502665vcb.2 for ; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j3lEfUgl3ENIkRJe1asq24n4ZDTwwnC7JLLuXafk/pE=; b=CI+JNeVQ4WyrhFfGG539oN7s2qRlCq9fkBckNwKmZ4O1sSK84GeKWpvIXFnrr7i1ln +OYPeGVZaPjct55QdCJsKEkjsKMIFZ4GUVu7p2vuYC/ex6+buOCx+A+hdpdbjatrv1/b vhd24ZCieI3qvtn6FDYbX+72WTy+YdTplHqXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=j3lEfUgl3ENIkRJe1asq24n4ZDTwwnC7JLLuXafk/pE=; b=NTlVEYsyqWVB/AHE0UkcPF/V/AddhPZnFyd0ANCM9JSk8PrQ+mroDHusyEDAW6pTaC J61NQcfrsiNt+rf5Bi+YvK0fQ/0d0iIXPXp3XHqmj2xoYgQWlcyVEjXH/At8egaJn4xB Ag+HYeFC2M+Fbgl/bupGFSLeeznT1ky0GQ38L69kF5bVuE+J0EmPnxApbrJnBVLAhif1 Wrjw37luKva1Yca5UqzzFd7FBl3h6AxQZZQSBeksyDbQYhGUeGeztP+Do4R8CdzR9j0Q iEA+EyLQ2L8RYLdSmELlGMmvsM31dwSjmcobKb1FUGG5yWhMkC+d1hecGipC6cqX+WJM bb4w== MIME-Version: 1.0 X-Received: by 10.52.35.110 with SMTP id g14mr4933384vdj.61.1364702424376; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) Received: by 10.221.11.72 with HTTP; Sat, 30 Mar 2013 21:00:24 -0700 (PDT) In-Reply-To: <5157756F.4040908@FreeBSD.org> References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> Date: Sat, 30 Mar 2013 21:00:24 -0700 Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Peter Wemm To: Matthias Andree Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmu9vCGOAZ/Un44Oybg3bkr5plOxFEXfxYXc02wzrzbhG7CWxBMpLkyGRJkg5dcEKB19o/3 Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 04:00:30 -0000 On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote: > Am 27.03.2013 22:22, schrieb Alexander Motin: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >> stack, using only some controller drivers of old ata(4) by having >> `options ATA_CAM` enabled in all kernels by default. I have a wish to >> drop non-ATA_CAM ata(4) code, unused since that time from the head >> branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built >> without `options ATA_CAM`) for some reason, for example as workaround >> for some regression? Does anybody have good ideas why we should not drop >> it now? > > Alexander, > > The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 > where the SATA NCQ slots stall for some Samsung drives in the new stack, > and consequently hang the computer for prolonged episodes where it is in > the NCQ error handling, disallows removal of the old driver. (Last > checked with 9.1-RELEASE at current patchlevel.) We're talking about 10.x, so if you want it fixed, you need update with 10.x information. Please put 10.x diagnostics in the PR. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 05:20:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56989CE6; Sun, 31 Mar 2013 05:20:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id BCD44A32; Sun, 31 Mar 2013 05:20:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r2V5Duap039581; Sun, 31 Mar 2013 16:13:57 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 31 Mar 2013 16:13:56 +1100 (EST) From: Ian Smith To: Peter Wemm Subject: Re: Any objections/comments on axing out old ATA stack? In-Reply-To: Message-ID: <20130331160157.G36471@sola.nimnet.asn.au> References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alexander Motin , freebsd-stable@freebsd.org, Matthias Andree X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 05:20:11 -0000 On Sat, 30 Mar 2013 21:00:24 -0700, Peter Wemm wrote: > On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote: > > Am 27.03.2013 22:22, schrieb Alexander Motin: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Alexander, > > > > The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 > > where the SATA NCQ slots stall for some Samsung drives in the new stack, > > and consequently hang the computer for prolonged episodes where it is in > > the NCQ error handling, disallows removal of the old driver. (Last > > checked with 9.1-RELEASE at current patchlevel.) > > We're talking about 10.x, so if you want it fixed, you need update > with 10.x information. > > Please put 10.x diagnostics in the PR. Given Alexander also posted this to -stable, just for clarity, are we _only_ talking about 10.x here, or might this change get MFC'd to 9? cheers, Ian (dropping -current as I'm not subscribed so would only get bounced) From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 09:30:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65CE1106; Sun, 31 Mar 2013 09:30:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id C91622C3; Sun, 31 Mar 2013 09:30:03 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b15so726582eek.21 for ; Sun, 31 Mar 2013 02:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nGyuimu7oPNSnlJu5IhuDpDDqSMsVdSLmG6nI6NwDtY=; b=eXIBJ28eBZuzXcwkP6Vpu9ONyOPbIUaIGHFSLoJ9qrpcos91K1dKHPlX/sNQBnY1Xp vrakGzviKdj96eB6xOF/8VzU8a+ooaDta2DeJJI8l6tmtSZA0cd9UKWiY0XvrmAs2Dm4 0Xde3hsMhFkeKKPnSp8oXO6TKwj59hcSPrnwKWOt8BvxqZrgItSK5yLg/80lhPlAh5GZ wQ75CP+FFEbK/nItj4EmXepLopuhNew21mf3qY1rkEdzJcb9zbVLMg9ic546e6VlgYlt eDTNfrVPQ/1hifvcj6Rdhy5hIIbVORXv0dfVkQ/i2aWqEalJbwW1GlD5b+sQAFM1ZWBD aCpA== X-Received: by 10.14.183.198 with SMTP id q46mr26109106eem.1.1364722196577; Sun, 31 Mar 2013 02:29:56 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id 44sm14550209eek.5.2013.03.31.02.29.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 02:29:55 -0700 (PDT) Sender: Alexander Motin Message-ID: <5157F401.1080609@FreeBSD.org> Date: Sun, 31 Mar 2013 11:29:53 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Smith Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> <20130331160157.G36471@sola.nimnet.asn.au> In-Reply-To: <20130331160157.G36471@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Matthias Andree , Peter Wemm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 09:30:04 -0000 On 31.03.2013 08:13, Ian Smith wrote: > On Sat, 30 Mar 2013 21:00:24 -0700, Peter Wemm wrote: > > On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote: > > > Am 27.03.2013 22:22, schrieb Alexander Motin: > > >> Hi. > > >> > > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > > >> stack, using only some controller drivers of old ata(4) by having > > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > > >> branch to allow further ATA code cleanup. > > >> > > >> Does any one here still uses legacy ATA stack (kernel explicitly built > > >> without `options ATA_CAM`) for some reason, for example as workaround > > >> for some regression? Does anybody have good ideas why we should not drop > > >> it now? > > > > > > Alexander, > > > > > > The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 > > > where the SATA NCQ slots stall for some Samsung drives in the new stack, > > > and consequently hang the computer for prolonged episodes where it is in > > > the NCQ error handling, disallows removal of the old driver. (Last > > > checked with 9.1-RELEASE at current patchlevel.) > > > > We're talking about 10.x, so if you want it fixed, you need update > > with 10.x information. > > > > Please put 10.x diagnostics in the PR. > > Given Alexander also posted this to -stable, just for clarity, are we > _only_ talking about 10.x here, or might this change get MFC'd to 9? Yes, I am only going to drop it from 10.x, but bug reports from 9-STABLE users are welcome, as at some point they will become 10.x users. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 09:53:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BD482B9 for ; Sun, 31 Mar 2013 09:53:02 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id B6277345 for ; Sun, 31 Mar 2013 09:53:01 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id t10so701247eei.6 for ; Sun, 31 Mar 2013 02:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qYm4XASuNSzi2ETyl8Kh1UkH7zicL0tBsq64aN9iAfs=; b=APJ3s2lPrlWKzm7cp139Mwq+146cBMEpc3AQy5gG5VvbPoYaYZsHXpyJf+o84LgPgk Z+F5Vwu/j8QCZLRBlrtUxobS9P/ebVqC5tH8RMU20b01gJ3S3dCAEtwDesMRv3Lds/zo cVwVSCRq9lxRylfCNAfJ/ZXL/cIzYyzpWGollZBR0j8rjyy4A2DMIpH0TK7CCzi36bmN 24P3f9yRWLGNorA4YnymzqY+3kAOHlE3KTqPZP4uep2QCFU0/+MP74CkqqKaaL9BSaAG ecyWqvr2DomRZRs1PuR3/GVxEvPmGgqNLSKQ1/0U5/S0lij34cW1SJqOzoQjEz+IFMs3 opxQ== X-Received: by 10.14.218.71 with SMTP id j47mr25782767eep.28.1364723574144; Sun, 31 Mar 2013 02:52:54 -0700 (PDT) Received: from mkushnir.zapto.org (159-73-132-95.pool.ukrtel.net. [95.132.73.159]) by mx.google.com with ESMTPS id bc1sm14583327eeb.11.2013.03.31.02.52.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 02:52:53 -0700 (PDT) Message-ID: <51580718.1010501@gmail.com> Date: Sun, 31 Mar 2013 12:51:20 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <513E2DA5.70200@mac.com> <514E7927.2010901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 09:53:02 -0000 On 25.03.2013 02:55, John Mehr wrote: > > > > On Sun, 24 Mar 2013 05:55:19 +0200 > Markiyan Kushnir wrote: >> Hello John, >> >> Tested svnup for a while, and I can say it does its job well, and >> works basically as I would expect, so thanks for your initiative. >> Although it appears to be quite resource greedy. Most of the time it >> showed something like: >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% >> a.out >> >> >> I looked at the source code, and found that it uses svn commands that >> are known as the "main command set". The program is implemented around >> get-dir and get-file. I think there is significant room for resource >> and performance improvement. >> >> Have you considered an approach to use what svn folks call the editor >> command set? I mean acting as a trivial svn client: we might ask the >> server to drive our checking out or updating. The server will be >> telling us only diffs. Checking out a full tree would be just another >> diff, although bigger than usually. We would also benefit from >> compression on the wire. >> >> Another advantage would be to always have consistent repo more-or-less >> guaranteed by the svn server. >> >> I've done some proof of concept recently, and the results look >> encouraging to me. For example, a do-nothing update really does >> nothing. A two-or-three revisions update takes a couple of seconds. >> And a full checkout of the base/stable/9 takes ~7m30s at 530kB/s to me. > > Hello, > > The results I was getting from testing out the svn protocol's editor > command set were unpleasant enough to put it into the "come back to this > later" category while I worked on implementing the http/https side. The > good news it that the http side is *much* easier to work with in this > respect and getting a report with filenames and MD5/SHA-1 signatures for > all of the files in the repository can be obtained all at once. I > should have a new and improved version ready to go this weekend or early > next week at the latest. Hi again! Yes, I agree that svn editor needs quite a bit of effort. I was actually encouraged to break this challenge, and made my own svnup based on svndiff. If you are interested in details, you may find it on github.com under mkushnir/mrksvnup. It's a complete app, although you may use or re-use (parts of) it if you want. I also tested your svnup more and found that it doesn't handle symbolic links well. (May be you have already been aware of it.) I would suggest to test svnup against official svn client. Here is briefly what I'm doing to test my own svnup: # svn co -r NNNNNN svn://svn.freebsd.org/base/head head.svn # svnup -u svn://svn.freebsd.org/base/head -r NNNNNN -l head.svnup # diff -r head.svnup/ head.svn | egrep -v 'FreeBSD|\-\-\-|^diff \-r|^[0-9]+c[0-9]+' The diff output must be clean. -- Markiyan. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 10:08:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5231E591 for ; Sun, 31 Mar 2013 10:08:47 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id CA13B3F1 for ; Sun, 31 Mar 2013 10:08:46 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so735465eek.29 for ; Sun, 31 Mar 2013 03:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=xuZSancFPMpenbU0CB1+QCkRCEA3MsnGStRTKtCwaQA=; b=wgR9488rubVZs2Xo9DsTchjdi3k7zzf2SZrVYRPXX+ILjCA1DFYChOTH7B3SoPp70r 8hpFYDb1SLXB9mm2mCJmIASyFeKTl3FBfgR1gD5vL1tEIXMTK1V6E8JrS/OX0k4X47TJ Miq2uyLJosm0yvJtNKGvtWen9ZM1srkprZRNvViyskkUmgrZasQFhTIUF8Sbsf/7jsm0 cPq8wRqYi41dHI4jVZS1IK1vCJM0w2WkS1FuQDXPE9staTSlwzfBtGea6qtpqj49KCSw kEZLILMjCuGFjv0K4gM+HWnaxtbNqWr3ODEz22z9HctrVI/0YNu0pox4XGigtQ7kKv48 /aMA== X-Received: by 10.15.23.193 with SMTP id h41mr26226638eeu.17.1364724520062; Sun, 31 Mar 2013 03:08:40 -0700 (PDT) Received: from mkushnir.zapto.org (159-73-132-95.pool.ukrtel.net. [95.132.73.159]) by mx.google.com with ESMTPS id bc1sm14651561eeb.11.2013.03.31.03.08.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 03:08:39 -0700 (PDT) Message-ID: <51580AD1.1070704@gmail.com> Date: Sun, 31 Mar 2013 13:07:13 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <513E2DA5.70200@mac.com> <514E7927.2010901@gmail.com> <51580718.1010501@gmail.com> In-Reply-To: <51580718.1010501@gmail.com> Content-Type: multipart/mixed; boundary="------------010900030808000201030405" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 10:08:47 -0000 This is a multi-part message in MIME format. --------------010900030808000201030405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi John, I also measured svnup basic process resource usage, attaching a complete plot (measurements were taken each 2 seconds based on ps(1) and procstat(1)). Hopefully it will help you as well. -- Markiyan. On 31.03.2013 12:51, Markiyan Kushnir wrote: > On 25.03.2013 02:55, John Mehr wrote: >> >> >> >> On Sun, 24 Mar 2013 05:55:19 +0200 >> Markiyan Kushnir wrote: >>> Hello John, >>> >>> Tested svnup for a while, and I can say it does its job well, and >>> works basically as I would expect, so thanks for your initiative. >>> Although it appears to be quite resource greedy. Most of the time it >>> showed something like: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>> COMMAND >>> 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% >>> a.out >>> >>> >>> I looked at the source code, and found that it uses svn commands that >>> are known as the "main command set". The program is implemented around >>> get-dir and get-file. I think there is significant room for resource >>> and performance improvement. >>> >>> Have you considered an approach to use what svn folks call the editor >>> command set? I mean acting as a trivial svn client: we might ask the >>> server to drive our checking out or updating. The server will be >>> telling us only diffs. Checking out a full tree would be just another >>> diff, although bigger than usually. We would also benefit from >>> compression on the wire. >>> >>> Another advantage would be to always have consistent repo more-or-less >>> guaranteed by the svn server. >>> >>> I've done some proof of concept recently, and the results look >>> encouraging to me. For example, a do-nothing update really does >>> nothing. A two-or-three revisions update takes a couple of seconds. >>> And a full checkout of the base/stable/9 takes ~7m30s at 530kB/s to me. >> >> Hello, >> >> The results I was getting from testing out the svn protocol's editor >> command set were unpleasant enough to put it into the "come back to this >> later" category while I worked on implementing the http/https side. The >> good news it that the http side is *much* easier to work with in this >> respect and getting a report with filenames and MD5/SHA-1 signatures for >> all of the files in the repository can be obtained all at once. I >> should have a new and improved version ready to go this weekend or early >> next week at the latest. > > Hi again! > > Yes, I agree that svn editor needs quite a bit of effort. I was actually > encouraged to break this challenge, and made my own svnup based on > svndiff. If you are interested in details, you may find it on github.com > under mkushnir/mrksvnup. It's a complete app, although you may use or > re-use (parts of) it if you want. > > I also tested your svnup more and found that it doesn't handle symbolic > links well. (May be you have already been aware of it.) > > I would suggest to test svnup against official svn client. Here is > briefly what I'm doing to test my own svnup: > > # svn co -r NNNNNN svn://svn.freebsd.org/base/head head.svn > # svnup -u svn://svn.freebsd.org/base/head -r NNNNNN -l head.svnup > # diff -r head.svnup/ head.svn | egrep -v 'FreeBSD|\-\-\-|^diff > \-r|^[0-9]+c[0-9]+' > > The diff output must be clean. > > > -- > Markiyan. > > >> _______________________________________________ >> 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" > --------------010900030808000201030405-- From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 10:34:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 683EDAAD; Sun, 31 Mar 2013 10:34:25 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 105D323CEE1; Sun, 31 Mar 2013 12:26:43 +0200 (CEST) Message-ID: <51580F62.3080503@FreeBSD.org> Date: Sun, 31 Mar 2013 12:26:42 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Peter Wemm Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <5157756F.4040908@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 10:34:25 -0000 Am 31.03.2013 06:00, schrieb Peter Wemm: > We're talking about 10.x, so if you want it fixed, you need update > with 10.x information. > > Please put 10.x diagnostics in the PR. I will not. The PR was filed four months before 10-CURRENT branched; I have no reason to assume it were to be no longer pertinent -- no MFCs, no PR followups). (according to , 10-CURRENT appeared on 2011-09-26) From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 11:11:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E325AF1 for ; Sun, 31 Mar 2013 11:11:40 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACD97E7 for ; Sun, 31 Mar 2013 11:11:40 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UMGAj-000I3i-3O for freebsd-stable@freebsd.org; Sun, 31 Mar 2013 13:11:37 +0200 Resent-From: Kurt Jaeger Resent-Date: Sun, 31 Mar 2013 13:11:37 +0200 Resent-Message-ID: <20130331111137.GW12256@home.opsec.eu> Resent-To: freebsd-stable@freebsd.org Received: from localhost ([127.0.0.1] ident=exim) by home.opsec.eu with spam-scanned (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UMFX7-000I0h-T6 for pi@opsec.eu; Sun, 31 Mar 2013 12:30:47 +0200 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.opsec.eu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS, TW_SV, TW_VN autolearn=ham version=3.3.2 Received: from mail-ee0-f41.google.com ([74.125.83.41]:45559) by home.opsec.eu with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UMFX7-000I0c-Oa for pi@opsec.eu; Sun, 31 Mar 2013 12:30:41 +0200 Received: by mail-ee0-f41.google.com with SMTP id c1so739514eek.0 for ; Sun, 31 Mar 2013 03:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QsZU3QeNa+d/+uKGAZXrdGpr4PhaQWnfKA5TPjgxqmA=; b=jrHyGr7FHND1e8raIjyRSZl4XL8jKbv3DnEs23k7SXks+JlyTc7rkERMsxY93nKzk0 HrFdrdAzjEvhCptJ68DIwvSGnG7YgWa16ioYkb7pkhgGBqosdxhIVJgxX3oYiz6UIaZW XLE+EtIRdST7ArAwOuyYTpXdy2uWNH02m/wG/q4CoaILgkTnkqYqLk6VQK1inRWg3nMt sPF/ONGd032NMV0o7DPNlVOXBbJvFPdewdozKoaU4Scl+yAoemwj9uoyUZz3t3vK6cOL 0hke/bo6YGSoPPTX3+4llpW+WTOH3dkDpwBFtIK5vG4atP5yWCyhwUguw4FOvPMx8FBd cRHA== X-Received: by 10.15.22.197 with SMTP id f45mr25901375eeu.46.1364725832550; Sun, 31 Mar 2013 03:30:32 -0700 (PDT) Received: from mkushnir.zapto.org (159-73-132-95.pool.ukrtel.net. [95.132.73.159]) by mx.google.com with ESMTPS id ca4sm14704753eeb.15.2013.03.31.03.30.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 03:30:32 -0700 (PDT) Message-ID: <51580FF2.6020808@gmail.com> Date: Sun, 31 Mar 2013 13:29:06 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: Kurt Jaeger Subject: Re: svn - but smaller? References: <513E2DA5.70200@mac.com> <514E7927.2010901@gmail.com> <51580718.1010501@gmail.com> <51580AD1.1070704@gmail.com> <20130331101825.GU8239@home.opsec.eu> In-Reply-To: <20130331101825.GU8239@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 11:11:40 -0000 ups, sorry: https://docs.google.com/file/d/0B9Q-zpUXxqCnRVVMTkk1blVfZzA/edit?usp=sharing Please let me know if you have problems with accessing it. -- Markiyan On 31.03.2013 13:18, Kurt Jaeger wrote: > Hi! > >> I also measured svnup basic process resource usage, attaching a complete >> plot (measurements were taken each 2 seconds based on ps(1) and >> procstat(1)). Hopefully it will help you as well. > > The attachment did not make it to the list. Can you put it up somewhere ? > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 11:29:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDD4C49C for ; Sun, 31 Mar 2013 11:29:05 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 628A089A for ; Sun, 31 Mar 2013 11:29:05 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id m14so737417eaj.33 for ; Sun, 31 Mar 2013 04:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Tl+2q6GmHeKwo9n0Kq8LbtUyxfuuNJJKm+EJr4fO8MI=; b=vEk/l2bfPAbeQ57qQwgxtcdO9d3EGKF1wf/Y3FFykMTlZoSntTV5YHj4oomGSTvo8h IwaAa4NxjbETqX/23vfuV5hHg3uWo7cXKI8PuQEtAPE8tjXbT2aML9btGI5MxDSXL8z4 28q55YjNAas39jvqbYyZyUKnmgDT/3SbdtLSeTqgvGVLrP2RAKbKo2iaAeayduhG4u/O XcNGPD7Oy9sPSOgZIG85x1dIATsRs+ZVg+dvocJMHzKjC+LBd1yErD57YMAXT4SaVu9s HDzQ0ztdcd8AbXlhCYMFggKjJKsV5lnd1oRJOc7ujfdhgA63B0eCNG1NfYlN+5cnPRRX g66A== X-Received: by 10.14.219.129 with SMTP id m1mr26574998eep.16.1364729343791; Sun, 31 Mar 2013 04:29:03 -0700 (PDT) Received: from mkushnir.zapto.org (159-73-132-95.pool.ukrtel.net. [95.132.73.159]) by mx.google.com with ESMTPS id f47sm14989126eep.13.2013.03.31.04.29.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 04:29:03 -0700 (PDT) Message-ID: <51581DA8.7040106@gmail.com> Date: Sun, 31 Mar 2013 14:27:36 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <513E2DA5.70200@mac.com> <514E7927.2010901@gmail.com> <51580718.1010501@gmail.com> <51580AD1.1070704@gmail.com> In-Reply-To: <51580AD1.1070704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 11:29:05 -0000 On 31.03.2013 13:07, Markiyan Kushnir wrote: > Hi John, > > I also measured svnup basic process resource usage, attaching a complete > plot (measurements were taken each 2 seconds based on ps(1) and > procstat(1)). Hopefully it will help you as well. > (in case it's not available through the list) https://docs.google.com/file/d/0B9Q-zpUXxqCnRVVMTkk1blVfZzA/edit?usp=sharing -- Markiyan. > -- > Markiyan. > > On 31.03.2013 12:51, Markiyan Kushnir wrote: >> On 25.03.2013 02:55, John Mehr wrote: >>> >>> >>> >>> On Sun, 24 Mar 2013 05:55:19 +0200 >>> Markiyan Kushnir wrote: >>>> Hello John, >>>> >>>> Tested svnup for a while, and I can say it does its job well, and >>>> works basically as I would expect, so thanks for your initiative. >>>> Although it appears to be quite resource greedy. Most of the time it >>>> showed something like: >>>> >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>> COMMAND >>>> 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% >>>> a.out >>>> >>>> >>>> I looked at the source code, and found that it uses svn commands that >>>> are known as the "main command set". The program is implemented around >>>> get-dir and get-file. I think there is significant room for resource >>>> and performance improvement. >>>> >>>> Have you considered an approach to use what svn folks call the editor >>>> command set? I mean acting as a trivial svn client: we might ask the >>>> server to drive our checking out or updating. The server will be >>>> telling us only diffs. Checking out a full tree would be just another >>>> diff, although bigger than usually. We would also benefit from >>>> compression on the wire. >>>> >>>> Another advantage would be to always have consistent repo more-or-less >>>> guaranteed by the svn server. >>>> >>>> I've done some proof of concept recently, and the results look >>>> encouraging to me. For example, a do-nothing update really does >>>> nothing. A two-or-three revisions update takes a couple of seconds. >>>> And a full checkout of the base/stable/9 takes ~7m30s at 530kB/s to me. >>> >>> Hello, >>> >>> The results I was getting from testing out the svn protocol's editor >>> command set were unpleasant enough to put it into the "come back to this >>> later" category while I worked on implementing the http/https side. The >>> good news it that the http side is *much* easier to work with in this >>> respect and getting a report with filenames and MD5/SHA-1 signatures for >>> all of the files in the repository can be obtained all at once. I >>> should have a new and improved version ready to go this weekend or early >>> next week at the latest. >> >> Hi again! >> >> Yes, I agree that svn editor needs quite a bit of effort. I was actually >> encouraged to break this challenge, and made my own svnup based on >> svndiff. If you are interested in details, you may find it on github.com >> under mkushnir/mrksvnup. It's a complete app, although you may use or >> re-use (parts of) it if you want. >> >> I also tested your svnup more and found that it doesn't handle symbolic >> links well. (May be you have already been aware of it.) >> >> I would suggest to test svnup against official svn client. Here is >> briefly what I'm doing to test my own svnup: >> >> # svn co -r NNNNNN svn://svn.freebsd.org/base/head head.svn >> # svnup -u svn://svn.freebsd.org/base/head -r NNNNNN -l head.svnup >> # diff -r head.svnup/ head.svn | egrep -v 'FreeBSD|\-\-\-|^diff >> \-r|^[0-9]+c[0-9]+' >> >> The diff output must be clean. >> >> >> -- >> Markiyan. >> >> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 13:12:13 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E25AA0C; Sun, 31 Mar 2013 13:12:13 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD5ACB2; Sun, 31 Mar 2013 13:12:12 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id CE7472283F; Sun, 31 Mar 2013 15:04:09 +0200 (CEST) Date: Sun, 31 Mar 2013 15:04:09 +0200 From: Victor Balada Diaz To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130331130409.GO3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51536306.5030907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 13:12:13 -0000 On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not drop > it now? Hello, At my previous job we had troubles with NCQ on some controllers. It caused failures and silent data corruption. As old ata code didn't use NCQ we just used it. I reported some of the problems on 8.2[1] but the problem existed with 8.3. I no longer have access to those systems, so i don't know if the problem still exists or have been fixed on newer versions. Regards. Victor. [1]: https://groups.google.com/forum/#!topic/muc.lists.freebsd.stable/dAMf028CtXM -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 19:18:04 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C324DD2; Sun, 31 Mar 2013 19:18:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 1CEA7ACE; Sun, 31 Mar 2013 19:18:04 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r2VJI16h075708; Sun, 31 Mar 2013 19:18:01 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r2VJI0go075631; Sun, 31 Mar 2013 19:18:00 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 31 Mar 2013 19:18:00 GMT Message-Id: <201303311918.r2VJI0go075631@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 19:18:04 -0000 TB --- 2013-03-31 18:15:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-03-31 18:15:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-31 18:15:12 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2013-03-31 18:15:12 - cleaning the object tree TB --- 2013-03-31 18:15:12 - /usr/local/bin/svn stat /src TB --- 2013-03-31 18:15:15 - At svn revision 248952 TB --- 2013-03-31 18:15:16 - building world TB --- 2013-03-31 18:15:16 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 18:15:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 18:15:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 18:15:16 - SRCCONF=/dev/null TB --- 2013-03-31 18:15:16 - TARGET=pc98 TB --- 2013-03-31 18:15:16 - TARGET_ARCH=i386 TB --- 2013-03-31 18:15:16 - TZ=UTC TB --- 2013-03-31 18:15:16 - __MAKE_CONF=/dev/null TB --- 2013-03-31 18:15:16 - cd /src TB --- 2013-03-31 18:15:16 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 31 18:15:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Mar 31 18:59:38 UTC 2013 TB --- 2013-03-31 18:59:38 - generating LINT kernel config TB --- 2013-03-31 18:59:38 - cd /src/sys/pc98/conf TB --- 2013-03-31 18:59:38 - /usr/bin/make -B LINT TB --- 2013-03-31 18:59:38 - cd /src/sys/pc98/conf TB --- 2013-03-31 18:59:38 - /usr/sbin/config -m LINT TB --- 2013-03-31 18:59:38 - building LINT kernel TB --- 2013-03-31 18:59:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 18:59:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 18:59:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 18:59:38 - SRCCONF=/dev/null TB --- 2013-03-31 18:59:38 - TARGET=pc98 TB --- 2013-03-31 18:59:38 - TARGET_ARCH=i386 TB --- 2013-03-31 18:59:38 - TZ=UTC TB --- 2013-03-31 18:59:38 - __MAKE_CONF=/dev/null TB --- 2013-03-31 18:59:38 - cd /src TB --- 2013-03-31 18:59:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 31 18:59:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-dec! ls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'update_pages': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: implicit declaration of function 'pmap_page_is_write_mapped' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: nested extern declaration of 'pmap_page_is_write_mapped' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-03-31 19:18:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-31 19:18:00 - ERROR: failed to build LINT kernel TB --- 2013-03-31 19:18:00 - 3150.15 user 533.12 system 3768.43 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 19:21:13 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76492F52; Sun, 31 Mar 2013 19:21:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 2260CB0F; Sun, 31 Mar 2013 19:21:13 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r2VJLC72038092; Sun, 31 Mar 2013 19:21:12 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r2VJLCTq038091; Sun, 31 Mar 2013 19:21:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 31 Mar 2013 19:21:12 GMT Message-Id: <201303311921.r2VJLCTq038091@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 19:21:13 -0000 TB --- 2013-03-31 18:15:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-03-31 18:15:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-31 18:15:12 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2013-03-31 18:15:12 - cleaning the object tree TB --- 2013-03-31 18:15:12 - /usr/local/bin/svn stat /src TB --- 2013-03-31 18:15:16 - At svn revision 248952 TB --- 2013-03-31 18:15:17 - building world TB --- 2013-03-31 18:15:17 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 18:15:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 18:15:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 18:15:17 - SRCCONF=/dev/null TB --- 2013-03-31 18:15:17 - TARGET=i386 TB --- 2013-03-31 18:15:17 - TARGET_ARCH=i386 TB --- 2013-03-31 18:15:17 - TZ=UTC TB --- 2013-03-31 18:15:17 - __MAKE_CONF=/dev/null TB --- 2013-03-31 18:15:17 - cd /src TB --- 2013-03-31 18:15:17 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 31 18:15:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Mar 31 19:00:15 UTC 2013 TB --- 2013-03-31 19:00:15 - generating LINT kernel config TB --- 2013-03-31 19:00:15 - cd /src/sys/i386/conf TB --- 2013-03-31 19:00:15 - /usr/bin/make -B LINT TB --- 2013-03-31 19:00:15 - cd /src/sys/i386/conf TB --- 2013-03-31 19:00:15 - /usr/sbin/config -m LINT TB --- 2013-03-31 19:00:15 - building LINT kernel TB --- 2013-03-31 19:00:15 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 19:00:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 19:00:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 19:00:15 - SRCCONF=/dev/null TB --- 2013-03-31 19:00:15 - TARGET=i386 TB --- 2013-03-31 19:00:15 - TARGET_ARCH=i386 TB --- 2013-03-31 19:00:15 - TZ=UTC TB --- 2013-03-31 19:00:15 - __MAKE_CONF=/dev/null TB --- 2013-03-31 19:00:15 - cd /src TB --- 2013-03-31 19:00:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 31 19:00:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wne! sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'update_pages': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: implicit declaration of function 'pmap_page_is_write_mapped' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: nested extern declaration of 'pmap_page_is_write_mapped' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-03-31 19:21:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-31 19:21:12 - ERROR: failed to build LINT kernel TB --- 2013-03-31 19:21:12 - 3342.26 user 551.19 system 3960.55 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 19:39:28 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13792280; Sun, 31 Mar 2013 19:39:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id B4FE0BFF; Sun, 31 Mar 2013 19:39:27 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r2VJdRAD053856; Sun, 31 Mar 2013 19:39:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r2VJdReH053838; Sun, 31 Mar 2013 19:39:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 31 Mar 2013 19:39:27 GMT Message-Id: <201303311939.r2VJdReH053838@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 19:39:28 -0000 TB --- 2013-03-31 18:15:12 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-03-31 18:15:12 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-31 18:15:12 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2013-03-31 18:15:12 - cleaning the object tree TB --- 2013-03-31 18:15:12 - /usr/local/bin/svn stat /src TB --- 2013-03-31 18:15:15 - At svn revision 248952 TB --- 2013-03-31 18:15:16 - building world TB --- 2013-03-31 18:15:16 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 18:15:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 18:15:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 18:15:16 - SRCCONF=/dev/null TB --- 2013-03-31 18:15:16 - TARGET=amd64 TB --- 2013-03-31 18:15:16 - TARGET_ARCH=amd64 TB --- 2013-03-31 18:15:16 - TZ=UTC TB --- 2013-03-31 18:15:16 - __MAKE_CONF=/dev/null TB --- 2013-03-31 18:15:16 - cd /src TB --- 2013-03-31 18:15:16 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 31 18:15:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Mar 31 19:20:15 UTC 2013 TB --- 2013-03-31 19:20:15 - generating LINT kernel config TB --- 2013-03-31 19:20:15 - cd /src/sys/amd64/conf TB --- 2013-03-31 19:20:15 - /usr/bin/make -B LINT TB --- 2013-03-31 19:20:15 - cd /src/sys/amd64/conf TB --- 2013-03-31 19:20:15 - /usr/sbin/config -m LINT TB --- 2013-03-31 19:20:15 - building LINT kernel TB --- 2013-03-31 19:20:15 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 19:20:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 19:20:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 19:20:15 - SRCCONF=/dev/null TB --- 2013-03-31 19:20:15 - TARGET=amd64 TB --- 2013-03-31 19:20:15 - TARGET_ARCH=amd64 TB --- 2013-03-31 19:20:15 - TZ=UTC TB --- 2013-03-31 19:20:15 - __MAKE_CONF=/dev/null TB --- 2013-03-31 19:20:15 - cd /src TB --- 2013-03-31 19:20:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 31 19:20:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -s! td=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'update_pages': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: implicit declaration of function 'pmap_page_is_write_mapped' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: nested extern declaration of 'pmap_page_is_write_mapped' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-03-31 19:39:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-31 19:39:27 - ERROR: failed to build LINT kernel TB --- 2013-03-31 19:39:27 - 4238.27 user 740.91 system 5055.13 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 20:20:09 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98B019C8; Sun, 31 Mar 2013 20:20:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 4979EDC2; Sun, 31 Mar 2013 20:20:09 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r2VKK8e5051816; Sun, 31 Mar 2013 20:20:08 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r2VKK7NE051489; Sun, 31 Mar 2013 20:20:07 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 31 Mar 2013 20:20:07 GMT Message-Id: <201303312020.r2VKK7NE051489@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 20:20:09 -0000 TB --- 2013-03-31 19:19:20 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-03-31 19:19:20 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-31 19:19:20 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2013-03-31 19:19:20 - cleaning the object tree TB --- 2013-03-31 19:19:20 - /usr/local/bin/svn stat /src TB --- 2013-03-31 19:19:22 - At svn revision 248952 TB --- 2013-03-31 19:19:23 - building world TB --- 2013-03-31 19:19:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 19:19:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 19:19:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 19:19:23 - SRCCONF=/dev/null TB --- 2013-03-31 19:19:23 - TARGET=sparc64 TB --- 2013-03-31 19:19:23 - TARGET_ARCH=sparc64 TB --- 2013-03-31 19:19:23 - TZ=UTC TB --- 2013-03-31 19:19:23 - __MAKE_CONF=/dev/null TB --- 2013-03-31 19:19:23 - cd /src TB --- 2013-03-31 19:19:23 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 31 19:19:24 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Mar 31 20:02:21 UTC 2013 TB --- 2013-03-31 20:02:21 - generating LINT kernel config TB --- 2013-03-31 20:02:21 - cd /src/sys/sparc64/conf TB --- 2013-03-31 20:02:21 - /usr/bin/make -B LINT TB --- 2013-03-31 20:02:21 - cd /src/sys/sparc64/conf TB --- 2013-03-31 20:02:21 - /usr/sbin/config -m LINT TB --- 2013-03-31 20:02:21 - building LINT kernel TB --- 2013-03-31 20:02:21 - CROSS_BUILD_TESTING=YES TB --- 2013-03-31 20:02:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-31 20:02:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-31 20:02:21 - SRCCONF=/dev/null TB --- 2013-03-31 20:02:21 - TARGET=sparc64 TB --- 2013-03-31 20:02:21 - TARGET_ARCH=sparc64 TB --- 2013-03-31 20:02:21 - TZ=UTC TB --- 2013-03-31 20:02:21 - __MAKE_CONF=/dev/null TB --- 2013-03-31 20:02:21 - cd /src TB --- 2013-03-31 20:02:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 31 20:02:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_rlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c cc -O2 -pipe -DFREEBSD_NAMECACHE -DBUILDING_ZFS -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/src/sys/modules/zfs/../.. -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar! ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c cc1: warnings being treated as errors /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: In function 'update_pages': /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: implicit declaration of function 'pmap_page_is_write_mapped' /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:453: warning: nested extern declaration of 'pmap_page_is_write_mapped' *** [zfs_vnops.o] Error code 1 Stop in /src/sys/modules/zfs. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** [buildkernel] Error code 1 Stop in /src. TB --- 2013-03-31 20:20:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-31 20:20:07 - ERROR: failed to build LINT kernel TB --- 2013-03-31 20:20:07 - 3102.76 user 496.86 system 3647.20 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 21:02:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F047616C; Sun, 31 Mar 2013 21:02:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A6780F00; Sun, 31 Mar 2013 21:02:26 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2VL29hN079467; Sun, 31 Mar 2013 15:02:10 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <20130331130409.GO3178@equilibrium.bsdes.net> Date: Sun, 31 Mar 2013 15:02:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> To: Victor Balada Diaz , Alexander Motin X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 21:02:27 -0000 On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz = wrote: > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >> Hi. >>=20 >> Since FreeBSD 9.0 we are successfully running on the new CAM-based = ATA=20 >> stack, using only some controller drivers of old ata(4) by having=20 >> `options ATA_CAM` enabled in all kernels by default. I have a wish to=20= >> drop non-ATA_CAM ata(4) code, unused since that time from the head=20 >> branch to allow further ATA code cleanup. >>=20 >> Does any one here still uses legacy ATA stack (kernel explicitly = built=20 >> without `options ATA_CAM`) for some reason, for example as workaround=20= >> for some regression? Does anybody have good ideas why we should not = drop=20 >> it now? >=20 > Hello, >=20 > At my previous job we had troubles with NCQ on some controllers. It = caused > failures and silent data corruption. As old ata code didn't use NCQ we = just used > it. >=20 > I reported some of the problems on 8.2[1] but the problem existed with = 8.3. >=20 > I no longer have access to those systems, so i don't know if the = problem > still exists or have been fixed on newer versions. >=20 > Regards. > Victor. So what I hear you and Matthias saying, I believe, is that it should be = easier to force disks to fall back to non-NCQ mode, and/or have a more responsive black-list for problematic controllers. Would this help the situation? = It's hard to justify holding back overall forward progress because of some bad = controllers; we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD = 9.x, enough to make up a sizable percentage of the internet's traffic, and we = see no problems. How can we move forward but also take care of you guys with problematic hardware? Scott From owner-freebsd-stable@FreeBSD.ORG Sun Mar 31 22:00:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C9BBC51 for ; Sun, 31 Mar 2013 22:00:17 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 80268264 for ; Sun, 31 Mar 2013 22:00:17 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta01.emeryville.ca.mail.comcast.net with comcast id JMy91l0071afHeLA1N0GYW; Sun, 31 Mar 2013 22:00:16 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id JN0F1l00S1t3BNj8dN0FDE; Sun, 31 Mar 2013 22:00:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4054F73A1C; Sun, 31 Mar 2013 15:00:15 -0700 (PDT) Date: Sun, 31 Mar 2013 15:00:15 -0700 From: Jeremy Chadwick To: Scott Long Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130331220015.GA93163@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364767216; bh=oEi+Vmoh2kow/fmLGUmSJyv2xSL78yJwl2XiEiIizA0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=gTjd1FwS3PF4Pk+HYgFguTsrXOm9V5K6Jyo/vbaEs24V+1qKL9J6uy4W2kA+nOIfF cUSIiIZ/GIl2t2V122kHV/HGdFmJSkrXLesv7COH2WLyrCjU0jjjilAklqSLixKtBl d+aF6g0I9Zn0IsbREUkhpaXl4g1k50Rc4ZS1mIuTyP4jhUF5jsuSnBNfghBSWhbsFP EkYt3R7uh9bdFfUR/BxduI5M9zDwth7yCWpP3BWoERE7vSzHLPSOlDqM7rxke2eV7D DTctQIGJBEPD9d8DOH12+3ixpozXLx51SQkXPRrPX6Xe5GIDwA/qshmE5qu/j1nDKq oG6fVxhQamkrw== Cc: Victor Balada Diaz , Alexander Motin , "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Mar 2013 22:00:17 -0000 On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote: > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Hello, > > > > At my previous job we had troubles with NCQ on some controllers. It caused > > failures and silent data corruption. As old ata code didn't use NCQ we just used > > it. > > > > I reported some of the problems on 8.2[1] but the problem existed with 8.3. > > > > I no longer have access to those systems, so i don't know if the problem > > still exists or have been fixed on newer versions. > > So what I hear you and Matthias saying, I believe, is that it should be easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive > black-list for problematic controllers. Would this help the situation? It's hard to > justify holding back overall forward progress because of some bad controllers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, > enough to make up a sizable percentage of the internet's traffic, and we see no > problems. How can we move forward but also take care of you guys with > problematic hardware? I've read a referenced PR (157397) except there really isn't enough technical troubleshooting/detail to determine what the root cause is. That isn't the fault of the reporter either -- the reporter needs to be told what information they need to provide / how to troubleshoot it. Meaning: kernel folks who are in-the-know need to step up and help. That PR is soon-to-be 2 years old and is missing tons of information that, even as a non-kernel guy, that *I* would find useful: 1. Output from: - camcontrol tags ada1 -v - camcontrol identify ada1 - What sorts of filesystems are on ada1; if UFS, tunefs -p output would be greatly appreciated - If the timeouts happen during heavy I/O load, and if so, during what kinds of I/O load (reads or writes). 2. Does "camcontrol tags ada1 -N 31" help? I mention this because stated here: http://lists.freebsd.org/pipermail/freebsd-stable/2013-March/072985.html ...there are statements which imply decreasing queue length may solve the issue. What confuses me, however, is that the queue length on my own systems (with different models of disks, as well as an SSD) all have a limit of 32. I dug through the kernel source for a while but could not easily find where this number comes from. (I have very little familiarity with command queuing at the protocol level) 3. Why not find out why Linux (probably libata) has a 32 (or 31?) queue limit? They have commit logs, and there is the LVKM where you could ask. While I understand reluctance to add something "just because Linux does it", it doesn't appear anyone's stepped up to the plate to ask them why; I pray this is not caused by anti-Linux sentiment. 4. The ada1 device in the PR is a Samsung Spinpoint EcoGreen F2 hard drive (1TB, 5400rpm, 32MB cache). Possibly the drive has firmware bugs relating to its NCQ implementation, or possibly it's going into some power-saving mode (it is an EcoGreen model). I've always been wary of the EcoGreen disks since reading about the F4 EcoGreen firmware fiasco (even though the same page says the F1 and F3 EcoGreen had no issue): http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks 5. We really need to have some way to print "active quirks" for devices, even if it's only at boot-up, e.g.: ada3: quirks=0x0003<4K,NO_NCQ> I'd be happy to write the code for this (basing it on how we do CPU flags), but as I've said in the past, kernel-land is scary to me. 6. The controller referenced is an ATI IXP700. I cannot tell you how many times on the mailing lists I've seen "weird issues" reported by people using that controller. I am in no way/shape/form saying the issue is with the controller or with AHCI compatibility (FreeBSD vs. ATI), because I have no proof. I just find it very unnerving that so many issues have been reported where that controller is involved, and often across all sorts of different device/disk models. All that said: I agree a loader tunable to inhibit command queueing would be nice. sysctl would be even more convenient (easier for real-time testing) but I don't know the implications of turning CQ off in the middle of any pending I/O requests. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 07:04:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66BCA625 for ; Mon, 1 Apr 2013 07:04:54 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2FA1A1 for ; Mon, 1 Apr 2013 07:04:53 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id a22so949608qcs.12 for ; Mon, 01 Apr 2013 00:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=yT5qfFYL6loAyakMnI3msLf4JM6+AfB3oPOT6DrNlV0=; b=i60zj67FFqiMsg6WMdRwxd3n/l0qI7KQ6PHyjFI5XWLvL/HgXdkOJshiiRYiPVXS04 zMEccAk70FbYgE0yR0sJZQn3theYjNnqJ9/e4hVjL2zRxGYJYxDwgrGzjls56RIlQFJM 2TVd++rIMzYFWos72He+3ryEfTMbHmVpuDN2YzWper1K1Gu6EH8bGPIs+sfJFzVzCyjj Qv8hChHS+B4mFoLclOTjdKnhCyVLJICaGuZgsJVzisWbXyCVgZQE7kzA38d+sPTnDml/ M/RSiqR5nkEKnev5Kp8g8tKprqyrI7hWT+qKfMsH/vTzy9mSQewBjLD3ORtvP2+4gWPr V3Tg== MIME-Version: 1.0 X-Received: by 10.49.129.7 with SMTP id ns7mr12835825qeb.59.1364799893575; Mon, 01 Apr 2013 00:04:53 -0700 (PDT) Received: by 10.49.1.109 with HTTP; Mon, 1 Apr 2013 00:04:53 -0700 (PDT) X-Originating-IP: [64.72.74.50] Date: Mon, 1 Apr 2013 03:04:53 -0400 Message-ID: Subject: 9.1-REL Supermicro H8DCL-iF kernel panic From: Ryan McIntosh To: freebsd-stable@freebsd.org X-Gm-Message-State: ALoCoQmA9hW7CDO9BwGiVS+mR8uFLwGK1AbzJ4Dtqvro6wUvtzrm5v9YHxRMWLT6ek8BVZifqEkk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 07:04:54 -0000 This has been brought up before for a different board, none specifically mentioned this one nor the if_em driver (it was if_igb before on a X8DTU-6+ board). References: http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 Panic image from H8DCl-iF: http://nitemail.net/img/crash91-h8dcl-if.png Original image from X8DTU-6+: http://www.grosbein.net/img/crash-91rc.png While I'd love to try out some fixes myself however I don't have a ton of time with this system in my hands to be developed on. Jack (as referenced in the kernel pr) felt that it was too few system specific to go further with the issue as per the last response. I would be more than happy to assist or even lend remote access to this machine to figure out just what's causing the problem if anyone is up for the task, but I will only have about 3-4 days with it. I have confirmed dumping msix on the boot loader will permit the system to boot up and function, however horridly slow (6gbps drives pushing 8mbyte/sec isnt even usable). Maybe there's a grander problem here.. with supermicro? Let me know, I'll happily test whatever if it benefits the community. Ryan McIntosh e: rmcintosh@nitemare.net From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 07:31:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D32BFAFE for ; Mon, 1 Apr 2013 07:31:12 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id BF3F6333 for ; Mon, 1 Apr 2013 07:31:11 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 6FF61333F; Mon, 1 Apr 2013 00:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1364801471; bh=evK2Nv979whclZWkGCApjp+RULG6pNsvse/EcCxCZ4g=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=LzlyMwPGcI4VwcJ3zIEClriNPSJOqvpXo8v+GeCKGML9eYU2AYzaOlsp+oxnVEjeM 45vf9jSIIyljsK9TfSDqi3lRyjNPtMCvzY+lw8yolSR4AiGtg99RSMMozG4aHn3aao OW8Qc985BS7FZIELCjRRqf+v/jwOCXDNp5CQqTz8= Message-ID: <515937BF.9010805@delphij.net> Date: Mon, 01 Apr 2013 00:31:11 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Ryan McIntosh Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 07:31:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/1/13 12:04 AM, Ryan McIntosh wrote: > This has been brought up before for a different board, none > specifically mentioned this one nor the if_em driver (it was if_igb > before on a X8DTU-6+ board). > > References: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 > > Panic image from H8DCl-iF: > http://nitemail.net/img/crash91-h8dcl-if.png > > Original image from X8DTU-6+: > http://www.grosbein.net/img/crash-91rc.png > > While I'd love to try out some fixes myself however I don't have a > ton of time with this system in my hands to be developed on. Jack > (as referenced in the kernel pr) felt that it was too few system > specific to go further with the issue as per the last response. > > I would be more than happy to assist or even lend remote access to > this machine to figure out just what's causing the problem if > anyone is up for the task, but I will only have about 3-4 days with > it. I have confirmed dumping msix on the boot loader will permit > the system to boot up and function, however horridly slow (6gbps > drives pushing 8mbyte/sec isnt even usable). Maybe there's a > grander problem here.. with supermicro? Let me know, I'll happily > test whatever if it benefits the community. I tend to agree with John's patch (on Feb 21, 2013 on kern/172113), will you have a chance to test it? (My thought is that we should probably just initialize adapter->rx_mbuf_sz = MCLBYTES; in _attach() right after adapter->dev assignment?) Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRWTe/AAoJEG80Jeu8UPuzMf8IALPmOclwXEwLHSzVX8BEDbq7 YOgCsyNAa9Yi3aeSjDkH3Hvqi3XZzc5FtIeXODUMoU9+vTtI9KQSh4As3UsIYJG5 rGAS9dyT8hJ/VNVAzDNAPRmOTaeSRyXCughfCd5MCJXMTG/6KtVkJ2z/js9VpP4r sqA3qD21p9q88wfPJIhCj7hHFRLa5emv5Ir76pnZHrQ7ORerwtHEbTosWBWQdG7+ 9gREoMl0VB28Zoh8Ai1+TvB79MsUklB4F/XZ63sM2ccJ0Uk1Egn6shI9VMBqbh75 tkMSsjenxbM6/BgK86cyNS+NA8Nyh9hGrpNfab5qj79usJKFskSxUpP/iszHCJc= =xUCH -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 07:34:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2D4EC67 for ; Mon, 1 Apr 2013 07:34:42 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by mx1.freebsd.org (Postfix) with ESMTP id 88B48371 for ; Mon, 1 Apr 2013 07:34:42 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id x7so1084432qeu.3 for ; Mon, 01 Apr 2013 00:34:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=spnb2kOE23C+l4uMU4k+PHOLfCdBWvJQVElA09LJ7nM=; b=TPmlnIZYn2D3cUPpro87vL5077xmUwJ6EAzNfpwNkKVgLyCEzeK/NMv0iKk/XkXQod vfanRT2aS3iSzRsYzwnM2dQeSX2zwcUiZgAPTzbP4HEWQBT/A07eEE0f1yjZsR49zN2Z oKA4lszhO2uLjFn01YbcyF5muYWRPqO3LyQYwTh8Xit2V6LNUPg0UqU4nZB1y8tMR2vF MO/PwgLJdvSmKdQDOyomxcwvh3Agg9G4L/mLUXR/sw6rtMKv/zoBsPmt44Eq3lgOubnG CyV+nJQPdAXbAuvzTb/xn+5cBFNtfJ9QqTXk3H6JOLzO5SdCiLmfRrlidzVW7eqvzyr7 /xbw== MIME-Version: 1.0 X-Received: by 10.49.0.67 with SMTP id 3mr13155199qec.9.1364801681703; Mon, 01 Apr 2013 00:34:41 -0700 (PDT) Received: by 10.49.1.109 with HTTP; Mon, 1 Apr 2013 00:34:41 -0700 (PDT) X-Originating-IP: [64.72.74.50] In-Reply-To: <515937BF.9010805@delphij.net> References: <515937BF.9010805@delphij.net> Date: Mon, 1 Apr 2013 03:34:41 -0400 Message-ID: Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic From: Ryan McIntosh To: Xin LI X-Gm-Message-State: ALoCoQneoSiYAi0roXxTVi1J/tFhJEYcyQSAvSMzLfYnvM8gwRwMDGLiPCjHyTOwVziUN/SGIiCm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 07:34:42 -0000 I could try that patch, however that was intended for if_igb.c which for my system (and the panic's are almost identical except if_em for me) I'd have to apply that fix to if_em.c and I haven't looked at the source just yet. If you can give me a patch I'll do apply and test it shortly though. Ryan On Mon, Apr 1, 2013 at 3:31 AM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 4/1/13 12:04 AM, Ryan McIntosh wrote: > > This has been brought up before for a different board, none > > specifically mentioned this one nor the if_em driver (it was if_igb > > before on a X8DTU-6+ board). > > > > References: > > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 > > > > Panic image from H8DCl-iF: > > http://nitemail.net/img/crash91-h8dcl-if.png > > > > Original image from X8DTU-6+: > > http://www.grosbein.net/img/crash-91rc.png > > > > While I'd love to try out some fixes myself however I don't have a > > ton of time with this system in my hands to be developed on. Jack > > (as referenced in the kernel pr) felt that it was too few system > > specific to go further with the issue as per the last response. > > > > I would be more than happy to assist or even lend remote access to > > this machine to figure out just what's causing the problem if > > anyone is up for the task, but I will only have about 3-4 days with > > it. I have confirmed dumping msix on the boot loader will permit > > the system to boot up and function, however horridly slow (6gbps > > drives pushing 8mbyte/sec isnt even usable). Maybe there's a > > grander problem here.. with supermicro? Let me know, I'll happily > > test whatever if it benefits the community. > > I tend to agree with John's patch (on Feb 21, 2013 on kern/172113), > will you have a chance to test it? > > (My thought is that we should probably just initialize > adapter->rx_mbuf_sz = MCLBYTES; in _attach() right after adapter->dev > assignment?) > > Cheers, > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCAAGBQJRWTe/AAoJEG80Jeu8UPuzMf8IALPmOclwXEwLHSzVX8BEDbq7 > YOgCsyNAa9Yi3aeSjDkH3Hvqi3XZzc5FtIeXODUMoU9+vTtI9KQSh4As3UsIYJG5 > rGAS9dyT8hJ/VNVAzDNAPRmOTaeSRyXCughfCd5MCJXMTG/6KtVkJ2z/js9VpP4r > sqA3qD21p9q88wfPJIhCj7hHFRLa5emv5Ir76pnZHrQ7ORerwtHEbTosWBWQdG7+ > 9gREoMl0VB28Zoh8Ai1+TvB79MsUklB4F/XZ63sM2ccJ0Uk1Egn6shI9VMBqbh75 > tkMSsjenxbM6/BgK86cyNS+NA8Nyh9hGrpNfab5qj79usJKFskSxUpP/iszHCJc= > =xUCH > -----END PGP SIGNATURE----- > From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 07:48:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A87DF9F for ; Mon, 1 Apr 2013 07:48:09 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id F3F7E637 for ; Mon, 1 Apr 2013 07:48:08 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B30C1348D; Mon, 1 Apr 2013 00:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1364802488; bh=mcCzF4ZupQFVWAlR1LAYWXumL8NIZc+sxrSa1PQZYds=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=vCIttel8zU+1XapiPzcTr5jKClwzqF1PnHcvzi7T3XxIJUEOHRWjj4j+PMnxRM6nI +rpeJC/HBefM0qctxkASNy07eJwqi5ITHV23d+lrH4Q+QBy8EiAtlrM+WHVZm5g8xU 54Q1XkG+jVnh7l1Ay1Pv7croBGW4knokoEssMgZc= Message-ID: <51593BB8.4020403@delphij.net> Date: Mon, 01 Apr 2013 00:48:08 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Ryan McIntosh Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic References: <515937BF.9010805@delphij.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Xin LI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 07:48:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/1/13 12:34 AM, Ryan McIntosh wrote: > I could try that patch, however that was intended for if_igb.c > which for my system (and the panic's are almost identical except > if_em for me) I'd have to apply that fix to if_em.c and I haven't > looked at the source just yet. If you can give me a patch I'll do > apply and test it shortly though. Try this: http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRWTu4AAoJEG80Jeu8UPuzPnkIAIMgnUYgzXTdEt93aQVpK38v IKH54G8iU7xR98V5auokFqGAuy3wqnbT4GQGsQCZWl+Lu7lmrbvIVufuB04Zjmyp YO7gRNHeBVThp53nkDaPBjwLsEeGrFR11zLLq0nHJCDOFf+SgvPROuBEEMIBvzUR LeHWKZUOcMOHdkADfAm3T1QIZ6F/K5iJdr6OB+r86b+nxV9Z+whEO2Tzk87XodTD 39+9t4EdkM4BgMDBoheS74SWK+vHhsmXbX7PPFXJZ/Zrasp6GMYLk8AAcWDm0IZ4 7s7lmx0xqckzwhaJZzKfO+DWtlaIrE+LIQwQmg5QVeZBDxlDU0orsLGO55zSlAo= =B1sL -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 09:45:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1CE13F40 for ; Mon, 1 Apr 2013 09:45:55 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id D624DF26 for ; Mon, 1 Apr 2013 09:45:54 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hg5so757736qab.18 for ; Mon, 01 Apr 2013 02:45:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=njmkv6EQ/KnZ2VOG/kCvT0m7fXHLSY+2qisaJbqE8CE=; b=eJBUPonQNx+aVBcO8N8pPqpBkXq9BbbMxKK2P2cGkCY5Z32C/GUV2Kvu+MGm9+FJEp Y42oEcnsZNI2t4egRrf3I3/5Ma9bmd+5vtQyX2hjRSSGmRSYN93OVk8CLuLH1wFs9Jtx 9XViwFOMrLfpUHzS1pkF852c7UBd31MisLGQx/cY7Lf1s+TPte1P4UzruEebnjVFhasd PHfNl87d7CiYIxmd13hYpNNfLsawtP5Okv1J6GPetJE9e/22+AZh/E9+XUZKPWOEC2wZ 1Xr9tBgwyo96F1tvQdmfKiNzKKIaQbj0uMyb7ARH3X9ZTHGyag3bk/XOvLNSg/fDFInk SrYQ== MIME-Version: 1.0 X-Received: by 10.229.8.141 with SMTP id h13mr1030355qch.21.1364809548474; Mon, 01 Apr 2013 02:45:48 -0700 (PDT) Received: by 10.49.28.134 with HTTP; Mon, 1 Apr 2013 02:45:48 -0700 (PDT) X-Originating-IP: [64.72.74.50] In-Reply-To: <51593BB8.4020403@delphij.net> References: <515937BF.9010805@delphij.net> <51593BB8.4020403@delphij.net> Date: Mon, 1 Apr 2013 05:45:48 -0400 Message-ID: Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic From: Ryan McIntosh To: Xin LI X-Gm-Message-State: ALoCoQmL+32G3eqsG+vprWq8ru7K9ZzLfJ6G710zXA+udsXt1LsEPQzU8M1FJQMbeLxSnL3wad3q Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 09:45:55 -0000 I can confirm that works as intended. I appreciate the prompt response and it looks like there's a real fix. For google reference for anyone else searching.. Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE Boot message: panic: m_getzone: m_getjcl: invalid cluster type cpuid = 0 KBD: stack backtrace: #0 0xffffffff809208a6 at kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 0xffffffff804ad5a7 at em_refresh_mbufs+0x207 #3 0xffffffff804adb7f at em_rxeof+0x47f #4 0xffffffff804adca4 at em_msix_rx+0x24 #5 0xffffffff808be8d4 at intr_event_execute_handlers+0x104 #6 0xffffffff808c0076 at ithread_loop+0xa6 #7 0xffffffff808bb9ef at fork_exit+0x11f #8 0xffffffff80bc368e at fork_trampoline+0xe Panic image from H8DCl-iF: http://nitemail.net/img/crash91-h8dcl-if.png Original image from X8DTU-6+: http://www.grosbein.net/img/crash-91rc.png As per Xin Li, which seems to work: http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch References: http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 Thanks again, Ryan McIntosh e: rmcintosh@nitemare.net On Mon, Apr 1, 2013 at 3:48 AM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 4/1/13 12:34 AM, Ryan McIntosh wrote: > > I could try that patch, however that was intended for if_igb.c > > which for my system (and the panic's are almost identical except > > if_em for me) I'd have to apply that fix to if_em.c and I haven't > > looked at the source just yet. If you can give me a patch I'll do > > apply and test it shortly though. > > Try this: > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > > Cheers, > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCAAGBQJRWTu4AAoJEG80Jeu8UPuzPnkIAIMgnUYgzXTdEt93aQVpK38v > IKH54G8iU7xR98V5auokFqGAuy3wqnbT4GQGsQCZWl+Lu7lmrbvIVufuB04Zjmyp > YO7gRNHeBVThp53nkDaPBjwLsEeGrFR11zLLq0nHJCDOFf+SgvPROuBEEMIBvzUR > LeHWKZUOcMOHdkADfAm3T1QIZ6F/K5iJdr6OB+r86b+nxV9Z+whEO2Tzk87XodTD > 39+9t4EdkM4BgMDBoheS74SWK+vHhsmXbX7PPFXJZ/Zrasp6GMYLk8AAcWDm0IZ4 > 7s7lmx0xqckzwhaJZzKfO+DWtlaIrE+LIQwQmg5QVeZBDxlDU0orsLGO55zSlAo= > =B1sL > -----END PGP SIGNATURE----- > From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 12:25:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B2C18FC4 for ; Mon, 1 Apr 2013 12:25:51 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 95D2CE31 for ; Mon, 1 Apr 2013 12:25:51 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta07.emeryville.ca.mail.comcast.net with comcast id JcP71l0040FhH24A7cRrw2; Mon, 01 Apr 2013 12:25:51 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id JcRq1l0051t3BNj8UcRqWi; Mon, 01 Apr 2013 12:25:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0EFCE73A1C; Mon, 1 Apr 2013 05:25:50 -0700 (PDT) Date: Mon, 1 Apr 2013 05:25:50 -0700 From: Jeremy Chadwick To: Ryan McIntosh Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic Message-ID: <20130401122550.GA7367@icarus.home.lan> References: <515937BF.9010805@delphij.net> <51593BB8.4020403@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364819151; bh=9i6onGGnuZLQJcpbG1M+f29DYJgVyg1N2ium/IPhPbk=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=CYDBOwVbK3V/0Df0nEwL4SR2j/h9bEMWgYH5Q8rxzT0zrr4AR3QefQufWx6bYL17t Yw8CVbyp4Gsq5hZclAs8V60xriTgi9wXQMcp71CB7piaM0ORJfh/G52pGNELnDQAxv aTWx7h/hQGCidaWsVTFcyhxmMDHcl1J+/0+XpDN3G6NJYYpacHzLBqonPMP1bNzwCl lP0q/ONTAR4E01QTfmKOE0DKo7KPuvzvZOvNc2N1CdpaYkd1Gou+BJ8bP+oauaomzf Xp/fnFkc5YawhiYB0ZVfSz0N662Ff7szCmb401Mb4gXdIrXtNT3XvZFeEqDyd+ouJD ZKSuc4BEUVbKw== Cc: freebsd-stable@freebsd.org, Xin LI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 12:25:51 -0000 On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: > I can confirm that works as intended. I appreciate the prompt response and > it looks like there's a real fix. > > For google reference for anyone else searching.. > > Motherboard: Supermicro H8DCL-iF > OS: FreeBSD 9.1-RELEASE > > Boot message: > panic: m_getzone: m_getjcl: invalid cluster type > cpuid = 0 > KBD: stack backtrace: > #0 0xffffffff809208a6 at kdb_backtrace+0x66 > #1 0xffffffff808ea8be at panic+0x1ce > #2 0xffffffff804ad5a7 at em_refresh_mbufs+0x207 > #3 0xffffffff804adb7f at em_rxeof+0x47f > #4 0xffffffff804adca4 at em_msix_rx+0x24 > #5 0xffffffff808be8d4 at intr_event_execute_handlers+0x104 > #6 0xffffffff808c0076 at ithread_loop+0xa6 > #7 0xffffffff808bb9ef at fork_exit+0x11f > #8 0xffffffff80bc368e at fork_trampoline+0xe > > Panic image from H8DCl-iF: > http://nitemail.net/img/crash91-h8dcl-if.png > > Original image from X8DTU-6+: > http://www.grosbein.net/img/crash-91rc.png > > As per Xin Li, which seems to work: > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > > References: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 > > > Thanks again, > > Ryan McIntosh > e: rmcintosh@nitemare.net > > > On Mon, Apr 1, 2013 at 3:48 AM, Xin Li wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 4/1/13 12:34 AM, Ryan McIntosh wrote: > > > I could try that patch, however that was intended for if_igb.c > > > which for my system (and the panic's are almost identical except > > > if_em for me) I'd have to apply that fix to if_em.c and I haven't > > > looked at the source just yet. If you can give me a patch I'll do > > > apply and test it shortly though. > > > > Try this: > > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch Jack Vogel has stated it's not a "real fix" (your words) but rather a "bandaid", for both igb(4) and em(4). The commit messages (for r238214 and r239304) contain details: http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304 -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 13:14:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9464FE0C; Mon, 1 Apr 2013 13:14:24 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3648F296; Mon, 1 Apr 2013 13:14:23 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id D0DD92283F; Mon, 1 Apr 2013 15:14:15 +0200 (CEST) Date: Mon, 1 Apr 2013 15:14:15 +0200 From: Victor Balada Diaz To: Scott Long Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130401131415.GQ3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 13:14:24 -0000 On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote: > > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? Does anybody have good ideas why we should not drop > >> it now? > > > > Hello, > > > > At my previous job we had troubles with NCQ on some controllers. It caused > > failures and silent data corruption. As old ata code didn't use NCQ we just used > > it. > > > > I reported some of the problems on 8.2[1] but the problem existed with 8.3. > > > > I no longer have access to those systems, so i don't know if the problem > > still exists or have been fixed on newer versions. > > > > Regards. > > Victor. > > > So what I hear you and Matthias saying, I believe, is that it should be easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive > black-list for problematic controllers. Would this help the situation? It's hard to > justify holding back overall forward progress because of some bad controllers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, > enough to make up a sizable percentage of the internet's traffic, and we see no > problems. How can we move forward but also take care of you guys with > problematic hardware? > > Scott Being able to configure quirks from loader.conf for disks AND controllers would be great and is not hard to do. If you want i can do a patch in two weeks and send it to you. That way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also being able to modify the configuration without a kernel recompile would be a big improvement because we could still use freebsd-update to keep systems updated. Anyway, my comment was not against dropping old ata code, but more on the "comments on regresssions on the new one". Regards. Victor. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 15:07:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2EB3BCC for ; Mon, 1 Apr 2013 15:07:31 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm1.bullet.mail.ird.yahoo.com (nm1.bullet.mail.ird.yahoo.com [77.238.189.58]) by mx1.freebsd.org (Postfix) with SMTP id 00F8FB2F for ; Mon, 1 Apr 2013 15:07:30 +0000 (UTC) Received: from [212.82.105.247] by nm1.bullet.mail.ird.yahoo.com with NNFMP; 01 Apr 2013 15:07:24 -0000 Received: from [46.228.39.57] by tm19.bullet.mail.ird.yahoo.com with NNFMP; 01 Apr 2013 15:07:24 -0000 Received: from [127.0.0.1] by smtp190.mail.ir2.yahoo.com with NNFMP; 01 Apr 2013 15:07:24 -0000 X-Yahoo-Newman-Id: 681576.48491.bm@smtp190.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: u6_VfT4VM1nO.pvMuJAuoWSx3MRKufjSWcOQxo5.o95Tpdl ZrMQRdqDRu5UxFsIxyVNLVJMna7tti4vaM5uzcl2pLo03Ufcn.fMR3n7HRdK 12VENDluIOt.o9EXKU2kYrkTcFqzK0L.aQxsGvSpXGAXlCIESlspkJQaczV9 9AQ0liO70SD.gomCzDmUvayJeDcPldiYEFaFTCcbHOiUreFsjWE8pc5i2XAq nLcGAArHZYmEFkqDRwrP06ejtVZX7X4VoTs80sefFigEosr9InKgCaMdGB1. W.q.bLlvTNUaky5.9aW.OAJ0agB.bk9JoMWiUqcUT.aQ5lQxDm06skOWtEGB RQ6BQJnB0VDJSDHxJZyzNupwK._68ua3V7vuGm8MiCOpk6hp4pXRVfumRbv0 jeqrhexw8ysI9uoHk9lgz66xnCW5QVCWINRIygoMYhfbSoWEP_Q-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@87.153.62.169 with plain) by smtp190.mail.ir2.yahoo.com with SMTP; 01 Apr 2013 15:07:24 +0000 UTC Message-ID: <5159A2A8.3090705@freebsd.org> Date: Mon, 01 Apr 2013 17:07:20 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <20130401131415.GQ3178@equilibrium.bsdes.net> In-Reply-To: <20130401131415.GQ3178@equilibrium.bsdes.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 15:07:31 -0000 Am 01.04.2013 15:14, schrieb Victor Balada Diaz: > Being able to configure quirks from loader.conf for disks AND controllers would be great > and is not hard to do. If you want i can do a patch in two weeks and send it to you. That > way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also > being able to modify the configuration without a kernel recompile would be a big > improvement because we could still use freebsd-update to keep systems updated. Something like: kern.cam.ada.0.quirks=1 to force 4KB sectors? No need to implement that, it is in -CURRENT (did not check -STABLE). But there is no quirk, that disables NCQ, currently, although it is easy to implement. See the places where "ADA_FLAG_CAN_NCQ" is set and make that value depend on a new quirk flag being unset ... But instead of setting that flag in the loader, it would be good to collect drive signatures that need it and to add quirk entries for them in ata_da.c ... Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 16:11:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9374183C; Mon, 1 Apr 2013 16:11:38 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB6FFDA; Mon, 1 Apr 2013 16:11:37 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 4D64D2283F; Mon, 1 Apr 2013 18:11:36 +0200 (CEST) Date: Mon, 1 Apr 2013 18:11:36 +0200 From: Victor Balada Diaz To: Stefan Esser Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130401161136.GR3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <20130401131415.GQ3178@equilibrium.bsdes.net> <5159A2A8.3090705@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5159A2A8.3090705@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 16:11:38 -0000 On Mon, Apr 01, 2013 at 05:07:20PM +0200, Stefan Esser wrote: > Am 01.04.2013 15:14, schrieb Victor Balada Diaz: > > Being able to configure quirks from loader.conf for disks AND controllers would be great > > and is not hard to do. If you want i can do a patch in two weeks and send it to you. That > > way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also > > being able to modify the configuration without a kernel recompile would be a big > > improvement because we could still use freebsd-update to keep systems updated. > > Something like: > > kern.cam.ada.0.quirks=1 > > to force 4KB sectors? > > No need to implement that, it is in -CURRENT (did not check -STABLE). > But there is no quirk, that disables NCQ, currently, although it is > easy to implement. See the places where "ADA_FLAG_CAN_NCQ" is set and > make that value depend on a new quirk flag being unset ... > > But instead of setting that flag in the loader, it would be good to > collect drive signatures that need it and to add quirk entries for > them in ata_da.c ... > > Regards, STefan Yep, something like that but also for controllers. Looking here[1] i don't see it implemented for controllers on current. I agree that we should collect drive and controller signatures and add that quirks to the OS, but being able to play with quirks from loader is still useful. If your FreeBSD version don't have yet the quirks needed for the disk/controller that you're using, you'd need to patch and rebuild a custom kernel. Having a loader tunable helps maintaining "old" FreeBSD versions easier. Regards. Victor. [1]: http://fxr.watson.org/fxr/source/dev/ahci/ahci.c -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 16:29:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E952E1C5 for ; Mon, 1 Apr 2013 16:29:48 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id CAD1B147 for ; Mon, 1 Apr 2013 16:29:48 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 31798641F; Mon, 1 Apr 2013 09:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1364833787; bh=HQy3Hc83kR1t0onK2wJgA5JoI2USdKYOIrciDj0Hp+Q=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=noiURGFCfpiLWfn6tdKVPlYaMz4xfTETYKFA/Va/LKOFD51P4py18rk/1FSjkAHeO XW3+4bS+M62LnN+h07Eft+fwCdOdo88W7XbBMwC2kR8MLhGn0j1v2w3l3IHLT0B9em Em+oNLz8z6irbCONK90Y2KalQmPaEZqAYtqjqBo4= Message-ID: <5159B5FA.1080005@delphij.net> Date: Mon, 01 Apr 2013 09:29:46 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic References: <515937BF.9010805@delphij.net> <51593BB8.4020403@delphij.net> <20130401122550.GA7367@icarus.home.lan> In-Reply-To: <20130401122550.GA7367@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ryan McIntosh , Xin LI , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:29:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/1/13 5:25 AM, Jeremy Chadwick wrote: > On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: >> I can confirm that works as intended. I appreciate the prompt >> response and it looks like there's a real fix. >> >> For google reference for anyone else searching.. >> >> Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE >> >> Boot message: panic: m_getzone: m_getjcl: invalid cluster type >> cpuid = 0 KBD: stack backtrace: #0 0xffffffff809208a6 at >> kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 >> 0xffffffff804ad5a7 at em_refresh_mbufs+0x207 #3 >> 0xffffffff804adb7f at em_rxeof+0x47f #4 0xffffffff804adca4 at >> em_msix_rx+0x24 #5 0xffffffff808be8d4 at >> intr_event_execute_handlers+0x104 #6 0xffffffff808c0076 at >> ithread_loop+0xa6 #7 0xffffffff808bb9ef at fork_exit+0x11f #8 >> 0xffffffff80bc368e at fork_trampoline+0xe >> >> Panic image from H8DCl-iF: >> http://nitemail.net/img/crash91-h8dcl-if.png >> >> Original image from X8DTU-6+: >> http://www.grosbein.net/img/crash-91rc.png >> >> As per Xin Li, which seems to work: >> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch >> >> >> References: >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 >> >> >> Thanks again, >> >> Ryan McIntosh e: rmcintosh@nitemare.net >> >> >> On Mon, Apr 1, 2013 at 3:48 AM, Xin Li >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 4/1/13 12:34 AM, Ryan McIntosh wrote: >>>> I could try that patch, however that was intended for >>>> if_igb.c which for my system (and the panic's are almost >>>> identical except if_em for me) I'd have to apply that fix to >>>> if_em.c and I haven't looked at the source just yet. If you >>>> can give me a patch I'll do apply and test it shortly >>>> though. >>> >>> Try this: >>> >>> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > >>> > Jack Vogel has stated it's not a "real fix" (your words) but rather > a "bandaid", for both igb(4) and em(4). The commit messages (for > r238214 and r239304) contain details: > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214 > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304 Hm why 238214 is related, or did you mean the change between 238214 and 239304? Yes, this is a bandaid and the right fix should be refactor the code a little bit to make sure that no interrupt handler is installed before the driver have done other initializations but I don't have hardware that can reproduce this issue handy to validate changes like that. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRWbX6AAoJEG80Jeu8UPuzfR4IAID80wE0vCg+AyunRBLusue3 zBXNVwbAwxUFcJ2HcFRFLXVGj2kNsYnHGEp2KGJbYxX/zYJN6Kvv0nXhDIFM0IvJ dsyC9f/vAay4EtKn9bSz6DmB57KUuhdy5v+40uGQIcoAaQ3/7My06RYcY2dm2PVM XzLrEz3K5kEC+0dCRIRFi61yZAAPp4/FkHzrDud1AyQ+M03VnbXszzR7J6QIOYbQ pN2I7RZfIMQXX9Qc+kqX6fFSCYrI7MzZmZkZPIQguWj/x+TUjk5pt5kyuNbum+YF mqut0VyKAkwVRnsZMIJUXYEXfVtPorDlKRG4dlJdloF1Hz/xP02NpZoDzaK72GU= =7Wll -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 17:25:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 274C595 for ; Mon, 1 Apr 2013 17:25:03 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB67403 for ; Mon, 1 Apr 2013 17:25:03 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id JeJ81l0041bwxycA9hR2CY; Mon, 01 Apr 2013 17:25:02 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id JhR11l00G1t3BNj8ehR1rG; Mon, 01 Apr 2013 17:25:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 419A273A1C; Mon, 1 Apr 2013 10:25:01 -0700 (PDT) Date: Mon, 1 Apr 2013 10:25:01 -0700 From: Jeremy Chadwick To: d@delphij.net Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic Message-ID: <20130401172501.GA12934@icarus.home.lan> References: <515937BF.9010805@delphij.net> <51593BB8.4020403@delphij.net> <20130401122550.GA7367@icarus.home.lan> <5159B5FA.1080005@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5159B5FA.1080005@delphij.net> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364837102; bh=us6lu8U++IzfE1jDtTKHL8Vc4EokwrN2mCzM1QrN7X8=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ovbscda/qew6F2hJ/pC9jlcXOCTj3FlQTpGxtdEDnOWKbc6+4YEFBvU2Smet19YN5 OTpPNZVbNtKqaUum9OjhDFmf8pZaM7JJ6iSGLCTa0QhLnArl7xQr1Y9t3Npiv10n/s oAhTYqv34QRiyiS/91rM37TJc/eCpwrzoSXTrQ1QHnZUGj1RHdpfZxXn6II4Si5Umn 0AW8EIpz/1yY0MTw9ysF/BQY5xGqW/WDfI2Oxwk+EKz9gdHtfbBs6cOCIHlagUhp9L KIAc8CbCg2k8J8rt4QSd8EqjO4LMELR5YPQw3FLFRk4WTe7eLj+R7TlU1/L1NHLlJ8 VFbag6ZsbWLVA== Cc: Ryan McIntosh , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 17:25:03 -0000 On Mon, Apr 01, 2013 at 09:29:46AM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 4/1/13 5:25 AM, Jeremy Chadwick wrote: > > On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: > >> I can confirm that works as intended. I appreciate the prompt > >> response and it looks like there's a real fix. > >> > >> For google reference for anyone else searching.. > >> > >> Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE > >> > >> Boot message: panic: m_getzone: m_getjcl: invalid cluster type > >> cpuid = 0 KBD: stack backtrace: #0 0xffffffff809208a6 at > >> kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 > >> 0xffffffff804ad5a7 at em_refresh_mbufs+0x207 #3 > >> 0xffffffff804adb7f at em_rxeof+0x47f #4 0xffffffff804adca4 at > >> em_msix_rx+0x24 #5 0xffffffff808be8d4 at > >> intr_event_execute_handlers+0x104 #6 0xffffffff808c0076 at > >> ithread_loop+0xa6 #7 0xffffffff808bb9ef at fork_exit+0x11f #8 > >> 0xffffffff80bc368e at fork_trampoline+0xe > >> > >> Panic image from H8DCl-iF: > >> http://nitemail.net/img/crash91-h8dcl-if.png > >> > >> Original image from X8DTU-6+: > >> http://www.grosbein.net/img/crash-91rc.png > >> > >> As per Xin Li, which seems to work: > >> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > >> > >> > >> > References: > >> http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 > >> > >> > >> Thanks again, > >> > >> Ryan McIntosh e: rmcintosh@nitemare.net > >> > >> > >> On Mon, Apr 1, 2013 at 3:48 AM, Xin Li > >> wrote: > >> > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>> > >>> On 4/1/13 12:34 AM, Ryan McIntosh wrote: > >>>> I could try that patch, however that was intended for > >>>> if_igb.c which for my system (and the panic's are almost > >>>> identical except if_em for me) I'd have to apply that fix to > >>>> if_em.c and I haven't looked at the source just yet. If you > >>>> can give me a patch I'll do apply and test it shortly > >>>> though. > >>> > >>> Try this: > >>> > >>> http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > > > >>> > > Jack Vogel has stated it's not a "real fix" (your words) but rather > > a "bandaid", for both igb(4) and em(4). The commit messages (for > > r238214 and r239304) contain details: > > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214 > > > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304 > > Hm why 238214 is related, or did you mean the change between 238214 > and 239304? Correct (the latter). :-) The "bandaid" in 239304 **wasn't** to fix a bug introduced in 238214, it was an overall "bandaid". I've gotten in the habit of always examining two commits (fix + previous commit) to see what got introduced where. > Yes, this is a bandaid and the right fix should be refactor the code a > little bit to make sure that no interrupt handler is installed before > the driver have done other initializations but I don't have hardware > that can reproduce this issue handy to validate changes like that. Yes exactly. I just want to make sure Ryan understands that this is simply a workaround for said spurious interrupt scenario, while the actual root cause needs to be dealt as you describe. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 20:23:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47DE45ED for ; Mon, 1 Apr 2013 20:23:23 +0000 (UTC) (envelope-from rmcintosh@nitemare.net) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 089B4E8B for ; Mon, 1 Apr 2013 20:23:22 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id l8so1075296qaq.15 for ; Mon, 01 Apr 2013 13:23:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qFIHSijnA56BXPXRAvaKhjcWu1jSOIF8a5F1kAbGQMY=; b=B3oo48e5Vf3Zyqk2ut3q4+cxPI042L1I/DCRqMkLGb9H3wqDOCFf7LDwsSOHQrGbCJ skTaqR2vrK98klNWph+CsMoDSx7wBzHznPJWpWUXHiRkM0Ft66WpEiGT1RMesaAYr19d JFybgiTyLQRv5Kknfp6vRUO5931n7Mm5hh7n8SDR1RG8Od4Tc6fB6dsMPSkD4/rgdLVN GFkph8lazalpNJBE3N4bAvzwI+0Xj6BhMuhRTwLtygspeVFFKX3hBKA4YbIRixe/25Iq nLmLaxsNYILKvXqS0Y1lZNoVAlro1FlFmN4cFxlY5+R/2YarwaJbky38JdC2jG2Guxkn gOcA== MIME-Version: 1.0 X-Received: by 10.224.167.83 with SMTP id p19mr13952393qay.73.1364847801777; Mon, 01 Apr 2013 13:23:21 -0700 (PDT) Received: by 10.49.28.134 with HTTP; Mon, 1 Apr 2013 13:23:21 -0700 (PDT) X-Originating-IP: [64.72.74.50] In-Reply-To: <20130401172501.GA12934@icarus.home.lan> References: <515937BF.9010805@delphij.net> <51593BB8.4020403@delphij.net> <20130401122550.GA7367@icarus.home.lan> <5159B5FA.1080005@delphij.net> <20130401172501.GA12934@icarus.home.lan> Date: Mon, 1 Apr 2013 16:23:21 -0400 Message-ID: Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic From: Ryan McIntosh To: Jeremy Chadwick X-Gm-Message-State: ALoCoQnKtb6jWV7LEWXcv3Ai103wbeHBSTHZ/KDIwVsjUBCT2c+oyni9qbLPAdIGkI3xgXgn5p2B Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org, Xin LI X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Apr 2013 20:23:23 -0000 I had to get some sleep lol. Yes Jeremy, I do completely understand that and likewise FreeBSD was unusable without any type of semi-hack fix, let alone fixing it properly, as without msix the system was pretty slow. If you'd like access or are up for trying to fix the driver I'm all for being a guinea pig. Let me know. Ryan On Mon, Apr 1, 2013 at 1:25 PM, Jeremy Chadwick wrote: > On Mon, Apr 01, 2013 at 09:29:46AM -0700, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 4/1/13 5:25 AM, Jeremy Chadwick wrote: > > > On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote: > > >> I can confirm that works as intended. I appreciate the prompt > > >> response and it looks like there's a real fix. > > >> > > >> For google reference for anyone else searching.. > > >> > > >> Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE > > >> > > >> Boot message: panic: m_getzone: m_getjcl: invalid cluster type > > >> cpuid = 0 KBD: stack backtrace: #0 0xffffffff809208a6 at > > >> kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 > > >> 0xffffffff804ad5a7 at em_refresh_mbufs+0x207 #3 > > >> 0xffffffff804adb7f at em_rxeof+0x47f #4 0xffffffff804adca4 at > > >> em_msix_rx+0x24 #5 0xffffffff808be8d4 at > > >> intr_event_execute_handlers+0x104 #6 0xffffffff808c0076 at > > >> ithread_loop+0xa6 #7 0xffffffff808bb9ef at fork_exit+0x11f #8 > > >> 0xffffffff80bc368e at fork_trampoline+0xe > > >> > > >> Panic image from H8DCl-iF: > > >> http://nitemail.net/img/crash91-h8dcl-if.png > > >> > > >> Original image from X8DTU-6+: > > >> http://www.grosbein.net/img/crash-91rc.png > > >> > > >> As per Xin Li, which seems to work: > > >> > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > > >> > > >> > > >> > > References: > > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html > > >> > > >> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113 > > >> > > >> > > >> Thanks again, > > >> > > >> Ryan McIntosh e: rmcintosh@nitemare.net > > >> > > >> > > >> On Mon, Apr 1, 2013 at 3:48 AM, Xin Li > > >> wrote: > > >> > > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > >>> > > >>> On 4/1/13 12:34 AM, Ryan McIntosh wrote: > > >>>> I could try that patch, however that was intended for > > >>>> if_igb.c which for my system (and the panic's are almost > > >>>> identical except if_em for me) I'd have to apply that fix to > > >>>> if_em.c and I haven't looked at the source just yet. If you > > >>>> can give me a patch I'll do apply and test it shortly > > >>>> though. > > >>> > > >>> Try this: > > >>> > > >>> > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214&r2=239304&view=patch > > > > > >>> > > > Jack Vogel has stated it's not a "real fix" (your words) but rather > > > a "bandaid", for both igb(4) and em(4). The commit messages (for > > > r238214 and r239304) contain details: > > > > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214 > > > > > > > > http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304 > > > > Hm why 238214 is related, or did you mean the change between 238214 > > and 239304? > > Correct (the latter). :-) The "bandaid" in 239304 **wasn't** to fix a > bug introduced in 238214, it was an overall "bandaid". > > I've gotten in the habit of always examining two commits (fix + previous > commit) to see what got introduced where. > > > Yes, this is a bandaid and the right fix should be refactor the code a > > little bit to make sure that no interrupt handler is installed before > > the driver have done other initializations but I don't have hardware > > that can reproduce this issue handy to validate changes like that. > > Yes exactly. I just want to make sure Ryan understands that this is > simply a workaround for said spurious interrupt scenario, while the > actual root cause needs to be dealt as you describe. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | > From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 00:04:40 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD45CEFF for ; Tue, 2 Apr 2013 00:04:40 +0000 (UTC) (envelope-from bowlapplefork@yahoo.com) Received: from nm25.bullet.mail.ne1.yahoo.com (nm25.bullet.mail.ne1.yahoo.com [98.138.90.88]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7198E7 for ; Tue, 2 Apr 2013 00:04:39 +0000 (UTC) Received: from [98.138.90.48] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 02 Apr 2013 00:02:55 -0000 Received: from [98.138.89.195] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 02 Apr 2013 00:02:55 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 02 Apr 2013 00:02:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 970956.50007.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 6675 invoked by uid 60001); 2 Apr 2013 00:02:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1364860975; bh=cer/nMohimPQZ/msUwobuAtpllrBbVox208jch29kOw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=rq5MVNmTUVBoe3cEJRz4websxXWi2VtWUuJSlAhc0Zk4b/0tX0Ze30l38lnsS86jLVxB1CrZxyw9Ea6O/p2kGudBsCGRd5ewrVICxdQGqnncMIfm4EQsFq70Q8Ky9yZei8N7mMCTtq1rnmBuDwXoP1xKFQ7lOP0wPbtbkqQHvgs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=NU+pkY3pk+yGD5VJfBtuy9MWW/JvJ+wvEnaApcFw16L3t1KBYWHBemyb5Y+HSJbui/nRQKvPxtXKueb9LuBGC8llXuFF4/uHJG9qgilJkHHNcgj8F+fRUWiBHf/TcByYZoXhVi7HPlKDRh2BeD5WY4GUlaI5qdUD8FXj0yEiiXU=; X-YMail-OSG: _sDJqj4VM1kk4lMkAIzNHC.bz7Y7vZ0Xr9oyhRVNqEETxF4 UlWv4SL6KKu1WlFXNL6lYDZLYZ9l7WbMYniEkrWzKK5lwo5Z1wcFACwzmi1a 0RNb6lkQgEFzxBPpFd4t2jMinClaxFboWoXgoP3ThYGEp1F8pMiGDPaiU5yB mPDlDOkUHDRJxTv5p77zD9c7MUzzfWBPvA_fAksHz6sPkSprQMsBLMA.owN2 o6wS9GobmSk9IxIUSyHk0LhwUuKNGNUywbE4JZ14mNTc2n3fv4VIQ_meKQix IZcwJpTFzpQVOphLFrgypK5u89sYAyQ3GMyVjC8opHmJ74PDmF4zJGRZL2i2 ywKcduMVyoIzmZYuaLuF68QkyCSrU6sb3wldxzsxkzF2AjYzJkIE8NIm4aR3 nRMF7T4HIyEEjhR2OJp6.t_uz8DgWiN8n8zRH68izSpWmGKSoQ0q8Hv1EPEG Jaw-- Received: from [97.89.230.199] by web121702.mail.ne1.yahoo.com via HTTP; Mon, 01 Apr 2013 17:02:55 PDT X-Rocket-MIMEInfo: 002.001, RXZlciBzaW5jZSBJIHVwZ3JhZGVkIHRvIHRoZSAobm9ud29ya2luZykgS01TIGV4dGVuc2lvbiBmb3IgWG9yZywgSSd2ZSBiZWVuIGdldHRpbmcgdGhlc2UgbWVzc2FnZXMgcmVwZWF0aW5nIGVuZGxlc3NseSBpbiBteSBrZXJuZWwgbG9nLsKgIEkndmUgZ2l2ZW4gdXAgb24gdHJ5aW5nIHRvIGdldCAzRCBncmFwaGljcyBiYWNrIGludG8gYSB3b3JrYWJsZSBzdGF0ZSwgYnV0IGlzIHRoZXJlIHNvbWUgYm9vdC10aW1lIG9wdGlvbiBvciBzeXNjdGwgc2V0dGluZyB0aGF0IGNhbiBiZSB1c2VkIHRvIGRpc2FibGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 Message-ID: <1364860975.6635.YahooMailNeo@web121702.mail.ne1.yahoo.com> Date: Mon, 1 Apr 2013 17:02:55 -0700 (PDT) From: B Z Subject: Worthless debug messages To: "stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: B Z List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 00:04:40 -0000 Ever since I upgraded to the (nonworking) KMS extension for Xorg, I've been= getting these messages repeating endlessly in my kernel log.=A0 I've given= up on trying to get 3D graphics back into a workable state, but is there s= ome boot-time option or sysctl setting that can be used to disable these me= ssages without making Xorg totally unusable?=0A=0A[2665] [drm:KMS:pid0:inte= l_crt_detect] CRT not detected via hotplug=0A[2665] [drm:KMS:pid0:output_po= ll_execute] [CONNECTOR:11:VGA-1] status updated from 2 to 2=0A[2665] [drm:K= MS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status updated from 2 = to 2=0A[2674] [drm:KMS:pid1774:intel_crtc_cursor_set] =0A[2674] [drm:KMS:pi= d1774:intel_crtc_cursor_set] cursor off=0A[2675] [drm:KMS:pid0:intel_crt_de= tect] CRT not detected via hotplug=0A[2675] [drm:KMS:pid0:output_poll_execu= te] [CONNECTOR:11:VGA-1] status updated from 2 to 2=0A[2675] [drm:KMS:pid0:= output_poll_execute] [CONNECTOR:13:SVIDEO-1] status updated from 2 to 2=0A[= 2685] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug=0A[2685]= [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status updated fro= m 2 to 2=0A[2685] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1= ] status updated from 2 to 2=0A[2695] [drm:KMS:pid0:intel_crt_detect] CRT n= ot detected via hotplug=0A[2695] [drm:KMS:pid0:output_poll_execute] [CONNEC= TOR:11:VGA-1] status updated from 2 to 2=0A[2695] [drm:KMS:pid0:output_poll= _execute] [CONNECTOR:13:SVIDEO-1] status updated from 2 to 2=0A[2705] [drm:= KMS:pid0:intel_crt_detect] CRT not detected via hotplug=0A[2705] [drm:KMS:p= id0:output_poll_execute] [CONNECTOR:11:VGA-1] status updated from 2 to 2=0A= [2705] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status up= dated from 2 to 2=0A[2715] [drm:KMS:pid0:intel_crt_detect] CRT not detected= via hotplug=0A[2715] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-= 1] status updated from 2 to 2=0A[2715] [drm:KMS:pid0:output_poll_execute] [= CONNECTOR:13:SVIDEO-1] status updated from 2 to 2=0A[2725] [drm:KMS:pid0:in= tel_crt_detect] CRT not detected via hotplug=0A[2725] [drm:KMS:pid0:output_= poll_execute] [CONNECTOR:11:VGA-1] status updated from 2 to 2=0A[2725] [drm= :KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status updated from = 2 to 2 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 01:35:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9CA73ECB for ; Tue, 2 Apr 2013 01:35:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 6C213BE8 for ; Tue, 2 Apr 2013 01:35:32 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wc20so2406102obb.29 for ; Mon, 01 Apr 2013 18:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JFJeSudNLq17WFVfNByQ3b02/6RNqYPQLunojuKg2KE=; b=AnYVgvRx/sxewmaAu6eUdp6Dye2oPwjjBY8OHPVOdQ8ba4dVBbPNXJdFxmNWcTC0F6 zgkPrYf3QTvyajvXp79yQlNLFIRe66TlwMA8D4jvZqWJSuvxcRmdlDFB2dfcRMMM/LY/ HTT1uO5cXOH4Vt07lIXxq3W54/1t3v6TrpLvI68Q6dWVzx9Bqtu7k6yZdTXs48sLggXm bMXDoHd5VPNyzmxrvlA0bvLcgrKrv4xebW/C7i0XI0jRJjvbCI4smyxlb7dUPsH/n4dA 47k8qMFGCT3JIB1czi8Mem1M4BXmV3XPs9ZRiodxxVPgrSx/6szOE9CcTSIsUig+vwjz KOGA== MIME-Version: 1.0 X-Received: by 10.182.86.162 with SMTP id q2mr4962454obz.35.1364866531780; Mon, 01 Apr 2013 18:35:31 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Mon, 1 Apr 2013 18:35:31 -0700 (PDT) In-Reply-To: <1364860975.6635.YahooMailNeo@web121702.mail.ne1.yahoo.com> References: <1364860975.6635.YahooMailNeo@web121702.mail.ne1.yahoo.com> Date: Mon, 1 Apr 2013 18:35:31 -0700 X-Google-Sender-Auth: Uu7sbkr6IxE_-BmQDoqT-Roy28k Message-ID: Subject: Re: Worthless debug messages From: Kevin Oberman To: B Z Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 01:35:32 -0000 On Mon, Apr 1, 2013 at 5:02 PM, B Z wrote: > Ever since I upgraded to the (nonworking) KMS extension for Xorg, I've > been getting these messages repeating endlessly in my kernel log. I've > given up on trying to get 3D graphics back into a workable state, but is > there some boot-time option or sysctl setting that can be used to disable > these messages without making Xorg totally unusable? > > [2665] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2665] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2665] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2674] [drm:KMS:pid1774:intel_crtc_cursor_set] > [2674] [drm:KMS:pid1774:intel_crtc_cursor_set] cursor off > [2675] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2675] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2675] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2685] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2685] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2685] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2695] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2695] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2695] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2705] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2705] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2705] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2715] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2715] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2715] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > [2725] [drm:KMS:pid0:intel_crt_detect] CRT not detected via hotplug > [2725] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:11:VGA-1] status > updated from 2 to 2 > [2725] [drm:KMS:pid0:output_poll_execute] [CONNECTOR:13:SVIDEO-1] status > updated from 2 to 2 > Yes, there is, but most of the drm errors were already silenced. What version are you running? Also, if the KMS code is not working for you, why are you using it? In any case, most KMS errors can be silenced with hw.dri.debug=0. I can't confirm that these are, though, as I have never goten them. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 11:17:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 226E813D for ; Tue, 2 Apr 2013 11:17:28 +0000 (UTC) (envelope-from isabell@issyl0.co.uk) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by mx1.freebsd.org (Postfix) with ESMTP id DD596A90 for ; Tue, 2 Apr 2013 11:17:27 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id m1so306520ves.27 for ; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=j4q6f/hzzi8RjgPo3d1NXqs3Jf8mhk/26YGiWcXjcOQ=; b=GRiKuSloSfsE5MefR7wZ9HnMH7tDnlZMfviae6il9EW7MhWJTW7QLDZDBsOw4rcoRh CIvcMa2WaYQAFPlB6Owzz/5x2CUcEx9a7Hc7IJyaDAiQEdEdL1LG6R+Jsz2argwHsBrk 1XIkF1rqjZOE8Kgt5Q7RKGSM6zyzbWud5CxT/0fRmgwn7Zid2XgJ/yd5CYhdyxalwioJ RccJrUBPBEL0FxvBBdfPBE49xpbtJgqtqC3SjPKbIEzwVLmEl6ZjwJyDMbcoE8XlSAfk 2G7m/cpvwVwI/bqNiLPJ9VfPaSbY71Z4Xe8Ys+OMXShtuVICQAeFGCN1f87AQReMf25U zTOA== MIME-Version: 1.0 X-Received: by 10.220.155.8 with SMTP id q8mr12065231vcw.42.1364901441254; Tue, 02 Apr 2013 04:17:21 -0700 (PDT) Sender: isabell@issyl0.co.uk Received: by 10.220.84.71 with HTTP; Tue, 2 Apr 2013 04:17:21 -0700 (PDT) X-Originating-IP: [87.246.88.161] Date: Tue, 2 Apr 2013 12:17:21 +0100 X-Google-Sender-Auth: BvPd5I1XgjbcT5mSJnXrYcYBacQ Message-ID: Subject: Call for FreeBSD 2013-Q1 status reports! From: Isabell Long To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmA/07936tsYLgTOJJcp60a/+aO4XPNFIZSgQ++pbMU70fQ7NqcDiK10G8OVw9Un7iVETYj X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 11:17:28 -0000 Hi all, On behalf of monthly@, I would like to inform you that the next submission date for the January to March quarterly status reports is April 21st, 2013 - less than a month away. They don't have to be very long - anything that lets people know what is going on inside FreeBSD is useful. Note that submission of reports is not restricted to committers - anyone who is doing anything interesting and FreeBSD-related can write one! The preferred and easiest submission method is to use the XML generator linked to from http://www.freebsd.org/news/status/status.html, with the result emailed as an attachment to monthly@FreeBSD.org. On that page, there is also a link to an XML template which can be filled out manually and attached if preferred. To enable compilation and publication of the Q1 report as soon as possible after the April 21st deadline, please be prompt with any report submissions you may have. I look forward to compiling the report for 2013 Q1. Many thanks, Isabell. (Hat: monthly@) From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 11:28:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4DE8A712 for ; Tue, 2 Apr 2013 11:28:16 +0000 (UTC) (envelope-from dmitryluhtionov@gmail.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 27D8DB58 for ; Tue, 2 Apr 2013 11:28:16 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id h8so227420iaa.29 for ; Tue, 02 Apr 2013 04:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=tgILAM/Q7+NPnv+f5gHgd/p3EGKmOVPGrobt4D6sE/E=; b=GcODZSe9ikS29atzB3cZiybIvTwqVr03CZCxLQgajQpKwjJ9r4nFr9iOmcGacmI289 Pazgvj9Oyy0DnhAs5Q4687MRTtb4P0X72XJ89qK3k62Kxd8lTxlAYPhEdXK0aMF0h1NG LW5fcOp2l1DqXH55QQMAowBeCgEUl/4JpUF/ljUwR6Thhl9CdnA0T2Ib8SkCi4YOkZSm 296kBDfLEe73bbprKHyOK+//YzdPwX9XLVGFlQLmvZsfsQDy99ig58+oE5EZR/OZWshU ifxhQxWZcS26/6+RXGEwZpZw2Gwc6T2kvHho2btmKmsrp2lhDLQ6nt89E/H4PiAENS9Q nOmw== MIME-Version: 1.0 X-Received: by 10.50.17.234 with SMTP id r10mr4739691igd.102.1364902095412; Tue, 02 Apr 2013 04:28:15 -0700 (PDT) Received: by 10.43.138.10 with HTTP; Tue, 2 Apr 2013 04:28:15 -0700 (PDT) Date: Tue, 2 Apr 2013 14:28:15 +0300 Message-ID: Subject: 9-STABLE buildworld compile error From: Dmitry Luhtionov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 11:28:16 -0000 When I put MALLOC_PRODUCTION=yes in /etc/make/conf, make buildworld hangs with error /usr/src/lib/libc/stdlib/ malloc.c:126:1: error: "MALLOC_PRODUCTION" redefined : error: this is the location of the previous definition This is a patch, which avoid this error --- /usr/src/lib/libc/stdlib/Makefile.inc.orig 2012-12-04 11:53:28.000000000 +0200 +++ /usr/src/lib/libc/stdlib/Makefile.inc 2013-04-02 14:14:35.000000000 +0300 @@ -51,7 +51,3 @@ malloc.3 realloc.3 malloc.3 reallocf.3 malloc.3 malloc_usable_size.3 MLINKS+=tsearch.3 tdelete.3 tsearch.3 tfind.3 tsearch.3 twalk.3 -.if defined(MALLOC_PRODUCTION) -CFLAGS+= -DMALLOC_PRODUCTION -.endif - From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 13:34:04 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81048462 for ; Tue, 2 Apr 2013 13:34:04 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2BE2D5 for ; Tue, 2 Apr 2013 13:34:04 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UN1LZ-0003ba-Ln; Tue, 02 Apr 2013 13:33:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r32DXsxr019615; Tue, 2 Apr 2013 07:33:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX192uw+6u8De0CnNOMl4g7v5 Subject: Re: 9-STABLE buildworld compile error From: Ian Lepore To: Dmitry Luhtionov In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Apr 2013 07:33:54 -0600 Message-ID: <1364909634.1312.21.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 13:34:04 -0000 On Tue, 2013-04-02 at 14:28 +0300, Dmitry Luhtionov wrote: > When I put MALLOC_PRODUCTION=yes in /etc/make/conf, make buildworld hangs > with error > /usr/src/lib/libc/stdlib/ > malloc.c:126:1: error: "MALLOC_PRODUCTION" redefined > : error: this is the location of the previous definition > > This is a patch, which avoid this error > > --- /usr/src/lib/libc/stdlib/Makefile.inc.orig 2012-12-04 > 11:53:28.000000000 +0200 > +++ /usr/src/lib/libc/stdlib/Makefile.inc 2013-04-02 14:14:35.000000000 > +0300 > @@ -51,7 +51,3 @@ > malloc.3 realloc.3 malloc.3 reallocf.3 malloc.3 malloc_usable_size.3 > MLINKS+=tsearch.3 tdelete.3 tsearch.3 tfind.3 tsearch.3 twalk.3 > > -.if defined(MALLOC_PRODUCTION) > -CFLAGS+= -DMALLOC_PRODUCTION > -.endif > - That's because MALLOC_PRODUCTION is already defined in -stable. The right fix would be to remove it from your make.conf, because it's no longer necessary in -current either -- the performance problems that originally led to the advice to put MALLOC_PRODUCTION in make.conf for -current have been fixed. -- Ian From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 18:39:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id DBAD63B3; Tue, 2 Apr 2013 18:39:26 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id E7BB123CED6; Tue, 2 Apr 2013 20:39:25 +0200 (CEST) Message-ID: <515B25D8.7050902@FreeBSD.org> Date: Tue, 02 Apr 2013 20:39:20 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4607F44AD83573971B4E25C3" Cc: Alexander Motin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 18:39:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4607F44AD83573971B4E25C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 31.03.2013 23:02, schrieb Scott Long: > So what I hear you and Matthias saying, I believe, is that it should be= easier to > force disks to fall back to non-NCQ mode, and/or have a more responsive= > black-list for problematic controllers. Would this help the situation?= It's hard to > justify holding back overall forward progress because of some bad contr= ollers; > we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD = 9.x, > enough to make up a sizable percentage of the internet's traffic, and w= e see no > problems. How can we move forward but also take care of you guys with > problematic hardware? Well, I am running the driver fine off of my WD Caviar RE3 disk, and the problematic drive also works just fine with Windows and Linux, so it must be something between the problematic drive and the FreeBSD driver. I would like to see any of this, in decreasing order of precedence: - debugged driver - assistance/instructions on helping how to debug the driver/trace NCQ stuff/... (as in Jeremy Chadwick's followup in this same thread - this helps, I will attempt to procure the required information; "back then", reducing the number of tags to 31 was ineffective, including an error message and getting a value of 32 when reading the setting back) - "user-space" contingency features, such as letting camcontrol limit the number of open NCQ tags, or disable NCQ, either on a per-drive basis I am capable of debugging C - mostly with gdb command-line, and graphical Windows IDEs - but am unfamiliar with FreeBSD kernel debugging. If necessary, I can pull up a second console, but the PC that is affected is legacy-free, so serial port only works through a serial/USB converter. --------------enig4607F44AD83573971B4E25C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFbJd0ACgkQvmGDOQUufZXgTQCdHbEU7eARpq9xywE6doCJKcs1 5HEAoJibxdGKMztwTmtPi5GaVGnuTW4q =sEXh -----END PGP SIGNATURE----- --------------enig4607F44AD83573971B4E25C3-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 18:43:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 9B35B648 for ; Tue, 2 Apr 2013 18:43:37 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id D32FA23CED6 for ; Tue, 2 Apr 2013 20:43:36 +0200 (CEST) Message-ID: <515B26D8.9020305@FreeBSD.org> Date: Tue, 02 Apr 2013 20:43:36 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <20130401131415.GQ3178@equilibrium.bsdes.net> <5159A2A8.3090705@freebsd.org> In-Reply-To: <5159A2A8.3090705@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4B86CED45A1EEA4B5185170" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 18:43:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4B86CED45A1EEA4B5185170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 01.04.2013 17:07, schrieb Stefan Esser: > Am 01.04.2013 15:14, schrieb Victor Balada Diaz: >> Being able to configure quirks from loader.conf for disks AND controll= ers would be great >> and is not hard to do. If you want i can do a patch in two weeks and s= end it to you. That >> way it's easy to test disabling NCQ and/or other things in case of hit= ting a bug. Also >> being able to modify the configuration without a kernel recompile woul= d be a big >> improvement because we could still use freebsd-update to keep systems = updated. >=20 > Something like: >=20 > kern.cam.ada.0.quirks=3D1 >=20 > to force 4KB sectors? >=20 > No need to implement that, it is in -CURRENT (did not check -STABLE). > But there is no quirk, that disables NCQ, currently, although it is > easy to implement. See the places where "ADA_FLAG_CAN_NCQ" is set and > make that value depend on a new quirk flag being unset ... >=20 > But instead of setting that flag in the loader, it would be good to > collect drive signatures that need it and to add quirk entries for > them in ata_da.c ... Before we can do that, we need to know if it's really the drive's fault or if the driver is wrong. We need to debug that. If we have relevant parameters exposed through the CAM interface (rather than loader variables), that would also help expedite the debugging. --------------enigF4B86CED45A1EEA4B5185170 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFbJtgACgkQvmGDOQUufZUfzQCgiMalykGpr/6QGxYAxc0o1z2M n0cAnjr/zvT1tPwF2k7Ndr7LWkarCP5Z =Ca4h -----END PGP SIGNATURE----- --------------enigF4B86CED45A1EEA4B5185170-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 21:08:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB10BE82 for ; Tue, 2 Apr 2013 21:08:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD60ABC for ; Tue, 2 Apr 2013 21:08:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1388B964; Tue, 2 Apr 2013 17:08:07 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: [patch] IPMI KCS can drop the lock while servicing a request Date: Tue, 2 Apr 2013 17:04:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514E6ED8.9040305@vangyzen.net> In-Reply-To: <514E6ED8.9040305@vangyzen.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304021704.07197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 02 Apr 2013 17:08:08 -0400 (EDT) Cc: Eric van Gyzen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 21:08:08 -0000 On Saturday, March 23, 2013 11:11:20 pm Eric van Gyzen wrote: > At work, we discovered that our application's IPMI thread would often > use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, > so it can run without sleeping for a "long" time with a slow BMC. It > also holds the ipmi_softc.ipmi_lock during this time. When using > adaptive mutexes, an application thread that wants to operate on the > ipmi_pending_requests list will also spin during this same time. > > We see no reason that the KCS thread needs to hold the lock while > servicing a request. We've been running with the attached patch for a > few months, with no ill effects. The lock protects against concurrent access to the registers themselves (though the thread sort of does this already). However, even with a slow BMC it shouldn't be waiting but so long. I had some other comments about this patch in my reply to when it was committed. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 21:08:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20440E84 for ; Tue, 2 Apr 2013 21:08:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 00983ABF for ; Tue, 2 Apr 2013 21:08:11 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5299CB9AE; Tue, 2 Apr 2013 17:08:10 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: gptzfsboot: error 4 lba 30 Date: Tue, 2 Apr 2013 17:07:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> In-Reply-To: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304021707.14719.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 02 Apr 2013 17:08:10 -0400 (EDT) Cc: Kai Gallasch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 21:08:11 -0000 On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote: > Hi. > > On one of my fresh installed servers I am seeing the following output during boot: > > gptzfsboot: error 4 lba 30 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 30 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 > gptzfsboot: error 4 lba 31 Humm, do you have disks that the BIOS sees that are small? An error code of 4 means 'sector not found' or 'read error'. It would be interesting to see the output of 'lsdev -v' from the loader prompt. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 22:43:26 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66B9DC67 for ; Tue, 2 Apr 2013 22:43:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 03C2196 for ; Tue, 2 Apr 2013 22:43:25 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hn17so948495wib.12 for ; Tue, 02 Apr 2013 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ibbNoFv0mn9ILtSA3tzdyAo6dcdJEwJlANZTWI66TG0=; b=RQIFs1rdsIKOkSCHxgopHMDA6+hVrykHmGLqoJFkQuvxR5OydFjrbs86XQBv4Uz9ZP XgDBKV9j/IfRj1mIiJ91G6XsZeYwjgsTfdN+Fgjx68nMQqzNeV6mXPFJKF7mRtxyTvYK 8c8vTPssWV/gq0kTg7WcwZIzL5t9KlPpg+0otsGdY09wLEGHHXIU5Oi0GWW1xm0e3/qC R61LfZLsBPAy1IBBYmuaNXwofmqAJ6zpgYEuQMSfGQ29Yo8pJJDfyRH5Maq1Toz2GmCa KnEp/iz+B7ri2z3njclEruETn99SYXU302tQ/V3RKGos691BjE5Y8vFHetDbh1DKF9D7 Qscw== MIME-Version: 1.0 X-Received: by 10.180.89.105 with SMTP id bn9mr426969wib.26.1364942605183; Tue, 02 Apr 2013 15:43:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 2 Apr 2013 15:43:25 -0700 (PDT) In-Reply-To: <514E6ED8.9040305@vangyzen.net> References: <514E6ED8.9040305@vangyzen.net> Date: Tue, 2 Apr 2013 15:43:25 -0700 X-Google-Sender-Auth: Qn5YQJpV868rLNpSL548gU62p-8 Message-ID: Subject: Re: [patch] IPMI KCS can drop the lock while servicing a request From: Adrian Chadd To: Eric van Gyzen Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Apr 2013 22:43:26 -0000 On 23 March 2013 20:11, Eric van Gyzen wrote: > At work, we discovered that our application's IPMI thread would often use a > lot of CPU time. The KCS thread uses DELAY to wait for the BMC, so it can > run without sleeping for a "long" time with a slow BMC. It also holds the > ipmi_softc.ipmi_lock during this time. When using adaptive mutexes, an > application thread that wants to operate on the ipmi_pending_requests list > will also spin during this same time. > > We see no reason that the KCS thread needs to hold the lock while servicing > a request. We've been running with the attached patch for a few months, > with no ill effects. Typically holding a lock is to serialise both program state and hardware state. The whole "unlock; do blocking work or sleep; lock" thing needs to be very carefully thought out. Adrian From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 01:15:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C07F35FC for ; Wed, 3 Apr 2013 01:15:41 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 59B9892A for ; Wed, 3 Apr 2013 01:15:41 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so1096241wgg.24 for ; Tue, 02 Apr 2013 18:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=4PkVFJvefTpIAFbadv7CoVB8/VNT6wbWf4IkdASJdIw=; b=tF5SZPEVrGLbVfeQOQZizIMeQpWiMWlJchL4gOp/YheTEK7bdTe/5Qdujf28zcFrFg 8kVySM8bR5g0B3UmzRa2MU9dXGTfR8BRbJ20gx2LhaokzH7WNZ8MMKvYFw/LK+x6eIMX NxSwc6VZ3tH+LF+btdq2uerRZ7DG2tRTVlhwc+o05/CNuGYCTW0n+3SV5Sh3MvF56eQR MdzFDxdTzJIMLjhAMDp8GEAdlejS4P3jNr2PmTAjnM2bw5tARoC+uW7gmOw8b1MjKF6o eORzSs9gnJVBhafNGr2y1VPPGITmGPJD/sq4xSofb4LmoXe2MnY6Zd218OHp8Ymsrdze FM0A== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr25011066wjs.45.1364951740161; Tue, 02 Apr 2013 18:15:40 -0700 (PDT) Received: by 10.194.158.164 with HTTP; Tue, 2 Apr 2013 18:15:40 -0700 (PDT) In-Reply-To: References: <44li94vdq7.fsf@lowell-desk.lan> <44hajsvclt.fsf@lowell-desk.lan> Date: Tue, 2 Apr 2013 20:15:40 -0500 Message-ID: Subject: Re: problem building world on 9.1 stable after changing 100% to svn From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org, Lowell Gilbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 01:15:41 -0000 Finally have all working as expected. I finally just erased sources and ports, rebuilt and restarted freebsd and I'm finally ok. Lowell, thanks for your support and suggestions. I will now try to forget all csup, cvsup, etc. Thank goodness that portmaster still handles ports as always and svn is working fine. ed On Sat, Mar 30, 2013 at 4:10 PM, Edwin L. Culp W. wro= te: > > > On Sat, Mar 30, 2013 at 3:47 PM, Lowell Gilbert < > freebsd-stable-local@be-well.ilk.org> wrote: > >> "Edwin L. Culp W." writes: >> >> > On Sat, Mar 30, 2013 at 3:23 PM, Lowell Gilbert < >> > freebsd-stable-local@be-well.ilk.org> wrote: >> >> It's possible you're building with the wrong set of headers, but ever= y >> >> case I can think of would have given you an error earlier than this. >> >> Do you get any output from: >> >> # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c >> >> by any chance? >> >> >> >> What command did you use for your initial source checkout from >> SubVersion? >> >> >> > >> > I did it twice. >> > >> > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c >> > M xinstall.c >> > # cd /usr/src/usr.bin/xinstall/ && svn status xinstall.c >> > M xinstall.c >> > >> > Hopefully you will find something there. >> >> Yup, that's clearly wrong. For the moment I'll assume you did the >> initial checkout correctly. Or at least in some wrong way that doesn't >> require you to remove the whole tree and check it out again (which >> definitely is what you should have done the first time, by the way). >> > > If the below instructions don't solve it, I'll remover the tree. It is > the same tree that I was updating with cvsup daily for years. It could b= e > causing the problem. > > >> I'm guessing the revert part is what you really need, but go to the >> /usr/src directory and try: >> # svn cleanup >> or >> # svn revert -R * >> >> and if you're still lost, >> # svn status . >> will tell you what is in your tree that is different from a pristine one= . >> > > Thanks a lot, > > This will keep me busy and should solve the problem, if not erase and > restart ;) I'm sure that will do it. > > Enjoy what is left of Easter if you live where it is celebrated. > > ed > --=20 Bienes Ra=EDces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/1= 02249989850215?sk=3Dphotos_albums From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 01:49:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04CAAEA4 for ; Wed, 3 Apr 2013 01:49:03 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id DA149B61 for ; Wed, 3 Apr 2013 01:49:02 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta12.emeryville.ca.mail.comcast.net with comcast id KC2q1l0020FhH24ACDp1aE; Wed, 03 Apr 2013 01:49:01 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id KDp01l00Z1t3BNj8UDp1vZ; Wed, 03 Apr 2013 01:49:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BE4BE73A1C; Tue, 2 Apr 2013 18:49:00 -0700 (PDT) Date: Tue, 2 Apr 2013 18:49:00 -0700 From: Jeremy Chadwick To: "Edwin L. Culp W." Subject: Re: problem building world on 9.1 stable after changing 100% to svn Message-ID: <20130403014900.GA43237@icarus.home.lan> References: <44li94vdq7.fsf@lowell-desk.lan> <44hajsvclt.fsf@lowell-desk.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364953741; bh=B/5gPLOlbP/gl/hJwgzMr3muXmxKOdu/JGZ+Vz+WrQ4=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=Wx79T+Z+y5nDhPO97G6hamh9UCHZdXwvB7IYiuy5WzptUrVvmJbQLeUzUq+OIRDQP NPWbEVXAPTynIRsDNlFqlbVooWr8xyrZI5ar6eH4UmAkK5W4dl8CNDIeb7Onf0lOg/ OwD9D1FzBwjSI7KLncWIp9CzfU2hzG0h7oRSCUlX4HLiHzVWzVZJwEbg5F6uvYVaoS Ef2twEfTu+TkOSLaTEbfJfCXv8mwgmaOjuhQq4IicrPbqMYRldNm1SD7MIvHpc/m0H lGuBVV+3F6Q+gOy53KuSp4oOYeRuNI55kgzmbl8hG5j42+zCP09soMYwxvPw55zWYV +IKBWyRlTYQFQ== Cc: freebsd-stable@freebsd.org, Lowell Gilbert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 01:49:03 -0000 On Tue, Apr 02, 2013 at 08:15:40PM -0500, Edwin L. Culp W. wrote: > Finally have all working as expected. I finally just erased sources and > ports, rebuilt and restarted freebsd and I'm finally ok. > > Lowell, thanks for your support and suggestions. I will now try to forget > all csup, cvsup, etc. Thank goodness that portmaster still handles ports > as always and svn is working fine. Don't forget to: - rm -fr /usr/sup if you've used cvsup on the system - rm -fr /var/db/sup/* if you've used csup on the system -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 06:11:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 55DE8CCC for ; Wed, 3 Apr 2013 06:11:54 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id DB2066D2 for ; Wed, 3 Apr 2013 06:11:53 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id jk13so575876bkc.3 for ; Tue, 02 Apr 2013 23:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; bh=7Zi+G0YCh46pPSKIN/wZuC/lJakmirLEXZX6kIxEH3U=; b=JR5KBzGRcBQo74e/j7l9NlxtHVT4q1XcW41TKlKcNzd+BAuryoEkoE4zi24ACURgih IdPw94A7WMAe61KW81ESblZuCHkBD/Dl99oSeMJ72UvnMLW34mgke3UlQrAjQWa+VLw2 qrrvkEooONKbbvhV0sr9JoigXVT76U5D0yzC/53WDkQetx99SlyVlXKIPWY1rB8Sw9Zn VWCvC4BjpeA9KFhJZcQUskzdiCeO12QXrOPAjbOkU3o1HEY32+S6n5ikj068yaV03rAq LIWe/rtCuStInHY+uUW6tMvma01JeKi2V6S2c3CQGjwPM3GXQlIkWHp2NjxKPIsYRpco YE8w== X-Received: by 10.204.168.15 with SMTP id s15mr199196bky.69.1364969512915; Tue, 02 Apr 2013 23:11:52 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id io13sm1703978bkc.15.2013.04.02.23.11.51 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 23:11:52 -0700 (PDT) Date: Wed, 3 Apr 2013 09:12:18 +0300 From: "Sergey V. Dyatko" To: freebsd-stable@freebsd.org Subject: Re: gptzfsboot: error 4 lba 30 Message-ID: <20130403091218.101d3642@laptop.minsk.domain> In-Reply-To: <201304021707.14719.jhb@freebsd.org> References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> <201304021707.14719.jhb@freebsd.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 06:11:54 -0000 On Tue, 2 Apr 2013 17:07:14 -0400 John Baldwin wrote: > On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote: > > Hi. > > > > On one of my fresh installed servers I am seeing the following > > output during > boot: > > > > gptzfsboot: error 4 lba 30 ... > > gptzfsboot: error 4 lba 31 > > Humm, do you have disks that the BIOS sees that are small? An error > code of 4 means 'sector not found' or 'read error'. It would be > interesting to see the output of 'lsdev -v' from the loader prompt. > by the way, where I can find a transcript of codes? -- wbr, tiger From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 06:32:49 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6CDA7584 for ; Wed, 3 Apr 2013 06:32:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B58797B8 for ; Wed, 3 Apr 2013 06:32:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA18650; Wed, 03 Apr 2013 09:32:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UNHFW-000FHt-3w; Wed, 03 Apr 2013 09:32:46 +0300 Message-ID: <515BCD0A.3070901@FreeBSD.org> Date: Wed, 03 Apr 2013 09:32:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Sergey V. Dyatko" Subject: Re: gptzfsboot: error 4 lba 30 References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> <201304021707.14719.jhb@freebsd.org> <20130403091218.101d3642@laptop.minsk.domain> In-Reply-To: <20130403091218.101d3642@laptop.minsk.domain> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 06:32:49 -0000 on 03/04/2013 09:12 Sergey V. Dyatko said the following: > On Tue, 2 Apr 2013 17:07:14 -0400 > John Baldwin wrote: > >> On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote: >>> Hi. >>> >>> On one of my fresh installed servers I am seeing the following >>> output during >> boot: >>> >>> gptzfsboot: error 4 lba 30 > ... >>> gptzfsboot: error 4 lba 31 >> >> Humm, do you have disks that the BIOS sees that are small? An error >> code of 4 means 'sector not found' or 'read error'. It would be >> interesting to see the output of 'lsdev -v' from the loader prompt. >> > > by the way, where I can find a transcript of codes? In the BIOS Int 13h documentation. E.g.: http://stanislavs.org/helppc/int_13-2.html http://www.bioscentral.com/misc/biosint13.htm -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 09:13:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1A6C781 for ; Wed, 3 Apr 2013 09:13:09 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by mx1.freebsd.org (Postfix) with ESMTP id 996CCE82 for ; Wed, 3 Apr 2013 09:13:08 +0000 (UTC) Received: from localhost ([92.156.227.243]) by mwinf5d39 with ME id KMCz1l00m5FjRcU03MD0dt; Wed, 03 Apr 2013 11:13:00 +0200 Message-ID: <515BF29B.9000701@orange.fr> Date: Wed, 03 Apr 2013 11:12:59 +0200 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Why tzdata2013b has not be merged to stable/8 ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: edwin@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 09:13:10 -0000 Hi, On March 15, tzdata2013b has been merged to head (r248307), to stable/6 (r248308), to stable/7 (r248309) and to stable/9 (r248310). But not to stable/8. I dare think than having an up to date zoneinfo could be a must for the incoming 8.4 release.. Claude Buisson From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 09:26:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75C95ACE; Wed, 3 Apr 2013 09:26:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id A83F3F3D; Wed, 3 Apr 2013 09:26:12 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id ik5so674623bkc.34 for ; Wed, 03 Apr 2013 02:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jaEBGAJH3UakwCfUj8P0wDHH/j7krKpd3n7CgCXtK3M=; b=uZD8Yj0cZ9rmGppdRz0SMkJxiFY6xu5M8xpJw9fY7RQvQLYcGla+sF2VeQKGO0/J6x zCpvSUYIDnbJx0/5LtY4TcxJlPRzoQVurOYmc0WzhxXJ3VN8sSSSPosNhQiJ5QVxIo7s delOpq19Gbf28JxOkMuUvTxLWwf24gOTqQ/ohZj5fq9cthZQqo/zyJI0GzgCm8OCdimw ShTmpgpXDBw3lF7AwnLw8lUs0Ec39fjAJG2f6J1N0+k9StotyPWdQHm3paG2TmsSSWT1 9FEikEZWF7S+jEr/FUYKb65vfoCuhiKcCYCMRgh1row0khULh9qIOuqXmxKwgZorI0aR mdoQ== X-Received: by 10.205.103.67 with SMTP id dh3mr670862bkc.19.1364981171605; Wed, 03 Apr 2013 02:26:11 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o2sm2196418bkv.3.2013.04.03.02.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 02:26:10 -0700 (PDT) Sender: Alexander Motin Message-ID: <515BF5AE.4050804@FreeBSD.org> Date: Wed, 03 Apr 2013 12:26:06 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130326 Thunderbird/17.0.4 MIME-Version: 1.0 To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> In-Reply-To: <515B25D8.7050902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 09:26:13 -0000 On 02.04.2013 21:39, Matthias Andree wrote: > Am 31.03.2013 23:02, schrieb Scott Long: > >> So what I hear you and Matthias saying, I believe, is that it should be easier to >> force disks to fall back to non-NCQ mode, and/or have a more responsive >> black-list for problematic controllers. Would this help the situation? It's hard to >> justify holding back overall forward progress because of some bad controllers; >> we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x, >> enough to make up a sizable percentage of the internet's traffic, and we see no >> problems. How can we move forward but also take care of you guys with >> problematic hardware? > > Well, I am running the driver fine off of my WD Caviar RE3 disk, and the > problematic drive also works just fine with Windows and Linux, so it > must be something between the problematic drive and the FreeBSD driver. > > I would like to see any of this, in decreasing order of precedence: > > - debugged driver > > - assistance/instructions on helping how to debug the driver/trace NCQ > stuff/... (as in Jeremy Chadwick's followup in this same thread - this > helps, I will attempt to procure the required information; "back then", > reducing the number of tags to 31 was ineffective, including an error > message and getting a value of 32 when reading the setting back) Unfortunately, I don't know how to debug that. Command timeouts reported on the lists before are the kind of errors that are most difficult to diagnose since the controller gives no information to do that. We just see that sent commands are no longer completing. May be it is some incompatibility of specific drive and HBA firmwares, triggered by some innocent specifics of our ATA stack, GEOM or filesystems implementation. All I can propose is to try to identify such cases and add some quirks to workaround it, like disabling NCQ or limiting number of tags. I am not sure what else can we do about it without some controlled lab environment with affected hardware and SATA analyzer. > - "user-space" contingency features, such as letting camcontrol limit > the number of open NCQ tags, or disable NCQ, either on a per-drive basis I've merged support for that to 8/9-STABLE about 9 months ago: `camcontrol tags ada0 -v -N X` should change number of simultaneously used tags, `camcontrol negotiate ada0 -T (en|dis)able` should enable/disable use of NCQ. I just did some tests on HEAD and these commands seems like working. If you can reproduce the problem, it would be nice to collect information how these changes affect it. > I am capable of debugging C - mostly with gdb command-line, and > graphical Windows IDEs - but am unfamiliar with FreeBSD kernel > debugging. If necessary, I can pull up a second console, but the PC that > is affected is legacy-free, so serial port only works through a > serial/USB converter. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 11:17:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9B57B39; Wed, 3 Apr 2013 11:17:47 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward17.mail.yandex.net (forward17.mail.yandex.net [IPv6:2a02:6b8:0:1402::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E43B724; Wed, 3 Apr 2013 11:17:47 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward17.mail.yandex.net (Yandex) with ESMTP id 8EE031061450; Wed, 3 Apr 2013 15:17:44 +0400 (MSK) Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 45AAA19002DB; Wed, 3 Apr 2013 15:17:44 +0400 (MSK) Received: from v10-165-42.yandex.net (v10-165-42.yandex.net [84.201.165.42]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id EmmYj1FGNl-Hh7qiiCl; Wed, 3 Apr 2013 15:17:44 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1364987864; bh=w6EPArYkiSNNGWQyMuiQwWhSK/5LeLz5ytzynBWc8Xk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=cMcFdt5T1nPmqOM9wVFdAQqWMz84MEigh/SYFuLTMI2c2D83CmFxJgbHjdHPeBFIK KyJwDht+4xJoV0eND4ixK81G6YSWiw0WW36SYabHu5gCEns27WfvAVoJYhPig6FpEQ AKue2rD0L2V012apLgjSi+A3v9mfRqSutWNsO6Ss= Message-ID: <515C0F6A.1000900@yandex.ru> Date: Wed, 03 Apr 2013 15:15:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: gptzfsboot: error 4 lba 30 References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> <201304021707.14719.jhb@freebsd.org> In-Reply-To: <201304021707.14719.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kai Gallasch , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 11:17:47 -0000 On 03.04.2013 01:07, John Baldwin wrote: >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 > > Humm, do you have disks that the BIOS sees that are small? An error code of 4 > means 'sector not found' or 'read error'. It would be interesting to see the > output of 'lsdev -v' from the loader prompt. Hi, Usually, I see such messages when the system has some virtual IPMI devices. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 21:29:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7630C6BE for ; Wed, 3 Apr 2013 21:29:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 54C94FD4 for ; Wed, 3 Apr 2013 21:29:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 79143B960; Wed, 3 Apr 2013 17:29:23 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, d@delphij.net Subject: Re: 9.1-REL Supermicro H8DCL-iF kernel panic Date: Wed, 3 Apr 2013 15:34:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130401122550.GA7367@icarus.home.lan> <5159B5FA.1080005@delphij.net> In-Reply-To: <5159B5FA.1080005@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304031534.06872.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Apr 2013 17:29:23 -0400 (EDT) Cc: Jeremy Chadwick , Ryan McIntosh X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 21:29:24 -0000 On Monday, April 01, 2013 12:29:46 pm Xin Li wrote: > Yes, this is a bandaid and the right fix should be refactor the code a > little bit to make sure that no interrupt handler is installed before > the driver have done other initializations but I don't have hardware > that can reproduce this issue handy to validate changes like that. It is not that easy. I instrumented the crap out of the igb driver on the one machine where I could reliably reproduce this and kept clearing the interrupt cause register during attach multiple times and still got a spurious interrupt. I believe this is a chip bug of some sort, but I've no idea whose fault it is. It has only been reported on SuperMicro *8* boards to date. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 22:15:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 20858319; Wed, 3 Apr 2013 22:15:36 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 4448623CED6; Thu, 4 Apr 2013 00:15:35 +0200 (CEST) Message-ID: <515CAA04.1050108@FreeBSD.org> Date: Thu, 04 Apr 2013 00:15:32 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> In-Reply-To: <515BF5AE.4050804@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8376BEA5B9FB187BC8515317" Cc: Jeremy Chadwick , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 22:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8376BEA5B9FB187BC8515317 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have just sent more information to the PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=3D157397 The short summary (more info in the PR) is: - limiting tags to 31 does not help - disabling NCQ appears to help in initial testing, but warrants more testing - error happens during WRITE_FPDMA_QUEUED, - File system in question is SU+J UFS2 mounted on /usr, and I can for instance "rm -rf /usr/obj" or just log into GNOME and try to open a gnome-terminal to trigger stalls; - Linux uses 31 tags (for different reason) and has no drive quirks, but a controller quirk; for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag - it gets set by Linux on the SB700 that my computer is using, see ahci_error_intr() in libahci.h - I am not going to interpret that for lack of expertise, but it does affect error handling and appears to ignore a certain condition. Why only my Samsung HDD drive triggers this but not the WD drive, I do not know yet. Hope that helps a bit. --------------enig8376BEA5B9FB187BC8515317 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcqgcACgkQvmGDOQUufZWWaQCeMAxtWxO2tGDhIYihltp7k5vt tG4AoOJs+E3ZKj5bYzdPuOJZASipS4CZ =7HNI -----END PGP SIGNATURE----- --------------enig8376BEA5B9FB187BC8515317-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 3 23:38:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AB9D28E for ; Wed, 3 Apr 2013 23:38:17 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEDA850 for ; Wed, 3 Apr 2013 23:38:17 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id KTVF1l0051zF43QA1beG2A; Wed, 03 Apr 2013 23:38:16 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id KbeF1l00S1t3BNj8kbeGyr; Wed, 03 Apr 2013 23:38:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BBB4A73A1C; Wed, 3 Apr 2013 16:38:15 -0700 (PDT) Date: Wed, 3 Apr 2013 16:38:15 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130403233815.GA65719@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CAA04.1050108@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365032296; bh=0vyC6baetUvnRbBry/tm2+XU83XvplLjZi9RWo9evOU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=RgYrX0EyULHIM1ALaofprwNRQgSop0/vPgAixR+EeriyA5yTygcy0Lv9FfbbzA5D5 gVikG22P8vYlaT24lM9mRy6PJyMexHSCqgAwo7fVdNZX8YeDVRnwcvxO4bH5u5SQPz jM1zLMPwL+tpRfygwFtUPwGQoUSxM4ffCXzQ4juE8qSS9WE1CAyaa0ycP1pijOk7Sl /SBXN8mwCKm4jo7346iWM03q4kHp9aKNa9kAcF0z3VZRbRatwWlFieL1JAlizVLKZy TJW64jH7/YxHjgm5m6sk0ZfpUupKYClQEVyK7KLdIbNk04gAxIWbqYPumRnv9qSCHi rcb0cmQ7sHpWw== Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 03 Apr 2013 23:38:17 -0000 On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote: > I have just sent more information to the PR at > http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 > > The short summary (more info in the PR) is: > > - limiting tags to 31 does not help > > - disabling NCQ appears to help in initial testing, but warrants more > testing > > - error happens during WRITE_FPDMA_QUEUED, This is an NCQ-based write LBA request. There are many non-NCQ equivalents of this, ATA-protocol-wise (too many to list here), but the most likely non-NCQ ATA command you'd see is WRITE_DMA48. > - File system in question is SU+J UFS2 mounted on /usr, and I can for > instance "rm -rf /usr/obj" or just log into GNOME and try to open a > gnome-terminal to trigger stalls; > > - Linux uses 31 tags (for different reason) and has no drive quirks, but > a controller quirk; > > for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it > might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag > - it gets set by Linux on the SB700 that my computer is using, see > ahci_error_intr() in libahci.h - I am not going to interpret that for > lack of expertise, but it does affect error handling and appears to > ignore a certain condition. Alexander could expand on this, but the name of the flag implies that there are certain conditions where the SATA-level SERR condition gets ignored ("IGN"). While skimming Linux libata code and commits in the past, the only glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the hardware revision apparently matters) and port multiplier (PMP) support and soft resets. Are you using a port multiplier? I doubt it, but I have to ask. > Why only my Samsung HDD drive triggers this but not the WD drive, I do > not know yet. Please provide "gpart show -p ada1" output, both here and in the PR, if you could. I have a gut feeling I know what the issue is (and if it is what I think it is, it's actually happening all the time, just that NCQ exacerbates it given how command queueing works), but I won't know for sure until I see the output. Thanks. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 4 00:19:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 33536C16; Thu, 4 Apr 2013 00:19:20 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 5791423CED6; Thu, 4 Apr 2013 02:19:19 +0200 (CEST) Message-ID: <515CC704.90302@FreeBSD.org> Date: Thu, 04 Apr 2013 02:19:16 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> In-Reply-To: <20130403233815.GA65719@icarus.home.lan> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7D83C6BF10896513FA0E81E0" Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Apr 2013 00:19:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7D83C6BF10896513FA0E81E0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04.04.2013 01:38, schrieb Jeremy Chadwick: =2E.. > While skimming Linux libata code and commits in the past, the only > glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the > hardware revision apparently matters) and port multiplier (PMP) support= > and soft resets. >=20 > Are you using a port multiplier? I doubt it, but I have to ask. I am not using a PMP as far as I know (unless one is buried on my Asus M4A78T-E main board). It would seem the drives are directly attached to the south bridge's SATA ports. >> Why only my Samsung HDD drive triggers this but not the WD drive, I do= >> not know yet. >=20 > Please provide "gpart show -p ada1" output, both here and in the PR, > if you could. =3D> 63 1953525105 ada1 MBR (931G) 63 209714337 ada1s1 freebsd [active] (100G) 209714400 800 - free - (400k) 209715200 71680000 ada1s2 ntfs (34G) 281395200 15405 - free - (7.5M) 281410605 488263545 ada1s3 linux-data (232G) 769674150 1183851018 - free - (564G) HTH Best regards Matthias --------------enig7D83C6BF10896513FA0E81E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFcxwcACgkQvmGDOQUufZVwqgCg4D2AxN7XOv4agaXe1bDiIT9G aXoAoLj3C/ZWIYRT2SzZCd6PEv5bm/U0 =6bx7 -----END PGP SIGNATURE----- --------------enig7D83C6BF10896513FA0E81E0-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 4 01:05:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C29D14AC for ; Thu, 4 Apr 2013 01:05:27 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by mx1.freebsd.org (Postfix) with ESMTP id A429ED74 for ; Thu, 4 Apr 2013 01:05:27 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta06.emeryville.ca.mail.comcast.net with comcast id KcyE1l0011u4NiLA6d5TFs; Thu, 04 Apr 2013 01:05:27 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id Kd5S1l00T1t3BNj8hd5SEK; Thu, 04 Apr 2013 01:05:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 832C173A1C; Wed, 3 Apr 2013 18:05:26 -0700 (PDT) Date: Wed, 3 Apr 2013 18:05:26 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130404010526.GA66858@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CC704.90302@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365037527; bh=6KMV9MX9XtyQcKBuLMhAYtElbw73yRPlpG0rTWp8tOo=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=Gi+Lbo9t/DnlA6rXp3u6SvSpON/hmtszUVUX7RhgSEUj/ajujvGdBNbgRr5vLo3L5 jFjSG4TslSObP39yc7+h7InsidAiEpOuaC0PIe6IDVvokyXWzYjEh+/2btc8nGW/Jn gajQ4qU/89921Wqhim083ArzN13GULhHmQOcewqNCdVB0/z+NlB2VJ/5URE2Siz3cc zoG4XFSkn1QbLCWFzpU/28F7rcqekdlX/u2a7qOMlbPuFrz9aVj1UZJcmekW+ztXvF YLNNoRAuxzJdWlunIYHmgCTa6F6P1oRgzqVIwdkSzRC34QiVRGuguYXDLO+5BosWLE zEhVK4p9F4+4Q== Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Apr 2013 01:05:27 -0000 On Thu, Apr 04, 2013 at 02:19:16AM +0200, Matthias Andree wrote: > Am 04.04.2013 01:38, schrieb Jeremy Chadwick: > > ... > > > While skimming Linux libata code and commits in the past, the only > > glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the > > hardware revision apparently matters) and port multiplier (PMP) support > > and soft resets. > > > > Are you using a port multiplier? I doubt it, but I have to ask. > > I am not using a PMP as far as I know (unless one is buried on my Asus > M4A78T-E main board). It would seem the drives are directly attached to > the south bridge's SATA ports. Then the answer is nope, you're not using a PM. Details: http://www.serialata.org/technology/port_multipliers.asp http://en.wikipedia.org/wiki/Port_multiplier > >> Why only my Samsung HDD drive triggers this but not the WD drive, I do > >> not know yet. > > > > Please provide "gpart show -p ada1" output, both here and in the PR, > > if you could. > > => 63 1953525105 ada1 MBR (931G) > 63 209714337 ada1s1 freebsd [active] (100G) > 209714400 800 - free - (400k) > 209715200 71680000 ada1s2 ntfs (34G) > 281395200 15405 - free - (7.5M) > 281410605 488263545 ada1s3 linux-data (232G) > 769674150 1183851018 - free - (564G) This is what I was worried about. Referring to your "camcontrol identify" output: > device model SAMSUNG HD103SI > sector size logical 512, physical 512, offset 0 Hear me out entirely on this one. My theory is that your hard disk actually uses 4096-byte sectors but is too old to provide ATA IDENTIFY semantics to delineate between logical vs. physical sector size. In other words, only logical is provided, thus logical=physical in the eyes of all software; smartctl will show you the exact same thing too. There are drives like this in the wild, both SSDs as well as MHDDs. For example, the Intel 320-series SSD behaves this way too (providing only logical size). Do not let the capacity/size of the drive be the deciding factor; your drive is 1TB, but I also have many 1TB MHDDs that use 4096-byte sectors. Seagate/Samsung's specification** for the HD103SI states, and I quote: "Byte per Sensor: 512 bytes". Yes, it says "Sensor". Whether or not this documentation is correct/accurate is unknown, and when vendors have typos in their own specification docs, I cannot help but to honour the possibility of the information being wrong. So I'm unsure if this drive uses 512-byte sectors or 4096-byte sectors. That said: in your "gpart show ada1" output, none of your partitions (FreeBSD, NTFS, nor Linux) appear to be aligned to 4096-byte boundaries. Ideally you'd want to have these aligned to 1MB or 2MByte boundaries in the case you ever move to an SSD. You're also using the MBR scheme, which does not tend to play well with alignment. Comparatively, your WD5002ABYS drive **does** use 512-byte sectors (I know this for a fact). The problem here is that I cannot guarantee you that alignment is the problem. The performance impact of writes to partitions which are non-aligned is quite high, and NCQ just exacerbates this problem. I would love to tell you "switch to GPT and follow Warren Block's document***" but if your NTFS partition is Windows and is a Windows version older than Windows 7 GPT is not supported. One piece of evidence that refutes my theory is that if Windows and/or Linux partition are something you boot into and use often, I would imagine NCQ would be used in both of those environments and would suffer from the same issue. Although Windows tends to hide all sorts of transient errors from the user (sigh), Linux tends to be like FreeBSD with regards to such issues (on the console anyway; you wouldn't see such messages normally inside of X). If you have the time and want to put forth the effort, I would recommend backing up all your data on ada1, zero the first and last 1MByte of the drive, and then try following Warren Block's guide. I'd just recommend doing this: gpart create -s gpt ada1 gpart add -t freebsd-ufs -b 2m ada1 newfs -U -j /dev/ada1p1 (or remove -j if you don't want to use SUJ) I picked an alignment value of 2MBytes since it's both 4K-aligned and is generally safe for things like newer SSDs that have larger NAND erase block size (I am not going to get into a discussion about that here, so please stay focused. :-) ) If the problem is gone after that (it should be easy to induce by writing tons and tons of data to the drive), then we can safely say that the drive uses 4096-byte sectors and need to add it to the quirks list in ata_da.c. If the problem remains after that, then further investigation is needed, and we can safely rule out alignment. Welcome to all the pain/effort one has to go through when troubleshooting things like this. :-) Another thing: in your PR you state: > - I am running with kern.cam.ada.default_timeout=5 which makes the > computer recover faster I can definitely imagine cases where a drive using NCQ but doing writes to a non-aligned partition could take longer than 5 seconds to respond to an ATA CDB (this is different than a SATA or AHCI layer timeout). I am not telling you "change this back to 30", but it might not be helping your situation at all given my above theory. Finally: could you please provide output from "smartctl -x /dev/ada1"? I would like to rule out any possibility of your drive having some other kind of issue that might cause it to go catatonic. Thanks. ** -- http://www.seagate.com/files/www-content/support-content/documentation/samsung/tech-specs/eco_greenf2.pdf *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 4 08:00:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id B6C97CAE; Thu, 4 Apr 2013 08:00:23 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id E64AA23CED6; Thu, 4 Apr 2013 10:00:22 +0200 (CEST) Message-ID: <515D3312.3010109@FreeBSD.org> Date: Thu, 04 Apr 2013 10:00:18 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> In-Reply-To: <20130404010526.GA66858@icarus.home.lan> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05900F9F959D20FB9CBDA030" Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 04 Apr 2013 08:00:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05900F9F959D20FB9CBDA030 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04.04.2013 03:05, schrieb Jeremy Chadwick: >>> Please provide "gpart show -p ada1" output, both here and in the PR, >>> if you could. >> >> =3D> 63 1953525105 ada1 MBR (931G) >> 63 209714337 ada1s1 freebsd [active] (100G) >> 209714400 800 - free - (400k) >> 209715200 71680000 ada1s2 ntfs (34G) >> 281395200 15405 - free - (7.5M) >> 281410605 488263545 ada1s3 linux-data (232G) >> 769674150 1183851018 - free - (564G) Thanks for all the useful information provided so far (including further down). I know some of that already, but am not going to complain because it is very useful in the logs. > The problem here is that I cannot guarantee you that alignment is > the problem. The performance impact of writes to partitions which are > non-aligned is quite high, and NCQ just exacerbates this problem. I > would love to tell you "switch to GPT and follow Warren Block's > document***" but if your NTFS partition is Windows and is a Windows ver= sion > older than Windows 7 GPT is not supported. I am happy to make that realign-and-use-GPT experiment. My Windows is "7 Professional 64-bit". It will take me a few days because this is spare-time stuff. > One piece of evidence that refutes my theory is that if Windows and/or > Linux partition are something you boot into and use often, I would > imagine NCQ would be used in both of those environments and would suffe= r > from the same issue. Although Windows tends to hide all sorts of > transient errors from the user (sigh), Linux tends to be like FreeBSD > with regards to such issues (on the console anyway; you wouldn't see > such messages normally inside of X). Now, the FreeBSD slice is the only partition on that disk that would likely see concurrent write accesses (think "make -j8" on a quadcore computer) which is more prone to ferret out such alignment contention. The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit the problem anyways. The Linux partition is in ext4 format for mostly sequential access to files usually in excess of 10 MB each. Linux's ext4 jumps through several hoops to end up with bulk writes, like extents, delayed allocations (to avoid fragmentation), reordering of data and metadata writes, serialized log writes and all that stuff, and it would appear I am permitting it to cache writes -- Linux uses write barriers to enforce proper ordering of journal/meta-data writes. It would be rather hard to hit ATA taskfile timeouts, the expected rate with which the drive needs to do a partial write is orders of magnitude lower. Any good "concurrent write" exercise tools for Unix that I could run on the Linux ext4 partition that you would propose? > If you have the time and want to put forth the effort, I would recommen= d > backing up all your data on ada1, zero the first and last 1MByte of the= > drive, and then try following Warren Block's guide. I'd just recommend= > doing this: >=20 > gpart create -s gpt ada1 > gpart add -t freebsd-ufs -b 2m ada1 > newfs -U -j /dev/ada1p1 (or remove -j if you don't want to use SUJ) Will do. >> - I am running with kern.cam.ada.default_timeout=3D5 which makes the >> computer recover faster >=20 > I can definitely imagine cases where a drive using NCQ but doing writes= > to a non-aligned partition could take longer than 5 seconds to respond > to an ATA CDB (this is different than a SATA or AHCI layer timeout). I= am > not telling you "change this back to 30", but it might not be helping > your situation at all given my above theory. My feeling is that the stalls are mostly from the error handler and the overall time the drive is "frozen" gets shorter. If it had not _felt_ faster, I'd not have left that in sysctl.conf in the first place. > Finally: could you please provide output from "smartctl -x /dev/ada1"? > I would like to rule out any possibility of your drive having some othe= r > kind of issue that might cause it to go catatonic. Thanks. I have fetched the data with Linux this time (should not make a difference as it's all drive internal data, not host OS stuff). Looks sane to me, . I'll be happy to refetch this data with a more current smartctl version under FreeBSD if required. >=20 >=20 > ** -- http://www.seagate.com/files/www-content/support-content/document= ation/samsung/tech-specs/eco_greenf2.pdf >=20 > *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html >=20 --------------enig05900F9F959D20FB9CBDA030 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFdMxIACgkQvmGDOQUufZXemgCgk4AJnaRlr17BDpOzvCS7sHej QNIAoMLTA4PsdYY6fCxJ5w8KxwIJQTUX =/vE0 -----END PGP SIGNATURE----- --------------enig05900F9F959D20FB9CBDA030-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 5 09:43:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A119CB2D for ; Fri, 5 Apr 2013 09:43:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5B6B18 for ; Fri, 5 Apr 2013 09:43:24 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1UO31d-000BgS-M9 for freebsd-stable@freebsd.org; Fri, 05 Apr 2013 12:33:37 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: panic: vm_fault_copy_wired: page missing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2013 12:33:37 +0300 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 05 Apr 2013 09:43:25 -0000 The system is running FreeBSD-9.1-stable, and is dataless/diskless. the culprit is mlockall(2) which is called from the automounter amd/am-utils, commenting the call, eliminates the panic. I don't know when the problem surfaced, I was last hit by this 2 years ago almost to the day - creepy. I can make this happen by first running firefox, and the trying some command that involves the automounter. so is someone interested in fixing this? danny From owner-freebsd-stable@FreeBSD.ORG Fri Apr 5 18:50:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7FEE65C3 for ; Fri, 5 Apr 2013 18:50:17 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7AE821 for ; Fri, 5 Apr 2013 18:50:17 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id w4so1717053dam.14 for ; Fri, 05 Apr 2013 11:50:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=poWC4yRDuxQi61QZ5m6wKrfT+Mo0u4eT+DGThrmYwT4=; b=Daq5D6mg9x+gxG5pRnSCodzUf8G1CixNcaHyu4lXkiWFwNTw3PlbMZlT7SaGCTjqeU iEB/ZuLIz2UtA/7UPyr98twBj8P3WMNv3mTZnmeg6WoR+ZRZ3Guxsjq1vmAgJLQWlbA2 4uyEZQV/xnkprlaOvmSVwChWsGseAv68YuGZDgbiIlcwyM5qO8bJ74tZm+1gnfZKFPe7 UHC/f1HKA8+6uhwa94+KbBzjueheT8BrJjAM+8oqaKbEymP/nusTo7ecY75UWBdjzdWM 1BGyuExwVT3gtTxxx2q690lc531IeDGAunCkO3X0xBJ9sTE1HQhJyDG4aumx1bBf2xqw gfqw== X-Received: by 10.68.213.193 with SMTP id nu1mr15879389pbc.178.1365187817053; Fri, 05 Apr 2013 11:50:17 -0700 (PDT) Received: from [192.168.10.2] ([187.210.81.114]) by mx.google.com with ESMTPS id kb3sm15394618pbc.21.2013.04.05.11.50.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 11:50:15 -0700 (PDT) Message-ID: <515F1CE6.8080500@motumweb.com> Date: Fri, 05 Apr 2013 12:50:14 -0600 From: =?ISO-8859-1?Q?Efra=EDn_D=E9ctor?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Problem with portsnap fetch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnXTkEFqh81ev0DQ6JO91OpOxmObJbh39HfCMeegNY7bw0E2ALveCHImrYe5OEcksmkq7HP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 05 Apr 2013 18:50:17 -0000 Hello. Today I ran into a problem when trying to update the ports tree. I executed the following command: # portsnap fetch However I got this message: Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching public key from your-org.portsnap.freebsd.org... done. Fetching snapshot tag from your-org.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Fri Apr 5 00:09:09 UTC 2013: 2c954aa9458bb07dbefad840b7a06e3b9a5f5f90e10963100% of 1045 B 5101 kBps Extracting snapshot... tar: Unrecognized archive format tar: snap: Not found in archive tar: Error exit delayed from previous errors. Looking in the Internet I found that deleting the directory /var/db/portsnap/files should help, however it didn't work, also found that deleting the portsnap directory should do the trick, but this didn't work either I keep getting the same error message. The tar command is functioning correctly (I tested it). uname -a: FreeBSD motum.test.com 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Can you guys please point me in the right direction?. Thanks in advance. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 5 21:19:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 046A08EB for ; Fri, 5 Apr 2013 21:19:39 +0000 (UTC) (envelope-from efraindector@motumweb.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D541BE1C for ; Fri, 5 Apr 2013 21:19:38 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id xa7so2217899pbc.13 for ; Fri, 05 Apr 2013 14:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=oEgaodphXNcKHznySeQkXB7ozlGxPGVLsnF8Zs/bhmg=; b=G1FnNbIBtBhOtYINQ1dY2b6f4NYBxdYyOOA5hANa1TfDHkeHg0Ksa2fI60koKAbJEa ULkDKh//8i9T+q/KjauJBWSzxjRnDa7G1kPFw6yh4ebj5i1MI43FhmeMy4L4oJK3rHvu Wh9IVJBgmPuOyaCX3JyGvho6bBOtvwc6Ix6Up93rlr8sv6yO5ugB3SmtbtF8TyYC63hj RA37t12irn+rWOS7NrwlCewtLpp0ry+eXVqA82EblXDOAsn49k4KX5yxUiutmJitsHgW wyy+lUF+97/QX0nvotoa3s0JWOzRiMH9DfO+mJcKpv9yd1j1WGaviEMpex8mDxoytjRr ipew== X-Received: by 10.66.233.9 with SMTP id ts9mr17506171pac.15.1365196771808; Fri, 05 Apr 2013 14:19:31 -0700 (PDT) Received: from [192.168.10.2] ([187.210.81.114]) by mx.google.com with ESMTPS id kb3sm15760544pbc.21.2013.04.05.14.19.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 14:19:30 -0700 (PDT) Message-ID: <515F3FE1.4080206@motumweb.com> Date: Fri, 05 Apr 2013 15:19:29 -0600 From: =?ISO-8859-1?Q?Efra=EDn_D=E9ctor?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problem with portsnap fetch References: <515F1CE6.8080500@motumweb.com> In-Reply-To: <515F1CE6.8080500@motumweb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQn8rFBaL5ecCb/j/X9uiVIL7S0CFQrYgdl6DPbmQpd0RxcDnKeO76bLB+A145QDRLJpb5VR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 05 Apr 2013 21:19:39 -0000 El 05/04/2013 12:50 p.m., Efraín Déctor escribió: > Hello. Today I ran into a problem when trying to update the ports tree. > > I executed the following command: > > # portsnap fetch > > However I got this message: > > Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. > Fetching public key from your-org.portsnap.freebsd.org... done. > Fetching snapshot tag from your-org.portsnap.freebsd.org... done. > Fetching snapshot metadata... done. > Fetching snapshot generated at Fri Apr 5 00:09:09 UTC 2013: > 2c954aa9458bb07dbefad840b7a06e3b9a5f5f90e10963100% of 1045 B 5101 kBps > Extracting snapshot... tar: Unrecognized archive format > tar: snap: Not found in archive > tar: Error exit delayed from previous errors. > > Looking in the Internet I found that deleting the directory > /var/db/portsnap/files should help, however it didn't work, also found > that deleting the portsnap directory should do the trick, but this > didn't work either I keep getting the same error message. The tar > command is functioning correctly (I tested it). > > uname -a: > FreeBSD motum.test.com 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue > Sep 27 18:45:57 UTC 2011 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Can you guys please point me in the right direction?. > > Thanks in advance. Sorry. It was a problem with the proxy. It was blocking the download of larger files. Thanks. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 6 18:22:53 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FFDD7CB for ; Sat, 6 Apr 2013 18:22:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 68350A41 for ; Sat, 6 Apr 2013 18:22:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA05053; Sat, 06 Apr 2013 21:17:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UOXgH-0006Jj-7p; Sat, 06 Apr 2013 21:17:37 +0300 Message-ID: <516066BF.90103@FreeBSD.org> Date: Sat, 06 Apr 2013 21:17:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: panic: vm_fault_copy_wired: page missing References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Apr 2013 18:22:53 -0000 on 05/04/2013 12:33 Daniel Braniss said the following: > The system is running FreeBSD-9.1-stable, and is dataless/diskless. > the culprit is mlockall(2) which is called from the automounter amd/am-utils, > commenting the call, eliminates the panic. > > I don't know when the problem surfaced, I was last hit by this > 2 years ago almost to the day - creepy. > > I can make this happen by first running firefox, and the trying some > command that involves the automounter. > > so is someone interested in fixing this? So, is there someone interested in properly reporting the problem first? :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Apr 6 20:23:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8AAE95B for ; Sat, 6 Apr 2013 20:23:23 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5B302ED3 for ; Sat, 6 Apr 2013 20:23:23 +0000 (UTC) Received: (qmail 24783 invoked from network); 6 Apr 2013 22:16:40 +0200 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Apr 2013 22:16:40 +0200 Subject: Re: gptzfsboot: error 4 lba 30 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Kai Gallasch In-Reply-To: <201304021707.14719.jhb@freebsd.org> Date: Sat, 6 Apr 2013 22:16:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F20F9F9-CBFD-48B6-8A86-82DAA4AB5BEB@free.de> <201304021707.14719.jhb@freebsd.org> To: freebsd-stable X-Mailer: Apple Mail (2.1085) Cc: John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 06 Apr 2013 20:23:24 -0000 Am 02.04.2013 um 23:07 schrieb John Baldwin: > On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote: >> Hi. >>=20 >> On one of my fresh installed servers I am seeing the following output = during=20 > boot: >>=20 >> gptzfsboot: error 4 lba 30 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 30 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >> gptzfsboot: error 4 lba 31 >=20 > Humm, do you have disks that the BIOS sees that are small? An error = code of 4 > means 'sector not found' or 'read error'. It would be interesting to = see the > output of 'lsdev -v' from the loader prompt. Since upgrading the server to 9-STABLE (2013-03-30) the gptzfsboot error = message miraculously disappeared. Because I upgraded the zpools on this particular server to a new version = ("feature flags") I cannot boot back to 9.1-REL to find out if the = upgrade was the cause of this - or not. When I bootup the server from a 9.1-REL USB stick, I also cannot = reproduce the error. What did I change since seeing the error message the first time? - I put GPT partitions on da2-da7 and used them for zpools - Upgrading 9.1 REL to 9.1-2013-03-30 - refreshed the zfs bootcode on da0/da1 aferwards If the error shows up again on a similar server soon to be upgraded, = I'll give feedback. Kai.=