From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 00:40:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA53106566C for ; Sun, 31 Oct 2010 00:40:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A92438FC12 for ; Sun, 31 Oct 2010 00:40:11 +0000 (UTC) Received: by wwi17 with SMTP id 17so3154232wwi.31 for ; Sat, 30 Oct 2010 17:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=5DDnaJfRPf+LyOrgpWjazjmJdl0kIEAD2UHSgFuyUFs=; b=HYJVjpTGV3ZVeWINNSikdF6UN8Ti7bkjmMO/kQHGweArhWqp72ARqsWukR4+sJ3hJ5 Jc3v9G3fTg0e8kSvWjfHa3r8exQO1aXc44YOImStynCke18H64SEtx2Osz1PAiVW6K+C RAyxpQRATXgZYF6TOXi7nZaV6MAWcS7/ZxOS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MyBh8SRN2j+gZ/yb7a6tgNO1iC2EpdWCyYA50o4FHsd3qDrx0+cXMqa+mLSJUBl2lb pd5sV0vEyifrLT3/tZuhaYPoinayy+nzUvx4+sdjZkFibA3MciI3K0ZRtH00jw/W1kji tubzndbgmk/2sYGP3wgEtU/7i5tYL6/5Nl6ig= MIME-Version: 1.0 Received: by 10.216.182.202 with SMTP id o52mr731320wem.29.1288485610431; Sat, 30 Oct 2010 17:40:10 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Sat, 30 Oct 2010 17:40:10 -0700 (PDT) Date: Sun, 31 Oct 2010 00:40:10 +0000 Message-ID: From: Paul B Mahol To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: panic: loading if_bfe after boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 00:40:12 -0000 Hi, Loading if_bfe module after boot hangs machine, it works/attach fine from loader. Tell me if you need bt. From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 04:41:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4A441065674 for ; Sun, 31 Oct 2010 04:41:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 793828FC12 for ; Sun, 31 Oct 2010 04:41:15 +0000 (UTC) Received: by wwi17 with SMTP id 17so3229849wwi.31 for ; Sat, 30 Oct 2010 21:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=Jv5o+VeHkB+jV9zcC+Gjvor6v38dEfbevbojL9ljrFc=; b=jun8TRPnji2kDSxI0WwhcmvvFHFXUBy9VqDEiJ2tnxz1/T5chePwL7MtuFVwalgl5h cZU0vdXvKtIEO2G3zdfIFNu38JnC419nPKe9zY6aBteA4/03XFmrzvpGfbFVCloDMAaE jmcvG8vyWBs1/s+vAQRKlXEKpa98oy1L05jJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=atv2XMZSe3NvgK7FCdRCoyOPPbds3Lb/BGTnjwNbMLICMuRbyQcNbkqdiOsz7eg1LJ DU9TVU3dreaWn0TP8t/RvXgqu2Tn0TfVuSf4hTclajR+AwjwTgJFqzSrwD3/4+HYUTOv wImt7hJXB9T2pLj+QHE2p5wUy4SkHnd7gKSHk= MIME-Version: 1.0 Received: by 10.216.16.211 with SMTP id h61mr2903786weh.106.1288498746976; Sat, 30 Oct 2010 21:19:06 -0700 (PDT) Received: by 10.216.29.141 with HTTP; Sat, 30 Oct 2010 21:19:06 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 Oct 2010 21:19:06 -0700 Message-ID: From: Pyun YongHyeon To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: panic: loading if_bfe after boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 04:41:16 -0000 On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol wrote: > Hi, > > Loading if_bfe module after boot hangs machine, it works/attach fine > from loader. > > Tell me if you need bt. Yes, I want to see the back trace. From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 11:09:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9A531065698 for ; Sun, 31 Oct 2010 11:09:46 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0A68FC13 for ; Sun, 31 Oct 2010 11:09:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id A36B48061 for ; Sun, 31 Oct 2010 11:53:28 +0100 (CET) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id C0EBA8053; Sun, 31 Oct 2010 11:53:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: Date: Sun, 31 Oct 2010 11:53:19 +0100 Content-Transfer-Encoding: 8bit Message-Id: References: To: David Rhodus X-Mailer: Apple Mail (2.1081) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Oct 31 11:53:28 2010 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 930,4ccd4aa810263770721941 X-DSPAM-Factors: 27, From*Alban, 0.01000, Mime-Version*Message, 0.01000, from, 0.01000, from, 0.01000, of, 0.01000, of, 0.01000, Received*ESMTP, 0.01000, Content-Transfer-Encoding*8bit, 0.01000, Alban+Hertroys, 0.01000, Mime-Version*1.0+(Apple, 0.01000, Hertroys, 0.01000, Date*2010, 0.01000, as, 0.01000, From*Hertroys, 0.01000, From*solfertje.student.utwente.nl>, 0.01000, in, 0.01000, Received*with, 0.01000, Received*id, 0.01000, Received*ESMTP+id, 0.01000, Alban, 0.01000, Received*[10.236.150.4]), 0.01000, Received*2010, 0.01000, From*Hertroys+, 0.01000, for, 0.01000, for, 0.01000, Received*(Postfix)+with, 0.01000 Cc: current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 11:09:46 -0000 On 30 Oct 2010, at 21:19, David Rhodus wrote: > I haven't seen much of this since 5.x days. Anyone else see calcru > messages lately ? I had a bunch of those in my daily-mail this morning as well. I assumed it was due to the DST change last night: Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 11993 usec to 9596 usec for pid 34369 (local) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 13584 usec to 10869 usec for pid 34368 (smtpd) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 11459 usec to 9169 usec for pid 34367 (lmtp) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 13430 usec to 10746 usec for pid 34366 (cleanup) That system isn't running HEAD btw, it runs FreeBSD 7.2-STABLE (upgrade planned). Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4ccd4aa810263770721941! From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 11:38:20 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D72E8106564A for ; Sun, 31 Oct 2010 11:38:20 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep24.mx.upcmail.net (fep24.mx.upcmail.net [62.179.121.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0888FC0C for ; Sun, 31 Oct 2010 11:38:19 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20101031111826.XLXC1424.viefep18-int.chello.at@edge01.upcmail.net>; Sun, 31 Oct 2010 12:18:26 +0100 Received: from mole.fafoe.narf.at ([213.47.85.26]) by edge01.upcmail.net with edge id RPJQ1f05P0a5KZh01PJRsB; Sun, 31 Oct 2010 12:18:26 +0100 X-SourceIP: 213.47.85.26 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 9B3446D420; Sun, 31 Oct 2010 12:18:24 +0100 (CET) Date: Sun, 31 Oct 2010 12:18:24 +0100 From: Stefan Farfeleder To: David Rhodus Message-ID: <20101031111823.GA1776@mole.fafoe.narf.at> References: 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) X-Cloudmark-Analysis: v=1.1 cv=kR1739jI04gsLPPBAx/k25XPeS1fzQof9TaPDYrpM2k= c=1 sm=0 a=cTQVF4nVtLkA:10 a=kj9zAlcOel0A:10 a=r7SUUljForD0Aa57UBAA:9 a=BUb56QaN8rnQCCsnnK58znofRgYA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 11:38:20 -0000 On Sat, Oct 30, 2010 at 03:19:04PM -0400, David Rhodus wrote: > I haven't seen much of this since 5.x days. Anyone else see calcru > messages lately ? Yes, I am seeing those as well in the last weeks, accompanied with sporadic hangs of a few seconds. For now I've been to lazy to investigate further, but I assume it's somehow connected to recent timecounter changes. Stefan From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 19:14:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC50A106566B for ; Sun, 31 Oct 2010 19:14:06 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5078FC1C for ; Sun, 31 Oct 2010 19:14:06 +0000 (UTC) Received: from [109.85.73.168] (helo=tiny.Sisis.de.) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PCdLx-0000Rc-3u for freebsd-current@freebsd.org; Sun, 31 Oct 2010 20:14:05 +0100 Received: from tiny.Sisis.de. (localhost [127.0.0.1]) by tiny.Sisis.de. (8.14.3/8.14.3) with ESMTP id o9VKFrns001343 for ; Sun, 31 Oct 2010 21:15:53 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de. (8.14.3/8.14.3/Submit) id o9VKFqLq001342 for freebsd-current@freebsd.org; Sun, 31 Oct 2010 21:15:52 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de.: guru set sender to guru@unixarea.de using -f Date: Sun, 31 Oct 2010 21:15:52 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20101031201551.GB1302@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 109.85.73.168 Subject: having 'src' and 'obj' in some other place X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 19:14:07 -0000 Hello, I compiled a 9-CURRENT from SVN but having it in a non default place, in /home/guru/9-CURRENT/src. To compile kernel and world I set MAKEOBJDIRPREFIX to /home/guru/9-CURRENT/obj and all went fine. Then I installed kernel und world to the USB key using DESTDIR set to /mnt. Because the idea is to use the USB key for further installation a copied the 'src' and 'obj' to it as well with: # cp -Rp /home/guru/9-CURRENT/src /mnt/usr # cp -Rp /home/guru/9-CURRENT/obj /mnt/usr The USB key boots fine. From this USB key I now wanted to install the system to a partitioned hard disk, again with something like: # cd /usr/src # make installworld DESTDIR=/mnt where below /mnt now the file system of the disk was mounted. This failed with messages about 'install: ... not found' and the way around was to move /usr/src again on the USB key to a faked location of /home/guru/9-CURRENT/src, and as well 'obj'. After this all went fine. Question: Why is this so hardwired bound to the original location of 'src' and 'obj'? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 31 22:15:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87972106564A for ; Sun, 31 Oct 2010 22:15:49 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 495518FC14 for ; Sun, 31 Oct 2010 22:15:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAO+AzUyDaFvO/2dsb2JhbACDCZBEjmqnepEIgSKDL3MEilQ X-IronPort-AV: E=Sophos;i="4.58,268,1286164800"; d="scan'208";a="99119958" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 31 Oct 2010 17:46:57 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7267EB3F65 for ; Sun, 31 Oct 2010 17:46:57 -0400 (EDT) Date: Sun, 31 Oct 2010 17:46:57 -0400 (EDT) From: Rick Macklem To: freebsd-current@freebsd.org Message-ID: <1060261000.280090.1288561617454.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Subject: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 22:15:49 -0000 I recently purchased a laptop that has a re(4) Realtek 8101E/8102E/8103E net chip in it and I find that it is dropping packets like crazy when reading files over an NFS mount. (It seems that bursts of receive traffic cause it, since when I look over wireshark, typically the 2nd packet in a read reply is not received, although it was sent at the other end.) Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude faster reading) Does this hint that interrupts are being lost or delayed too much? Anyhow, if anyone has an idea on what the cause/fix might be or are familiar with the driver/hardware, I'd appreciate hearing about it. Thanks, rick ps: This laptop is running a low end AMD cpu and I did install amd64 on it, instead of i386, in case that might be relevent? From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 10:32:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF75A1065673 for ; Mon, 1 Nov 2010 10:32:06 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6D68FC1A for ; Mon, 1 Nov 2010 10:32:05 +0000 (UTC) Received: by bwz3 with SMTP id 3so4382763bwz.13 for ; Mon, 01 Nov 2010 03:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vZEKy/H95sXfIGKwMSCkq+oD//sMHNWNBuMsurddPqQ=; b=ZrHf3BhODe7F3YA+RoLmZ39VO4+wQLqlS1ad4M4XthCL1edJChoMk3Wq5jwWO3XaIj IqMc6MFpRWNYr3p7gs1FdBpDeaON5tsMKoiawwnWvU4W+qtTbeMFi4l39kstFqtNp1Kw wgco6hZ5kHFhDklgHxzUw5jqZTGZrg3i+MJIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=OJ06J+sZyOV3eVYynEPqAWMNZ3b86tJnF+X+pVusJdNwwnWtrahsVyt50RSJqBaN/B 34gLIkYmTy7YYkqOOuzGZastk/5q7AKWDAkxA1EC2QRWwUGGUyOQ7By3im/9rZt7w8WD GOoSDmCdH23lj9NYe+I1Kq1Zr1GxESZXSXYvc= Received: by 10.204.52.7 with SMTP id f7mr4786732bkg.190.1288605993714; Mon, 01 Nov 2010 03:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.18.16 with HTTP; Mon, 1 Nov 2010 03:06:13 -0700 (PDT) In-Reply-To: <20101031201551.GB1302@tiny.Sisis.de> References: <20101031201551.GB1302@tiny.Sisis.de> From: Eir Nym Date: Mon, 1 Nov 2010 13:06:13 +0300 Message-ID: To: Matthias Apitz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: having 'src' and 'obj' in some other place X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 10:32:06 -0000 On 31 October 2010 23:15, Matthias Apitz wrote: > > Hello, > > I compiled a 9-CURRENT from SVN but having it in a non default place, > in /home/guru/9-CURRENT/src. To compile kernel and world I set > MAKEOBJDIRPREFIX to /home/guru/9-CURRENT/obj and all went fine. Then I > installed kernel und world to the USB key using DESTDIR set to /mnt. > > Because the idea is to use the USB key for further installation a copied > the 'src' and 'obj' to it as well with: > > # cp -Rp /home/guru/9-CURRENT/src /mnt/usr > # cp -Rp /home/guru/9-CURRENT/obj /mnt/usr > > The USB key boots fine. From this USB key I now wanted to install the > system to a partitioned hard disk, again with something like: > > # cd /usr/src > # make installworld DESTDIR=3D/mnt > > where below /mnt now the file system of the disk was mounted. This failed > with messages about 'install: ... not found' and the way around was to > move /usr/src again on the USB key to a faked location of > /home/guru/9-CURRENT/src, and as well 'obj'. After this all went fine. > You can experiment with moving /usr/obj//home/guru/9-CURRENT/src to /usr/obj/usr/src > Question: Why is this so hardwired bound to the original location of > 'src' and 'obj'? > you can see /usr/share/mk/bsd.obj.mk for details. make(1) creates directory ${MAKEOBJDIRPREFIX}/${.CURDIR} . It is useful when you make world for yourself, do some development stuff with another things, etc. > Thanks > > =C2=A0 =C2=A0 =C2=A0 =C2=A0matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I do installation with another method: On build server I make world, install it into some directory, and make cpio(1) archive to save file rights. Then I copy archive to usb and unpack it into new system. One more question for community: does cpio(1) archive format save file flags (see chflags(1))? From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 14:38:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C5CAC1065698; Mon, 1 Nov 2010 14:38:38 +0000 (UTC) Date: Mon, 1 Nov 2010 14:38:38 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101101143838.GA64120@freebsd.org> References: <20101020153040.GA3184@freebsd.org> <201010201955.56816.hselasky@c2i.net> <4CC529CF.8000304@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC529CF.8000304@FreeBSD.org> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: serious issue caused by usb device, stalling almost all operations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 14:38:38 -0000 On Mon Oct 25 10, Alexander Motin wrote: > Hans Petter Selasky wrote: > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > >> hi there, > >> > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: > >> > >> after attaching my mobile phone, it simply resets without doing mount or > >> anything. however after letting the device come up again it won't show up > >> in the console. after detaching it the usb subsystem seemed to have > >> completely crashed. but that's not all. the following programs now simply > >> hang without producing any output C-C won't do anything: > >> > >> - dmesg > >> - top > >> - ps > >> - killall > >> - camcontrol devlist > >> - usbconfig > > > > That's most likely because USB's umass driver is waiting for cam to drain. > > Possibly some refcounting is not correct. I suspect this is not a USB problem. > > Try to enter into the debugger, and look for backtrace for function stuck in > > umass_detach. i set debug.kdb.panic=1, but didn't work, because writing the core dump stalled and watchdog came up. any advice? cheers. alex > > It is a bit suspicious that problem happens only when device dies during > request. Are you sure that running command was properly aborted when > device got detached? Every running command has own set of references, > denying detach. > > -- > Alexander Motin -- a13x From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 17:09:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9422B106564A; Mon, 1 Nov 2010 17:09:27 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 618358FC19; Mon, 1 Nov 2010 17:09:25 +0000 (UTC) Received: by fxm17 with SMTP id 17so5280121fxm.13 for ; Mon, 01 Nov 2010 10:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=vrpEkDQSL2A+rWpxazgyW6ponGSdsNpby+af2PDDhz0=; b=AoQ7u9413My2Iwixxt5HznpsJP24pY/qkagbBbYRuH3GmNSbc2IcgS8zWDv3twY9uL /F9Q9bhwwgVn4EY86X0TlpLDl3OE0J+OOkTOmC8/s0pTn64h1kJiFeeSTEMmh8mAXBXZ FJsPBzMH5LIbGU1DKZfO/TtmnrW43PXHpyp7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=mU0QdiOZ5NlOwMjNcxOCt1ITSGTIincHEooAyMPjDvAVcKF7nRuC92aansKzlK+aPy ORsjPe1WY1Q67C9y1+usAk7b5+H46E/Zk0Zi84VU6K3iEWOGTmC1BHAe2W5I4L/1lfjT qdoy/3FRAiLRD/BlDrh4Dq1F7YYETven74UUg= MIME-Version: 1.0 Received: by 10.223.96.208 with SMTP id i16mr3716263fan.34.1288631362787; Mon, 01 Nov 2010 10:09:22 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.223.115.84 with HTTP; Mon, 1 Nov 2010 10:09:22 -0700 (PDT) In-Reply-To: <4CBD40E2.7030507@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> <4CBD40E2.7030507@freebsd.org> Date: Mon, 1 Nov 2010 18:09:22 +0100 X-Google-Sender-Auth: 344Q2qF9BWK1ewHJquut2j003aw Message-ID: From: Giovanni Trematerra To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:09:27 -0000 On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > on 19/10/2010 00:01 Giovanni Trematerra said the following: >> >> Your patch seems just a work around about initial slab size where the >> keg is backed. > > Well, setting aside my confusion with the terminology - yes, the patch is just > that, and precisely because I only tried to solve that particular problem. > >> Having dynamic slab sizes would allow to have the keg backed on a larger slab >> without going OFFPAGE. > > I agree in principle. > But without seeing code that implements that I can't guess if it would really be > more efficient or more maintainable, i.e. more useful in general. > Still a very good idea. > Here the patch that was in my mind. The patch doesn't implement dynamic slab size just allow to have a multipage slab to back uma_zone objects. I'm going to work more on the topic "dynamic slab size" soon. I tested the patch on qemu with -smp 32. I'm looking for real hw to test the patch on. here some interesting output: qemulab# vmstat -z | more ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 149, 4, 149, 0, 0 UMA Zones: 4480, 0, 149, 0, 149, 0, 0 UMA Slabs: 568, 0, 836, 4, 1187, 0, 0 UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0 UMA Hash: 256, 0, 2, 13, 3, 0, 0 qemulab# sysctl kern | grep cpu kern.ccpu: 0 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 kern.smp.cpus: 32 kern.smp.maxcpus: 32 Any feedback will be appreciate. -- Giovanni Trematerra ============================================================== diff -r 36572cbc6817 sys/vm/uma_core.c --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400 +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400 @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes { uma_keg_t keg; uma_slab_t tmps; - - keg = zone_first_keg(zone); + u_int16_t pages; + + keg = zone_first_keg(zone); + pages = bytes / PAGE_SIZE; + + /* Account for remainder */ + if ((pages * PAGE_SIZE) < bytes) + pages++; + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n")); /* * Check our small startup cache to see if it has pages remaining. */ mtx_lock(&uma_boot_pages_mtx); - if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) { - LIST_REMOVE(tmps, us_link); + do { + if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) + LIST_REMOVE(tmps, us_link); + } while (--pages && tmps != NULL); + if (tmps != NULL) { mtx_unlock(&uma_boot_pages_mtx); *pflag = tmps->us_flags; return (tmps->us_data); - } + } else if (booted == 0) + panic("UMA: Increase vm.boot_pages"); mtx_unlock(&uma_boot_pages_mtx); - if (booted == 0) - panic("UMA: Increase vm.boot_pages"); /* * Now that we've booted reset these users to their real allocator. */ #ifdef UMA_MD_SMALL_ALLOC - keg->uk_allocf = uma_small_alloc; + keg->uk_allocf = (keg->uk_ppera > 1) ? page_alloc : uma_small_alloc; #else keg->uk_allocf = page_alloc; #endif @@ -1163,7 +1172,7 @@ keg_small_init(uma_keg_t keg) static void keg_large_init(uma_keg_t keg) { - int pages; + u_int16_t pages; KASSERT(keg != NULL, ("Keg is null in keg_large_init")); KASSERT((keg->uk_flags & UMA_ZFLAG_CACHEONLY) == 0, @@ -1177,12 +1186,15 @@ keg_large_init(uma_keg_t keg) keg->uk_ppera = pages; keg->uk_ipers = 1; + keg->uk_rsize = keg->uk_size; + + /* We can't do OFFPAGE if we're internal, bail out here. */ + if (keg->uk_flags & UMA_ZFLAG_INTERNAL) + return; keg->uk_flags |= UMA_ZONE_OFFPAGE; if ((keg->uk_flags & UMA_ZONE_VTOSLAB) == 0) keg->uk_flags |= UMA_ZONE_HASH; - - keg->uk_rsize = keg->uk_size; } static void @@ -1301,7 +1313,8 @@ keg_ctor(void *mem, int size, void *udat #endif if (booted == 0) keg->uk_allocf = startup_alloc; - } + } else if (booted == 0 && (keg->uk_flags & UMA_ZFLAG_INTERNAL)) + keg->uk_allocf = startup_alloc; /* * Initialize keg's lock (shared among zones). @@ -1330,7 +1343,7 @@ keg_ctor(void *mem, int size, void *udat if (totsize & UMA_ALIGN_PTR) totsize = (totsize & ~UMA_ALIGN_PTR) + (UMA_ALIGN_PTR + 1); - keg->uk_pgoff = UMA_SLAB_SIZE - totsize; + keg->uk_pgoff = (UMA_SLAB_SIZE * keg->uk_ppera) - totsize; if (keg->uk_flags & UMA_ZONE_REFCNT) totsize = keg->uk_pgoff + sizeof(struct uma_slab_refcnt) @@ -1346,7 +1359,7 @@ keg_ctor(void *mem, int size, void *udat * mathematically possible for all cases, so we make * sure here anyway. */ - if (totsize > UMA_SLAB_SIZE) { + if (totsize > UMA_SLAB_SIZE * keg->uk_ppera) { printf("zone %s ipers %d rsize %d size %d\n", zone->uz_name, keg->uk_ipers, keg->uk_rsize, keg->uk_size); From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 17:30:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2979A1065787 for ; Mon, 1 Nov 2010 17:30:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB2878FC0C for ; Mon, 1 Nov 2010 17:30:46 +0000 (UTC) Received: by vws12 with SMTP id 12so4129783vws.13 for ; Mon, 01 Nov 2010 10:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=1IKMJ1yjMHnw8ANEZkbPsVy7Hd68yHoWg5j/lNbhry8=; b=wqwUDPOPijFbOxJD7sfuv7nCPgh04tmkcHIm9NmoqhAcDM21NicYPB3+IT7u23i/mp 5lCbvDDpfRFau1UXS8eNSk6ODgicfMDp3OWOdzY3CublY7vheTSFQYRcTST+1r4W1kVL e+99rZm/FwS7stcIAetThOsTvnUaeK7fnw8uM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=hBtflYGGt5K+9mEvks/S1fvXLFuqowkJHWJCxCE8iUbwSALN7PXGSHJe5s66QL2eG5 yTp6j5vwkk8NR/OEF1TVcUd1cA8o9uWDCbXgF4uSjWXKVl56YNBbJ3tgz7r/fuR/rcbu MJamEqfORHbBhxh3OuWiZ7OUxcqEjoACX00QY= Received: by 10.229.229.199 with SMTP id jj7mr1006538qcb.130.1288632645956; Mon, 01 Nov 2010 10:30:45 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l14sm5200207qck.29.2010.11.01.10.30.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 10:30:43 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 1 Nov 2010 10:30:36 -0700 From: Pyun YongHyeon Date: Mon, 1 Nov 2010 10:30:36 -0700 To: Rick Macklem Message-ID: <20101101173036.GA1433@michelle.cdnetworks.com> References: <1060261000.280090.1288561617454.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1060261000.280090.1288561617454.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 17:30:49 -0000 On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > I recently purchased a laptop that has a re(4) Realtek 8101E/8102E/8103E net > chip in it and I find that it is dropping packets like crazy when reading > files over an NFS mount. (It seems that bursts of receive traffic cause it, > since when I look over wireshark, typically the 2nd packet in a read reply > is not received, although it was sent at the other end.) > Are you using NFS over UDP? > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude faster > reading) Does this hint that interrupts are being lost or delayed too much? > Actually I'm not a fan of polling(4) but re(4) controllers might be exceptional one due to controller limitation but order of magnitude faster indicates something is wrong in driver. > Anyhow, if anyone has an idea on what the cause/fix might be or are familiar > with the driver/hardware, I'd appreciate hearing about it. > AFAIK re(4) controllers lacks interrupts moderation so re(4) used to rely on taskqueue to reduce number of interrupts. It was written long time ago by Bill and I'm not sure whether it's still valid for recent PCIe RealTek controllers. One of problem is getting stand-alone PCIe controllers in market and I was not able to buy recent controllers. This is one of reason why re(4) still lacks TSO, jumbo frame and 64bit DMA support for newer controllers. Another problem is RealTek no longer releases data sheet so it's hard to write new features that may present on recent controllers. Recent re(4) controllers started to support small set of hardware MAC statistics counters and that may help to understand how many frames were lost under heavy load. I'll let you know when I have a patch for that. Flow-control may also enhance performance a little bit but it was not implemented yet like most other consumer grade ethernet drivers. But this may change in near future, marius@ is actively working on this so we'll get generic flow-control framework in tree. I'll see what can be done in interrupt handler and I'll let you know when patch is ready. > Thanks, rick > ps: This laptop is running a low end AMD cpu and I did install amd64 on it, > instead of i386, in case that might be relevent? I don't think so. From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 19:16:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D69C6106566B; Mon, 1 Nov 2010 19:16:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A33428FC14; Mon, 1 Nov 2010 19:16:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3FB6246B65; Mon, 1 Nov 2010 15:16:15 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6E6FA8A009; Mon, 1 Nov 2010 15:16:10 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 1 Nov 2010 15:14:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C9B9B9C.6000807@freebsd.org> <4CBD40E2.7030507@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011011514.50322.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 15:16:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: alc@freebsd.org, kib@freebsd.org, Giovanni Trematerra , Andriy Gapon Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:16:15 -0000 On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote: > On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > > on 19/10/2010 00:01 Giovanni Trematerra said the following: > >> > >> Your patch seems just a work around about initial slab size where the > >> keg is backed. > > > > Well, setting aside my confusion with the terminology - yes, the patch is just > > that, and precisely because I only tried to solve that particular problem. > > > >> Having dynamic slab sizes would allow to have the keg backed on a larger slab > >> without going OFFPAGE. > > > > I agree in principle. > > But without seeing code that implements that I can't guess if it would really be > > more efficient or more maintainable, i.e. more useful in general. > > Still a very good idea. > > > > Here the patch that was in my mind. > The patch doesn't implement dynamic slab size just allow > to have a multipage slab to back uma_zone objects. > I'm going to work more on the topic "dynamic slab size" soon. > I tested the patch on qemu with -smp 32. > I'm looking for real hw to test the patch on. > > here some interesting output: > qemulab# vmstat -z | more > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > UMA Kegs: 208, 0, 149, 4, 149, 0, 0 > UMA Zones: 4480, 0, 149, 0, 149, 0, 0 > UMA Slabs: 568, 0, 836, 4, 1187, 0, 0 > UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0 > UMA Hash: 256, 0, 2, 13, 3, 0, 0 > > qemulab# sysctl kern | grep cpu > kern.ccpu: 0 > 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, > 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, > 28, 29, 30, 31 > kern.smp.cpus: 32 > kern.smp.maxcpus: 32 > > Any feedback will be appreciate. > > -- > Giovanni Trematerra > > > ============================================================== > diff -r 36572cbc6817 sys/vm/uma_core.c > --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400 > +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400 > @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes > { > uma_keg_t keg; > uma_slab_t tmps; > - > - keg = zone_first_keg(zone); > + u_int16_t pages; > + > + keg = zone_first_keg(zone); > + pages = bytes / PAGE_SIZE; > + > + /* Account for remainder */ > + if ((pages * PAGE_SIZE) < bytes) > + pages++; > + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n")); You can use 'pages = howmany(bytes, PAGE_SIZE)' here. Also, why did you make pages a uint16_t instead of an int? An int is generally more convenient unless you really need a uint16_t (and C99 spells it without an _ after the leading 'u'.. FYI). > /* > * Check our small startup cache to see if it has pages remaining. > */ > mtx_lock(&uma_boot_pages_mtx); > - if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) { > - LIST_REMOVE(tmps, us_link); > + do { > + if ((tmps = LIST_FIRST(&uma_boot_pages)) != NULL) > + LIST_REMOVE(tmps, us_link); > + } while (--pages && tmps != NULL); > + if (tmps != NULL) { > mtx_unlock(&uma_boot_pages_mtx); > *pflag = tmps->us_flags; > return (tmps->us_data); > - } > + } else if (booted == 0) > + panic("UMA: Increase vm.boot_pages"); > mtx_unlock(&uma_boot_pages_mtx); > - if (booted == 0) > - panic("UMA: Increase vm.boot_pages"); Probably best to make the pages test here explicit. Also, is there any reason you can't do this as: while (--pages > 0) { tmps = LIST_FIRST(&uma_boot_pages); if (tmps != NULL) LIST_REMOVE(tmps, us_link); else if (booted == 0) panic(...); } One question btw, how does this work since if you need to allocate more than 1 page it seems that the 'tmps' values for all but the last are simply ignored and leaked? Is there some unwritten assumption that the free pages are all virtually contiguous (and in order), so you can just pull off a run of X and use the address from X? > /* > * Now that we've booted reset these users to their real allocator. > */ > #ifdef UMA_MD_SMALL_ALLOC > - keg->uk_allocf = uma_small_alloc; > + keg->uk_allocf = (keg->uk_ppera > 1) ? page_alloc : uma_small_alloc; > #else > keg->uk_allocf = page_alloc; > #endif > @@ -1163,7 +1172,7 @@ keg_small_init(uma_keg_t keg) > static void > keg_large_init(uma_keg_t keg) > { > - int pages; > + u_int16_t pages; > > KASSERT(keg != NULL, ("Keg is null in keg_large_init")); > KASSERT((keg->uk_flags & UMA_ZFLAG_CACHEONLY) == 0, > @@ -1177,12 +1186,15 @@ keg_large_init(uma_keg_t keg) > > keg->uk_ppera = pages; > keg->uk_ipers = 1; > + keg->uk_rsize = keg->uk_size; > + > + /* We can't do OFFPAGE if we're internal, bail out here. */ > + if (keg->uk_flags & UMA_ZFLAG_INTERNAL) > + return; > > keg->uk_flags |= UMA_ZONE_OFFPAGE; > if ((keg->uk_flags & UMA_ZONE_VTOSLAB) == 0) > keg->uk_flags |= UMA_ZONE_HASH; > - > - keg->uk_rsize = keg->uk_size; > } > > static void > @@ -1301,7 +1313,8 @@ keg_ctor(void *mem, int size, void *udat > #endif > if (booted == 0) > keg->uk_allocf = startup_alloc; > - } > + } else if (booted == 0 && (keg->uk_flags & UMA_ZFLAG_INTERNAL)) > + keg->uk_allocf = startup_alloc; > > /* > * Initialize keg's lock (shared among zones). > @@ -1330,7 +1343,7 @@ keg_ctor(void *mem, int size, void *udat > if (totsize & UMA_ALIGN_PTR) > totsize = (totsize & ~UMA_ALIGN_PTR) + > (UMA_ALIGN_PTR + 1); > - keg->uk_pgoff = UMA_SLAB_SIZE - totsize; > + keg->uk_pgoff = (UMA_SLAB_SIZE * keg->uk_ppera) - totsize; > > if (keg->uk_flags & UMA_ZONE_REFCNT) > totsize = keg->uk_pgoff + sizeof(struct uma_slab_refcnt) > @@ -1346,7 +1359,7 @@ keg_ctor(void *mem, int size, void *udat > * mathematically possible for all cases, so we make > * sure here anyway. > */ > - if (totsize > UMA_SLAB_SIZE) { > + if (totsize > UMA_SLAB_SIZE * keg->uk_ppera) { > printf("zone %s ipers %d rsize %d size %d\n", > zone->uz_name, keg->uk_ipers, keg->uk_rsize, > keg->uk_size); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 19:53:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 346EA106566C; Mon, 1 Nov 2010 19:53:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id E0B038FC19; Mon, 1 Nov 2010 19:53:50 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=ZJKxzO8xKrIA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=oRQRuTlL4tF4YFdG0KEA:9 a=ObUINUouHsCKj4En9vAA:7 a=Fy61cc9Geugf3KA_8aKYKOD7WEoA:4 a=CjuIK1q_8ugA:10 a=Bv938iqYfvFtlDwxFssA:9 a=uM761qN_FhgtPHaD6xMA:7 a=J3rm2JEZ12vxksrYZHk5wOmsnpoA:4 a=2oojFnQ6c6Waurg1:21 a=ZqU7GHg2O_BuwJCW:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42649858; Mon, 01 Nov 2010 20:53:48 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Mon, 1 Nov 2010 20:54:59 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_TsxzMdRyDrUyIHv" Message-Id: <201011012054.59551.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-current@freebsd.org, Weongyo Jeong Subject: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:53:52 -0000 --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >sc_task_on[1]); b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state "on" or "off" is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] Manpage: .Ft int .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" .. The function .Fn taskqueue_enqueue_odd should be used if it is important that the last queued task is also executed last in the task queue at the given priority level. This function requires two valid task pointers. Depending on which of the tasks passed are queued at the calling moment, the last queued task of the two will get dequeued and put last in the task queue, while not touching the first queued task. If no tasks are queued at the calling moment, this function behaves like .Fn taskqueue_enqueue . This function returns zero if the first task was queued last, one if the second task was queued last. Preliminary patch - see e-mail attachment. Comments are welcome! --HPS More docs: Also see talk about the new USB stack in FreeBSD on Youtube. --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: text/plain; charset="us-ascii"; name="hps_taskqueue_patch_v001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hps_taskqueue_patch_v001.txt" === share/man/man9/taskqueue.9 ================================================================== --- share/man/man9/taskqueue.9 (revision 214211) +++ share/man/man9/taskqueue.9 (local) @@ -46,11 +46,15 @@ typedef void (*taskqueue_enqueue_fn)(void *context); struct task { - STAILQ_ENTRY(task) ta_link; /* link for queue */ - u_short ta_pending; /* count times queued */ - u_short ta_priority; /* priority of task in queue */ - task_fn_t ta_func; /* task handler */ - void *ta_context; /* argument for handler */ + TAILQ_ENTRY(task) ta_link; /* link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255 + u_char ta_sequence; /* sequence number */ +#define TASKQUEUE_PENDING_MAX 255 + u_char ta_pending; /* count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* priority of task in queue */ + task_fn_t *ta_func; /* task handler */ + void *ta_context; /* argument for handler */ }; .Ed .Ft struct taskqueue * @@ -62,6 +66,8 @@ .Ft int .Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" .Ft int +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" +.Ft int .Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task" .Ft void .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" @@ -134,6 +140,19 @@ if the queue is being freed. .Pp The function +.Fn taskqueue_enqueue_odd +should be used if it is important that the last queued task is also +executed last in the task queue at the given priority level. This +function requires two valid task pointers. Depending on which of the +tasks passed are queued at the calling moment, the last queued task of +the two will get dequeued and put last in the task queue, while not +touching the first queued task. If no tasks are queued at the calling +moment, this function behaves like +.Fn taskqueue_enqueue . +This function returns zero if the first task was queued last, one if +the second task was queued last. +.Pp +The function .Fn taskqueue_enqueue_fast should be used in place of .Fn taskqueue_enqueue === sys/sys/_task.h ================================================================== --- sys/sys/_task.h (revision 214433) +++ sys/sys/_task.h (local) @@ -44,9 +44,13 @@ typedef void task_fn_t(void *context, int pending); struct task { - STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ - u_short ta_pending; /* (q) count times queued */ - u_short ta_priority; /* (c) Priority */ + TAILQ_ENTRY(task) ta_link; /* (q) link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255U + u_char ta_sequence; /* (q) sequence number */ +#define TASKQUEUE_PENDING_MAX 255U + u_char ta_pending; /* (q) count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* (c) priority of task in queue */ task_fn_t *ta_func; /* (c) task handler */ void *ta_context; /* (c) argument for handler */ }; === sys/sys/taskqueue.h ================================================================== --- sys/sys/taskqueue.h (revision 214433) +++ sys/sys/taskqueue.h (local) @@ -54,6 +54,7 @@ int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -71,6 +72,7 @@ * Initialise a task structure. */ #define TASK_INIT(task, priority, func, context) do { \ + (task)->ta_link.tqe_prev = NULL; \ (task)->ta_pending = 0; \ (task)->ta_priority = (priority); \ (task)->ta_func = (func); \ === sys/kern/subr_taskqueue.c ================================================================== --- sys/kern/subr_taskqueue.c (revision 214433) +++ sys/kern/subr_taskqueue.c (local) @@ -52,7 +52,7 @@ }; struct taskqueue { - STAILQ_HEAD(, task) tq_queue; + TAILQ_HEAD(task_head, task) tq_queue; const char *tq_name; taskqueue_enqueue_fn tq_enqueue; void *tq_context; @@ -62,12 +62,15 @@ int tq_tcount; int tq_spin; int tq_flags; + u_char tq_sequence; }; #define TQ_FLAGS_ACTIVE (1 << 0) #define TQ_FLAGS_BLOCKED (1 << 1) #define TQ_FLAGS_PENDING (1 << 2) +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); + static __inline void TQ_LOCK(struct taskqueue *tq) { @@ -106,7 +109,7 @@ if (!queue) return NULL; - STAILQ_INIT(&queue->tq_queue); + TAILQ_INIT(&queue->tq_queue); TAILQ_INIT(&queue->tq_active); queue->tq_name = name; queue->tq_enqueue = enqueue; @@ -155,48 +158,132 @@ int taskqueue_enqueue(struct taskqueue *queue, struct task *task) { - struct task *ins; - struct task *prev; - TQ_LOCK(queue); /* * Count multiple enqueues. */ if (task->ta_pending) { - task->ta_pending++; + if (task->ta_pending != TASKQUEUE_PENDING_MAX) + task->ta_pending++; TQ_UNLOCK(queue); - return 0; + return (0); } + KASSERT(task->ta_link.tqe_prev == NULL, ("Task already queued?")); + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, task); + + TQ_UNLOCK(queue); + + return (0); +} + +/* Enqueue task ordered and dualed */ + +int +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1) +{ + struct task *tx; + uint8_t t; + uint8_t d; + + TQ_LOCK(queue); + /* + * Compute a number based on which of the two tasks passed as + * arguments to this function are queued. + */ + t = 0; + if (t0->ta_link.tqe_prev != NULL) + t |= 1; + if (t1->ta_link.tqe_prev != NULL) + t |= 2; + + if (t == 0) { + /* + * No entries are queued. Queue task "t0" last and use + * the existing sequence number. + */ + tx = t0; + } else if (t == 1) { + /* + * Check if we need to increment the sequence number. + */ + if (t0->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t1; + } else if (t == 2) { + /* + * Check if we need to increment the sequence number. + */ + if (t1->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t0; + } else { + /* + * Both tasks are queued. Re-queue the task closest to + * the end which is computed by looking at the + * sequence number. + */ + d = (t1->ta_sequence - t0->ta_sequence); + + /* Check sign after subtraction */ + if (d & 0x80) + tx = t0; + else + tx = t1; + + TAILQ_REMOVE(&queue->tq_queue, tx, ta_link); + } + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, tx); + + TQ_UNLOCK(queue); + + if (tx == t1) + return (1); + + return (0); +} + +static void +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) +{ + struct task *ins; + struct task *prev; + + /* * Optimise the case when all tasks have the same priority. */ - prev = STAILQ_LAST(&queue->tq_queue, task, ta_link); + prev = TAILQ_LAST(&queue->tq_queue, task_head); if (!prev || prev->ta_priority >= task->ta_priority) { - STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); } else { prev = NULL; - for (ins = STAILQ_FIRST(&queue->tq_queue); ins; - prev = ins, ins = STAILQ_NEXT(ins, ta_link)) + for (ins = TAILQ_FIRST(&queue->tq_queue); ins; + prev = ins, ins = TAILQ_NEXT(ins, ta_link)) if (ins->ta_priority < task->ta_priority) break; if (prev) - STAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); + TAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); else - STAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); } + task->ta_sequence = queue->tq_sequence; task->ta_pending = 1; if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) queue->tq_enqueue(queue->tq_context); else queue->tq_flags |= TQ_FLAGS_PENDING; - - TQ_UNLOCK(queue); - - return 0; } void @@ -232,13 +319,14 @@ tb.tb_running = NULL; TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); - while (STAILQ_FIRST(&queue->tq_queue)) { + while ((task = TAILQ_FIRST(&queue->tq_queue)) != NULL) { /* - * Carefully remove the first task from the queue and - * zero its pending count. + * Carefully remove the first task from the queue, + * clear the previous next pointer and zero its + * pending count. */ - task = STAILQ_FIRST(&queue->tq_queue); - STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); + TAILQ_REMOVE(&queue->tq_queue, task, ta_link); + task->ta_link.tqe_prev = NULL; pending = task->ta_pending; task->ta_pending = 0; tb.tb_running = task; --Boundary-00=_TsxzMdRyDrUyIHv-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 20:07:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF95E106566B; Mon, 1 Nov 2010 20:07:30 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79EEC8FC1A; Mon, 1 Nov 2010 20:07:30 +0000 (UTC) Received: by iwn39 with SMTP id 39so7465195iwn.13 for ; Mon, 01 Nov 2010 13:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWRcEYFem6yf3fFJORN9++0ZAcVpKD8bEdU3c+Br+K0=; b=nYzGF19PZHbdY+6HSGUtgeRe15B//XOSLLcRdlApiCEsfJDl804+TwBLyLFdoS3565 bIr7IkDd6DL6e6Y23BDHqLfx6hclDaqfm8mAQKsod3osYKL2lsfipRU+antc2F23hu5U JvVUWLMMAjFiHE6vZtY1BCaXoq5t1ZlFuJx0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FgzmYJefrCOF1QzDICxSxu1Ir7bgCDwQO1m0ULj6dYR3JNFbNqr+3mcKzt/01yg6Ch xi6P56kzYuLvAR5VkxZXSdd69O4odBl5dQnRpwfrr88GJcxZs1CjtYZdz/eN39tOlom5 8W+2qmZrQ8mgws3IO4FHcDHwMuhVEU756za4k= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr3331721ibd.58.1288642049448; Mon, 01 Nov 2010 13:07:29 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Mon, 1 Nov 2010 13:07:29 -0700 (PDT) In-Reply-To: <201011012054.59551.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> Date: Mon, 1 Nov 2010 13:07:29 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:07:31 -0000 On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wro= te: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate t= he > USB process framework into the kernel taskqueue system in a more direct w= ay > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantee= s > execution at a given priority level. USB requires more. USB also requires= a > guarantee that the last task queued task also gets executed last. This is= for > example so that a deferred USB detach event does not happen before any pe= nding > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow buss= es > like the USB. Typical use case: > > 2 tasks to program GPIO on. > 2 tasks to program GPIO off. > > Example: > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >>sc_task_on[1]); > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >>sc_task_off[1]); > > > No matter how the call ordering of code-line a) and b), we are always > guaranteed that the last queued state "on" or "off" is reached before the= head > of the taskqueue empties. > > > In lack of a better name, the new function was called taskqueue_enqueue_o= dd > [some people obviously think that USB processes are odd, but not taskqueu= es > :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do = not. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). Thanks, matthew > Manpage: > > .Ft int > .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "st= ruct > task *t1" > > .. > > The function > .Fn taskqueue_enqueue_odd > should be used if it is important that the last queued task is also > executed last in the task queue at the given priority level. This > function requires two valid task pointers. Depending on which of the > tasks passed are queued at the calling moment, the last queued task of > the two will get dequeued and put last in the task queue, while not > touching the first queued task. If no tasks are queued at the calling > moment, this function behaves like > .Fn taskqueue_enqueue . > This function returns zero if the first task was queued last, one if > the second task was queued last. > > Preliminary patch - see e-mail attachment. > > Comments are welcome! > > --HPS > > More docs: Also see talk about the new USB stack in FreeBSD on Youtube. > > =3D=3D=3D share/man/man9/taskqueue.9 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/taskqueue.9 =A0(revision 214211) > +++ share/man/man9/taskqueue.9 =A0(local) > @@ -46,11 +46,15 @@ > =A0typedef void (*taskqueue_enqueue_fn)(void *context); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) =A0 =A0 =A0ta_link; =A0 =A0 =A0 =A0/* li= nk for queue */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_pending; =A0 =A0= /* count times queued */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_priority; =A0 = =A0/* priority of task in queue */ > - =A0 =A0 =A0 task_fn_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_func; =A0 =A0 =A0 = =A0/* task handler */ > - =A0 =A0 =A0 void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*ta_context; = =A0 =A0/* argument for handler */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* link for queue */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255 > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* sequence n= umber */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255 > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* count time= s queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* priority of = task in queue */ > + =A0 =A0 =A0 task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* task handler= */ > + =A0 =A0 =A0 void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* argument= for handler */ > =A0}; > =A0.Ed > =A0.Ft struct taskqueue * > @@ -62,6 +66,8 @@ > =A0.Ft int > =A0.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" > =A0.Ft int > +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "s= truct task *t1" > +.Ft int > =A0.Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *tas= k" > =A0.Ft void > =A0.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" > @@ -134,6 +140,19 @@ > =A0if the queue is being freed. > =A0.Pp > =A0The function > +.Fn taskqueue_enqueue_odd > +should be used if it is important that the last queued task is also > +executed last in the task queue at the given priority level. This > +function requires two valid task pointers. Depending on which of the > +tasks passed are queued at the calling moment, the last queued task of > +the two will get dequeued and put last in the task queue, while not > +touching the first queued task. If no tasks are queued at the calling > +moment, this function behaves like > +.Fn taskqueue_enqueue . > +This function returns zero if the first task was queued last, one if > +the second task was queued last. > +.Pp > +The function > =A0.Fn taskqueue_enqueue_fast > =A0should be used in place of > =A0.Fn taskqueue_enqueue > =3D=3D=3D sys/sys/_task.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/_task.h =A0 =A0 (revision 214433) > +++ sys/sys/_task.h =A0 =A0 (local) > @@ -44,9 +44,13 @@ > =A0typedef void task_fn_t(void *context, int pending); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) ta_link; =A0 =A0 /* (q) link for queue *= / > - =A0 =A0 =A0 u_short ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count ti= mes queued */ > - =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) Priority= */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* (q) link for queue= */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255U > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* (q) sequen= ce number */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255U > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count = times queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) priority= of task in queue */ > =A0 =A0 =A0 =A0task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* (c) task ha= ndler */ > =A0 =A0 =A0 =A0void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* (c) arg= ument for handler */ > =A0}; > =3D=3D=3D sys/sys/taskqueue.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/taskqueue.h (revision 214433) > +++ sys/sys/taskqueue.h (local) > @@ -54,6 +54,7 @@ > =A0int =A0 =A0taskqueue_start_threads(struct taskqueue **tqp, int count, = int pri, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char= *name, ...) __printflike(4, 5); > =A0int =A0 =A0taskqueue_enqueue(struct taskqueue *queue, struct task *tas= k); > +int =A0 =A0taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t= 0, struct task *t1); > =A0void =A0 taskqueue_drain(struct taskqueue *queue, struct task *task); > =A0void =A0 taskqueue_free(struct taskqueue *queue); > =A0void =A0 taskqueue_run(struct taskqueue *queue); > @@ -71,6 +72,7 @@ > =A0* Initialise a task structure. > =A0*/ > =A0#define TASK_INIT(task, priority, func, context) do { =A0\ > + =A0 =A0 =A0 (task)->ta_link.tqe_prev =3D NULL; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ > =A0 =A0 =A0 =A0(task)->ta_pending =3D 0; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_priority =3D (priority); =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_func =3D (func); =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =3D=3D=3D sys/kern/subr_taskqueue.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/subr_taskqueue.c =A0 (revision 214433) > +++ sys/kern/subr_taskqueue.c =A0 (local) > @@ -52,7 +52,7 @@ > =A0}; > > =A0struct taskqueue { > - =A0 =A0 =A0 STAILQ_HEAD(, task) =A0 =A0 tq_queue; > + =A0 =A0 =A0 TAILQ_HEAD(task_head, task) =A0 =A0 tq_queue; > =A0 =A0 =A0 =A0const char =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_name; > =A0 =A0 =A0 =A0taskqueue_enqueue_fn =A0 =A0tq_enqueue; > =A0 =A0 =A0 =A0void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_context; > @@ -62,12 +62,15 @@ > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_tcount; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_spin; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_flags; > + =A0 =A0 =A0 u_char =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tq_sequence; > =A0}; > > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_ACTIVE =A0 =A0 =A0 =A0 (1 << 0) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_BLOCKED =A0 =A0 =A0 =A0(1 << 1) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_PENDING =A0 =A0 =A0 =A0(1 << 2) > > +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); > + > =A0static __inline void > =A0TQ_LOCK(struct taskqueue *tq) > =A0{ > @@ -106,7 +109,7 @@ > =A0 =A0 =A0 =A0if (!queue) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; > > - =A0 =A0 =A0 STAILQ_INIT(&queue->tq_queue); > + =A0 =A0 =A0 TAILQ_INIT(&queue->tq_queue); > =A0 =A0 =A0 =A0TAILQ_INIT(&queue->tq_active); > =A0 =A0 =A0 =A0queue->tq_name =3D name; > =A0 =A0 =A0 =A0queue->tq_enqueue =3D enqueue; > @@ -155,48 +158,132 @@ > =A0int > =A0taskqueue_enqueue(struct taskqueue *queue, struct task *task) > =A0{ > - =A0 =A0 =A0 struct task *ins; > - =A0 =A0 =A0 struct task *prev; > - > =A0 =A0 =A0 =A0TQ_LOCK(queue); > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Count multiple enqueues. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (task->ta_pending) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (task->ta_pending !=3D TASKQUEUE_PENDING= _MAX) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 KASSERT(task->ta_link.tqe_prev =3D=3D NULL, ("Task already = queued?")); > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, task); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 return (0); > +} > + > +/* Enqueue task ordered and dualed */ > + > +int > +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct t= ask *t1) > +{ > + =A0 =A0 =A0 struct task *tx; > + =A0 =A0 =A0 uint8_t t; > + =A0 =A0 =A0 uint8_t d; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + > =A0 =A0 =A0 =A0/* > + =A0 =A0 =A0 =A0* Compute a number based on which of the two tasks passe= d as > + =A0 =A0 =A0 =A0* arguments to this function are queued. > + =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 t =3D 0; > + =A0 =A0 =A0 if (t0->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 1; > + =A0 =A0 =A0 if (t1->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 2; > + > + =A0 =A0 =A0 if (t =3D=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* No entries are queued. Queue task "t0"= last and use > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the existing sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else if (t =3D=3D 1) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t0->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + =A0 =A0 =A0 } else if (t =3D=3D 2) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t1->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Both tasks are queued. Re-queue the ta= sk closest to > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the end which is computed by looking a= t the > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 d =3D (t1->ta_sequence - t0->ta_sequence); > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Check sign after subtraction */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (d & 0x80) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, tx, ta_link)= ; > + =A0 =A0 =A0 } > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, tx); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 if (tx =3D=3D t1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (1); > + > + =A0 =A0 =A0 return (0); > +} > + > +static void > +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 struct task *ins; > + =A0 =A0 =A0 struct task *prev; > + > + =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 * Optimise the case when all tasks have the same priority= . > =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 prev =3D STAILQ_LAST(&queue->tq_queue, task, ta_link); > + =A0 =A0 =A0 prev =3D TAILQ_LAST(&queue->tq_queue, task_head); > =A0 =A0 =A0 =A0if (!prev || prev->ta_priority >=3D task->ta_priority) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_TAIL(&queue->tq_queue, task, = ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_TAIL(&queue->tq_queue, task, t= a_link); > =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D NULL; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D STAILQ_FIRST(&queue->tq_queue)= ; ins; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D STAILQ_NEX= T(ins, ta_link)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D TAILQ_FIRST(&queue->tq_queue);= ins; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D TAILQ_NEXT= (ins, ta_link)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ins->ta_priority < tas= k->ta_priority) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (prev) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_AFTER(&queue-= >tq_queue, prev, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_AFTER(&queue->= tq_queue, prev, task, ta_link); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_HEAD(&queue->= tq_queue, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_HEAD(&queue->t= q_queue, task, ta_link); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 task->ta_sequence =3D queue->tq_sequence; > =A0 =A0 =A0 =A0task->ta_pending =3D 1; > =A0 =A0 =A0 =A0if ((queue->tq_flags & TQ_FLAGS_BLOCKED) =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_enqueue(queue->tq_context); > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_flags |=3D TQ_FLAGS_PENDING; > - > - =A0 =A0 =A0 TQ_UNLOCK(queue); > - > - =A0 =A0 =A0 return 0; > =A0} > > =A0void > @@ -232,13 +319,14 @@ > =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); > > - =A0 =A0 =A0 while (STAILQ_FIRST(&queue->tq_queue)) { > + =A0 =A0 =A0 while ((task =3D TAILQ_FIRST(&queue->tq_queue)) !=3D NULL) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue and > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* zero its pending count. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* clear the previous next pointer and ze= ro its > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* pending count. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task =3D STAILQ_FIRST(&queue->tq_queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, task, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_link.tqe_prev =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pending =3D task->ta_pending; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 20:14:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D296106564A; Mon, 1 Nov 2010 20:14:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA7F8FC1F; Mon, 1 Nov 2010 20:14:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=fSevNTtoN4QgcqRp2OYA:9 a=stlMNjSOas5fGyG6P3UA:7 a=6G91sS9h5Cx9rxYMxB0z_FDb4doA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42657199; Mon, 01 Nov 2010 21:14:04 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Mon, 1 Nov 2010 21:15:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011012115.15261.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:14:06 -0000 On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > >>sc_task_on[1]); > >> > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > >>sc_task_off[1]); > >> > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > I'd like to make sure I understand the USB requirements. > > (1) does USB need the task priority field? Many taskqueue(9) consumers do > not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. > (2) if there was a working taskqueue_remove(9) that removed the task > if pending or returned error if the task was currently running, would > that be sufficient to implement the required USB functionality? > (assuming that taskqueue_enqueue(9) put all tasks with equal priority > in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 21:25:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 823C61065673; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E99E8FC13; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D174246B85; Mon, 1 Nov 2010 17:25:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B40998A009; Mon, 1 Nov 2010 17:25:35 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 1 Nov 2010 17:14:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: <201011012054.59551.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011011714.50121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 17:25:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 21:25:41 -0000 On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate the > USB process framework into the kernel taskqueue system in a more direct way > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantees > execution at a given priority level. USB requires more. USB also requires a > guarantee that the last task queued task also gets executed last. This is for > example so that a deferred USB detach event does not happen before any pending > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow busses > like the USB. Typical use case: > > 2 tasks to program GPIO on. > 2 tasks to program GPIO off. > > Example: > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >sc_task_on[1]); > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >sc_task_off[1]); > > > No matter how the call ordering of code-line a) and b), we are always > guaranteed that the last queued state "on" or "off" is reached before the head > of the taskqueue empties. > > > In lack of a better name, the new function was called taskqueue_enqueue_odd > [some people obviously think that USB processes are odd, but not taskqueues > :-)] It feels like this should be something you could manage with a state machine internal to USB rather than forcing that state into the taskqueue code itself. If you wanted a simple barrier task (where a barrier task is always queued at the tail of the list and all subsequent tasks are queued after the barrier task) then I would be fine with adding that. You could manage this without having to alter the task KBI by having the taskqueue maintain a separate pointer to the current "barrier" task and always enqueue entries after that task (the barrier would be NULL before a barrier is queued, and set to NULL when a barrier executes). I think this sort of semantic is a bit simpler and also used in other parts of the tree (e.g. in bio queues). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 22:02:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD039106566C; Mon, 1 Nov 2010 22:02:21 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 619188FC13; Mon, 1 Nov 2010 22:02:19 +0000 (UTC) Received: by fxm17 with SMTP id 17so5568344fxm.13 for ; Mon, 01 Nov 2010 15:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=l9BU8NySE7Q+hVsdtO/sQcBq4hkk8ZjrGY+SlKq6GvA=; b=twLAB41DT6Kh1tejKpAVCoFq8XVP2usKAnWO0jvI10ntqZaNlvj+w2BgULT31oLAGw cGL74M4fjd9yZatCCdRb5AxFvshj5i32gNGKCg0U+vXCKGorqn/kMhEHJuey6E9guC0S qGf9HFGLPYiy3ybsZcAhKThfImoTMqLRr+7nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j2Jwwa0FzxT00ptoqfRxg2db0knyv6thLy+lfcBTYO++FOzS5t2JWjMlT2XNJDeQ2t 2uqYUlzM2QuvsFE01I+OK/7346SSItzL0+k1jLT1ArVZSfHuOH2T40LMFhwk16QumZf5 QhYdOmuQLam/d7+JAVH0TP0R/dxVlZ3yTgKis= MIME-Version: 1.0 Received: by 10.223.125.132 with SMTP id y4mr9719598far.148.1288648939110; Mon, 01 Nov 2010 15:02:19 -0700 (PDT) Sender: giovanni.trematerra@gmail.com Received: by 10.223.115.84 with HTTP; Mon, 1 Nov 2010 15:02:19 -0700 (PDT) In-Reply-To: <201011011514.50322.jhb@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBD40E2.7030507@freebsd.org> <201011011514.50322.jhb@freebsd.org> Date: Mon, 1 Nov 2010 23:02:19 +0100 X-Google-Sender-Auth: R3D1ExywdR_gpPOG4W9Izs-5rKQ Message-ID: From: Giovanni Trematerra To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, Attilio Rao , freebsd-current@freebsd.org, kib@freebsd.org, Andriy Gapon Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 22:02:21 -0000 On Mon, Nov 1, 2010 at 8:14 PM, John Baldwin wrote: > On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote: >> On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: >> > on 19/10/2010 00:01 Giovanni Trematerra said the following: >> >> >> >> Your patch seems just a work around about initial slab size where the >> >> keg is backed. >> > >> > Well, setting aside my confusion with the terminology - yes, the patch= is > just >> > that, and precisely because I only tried to solve that particular prob= lem. >> > >> >> Having dynamic slab sizes would allow to have the keg backed on a lar= ger > slab >> >> without going OFFPAGE. >> > >> > I agree in principle. >> > But without seeing code that implements that I can't guess if it would > really be >> > more efficient or more maintainable, i.e. more useful in general. >> > Still a very good idea. >> > >> >> Here the patch that was in my mind. >> The patch doesn't implement dynamic slab size just allow >> to have a multipage slab to back uma_zone objects. >> I'm going to work more on the topic "dynamic slab size" soon. >> I tested the patch on qemu with -smp 32. >> I'm looking for real hw to test the patch on. >> >> here some interesting output: >> qemulab# vmstat -z | more >> ITEM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIZE =A0LIMIT =A0 =A0 USED =A0 = =A0 FREE =A0 =A0 =A0REQ FAIL SLEEP >> >> UMA Kegs: =A0 =A0 =A0 =A0 =A0 =A0 =A0 208, =A0 =A0 =A00, =A0 =A0 149, = =A0 =A0 =A0 4, =A0 =A0 149, =A0 0, =A0 0 >> UMA Zones: =A0 =A0 =A0 =A0 =A0 =A0 4480, =A0 =A0 =A00, =A0 =A0 149, =A0 = =A0 =A0 0, =A0 =A0 149, =A0 0, =A0 0 >> UMA Slabs: =A0 =A0 =A0 =A0 =A0 =A0 =A0568, =A0 =A0 =A00, =A0 =A0 836, = =A0 =A0 =A0 4, =A0 =A01187, =A0 0, =A0 0 >> UMA RCntSlabs: =A0 =A0 =A0 =A0 =A0568, =A0 =A0 =A00, =A0 =A0 202, =A0 = =A0 =A0 1, =A0 =A0 202, =A0 0, =A0 0 >> UMA Hash: =A0 =A0 =A0 =A0 =A0 =A0 =A0 256, =A0 =A0 =A00, =A0 =A0 =A0 2, = =A0 =A0 =A013, =A0 =A0 =A0 3, =A0 0, =A0 0 >> >> qemulab# sysctl kern | grep cpu >> kern.ccpu: 0 >> =A0 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, = 10, >> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, >> 28, 29, 30, 31 >> kern.smp.cpus: 32 >> kern.smp.maxcpus: 32 >> >> Any feedback will be appreciate. >> >> -- >> Giovanni Trematerra >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> diff -r 36572cbc6817 sys/vm/uma_core.c >> --- a/sys/vm/uma_core.c =A0 =A0 =A0 Tue Oct 05 04:49:04 2010 -0400 >> +++ b/sys/vm/uma_core.c =A0 =A0 =A0 Mon Nov 01 11:54:38 2010 -0400 >> @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes >> =A0{ >> =A0 =A0 =A0 uma_keg_t keg; >> =A0 =A0 =A0 uma_slab_t tmps; >> - >> - =A0 =A0 keg =3D zone_first_keg(zone); >> + =A0 =A0 u_int16_t pages; >> + >> + =A0 =A0 keg =A0 =3D zone_first_keg(zone); >> + =A0 =A0 pages =3D bytes / PAGE_SIZE; >> + >> + =A0 =A0 /* Account for remainder */ >> + =A0 =A0 if ((pages * PAGE_SIZE) < bytes) >> + =A0 =A0 =A0 =A0 =A0 =A0 pages++; >> + =A0 =A0 KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n")); > > You can use 'pages =3D howmany(bytes, PAGE_SIZE)' here. Thanks for the hint. > Also, why did you make > pages a uint16_t instead of an int? =A0An int is generally more convenien= t > unless you really need a uint16_t (and C99 spells it without an _ after t= he > leading 'u'.. FYI). Uhm just to be coherent with field uk_ppera of struct keg, but I think I can just use an int. BTW is new code supposed to use C99 form even if the rest of the file use u_int* form? > >> =A0 =A0 =A0 /* >> =A0 =A0 =A0 =A0* Check our small startup cache to see if it has pages re= maining. >> =A0 =A0 =A0 =A0*/ >> =A0 =A0 =A0 mtx_lock(&uma_boot_pages_mtx); >> - =A0 =A0 if ((tmps =3D LIST_FIRST(&uma_boot_pages)) !=3D NULL) { >> - =A0 =A0 =A0 =A0 =A0 =A0 LIST_REMOVE(tmps, us_link); >> + =A0 =A0 do { >> + =A0 =A0 =A0 =A0 =A0 =A0 if ((tmps =3D LIST_FIRST(&uma_boot_pages)) != =3D NULL) >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 LIST_REMOVE(tmps, us_link); >> + =A0 =A0 } while (--pages && tmps !=3D NULL); >> + =A0 =A0 if (tmps !=3D NULL) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_unlock(&uma_boot_pages_mtx); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 *pflag =3D tmps->us_flags; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (tmps->us_data); >> - =A0 =A0 } >> + =A0 =A0 } else if (booted =3D=3D 0) >> + =A0 =A0 =A0 =A0 =A0 =A0 panic("UMA: Increase vm.boot_pages"); >> =A0 =A0 =A0 mtx_unlock(&uma_boot_pages_mtx); >> - =A0 =A0 if (booted =3D=3D 0) >> - =A0 =A0 =A0 =A0 =A0 =A0 panic("UMA: Increase vm.boot_pages"); > > Probably best to make the pages test here explicit. =A0Also, is there any= reason > you can't do this as: > > =A0 =A0 =A0 =A0while (--pages > 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmps =3D LIST_FIRST(&uma_boot_pages); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tmps !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LIST_REMOVE(tmps, us_link)= ; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else if (booted =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0panic(...); > =A0 =A0 =A0 =A0} > Well, no, even if I'll need to initialize tmps to NULL otherwise the compiler will raise a warning. do {} while(); might be still better than a while(){}. bytes parameter will never be zero so pages will always be at least one and KASSERT will catch some wired behavior. Anyway that looks to me more readable, thanks. I could add an "else break;" just in the few cases that "pages" is still > 0 and tmps =3D=3D NULL, that could be useless though. > One question btw, how does this work since if you need to allocate more t= han 1 > page it seems that the 'tmps' values for all but the last are simply igno= red > and leaked? When you extract one item from the list you have tmps->us_data pointing to start address of the memory page. The pages are contiguous in decrescent order of address (see below) so when you extract 2 items the last one will point at the start address of 2 contiguous pages of memory, just what I need to retu= rn. > > Is there some unwritten assumption that the free pages are all virtually > contiguous (and in order), so you can just pull off a run of X and use > the address from X? > sys/vm/vm_page.c:351 @@ vm_page_startup(vm_offset_t vaddr) /* * Allocate memory for use when boot strapping the kernel memory * allocator. */ new_end =3D end - (boot_pages * UMA_SLAB_SIZE); new_end =3D trunc_page(new_end); mapped =3D pmap_map(&vaddr, new_end, end, VM_PROT_READ | VM_PROT_WRITE); bzero((void *)mapped, end - new_end); uma_startup((void *)mapped, boot_pages); -------- sys/vm/uma_core.c:1683 @@ uma_startup(void *bootmem, int boot_pages) #ifdef UMA_DEBUG printf("Filling boot free list.\n"); #endif for (i =3D 0; i < boot_pages; i++) { slab =3D (uma_slab_t)((u_int8_t *)bootmem + (i * UMA_SLAB_SIZE)); slab->us_data =3D (u_int8_t *)slab; slab->us_flags =3D UMA_SLAB_BOOT; LIST_INSERT_HEAD(&uma_boot_pages, slab, us_link); } So if I'm not wrong I'd say that the pages are virtually contiguous. Just for the record, attilio@ made a light review of this patch in private. -- Giovanni Trematerra From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 22:18:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DC4106564A for ; Mon, 1 Nov 2010 22:18:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 04AAD8FC14 for ; Mon, 1 Nov 2010 22:18:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHvZzkyDaFvO/2dsb2JhbACDG584rHiRWYEigzBzBIpU X-IronPort-AV: E=Sophos;i="4.58,276,1286164800"; d="scan'208";a="99248716" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Nov 2010 18:18:13 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AA599B3F38; Mon, 1 Nov 2010 18:18:13 -0400 (EDT) Date: Mon, 1 Nov 2010 18:18:13 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <1582966095.346887.1288649893634.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101101173036.GA1433@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [72.38.60.17] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 22:18:15 -0000 > On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > > I recently purchased a laptop that has a re(4) Realtek > > 8101E/8102E/8103E net > > chip in it and I find that it is dropping packets like crazy when > > reading > > files over an NFS mount. (It seems that bursts of receive traffic > > cause it, > > since when I look over wireshark, typically the 2nd packet in a read > > reply > > is not received, although it was sent at the other end.) > > > > Are you using NFS over UDP? The test I referred to was over TCP, which works fine until reading a file and then about the second TCP data segment that is sent by the server isn't received by the client with the re(4). (I had tcpdump capturing on both machines and then compared them using wireshark.) The read does progress slowly, after TCP retransmits the segment that was dropped. The result is a rate of about 10 reads/sec. A test over UDP gets nowhere. You just gets lots of "IP fragments timed out" when you "netstat -s", so it seems to consistently drop a fragment in the read UDP reply. > > > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude > > faster > > reading) Does this hint that interrupts are being lost or delayed > > too much? > > > > Actually I'm not a fan of polling(4) but re(4) controllers might be > exceptional one due to controller limitation but order of magnitude > faster indicates something is wrong in driver. > Yep, I'd agree. I can print out the exact chip device info, but if you don't have data sheets, it may not help. It seems to be a low end chip, since it doesn't support 1Gbps --> closer to an 8139. It might be called an 8036, since that # shows up in the device resources under windoze. > > AFAIK re(4) controllers lacks interrupts moderation so re(4) used > to rely on taskqueue to reduce number of interrupts. It was written > long time ago by Bill and I'm not sure whether it's still valid for > recent PCIe RealTek controllers. One of problem is getting > stand-alone PCIe controllers in market and I was not able to buy > recent controllers. This is one of reason why re(4) still lacks TSO, > jumbo frame and 64bit DMA support for newer controllers. Another > problem is RealTek no longer releases data sheet so it's hard to > write new features that may present on recent controllers. > > Recent re(4) controllers started to support small set of hardware > MAC statistics counters and that may help to understand how many > frames were lost under heavy load. I'll let you know when I have a > patch for that. Flow-control may also enhance performance a little > bit but it was not implemented yet like most other consumer grade > ethernet drivers. But this may change in near future, marius@ is > actively working on this so we'll get generic flow-control > framework in tree. It drops a frame as soon as the read starts and there is a burst of more than one. (I can email you the tcpdump captures if you're interested and you won't have to look far into it to see it happen.) It seems to do it consistently and then recovers when the TCP segment is resent, but repeats the fun on the next one. (I'm wondering if it can't support a 64 entry receive ring. I'll try making it smaller and see what happens? Probably won't help, but can't hurt to try:-) > > I'll see what can be done in interrupt handler and I'll let you > know when patch is ready. > > > Thanks, rick > > ps: This laptop is running a low end AMD cpu and I did install amd64 > > on it, > > instead of i386, in case that might be relevent? > > I don't think so. > Ok. I didn't think so, but someone recently mentioned that some drivers for wifi chips don't work for amd64. It actually works fairly well (and quite well with DEVICE_POLLING), except for this issue where it drops received packets when it gets bursts of them. (It almost looks like it only handles the first received packet, although it appears to be using a receive ring of 64 buffers.) Anyhow, I'll keep poking at it and will appreciate any patches/suggestions that you might have. Thanks, rick From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 22:25:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FCBE106566B for ; Mon, 1 Nov 2010 22:25:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3908D8FC0C for ; Mon, 1 Nov 2010 22:25:10 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA1MPA2U013665 for ; Mon, 1 Nov 2010 15:25:10 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA1MPAAQ013664 for current@freebsd.org; Mon, 1 Nov 2010 15:25:10 -0700 (PDT) (envelope-from david) Date: Mon, 1 Nov 2010 15:25:10 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20101101222510.GY1506@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="up2r7mkFEYHJ3y+X" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 22:25:11 -0000 --up2r7mkFEYHJ3y+X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times =2E.. Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. =2E.. Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. =2E.. Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. =2E.. Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? I don't recall stable/8 doing this, though I could be wrong. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --up2r7mkFEYHJ3y+X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEUEARECAAYFAkzPPkUACgkQmprOCmdXAD1WyQCffCPo+v5zdNmQlu+k2bTH0WeN FNIAmP/5qWWo1nIp5BzYN72nN5iHYbM= =lbHP -----END PGP SIGNATURE----- --up2r7mkFEYHJ3y+X-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 22:32:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B44D1065670 for ; Mon, 1 Nov 2010 22:32:51 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0032F8FC14 for ; Mon, 1 Nov 2010 22:32:50 +0000 (UTC) Received: by wwb17 with SMTP id 17so620501wwb.31 for ; Mon, 01 Nov 2010 15:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=XvghxAjFbBtdLWEk10T/0FXQfzVd5W/RhFxc+Jj1NmE=; b=fF4UKK+P4NIBpSqIObKCwK3CiMhSCQqdstduBtyHRG7mg1FpcTbhoiy8qTxEUGLy/X chm3A6bJWoaJcHcQxpd8SQuel3ZGmWLn1QABLC7alIek9GqQ+LD8lNtnTFRJa5fNT9s0 tCxu1IOWTcYvfum+AIlpPswvO+/eLh0CpWa28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SnNy28KAGysFDfSB++iFjsma7Hm6Bg+83g4tU+0UbQlwaboEiImH6EcC+AowJ/TLGp 90iWBwkxyBWHEwxHSbHaxE2SAWGnErp/IKB1xEYgTYl64g+qxrbn24AhVDY6w62+s1CB +0jSuwoym/yZuOl3hJctiH3DniFE3BabU+VM8= MIME-Version: 1.0 Received: by 10.216.54.147 with SMTP id i19mr273372wec.59.1288650769520; Mon, 01 Nov 2010 15:32:49 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Mon, 1 Nov 2010 15:32:49 -0700 (PDT) In-Reply-To: <20101101222510.GY1506@albert.catwhisker.org> References: <20101101222510.GY1506@albert.catwhisker.org> Date: Mon, 1 Nov 2010 22:32:49 +0000 Message-ID: From: Paul B Mahol To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 22:32:51 -0000 On 11/1/10, David Wolfskill wrote: > FreeBSD 9.0-CURRENT #31 r214621M > > Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:10:10 d130 last message repeated 3 times > Nov 1 15:10:50 d130 last message repeated 4 times > ... > Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > ... > Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. > Nov 1 15:12:10 d130 last message repeated 2 times > Nov 1 15:14:10 d130 last message repeated 12 times > > I have the switch on this laptop in position to disable the wireless > device (iwn(4)). Is there some way wpa_supplicant (or something) might > be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? > > I don't recall stable/8 doing this, though I could be wrong. From owner-freebsd-current@FreeBSD.ORG Mon Nov 1 23:40:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D088106566B for ; Mon, 1 Nov 2010 23:40:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BCDA98FC12 for ; Mon, 1 Nov 2010 23:40:10 +0000 (UTC) Received: by gwaa18 with SMTP id a18so3923869gwa.13 for ; Mon, 01 Nov 2010 16:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uNk74CoJZPEv48krYhWUwOfOBaF/SW+u/0pTXeh2seo=; b=RnQBKHRJenA0/ZuaTW1++CBxDv1jPJnPCYtpxKo/yzi/KBLVWCoSQaVHAwElaNKH6g bGvd/Amyhd/0bEBPoZYVTxLnYFsiOpGU43jchVdUMgO144EFaExrQjr/PVWVXZ8NObGg cKizMcW2UHGXt6euNxCbLZwjDElowGX9COiu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=jnSo+GCXgn1TgN87sOkVQ3KuXRiRosQqcm12OxBALDX6t+XrFKROkVq6Vy9sgzUrao vLeoBrL50ZAHGOsgbOLcojIECE9xcyK7XXODCAuXNQD6LRnvsgyn8O9IhWk7rMggDrUY vx3ISmG9U6iv5eyhdZuPUuIJnpb7fpMI2CvuE= Received: by 10.151.112.16 with SMTP id p16mr9587643ybm.199.1288654809657; Mon, 01 Nov 2010 16:40:09 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v39sm47070yba.7.2010.11.01.16.40.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 16:40:08 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 1 Nov 2010 16:40:01 -0700 From: Pyun YongHyeon Date: Mon, 1 Nov 2010 16:40:01 -0700 To: Rick Macklem Message-ID: <20101101234001.GD1433@michelle.cdnetworks.com> References: <20101101173036.GA1433@michelle.cdnetworks.com> <1582966095.346887.1288649893634.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1582966095.346887.1288649893634.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 23:40:11 -0000 On Mon, Nov 01, 2010 at 06:18:13PM -0400, Rick Macklem wrote: > > On Sun, Oct 31, 2010 at 05:46:57PM -0400, Rick Macklem wrote: > > > I recently purchased a laptop that has a re(4) Realtek > > > 8101E/8102E/8103E net > > > chip in it and I find that it is dropping packets like crazy when > > > reading > > > files over an NFS mount. (It seems that bursts of receive traffic > > > cause it, > > > since when I look over wireshark, typically the 2nd packet in a read > > > reply > > > is not received, although it was sent at the other end.) > > > > > > > Are you using NFS over UDP? > > The test I referred to was over TCP, which works fine until reading a > file and then about the second TCP data segment that is sent by the > server isn't received by the client with the re(4). (I had tcpdump > capturing on both machines and then compared them using wireshark.) Hmm, this is not what I initially thought. re(4) has much more preference on handling RX traffic over TX so it should have received that even though it couldn't send response packets. I'm not sure my patch can mitigate the issue. > The read does progress slowly, after TCP retransmits the segment that > was dropped. The result is a rate of about 10 reads/sec. > > A test over UDP gets nowhere. You just gets lots of > "IP fragments timed out" when you "netstat -s", so it seems to > consistently drop a fragment in the read UDP reply. > > > > > Adding "options DEVICE_POLLING" helps a lot. (ie. order of magnitude > > > faster > > > reading) Does this hint that interrupts are being lost or delayed > > > too much? > > > > > > > Actually I'm not a fan of polling(4) but re(4) controllers might be > > exceptional one due to controller limitation but order of magnitude > > faster indicates something is wrong in driver. > > > > Yep, I'd agree. I can print out the exact chip device info, but if you > don't have data sheets, it may not help. It seems to be a low end chip, > since it doesn't support 1Gbps --> closer to an 8139. It might be > called an 8036, since that # shows up in the device resources under > windoze. > > > > > AFAIK re(4) controllers lacks interrupts moderation so re(4) used > > to rely on taskqueue to reduce number of interrupts. It was written > > long time ago by Bill and I'm not sure whether it's still valid for > > recent PCIe RealTek controllers. One of problem is getting > > stand-alone PCIe controllers in market and I was not able to buy > > recent controllers. This is one of reason why re(4) still lacks TSO, > > jumbo frame and 64bit DMA support for newer controllers. Another > > problem is RealTek no longer releases data sheet so it's hard to > > write new features that may present on recent controllers. > > > > Recent re(4) controllers started to support small set of hardware > > MAC statistics counters and that may help to understand how many > > frames were lost under heavy load. I'll let you know when I have a > > patch for that. Flow-control may also enhance performance a little > > bit but it was not implemented yet like most other consumer grade > > ethernet drivers. But this may change in near future, marius@ is > > actively working on this so we'll get generic flow-control > > framework in tree. > > It drops a frame as soon as the read starts and there is a burst > of more than one. (I can email you the tcpdump captures if you're > interested and you won't have to look far into it to see it happen.) > I'm more interested in number of dropped frames. See below how to extract that information. > It seems to do it consistently and then recovers when the TCP > segment is resent, but repeats the fun on the next one. > (I'm wondering if it can't support a 64 entry receive ring. I'll > try making it smaller and see what happens? Probably won't help, > but can't hurt to try:-) > > > > > I'll see what can be done in interrupt handler and I'll let you > > know when patch is ready. > > > > > Thanks, rick > > > ps: This laptop is running a low end AMD cpu and I did install amd64 > > > on it, > > > instead of i386, in case that might be relevent? > > > > I don't think so. > > > Ok. I didn't think so, but someone recently mentioned that some drivers > for wifi chips don't work for amd64. > All drivers touched by me should work on any architectures. The code is the same so there is no difference. > It actually works fairly well (and quite well with DEVICE_POLLING), except > for this issue where it drops received packets when it gets bursts of them. Actually this is one of advantage of using interrupts against polling. Interrupts tend to give more fast response. To achieve the similar behavior with polling you should have used high hz. Your test indicates quite opposite result though. > (It almost looks like it only handles the first received packet, although > it appears to be using a receive ring of 64 buffers.) > No, re(4) uses 256 TX/RX buffers for RTL810xE controllers. > Anyhow, I'll keep poking at it and will appreciate any patches/suggestions > that you might have. > Ok, here is patch. http://people.freebsd.org/~yongari/re/re.intr.patch The patch has the following changes. o 64bit DMA support for PCIe controllers. o Hardware MAC statistics counter support. You can extract these counters with "sysctl dev.re.0.stats=1". You can check the output on console or dmesg. It seems extracting these counters take a lot of time so I didn't try to accumulate the counters. You can see how many frames are dropped from the output. I saw a lot FAE(frame alignment errors) under high RX load and I can't explain how this can happen. This may indicate PHY hardware is poor or it may need DSP fixups. Realtek seems to maintain large set of DSP fixups for each PHY revisions and re(4) does not have the magic code at this moment. o Overhaul MSI interrupt handler such that make it give fairness to TX as well as serving RX. Because re(4) controllers do not have interrupt moderation mechanism, naive interrupt handler can generate more than 125k intrs/sec under high load. Fortunately, Bill implemented TX interrupt moderation with a timer register and it seems to work well on TX path. One drawback of the approach is it will require extra timer register accesses in fast path. There is no second timer register to use in RX path so no RX interrupt moderation is done in driver such that it can generate about 25k intrs/sec under high RX load. However, I think most systems can handle that interrupt load. Note, this feature is activated only when MSI is in use and DEVICE_POLLING is not defined. >From my limited testing, it seems it works as expected. Would you give it try and let me know how well it behaves with NFS? > Thanks, rick From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 06:14:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA56106564A for ; Tue, 2 Nov 2010 06:14:20 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id B848A8FC12 for ; Tue, 2 Nov 2010 06:14:19 +0000 (UTC) Received: from [93.104.107.250] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PDA8Q-0001jA-E8; Tue, 02 Nov 2010 07:14:18 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA26EJ0O001939; Tue, 2 Nov 2010 07:14:19 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA26EIjS001938; Tue, 2 Nov 2010 07:14:18 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Nov 2010 07:14:18 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20101102061418.GA1884@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.107.250 Cc: kde-freebsd@kde.org Subject: 9-CURRENT: ports/net/kdenetwork3 does not compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 06:14:20 -0000 Hello, $ uname -a FreeBSD tinyCurrent 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r214444: Thu Oct 28 10:56:32 CEST 2010 with /usr/ports from CVS October, 30; compiling KDE3 gives: ... gmake[4]: Entering directory `/usr/ports/net/kdenetwork3/work/kdenetwork-3.5.10/ktalkd/ktalkd' c++ -DHAVE_CONFIG_H -I. -I../.. -I../../kopete/protocols/gadu/libgadu -I/usr/local/include -I/usr/local/include -DHAVE_KDE -D_THREAD_SAFE -pthread -DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include -I/usr/local/include -D_GETOPT_H -D_THREAD_SAFE -D_LARGE_FILES=1 -Wno-long-long -Wundef -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -pipe -fno-strict-aliasing -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT find_user.o -MD -MP -MF .deps/find_user.Tpo -c -o find_user.o find_user.cpp find_user.cpp: In function 'int find_user(char*, char*, char*)': find_user.cpp:344: error: aggregate 'utmp ubuf' has incomplete type and cannot be defined gmake[4]: *** [find_user.o] Error 1 The code in find_user.cpp reads: ... #endif /*UTMP_AND_PROC_FIND_USER*/ #else /*not PROC_FIND_USER*/ int find_user(char *name, char *tty, char *disp) { struct utmp ubuf; <<<<<<<<<<<<<< line 344 int status; FILE *fd; struct stat statb; char ftty[20+UT_LINESIZE]; char ttyFound[UT_LINESIZE] = ""; char dispFound[UT_HOSTSIZE+1] = ""; if (!(fd = fopen(_PATH_UTMP, "r"))) { fprintf(stderr, "talkd: can't read %s.\n", _PATH_UTMP); return (FAILED); } Something wrong with 'struct utmp ubuf' in HEAD? Thanks mattihas -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 07:38:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C79106564A; Tue, 2 Nov 2010 07:38:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 816238FC18; Tue, 2 Nov 2010 07:38:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=WktskUVpHMbtOkM2tRUA:9 a=1nZNbYgAICjbbIhLnOsA:7 a=fXf6KUqNvkir4ELthc67aDRHUWIA:4 a=PUjeQqilurYA:10 a=QLp5_XDAv1VEkvBO:21 a=9dnm0tSLCu5UgOgx:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43160988; Tue, 02 Nov 2010 08:38:34 +0100 From: Hans Petter Selasky To: John Baldwin Date: Tue, 2 Nov 2010 08:39:45 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011011714.50121.jhb@freebsd.org> In-Reply-To: <201011011714.50121.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011020839.45839.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 07:38:37 -0000 On Monday 01 November 2010 22:14:49 John Baldwin wrote: > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > >sc_task_on[1]); > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > >sc_task_off[1]); > > > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > It feels like this should be something you could manage with a state > machine internal to USB rather than forcing that state into the taskqueue > code itself. Hi John, No, this is not possible without keeping my own queue, which I want to avoid. By state-machine you mean remembering the last state as a separate variable and checking that in the task-callback, right? Yes, I do that in addition to the new queuing mechanism. A task barrier does not solve my problem. The barrier in my case is always last in the queue. I need to pull out previously queued tasks and put them last. That is currently not supported. I do this because I don't want to have a FIFO signalling model, and a neither want the pure taskqueue, which only ensures execution, not order of execution when at the same priority. Another issue: Won't the barrier model lead to blocking the caller once the task in question is being issued the second time? --HPS > If you wanted a simple barrier task (where a barrier task is > always queued at the tail of the list and all subsequent tasks are queued > after the barrier task) then I would be fine with adding that. You could > manage this without having to alter the task KBI by having the taskqueue > maintain a separate pointer to the current "barrier" task and always > enqueue entries after that task (the barrier would be NULL before a > barrier is queued, and set to NULL when a barrier executes). > > I think this sort of semantic is a bit simpler and also used in other parts > of the tree (e.g. in bio queues). From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 07:42:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD75106566C; Tue, 2 Nov 2010 07:42:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id B1BA18FC0C; Tue, 2 Nov 2010 07:42:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=88e7-T71Oz4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=2gous0I8H8juMTWfAzwA:9 a=5tgEV1_38apm88RSqo-W6wGdNakA:4 a=wPNLvfGTeEIA:10 a=ntJSdXeiMXs7de4o:21 a=wlr35HWB0y9YUtxd:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42884173; Tue, 02 Nov 2010 08:42:49 +0100 From: Hans Petter Selasky To: Alexander Best Date: Tue, 2 Nov 2010 08:44:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101020153040.GA3184@freebsd.org> <4CC529CF.8000304@FreeBSD.org> <20101101143838.GA64120@freebsd.org> In-Reply-To: <20101101143838.GA64120@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020844.00600.hselasky@c2i.net> Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: serious issue caused by usb device, stalling almost all operations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 07:42:52 -0000 On Monday 01 November 2010 15:38:38 Alexander Best wrote: > On Mon Oct 25 10, Alexander Motin wrote: > > Hans Petter Selasky wrote: > > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > > >> hi there, > > >> > > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe > > >> problem: > > >> > > >> after attaching my mobile phone, it simply resets without doing mount > > >> or anything. however after letting the device come up again it won't > > >> show up in the console. after detaching it the usb subsystem seemed > > >> to have completely crashed. but that's not all. the following > > >> programs now simply hang without producing any output C-C won't do > > >> anything: > > >> > > >> - dmesg > > >> - top > > >> - ps > > >> - killall > > >> - camcontrol devlist > > >> - usbconfig > > > > > > That's most likely because USB's umass driver is waiting for cam to > > > drain. Possibly some refcounting is not correct. I suspect this is not > > > a USB problem. Try to enter into the debugger, and look for backtrace > > > for function stuck in umass_detach. > > i set debug.kdb.panic=1, but didn't work, because writing the core dump > stalled and watchdog came up. > Maybe you could manually run: bt all And look for "cam" and "usb" keywords. And write down the backtraces. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 08:05:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D53106564A for ; Tue, 2 Nov 2010 08:05:22 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 878B18FC17 for ; Tue, 2 Nov 2010 08:05:21 +0000 (UTC) Received: by bwz3 with SMTP id 3so5378167bwz.13 for ; Tue, 02 Nov 2010 01:05:20 -0700 (PDT) Received: by 10.204.101.82 with SMTP id b18mr13905623bko.70.1288683658048; Tue, 02 Nov 2010 00:40:58 -0700 (PDT) Received: from jessie.localnet (p5B0E0B05.dip0.t-ipconnect.de [91.14.11.5]) by mx.google.com with ESMTPS id f21sm4280839bkf.12.2010.11.02.00.40.56 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 00:40:57 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: David Wolfskill Date: Tue, 2 Nov 2010 08:40:54 +0100 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: <20101101222510.GY1506@albert.catwhisker.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020840.54931.bschmidt@freebsd.org> Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 08:05:22 -0000 On Monday, November 01, 2010 23:32:49 Paul B Mahol wrote: > On 11/1/10, David Wolfskill wrote: > > FreeBSD 9.0-CURRENT #31 r214621M > > > > Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:10:10 d130 last message repeated 3 times > > Nov 1 15:10:50 d130 last message repeated 4 times > > ... > > Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > ... > > Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. > > Nov 1 15:12:10 d130 last message repeated 2 times > > Nov 1 15:14:10 d130 last message repeated 12 times > > > > I have the switch on this laptop in position to disable the wireless > > device (iwn(4)). Is there some way wpa_supplicant (or something) might > > be able to recognize that this is a pointless exercise? > > Well iwn could bring device down when radio is turned off and > bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? > > I don't recall stable/8 doing this, though I could be wrong. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 09:29:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CF281065786 for ; Tue, 2 Nov 2010 09:29:43 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6FA8FC1B for ; Tue, 2 Nov 2010 09:29:43 +0000 (UTC) Received: by iwn39 with SMTP id 39so8211026iwn.13 for ; Tue, 02 Nov 2010 02:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.16.195 with SMTP id p3mr14566858iba.62.1288690182869; Tue, 02 Nov 2010 02:29:42 -0700 (PDT) Received: by 10.220.187.71 with HTTP; Tue, 2 Nov 2010 02:29:42 -0700 (PDT) X-Originating-IP: [128.95.133.181] In-Reply-To: <20101102061418.GA1884@current.Sisis.de> References: <20101102061418.GA1884@current.Sisis.de> Date: Tue, 2 Nov 2010 02:29:42 -0700 Message-ID: From: Rob Farmer To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Cc: kde-freebsd@kde.org, freebsd-current@freebsd.org Subject: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 09:29:43 -0000 On Mon, Nov 1, 2010 at 23:14, Matthias Apitz wrote: > Something wrong with 'struct utmp ubuf' in HEAD? It has been removed: http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 10:05:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61C5106564A for ; Tue, 2 Nov 2010 10:05:24 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD6B8FC0C for ; Tue, 2 Nov 2010 10:05:24 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1PDDk2-00024q-JV; Tue, 02 Nov 2010 10:05:22 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PDDk2-0002h7-DK; Tue, 02 Nov 2010 10:05:22 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id oA2A5Mk0088820; Tue, 2 Nov 2010 10:05:22 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id oA2A5LVr088819; Tue, 2 Nov 2010 10:05:21 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 2 Nov 2010 10:05:21 +0000 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20101102100521.GA56887@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Marcel Moolenaar , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94486EC3-6BBB-4830-A95B-B3ACAC25B724@mac.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 10:05:24 -0000 On Thu, Oct 21, 2010 at 09:44:58PM -0700, Marcel Moolenaar wrote: > > On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: > >>> > >>> % man ls > >>> zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > >>> % man man > >>> zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged > >>> > >>> # cd /etc/mail > >>> # make start > >>> Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > >>> sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > >>> . > >>> # > >>> > >>> # cd /usr/src > >>> # svn up > >>> svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > >>> # > >>> > > This is now fixed (revision 214194). Yes, I've got r214196 and r214621 working fine on 2 different boxes. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 10:49:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42C5B106566C for ; Tue, 2 Nov 2010 10:49:30 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D0D2F8FC0C for ; Tue, 2 Nov 2010 10:49:29 +0000 (UTC) Received: by wwb17 with SMTP id 17so1091596wwb.31 for ; Tue, 02 Nov 2010 03:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=3Y1XVkCaOLJIFcIV+kb65Yuq36SOV7sJSc4MwpxSa78=; b=h+SXAzHwWiDH43mwgZpMGRy5YqPuLoRr8UV54e9a5v57Uu0R/h+goZo1j5TqSnxm10 5PjaSGNcWOXZroOVOW9OGEnfg1tm7+ocZsjxqCsTT/gFH82seisBIeyKCLt8O4gDb1y5 BaTc8WgmquckbJJbTrUcuki7pJgPks4+1zYN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kCgflG4TFhH3MEVEBUhNaCoiLhAFMc1iBwyUtbFD70Nv9FBxKlZOu3pzEvsRcuG8iE XWrQ/lpAFa6ZeJq+ihUuV6pum4DZHfe7BeiyGNhtPft4/E1103BABAAFA93/IvbGZSKO FwOXgVMIEjQNNeLRV8ZZNXu5noVxRGACQCVFg= MIME-Version: 1.0 Received: by 10.227.147.148 with SMTP id l20mr9512632wbv.118.1288694968580; Tue, 02 Nov 2010 03:49:28 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Tue, 2 Nov 2010 03:49:28 -0700 (PDT) Date: Tue, 2 Nov 2010 10:49:28 +0000 Message-ID: From: Paul B Mahol To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: net.link.log_link_state_change broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 10:49:30 -0000 Hi, It appears we do not log such events anymore (at least with wlan devices) in console. I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will change. Because I had loging disabled for very long time I encountered this problem just now. From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 13:06:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E0A1065672; Tue, 2 Nov 2010 13:06:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97B4A8FC16; Tue, 2 Nov 2010 13:06:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2E4AA46B1A; Tue, 2 Nov 2010 09:06:38 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 10BAA8A01D; Tue, 2 Nov 2010 09:06:37 -0400 (EDT) From: John Baldwin To: Giovanni Trematerra Date: Tue, 2 Nov 2010 08:49:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C9B9B9C.6000807@freebsd.org> <201011011514.50322.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020849.10288.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 02 Nov 2010 09:06:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: alc@freebsd.org, Attilio Rao , freebsd-current@freebsd.org, kib@freebsd.org, Andriy Gapon Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:06:38 -0000 On Monday, November 01, 2010 6:02:19 pm Giovanni Trematerra wrote: > On Mon, Nov 1, 2010 at 8:14 PM, John Baldwin wrote: > > On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote: > >> On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon wrote: > >> > on 19/10/2010 00:01 Giovanni Trematerra said the following: > >> >> > >> >> Your patch seems just a work around about initial slab size where the > >> >> keg is backed. > >> > > >> > Well, setting aside my confusion with the terminology - yes, the patch is > > just > >> > that, and precisely because I only tried to solve that particular problem. > >> > > >> >> Having dynamic slab sizes would allow to have the keg backed on a larger > > slab > >> >> without going OFFPAGE. > >> > > >> > I agree in principle. > >> > But without seeing code that implements that I can't guess if it would > > really be > >> > more efficient or more maintainable, i.e. more useful in general. > >> > Still a very good idea. > >> > > >> > >> Here the patch that was in my mind. > >> The patch doesn't implement dynamic slab size just allow > >> to have a multipage slab to back uma_zone objects. > >> I'm going to work more on the topic "dynamic slab size" soon. > >> I tested the patch on qemu with -smp 32. > >> I'm looking for real hw to test the patch on. > >> > >> here some interesting output: > >> qemulab# vmstat -z | more > >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > >> > >> UMA Kegs: 208, 0, 149, 4, 149, 0, 0 > >> UMA Zones: 4480, 0, 149, 0, 149, 0, 0 > >> UMA Slabs: 568, 0, 836, 4, 1187, 0, 0 > >> UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0 > >> UMA Hash: 256, 0, 2, 13, 3, 0, 0 > >> > >> qemulab# sysctl kern | grep cpu > >> kern.ccpu: 0 > >> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, > >> 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, > >> 28, 29, 30, 31 > >> kern.smp.cpus: 32 > >> kern.smp.maxcpus: 32 > >> > >> Any feedback will be appreciate. > >> > >> -- > >> Giovanni Trematerra > >> > >> > >> ============================================================== > >> diff -r 36572cbc6817 sys/vm/uma_core.c > >> --- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400 > >> +++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400 > >> @@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes > >> { > >> uma_keg_t keg; > >> uma_slab_t tmps; > >> - > >> - keg = zone_first_keg(zone); > >> + u_int16_t pages; > >> + > >> + keg = zone_first_keg(zone); > >> + pages = bytes / PAGE_SIZE; > >> + > >> + /* Account for remainder */ > >> + if ((pages * PAGE_SIZE) < bytes) > >> + pages++; > >> + KASSERT(pages > 0, ("startup_alloc can't reserve 0 pages\n")); > > > > You can use 'pages = howmany(bytes, PAGE_SIZE)' here. > > Thanks for the hint. > > > Also, why did you make > > pages a uint16_t instead of an int? An int is generally more convenient > > unless you really need a uint16_t (and C99 spells it without an _ after the > > leading 'u'.. FYI). > > Uhm just to be coherent with field uk_ppera of struct keg, but I think > I can just use an int. > BTW is new code supposed to use C99 form even if the rest of the file > use u_int* form? Hmm, if it is matching existing code that is ok I guess. I do use the C99 names for all new code personally. > > Probably best to make the pages test here explicit. Also, is there any reason > > you can't do this as: > > > > while (--pages > 0) { > > tmps = LIST_FIRST(&uma_boot_pages); > > if (tmps != NULL) > > LIST_REMOVE(tmps, us_link); > > else if (booted == 0) > > panic(...); > > } > > > > Well, no, even if I'll need to initialize tmps to NULL otherwise the > compiler will > raise a warning. > do {} while(); might be still better than a while(){}. bytes parameter > will never be > zero so pages will always be at least one and KASSERT will catch some > wired behavior. > Anyway that looks to me more readable, thanks. I could add an "else > break;" just in > the few cases that "pages" is still > 0 and tmps == NULL, that could > be useless though. It is probably best to add the break. You can still use a do {} while to fix the compiler warning though, that's a legitimate reason. :) > > One question btw, how does this work since if you need to allocate more than 1 > > page it seems that the 'tmps' values for all but the last are simply ignored > > and leaked? > > When you extract one item from the list you have tmps->us_data > pointing to start address of the memory page. The pages are contiguous > in decrescent > order of address (see below) so when you extract 2 items the last one > will point at > the start address of 2 contiguous pages of memory, just what I need to return. Ahhh, ok. I would maybe add a comment to explain that it is ok to "lose" the tmps references for this reason. Hmm, one problem I see is that if you need to allocate 4 pages and only 3 are available, you will fail with 'tmps = NULL', but the 3 pages will be lost. I'm not sure how much we care about that case? You could always do two passes (one to see if N pages are available and fail the allocation if not) and a second one to actually pull the pages off of the LIST. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 13:11:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C31041065670; Tue, 2 Nov 2010 13:11:26 +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 4244E8FC14; Tue, 2 Nov 2010 13:11:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12951; Tue, 02 Nov 2010 15:11:23 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD00DFB.7030603@freebsd.org> Date: Tue, 02 Nov 2010 15:11:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Giovanni Trematerra References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> <4CBD40E2.7030507@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:11:26 -0000 on 01/11/2010 19:09 Giovanni Trematerra said the following: > Here the patch that was in my mind. > The patch doesn't implement dynamic slab size just allow > to have a multipage slab to back uma_zone objects. > I'm going to work more on the topic "dynamic slab size" soon. > I tested the patch on qemu with -smp 32. > I'm looking for real hw to test the patch on. Having only skimmed the patch I have a question - is this only used for internal zones? "Application" zones with large items still use off-page slabs? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 13:16:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 367BA106566B; Tue, 2 Nov 2010 13:16:17 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 13EA08FC1B; Tue, 2 Nov 2010 13:16:15 +0000 (UTC) Received: by fxm17 with SMTP id 17so6045488fxm.13 for ; Tue, 02 Nov 2010 06:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L5ZVwtwoxYDzr1ZWzk9xCwwpRE8cyIMD4l+IAjcw1vI=; b=WIe7DUqnqupYNZKiQCp6437nWJV/XXvKNnMzx9SNMBBqNedmjDlld+HuQ+3whtSIKm hZe5tmBfVHpSe04twTCbZLetY3DYrt5j89bAJGPc1EnRAz7An3cvZUT9V6/oR6Zz65J8 EpkXyrrIaZvIQYbe/uE9AGCY1TB1HywF8LMnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pZSEcrMeIozLYJg2WKc0T9HBd55IojmLFNeGG7ZWc8V8wug5bWIZnwDzjMPmCYJWfs xdftmwNWhnp8aZBRZjd8Gs4hY6xosAYqYxUDQ2uOfCwJT09gfAYrt2D7SkvUzAWD0dAa 6PQtL9RFH0CizNw6JYKF/nBebkJvU0ujdrJOU= MIME-Version: 1.0 Received: by 10.223.69.141 with SMTP id z13mr7575777fai.72.1288703775023; Tue, 02 Nov 2010 06:16:15 -0700 (PDT) Received: by 10.223.115.84 with HTTP; Tue, 2 Nov 2010 06:16:14 -0700 (PDT) In-Reply-To: <4CD00DFB.7030603@freebsd.org> References: <4C9B9B9C.6000807@freebsd.org> <4CBBEBDF.3060905@freebsd.org> <4CBC5719.1020807@freebsd.org> <4CBD40E2.7030507@freebsd.org> <4CD00DFB.7030603@freebsd.org> Date: Tue, 2 Nov 2010 14:16:14 +0100 Message-ID: From: Giovanni Trematerra To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: panic in uma_startup for many-core amd64 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:16:17 -0000 On Tue, Nov 2, 2010 at 2:11 PM, Andriy Gapon wrote: > on 01/11/2010 19:09 Giovanni Trematerra said the following: >> Here the patch that was in my mind. >> The patch doesn't implement dynamic slab size just allow >> to have a multipage slab to back uma_zone objects. >> I'm going to work more on the topic "dynamic slab size" soon. >> I tested the patch on qemu with -smp 32. >> I'm looking for real hw to test the patch on. > > Having only skimmed the patch I have a question - is this only used for i= nternal > zones? =A0"Application" zones with large items still use off-page slabs? > Yes, it is used only for internal zones. Other zones will go off-page as us= ual. -- Giovanni Trematerra From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 15:53:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C20F106566C for ; Tue, 2 Nov 2010 15:53:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D9F408FC14 for ; Tue, 2 Nov 2010 15:53:11 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA2FrAiE020691; Tue, 2 Nov 2010 08:53:10 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA2FrA8Q020690; Tue, 2 Nov 2010 08:53:10 -0700 (PDT) (envelope-from david) Date: Tue, 2 Nov 2010 08:53:10 -0700 From: David Wolfskill To: Bernhard Schmidt Message-ID: <20101102155310.GF1506@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Bernhard Schmidt , current@freebsd.org References: <20101101222510.GY1506@albert.catwhisker.org> <201011020840.54931.bschmidt@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7e8BFhNxqpjiNKz7" Content-Disposition: inline In-Reply-To: <201011020840.54931.bschmidt@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 15:53:12 -0000 --7e8BFhNxqpjiNKz7 Content-Type: multipart/mixed; boundary="qih7n4MdZQ4fb9uN" Content-Disposition: inline --qih7n4MdZQ4fb9uN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: > .... > > > I have the switch on this laptop in position to disable the wireless > > > device (iwn(4)). Is there some way wpa_supplicant (or something) mig= ht > > > be able to recognize that this is a pointless exercise? > >=20 > > Well iwn could bring device down when radio is turned off and > > bring it up when radio is turned on ??? >=20 > Well, that should actually be the case. I don't see how it might differ= =20 > between stable/8 and head. >=20 > Can you post the output of > wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d > while the RF kill button is in disabled state? >=20 > > > I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qih7n4MdZQ4fb9uN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wpa.txt" Content-Transfer-Encoding: quoted-printable Script started on Tue Nov 2 08:45:28 2010 =0D d130# ps axwwl | grep wpa_s=0D=0D 0 3528 3523 0 45 0 3500 1240 piperd S+ 18 0:00.01 grep wp= a_s=0D d130# wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d=0D=0D Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd'= ctrl_interface 'N/A' bridge 'N/A'=0D Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'= =0D Reading configuration file '/etc/wpa_supplicant.conf'=0D Priority group 93=0D id=3D17 ssid=3D'lmdhw-net'=0D id=3D18 ssid=3D'lmdhw-net'=0D Priority group 85=0D id=3D19 ssid=3D'NETGEAR'=0D id=3D20 ssid=3D'wifi'=0D Priority group 17=0D id=3D0 ssid=3D'DojoTest'=0D Priority group 16=0D id=3D1 ssid=3D'HackerDojoDownstairs'=0D id=3D2 ssid=3D'HackerDojoUpstairs'=0D id=3D3 ssid=3D'LINKEDIN-GUEST'=0D id=3D4 ssid=3D'LINKEDIN-GUEST'=0D id=3D5 ssid=3D'LINKEDIN-GUEST'=0D id=3D6 ssid=3D'LINKEDIN-GUEST'=0D id=3D7 ssid=3D'LINKEDIN-GUEST'=0D id=3D8 ssid=3D'LINKEDIN-GUEST'=0D id=3D9 ssid=3D'LINKEDIN-GUEST'=0D id=3D10 ssid=3D'LINKEDIN-GUEST'=0D id=3D11 ssid=3D'LINKEDIN-GUEST'=0D id=3D12 ssid=3D'LINKEDIN-GUEST'=0D id=3D13 ssid=3D'LINKEDIN-GUEST'=0D id=3D14 ssid=3D'LINKEDIN-GUEST'=0D id=3D15 ssid=3D'LINKEDIN-GUEST'=0D id=3D16 ssid=3D'LINKEDIN-GUEST'=0D Initializing interface (2) 'wlan0'=0D Own MAC address: 00:21:6a:26:34:c0=0D wpa_driver_bsd_set_wpa: enabled=3D1=0D wpa_driver_bsd_set_wpa_internal: wpa=3D3 privacy=3D1=0D wpa_driver_bsd_del_key: keyidx=3D0=0D wpa_driver_bsd_del_key: keyidx=3D1=0D wpa_driver_bsd_del_key: keyidx=3D2=0D wpa_driver_bsd_del_key: keyidx=3D3=0D wpa_driver_bsd_set_countermeasures: enabled=3D0=0D wpa_driver_bsd_set_drop_unencrypted: enabled=3D1=0D RSN: flushing PMKID list in the driver=0D Setting scan request: 0 sec 100000 usec=0D EAPOL: SUPP_PAE entering state DISCONNECTED=0D EAPOL: KEY_RX entering state NO_KEY_RECEIVE=0D EAPOL: SUPP_BE entering state INITIALIZE=0D EAP: EAP entering state DISABLED=0D Added interface wlan0=0D State: DISCONNECTED -> SCANNING=0D Starting AP scan (broadcast SSID)=0D Trying to get current scan results first without requesting a new scan to s= peed up initial association=0D Received 0 bytes of scan results (0 BSSes)=0D Scan results: 0=0D Cached scan results are empty - not posting=0D Selecting BSS from priority group 93=0D Try to find WPA-enabled AP=0D Try to find non-WPA AP=0D Selecting BSS from priority group 85=0D Try to find WPA-enabled AP=0D Try to find non-WPA AP=0D Selecting BSS from priority group 17=0D Try to find WPA-enabled AP=0D Try to find non-WPA AP=0D Selecting BSS from priority group 16=0D Try to find WPA-enabled AP=0D Try to find non-WPA AP=0D No suitable AP found.=0D Setting scan request: 0 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D EAPOL: disable timer tick=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D Starting AP scan (broadcast SSID)=0D ioctl[SIOCS80211, op 103, len 128]: Device not configured=0D Failed to initiate AP scan.=0D Setting scan request: 10 sec 0 usec=0D ^CCTRL-EVENT-TERMINATING - signal 2 received=0D Removing interface wlan0=0D State: SCANNING -> DISCONNECTED=0D No keys have been configured - skip key clearing=0D EAPOL: External notification - portEnabled=3D0=0D EAPOL: External notification - portValid=3D0=0D wpa_driver_bsd_set_wpa: enabled=3D0=0D wpa_driver_bsd_set_wpa_internal: wpa=3D0 privacy=3D0=0D ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported=0D Failed to disable WPA in the driver.=0D wpa_driver_bsd_set_drop_unencrypted: enabled=3D0=0D wpa_driver_bsd_set_countermeasures: enabled=3D0=0D No keys have been configured - skip key clearing=0D Cancelling scan request=0D Cancelling authentication timeout=0D wpa_driver_bsd_set_wpa_internal: wpa=3D3 privacy=3D1=0D ELOOP: remaining socket: sock=3D4 eloop_data=3D0x28406140 user_data=3D0x284= 0e040 handler=3D0x8069f90=0D d130# ^D=08=08exit=0D Script done on Tue Nov 2 08:49:28 2010 --qih7n4MdZQ4fb9uN-- --7e8BFhNxqpjiNKz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzQM+YACgkQmprOCmdXAD01vACghzv5UojV02g3vX/rv1K6RYwy Y54An3zoO2XqfVss3dRL2P9etyxTHBPb =X0fj -----END PGP SIGNATURE----- --7e8BFhNxqpjiNKz7-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 17:30:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C636F106566B for ; Tue, 2 Nov 2010 17:30:11 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 85ACC8FC18 for ; Tue, 2 Nov 2010 17:30:11 +0000 (UTC) Received: by vws12 with SMTP id 12so5459646vws.13 for ; Tue, 02 Nov 2010 10:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.182.137 with SMTP id cc9mr5844846qab.320.1288719010294; Tue, 02 Nov 2010 10:30:10 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.213.73 with HTTP; Tue, 2 Nov 2010 10:30:10 -0700 (PDT) X-Originating-IP: [84.180.228.184] In-Reply-To: <20101102155310.GF1506@albert.catwhisker.org> References: <20101101222510.GY1506@albert.catwhisker.org> <201011020840.54931.bschmidt@freebsd.org> <20101102155310.GF1506@albert.catwhisker.org> Date: Tue, 2 Nov 2010 18:30:10 +0100 X-Google-Sender-Auth: yrVXAIaJFVZ25aGJ9ryh3BtkOB8 Message-ID: From: Bernhard Schmidt To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 17:30:11 -0000 On Tue, Nov 2, 2010 at 16:53, David Wolfskill wrote: > On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: >> .... >> > > I have the switch on this laptop in position to disable the wireless >> > > device (iwn(4)). =A0Is there some way wpa_supplicant (or something) = might >> > > be able to recognize that this is a pointless exercise? >> > >> > Well iwn could bring device down when radio is turned off and >> > bring it up when radio is turned on ??? >> >> Well, that should actually be the case. I don't see how it might differ >> between stable/8 and head. >> >> Can you post the output of >> wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d >> while the RF kill button is in disabled state? >> >> > > I don't recall stable/8 doing this, though I could be wrong. > > Next time I booted stable/8, I checked /var/log/messages, and verified > that wpa_supplicant is also persistent in that environment. > > So I did the above within script(1); I've attached a copy of the > typescript file. =A0This was done while running: > > FreeBSD 8.1-STABLE #20 r214672: Tue Nov =A02 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=3D"-qqqq" to rc.conf. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 18:06:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E7D1065696 for ; Tue, 2 Nov 2010 18:06:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EBB428FC1C for ; Tue, 2 Nov 2010 18:06:02 +0000 (UTC) Received: by wyb42 with SMTP id 42so6909385wyb.13 for ; Tue, 02 Nov 2010 11:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BCmNN3tAcELN3mPTVT6HSARe7AALEY5eX9LmbX36R5g=; b=aDFcwuPhmiOC8Df3sjEoZW0Y0JNYeFmoCJTjYGrgba61ppZG23OnT5vHSVOouCeoMp MlVhEnQe4p+Mk3ciEtA04WagTX1zp8xZH+oD+z1vn10Fdih9V3xo/c/1tCiGkp/wWCKn 0xJD97roWR5YRyMj65fhnb3Hwintm/9AyB/Ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZKMo3ujxDc8SuThlAqHTVvuhPFylbpAJ3f8uysB4DKyu2XjXafE4wQEzxRfAE7M62V 2aMmNySGqfjI2LmrBSbyg42+hZG3SuhrWrB9y+Xo9PRCxB3FNIqXrHdGBM3VmCLUgRsV JLYifQjQ3I064g8DATLEcpq9q8adwowN5GWDA= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr1401943web.45.1288721160788; Tue, 02 Nov 2010 11:06:00 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Tue, 2 Nov 2010 11:06:00 -0700 (PDT) In-Reply-To: References: <20101101222510.GY1506@albert.catwhisker.org> <201011020840.54931.bschmidt@freebsd.org> <20101102155310.GF1506@albert.catwhisker.org> Date: Tue, 2 Nov 2010 11:06:00 -0700 X-Google-Sender-Auth: qU65l6swSoV_XKa1V36hG-Zxw7A Message-ID: From: Garrett Cooper To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 18:06:03 -0000 On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt wr= ote: > On Tue, Nov 2, 2010 at 16:53, David Wolfskill wrot= e: >> On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: >>> .... >>> > > I have the switch on this laptop in position to disable the wireles= s >>> > > device (iwn(4)). =A0Is there some way wpa_supplicant (or something)= might >>> > > be able to recognize that this is a pointless exercise? >>> > >>> > Well iwn could bring device down when radio is turned off and >>> > bring it up when radio is turned on ??? >>> >>> Well, that should actually be the case. I don't see how it might differ >>> between stable/8 and head. >>> >>> Can you post the output of >>> wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d >>> while the RF kill button is in disabled state? >>> >>> > > I don't recall stable/8 doing this, though I could be wrong. >> >> Next time I booted stable/8, I checked /var/log/messages, and verified >> that wpa_supplicant is also persistent in that environment. >> >> So I did the above within script(1); I've attached a copy of the >> typescript file. =A0This was done while running: >> >> FreeBSD 8.1-STABLE #20 r214672: Tue Nov =A02 04:19:13 PDT 2010 > > Thanks. I had quick look into that and I currently do not see an easy > way to address that issue, as in tell wpa_supplicant about the device's > state. This might change though once a newer wpa_supplicant has been > imported. > > For now just add wpa_supplicant_flags=3D"-qqqq" to rc.conf. Device states could and should be periodically polled via the SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version of wpa_supplicant). This seems like a worthy enhancement. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 18:35:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D6301065694 for ; Tue, 2 Nov 2010 18:35:16 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED3408FC1E for ; Tue, 2 Nov 2010 18:35:15 +0000 (UTC) Received: by pwi8 with SMTP id 8so1730711pwi.13 for ; Tue, 02 Nov 2010 11:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.232.211 with SMTP id jv19mr9828657qcb.28.1288722914411; Tue, 02 Nov 2010 11:35:14 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.229.213.73 with HTTP; Tue, 2 Nov 2010 11:35:14 -0700 (PDT) X-Originating-IP: [84.180.228.184] In-Reply-To: References: <20101101222510.GY1506@albert.catwhisker.org> <201011020840.54931.bschmidt@freebsd.org> <20101102155310.GF1506@albert.catwhisker.org> Date: Tue, 2 Nov 2010 19:35:14 +0100 X-Google-Sender-Auth: 03--QKQygxxpmFUsqe6NDayGhoY Message-ID: From: Bernhard Schmidt To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 18:35:16 -0000 On Tue, Nov 2, 2010 at 19:06, Garrett Cooper wrote: > On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt = wrote: >> On Tue, Nov 2, 2010 at 16:53, David Wolfskill wro= te: >>> On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: >>>> .... >>>> > > I have the switch on this laptop in position to disable the wirele= ss >>>> > > device (iwn(4)). =A0Is there some way wpa_supplicant (or something= ) might >>>> > > be able to recognize that this is a pointless exercise? >>>> > >>>> > Well iwn could bring device down when radio is turned off and >>>> > bring it up when radio is turned on ??? >>>> >>>> Well, that should actually be the case. I don't see how it might diffe= r >>>> between stable/8 and head. >>>> >>>> Can you post the output of >>>> wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d >>>> while the RF kill button is in disabled state? >>>> >>>> > > I don't recall stable/8 doing this, though I could be wrong. >>> >>> Next time I booted stable/8, I checked /var/log/messages, and verified >>> that wpa_supplicant is also persistent in that environment. >>> >>> So I did the above within script(1); I've attached a copy of the >>> typescript file. =A0This was done while running: >>> >>> FreeBSD 8.1-STABLE #20 r214672: Tue Nov =A02 04:19:13 PDT 2010 >> >> Thanks. I had quick look into that and I currently do not see an easy >> way to address that issue, as in tell wpa_supplicant about the device's >> state. This might change though once a newer wpa_supplicant has been >> imported. >> >> For now just add wpa_supplicant_flags=3D"-qqqq" to rc.conf. > > =A0 =A0Device states could and should be periodically polled via the > SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version > of wpa_supplicant). This seems like a worthy enhancement. Not necessarily, we have a event based facility for that, the functions are empty though because the consumer, wpa_supplicant, is not able to make any use of it. There were some changes in 0.7 for interface states but I'm not sure what exactly changed, it might be possible to use events for the 'rfkill on' case, the 'rfkill off' might still need polling.. Once Rui has imported the new wpa stuff, someone should implemented the proper calls :) -- Bernhard From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 18:50:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAC81065746 for ; Tue, 2 Nov 2010 18:50:14 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 420198FC12 for ; Tue, 2 Nov 2010 18:50:09 +0000 (UTC) Received: by gya6 with SMTP id 6so4664306gya.13 for ; Tue, 02 Nov 2010 11:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.69.82 with SMTP id a18mr13042716icj.459.1288723809364; Tue, 02 Nov 2010 11:50:09 -0700 (PDT) Received: by 10.220.187.71 with HTTP; Tue, 2 Nov 2010 11:50:09 -0700 (PDT) X-Originating-IP: [128.95.133.181] In-Reply-To: References: <20101102061418.GA1884@current.Sisis.de> Date: Tue, 2 Nov 2010 11:50:09 -0700 Message-ID: From: Rob Farmer To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Cc: kde-freebsd@kde.org, Matthias Apitz , freebsd-current@freebsd.org Subject: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 18:50:14 -0000 On Tue, Nov 2, 2010 at 11:38, David DEMELIER wrote: > A lot of ports will need some patches then, isn't it ? Most were taken care of back when it happened - many either included utmp.h and never used it or only used it trivially, so it was easy to fix (I submitted patches for some and I'm definitely not a great programmer). So the fact that it wasn't fixed either means nobody cares about that port (somewhat true here - most of the KDE people moved on to 4) or that the fix will be more involved (probably the case for this one). -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 19:04:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 918501065672 for ; Tue, 2 Nov 2010 19:04:35 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB0F8FC1A for ; Tue, 2 Nov 2010 19:04:34 +0000 (UTC) Received: by bwz3 with SMTP id 3so5913698bwz.13 for ; Tue, 02 Nov 2010 12:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pvCNaTSizVVinoX6/7kp0ahtTI5MqReiHwOeZGgjQvY=; b=nh9niV5lJg8Dh6itUmRCb+8cJpKdLJgQa3JqWgEYmCCs2AVxZzEALws7Hviiuhd6jK OquYuA0f7ef0OvjM3+vJj6R2c9NEwq28uTthntpmrrsZWUDum6B6VcJBrwIczQj1wbyp sVP16MpvrGYFvGJQqP5eQ0iNwyZlgVZdyRZdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EyXgC6nonKH/PGRx2qqPyMYEuJVcVD2qPhTMaSucFSu+VlSlvmyW0gEptJrSf7F/5E 4rh1PLRlPOS6L1ii4KxQpzceljW9r0Ln9HlTJG7hci5nLZid3/TRGCS39uNolm48Fajn msQVlz+51/X4nRh+uoC2aNdstSwuNiBzciiNg= MIME-Version: 1.0 Received: by 10.204.64.139 with SMTP id e11mr3219776bki.212.1288723109314; Tue, 02 Nov 2010 11:38:29 -0700 (PDT) Received: by 10.204.98.195 with HTTP; Tue, 2 Nov 2010 11:38:29 -0700 (PDT) In-Reply-To: References: <20101102061418.GA1884@current.Sisis.de> Date: Tue, 2 Nov 2010 19:38:29 +0100 Message-ID: From: David DEMELIER To: Rob Farmer Content-Type: text/plain; charset=UTF-8 Cc: kde-freebsd@kde.org, Matthias Apitz , freebsd-current@freebsd.org Subject: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:04:35 -0000 2010/11/2 Rob Farmer : > On Mon, Nov 1, 2010 at 23:14, Matthias Apitz wrote: >> Something wrong with 'struct utmp ubuf' in HEAD? > > It has been removed: > > http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html > > -- > Rob Farmer > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > A lot of ports will need some patches then, isn't it ? -- Demelier David From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 19:12:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71BD5106566C for ; Tue, 2 Nov 2010 19:12:16 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 108BA8FC1E for ; Tue, 2 Nov 2010 19:12:16 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 5AF49E7209 for ; Tue, 2 Nov 2010 19:12:15 +0000 (GMT) Received: from core.nessbank (client-81-107-141-216.midd.adsl.virginmedia.com [81.107.141.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Tue, 2 Nov 2010 19:12:14 +0000 (GMT) From: Bruce Cran To: freebsd-current@freebsd.org Date: Tue, 2 Nov 2010 19:12:14 +0000 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.2; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201011021912.14281.bruce@cran.org.uk> Subject: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:12:16 -0000 I've noticed in recent months that I appear to be getting silent corruption of my UFS filesystems - and I think it may be linked to using md(4) or creating sparse files. I created a 20GB md device using "truncate -s 20G mdfile && mdconfig -a -f mdfile" and then ran some gpart commands before using "mdconfig -d -u 0" and rm'ing the file. Some time later I noticed the following had been logged to dmesg: free inode /usr/3367984 had 128 blocks free inode /usr/3367984 had 32 blocks Now, whenever I run vim it creates a sparse 20GB .viminfo file - on another server those files were reported as being 8TB. I've disabled background fsck so the filesystems should have been clean when the system booted, and I'm not using SU+J. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 19:32:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD161065674 for ; Tue, 2 Nov 2010 19:32:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id B607A8FC14 for ; Tue, 2 Nov 2010 19:32:50 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 206492A28D05; Tue, 2 Nov 2010 20:32:50 +0100 (CET) Date: Tue, 2 Nov 2010 20:32:50 +0100 From: Ed Schouten To: Matthias Apitz Message-ID: <20101102193250.GU81149@hoeg.nl> References: <20101102061418.GA1884@current.Sisis.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AJd+a2ML6L6CXP6l" Content-Disposition: inline In-Reply-To: <20101102061418.GA1884@current.Sisis.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kde-freebsd@kde.org, freebsd-current@freebsd.org Subject: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:32:51 -0000 --AJd+a2ML6L6CXP6l Content-Type: multipart/mixed; boundary="jtEtYGE75hrP1CgP" Content-Disposition: inline --jtEtYGE75hrP1CgP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, Just to notify everyone what's going on; Matthias tested a patch for me, which should make it work on HEAD again. The attached patch should be applied to the sources conditionally (so only when running HEAD). I am in the process of getting it fixed in ports/upstreamed. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --jtEtYGE75hrP1CgP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kdenetwork.txt" Content-Transfer-Encoding: quoted-printable --- ktalkd/ktalkd/find_user.cpp +++ ktalkd/ktalkd/find_user.cpp @@ -339,34 +339,33 @@ =20 #else /*not PROC_FIND_USER*/ =20 +#include + int find_user(char *name, char *tty, char *disp) { =20 - struct utmp ubuf; + struct utmpx *ubuf; int status; - FILE *fd; struct stat statb; - char ftty[20+UT_LINESIZE]; - char ttyFound[UT_LINESIZE] =3D ""; - char dispFound[UT_HOSTSIZE+1] =3D ""; - - if (!(fd =3D fopen(_PATH_UTMP, "r"))) { - fprintf(stderr, "talkd: can't read %s.\n", _PATH_UTMP); - return (FAILED); - } + char ftty[20 + sizeof ubuf->ut_line]; + char ttyFound[sizeof ubuf->ut_line] =3D ""; + char dispFound[sizeof ubuf->ut_line + 1] =3D ""; + + setutxent(); #define SCMPN(a, b) strncmp(a, b, sizeof (a)) status =3D NOT_HERE; (void) strcpy(ftty, _PATH_DEV); - while (fread((char *) &ubuf, sizeof ubuf, 1, fd) =3D=3D 1) { - if (!SCMPN(ubuf.ut_name, name)) { + while ((ubuf =3D getutxent())) { + if ((ubuf->ut_type =3D=3D USER_PROCESS) && + (!SCMPN(ubuf->ut_user, name))) { if (*tty =3D=3D '\0') { /* no particular tty was requested */ - (void) strcpy(ftty+5, ubuf.ut_line); + (void) strcpy(ftty+5, ubuf->ut_line); if (stat(ftty,&statb) =3D=3D 0) { if (!(statb.st_mode & 020)) /* ?character device? */ continue; - (void) strcpy(ttyFound, ubuf.ut_line); + (void) strcpy(ttyFound, ubuf->ut_line); #ifdef USE_UT_HOST - (void) strcpy(dispFound, ubuf.ut_host); + (void) strcpy(dispFound, ubuf->ut_host); strcat(dispFound, " "); #endif status =3D SUCCESS; @@ -384,13 +383,13 @@ } } } - else if (!strcmp(ubuf.ut_line, tty)) { + else if (!strcmp(ubuf->ut_line, tty)) { status =3D SUCCESS; break; } } } - fclose(fd); + endutxent(); if (status =3D=3D SUCCESS) { (void) strcpy(tty, ttyFound); (void) strcpy(disp, dispFound); --jtEtYGE75hrP1CgP-- --AJd+a2ML6L6CXP6l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzQZ2IACgkQ52SDGA2eCwUK8wCdHtPLPSE84t/Lzr2UeoA53Gql q8oAnj6bxSSoKy3QoN1/DF9A6v1FApse =a1NZ -----END PGP SIGNATURE----- --AJd+a2ML6L6CXP6l-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 19:33:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECBC910656A4 for ; Tue, 2 Nov 2010 19:33:52 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id AF3498FC12 for ; Tue, 2 Nov 2010 19:33:52 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 13A37E7209 for ; Tue, 2 Nov 2010 19:33:52 +0000 (GMT) Received: from core.nessbank (client-81-107-141-216.midd.adsl.virginmedia.com [81.107.141.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Tue, 2 Nov 2010 19:33:51 +0000 (GMT) From: Bruce Cran To: freebsd-current@freebsd.org Date: Tue, 2 Nov 2010 19:33:50 +0000 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.2; amd64; ; ) References: <201011021912.14281.bruce@cran.org.uk> In-Reply-To: <201011021912.14281.bruce@cran.org.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011021933.51052.bruce@cran.org.uk> Subject: Re: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:33:53 -0000 On Tuesday 02 November 2010 19:12:14 Bruce Cran wrote: > I've noticed in recent months that I appear to be getting silent corruption > of my UFS filesystems - and I think it may be linked to using md(4) or > creating sparse files. I've confirmed this is a UFS bug related to sparse files: "truncate -s20G f1 && rm f1" is enough to trigger the error and start generating .viminfo files that appear to be 20GB. When running fsck I get an "Invalid block count" error if I just reboot without removing the .viminfo file; if I do remove it, I get a "Partially allocated inode" error. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 19:57:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 387DD1065670 for ; Tue, 2 Nov 2010 19:57:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 886F38FC08 for ; Tue, 2 Nov 2010 19:57:37 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA2JvWiY007714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2010 21:57:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA2JvWaO054278; Tue, 2 Nov 2010 21:57:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA2JvWAV054277; Tue, 2 Nov 2010 21:57:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Nov 2010 21:57:32 +0200 From: Kostik Belousov To: Bruce Cran Message-ID: <20101102195732.GL2392@deviant.kiev.zoral.com.ua> References: <201011021912.14281.bruce@cran.org.uk> <201011021933.51052.bruce@cran.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s7vS0va6JnAX3C/Y" Content-Disposition: inline In-Reply-To: <201011021933.51052.bruce@cran.org.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 19:57:38 -0000 --s7vS0va6JnAX3C/Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 02, 2010 at 07:33:50PM +0000, Bruce Cran wrote: > On Tuesday 02 November 2010 19:12:14 Bruce Cran wrote: > > I've noticed in recent months that I appear to be getting silent corrup= tion > > of my UFS filesystems - and I think it may be linked to using md(4) or > > creating sparse files. >=20 > I've confirmed this is a UFS bug related to sparse files: "truncate -s20G= f1=20 > && rm f1" is enough to trigger the error and start generating .viminfo fi= les=20 > that appear to be 20GB. When running fsck I get an "Invalid block count" = error=20 > if I just reboot without removing the .viminfo file; if I do remove it, I= get=20 > a "Partially allocated inode" error. What is .viminfo ? How is it related to the command you have shown ? What are exact mount options you are using ? --s7vS0va6JnAX3C/Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzQbSwACgkQC3+MBN1Mb4ixMQCghGO9CMCcSGcHqeOgMc7ytq8+ TWEAn3af1bpbWN4crvXWxIC2JmLdpZMV =BtSp -----END PGP SIGNATURE----- --s7vS0va6JnAX3C/Y-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 20:37:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B88A6106564A for ; Tue, 2 Nov 2010 20:37:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4528FC18 for ; Tue, 2 Nov 2010 20:37:07 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 96B87E720D; Tue, 2 Nov 2010 20:37:06 +0000 (GMT) Received: from core.nessbank (client-81-107-141-216.midd.adsl.virginmedia.com [81.107.141.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Tue, 2 Nov 2010 20:37:05 +0000 (GMT) From: Bruce Cran To: Kostik Belousov Date: Tue, 2 Nov 2010 20:37:04 +0000 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.2; amd64; ; ) References: <201011021912.14281.bruce@cran.org.uk> <201011021933.51052.bruce@cran.org.uk> <20101102195732.GL2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101102195732.GL2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011022037.05031.bruce@cran.org.uk> Cc: freebsd-current@freebsd.org Subject: Re: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 20:37:07 -0000 On Tuesday 02 November 2010 19:57:32 Kostik Belousov wrote: > What is .viminfo ? How is it related to the command you have shown ? > What are exact mount options you are using ? .viminfo is a file created by vim containing various bits of session information. I don't know why it gets corrupted, but I guess it's the way it's created. I've seen other dot files get corrupted in the past too though. /usr is mounted as: /dev/ada0s1f on /usr (ufs, local, soft-updates) Its entry in /etc/fstab is: /dev/ada0s1f /usr ufs rw 2 2 It's a totally standard installation from a HEAD snapshot which is now running r214509. I've now seen the problem on a xen VPS, a desktop and a laptop. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 21:02:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9631065670; Tue, 2 Nov 2010 21:02:41 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id 541368FC16; Tue, 2 Nov 2010 21:02:41 +0000 (UTC) Received: from [2a01:e35:8b50:830:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PDNzm-000HjP-7N; Tue, 02 Nov 2010 22:02:40 +0100 Message-ID: <4CD07C59.8080805@FreeBSD.org> Date: Tue, 02 Nov 2010 22:02:17 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101029 Thunderbird/3.0.10 MIME-Version: 1.0 To: Norikatsu Shigemura References: <20100927004436.997b82d7.nork@FreeBSD.org> In-Reply-To: <20100927004436.997b82d7.nork@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: psm(4) - synaptics touch pad strange behavier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:02:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On 26.09.2010 17:44, Norikatsu Shigemura wrote: > Hi psm(4) masters! > > I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. > The trouble is that the mouse cursor moves at random, and the > mouse button is clicked without button action. I heard same > trouble from ume@'s CF-R8. > > So I enabled options PSM_DEBUG=5 and traced psm's packets. My Synaptics touchpad was going back to "Relative Mode" after initialization (enable_synaptics) and I never identified the reason. I think yours is suffering from the same behaviour. To work around this, I added a hack at the beginning of doopen() in psm.c but looking at your log, it's never executed (you should see "psm0: Synaptis Absolute Mode hopefully restored"). I think my check on line 886 in psm.c (on -CURRENT) isn't right: if (stat[1] == 0x47 && stat[2] == 0x40) { Could you please try to change this line to: if (stat[1] == 0x47) { (ie. remove the second test) stat[2] contains the value of the "Mode Byte". 0x40 means "Relative Mode with high packet rate". Maybe yours is going back to "Relative Mode" only (0x00); see top of p.35 of the Interfacing Guide. A better test would be to look at the "Absolute Mode" bit only (or no test at all, like the change I propose). I can't test this myself because my laptop with the Synaptics touchpad died. - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzQfFkACgkQa+xGJsFYOlNYcACeM0/JYaYCx4CZHiWOZyi/pTaS lmoAoJLzYwlVn4ANpdoL+n99XOKzLWjv =AXjv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 21:41:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D613B106566C for ; Tue, 2 Nov 2010 21:41:42 +0000 (UTC) (envelope-from tgen@deepbone.net) Received: from cpsmtpb-ews08.kpnxchange.com (cpsmtpb-ews08.kpnxchange.com [213.75.39.13]) by mx1.freebsd.org (Postfix) with ESMTP id 504418FC08 for ; Tue, 2 Nov 2010 21:41:41 +0000 (UTC) Received: from cpbrm-ews12.kpnxchange.com ([10.94.84.143]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 22:41:40 +0100 Received: from CPSMTPM-EML108.kpnxchange.com ([195.121.3.12]) by cpbrm-ews12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 22:41:40 +0100 Received: from smtp.deepbone.net ([84.83.37.40]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Tue, 2 Nov 2010 22:41:40 +0100 Received: from [10.64.3.36] (unknown [10.64.1.10]) (Authenticated sender: tgen) by smtp.deepbone.net (Postfix) with ESMTPSA id A938F39842 for ; Tue, 2 Nov 2010 21:41:39 +0000 (UTC) Message-ID: <4CD0858D.2060308@deepbone.net> Date: Tue, 02 Nov 2010 21:41:33 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100527 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201011021912.14281.bruce@cran.org.uk> <201011021933.51052.bruce@cran.org.uk> <20101102195732.GL2392@deviant.kiev.zoral.com.ua> <201011022037.05031.bruce@cran.org.uk> In-Reply-To: <201011022037.05031.bruce@cran.org.uk> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig257A28F7DC6D2FF1C39C066B" X-OriginalArrivalTime: 02 Nov 2010 21:41:40.0350 (UTC) FILETIME=[BBDB69E0:01CB7AD6] X-RcptDomain: freebsd.org Subject: Re: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:41:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig257A28F7DC6D2FF1C39C066B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/02/2010 20:37, Bruce Cran wrote: > On Tuesday 02 November 2010 19:57:32 Kostik Belousov wrote: >=20 >> What is .viminfo ? How is it related to the command you have shown ? >> What are exact mount options you are using ? >=20 > .viminfo is a file created by vim containing various bits of session=20 > information. I don't know why it gets corrupted, but I guess it's the w= ay it's=20 > created. I've seen other dot files get corrupted in the past too though= =2E Chances are it's reusing the inode that was used for the sparse file. Cheers, --=20 Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net --------------enig257A28F7DC6D2FF1C39C066B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJM0IWTAAoJEKE55rmjwpbTAusH/1NVaisEnnsJmejggsfhCRcQ mdWPJ5JBC68WY5lqixpzFzPh1Uw6sHdkQ2cgFyilrqOxT/HjFDIkMGu57q/Au5ah 6FZ+EVYZWCFAvDZ6+oZV+m1QhyD1IAT5RiUxfPZ2hgDqzH2FHjZjYUgR47INR50g +aKRPwmD/RNNnsKwpgZKQDzbKs14sJJX7XIHn+BX+UkiU1XZ4lzatH1j+34PsxTV JWgm1Z8bnK3Ww4kwAqCOhBHq/Y31kBz7MnAG01JTDtswgoMD4YTxMwxvqq18baux 41ZgIKT3cGBujsbyuNbdwQFggd/g3IP9m0j3T0g/gHmOddUTtdxIrP1aaF69gn0= =w+yz -----END PGP SIGNATURE----- --------------enig257A28F7DC6D2FF1C39C066B-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 21:55:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10C51065675; Tue, 2 Nov 2010 21:55:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 932AA8FC15; Tue, 2 Nov 2010 21:55:19 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA2LtI2v002022; Tue, 2 Nov 2010 14:55:18 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA2LtIqn002021; Tue, 2 Nov 2010 14:55:18 -0700 (PDT) (envelope-from david) Date: Tue, 2 Nov 2010 14:55:18 -0700 From: David Wolfskill To: Bernhard Schmidt Message-ID: <20101102215518.GA1980@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Bernhard Schmidt , current@freebsd.org References: <20101101222510.GY1506@albert.catwhisker.org> <201011020840.54931.bschmidt@freebsd.org> <20101102155310.GF1506@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:55:19 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: > .... > Thanks. I had quick look into that and I currently do not see an easy > way to address that issue, as in tell wpa_supplicant about the device's > state. This might change though once a newer wpa_supplicant has been > imported. I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed to indicate to me that whiule iwn(4) could whine about the switch, it didn't have much in the way of ability to actually provide information about that status in some other way (e.g., a non-zero return from attempt to mess with the device). But I don't claim extensive expertise in that area. > For now just add wpa_supplicant_flags=3D"-qqqq" to rc.conf. :-} That, or decide to ignore the silly messages.... Noted, thanks. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzQiMYACgkQmprOCmdXAD3aewCePs5WHO1wkQvfarf4ALfezF1d 814AnReMHE7uy35BCFAunDitMdxMPUGy =nmOK -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 22:16:57 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B37BB106564A; Tue, 2 Nov 2010 22:16:57 +0000 (UTC) (envelope-from lists@somerandom.net) Received: from mx1.somerandom.net (mx1.somerandom.net [93.89.80.202]) by mx1.freebsd.org (Postfix) with ESMTP id 391328FC12; Tue, 2 Nov 2010 22:16:56 +0000 (UTC) Received: from mx1.somerandom.net ([93.89.80.202]:10791 helo=localhost) by mx1.somerandom.net with esmtps (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PDOmm-000Ge1-BP; Tue, 02 Nov 2010 21:52:56 +0000 Date: Tue, 2 Nov 2010 21:48:36 +0000 From: To: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Message-ID: <20101102214836.0206e3fe@somerandom.net> In-Reply-To: <4CD07C59.8080805@FreeBSD.org> References: <20100927004436.997b82d7.nork@FreeBSD.org> <4CD07C59.8080805@FreeBSD.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 02 Nov 2010 23:35:33 +0000 Cc: freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: psm(4) - synaptics touch pad strange behavier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 22:16:57 -0000 On Tue, 02 Nov 2010 22:02:17 +0100 Jean-S=E9bastien P=E9dron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi! >=20 > On 26.09.2010 17:44, Norikatsu Shigemura wrote: > > Hi psm(4) masters! > >=20 > > I have trouble using Synaptics TouchPad, psm(4) on my CF-R9. > > The trouble is that the mouse cursor moves at random, and > > the mouse button is clicked without button action. I heard same > > trouble from ume@'s CF-R8.=20 > > =20 > > So I enabled options PSM_DEBUG=3D5 and traced psm's packets. >=20 > My Synaptics touchpad was going back to "Relative Mode" after > initialization (enable_synaptics) and I never identified the reason. I > think yours is suffering from the same behaviour. >=20 This may or may not be helpful, so my apologies if I'm up the wrong tree. I'm not sure if the CF-R{8,9} share the same touchpad. I have a CF-19k and my Synaptics pad was never recognised as such, so a while ago I attempted to hack the psm(4) code to force it. I was able to force it and change from abs to relative (or maybe the other way, I forget), but when I did I had similar problems with a cursor moving at random. Is your touchpad a Fujitsu touchscreen/touchpad (FJC6001 - I think) like the CF19? If so I believe Linux have a Fujitsu Lifebook touchscreen/touchpad driver that treats the device as two different units, touchpad & touchscreen (I believe the hardware appears only as one device but has two outputs). Unfortunately, the touchpad side of things appears to be a plain ps/2 device without Synaptics capabilities (the hardware/programming spec was out on the Internet at some point). However, with very minimal effort I think the touchscreen could be enabled via psm(4). I have not been able to try it as my CF19 has the Wacom touchscreen (which doesn't work on CURRENT :( ), but it still retains the full Fujitsu touchscreen/touchpad device. HTH, if not good luck and sorry for the wasted bandwidth. Rob From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 07:15:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AC061065670 for ; Wed, 3 Nov 2010 07:15:46 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 1B4648FC17 for ; Wed, 3 Nov 2010 07:15:46 +0000 (UTC) Received: (qmail 82243 invoked from network); 3 Nov 2010 06:49:05 -0000 Received: from 93.166.52.54 (HELO x2.osted.lan) (93.166.52.54) by relay00.pair.com with SMTP; 3 Nov 2010 06:49:05 -0000 X-pair-Authenticated: 93.166.52.54 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.3/8.14.3) with ESMTP id oA36n5Xg039844; Wed, 3 Nov 2010 07:49:05 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.3/8.14.3/Submit) id oA36n5SE039843; Wed, 3 Nov 2010 07:49:05 +0100 (CET) (envelope-from pho) Date: Wed, 3 Nov 2010 07:49:04 +0100 From: Peter Holm To: Bruce Cran Message-ID: <20101103064904.GA39407@x2.osted.lan> References: <201011021912.14281.bruce@cran.org.uk> <201011021933.51052.bruce@cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011021933.51052.bruce@cran.org.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Corruption of UFS filesystems after using md(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 07:15:46 -0000 On Tue, Nov 02, 2010 at 07:33:50PM +0000, Bruce Cran wrote: > On Tuesday 02 November 2010 19:12:14 Bruce Cran wrote: > > I've noticed in recent months that I appear to be getting silent corruption > > of my UFS filesystems - and I think it may be linked to using md(4) or > > creating sparse files. > > I've confirmed this is a UFS bug related to sparse files: "truncate -s20G f1 > && rm f1" is enough to trigger the error and start generating .viminfo files > that appear to be 20GB. When running fsck I get an "Invalid block count" error > if I just reboot without removing the .viminfo file; if I do remove it, I get > a "Partially allocated inode" error. > I'm able to verify this by: "m.sh" 49L, 1917C written $ ./m.sh Local config: x4 + mdconfig -a -t swap -s 1g -u 5 + bsdlabel -w md5 auto + newfs -U md5a + mount /dev/md5a /mnt + truncate -s20G /mnt/f1 + rm /mnt/f1 + umount /mnt + fsck -t ufs -y /dev/md5a ** /dev/md5a ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes PARTIALLY ALLOCATED INODE I=4 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 2 files, 2 used, 506481 free (25 frags, 63307 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** + mdconfig -d -u 5 $ - Peter From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 07:27:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC0DC1065673 for ; Wed, 3 Nov 2010 07:27:06 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA838FC16 for ; Wed, 3 Nov 2010 07:27:05 +0000 (UTC) Received: by bwz3 with SMTP id 3so285998bwz.13 for ; Wed, 03 Nov 2010 00:27:05 -0700 (PDT) Received: by 10.204.120.194 with SMTP id e2mr4953837bkr.200.1288769225130; Wed, 03 Nov 2010 00:27:05 -0700 (PDT) Received: from jessie.localnet (p5B0E0F9E.dip0.t-ipconnect.de [91.14.15.158]) by mx.google.com with ESMTPS id r21sm5294293bkj.10.2010.11.03.00.27.03 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 00:27:03 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: David Wolfskill Date: Wed, 3 Nov 2010 08:27:02 +0100 User-Agent: KMail/1.13.2 (Linux/2.6.32-25-generic; KDE/4.4.2; i686; ; ) References: <20101101222510.GY1506@albert.catwhisker.org> <20101102215518.GA1980@albert.catwhisker.org> In-Reply-To: <20101102215518.GA1980@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011030827.02253.bschmidt@freebsd.org> Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 07:27:06 -0000 On Tuesday, November 02, 2010 22:55:18 David Wolfskill wrote: > On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: > > .... > > Thanks. I had quick look into that and I currently do not see an easy > > way to address that issue, as in tell wpa_supplicant about the device's > > state. This might change though once a newer wpa_supplicant has been > > imported. > > I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed > to indicate to me that whiule iwn(4) could whine about the switch, it > didn't have much in the way of ability to actually provide information > about that status in some other way (e.g., a non-zero return from > attempt to mess with the device). But I don't claim extensive expertise > in that area. There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that function is supposed to notify upper layers about the radio state (0 = off, 1 = on). Anyways, once wpa_supplicant import/update is done, I'll probably have a look into that again. > > For now just add wpa_supplicant_flags="-qqqq" to rc.conf. > : > :-} That, or decide to ignore the silly messages.... Noted, thanks. > > Peace, > david -- Bernhard From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 09:54:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDEC31065672 for ; Wed, 3 Nov 2010 09:54:23 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 03FF78FC08 for ; Wed, 3 Nov 2010 09:54:22 +0000 (UTC) Received: from igor.geek.sh (196-209-37-44.dynamic.isadsl.co.za [196.209.37.44]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id A86B53B2DC; Wed, 3 Nov 2010 11:36:41 +0200 (SAST) Message-ID: <4CD12D29.2060501@phat.za.net> Date: Wed, 03 Nov 2010 11:36:41 +0200 From: Aragon Gouveia User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100725 Thunderbird/3.0.6 MIME-Version: 1.0 To: David Rhodus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 09:54:23 -0000 I recently saw these on a Dell server. It was caused by power saving being enabled in the BIOS in a mode where the BIOS takes control instead of handing it off to the OS. Disable power saving or set it such that the OS has control (and then enable powerd(8) if you like). Regards, Aragon On 10/30/10 21:19, David Rhodus wrote: > I haven't seen much of this since 5.x days. Anyone else see calcru > messages lately ? > > -DR > > NFS# uname -a > FreeBSD NFS.Lesmilde.com 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Fri Oct > 29 01:07:40 CDT 2010 > root@NFS.Lesmilde.com:/usr/obj/usr/src/sys/GENERIC amd64 > NFS# tail -25 /var/log/messages > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 91464 > usec to 40935 usec for pid 2709 (csh) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 4334 > usec to 1927 usec for pid 2134 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 4814 > usec to 2140 usec for pid 2133 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 4752 > usec to 2113 usec for pid 2132 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 5322 > usec to 2366 usec for pid 2131 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 5183 > usec to 2304 usec for pid 2130 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 4495 > usec to 1998 usec for pid 2129 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 4501 > usec to 2001 usec for pid 2128 (getty) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 15315 > usec to 6809 usec for pid 2127 (login) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from > 32057357 usec to 28943929 usec for pid 2063 (cron) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 1381 > usec to 613 usec for pid 2015 (rsync) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 1606 > usec to 936 usec for pid 1940 (smbd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 20818 > usec to 9600 usec for pid 1895 (smbd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 18992 > usec to 8440 usec for pid 1760 (cupsd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 3378 > usec to 1501 usec for pid 1720 (mountd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 1458 > usec to 648 usec for pid 1681 (nfsuserd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 568 > usec to 308 usec for pid 1335 (devd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 214373 > usec to 95273 usec for pid 1335 (devd) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 965 > usec to 428 usec for pid 132 (adjkerntz) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 191 > usec to 84 usec for pid 15 (vmdaemon) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 74 > usec to 33 usec for pid 7 (sctp_iterator) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 984227 > usec to 748883 usec for pid 4 (g_down) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from > 1281130 usec to 979529 usec for pid 3 (g_up) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from 10320 > usec to 4890 usec for pid 1 (init) > Oct 30 19:13:25 NFS kernel: calcru: runtime went backwards from > 6244341 usec to 2848133 usec for pid 1 (init) > NFS# From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 10:06:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEF7106566C for ; Wed, 3 Nov 2010 10:06:30 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A352B8FC13 for ; Wed, 3 Nov 2010 10:06:30 +0000 (UTC) Received: by vws12 with SMTP id 12so916003vws.13 for ; Wed, 03 Nov 2010 03:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/PUv3BS9/2bBKX4XIrN94mwiUJ0K38UB9T+UTP+Wvsk=; b=hKheNpU0Vn2+YWFi7i17hhsza1NyvaopX6jYhMEi0YyRh4jNmdnpu4MWT+K+F5evc6 /1627aNS15kDx4M5oBFWFOG8stfwLkTexQRgtSe4H7rXwGFFXYylklKGK1D4oVvQqHin re+ALV2Lx61zI5b4IlS6vsJmer0+WPpp0ob10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lqg3gxM6X2yv8P/YcPrUIFLeQKoQX1Co7SGwTwpvzzwN45cuk3J1LSNoDPH9atfegs zr0K2vFRHuXMNbX3kHTGPdsMR8AETHdEWvY/OpOdRiv9PANqw3uAPfycS/fV6sRoV0+F In1dqRewJ4oAyCeG5U0meNapM41L5B3WYjVkw= MIME-Version: 1.0 Received: by 10.224.137.195 with SMTP id x3mr10166790qat.103.1288778787741; Wed, 03 Nov 2010 03:06:27 -0700 (PDT) Received: by 10.229.248.138 with HTTP; Wed, 3 Nov 2010 03:06:27 -0700 (PDT) In-Reply-To: <4CD12D29.2060501@phat.za.net> References: <4CD12D29.2060501@phat.za.net> Date: Wed, 3 Nov 2010 05:06:27 -0500 Message-ID: From: "Sam Fourman Jr." To: Aragon Gouveia Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Rhodus , current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 10:06:31 -0000 On Wed, Nov 3, 2010 at 4:36 AM, Aragon Gouveia wrote: > I recently saw these on a Dell server. =A0It was caused by power saving b= eing > enabled in the BIOS in a mode where the BIOS takes control instead of > handing it off to the OS. =A0Disable power saving or set it such that the= OS > has control (and then enable powerd(8) if you like). > > We disabled AMD C1E support in BIOS (it was Enabled) now we have not seen this problem for 2 days now. --=20 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 10:27:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D104D106564A; Wed, 3 Nov 2010 10:27:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id A6DA18FC12; Wed, 3 Nov 2010 10:27:35 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA3ARZVO005936; Wed, 3 Nov 2010 03:27:35 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA3ARYEH005935; Wed, 3 Nov 2010 03:27:35 -0700 (PDT) (envelope-from david) Date: Wed, 3 Nov 2010 03:27:34 -0700 From: David Wolfskill To: Bernhard Schmidt Message-ID: <20101103102734.GH1980@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Bernhard Schmidt , current@freebsd.org References: <20101101222510.GY1506@albert.catwhisker.org> <20101102215518.GA1980@albert.catwhisker.org> <201011030827.02253.bschmidt@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6cMF9JLEeZkfJjkP" Content-Disposition: inline In-Reply-To: <201011030827.02253.bschmidt@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 10:27:35 -0000 --6cMF9JLEeZkfJjkP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2010 at 08:27:02AM +0100, Bernhard Schmidt wrote: > ... > There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that= =20 > function is supposed to notify upper layers about the radio state (0 =3D = off, 1=20 > =3D on). Anyways, once wpa_supplicant import/update is done, I'll probabl= y have=20 > a look into that again. > .... Cool. If you want/need testing, I'll be happy to help. :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6cMF9JLEeZkfJjkP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzRORUACgkQmprOCmdXAD0E2wCfRg+UR1wOA+fKcT3LLhJVS3cm Tx4AoIMFGuNLeUKMPiC9OVTPjW2uHbTU =EFxD -----END PGP SIGNATURE----- --6cMF9JLEeZkfJjkP-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 12:38:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733C9106564A for ; Wed, 3 Nov 2010 12:38:26 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 083EC8FC08 for ; Wed, 3 Nov 2010 12:38:25 +0000 (UTC) Received: by ewy28 with SMTP id 28so176200ewy.13 for ; Wed, 03 Nov 2010 05:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=WHlGgB17x1W5GppQJ8WGMZ908MZm9ixAbmMGhZxudJI=; b=AeIDxTm67vNuIGTxyHPmxr+1nUreHkEph0nOgG5xd/DweJx+BQHgWDdK7G/ktrWho2 4p1d3g8DqqwhaH79VBUNODv3XuothpcQktPSUP88HSUbl8bG+aDTjefIvjda4U33V+H4 wehRfY3a9d3OAcf/MBbXJ/B82O1fRIWJZ9eEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=t/pANQ5ErN8fNMkLffrx00lzvLy+2/PArOpdUHBZZXACdupeJi7oCHuw47LCoj3vxd ZKp1sopU2UxJUYVAxvB4cO5EjmhtYFBsQaIncJKHAW3Hh8/BerQBdhU4msnn6UjWgAJm G+ODHnWWMd6mrCdfd87dvPY2N0Aygr+4mTwHg= Received: by 10.216.231.146 with SMTP id l18mr10940554weq.52.1288787902537; Wed, 03 Nov 2010 05:38:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Wed, 3 Nov 2010 05:36:23 -0700 (PDT) In-Reply-To: References: From: Renato Botelho Date: Wed, 3 Nov 2010 10:36:23 -0200 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Openoffice doesn't work with kernel+world built with Clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 12:38:26 -0000 On Fri, Oct 22, 2010 at 8:54 AM, Renato Botelho wrote: > I have a 9.0-current (r214167) amd64, kernel and world built > with clang and all ports built with gcc, and i cannot start > openoffice anymore, it shows splash, start to go up and die. > > If I reinstall world+kernel built with gcc openoffice works fine. > > The is a ktrace result available [1], let me know if you need > more information or tests. For now i solve my problem adding this to /etc/src.conf .if ${.CURDIR} == "/usr/src/gnu/lib/libgcc" CC=cc CXX=c++ .endif This way libgcc_s.so is built using gcc instead of clang and the problem is gone. I just wonder other problems we can find since simething on libgcc_s.so is broken when built with clang. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 13:32:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745F1106566B for ; Wed, 3 Nov 2010 13:32:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BFE1B8FC0C for ; Wed, 3 Nov 2010 13:32:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA08412; Wed, 03 Nov 2010 15:32:25 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD16468.8060100@icyb.net.ua> Date: Wed, 03 Nov 2010 15:32:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4CD12D29.2060501@phat.za.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 13:32:29 -0000 on 03/11/2010 12:06 Sam Fourman Jr. said the following: > On Wed, Nov 3, 2010 at 4:36 AM, Aragon Gouveia wrote: >> I recently saw these on a Dell server. It was caused by power saving being >> enabled in the BIOS in a mode where the BIOS takes control instead of >> handing it off to the OS. Disable power saving or set it such that the OS >> has control (and then enable powerd(8) if you like). >> >> > > We disabled AMD C1E support in BIOS (it was Enabled) > now we have not seen this problem for 2 days now. What revision do you run? What is output of kern.eventtimer sub-tree? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 14:37:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A12106566B for ; Wed, 3 Nov 2010 14:37:08 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A05528FC0C for ; Wed, 3 Nov 2010 14:37:07 +0000 (UTC) Received: by eyb7 with SMTP id 7so263269eyb.13 for ; Wed, 03 Nov 2010 07:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=LDKl50uQVTL7hoIfoElfLJxQNnbTRgj/C/BzO7Iqgag=; b=OMRVIxVCVe5jD4iWZqrWk2am5gEfxzLpwGQaGCWnOP7idXfNC53QsWtJ2PHgy12SVZ HM4Ld/BeWjCpOSBZEv8sMcNM7UYyyTn56l6SCQe2ro1Dcy7q1zsWMT7L+fbJOJA7lsyq 49FUkkWruQF+M8u0Oa2kMzLckaa/nJNytxe1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=fK+7J6F57deJc8uxE+SJlnSBdBo6Oj+2suAxJB7xz5hhjQtA/O13e1W0o1d/D8SiIi /felL3PEEzOdEUSfbtzVJGf+n5DhKBNgwXap0zQ2lT/WPesDn4iVhMU4yBu8/Y8h78wR BsKSsva5IzZkec+T0B7GSAwyH1biRT64r3MqY= Received: by 10.216.231.146 with SMTP id l18mr11051364weq.52.1288795025853; Wed, 03 Nov 2010 07:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Wed, 3 Nov 2010 07:36:44 -0700 (PDT) In-Reply-To: <20101103134417.GB81149@hoeg.nl> References: <20101103134417.GB81149@hoeg.nl> From: Renato Botelho Date: Wed, 3 Nov 2010 12:36:44 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Openoffice doesn't work with kernel+world built with Clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 14:37:08 -0000 On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten wrote: > Garga! > > * Renato Botelho , 20101103 13:36: >> For now i solve my problem adding this to /etc/src.conf >> >> .if ${.CURDIR} == "/usr/src/gnu/lib/libgcc" >> CC=cc >> CXX=c++ >> .endif >> >> This way libgcc_s.so is built using gcc instead of clang and the problem >> is gone. I just wonder other problems we can find since simething on >> libgcc_s.so is broken when built with clang. > > Would it be hard to figure out which exact object file causes this? Hi Ed, I've submitted a ktrace result of openoffice execution [1], i just saw it got a SIGBUS at some point, but debug openoffice doesn't seem to be a trivial task. I don't know if we can build OO with debug symbols to make it easier to debug. If you know what i can do to help debugging, just let me know and i can provide any information. [1] - http://people.freebsd.org/~garga/ktrace-error2.txt.gz -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 14:37:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 607E2106566C for ; Wed, 3 Nov 2010 14:37:37 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 1ECBC8FC25 for ; Wed, 3 Nov 2010 14:37:35 +0000 (UTC) Received: from [93.104.83.17] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PDeSx-0008GD-WC; Wed, 03 Nov 2010 15:37:33 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA3EbUA9002610; Wed, 3 Nov 2010 15:37:30 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA3EbUqG002609; Wed, 3 Nov 2010 15:37:30 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Wed, 3 Nov 2010 15:37:29 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org, kde-freebsd@kde.org Message-ID: <20101103143729.GA2560@current.Sisis.de> References: <20101102061418.GA1884@current.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101102061418.GA1884@current.Sisis.de> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.83.17 Cc: Subject: KDE 3.5.10_6 compiled (was Re: 9-CURRENT: ports/net/kdenetwork3 does not compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 14:37:37 -0000 Just for the records: After applying the patch for net/kdenetwork3 from Ed (thanks again for this), the port x11/kde3 (3.5.10_6) compiled fine on -CURRENT without further tweakings; and it comes up fine too :-) I've two smaller problems to investigate 1) I can't zapp the Xorg server with CTRL-ALT-BS (I've checked with xev(1) that the keys are working) 2) after KDE shutdown, the X server restarts again in background and I must kill the X proc manually... Any ideas about this? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 14:44:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F64D106564A for ; Wed, 3 Nov 2010 14:44:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id B8D728FC08 for ; Wed, 3 Nov 2010 14:44:50 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id EC3242A28FF8; Wed, 3 Nov 2010 15:44:49 +0100 (CET) Date: Wed, 3 Nov 2010 15:44:49 +0100 From: Ed Schouten To: Renato Botelho Message-ID: <20101103144449.GD81149@hoeg.nl> References: <20101103134417.GB81149@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="73F5niR8LUvFAf4p" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current Subject: Re: Openoffice doesn't work with kernel+world built with Clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 14:44:51 -0000 --73F5niR8LUvFAf4p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Renato Botelho , 20101103 15:36: > On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten wrote: > > Garga! > > > > * Renato Botelho , 20101103 13:36: > >> For now i solve my problem adding this to /etc/src.conf > >> > >> .if ${.CURDIR} =3D=3D "/usr/src/gnu/lib/libgcc" > >> CC=3Dcc > >> CXX=3Dc++ > >> .endif > >> > >> This way libgcc_s.so is built using gcc instead of clang and the probl= em > >> is gone. I just wonder other problems we can find since simething on > >> libgcc_s.so is broken when built with clang. > > > > Would it be hard to figure out which exact object file causes this? >=20 > Hi Ed, >=20 > I've submitted a ktrace result of openoffice execution [1], i just > saw it got a SIGBUS at some point, but debug openoffice doesn't > seem to be a trivial task. >=20 > I don't know if we can build OO with debug symbols to make it > easier to debug. If you know what i can do to help debugging, > just let me know and i can provide any information. Well, I mean, can you build some of libgcc's object files with Clang and others with GCC? Hint: Just build everything with GCC. Afterwards, go into the object directory, rm some of the .o files and make CC=3Dclang. Since OOo is a C++ application, I suspect the unwind-related object files to be the culprit. --=20 Ed Schouten WWW: http://80386.nl/ --73F5niR8LUvFAf4p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzRdWEACgkQ52SDGA2eCwVEZACfRzRC2NqY52/u2aD4iOY5/EM/ QV0An06aC7QbuIRiRuCwcmmiXLtNOnRt =K8z6 -----END PGP SIGNATURE----- --73F5niR8LUvFAf4p-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 15:06:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F30B106564A for ; Wed, 3 Nov 2010 15:06:03 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 303F08FC12 for ; Wed, 3 Nov 2010 15:06:02 +0000 (UTC) Received: by wwi17 with SMTP id 17so1534215wwi.1 for ; Wed, 03 Nov 2010 08:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=tt5dcchMoNm4dRLBqfNv/1BmgGLzc4M1Zyi3oX/5+Zw=; b=LHS9+VujNkjG9ZPcL10gAY9cQu+gA+kAYkZ3/ZLyXPwT4RVOaH1hVA5JslayRCbsiU nLJeEWYYKuNYnxhpuTmjW0dkkE6F3W8NejyAcg+GZfaGifry4GM81q/7TPNKUxjU6JEA bguULwbF9+UPO7zzTyCxbDSvzKCEBsI9XklcY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=tziKqhRKbtQfOCoW6zOkJJgSSS6xmg5DTiWQff/FCP3AMJTWSqCGdxiM4n7+824Oyg GSGXWPfWJ39592r66/tJj+L5yysaKc7zHsL5DUhYu0L79QJVxyV6qBbAW7BJsSW2jqcl qJgIFw4Cgwyop2Mo1AnC5ggNFO4YW8liVCO7k= Received: by 10.216.231.146 with SMTP id l18mr11080063weq.52.1288796761882; Wed, 03 Nov 2010 08:06:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Wed, 3 Nov 2010 08:05:41 -0700 (PDT) In-Reply-To: <20101103144449.GD81149@hoeg.nl> References: <20101103134417.GB81149@hoeg.nl> <20101103144449.GD81149@hoeg.nl> From: Renato Botelho Date: Wed, 3 Nov 2010 13:05:41 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Openoffice doesn't work with kernel+world built with Clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 15:06:03 -0000 On Wed, Nov 3, 2010 at 12:44 PM, Ed Schouten wrote: > * Renato Botelho , 20101103 15:36: >> On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten wrote: >> > Garga! >> > >> > * Renato Botelho , 20101103 13:36: >> >> For now i solve my problem adding this to /etc/src.conf >> >> >> >> .if ${.CURDIR} == "/usr/src/gnu/lib/libgcc" >> >> CC=cc >> >> CXX=c++ >> >> .endif >> >> >> >> This way libgcc_s.so is built using gcc instead of clang and the problem >> >> is gone. I just wonder other problems we can find since simething on >> >> libgcc_s.so is broken when built with clang. >> > >> > Would it be hard to figure out which exact object file causes this? >> >> Hi Ed, >> >> I've submitted a ktrace result of openoffice execution [1], i just >> saw it got a SIGBUS at some point, but debug openoffice doesn't >> seem to be a trivial task. >> >> I don't know if we can build OO with debug symbols to make it >> easier to debug. If you know what i can do to help debugging, >> just let me know and i can provide any information. > > Well, I mean, can you build some of libgcc's object files with Clang and > others with GCC? Hint: Just build everything with GCC. Afterwards, go > into the object directory, rm some of the .o files and make CC=clang. > > Since OOo is a C++ application, I suspect the unwind-related object > files to be the culprit. Bingo! When I build everything but unwind-dw2.o with clang it works. This is the object that is causing the problem. -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 15:10:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A33B51065679 for ; Wed, 3 Nov 2010 15:10:30 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3078E8FC1E for ; Wed, 3 Nov 2010 15:10:29 +0000 (UTC) Received: by bwz3 with SMTP id 3so633089bwz.13 for ; Wed, 03 Nov 2010 08:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VaIIQybSTbMHCxmGslJFHvVWKUSgqeva8qkA4j0mNh4=; b=nhB9wdKcBWvIW1q/KMCnewozw5QPCJI6G9sD2IuSxkOPyLRw1FT9qTWi6skrbQlq3c pkQqzp9I7gfMGZDdtKIVz7b1Q5J3XJi7e7g202LWb6/zZ60OLYTdErQzCwf+8BSC60em EK4rRWJRpeA9HlQw7bfrf4DsOFn7tQNzdrKIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sJOnQFV7ckju7c13DDRiMKKhn0aQ3POKVtZKt3/rcozGeidhwxhwQ3QjW9HRNstcBw I2tuj/rI5Od87q3zCsMJh4bE0ER53bwLEjtLlqNrNMbcxK+Wfv/nHu17GWm7OagYLOfT lPQjIbHPwkmR5wwolfT0lNk7zhzDziFfc6tNg= MIME-Version: 1.0 Received: by 10.204.113.196 with SMTP id b4mr6369939bkq.176.1288795451972; Wed, 03 Nov 2010 07:44:11 -0700 (PDT) Received: by 10.204.142.133 with HTTP; Wed, 3 Nov 2010 07:44:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Nov 2010 17:44:11 +0300 Message-ID: From: Alexander Churanov To: David Rhodus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 15:10:30 -0000 2010/10/30 David Rhodus : > I haven't seen much of this since 5.x days. =A0Anyone else see calcru > messages lately ? The following was performed on my Xen-powered VPS by RootBSD: $ grep calcru /var/log/messages | wc -l 125 $ grep calcru /var/log/messages | head -n3 Oct 26 18:05:59 vps-1 kernel: calcru: runtime went backwards from 23 usec to 20 usec for pid 5 (sctp_iterator) Oct 26 18:43:10 vps-1 kernel: calcru: runtime went backwards from 7227818 usec to 7102572 usec for pid 97039 (emacs) Oct 26 18:43:10 vps-1 kernel: calcru: runtime went backwards from 1364643 usec to 1340996 usec for pid 97039 (emacs) $ grep calcru /var/log/messages | tail -n3 Oct 29 14:25:55 vps-1 kernel: calcru: runtime went backwards from 353859 usec to 341567 usec for pid 37537 (zsh) Oct 29 14:25:55 vps-1 kernel: calcru: runtime went backwards from 2837565876 usec to 2734396425 usec for pid 37537 (zsh) Oct 29 17:44:47 vps-1 kernel: calcru: runtime went backwards from 111596 usec to 105716 usec for pid 44694 (zsh) $ Alexander Churanov From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 15:36:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECA8A106566C for ; Wed, 3 Nov 2010 15:36:40 +0000 (UTC) (envelope-from tgen@deepbone.net) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id 76AF08FC08 for ; Wed, 3 Nov 2010 15:36:39 +0000 (UTC) Received: from cpbrm-ews21.kpnxchange.com ([10.94.84.152]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 16:36:38 +0100 Received: from CPSMTPM-EML110.kpnxchange.com ([195.121.3.14]) by cpbrm-ews21.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 16:36:38 +0100 Received: from smtp.deepbone.net ([84.83.37.40]) by CPSMTPM-EML110.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Wed, 3 Nov 2010 16:36:37 +0100 Received: from [10.64.3.36] (unknown [10.64.1.10]) (Authenticated sender: tgen) by smtp.deepbone.net (Postfix) with ESMTPSA id 2249139842 for ; Wed, 3 Nov 2010 15:36:38 +0000 (UTC) Message-ID: <4CD18180.5000205@deepbone.net> Date: Wed, 03 Nov 2010 15:36:32 +0000 From: "Thomas E. Spanjaard" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100527 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8675858B2C65F5171869209" X-OriginalArrivalTime: 03 Nov 2010 15:36:38.0108 (UTC) FILETIME=[E78441C0:01CB7B6C] X-RcptDomain: freebsd.org Subject: Re: calcru: runtime went backwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 15:36:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8675858B2C65F5171869209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/30/2010 19:19, David Rhodus wrote: > I haven't seen much of this since 5.x days. Anyone else see calcru > messages lately ? I only get them right after boot due to ntpd_sync_on_start=3DYES. Cheers, --=20 Thomas E. Spanjaard tgen@netphreax.net tgen@deepbone.net --------------enigB8675858B2C65F5171869209 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJM0YGGAAoJEKE55rmjwpbTBToIAKKHQJHsgPh5UoBAyJs2iTOf w7cmSz2fwJauun1eeyu0qsOCpuo4Fa4khSi0kiszaVvEFPFSX77rTiQz42RH6c5N icyLQ42586IpQ+8a+jfLyVtmfxXpQfRzD841CR305wwWrXoYQmvmiYVYGaPLLLPf INZDe9Ch5/20PqsWWau2/HcmF1vlxS8ZiOADa9l+ZEv2qk2eanF25oWuzyxtl3rk /6XZx1pPRzJOGym1Hcq0qZamekJ85ul4F5j2+KT79suEiV1G4OgS7QHIfeAVVcZF GOgId7SKfsm7FDMuGzFQIYXOGI38lk6YEH9S5auNeBYvgMm5iiYcJwgBkJQHmAI= =hT9q -----END PGP SIGNATURE----- --------------enigB8675858B2C65F5171869209-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 16:27:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DDB8106564A for ; Wed, 3 Nov 2010 16:27:09 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6545F8FC19 for ; Wed, 3 Nov 2010 16:27:09 +0000 (UTC) Received: by pwi8 with SMTP id 8so328828pwi.13 for ; Wed, 03 Nov 2010 09:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=38ssT7+n5k/PLT22QN3Bg7C8RybwM7sNyTaTrcIPkRM=; b=Bs2kUKvgSKhWspL83J4PQNJm+8VUsp+hX37QPgt2wZBJz8NTXjUOQzyaj2OmZ1e3W9 3Zh3lnLuLEQ575lG4sGsKfodGVRozVZdgR3RX/GvcnT2bvZ/lSso7G0bjX6DvT28qPJt GX7QvZ6xNER2KcZR3fco4vKUQN219oVxi5hSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=TIvAvVzwN8EiTNnKiL49eVggHjWtL+1AzTO9FTnjHLQ0LQVSBXHexpF3GDPVDbba1B VKzkZGela/odknKd798sxcyESE/y2pK2cspBdB+insa8ufjCVDvaJiVsDiEPQPj+bcdW K/ZQv1I45VikuMl2z7lUYM89yv857v2R13Qvs= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr354713icb.477.1288801628033; Wed, 03 Nov 2010 09:27:08 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.159.198 with HTTP; Wed, 3 Nov 2010 09:27:07 -0700 (PDT) Date: Wed, 3 Nov 2010 09:27:07 -0700 X-Google-Sender-Auth: NZDV_J3ZK2-yiYpWhVi_kpqZ66Q Message-ID: From: mdf@FreeBSD.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:27:09 -0000 It's not clear to me from the man pages (perhaps I didn't look at the right one?) in which environments I need a spinlock. For example, I wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler (i.e one that was registered with BUS_SETUP_INTR), but I see some code lying around here that does it and nothing I'm aware of has broken. Perhaps this comes to me still not understanding exactly how interrupts work on FreeBSD. If I capture the stack in a hard interrupt, it looks something like: #0 0xffffff87b07f43b5 at rnv_hard_intr+0x35 #1 0xffffffff8026e7ce at ithread_execute_handlers+0x9e #2 0xffffffff8026ead0 at ithread_loop+0x70 #3 0xffffffff8026b84c at fork_exit+0x9c #4 0xffffffff804a7f7e at fork_trampoline+0xe And there the stack ends. From my perspective, this doesn't look like anything was actually interrupted. By way of explaining what I mean, on AIX we defined 10 levels of software interrupt, and we trained the kernel debugger to understand the save frames that were acquired on interrupt to print a full stack. So a full stack dump might show something like a few frames from one interrupt handler, then a save area, then a frames from a lower priority interrupt, then another save area, then the base-level stack. In this kind of programming environment, it was important to know at what interrupt level your handler would execute, so that locks acquired to synchronize between the top-half and bottom-half were acquired with interupts disabled to the same level. So, back to my question. Is it safe to take a MTX_DEF in a hard interrupt? What about a soft interrupt? I have to assume it's okay in a soft-interrupt context (swi_sched, callout, etc.), since softclock() will acquire a MTX_DEF on behalf of a callout. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 16:42:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5771D1065670 for ; Wed, 3 Nov 2010 16:42:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 719508FC14 for ; Wed, 3 Nov 2010 16:42:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11441; Wed, 03 Nov 2010 18:42:23 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD190EF.5080600@icyb.net.ua> Date: Wed, 03 Nov 2010 18:42:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: mdf@FreeBSD.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 16:42:26 -0000 on 03/11/2010 18:27 mdf@FreeBSD.org said the following: > It's not clear to me from the man pages (perhaps I didn't look at the > right one?) in which environments I need a spinlock. For example, I > wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler > (i.e one that was registered with BUS_SETUP_INTR), but I see some code > lying around here that does it and nothing I'm aware of has broken. Such a handler runs in an interrupt thread. The "harder" interrupt handler is called interrupt filter in FreeBSD terminology. I think that it was formerly known as fast interrupt. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:04:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3681065672 for ; Wed, 3 Nov 2010 17:04:14 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 71B9B8FC18 for ; Wed, 3 Nov 2010 17:04:14 +0000 (UTC) Received: by iwn39 with SMTP id 39so928865iwn.13 for ; Wed, 03 Nov 2010 10:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=E4NjuZTm2ZdvuZiRMrjaIPkPFxw7cty7I7cb3fWFW18=; b=IjiJE9IqG2LHbnr4G/PalcQQwUqY1Itsf2i/4OPeQaIHQVKgRnJzb4RoQd15bhc15q QtWwKfgZXn3g9owJZh5WbxqsS8y3ImaqSLoKGhaWVldcPzFbOuFnE78pjqaBYGcwMlWH PZQoyNJslSCH7OOoRQyzTkZFZ0232MjbqTKS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HTrIpMdeY/IuKZ9evMOzBKZP7pDynPl+pT5mTSgW8yoMAMhSS8fjzDxglWXV+o5GTZ Wb71urPlycIjW/sWUf+9BhHdOPs3Z17ThqxL77a+hOeOgEAzeflpgPB0wRddk/GFTe19 d85fEB2Tgf7ebhNfsjRZVNgGOUn/frse8IZrI= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr5448797ibd.58.1288803853537; Wed, 03 Nov 2010 10:04:13 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.159.198 with HTTP; Wed, 3 Nov 2010 10:04:13 -0700 (PDT) In-Reply-To: <4CD190EF.5080600@icyb.net.ua> References: <4CD190EF.5080600@icyb.net.ua> Date: Wed, 3 Nov 2010 10:04:13 -0700 X-Google-Sender-Auth: Xqcul_ec2hZdO7se7-sULu6f2pE Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:04:14 -0000 On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon wrote: > on 03/11/2010 18:27 mdf@FreeBSD.org said the following: >> It's not clear to me from the man pages (perhaps I didn't look at the >> right one?) in which environments I need a spinlock. =A0For example, I >> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler >> (i.e one that was registered with BUS_SETUP_INTR), but I see some code >> lying around here that does it and nothing I'm aware of has broken. > > Such a handler runs in an interrupt thread. > The "harder" interrupt handler is called interrupt filter in FreeBSD term= inology. > =A0I think that it was formerly known as fast interrupt. So a MTX_DEF is okay in that environment? What would "best practices" be considered for what code should be run in the interrupt handler versus a soft interrupt? In this case the kinds of things we have to do at some level of interrupt are: - handle a heartbeat interrupt from firmware a few times a second - get a DMA completion interrupt (completely handling this requires calling biodone on all the associated bios) - receive an ECC interrupt (this requires reading registers off the card for details) At the moment we're on stable/7, but we will be migrating the code base to something more recent in another year or so, if that affects the answer. Is there any documentation on best practices for writing a FreeBSD driver? Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:09:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397B61065674; Wed, 3 Nov 2010 17:09:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 484298FC16; Wed, 3 Nov 2010 17:09:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA11787; Wed, 03 Nov 2010 19:09:23 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD19742.2010501@icyb.net.ua> Date: Wed, 03 Nov 2010 19:09:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <4CD190EF.5080600@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:09:26 -0000 on 03/11/2010 19:04 mdf@FreeBSD.org said the following: > On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon wrote: >> on 03/11/2010 18:27 mdf@FreeBSD.org said the following: >>> It's not clear to me from the man pages (perhaps I didn't look at the >>> right one?) in which environments I need a spinlock. For example, I >>> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler >>> (i.e one that was registered with BUS_SETUP_INTR), but I see some code >>> lying around here that does it and nothing I'm aware of has broken. >> >> Such a handler runs in an interrupt thread. >> The "harder" interrupt handler is called interrupt filter in FreeBSD terminology. >> I think that it was formerly known as fast interrupt. > > So a MTX_DEF is okay in that environment? Yes, I think so. > What would "best practices" be considered for what code should be run > in the interrupt handler versus a soft interrupt? Sorry for not going into details, but I personally think that there is no reason to use soft interrupts. If you can do everything in interrupt handler (i.e. on interrupt threads), then that should be all you need. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:10:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DA81065674; Wed, 3 Nov 2010 17:10:00 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6431D8FC15; Wed, 3 Nov 2010 17:09:58 +0000 (UTC) Received: by ewy28 with SMTP id 28so423717ewy.13 for ; Wed, 03 Nov 2010 10:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6mrmO9Fipp3fyCqSTp8OqrqrI8UUa+rJ4Uvct3/Yp6I=; b=JKBMsCJY0rgoCY5q4OYvYDexHgOf0bEcRMSiV7KuxjpDCQUCym71rtXXwWQCo0SnGt 83Kjepcg/2ZwmhdpbkWYgrytyRuxwHBHtxvkJxvr6n0ttZWeQy6HliWvAH3BlLNmAtuu 6x5JBgpglme4gjKr9RvlB9nz15ORZ2146UgXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jjEF0oJLIqvCnZTz/14hUP4ThUy5PGzAcd4dFM0lJjKm528MhKpQG2urmB6pNrI5sb nU+ZRjDXiKZC8XE0XyiAFHxAxaS5qvxMQp/SZbxrH2sga85LrCPFttrN2xClnzAW0jAq bsYXMKann0hgsgpmaNI9uwoeIrv6oFRCxPMiw= MIME-Version: 1.0 Received: by 10.213.34.198 with SMTP id m6mr4677265ebd.68.1288802446581; Wed, 03 Nov 2010 09:40:46 -0700 (PDT) Received: by 10.213.106.15 with HTTP; Wed, 3 Nov 2010 09:40:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Nov 2010 12:40:46 -0400 Message-ID: From: Ryan Stone To: mdf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:10:00 -0000 On Wed, Nov 3, 2010 at 12:27 PM, wrote: > It's not clear to me from the man pages (perhaps I didn't look at the > right one?) in which environments I need a spinlock. =A0For example, I > wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler > (i.e one that was registered with BUS_SETUP_INTR), but I see some code > lying around here that does it and nothing I'm aware of has broken. You can get either a hard interrupt handler(or fast handler in FreeBSD parlance) or a soft handler using BUS_SETUP_INTR. On FreeBSD 7 and later fast interrupt handlers are passed to filter argument to BUS_SETUP_INTR and soft handlers are passed to the ithread argument(on earlier versions you had to pass the INTR_FAST flag to get a fast handler). You are correct that fast interrupt handlers may only acquire spinlocks, not mutexes. Soft interrupt handlers have their own thread associated with them and so it's safe to acquire MTX_DEF locks in that thread. In your particular example you are running from the context of a software interrupt thread, so you are safe to acquire MTX_DEF mutexes. From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:11:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D36B106566B; Wed, 3 Nov 2010 17:11:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 316008FC2A; Wed, 3 Nov 2010 17:11:04 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oA3HB11h006764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 19:11:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oA3HB1oh063805; Wed, 3 Nov 2010 19:11:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oA3HB1c8063804; Wed, 3 Nov 2010 19:11:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Nov 2010 19:11:01 +0200 From: Kostik Belousov To: mdf@freebsd.org Message-ID: <20101103171101.GS2392@deviant.kiev.zoral.com.ua> References: <4CD190EF.5080600@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="diyAeELN2I8WbrL0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:11:05 -0000 --diyAeELN2I8WbrL0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2010 at 10:04:13AM -0700, mdf@freebsd.org wrote: > On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon wrote: > > on 03/11/2010 18:27 mdf@FreeBSD.org said the following: > >> It's not clear to me from the man pages (perhaps I didn't look at the > >> right one?) in which environments I need a spinlock. =9AFor example, I > >> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler > >> (i.e one that was registered with BUS_SETUP_INTR), but I see some code > >> lying around here that does it and nothing I'm aware of has broken. > > > > Such a handler runs in an interrupt thread. > > The "harder" interrupt handler is called interrupt filter in FreeBSD te= rminology. > > =9AI think that it was formerly known as fast interrupt. >=20 > So a MTX_DEF is okay in that environment? >=20 > What would "best practices" be considered for what code should be run > in the interrupt handler versus a soft interrupt? In this case the > kinds of things we have to do at some level of interrupt are: >=20 > - handle a heartbeat interrupt from firmware a few times a second Doing this in the filter would only assert that interrupts are not disabled. If you perform the heartbeat notification from the interrupt thread instead, you have some assurance that scheduling works. > - get a DMA completion interrupt (completely handling this requires > calling biodone on all the associated bios) Calling into geom and possibly fs/VFS level should be done from the interrupt thread. I thought that g_up thread is used to handle the finish of i/o ? > - receive an ECC interrupt (this requires reading registers off the > card for details) >=20 > At the moment we're on stable/7, but we will be migrating the code > base to something more recent in another year or so, if that affects > the answer. >=20 > Is there any documentation on best practices for writing a FreeBSD driver? Not that I am aware of. You can read locking(9) in HEAD to get the answer on your question about spin mutexes. --diyAeELN2I8WbrL0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzRl6QACgkQC3+MBN1Mb4gEZACeNKCeEXlf4nRVQ5E1Q0TGW75j 2kAAn1Po3Xe0Tb8AOOlWVhurL/VCZDpE =grq6 -----END PGP SIGNATURE----- --diyAeELN2I8WbrL0-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:18:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C611065679; Wed, 3 Nov 2010 17:18:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A5EC98FC0A; Wed, 3 Nov 2010 17:18:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 52D5846B2D; Wed, 3 Nov 2010 13:18:20 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DE7C38A009; Wed, 3 Nov 2010 13:18:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 3 Nov 2010 13:17:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CD190EF.5080600@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031317.36332.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 03 Nov 2010 13:18:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: mdf@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:18:20 -0000 On Wednesday, November 03, 2010 1:04:13 pm mdf@freebsd.org wrote: > On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon wrote: > > on 03/11/2010 18:27 mdf@FreeBSD.org said the following: > >> It's not clear to me from the man pages (perhaps I didn't look at the > >> right one?) in which environments I need a spinlock. For example, I > >> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler > >> (i.e one that was registered with BUS_SETUP_INTR), but I see some code > >> lying around here that does it and nothing I'm aware of has broken. > > > > Such a handler runs in an interrupt thread. > > The "harder" interrupt handler is called interrupt filter in FreeBSD terminology. > > I think that it was formerly known as fast interrupt. > > So a MTX_DEF is okay in that environment? Yes. In fact, the reason to have threads for interrupt handlers is to allow interrupt handlers to use non-spin locks that block when the lock is held. MTX_SPIN locks are generally not needed in device drivers. The only reason a driver would use one is if it used a filter handler which does not run in a threaded context. > What would "best practices" be considered for what code should be run > in the interrupt handler versus a soft interrupt? In this case the > kinds of things we have to do at some level of interrupt are: > > - handle a heartbeat interrupt from firmware a few times a second > - get a DMA completion interrupt (completely handling this requires > calling biodone on all the associated bios) > - receive an ECC interrupt (this requires reading registers off the > card for details) > > At the moment we're on stable/7, but we will be migrating the code > base to something more recent in another year or so, if that affects > the answer. I suspect all of these are fine to handle in a regular interrupt handler. If you need to run a task that needs to block on a condition (e.g. cv_*wait*() or *sleep()), then you probably want to use a task to deter that to a taskqueue. At this point taskqueue's are probably the cloest thing FreeBSD really has to a true software interrupt. FreeBSD does have software interrupts still, but the taskqueue API is actually easier to work with for device drivers. > Is there any documentation on best practices for writing a FreeBSD driver? Not really. :-/ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:23:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A613D106566C; Wed, 3 Nov 2010 17:23:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BDF198FC1E; Wed, 3 Nov 2010 17:23:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA11996; Wed, 03 Nov 2010 19:23:48 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD19AA3.3070106@icyb.net.ua> Date: Wed, 03 Nov 2010 19:23:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: mdf@freebsd.org References: <4CD190EF.5080600@icyb.net.ua> <20101103171101.GS2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101103171101.GS2392@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 17:23:50 -0000 on 03/11/2010 19:11 Kostik Belousov said the following: > On Wed, Nov 03, 2010 at 10:04:13AM -0700, mdf@freebsd.org wrote: >> Is there any documentation on best practices for writing a FreeBSD driver? > Not that I am aware of. You can read locking(9) in HEAD to get the answer > on your question about spin mutexes. BTW, I think that BUS_SETUP_INTR(9) contains the most up to date information on interrupt handling piece of a driver. Unlike e.g. ithread(9). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 18:16:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90EA5106564A; Wed, 3 Nov 2010 18:16:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6D30C8FC0C; Wed, 3 Nov 2010 18:16:03 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA3HqHWI016933; Wed, 3 Nov 2010 10:52:18 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id D48AC2D6018; Wed, 3 Nov 2010 10:52:16 -0700 (PDT) Message-ID: <4CD1A14E.8060508@freebsd.org> Date: Wed, 03 Nov 2010 10:52:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <4CD190EF.5080600@icyb.net.ua> <201011031317.36332.jhb@freebsd.org> In-Reply-To: <201011031317.36332.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: mdf@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 18:16:03 -0000 On 11/3/10 10:17 AM, John Baldwin wrote: > On Wednesday, November 03, 2010 1:04:13 pm mdf@freebsd.org wrote: >> >> So a MTX_DEF is okay in that environment? > Yes. In fact, the reason to have threads for interrupt handlers is to allow > interrupt handlers to use non-spin locks that block when the lock is held. > > MTX_SPIN locks are generally not needed in device drivers. The only reason a > driver would use one is if it used a filter handler which does not run in a > threaded context. It should be noted that in the case where you really just want to spin a few instructions because some other thread is accessing a structure you want, descheduling you. so you don't always incur the scheduling overhead. From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 18:30:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30922106564A; Wed, 3 Nov 2010 18:30:42 +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 4A39B8FC22; Wed, 3 Nov 2010 18:30:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA12639; Wed, 03 Nov 2010 20:30:29 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD1AA45.7000504@freebsd.org> Date: Wed, 03 Nov 2010 20:30:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> In-Reply-To: <4CAECC4D.90707@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 18:30:42 -0000 on 08/10/2010 10:46 Alan Cox said the following: > Andriy Gapon wrote: >> Here's an updated patch: >> http://people.freebsd.org/~avg/amd64-minidump.3.diff > > The kernel part of the patch looks good. That said, I have one suggestion. The > current generation of AMD and Intel processors has support for 1GB pages. If you > want to make sure that this change will last us a long time, I would suggest > translating the old trick of generating a fake page table page for 2MB pages into > generating a fake page directory page for 1GB pages, rather than disposing of this > code. Let me double-check if I understand your suggestion correctly. So, if a 1GB page is used, then there will be a PDP entry for it with PS bit set, and PD entries for the range covered by the page will not be correctly set up? That is, I assumed that even if 1GB pages are used, then the corresponding PD entries are still correctly set up. But you say that this may not be the case in reality? So, I have to check PDP entry first and only if it's valid and it doesn't point to a 1GB page then I should examine corresponding PD entries. Correct? P.S. is there a macro for extracting frame address from PDPE? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 18:50:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79DC10656A6; Wed, 3 Nov 2010 18:50:34 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8AB8FC22; Wed, 3 Nov 2010 18:50:34 +0000 (UTC) Received: by iwn39 with SMTP id 39so1030742iwn.13 for ; Wed, 03 Nov 2010 11:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.19.74 with SMTP id z10mr4240703iba.120.1288808895749; Wed, 03 Nov 2010 11:28:15 -0700 (PDT) Received: by 10.231.172.202 with HTTP; Wed, 3 Nov 2010 11:28:15 -0700 (PDT) In-Reply-To: <20100831215915.GE1932@garage.freebsd.pl> References: <20100831215915.GE1932@garage.freebsd.pl> Date: Wed, 3 Nov 2010 19:28:15 +0100 Message-ID: From: Olivier Smedts To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 18:50:34 -0000 2010/8/31 Pawel Jakub Dawidek : > Hello. > > I'd like to give you ZFS v28 for testing. If you are neither brave nor > mad, you can stop here. > > The patchset is very experimental. It can eat your cookie and hurt your > teddy bear, so be warned. Don't try it for anything except testing. > > This patchset is also a message we, as the FreeBSD project, would like > to send to our users: Eventhough OpenSolaris is dead, the ZFS file > system is going to stay in FreeBSD. At this point we have quite a few > developers involved in ZFS on FreeBSD as well as serveral companies. > We are also looking forward to work with IllumOS. > > So, what this new ZFS brings? > > - Data deduplication. Read more here: > > =A0 =A0 =A0 =A0http://blogs.sun.com/bonwick/entry/zfs_dedup > > - Triple parity RAIDZ (RAIDZ3). Read more here: > > =A0 =A0 =A0 =A0http://dtrace.org/blogs/ahl/2009/07/21/triple-parity-raid-= z/ > > - zfs diff. Read more here: > > =A0 =A0 =A0 =A0http://arc.opensolaris.org/caselog/PSARC/2010/105/20100328= _tim.haley > > - zpool split. Read more here: > > =A0 =A0 =A0 =A0http://arc.opensolaris.org/caselog/PSARC/2009/511/20090924= _mark.musante > > - Snapshot holds. Read more here: > > =A0 =A0 =A0 =A0http://arc.opensolaris.org/caselog/PSARC/2009/297/20090511= _chris.kirby > > - zpool import -F. Allows to rewind corrupted pool to earlier > =A0transaction group. > > - Possibility to import pool in read-only mode. > > And much, much more, including plenty of preformance improvements and bug > fixes. > > So test whatever you can and report back. Look for regressions, strange > behaviour, missing features, deadlocks, livelocks, preformance > degradation, etc. > > The boot code is not updated at all, so booting off of ZFS doesn't > currently work. > > The patch is against today's FreeBSD HEAD. > > The patch enables (in sys/modules/zfs/Makefile) ZFS internal debugging, > please don't turn it off. Also, compile your kernel with the following > options: > > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 KDB > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 DDB > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 INVARIANTS > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 INVARIANT_SUPPORT > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 WITNESS > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 WITNESS_SKIPSPIN > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 DEBUG_LOCKS > =A0 =A0 =A0 =A0options =A0 =A0 =A0 =A0 DEBUG_VFS_LOCKS > > Ignore all the LOR (Lock Order Reversal) reports from WITNESS. There will > be plenty of those, and you'll desperately want to report them, but pleas= e > don't. > > The best way to report a problem is to answer to this e-mail with as shor= t > as possible procedure of how to reproduce it and debugging info. I'd > prefer textdump if possible. Below you can find quick procedure how to > setup textdumps: > > =A0 =A0 =A0 =A0Choose spare/swap disk/partition in your system, let's say= it is > =A0 =A0 =A0 =A0/dev/ad0s1b. > > =A0 =A0 =A0 =A0Add the following line to /etc/fstab: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/dev/ad0s1b =A0 =A0 none =A0 =A0swap =A0 = =A0sw =A0 =A0 =A00 =A0 =A0 =A0 0 > > =A0 =A0 =A0 =A0Add the following line to /etc/rc.conf: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ddb_enable=3D"YES" > > =A0 =A0 =A0 =A0Run the following commands: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# /etc/rc.d/swap1 start > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# /etc/rc.d/dumpon start > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# /etc/rc.d/ddb start > > =A0 =A0 =A0 =A0This will setup swap, mark it as dump device and setup som= e DDB > =A0 =A0 =A0 =A0scripts. Or you can just reboot. > > =A0 =A0 =A0 =A0Now when your system panic or deadlock, enter DDB and call= the > =A0 =A0 =A0 =A0following command: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ddb> run kdb.enter.panic > > =A0 =A0 =A0 =A0It will execute all the commands I need, dump them in text= format to > =A0 =A0 =A0 =A0your swap device and reboot machine. > > =A0 =A0 =A0 =A0After the reboot, you should find textdump.tar.0 file in /= var/crash/ > =A0 =A0 =A0 =A0directory. This is the debug info I need. > > End of textdumps procedure. > > Ok, now that I know you read everything carefully, here is the patch: > > =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.= bz2 Hello, Any status update on this ? I regularly check http://people.freebsd.org/~pjd/patches/ to see if there's an updated version of your patch. 2 months old is quite a bit for -CURRENT, which often receives commits on zfs&co parts. Thanks for all your work on FreeBSD (not only ZFS). > > Good luck! >:> > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheelsystems.com > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 18:55:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476E71065675; Wed, 3 Nov 2010 18:55:54 +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 5E2AA8FC26; Wed, 3 Nov 2010 18:55:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA12924; Wed, 03 Nov 2010 20:55:42 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD1B02E.2070708@freebsd.org> Date: Wed, 03 Nov 2010 20:55:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> In-Reply-To: <4CD1AD80.2090903@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 18:55:54 -0000 on 03/11/2010 20:44 Alan Cox said the following: [snip] Thank you for the confirmation! > Andriy Gapon wrote: >> P.S. is there a macro for extracting frame address from PDPE? > To a lower level page table page or to a 1GB physical page? For the latter, you > can use PG_PS_FRAME. To a 1GB page. I see in the architecture manual that the lower bits are marked as MBZ, so this macro should work. Actually, it seems that even PG_FRAME should work in place of PG_PS_FRAME for exactly the same reason (MBZ) on amd64. Thank you! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 20:06:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE7D106566B for ; Wed, 3 Nov 2010 20:06:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 281678FC12 for ; Wed, 3 Nov 2010 20:06:20 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id oA3K5inH044493 for ; Wed, 3 Nov 2010 13:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1288814745; bh=D3llY1LuheoOs9veXpdId2WiF+BPUTPBQmK4Hedh4hk=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=sUlLDj6bzdQRO/OUc0/CAgVKCN3trVZkyZCDh/hd+BYyxQgi/HhwvhUzflJUn0YLT soJQiubFWPcdqiflYI5Z/JRTRcG9xtKsPfAq4OUUVLyN/Bou3ryBY+33O7UsXZj1f3 U8Gw8kwb+Bla1Zo2zFlS9kG3SU5IRB/rhH83vcHI= From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Wed, 03 Nov 2010 13:05:44 -0700 Message-ID: <1288814744.2647.6.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: Sanity Check, HP Bigger Iron DL580G7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 20:06:21 -0000 Been working on getting this machine serviceable under FreeBSD with HP, I need to try out some patches for other problems, but I wanted to link folks to the pciconf output first. Most importantly, I see an unsupported ethernet controller in this box, but other's may find other devices of interest as well. Sean http://people.freebsd.org/~sbruno/dl580g7_pciconf.txt From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 21:24:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE8C91065670; Wed, 3 Nov 2010 21:24:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 775268FC1F; Wed, 3 Nov 2010 21:24:57 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6620845C89; Wed, 3 Nov 2010 22:24:56 +0100 (CET) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 48A8A45C98; Wed, 3 Nov 2010 22:24:51 +0100 (CET) Date: Wed, 3 Nov 2010 22:24:11 +0100 From: Pawel Jakub Dawidek To: Olivier Smedts Message-ID: <20101103212411.GE13266@garage.freebsd.pl> References: <20100831215915.GE1932@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NGIwU0kFl1Z1A3An" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 21:24:58 -0000 --NGIwU0kFl1Z1A3An Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2010 at 07:28:15PM +0100, Olivier Smedts wrote: > > =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/zfs_20100831.patc= h.bz2 >=20 > Hello, >=20 > Any status update on this ? I regularly check > http://people.freebsd.org/~pjd/patches/ to see if there's an updated > version of your patch. 2 months old is quite a bit for -CURRENT, which > often receives commits on zfs&co parts. >=20 > Thanks for all your work on FreeBSD (not only ZFS). It took a while, but I should have something new shortly. I recently finished boot support for v28 (the most missing feature in the previous patch?) and will work on new patch soon. I'm heading to meetBSD California tomorrow and I'll be back in a week, so nothing will happen till then for sure. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --NGIwU0kFl1Z1A3An Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzR0vsACgkQForvXbEpPzRDTACeN9wKLtXdkNvZfOUQd8i5yiiA Z2cAnjuf0GPnJn4anBzumqJyxfTg7OI1 =jmof -----END PGP SIGNATURE----- --NGIwU0kFl1Z1A3An-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 21:31:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6506E1065679; Wed, 3 Nov 2010 21:31:35 +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 7A6578FC1E; Wed, 3 Nov 2010 21:31:34 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14538; Wed, 03 Nov 2010 23:31:22 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDkvS-000AtK-DG; Wed, 03 Nov 2010 23:31:22 +0200 Message-ID: <4CD1D4AA.3060309@freebsd.org> Date: Wed, 03 Nov 2010 23:31:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alan Cox , freebsd-current@freebsd.org References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> In-Reply-To: <4CD1AD80.2090903@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 21:31:35 -0000 So, here is the next version of the patch: http://people.freebsd.org/~avg/amd64-minidump.4.diff Changes since the last version: 1. libkvm - try to support both the new and the previous formats/versions of amd64 minidump. I am not entirely sure about style in which I handled handling of version 1 minidump. Identifier names like pmapsize (for "page map size") and page_map could also be improved, perhaps. 2. kernel - implemented dumping of 1GB pages via "fake" 512 x 2MB pages per Alan's suggestion. The change is only compile tested so far. Not sure if it's possible to test handling 1GB pages yet :-) As always, reviews, testing and suggestions are very welcome. Thank you for your help! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 21:56:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 631B21065672; Wed, 3 Nov 2010 21:56:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 904098FC08; Wed, 3 Nov 2010 21:56:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAK920UyDaFvO/2dsb2JhbACDI583r1mRGIEigzFzBIUPhUaFCg X-IronPort-AV: E=Sophos;i="4.58,291,1286164800"; d="scan'208";a="97701904" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 03 Nov 2010 17:56:09 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1E324B3F50; Wed, 3 Nov 2010 17:56:09 -0400 (EDT) Date: Wed, 3 Nov 2010 17:56:09 -0400 (EDT) From: Rick Macklem To: John Baldwin Message-ID: <1467533946.56814.1288821369058.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201011031317.36332.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: mdf@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 21:56:11 -0000 > > > Is there any documentation on best practices for writing a FreeBSD > > driver? > > Not really. :-/ > Just a dumb obvious suggestion. Imho, there is no better doc. than some well written code, so maybe someone familiar with the drivers can suggest one (or two) that they consider well written and use the current conventions as "examples"? rick, who never trusts documentation anyhow;-) From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 22:01:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3DEB1065693; Wed, 3 Nov 2010 22:01:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 80FD68FC12; Wed, 3 Nov 2010 22:01:20 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA3M1J19029267; Wed, 3 Nov 2010 15:01:19 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 8C57D2D6012; Wed, 3 Nov 2010 15:01:18 -0700 (PDT) Message-ID: <4CD1DBAC.6050004@freebsd.org> Date: Wed, 03 Nov 2010 15:01:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <4CD190EF.5080600@icyb.net.ua> <201011031317.36332.jhb@freebsd.org> <4CD1A14E.8060508@freebsd.org> In-Reply-To: <4CD1A14E.8060508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: mdf@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 22:01:20 -0000 On 11/3/10 10:52 AM, Julian Elischer wrote: > On 11/3/10 10:17 AM, John Baldwin wrote: >> On Wednesday, November 03, 2010 1:04:13 pm mdf@freebsd.org wrote: >>> >>> So a MTX_DEF is okay in that environment? >> Yes. In fact, the reason to have threads for interrupt handlers is >> to allow >> interrupt handlers to use non-spin locks that block when the lock >> is held. >> >> MTX_SPIN locks are generally not needed in device drivers. The >> only reason a >> driver would use one is if it used a filter handler which does not >> run in a >> threaded context. > oops a line got deleted I think.. > It should be noted that in the case where you really just want to > spin a few > instructions because some other thread is accessing a structure you > want, ... then the BTX_DEF code will spin for a short while before ... > descheduling you. so you don't always incur the scheduling overhead. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 22:02:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02D371065672; Wed, 3 Nov 2010 22:02:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id D5A778FC14; Wed, 3 Nov 2010 22:02:19 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA3M2JmS029315; Wed, 3 Nov 2010 15:02:19 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id E75F02D6014; Wed, 3 Nov 2010 15:02:17 -0700 (PDT) Message-ID: <4CD1DBE8.7090200@freebsd.org> Date: Wed, 03 Nov 2010 15:02:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Rick Macklem References: <1467533946.56814.1288821369058.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1467533946.56814.1288821369058.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: mdf@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 22:02:20 -0000 On 11/3/10 2:56 PM, Rick Macklem wrote: >>> Is there any documentation on best practices for writing a FreeBSD >>> driver? >> Not really. :-/ >> > Just a dumb obvious suggestion. Imho, there is no better doc. than some > well written code, so maybe someone familiar with the drivers can suggest > one (or two) that they consider well written and use the current conventions > as "examples"? we try every now and then to put good examples in /usr/share/examples but I think what's there is hopelessly out of date. > rick, who never trusts documentation anyhow;-) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 22:12:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 339B1106564A; Wed, 3 Nov 2010 22:12:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 395DB8FC13; Wed, 3 Nov 2010 22:12:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIZ70UyDaFvO/2dsb2JhbACDI583r1ORFoEigzFzBIUPhUaFCg X-IronPort-AV: E=Sophos;i="4.58,291,1286164800"; d="scan'208";a="97703628" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 03 Nov 2010 18:12:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 05929B3F53; Wed, 3 Nov 2010 18:12:50 -0400 (EDT) Date: Wed, 3 Nov 2010 18:12:50 -0400 (EDT) From: Rick Macklem To: Julian Elischer Message-ID: <223810140.57555.1288822369961.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4CD1DBE8.7090200@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: mdf@freebsd.org, freebsd-current@freebsd.org, Andriy Gapon Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 22:12:52 -0000 > On 11/3/10 2:56 PM, Rick Macklem wrote: > >>> Is there any documentation on best practices for writing a FreeBSD > >>> driver? > >> Not really. :-/ > >> > > Just a dumb obvious suggestion. Imho, there is no better doc. than > > some > > well written code, so maybe someone familiar with the drivers can > > suggest > > one (or two) that they consider well written and use the current > > conventions > > as "examples"? > > we try every now and then to put good examples in /usr/share/examples > but I think what's there is hopelessly out of date. > Yep, that's the inevitable problem with this kind of doc. What I was suggesting was to list a couple of the current drivers in src/sys as good examples of "best practice" and hope they stay current, if they're in the kernel source tree and being used for current hardware. But, just a suggestion (and the "list" could/will get out of date someday), rick From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 22:55:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8752106564A for ; Wed, 3 Nov 2010 22:55:05 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDC78FC1C for ; Wed, 3 Nov 2010 22:55:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PDmER-0004NX-Nn for freebsd-current@freebsd.org; Wed, 03 Nov 2010 23:55:03 +0100 Received: from host71-40-static.74-81-b.business.telecomitalia.it ([81.74.40.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Nov 2010 23:55:03 +0100 Received: from lapo by host71-40-static.74-81-b.business.telecomitalia.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Nov 2010 23:55:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Lapo Luchini Date: Wed, 03 Nov 2010 23:00:22 +0100 Lines: 31 Message-ID: <4CD1DB76.8090708@lapo.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: host71-40-static.74-81-b.business.telecomitalia.it User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.15) Gecko/20101027 SeaMonkey/2.0.10 In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=C8F252FB; url=http://www.lapo.it/pgpkey.txt Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Web feeds for UPDATING files [and commits too] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 22:55:05 -0000 Alexander Kojevnikov wrote: > The site now features Atom feeds for the following files: > > * ports/UPDATING > * head/UPDATING > * stable/7/UPDATING > * stable/8/UPDATING > > Hope you find the feeds useful. Useful indeed! Also, this is probably a nice thread to point out that a commit log feed exists. It was made by ale@ many months ago but (as far as GoogleReader says) I think I'm the only user so far; these are the FeedBurner-cached entries (to avoid hitting ale@'s ADSL too much): src/ http://feeds.feedburner.com/FreeBSD-6-src http://feeds.feedburner.com/FreeBSD-7-src http://feeds.feedburner.com/FreeBSD-8-src http://feeds.feedburner.com/FreeBSD-HEAD-src ports/ http://feeds.feedburner.com/FreeBSD-ports -- Lapo Luchini - http://lapo.it/ “There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.†(Jeremy S. Anderson) From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 23:27:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06C4106566B for ; Wed, 3 Nov 2010 23:27:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 33A308FC13 for ; Wed, 3 Nov 2010 23:27:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAN+M0UyDaFvO/2dsb2JhbACDI583rxiRFYRTcwSKVQ X-IronPort-AV: E=Sophos;i="4.58,291,1286164800"; d="scan'208";a="99541892" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 03 Nov 2010 19:27:20 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BB754B3F35; Wed, 3 Nov 2010 19:27:20 -0400 (EDT) Date: Wed, 3 Nov 2010 19:27:20 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <1320759482.60041.1288826840754.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101101234001.GD1433@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_60040_1528688248.1288826840752" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 23:27:22 -0000 ------=_Part_60040_1528688248.1288826840752 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > I'm more interested in number of dropped frames. See below how to > extract that information. > I've attached the stats. I'm guessing that the Rx missed frames : 14792 is the culprit. This was for a read of a fairly large file via NFS over TCP, getting a read rate of about 450Kbytes/sec. (No DEVICE_POLLING option.) (with your patch applied) > > > (It almost looks like it only handles the first received packet, > > although > > it appears to be using a receive ring of 64 buffers.) > > > > No, re(4) uses 256 TX/RX buffers for RTL810xE controllers. > Oops, my mistake. At a quick glance, I had thought rl_type was set to 8139, but I now see it's 8169. Btw, I printed out the hwrev and its a RL_HWREV_8102EL_SPIN1, if that is of any use to you. > > Ok, here is patch. > http://people.freebsd.org/~yongari/re/re.intr.patch > > The patch has the following changes. > o 64bit DMA support for PCIe controllers. > o Hardware MAC statistics counter support. You can extract these > counters with "sysctl dev.re.0.stats=1". You can check the > output on console or dmesg. It seems extracting these counters > take a lot of time so I didn't try to accumulate the counters. > You can see how many frames are dropped from the output. I saw a > lot FAE(frame alignment errors) under high RX load and I can't > explain how this can happen. This may indicate PHY hardware is > poor or it may need DSP fixups. Realtek seems to maintain large > set of DSP fixups for each PHY revisions and re(4) does not > have the magic code at this moment. > o Overhaul MSI interrupt handler such that make it give fairness > to TX as well as serving RX. Because re(4) controllers do not > have interrupt moderation mechanism, naive interrupt handler can > generate more than 125k intrs/sec under high load. Fortunately, > Bill implemented TX interrupt moderation with a timer register > and it seems to work well on TX path. One drawback of the > approach is it will require extra timer register accesses in > fast path. There is no second timer register to use in RX path > so no RX interrupt moderation is done in driver such that it can > generate about 25k intrs/sec under high RX load. However, I > think most systems can handle that interrupt load. Note, this > feature is activated only when MSI is in use and DEVICE_POLLING > is not defined. > > >From my limited testing, it seems it works as expected. Would you > give it try and let me know how well it behaves with NFS? > Without DEVICE_POLLING it behaves just like the unpatched one. I'm going to look at the driver tomorrow and try some hacks on it, rick ------=_Part_60040_1528688248.1288826840752 Content-Type: text/plain; name=re.stats Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=re.stats cmUwIHN0YXRpc3RpY3M6DQpUcmFuc21pdCBnb29kIGZyYW1lcyA6IDEwMDk2Ng0KUmVjZWl2ZSBn b29kIGZyYW1lcyA6IDEzMzQ3MA0KVHggZXJyb3JzIDogMA0KUnggZXJyb3JzIDogMA0KUnggbWlz c2VkIGZyYW1lcyA6IDE0NzkyDQpSeCBmcmFtZSBhbGlnbm1lbnQgZXJycyA6IDANClR4IHNpbmds ZSBjb2xsaXNpb25zIDogMA0KVHggbXVsdGlwbGUgY29sbGlzaW9ucyA6IDANClJ4IHVuaWNhc3Qg ZnJhbWVzIDogMTMzNDYzDQpSeCBicm9hZGNhc3QgZnJhbWVzIDogMA0KUnggbXVsdGljYXN0IGZy YW1lcyA6IDcNClR4IGFib3J0cyA6IDANClR4IHVuZGVycnVucyA6IDANCg== ------=_Part_60040_1528688248.1288826840752-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 00:39:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73EA1106566C for ; Thu, 4 Nov 2010 00:39:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 426098FC0A for ; Thu, 4 Nov 2010 00:39:17 +0000 (UTC) Received: by pxi1 with SMTP id 1so76001pxi.13 for ; Wed, 03 Nov 2010 17:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=/ZI1owUWBO1y+Jv3AYgOKfH190iWiWvMifuM3+Ouijg=; b=JvVVGhJAkhyuFFQ6HP06zfVqRSyVot23qBbL4Id14+4tkTehFicrUKbq9AtTxeoyvP /PyzWIiEM8w9acHjWvlNmqPLZfObBBeR81+/eRw1YvqIqR88n9ZYfXj/P2n0IdHl4BjP hakMoh9nOR4Rf/PEgkjFEQ/Q/2w/iSY3hEHMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=RmZgrk85miLh0WoMef9UZnsXPf9W5ttRl1l5h8nhoAQNGtGVjxDHSo6Zex/yh5t7Xd rAMmZp3X7fr540XuknXxB4D2yDwnzw7xbTyCLqo2YM18JWg9o4M5nw7aUoW/7rj1hJEP wjXMHQCOU47k+dWFIgTF+8FujheM5ERvdZda4= Received: by 10.142.153.4 with SMTP id a4mr1031465wfe.240.1288831153574; Wed, 03 Nov 2010 17:39:13 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w22sm14482596wfd.7.2010.11.03.17.39.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 17:39:11 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 3 Nov 2010 17:39:06 -0700 From: Pyun YongHyeon Date: Wed, 3 Nov 2010 17:39:06 -0700 To: Rick Macklem Message-ID: <20101104003906.GC14740@michelle.cdnetworks.com> References: <20101101234001.GD1433@michelle.cdnetworks.com> <1320759482.60041.1288826840754.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1320759482.60041.1288826840754.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 00:39:17 -0000 On Wed, Nov 03, 2010 at 07:27:20PM -0400, Rick Macklem wrote: > > > > I'm more interested in number of dropped frames. See below how to > > extract that information. > > > > I've attached the stats. I'm guessing that the > Rx missed frames : 14792 > is the culprit. > Because that counter is 16bit it's also possible it wrapped multiple times. Could you verify that? > This was for a read of a fairly large file via NFS over TCP, > getting a read rate of about 450Kbytes/sec. (No DEVICE_POLLING option.) > (with your patch applied) > > > > > > (It almost looks like it only handles the first received packet, > > > although > > > it appears to be using a receive ring of 64 buffers.) > > > > > > > No, re(4) uses 256 TX/RX buffers for RTL810xE controllers. > > > > Oops, my mistake. At a quick glance, I had thought rl_type was > set to 8139, but I now see it's 8169. > > Btw, I printed out the hwrev and its a RL_HWREV_8102EL_SPIN1, > if that is of any use to you. > > > > > Ok, here is patch. > > http://people.freebsd.org/~yongari/re/re.intr.patch > > > > The patch has the following changes. > > o 64bit DMA support for PCIe controllers. > > o Hardware MAC statistics counter support. You can extract these > > counters with "sysctl dev.re.0.stats=1". You can check the > > output on console or dmesg. It seems extracting these counters > > take a lot of time so I didn't try to accumulate the counters. > > You can see how many frames are dropped from the output. I saw a > > lot FAE(frame alignment errors) under high RX load and I can't > > explain how this can happen. This may indicate PHY hardware is > > poor or it may need DSP fixups. Realtek seems to maintain large > > set of DSP fixups for each PHY revisions and re(4) does not > > have the magic code at this moment. > > o Overhaul MSI interrupt handler such that make it give fairness > > to TX as well as serving RX. Because re(4) controllers do not > > have interrupt moderation mechanism, naive interrupt handler can > > generate more than 125k intrs/sec under high load. Fortunately, > > Bill implemented TX interrupt moderation with a timer register > > and it seems to work well on TX path. One drawback of the > > approach is it will require extra timer register accesses in > > fast path. There is no second timer register to use in RX path > > so no RX interrupt moderation is done in driver such that it can > > generate about 25k intrs/sec under high RX load. However, I > > think most systems can handle that interrupt load. Note, this > > feature is activated only when MSI is in use and DEVICE_POLLING > > is not defined. > > > > >From my limited testing, it seems it works as expected. Would you > > give it try and let me know how well it behaves with NFS? > > > Without DEVICE_POLLING it behaves just like the unpatched one. > Hmm, that's strange. Are you sure you rebuilt kernel without polling option? Just disabling polling with ifconfig(8) has no effect to make patch work. > I'm going to look at the driver tomorrow and try some hacks on it, rick > re0 statistics: > Transmit good frames : 100966 > Receive good frames : 133470 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 14792 If the counter was not wrapped, it seem you lost more than 10% out of total RX frames. This is a lot loss and there should be a way to mitigate it. > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 133463 > Rx broadcast frames : 0 > Rx multicast frames : 7 > Tx aborts : 0 > Tx underruns : 0 From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 07:49:06 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33501065670; Thu, 4 Nov 2010 07:49:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B5D738FC21; Thu, 4 Nov 2010 07:49:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA21122; Thu, 04 Nov 2010 09:49:03 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PDuZD-000Dhk-1R; Thu, 04 Nov 2010 09:49:03 +0200 Message-ID: <4CD2656D.8050701@icyb.net.ua> Date: Thu, 04 Nov 2010 09:49:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: processes stuck on a vnode lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 07:49:06 -0000 I see a few processes stuck on the same vnode, trying to take or to upgrade to an exclusive lock on it, while the lock data suggests that it is already shared-locked. The vnode is a root vnode of one of ZFS filesystems (it's not a global root). I couldn't find any (other) threads that could actually hold the vnode lock, but lock shared count is suspiciously or coincidentally the same as number of threads in zfs_root call. Relevant data dump: 1125 100129 mountd - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_root lookup namei getfh syscallenter syscall Xfast_syscall 1135 100209 nfsd nfsd: service mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsrv_fhtovp nfsrv_readdirplus nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 39672 100779 find - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_root lookup namei vn_open_cred vn_open kern_openat kern_open open syscallenter syscall Xfast_syscall 61414 100769 smbd - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock cache_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei vn_open_cred vn_open kern_openat kern_open open syscallenter 61644 100525 smbd - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock cache_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei vn_open_cred vn_open kern_openat kern_open open syscallenter 61645 100504 smbd - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock cache_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei vn_open_cred vn_open kern_openat kern_open open syscallenter 61646 100822 smbd - mi_switch sleepq_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock cache_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei vn_open_cred vn_open kern_openat kern_open open syscallenter ====================================================================== (kgdb) tid 100779 [Switching to thread 521 (Thread 100779)]#0 sched_switch (td=0xffffff0051e59450, newtd=0xffffff0001a4c450, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1851 1851 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xffffff0051e59450, newtd=0xffffff0001a4c450, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1851 #1 0xffffffff8038631e in mi_switch (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_synch.c:449 #2 0xffffffff803bd87b in sleepq_switch (wchan=Variable "wchan" is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:538 #3 0xffffffff803be5a5 in sleepq_wait (wchan=0xffffff000a3e4098, pri=80) at /usr/src/sys/kern/subr_sleepqueue.c:617 #4 0xffffffff80362d62 in __lockmgr_args (lk=0xffffff000a3e4098, flags=524288, ilk=0xffffff000a3e40c8, wmesg=Variable "wmesg" is not available. ) at /usr/src/sys/kern/kern_lock.c:218 #5 0xffffffff804037f1 in vop_stdlock (ap=Variable "ap" is not available. ) at lockmgr.h:97 #6 0xffffffff805bd322 in VOP_LOCK1_APV (vop=0xffffffff807e2580, a=0xffffff8126ec05b0) at vnode_if.c:1988 #7 0xffffffff80422d98 in _vn_lock (vp=0xffffff000a3e4000, flags=524288, file=0xffffffff80b23c58 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c", line=1305) at vnode_if.h:859 #8 0xffffffff80abd185 in zfs_root (vfsp=Variable "vfsp" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1305 #9 0xffffffff80408323 in lookup (ndp=0xffffff8126ec09a0) at /usr/src/sys/kern/vfs_lookup.c:785 #10 0xffffffff80408f0f in namei (ndp=0xffffff8126ec09a0) at /usr/src/sys/kern/vfs_lookup.c:273 #11 0xffffffff80422120 in vn_open_cred (ndp=0xffffff8126ec09a0, flagp=0xffffff8126ec099c, cmode=2432, vn_open_flags=Variable "vn_open_flags" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:189 #12 0xffffffff804223cc in vn_open (ndp=Variable "ndp" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:95 #13 0xffffffff80420b9d in kern_openat (td=0xffffff0051e59450, fd=-100, path=0x800c61100 , pathseg=UIO_USERSPACE, flags=131077, mode=13052800) at /usr/src/sys/kern/vfs_syscalls.c:1083 #14 0xffffffff80420f19 in kern_open (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:1039 #15 0xffffffff80420f38 in open (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:1015 #16 0xffffffff803c0f8e in syscallenter (td=0xffffff0051e59450, sa=0xffffff8126ec0bb0) at /usr/src/sys/kern/subr_trap.c:318 #17 0xffffffff8055b5f1 in syscall (frame=0xffffff8126ec0c40) at /usr/src/sys/amd64/amd64/trap.c:939 #18 0xffffffff80546262 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #19 0x000000080073489c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 4 #4 0xffffffff80362d62 in __lockmgr_args (lk=0xffffff000a3e4098, flags=524288, ilk=0xffffff000a3e40c8, wmesg=Variable "wmesg" is not available. ) at /usr/src/sys/kern/kern_lock.c:218 218 sleepq_wait(&lk->lock_object, pri); (kgdb) p *lk $3 = {lock_object = {lo_name = 0xffffffff80b267b0 "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0x0}, lk_lock = 37, lk_exslpfail = 0, lk_timo = 51, lk_pri = 80} (kgdb) p/x lk->lk_lock $7 = 0x25 ===================================================================== (kgdb) p *dvp $8 = {v_type = VDIR, v_tag = 0xffffffff80b267b0 "zfs", v_op = 0xffffffff80b2c780, v_data = 0xffffff000a2c8840, v_mount = 0xffffff000a3e92f8, v_nmntvnodes = {tqe_next = 0xffffff000a3e3d20, tqe_prev = 0xffffff000a3e9358}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = { tqh_first = 0x0, tqh_last = 0xffffff000a3e4060}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = { lo_name = 0xffffffff80b267b0 "zfs", lo_flags = 91947008, lo_data = 0, lo_witness = 0x0}, lk_lock = 37, lk_exslpfail = 0, lk_timo = 51, lk_pri = 80}, v_interlock = {lock_object = {lo_name = 0xffffffff8064ecf9 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock = 0xffffff000a3e4098, v_holdcnt = 16, v_usecount = 16, v_iflag = 0, v_vflag = 1, v_writecount = 0, v_freelist = { tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff8064ed09 "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff000a3e4140}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff000a3e4160}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff807df2a0, bo_bsize = 131072, bo_object = 0xffffff0123507000, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff000a3e4000, __bo_vnode = 0xffffff000a3e4000}, v_pollinfo = 0xffffff00658778c0, v_label = 0x0, v_lockf = 0x0} -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 08:37:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DEE4106566C; Thu, 4 Nov 2010 08:37:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id BCC7D8FC0C; Thu, 4 Nov 2010 08:37:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=hbYBJcQZDcC0HrEwo7wA:9 a=rdHuChauiKYftlwAyukA:7 a=rp5_LUhrVUki9jaKdWBadY-w694A:4 a=PUjeQqilurYA:10 a=hc5yWR8y822bM0dV:21 a=_9LHc2Q8-2OudMNw:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44321807; Thu, 04 Nov 2010 09:37:13 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 09:38:25 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011011714.50121.jhb@freebsd.org> <201011020839.45839.hselasky@c2i.net> In-Reply-To: <201011020839.45839.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011040938.25094.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 08:37:17 -0000 On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote: > On Monday 01 November 2010 22:14:49 John Baldwin wrote: > > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > > Hi! > > > > > > I've wrapped up an outline patch for what needs to be done to integrate > > > the USB process framework into the kernel taskqueue system in a more > > > direct way that to wrap it. > > > > > > The limitation of the existing taskqueue system is that it only > > > guarantees execution at a given priority level. USB requires more. USB > > > also requires a guarantee that the last task queued task also gets > > > executed last. This is for example so that a deferred USB detach event > > > does not happen before any pending deferred I/O for example in case of > > > multiple occurring events. > > > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > > busses like the USB. Typical use case: > > > > > > 2 tasks to program GPIO on. > > > 2 tasks to program GPIO off. > > > > > > Example: > > > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > > > >sc_task_on[1]); > > > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > > > >sc_task_off[1]); > > > > > > No matter how the call ordering of code-line a) and b), we are always > > > guaranteed that the last queued state "on" or "off" is reached before > > > the head of the taskqueue empties. > > > > > > > > > In lack of a better name, the new function was called > > > taskqueue_enqueue_odd [some people obviously think that USB processes > > > are odd, but not taskqueues > > > > > > :-)] > > > > It feels like this should be something you could manage with a state > > machine internal to USB rather than forcing that state into the taskqueue > > code itself. > > Hi John, > > No, this is not possible without keeping my own queue, which I want to > avoid. By state-machine you mean remembering the last state as a separate > variable and checking that in the task-callback, right? Yes, I do that in > addition to the new queuing mechanism. > > A task barrier does not solve my problem. The barrier in my case is always > last in the queue. I need to pull out previously queued tasks and put them > last. That is currently not supported. I do this because I don't want to > have a FIFO signalling model, and a neither want the pure taskqueue, which > only ensures execution, not order of execution when at the same priority. > > Another issue: Won't the barrier model lead to blocking the caller once the > task in question is being issued the second time? > > --HPS > > > If you wanted a simple barrier task (where a barrier task is > > always queued at the tail of the list and all subsequent tasks are queued > > after the barrier task) then I would be fine with adding that. You > > could manage this without having to alter the task KBI by having the > > taskqueue maintain a separate pointer to the current "barrier" task and > > always enqueue entries after that task (the barrier would be NULL before > > a barrier is queued, and set to NULL when a barrier executes). > > > > I think this sort of semantic is a bit simpler and also used in other > > parts of the tree (e.g. in bio queues). > Any more comments on this matter or someone still doing review? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 06:05:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40726106566B; Thu, 4 Nov 2010 06:05:46 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1501A8FC1B; Thu, 4 Nov 2010 06:05:45 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id DDC2828F799; Thu, 4 Nov 2010 01:05:44 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 2cLMaW4cn6q0; Thu, 4 Nov 2010 01:05:44 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh6.mail.rice.edu (Postfix) with ESMTPSA id 5302C28F797; Thu, 4 Nov 2010 01:05:44 -0500 (CDT) Message-ID: <4CD24D37.5060701@rice.edu> Date: Thu, 04 Nov 2010 01:05:43 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1B02E.2070708@freebsd.org> In-Reply-To: <4CD1B02E.2070708@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 04 Nov 2010 09:04:48 +0000 Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 06:05:46 -0000 Andriy Gapon wrote: > on 03/11/2010 20:44 Alan Cox said the following: > [snip] > > Thank you for the confirmation! > > >> Andriy Gapon wrote: >> >>> P.S. is there a macro for extracting frame address from PDPE? >>> >> To a lower level page table page or to a 1GB physical page? For the latter, you >> can use PG_PS_FRAME. >> > > To a 1GB page. > I see in the architecture manual that the lower bits are marked as MBZ, so this > macro should work. Actually, it seems that even PG_FRAME should work in place of > PG_PS_FRAME for exactly the same reason (MBZ) on amd64. > There is actually a point to using PG_PS_FRAME. The PAT bit for a 2MB page mapping occupies a bit that is a part of the physical page number with PG_FRAME. I suspect that the same is true of 1GB page mappings, but I haven't double checked the manual. Alan From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 08:57:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 249811065673; Thu, 4 Nov 2010 08:57:01 +0000 (UTC) (envelope-from simonln@me.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id F39858FC13; Thu, 4 Nov 2010 08:57:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.6.2.126] (fr.ffw.spectronic-systems.com [90.184.203.251]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LBC00ENHRI5ZA00@asmtp024.mac.com>; Thu, 04 Nov 2010 01:56:32 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-04_04:2010-11-04, 2010-11-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1011040035 From: "Simon L. B. Nielsen" Date: Thu, 04 Nov 2010 09:55:28 +0100 To: freebsd-stable@freebsd.org, freebsd-current Message-id: X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 04 Nov 2010 09:04:55 +0000 Cc: Subject: svn2cvs replication down for the moment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 08:57:01 -0000 Hey, The FreeBSD svn2cvs exporter is currently down and won't be fixed until tonight CET at the earliest. This basically mean that until that is fixed, any change in svn (IE, src/) won't be available via CVS or CVSup. A change yesterday morning "replaced" an entire directory, which svn2cvs don't know how to deal with. As it's an entire directory I can't just use our usual hack and ignore the delete part as that will leave files in the directory in CVS which wasn't supposed to be there. As that not a quick thing to do I won't be able to fix it before getting home from work. -- Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 11:07:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D453106564A; Thu, 4 Nov 2010 11:07:39 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6480D8FC0C; Thu, 4 Nov 2010 11:07:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA24402; Thu, 04 Nov 2010 13:07:30 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD293F1.8040000@freebsd.org> Date: Thu, 04 Nov 2010 13:07:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> <4CD1AA45.7000504@freebsd.org> <4CD1AD80.2090903@rice.edu> <4CD1B02E.2070708@freebsd.org> <4CD24D37.5060701@rice.edu> In-Reply-To: <4CD24D37.5060701@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 11:07:39 -0000 on 04/11/2010 08:05 Alan Cox said the following: > > There is actually a point to using PG_PS_FRAME. The PAT bit for a 2MB page > mapping occupies a bit that is a part of the physical page number with PG_FRAME. > I suspect that the same is true of 1GB page mappings, but I haven't double checked > the manual. Ah, yes, you are right - bit 12 is a part of an address in PTE, but is used for PAT in PDE or PDPE if PS bit is 1. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 11:08:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D404F1065674 for ; Thu, 4 Nov 2010 11:08:56 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 93A718FC17 for ; Thu, 4 Nov 2010 11:08:56 +0000 (UTC) Received: from 37-148-132-95.pool.ukrtel.net ([95.132.148.37] helo=localhost) by fsm1.ukr.net with esmtps ID 1PDxJE-000DkY-PW for current@freebsd.org; Thu, 04 Nov 2010 12:44:45 +0200 Date: Thu, 4 Nov 2010 12:44:43 +0200 From: Ivan Klymenko To: current@freebsd.org Message-ID: <20101104124443.40b743bf@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 11:08:56 -0000 Hello, people! After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does not build world: ... ===> usr.sbin/wpa/wpa_passphrase (depend) rm -f .depend mkdep -f .depend -a -I/usr/src/usr.sbin/wpa/wpa_passphrase -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DINTERNAL_SHA1 -DINTERNAL_MD5 -I/usr/src/usr.sbin/wpa/wpa_passphrase -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//wpa_supplicant/wpa_passphrase.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-internal.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-pbkdf2.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c echo wpa_passphrase: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/wpa/hostapd (depend) make: don't know how to make config_file.c. Stop *** Error code 2 1 error *** Error code 2 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 12:14:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09BC1065674 for ; Thu, 4 Nov 2010 12:14:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 80A9B8FC0A for ; Thu, 4 Nov 2010 12:14:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACtA0kyDaFvO/2dsb2JhbACDJ5BIjnWreZBzgSKDMXMEilU X-IronPort-AV: E=Sophos;i="4.58,295,1286164800"; d="scan'208";a="99584547" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 04 Nov 2010 08:14:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id AACD1B3F48; Thu, 4 Nov 2010 08:14:49 -0400 (EDT) Date: Thu, 4 Nov 2010 08:14:49 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <29635212.74044.1288872889645.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101104003906.GC14740@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 12:14:50 -0000 > On Wed, Nov 03, 2010 at 07:27:20PM -0400, Rick Macklem wrote: > > > > > > I'm more interested in number of dropped frames. See below how to > > > extract that information. > > > > > > > I've attached the stats. I'm guessing that the > > Rx missed frames : 14792 > > is the culprit. > > > > Because that counter is 16bit it's also possible it wrapped > multiple times. Could you verify that? > Ill look, but since the test was run just after booting the machine, if it wrapped it would mean that it dropped even more packets, I think? > > > > > > >From my limited testing, it seems it works as expected. Would you > > > give it try and let me know how well it behaves with NFS? > > > > > Without DEVICE_POLLING it behaves just like the unpatched one. > > > > Hmm, that's strange. Are you sure you rebuilt kernel without polling > option? Just disabling polling with ifconfig(8) has no effect to > make patch work. > Yep. I have two kernel configs and I rebuilt/installed using the one that doesn't have DEVICE_POLLING. (Also, I would have seen about 9Mbytes/sec read rate if I was using the one that has DEVICE_POLLING.) > > If the counter was not wrapped, it seem you lost more than 10% out of > total RX frames. This is a lot loss and there should be a way to > mitigate it. > Agreed. There is definitely an issue for at least this variant of the chip. Is it fair to assume that, since the chip reports the missed packets, that it thinks that it doesn't have a usable receive buffer at the time the packet is received? (I'm thinking that it couldn't have used up 256 receive buffers when the first drop happens, since I see it early in the tcpdump I took before, so maybe something related to handling of the receive ring? As I said, I'll play with it later to-day and let you know if I learn something more.) rick From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 13:55:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B482A1065679; Thu, 4 Nov 2010 13:55:12 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD15E8FC12; Thu, 4 Nov 2010 13:55:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1442199iwn.13 for ; Thu, 04 Nov 2010 06:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rc6Kf9M4JbqxPQwsiLamXqjZv7hw7qPAbMGIlSL8Prc=; b=lhInRB7GhpdX3uDnyYrOVphBArMV2tL/Uyd60gDHexCc0bXEUPLArOOZgiPRa1Tw/Z OL6h6Vh4BK82OvnMVa2HnpY65OizkAZw9OAxbugup/eNIGmBj43kVwUV4tejVGwL7xjk ttInqLtFa5GrjknG6B8g9TvE0Bb5E9pB8RikA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=is+GRIxG7FlicA8x+7DoC0R9Po5VylH8eu3ln0WTPSFoslwaXPNqJm9he0jJ8/8okT ABuI7NcHTSztRM6vRgUI9YFBWEs7OKjjNKuZCkxzJyFKl1l/SOgiEJLznrln8f+rusZ7 HoR+lUKhuu3qSw++keX/shCIhz7yvui16KNNI= MIME-Version: 1.0 Received: by 10.231.33.203 with SMTP id i11mr490075ibd.8.1288878909370; Thu, 04 Nov 2010 06:55:09 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 06:55:09 -0700 (PDT) In-Reply-To: <201011012115.15261.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> Date: Thu, 4 Nov 2010 06:55:09 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 13:55:12 -0000 On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrot= e: > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > wrote: >> > Hi! >> > >> > I've wrapped up an outline patch for what needs to be done to integrat= e >> > the USB process framework into the kernel taskqueue system in a more >> > direct way that to wrap it. >> > >> > The limitation of the existing taskqueue system is that it only >> > guarantees execution at a given priority level. USB requires more. USB >> > also requires a guarantee that the last task queued task also gets >> > executed last. This is for example so that a deferred USB detach event >> > does not happen before any pending deferred I/O for example in case of >> > multiple occurring events. >> > >> > Mostly this new feature is targeted for GPIO-alike system using slow >> > busses like the USB. Typical use case: >> > >> > 2 tasks to program GPIO on. >> > 2 tasks to program GPIO off. >> > >> > Example: >> > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >> > >> >>sc_task_on[1]); >> >> >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >> > >> >>sc_task_off[1]); >> >> >> > No matter how the call ordering of code-line a) and b), we are always >> > guaranteed that the last queued state "on" or "off" is reached before = the >> > head of the taskqueue empties. >> > >> > >> > In lack of a better name, the new function was called >> > taskqueue_enqueue_odd [some people obviously think that USB processes >> > are odd, but not taskqueues >> > >> > :-)] >> >> I'd like to make sure I understand the USB requirements. >> >> (1) does USB need the task priority field? =A0Many taskqueue(9) consumer= s do >> not. > > No, USB does not need a task priority field, but a sequence field associa= ted > with the task and task queue head to figure out which task was queued fir= st > without having to scan all the tasks queued. > >> (2) if there was a working taskqueue_remove(9) that removed the task >> if pending or returned error if the task was currently running, would >> that be sufficient to implement the required USB functionality? >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority >> in order of queueing). > > No, not completely. See comment above. I also need information about whic= h > task was queued first, or else I have to keep this information separately= , > which again, confuse people. The more layers the more confusion? I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 14:45:29 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3DEC106564A; Thu, 4 Nov 2010 14:45:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CCD3E8FC1A; Thu, 4 Nov 2010 14:45:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27911; Thu, 04 Nov 2010 16:45:26 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD2C706.6000100@icyb.net.ua> Date: Thu, 04 Nov 2010 16:45:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <4CD2656D.8050701@icyb.net.ua> In-Reply-To: <4CD2656D.8050701@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: processes stuck on a vnode lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 14:45:29 -0000 on 04/11/2010 09:49 Andriy Gapon said the following: > > I see a few processes stuck on the same vnode, trying to take or to upgrade to > an exclusive lock on it, while the lock data suggests that it is already > shared-locked. The vnode is a root vnode of one of ZFS filesystems (it's not a > global root). > > I couldn't find any (other) threads that could actually hold the vnode lock, but > lock shared count is suspiciously or coincidentally the same as number of > threads in zfs_root call. BTW, I still have the system alive and online, so if anyone has ideas I can try them. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 14:53:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EFFD106566B for ; Thu, 4 Nov 2010 14:53:20 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7F68FC17 for ; Thu, 4 Nov 2010 14:53:19 +0000 (UTC) Received: from 37-148-132-95.pool.ukrtel.net ([95.132.148.37] helo=localhost) by fsm1.ukr.net with esmtps ID 1PE1Bm-000L30-5L for freebsd-current@FreeBSD.ORG; Thu, 04 Nov 2010 16:53:18 +0200 Date: Thu, 4 Nov 2010 16:53:16 +0200 From: Ivan Klymenko To: freebsd-current@FreeBSD.ORG Message-ID: <20101104165316.0c0d4579@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 14:53:20 -0000 Hello, people! After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does not build world: ... ===> usr.sbin/wpa/wpa_passphrase (depend) rm -f .depend mkdep -f .depend -a -I/usr/src/usr.sbin/wpa/wpa_passphrase -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DINTERNAL_SHA1 -DINTERNAL_MD5 -I/usr/src/usr.sbin/wpa/wpa_passphrase -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//wpa_supplicant/wpa_passphrase.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-internal.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-pbkdf2.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5.c /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c echo wpa_passphrase: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend ===> usr.sbin/wpa/hostapd (depend) make: don't know how to make config_file.c. Stop *** Error code 2 1 error *** Error code 2 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 15:08:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F72E106564A for ; Thu, 4 Nov 2010 15:08:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 09ADA8FC13 for ; Thu, 4 Nov 2010 15:08:19 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA4EvoYe016403; Thu, 4 Nov 2010 07:57:50 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA4EvoTw016402; Thu, 4 Nov 2010 07:57:50 -0700 (PDT) (envelope-from david) Date: Thu, 4 Nov 2010 07:57:50 -0700 From: David Wolfskill To: Ivan Klymenko Message-ID: <20101104145750.GT1980@albert.catwhisker.org> References: <20101104165316.0c0d4579@ukr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jZNlLGxhPb4urluq" Content-Disposition: inline In-Reply-To: <20101104165316.0c0d4579@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 15:08:20 -0000 --jZNlLGxhPb4urluq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: > Hello, people! > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does not > build world: ... > .... I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to r214777. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --jZNlLGxhPb4urluq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzSyewACgkQmprOCmdXAD2D1ACdGMY/0xzWgl9sD0/NBXlSQpEz y/EAn3Qrz//Om+y+7aIFatn9XNIZbQiA =DMZI -----END PGP SIGNATURE----- --jZNlLGxhPb4urluq-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 15:08:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D81761065672; Thu, 4 Nov 2010 15:08:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC16; Thu, 4 Nov 2010 15:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=eBBTKOCzzS4ddj3yubgA:9 a=UVoTL3aoASoHr0WDeJkA:7 a=nXYsBsMJQ5gLzLLRCrZL-R1_Wg0A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44175068; Thu, 04 Nov 2010 16:08:49 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 16:10:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041610.00736.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 15:08:53 -0000 On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > > > > wrote: > >> > Hi! > >> > > >> > I've wrapped up an outline patch for what needs to be done to > >> > integrate the USB process framework into the kernel taskqueue system > >> > in a more direct way that to wrap it. > >> > > >> > The limitation of the existing taskqueue system is that it only > >> > guarantees execution at a given priority level. USB requires more. USB > >> > also requires a guarantee that the last task queued task also gets > >> > executed last. This is for example so that a deferred USB detach event > >> > does not happen before any pending deferred I/O for example in case of > >> > multiple occurring events. > >> > > >> > Mostly this new feature is targeted for GPIO-alike system using slow > >> > busses like the USB. Typical use case: > >> > > >> > 2 tasks to program GPIO on. > >> > 2 tasks to program GPIO off. > >> > > >> > Example: > >> > > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >> > > >> >>sc_task_on[1]); > >> >> > >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >> > > >> >>sc_task_off[1]); > >> >> > >> > No matter how the call ordering of code-line a) and b), we are always > >> > guaranteed that the last queued state "on" or "off" is reached before > >> > the head of the taskqueue empties. > >> > > >> > > >> > In lack of a better name, the new function was called > >> > taskqueue_enqueue_odd [some people obviously think that USB processes > >> > are odd, but not taskqueues > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers > >> do not. > > > > No, USB does not need a task priority field, but a sequence field > > associated with the task and task queue head to figure out which task > > was queued first without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about > > which task was queued first, or else I have to keep this information > > separately, which again, confuse people. The more layers the more > > confusion? Hi, > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. Probably I can check which task is pending when I queue them and store that in a separate variable. Still I need a way to remove a task from the queue, which becomes very slow due to the fact that STAILQ() is used. > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. That is right, if there is a way to remove a task from a queue without draining. > It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. The only reason I want to break the KBI is because it is slow to remove a task from the taskqueue using STAILQ's when you don't know the previous task- element in the queue. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 15:15:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7491065693 for ; Thu, 4 Nov 2010 15:15:48 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 186458FC0A for ; Thu, 4 Nov 2010 15:15:47 +0000 (UTC) Received: from 37-148-132-95.pool.ukrtel.net ([95.132.148.37] helo=localhost) by fsm1.ukr.net with esmtps ID 1PE1XV-0001Bl-MX ; Thu, 04 Nov 2010 17:15:45 +0200 Date: Thu, 4 Nov 2010 17:15:43 +0200 From: Ivan Klymenko To: David Wolfskill Message-ID: <20101104171543.4007aa6a@ukr.net> In-Reply-To: <20101104145750.GT1980@albert.catwhisker.org> References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 15:15:48 -0000 =D0=92 Thu, 4 Nov 2010 07:57:50 -0700 David Wolfskill =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: > > Hello, people! > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does > > not build world: ... > > .... >=20 > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to > r214777. >=20 > Peace, > david Do you use when building make option -j? I'm using -j 3 From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 16:11:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DD4B106566B for ; Thu, 4 Nov 2010 16:11:57 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id ED9498FC14 for ; Thu, 4 Nov 2010 16:11:56 +0000 (UTC) Received: from 37-148-132-95.pool.ukrtel.net ([95.132.148.37] helo=localhost) by fsm1.ukr.net with esmtps ID 1PE2Pr-000FHd-CJ ; Thu, 04 Nov 2010 18:11:55 +0200 Date: Thu, 4 Nov 2010 18:11:54 +0200 From: Ivan Klymenko To: ticso@cicely.de Message-ID: <20101104181154.20db9164@ukr.net> In-Reply-To: <20101104160720.GQ23848@cicely7.cicely.de> References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> <20101104160720.GQ23848@cicely7.cicely.de> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ticso@cicely7.cicely.de, freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 16:11:57 -0000 =D0=92 Thu, 4 Nov 2010 17:07:20 +0100 Bernd Walter =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: > > ?? Thu, 4 Nov 2010 07:57:50 -0700 > > David Wolfskill ??????????: > >=20 > > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: > > > > Hello, people! > > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 > > > > does not build world: ... > > > > .... > > >=20 > > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to > > > r214777. > > >=20 > > > Peace, > > > david > >=20 > > Do you use when building make option -j? > >=20 > > I'm using -j 3 >=20 > You likely have stall dependencies in /usr/obj. >=20 How can I fix it? From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 16:19:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4361106566C for ; Thu, 4 Nov 2010 16:19:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 699E78FC16 for ; Thu, 4 Nov 2010 16:19:03 +0000 (UTC) Received: by gxk9 with SMTP id 9so1580876gxk.13 for ; Thu, 04 Nov 2010 09:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=klhpOl/92NJ6kTMCa/FxtscHNHQAsZEgqVOqgmaMNOk=; b=PmNuvFAsYtymEizq9hO+VfOax0hKUg+wi/268f911QfDWlxFkspVVWxbb5HBlojN4s SIEv9gXYf6XlWQkAMKMkS71p3Vw9Bfz2junOI97T+4a8gt3GqdtuFh/plrPc8SaBNmqn OlJi8v4RkpAKs2ArITumvu3oksJiN0FXDmW24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XZvXlLBs1As1XbCAY8U2QT80RQR4yEuErjsf2Z9bWt5V9NDCxor1bl2+UtXpXBqrqq m6gHvYFURMFWqJ42NGBA9oWiO3rkWTwbZBcZCqxvFLBg6tRLg5W6OfoEDXtf6afZTf0s lYBnxLaq4YdtPsuT6vG0EFJCMYQ4xKrhpFi+g= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr45776web.45.1288887542076; Thu, 04 Nov 2010 09:19:02 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Thu, 4 Nov 2010 09:19:01 -0700 (PDT) In-Reply-To: <20101104181154.20db9164@ukr.net> References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> <20101104160720.GQ23848@cicely7.cicely.de> <20101104181154.20db9164@ukr.net> Date: Thu, 4 Nov 2010 09:19:01 -0700 X-Google-Sender-Auth: x03ulyArh7j7gTCPLKQkHjyMmq8 Message-ID: From: Garrett Cooper To: Ivan Klymenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ticso@cicely7.cicely.de, ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 16:19:03 -0000 On Thu, Nov 4, 2010 at 9:11 AM, Ivan Klymenko wrote: > =D0=92 Thu, 4 Nov 2010 17:07:20 +0100 > Bernd Walter =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: >> > ?? Thu, 4 Nov 2010 07:57:50 -0700 >> > David Wolfskill ??????????: >> > >> > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: >> > > > Hello, people! >> > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 >> > > > does not build world: ... >> > > > .... >> > > >> > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to >> > > r214777. >> > > >> > > Peace, >> > > david >> > >> > Do you use when building make option -j? >> > >> > I'm using -j 3 >> >> You likely have stall dependencies in /usr/obj. >> > > How can I fix it? rm -Rf /usr/obj/* From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 16:28:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BE41065672 for ; Thu, 4 Nov 2010 16:28:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9DF8FC28 for ; Thu, 4 Nov 2010 16:28:46 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id oA4G7fXV077790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Nov 2010 17:07:41 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id oA4G7Lj2038080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Nov 2010 17:07:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id oA4G7L3x031285; Thu, 4 Nov 2010 17:07:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id oA4G7Kvb031284; Thu, 4 Nov 2010 17:07:20 +0100 (CET) (envelope-from ticso) Date: Thu, 4 Nov 2010 17:07:20 +0100 From: Bernd Walter To: Ivan Klymenko Message-ID: <20101104160720.GQ23848@cicely7.cicely.de> References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101104171543.4007aa6a@ukr.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 16:28:47 -0000 On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: > ?? Thu, 4 Nov 2010 07:57:50 -0700 > David Wolfskill ??????????: > > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: > > > Hello, people! > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does > > > not build world: ... > > > .... > > > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to > > r214777. > > > > Peace, > > david > > Do you use when building make option -j? > > I'm using -j 3 You likely have stall dependencies in /usr/obj. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 16:31:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37DF31065672 for ; Thu, 4 Nov 2010 16:31:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B77C08FC1A for ; Thu, 4 Nov 2010 16:31:02 +0000 (UTC) Received: by ewy28 with SMTP id 28so1122394ewy.13 for ; Thu, 04 Nov 2010 09:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=w94CgC+T62D1IytNLbY7Sf1IFU41R7z/MoOG2tc5Z6M=; b=uiiae48Ip7UTFazvWpDNDOxculnIT/xIJKDckQNDwVo3tQwkG/DPofcZ1C9jFF7sF5 Xji95N6Gda6LJh6ydcQUAuL9TlaoVxshUif9+tkJG735o48mKPkPG6X+GudFghyx1pPL OBnnzwYkAZRrTg8AmHwKb64h1eUQZ+CAg6upY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oAh4iSGBrnObdFlx9NnpEBeLE4GK8tC6vFciwZyQaM95oK+/ev3guXPbgKKKKxOmeH 9267bn6EUa+5AR34V6rEDr1HqNzSSgTDxNlwpiQk/3UKXzOoAUP+tA9yACr2KV8tLTR3 Q3ckIj3DoWlSKIYdRiPKLGH5SJ0W+Nt9RPmnI= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr59768web.45.1288888259878; Thu, 04 Nov 2010 09:30:59 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Thu, 4 Nov 2010 09:30:59 -0700 (PDT) In-Reply-To: References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> <20101104160720.GQ23848@cicely7.cicely.de> <20101104181154.20db9164@ukr.net> Date: Thu, 4 Nov 2010 09:30:59 -0700 X-Google-Sender-Auth: lYuvDCxGPbYe-WB2zgt_N2qlZsg Message-ID: From: Garrett Cooper To: Ivan Klymenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ticso@cicely7.cicely.de, ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 16:31:03 -0000 On Thu, Nov 4, 2010 at 9:19 AM, Garrett Cooper wrote: > On Thu, Nov 4, 2010 at 9:11 AM, Ivan Klymenko wrote: >> =D0=92 Thu, 4 Nov 2010 17:07:20 +0100 >> Bernd Walter =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: >>> > ?? Thu, 4 Nov 2010 07:57:50 -0700 >>> > David Wolfskill ??????????: >>> > >>> > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: >>> > > > Hello, people! >>> > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 >>> > > > does not build world: ... >>> > > > .... >>> > > >>> > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to >>> > > r214777. >>> > > >>> > > Peace, >>> > > david >>> > >>> > Do you use when building make option -j? >>> > >>> > I'm using -j 3 >>> >>> You likely have stall dependencies in /usr/obj. >>> >> >> How can I fix it? > > rm -Rf /usr/obj/* BTW, this *should* be the case IIRC unless you specified NO_CLEAN=3D somewhere in src.conf, make.conf, any file they include, or on the command line. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 16:38:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5157106564A for ; Thu, 4 Nov 2010 16:38:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id BF69D8FC14 for ; Thu, 4 Nov 2010 16:38:55 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id oA4GctkH016971; Thu, 4 Nov 2010 09:38:55 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id oA4GctCs016970; Thu, 4 Nov 2010 09:38:55 -0700 (PDT) (envelope-from david) Date: Thu, 4 Nov 2010 09:38:54 -0700 From: David Wolfskill To: Ivan Klymenko Message-ID: <20101104163854.GU1980@albert.catwhisker.org> References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yIMHf/Pa6CzSkARF" Content-Disposition: inline In-Reply-To: <20101104171543.4007aa6a@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 16:38:56 -0000 --yIMHf/Pa6CzSkARF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: > ... > Do you use when building make option -j? >=20 > I'm using -j 3 I used -j 4. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yIMHf/Pa6CzSkARF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzS4Z4ACgkQmprOCmdXAD3Z6ACeIVe4Vjc6+adIsqHzXOZA7B9q Cb8AmgLOx7LNE4dnjNOwzXV7T+AIpo/l =E75y -----END PGP SIGNATURE----- --yIMHf/Pa6CzSkARF-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 18:00:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785B71065697; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 437AA8FC13; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CBBF946B5B; Thu, 4 Nov 2010 14:00:33 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD7D78A009; Thu, 4 Nov 2010 14:00:32 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 10:29:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041029.51864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 14:00:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:00:34 -0000 On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > > wrote: > >> > Hi! > >> > > >> > I've wrapped up an outline patch for what needs to be done to integrate > >> > the USB process framework into the kernel taskqueue system in a more > >> > direct way that to wrap it. > >> > > >> > The limitation of the existing taskqueue system is that it only > >> > guarantees execution at a given priority level. USB requires more. USB > >> > also requires a guarantee that the last task queued task also gets > >> > executed last. This is for example so that a deferred USB detach event > >> > does not happen before any pending deferred I/O for example in case of > >> > multiple occurring events. > >> > > >> > Mostly this new feature is targeted for GPIO-alike system using slow > >> > busses like the USB. Typical use case: > >> > > >> > 2 tasks to program GPIO on. > >> > 2 tasks to program GPIO off. > >> > > >> > Example: > >> > > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >> > > >> >>sc_task_on[1]); > >> >> > >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >> > > >> >>sc_task_off[1]); > >> >> > >> > No matter how the call ordering of code-line a) and b), we are always > >> > guaranteed that the last queued state "on" or "off" is reached before the > >> > head of the taskqueue empties. > >> > > >> > > >> > In lack of a better name, the new function was called > >> > taskqueue_enqueue_odd [some people obviously think that USB processes > >> > are odd, but not taskqueues > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers do > >> not. > > > > No, USB does not need a task priority field, but a sequence field associated > > with the task and task queue head to figure out which task was queued first > > without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about which > > task was queued first, or else I have to keep this information separately, > > which again, confuse people. The more layers the more confusion? > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. > > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. My sense is that I certainly agree. The fact that you can't think of a good name for the operation certainly indicates that it is not generic. Unfortunately, I don't really understand the problem that is being solved. I do agree that due to the 'pending' feature and automatic-coalescing of task enqueue operations, taskqueues do not lend themselves to a barrier operation. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 18:40:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8690E1065675; Thu, 4 Nov 2010 18:40:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 476438FC18; Thu, 4 Nov 2010 18:40:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=iww12FFwlFl3aLusVMYA:9 a=G2MUKtwv3xM2W6zJlr3T7OYMlNgA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44269867; Thu, 04 Nov 2010 19:40:00 +0100 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Nov 2010 19:41:09 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> In-Reply-To: <201011041029.51864.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041941.09662.hselasky@c2i.net> Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:40:02 -0000 On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 18:41:09 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39F41065697 for ; Thu, 4 Nov 2010 18:41:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 46C458FC20 for ; Thu, 4 Nov 2010 18:41:08 +0000 (UTC) Received: (qmail 1106 invoked by uid 399); 4 Nov 2010 18:41:08 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Nov 2010 18:41:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CD2FE43.7060709@FreeBSD.org> Date: Thu, 04 Nov 2010 11:41:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:41:09 -0000 Howdy, Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, with the following device: hdac0: mem 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: HDA Codec #0: Analog Devices AD1984A pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 There's 2 problems. When I plug the headphones in there are sounds, sometimes a low-level sound like a tea kettle whistling, and sometimes a louder screeching sound. The other problem is that the front headphone jack doesn't work. The rear one works, but this is less than convenient. :) Windows and ubuntu linux do not have either problem with the same hardware. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 18:46:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513E7106564A; Thu, 4 Nov 2010 18:46:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA2E18FC14; Thu, 4 Nov 2010 18:46:12 +0000 (UTC) Received: by ewy28 with SMTP id 28so1253400ewy.13 for ; Thu, 04 Nov 2010 11:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SofXjVx2xJb3MqNLDHCtJUNgnfR3DhRt6/eSNbi3nHg=; b=dP6RNLJIAO1ET7cYhZfOoCfPwk5CnWW0jRIIasbMN3Oowc7u/v45mkNaQpVRM++7hQ W00C2slqQiiLVWCuigjjvyeKBWE9yDqVnsBORTKlEGJxEFxOto4mPKsJfLxrI9pQyq/H 6g2IrpBbXYQS4UVhMmTsX0+HXul+TJukWnzCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RF7/xUuMhbcRTACR7dQU0L3k7YWVgMPgz9yy4Wqz7KKvejvTtypEHF9GNBsTF0HfnO 1wX/9nLITMt1kVR4z5wD3jsXZEXZbNIxEbgCxmW7yDBPzc+/09FUm3kIWvS5Y5Xedu8U 3GuDlfxoGcX3joLfd2RYnVvX8lKPd1VdUy7+Q= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr213970web.45.1288896371148; Thu, 04 Nov 2010 11:46:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Thu, 4 Nov 2010 11:46:11 -0700 (PDT) In-Reply-To: <4CD2FE43.7060709@FreeBSD.org> References: <4CD2FE43.7060709@FreeBSD.org> Date: Thu, 4 Nov 2010 11:46:11 -0700 X-Google-Sender-Auth: frL_1QFkhlqdmRd6ayod2tsvHKQ Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:46:14 -0000 On Thu, Nov 4, 2010 at 11:41 AM, Doug Barton wrote: > Howdy, > > Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, w= ith > the following device: > > hdac0: mem > 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: HDA Codec #0: Analog Devices AD1984A > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > > There's 2 problems. When I plug the headphones in there are sounds, > sometimes a low-level sound like a tea kettle whistling, and sometimes a > louder screeching sound. The other problem is that the front headphone ja= ck > doesn't work. The rear one works, but this is less than convenient. :) > =A0Windows and ubuntu linux do not have either problem with the same hard= ware. Can you try with 7.x to see if there's a similar problem? I ask this because similar symptoms might exist with snd_emu10kx as another person and I have hashed over in another thread. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:02:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E3A106564A; Thu, 4 Nov 2010 19:02:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6778FC08; Thu, 4 Nov 2010 19:01:59 +0000 (UTC) Received: by ywh2 with SMTP id 2so1768476ywh.13 for ; Thu, 04 Nov 2010 12:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I1HBTmal4wdj7RoHcpK5ZAj42DF8gXyVmwLeiE2VbIg=; b=GQKlLEbUB+NgCPMZ8Sh3T1JaNUKdIdsBeAdRgeiixFoTHCPaOAilAoxFXIJIJwBNGS xISQXfnZgWh8Wpe5NYtrnNcyxL5+wduOohtvnZljsgjn/4z/OR8ZHXIXWQ3QUSwWFhDL 9EzEK6wfPqwJGuGpFwSHNy37uKGqa9eL0+xW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oElfcZT08ZfGcR0F3YxBLm5qIlWQ0b8xnZo4wi1DTHgglfJUyDZ4LUDE5pa+UlHpGG NQKkhF2l7TvTmzvckiYVyXnZ5Otb2ToXBJ647/yN1QL1AUXkay9uSoUDVl1Wd+suGeXs 30sT0OF9PcBxmM33I16NnvDVGUmzO+wN+VP9E= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr657740icn.343.1288897317938; Thu, 04 Nov 2010 12:01:57 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 12:01:57 -0700 (PDT) In-Reply-To: <201011041941.09662.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> <201011041941.09662.hselasky@c2i.net> Date: Thu, 4 Nov 2010 12:01:57 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:02:00 -0000 On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> =A0(and there is in Jeff's OFED branch) > > Is there a link to this branch? I would certainly have a look at his work= and > re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque= ue.c?view=3Dlog http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:07:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDCA106566B; Thu, 4 Nov 2010 19:07:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE618FC08; Thu, 4 Nov 2010 19:07:39 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=qRdCxWWPLfbE3fxGEroA:9 a=UEHWcmcm-zK5qilDy1FloXSCRVoA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45408163; Thu, 04 Nov 2010 20:07:38 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:08:47 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042008.47703.hselasky@c2i.net> Cc: Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:07:41 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) Hi, In my case we are talking about 10-15 tasks at maximum. But still (10*9) / 2 = 45 iterations is much more than 2 steps to do the unlink. Anyway. I will have a look at your work and suggest a new patch for my needs. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:10:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99ABF106566C; Thu, 4 Nov 2010 19:10:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 618C08FC12; Thu, 4 Nov 2010 19:10:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=qVhn0TDvtfzDoSz3N8YA:9 a=8QUpVPaYN4w5MPYWOUqInMW9KUQA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45409098; Thu, 04 Nov 2010 20:10:35 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:11:44 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042011.44705.hselasky@c2i.net> Cc: Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:10:37 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> (and there is in Jeff's OFED branch) > > > > Is there a link to this branch? I would certainly have a look at his work > > and re-base my patch. > > It's on svn.freebsd.org: > > http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque > ue.c?view=log > http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) > > Thanks, > matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:32:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECBBB106564A for ; Thu, 4 Nov 2010 19:32:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 84C338FC0C for ; Thu, 4 Nov 2010 19:32:45 +0000 (UTC) Received: (qmail 16431 invoked by uid 399); 4 Nov 2010 19:32:44 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Nov 2010 19:32:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CD30A5C.5070801@FreeBSD.org> Date: Thu, 04 Nov 2010 12:32:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: Garrett Cooper References: <4CD2FE43.7060709@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:32:46 -0000 On 11/04/10 11:46, Garrett Cooper wrote: > Can you try with 7.x to see if there's a similar problem? I ask > this because similar symptoms might exist with snd_emu10kx as another > person and I have hashed over in another thread. Yes, but not right away. :) What am I looking for when I do? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:36:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F76C106566C for ; Thu, 4 Nov 2010 19:36:04 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id E9FEF8FC12 for ; Thu, 4 Nov 2010 19:36:03 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id oA4JZ3qu037928 for ; Thu, 4 Nov 2010 12:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1288899303; bh=T1YJQsQAFoUkWj5LaqiNbw2fKer9AtOOw2i1vZV5/4U=; h=Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=rJMsD1fy5dJ6tmK9HRiIGy/I9wlKlvua988UnmU4dJchebVIcymP1DKQ4J9jm404n qE9o0T3LdPDnstrDe/0VmMTxsjjN/fYGBr8cV3KSwTjnk40nqhj6s30o5iW6Wx5+fq izLFeS1hlAAPEMMSwJjDCAbDsJW7RVZA9kM7LcgA= From: Sean Bruno To: "freebsd-current@freebsd.org" In-Reply-To: <1288814744.2647.6.camel@home-yahoo> References: <1288814744.2647.6.camel@home-yahoo> Content-Type: text/plain; charset="UTF-8" Date: Thu, 04 Nov 2010 12:35:03 -0700 Message-ID: <1288899303.6670.3.camel@home-yahoo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: Re: Sanity Check, HP Bigger Iron DL580G7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "sbruno@freebsd.org" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:36:04 -0000 On Wed, 2010-11-03 at 13:05 -0700, Sean Bruno wrote: > Been working on getting this machine serviceable under FreeBSD with HP, > I need to try out some patches for other problems, but I wanted to link > folks to the pciconf output first. > > Most importantly, I see an unsupported ethernet controller in this box, > but other's may find other devices of interest as well. > > Sean > > http://people.freebsd.org/~sbruno/dl580g7_pciconf.txt > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Interesting stuff here. It *appears* that the Fibre Channel Adapter is not working correctly isp(4). Also, it appears that this 10G Ethernet card is a Qlogic 10G Ethernet device. I'm not aware of a qlogic driver for this device. http://people.freebsd.org/~sbruno/dl580g7_dmesg.txt Sean From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:42:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18CEF106564A; Thu, 4 Nov 2010 19:42:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 718F88FC0A; Thu, 4 Nov 2010 19:42:26 +0000 (UTC) Received: by eyb7 with SMTP id 7so1298621eyb.13 for ; Thu, 04 Nov 2010 12:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vmF+OYvTEDKLbu1yepBmVXn7FaRJ/VXjaj45wy1bOCg=; b=MFReRYUb8cb8rj90hztlUed0cy7MyZh5sCD5YYZjOJslx23+BkwD1Dao5pdAwb8BKg LIe+o+KWpbQRDh7FMJWPW+X8kiXFjtBmbnV0JlLh9KSm46OjRqpC+3uNcYbwxjrg+pLr ssGR/tWKwO/vqHMXzBSfJ60jjSrm0xDkpPKLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wDxiB5WevbcnOf79Dp4J7XeNWbXe7bKOdBIqxSzhUYxasgwSP6CclPEfavVrlkudLn YZ0lxP7ZW7p6r3p53SSyzSZNc+7khTEIxTtVDn4196p7bWqgG23vBlLJ0KiA9jtMtjFI sz1jqglZkm2jiAZqb7fbq6nByDHz/htwPVVw0= MIME-Version: 1.0 Received: by 10.216.175.18 with SMTP id y18mr1202310wel.30.1288899744189; Thu, 04 Nov 2010 12:42:24 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Thu, 4 Nov 2010 12:42:24 -0700 (PDT) In-Reply-To: <4CD30A5C.5070801@FreeBSD.org> References: <4CD2FE43.7060709@FreeBSD.org> <4CD30A5C.5070801@FreeBSD.org> Date: Thu, 4 Nov 2010 12:42:24 -0700 X-Google-Sender-Auth: s8X9-S8wO11qYko4Yg8zoJNHKYk Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:42:27 -0000 On Thu, Nov 4, 2010 at 12:32 PM, Doug Barton wrote: > On 11/04/10 11:46, Garrett Cooper wrote: >> >> Can you try with 7.x to see if there's a similar problem? I ask >> this because similar symptoms might exist with snd_emu10kx as another >> person and I have hashed over in another thread. > > Yes, but not right away. :) =A0What am I looking for when I do? Not much, other than [if it does follow my hunch] it should consistently work as expected on 7.x (with sound and snd_hda built into the kernel, sound built into the kernel and snd_hda built in as a module, and both built as modules). A bunch of stuff went into sound(4) in 8.x to 'improve sound quality' and it caused potentially non-deterministic breakage, but I don't have a concrete root cause for the issue (and haven't tried 7.x in a while); I did reproduce it by running as many instances of audio consuming apps as possible (haven't determined the salient number, but with 8 vchans, running 4~8 instances of vlc unrooted the issue on my 8-core box). I need to try reproducing it with snd_hda as well... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:45:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532F4106566B for ; Thu, 4 Nov 2010 19:45:16 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD1F98FC0A for ; Thu, 4 Nov 2010 19:45:15 +0000 (UTC) Received: by bwz3 with SMTP id 3so1963841bwz.13 for ; Thu, 04 Nov 2010 12:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=gX6TCD0w4aFP2LX//+XkijbQQBgoxqvcHGzxj9TFcYI=; b=o0yex2lX/lz5uIGOz7lXcyitVav6288nDU7joQXmi1KV21TCxVT2WegW6PMiwCXMvR Q7rydQRuzXZKZS5fZxSCx3UnXGcb2h0vLSzwKdZU07La/GaGPu6ebenaMWkFB4sVE7bf ay0UE8UHgMpi1qakuC9+MoJeXWvHUSnBVZXV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wE/xE+dLfa+PXezyeaULxpxZXSq9uFwV6zY+9Yn739xyhBDqvsp/pofiuACKYsJPpi 7cQoJCfpubPUFNFfPif529kjW625wTASWg2TVtdRjfp63pkX7L7Pbh3EK4+L/9MBl9pt OD7WzVAtYF9olcqFYs2XLuttAeOH6LlxrJY/0= Received: by 10.204.68.137 with SMTP id v9mr1042017bki.148.1288899913840; Thu, 04 Nov 2010 12:45:13 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id v25sm299565bkt.18.2010.11.04.12.45.12 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 12:45:13 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD30D47.5020101@FreeBSD.org> Date: Thu, 04 Nov 2010 21:45:11 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Doug Barton , FreeBSD-Current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:45:16 -0000 Doug Barton wrote: > Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, > with the following device: > > hdac0: mem > 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: HDA Codec #0: Analog Devices AD1984A > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > > There's 2 problems. When I plug the headphones in there are sounds, > sometimes a low-level sound like a tea kettle whistling, and sometimes a > louder screeching sound. Try to play with mixer. Especially with "speaker", if you have it. Some unconnected CODEC inputs may receive random radio interference from other system components. > The other problem is that the front headphone > jack doesn't work. The rear one works, but this is less than convenient. > :) Have you tried to playback via pcm1? It could go exactly there. > Windows and ubuntu linux do not have either problem with the same > hardware. Linux and Windows often have hardcoded drivers for specific hardware. Our driver tries to be universal and honor standards, unluckily often violated by BIOS makers. For more information about CODEC and it's configuration you need to get verbose dmesg. Details are in snd_hda(4). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 19:55:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 348111065670; Thu, 4 Nov 2010 19:55:23 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 504D58FC17; Thu, 4 Nov 2010 19:55:21 +0000 (UTC) Received: from [128.39.150.150] ([128.39.150.150]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id oA4JUxYS064175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Nov 2010 06:01:09 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-15--793270180; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <4CD2FE43.7060709@FreeBSD.org> Date: Thu, 4 Nov 2010 20:30:58 +0100 Message-Id: <549799F7-9650-4E55-BCD7-1B452E4141A1@gsoft.com.au> References: <4CD2FE43.7060709@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1081) X-Spam-Score: -0.272 () BAYES_00,RDNS_NONE X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:55:23 -0000 --Apple-Mail-15--793270180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 04/11/2010, at 19:41, Doug Barton wrote: > hdac0: mem = 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: HDA Codec #0: Analog Devices AD1984A > pcm0: at cad 0 nid 1 on = hdac0 > pcm1: at cad 0 nid 1 on = hdac0 >=20 > There's 2 problems. When I plug the headphones in there are sounds, = sometimes a low-level sound like a tea kettle whistling, and sometimes a = louder screeching sound. The other problem is that the front headphone = jack doesn't work. The rear one works, but this is less than convenient. = :) Windows and ubuntu linux do not have either problem with the same = hardware. Try sysctl hw.snd.default_unit=3D1 You have 2 separate outputs, almost certainly one is the rear and one is = the front. The noise you hear might be fixable using mixer to mute any other = sources but PCM. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail-15--793270180-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 20:02:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80FF1065672; Thu, 4 Nov 2010 20:02:48 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id A6FA18FC0C; Thu, 4 Nov 2010 20:02:48 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 4 Nov 2010 15:52:14 -0400 Message-ID: <4CD30EEE.9070101@wintek.com> Date: Thu, 4 Nov 2010 15:52:14 -0400 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Doug Barton References: <4CD2FE43.7060709@FreeBSD.org> In-Reply-To: <4CD2FE43.7060709@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:02:49 -0000 On 11/04/10 14:41, Doug Barton wrote: > Howdy, > > Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, > with the following device: > > hdac0: mem > 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: HDA Codec #0: Analog Devices AD1984A > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > > There's 2 problems. When I plug the headphones in there are sounds, > sometimes a low-level sound like a tea kettle whistling, and sometimes a > louder screeching sound. The other problem is that the front headphone > jack doesn't work. The rear one works, but this is less than convenient. > :) Windows and ubuntu linux do not have either problem with the same > hardware. > > > Doug > I managed to get the front headphone jack to work at the expense of the rear one by setting hw.snd.default_unit=2. If it works for you don't forget to put it in /etc/sysctl.conf (like I did!). - Richard -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 20:04:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3149C1065672 for ; Thu, 4 Nov 2010 20:04:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id C6B388FC13 for ; Thu, 4 Nov 2010 20:04:21 +0000 (UTC) Received: (qmail 31035 invoked by uid 399); 4 Nov 2010 20:04:20 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Nov 2010 20:04:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CD311C3.5000705@FreeBSD.org> Date: Thu, 04 Nov 2010 13:04:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CD30D47.5020101@FreeBSD.org> In-Reply-To: <4CD30D47.5020101@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:04:22 -0000 On 11/04/10 12:45, Alexander Motin wrote: > Doug Barton wrote: >> Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, >> with the following device: >> >> hdac0: mem >> 0xf7adc000-0xf7adffff irq 16 at device 27.0 on pci0 >> hdac0: HDA Driver Revision: 20100226_0142 >> hdac0: HDA Codec #0: Analog Devices AD1984A >> pcm0: at cad 0 nid 1 on hdac0 >> pcm1: at cad 0 nid 1 on hdac0 >> >> There's 2 problems. When I plug the headphones in there are sounds, >> sometimes a low-level sound like a tea kettle whistling, and sometimes a >> louder screeching sound. > > Try to play with mixer. Especially with "speaker", if you have it. Some > unconnected CODEC inputs may receive random radio interference from > other system components. Bang on! Setting speaker to 0:0 instantly removed the random sounds. I assumed it was RFI from something, but I was using the windowmaker mixer app previously and thought I had already adjusted everything to 0. Silly of me not to check the command line version, thanks for the reminder. >> The other problem is that the front headphone >> jack doesn't work. The rear one works, but this is less than convenient. >> :) > > Have you tried to playback via pcm1? It could go exactly there. 2 for 2! The magic is hw.snd.default_unit=1 >> Windows and ubuntu linux do not have either problem with the same >> hardware. > > Linux and Windows often have hardcoded drivers for specific hardware. > Our driver tries to be universal and honor standards, unluckily often > violated by BIOS makers. So, same song, $N'th verse? :) > For more information about CODEC and it's configuration you need to get > verbose dmesg. Details are in snd_hda(4). Thank you for your excellent help, I learned something today. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 20:11:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3E31065672; Thu, 4 Nov 2010 20:11:40 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A01588FC12; Thu, 4 Nov 2010 20:11:39 +0000 (UTC) Received: by yxl31 with SMTP id 31so1808006yxl.13 for ; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aMZNkIF9iVlGQqt1uYJpveDEPXRqgwgMV3juNw8lHVc=; b=bof83p7zSh8loU1jljLWlrzmnWbnZmGOVQTEWULbxFIBZ/7FTxByFe8Xp3bUpTggGj Dp+B/iyA5JsczjE4qBLn/CWoPzryt+RYwl49SoDVZoZJR7nQrmcdvxp9ahubeuWiD0Ad hHj2TI7ACzkVnAjaa/ZL8G6u5EVq9stEzeNWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v36Ozpxmqlcl2vlCGYLLjRFENZR9EXPndpzn6FqP4TfXZ6kOEqPP5fnyT4ghyQ+ATQ mMa/e1drhQIi4LKuTwmigwjn6ZciO1RzZF38R6vhSZFJHFpM4SmUIqWva1qOwKMCMX7+ 59Yjgqdo49ABDSECfC//RUCJfANWoegPUlF6I= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr731997icn.343.1288901498679; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 13:11:38 -0700 (PDT) In-Reply-To: <201011042011.44705.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> Date: Thu, 4 Nov 2010 13:11:38 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:11:40 -0000 On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > wrote: >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> >> =A0(and there is in Jeff's OFED branch) >> > >> > Is there a link to this branch? I would certainly have a look at his w= ork >> > and re-base my patch. >> >> It's on svn.freebsd.org: >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task= que >> ue.c?view=3Dlog >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 >> >> For the purpose of speed, I'm not opposed to breaking the KBI by using >> a doubly-linked TAILQ, but I don't think the difference will matter >> all that often (perhaps I'm wrong and some taskqueues have dozens of >> pending tasks?) >> >> Thanks, >> matthew > > At first look I see that I need a non-blocking version of: > > taskqueue_cancel( > > At the point in the code where these functions are called I cannot block.= Is > this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 20:14:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706F8106566B; Thu, 4 Nov 2010 20:14:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADBA8FC08; Thu, 4 Nov 2010 20:14:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=0QwtpmV1rXepT5CfuEUA:9 a=eS946g9CBUxHvd1zr24A:7 a=CZwjQWI-HvlaZHoSd6vtHMF60NkA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45433961; Thu, 04 Nov 2010 21:14:06 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 21:15:16 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042115.16187.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:14:09 -0000 On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > wrote: > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> >> (and there is in Jeff's OFED branch) > >> > > >> > Is there a link to this branch? I would certainly have a look at his > >> > work and re-base my patch. > >> > >> It's on svn.freebsd.org: > >> > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > >> que ue.c?view=log > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > >> > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > >> a doubly-linked TAILQ, but I don't think the difference will matter > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > >> pending tasks?) > >> > >> Thanks, > >> matthew > > > > At first look I see that I need a non-blocking version of: > > > > taskqueue_cancel( > > > > At the point in the code where these functions are called I cannot block. > > Is this impossible to implement? > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > possible to determine whether a task is running without taking the > taskqueue lock. And it is certainly impossible to dequeue a task > without the lock that was used to enqueue it. > > However, a variant that dequeued if the task was still pending, and > returned failure otherwise (rather than sleeping) is definitely > possible. I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 20:37:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F16E106564A; Thu, 4 Nov 2010 20:37:43 +0000 (UTC) (envelope-from vic@yeaguy.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mx1.freebsd.org (Postfix) with ESMTP id 3386D8FC1C; Thu, 4 Nov 2010 20:37:43 +0000 (UTC) Received: from hrndva-omtalb.mail.rr.com ([10.128.143.54]) by hrndva-qmta02.mail.rr.com with ESMTP id <20101104202654179.OEOZ10056@hrndva-qmta02.mail.rr.com>; Thu, 4 Nov 2010 20:26:54 +0000 X-Authority-Analysis: v=1.1 cv=NFUeGz0loTdi/T6hXKngYYtckjed7x3pKvNOqmBBK18= c=1 sm=0 a=kj9zAlcOel0A:10 a=K3oiwSFwsX5fJWoDMELOCw==:17 a=tZ5SSJdqAAAA:8 a=6I5d2MoRAAAA:8 a=g5jMxhRzFYGwUju_2mcA:9 a=waUz3fXEYVsUHuqZDWgA:7 a=T4GNTpXtbt2pIvhSLeZckxMsSVoA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=K3oiwSFwsX5fJWoDMELOCw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 67.49.120.184 Received: from [67.49.120.184] ([67.49.120.184:15610] helo=[192.168.1.169]) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 7A/EC-12606-4C613DC4; Thu, 04 Nov 2010 20:25:40 +0000 Date: Thu, 4 Nov 2010 13:25:35 -0700 (PDT) From: "Justin V." To: Doug Barton In-Reply-To: <4CD30A5C.5070801@FreeBSD.org> Message-ID: References: <4CD2FE43.7060709@FreeBSD.org> <4CD30A5C.5070801@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Garrett Cooper Subject: Re: Problems with hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:37:43 -0000 On Thu, 4 Nov 2010, Doug Barton wrote: > On 11/04/10 11:46, Garrett Cooper wrote: >> Can you try with 7.x to see if there's a similar problem? I ask >> this because similar symptoms might exist with snd_emu10kx as another >> person and I have hashed over in another thread. > > Yes, but not right away. :) What am I looking for when I do? > > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I have the same soundcard I believe.. You loaded the driver?? I built mine into the kernal: [vic@yeaguy ~]$ grep -i hda /usr/src/sys/i386/conf/HBCA device snd_hda [vic@yeaguy ~]$ cat /var/run/dmesg.boot | grep hd hdac0: mem 0xdffdc000-0xdffdffff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] hdac0: HDA Codec #2: Sigmatel STAC9227X pcm0: at cad 2 nid 1 on hdac0 pcm1: at cad 2 nid 1 on hdac0 Did you try playing with the MIXER?? i use rexima .. console based mixer, easy to use. From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 21:23:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF90106564A; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14DB98FC13; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AC24446B0D; Thu, 4 Nov 2010 17:23:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9BAD38A009; Thu, 4 Nov 2010 17:23:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 17:22:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> In-Reply-To: <201011042115.16187.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041722.46673.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 17:23:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:23:04 -0000 On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky > wrote: > > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > > > wrote: > > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > > >> >> (and there is in Jeff's OFED branch) > > >> > > > >> > Is there a link to this branch? I would certainly have a look at his > > >> > work and re-base my patch. > > >> > > >> It's on svn.freebsd.org: > > >> > > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > > >> que ue.c?view=log > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > >> > > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > > >> a doubly-linked TAILQ, but I don't think the difference will matter > > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > > >> pending tasks?) > > >> > > >> Thanks, > > >> matthew > > > > > > At first look I see that I need a non-blocking version of: > > > > > > taskqueue_cancel( > > > > > > At the point in the code where these functions are called I cannot block. > > > Is this impossible to implement? > > > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > > possible to determine whether a task is running without taking the > > taskqueue lock. And it is certainly impossible to dequeue a task > > without the lock that was used to enqueue it. > > > > However, a variant that dequeued if the task was still pending, and > > returned failure otherwise (rather than sleeping) is definitely > > possible. > > I think that if a task is currently executing, then there should be a drain > method for that. I.E. two methods: One to stop and one to cancel/drain. Can > you implement this? I agree, this would also be consistent with the callout_*() API if you had both "stop()" and "drain()" methods. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 21:33:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A072E106566B; Thu, 4 Nov 2010 21:33:30 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from smtp.fullrate.dk (smtp.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8498FC1D; Thu, 4 Nov 2010 21:33:30 +0000 (UTC) Received: from [192.168.4.26] (4304ds2-vlb.1.fullrate.dk [90.184.171.166]) by smtp.fullrate.dk (Postfix) with ESMTP id 4CF209CD84; Thu, 4 Nov 2010 22:14:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Simon L. B. Nielsen" In-Reply-To: Date: Thu, 4 Nov 2010 22:14:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69CE6B92-910F-4F45-9376-175901A9B4CA@nitro.dk> References: To: Simon L. B. Nielsen X-Mailer: Apple Mail (2.1081) Cc: freebsd-current , freebsd-stable@freebsd.org Subject: Re: svn2cvs replication down for the moment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:33:31 -0000 On 4 Nov 2010, at 09:55, Simon L. B. Nielsen wrote: > The FreeBSD svn2cvs exporter is currently down and won't be fixed = until tonight CET at the earliest. This basically mean that until that = is fixed, any change in svn (IE, src/) won't be available via CVS or = CVSup. >=20 > A change yesterday morning "replaced" an entire directory, which = svn2cvs don't know how to deal with. > As it's an entire directory I can't just use our usual hack and ignore = the delete part as that will leave files in the directory in CVS which = wasn't supposed to be there. After some handholding (and 'evil' direct cvs commit) cvs2svn is now = running again. --=20 Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 21:49:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176771065701; Thu, 4 Nov 2010 21:49:24 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 730798FC14; Thu, 4 Nov 2010 21:49:23 +0000 (UTC) Received: by gwj16 with SMTP id 16so1890883gwj.13 for ; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y5OWkyV0yWOgrJoXXzsMGOw+u+lerBuuB68hIWvCy20=; b=RImZJ053F2jMX3McwHgNha06a1oquosW3mUcVyDYtk3SSbExv0r6H7sWE9HTrmY8hM 66kLZO3FaPGPL1CwwLiCYgqjSGV5bIKLzNpjVCe3JPIgdd4nvaedznesRut/FQs/M06z igr8n4IMQYYZKc+4VwjGP0QPY8ryZBE5y3KCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qWa94M36Byq7C0OS+BuSi8WSfDGJHFlkPcQ5jZi23oDSqRXS0nDgDT4yTjJ3EMmvpX hk/6EJN4C0A5ZsePlAGE5z7DWTiZIe2gXq4WNHmTFYJgqVRvwip6K4TgLXnkjH6ZpB/E sv8lof1UM+BhXYDrgAfDgLm9qeSFaADQTCCdE= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr926521icb.276.1288907362527; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 14:49:22 -0700 (PDT) In-Reply-To: <201011041722.46673.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> Date: Thu, 4 Nov 2010 14:49:22 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:49:24 -0000 On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> I think that if a task is currently executing, then there should be a drain >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can >> you implement this? > > I agree, this would also be consistent with the callout_*() API if you had > both "stop()" and "drain()" methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 22:23:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C64AD106566B for ; Thu, 4 Nov 2010 22:23:43 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id F06E98FC15 for ; Thu, 4 Nov 2010 22:23:42 +0000 (UTC) Received: from [93.104.81.246] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PE8Db-0008Qg-PR for freebsd-current@freebsd.org; Thu, 04 Nov 2010 23:23:40 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA4MNb7G006469 for ; Thu, 4 Nov 2010 23:23:37 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA4MNbc1006468 for freebsd-current@freebsd.org; Thu, 4 Nov 2010 23:23:37 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 4 Nov 2010 23:23:36 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20101104222336.GA6428@current.Sisis.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.81.246 Subject: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 22:23:43 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I have the above modell running 9-CURRENT, but can't get the build-in mic recording, only the jack for the mic in the headset records fine in Skype; here are the output of /dev/sndstat and mixer(1): $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: (play/rec) default pcm1: (rec) $ mixer Mixer vol is currently set to 66:66 Mixer pcm is currently set to 40:40 Mixer mic is currently set to 70:70 Mixer mix is currently set to 74:74 Mixer rec is currently set to 75:75 Mixer igain is currently set to 57:57 Mixer ogain is currently set to 65:65 Recording source: mic mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as well the output of verbose messages grep'ed for pcm and hdac. Btw: Is there some tutorial for the settings mentioned in snd_hda(4), I don't understand the man page without more background info :-( Btw II: Is there some test recording software that let me just record from /dev/dspX and play it back (to not use Skype for such tests)? Thanks in advance for any help matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pcm.txt" hdac0: OSS: pcm (pcm) hdac0: OSS: pcm, mix pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 2 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=20 [pin: Speaker (Fixed)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: nid=33 [pin: Headphones (Green Jack)] pcm0: | pcm0: + <- nid=12 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=35 [audio mixer] [src: mic, mix] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 14 (nid 12 in 0): mute pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: +- ctl 22 (nid 20 in ): mute pcm0: +- ctl 34 (nid 33 in ): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 2 out): -64/0dB (65 steps) pcm0: +- ctl 14 (nid 12 in 0): mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 27 (nid 24 out): 0/30dB (4 steps) pcm0: +- ctl 45 (nid 35 in 0): mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 8 in 0): -16/30dB (32 steps) + mute pcm0: +- ctl 45 (nid 35 in 0): mute pcm0: +- ctl 53 (nid 35 in 8): mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 6 (nid 11 in 0): -34/12dB (32 steps) + mute pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: +- ctl 53 (nid 35 in 8): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 15 (nid 12 in 1): mute pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "mic": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 3e200000, 4000; 0xe472d000 -> 3e200000 pcm0: sndbuf_setmap 3e210000, 4000; 0xe473d000 -> 3e210000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: ADC: 9 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + <- nid=34 [audio mixer] [src: monitor] pcm1: | pcm1: + <- nid=18 [pin: Mic (Fixed)] [src: monitor] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Microphone2 Volume (OSS: monitor) pcm1: | pcm1: +- ctl 5 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 44 (nid 34 in 9): mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 5 (nid 9 in 0): -16/30dB (32 steps) + mute pcm1: +- ctl 44 (nid 34 in 9): mute pcm1: pcm1: Mixer "rec": pcm1: Mixer "monitor": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 3e220000, 4000; 0xe474d000 -> 3e220000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="hdac.txt" hdac0: mem 0x58340000-0x58343fff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) hdac0: using IRQ 256 for MSI hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC272 hdac0: HDA Codec ID: 0x10ec0272 hdac0: Vendor: 0x10ec hdac0: Device: 0x0272 hdac0: Revision: 0x00 hdac0: Stepping: 0x01 hdac0: PCI Subvendor: 0x022f1025 hdac0: Found audio FG nid=1 startnode=2 endnode=36 total=34 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000002 NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 23 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 29 0x4016892d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 9 hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 33 0x0321401f as 1 seq 15 Headphones Jack jack 1 loc 3 color Green misc 0 hdac0: Patched pins configuration: hdac0: nid 17 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 hdac0: nid 19 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 20 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 21 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 23 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 hdac0: nid 25 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 26 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 27 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 29 0x4016892d as 2 seq 13 Speaker None jack 6 loc 0 color Purple misc 9 [DISABLED] hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 33 0x0321401f as 1 seq 15 Headphones Jack jack 1 loc 3 color Green misc 0 hdac0: 3 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=20 seq=0 hdac0: Pin nid=33 seq=15 hdac0: Association 1 (2) in: hdac0: Pin nid=24 seq=0 hdac0: Association 2 (3) in: hdac0: Pin nid=18 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 20 traced to DAC 2 hdac0: Pin 33 traced to DAC 2 and hpredir 0 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 24 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing association 2 (3) hdac0: Pin 18 traced to ADC 9 hdac0: Association 2 (3) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 11 to out hdac0: nid 11 is input monitor hdac0: Tracing nid 34 to out hdac0: Tracing nid 35 to out hdac0: Tracing other input monitors hdac0: Tracing nid 18 to out hdac0: Tracing nid 24 to out hdac0: Tracing beeper hdac0: GPIO init: data=0x00000000 mask=0x00000000 dir=0x00000000 hdac0: GPIO commit: data=0x00000001 mask=0x00000001 dir=0x00000001 hdac0: Enabling headphone/speaker audio routing switching: hdac0: as=0 sense nid=33 [UNSOL] hdac0: Pin sense: nid=33 res=0x00000000 hdac0: FG config/quirks: gpio0 forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 3 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 4 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x0000041d hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x00034040 hdac0: mute=0 step=64 size=3 offset=64 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=35 [audio mixer] hdac0: hdac0: nid: 9 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Input amp: 0x80051f0b hdac0: mute=1 step=31 size=5 offset=11 hdac0: connections: 1 hdac0: | hdac0: + <- nid=34 [audio mixer] hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mix (mix) hdac0: Input amp: 0x80051f17 hdac0: mute=1 step=31 size=5 offset=23 hdac0: connections: 8 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 12 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00008001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: + <- nid=11 [audio mixer] hdac0: hdac0: nid: 13 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=3 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: -2 (0x00000000) hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010a hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=2 [audio output] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e05e0 hdac0: 16 20 24 bits, 44 48 88 96 192 KHz hdac0: hdac0: nid: 17 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400700 hdac0: PWR DIGITAL hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=16 [audio output] [DISABLED] hdac0: hdac0: nid: 18 hdac0: Name: pin: Mic (Fixed) hdac0: Widget cap: 0x00400401 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: monitor (monitor) hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x99a30930 hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400401 hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 20 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x99130110 hdac0: Pin control: 0x00000040 OUT hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0001003c hdac0: PDC HP OUT IN EAPD hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000034 hdac0: PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040050c hdac0: PWR hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x03a19820 hdac0: Pin control: 0x00000024 IN VREFs hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 25 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 3 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: + <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00001734 hdac0: PDC OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x0040058f hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000173c hdac0: PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: Input amp: 0x00270300 hdac0: mute=0 step=3 size=39 offset=0 hdac0: connections: 3 hdac0: | hdac0: + [DISABLED] <- nid=12 [audio mixer] (selected) hdac0: + <- nid=13 [audio mixer] [DISABLED] hdac0: + <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400400 hdac0: PWR hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x4016892d hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400780 hdac0: PWR DIGITAL UNSOL hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=6 [audio output] [DISABLED] hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00040 hdac0: PROC hdac0: hdac0: nid: 33 hdac0: Name: pin: Headphones (Green Jack) hdac0: Widget cap: 0x0040058d hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00008000) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x0321401f hdac0: Pin control: 0x000000c0 HP OUT hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 3 hdac0: | hdac0: + <- nid=12 [audio mixer] (selected) hdac0: + [DISABLED] <- nid=13 [audio mixer] [DISABLED] hdac0: + [DISABLED] <- nid=14 [audio mixer] [DISABLED] hdac0: hdac0: nid: 34 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: monitor hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + [DISABLED] <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=11 [audio mixer] hdac0: + <- nid=18 [pin: Mic (Fixed)] hdac0: hdac0: nid: 35 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 10 hdac0: | hdac0: + <- nid=24 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=20 [pin: Speaker (Fixed)] hdac0: + [DISABLED] <- nid=21 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=22 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=11 [audio mixer] hdac0: + [DISABLED] <- nid=19 [pin: Speaker (None)] [DISABLED] hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 --wac7ysb48OaltWcw-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 22:46:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BCC106564A for ; Thu, 4 Nov 2010 22:46:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1848FC14 for ; Thu, 4 Nov 2010 22:46:55 +0000 (UTC) Received: by bwz3 with SMTP id 3so2126688bwz.13 for ; Thu, 04 Nov 2010 15:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ZGW59tfc2/iwrqGhthtKz8AgKn/I8qLgBWb9RplCQiM=; b=DZVv+FzPPfEHuyUOtS13/8rAhVVqoV8ON2i5arPh4lRcoNp2T4J4OsI3/9nbWIYd+T I6JHCCah/+VORXH+snLgtFs8RW/SHnDE+ptzlw2luJX6BNQaeDW/NSfofdZWk3RxArMm iozkQyZuw5ZvCpfs99dTZgwtM83doiLU+5+bQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=iPPIbdKmofLg1AXYWNL/JX0XsuItcOPhecBFqIaL9aXHUoUo39jLT1o9v55SzsJ4fI B2lUwbniJBeso4z2eI1eO/JKjTUo24dBFKJDMGIm4+71Kxky0YBtOf0IQY1HkXm7jipp rlLOzm0o0n1xX3SyG1NnBX6bdPMYifpOf92MU= Received: by 10.204.113.195 with SMTP id b3mr1164407bkq.210.1288910813228; Thu, 04 Nov 2010 15:46:53 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d27sm426185bkw.2.2010.11.04.15.46.51 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 15:46:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD337DA.7030902@FreeBSD.org> Date: Fri, 05 Nov 2010 00:46:50 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Matthias Apitz , FreeBSD-Current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 22:46:57 -0000 Matthias Apitz wrote: > > Hello, > > I have the above modell running 9-CURRENT, but can't get the build-in > mic recording, only the jack for the mic in the headset records fine in > Skype; > > here are the output of /dev/sndstat and mixer(1): > > $ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) > Installed devices: > pcm0: (play/rec) default > pcm1: (rec) > > $ mixer > Mixer vol is currently set to 66:66 > Mixer pcm is currently set to 40:40 > Mixer mic is currently set to 70:70 > Mixer mix is currently set to 74:74 > Mixer rec is currently set to 75:75 > Mixer igain is currently set to 57:57 > Mixer ogain is currently set to 65:65 > Recording source: mic > > mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as > well the output of verbose messages grep'ed for pcm and hdac. Your CODEC configured to provide built-in microphone on separate device pcm1. You may record from there (Skype allows to choose device) or reconfigure CODEC using hints. > Btw: Is there some tutorial for the settings mentioned in snd_hda(4), I > don't understand the man page without more background info :-( HDA and UAA specifications, but they are rather large. I have small presentation from KyivBSD conference, but it is in Russian: http://ru.kyivbsd.org.ua/arhiv/2010/motin.HDA.pdf?attredirects=0&d=1 > Btw II: Is there some test recording software that let me just record > from /dev/dspX and play it back (to not use Skype for such tests)? dd? :) Also audio/rawrec. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 23:07:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADFEB106564A; Thu, 4 Nov 2010 23:07:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 298698FC0A; Thu, 4 Nov 2010 23:07:40 +0000 (UTC) Received: from [93.104.81.246] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PE8uA-0007jp-9Y; Fri, 05 Nov 2010 00:07:38 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA4N7a41006713; Fri, 5 Nov 2010 00:07:36 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA4N7ZNv006712; Fri, 5 Nov 2010 00:07:35 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 5 Nov 2010 00:07:35 +0100 From: Matthias Apitz To: Alexander Motin Message-ID: <20101104230735.GA6686@current.Sisis.de> References: <4CD337DA.7030902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD337DA.7030902@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.81.246 Cc: FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 23:07:40 -0000 El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: > Matthias Apitz wrote: > > > > mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as > > well the output of verbose messages grep'ed for pcm and hdac. > > Your CODEC configured to provide built-in microphone on separate device > pcm1. You may record from there (Skype allows to choose device) or > reconfigure CODEC using hints. In Skype in let me choose between /dev/dsp /dev/dsp0 /dev/dsp1 When I set mic to /dev/dsp0 it records from the jack (headphone mic), when I set it to /dev/dsp1 there is no recording. And the mixer for the pcm1 says: # mixer -f /dev/mixer1 Mixer rec is currently set to 100:100 Mixer monitor is currently set to 100:100 Recording source: monitor Would you be so kind and give me the lines for reconfigure CODEC using hints? I'm really lost in this. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 4 23:13:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A28911065672 for ; Thu, 4 Nov 2010 23:13:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 259FA8FC1E for ; Thu, 4 Nov 2010 23:13:18 +0000 (UTC) Received: by bwz3 with SMTP id 3so2145669bwz.13 for ; Thu, 04 Nov 2010 16:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4o8oDbqlW4SWzvkdN0f0fzggQnXXoa+27luy1hlnSVI=; b=GOsHBNFSb7BHCUFFIddlT26LX5LrYUdn3+RiMwB3PhkqMbIwmL4s1A+P8if3f2+p5N PAupEyJETQ481NRhAsYAYz59vMD7oSQptdaZ5FYLtSAIhEnOQiZc+omRguMW2/66H3xi MvC3Y00g/nzNrXkP+1q5P3jTOu+5fDZLUKcWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ieRTQzSdcmrMfMOSHF9ceaAPhQZrsRd+jgq2Mc9z0J04fb34PREeX6fMQ4GZSdCtvy sV+a953sz0SxtlXsze8BE1gEKvLvtygIyqGRrVMsnJ39aJRBAjeNLKBQzdszBFpu1rXS a3QKAYUDCwhtliBPm1USIpLHdxlucbyI/0rJI= Received: by 10.204.121.83 with SMTP id g19mr1225553bkr.13.1288912397951; Thu, 04 Nov 2010 16:13:17 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id t10sm440345bkj.16.2010.11.04.16.13.15 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 16:13:16 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD33E0B.1070304@FreeBSD.org> Date: Fri, 05 Nov 2010 01:13:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Matthias Apitz References: <4CD337DA.7030902@FreeBSD.org> <20101104230735.GA6686@current.Sisis.de> In-Reply-To: <20101104230735.GA6686@current.Sisis.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 23:13:19 -0000 Matthias Apitz wrote: > El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: >> Matthias Apitz wrote: >>> mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as >>> well the output of verbose messages grep'ed for pcm and hdac. >> Your CODEC configured to provide built-in microphone on separate device >> pcm1. You may record from there (Skype allows to choose device) or >> reconfigure CODEC using hints. > > In Skype in let me choose between > /dev/dsp > /dev/dsp0 > /dev/dsp1 > > When I set mic to /dev/dsp0 it records from the jack (headphone mic), > when I set it to /dev/dsp1 there is no recording. And the mixer for the > pcm1 says: > > # mixer -f /dev/mixer1 > Mixer rec is currently set to 100:100 > Mixer monitor is currently set to 100:100 > Recording source: monitor That's strange. I would expect it working. > Would you be so kind and give me the lines for reconfigure CODEC using > hints? I'm really lost in this. OK, try this: hint.hdac.0.cad0.nid18.config="as=2 seq=1" -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 00:08:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF8DD10656A6; Fri, 5 Nov 2010 00:08:02 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 882438FC17; Fri, 5 Nov 2010 00:08:01 +0000 (UTC) Received: from 37-148-132-95.pool.ukrtel.net ([95.132.148.37] helo=localhost) by fsm1.ukr.net with esmtps ID 1PE9qZ-000Cjx-VD ; Fri, 05 Nov 2010 02:08:00 +0200 Date: Fri, 5 Nov 2010 02:07:58 +0200 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101105020758.2d9b659b@ukr.net> In-Reply-To: References: <20101104165316.0c0d4579@ukr.net> <20101104145750.GT1980@albert.catwhisker.org> <20101104171543.4007aa6a@ukr.net> <20101104160720.GQ23848@cicely7.cicely.de> <20101104181154.20db9164@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ticso@cicely7.cicely.de, ticso@cicely.de, freebsd-current@freebsd.org Subject: Re: the world is not built gcc after upgrade svn r214735 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 00:08:02 -0000 =D0=92 Thu, 4 Nov 2010 09:19:01 -0700 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Thu, Nov 4, 2010 at 9:11 AM, Ivan Klymenko wrote: > > =D0=92 Thu, 4 Nov 2010 17:07:20 +0100 > > Bernd Walter =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > >> On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote: > >> > ?? Thu, 4 Nov 2010 07:57:50 -0700 > >> > David Wolfskill ??????????: > >> > > >> > > On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote: > >> > > > Hello, people! > >> > > > After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 > >> > > > does not build world: ... > >> > > > .... > >> > > > >> > > I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to > >> > > r214777. > >> > > > >> > > Peace, > >> > > david > >> > > >> > Do you use when building make option -j? > >> > > >> > I'm using -j 3 > >> > >> You likely have stall dependencies in /usr/obj. > >> > > > > How can I fix it? >=20 > rm -Rf /usr/obj/* > :) I mean - the problem as a whole I do not know what the reason, but the build process was successful only af= ter completely remove all source codes and update on the new: svn checkout svn://svn.freebsd.org/base/head /usr/src I have previously also used this type of update ... :( sorry for the noise :( From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 01:31:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C81B1065672 for ; Fri, 5 Nov 2010 01:31:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A0BBA8FC14 for ; Fri, 5 Nov 2010 01:31:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFALv60kyDaFvO/2dsb2JhbACDKZBCjnWsMJEChFRzBIpV X-IronPort-AV: E=Sophos;i="4.58,299,1286164800"; d="scan'208";a="97858248" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Nov 2010 21:31:30 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 732DDB3F4C; Thu, 4 Nov 2010 21:31:30 -0400 (EDT) Date: Thu, 4 Nov 2010 21:31:30 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <430617549.130565.1288920690389.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101104003906.GC14740@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_130564_31585594.1288920690387" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 01:31:32 -0000 ------=_Part_130564_31585594.1288920690387 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > > If the counter was not wrapped, it seem you lost more than 10% out of > total RX frames. This is a lot loss and there should be a way to > mitigate it. > I've attached a patch (to the if_re.c in head, not your patched variant) that works a lot better (about 5Mbytes/sec read rate). To get that, I had to disable msi and not clear the RL_IMR register in re_intr(). I suspect that a packet would be received between when the bits in RL_IMR were cleared and when they were set at the end of re_int_task() and those were getting lost. This patch doesn't completely fix the problem. (I added your stats collecting stuff to the if_re.c in head and attached the result, which still shows some lost packets. One thought is clearing the bits in RL_ISR in re_intr() instead of re_int_task(), but then I can't see a good way to pass the old value of the status reg. through to re_int_task()? The patch doesn't help when msi is enabled and when I played with your patched variant, I got it to hang when RL_IMR wasn't cleared. I've attached the patch and stats. I might play around with it some more tomorrow, rick ps: If you have hardware to test re with, you want to do an NFS mount and then read a large file when nothing else is happening on the machine, to see if you can reproduce the problem. pss: All tests done with a kernel that does not have option DEVICE_POLLING. ------=_Part_130564_31585594.1288920690387 Content-Type: text/x-patch; name=if_re.c.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=if_re.c.patch LS0tIGlmX3JlLmMub3JpZwkyMDEwLTExLTAzIDE4OjQ5OjI5LjAwMDAwMDAwMCAtMDQwMA0KKysr IGlmX3JlLmMJMjAxMC0xMS0wNCAyMTowNDozNC4wMDAwMDAwMDAgLTA0MDANCkBAIC0xNTYsNyAr MTU2LDcgQEANCiAjaW5jbHVkZSAibWlpYnVzX2lmLmgiDQogDQogLyogVHVuYWJsZXMuICovDQot c3RhdGljIGludCBtc2lfZGlzYWJsZSA9IDA7DQorc3RhdGljIGludCBtc2lfZGlzYWJsZSA9IDE7 DQogVFVOQUJMRV9JTlQoImh3LnJlLm1zaV9kaXNhYmxlIiwgJm1zaV9kaXNhYmxlKTsNCiBzdGF0 aWMgaW50IHByZWZlcl9pb21hcCA9IDA7DQogVFVOQUJMRV9JTlQoImh3LnJlLnByZWZlcl9pb21h cCIsICZwcmVmZXJfaW9tYXApOw0KQEAgLTIxNzksNyArMjE3OSw2IEBADQogCXN0YXR1cyA9IENT Ul9SRUFEXzIoc2MsIFJMX0lTUik7DQogCWlmIChzdGF0dXMgPT0gMHhGRkZGIHx8IChzdGF0dXMg JiBSTF9JTlRSU19DUExVUykgPT0gMCkNCiAgICAgICAgICAgICAgICAgcmV0dXJuIChGSUxURVJf U1RSQVkpOw0KLQlDU1JfV1JJVEVfMihzYywgUkxfSU1SLCAwKTsNCiANCiAJdGFza3F1ZXVlX2Vu cXVldWVfZmFzdCh0YXNrcXVldWVfZmFzdCwgJnNjLT5ybF9pbnR0YXNrKTsNCiANCg== ------=_Part_130564_31585594.1288920690387 Content-Type: text/plain; name=newre.stats Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=newre.stats cmUwIHN0YXRpc3RpY3M6DQpUcmFuc21pdCBnb29kIGZyYW1lcyA6IDgzMzIwDQpSZWNlaXZlIGdv b2QgZnJhbWVzIDogMTM2MTU4DQpUeCBlcnJvcnMgOiAwDQpSeCBlcnJvcnMgOiAwDQpSeCBtaXNz ZWQgZnJhbWVzIDogMjY2Ng0KUnggZnJhbWUgYWxpZ25tZW50IGVycnMgOiAwDQpUeCBzaW5nbGUg Y29sbGlzaW9ucyA6IDANClR4IG11bHRpcGxlIGNvbGxpc2lvbnMgOiAwDQpSeCB1bmljYXN0IGZy YW1lcyA6IDEzNjE1Nw0KUnggYnJvYWRjYXN0IGZyYW1lcyA6IDANClJ4IG11bHRpY2FzdCBmcmFt ZXMgOiAxDQpUeCBhYm9ydHMgOiAwDQpUeCB1bmRlcnJ1bnMgOiAwDQo= ------=_Part_130564_31585594.1288920690387-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 02:32:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BCE21065670 for ; Fri, 5 Nov 2010 02:32:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 073A68FC12 for ; Fri, 5 Nov 2010 02:32:00 +0000 (UTC) Received: by iwn39 with SMTP id 39so2233628iwn.13 for ; Thu, 04 Nov 2010 19:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=n9xecjTwCH0yLw3qMMVieYQ0TWPpEG6xjjeNC+TXt3U=; b=VtDxWFJKtsutlj9aEkwcJCiBhEXsgXd0HnspnTyVzjUvN/tlj7oLcAEeSBQr6++juY nNJD5O6AeTLxpHZ8XKuGbj16ydZb7L6jMLcPEmLYlkHpBWCzA5OA1nQnw5oozGz4Br/T FExqOLFqvioozBKUQFY6DJuEHCNq0eqY6Tu6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=DZKYUU3vMEd4aRT6pdpgDCEwLP21Ti2Aii8rb5wTEl01cDUaKFWvIbgPYsYwb5/bM8 RW62K7UG5pP3iRuBqDCgqwXRBrg3RmA92HiHo/Qsy2mv+pFxTc4w9Mk77WHy7RT0T4gU qqVsPgChRSoko7q/M3CWk+NoR7QnOsZR34sFE= Received: by 10.231.85.138 with SMTP id o10mr1237461ibl.165.1288924320394; Thu, 04 Nov 2010 19:32:00 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id fw4sm623288ibb.19.2010.11.04.19.31.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 19:31:58 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 4 Nov 2010 19:31:53 -0700 From: Pyun YongHyeon Date: Thu, 4 Nov 2010 19:31:53 -0700 To: Rick Macklem Message-ID: <20101105023153.GA20301@michelle.cdnetworks.com> References: <20101104003906.GC14740@michelle.cdnetworks.com> <430617549.130565.1288920690389.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <430617549.130565.1288920690389.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 02:32:01 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote: > > > > If the counter was not wrapped, it seem you lost more than 10% out of > > total RX frames. This is a lot loss and there should be a way to > > mitigate it. > > > I've attached a patch (to the if_re.c in head, not your patched variant) > that works a lot better (about 5Mbytes/sec read rate). To get that, I > had to disable msi and not clear the RL_IMR register in re_intr(). I > suspect that a packet would be received between when the bits in RL_IMR > were cleared and when they were set at the end of re_int_task() and those > were getting lost. > > This patch doesn't completely fix the problem. (I added your stats collecting > stuff to the if_re.c in head and attached the result, which still shows some lost packets. One > thought is clearing the bits in RL_ISR in re_intr() instead of re_int_task(), > but then I can't see a good way to pass the old value of the status reg. > through to re_int_task()? > Hmm, I still don't understand how the patch mitigates the issue. :-( The patch does not disable interrupts in interrupt handler so taskqueue runs with interrupt enabled. This may ensure not loosing interrupts but it may also generate many interrupts. By chance, did you check number of interrupts generated with/without your patch? The only guess I have at the moment is the writing RL_IMR in interrupt handler at the end of taskqueue might be not immediately reflected so controller can loose interrupts for the time window. Would you try attach patch and let me know it makes any difference? > The patch doesn't help when msi is enabled and when I played with your > patched variant, I got it to hang when RL_IMR wasn't cleared. > > I've attached the patch and stats. > > I might play around with it some more tomorrow, rick Thanks for your work. > ps: If you have hardware to test re with, you want to do an NFS mount > and then read a large file when nothing else is happening on the > machine, to see if you can reproduce the problem. It seems I'm not able to reproduce it on my box(8168B GigE). > pss: All tests done with a kernel that does not have option DEVICE_POLLING. Ok, I have to commit statistics counter patch since it seems to help narrowing down driver issue. > re0 statistics: > Transmit good frames : 83320 > Receive good frames : 136158 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 2666 > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 136157 > Rx broadcast frames : 0 > Rx multicast frames : 1 > Tx aborts : 0 > Tx underruns : 0 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.intr.patch2" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 214692) +++ sys/dev/re/if_re.c (working copy) @@ -2254,6 +2254,7 @@ } CSR_WRITE_2(sc, RL_IMR, RL_INTRS_CPLUS); + CSR_READ_2(sc, RL_IMR); } static int --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 04:29:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847AA106566B; Fri, 5 Nov 2010 04:29:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id C97DB8FC15; Fri, 5 Nov 2010 04:29:24 +0000 (UTC) Received: from [93.104.81.246] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PEDvW-0006FF-Qo; Fri, 05 Nov 2010 05:29:23 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA54TNEv001954; Fri, 5 Nov 2010 05:29:23 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA54TMq6001953; Fri, 5 Nov 2010 05:29:22 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 5 Nov 2010 05:29:22 +0100 From: Matthias Apitz To: Alexander Motin Message-ID: <20101105042922.GA1883@current.Sisis.de> References: <4CD337DA.7030902@FreeBSD.org> <20101104230735.GA6686@current.Sisis.de> <4CD33E0B.1070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD33E0B.1070304@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.81.246 Cc: FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 04:29:25 -0000 El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: > Matthias Apitz wrote: > > El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: > >> Matthias Apitz wrote: > >>> mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as > >>> well the output of verbose messages grep'ed for pcm and hdac. > >> Your CODEC configured to provide built-in microphone on separate device > >> pcm1. You may record from there (Skype allows to choose device) or > >> reconfigure CODEC using hints. > > > > In Skype in let me choose between > > /dev/dsp > > /dev/dsp0 > > /dev/dsp1 > > > > When I set mic to /dev/dsp0 it records from the jack (headphone mic), > > when I set it to /dev/dsp1 there is no recording. And the mixer for the > > pcm1 says: > > > > # mixer -f /dev/mixer1 > > Mixer rec is currently set to 100:100 > > Mixer monitor is currently set to 100:100 > > Recording source: monitor > > That's strange. I would expect it working. > > > Would you be so kind and give me the lines for reconfigure CODEC using > > hints? I'm really lost in this. > > OK, try this: > hint.hdac.0.cad0.nid18.config="as=2 seq=1" Thank you. The result of this is: 1) mixer(1) is now showing a line 'monitor' in addition and as recording source: # mixer Mixer vol is currently set to 83:83 Mixer pcm is currently set to 78:78 Mixer mic is currently set to 87:87 Mixer mix is currently set to 81:81 Mixer rec is currently set to 65:65 Mixer igain is currently set to 78:78 Mixer ogain is currently set to 65:65 Mixer monitor is currently set to 87:87 Recording source: mix, monitor 2) in Skype I can only choos between /dev/dsp and /dev/dsp0 and /dev/mixer1 does not exist anymore; 3) recording still works only from jack, not from build-in mic; 4) if I set 'mixer =rec monitor' it does not even record from the jack; I even checked the BIOS if there is something to disable the mic, but it isn't. Thanks for your help in any case. Btw: If this does matter, it is with kernel r214444. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 07:27:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7FB10656C2; Fri, 5 Nov 2010 07:27:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 91E078FC1A; Fri, 5 Nov 2010 07:27:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07934; Fri, 05 Nov 2010 09:27:15 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PEGhf-000HVT-Ky; Fri, 05 Nov 2010 09:27:15 +0200 Message-ID: <4CD3B1D2.30003@icyb.net.ua> Date: Fri, 05 Nov 2010 09:27:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-x11@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: radeon_cp_texture: page fault with non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 07:27:18 -0000 I use FreeSBD head and KDE 4 with all the bells and whistles enabled. Apparently recent KDE update has enabled even more of them, because I started to have panics with a kernel that has INVARIANTS and WITNESS enabled. The panic: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xffffff0001b968a0) locked @ /usr/src/sys/dev/drm/drm_drv.c:791 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801b8afa = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff803a7afa = kdb_backtrace+0x3a _witness_debugger() at 0xffffffff803bd49c = _witness_debugger+0x2c witness_warn() at 0xffffffff803bed32 = witness_warn+0x322 trap() at 0xffffffff8054639f = trap+0x39f calltrap() at 0xffffffff80530688 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff8054411d, rsp = 0xffffff81241917f0, rbp = 0xffffff8124191870 --- copyin() at 0xffffffff8054411d = copyin+0x3d radeon_cp_texture() at 0xffffffff8022fcc7 = radeon_cp_texture+0x167 drm_ioctl() at 0xffffffff8020fa78 = drm_ioctl+0x318 devfs_ioctl_f() at 0xffffffff802dd739 = devfs_ioctl_f+0x109 kern_ioctl() at 0xffffffff803c1197 = kern_ioctl+0x1f7 ioctl() at 0xffffffff803c1358 = ioctl+0x168 syscallenter() at 0xffffffff803b584e = syscallenter+0x26e syscall() at 0xffffffff80545f12 = syscall+0x42 Xfast_syscall() at 0xffffffff80530962 = Xfast_syscall+0xe2 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801f96a1c, rsp = 0x7fffffffe7a8, rbp = 0xc020644e --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x832372000 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8054411d stack pointer = 0x28:0xffffff81241917f0 frame pointer = 0x28:0xffffff8124191870 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 3 current process = 3439 (initial thread) trap number = 12 panic: page fault cpuid = 0 The panic is quite obvious: drmdev mutex is taken and held in drm_ioctl() and radeon_cp_texture() can perform copyin and/or copyout, so it's a matter of a chance (or proper workload) to hit a page fault there. What's not obvious is how to properly fix this. Any ideas? Probably less important is what started to trigger the problem. Because the code hasn't been changed in ages and I have never seen this issue before. But, d'oh, it seems that this issue has been already reported: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg67757.html I will appreciate any help. Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 07:34:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB451065698 for ; Fri, 5 Nov 2010 07:34:35 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id D0DC18FC18 for ; Fri, 5 Nov 2010 07:34:34 +0000 (UTC) Received: from [93.104.81.246] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PEGoh-0001bC-FA; Fri, 05 Nov 2010 08:34:32 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA57YVUl002799; Fri, 5 Nov 2010 08:34:31 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA57YVW5002798; Fri, 5 Nov 2010 08:34:31 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 5 Nov 2010 08:34:30 +0100 From: Matthias Apitz To: Ed Schouten Message-ID: <20101105073430.GA2765@current.Sisis.de> References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101102193250.GU81149@hoeg.nl> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.81.246 Cc: freebsd-current@freebsd.org Subject: utmpx (was: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 07:34:35 -0000 Hello, I found another port lacking utmpx support: # cd /usr/ports/security/chkrootkit # make ===> chkrootkit-0.49 is marked as broken: fails to build with new utmpx. *** Error code 1 matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 07:39:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2A0106564A; Fri, 5 Nov 2010 07:39:15 +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 7537C8FC08; Fri, 5 Nov 2010 07:39:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA08050; Fri, 05 Nov 2010 09:39:13 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PEGtE-000HWJ-No; Fri, 05 Nov 2010 09:39:12 +0200 Message-ID: <4CD3B4A0.6060207@freebsd.org> Date: Fri, 05 Nov 2010 09:39:12 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <4CD2656D.8050701@icyb.net.ua> <4CD2C706.6000100@icyb.net.ua> In-Reply-To: <4CD2C706.6000100@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: processes stuck on a vnode lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 07:39:15 -0000 on 04/11/2010 16:45 Andriy Gapon said the following: > on 04/11/2010 09:49 Andriy Gapon said the following: >> >> I see a few processes stuck on the same vnode, trying to take or to upgrade to >> an exclusive lock on it, while the lock data suggests that it is already >> shared-locked. The vnode is a root vnode of one of ZFS filesystems (it's not a >> global root). >> >> I couldn't find any (other) threads that could actually hold the vnode lock, but >> lock shared count is suspiciously or coincidentally the same as number of >> threads in zfs_root call. > > BTW, I still have the system alive and online, so if anyone has ideas I can try them. > The kernel is not live now, but I have saved it and vmcore of the system. Kostik, just a pure guesswork here - could r214049 have something to do with this? I looked at the change and it looks completely correct - I don't think that a vnode lock can be leaked by that code. But, OTOH, it has some special handling for VV_ROOT, it's in NFS code and and it's in a right time-frame, so just asking. Here's a link to the start of this report thread: http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/10659/focus=128893 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 08:50:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3771065670 for ; Fri, 5 Nov 2010 08:50:39 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpb-ews02.kpnxchange.com (cpsmtpb-ews02.kpnxchange.com [213.75.39.5]) by mx1.freebsd.org (Postfix) with ESMTP id 533C08FC17 for ; Fri, 5 Nov 2010 08:50:35 +0000 (UTC) Received: from cpbrm-ews33.kpnxchange.com ([10.94.84.164]) by cpsmtpb-ews02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 09:38:31 +0100 Received: from CPSMTPM-EML105.kpnxchange.com ([195.121.3.9]) by cpbrm-ews33.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 09:38:31 +0100 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Fri, 5 Nov 2010 09:38:30 +0100 Received: from hillary.van-laarhoven.org (Hillary.van-laarhoven.org [10.66.0.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by uitsmijter.van-laarhoven.org (Postfix) with ESMTPSA id 01BBB4080; Fri, 5 Nov 2010 09:38:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nick Hibma In-Reply-To: <20101024231642.GB2123@mark-laptop-bsd.mark-home> Date: Fri, 5 Nov 2010 09:38:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101024231119.GA2123@mark-laptop-bsd.mark-home> <20101024231642.GB2123@mark-laptop-bsd.mark-home> To: Mark Johnston X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-15.4 required=5.0 tests=J_CHICKENPOX_52, UNPARSEABLE_RELAY,USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on uitsmijter.van-laarhoven.org X-OriginalArrivalTime: 05 Nov 2010 08:38:31.0097 (UTC) FILETIME=[D351AA90:01CB7CC4] X-RcptDomain: freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: [Patch] libfetch - closing the cached FTP connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 08:50:40 -0000 Mark, My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd? fcntl(fd, F_SETFD, FD_CLOEXEC);=20 It doesn't sound like you ever want to have a cached connection be = copied into the child. Mum and child calling daddy using the same phone = line isn't going to make the conversation any easier for daddy. Cheers, Nick On 25 Oct 2010, at 01:16, Mark Johnston wrote: > Hello, >=20 > We've run into problems with pkg_add because of some caching behaviour > in libfetch. Specifically, after an FTP transfer, a connection to the > FTP server is held open by the cached_connection pointer in ftp.c. = Thus, > if one requests a file with fetchGetFTP() and later closes the > connection with fclose(), a socket is still held open, and the > descriptor is copied to any child processes. >=20 > What was apparently happening was that we were using pkg_add to = install > a package whose install script started a daemon, which consequently = kept > open a connection to our FTP server. This is "fixed" in our tree with = a > closefrom(2) in pkg_install at an appropriate point, but I thought = that > libfetch should provide some way of forcing a close on the cached > connection so that the above hack isn't necessary. >=20 > My solution is provided in a patch below. It's not particularly = elegant, > but I can't see a better way to go about it. I was hoping to get some > feedback and to see if anyone can come up with a better approach. I'll > also update the libfetch man page if the patch below is acceptable. >=20 > Thanks, > -Mark >=20 > diff --git a/lib/libfetch/fetch.h b/lib/libfetch/fetch.h > index 11a3f77..d379e63 100644 > --- a/lib/libfetch/fetch.h > +++ b/lib/libfetch/fetch.h > @@ -109,6 +109,7 @@ FILE *fetchGetFTP(struct url *, const = char *); > FILE *fetchPutFTP(struct url *, const char *); > int fetchStatFTP(struct url *, struct url_stat *, const = char *); > struct url_ent *fetchListFTP(struct url *, const char *); > +void fetchCloseCachedFTP(); >=20 > /* Generic functions */ > FILE *fetchXGetURL(const char *, struct url_stat *, const = char *); > diff --git a/lib/libfetch/ftp.c b/lib/libfetch/ftp.c > index 0983a76..746ad54 100644 > --- a/lib/libfetch/ftp.c > +++ b/lib/libfetch/ftp.c > @@ -1204,3 +1204,12 @@ fetchListFTP(struct url *url __unused, const = char *flags __unused) > warnx("fetchListFTP(): not implemented"); > return (NULL); > } > + > +/* > + * Force close the cached connection. > + */ > +void > +fetchCloseCachedFTP() > +{ > + ftp_disconnect(cached_connection); > +} > diff --git a/usr.sbin/pkg_install/lib/url.c = b/usr.sbin/pkg_install/lib/url.c > index 914ce39..68f31bb 100644 > --- a/usr.sbin/pkg_install/lib/url.c > +++ b/usr.sbin/pkg_install/lib/url.c > @@ -163,5 +163,6 @@ fileGetURL(const char *base, const char *spec, int = keep_package) > printf("tar command returns %d status\n", WEXITSTATUS(pstat)); > if (rp && (isatty(0) || Verbose)) > printf(" Done.\n"); > + fetchCloseCachedFTP(); > return rp; > } > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 08:56:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFEAB106564A for ; Fri, 5 Nov 2010 08:56:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF7A8FC08 for ; Fri, 5 Nov 2010 08:56:28 +0000 (UTC) Received: by wyb34 with SMTP id 34so869335wyb.13 for ; Fri, 05 Nov 2010 01:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Qqg/9aYAqsu/FqT/IWk+dft0GRv9RHcA+K1uqpRlU4g=; b=QWOoaihhbqKiNEegIMfl4ZM9Nge9LGMYC1RMyuE5kFTpDZsjkPHaJwnAX9qdyNgpdI IqhMHhzv4KcxJrcvh68Sch5z6qCzxlZID5MJ9U6Ivh9Uww23q0K1qRLPD0BPTOn5I/pu ZcXRNhuFJnKl15l99RNgoo6dqz05sarSlUGNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mHMKpp9ChU2ByDip+7LhHGalfnHiwhn4AzHkgs2jfjIubsV2mqpPXqr1OluhEOPZTU XvtSScJqU2b2MwMJVFBxidBp4LvjiZRv2k5WhQaYXoP4/mzeX/Xe4J/biiw5Fek/gm3L i31P4mDxYW+yEiT8IMxojSKnV8Cf0QTHLMCNU= MIME-Version: 1.0 Received: by 10.216.82.197 with SMTP id o47mr1827368wee.45.1288947387160; Fri, 05 Nov 2010 01:56:27 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 01:56:27 -0700 (PDT) In-Reply-To: References: <20101024231119.GA2123@mark-laptop-bsd.mark-home> <20101024231642.GB2123@mark-laptop-bsd.mark-home> Date: Fri, 5 Nov 2010 01:56:27 -0700 X-Google-Sender-Auth: 8WhUw9TOsoCyV-H6LQGSa0qUS7U Message-ID: From: Garrett Cooper To: Nick Hibma Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Mark Johnston Subject: Re: [Patch] libfetch - closing the cached FTP connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 08:56:29 -0000 On Fri, Nov 5, 2010 at 1:38 AM, Nick Hibma wrote: > Mark, > > My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd? > > =A0 =A0 =A0 =A0fcntl(fd, F_SETFD, FD_CLOEXEC); > > It doesn't sound like you ever want to have a cached connection be copied= into the child. Mum and child calling daddy using the same phone line isn'= t going to make the conversation any easier for daddy. > > Cheers, > > Nick > > On 25 Oct 2010, at 01:16, Mark Johnston wrote: > >> Hello, >> >> We've run into problems with pkg_add because of some caching behaviour >> in libfetch. Specifically, after an FTP transfer, a connection to the >> FTP server is held open by the cached_connection pointer in ftp.c. Thus, >> if one requests a file with fetchGetFTP() and later closes the >> connection with fclose(), a socket is still held open, and the >> descriptor is copied to any child processes. >> >> What was apparently happening was that we were using pkg_add to install >> a package whose install script started a daemon, which consequently kept >> open a connection to our FTP server. This is "fixed" in our tree with a >> closefrom(2) in pkg_install at an appropriate point, but I thought that >> libfetch should provide some way of forcing a close on the cached >> connection so that the above hack isn't necessary. >> >> My solution is provided in a patch below. It's not particularly elegant, >> but I can't see a better way to go about it. I was hoping to get some >> feedback and to see if anyone can come up with a better approach. I'll >> also update the libfetch man page if the patch below is acceptable. >> >> Thanks, >> -Mark >> >> diff --git a/lib/libfetch/fetch.h b/lib/libfetch/fetch.h >> index 11a3f77..d379e63 100644 >> --- a/lib/libfetch/fetch.h >> +++ b/lib/libfetch/fetch.h >> @@ -109,6 +109,7 @@ FILE =A0 =A0 =A0 =A0 =A0 =A0 =A0*fetchGetFTP(struct = url *, const char *); >> FILE =A0 =A0 =A0 =A0 =A0*fetchPutFTP(struct url *, const char *); >> int =A0 =A0 =A0 =A0 =A0 =A0fetchStatFTP(struct url *, struct url_stat *,= const char *); >> struct url_ent =A0 =A0 =A0 =A0*fetchListFTP(struct url *, const char *); >> +void =A0 =A0 =A0 =A0 =A0fetchCloseCachedFTP(); >> >> /* Generic functions */ >> FILE =A0 =A0 =A0 =A0 =A0*fetchXGetURL(const char *, struct url_stat *, c= onst char *); >> diff --git a/lib/libfetch/ftp.c b/lib/libfetch/ftp.c >> index 0983a76..746ad54 100644 >> --- a/lib/libfetch/ftp.c >> +++ b/lib/libfetch/ftp.c >> @@ -1204,3 +1204,12 @@ fetchListFTP(struct url *url __unused, const char= *flags __unused) >> =A0 =A0 =A0 warnx("fetchListFTP(): not implemented"); >> =A0 =A0 =A0 return (NULL); >> } >> + >> +/* >> + * Force close the cached connection. >> + */ >> +void >> +fetchCloseCachedFTP() >> +{ >> + =A0 =A0 ftp_disconnect(cached_connection); >> +} >> diff --git a/usr.sbin/pkg_install/lib/url.c b/usr.sbin/pkg_install/lib/u= rl.c >> index 914ce39..68f31bb 100644 >> --- a/usr.sbin/pkg_install/lib/url.c >> +++ b/usr.sbin/pkg_install/lib/url.c >> @@ -163,5 +163,6 @@ fileGetURL(const char *base, const char *spec, int k= eep_package) >> =A0 =A0 =A0 printf("tar command returns %d status\n", WEXITSTATUS(pstat)= ); >> =A0 =A0 if (rp && (isatty(0) || Verbose)) >> =A0 =A0 =A0 printf(" Done.\n"); >> + =A0 =A0fetchCloseCachedFTP(); >> =A0 =A0 return rp; >> } There are a lot of corner cases not caught with libpkg and pkg_install that should be due to the fact that ports and pkg_install are spaghetti code. That being said, small patches submitted to portmgr via send-pr are more than welcome as anything that would help improve binary packages is more than welcome. I do agree with Nick though... it's better that the issue be `fixed' in libpkg/pkg_install, not libfetch in this case. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 10:39:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCEE1065675; Fri, 5 Nov 2010 10:39:43 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id C845D8FC15; Fri, 5 Nov 2010 10:39:42 +0000 (UTC) Received: from [93.104.81.246] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PEJhr-0007LR-Vw; Fri, 05 Nov 2010 11:39:40 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA5Adbpq003766; Fri, 5 Nov 2010 11:39:38 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA5Adb2u003765; Fri, 5 Nov 2010 11:39:37 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 5 Nov 2010 11:39:37 +0100 From: Matthias Apitz To: Alexander Motin Message-ID: <20101105103937.GA3744@current.Sisis.de> References: <4CD337DA.7030902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD337DA.7030902@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 93.104.81.246 Cc: FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 10:39:43 -0000 El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: > Matthias Apitz wrote: > > ... > > Btw II: Is there some test recording software that let me just record > > from /dev/dspX and play it back (to not use Skype for such tests)? > > dd? :) Also audio/rawrec. Indeed, a # dd if=/dev/dsp0.0 > file records and # cat file > /dev/dsp0.0 plays fine the recorded voice... but only from Jack :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 11:59:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A980D106566B for ; Fri, 5 Nov 2010 11:59:03 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 60F3D8FC18 for ; Fri, 5 Nov 2010 11:59:03 +0000 (UTC) Received: by gxk9 with SMTP id 9so2156517gxk.13 for ; Fri, 05 Nov 2010 04:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=xBj7YTEwuM5/a7Gx0CWKwlV3aYRCYBGoClOcc3q7URY=; b=VOyxiMYZii5n75LZd8cudhJ4QlwPtHSJ6cwKyXA6SEN/fBRqpM5ieeDQyuod8MA4r/ yQfoOLr407xJKbe3SJKajht7dKKbaQd/vXVfXpCFZygElG9LWjAXdzLMjGnv5GSC4f3m FenHWN8Pcy3thPB2j5ALUX6rktWnm7ECJ52nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; b=uF9xLISL4vCepwC1zXUdJVSH6ZlTzT4NGF7Mf5pmFRT44pcG0RZ4VAXOBWmBxwyGMP ghunXei8AamZK7c/bIW4S/DKOTwuDlnQiWXbBZOUy6MqKOldCcEq4+zQdYZ+PGuLQYhr 7CdCojOFuw3EMxSCuuDCy2fNpNVt63lRndeYY= Received: by 10.150.186.10 with SMTP id j10mr3267851ybf.364.1288958342599; Fri, 05 Nov 2010 04:59:02 -0700 (PDT) Received: from localhost (spftor1.privacyfoundation.de [87.118.104.203]) by mx.google.com with ESMTPS id q41sm893722ybk.13.2010.11.05.04.59.00 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 04:59:02 -0700 (PDT) From: Anonymous To: freebsd-current@freebsd.org References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> <20101105073430.GA2765@current.Sisis.de> Date: Fri, 05 Nov 2010 14:58:49 +0300 In-Reply-To: <20101105073430.GA2765@current.Sisis.de> (Matthias Apitz's message of "Fri, 5 Nov 2010 08:34:30 +0100") Message-ID: <86wros3rt2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: utmpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 11:59:03 -0000 Matthias Apitz writes: > I found another port lacking utmpx support: > > # cd /usr/ports/security/chkrootkit > # make > ===> chkrootkit-0.49 is marked as broken: fails to build with new utmpx. > *** Error code 1 There are more, see ports listed under utmpx.h in http://wiki.freebsd.org/PortsBrokenOnCurrent From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 12:09:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82FC1106566B for ; Fri, 5 Nov 2010 12:09:07 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9CB8FC14 for ; Fri, 5 Nov 2010 12:09:07 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 47CBD2A28C30; Fri, 5 Nov 2010 13:09:06 +0100 (CET) Date: Fri, 5 Nov 2010 13:09:06 +0100 From: Ed Schouten To: Anonymous Message-ID: <20101105120906.GD2054@hoeg.nl> References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> <20101105073430.GA2765@current.Sisis.de> <86wros3rt2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJcv+A0YCCLh2VIg" Content-Disposition: inline In-Reply-To: <86wros3rt2.fsf@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: utmpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 12:09:07 -0000 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Anonymous , 20101105 12:58: > There are more, see ports listed under utmpx.h in >=20 > http://wiki.freebsd.org/PortsBrokenOnCurrent It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --ZJcv+A0YCCLh2VIg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzT8+IACgkQ52SDGA2eCwVc5gCcCzRdJ6986d+hnu3xAxQHjcPk mpkAnj+HelFGkTTyjBPapX9TpPSBzgcC =rTE1 -----END PGP SIGNATURE----- --ZJcv+A0YCCLh2VIg-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 12:49:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0A8106566B for ; Fri, 5 Nov 2010 12:49:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7B89B8FC08 for ; Fri, 5 Nov 2010 12:49:09 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 2CF0756026; Fri, 5 Nov 2010 12:32:35 +0000 (UTC) Date: Fri, 5 Nov 2010 12:32:35 +0000 From: Mark Linimon To: Ed Schouten Message-ID: <20101105123235.GA12899@lonesome.com> References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> <20101105073430.GA2765@current.Sisis.de> <86wros3rt2.fsf@gmail.com> <20101105120906.GD2054@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101105120906.GD2054@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Anonymous , freebsd-current@freebsd.org Subject: Re: utmpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 12:49:09 -0000 On Fri, Nov 05, 2010 at 01:09:06PM +0100, Ed Schouten wrote: > It should be noted that that list is a bit pessimistic, since various > ports have been fixed in the mean time. Updates welcomed :-) mcl From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 13:02:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB301106566C; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97F968FC15; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 44EFF46B03; Fri, 5 Nov 2010 09:02:49 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13C648A009; Fri, 5 Nov 2010 09:02:48 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 08:58:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011050858.33568.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 09:02:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:02:50 -0000 On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> I think that if a task is currently executing, then there should be a drain > >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> you implement this? > > > > I agree, this would also be consistent with the callout_*() API if you had > > both "stop()" and "drain()" methods. > > Here's my proposed code. Note that this builds but is not yet tested. > > > Implement a taskqueue_cancel(9), to cancel a task from a queue. > > Requested by: hps > Original code: jeff > MFC after: 1 week > > > http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a "race" where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 13:14:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A76EE106564A for ; Fri, 5 Nov 2010 13:14:25 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 398AC8FC0A for ; Fri, 5 Nov 2010 13:14:25 +0000 (UTC) Received: by wyb34 with SMTP id 34so1084704wyb.13 for ; Fri, 05 Nov 2010 06:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CFQis5p/2R52qTUXlF/YvdEHtuFSQZIEBrMTxxS96xA=; b=S5jRQeVsvgVLlwe+EENCGnEsUOGPRJIdelaquGxcEXFw1tDv4rPfgEHjbk4v0YhikN CWxdxwodPjbmW4wkrZi4ME7K3I+jeFl6z2DpiAtY8zX8N2TYkfvNQpercfbFx66AlMKF rlyVYp7m3MStFu2rkyi4CNlYtQg9OyGL8LLig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=F4/zH+YQXRlSmw/sz7HVxi9RG/w1srY9KzhVNl98RmAoUgYClsqyAZ+Rl3dSbGeEoQ wpMa9RimUEt8ELS72gld/CEyJlsNX2b0U/GmASF+RwzvgXP1B3ymc+ENvZLZUUKjBvI2 6VKoi3YPxkUtUKoT7euFYjxFMu6/HJW0ccsSk= Received: by 10.227.134.142 with SMTP id j14mr1951853wbt.228.1288961380898; Fri, 05 Nov 2010 05:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.10 with HTTP; Fri, 5 Nov 2010 05:49:20 -0700 (PDT) In-Reply-To: <20101105120906.GD2054@hoeg.nl> References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> <20101105073430.GA2765@current.Sisis.de> <86wros3rt2.fsf@gmail.com> <20101105120906.GD2054@hoeg.nl> From: Renato Botelho Date: Fri, 5 Nov 2010 10:49:20 -0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Anonymous , freebsd-current@freebsd.org Subject: Re: utmpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:14:25 -0000 On Fri, Nov 5, 2010 at 10:09 AM, Ed Schouten wrote: > * Anonymous , 20101105 12:58: >> There are more, see ports listed under utmpx.h in >> >> =A0 http://wiki.freebsd.org/PortsBrokenOnCurrent > > It should be noted that that list is a bit pessimistic, since various > ports have been fixed in the mean time. Ed, I've made a patch for chkrootkit [1], it's building, but i didn't test if it's working. Could you take a look at it? [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Regards --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 13:48:03 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3EB91065675; Fri, 5 Nov 2010 13:48:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B67B8FC08; Fri, 5 Nov 2010 13:48:02 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13898; Fri, 05 Nov 2010 15:48:01 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD40B10.5090205@icyb.net.ua> Date: Fri, 05 Nov 2010 15:48:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: stuck in cam with bad optical media X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:48:04 -0000 [I am probably just having an unlucky day.] I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some problems. First, the burning process got stuck at the same percentage and the drive started to make unusual sounds. Then, the following messages appeared in system log: kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No seek complete) kernel: ahcich5: Timeout on slot 7 kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 serr 00000000 kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back After that growisofs either remained or became stuck in the following state: 42433 100119 growisofs initial thread mi_switch+0x1de sleepq_switch+0xdb sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be syscall+0x41 Xfast_syscall+0xe2 Any commands that tried to access the device (cdcontrol eject, camcontrol reset 5:0:0) also got stuck. Only reboot helped to recover the device. I understand that bad media is bad, but it happens. I think that cam and ahci typically recover from errors/timeouts, so somehting must have gone wrong in this case. P.S. I have already thrown out the bad disk - irritation won over reason when that happened, unfortunately :( -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 13:50:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF81106564A; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3829D8FC16; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) Received: by gxk9 with SMTP id 9so2227881gxk.13 for ; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yIl7S6Pklw/SCH6aYHWJXvN1x24XuLiY+mRktHJI5+4=; b=B/d0MBW2L/87bSreHOi3atmmuFVloL1pVxaxy5j95LuTPr2Qna9mmEz8a6B6sNc/am wFaAnFP49R4HlckuKsZwR+vyUW1IvX1FG7WUV3GrUjnBKnkAylx8K6UedAf3W3+nn874 Ab/uuQEaD93oxKb+UItcowNAp/te7CFMjvVco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MUXkDTTBUlNY4H2xPpUDjbHUCB5wzujANiIZx0H+szwh/fLMoBgl6vMEEJ1fX56+fb AIW1hL81CByB+uxarwwycFNjXyDwVGfLu6qiBag2mSwzIhfwwA8cVYyilsg9KJx516N1 B0Dlol/aUiAEUF13b3pUrQlQ/4Tx8haFpre7w= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1088729icb.477.1288965010417; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 06:50:10 -0700 (PDT) In-Reply-To: <201011050858.33568.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> <201011050858.33568.jhb@freebsd.org> Date: Fri, 5 Nov 2010 06:50:10 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:50:12 -0000 On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> >> I think that if a task is currently executing, then there should be a= drain >> >> method for that. I.E. two methods: One to stop and one to cancel/drai= n. Can >> >> you implement this? >> > >> > I agree, this would also be consistent with the callout_*() API if you= had >> > both "stop()" and "drain()" methods. >> >> Here's my proposed code. =A0Note that this builds but is not yet tested. >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> Requested by: =A0 =A0 =A0 hps >> Original code: =A0 =A0 =A0jeff >> MFC after: =A01 week >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0Howeve= r, I > would prefer that it follow the semantics of callout_stop() and return tr= ue > if it stopped the task and false otherwise. =A0The Linux wrapper for > taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success (> 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAI= TOK) > for this blocking flag. =A0In the case of callout(9) we just have two fun= ctions > that pass an internal boolean to the real routine (callout_stop() and > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit > unfortunate that taskqueue_drain() already exists and has different seman= tics > than callout_drain(). =A0It would have been nice to have the two APIs mir= ror each > other instead. > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > doing: > > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about = this. Thanks, matthew > > If that works ok (I think it does), I would rather have taskqueue_cancel(= ) > always be non-blocking. =A0Even though there is a "race" where the task c= ould > be rescheduled by another thread in between cancel and drain, the race st= ill > exists since if the task could be scheduled between the two, it could als= o > be scheduled just before the call to taskqueue_cancel() (in which case a > taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it > matching the taskqueue_drain() above). =A0The caller still always has to > provide synchronization for preventing a task's execution outright via th= eir > own locking. > > -- > John Baldwin > From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 13:50:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 799FE106564A for ; Fri, 5 Nov 2010 13:50:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 10D378FC28 for ; Fri, 5 Nov 2010 13:50:26 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 71D042A28C30; Fri, 5 Nov 2010 14:50:25 +0100 (CET) Date: Fri, 5 Nov 2010 14:50:25 +0100 From: Ed Schouten To: Renato Botelho Message-ID: <20101105135025.GG2054@hoeg.nl> References: <20101102061418.GA1884@current.Sisis.de> <20101102193250.GU81149@hoeg.nl> <20101105073430.GA2765@current.Sisis.de> <86wros3rt2.fsf@gmail.com> <20101105120906.GD2054@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzX0AQGjRQPusK/O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Anonymous , freebsd-current@freebsd.org Subject: Re: utmpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:50:26 -0000 --NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Renato Botelho , 20101105 13:49: > I've made a patch for chkrootkit [1], it's building, but i didn't test if > it's working. Could you take a look at it? >=20 > [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Well, files cannot be accessed without the utmpx API. I looked at these tools and I don't think they have very little use with utmpx. Can't we just disable all utmp related tools? --=20 Ed Schouten WWW: http://80386.nl/ --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzUC6EACgkQ52SDGA2eCwVBZwCdEYedVS5By03Iit1r1SGKb1lH A/cAn3rVAhn0xyYLyePP6iK1R0RF6X9/ =Z2bz -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 14:22:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56EDB106564A; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA618FC15; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84A0246B37; Fri, 5 Nov 2010 10:22:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 806658A009; Fri, 5 Nov 2010 10:22:15 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 10:18:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051018.28860.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 10:22:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:22:17 -0000 On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> I think that if a task is currently executing, then there should be a drain > >> >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> >> you implement this? > >> > > >> > I agree, this would also be consistent with the callout_*() API if you had > >> > both "stop()" and "drain()" methods. > >> > >> Here's my proposed code. Note that this builds but is not yet tested. > >> > >> > >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> > >> Requested by: hps > >> Original code: jeff > >> MFC after: 1 week > >> > >> > >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I > > would prefer that it follow the semantics of callout_stop() and return true > > if it stopped the task and false otherwise. The Linux wrapper for > > taskqueue_cancel() can convert the return value. > > I used -EBUSY since positive return values reflect the old pending > count. ta_pending was zero'd, and I think needs to be to keep the > task sane, because all of taskqueue(9) assumes a non-zero ta_pending > means the task is queued. > > I don't know that the caller often needs to know the old value of > ta_pending, but it seems simpler to return that as the return value > and use -EBUSY than to use an optional pointer to a place to store the > old ta_pending just so we can keep the error return positive. > > Note that phk (IIRC) suggested using -error in the returns for > sbuf_drain to indicate the difference between success (> 0 bytes > drained) and an error, so FreeBSD now has precedent. I'm not entirely > sure that's a good thing, since I am not generally fond of Linux's use > of -error, but for some cases it is convenient. > > But, I'll do this one either way, just let me know if the above hasn't > convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. > > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) > > for this blocking flag. In the case of callout(9) we just have two functions > > that pass an internal boolean to the real routine (callout_stop() and > > callout_drain() are wrappers for _callout_stop_safe()). It is a bit > > unfortunate that taskqueue_drain() already exists and has different semantics > > than callout_drain(). It would have been nice to have the two APIs mirror each > > other instead. > > > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > > doing: > > > > if (!taskqueue_cancel(queue, task, M_NOWAIT) > > taskqueue_drain(queue, task); > > This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 14:35:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 439DA106564A for ; Fri, 5 Nov 2010 14:35:16 +0000 (UTC) (envelope-from freebsd-tracker-int0dh@mail.ru) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id B770D8FC13 for ; Fri, 5 Nov 2010 14:35:15 +0000 (UTC) Received: from f191.mail.ru (f191.mail.ru [217.69.128.138]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id 987F9AF6570 for ; Fri, 5 Nov 2010 17:01:32 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:Date:Mime-Version:To:From; bh=a0wtccQ9K2FylqbzSH9mSgHd50mpJ8p8HJyRK9MwYWM=; b=ZI9ODtU03/qDCW2L86yR5susyB5saiTWrew1ciBMy9ZqfLwCCfOXfPDSbDkyVMk0O6lhZQQgv+V85075IKRYnDtemQORdrNzbjsBq5Ekv+lE2VgV07m7z9iHcaQQnO7+; Received: from mail by f191.mail.ru with local id 1PEMrC-0006JB-00 for freebsd-current@freebsd.org; Fri, 05 Nov 2010 17:01:30 +0300 Received: from [93.92.200.151] by win.mail.ru with HTTP; Fri, 05 Nov 2010 17:01:30 +0300 From: sdfsdf rwerwer To: freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [93.92.200.151] Date: Fri, 05 Nov 2010 17:01:30 +0300 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Subject: (no subject) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sdfsdf rwerwer List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:35:16 -0000 Hi everybody, The following commands lead the 9.0-CURRENT kernel to crash: [root@freebsd /usr/home/int0dh]# ngctl Available commands: config get or set configuration of node at connect Connects hook of the node at to debug Get/set debugging verbosity level dot Produce a GraphViz (.dot) of the entire netgraph. help Show command summary or get more help on a specific command list Show information about all nodes mkpeer Create and connect a new node to the node at "path" msg Send a netgraph control message to the node at "path" name Assign name to the node at read Read and execute commands from a file rmhook Disconnect hook "hook" of the node at "path" show Show information about the node at shutdown Shutdown the node at status Get human readable status information from the node at types Show information about all installed node types write Send a data packet down the hook named by "hook". quit Exit program + mkpeer ksocket myhook inet/stream/tcp + msg .:myhook connect inet/127.0.0.1:22 After last command the kernel panics. Any listening TCP port can be used instead of 22. The panic occurs here (sys/kern/uipc_sockbuf.c): int sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control) { struct mbuf *m, *n, *nlast; int space = asa->sa_len; SOCKBUF_LOCK_ASSERT(sb); if (m0 && (m0->m_flags & M_PKTHDR) == 0) { panic("sbappendaddr_locked"); } I`ve tried with the custom kernel only, but I think that issue can be reproduced with GENERIC too. From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 15:18:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2005A106566B for ; Fri, 5 Nov 2010 15:18:23 +0000 (UTC) (envelope-from freebsd-tracker-int0dh@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id 93FE18FC0C for ; Fri, 5 Nov 2010 15:18:22 +0000 (UTC) Received: from f231.mail.ru (f231.mail.ru [217.69.128.161]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id 331A11309712 for ; Fri, 5 Nov 2010 17:06:24 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:Date:Mime-Version:Subject:To:From; bh=zQRdf49sM2JGqHTe92xk8cib5y/qaBZDfa5/qHtzxJA=; b=vXrv4BbRKlzSM37uykr81RhRyWC17v+VBdog6h5MUZJgdBcOhg3DVRLOdWOF8SuqeVQ0rBYIpfOgxKwoJ5/KwPY+VDrwuDBJytY7JRpduO9qrQ8UP5fMv+XU/hdBS1JD; Received: from mail by f231.mail.ru with local id 1PEMvu-0006UK-00 for freebsd-current@freebsd.org; Fri, 05 Nov 2010 17:06:22 +0300 Received: from [93.92.200.151] by win.mail.ru with HTTP; Fri, 05 Nov 2010 17:06:22 +0300 From: sdfsdf rwerwer To: freebsd-current Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [93.92.200.151] Date: Fri, 05 Nov 2010 17:06:22 +0300 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Subject: ngctl can crash the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sdfsdf rwerwer List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 15:18:23 -0000 Hi everybody, The following commands lead the 9.0-CURRENT kernel to crash: [root@freebsd /usr/home/int0dh]# ngctl Available commands: config get or set configuration of node at connect Connects hook of the node at to debug Get/set debugging verbosity level dot Produce a GraphViz (.dot) of the entire netgraph. help Show command summary or get more help on a specific command list Show information about all nodes mkpeer Create and connect a new node to the node at "path" msg Send a netgraph control message to the node at "path" name Assign name to the node at read Read and execute commands from a file rmhook Disconnect hook "hook" of the node at "path" show Show information about the node at shutdown Shutdown the node at status Get human readable status information from the node at types Show information about all installed node types write Send a data packet down the hook named by "hook". quit Exit program + mkpeer ksocket myhook inet/stream/tcp + msg .:myhook connect inet/127.0.0.1:22 After last command the kernel panics. Any listening TCP port can be used instead of 22. The panic occurs here (sys/kern/uipc_sockbuf.c): int sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control) { struct mbuf *m, *n, *nlast; int space = asa->sa_len; SOCKBUF_LOCK_ASSERT(sb); if (m0 && (m0->m_flags & M_PKTHDR) == 0) { panic("sbappendaddr_locked" ; } I`ve tried with the custom kernel only, but I think that issue can be reproduced with GENERIC too. From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 15:20:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936D5106566C for ; Fri, 5 Nov 2010 15:20:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 46FAA8FC0C for ; Fri, 5 Nov 2010 15:20:29 +0000 (UTC) Received: by gxk9 with SMTP id 9so2300920gxk.13 for ; Fri, 05 Nov 2010 08:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=RWRpCeAxtoJJwmatjmo6OvY2M8e52NQspXayZQM0AWs=; b=gHpV1P9HVITa/j/9DgHyTpJwKMpbJTbFUVyjmHJkAwOfDWVlf8Kuu3vpeiTJEY5Jah bxfclmIsHTtQp4JM1V5CgmeQVpVzpcbugIAHrvP7RpO12tCmFQUIx7qaDgqh/V+E0r+g qvXFhYVfgcchwmkDpk9sz2fSkZrdcm3LzeORY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fVF5+ieiLW4SodoBdva+R1WJXg58QssCFAIKcaQB4i6Q9J9CCIdSwhVyPZjIDpxDUs 6K9sQmzB2XSfMT9gNNUTPCKjQI75NBJN/R2wMBFYOqh4ypaiM19viMAXmIbvBoq/g0qm kq0chtPo2j+2x9JZv0lfpOFHfnoEi331Y7LiA= Received: by 10.150.215.17 with SMTP id n17mr1298427ybg.8.1288970429115; Fri, 05 Nov 2010 08:20:29 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id p38sm2599839ybk.4.2010.11.05.08.20.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 08:20:27 -0700 (PDT) Date: Fri, 5 Nov 2010 11:20:09 -0400 From: Mark Johnston To: Nick Hibma Message-ID: <20101105152009.GB1437@mark-laptop-bsd.mark-home> References: <20101024231119.GA2123@mark-laptop-bsd.mark-home> <20101024231642.GB2123@mark-laptop-bsd.mark-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: [Patch] libfetch - closing the cached FTP connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 15:20:30 -0000 On Fri, Nov 05, 2010 at 09:38:24AM +0100, Nick Hibma wrote: > Mark, > > My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd? > > fcntl(fd, F_SETFD, FD_CLOEXEC); > > It doesn't sound like you ever want to have a cached connection be copied into the child. Mum and child calling daddy using the same phone line isn't going to make the conversation any easier for daddy. > > Cheers, > > Nick The problem is that libfetch's ftp functions use an interface set up by funopen(3), so functions like fetchGetURL return a FILE*. However, I can't use something like fileno(3) to get the descriptor to pass to fcntl, because libfetch's FILE * is actually a struct ftpio *, which is only in ftp.c, i.e. not in the headers. I think using fcntl is nicer than having a "close the cached connection" function, but I don't think I can get around this problem without changing something in libfetch. Thanks, -Mark From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 15:57:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CEB9106566C for ; Fri, 5 Nov 2010 15:57:54 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D9ABA8FC14 for ; Fri, 5 Nov 2010 15:57:53 +0000 (UTC) Received: by yxl31 with SMTP id 31so2333243yxl.13 for ; Fri, 05 Nov 2010 08:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:user-agent:mime-version:content-type; bh=hmqIQf9Rj5wHhzMCwigM1tJD2zRdAiZQbim3s3O5tdY=; b=JW3vZu2S+FXV2w2pygeytttmmLbIjmOHeupGO6uABgZYz2ly1AfPh7V+ZfFZ2WD0oh 7gnAwd8lpdeCzXDMfT36QAIlVxi1mJZgLPi6sdkHH2R3paNeEMYbAic3ks2saIQznBM+ KNMEWzuFfj82E/28fTD9K6oJIFNYmLFxdy0cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:mime-version :content-type; b=kV0ePe0BG1yfe9zfmoKXhOYQhB6fZi9L4m2SxtXPJN1aNxYHM6uK+TlKloribrpCOR JWAEEsgFGQR39wMsbHLv3/2ENj2UQxFasoDJihJ4Oqjap8dOIR1EhjPJrcAHKB9tyv7H nCvX28I7Vcz/nSY1jnArZ7tdmTuvhQvZ3RcEo= Received: by 10.42.218.132 with SMTP id hq4mr1568680icb.41.1288972672765; Fri, 05 Nov 2010 08:57:52 -0700 (PDT) Received: from localhost (tor-exit-proxy1-readme.formlessnetworking.net [208.53.142.37]) by mx.google.com with ESMTPS id l14sm508006vcr.42.2010.11.05.08.57.50 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 08:57:52 -0700 (PDT) From: Anonymous To: Gordon Tetlow Date: Fri, 05 Nov 2010 18:57:41 +0300 Message-ID: <8639rfyd8q.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-current@freebsd.org Subject: man(1) no longer understands manpages like .so man3/printf.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 15:57:54 -0000 A few examples from ports tree devel/automake111: automake-1.11(1) devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3) devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1) textproc/gnugrep: egrep(1), fgrep(1) www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3) x11/libX11: BlackPixel(3), XArc(3), etc x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc [+ more x11 libs] From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 16:06:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B4A106566B; Fri, 5 Nov 2010 16:06:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7808FC12; Fri, 5 Nov 2010 16:06:51 +0000 (UTC) Received: by eyb7 with SMTP id 7so1755468eyb.13 for ; Fri, 05 Nov 2010 09:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=53nmMSbbi9ew6ArtNSWWqSHC+PLYLWrDSKuV2zth0tc=; b=goDMt2zU3yrXX4bYGf3w5M1c6U5XMBy4ByjHYvhoiuM5l3j9MFmGhJpE5+kPg8XyK9 d611quv7IKAL2qds12qa6HPNJ4JXb6DYTKAzL+cn9W78KxgacDQiN9eYqa2mX19GUgoU IWpwqmUjIU2Hx3LUzaSRflwRBMHkfw6XazqUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LFqP2r4kalq112G3Y9VXAJonrDiuFj2wRzxMmCahyxNyBHsrcdHzGoCCFa3Y8hJkdf 6jMvgZ6DsRxOyzJhOnqNvUKAwX7D15WTnFAEAxwCWLcvKVjfplBvOeMlOiJN5RNbbrP6 NIuirSB5hPaZa4n70LSQFl0hcOc1f/I0NZfUo= MIME-Version: 1.0 Received: by 10.216.7.210 with SMTP id 60mr1367146wep.30.1288973209982; Fri, 05 Nov 2010 09:06:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 09:06:49 -0700 (PDT) In-Reply-To: <4CD40B10.5090205@icyb.net.ua> References: <4CD40B10.5090205@icyb.net.ua> Date: Fri, 5 Nov 2010 09:06:49 -0700 X-Google-Sender-Auth: pGKIji4qq0p0cRCknyOkWnY0I1k Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org, Alexander Motin , freebsd-current@freebsd.org Subject: Re: stuck in cam with bad optical media X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 16:06:52 -0000 On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon wrote: > > [I am probably just having an unlucky day.] > > I tried to burn (with growisofs) a DVD+RW disk which seems to have develo= ped some > problems. > First, the burning process got stuck at the same percentage and the drive= started > to make unusual sounds. =A0Then, the following messages appeared in syste= m log: > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek co= mplete) > kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc= :2,0 (No > seek complete) > kernel: ahcich5: Timeout on slot 7 > kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 s= err 00000000 > kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back > > After that growisofs either remained or became stuck in the following sta= te: > 42433 100119 growisofs =A0 =A0 =A0 =A0initial thread =A0 mi_switch+0x1de = sleepq_switch+0xdb > sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0= x68 > passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallen= ter+0x3be > syscall+0x41 Xfast_syscall+0xe2 > > Any commands that tried to access the device (cdcontrol eject, camcontrol= reset > 5:0:0) also got stuck. > Only reboot helped to recover the device. > > I understand that bad media is bad, but it happens. > I think that cam and ahci typically recover from errors/timeouts, so some= hting > must have gone wrong in this case. > > P.S. I have already thrown out the bad disk - irritation won over reason = when that > happened, unfortunately :( I think we are in the same boat (I've run into this problem on two different machines with my revisions of CURRENT) :(... I resorted to using an external DVD writer to write media (which is in and of itself a PITA): $ camcontrol devlist; uname -a at scbus1 target 0 lun 0 (cd0,pass0) at scbus2 target 0 lun 0 (pass1,ada0) FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA amd64 Have you tried non-rewritable CDs and DVDs yet (something that I need to try too)? HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 16:11:59 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFFD1065672; Fri, 5 Nov 2010 16:11:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EF8508FC19; Fri, 5 Nov 2010 16:11:57 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA16519; Fri, 05 Nov 2010 18:11:56 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD42CCC.6060005@icyb.net.ua> Date: Fri, 05 Nov 2010 18:11:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Garrett Cooper References: <4CD40B10.5090205@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: stuck in cam with bad optical media X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 16:11:59 -0000 on 05/11/2010 18:06 Garrett Cooper said the following: > On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon wrote: >> >> [I am probably just having an unlucky day.] >> >> I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some >> problems. >> First, the burning process got stuck at the same percentage and the drive started >> to make unusual sounds. Then, the following messages appeared in system log: >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) >> kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 >> kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error >> kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition >> kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No >> seek complete) >> kernel: ahcich5: Timeout on slot 7 >> kernel: ahcich5: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd 58 serr 00000000 >> kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back >> >> After that growisofs either remained or became stuck in the following state: >> 42433 100119 growisofs initial thread mi_switch+0x1de sleepq_switch+0xdb >> sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 >> passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be >> syscall+0x41 Xfast_syscall+0xe2 >> >> Any commands that tried to access the device (cdcontrol eject, camcontrol reset >> 5:0:0) also got stuck. >> Only reboot helped to recover the device. >> >> I understand that bad media is bad, but it happens. >> I think that cam and ahci typically recover from errors/timeouts, so somehting >> must have gone wrong in this case. >> >> P.S. I have already thrown out the bad disk - irritation won over reason when that >> happened, unfortunately :( > > I think we are in the same boat (I've run into this problem on two > different machines with my revisions of CURRENT) :(... I resorted to > using an external DVD writer to write media (which is in and of itself > a PITA): > > $ camcontrol devlist; uname -a > at scbus1 target 0 lun 0 (cd0,pass0) > at scbus2 target 0 lun 0 (pass1,ada0) > FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: > Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA > amd64 > > Have you tried non-rewritable CDs and DVDs yet (something that I > need to try too)? Not sure if you refer to exactly the same problem. I regularly successfully burn various media (re-writable and write-once). This time this was definitely a bad (degraded) disk. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 17:15:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFBF1065670; Fri, 5 Nov 2010 17:15:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B19B58FC1B; Fri, 5 Nov 2010 17:15:02 +0000 (UTC) Received: by gya6 with SMTP id 6so2387413gya.13 for ; Fri, 05 Nov 2010 10:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VxEAITq6iW6923DUMnI8WPm53m8GXLHaC47ypEY4544=; b=gxfxLyi6WvH5ihTkco42ygIrz2EG4P/ZwoiYeHvS0mc0CB8idVzF/bapNukHxaLz/Z 7oibcCB3VaFyeQRbhnfCkoq8mD6RigqBAVGf2siUc+lIc19I7dyUJkV1EBhKAL/UWMvY 106XGEHuhaRaO1CDJL4Nk6gzlizfl8C+HEASw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B8WxiybCw03FjnlaDcMTTiGqADLtjDKTUBVe28XLTRcLfTiKa+cLAHEy2Lcvg98Trx ux0+BohG5auOALzhvha0pkXcqVVM3xMdjLSWA6rBMNPtJizjEnvDWMIpnV7dtOBxSijX YRtNFRAiG+i1+XyYKglBxxSVULP9MRLZFm+KI= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr1600934icb.276.1288977301642; Fri, 05 Nov 2010 10:15:01 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 10:15:01 -0700 (PDT) In-Reply-To: <201011051018.28860.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> <201011051018.28860.jhb@freebsd.org> Date: Fri, 5 Nov 2010 10:15:01 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 17:15:03 -0000 On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote= : >> >> >> I think that if a task is currently executing, then there should b= e a drain >> >> >> method for that. I.E. two methods: One to stop and one to cancel/d= rain. Can >> >> >> you implement this? >> >> > >> >> > I agree, this would also be consistent with the callout_*() API if = you had >> >> > both "stop()" and "drain()" methods. >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet test= ed. >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> Original code: =A0 =A0 =A0jeff >> >> MFC after: =A01 week >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0How= ever, I >> > would prefer that it follow the semantics of callout_stop() and return= true >> > if it stopped the task and false otherwise. =A0The Linux wrapper for >> > taskqueue_cancel() can convert the return value. >> >> I used -EBUSY since positive return values reflect the old pending >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> means the task is queued. >> >> I don't know that the caller often needs to know the old value of >> ta_pending, but it seems simpler to return that as the return value >> and use -EBUSY than to use an optional pointer to a place to store the >> old ta_pending just so we can keep the error return positive. >> >> Note that phk (IIRC) suggested using -error in the returns for >> sbuf_drain to indicate the difference between success (> 0 bytes >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entirely >> sure that's a good thing, since I am not generally fond of Linux's use >> of -error, but for some cases it is convenient. >> >> But, I'll do this one either way, just let me know if the above hasn't >> convinced you. > > Hmm, I hadn't considered if callers would want to know the pending count = of > the cancelled task. > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_= WAITOK) >> > for this blocking flag. =A0In the case of callout(9) we just have two = functions >> > that pass an internal boolean to the real routine (callout_stop() and >> > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit >> > unfortunate that taskqueue_drain() already exists and has different se= mantics >> > than callout_drain(). =A0It would have been nice to have the two APIs = mirror each >> > other instead. >> > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by ju= st >> > doing: >> > >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> This seems reasonable and correct. =A0I will add a note to the manpage a= bout this. > > In that case, would you be fine with dropping the blocking functionality = from > taskqueue_cancel() completely and requiring code that wants the blocking > semantics to use a cancel followed by a drain? New patch is at http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-= a-task-from-a.patch I'll try to set up something to test it today too. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 17:35:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51B0E1065675; Fri, 5 Nov 2010 17:35:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1015A8FC12; Fri, 5 Nov 2010 17:35:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=24NoxT-kmLX8QFLnx5MA:9 a=g0NIqYagmTlxspyxPIgA:7 a=LFkYILy1PJmkOeKz3kPsMjiUSV0A:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45334299; Fri, 05 Nov 2010 18:35:31 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 18:36:39 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051836.39697.hselasky@c2i.net> Cc: Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 17:35:34 -0000 On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> I think that if a task is currently executing, then there should > >> >> >> be a drain method for that. I.E. two methods: One to stop and one > >> >> >> to cancel/drain. Can you implement this? > >> >> > > >> >> > I agree, this would also be consistent with the callout_*() API if > >> >> > you had both "stop()" and "drain()" methods. > >> >> > >> >> Here's my proposed code. Note that this builds but is not yet > >> >> tested. > >> >> > >> >> > >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> > >> >> Requested by: hps > >> >> Original code: jeff > >> >> MFC after: 1 week > >> >> > >> >> > >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> > > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> > However, I would prefer that it follow the semantics of > >> > callout_stop() and return true if it stopped the task and false > >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert the > >> > return value. > >> > >> I used -EBUSY since positive return values reflect the old pending > >> count. ta_pending was zero'd, and I think needs to be to keep the > >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> means the task is queued. > >> > >> I don't know that the caller often needs to know the old value of > >> ta_pending, but it seems simpler to return that as the return value > >> and use -EBUSY than to use an optional pointer to a place to store the > >> old ta_pending just so we can keep the error return positive. > >> > >> Note that phk (IIRC) suggested using -error in the returns for > >> sbuf_drain to indicate the difference between success (> 0 bytes > >> drained) and an error, so FreeBSD now has precedent. I'm not entirely > >> sure that's a good thing, since I am not generally fond of Linux's use > >> of -error, but for some cases it is convenient. > >> > >> But, I'll do this one either way, just let me know if the above hasn't > >> convinced you. > > > > Hmm, I hadn't considered if callers would want to know the pending count > > of the cancelled task. > > > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> > M_WAITOK) for this blocking flag. In the case of callout(9) we just > >> > have two functions that pass an internal boolean to the real routine > >> > (callout_stop() and callout_drain() are wrappers for > >> > _callout_stop_safe()). It is a bit unfortunate that > >> > taskqueue_drain() already exists and has different semantics than > >> > callout_drain(). It would have been nice to have the two APIs mirror > >> > each other instead. > >> > > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> > just doing: > >> > > >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> > taskqueue_drain(queue, task); > >> > >> This seems reasonable and correct. I will add a note to the manpage > >> about this. > > > > In that case, would you be fine with dropping the blocking functionality > > from taskqueue_cancel() completely and requiring code that wants the > > blocking semantics to use a cancel followed by a drain? > > New patch is at > http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel- > a-task-from-a.patch I think the: + if (!task_is_running(queue, task)) { check needs to be omitted. Else you block the possibility of enqueue and cancel a task while it is actually executing/running ?? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:13:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5515106566B; Fri, 5 Nov 2010 18:13:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1B68FC15; Fri, 5 Nov 2010 18:13:09 +0000 (UTC) Received: by iwn39 with SMTP id 39so3109127iwn.13 for ; Fri, 05 Nov 2010 11:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5a8cIMwwtaVrYIj5jLPK00hC6AwQ8rbk9A+Q73qydtc=; b=jY/EDRFqecOWlKMh55HRUBWcJU1hzIgxLugVhyKYA7bNHPkX09DDikZd+j0G8sFJm5 BaOB7dbZKkD408Z7J0UQ5/wlrTCwmin/TDhkFi2dZncS56btvbNhU5/KWMU3UcdbzjxT zqJWIf68niCB1rySdzag79K3FKU9LoZ2vcvyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mp4QjUA4/DtYbCeAiL4z2FzdZaxYjqntgMNfpH8bW5uC6GqWv+c4oWX6wiwwdTc5G5 oyPrHf6y/OKA4QEBWqjrMkA8zWVSf8jA7IKIdbkTrEe4/sXdUI5ihXmafF3OWB+9z25X 1m1UGuyLuWuOgC6vDJFJ6BRDsHZv7Egi9CHro= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr2010293ibd.58.1288980788700; Fri, 05 Nov 2010 11:13:08 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:13:08 -0700 (PDT) In-Reply-To: <201011051836.39697.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> <201011051836.39697.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:13:08 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:13:10 -0000 On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wr= ote: >> >> >> >> I think that if a task is currently executing, then there shoul= d >> >> >> >> be a drain method for that. I.E. two methods: One to stop and o= ne >> >> >> >> to cancel/drain. Can you implement this? >> >> >> > >> >> >> > I agree, this would also be consistent with the callout_*() API = if >> >> >> > you had both "stop()" and "drain()" methods. >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet >> >> >> tested. >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> > =A0However, I would prefer that it follow the semantics of >> >> > callout_stop() and return true if it stopped the task and false >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can convert = the >> >> > return value. >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> >> means the task is queued. >> >> >> >> I don't know that the caller often needs to know the old value of >> >> ta_pending, but it seems simpler to return that as the return value >> >> and use -EBUSY than to use an optional pointer to a place to store th= e >> >> old ta_pending just so we can keep the error return positive. >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entir= ely >> >> sure that's a good thing, since I am not generally fond of Linux's us= e >> >> of -error, but for some cases it is convenient. >> >> >> >> But, I'll do this one either way, just let me know if the above hasn'= t >> >> convinced you. >> > >> > Hmm, I hadn't considered if callers would want to know the pending cou= nt >> > of the cancelled task. >> > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) we j= ust >> >> > have two functions that pass an internal boolean to the real routin= e >> >> > (callout_stop() and callout_drain() are wrappers for >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> > taskqueue_drain() already exists and has different semantics than >> >> > callout_drain(). =A0It would have been nice to have the two APIs mi= rror >> >> > each other instead. >> >> > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by >> >> > just doing: >> >> > >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> This seems reasonable and correct. =A0I will add a note to the manpag= e >> >> about this. >> > >> > In that case, would you be fine with dropping the blocking functionali= ty >> > from taskqueue_cancel() completely and requiring code that wants the >> > blocking semantics to use a cancel followed by a drain? >> >> New patch is at >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc= el- >> a-task-from-a.patch > > I think the: > > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > > check needs to be omitted. Else you block the possibility of enqueue and > cancel a task while it is actually executing/running ?? Huh? If the task is currently running, there's nothing to do except return failure. Task running means it can't be canceled, because... it's running. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:27:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B526106566C for ; Fri, 5 Nov 2010 18:27:53 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpb-ews06.kpnxchange.com (cpsmtpb-ews06.kpnxchange.com [213.75.39.9]) by mx1.freebsd.org (Postfix) with ESMTP id 019228FC13 for ; Fri, 5 Nov 2010 18:27:52 +0000 (UTC) Received: from cpbrm-ews10.kpnxchange.com ([10.94.84.141]) by cpsmtpb-ews06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 19:27:51 +0100 Received: from CPSMTPM-EML102.kpnxchange.com ([195.121.3.6]) by cpbrm-ews10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 19:27:51 +0100 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Fri, 5 Nov 2010 19:27:50 +0100 Received: from hillary.van-laarhoven.org (Hillary.van-laarhoven.org [10.66.0.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by uitsmijter.van-laarhoven.org (Postfix) with ESMTPSA id 041B1421A; Fri, 5 Nov 2010 19:27:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nick Hibma In-Reply-To: <20101105152009.GB1437@mark-laptop-bsd.mark-home> Date: Fri, 5 Nov 2010 19:27:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08D6E625-5BE9-4121-A0D8-8B5BDA20A813@van-laarhoven.org> References: <20101024231119.GA2123@mark-laptop-bsd.mark-home> <20101024231642.GB2123@mark-laptop-bsd.mark-home> <20101105152009.GB1437@mark-laptop-bsd.mark-home> To: Mark Johnston X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-16.0 required=5.0 tests=UNPARSEABLE_RELAY, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on uitsmijter.van-laarhoven.org X-OriginalArrivalTime: 05 Nov 2010 18:27:50.0534 (UTC) FILETIME=[272F9260:01CB7D17] X-RcptDomain: freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: [Patch] libfetch - closing the cached FTP connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:27:53 -0000 > I think using fcntl is nicer than having a "close the cached = connection" > function, but I don't think I can get around this problem without > changing something in libfetch. I think libfetch should set the Close-On-Exec flag. It's wrong to have = these files propagate to children. Nick= From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:29:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C5B106566C; Fri, 5 Nov 2010 18:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D42F58FC1A; Fri, 5 Nov 2010 18:29:31 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Cw8rU7oRz3VboNDMIlAA:9 a=MUlSQjhuJp0JbwSJUxwIolEPeYMA:4 a=wPNLvfGTeEIA:10 a=FcgzJa1LcXe6IDLysl4A:9 a=XnCYU3IuQVv1LWxiYhsA:7 a=klG2om15o0QNuV1ZETSHBZYqC58A:4 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45156194; Fri, 05 Nov 2010 19:29:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 5 Nov 2010 19:30:38 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: <201011051836.39697.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_O1E1M5DxgzaX2zh" Message-Id: <201011051930.38530.hselasky@c2i.net> Cc: Weongyo Jeong , Matthew Fleming , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:29:32 -0000 --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In the patch attached to this e-mail I included Matthew Fleming's patch aswell. 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles the words of the callout and USB API's terminology for doing the same. 2) I turns out I need to have code in subr_taskqueue.c to be able to make the operations atomic. 3) I did not update the manpage in this patch. Will do that before a commit. 4) My patch implements separate state keeping in "struct task_pair", which avoids having to change any KPI's for now, like suggested by John Baldwin I think. 5) In my implementation I hard-coded the priority argument to zero, so that enqueuing is fast. Comments are welcome! --HPS --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: text/x-patch; charset="iso-8859-1"; name="0001-Implement-taskqueue_pair.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-Implement-taskqueue_pair.patch" === kern/subr_taskqueue.c ================================================================== --- kern/subr_taskqueue.c (revision 214796) +++ kern/subr_taskqueue.c (local) @@ -275,6 +275,25 @@ return (0); } +int +taskqueue_stop(struct taskqueue *queue, struct task *task) +{ + int retval = 0; + + TQ_LOCK(queue); + + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + void taskqueue_drain(struct taskqueue *queue, struct task *task) { @@ -288,6 +307,113 @@ TQ_UNLOCK(queue); } + +int +taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval; + int j; + + TQ_LOCK(queue); + + j = 0; + if (tp->tp_task[0].ta_pending > 0) + j |= 1; + if (tp->tp_task[1].ta_pending > 0) + j |= 2; + + if (j == 0) { + /* No entries are queued. Just pick a last task. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else if (j == 1) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 1; + /* Re-queue the last queued task. */ + task = &tp->tp_task[1]; + } else if (j == 2) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else { + /* Re-queue the last queued task. */ + task = &tp->tp_task[tp->tp_last]; + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + } + + STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + + retval = tp->tp_last + 1; + /* store the actual order in the pending count */ + task->ta_pending = retval; + + if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) + queue->tq_enqueue(queue->tq_context); + else + queue->tq_flags |= TQ_FLAGS_PENDING; + + TQ_UNLOCK(queue); + + return (retval); +} + +int +taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval = 0; + + TQ_LOCK(queue); + + task = &tp->tp_task[0]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + task = &tp->tp_task[1]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + +void +taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + + if (!queue->tq_spin) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); + + TQ_LOCK(queue); +top: + task = &tp->tp_task[0]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + task = &tp->tp_task[1]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + TQ_UNLOCK(queue); +} + static void taskqueue_swi_enqueue(void *context) { === sys/_task.h ================================================================== --- sys/_task.h (revision 214796) +++ sys/_task.h (local) @@ -51,4 +51,9 @@ void *ta_context; /* (c) argument for handler */ }; +struct task_pair { + struct task tp_task[2]; + int tp_last; /* (q) index of last queued task */ +}; + #endif /* !_SYS__TASK_H_ */ === sys/taskqueue.h ================================================================== --- sys/taskqueue.h (revision 214796) +++ sys/taskqueue.h (local) @@ -53,7 +53,11 @@ void *context); int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); +int taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp); +int taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp); +void taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_stop(struct taskqueue *queue, struct task *task); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -78,6 +82,15 @@ } while (0) /* + * Initialise a task pair structure. + */ +#define TASK_PAIR_INIT(tp, func, context) do { \ + TASK_INIT(&(tp)->tp_task[0], 0, func, context); \ + TASK_INIT(&(tp)->tp_task[1], 0, func, context); \ + (tp)->tp_last = 0; \ +} while (0) + +/* * Declare a reference to a taskqueue. */ #define TASKQUEUE_DECLARE(name) \ --Boundary-00=_O1E1M5DxgzaX2zh-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:34:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16E0106566B; Fri, 5 Nov 2010 18:34:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id C03C88FC16; Fri, 5 Nov 2010 18:34:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=NQlS8b5mwfIYmOo8uroA:9 a=E_rvnGVBWsNcG74Lc3UA:7 a=2RIT3NFf099GxrwdX1yFkcDJl_4A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44710663; Fri, 05 Nov 2010 19:34:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:35:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051935.27579.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:34:22 -0000 On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> >> I think that if a task is currently executing, then there > >> >> >> >> should be a drain method for that. I.E. two methods: One to > >> >> >> >> stop and one to cancel/drain. Can you implement this? > >> >> >> > > >> >> >> > I agree, this would also be consistent with the callout_*() API > >> >> >> > if you had both "stop()" and "drain()" methods. > >> >> >> > >> >> >> Here's my proposed code. Note that this builds but is not yet > >> >> >> tested. > >> >> >> > >> >> >> > >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> >> > >> >> >> Requested by: hps > >> >> >> Original code: jeff > >> >> >> MFC after: 1 week > >> >> >> > >> >> >> > >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> >> > > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> >> > However, I would prefer that it follow the semantics of > >> >> > callout_stop() and return true if it stopped the task and false > >> >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert > >> >> > the return value. > >> >> > >> >> I used -EBUSY since positive return values reflect the old pending > >> >> count. ta_pending was zero'd, and I think needs to be to keep the > >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> >> means the task is queued. > >> >> > >> >> I don't know that the caller often needs to know the old value of > >> >> ta_pending, but it seems simpler to return that as the return value > >> >> and use -EBUSY than to use an optional pointer to a place to store > >> >> the old ta_pending just so we can keep the error return positive. > >> >> > >> >> Note that phk (IIRC) suggested using -error in the returns for > >> >> sbuf_drain to indicate the difference between success (> 0 bytes > >> >> drained) and an error, so FreeBSD now has precedent. I'm not > >> >> entirely sure that's a good thing, since I am not generally fond of > >> >> Linux's use of -error, but for some cases it is convenient. > >> >> > >> >> But, I'll do this one either way, just let me know if the above > >> >> hasn't convinced you. > >> > > >> > Hmm, I hadn't considered if callers would want to know the pending > >> > count of the cancelled task. > >> > > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> >> > M_WAITOK) for this blocking flag. In the case of callout(9) we > >> >> > just have two functions that pass an internal boolean to the real > >> >> > routine (callout_stop() and callout_drain() are wrappers for > >> >> > _callout_stop_safe()). It is a bit unfortunate that > >> >> > taskqueue_drain() already exists and has different semantics than > >> >> > callout_drain(). It would have been nice to have the two APIs > >> >> > mirror each other instead. > >> >> > > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> >> > just doing: > >> >> > > >> >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> >> > taskqueue_drain(queue, task); > >> >> > >> >> This seems reasonable and correct. I will add a note to the manpage > >> >> about this. > >> > > >> > In that case, would you be fine with dropping the blocking > >> > functionality from taskqueue_cancel() completely and requiring code > >> > that wants the blocking semantics to use a cancel followed by a > >> > drain? > >> > >> New patch is at > >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc > >> el- a-task-from-a.patch > > > > I think the: > > > > + if (!task_is_running(queue, task)) { > > If it is running, it is dequeued from the the taskqueue, right? And while it is running it can be queued again, which your initial code didn't handle? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:39:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C989F1065674; Fri, 5 Nov 2010 18:39:46 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 448228FC13; Fri, 5 Nov 2010 18:39:45 +0000 (UTC) Received: by yxl31 with SMTP id 31so2477722yxl.13 for ; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D29wDRntq2CSQZo7Nv6wTrGlpMMuFRkjaIAHLqmjLQA=; b=xF0WixRPSti32fB5rxhr9brs2sjVB9vN5YL0CFe3WDx4yvs/DEutQo6A2TmQ+QrwaD eQqzEASKZa+SQleMAlUKhLe3/iGQStfmXTfIpn0dXso9tRqyWxIbQTvYYXML3IW9+ItS aGAZOdBLnAJOdGHOe1dkabyMCPGJO+k2PgpcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WljFVibE0pGR8hNAZTYTdSu9rnEmS/16pWMhihuoVOHTeYxY4Ddh4sBoVNc4Fmxx+x 5dHW1z5YB6YEmWBNS9U4/JdPGAAON2nAfw6u9OqYijLS8XMitrp5AkYSP0vQRdNtR844 5MHJp6wS1/bBD/9jMPYUEBPdY32MYGCPdQxEI= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr1524332icn.343.1288982385280; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:39:45 -0700 (PDT) In-Reply-To: <201011051935.27579.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:39:45 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:39:46 -0000 On Fri, Nov 5, 2010 at 11:35 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky > wrote: >> > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin > wrote: >> >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky > wrote: >> >> >> >> >> I think that if a task is currently executing, then there >> >> >> >> >> should be a drain method for that. I.E. two methods: One to >> >> >> >> >> stop and one to cancel/drain. Can you implement this? >> >> >> >> > >> >> >> >> > I agree, this would also be consistent with the callout_*() A= PI >> >> >> >> > if you had both "stop()" and "drain()" methods. >> >> >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not ye= t >> >> >> >> tested. >> >> >> >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> >> > >> >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> >> > =A0However, I would prefer that it follow the semantics of >> >> >> > callout_stop() and return true if it stopped the task and false >> >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can conve= rt >> >> >> > the return value. >> >> >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep t= he >> >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pendi= ng >> >> >> means the task is queued. >> >> >> >> >> >> I don't know that the caller often needs to know the old value of >> >> >> ta_pending, but it seems simpler to return that as the return valu= e >> >> >> and use -EBUSY than to use an optional pointer to a place to store >> >> >> the old ta_pending just so we can keep the error return positive. >> >> >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not >> >> >> entirely sure that's a good thing, since I am not generally fond o= f >> >> >> Linux's use of -error, but for some cases it is convenient. >> >> >> >> >> >> But, I'll do this one either way, just let me know if the above >> >> >> hasn't convinced you. >> >> > >> >> > Hmm, I hadn't considered if callers would want to know the pending >> >> > count of the cancelled task. >> >> > >> >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAI= T / >> >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) w= e >> >> >> > just have two functions that pass an internal boolean to the rea= l >> >> >> > routine (callout_stop() and callout_drain() are wrappers for >> >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> >> > taskqueue_drain() already exists and has different semantics tha= n >> >> >> > callout_drain(). =A0It would have been nice to have the two APIs >> >> >> > mirror each other instead. >> >> >> > >> >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided= by >> >> >> > just doing: >> >> >> > >> >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> >> >> This seems reasonable and correct. =A0I will add a note to the man= page >> >> >> about this. >> >> > >> >> > In that case, would you be fine with dropping the blocking >> >> > functionality from taskqueue_cancel() completely and requiring code >> >> > that wants the blocking semantics to use a cancel followed by a >> >> > drain? >> >> >> >> New patch is at >> >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-c= anc >> >> el- a-task-from-a.patch >> > >> > I think the: >> > >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > > > If it is running, it is dequeued from the the taskqueue, right? And while= it > is running it can be queued again, which your initial code didn't handle? True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). BTW, I planned to commit the patch I sent today after testing, assuming jhb@ has no more issues. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:44:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D12A106564A; Fri, 5 Nov 2010 18:44:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 47BD58FC19; Fri, 5 Nov 2010 18:44:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Hn5bgWAfYFTdbKXFfdsA:9 a=2En-A4nSjAFEL4h1BRZjkSm4QfUA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44714363; Fri, 05 Nov 2010 19:44:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:45:51 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051945.51393.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:44:45 -0000 On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > True, but no taskqueue(9) code can handle that. Only the caller can > prevent a task from becoming enqueued again. The same issue exists > with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:48:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B18106564A; Fri, 5 Nov 2010 18:48:06 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37DF58FC20; Fri, 5 Nov 2010 18:48:05 +0000 (UTC) Received: by ywh2 with SMTP id 2so2519496ywh.13 for ; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KkKNUrZJAdzo+uUSdLQ9ycvhki1H8jqlPpk2OKp8VME=; b=VaTx3IpJ/ApgbPCTxUeduldg5Du1ePvYOgX3M63B9hvANDSjlTcXc9A1zL0oUYZV+f S3RJeYAgDFots40uLm6kIpWZGkU2GYJ7MJL0iGTGybKF/U8HN+6CpqJf167X0+GldzdS Xv2qTGnwcSHXgMdQAaz657AnYt5DnyjThOLtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VE+PyPMPnqsTaDDlTO/p2JkkaBqAlP3fHzFlJa0/OQUn61a2Plp6/dgQQDIqVb036+ wJZKMIJG/6WQlHaJY6xbU8qNv2pMiQOnZ8tHK5SxEGd2LT+Fd5zvO0s4o3jrjROOO6Mw 9r+1HkSkO6bzY2TiMMyIg2lUMGfM5rs3Orgfs= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1388786icb.477.1288982885106; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:48:05 -0700 (PDT) In-Reply-To: <201011051945.51393.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:48:05 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:48:06 -0000 On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> True, but no taskqueue(9) code can handle that. =A0Only the caller can >> prevent a task from becoming enqueued again. =A0The same issue exists >> with taskqueue_drain(). > > I find that strange, because that means if I queue a task again while it = is > running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:51:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D55F106566B; Fri, 5 Nov 2010 18:51:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A50328FC1D; Fri, 5 Nov 2010 18:51:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so2930031bwz.13 for ; Fri, 05 Nov 2010 11:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=TKPZQ4B/pYcWI+c0Jv3uhc3o4lpVrFV8bm/BjjSEveU=; b=QCooEPeu5hR2Dd1olNCcaH/t8t4A73h731tOp/KgeMPdgmwBMa0fSfNTc1TqTdfBdA 2FjZ9HfEEOqi4moKS0yf1g8lj8FTCIBAQnnckkx1NMiEwZppuq3O9h7oezWyLXdZXC05 +pxhgOIiYxdSJATnOxdkx5a/xlWegyJ+fkN/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=B+hLhEM/W247tAT0gszapiOSMYEhx0HqFYsXzd8O8FVvltJNo+aoGbG1NlkSshtAUA X1VsuWRir7dz2t5NYzC60+k9ttbHNntrUqUfN0Un7qMIn4pLPIHPIDBpFGg1Lr7Ytsip r5A86otQ3zrTXNCuktb2kphe5FB6IysX55OhE= Received: by 10.204.79.142 with SMTP id p14mr2170956bkk.175.1288983061541; Fri, 05 Nov 2010 11:51:01 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d12sm1251680bkw.19.2010.11.05.11.50.59 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 11:51:00 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD45209.5010607@FreeBSD.org> Date: Fri, 05 Nov 2010 20:50:49 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current , FreeBSD Stable , freebsd-scsi@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:51:03 -0000 Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 18:59:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87FD3106566B; Fri, 5 Nov 2010 18:59:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6878FC20; Fri, 5 Nov 2010 18:59:30 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=7l0j79IZqt8iMOdoQ2YA:9 a=f3QMjJQtTtU01tPy7UiD68_cvEMA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45923574; Fri, 05 Nov 2010 19:59:28 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 20:00:37 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011052000.37188.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:59:31 -0000 On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > >> True, but no taskqueue(9) code can handle that. Only the caller can > >> prevent a task from becoming enqueued again. The same issue exists > >> with taskqueue_drain(). > > > > I find that strange, because that means if I queue a task again while it > > is running, then I doesn't get run? Are you really sure? > > If a task is currently running when enqueued, the task struct will be > re-enqueued to the taskqueue. When that task comes up as the head of > the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 19:00:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 830B81065673 for ; Fri, 5 Nov 2010 19:00:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF1C08FC2D for ; Fri, 5 Nov 2010 19:00:17 +0000 (UTC) Received: by gya6 with SMTP id 6so2469080gya.13 for ; Fri, 05 Nov 2010 12:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=zEleHvxLGo4t+sINmznqpNVtfJtbubO0gDHcL5cTMBs=; b=siriz+Wy0B6wsQ9WuND5AQH5wnZPXA9VVKzvJaMYuqQdGssMP9uHFOXDqCKA2VH3lm +2KABv/pd4Eru2JrzItlRErbCaCpH9Krysn1feFbB0J5xwA2lLQH9fjEPgCQHCwQuq2Z FkzCFm2FRybi4CbOuSBVpqmSA93OoLB7Ah8Ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=jmL7hw4FzwHcr7nR1jQQ15uUELJSyL1EY6awAqeIUlMZpCaDOGfw0KGweXfq67IHai BUi262wr/94tlHn8oG4y/2fiWgzuNy7CK2J1jUg6fc618uc8Ne7mv35KAevNKKqZJfEr zz03eB4HFAxp/2Pm0iW/DOUnmvvcrLWlpD1is= Received: by 10.100.58.9 with SMTP id g9mr51419ana.107.1288983616937; Fri, 05 Nov 2010 12:00:16 -0700 (PDT) Received: from mark-laptop-bsd.mark-home (Mail1.sandvine.com [64.7.137.162]) by mx.google.com with ESMTPS id b25sm1778624anb.3.2010.11.05.12.00.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 12:00:16 -0700 (PDT) Date: Fri, 5 Nov 2010 14:59:58 -0400 From: Mark Johnston To: Nick Hibma Message-ID: <20101105185958.GC1437@mark-laptop-bsd.mark-home> References: <20101024231119.GA2123@mark-laptop-bsd.mark-home> <20101024231642.GB2123@mark-laptop-bsd.mark-home> <20101105152009.GB1437@mark-laptop-bsd.mark-home> <08D6E625-5BE9-4121-A0D8-8B5BDA20A813@van-laarhoven.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08D6E625-5BE9-4121-A0D8-8B5BDA20A813@van-laarhoven.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: [Patch] libfetch - closing the cached FTP connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 19:00:24 -0000 On Fri, Nov 05, 2010 at 07:27:43PM +0100, Nick Hibma wrote: > > I think using fcntl is nicer than having a "close the cached connection" > > function, but I don't think I can get around this problem without > > changing something in libfetch. > > I think libfetch should set the Close-On-Exec flag. It's wrong to have these files propagate to children. > > Nick_______________________________________________ Oh I see, I thought you were talking about changing pkg_add alone. I'll post an alternative patch to the PR I opened (bin/151866). Thanks, -Mark From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 19:07:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B43A106566B; Fri, 5 Nov 2010 19:07:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB0298FC16; Fri, 5 Nov 2010 19:07:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 88C0F46B4C; Fri, 5 Nov 2010 15:07:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 80B0E8A01D; Fri, 5 Nov 2010 15:07:54 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 15:06:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> In-Reply-To: <201011052000.37188.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051506.12643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 15:07:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 19:07:56 -0000 On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > wrote: > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > >> prevent a task from becoming enqueued again. The same issue exists > > >> with taskqueue_drain(). > > > > > > I find that strange, because that means if I queue a task again while it > > > is running, then I doesn't get run? Are you really sure? > > > > If a task is currently running when enqueued, the task struct will be > > re-enqueued to the taskqueue. When that task comes up as the head of > > the queue, it will be run again. > > Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't > because it only checks pending if !running() :-) ?? You can't close that race in taskqueue_cancel(). You have to manage that race yourself in your task handler. For the callout(9) API we are only able to close that race if you use callout_init_mtx() so that the code managing the callout wheel can make use of your lock to resolve the races. If you use callout_init() you have to explicitly manage these races in your callout handler. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 19:21:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D93EC1065670; Fri, 5 Nov 2010 19:21:46 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 15EAE8FC0C; Fri, 5 Nov 2010 19:21:45 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id oA5JKSXw068846; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id oA5JKSWu068845; Fri, 5 Nov 2010 20:20:28 +0100 (CET) (envelope-from marius) Date: Fri, 5 Nov 2010 20:20:28 +0100 From: Marius Strobl To: Alexander Motin Message-ID: <20101105192028.GA68728@alchemy.franken.de> References: <4CD45209.5010607@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CD45209.5010607@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Joerg.Schilling@fokus.fraunhofer.de, freebsd-scsi@freebsd.org, FreeBSD-Current , FreeBSD Stable Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 19:21:46 -0000 On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: > Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return "schily" for an SCG_AUTHOR request anymore. * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */ > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. > Marius From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 20:25:38 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 367C11065672 for ; Fri, 5 Nov 2010 20:25:38 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id A748F8FC1D for ; Fri, 5 Nov 2010 20:25:37 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA5KPaB9060889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Nov 2010 21:25:36 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1288988736; bh=WJfUS6nyxPYH5bH0kVUt7/6N44k0OmS/h2p7AIVujCs=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=VzNqcSzstcQtq6dVEFj+VkjmwOKZltG4cYFPIDGdZrtVe4sxAUR5NPW9gjbtwp1a6 Gwt2n4pIIgZxCKA8VQbfVhtgsBU2kEXxz80vdOoSubg52BGlAQ2OUoZLYHnvYipOg1 55a3/YbTOrZHWdHNdjGn41hd0/sI+KCGKcgGO+WI= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA5KPadK060888 for current@FreeBSD.org; Fri, 5 Nov 2010 21:25:36 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Fri, 5 Nov 2010 21:25:36 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org Message-ID: <20101105202536.GR85693@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 20:25:38 -0000 Hey folks, not sure why, but I had a stab at looking which files were actually read during building world. Method went something like this: (turn on atime) # find . -exec touch {} + # sleep 2; touch timestamp # make buildworld buildkernel installworld installkernel (this is on amd64) # make universe # make distribution DESTDIR=/foo # mergemaster (I think this is redundant) # find . -name .svn -prune -or -not -anewer timestamp Please note that I skipped 'make release' as I don't know all the parameters off-hand. The list of files (tools/ removed) can be seen at https://www.spoerlein.net/pub/untouched_files Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped): bin/sh/bltin/echo.1 etc/periodic/security/610.ipf6denied include/hesiod.h include/rpcsvc/pmap_prot.x lib/libarchive/archive_crc32.h lib/libarchive/libarchive_internals.3 lib/libautofs/Makefile lib/libautofs/libautofs.3 lib/libautofs/libautofs.c lib/libautofs/libautofs.h lib/libc/sys/kse.2 lib/libc/xdr/xdr_sizeof.c lib/libc_r/* # we can remove that from head, right? lib/libkse/* # dito lib/libmd/mddriver.c lib/libmd/rmddriver.c lib/libmd/shadriver.c lib/msun/src/s_fabs.c lib/msun/src/s_modf.c sbin/bsdlabel/bsdlabel.5 # eh? sbin/mount/getmntopts.3 sbin/mount_autofs/Makefile sbin/mount_autofs/mount_autofs.8 sbin/mount_autofs/mount_autofs.c sbin/mount_ext2fs/Makefile sbin/mount_ext2fs/mount_ext2fs.8 sbin/mount_ext2fs/mount_ext2fs.c sbin/mount_hpfs/Makefile sbin/mount_hpfs/mount_hpfs.8 sbin/mount_hpfs/mount_hpfs.c sbin/mount_reiserfs/Makefile sbin/mount_reiserfs/mount_reiserfs.8 sbin/mount_reiserfs/mount_reiserfs.c sbin/mount_std/Makefile sbin/mount_std/mount_std.8 sbin/mount_std/mount_std.c usr.bin/cpio/test/* # move to tools/regression? usr.bin/csup/fattr_posix.h usr.bin/ftp/config.h usr.bin/hesinfo/Makefile usr.bin/hesinfo/hesinfo.1 usr.bin/hesinfo/hesinfo.c usr.bin/objformat/Makefile usr.bin/objformat/objformat.sh # delete? usr.bin/setchannel/Makefile usr.bin/setchannel/setchannel.1 usr.bin/setchannel/setchannel.c usr.sbin/cxgbtool/* usr.sbin/gpioctl # wtf? my system has MK_GPIO=no set? usr.sbin/kernbb usr.sbin/route6d/misc/chkrt usr.sbin/route6d/misc/cksum.c usr.sbin/usbdevs/* # delete? does it work with new stack? I haven't looked too closely (ie., not at all) at these cases. Please discuss and happy browsing the list! The Janitor From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 20:34:57 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0784B1065694 for ; Fri, 5 Nov 2010 20:34:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id C32118FC17 for ; Fri, 5 Nov 2010 20:34:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id oA5KYu2W023294 for ; Fri, 5 Nov 2010 13:34:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id oA5KYuoH023293 for current@FreeBSD.org; Fri, 5 Nov 2010 13:34:56 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 Nov 2010 13:34:56 -0700 From: Steve Kargl To: current@FreeBSD.org Message-ID: <20101105203456.GA23267@troutmask.apl.washington.edu> References: <20101105202536.GR85693@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101105202536.GR85693@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 20:34:57 -0000 On Fri, Nov 05, 2010 at 09:25:36PM +0100, Ulrich Sp??rlein wrote: > lib/msun/src/s_fabs.c > lib/msun/src/s_modf.c These are explicitly ignored by msun/Makefile. # FreeBSD's C library supplies these functions: #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 21:16:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6BDD106564A; Fri, 5 Nov 2010 21:16:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 70D9A8FC0A; Fri, 5 Nov 2010 21:16:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAGYR1EyDaFvO/2dsb2JhbACDKJ80qwOQboJ0gWFzBIpW X-IronPort-AV: E=Sophos;i="4.58,305,1286164800"; d="scan'208";a="99793894" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2010 17:16:04 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 173D7B3F56; Fri, 5 Nov 2010 17:16:04 -0400 (EDT) Date: Fri, 5 Nov 2010 17:16:04 -0400 (EDT) From: Rick Macklem To: Andriy Gapon Message-ID: <1090600565.181851.1288991764084.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4CD3B4A0.6060207@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_181850_1076044894.1288991764083" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: processes stuck on a vnode lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:16:16 -0000 ------=_Part_181850_1076044894.1288991764083 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > on 04/11/2010 16:45 Andriy Gapon said the following: > > on 04/11/2010 09:49 Andriy Gapon said the following: > >> > >> I see a few processes stuck on the same vnode, trying to take or to > >> upgrade to > >> an exclusive lock on it, while the lock data suggests that it is > >> already > >> shared-locked. The vnode is a root vnode of one of ZFS filesystems > >> (it's not a > >> global root). > >> > >> I couldn't find any (other) threads that could actually hold the > >> vnode lock, but > >> lock shared count is suspiciously or coincidentally the same as > >> number of > >> threads in zfs_root call. > > > > BTW, I still have the system alive and online, so if anyone has > > ideas I can try them. > > > > The kernel is not live now, but I have saved it and vmcore of the > system. > > Kostik, > > just a pure guesswork here - could r214049 have something to do with > this? > I looked at the change and it looks completely correct - I don't think > that a > vnode lock can be leaked by that code. But, OTOH, it has some special > handling > for VV_ROOT, it's in NFS code and and it's in a right time-frame, so > just asking. > You could try the attached patch which seems to have worked for Josh Carroll, who had a similar problem with stable/8. rick ------=_Part_181850_1076044894.1288991764083 Content-Type: text/x-patch; name=nfs_serv.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=nfs_serv.patch LS0tIG5mc19zZXJ2LmMuc2F2CTIwMTAtMTEtMDUgMDg6MTU6NTcuMDAwMDAwMDAwIC0wNDAwCisr KyBuZnNfc2Vydi5jCTIwMTAtMTEtMDUgMDg6MTg6NDAuMDAwMDAwMDAwIC0wNDAwCkBAIC0zMjUy LDcgKzMyNTIsNyBAQAogCQkJbmZocC0+ZmhfZnNpZCA9IG52cC0+dl9tb3VudC0+bW50X3N0YXQu Zl9mc2lkOwogCQkJaWYgKChlcnJvcjEgPSBWT1BfVlBUT0ZIKG52cCwgJm5maHAtPmZoX2ZpZCkp ID09IDApCiAJCQkJZXJyb3IxID0gVk9QX0dFVEFUVFIobnZwLCB2YXAsIGNyZWQpOwotCQkJaWYg KHZwID09IG52cCkKKwkJCWlmICh1c2V2Z2V0ID09IDAgJiYgdnAgPT0gbnZwKQogCQkJCXZ1bnJl ZihudnApOwogCQkJZWxzZQogCQkJCXZwdXQobnZwKTsK ------=_Part_181850_1076044894.1288991764083-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 21:18:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07000106564A; Fri, 5 Nov 2010 21:18:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCB5D8FC24; Fri, 5 Nov 2010 21:18:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 836B946B03; Fri, 5 Nov 2010 17:18:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66E2A8A009; Fri, 5 Nov 2010 17:18:23 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 5 Nov 2010 17:16:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101105202536.GR85693@acme.spoerlein.net> In-Reply-To: <20101105202536.GR85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201011051716.47962.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 17:18:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:18:25 -0000 On Friday, November 05, 2010 4:25:36 pm Ulrich Sp=F6rlein wrote: > Hey folks, not sure why, but I had a stab at looking which files were > actually read during building world. >=20 > Method went something like this: >=20 > (turn on atime) > # find . -exec touch {} + > # sleep 2; touch timestamp > # make buildworld buildkernel installworld installkernel (this is on amd6= 4) > # make universe > # make distribution DESTDIR=3D/foo > # mergemaster (I think this is redundant) > # find . -name .svn -prune -or -not -anewer timestamp >=20 > Please note that I skipped 'make release' as I don't know all the > parameters off-hand. >=20 > The list of files (tools/ removed) can be seen at > https://www.spoerlein.net/pub/untouched_files >=20 > Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped): >=20 > etc/periodic/security/610.ipf6denied I wonder if this is stale due to ip6fw being removed? > usr.bin/objformat/Makefile > usr.bin/objformat/objformat.sh # delete? This can definitely go. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 21:18:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07000106564A; Fri, 5 Nov 2010 21:18:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCB5D8FC24; Fri, 5 Nov 2010 21:18:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 836B946B03; Fri, 5 Nov 2010 17:18:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66E2A8A009; Fri, 5 Nov 2010 17:18:23 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 5 Nov 2010 17:16:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101105202536.GR85693@acme.spoerlein.net> In-Reply-To: <20101105202536.GR85693@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201011051716.47962.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 17:18:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: current@freebsd.org Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:18:25 -0000 On Friday, November 05, 2010 4:25:36 pm Ulrich Sp=F6rlein wrote: > Hey folks, not sure why, but I had a stab at looking which files were > actually read during building world. >=20 > Method went something like this: >=20 > (turn on atime) > # find . -exec touch {} + > # sleep 2; touch timestamp > # make buildworld buildkernel installworld installkernel (this is on amd6= 4) > # make universe > # make distribution DESTDIR=3D/foo > # mergemaster (I think this is redundant) > # find . -name .svn -prune -or -not -anewer timestamp >=20 > Please note that I skipped 'make release' as I don't know all the > parameters off-hand. >=20 > The list of files (tools/ removed) can be seen at > https://www.spoerlein.net/pub/untouched_files >=20 > Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped): >=20 > etc/periodic/security/610.ipf6denied I wonder if this is stale due to ip6fw being removed? > usr.bin/objformat/Makefile > usr.bin/objformat/objformat.sh # delete? This can definitely go. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 21:47:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9E84106564A; Fri, 5 Nov 2010 21:47:02 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24C988FC18; Fri, 5 Nov 2010 21:47:01 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id oA5Ll12u065514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Nov 2010 22:47:01 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1288993621; bh=PaT6VMSkrlJ8cO8Y2z7hDKNhmDzWbFo4MRenxVVZdfI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=m0wCFSAPsP34p7HKPrU6fw/RfZrOexu0lK9th32tmS7DLsiLMZ01tZcKteaMYB9q7 e8dypB4pDruSzfklJTVRLWHPRdjQwSUQG18z6mvNbUp6l2AP54cu+VIzOgxE9AElrG sAvHMmIp751Rc1irq/qslOLd4oH0ELUcm+u/4Hk0= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id oA5Ll1uu065513; Fri, 5 Nov 2010 22:47:01 +0100 (CET) (envelope-from uqs@spoerlein.net) Date: Fri, 5 Nov 2010 22:47:01 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alexander Best Message-ID: <20101105214700.GT85693@acme.spoerlein.net> Mail-Followup-To: Alexander Best , freebsd-current@freebsd.org References: <20101030232244.GA35209@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101030232244.GA35209@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: issue with "options DDB" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:47:02 -0000 On Sat, 30.10.2010 at 23:22:44 +0000, Alexander Best wrote: > hi there, > > with "options DDB" in my kernel conf i run into the following issue with my > kernel modules: > > link_elf_lookup_symbol: missing symbol hash table > KLD file snd_hda.ko is missing dependencies > KLD file sound.ko is missing dependencies > KLD file nvidia.ko is missing dependencies > KLD file linux.ko is missing dependencies > KLD file ng_ubt.ko is missing dependencies > KLD file ng_hci.ko is missing dependencies > KLD file ng_bluetooth.ko is missing dependencies > KLD file netgraph.ko is missing dependencies > link_elf_lookup_symbol: missing symbol hash table > > removing the option solves the issue. any advice? > > cheers. > alex > > ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date "buildworld" for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL If it fails again, try env __MAKE_CONF=/dev/null make buildkernel KERNCONF=YOURKERNEL Oh, and the actual kernel config might help as well. hth Uli From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 23:43:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F95106564A for ; Fri, 5 Nov 2010 23:43:03 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id AC5388FC12 for ; Fri, 5 Nov 2010 23:43:02 +0000 (UTC) Received: by yxl31 with SMTP id 31so2631073yxl.13 for ; Fri, 05 Nov 2010 16:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=bseoPntr1YPM9iOf/43+CdCnEruR2EcNadt6DDocXxM=; b=sJkBFzvtHVm77wvzebPVT+9A57+fFztWgzabnAdLiuO8WfLmQCN4WDiMhOa+szxvdP RcKdtuqFPRZCETGIi0G2/3v7xkNN9V1Z/ZnmEWJFTeuGeMXYvv2DIeLog9bVicDn7ISX FPYVh5cXOmcm8nxPsh/CP8q7eNpfrJwqWU84A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=DXRSY7e8jsubaNbRoHB59bHDZAOHnLXij/F0I9Tb9waH1WWejypt3IfdsIQClwm6X6 /bHg4eQ2GPnkKzN3uz38kYHYhntbhJ5uMnuvGlE4sswVIeWhV0uFE7ynEyeVBXnu4O7b BINJp69+U6nyP7jFuSq4+tfFudZEsiHolNHf8= Received: by 10.100.57.4 with SMTP id f4mr267158ana.105.1289000581928; Fri, 05 Nov 2010 16:43:01 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id 13sm2056592anq.30.2010.11.05.16.42.59 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 16:43:00 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CD49682.102@DataIX.net> Date: Fri, 05 Nov 2010 19:42:58 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: d@delphij.net References: <4CC62413.50703@delphij.net> In-Reply-To: <4CC62413.50703@delphij.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Xin LI Subject: Re: [PATCH] top(1) inverse display of table header X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 23:43:03 -0000 On 10/25/2010 20:42, Xin LI wrote: > Hi, > > Here is a patch that makes top(1) to inverse its table header (PID > USERNAME THR, etc). > > Cheers, Pretty neato fix for a long-standing annoyance. -- jhell,v From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 23:44:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2562C1065672 for ; Fri, 5 Nov 2010 23:44:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D29E88FC12 for ; Fri, 5 Nov 2010 23:44:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAGMz1EyDaFvO/2dsb2JhbACDKJ85qhuQZ4RVcwSKVg X-IronPort-AV: E=Sophos;i="4.58,306,1286164800"; d="scan'208";a="99803797" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Nov 2010 19:44:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id F3E68B3F4E; Fri, 5 Nov 2010 19:44:56 -0400 (EDT) Date: Fri, 5 Nov 2010 19:44:56 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <77175273.185228.1289000696906.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101105023153.GA20301@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_185227_1527164316.1289000696903" X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 23:44:58 -0000 ------=_Part_185227_1527164316.1289000696903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote: > > > > > > If the counter was not wrapped, it seem you lost more than 10% out > > > of > > > total RX frames. This is a lot loss and there should be a way to > > > mitigate it. > > > > > I've attached a patch (to the if_re.c in head, not your patched > > variant) > > that works a lot better (about 5Mbytes/sec read rate). To get that, > > I > > had to disable msi and not clear the RL_IMR register in re_intr(). I > > suspect that a packet would be received between when the bits in > > RL_IMR > > were cleared and when they were set at the end of re_int_task() and > > those > > were getting lost. > > > > This patch doesn't completely fix the problem. (I added your stats > > collecting > > stuff to the if_re.c in head and attached the result, which still > > shows some lost packets. One > > thought is clearing the bits in RL_ISR in re_intr() instead of > > re_int_task(), > > but then I can't see a good way to pass the old value of the status > > reg. > > through to re_int_task()? > > > > Hmm, I still don't understand how the patch mitigates the issue. :-( > The patch does not disable interrupts in interrupt handler so > taskqueue runs with interrupt enabled. This may ensure not loosing > interrupts but it may also generate many interrupts. By chance, did > you check number of interrupts generated with/without your patch? > I agree. I think all it did was create more interrupts so that re_rxeof() got called more frequently. (see below) > The only guess I have at the moment is the writing RL_IMR in > interrupt handler at the end of taskqueue might be not immediately > reflected so controller can loose interrupts for the time window. > Would you try attach patch and let me know it makes any difference? > Nope, it didn't make any difference. I've added a counter of how many times re_rxeof() gets called, but then returns without handling any received packets (I think because RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv. ring.) This count comes out as almost the same as the # of missed frames (see "rxe did 0:" in the attached stats). So, I think what is happenning about 10% of the time is that re_rxeof() is looking at the ring descriptor before it has been "updated" and then returns without handling the packet and then it doesn't get called again because the RL_ISR bit has been cleared. When "options DEVICE_POLLING" is specified, it works ok, because it calls re_rxeof() fairly frequently and it doesn't pay any attention to the RL_ISR bits. Now, I don't know if this is a hardware flaw on this machine or something that can be fixed in software? I know diddly about the current driver setup, but I assume something like this has to happen? - chip (or PCIe handler) forces the DMA of the descriptor change to RAM - then posts the interrupt - and the driver must read the up to date descriptor from RAM --> I notice that "volatile" isn't used anywhere in the driver. Wouldn't the descriptor ring memory have to be defined "volatile" somehow? (I don't know how to do this correctly?) So, if you can think of anything that will ensure that re_rxeof() reads "up to date" descriptor ring entries, please let me know. Otherwise, I can live with "options DEVICE_POLLING". Thanks for your help, rick ------=_Part_185227_1527164316.1289000696903 Content-Type: text/plain; name=re.stats Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=re.stats cmUwIHN0YXRpc3RpY3M6ClRyYW5zbWl0IGdvb2QgZnJhbWVzIDogMTAxMzQ2ClJlY2VpdmUgZ29v ZCBmcmFtZXMgOiAxMzMzOTAKVHggZXJyb3JzIDogMApSeCBlcnJvcnMgOiAwClJ4IG1pc3NlZCBm cmFtZXMgOiAxNDM5NApSeCBmcmFtZSBhbGlnbm1lbnQgZXJycyA6IDAKVHggc2luZ2xlIGNvbGxp c2lvbnMgOiAwClR4IG11bHRpcGxlIGNvbGxpc2lvbnMgOiAwClJ4IHVuaWNhc3QgZnJhbWVzIDog MTMzMzc4ClJ4IGJyb2FkY2FzdCBmcmFtZXMgOiAwClJ4IG11bHRpY2FzdCBmcmFtZXMgOiAxMgpU eCBhYm9ydHMgOiAwClR4IHVuZGVycnVucyA6IDAKcnhlIGRpZCAwOiAxNDM1OQo= ------=_Part_185227_1527164316.1289000696903-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 5 23:54:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86A31065674 for ; Fri, 5 Nov 2010 23:54:13 +0000 (UTC) (envelope-from sdrhodus@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB018FC15 for ; Fri, 5 Nov 2010 23:54:12 +0000 (UTC) Received: by wwb28 with SMTP id 28so59629wwb.31 for ; Fri, 05 Nov 2010 16:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Kim22NMyOEQAKeTaZp22/MEkTs2XfGANZXnghz0eyOM=; b=AanDhK+J+uMnww/Mo8dGzEB8LmvcvNB6pDKN8VKgSX+uZNJcnADKmXBFfjqM6tujV1 9VCmZqRDi2E3gXM8FJrrknOWWdF1VR26xAkE2M0zL2EhOm+qS4SR9tUP7wPlZ2g6bFhe L7ztb28kdgfDa2arYrrJpi1RMyAFhuGO0fAx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jmKwM0RLkie7dT2uWWPeuxXEDfecbWyBuCdxgTNcCh4AxMrROqNIOM20ocBBdPhMaE XGFsCAz/HXNgXhVilCaH18VIGwTwxaJiLQQN+1s0peJCD8BVDyMBd5MF+/QahAA+x59s JRGJk0hAJEk7Gpt9MFH9wam5bk36S9PUld4PQ= Received: by 10.216.132.131 with SMTP id o3mr2736732wei.19.1288999654142; Fri, 05 Nov 2010 16:27:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.60.137 with HTTP; Fri, 5 Nov 2010 16:27:13 -0700 (PDT) In-Reply-To: References: From: David Rhodus Date: Fri, 5 Nov 2010 19:27:13 -0400 Message-ID: To: sdfsdf rwerwer Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: ngctl can crash the kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 23:54:13 -0000 Same panic here... Also the MPD2 port is broken, I'm guessing a netgraph problem too. 2010/11/5 sdfsdf rwerwer : > > Hi everybody, > > The following commands lead the 9.0-CURRENT kernel to crash: > > > [root@freebsd /usr/home/int0dh]# ngctl > Available commands: > =9Aconfig get or set configuration of node at > =9Aconnect Connects hook of the node at to > =9Adebug Get/set debugging verbosity level > =9Adot Produce a GraphViz (.dot) of the entire netgraph. > =9Ahelp Show command summary or get more help on a specific command > =9Alist Show information about all nodes > =9Amkpeer Create and connect a new node to the node at "path" > =9Amsg Send a netgraph control message to the node at "path" > =9Aname Assign name to the node at > =9Aread Read and execute commands from a file > =9Armhook Disconnect hook "hook" of the node at "path" > =9Ashow Show information about the node at > =9Ashutdown Shutdown the node at > =9Astatus Get human readable status information from the node at > =9Atypes Show information about all installed node types > =9Awrite Send a data packet down the hook named by "hook". > =9Aquit Exit program > + mkpeer ksocket myhook inet/stream/tcp > + msg .:myhook connect inet/127.0.0.1:22 > > After last command the kernel panics. > > > Any listening TCP port can be used instead of 22. > The panic occurs here (sys/kern/uipc_sockbuf.c): > > > int > sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, > =9A =9Astruct mbuf *m0, struct mbuf *control) > { > =9A =9A =9A =9Astruct mbuf *m, *n, *nlast; > =9A =9A =9A =9Aint space =3D asa->sa_len; > > =9A =9A =9A =9ASOCKBUF_LOCK_ASSERT(sb); > > =9A =9A =9A =9Aif (m0 && (m0->m_flags & M_PKTHDR) =3D=3D 0) > =9A =9A =9A =9A{ > =9A =9A =9A =9A =9A =9A =9A =9Apanic("sbappendaddr_locked" ; > =9A =9A =9A =9A} > > I`ve tried with the custom kernel only, but I think that issue can be rep= roduced with GENERIC too. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 02:33:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F19FE106564A for ; Sat, 6 Nov 2010 02:33:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACBA18FC08 for ; Sat, 6 Nov 2010 02:33:52 +0000 (UTC) Received: by iwn39 with SMTP id 39so3568587iwn.13 for ; Fri, 05 Nov 2010 19:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Pwp/j6Gvv2NpW7IzCKexAClFro/8lZWqoorKwn0lk58=; b=OmLfWaiCG/V/eFbrF89t0+iCP929usq3jC7CCaCSB4JKGLJgnOwBU045QEuMym5pfX rUWpaRTsf+tXVPJ/yR96KD4dY5EM9o9tFTiWqg8ACHhUNe5YIQ6aLJYMzoMXUxSzYbO0 6Pxu4nXzxeRFAuwnu7Q8eLeJ4DO6WtHqskMFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rp6ZkY3uNfw+zOvFUDAURQFBErL05PyG218u+CjzgOEiLCsCD/0afitmFa/TEiUjIP mBTNgYbCIoAK8x1HUdX/uaG6EMUmS7ijAXEgqTDcJhk9+6eb6sToeVO7L8vvcfIag6y9 ra/4L0EKrs2duC5yoQHOKLCdMzklo+owFsGSo= Received: by 10.231.33.137 with SMTP id h9mr2267723ibd.117.1289010831950; Fri, 05 Nov 2010 19:33:51 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i16sm108705ibl.0.2010.11.05.19.33.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 19:33:50 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 5 Nov 2010 19:33:45 -0700 From: Pyun YongHyeon Date: Fri, 5 Nov 2010 19:33:45 -0700 To: Rick Macklem Message-ID: <20101106023345.GC22715@michelle.cdnetworks.com> References: <20101105023153.GA20301@michelle.cdnetworks.com> <77175273.185228.1289000696906.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <77175273.185228.1289000696906.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 02:33:53 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 05, 2010 at 07:44:56PM -0400, Rick Macklem wrote: > > On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote: > > > > > > > > If the counter was not wrapped, it seem you lost more than 10% out > > > > of > > > > total RX frames. This is a lot loss and there should be a way to > > > > mitigate it. > > > > > > > I've attached a patch (to the if_re.c in head, not your patched > > > variant) > > > that works a lot better (about 5Mbytes/sec read rate). To get that, > > > I > > > had to disable msi and not clear the RL_IMR register in re_intr(). I > > > suspect that a packet would be received between when the bits in > > > RL_IMR > > > were cleared and when they were set at the end of re_int_task() and > > > those > > > were getting lost. > > > > > > This patch doesn't completely fix the problem. (I added your stats > > > collecting > > > stuff to the if_re.c in head and attached the result, which still > > > shows some lost packets. One > > > thought is clearing the bits in RL_ISR in re_intr() instead of > > > re_int_task(), > > > but then I can't see a good way to pass the old value of the status > > > reg. > > > through to re_int_task()? > > > > > > > Hmm, I still don't understand how the patch mitigates the issue. :-( > > The patch does not disable interrupts in interrupt handler so > > taskqueue runs with interrupt enabled. This may ensure not loosing > > interrupts but it may also generate many interrupts. By chance, did > > you check number of interrupts generated with/without your patch? > > > I agree. I think all it did was create more interrupts so that re_rxeof() > got called more frequently. (see below) > > > The only guess I have at the moment is the writing RL_IMR in > > interrupt handler at the end of taskqueue might be not immediately > > reflected so controller can loose interrupts for the time window. > > Would you try attach patch and let me know it makes any difference? > > > Nope, it didn't make any difference. > > I've added a counter of how many times re_rxeof() gets called, but then > returns without handling any received packets (I think because > RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv. ring.) > > This count comes out as almost the same as the # of missed frames (see > "rxe did 0:" in the attached stats). > > So, I think what is happenning about 10% of the time is that re_rxeof() > is looking at the ring descriptor before it has been "updated" and then > returns without handling the packet and then it doesn't get called again > because the RL_ISR bit has been cleared. > > When "options DEVICE_POLLING" is specified, it works ok, because it calls > re_rxeof() fairly frequently and it doesn't pay any attention to the RL_ISR > bits. > That's one of possible theory. See below for another theory. > Now, I don't know if this is a hardware flaw on this machine or something > that can be fixed in software? I know diddly about the current driver I highly doubt it could be hardware issue. > setup, but I assume something like this has to happen? > - chip (or PCIe handler) forces the DMA of the descriptor change to RAM > - then posts the interrupt > - and the driver must read the up to date descriptor from RAM > --> I notice that "volatile" isn't used anywhere in the driver. Wouldn't > the descriptor ring memory have to be defined "volatile" somehow? > (I don't know how to do this correctly?) Because driver check different descriptor location in each loop, adding volatile keyword wouldn't help. You can verify that whether that makes any difference though. Another possibility I have in mind is the controller would have reported RL_ISR_RX_OVERRUN but re(4) didn't check that condition. The old data sheet I have does not clearly mention when it is set and what other bits of RL_ISR register is affected from the bit. If RL_ISR_RX_OVERRUN bit is set when there are no more free RX descriptors available to controller and RL_ISR_RX_ERR is not set when RL_ISR_RX_OVERRUN is set, re(4) have ignored that event. Because driver ignored that error interrupt, the next error interrupt would be RL_ISR_FIFO_OFLOW error and this time it would be served in re_rxeof() and will refill RX buffers. However driver would have lost lots of frames received between the time window RL_ISR_RX_OVERRUN error and RL_ISR_FIFO_OFLOW error. If this theory is correct, the attached patch may mitigate the issue. > > So, if you can think of anything that will ensure that re_rxeof() reads > "up to date" descriptor ring entries, please let me know. > It's job of bus_dma(9) and I don't think barrier instructions would be helpful here as I don't see out-of-order execution in RX handler. > Otherwise, I can live with "options DEVICE_POLLING". > Sorry, I can't live with DEVICE_POLLING on re(4). :-( Let's kill driver bug. No one reported this kind of issue so far and I guess most users took it granted for the poor performance because they are using low end consumer grade controller. > Thanks for your help, rick > re0 statistics: > Transmit good frames : 101346 > Receive good frames : 133390 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 14394 > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 133378 > Rx broadcast frames : 0 > Rx multicast frames : 12 > Tx aborts : 0 > Tx underruns : 0 > rxe did 0: 14359 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.intr.patch3" Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 214844) +++ sys/pci/if_rlreg.h (working copy) @@ -873,9 +873,7 @@ int rl_twist_row; int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ -#ifdef DEVICE_POLLING int rxcycles; -#endif struct task rl_txtask; struct task rl_inttask; Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 214844) +++ sys/dev/re/if_re.c (working copy) @@ -1860,7 +1860,7 @@ int i, total_len; struct rl_desc *cur_rx; u_int32_t rxstat, rxvlan; - int maxpkt = 16, rx_npkts = 0; + int rx_npkts = 0; RL_LOCK_ASSERT(sc); @@ -1872,7 +1872,7 @@ sc->rl_ldata.rl_rx_list_map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); - for (i = sc->rl_ldata.rl_rx_prodidx; maxpkt > 0; + for (i = sc->rl_ldata.rl_rx_prodidx; sc->rxcycles > 0; i = RL_RX_DESC_NXT(sc, i)) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) break; @@ -2036,7 +2036,7 @@ } } } - maxpkt--; + sc->rxcycles--; if (rxvlan & RL_RDESC_VLANCTL_TAG) { m->m_pkthdr.ether_vtag = bswap16((rxvlan & RL_RDESC_VLANCTL_DATA)); @@ -2058,7 +2058,7 @@ if (rx_npktsp != NULL) *rx_npktsp = rx_npkts; - if (maxpkt) + if (sc->rxcycles) return (EAGAIN); return (0); @@ -2258,8 +2258,11 @@ } #endif - if (status & (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_FIFO_OFLOW)) + if (status & (RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW | + RL_ISR_RX_OVERRUN)) { + sc->rxcycles = sc->rl_ldata.rl_rx_desc_cnt / 2; rval = re_rxeof(sc, NULL); + } /* * Some chips will ignore a second TX request issued --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 02:40:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 710EA1065791 for ; Sat, 6 Nov 2010 02:40:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 20F5E8FC16 for ; Sat, 6 Nov 2010 02:40:55 +0000 (UTC) Received: by gya6 with SMTP id 6so2649053gya.13 for ; Fri, 05 Nov 2010 19:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uTGlzXpfU4hfkncLVHLvvJX3Y6SDaKEbCxtcY11TH2c=; b=rL6x6EnrnpC2oSoT0mk1fr18VTjJFr/1kkL1A8WupPY/8MiYGbKeSzOu7Vdv7Cpj4m tZ6kFgWzhCjbxjp5bmXIyLNRrp9C0TXKmiexdZVCVh2S4XHMz2Y9BRXT6pTXlxwR3/l5 w2h9nEa6unfOhQaGO86NG6y3+fN2+flFngImc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fsgXGl/DrmG+U/g0ZVXOiPx/NE3owspiZAzsqfYd59BIreew9NnZNP/iXHaYrzpET7 pVy7ttcmcKW+XEaQoWUodCrJlVi8yNXstwbXWoPgX34SB8x9eTRkCrL+B/3eRL0Ii+Pt ufjynAq0ZwpdNsC0/gUmjCrBxnGsKhFv2Lf0M= Received: by 10.151.48.12 with SMTP id a12mr4623277ybk.224.1289011255016; Fri, 05 Nov 2010 19:40:55 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z16sm1513786ybm.4.2010.11.05.19.40.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Nov 2010 19:40:53 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 5 Nov 2010 19:40:47 -0700 From: Pyun YongHyeon Date: Fri, 5 Nov 2010 19:40:47 -0700 To: Rick Macklem Message-ID: <20101106024047.GD22715@michelle.cdnetworks.com> References: <20101105023153.GA20301@michelle.cdnetworks.com> <77175273.185228.1289000696906.JavaMail.root@erie.cs.uoguelph.ca> <20101106023345.GC22715@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20101106023345.GC22715@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 02:40:56 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 05, 2010 at 07:33:45PM -0700, Pyun YongHyeon wrote: [...] > > If this theory is correct, the attached patch may mitigate the > issue. > Oops, I incorrectly used old code. Please use this one. --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.intr.patch4" Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 214844) +++ sys/pci/if_rlreg.h (working copy) @@ -873,9 +873,7 @@ int rl_twist_row; int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ -#ifdef DEVICE_POLLING int rxcycles; -#endif struct task rl_txtask; struct task rl_inttask; Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 214844) +++ sys/dev/re/if_re.c (working copy) @@ -1860,7 +1860,7 @@ int i, total_len; struct rl_desc *cur_rx; u_int32_t rxstat, rxvlan; - int maxpkt = 16, rx_npkts = 0; + int rx_npkts = 0; RL_LOCK_ASSERT(sc); @@ -1872,7 +1872,7 @@ sc->rl_ldata.rl_rx_list_map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); - for (i = sc->rl_ldata.rl_rx_prodidx; maxpkt > 0; + for (i = sc->rl_ldata.rl_rx_prodidx; sc->rxcycles > 0; i = RL_RX_DESC_NXT(sc, i)) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) break; @@ -2036,7 +2036,7 @@ } } } - maxpkt--; + sc->rxcycles--; if (rxvlan & RL_RDESC_VLANCTL_TAG) { m->m_pkthdr.ether_vtag = bswap16((rxvlan & RL_RDESC_VLANCTL_DATA)); @@ -2058,10 +2058,10 @@ if (rx_npktsp != NULL) *rx_npktsp = rx_npkts; - if (maxpkt) - return (EAGAIN); + if (sc->rxcycles) + return (0); - return (0); + return (EAGAIN); } static void @@ -2258,8 +2258,11 @@ } #endif - if (status & (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_FIFO_OFLOW)) + if (status & (RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW | + RL_ISR_RX_OVERRUN)) { + sc->rxcycles = sc->rl_ldata.rl_rx_desc_cnt / 2; rval = re_rxeof(sc, NULL); + } /* * Some chips will ignore a second TX request issued --rS8CxjVDS/+yyDmU-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 04:42:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51FA0106566B for ; Sat, 6 Nov 2010 04:42:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA4E88FC16 for ; Sat, 6 Nov 2010 04:42:28 +0000 (UTC) Received: by wyb34 with SMTP id 34so1754983wyb.13 for ; Fri, 05 Nov 2010 21:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=6Kr81SRRpnLD9a/Esk9pCjWXDF/YYbnCdjjxE88x/mI=; b=qyUdcGwiFFDE71dgHAexEbvJmZlIz0XelNp9m+dIRwWrhS+uwMgbOM+rMFgSfucOki I8a8ZCefyyIxGw2cTtEBZGDobqxXT3eEjZPdLpOpjIi5ZjisSYKAwZ6PVla0V3ugTJXx PoP0tPeO1+NpzOx/rwp8AIX3Ot7mVuTkJFZCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Of014v8tH0fEumukAgvWO5kpG2E9IHoK+pHuP3OZGuuGiZZV/cYxF8Ao+bzHnqzZCy UF4qW+cFuJf6MGaiXjdgZLjP3F/pQWC93PAJ8CUxNSKJqR7G5xDN+ZEvaz/mgzrZk6+A a/762w9wV33WOsc9XL/W/wko5HXX1DVcKlhME= MIME-Version: 1.0 Received: by 10.216.46.200 with SMTP id r50mr1975118web.45.1289018547200; Fri, 05 Nov 2010 21:42:27 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.198.27 with HTTP; Fri, 5 Nov 2010 21:42:27 -0700 (PDT) In-Reply-To: <20101105202536.GR85693@acme.spoerlein.net> References: <20101105202536.GR85693@acme.spoerlein.net> Date: Fri, 5 Nov 2010 21:42:27 -0700 X-Google-Sender-Auth: C6fHeKSI7ZPNVozl4xTmR7DJC_w Message-ID: From: Garrett Cooper To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 04:42:29 -0000 On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Sp=F6rlein wrote= : > Hey folks, not sure why, but I had a stab at looking which files were > actually read during building world. > > Method went something like this: > > (turn on atime) > # find . -exec touch {} + > # sleep 2; touch timestamp > # make buildworld buildkernel installworld installkernel (this is on amd6= 4) > # make universe > # make distribution DESTDIR=3D/foo > # mergemaster (I think this is redundant) > # find . -name .svn -prune -or -not -anewer timestamp > > Please note that I skipped 'make release' as I don't know all the > parameters off-hand. > > The list of files (tools/ removed) can be seen at > https://www.spoerlein.net/pub/untouched_files > > Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped): > > bin/sh/bltin/echo.1 I'd talk to jilles@ (weird thing is that this is installed on my machine). ... > lib/libarchive/archive_crc32.h > lib/libarchive/libarchive_internals.3 I'd talk to kientzle@. > lib/libautofs/Makefile > lib/libautofs/libautofs.3 > lib/libautofs/libautofs.c > lib/libautofs/libautofs.h Missing from lib/Makefile (hmmm...). > lib/libc/sys/kse.2 Shouldn't kse be yanked? ... > lib/libkse/* =A0 # dito Same as above. ... > sbin/bsdlabel/bsdlabel.5 # eh? Not sure why but this was commented out (see the Makefile). > sbin/mount/getmntopts.3 It would be nice if this was installed too. > sbin/mount_autofs/Makefile > sbin/mount_autofs/mount_autofs.8 > sbin/mount_autofs/mount_autofs.c > sbin/mount_ext2fs/Makefile > sbin/mount_ext2fs/mount_ext2fs.8 > sbin/mount_ext2fs/mount_ext2fs.c > sbin/mount_hpfs/Makefile > sbin/mount_hpfs/mount_hpfs.8 > sbin/mount_hpfs/mount_hpfs.c > sbin/mount_reiserfs/Makefile > sbin/mount_reiserfs/mount_reiserfs.8 > sbin/mount_reiserfs/mount_reiserfs.c > sbin/mount_std/Makefile > sbin/mount_std/mount_std.8 > sbin/mount_std/mount_std.c Not sure about the above items. > usr.bin/cpio/test/* =A0 =A0 # move to tools/regression? Seems like a legitimate request. ... > usr.bin/setchannel/Makefile > usr.bin/setchannel/setchannel.1 > usr.bin/setchannel/setchannel.c Not included in usr.bin/Makefile . ... > usr.sbin/gpioctl =A0 =A0 =A0 =A0# wtf? my system has MK_GPIO=3Dno set? Unless you say WITH_GPIO, it defaults to WITHOUT_GPIO (according to what I'm reading from bsd.own.mk). ... > I haven't looked too closely (ie., not at all) at these cases. Please > discuss and happy browsing the list! Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 05:18:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C8F106564A; Sat, 6 Nov 2010 05:18:49 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1F14A8FC18; Sat, 6 Nov 2010 05:18:48 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id oA65IcFd046868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Nov 2010 14:18:42 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 06 Nov 2010 14:18:37 +0900 Message-ID: From: Hajimu UMEMOTO To: John Baldwin In-Reply-To: <201011051716.47962.jhb@freebsd.org> References: <20101105202536.GR85693@acme.spoerlein.net> <201011051716.47962.jhb@freebsd.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.1-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 06 Nov 2010 14:18:42 +0900 (JST) X-Virus-Scanned: clamav-milter 0.96.4 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: freebsd-current@freebsd.org Subject: Re: Files under src/ not used for building world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 05:18:49 -0000 Hi, >>>>> On Fri, 5 Nov 2010 17:16:47 -0400 >>>>> John Baldwin said: > etc/periodic/security/610.ipf6denied jhb> I wonder if this is stale due to ip6fw being removed? No, it seems to me that it is not related to ip6fw, and it calls ipfstat. Perhaps, some work for IPv6 support of IP Filter? Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 08:36:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD941065670; Sat, 6 Nov 2010 08:36:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 23B178FC18; Sat, 6 Nov 2010 08:36:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=NeL9HQIyaxTiqRflnoYA:9 a=Jzdrks91--tz73bWEW4A:7 a=b0ip0QWF_mfza3iejVZCFHj2lVUA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45442018; Sat, 06 Nov 2010 09:36:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 09:37:50 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> In-Reply-To: <201011051506.12643.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011060937.50639.hselasky@c2i.net> Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 08:36:46 -0000 On Friday 05 November 2010 20:06:12 John Baldwin wrote: > On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > > > > wrote: > > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > > >> prevent a task from becoming enqueued again. The same issue exists > > > >> with taskqueue_drain(). > > > > > > > > I find that strange, because that means if I queue a task again while > > > > it is running, then I doesn't get run? Are you really sure? > > > > > > If a task is currently running when enqueued, the task struct will be > > > re-enqueued to the taskqueue. When that task comes up as the head of > > > the queue, it will be run again. > > > > Right, and the taskqueue_cancel has to cancel in that state to, but it > > doesn't because it only checks pending if !running() :-) ?? > > You can't close that race in taskqueue_cancel(). You have to manage that > race yourself in your task handler. For the callout(9) API we are only > able to close that race if you use callout_init_mtx() so that the code > managing the callout wheel can make use of your lock to resolve the races. > If you use callout_init() you have to explicitly manage these races in your > callout handler. Hi, I think you are getting me wrong! In the initial "0001-Implement- taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following code- chunk: +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if (!task_is_running(queue, task)) { + if ((rc = task->ta_pending) > 0) + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } else + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} This code should be written like this, having the if (!task_is_running()) after checking the ta_pending variable. +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if ((rc = task->ta_pending) > 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (!task_is_running(queue, task)) + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} Or completely skip the !task_is_running() check. Else you are opening up a race in this function! Do I need to explain that more? Isn't it obvious? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 09:57:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D3191065672 for ; Sat, 6 Nov 2010 09:57:06 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by mx1.freebsd.org (Postfix) with ESMTP id 175C08FC1A for ; Sat, 6 Nov 2010 09:57:05 +0000 (UTC) Received: from wmail46 (172.31.0.236) by cp-out1.libero.it (8.5.115) (authenticated as barbara.xxx1975@libero.it) id 4AB2342317FDA4B5 for freebsd-current@freebsd.org; Sat, 6 Nov 2010 10:57:04 +0100 Message-ID: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> Date: Sat, 6 Nov 2010 10:57:04 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.3.210.9 Subject: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:57:06 -0000 I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. In the part of the code causing the crash, a std::map is read with an iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while and increasing the iterator before erasing from the map, and it seems working. Then I wrote a simple program that do something similar to IcedTea, so there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g I hope that the crash is not caused by a bad environment, can anyone else test it? Thanks Barbara From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:09:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4FEA106564A for ; Sat, 6 Nov 2010 10:09:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF3B8FC08 for ; Sat, 6 Nov 2010 10:09:25 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 3A77C2A28C30; Sat, 6 Nov 2010 11:09:24 +0100 (CET) Date: Sat, 6 Nov 2010 11:09:24 +0100 From: Ed Schouten To: Barbara Message-ID: <20101106100924.GT2054@hoeg.nl> References: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2wYUONsACSj9OMJp" Content-Disposition: inline In-Reply-To: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:09:26 -0000 --2wYUONsACSj9OMJp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Barbara , 20101106 10:57: > Just to be clear, I'm not looking for a solution about the port here, > I'm just wondering why the same c++ code is working on 8_STABLE and > it's segfaulting on CURRENT, considering also that AFAIK the gcc > version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --2wYUONsACSj9OMJp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzVKVQACgkQ52SDGA2eCwWPWgCdFR1JO6wyF6SE9sb5WOMoDrGd 4VkAnidl/i2veaA7waEqJ7a9IQRAuyeZ =0XsM -----END PGP SIGNATURE----- --2wYUONsACSj9OMJp-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:20:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD961106564A for ; Sat, 6 Nov 2010 10:20:47 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by mx1.freebsd.org (Postfix) with ESMTP id 586B98FC13 for ; Sat, 6 Nov 2010 10:20:46 +0000 (UTC) Received: from wmail46 (172.31.0.236) by cp-out4.libero.it (8.5.107) (authenticated as barbara.xxx1975@libero.it) id 4CCF0A0E0061BFDE; Sat, 6 Nov 2010 11:20:42 +0100 Message-ID: <23015841.925301289038842271.JavaMail.defaultUser@defaultHost> Date: Sat, 6 Nov 2010 11:20:42 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.3.210.9 Cc: freebsd-current@freebsd.org Subject: R: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:20:47 -0000 >* Barbara , 20101106 10:57: >> Just to be clear, I'm not looking for a solution about the port here, >> I'm just wondering why the same c++ code is working on 8_STABLE and >> it's segfaulting on CURRENT, considering also that AFAIK the gcc >> version in both the base systems is the same. > >I am a real STL newbie, so I could be wrong. Maybe it's not allowed to >remove an element in the map you're currently iterating. Therefore >you're accessing memory which has been deallocated. > I'm sure you're not worse than me! :) Anyway that's what I was thinking when I wrote the patch. >This may crash on HEAD and not on 8-STABLE for various reasons. For >example, malloc() in HEAD has all sorts of debugging options enabled, >while 8-STABLE does not. > So you think that the problem is really in the original source code, but exposed only on CURRENT. That could be an option. Thanks Barbara From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:31:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FCC01065670 for ; Sat, 6 Nov 2010 10:31:22 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2A3C48FC17 for ; Sat, 6 Nov 2010 10:31:22 +0000 (UTC) Received: from wmail46 (172.31.0.236) by cp-out2.libero.it (8.5.107) (authenticated as barbara.xxx1975@libero.it) id 4CCEC8E5006586B1; Sat, 6 Nov 2010 11:31:20 +0100 Message-ID: <13873405.926621289039480757.JavaMail.defaultUser@defaultHost> Date: Sat, 6 Nov 2010 11:31:20 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.3.210.9 Cc: dudu@dudu.ro Subject: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:31:22 -0000 >On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote= : >> >> I had a problem running the IcedTea java plugin on CURRENT i386, while i= t >> works on 8_STABLE. >> But maybe it's not a problem related to the port. >> Just to be clear, I'm not looking for a solution about the port here, I'= m=20 just >> wondering why the same c++ code is working on 8_STABLE and it's segfault= ing=20 on >> CURRENT, considering also that AFAIK the gcc version in both the base=20 systems >> is the same. >> >> In the part of the code causing the crash, a std::map is read with an=20 iterator >> in a for loop, and if a condition is met, an entry is erased. >> The following is the bt I'm getting: >> #0 =C2=A00x29e36247 in kill () from /lib/libc.so.7 >> #1 =C2=A00x29e361a6 in raise () from /lib/libc.so.7 >> #2 =C2=A00x282424f6 in XRE_LockProfileDirectory () from >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/lib/firefox3/libxul.so >> #3 =C2=A0 >> #4 =C2=A00x29c8f1b2 in std::_Rb_tree_increment () from >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/lib/libstdc++.so.6 #5 =C2=A00x2ef92402 i= n >> =C2=A0 =C2=A0 =C2=A0 =C2=A0IcedTeaPluginUtilities::invalidateInstance ()= from >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >> ... >> >> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a= =20 while >> and increasing the iterator before erasing from the map, and it seems=20 working. >> Then I wrote a simple program that do something similar to IcedTea, so= =20 there >> is no need to build the whole java/openjdk6 port to do some testing. >> Running it on 8_STABLE it works, on CURRENT it crashes. >> You can find more details in this discussion on the freebsd-java ml: >> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.htm= l >> >> You can find the patch and the sample code in the discussion above, anyw= ay=20 I'm >> reporting them here too: >> icedtea patch: >> http://pastebin.com/b2KKFNSG >> test case: >> http://pastebin.com/Amk4UJ0g > >You appear to invalidate the iterator inside the loop and then >increment it. Do the following: > >-- cut here -- >for (iter =3D cars.begin(); iter !=3D cars.end(); ) { > if ((*iter).second =3D=3D modelName) > cars.erase(iter++); > else > ++iter; >} >-- and here -- > >In this example, you first increment the iterator and then erase its >previous value. > So there is a bug in my source code! Well, I'm not surprised. I'm trying to report the code in icedtea here, extracting it from the patch= so=20 I hope it's accurate enough: std::map::iterator iterator;=20 for (iterator =3D instance_map->begin(); iterator !=3D instance_map->en= d();=20 iterator++) { if ((*iterator).second =3D=3D instance) { instance_map->erase((*iterator).first); } } So, do you think, like Ed Schouten said, that there is a bug in the source= =20 code but it's just exposed on CURRENT? Is that code bad too? Thanks Barbara From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:33:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B131065675 for ; Sat, 6 Nov 2010 10:33:04 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE01A8FC08 for ; Sat, 6 Nov 2010 10:33:03 +0000 (UTC) Received: by wyb34 with SMTP id 34so1882333wyb.13 for ; Sat, 06 Nov 2010 03:33:02 -0700 (PDT) Received: by 10.216.7.205 with SMTP id 55mr2009006wep.96.1289039581732; Sat, 06 Nov 2010 03:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:32:21 -0700 (PDT) In-Reply-To: References: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:32:21 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:33:04 -0000 On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote: > On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrot= e: >> >> I had a problem running the IcedTea java plugin on CURRENT i386, while i= t >> works on 8_STABLE. >> But maybe it's not a problem related to the port. >> Just to be clear, I'm not looking for a solution about the port here, I'= m just >> wondering why the same c++ code is working on 8_STABLE and it's segfault= ing on >> CURRENT, considering also that AFAIK the gcc version in both the base sy= stems >> is the same. >> >> In the part of the code causing the crash, a std::map is read with an it= erator >> in a for loop, and if a condition is met, an entry is erased. >> The following is the bt I'm getting: >> #0 =A00x29e36247 in kill () from /lib/libc.so.7 >> #1 =A00x29e361a6 in raise () from /lib/libc.so.7 >> #2 =A00x282424f6 in XRE_LockProfileDirectory () from >> =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so >> #3 =A0 >> #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from >> =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in >> =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from >> =A0 =A0 =A0 =A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >> ... >> >> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a = while >> and increasing the iterator before erasing from the map, and it seems wo= rking. >> Then I wrote a simple program that do something similar to IcedTea, so t= here >> is no need to build the whole java/openjdk6 port to do some testing. >> Running it on 8_STABLE it works, on CURRENT it crashes. >> You can find more details in this discussion on the freebsd-java ml: >> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.htm= l >> >> You can find the patch and the sample code in the discussion above, anyw= ay I'm >> reporting them here too: >> icedtea patch: >> http://pastebin.com/b2KKFNSG >> test case: >> http://pastebin.com/Amk4UJ0g > > You appear to invalidate the iterator inside the loop and then > increment it. Do the following: > > -- cut here -- > for (iter =3D cars.begin(); iter !=3D cars.end(); ) { > =A0if ((*iter).second =3D=3D modelName) > =A0cars.erase(iter++); > =A0else > =A0++iter; > } > -- and here -- > > In this example, you first increment the iterator and then erase its > previous value. Or, better yet: cars.erase("punto"); I see no reason in iterating through the whole map unless you want to relate the deletion to the matched type, in which case you should use the previous example. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:34:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5587D106567A for ; Sat, 6 Nov 2010 10:34:13 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id EAFC18FC16 for ; Sat, 6 Nov 2010 10:34:12 +0000 (UTC) Received: by wwb28 with SMTP id 28so312961wwb.31 for ; Sat, 06 Nov 2010 03:34:12 -0700 (PDT) Received: by 10.216.231.227 with SMTP id l77mr2003936weq.104.1289039651822; Sat, 06 Nov 2010 03:34:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:33:31 -0700 (PDT) In-Reply-To: <13873405.926621289039480757.JavaMail.defaultUser@defaultHost> References: <13873405.926621289039480757.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:33:31 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:34:13 -0000 On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote: > > >>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrot= e: >>> >>> I had a problem running the IcedTea java plugin on CURRENT i386, while = it >>> works on 8_STABLE. >>> But maybe it's not a problem related to the port. >>> Just to be clear, I'm not looking for a solution about the port here, I= 'm > just >>> wondering why the same c++ code is working on 8_STABLE and it's segfaul= ting > on >>> CURRENT, considering also that AFAIK the gcc version in both the base > systems >>> is the same. >>> >>> In the part of the code causing the crash, a std::map is read with an > iterator >>> in a for loop, and if a condition is met, an entry is erased. >>> The following is the bt I'm getting: >>> #0 =A00x29e36247 in kill () from /lib/libc.so.7 >>> #1 =A00x29e361a6 in raise () from /lib/libc.so.7 >>> #2 =A00x282424f6 in XRE_LockProfileDirectory () from >>> =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so >>> #3 =A0 >>> #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from >>> =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in >>> =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from >>> =A0 =A0 =A0 =A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>> ... >>> >>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a > while >>> and increasing the iterator before erasing from the map, and it seems > working. >>> Then I wrote a simple program that do something similar to IcedTea, so > there >>> is no need to build the whole java/openjdk6 port to do some testing. >>> Running it on 8_STABLE it works, on CURRENT it crashes. >>> You can find more details in this discussion on the freebsd-java ml: >>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.ht= ml >>> >>> You can find the patch and the sample code in the discussion above, any= way > I'm >>> reporting them here too: >>> icedtea patch: >>> http://pastebin.com/b2KKFNSG >>> test case: >>> http://pastebin.com/Amk4UJ0g >> >>You appear to invalidate the iterator inside the loop and then >>increment it. Do the following: >> >>-- cut here -- >>for (iter =3D cars.begin(); iter !=3D cars.end(); ) { >> if ((*iter).second =3D=3D modelName) >> =A0cars.erase(iter++); >> else >> =A0++iter; >>} >>-- and here -- >> >>In this example, you first increment the iterator and then erase its >>previous value. >> > > So there is a bug in my source code! Well, I'm not surprised. > > I'm trying to report the code in icedtea here, extracting it from the pat= ch so > I hope it's accurate enough: > > =A0 =A0std::map::iterator iterator; > =A0 =A0for (iterator =3D instance_map->begin(); iterator !=3D instance_ma= p->end(); > iterator++) > =A0 =A0{ > =A0 =A0 =A0if ((*iterator).second =3D=3D instance) > =A0 =A0 =A0 =A0{ > =A0 =A0 =A0 =A0 =A0 instance_map->erase((*iterator).first); > =A0 =A0 =A0 =A0} > =A0 =A0 } > > So, do you think, like Ed Schouten said, that there is a bug in the sourc= e > code but it's just exposed on CURRENT? > Is that code bad too? > > Thanks > Barbara > > Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, whereas STABLE doesn't. So in STABLE you get an old copy of the invalidated iterator, hence it works. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:35:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BCB106566C for ; Sat, 6 Nov 2010 10:35:33 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95A638FC13 for ; Sat, 6 Nov 2010 10:35:32 +0000 (UTC) Received: by wyb34 with SMTP id 34so1883290wyb.13 for ; Sat, 06 Nov 2010 03:35:31 -0700 (PDT) Received: by 10.216.26.194 with SMTP id c44mr2892561wea.104.1289039730703; Sat, 06 Nov 2010 03:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:34:50 -0700 (PDT) In-Reply-To: References: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:34:50 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:35:33 -0000 On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu wrote: > On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote: >> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wro= te: >>> >>> I had a problem running the IcedTea java plugin on CURRENT i386, while = it >>> works on 8_STABLE. >>> But maybe it's not a problem related to the port. >>> Just to be clear, I'm not looking for a solution about the port here, I= 'm just >>> wondering why the same c++ code is working on 8_STABLE and it's segfaul= ting on >>> CURRENT, considering also that AFAIK the gcc version in both the base s= ystems >>> is the same. >>> >>> In the part of the code causing the crash, a std::map is read with an i= terator >>> in a for loop, and if a condition is met, an entry is erased. >>> The following is the bt I'm getting: >>> #0 =A00x29e36247 in kill () from /lib/libc.so.7 >>> #1 =A00x29e361a6 in raise () from /lib/libc.so.7 >>> #2 =A00x282424f6 in XRE_LockProfileDirectory () from >>> =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so >>> #3 =A0 >>> #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from >>> =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in >>> =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from >>> =A0 =A0 =A0 =A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>> ... >>> >>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a= while >>> and increasing the iterator before erasing from the map, and it seems w= orking. >>> Then I wrote a simple program that do something similar to IcedTea, so = there >>> is no need to build the whole java/openjdk6 port to do some testing. >>> Running it on 8_STABLE it works, on CURRENT it crashes. >>> You can find more details in this discussion on the freebsd-java ml: >>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.ht= ml >>> >>> You can find the patch and the sample code in the discussion above, any= way I'm >>> reporting them here too: >>> icedtea patch: >>> http://pastebin.com/b2KKFNSG >>> test case: >>> http://pastebin.com/Amk4UJ0g >> >> You appear to invalidate the iterator inside the loop and then >> increment it. Do the following: >> >> -- cut here -- >> for (iter =3D cars.begin(); iter !=3D cars.end(); ) { >> =A0if ((*iter).second =3D=3D modelName) >> =A0cars.erase(iter++); >> =A0else >> =A0++iter; >> } >> -- and here -- >> >> In this example, you first increment the iterator and then erase its >> previous value. > > Or, better yet: cars.erase("punto"); I see no reason in iterating > through the whole map unless you want to relate the deletion to the > matched type, in which case you should use the previous example. > Sorry, I meant mapped type. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:37:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2D901065675 for ; Sat, 6 Nov 2010 10:37:01 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8517B8FC15 for ; Sat, 6 Nov 2010 10:37:01 +0000 (UTC) Received: by wyb34 with SMTP id 34so1884058wyb.13 for ; Sat, 06 Nov 2010 03:37:00 -0700 (PDT) Received: by 10.216.231.227 with SMTP id l77mr1988733weq.104.1289038353440; Sat, 06 Nov 2010 03:12:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:11:53 -0700 (PDT) In-Reply-To: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> References: <19821003.923081289037424002.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:11:53 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:37:02 -0000 On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote: > > I had a problem running the IcedTea java plugin on CURRENT i386, while it > works on 8_STABLE. > But maybe it's not a problem related to the port. > Just to be clear, I'm not looking for a solution about the port here, I'm= just > wondering why the same c++ code is working on 8_STABLE and it's segfaulti= ng on > CURRENT, considering also that AFAIK the gcc version in both the base sys= tems > is the same. > > In the part of the code causing the crash, a std::map is read with an ite= rator > in a for loop, and if a condition is met, an entry is erased. > The following is the bt I'm getting: > #0 =A00x29e36247 in kill () from /lib/libc.so.7 > #1 =A00x29e361a6 in raise () from /lib/libc.so.7 > #2 =A00x282424f6 in XRE_LockProfileDirectory () from > =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so > #3 =A0 > #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from > =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in > =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from > =A0 =A0 =A0 =A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so > ... > > I wrote a "patch" for the IcedTea plugin, replacing the for loop with a w= hile > and increasing the iterator before erasing from the map, and it seems wor= king. > Then I wrote a simple program that do something similar to IcedTea, so th= ere > is no need to build the whole java/openjdk6 port to do some testing. > Running it on 8_STABLE it works, on CURRENT it crashes. > You can find more details in this discussion on the freebsd-java ml: > http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html > > You can find the patch and the sample code in the discussion above, anywa= y I'm > reporting them here too: > icedtea patch: > http://pastebin.com/b2KKFNSG > test case: > http://pastebin.com/Amk4UJ0g You appear to invalidate the iterator inside the loop and then increment it. Do the following: -- cut here -- for (iter =3D cars.begin(); iter !=3D cars.end(); ) { if ((*iter).second =3D=3D modelName) cars.erase(iter++); else ++iter; } -- and here -- In this example, you first increment the iterator and then erase its previous value. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:44:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8B2E106566B for ; Sat, 6 Nov 2010 10:44:01 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by mx1.freebsd.org (Postfix) with ESMTP id 71C728FC0A for ; Sat, 6 Nov 2010 10:44:01 +0000 (UTC) Received: from wmail46 (172.31.0.236) by cp-out1.libero.it (8.5.115) (authenticated as barbara.xxx1975@libero.it) id 4AB2342317FE36A7; Sat, 6 Nov 2010 11:44:00 +0100 Message-ID: <21554061.928151289040240274.JavaMail.defaultUser@defaultHost> Date: Sat, 6 Nov 2010 11:44:00 +0100 (CET) From: Barbara To: MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.3.210.9 Cc: dudu@dudu.ro Subject: R: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:44:02 -0000 >On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote= : >> >> >>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wro= te: >>>> >>>> I had a problem running the IcedTea java plugin on CURRENT i386, while= it >>>> works on 8_STABLE. >>>> But maybe it's not a problem related to the port. >>>> Just to be clear, I'm not looking for a solution about the port here, = I'm >> just >>>> wondering why the same c++ code is working on 8_STABLE and it's=20 segfaulting >> on >>>> CURRENT, considering also that AFAIK the gcc version in both the base >> systems >>>> is the same. >>>> >>>> In the part of the code causing the crash, a std::map is read with an >> iterator >>>> in a for loop, and if a condition is met, an entry is erased. >>>> The following is the bt I'm getting: >>>> #0 =C2=A00x29e36247 in kill () from /lib/libc.so.7 >>>> #1 =C2=A00x29e361a6 in raise () from /lib/libc.so.7 >>>> #2 =C2=A00x282424f6 in XRE_LockProfileDirectory () from >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/lib/firefox3/libxul.so >>>> #3 =C2=A0 >>>> #4 =C2=A00x29c8f1b2 in std::_Rb_tree_increment () from >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/lib/libstdc++.so.6 #5 =C2=A00x2ef92402= in >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0IcedTeaPluginUtilities::invalidateInstance = () from >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.s= o >>>> ... >>>> >>>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with = a >> while >>>> and increasing the iterator before erasing from the map, and it seems >> working. >>>> Then I wrote a simple program that do something similar to IcedTea, so >> there >>>> is no need to build the whole java/openjdk6 port to do some testing. >>>> Running it on 8_STABLE it works, on CURRENT it crashes. >>>> You can find more details in this discussion on the freebsd-java ml: >>>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.h= tml >>>> >>>> You can find the patch and the sample code in the discussion above,=20 anyway >> I'm >>>> reporting them here too: >>>> icedtea patch: >>>> http://pastebin.com/b2KKFNSG >>>> test case: >>>> http://pastebin.com/Amk4UJ0g >>> >>>You appear to invalidate the iterator inside the loop and then >>>increment it. Do the following: >>> >>>-- cut here -- >>>for (iter =3D cars.begin(); iter !=3D cars.end(); ) { >>> if ((*iter).second =3D=3D modelName) >>> =C2=A0cars.erase(iter++); >>> else >>> =C2=A0++iter; >>>} >>>-- and here -- >>> >>>In this example, you first increment the iterator and then erase its >>>previous value. >>> >> >> So there is a bug in my source code! Well, I'm not surprised. >> >> I'm trying to report the code in icedtea here, extracting it from the pa= tch=20 so >> I hope it's accurate enough: >> >> =C2=A0 =C2=A0std::map::iterator iterator; >> =C2=A0 =C2=A0for (iterator =3D instance_map->begin(); iterator !=3D inst= ance_map->end(); >> iterator++) >> =C2=A0 =C2=A0{ >> =C2=A0 =C2=A0 =C2=A0if ((*iterator).second =3D=3D instance) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0{ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance_map->erase((*iterator).first= ); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> =C2=A0 =C2=A0 } >> >> So, do you think, like Ed Schouten said, that there is a bug in the sour= ce >> code but it's just exposed on CURRENT? >> Is that code bad too? >> >> Thanks >> Barbara >> >> > >Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, >whereas STABLE doesn't. So in STABLE you get an old copy of the >invalidated iterator, hence it works. > Very nice explanation. Thanks From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 10:48:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76AB6106564A for ; Sat, 6 Nov 2010 10:48:00 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 015638FC19 for ; Sat, 6 Nov 2010 10:47:59 +0000 (UTC) Received: by wyb34 with SMTP id 34so1888493wyb.13 for ; Sat, 06 Nov 2010 03:47:59 -0700 (PDT) Received: by 10.227.136.143 with SMTP id r15mr3095674wbt.151.1289040477100; Sat, 06 Nov 2010 03:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.175.66 with HTTP; Sat, 6 Nov 2010 03:47:16 -0700 (PDT) In-Reply-To: <21554061.928151289040240274.JavaMail.defaultUser@defaultHost> References: <21554061.928151289040240274.JavaMail.defaultUser@defaultHost> From: Vlad Galu Date: Sat, 6 Nov 2010 11:47:16 +0100 Message-ID: To: Barbara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Re: libstc++ (?) problem on CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:48:00 -0000 On Sat, Nov 6, 2010 at 11:44 AM, Barbara wrote: > >>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrot= e: >>> >>> >>>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wr= ote: >>>>> >>>>> I had a problem running the IcedTea java plugin on CURRENT i386, whil= e it >>>>> works on 8_STABLE. >>>>> But maybe it's not a problem related to the port. >>>>> Just to be clear, I'm not looking for a solution about the port here,= I'm >>> just >>>>> wondering why the same c++ code is working on 8_STABLE and it's > segfaulting >>> on >>>>> CURRENT, considering also that AFAIK the gcc version in both the base >>> systems >>>>> is the same. >>>>> >>>>> In the part of the code causing the crash, a std::map is read with an >>> iterator >>>>> in a for loop, and if a condition is met, an entry is erased. >>>>> The following is the bt I'm getting: >>>>> #0 =A00x29e36247 in kill () from /lib/libc.so.7 >>>>> #1 =A00x29e361a6 in raise () from /lib/libc.so.7 >>>>> #2 =A00x282424f6 in XRE_LockProfileDirectory () from >>>>> =A0 =A0 =A0 =A0/usr/local/lib/firefox3/libxul.so >>>>> #3 =A0 >>>>> #4 =A00x29c8f1b2 in std::_Rb_tree_increment () from >>>>> =A0 =A0 =A0 =A0/usr/lib/libstdc++.so.6 #5 =A00x2ef92402 in >>>>> =A0 =A0 =A0 =A0IcedTeaPluginUtilities::invalidateInstance () from >>>>> =A0 =A0 =A0 =A0/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so >>>>> ... >>>>> >>>>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with= a >>> while >>>>> and increasing the iterator before erasing from the map, and it seems >>> working. >>>>> Then I wrote a simple program that do something similar to IcedTea, s= o >>> there >>>>> is no need to build the whole java/openjdk6 port to do some testing. >>>>> Running it on 8_STABLE it works, on CURRENT it crashes. >>>>> You can find more details in this discussion on the freebsd-java ml: >>>>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.= html >>>>> >>>>> You can find the patch and the sample code in the discussion above, > anyway >>> I'm >>>>> reporting them here too: >>>>> icedtea patch: >>>>> http://pastebin.com/b2KKFNSG >>>>> test case: >>>>> http://pastebin.com/Amk4UJ0g >>>> >>>>You appear to invalidate the iterator inside the loop and then >>>>increment it. Do the following: >>>> >>>>-- cut here -- >>>>for (iter =3D cars.begin(); iter !=3D cars.end(); ) { >>>> if ((*iter).second =3D=3D modelName) >>>> =A0cars.erase(iter++); >>>> else >>>> =A0++iter; >>>>} >>>>-- and here -- >>>> >>>>In this example, you first increment the iterator and then erase its >>>>previous value. >>>> >>> >>> So there is a bug in my source code! Well, I'm not surprised. >>> >>> I'm trying to report the code in icedtea here, extracting it from the p= atch > so >>> I hope it's accurate enough: >>> >>> =A0 =A0std::map::iterator iterator; >>> =A0 =A0for (iterator =3D instance_map->begin(); iterator !=3D instance_= map->end(); >>> iterator++) >>> =A0 =A0{ >>> =A0 =A0 =A0if ((*iterator).second =3D=3D instance) >>> =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0 instance_map->erase((*iterator).first); >>> =A0 =A0 =A0 =A0} >>> =A0 =A0 } >>> >>> So, do you think, like Ed Schouten said, that there is a bug in the sou= rce >>> code but it's just exposed on CURRENT? >>> Is that code bad too? >>> >>> Thanks >>> Barbara >>> >>> >> >>Yes, I believe CURRENT's malloc zeroes out the memory upon deletion, >>whereas STABLE doesn't. So in STABLE you get an old copy of the >>invalidated iterator, hence it works. >> > > Very nice explanation. > > Thanks > > I hope I'm right, I don't have CURRENT installed, it's just an assumption. However, the C++ code is most definitely buggy. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 13:57:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537641065670; Sat, 6 Nov 2010 13:57:51 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E05B28FC0C; Sat, 6 Nov 2010 13:57:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so4024936iwn.13 for ; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qneazsDNIHnT+FEsdzd/Vc6yhd1g6m4aAkCjeGHIAMw=; b=CFnhB3cCkSNfelW8UcFuxLarlS+3zZMlijDET3vxNkRySt9ibcgHRpjS7Om4X1K7/5 WR+P4/a1SOSG+F+qySywBouVWukTQfSpZarFVoXYlRR+vsxdXishRDf7Y11mFxC4xPbR BTt29+FPoWyra4/37TfiTOi2M/F2gJZ0YXSmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZco27Wbk68/LY9YVT6k3pPpaQecIFIYOS9uT5ZdHrvfkRyXG7sYDcdWRuUUOSlgf+ ySk7pJPZh4nIrArxFMh36HqbQbgFkAWw3cqhpo3ZOnCurV1Lzcj5z8bC270IyWFeuX7p wC+EPwA8+NSTFkaxSnq9AKLOPb0ShcubMGC8c= MIME-Version: 1.0 Received: by 10.231.35.138 with SMTP id p10mr2659573ibd.33.1289051870364; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 06:57:50 -0700 (PDT) In-Reply-To: <201011060937.50639.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> <201011060937.50639.hselasky@c2i.net> Date: Sat, 6 Nov 2010 06:57:50 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 13:57:51 -0000 On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky wrot= e: > On Friday 05 November 2010 20:06:12 John Baldwin wrote: >> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: >> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: >> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky >> > >> > wrote: >> > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> > > >> True, but no taskqueue(9) code can handle that. =A0Only the calle= r can >> > > >> prevent a task from becoming enqueued again. =A0The same issue ex= ists >> > > >> with taskqueue_drain(). >> > > > >> > > > I find that strange, because that means if I queue a task again wh= ile >> > > > it is running, then I doesn't get run? Are you really sure? >> > > >> > > If a task is currently running when enqueued, the task struct will b= e >> > > re-enqueued to the taskqueue. =A0When that task comes up as the head= of >> > > the queue, it will be run again. >> > >> > Right, and the taskqueue_cancel has to cancel in that state to, but it >> > doesn't because it only checks pending if !running() :-) ?? >> >> You can't close that race in taskqueue_cancel(). =A0You have to manage t= hat >> race yourself in your task handler. =A0For the callout(9) API we are onl= y >> able to close that race if you use callout_init_mtx() so that the code >> managing the callout wheel can make use of your lock to resolve the race= s. >> If you use callout_init() you have to explicitly manage these races in y= our >> callout handler. > > Hi, > > I think you are getting me wrong! In the initial "0001-Implement- > taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following = code- > chunk: > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; > + =A0 =A0 =A0 } else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > This code should be written like this, having the if (!task_is_running()) > after checking the ta_pending variable. > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->t= a_pending =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 if (!task_is_running(queue, task)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > Or completely skip the !task_is_running() check. Else you are opening up = a > race in this function! Do I need to explain that more? Isn't it obvious? I think you're misunderstanding the existing taskqueue(9) implementation. As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, nor can the set of running tasks. So the order of checks is irrelevant. As John said, the taskqueue(9) implementation cannot protect consumers of it from re-queueing a task; that kind of serialization needs to happen at a higher level. taskqueue(9) is not quite like callout(9); the taskqueue(9) implementation drops all locks before calling the task's callback function. So once the task is running, taskqueue(9) can do nothing about it until the task stops running. This is why Jeff's implementation of taskqueue_cancel(9) slept if the task was running, and why mine returns an error code. The only way to know for sure that a task is "about" to run is to ask taskqueue(9), because there's a window where the TQ_LOCK is dropped before the callback is entered. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 14:21:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0D01065673; Sat, 6 Nov 2010 14:21:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4673E8FC0A; Sat, 6 Nov 2010 14:21:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Z_5cUCg6Vf7GDme7dpcA:9 a=Ucnf10t7tCBU3dq19hQA:7 a=7vaHduFuufULc36w12w6ebi1-I0A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45604739; Sat, 06 Nov 2010 15:21:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 15:22:26 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011061522.26533.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 14:21:22 -0000 Hi, On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > > I think you're misunderstanding the existing taskqueue(9) implementation. > > As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > nor can the set of running tasks. So the order of checks is > irrelevant. I agree that the order of checks is not important. That is not the problem. Cut & paste from suggested taskqueue patch from Fleming: > +int > > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > > +{ > > + int rc; > > + > > + TQ_LOCK(queue); > > + if (!task_is_running(queue, task)) { > > + if ((rc = task->ta_pending) > 0) > > + STAILQ_REMOVE(&queue->tq_queue, task, task, > > ta_link); + task->ta_pending = 0; > > + } else { > > + rc = -EBUSY; What happens in this case if ta_pending > 0. Are you saying this is not possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > + } > > + TQ_UNLOCK(queue); > > + return (rc); > > +} > > > As John said, the taskqueue(9) implementation cannot protect consumers > of it from re-queueing a task; that kind of serialization needs to > happen at a higher level. Agreed, but that is not what I'm pointing at. I'm pointing at what happens if you re-queue a task and then cancel while it is actually running. Will the task still be queued for execution after taskqueue_cancel()? > taskqueue(9) is not quite like callout(9); the taskqueue(9) > implementation drops all locks before calling the task's callback > function. So once the task is running, taskqueue(9) can do nothing > about it until the task stops running. This is not the problem. > > This is why Jeff's > implementation of taskqueue_cancel(9) slept if the task was running, > and why mine returns an error code. The only way to know for sure > that a task is "about" to run is to ask taskqueue(9), because there's > a window where the TQ_LOCK is dropped before the callback is entered. And if you re-queue and cancel in this window, shouldn't this also be handled like in the other cases? Cut & paste from kern/subr_taskqueue.c: task->ta_pending = 0; tb.tb_running = task; TQ_UNLOCK(queue); If a concurrent thread at exactly this point in time calls taskqueue_enqueue() on this task, then we re-add the task to the "queue->tq_queue". So far we agree. Imagine now that for some reason a following call to taskqueue_cancel() on this task at same point in time. Now, shouldn't taskqueue_cancel() also remove the task from the "queue->tq_queue" in this case aswell? Because in your implementation you only remove the task if we are not running, and that is not true when we are at exactly this point in time. task->ta_func(task->ta_context, pending); TQ_LOCK(queue); tb.tb_running = NULL; wakeup(task); Another issue I noticed is that the ta_pending counter should have a wrap protector. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 14:25:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E181065696; Sat, 6 Nov 2010 14:25:46 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6992D8FC08; Sat, 6 Nov 2010 14:25:46 +0000 (UTC) Received: from [88.217.8.67] (helo=current.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PEjiC-0005s6-Tn; Sat, 06 Nov 2010 15:25:45 +0100 Received: from current.Sisis.de (current [127.0.0.1]) by current.Sisis.de (8.14.3/8.14.3) with ESMTP id oA6EPhOG003559; Sat, 6 Nov 2010 15:25:43 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by current.Sisis.de (8.14.3/8.14.3/Submit) id oA6EPgFD003558; Sat, 6 Nov 2010 15:25:42 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: current.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Sat, 6 Nov 2010 15:25:42 +0100 From: Matthias Apitz To: Alexander Motin Message-ID: <20101106142542.GA3472@current.Sisis.de> References: <4CD337DA.7030902@FreeBSD.org> <20101104230735.GA6686@current.Sisis.de> <4CD33E0B.1070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD33E0B.1070304@FreeBSD.org> X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.5.19 (2009-01-05) X-Con-Id: 51246 X-Originating-IP: 88.217.8.67 Cc: FreeBSD-Current Subject: Re: laptop Acer Aspire One D250 / snd_hda(4) && internal mic not recording X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 14:25:47 -0000 El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: > > # mixer -f /dev/mixer1 > > Mixer rec is currently set to 100:100 > > Mixer monitor is currently set to 100:100 > > Recording source: monitor > > That's strange. I would expect it working. > > > Would you be so kind and give me the lines for reconfigure CODEC using > > hints? I'm really lost in this. > > OK, try this: > hint.hdac.0.cad0.nid18.config="as=2 seq=1" I've tried this and a lot of other hint.hdac.... for which I now have some kind of understanding... all with no luck; it is only recording noice (not silense, but noise). I think there is something wrong either with the hardware or something in the driver, because searching in Google for "acer aspire one mic" I found a lot of complaints about the internal mic not working, for example in Ubuntu it needs some special tweaking: http://ubuntuforums.org/showthread.php?t=952568 https://help.ubuntu.com/community/AspireOneAOD250 (the last one speaks about some alsa driver) What do you think about? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 17:02:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69DFE106564A for ; Sat, 6 Nov 2010 17:02:59 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 04D2E8FC0A for ; Sat, 6 Nov 2010 17:02:58 +0000 (UTC) Received: by bwz3 with SMTP id 3so3612223bwz.13 for ; Sat, 06 Nov 2010 10:02:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.103.11 with SMTP id i11mr2935755bko.186.1289061429009; Sat, 06 Nov 2010 09:37:09 -0700 (PDT) Received: by 10.204.52.141 with HTTP; Sat, 6 Nov 2010 09:37:08 -0700 (PDT) In-Reply-To: <8639rfyd8q.fsf@gmail.com> References: <8639rfyd8q.fsf@gmail.com> Date: Sat, 6 Nov 2010 09:37:08 -0700 Message-ID: From: Gordon Tetlow To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: man(1) no longer understands manpages like .so man3/printf.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 17:02:59 -0000 On Fri, Nov 5, 2010 at 8:57 AM, Anonymous wrote: > A few examples from ports tree > > =A0devel/automake111: automake-1.11(1) > =A0devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3) > =A0devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1) > =A0textproc/gnugrep: egrep(1), fgrep(1) > =A0www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3= ) > =A0x11/libX11: BlackPixel(3), XArc(3), etc > =A0x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc > =A0[+ more x11 libs] Thanks for the report. I'll look into adding the feature. Gordon From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 17:27:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86B7E106566B for ; Sat, 6 Nov 2010 17:27:32 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 2594F8FC14 for ; Sat, 6 Nov 2010 17:27:32 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 44F69E7217; Sat, 6 Nov 2010 17:27:31 +0000 (GMT) Received: from unknown (client-82-26-212-122.pete.adsl.virginmedia.com [82.26.212.122]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sat, 6 Nov 2010 17:27:30 +0000 (GMT) Date: Sat, 6 Nov 2010 17:27:25 +0000 From: Bruce Cran To: current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20101106172725.00004b20@unknown> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: siftr LOR: PFil hook read/write mutex vs. tcp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 17:27:32 -0000 1st 0xffffffff80990308 PFil read/write mutex (PFil hook read/write mutex @ /usr/src/head/sys/net/pfil.c:77 2nd 0xffffffff80991528 tcp (tcp) @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() _witness_debugger() witness_checkorder() _rw_rlock() siftr_chkpkt() pfil_run_hooks() ip_input() netisr_dispatch_src() ether_demux() ether_input() msk_handle_events() msk_intr() intr_event_execute_handlers() ithread_loop() fork_exit() fork_trampoline() --- trap 0, rip = 0, rsp = 0xffffff8123559cf0, rbp = 0 --- -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 18:02:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8B7106566B; Sat, 6 Nov 2010 18:02:48 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 562828FC12; Sat, 6 Nov 2010 18:02:46 +0000 (UTC) Received: by bwz3 with SMTP id 3so3642621bwz.13 for ; Sat, 06 Nov 2010 11:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WoqWhpn5gGZ2ehbVKJmUkbGcZvUSK9JgXcNiYs8aaq0=; b=Qo+QBXf8bV7AvR/yTmmwAvXsvJvp0VtSOySva1bqmCkiF/Ge6f0/I1xdOPlWnfYkwl vKjnHXPxcZuEEqD0g5r/67mhKHN5pFaBqr9yB3g5bOyt/K/VYK4ciWDm48G6GXRlvr/i d6s4ZVsmB9t6SUagoJSkDveZjkkueJXtQag+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Nj6yIbmKhM/C60hm8U2wELfU73wlCSS7LA1ky5RWLPw4yxnoUv3C7vBS+CNZJZCEcJ o+y9C1k5OY2cZwAkRfztRWw3ZtacRzCQOn0k5jeVOajt8kT+1MmcF0pmTPnOqqkq6B43 Gv2I0UQ2sHY7Bw9AXnik4EU7YNTyP0hhJMXVA= Received: by 10.204.15.146 with SMTP id k18mr3058609bka.98.1289065184238; Sat, 06 Nov 2010 10:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.23.6 with HTTP; Sat, 6 Nov 2010 10:39:24 -0700 (PDT) In-Reply-To: <4CCC8752.7030403@gmail.com> References: <4CCC31C1.5090602@icyb.net.ua> <4CCC8752.7030403@gmail.com> From: Jia-Shiun Li Date: Sun, 7 Nov 2010 01:39:24 +0800 Message-ID: To: alc@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Andriy Gapon , current@freebsd.org Subject: Re: panic: invalid PDPE on recend amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 18:02:48 -0000 Hi, I got a similar panic on amd64. Looking into the source it hit KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with a printf to see what triggered the assertion and here is the output. Combined with memcontrol output 'bogus' keyword it seems buggy BIOS violated some kind of spec and caused this. Is it fatal? It looks fine on my machine without the assertion. --->8------boot message ----->8-------- mem: base 0x00000000fffdc000 len 0x0000000000020000 base 0x00000000ffffc000 len 0x0000000000004000 base 0x0000000000000000 len 0x0000000080000000 base 0x0000000080000000 len 0x0000000040000000 base 0x00000000bff00000 len 0x0000000000100000 base 0x0000000100000000 len 0x0000000040000000 null: --->8------memcontrol output ----->8-------- root@jsli-nb:~ # memcontrol list 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x10000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x20000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x30000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x40000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x50000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x60000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x70000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x80000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x90000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xde000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xdf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xe0000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xea000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xeb000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xec000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xed000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xee000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xef000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xf0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfa000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfe000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xff000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfffdc000/0x20000 BIOS write-protect set-by-firmware active bogus 0xffffc000/0x4000 BIOS write-protect set-by-firmware active 0x0/0x80000000 BIOS write-back set-by-firmware active 0x80000000/0x40000000 BIOS write-back set-by-firmware active 0xbff00000/0x100000 BIOS uncacheable set-by-firmware active 0x100000000/0x40000000 BIOS write-back set-by-firmware active 0xc0000000/0x10000000 pciacce write-combine active root@jsli-nb:~ # btw, it is a --->8------boot message ----->8-------- CPU: Pentium(R) Dual-Core CPU T4200 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x400e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000b00000 - 0x00000000b66edfff, 3049185280 bytes (744430 pages) 0x00000000bfdbf000 - 0x00000000bfe82fff, 802816 bytes (196 pages) 0x00000000bfebf000 - 0x00000000bfee9fff, 176128 bytes (43 pages) 0x00000000bfeff000 - 0x00000000bfefffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x000000013ffaffff, 1073414144 bytes (262064 pages) avail memory = 4095213568 (3905 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000016000 x86bios: EBDA 0x09f000-0x09ffff at 0xffffff000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 ULE: setup cpu 0 Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 18:50:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E1D1065695 for ; Sat, 6 Nov 2010 18:50:15 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 50B8D8FC1A for ; Sat, 6 Nov 2010 18:50:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A7889E7217 for ; Sat, 6 Nov 2010 18:50:14 +0000 (GMT) Received: from unknown (client-82-26-212-122.pete.adsl.virginmedia.com [82.26.212.122]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sat, 6 Nov 2010 18:50:13 +0000 (GMT) Date: Sat, 6 Nov 2010 18:50:08 +0000 From: Bruce Cran To: current@freebsd.org Message-ID: <20101106185008.00001b4e@unknown> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Ctrl-alt-delete in syscons pause/scrollback mode breaks system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 18:50:15 -0000 Today I came back to my computer and realised I'd left ttyv0 in history/scrollback mode, with scroll-lock enabled. To see what would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to see that it seemed to get partway through the process but it never rebooted: the other ttys were killed and I could still break into the debugger but otherwise the system was unresponsive. Trying to repeat it after rebooting I ended up with a system that won't even break into the debugger. Is this expected? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 18:56:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4959310656C9 for ; Sat, 6 Nov 2010 18:56:21 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3D258FC1A for ; Sat, 6 Nov 2010 18:56:20 +0000 (UTC) Received: by mail-wy0-f182.google.com with SMTP id 34so2133805wyb.13 for ; Sat, 06 Nov 2010 11:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/NRhF2jLJucwdokT4nT4t5Z67bpeCEwXnLk/IWOEtQU=; b=SlcsBCjD5IvIdIBhBUXfRHvEnQX3wZ7N84Olbfe8wrfP9RQiOf/ap053ADYU7gWbRs 54kdvhiQIDvpr3URXpIxy8f8uvltMIxNrVGx7iMmMcbAIQxP0gBcRBMW6QgWyPgSBsLx gOr6+pebPjRwEwZ22P9Tu6zTM9vUOVlOJlyGw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lb7vMQBDsf3eUESxB0/2QZjPNY3xTlFBJUm/8HYN6ECdOHH7EET1XXRwEaODCv563f ovItXikxp88HINq3DJrHdXrrfKhMovVwXVxBBu1LNEGvKAx7hm/qHaTwYODlH3oXiNvO am0ynUOsG+2XxEtFCdGxPOE8mDGv18ioT52BY= MIME-Version: 1.0 Received: by 10.216.54.147 with SMTP id i19mr2586611wec.59.1289069780293; Sat, 06 Nov 2010 11:56:20 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Sat, 6 Nov 2010 11:56:20 -0700 (PDT) In-Reply-To: <20101106185008.00001b4e@unknown> References: <20101106185008.00001b4e@unknown> Date: Sat, 6 Nov 2010 18:56:20 +0000 Message-ID: From: Paul B Mahol To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Ctrl-alt-delete in syscons pause/scrollback mode breaks system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 18:56:21 -0000 On 11/6/10, Bruce Cran wrote: > Today I came back to my computer and realised I'd left ttyv0 in > history/scrollback mode, with scroll-lock enabled. To see what > would happen I pressed Ctrl-Alt-Delete to reboot and was surprised to > see that it seemed to get partway through the process but it never > rebooted: the other ttys were killed and I could still break into the > debugger but otherwise the system was unresponsive. Trying to repeat > it after rebooting I ended up with a system that won't even break into > the debugger. Is this expected? Last issue, was reported my me long ago and only workaround was commited, which actually did not solved problem for me. I'm still looking forward for complete syscons rewrite. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 18:58:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCB1C1065672; Sat, 6 Nov 2010 18:58:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 38E6D8FC12; Sat, 6 Nov 2010 18:58:25 +0000 (UTC) Received: by wwb28 with SMTP id 28so576525wwb.31 for ; Sat, 06 Nov 2010 11:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zU/360L9sr7D7BdDpCpPEC4AzerUV0F2sRKu6LZBEHM=; b=GsRCJMPRMwJ/b5hmbR7IFq26ZI5TuESh0wSFwNGLQKf+0GUhibwYOcYC8vjXK4BHY4 W9epo+NlioiFhwgZFb6zFOMYwAFKOc7L6jRWIYIfyKPaGPC1xVXtyk5M4FuF7kQiAQ2Z zMJg/IdCpiV1HGpgKPcDheGApk0rkrHQfbWCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pXf1Qdqx28vSggJyS9YFR936u3cESrh5uJ8FdSKcBQz58yrLU7As7UENQ/yhjeTTh6 n+OMAsqerB2zoN+/ASR/CgCFXj4S0vvblLE48zD3Fj8nDjPZPMB0Gz/YXkS15xk8Gf1o 6PBy2mXG1Ha84cMDOa+XcqgHNdjag91grm910= MIME-Version: 1.0 Received: by 10.216.71.66 with SMTP id q44mr3582081wed.44.1289069904891; Sat, 06 Nov 2010 11:58:24 -0700 (PDT) Received: by 10.216.50.140 with HTTP; Sat, 6 Nov 2010 11:58:24 -0700 (PDT) In-Reply-To: References: <4CCC31C1.5090602@icyb.net.ua> <4CCC8752.7030403@gmail.com> Date: Sat, 6 Nov 2010 18:58:24 +0000 Message-ID: From: Paul B Mahol To: Jia-Shiun Li Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, Andriy Gapon , current@freebsd.org Subject: Re: panic: invalid PDPE on recend amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 18:58:26 -0000 On 11/6/10, Jia-Shiun Li wrote: > Hi, > > I got a similar panic on amd64. Looking into the source it hit > KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with > a printf to see what triggered the assertion and here is the output. > Combined with memcontrol output 'bogus' keyword it seems buggy BIOS > violated some kind of spec and caused this. Is it fatal? It looks fine > on my machine without the assertion. Send uname output. The fix for this issue got commited few days ago. From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 19:47:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8610656A9 for ; Sat, 6 Nov 2010 19:47:48 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh8.mail.rice.edu (mh8.mail.rice.edu [128.42.201.24]) by mx1.freebsd.org (Postfix) with ESMTP id D33298FC29 for ; Sat, 6 Nov 2010 19:47:47 +0000 (UTC) Received: from mh8.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh8.mail.rice.edu (Postfix) with ESMTP id B203F28F85D; Sat, 6 Nov 2010 14:28:47 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh8.mail.rice.edu, auth channel Received: from mh8.mail.rice.edu ([127.0.0.1]) by mh8.mail.rice.edu (mh8.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id qSvZS3Nk8RXo; Sat, 6 Nov 2010 14:28:47 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh8.mail.rice.edu (Postfix) with ESMTPSA id 25C8828F836; Sat, 6 Nov 2010 14:28:46 -0500 (CDT) Message-ID: <4CD5AC6D.2020705@rice.edu> Date: Sat, 06 Nov 2010 14:28:45 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Paul B Mahol References: <4CCC31C1.5090602@icyb.net.ua> <4CCC8752.7030403@gmail.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070406060905040106080303" X-Mailman-Approved-At: Sat, 06 Nov 2010 20:04:19 +0000 Cc: alc@freebsd.org, Andriy Gapon , Jia-Shiun Li , current@freebsd.org Subject: Re: panic: invalid PDPE on recend amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 19:47:48 -0000 This is a multi-part message in MIME format. --------------070406060905040106080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul B Mahol wrote: > On 11/6/10, Jia-Shiun Li wrote: > >> Hi, >> >> I got a similar panic on amd64. Looking into the source it hit >> KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with >> a printf to see what triggered the assertion and here is the output. >> Combined with memcontrol output 'bogus' keyword it seems buggy BIOS >> violated some kind of spec and caused this. Is it fatal? It looks fine >> on my machine without the assertion. >> > > Send uname output. The fix for this issue got commited few days ago. > > This is a different type of BIOS misconfiguration than your machine had. I'm attaching a possible patch for this one. Regards, Alan --------------070406060905040106080303 Content-Type: text/plain; name="mtrr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mtrr.patch" Index: amd64/amd64/amd64_mem.c =================================================================== --- amd64/amd64/amd64_mem.c (revision 214679) +++ amd64/amd64/amd64_mem.c (working copy) @@ -583,7 +583,7 @@ amd64_mrset(struct mem_range_softc *sc, struct mem i = (sc->mr_cap & MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0; mrd = sc->mr_desc + i; for (; i < sc->mr_ndesc; i++, mrd++) { - if (mrd->mr_flags & MDF_ACTIVE) + if ((mrd->mr_flags & (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE) pmap_demote_DMAP(mrd->mr_base, mrd->mr_len, FALSE); } @@ -688,7 +688,7 @@ amd64_mrinit(struct mem_range_softc *sc) i = (sc->mr_cap & MR686_FIXMTRR) ? MTRR_N64K + MTRR_N16K + MTRR_N4K : 0; mrd = sc->mr_desc + i; for (; i < sc->mr_ndesc; i++, mrd++) { - if (mrd->mr_flags & MDF_ACTIVE) + if ((mrd->mr_flags & (MDF_ACTIVE | MDF_BOGUS)) == MDF_ACTIVE) pmap_demote_DMAP(mrd->mr_base, mrd->mr_len, TRUE); } } --------------070406060905040106080303-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 20:33:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC9EE10656C6; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 564398FC16; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so4326861iwn.13 for ; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=teNB6EWR4XSnmTt3IQoFlxO0MPxY61lmOqo/4Vkkkyk=; b=QTPkZSxRVgIYuRNmcl7zm56VSwA4YHsYGLkAP5Zzxm+YGUV/JVgdkFox80Bm/5yitN a/4cjz6vRUTotF5kTuXrvWzK/ySR0YG5SnMPyJyDechgFruwITZ+ZED5bzsBbxyxXURV +6vVA6Gc13Pz4XAt0FsIwC3g8eQapIR0rs84c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HWJfT8+AdVD0tLl39v1yLP18AHJVCW2vEYrNUvQ393LQs+u8rJ9kEdYvdAhcjs3ysK G5Xcw5iBokYD3B7250ZWO0AnkFD/YsjUSZDG590duV3E//kR03mesaVn3XAvnWmnklJN r0hx8VDZ4LW/wMs7x/8YC2UzUHGBvTFrKZOGA= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr502601icn.343.1289075597669; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 13:33:17 -0700 (PDT) In-Reply-To: <201011061522.26533.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> Date: Sat, 6 Nov 2010 13:33:17 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 20:33:18 -0000 On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrot= e: > Hi, > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> I think you're misunderstanding the existing taskqueue(9) implementation= . >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, >> nor can the set of running tasks. =A0So the order of checks is >> irrelevant. > > I agree that the order of checks is not important. That is not the proble= m. > > Cut & paste from suggested taskqueue patch from Fleming: > > =A0> +int >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> > +{ >> > + =A0 =A0 =A0 int rc; >> > + >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq= _queue, task, task, >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> > + =A0 =A0 =A0 } else { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > > What happens in this case if ta_pending > 0. Are you saying this is not > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? Ah! I see what you mean. I'm not quite sure what the best thing to do here is; I agree it would be nice if taskqueue_cancel(9) dequeued the task, but I believe it also needs to indicate that the task is currently running. I guess the best thing would be to return the old pending count by reference parameter, and 0 or EBUSY to also indicate if there is a task currently running. Adding jhb@ to this mail since he has good thoughts on interfacing. Thanks, matthew > >> > + =A0 =A0 =A0 } >> > + =A0 =A0 =A0 TQ_UNLOCK(queue); >> > + =A0 =A0 =A0 return (rc); >> > +} >> > >> >> As John said, the taskqueue(9) implementation cannot protect consumers >> of it from re-queueing a task; that kind of serialization needs to >> happen at a higher level. > > Agreed, but that is not what I'm pointing at. I'm pointing at what happen= s if > you re-queue a task and then cancel while it is actually running. Will th= e > task still be queued for execution after taskqueue_cancel()? > >> taskqueue(9) is not quite like callout(9); the taskqueue(9) >> implementation drops all locks before calling the task's callback >> function. =A0So once the task is running, taskqueue(9) can do nothing >> about it until the task stops running. > > This is not the problem. > >> >> This is why Jeff's >> implementation of taskqueue_cancel(9) slept if the task was running, >> and why mine returns an error code. =A0The only way to know for sure >> that a task is "about" to run is to ask taskqueue(9), because there's >> a window where the TQ_LOCK is dropped before the callback is entered. > > And if you re-queue and cancel in this window, shouldn't this also be han= dled > like in the other cases? > > Cut & paste from kern/subr_taskqueue.c: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > > If a concurrent thread at exactly this point in time calls taskqueue_enqu= eue() > on this task, then we re-add the task to the "queue->tq_queue". So far we > agree. Imagine now that for some reason a following call to taskqueue_can= cel() > on this task at same point in time. Now, shouldn't taskqueue_cancel() als= o > remove the task from the "queue->tq_queue" in this case aswell? Because i= n > your implementation you only remove the task if we are not running, and t= hat > is not true when we are at exactly this point in time. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_func(task->ta_context, pending); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_LOCK(queue); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup(task); > > > Another issue I noticed is that the ta_pending counter should have a wrap > protector. > > --HPS > From owner-freebsd-current@FreeBSD.ORG Sat Nov 6 23:05:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95175106564A for ; Sat, 6 Nov 2010 23:05:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4E83E8FC0C for ; Sat, 6 Nov 2010 23:05:51 +0000 (UTC) Received: by qyk4 with SMTP id 4so101341qyk.13 for ; Sat, 06 Nov 2010 16:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8yNaD3CVhd1OwSs4RdwHWWsUFsijHBprv5g2o2utCwE=; b=foUG1sBvoEyORV9pPF609u7g0/aphpOv3wEt13juZs6SuAMO040G1+5pvYgvWS0A/l cUB9KcXGxKZUSS3D+TchwarqsdyS3EQYhHKf0Vw+VX1nYtcNxSLYIx+AjjlSU7PS+8xr tbAiIf8uBb6qhd9BT0Nkc4rISlj/u/+6E6DSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hKHYatLnYS4N2SLZGKs8OkGrjcyQ3wlvN65lvC5AUbuqEzu5JlM1mHpRlWzD37L+5m I4IClf8wI3i160uHD1esmHo4X7wNlCUn2YC062x6frV7VhLXD4VX/bjXcwvtKGjdD1Vo sqIKURrVGfPKP3YjfYggzD92X/+WcL9Vw3sN0= MIME-Version: 1.0 Received: by 10.224.197.9 with SMTP id ei9mr2483882qab.317.1289082888926; Sat, 06 Nov 2010 15:34:48 -0700 (PDT) Received: by 10.229.69.135 with HTTP; Sat, 6 Nov 2010 15:34:48 -0700 (PDT) In-Reply-To: <20101106172725.00004b20@unknown> References: <20101106172725.00004b20@unknown> Date: Sun, 7 Nov 2010 01:34:48 +0300 Message-ID: From: Sergey Kandaurov To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: siftr LOR: PFil hook read/write mutex vs. tcp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 23:05:52 -0000 On 6 November 2010 20:27, Bruce Cran wrote: > 1st 0xffffffff80990308 PFil read/write mutex (PFil hook read/write > mutex @ /usr/src/head/sys/net/pfil.c:77 > 2nd 0xffffffff80991528 tcp (tcp) > @ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702 > KDB: stack backtrace: > db_trace_self_wrapper() > kdb_backtrace() > _witness_debugger() > witness_checkorder() > _rw_rlock() > siftr_chkpkt() > pfil_run_hooks() > ip_input() > netisr_dispatch_src() > ether_demux() > ether_input() > msk_handle_events() > msk_intr() > intr_event_execute_handlers() > ithread_loop() > fork_exit() > fork_trampoline() > --- trap 0, rip = 0, rsp = 0xffffff8123559cf0, rbp = 0 --- > AFAIK, this LOR is documented in siftr(4) as harmless. -- wbr, pluknet