From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 02:03:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8913963E; Sun, 6 Jan 2013 02:03:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by mx1.freebsd.org (Postfix) with ESMTP id D65E8E03; Sun, 6 Jan 2013 02:03:10 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t49so8964863wey.14 for ; Sat, 05 Jan 2013 18:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xC9bdqS1B/edfvfx0gF2OZDNWzLZhZJ4UvvnfBV0t1g=; b=qB3VmECGyPTuPZAvtWkEF7UtmZ7Qus9YCEUIDY2ecsb6xu/sb+1P+QsP71RfjgiizS 2+o4JiJ+CezAaSlej/S/mSQjytYUd3JvOk8gvfaPmVXjv6zxHWC42URlpMzhABL7a4vs RUyUji/O4I9lEFjThVDrCGDcPN6GdMkgTHDq0Ao6MlzsnMB+aI0jUftgS0YTFBZr8LS6 2EDQTpRNd0mtp/nC2Wh2AYwp2t5SimIN8LviuFEHqw2/S48fedfizOI3oWyLJKlqzL/1 RXkM2f1gpQlI1e84L7ftXqyhFa9oi8n3wuLU0b4T5OOfNEmhk9LkI2x7DFgdrHZV9Vj+ 7OMg== MIME-Version: 1.0 Received: by 10.194.93.40 with SMTP id cr8mr90440504wjb.16.1357437784136; Sat, 05 Jan 2013 18:03:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 5 Jan 2013 18:03:04 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Jan 2013 18:03:04 -0800 X-Google-Sender-Auth: GhmIR5NIG4HoT4nMbbaUVJYZKMQ Message-ID: Subject: Re: L1 cache thrashing affects performance of HIMENO benchmark From: Adrian Chadd To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Hakisho Nukama X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 02:03:12 -0000 On 5 January 2013 13:54, Jason Evans wrote: >> Jason - any comments? > > There are many variations on this class of performance problem, and the s= hort of it is that only the application can have adequate understanding of = data structure layout and access patterns to reliably make optimal use of t= he cache. However, it is possible for the allocator to lay out memory in a= more haphazard fashion than jemalloc, phkmalloc, etc. do, such that the ap= plication can be cache-oblivious and (usually) not suffer worst case conseq= uences as happened in this case. Extent-based allocators like dlmalloc oft= en get this "for free" for a significant range of allocation sizes. jemall= oc could be modified to this end, but a full solution would necessarily inc= rease internal fragmentation. It might be worth experimenting with nonethe= less. For at least this particular computational workload, the loss in throughput based on cache thrashing is significant enough to learn FreeBSD a negative mark in computational workloads. It'd be interesting to see which other workloads FreeBSD behaves poorly in. In fact, it'd be doubly interesting to get some people who _do_ computational workloads to do some profiling using oprofile/pmc and report back. Maybe if we wrote a wiki page on how to do this kind of profiling and how to interpret the results. In any case, yes - I think it's worth pursuing this further as it's very likely not the only workload that exhibits this kind of cache unhappiness. Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 18:02:21 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A7BD55F for ; Sun, 6 Jan 2013 18:02:21 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id 76E1710F6 for ; Sun, 6 Jan 2013 18:02:21 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d49so9218915eek.32 for ; Sun, 06 Jan 2013 10:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:subject:date:x-mailer; bh=5rTJx5msIEtcHgaxnTfQHyQMY9dyI6TQTmWXqenZQ+M=; b=pPadm8NTnpekd2VnGImJeJ8ESZEb4GzJZIINYvVpxI4v2lWhsiM1h3zaqDBbKQznBk DJwnuYgSSCdyXtcnth8u+oMI4XvPw8gBHHoDu7JQ9sbPRfmMkz1yg+zl0hhr4s5bBxLx ehkG4qNr/wv9p+fihkRCBkLch2Pk3ZSo2TvGrTCEEVvN3IjXSIKKSeyCmKu1Fc6cWaJa If8dx1rqRNuz2IEuw9IlNjr3VljTYP6VMQUQPR+E8ZnHJG6mB7yskEIlYon5n8tbU/kX oUPqMj/6gokacF75zVS5dywap5YRmdv2JrdhZbM+DhABe4y5JusGB5Rtd8/mbnE783gv ZugA== X-Received: by 10.14.218.69 with SMTP id j45mr160956710eep.35.1357495340249; Sun, 06 Jan 2013 10:02:20 -0800 (PST) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPS id 43sm125770757eed.10.2013.01.06.10.02.18 (version=SSLv3 cipher=OTHER); Sun, 06 Jan 2013 10:02:19 -0800 (PST) Message-ID: <20130106.180225.308.14@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: mctest fails to install Date: Sun, 06 Jan 2013 19:02:25 +0100 X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 18:02:21 -0000 http://forums.freebsd.org/showthread.php?t=36483 Domagoj From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 18:17:18 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E291BBCC for ; Sun, 6 Jan 2013 18:17:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id A298D11A5 for ; Sun, 6 Jan 2013 18:17:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:a185:d642:e8c7:c80]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D02274AC32 for ; Sun, 6 Jan 2013 22:17:10 +0400 (MSK) Date: Sun, 6 Jan 2013 22:17:09 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1582957716.20130106221709@serebryakov.spb.ru> To: hackers@freebsd.org Subject: Proper way to determine place of system sources in makefile? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 18:17:18 -0000 Hello, Hackers. I'm writing some code, which is built outside of system sources but depends on them. I'm using FreeBSD mk infrastructure. When code is kernel module (uses ) here is SYSDIR variable. But which is proper way to refer to system sources when makefile is prepared for shared library () or program ()? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 18:32:18 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 915FCFB6; Sun, 6 Jan 2013 18:32:18 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4701205; Sun, 6 Jan 2013 18:32:16 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r06IWFbq093520; Sun, 6 Jan 2013 11:32:15 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r06IWD6b092830; Sun, 6 Jan 2013 11:32:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Proper way to determine place of system sources in makefile? From: Ian Lepore To: lev@freebsd.org In-Reply-To: <1582957716.20130106221709@serebryakov.spb.ru> References: <1582957716.20130106221709@serebryakov.spb.ru> Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Jan 2013 11:32:12 -0700 Message-ID: <1357497132.1088.82.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 18:32:18 -0000 On Sun, 2013-01-06 at 22:17 +0400, Lev Serebryakov wrote: > Hello, Hackers. > > I'm writing some code, which is built outside of system sources but > depends on them. > > I'm using FreeBSD mk infrastructure. > > When code is kernel module (uses ) here is SYSDIR > variable. > > But which is proper way to refer to system sources when makefile is > prepared for shared library () or program ()? > That may depend on what you mean by "system sources." In particular, some header files which are generated during the build don't live under /usr/src/sys, they're in $OBJDIR/sys//. I was struggling with how to include such a file (in a non-hacky way) while building a bootloader from sys/boot/arm the other day, and I never did come up with a clean answer. (I do understand why -- the header files I wanted have content that changes based on KERNCONF=, and sys/boot is built during buildworld, not buildkernel.) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 20:05:41 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11CBB7A7 for ; Sun, 6 Jan 2013 20:05:41 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 86F1B1636 for ; Sun, 6 Jan 2013 20:05:39 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r06K5bMI061241; Mon, 7 Jan 2013 00:05:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r06K5bX5061240; Mon, 7 Jan 2013 00:05:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Jan 2013 00:05:37 +0400 From: Gleb Smirnoff To: Mike Hix Subject: Re: ixgbe ALTQ support on 9.1-RELEASE Message-ID: <20130106200537.GH51864@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 20:05:41 -0000 On Wed, Jan 02, 2013 at 05:26:35PM -0800, Mike Hix wrote: M> Should ixgbe 2.4.8 (supplied with 9.1-RELEASE) or newer support altq? M> M> altq(4) lists ixgbe under the SUPPORTED DEVICES section. M> M> I've successfully built a kernel with altq support and altq works with M> 1Gb nics and corresponding drivers on the same system. M> M> When attempting to load a pf rule set that includes queueing for my 10Gb M> NIC, it fails with the following message: M> M> pfctl: ix0: driver does not support altq M> M> Note that 'load a pf rule set' means 'pfctl -vf /etc/pf.conf'. When M> using the flags '-vnf' to check my rule set pfctl does not produce the M> above error, prints out the complete rule set, and exits with status M> 0. I'd expect it to check the driver for support when '-n' is supplied, M> but it doesn't appear that it does. M> M> My card: M> ix0@pci0:3:0:0: class=0x020000 card=0xa12c8086 chip=0x150b8086 M> rev=0x01 hdr=0x00 M> vendor = 'Intel Corporation' M> device = '82598EB 10-Gigabit AT2 Server Adapter' M> class = network M> subclass = ethernet M> M> If ixgbe does support altq, why does pfctl report otherwise? If not, why M> does the man page state otherwise? The same issue with igb is discussed in this thread: http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034072.html For ixgbe situation is absolutely the same. -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 6 21:51:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CF9BB950 for ; Sun, 6 Jan 2013 21:51:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by mx1.freebsd.org (Postfix) with ESMTP id 593E1198D for ; Sun, 6 Jan 2013 21:51:16 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fh20so13820090lab.34 for ; Sun, 06 Jan 2013 13:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=WbXNwTTtwVJ57iUGflQZ1DHt2MgonRIKbSM7Ur5zEhs=; b=eiCsoBme/69H6fRzxOxQ7fEfz7VeZKktu9f7VtTv1yFRGKuakbLMrjjJibBQHu6E7y TIytppZKSrMbUL4AtpW1pcW5SUmG7VMOc7YQ53gSLEKcwQ/TN3ZfSBaq/nDpO8KWjzNg 9tkDeMqU0DqD8tCA3ZotFUQ2LbPDC7EV1vb7Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=WbXNwTTtwVJ57iUGflQZ1DHt2MgonRIKbSM7Ur5zEhs=; b=m+oENuB+tm7nHDmT+e/uKHkQ/II6+yqCYCEafy5ZQE/wI66N7NYX+5xEtdmXjelir4 T16NOqErv9uvKUvvfHafn3t4q27F1BofGXJrZqMIc4PhaztZnFAJ/rioPUPgGkXgPxmh 8842Lm+Hu8B4xS5pHWZiMRZhReUybLTaebPKuw0lUbQPM581LSSHnmXLHvVUyaM8r6N3 XSL2d4M2JTMfa2Ke2eDuqg7R9QKtIUPg8yN38+kYlaToZ0wMPNXrzTe6QmZ0nMvuVNMK kSe2UEfSYsj9/OfQkxjHbZKfQfjxx9FHrFfOVDF3aHAiy6tqbR1QTzb//EINYUmuH24s 6ueg== Received: by 10.152.106.163 with SMTP id gv3mr55858604lab.55.1357509075896; Sun, 06 Jan 2013 13:51:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.75.200 with HTTP; Sun, 6 Jan 2013 13:50:45 -0800 (PST) In-Reply-To: <201301062004.50665.hselasky@c2i.net> References: <201301060952.08631.hselasky@c2i.net> <201301062004.50665.hselasky@c2i.net> From: Eitan Adler Date: Sun, 6 Jan 2013 16:50:45 -0500 Message-ID: Subject: Fwd: regression: if_rue device doesn't attach on HEAD To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnEyVoQVLlk/BG+wABr7TwcjSzTVY4o6F7gKxtQw9GYD7A58Q7Rf41I+ZqomRAKBKO5SuPu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 21:51:17 -0000 context: I have a USB nic which worked in 9.1 but regressed in HEAD and appears as an unrecognized device. - 9.1-RELEASE is known to be working (this is r243808 I think) - r245084 is broken - r244446 is broken - r244127 is broken - r243968 is broken I should have time to do more bisection next week. If someone has an idea of a specific commit which may have broken it please let me know. Use(full|less) debug info: I now see xhci_do_command: Command timeout! device init 2 failed USB_ERR_TIMEOUT Any suggestions or pointers are appreciated: ugen2.3: ... idVendor = 0x0bda idProduct = 0x8150 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <8628> ---------- Forwarded message ---------- From: Hans Petter Selasky Date: 6 January 2013 14:04 Subject: Re: regression: if_rue device doesn't attach on HEAD To: Eitan Adler Cc: freebsd-usb@freebsd.org On Sunday 06 January 2013 19:00:03 Eitan Adler wrote: > On 6 January 2013 03:52, Hans Petter Selasky wrote: > > Could you do a diff between 9.1 and 9-stable sources and see what is > > changed? Might be some BIOS/ACPI stuff too. > > I havn't had a chance to go much beyond this but > > - 9.1-RELEASE is known to be working (this is r243808, right?) > - r245084 is broken > - r244446 is broken > - r244127 is broken > - r243968 is broken Hi, >From what I can see from the SVN log, there has been no relevant changes in the USB core since r242xxx: http://svnweb.freebsd.org/base/stable/9/sys/dev/usb/ I suspect the problem is somewhere else, like PCI/BIOS/ACPI. --HPS -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 01:27:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 342E04AE for ; Tue, 8 Jan 2013 01:27:56 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id CC147119 for ; Tue, 8 Jan 2013 01:27:55 +0000 (UTC) Received: (qmail 59759 invoked by uid 89); 8 Jan 2013 01:27:52 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 01:27:52 -0000 Subject: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Jan 2013 17:27:50 -0800 Message-ID: <1357608470.6752.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 01:27:56 -0000 Hi folks, I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 and I want to check if the assumptions made by the original coder are correct. Essentially, the code queues a number of AIO requests (up to 100) and specifies an RT signal to be sent upon completion with siginfo_t. These are placed into an array. The code assumes that when handling one of these signals, if it has already received N such siginfo_t structures, it can BLOCK further instances of the signal while these structures are drained by the main code in Samba. However, my debugging suggests that if a bunch of signals have already been queued, you cannot block those undelivered but already queued signals. I am certain that they are all being delivered to the main thread and that they keep coming despite the code trying to stop them at 64 (they get all the way up to the 100 that were queued.) Can someone confirm whether I have this correct or not? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 02:46:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0F10D5E for ; Tue, 8 Jan 2013 02:46:06 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A2D306A1 for ; Tue, 8 Jan 2013 02:46:06 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r082k5jS057991 for ; Tue, 8 Jan 2013 02:46:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50EB888A.2030802@freebsd.org> Date: Tue, 08 Jan 2013 10:46:34 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> In-Reply-To: <1357608470.6752.22.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 02:46:06 -0000 On 2013/01/08 09:27, Richard Sharpe wrote: > Hi folks, > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > and I want to check if the assumptions made by the original coder are > correct. > > Essentially, the code queues a number of AIO requests (up to 100) and > specifies an RT signal to be sent upon completion with siginfo_t. > > These are placed into an array. > > The code assumes that when handling one of these signals, if it has > already received N such siginfo_t structures, it can BLOCK further > instances of the signal while these structures are drained by the main > code in Samba. > > However, my debugging suggests that if a bunch of signals have already > been queued, you cannot block those undelivered but already queued > signals. > > I am certain that they are all being delivered to the main thread and > that they keep coming despite the code trying to stop them at 64 (they > get all the way up to the 100 that were queued.) > > Can someone confirm whether I have this correct or not? > I am curious that how the code BLOCKs the signal in its signal handler ? AFAIK, after signal handler returned, original signal mask is restored, and re-enables the signal delivering, unless you change it in ucontext.uc_sigmask. Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 03:24:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E544412 for ; Tue, 8 Jan 2013 03:24:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CEEF981E for ; Tue, 8 Jan 2013 03:24:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id r083OOXq043661; Mon, 7 Jan 2013 22:24:24 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Mon, 07 Jan 2013 22:24:24 -0500 (EST) Date: Mon, 7 Jan 2013 22:24:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? In-Reply-To: <1357608470.6752.22.camel@localhost.localdomain> Message-ID: References: <1357608470.6752.22.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 03:24:32 -0000 On Mon, 7 Jan 2013, Richard Sharpe wrote: > Hi folks, > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > and I want to check if the assumptions made by the original coder are > correct. > > Essentially, the code queues a number of AIO requests (up to 100) and > specifies an RT signal to be sent upon completion with siginfo_t. > > These are placed into an array. > > The code assumes that when handling one of these signals, if it has > already received N such siginfo_t structures, it can BLOCK further > instances of the signal while these structures are drained by the main > code in Samba. > > However, my debugging suggests that if a bunch of signals have already > been queued, you cannot block those undelivered but already queued > signals. > > I am certain that they are all being delivered to the main thread and > that they keep coming despite the code trying to stop them at 64 (they > get all the way up to the 100 that were queued.) > > Can someone confirm whether I have this correct or not? If true, could they not use sigwaitinfo() from a separate thread instead and just bypass having to use a signal handler altogether? That thread can either call sigwaitinfo() when it is ready to receive more signals, or block on a semaphore/CV/whatever while events are being processed. -- DE From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 05:16:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86E9459E; Tue, 8 Jan 2013 05:16:30 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 35D1CAB4; Tue, 8 Jan 2013 05:16:29 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id k1so9970oag.2 for ; Mon, 07 Jan 2013 21:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qTstP9I/xsP9nCHU11tAQD7350t0w0megMw+4g6/nho=; b=pdRovyD/J918ekPrKme7Mr1eSEy0O7tN20td/zy3PQRhQHyZNTLLdYAruIQb0DeKkO d8xB9ZOf10pQS3v9VeN31MAlK+wW7UlhMY9jhXC8CrLfwzuJVmz4088JyRNLBVKqXzmf So+HIf6QD7m9xH/xEqZ0tT6ioqurKAnDam5jOUKKxa67NhV0NCZSjQDvXUszsIWwHBpp t7VhshOcI5+v4u0cZVq0x72LfwlckziJspnrXLUcVaQdBYWIjtIvW6SppEpZRb850odO 6PUhDAz7e6v09blorDKloo/Y5Hof7R4htAScBNyzTqqQaaHLhZKYSbNGJjAYSRRa+OO0 Qykw== Received: by 10.182.18.133 with SMTP id w5mr45726836obd.64.1357622189287; Mon, 07 Jan 2013 21:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.93.105 with HTTP; Mon, 7 Jan 2013 21:15:59 -0800 (PST) In-Reply-To: References: <20110129084125.GA54969@freebsd.org> From: Jia-Shiun Li Date: Tue, 8 Jan 2013 13:15:59 +0800 Message-ID: Subject: Re: cpufreq not working as module on i386/amd64 To: Alexander Best Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 05:16:30 -0000 Hi all, move to -hackers as it seems a better place to discuss. Turns out, at acpi_cpu_attach(), the bus probe will query ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq drivers. Since it is only executed once at booting, subsequent module loading after booting will not be called get_features() and will not be able to express interests in terms of ACPI_CAP_* flags. And if these flags were not set first, acpi_perf won't get attached. Later when loading cpufreq.ko, est_attach(), etc. will not be able to find acpi_perf and thus failed to attach. After referred to Intel doc. #302223 mentioned in dev/acpica/acpivar.h, I got confused by the meaning of these bits. According to the document, capability bits probably should be set as long as OSPM is *capable* of using them, no matter when they will be used. I am not familiar with ACPI, but I suppose it will expose states/methods to OSPM according to these bits? To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot. powerd also works fine with it. If this is true, then probably we don't need get_features() for acpi interface/drivers. It is sufficient to just turn on proper bits directly for acpi_cpu when related code is added to repository. Any comments? ----->8----->8----->8----- # svn diff Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (revision 245148) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@ -350,6 +350,7 @@ sc->cpu_features |= features; } free(drivers, M_TEMP); + sc->cpu_features |= ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; } /* ----->8----->8----->8----- Jia-Shiun On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li wrote: > I was cleaning up hard drive and found these old logs. Anyway I added > some printf() > and saw the process failed at device_find_child(..., "acpi_perf", ...) > of est_acpi_info() i.e. it cannot find acpi_perf device. > > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs > revealed the main difference: IST (i-state?) OEM tables in SSDT seems > not loaded if cpufreq was not compiled into kernel, as it shows below. > > Before I diving into the ACPI part, can anyone familiar with how ACPI > works shed me some light? > > ----->8----->8----->8----- > % diff -bu cpufreq-nb.log cpufreq-no.log > ... > @@ -158,17 +158,11 @@ > acpi0: Power Button (fixed) > cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 > cpu0: on acpi0 > -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) > -ACPI: Dynamic OEM Table Load: > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 > cpu1: on acpi0 > -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRef ApIst 00003000 INTL 20051117) > -ACPI: Dynamic OEM Table Load: > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20051117 > > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best wrote: >> On Sat Jan 29 11, Jia-Shiun Li wrote: >>> Hi all, >>> >>> I found that cpufreq driver failed to attach when compiled as module >>> and loaded, but it works fine when compiled into kernel. I am >>> wondering if this is due to some kind of limitation, or can be fixed? >> >> that's rather odd. for me neither the module nor the kernel code works, since >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile >> cpus seem to be supported. >> >> maybe you can add some printf's to est.c:est_get_info() to identify at which >> point error gets set. also you might want to make >> >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); >> >> non-conditional. maybe the output differy in kernel/module mode. >> >> cheers. >> alex >> >>> >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop >>> (amd64). Both got the same result. dmesg of T4200 attached. >>> >>> kldload module: >>> ----->8----->8----->8----- >>> est0: on cpu0 >>> est: CPU supports Enhanced Speedstep, but is not recognized. >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >>> device_attach: est0 attach returned 6 >>> est1: on cpu1 >>> est: CPU supports Enhanced Speedstep, but is not recognized. >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >>> -----8<-----8<-----8<----- >>> (repeated 6 times, kldload retries?) >>> >>> compiled into kernel: >>> ----->8----->8----->8----- >>> ... >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >>> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >>> isa_probe_children: probing PnP devices >>> coretemp0: on cpu0 >>> coretemp0: Setting TjMax=104 >>> p4tcc0: on cpu0 >>> est0: on cpu0 >>> coretemp1: on cpu1 >>> coretemp1: Setting TjMax=104 >>> p4tcc1: on cpu1 >>> est1: on cpu1 >>> Device configuration finished. >>> procfs registered >>> ... >>> -----8<-----8<-----8<----- >>> >>> Jia-Shiun. >> >> >> -- >> a13x From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 06:26:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A33E97F1 for ; Tue, 8 Jan 2013 06:26:57 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2E6D55 for ; Tue, 8 Jan 2013 06:26:56 +0000 (UTC) Received: (qmail 48241 invoked by uid 89); 8 Jan 2013 06:26:55 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 06:26:55 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Daniel Eischen In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Jan 2013 22:26:52 -0800 Message-ID: <1357626412.6752.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 06:26:57 -0000 On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote: > On Mon, 7 Jan 2013, Richard Sharpe wrote: > > > Hi folks, > > > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > and I want to check if the assumptions made by the original coder are > > correct. > > > > Essentially, the code queues a number of AIO requests (up to 100) and > > specifies an RT signal to be sent upon completion with siginfo_t. > > > > These are placed into an array. > > > > The code assumes that when handling one of these signals, if it has > > already received N such siginfo_t structures, it can BLOCK further > > instances of the signal while these structures are drained by the main > > code in Samba. > > > > However, my debugging suggests that if a bunch of signals have already > > been queued, you cannot block those undelivered but already queued > > signals. > > > > I am certain that they are all being delivered to the main thread and > > that they keep coming despite the code trying to stop them at 64 (they > > get all the way up to the 100 that were queued.) > > > > Can someone confirm whether I have this correct or not? > > If true, could they not use sigwaitinfo() from a separate > thread instead and just bypass having to use a signal > handler altogether? That thread can either call sigwaitinfo() > when it is ready to receive more signals, or block on a > semaphore/CV/whatever while events are being processed. So, I guess that what I want is something that will continue to work for both Linux and FreeBSD with minimal code divergence ... I guess I need to write a simpler program to check what the deal is. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 06:34:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9648894D for ; Tue, 8 Jan 2013 06:34:06 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA40D81 for ; Tue, 8 Jan 2013 06:34:06 +0000 (UTC) Received: (qmail 49904 invoked by uid 89); 8 Jan 2013 06:34:05 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 06:34:04 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: David Xu In-Reply-To: <50EB888A.2030802@freebsd.org> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Jan 2013 22:33:58 -0800 Message-ID: <1357626838.6752.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 06:34:06 -0000 On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > On 2013/01/08 09:27, Richard Sharpe wrote: > > Hi folks, > > > > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > and I want to check if the assumptions made by the original coder are > > correct. > > > > Essentially, the code queues a number of AIO requests (up to 100) and > > specifies an RT signal to be sent upon completion with siginfo_t. > > > > These are placed into an array. > > > > The code assumes that when handling one of these signals, if it has > > already received N such siginfo_t structures, it can BLOCK further > > instances of the signal while these structures are drained by the main > > code in Samba. > > > > However, my debugging suggests that if a bunch of signals have already > > been queued, you cannot block those undelivered but already queued > > signals. > > > > I am certain that they are all being delivered to the main thread and > > that they keep coming despite the code trying to stop them at 64 (they > > get all the way up to the 100 that were queued.) > > > > Can someone confirm whether I have this correct or not? > > > > I am curious that how the code BLOCKs the signal in its signal handler ? > AFAIK, after signal handler returned, original signal mask is restored, > and re-enables the signal delivering, unless you change it in > ucontext.uc_sigmask. It does try to block the signals in the signal handler using the following code (in the signal handler): if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { /* we've filled the info array - block this signal until these ones are delivered */ sigset_t set; sigemptyset(&set); sigaddset(&set, signum); sigprocmask(SIG_BLOCK, &set, NULL); However, I also added pthread_sigmask with the same parameters to see if that made any difference and it seemed not to. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 07:01:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 450CD158 for ; Tue, 8 Jan 2013 07:01:57 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1D979E60; Tue, 8 Jan 2013 07:01:57 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0871t23007396; Tue, 8 Jan 2013 07:01:56 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50EBC480.8000306@freebsd.org> Date: Tue, 08 Jan 2013 15:02:24 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> In-Reply-To: <1357626838.6752.27.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 07:01:57 -0000 On 2013/01/08 14:33, Richard Sharpe wrote: > On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: >> On 2013/01/08 09:27, Richard Sharpe wrote: >>> Hi folks, >>> >>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 >>> and I want to check if the assumptions made by the original coder are >>> correct. >>> >>> Essentially, the code queues a number of AIO requests (up to 100) and >>> specifies an RT signal to be sent upon completion with siginfo_t. >>> >>> These are placed into an array. >>> >>> The code assumes that when handling one of these signals, if it has >>> already received N such siginfo_t structures, it can BLOCK further >>> instances of the signal while these structures are drained by the main >>> code in Samba. >>> >>> However, my debugging suggests that if a bunch of signals have already >>> been queued, you cannot block those undelivered but already queued >>> signals. >>> >>> I am certain that they are all being delivered to the main thread and >>> that they keep coming despite the code trying to stop them at 64 (they >>> get all the way up to the 100 that were queued.) >>> >>> Can someone confirm whether I have this correct or not? >>> >> >> I am curious that how the code BLOCKs the signal in its signal handler ? >> AFAIK, after signal handler returned, original signal mask is restored, >> and re-enables the signal delivering, unless you change it in >> ucontext.uc_sigmask. > > It does try to block the signals in the signal handler using the > following code (in the signal handler): > > if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { > /* we've filled the info array - block this signal until > these ones are delivered */ > sigset_t set; > sigemptyset(&set); > sigaddset(&set, signum); > sigprocmask(SIG_BLOCK, &set, NULL); > > However, I also added pthread_sigmask with the same parameters to see if > that made any difference and it seemed not to. > This code won't work, as I said, after the signal handler returned, kernel will copy the signal mask contained in ucontext into kernel space, and use it in feature signal delivering. The code should be modified as following: void handler(int signum, siginfo_t *info, ucontext_t *uap) { ... if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { sigaddset(&uap->uc_sigmask, signum); ... here, sigprocmask call should be removed. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 07:12:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD7F9462 for ; Tue, 8 Jan 2013 07:12:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A16F5EB3; Tue, 8 Jan 2013 07:12:23 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r087CMbT009188; Tue, 8 Jan 2013 07:12:23 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50EBC6F3.8060302@freebsd.org> Date: Tue, 08 Jan 2013 15:12:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> In-Reply-To: <50EBC480.8000306@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 07:12:23 -0000 On 2013/01/08 15:02, David Xu wrote: > On 2013/01/08 14:33, Richard Sharpe wrote: >> On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: >>> On 2013/01/08 09:27, Richard Sharpe wrote: >>>> Hi folks, >>>> >>>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 >>>> and I want to check if the assumptions made by the original coder are >>>> correct. >>>> >>>> Essentially, the code queues a number of AIO requests (up to 100) and >>>> specifies an RT signal to be sent upon completion with siginfo_t. >>>> >>>> These are placed into an array. >>>> >>>> The code assumes that when handling one of these signals, if it has >>>> already received N such siginfo_t structures, it can BLOCK further >>>> instances of the signal while these structures are drained by the main >>>> code in Samba. >>>> >>>> However, my debugging suggests that if a bunch of signals have already >>>> been queued, you cannot block those undelivered but already queued >>>> signals. >>>> >>>> I am certain that they are all being delivered to the main thread and >>>> that they keep coming despite the code trying to stop them at 64 (they >>>> get all the way up to the 100 that were queued.) >>>> >>>> Can someone confirm whether I have this correct or not? >>>> >>> >>> I am curious that how the code BLOCKs the signal in its signal handler ? >>> AFAIK, after signal handler returned, original signal mask is restored, >>> and re-enables the signal delivering, unless you change it in >>> ucontext.uc_sigmask. >> >> It does try to block the signals in the signal handler using the >> following code (in the signal handler): >> >> if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { >> /* we've filled the info array - block this signal until >> these ones are delivered */ >> sigset_t set; >> sigemptyset(&set); >> sigaddset(&set, signum); >> sigprocmask(SIG_BLOCK, &set, NULL); >> >> However, I also added pthread_sigmask with the same parameters to see if >> that made any difference and it seemed not to. >> > > This code won't work, as I said, after the signal handler returned, > kernel will copy the signal mask contained in ucontext into kernel > space, and use it in feature signal delivering. > > The code should be modified as following: > > void handler(int signum, siginfo_t *info, ucontext_t *uap) > { > ... > > if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > sigaddset(&uap->uc_sigmask, signum); > > ... > here, sigprocmask call should be removed. > > > > > Not that this code may only work in single thread mode, if there are multiple threads in the process, kernel is free to deliver the signal to any thread which is not masking it. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 12:35:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82AE4F4E for ; Tue, 8 Jan 2013 12:35:52 +0000 (UTC) (envelope-from andyzammy@googlemail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id 2B86AE42 for ; Tue, 8 Jan 2013 12:35:51 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so296772vbb.24 for ; Tue, 08 Jan 2013 04:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XujsrZQXgDPBp0xOw9ET4sJukpvYhih5jLhBr4gzk2Q=; b=iexYe2qakgC3Hx1pvCVzg3mgqyDeQKj/0/rFJ8lqsXHtZaEN0D+HeLRRJcY+nFD3fm 285m6FLjnU5kRsPvXJ/QgW0bh6lLuHKx9okUbS+Gz6CtRBvmF/kOiiqRFARz7bDqyQaH sK/mhdhMsBn52yowylxBApaZOn2Xy3k6XsoSVBVZIDuWD1SjLV+Ufg/oVRrgzeTd7vYq 7ZauW00/YdS1YJwWd4vHQkcxaim/oOiEhygejdi4LFwZ01PK/m+s1HJu6RY8/vwAPClF MlLko+MXlumJNiYHo0k7oqc7T+IlBdRb8I1Wa5U10CseAG/Ex/SKeO13vqaHI32KUGIp xSmQ== MIME-Version: 1.0 Received: by 10.52.23.37 with SMTP id j5mr75275305vdf.56.1357648551102; Tue, 08 Jan 2013 04:35:51 -0800 (PST) Received: by 10.221.4.200 with HTTP; Tue, 8 Jan 2013 04:35:50 -0800 (PST) Date: Tue, 8 Jan 2013 12:35:50 +0000 Message-ID: Subject: Getting the most out of nvi From: Andy Zammy To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:35:52 -0000 Hi, I'm interested in using nvi as my IDE for developing. I made a thread on the forum a while ago ( for those that are interested - http://forums.freebsd.org/showthread.php?t=34914 ), and concluded I would get a better response here. Since creating that thread I have gained a working understanding of how to use ctags and cscope, but I still don't think I have the most efficient interface possible. I'm very interested to hear how the developers here use nvi to code. One thing I'm really struggling with is full cscope integration with nvi and it's tags system. Basically, using :cs find will immediately open up the first result it finds, and I can't figure out how to bring up a list of all results in order to select the one you want to open up. Can anybody tell me how to achieve this? Alternatively, I could launch cscope from a shell within nvi (:!cscope blah blah), but this would open up a new session and start a new tag stack, so its not a very fluid way to navigate through source code. Any general tips on coding with nvi are welcome, even if they don't help my above situation. Kind Regards :) From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 15:02:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3041F2B2; Tue, 8 Jan 2013 15:02:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9B48076B; Tue, 8 Jan 2013 15:02:03 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r08F1tvV097278; Tue, 8 Jan 2013 17:01:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r08F1tvV097278 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r08F1tS0097277; Tue, 8 Jan 2013 17:01:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Jan 2013 17:01:55 +0200 From: Konstantin Belousov To: Jia-Shiun Li Subject: Re: cpufreq not working as module on i386/amd64 Message-ID: <20130108150155.GF82219@kib.kiev.ua> References: <20110129084125.GA54969@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k6SrlR5F+BMzH45x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:02:04 -0000 --k6SrlR5F+BMzH45x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 08, 2013 at 01:15:59PM +0800, Jia-Shiun Li wrote: > Hi all, >=20 > move to -hackers as it seems a better place to discuss. >=20 > Turns out, at acpi_cpu_attach(), the bus probe will query > ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq > drivers. Since it is only executed once at booting, subsequent module > loading after booting will not be called get_features() and will not > be able to express interests in terms of ACPI_CAP_* flags. And if > these flags were not set first, acpi_perf won't get attached. Later > when loading cpufreq.ko, est_attach(), etc. will not be able to find > acpi_perf and thus failed to attach. >=20 > After referred to Intel doc. #302223 mentioned in > dev/acpica/acpivar.h, I got confused by the meaning of these bits. > According to the document, capability bits probably should be set as > long as OSPM is *capable* of using them, no matter when they will be > used. I am not familiar with ACPI, but I suppose it will expose > states/methods to OSPM according to these bits? >=20 > To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS | > ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling > ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot. > powerd also works fine with it. >=20 > If this is true, then probably we don't need get_features() for acpi > interface/drivers. It is sufficient to just turn on proper bits > directly for acpi_cpu when related code is added to repository. >=20 > Any comments? >=20 > ----->8----->8----->8----- > # svn diff > Index: sys/dev/acpica/acpi_cpu.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/acpica/acpi_cpu.c (revision 245148) > +++ sys/dev/acpica/acpi_cpu.c (working copy) > @@ -350,6 +350,7 @@ > sc->cpu_features |=3D features; > } > free(drivers, M_TEMP); > + sc->cpu_features |=3D ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; > } I had almost word-to-word identical conversation with Andrey Gapon, might be a year ago. I Cc:ed him. >=20 > /* >=20 > ----->8----->8----->8----- >=20 >=20 > Jia-Shiun >=20 > On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li wrote: > > I was cleaning up hard drive and found these old logs. Anyway I added > > some printf() > > and saw the process failed at device_find_child(..., "acpi_perf", ...) > > of est_acpi_info() i.e. it cannot find acpi_perf device. > > > > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs > > revealed the main difference: IST (i-state?) OEM tables in SSDT seems > > not loaded if cpufreq was not compiled into kernel, as it shows below. > > > > Before I diving into the ACPI part, can anyone familiar with how ACPI > > works shed me some light? > > > > ----->8----->8----->8----- > > % diff -bu cpufreq-nb.log cpufreq-no.log > > ... > > @@ -158,17 +158,11 @@ > > acpi0: Power Button (fixed) > > cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 > > cpu0: on acpi0 > > -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 00003000 INTL 2005111= 7) > > -ACPI: Dynamic OEM Table Load: > > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) > > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 2005111= 7) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 > > cpu1: on acpi0 > > -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRef ApIst 00003000 INTL 2005111= 7) > > -ACPI: Dynamic OEM Table Load: > > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) > > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 2005111= 7) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20051117 > > > > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best w= rote: > >> On Sat Jan 29 11, Jia-Shiun Li wrote: > >>> Hi all, > >>> > >>> I found that cpufreq driver failed to attach when compiled as module > >>> and loaded, but it works fine when compiled into kernel. I am > >>> wondering if this is due to some kind of limitation, or can be fixed? > >> > >> that's rather odd. for me neither the module nor the kernel code works= , since > >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium= mobile > >> cpus seem to be supported. > >> > >> maybe you can add some printf's to est.c:est_get_info() to identify at= which > >> point error gets set. also you might want to make > >> > >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); > >> > >> non-conditional. maybe the output differy in kernel/module mode. > >> > >> cheers. > >> alex > >> > >>> > >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop > >>> (amd64). Both got the same result. dmesg of T4200 attached. > >>> > >>> kldload module: > >>> ----->8----->8----->8----- > >>> est0: on cpu0 > >>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > >>> device_attach: est0 attach returned 6 > >>> est1: on cpu1 > >>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > >>> -----8<-----8<-----8<----- > >>> (repeated 6 times, kldload retries?) > >>> > >>> compiled into kernel: > >>> ----->8----->8----->8----- > >>> ... > >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > >>> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > >>> isa_probe_children: probing PnP devices > >>> coretemp0: on cpu0 > >>> coretemp0: Setting TjMax=3D104 > >>> p4tcc0: on cpu0 > >>> est0: on cpu0 > >>> coretemp1: on cpu1 > >>> coretemp1: Setting TjMax=3D104 > >>> p4tcc1: on cpu1 > >>> est1: on cpu1 > >>> Device configuration finished. > >>> procfs registered > >>> ... > >>> -----8<-----8<-----8<----- > >>> > >>> Jia-Shiun. > >> > >> > >> -- > >> a13x > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --k6SrlR5F+BMzH45x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7DTiAAoJEJDCuSvBvK1B56EP/jSAbgGzLSd9tub1WE/Tsg/t 73D0wtgHH2UXeerxtdpQQiFR2Z9v6PWzYsQjSZsjXKNpXfCESkdqar48e+Nvi9Tt b8ApP6jMaW8pEnm6TJa23IPSYr2zvTK/1+8KJIuGk20ifn94wLrZBYPif/YtXRAw DiOHinU8umZgpV3KBPVG4eDVEOR0cx25Z1jPVIxuVDVwzm5gYjkhxw+JlH0nMoAb 42pdKJpv0IVEhqD95MyVKVPCwDQEFYnOMDzItcHblAA4LEO6MYWVr8JB0kSQPyje PD8hwEZmNAkak+W40KVT1N4jCOvtn7jYfU5BqNnDfwzAduGFdlZhsJ1k2VFIRH2t hqxiVdemsshrJ9rcvQMKpvRDWY9mwOyHSPoIoqUEjOexGZwz+qrocQhdwIXXCOAh HQ3LAhK2XogsQtXJDB0Y4hrcbjz5uxUS2Mxrb028sN6DZONIQakqF1YSE2Cu5Nkj 9OyHcABQPLcL6uo6X0urBDSb8b79rvLmEy0Eh1JDtDmZGH5xyA+W7gy2FYfGqDpB t85wKnSdhtB2yH6A657slbO2K1cW0SO0w5pz7ccmcqC4QANFhJGFYmCzGr1i/SbA zqCCj+bMMvXrOXT8zYu4RV4lHOU5MLhd7C29uqV7BiUDRnFmOlpwloagEBx85wiQ cyKf2LmRunwgHyyhjw0v =XhFv -----END PGP SIGNATURE----- --k6SrlR5F+BMzH45x-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 15:36:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DAE4FE0; Tue, 8 Jan 2013 15:36:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 0B34691B; Tue, 8 Jan 2013 15:36:20 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so447887wgb.32 for ; Tue, 08 Jan 2013 07:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gqw0wQPDG25BJu20R+zHVjftfEUjp012YazSg+GYnC4=; b=gd4jw7GnJV32XqI2SubaOqPaIq+K9029bw8UMUXksKR4GdsNfVYRoIIWzPRkpL5sBZ 10Z9OP89XVpJfGzFoBmhaaMGINfolo5ZfBnmzXkOQxLxfGzMMrl2mNtwf2ESTXIFn7wk rNOf+BmXAspjrcd/8c3c9qM71XJORQuXumhcvqE8HIQ6TcIeiVFO3Vf2FN40AYtvcSst 2PLhdxaATa0m1T0SovLorVj19IvSuTitKiNiTpq3r1eGnNQaRL8H43f8Q1Jfvlq83wtm y/oGTB/zmM+bExLLmB+vYieXt5zflnOxjEHbbHiqFiy7Rpg31pP+0qn4STfUV1lgvH6J kXhA== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr102364088wjc.1.1357659373410; Tue, 08 Jan 2013 07:36:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 8 Jan 2013 07:36:13 -0800 (PST) In-Reply-To: <1357626412.6752.24.camel@localhost.localdomain> References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> Date: Tue, 8 Jan 2013 07:36:13 -0800 X-Google-Sender-Auth: rD8mBdZ6JeH24qlUt_Brx15mWmo Message-ID: Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Adrian Chadd To: Richard Sharpe Content-Type: text/plain; charset=ISO-8859-1 Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:36:21 -0000 .. or you could abstract it out a bit and use freebsd's aio_waitcomplete() or kqueue aio notification. It'll then behave much saner. adrian On 7 January 2013 22:26, Richard Sharpe wrote: > On Mon, 2013-01-07 at 22:24 -0500, Daniel Eischen wrote: >> On Mon, 7 Jan 2013, Richard Sharpe wrote: >> >> > Hi folks, >> > >> > I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 >> > and I want to check if the assumptions made by the original coder are >> > correct. >> > >> > Essentially, the code queues a number of AIO requests (up to 100) and >> > specifies an RT signal to be sent upon completion with siginfo_t. >> > >> > These are placed into an array. >> > >> > The code assumes that when handling one of these signals, if it has >> > already received N such siginfo_t structures, it can BLOCK further >> > instances of the signal while these structures are drained by the main >> > code in Samba. >> > >> > However, my debugging suggests that if a bunch of signals have already >> > been queued, you cannot block those undelivered but already queued >> > signals. >> > >> > I am certain that they are all being delivered to the main thread and >> > that they keep coming despite the code trying to stop them at 64 (they >> > get all the way up to the 100 that were queued.) >> > >> > Can someone confirm whether I have this correct or not? >> >> If true, could they not use sigwaitinfo() from a separate >> thread instead and just bypass having to use a signal >> handler altogether? That thread can either call sigwaitinfo() >> when it is ready to receive more signals, or block on a >> semaphore/CV/whatever while events are being processed. > > So, I guess that what I want is something that will continue to work for > both Linux and FreeBSD with minimal code divergence ... > > I guess I need to write a simpler program to check what the deal is. > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 16:14:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A64B91B for ; Tue, 8 Jan 2013 16:14:20 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id A989AA74 for ; Tue, 8 Jan 2013 16:14:19 +0000 (UTC) Received: (qmail 24105 invoked by uid 89); 8 Jan 2013 16:14:11 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 16:14:10 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: David Xu In-Reply-To: <50EBC480.8000306@freebsd.org> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Jan 2013 08:14:06 -0800 Message-ID: <1357661646.6752.30.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:14:20 -0000 On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: > On 2013/01/08 14:33, Richard Sharpe wrote: > > On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > >> On 2013/01/08 09:27, Richard Sharpe wrote: > >>> Hi folks, > >>> > >>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > >>> and I want to check if the assumptions made by the original coder are > >>> correct. > >>> > >>> Essentially, the code queues a number of AIO requests (up to 100) and > >>> specifies an RT signal to be sent upon completion with siginfo_t. > >>> > >>> These are placed into an array. > >>> > >>> The code assumes that when handling one of these signals, if it has > >>> already received N such siginfo_t structures, it can BLOCK further > >>> instances of the signal while these structures are drained by the main > >>> code in Samba. > >>> > >>> However, my debugging suggests that if a bunch of signals have already > >>> been queued, you cannot block those undelivered but already queued > >>> signals. > >>> > >>> I am certain that they are all being delivered to the main thread and > >>> that they keep coming despite the code trying to stop them at 64 (they > >>> get all the way up to the 100 that were queued.) > >>> > >>> Can someone confirm whether I have this correct or not? > >>> > >> > >> I am curious that how the code BLOCKs the signal in its signal handler ? > >> AFAIK, after signal handler returned, original signal mask is restored, > >> and re-enables the signal delivering, unless you change it in > >> ucontext.uc_sigmask. > > > > It does try to block the signals in the signal handler using the > > following code (in the signal handler): > > > > if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > /* we've filled the info array - block this signal until > > these ones are delivered */ > > sigset_t set; > > sigemptyset(&set); > > sigaddset(&set, signum); > > sigprocmask(SIG_BLOCK, &set, NULL); > > > > However, I also added pthread_sigmask with the same parameters to see if > > that made any difference and it seemed not to. > > > > This code won't work, as I said, after the signal handler returned, > kernel will copy the signal mask contained in ucontext into kernel > space, and use it in feature signal delivering. > > The code should be modified as following: > > void handler(int signum, siginfo_t *info, ucontext_t *uap) > { > ... > > if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > sigaddset(&uap->uc_sigmask, signum); Hmmm, this seems unlikely because the signal handler is operating in user mode and has no access to kernel-mode variables. I guess I will just have to read the code. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 16:15:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6DACCA20 for ; Tue, 8 Jan 2013 16:15:59 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 0DED9A90 for ; Tue, 8 Jan 2013 16:15:58 +0000 (UTC) Received: (qmail 25422 invoked by uid 89); 8 Jan 2013 16:15:57 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 16:15:57 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Adrian Chadd In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Jan 2013 08:15:55 -0800 Message-ID: <1357661755.6752.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:15:59 -0000 On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: > .. or you could abstract it out a bit and use freebsd's > aio_waitcomplete() or kqueue aio notification. > > It'll then behave much saner. Yes, going forward that is what I want to do ... this would work nicely with a kqueue back-end for Samba's tevent subsystem, and if someone has not already written such a back end, I will have to do so, I guess. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 17:20:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C89695B7; Tue, 8 Jan 2013 17:20:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8B6E3A; Tue, 8 Jan 2013 17:20:17 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id z2so551951wey.18 for ; Tue, 08 Jan 2013 09:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/1bWi3vYP966ZEhx767muvYjKZamGHAxq1VH5PN8aC0=; b=U4jHeamj3w2H4eNJ2/+ssyyYQwu4diG8Gte9YrOvjTZHOyedDB8fcBNrXi+XGRSBO1 Q6brS4atWizjFrSSAvBeq0wiseHHJ1OB6+U5AQSNxCv8sZgENlmdlEDExt+y3TLjxxfq TZpw+7BSUWPz+jfqvt461BY3kL0lS2IV8lUC6CCy8YeptSxWeycGP6Kvy0PqxT+OFLRH wDlKDWVZJnHg8ZNxwJqVWyEbCNEhIVSDY30XXIHDZN1Bqlv0HeRipt0g0a85je50YVLO 2Yr4GqNOcxDgP3L/DLeUb0NGz+BooZhfZLl9/lAMCdx9Ti8iQITF7lI3hiqiwGhmkiVt XjfA== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr15392679wjd.59.1357665611115; Tue, 08 Jan 2013 09:20:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 8 Jan 2013 09:20:10 -0800 (PST) In-Reply-To: <1357661755.6752.32.camel@localhost.localdomain> References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> Date: Tue, 8 Jan 2013 09:20:10 -0800 X-Google-Sender-Auth: inrMF937oLjCKLQj7pWrzmYUmlA Message-ID: Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Adrian Chadd To: Richard Sharpe Content-Type: text/plain; charset=ISO-8859-1 Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:20:18 -0000 On 8 January 2013 08:15, Richard Sharpe wrote: > On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: >> .. or you could abstract it out a bit and use freebsd's >> aio_waitcomplete() or kqueue aio notification. >> >> It'll then behave much saner. > > Yes, going forward that is what I want to do ... this would work nicely > with a kqueue back-end for Samba's tevent subsystem, and if someone has > not already written such a back end, I will have to do so, I guess. Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! (Then, convert parts of samba over to use grand central dispatch... :-) Seriously though - I was doing network/disk IO using real time signals what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + waitcomplete is just brilliant. kqueue for signal delivery is also just brilliant. Just saying. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 17:23:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C60E952; Tue, 8 Jan 2013 17:23:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 92D1AE75; Tue, 8 Jan 2013 17:23:27 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so552715wgb.32 for ; Tue, 08 Jan 2013 09:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LOMGAqo8dwoiOZ6BsuZAYuC6LDIV5s5saff17MQrYvI=; b=mgarmcPlPXEbFupK8n+tKDU2OYpbD9XOlI55YdkeJUsOwHp8zbg98Rg8hNYefVMoel zm6hEt2LYcwPYO9OwfxtRenFA3I9n0OTk9tONtqYrOQwhKygIireH4IyBBz2BguwmGPB sEJmU3dN+X9mFwd/NNcyir9A0229mA356DwJcOju0qyjY7vNnOgtLRyaeDLHf6MZM9YA oF7DXYOv1ey+Le5oqa/VmcqrKXtTiOWhQod4W+Qst48+U+cy4YMs/4H1WaruRs3R1UJQ om6WmXEsSlQ28pJxyzWj/LNA8jX+0qZkGCLwMed52U/hKSH9wf+iP8PPLe3MKnzjvcC/ 6NSw== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr15409873wjd.59.1357665806648; Tue, 08 Jan 2013 09:23:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 8 Jan 2013 09:23:26 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Jan 2013 09:23:26 -0800 X-Google-Sender-Auth: DJLf1YWEyqnguVaJh_tJ5cI9ADU Message-ID: Subject: Re: L1 cache thrashing affects performance of HIMENO benchmark From: Adrian Chadd To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Hakisho Nukama X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:23:28 -0000 ... can someone please file a FreeBSD PR with some example workloads and the dfbsd list summary? I'd like to make sure we don't lose this particular thread. It may be worth "teaching" jemalloc to offset the allocation sizes so they don't hit this degenerate cache case, then do a bunch of testing to ensure nothing has regressed. Thanks, adrian On 5 January 2013 18:03, Adrian Chadd wrote: > On 5 January 2013 13:54, Jason Evans wrote: > >>> Jason - any comments? >> >> There are many variations on this class of performance problem, and the = short of it is that only the application can have adequate understanding of= data structure layout and access patterns to reliably make optimal use of = the cache. However, it is possible for the allocator to lay out memory in = a more haphazard fashion than jemalloc, phkmalloc, etc. do, such that the a= pplication can be cache-oblivious and (usually) not suffer worst case conse= quences as happened in this case. Extent-based allocators like dlmalloc of= ten get this "for free" for a significant range of allocation sizes. jemal= loc could be modified to this end, but a full solution would necessarily in= crease internal fragmentation. It might be worth experimenting with noneth= eless. > > For at least this particular computational workload, the loss in > throughput based on cache thrashing is significant enough to learn > FreeBSD a negative mark in computational workloads. > > It'd be interesting to see which other workloads FreeBSD behaves poorly i= n. > > In fact, it'd be doubly interesting to get some people who _do_ > computational workloads to do some profiling using oprofile/pmc and > report back. Maybe if we wrote a wiki page on how to do this kind of > profiling and how to interpret the results. > > In any case, yes - I think it's worth pursuing this further as it's > very likely not the only workload that exhibits this kind of cache > unhappiness. > > > > Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 17:40:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0423FF7; Tue, 8 Jan 2013 17:40:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx1.freebsd.org (Postfix) with ESMTP id 719AFF48; Tue, 8 Jan 2013 17:40:39 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so464992pad.11 for ; Tue, 08 Jan 2013 09:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=y76NVTNcc/wLitdxv4VqVCYzOe7Lj4neLxea6C/dRQU=; b=zeUCTrJboM2bnrfyik/WW6g2LzRU2K4KmwKMDQcOBE+P663FgyGJct8CwYCHgx0m8G oEZoiNsqCjtTTgoS2lcLAWnKaC8YT/t8+QPEqoQym0vTZBSCZbOExeloPMtX+DcmFZEL oRJNhQIUbTdeBn2FYn+ek41gBkZolW6khQLUQQ7XNLW8K3JlPLjVvWgSr0kpdOVzq2t8 TlqXGYO4pCy2g+Rz4V6E/c+htJoVIk9JcarbCYM+9rB7m71bXa1Gi+HXsr1RrYvLZmHw 77haElMBpJpafa0Wv52TBBmxS11lcmwEg1lE452U07TY+R4+ERksQFIOa/xwysjlGX0y pJow== X-Received: by 10.66.78.168 with SMTP id c8mr181789691pax.16.1357666838722; Tue, 08 Jan 2013 09:40:38 -0800 (PST) Received: from [10.16.29.78] (mobile-166-147-093-027.mycingular.net. [166.147.93.27]) by mx.google.com with ESMTPS id wh8sm39965408pbc.75.2013.01.08.09.40.36 (version=SSLv3 cipher=OTHER); Tue, 08 Jan 2013 09:40:37 -0800 (PST) References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <115B6A99-AC44-4F0A-B978-13D18A15B9CF@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? Date: Tue, 8 Jan 2013 09:40:31 -0800 To: Adrian Chadd Cc: Daniel Eischen , "freebsd-hackers@freebsd.org" , Richard Sharpe X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:40:39 -0000 On Jan 8, 2013, at 9:20 AM, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe wrote:= >> On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: >>> .. or you could abstract it out a bit and use freebsd's >>> aio_waitcomplete() or kqueue aio notification. >>>=20 >>> It'll then behave much saner. >>=20 >> Yes, going forward that is what I want to do ... this would work nicely >> with a kqueue back-end for Samba's tevent subsystem, and if someone has >> not already written such a back end, I will have to do so, I guess. >=20 > Embrace FreeBSD's nice asynchronous APIs for doing things! You know you wa= nt to! >=20 > (Then, convert parts of samba over to use grand central dispatch... :-) >=20 > Seriously though - I was doing network/disk IO using real time signals > what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + > waitcomplete is just brilliant. kqueue for signal delivery is also > just brilliant. Just saying. Or just use libevent to abstract away kqueues/inotify/etc? Samba isn't just f= or freebsd... Thanks, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 18:30:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4579CCD; Tue, 8 Jan 2013 18:30:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by mx1.freebsd.org (Postfix) with ESMTP id AD59D267; Tue, 8 Jan 2013 18:30:52 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id r3so630416wey.17 for ; Tue, 08 Jan 2013 10:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fOXYEqScaa9D8pJL9qC7eFGMcqFYV+s47+sLxjOCdic=; b=BFMVJ53ARPoUNZv0V6qRUfdGgPXjny1NChinBjyjuRWiRne3EOO3eEzOCzIXyjJnyQ is0/SbbjZTsFKR9DenbAF0K0Q43edR613AI7YZhQmu0JY3DQ1XKjiv6qTeL8pk5y4TCI L5gx9gEjn8UjmVh4n+GK85iAImafPHY07mk547dUh+ZU+GBh3m0fKdaqp2VDIa8ikw+s XSqwbYklnBJhLDtkUWYQH/AcM1llFyt9Dxs8x7c4+1v3L9+tx8Pu0zYW79QZU2pQ8Xjb WcWwM69zb/8Z+G3wa8uQJkTRaVMlxYt5amI/zTdhOz4k+PNQEplfxElO0ZVbH8v5vMK1 I0qw== MIME-Version: 1.0 X-Received: by 10.180.93.133 with SMTP id cu5mr16236322wib.32.1357669846467; Tue, 08 Jan 2013 10:30:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 8 Jan 2013 10:30:46 -0800 (PST) In-Reply-To: <115B6A99-AC44-4F0A-B978-13D18A15B9CF@gmail.com> References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> <115B6A99-AC44-4F0A-B978-13D18A15B9CF@gmail.com> Date: Tue, 8 Jan 2013 10:30:46 -0800 X-Google-Sender-Auth: o3xgXKRLRsSJwmNQxYWt0srimR0 Message-ID: Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Daniel Eischen , "freebsd-hackers@freebsd.org" , Richard Sharpe X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:30:53 -0000 libevent doesn't do disk IO. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 23:15:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F8B1B83 for ; Tue, 8 Jan 2013 23:15:04 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3BA1F5 for ; Tue, 8 Jan 2013 23:15:03 +0000 (UTC) Received: (qmail 51379 invoked by uid 89); 8 Jan 2013 23:15:02 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 8 Jan 2013 23:15:01 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: David Xu In-Reply-To: <1357661646.6752.30.camel@localhost.localdomain> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Jan 2013 15:14:54 -0800 Message-ID: <1357686894.6752.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 23:15:04 -0000 On Tue, 2013-01-08 at 08:14 -0800, Richard Sharpe wrote: > On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: > > On 2013/01/08 14:33, Richard Sharpe wrote: > > > On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: > > >> On 2013/01/08 09:27, Richard Sharpe wrote: > > >>> Hi folks, > > >>> > > >>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 > > >>> and I want to check if the assumptions made by the original coder are > > >>> correct. > > >>> > > >>> Essentially, the code queues a number of AIO requests (up to 100) and > > >>> specifies an RT signal to be sent upon completion with siginfo_t. > > >>> > > >>> These are placed into an array. > > >>> > > >>> The code assumes that when handling one of these signals, if it has > > >>> already received N such siginfo_t structures, it can BLOCK further > > >>> instances of the signal while these structures are drained by the main > > >>> code in Samba. > > >>> > > >>> However, my debugging suggests that if a bunch of signals have already > > >>> been queued, you cannot block those undelivered but already queued > > >>> signals. > > >>> > > >>> I am certain that they are all being delivered to the main thread and > > >>> that they keep coming despite the code trying to stop them at 64 (they > > >>> get all the way up to the 100 that were queued.) > > >>> > > >>> Can someone confirm whether I have this correct or not? > > >>> > > >> > > >> I am curious that how the code BLOCKs the signal in its signal handler ? > > >> AFAIK, after signal handler returned, original signal mask is restored, > > >> and re-enables the signal delivering, unless you change it in > > >> ucontext.uc_sigmask. > > > > > > It does try to block the signals in the signal handler using the > > > following code (in the signal handler): > > > > > > if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > > /* we've filled the info array - block this signal until > > > these ones are delivered */ > > > sigset_t set; > > > sigemptyset(&set); > > > sigaddset(&set, signum); > > > sigprocmask(SIG_BLOCK, &set, NULL); > > > > > > However, I also added pthread_sigmask with the same parameters to see if > > > that made any difference and it seemed not to. > > > > > > > This code won't work, as I said, after the signal handler returned, > > kernel will copy the signal mask contained in ucontext into kernel > > space, and use it in feature signal delivering. > > > > The code should be modified as following: > > > > void handler(int signum, siginfo_t *info, ucontext_t *uap) > > { > > ... > > > > if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > > sigaddset(&uap->uc_sigmask, signum); > > Hmmm, this seems unlikely because the signal handler is operating in > user mode and has no access to kernel-mode variables. Well, it turns out that your suggestion was correct. I did some more searching and found another similar suggestion, so I gave it a whirl, and it works. Now, my problem is that Jeremy Allison thinks that it is a fugly hack. This means that I will probably have big problems getting a patch for this into Samba. I guess a couple of questions I have now are: 1. Is this the same for all versions of FreeBSD since Posix RT Signals were introduced? 2. Which (interpretation of which) combination of standards require such an approach? From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 02:06:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52C3DCD1 for ; Wed, 9 Jan 2013 02:06:31 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 26AB8A64; Wed, 9 Jan 2013 02:06:31 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0926T8R020735; Wed, 9 Jan 2013 02:06:30 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50ECD0C2.7090801@freebsd.org> Date: Wed, 09 Jan 2013 10:06:58 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> In-Reply-To: <1357686894.6752.37.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 02:06:31 -0000 On 2013/01/09 07:14, Richard Sharpe wrote: > On Tue, 2013-01-08 at 08:14 -0800, Richard Sharpe wrote: >> On Tue, 2013-01-08 at 15:02 +0800, David Xu wrote: >>> On 2013/01/08 14:33, Richard Sharpe wrote: >>>> On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote: >>>>> On 2013/01/08 09:27, Richard Sharpe wrote: >>>>>> Hi folks, >>>>>> >>>>>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0 >>>>>> and I want to check if the assumptions made by the original coder are >>>>>> correct. >>>>>> >>>>>> Essentially, the code queues a number of AIO requests (up to 100) and >>>>>> specifies an RT signal to be sent upon completion with siginfo_t. >>>>>> >>>>>> These are placed into an array. >>>>>> >>>>>> The code assumes that when handling one of these signals, if it has >>>>>> already received N such siginfo_t structures, it can BLOCK further >>>>>> instances of the signal while these structures are drained by the main >>>>>> code in Samba. >>>>>> >>>>>> However, my debugging suggests that if a bunch of signals have already >>>>>> been queued, you cannot block those undelivered but already queued >>>>>> signals. >>>>>> >>>>>> I am certain that they are all being delivered to the main thread and >>>>>> that they keep coming despite the code trying to stop them at 64 (they >>>>>> get all the way up to the 100 that were queued.) >>>>>> >>>>>> Can someone confirm whether I have this correct or not? >>>>>> >>>>> >>>>> I am curious that how the code BLOCKs the signal in its signal handler ? >>>>> AFAIK, after signal handler returned, original signal mask is restored, >>>>> and re-enables the signal delivering, unless you change it in >>>>> ucontext.uc_sigmask. >>>> >>>> It does try to block the signals in the signal handler using the >>>> following code (in the signal handler): >>>> >>>> if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) { >>>> /* we've filled the info array - block this signal until >>>> these ones are delivered */ >>>> sigset_t set; >>>> sigemptyset(&set); >>>> sigaddset(&set, signum); >>>> sigprocmask(SIG_BLOCK, &set, NULL); >>>> >>>> However, I also added pthread_sigmask with the same parameters to see if >>>> that made any difference and it seemed not to. >>>> >>> >>> This code won't work, as I said, after the signal handler returned, >>> kernel will copy the signal mask contained in ucontext into kernel >>> space, and use it in feature signal delivering. >>> >>> The code should be modified as following: >>> >>> void handler(int signum, siginfo_t *info, ucontext_t *uap) >>> { >>> ... >>> >>> if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { >>> sigaddset(&uap->uc_sigmask, signum); >> >> Hmmm, this seems unlikely because the signal handler is operating in >> user mode and has no access to kernel-mode variables. > > Well, it turns out that your suggestion was correct. > > I did some more searching and found another similar suggestion, so I > gave it a whirl, and it works. > > Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > This means that I will probably have big problems getting a patch for > this into Samba. > > I guess a couple of questions I have now are: > > 1. Is this the same for all versions of FreeBSD since Posix RT Signals > were introduced? > I have checked source code, and found from FreeBSD 7.0, RT signal is supported, and aio code uses signal queue. > 2. Which (interpretation of which) combination of standards require such > an approach? > > The way I introduced is standard: http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html I quoted some text here: When a signal is caught by a signal-catching function installed by sigaction(), a new signal mask is calculated and installed for the duration of the signal-catching function (or until a call to either sigprocmask() or sigsuspend() is made). This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] and then including the signal being delivered. If and when the user's signal handler returns normally, the original signal mask is restored. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... When the signal handler returns, the receiving thread resumes execution at the point it was interrupted unless the signal handler makes other arrangements. If longjmp() or _longjmp() is used to leave the signal handler, then the signal mask must be explicitly restored. This volume of IEEE Std 1003.1-2001 defines the third argument of a signal handling function when SA_SIGINFO is set as a void * instead of a ucontext_t *, but without requiring type checking. New applications should explicitly cast the third argument of the signal handling ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ function to ucontext_t *. ^^^^^^^^^^^^^^^^^^^^^^^^^ --- The above means third parameter is pointing to ucontext_t which is used to restored the previously interrupted context, the context contains a signal mask which is also restored. http://pubs.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 03:14:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 315C4AFB; Wed, 9 Jan 2013 03:14:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E2555DB2; Wed, 9 Jan 2013 03:14:53 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id r093EqVN008066; Tue, 8 Jan 2013 22:14:52 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Tue, 08 Jan 2013 22:14:52 -0500 (EST) Date: Tue, 8 Jan 2013 22:14:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? In-Reply-To: <1357686894.6752.37.camel@localhost.localdomain> Message-ID: References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 03:14:54 -0000 On Tue, 8 Jan 2013, Richard Sharpe wrote: > [ ... ] > > Well, it turns out that your suggestion was correct. > > I did some more searching and found another similar suggestion, so I > gave it a whirl, and it works. > > Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > This means that I will probably have big problems getting a patch for > this into Samba. I don't understand why JA thinks this is a hack. Their current method doesn't work, or at least isn't portable. I've tried this on Solaris 10, and it works just as it does in FreeBSD. Test program included after signature. $ ./test_sigprocmask Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 0 Handled signal 16, blocked: false Sending signal 16 Got signal 16, blocked: true Blocking signal 16 using method 1 Handled signal 16, blocked: true -- DE #include #include #include #include #include #define SIGNAL_TO_USE SIGUSR1 static int got_signal = 0; static int method = 0; static char * signal_blocked_str(sigset_t *set) { if (sigismember(set, SIGNAL_TO_USE)) return ("true"); else return ("false"); } static void sighandler(int sig, int code, ucontext_t *ucp) { sigset_t set; sigprocmask(SIG_SETMASK, NULL, &set); printf("Got signal %d, blocked: %s\n", SIGNAL_TO_USE, signal_blocked_str(&set)); printf("Blocking signal %d using method %d\n", SIGNAL_TO_USE, method); if (method == 0) { sigaddset(&set, SIGNAL_TO_USE); sigprocmask(SIG_SETMASK, &set, NULL); } else sigaddset(&ucp->uc_sigmask, SIGNAL_TO_USE); got_signal = 1; } int main(int argc, char **argv) { sigset_t mask; struct sigaction act; /* Install the handler. */ sigemptyset(&act.sa_mask); sigaddset(&act.sa_mask, SIGNAL_TO_USE); act.sa_handler = sighandler; act.sa_flags = SA_SIGINFO; assert(sigaction(SIGNAL_TO_USE, &act, NULL) == 0); /* Unblock the signal. */ sigemptyset(&mask); sigaddset(&mask, SIGNAL_TO_USE); sigprocmask(SIG_UNBLOCK, &mask, NULL); printf("Sending signal %d\n", SIGNAL_TO_USE); kill(getpid(), SIGNAL_TO_USE); while (got_signal == 0) { sleep(1); } sigprocmask(SIG_SETMASK, NULL, &mask); printf("Handled signal %d, blocked: %s\n\n", SIGNAL_TO_USE, signal_blocked_str(&mask)); method = 1; printf("Sending signal %d\n", SIGNAL_TO_USE); kill(getpid(), SIGNAL_TO_USE); while (got_signal == 0) { sleep(1); } sigprocmask(SIG_SETMASK, NULL, &mask); printf("Handled signal %d, blocked: %s\n", SIGNAL_TO_USE, signal_blocked_str(&mask)); return (0); } From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 03:22:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66C31D2D; Wed, 9 Jan 2013 03:22:26 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA60DF9; Wed, 9 Jan 2013 03:22:26 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r093MO34035454; Wed, 9 Jan 2013 03:22:25 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50ECE28D.4080308@freebsd.org> Date: Wed, 09 Jan 2013 11:22:53 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Richard Sharpe X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 03:22:26 -0000 On 2013/01/09 11:14, Daniel Eischen wrote: > On Tue, 8 Jan 2013, Richard Sharpe wrote: > >> [ ... ] >> >> Well, it turns out that your suggestion was correct. >> >> I did some more searching and found another similar suggestion, so I >> gave it a whirl, and it works. >> >> Now, my problem is that Jeremy Allison thinks that it is a fugly hack. >> This means that I will probably have big problems getting a patch for >> this into Samba. > > I don't understand why JA thinks this is a hack. Their current > method doesn't work, or at least isn't portable. I've tried this > on Solaris 10, and it works just as it does in FreeBSD. Test > program included after signature. > > $ ./test_sigprocmask > Sending signal 16 > Got signal 16, blocked: true > Blocking signal 16 using method 0 > Handled signal 16, blocked: false > > Sending signal 16 > Got signal 16, blocked: true > Blocking signal 16 using method 1 > Handled signal 16, blocked: true > Yeah, people think that signal handler is normal code, this is a misunderstanding, in fact, it really works like an interrupt service routine. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 03:24:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3CBD0E24; Wed, 9 Jan 2013 03:24:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 03D52E0E; Wed, 9 Jan 2013 03:24:16 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id r093OFhG013579; Tue, 8 Jan 2013 22:24:15 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Tue, 08 Jan 2013 22:24:15 -0500 (EST) Date: Tue, 8 Jan 2013 22:24:15 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? In-Reply-To: Message-ID: References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 03:24:17 -0000 On Tue, 8 Jan 2013, Daniel Eischen wrote: > On Tue, 8 Jan 2013, Richard Sharpe wrote: > >> [ ... ] >> >> Well, it turns out that your suggestion was correct. >> >> I did some more searching and found another similar suggestion, so I >> gave it a whirl, and it works. >> >> Now, my problem is that Jeremy Allison thinks that it is a fugly hack. >> This means that I will probably have big problems getting a patch for >> this into Samba. > > I don't understand why JA thinks this is a hack. Their current > method doesn't work, or at least isn't portable. I've tried this > on Solaris 10, and it works just as it does in FreeBSD. Test > program included after signature. > > $ ./test_sigprocmask > Sending signal 16 > Got signal 16, blocked: true > Blocking signal 16 using method 0 > Handled signal 16, blocked: false > > Sending signal 16 > Got signal 16, blocked: true > Blocking signal 16 using method 1 > Handled signal 16, blocked: true Weird - I just tested it on Linux (2.6.18-238.el5) and it works the same as FreeBSD and Solaris. Am I misunderstanding something? Is it possible that Samba's code is broken on all platforms? -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 05:25:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF56C4BC for ; Wed, 9 Jan 2013 05:25:19 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id A119B1C8 for ; Wed, 9 Jan 2013 05:25:19 +0000 (UTC) Received: (qmail 62817 invoked by uid 89); 9 Jan 2013 05:25:15 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 9 Jan 2013 05:25:15 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Daniel Eischen In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Jan 2013 21:25:13 -0800 Message-ID: <1357709113.8329.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 05:25:20 -0000 On Tue, 2013-01-08 at 22:24 -0500, Daniel Eischen wrote: > On Tue, 8 Jan 2013, Daniel Eischen wrote: > > > On Tue, 8 Jan 2013, Richard Sharpe wrote: > > > >> [ ... ] > >> > >> Well, it turns out that your suggestion was correct. > >> > >> I did some more searching and found another similar suggestion, so I > >> gave it a whirl, and it works. > >> > >> Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > >> This means that I will probably have big problems getting a patch for > >> this into Samba. > > > > I don't understand why JA thinks this is a hack. Their current > > method doesn't work, or at least isn't portable. I've tried this > > on Solaris 10, and it works just as it does in FreeBSD. Test > > program included after signature. > > > > $ ./test_sigprocmask > > Sending signal 16 > > Got signal 16, blocked: true > > Blocking signal 16 using method 0 > > Handled signal 16, blocked: false > > > > Sending signal 16 > > Got signal 16, blocked: true > > Blocking signal 16 using method 1 > > Handled signal 16, blocked: true > > Weird - I just tested it on Linux (2.6.18-238.el5) and it works > the same as FreeBSD and Solaris. Am I misunderstanding something? > Is it possible that Samba's code is broken on all platforms? It is possible :-) AIO is off by default in configure. Then, when you switch it on in configure you have to switch it on in the smb.conf. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 15:21:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA62D92F for ; Wed, 9 Jan 2013 15:21:14 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 78EDE7E5 for ; Wed, 9 Jan 2013 15:21:13 +0000 (UTC) Received: (qmail 41294 invoked by uid 89); 9 Jan 2013 15:21:12 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 9 Jan 2013 15:21:12 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: Adrian Chadd In-Reply-To: References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jan 2013 07:21:10 -0800 Message-ID: <1357744870.8329.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:21:14 -0000 On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: > On 8 January 2013 08:15, Richard Sharpe wrote: > > On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: > >> .. or you could abstract it out a bit and use freebsd's > >> aio_waitcomplete() or kqueue aio notification. > >> > >> It'll then behave much saner. > > > > Yes, going forward that is what I want to do ... this would work nicely > > with a kqueue back-end for Samba's tevent subsystem, and if someone has > > not already written such a back end, I will have to do so, I guess. > > Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! > > (Then, convert parts of samba over to use grand central dispatch... :-) > > Seriously though - I was doing network/disk IO using real time signals > what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + > waitcomplete is just brilliant. kqueue for signal delivery is also > just brilliant. Just saying. The problem with a fully event-driven approach is that it will not work, it seems to me. Eventually, you find something that is not async and then you have to go threaded. (Because handling multiple clients in one process is very useful and you do not want client-A's long-running op preventing client-B's short-running op from being serviced.) Then, you run into problems like Posix's insistence that all threads in a process must use the same credentials (ie, uid and gids must be the same across all threads), although there is a hack on Linux to work around this behind glibc's back. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 9 18:20:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 094B3487; Wed, 9 Jan 2013 18:20:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id AFF1D314; Wed, 9 Jan 2013 18:20:16 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r09IK9hq002711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 10:20:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50EDB4D3.2060000@freebsd.org> Date: Wed, 09 Jan 2013 10:20:03 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? References: <1357608470.6752.22.camel@localhost.localdomain> <1357626412.6752.24.camel@localhost.localdomain> <1357661755.6752.32.camel@localhost.localdomain> <1357744870.8329.7.camel@localhost.localdomain> In-Reply-To: <1357744870.8329.7.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 18:20:17 -0000 On 1/9/13 7:21 AM, Richard Sharpe wrote: > On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: >> On 8 January 2013 08:15, Richard Sharpe wrote: >>> On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: >>>> .. or you could abstract it out a bit and use freebsd's >>>> aio_waitcomplete() or kqueue aio notification. >>>> >>>> It'll then behave much saner. >>> Yes, going forward that is what I want to do ... this would work nicely >>> with a kqueue back-end for Samba's tevent subsystem, and if someone has >>> not already written such a back end, I will have to do so, I guess. >> Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! >> >> (Then, convert parts of samba over to use grand central dispatch... :-) >> >> Seriously though - I was doing network/disk IO using real time signals >> what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + >> waitcomplete is just brilliant. kqueue for signal delivery is also >> just brilliant. Just saying. > The problem with a fully event-driven approach is that it will not work, > it seems to me. Eventually, you find something that is not async and > then you have to go threaded. (Because handling multiple clients in one > process is very useful and you do not want client-A's long-running op > preventing client-B's short-running op from being serviced.) > > Then, you run into problems like Posix's insistence that all threads in > a process must use the same credentials (ie, uid and gids must be the > same across all threads), although there is a hack on Linux to work > around this behind glibc's back. The best implementation of an async framework I've seen is the one that Alan Cox and friends wrote in the code they sold to IronPort/Cisco. It'd be nice if we could get that extracted out and donated/included into something generally available.. even had a #ifdef Linux code path.. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 04:28:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 10734ED for ; Thu, 10 Jan 2013 04:28:28 +0000 (UTC) (envelope-from rsharpe@richardsharpe.com) Received: from zmail.servaris.com (zmail.servaris.com [107.6.51.160]) by mx1.freebsd.org (Postfix) with ESMTP id 934481D0 for ; Thu, 10 Jan 2013 04:28:27 +0000 (UTC) Received: (qmail 77670 invoked by uid 89); 10 Jan 2013 04:28:20 -0000 Received: from unknown (HELO ?192.168.2.23?) (rsharpe@richardsharpe.com@108.225.16.199) by mail.richardsharpe.com with ESMTPA; 10 Jan 2013 04:28:20 -0000 Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? From: Richard Sharpe To: David Xu In-Reply-To: <50ECD0C2.7090801@freebsd.org> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain> <50EBC480.8000306@freebsd.org> <1357661646.6752.30.camel@localhost.localdomain> <1357686894.6752.37.camel@localhost.localdomain> <50ECD0C2.7090801@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jan 2013 20:28:17 -0800 Message-ID: <1357792097.8329.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 04:28:28 -0000 On Wed, 2013-01-09 at 10:06 +0800, David Xu wrote: > [...] > >>> This code won't work, as I said, after the signal handler returned, > >>> kernel will copy the signal mask contained in ucontext into kernel > >>> space, and use it in feature signal delivering. > >>> > >>> The code should be modified as following: > >>> > >>> void handler(int signum, siginfo_t *info, ucontext_t *uap) > >>> { > >>> ... > >>> > >>> if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) { > >>> sigaddset(&uap->uc_sigmask, signum); > >> > >> Hmmm, this seems unlikely because the signal handler is operating in > >> user mode and has no access to kernel-mode variables. > > > > Well, it turns out that your suggestion was correct. > > > > I did some more searching and found another similar suggestion, so I > > gave it a whirl, and it works. > > > > Now, my problem is that Jeremy Allison thinks that it is a fugly hack. > > This means that I will probably have big problems getting a patch for > > this into Samba. > > > > I guess a couple of questions I have now are: > > > > 1. Is this the same for all versions of FreeBSD since Posix RT Signals > > were introduced? > > > > I have checked source code, and found from FreeBSD 7.0, RT signal is > supported, and aio code uses signal queue. > > > 2. Which (interpretation of which) combination of standards require such > > an approach? > > > > > The way I introduced is standard: > http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html > > I quoted some text here: > > When a signal is caught by a signal-catching function installed by > sigaction(), a new signal mask is calculated and installed for the > duration of the signal-catching function (or until a call to either > sigprocmask() or sigsuspend() is made). This mask is formed by taking > the union of the current signal mask and the value of the sa_mask for > the signal being delivered [XSI] [Option Start] unless SA_NODEFER or > SA_RESETHAND is set, [Option End] and then including the signal being > delivered. If and when the user's signal handler returns normally, the > original signal mask is restored. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... > > When the signal handler returns, the receiving thread resumes execution > at the point it was interrupted unless the signal handler makes other > arrangements. If longjmp() or _longjmp() is used to leave the signal > handler, then the signal mask must be explicitly restored. > > This volume of IEEE Std 1003.1-2001 defines the third argument of a > signal handling function when SA_SIGINFO is set as a void * instead of a > ucontext_t *, but without requiring type checking. New applications > should explicitly cast the third argument of the signal handling > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > function to ucontext_t *. > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > --- > > The above means third parameter is pointing to ucontext_t which is used > to restored the previously interrupted context, the context contains > a signal mask which is also restored. > http://pubs.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html OK, thank you for that. Jeremy agrees that this is a portable approach, at least across Linux, FreeBSD and Solaris. We will try to get a fix into Samba to do it the correct way. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 06:41:10 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 569A9B87; Thu, 10 Jan 2013 06:41:10 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7C4685; Thu, 10 Jan 2013 06:41:09 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 97C691A3D01; Wed, 9 Jan 2013 22:41:08 -0800 (PST) Message-ID: <50EE6281.7030602@mu.org> Date: Thu, 10 Jan 2013 01:41:05 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jason Evans Subject: Re: malloc+utrace, tracking memory leaks in a running program. References: <50D52B10.1060205@mu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Daniel Eischen , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 06:41:10 -0000 On 12/23/12 12:28 PM, Jason Evans wrote: > On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote: >> So the other day in an effort to debug a memory leak I decided to take a look at malloc+utrace(2) and decided to make a tool to debug where leaks are coming from. >> >> A few hours later I have: >> 1) a new version of utrace(2) (utrace2(2)) that uses structured data to prevent overloading of data. (utrace2.diff) >> 2) changes to ktrace and kdump to decode the new format. (also in utrace2.diff) >> 3) changes to jemalloc to include the new format AND the function caller so it's easy to get the source of the leaks. (also in utrace2.diff) >> 4) a program that can take a pipe of kdump(1) and figure out what memory has leaked. (alloctrace.py) >> 5) simple test program (test_utrace.c) >> >> […] > Have you looked at the heap profiling functionality built into jemalloc? It's not currently enabled on FreeBSD, but as far as I know, the only issue keeping it from being useful is the absence of a Linux-compatible /proc//maps (and the gperftools folks may already have a solution for that; I haven't looked). I think it makes more sense to get that sorted out than to develop a separate trace-based leak checker. The problem with tracing is that it doesn't scale beyond some relatively small number of allocator events. I have looked at some of this functionality (heap profiling) but alas it is not implemented yet. In addition the dtrace work appears to be quite away from a workable solution with too many performance penalties until some serious hacking is done. I am just not sure how to proceed, on one hand I do not really have the skill to fix the /proc/pid/maps problem, nor figure out how to get dtrace into the system in any time frame that is reasonable. All a few of us need is the addition of the trace back into the existing utrace framework. >> Is it time to start installing with some form of debug symbols? This would help us also with dtrace. > Re: debug symbols, frame pointers, etc. necessary to make userland dtrace work by default, IMO we should strongly prefer such defaults. It's more reasonable to expect people who need every last bit of performance to remove functionality than to expect people who want to figure out what the system is doing to figure out what functionality to turn on. > This is very true. I'm going to continue to work towards this end with a few people and get up to speed on it so that hopefully we can get to this point hopefully in the next release cycle or two. If you have a few moments, can you have a look at the "utrace2" branches here: https://github.com/alfredperlstein/freebsd/tree/utrace2 This branch contains the addition of the utrace2 system call which is needed to structure data via utrace(2). The point of this is to avoid kdump(1) needing to discern type of ktrace records based on arbitrary size or other parameters and introduces an extensible protocol for new types of utrace data. The utrace2 branch here augments jemalloc to use utrace2 to pass the old utrace records, but in addition to pass the return address along with the type and size of the allocation: https://github.com/alfredperlstein/jemalloc/tree/utrace2 -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 06:56:53 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09A32DB6; Thu, 10 Jan 2013 06:56:53 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D22766E9; Thu, 10 Jan 2013 06:56:52 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 770071A3D00; Wed, 9 Jan 2013 22:56:51 -0800 (PST) Message-ID: <50EE6630.2010902@mu.org> Date: Thu, 10 Jan 2013 01:56:48 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jason Evans Subject: Re: malloc+utrace, tracking memory leaks in a running program. References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> In-Reply-To: <50EE6281.7030602@mu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Daniel Eischen , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 06:56:53 -0000 On 1/10/13 1:41 AM, Alfred Perlstein wrote: > On 12/23/12 12:28 PM, Jason Evans wrote: >> On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote: >>> So the other day in an effort to debug a memory leak I decided to >>> take a look at malloc+utrace(2) and decided to make a tool to debug >>> where leaks are coming from. >>> >>> A few hours later I have: >>> 1) a new version of utrace(2) (utrace2(2)) that uses structured data >>> to prevent overloading of data. (utrace2.diff) >>> 2) changes to ktrace and kdump to decode the new format. (also in >>> utrace2.diff) >>> 3) changes to jemalloc to include the new format AND the function >>> caller so it's easy to get the source of the leaks. (also in >>> utrace2.diff) >>> 4) a program that can take a pipe of kdump(1) and figure out what >>> memory has leaked. (alloctrace.py) >>> 5) simple test program (test_utrace.c) >>> >>> […] >> Have you looked at the heap profiling functionality built into >> jemalloc? It's not currently enabled on FreeBSD, but as far as I >> know, the only issue keeping it from being useful is the absence of a >> Linux-compatible /proc//maps (and the gperftools folks may >> already have a solution for that; I haven't looked). I think it >> makes more sense to get that sorted out than to develop a separate >> trace-based leak checker. The problem with tracing is that it >> doesn't scale beyond some relatively small number of allocator events. > > I have looked at some of this functionality (heap profiling) but alas > it is not implemented yet. In addition the dtrace work appears to be > quite away from a workable solution with too many performance > penalties until some serious hacking is done. > > I am just not sure how to proceed, on one hand I do not really have > the skill to fix the /proc/pid/maps problem, nor figure out how to get > dtrace into the system in any time frame that is reasonable. > > All a few of us need is the addition of the trace back into the > existing utrace framework. > >>> Is it time to start installing with some form of debug symbols? This >>> would help us also with dtrace. >> Re: debug symbols, frame pointers, etc. necessary to make userland >> dtrace work by default, IMO we should strongly prefer such defaults. >> It's more reasonable to expect people who need every last bit of >> performance to remove functionality than to expect people who want to >> figure out what the system is doing to figure out what functionality >> to turn on. >> > > This is very true. I'm going to continue to work towards this end > with a few people and get up to speed on it so that hopefully we can > get to this point hopefully in the next release cycle or two. > > If you have a few moments, can you have a look at the "utrace2" > branches here: > https://github.com/alfredperlstein/freebsd/tree/utrace2 > > This branch contains the addition of the utrace2 system call which is > needed to structure data via utrace(2). The point of this is to avoid > kdump(1) needing to discern type of ktrace records based on arbitrary > size or other parameters and introduces an extensible protocol for new > types of utrace data. > > The utrace2 branch here augments jemalloc to use utrace2 to pass the > old utrace records, but in addition to pass the return address along > with the type and size of the allocation: > https://github.com/alfredperlstein/jemalloc/tree/utrace2 > > -Alfred Jason, Here are more convenient links that give diffs against FreeBSD and jemalloc for the proposed changes: FreeBSD: https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2 jemalloc: https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 07:39:03 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 604E4122; Thu, 10 Jan 2013 07:39:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D05927E7; Thu, 10 Jan 2013 07:39:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0A7csXL077103; Thu, 10 Jan 2013 09:38:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0A7csXL077103 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0A7cska077102; Thu, 10 Jan 2013 09:38:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 09:38:54 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: malloc+utrace, tracking memory leaks in a running program. Message-ID: <20130110073854.GQ2561@kib.kiev.ua> References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZqRzwd/9tauJXEMK" Content-Disposition: inline In-Reply-To: <50EE6630.2010902@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:39:03 -0000 --ZqRzwd/9tauJXEMK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: > Here are more convenient links that give diffs against FreeBSD and=20 > jemalloc for the proposed changes: >=20 > FreeBSD: > https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0= 803a374212018f6b68~1...utrace2 >=20 Why do you need to expedite the records through the ktrace at all ? Wouldn't direct write(2)s to a file allow for better performance due to not stressing kernel memory allocator and single writing thread ? Also, the malloc coupling to the single-system interface would be prevented. I believe that other usermode tracers also behave in the similar way, using writes and not private kernel interface. Also, what /proc issues did you mentioned ? There is sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map and does not require /proc mounted. > jemalloc: > https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 >=20 > -Alfred >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --ZqRzwd/9tauJXEMK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7nANAAoJEJDCuSvBvK1BI0YP/3luZYesC/OpGaRrMZrBXBZK qjra23pzuMZ1FDXY72b1duogO7aV91VviBNFzE7eJLzeTN62W/1kN3PoSyIBJW5P T+cekDyUBiYb4xGuoTVM2/B+rdy1sCsklIWalN38F4PbfyJeEpOwiwYRXQ8TL7l/ YyTNquB79+yadDRQv8okcQFs38gAMNVzaYgphtTNCK3xQKM/s5hG3Kt5Tw3JNHqI lH/qAJiSqaZIQBqjQyYVtqq9WxHjC3rSDTCdEt8rtv4Exw2LwHMKNOUcNjQ0lq0F v9FblY5IrPbbx8lVToNNu2bmm2smqA3AuHMDrYDZSOLbJB1wYMZ7S0bhmUMXtx62 0ujnlThltm5uc042DGWVBCzdrMxkG6orFDo8IZlNK7aPIl/froL/iaNfS7jLcEVi TouSVgmjSS8fPFvvIBlN1Y0iKJoKNTchvUzOtvnyw40YY1fZ3XfStAez7ocKsfmC MBSXv8m7b8GCjIRfAdpNol3fOq6SS0IMyHxlBQOVfkVXgBMLn2A/0rkSpc4/uScd c0HdutalMUYGZtCoku9aOgaKB+mtY4e06qxQh02H6y/0EZPbQjMgBju048qqSdRq FFlhomrChC/tnee6X6G4Gma3BcBh1EKYfnfHiEhD16KZE4AWsTsBL6mgGvArMl7r P/Ssw7jQG3bb5l1Qp4LQ =ZoGY -----END PGP SIGNATURE----- --ZqRzwd/9tauJXEMK-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 11:39:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0D55E01 for ; Thu, 10 Jan 2013 11:39:32 +0000 (UTC) (envelope-from cwemre@hotmail.com) Received: from dub0-omc2-s12.dub0.hotmail.com (dub0-omc2-s12.dub0.hotmail.com [157.55.1.151]) by mx1.freebsd.org (Postfix) with ESMTP id C35C0772 for ; Thu, 10 Jan 2013 11:39:31 +0000 (UTC) Received: from DUB002-W109 ([157.55.1.136]) by dub0-omc2-s12.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 03:38:25 -0800 X-EIP: [8M9q4nOVvgQW8LXM4XS+zVkDw7h254fz] X-Originating-Email: [cwemre@hotmail.com] Message-ID: Content-Type: multipart/mixed; boundary="_a608859d-3979-481b-983d-36ed00f2e139_" From: =?windows-1254?B?RW1yZSDHYW1hbGFu?= To: "freebsd-hackers@freebsd.org" Subject: FreeBSD Hp Proliant DL580 g7 & IBM 3650 installation problem Date: Thu, 10 Jan 2013 11:38:24 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2013 11:38:25.0364 (UTC) FILETIME=[006ED940:01CDEF27] X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 11:39:33 -0000 --_a608859d-3979-481b-983d-36ed00f2e139_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: base64 SGksDQoKSSBoYXZlIGdvdCBhIGJpZyBjb21wdXRlciB3aGljaCBoYXMgZ290IGF0IGxlYXN0IDQg Y29yZSAiSHAgUHJvbGlhbnQgREw1ODAgZzciIHNlcnZlci4gDQpBbmQgaXQgaGFzIGdvdCBIUCBw NDEwaSBzbWFydCBhcnJheSBSQUlEIGNhcmQuDQoNCgpJIHRyaWVkIHRvIGluc3RhbGwgRnJlZUJT RCA4LjIsIDguMyA5LjEgZnJvbSBEVkQgYW5kIGJvb3Rvbmx5IGNkIGJ1dCBhZnRlciBwYXNzZWQg bWVudSBzY3JlZW4gSSBnb3QgYW4gZXJyb3IuDQoKDQoKUGxlYXNlIHNob3cgbWUgdGhlIHdheSBm b3Igc29sdXRpb24uDQoKSSBhdHRhY2hlZCBsYXN0IHNjcmVlbnNob3QgZnJvbSBIUCA1ODAuDQoN CkFuZCBJQk0gbWFjaGluZSBnaXZlIGFuIGVycm9yIGFuZCByZXN0YXJ0IGFnYWluIGFuZCBhZ2Fp bi4NCkkgYXR0YWNoZWQgc2NyZWVuc2hvdCB0b28uIAkJIAkgICAJCSAg --_a608859d-3979-481b-983d-36ed00f2e139_-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 15:17:00 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24366260; Thu, 10 Jan 2013 15:17:00 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 11AE826D; Thu, 10 Jan 2013 15:16:59 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 9979A1A3C1C; Thu, 10 Jan 2013 07:16:50 -0800 (PST) Message-ID: <50EEDB5E.2010906@mu.org> Date: Thu, 10 Jan 2013 10:16:46 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: malloc+utrace, tracking memory leaks in a running program. References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> <20130110073854.GQ2561@kib.kiev.ua> In-Reply-To: <20130110073854.GQ2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:17:00 -0000 On 1/10/13 2:38 AM, Konstantin Belousov wrote: > On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: >> Here are more convenient links that give diffs against FreeBSD and >> jemalloc for the proposed changes: >> >> FreeBSD: >> https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2 >> > Why do you need to expedite the records through the ktrace at all ? > Wouldn't direct write(2)s to a file allow for better performance > due to not stressing kernel memory allocator and single writing thread ? > Also, the malloc coupling to the single-system interface would be > prevented. > > I believe that other usermode tracers also behave in the similar way, > using writes and not private kernel interface. > > Also, what /proc issues did you mentioned ? There is > sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map > and does not require /proc mounted. > >> jemalloc: >> https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 >> Konstantin, you are right, it is a strange thing this utrace. I am not sure why it was done this way. You are correct in that much more efficient system could be made using writes gathered into a single write(2). Do you think there is any reason they may have re-used the kernel paths for ktrace even at the cost of efficiency? About kern.proc.vmmap I will look into that. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 18:05:22 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF54832E; Thu, 10 Jan 2013 18:05:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF7AD9F; Thu, 10 Jan 2013 18:05:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0AI5ETu042504; Thu, 10 Jan 2013 20:05:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0AI5ETu042504 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0AI5EUH042503; Thu, 10 Jan 2013 20:05:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 20:05:14 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: malloc+utrace, tracking memory leaks in a running program. Message-ID: <20130110180514.GS2561@kib.kiev.ua> References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> <20130110073854.GQ2561@kib.kiev.ua> <50EEDB5E.2010906@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fqIB0bRxfTYxTb/F" Content-Disposition: inline In-Reply-To: <50EEDB5E.2010906@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:05:22 -0000 --fqIB0bRxfTYxTb/F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote: > On 1/10/13 2:38 AM, Konstantin Belousov wrote: > > On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: > >> Here are more convenient links that give diffs against FreeBSD and > >> jemalloc for the proposed changes: > >> > >> FreeBSD: > >> https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc6= 3a0803a374212018f6b68~1...utrace2 > >> > > Why do you need to expedite the records through the ktrace at all ? > > Wouldn't direct write(2)s to a file allow for better performance > > due to not stressing kernel memory allocator and single writing thread ? > > Also, the malloc coupling to the single-system interface would be > > prevented. > > > > I believe that other usermode tracers also behave in the similar way, > > using writes and not private kernel interface. > > > > Also, what /proc issues did you mentioned ? There is > > sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map > > and does not require /proc mounted. > > > >> jemalloc: > >> https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 > >> >=20 > Konstantin, you are right, it is a strange thing this utrace. I am not= =20 > sure why it was done this way. >=20 > You are correct in that much more efficient system could be made using=20 > writes gathered into a single write(2). Even without writes gathering, non-coalesced writes should be faster than utrace. >=20 > Do you think there is any reason they may have re-used the kernel paths= =20 > for ktrace even at the cost of efficiency? I can only speculate. The utracing of the malloc calls in the context of the ktrace stream is useful for the human reading the trace. Instead of seeing the sequence of unexplanaible calls allocating and freeing memory, you would see something more penetrable. For example, you would see accept/malloc/read/write/free, which could be usefully interpreted as network server serving the client. This context is not needed for a leak detector. >=20 > About kern.proc.vmmap I will look into that. >=20 > -Alfred --fqIB0bRxfTYxTb/F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7wLZAAoJEJDCuSvBvK1Be24P/3rsEBB5K2R1rGoy+N+GYuHa QFmlyug+gRwHk9B/kiu2T4oVvRU8c0TqQtOacD1Y3lNIPDkTQ0P4zjMGf8zSfg6M QEnuNVBFo/29Tc/Eg5walNGogTEyZU1p7fKPNavaSHYoPwuoY8YaPEJY3h6De7rh gg2dAMbzpGK0jMdWM/3x1pKr+Adaz3/QDLZde2OTrJOYlNH5+jC7JjE5MFAJYIsj gVVsNDksETctHWcRgA4eQ7E9dN5gMyR2+sbGYAF/Xiw2ywjvhxCG5HvEPlPE5hK6 aAtGyy7+e/rlTGQoixdkgIp9cGyq+pJJ3+bqyQ84RIIKuvfNO+jR5ipMhVSsP3Tj 5SiDqGg7/ME68fCWd7RtOWu4PImRF/jBkzkLl7msEeOonED076hDpEu2sqNRECae vucD+eJj86sZxQ7jovmJWRrTUibWnd1EbkX9iKoN2atRebYKvW49jB32Uyv2ziXm w8wVRg8km2dC7qwnlbOgdzBkV4Vh9QXF2Ay0xwtfojhyvhd86mH2y7j/PLfAHlQH WcSer8FgJ/xR/VAMPVThYrUJmZfp5y9sKPAHqQMHqOU+ZQTwYBdDRtpjY/j3cTBK QwfUaaFf3t5Fo4M48Cymh8phsUoe/WTvjcwVUKAsjAws3Hj9KLM8OgxDaGQhM48f pQieI/nVrd12o6AaE2fm =B9Xf -----END PGP SIGNATURE----- --fqIB0bRxfTYxTb/F-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 18:29:44 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 046F81D5; Thu, 10 Jan 2013 18:29:44 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E643CF0B; Thu, 10 Jan 2013 18:29:43 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [207.238.187.242]) by elvis.mu.org (Postfix) with ESMTPSA id 93D221A3E40; Thu, 10 Jan 2013 10:29:41 -0800 (PST) Message-ID: <50EF0892.104@mu.org> Date: Thu, 10 Jan 2013 13:29:38 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: malloc+utrace, tracking memory leaks in a running program. References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> <20130110073854.GQ2561@kib.kiev.ua> <50EEDB5E.2010906@mu.org> <20130110180514.GS2561@kib.kiev.ua> In-Reply-To: <20130110180514.GS2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:29:44 -0000 On 1/10/13 1:05 PM, Konstantin Belousov wrote: > On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote: >> On 1/10/13 2:38 AM, Konstantin Belousov wrote: >>> On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: >>>> Here are more convenient links that give diffs against FreeBSD and >>>> jemalloc for the proposed changes: >>>> >>>> FreeBSD: >>>> https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2 >>>> >>> Why do you need to expedite the records through the ktrace at all ? >>> Wouldn't direct write(2)s to a file allow for better performance >>> due to not stressing kernel memory allocator and single writing thread ? >>> Also, the malloc coupling to the single-system interface would be >>> prevented. >>> >>> I believe that other usermode tracers also behave in the similar way, >>> using writes and not private kernel interface. >>> >>> Also, what /proc issues did you mentioned ? There is >>> sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map >>> and does not require /proc mounted. >>> >>>> jemalloc: >>>> https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 >>>> >> Konstantin, you are right, it is a strange thing this utrace. I am not >> sure why it was done this way. >> >> You are correct in that much more efficient system could be made using >> writes gathered into a single write(2). > Even without writes gathering, non-coalesced writes should be faster than > utrace. > >> Do you think there is any reason they may have re-used the kernel paths >> for ktrace even at the cost of efficiency? > I can only speculate. The utracing of the malloc calls in the context > of the ktrace stream is useful for the human reading the trace. Instead > of seeing the sequence of unexplanaible calls allocating and freeing > memory, you would see something more penetrable. For example, you would > see accept/malloc/read/write/free, which could be usefully interpreted > as network server serving the client. > > This context is not needed for a leak detector. Now I may be wrong here, but I think it's an artifact of someone noticing how useful fitting this into the ktrace system and leveraging existing code. Even though there are significant performance deficiencies, the actual utility of the existing framework may have been such a stepping stool towards tracing that it was just used. Right now the code already exists, however it logs just {operation, size, ptr}, example: malloc, 512, -> 0xdeadbeef free, 0, 0xdeadbeef realloc, 512, 0 -> 0xdeadc0de realloc, 1024, 0xdeadc0de -> 0xffff0000 free, 0, 0xffff0000 What do you think of just adding the address of the caller of malloc/free/realloc to these already existing tracepoints? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 19:01:17 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2D599C0 for ; Thu, 10 Jan 2013 19:01:17 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id B19B5E6 for ; Thu, 10 Jan 2013 19:01:17 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so1294991ieb.28 for ; Thu, 10 Jan 2013 11:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=oQvdjZ63bdrep+u04yHg1xS9QiuMA/P4C64ldC/1Bgo=; b=A6ETgRZqcIKm18IsLsKP1eYQObxAAH44RO0b/F3/5MZeR3w1s315I+wQzbU6l2D+8G 0c+AaDYrJ9dxTJOPgpHiRJKKjdNB6d5byDk6j1K7S95cSW+yTu5xJ3qDkbXVKN3Evf1V TN78wVulR8t3t/t5TpH5bsCa8UFBrFfpedg8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer:x-gm-message-state; bh=oQvdjZ63bdrep+u04yHg1xS9QiuMA/P4C64ldC/1Bgo=; b=pYN7x7vu8MG8tav4NMZ3L6WrXZR1gff6DtJHQuZsMxG2IaaDXVy0/w9bayak4OXHmv +NRumxQbkkfdLSJ2zsXAj+AVbzlQOMWESWK4cMvsEvAdvi3TUe6aqwkwjv3yvK0iIjqs KJF9EDvs55B7+Pmh1Ho32egNrsWs4yVbvSi23Am6wobp+TG8+VQOkt8zbl2tY5BI31OI hdz+29Sv77QAtENrKwFcZIeq4vkeBVH0rHhAYu7ufHL10NEHQEz0dilDXBottQiiKLpo gpoithBNRa7O/Tne5X8DSNU7jLG2EQDyHybgCJB3sqWsA6XsupOgDYu36AmCwMZwtwGW EUJw== X-Received: by 10.50.196.130 with SMTP id im2mr6728918igc.17.1357844470824; Thu, 10 Jan 2013 11:01:10 -0800 (PST) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id v12sm2587622igv.3.2013.01.10.11.01.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 11:01:09 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: __builtin_frame_address broken with self created stack? Message-Id: <4ADFB966-782C-4A4A-883C-0A9CFC0EC7A8@dragondata.com> Date: Thu, 10 Jan 2013 13:01:06 -0600 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnDvJCeGSyIk0RCcugLtVjCHnzgLhqyatEo2rwCE7BhhBqM0o/XymAiUPtDOlUCsUO3Zfih X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:01:17 -0000 I'm working on a project that uses State Threads (ports/devel/st). For = the unaware, it's a kinda neat library that implements totally userland = threads with setjmp/longjmp, manually creating stacks and moving the = stack pointer around. It works well, except for one problem, attempting to get a backtrace of = threads. Under linux, the state threads library uses execinfo to get a = backtrace. FreeBSD has libexecinfo in ports which basically is just a = wrapper around __builtin_frame_address and __builtin_return_address. This also mostly works. Except occasionally __builtin_frame_address will = segfault when executing in the context of a created stack. I'm kinda = lost how to debug this, because gdb seems entirely confused as to what = happened when the segfault is received, I'm guessing because this is a = builtin. It works 99% of the time, but under certain (somewhat = deterministic circumstances) __builtin_frame_address breaks. I realize this is breaking a whole lot of assumptions by mallocing some = memory, declaring it to be the new stack by using some assembly to move = the SP register. But, I'm having trouble figuring out what's actually = going wrong here. When it does work, libexecinfo's backtrace() function keeps stepping = back one frame at a time until it hits NULL. When it doesn't work, when = it reaches the frame that should have a NULL frame after it, it = segfaults. Breaking into gdb while using the stack that would kill = backtrace() and executing "bt" works okay - gdb is able to read that = frame anyway. Another datapoint is that this worked fine in FreeBSD 3.0, but that's a = pretty large set of changes to try to narrow down what's different now.=20= Anyone have any idea where to even start with this? I'm having trouble = finding anything that documents how frames work now, and what I'm = possibly not doing when creating a new stack by hand. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 21:03:23 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67CA24BB; Thu, 10 Jan 2013 21:03:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D2BF78C2; Thu, 10 Jan 2013 21:03:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0AL3Dnr065186; Thu, 10 Jan 2013 23:03:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0AL3Dnr065186 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0AL3DwD065185; Thu, 10 Jan 2013 23:03:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 23:03:13 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: malloc+utrace, tracking memory leaks in a running program. Message-ID: <20130110210313.GY2561@kib.kiev.ua> References: <50D52B10.1060205@mu.org> <50EE6281.7030602@mu.org> <50EE6630.2010902@mu.org> <20130110073854.GQ2561@kib.kiev.ua> <50EEDB5E.2010906@mu.org> <20130110180514.GS2561@kib.kiev.ua> <50EF0892.104@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KQ2iXOoQ638mtNze" Content-Disposition: inline In-Reply-To: <50EF0892.104@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Daniel Eischen , hackers@freebsd.org, Jason Evans X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:03:23 -0000 --KQ2iXOoQ638mtNze Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 10, 2013 at 01:29:38PM -0500, Alfred Perlstein wrote: > On 1/10/13 1:05 PM, Konstantin Belousov wrote: > > On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote: > >> On 1/10/13 2:38 AM, Konstantin Belousov wrote: > >>> On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: > >>>> Here are more convenient links that give diffs against FreeBSD and > >>>> jemalloc for the proposed changes: > >>>> > >>>> FreeBSD: > >>>> https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcf= c63a0803a374212018f6b68~1...utrace2 > >>>> > >>> Why do you need to expedite the records through the ktrace at all ? > >>> Wouldn't direct write(2)s to a file allow for better performance > >>> due to not stressing kernel memory allocator and single writing threa= d ? > >>> Also, the malloc coupling to the single-system interface would be > >>> prevented. > >>> > >>> I believe that other usermode tracers also behave in the similar way, > >>> using writes and not private kernel interface. > >>> > >>> Also, what /proc issues did you mentioned ? There is > >>> sysctl kern.proc.vmmap which is much more convenient than /proc/pid/m= ap > >>> and does not require /proc mounted. > >>> > >>>> jemalloc: > >>>> https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 > >>>> > >> Konstantin, you are right, it is a strange thing this utrace. I am not > >> sure why it was done this way. > >> > >> You are correct in that much more efficient system could be made using > >> writes gathered into a single write(2). > > Even without writes gathering, non-coalesced writes should be faster th= an > > utrace. > > > >> Do you think there is any reason they may have re-used the kernel paths > >> for ktrace even at the cost of efficiency? > > I can only speculate. The utracing of the malloc calls in the context > > of the ktrace stream is useful for the human reading the trace. Instead > > of seeing the sequence of unexplanaible calls allocating and freeing > > memory, you would see something more penetrable. For example, you would > > see accept/malloc/read/write/free, which could be usefully interpreted > > as network server serving the client. > > > > This context is not needed for a leak detector. > Now I may be wrong here, but I think it's an artifact of someone=20 > noticing how useful fitting this into the ktrace system and leveraging=20 > existing code. >=20 > Even though there are significant performance deficiencies, the actual=20 > utility of the existing framework may have been such a stepping stool=20 > towards tracing that it was just used. >=20 > Right now the code already exists, however it logs just {operation,=20 > size, ptr}, example: > malloc, 512, -> 0xdeadbeef > free, 0, 0xdeadbeef > realloc, 512, 0 -> 0xdeadc0de > realloc, 1024, 0xdeadc0de -> 0xffff0000 > free, 0, 0xffff0000 >=20 > What do you think of just adding the address of the caller of=20 > malloc/free/realloc to these already existing tracepoints? In most real-world applications I saw, malloc() was not a function called to do the allocation. Usually, there is either an app-specific wrapper, or the language runtime system which calls malloc(), e.g. the new operator for the C++ code. Than, the caller address becomes constant for the whole duration of the program run. What would be useful is the full backtrace of each allocation. The tools like libunwind are indeed optimized for this usage pattern. =46rom this POV, the libc malloc(3) might be better offering a set of the well-defined hooks for a pluggable tracer to utilize. I am on the fence there, you could override the malloc/free without hooks, by the ELF symbol interposing technique, but hooks would also offer features not easily implementable with the interposing. --KQ2iXOoQ638mtNze Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7yyQAAoJEJDCuSvBvK1B+ykP/3o2xJU5OBePwhJepRkiE8AL +y5m9TDUwJ8abK+lnyDvq2c+uK3AiaanTvM/fqrnvq6Y8oN1cw6l7dQKWR5Eja9p bjB5lo80FfZYM5lvdZm51inNPW+E/8QeEeib/LEm9XkTbHmTzRdlH3W63mGNjRSA alYtLcYuCnWD7Y/XXXB1P53Lt0kiE4Ldsu48cprcWbOtShiyrnW2WbNoOItyMG7y 5Fnn6SmRMGvwCZBiuxY4kYcL6Vbx5SNrxDp1rkyY2b7nJVQADbb3vLAjaDTg4eIJ GxCU3F2NTNKkU+hk6wXDFMBIeQozbQ41IupdpqbUTFG+guLCdtFSV6Bjk2+Izq8m i3jc4E3+OvZVWq9zCbKgB7uR7XpVf7fsE8PPhzQvVFMeNokH+XZvw1r//m+09fQz NOTjkjFIe2QtO+5DEcP9b8Aanxwov5YF7zh23mZmtM/G46OzlpJ+qf+SuiEymtzs zwQ9HfFwCQ3GvFIAS4ObjJ6ClWn4+LvJpilFkby0+mggzNGeuahaw32/92k8F3ow Q2r6pLSfLELgB/kAZP4vtLQmGt5E+gs7R/at/cguk3smiapFp4T0HzVso9FZufHh hhAuQacm2ywOO+lT6BAFQ7mNpq+n9DPQC0OVv0lt5kHNZQIHO0OMtEMbz+3nAKsk i8jMPEIyto6tvUlb5puN =K1XI -----END PGP SIGNATURE----- --KQ2iXOoQ638mtNze-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 01:21:46 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECBBA34C for ; Fri, 11 Jan 2013 01:21:46 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 58ED76DD for ; Fri, 11 Jan 2013 01:21:45 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0B0NNMn006725 for ; Fri, 11 Jan 2013 01:23:24 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0B0NNa9006722 for ; Fri, 11 Jan 2013 01:23:23 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 11 Jan 2013 01:23:23 +0100 (CET) From: Wojciech Puchar To: hackers@freebsd.org Subject: SATA disk disappears Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 11 Jan 2013 01:23:24 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 01:21:47 -0000 got this on dell poweredge T110 server with 4 disks, including two 3TB drives (ada2,ada3): ahcich2: Timeout on slot 8 port 0 ahcich2: is 00000000 cs 1ffffe00 ss 1fffff00 rs 1fffff00 tfd 40 serr 00000000 cmd 0000c817 ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) (ada2:ahcich2:0:0:0): lost device GEOM_MIRROR: Request failed (error=6). ada2[WRITE(offset=2997587410944, length=753664)] GEOM_MIRROR: Device home1: provider ada2 disconnected. (ada2:ahcich2:0:0:0): removing device entry did camcontrol reset 2, rescan 2 and ada2 reappeared ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-9 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) GEOM_MIRROR: Component ada2 (device home1) broken, skipping. GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). started gmirror rebuild and it now works at full speed. GEOM_MIRROR: Device home1: rebuilding provider ada2. What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk is fine. I use latest FreeBSD-8 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 03:55:31 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E44AAE93 for ; Fri, 11 Jan 2013 03:55:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A777CD02 for ; Fri, 11 Jan 2013 03:55:31 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0B3tTBB023507; Thu, 10 Jan 2013 20:55:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0B3tTxA023504; Thu, 10 Jan 2013 20:55:29 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 10 Jan 2013 20:55:29 -0700 (MST) From: Warren Block To: Wojciech Puchar Subject: Re: SATA disk disappears In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 10 Jan 2013 20:55:29 -0700 (MST) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 03:55:32 -0000 On Fri, 11 Jan 2013, Wojciech Puchar wrote: > > got this on dell poweredge T110 server with 4 disks, including two 3TB drives > (ada2,ada3): > > ahcich2: Timeout on slot 8 port 0 > ahcich2: is 00000000 cs 1ffffe00 ss 1fffff00 rs 1fffff00 tfd 40 serr 00000000 > cmd 0000c817 > ahcich2: AHCI reset: device not ready after 31000ms (tfd = 00000080) > (ada2:ahcich2:0:0:0): lost device > GEOM_MIRROR: Request failed (error=6). ada2[WRITE(offset=2997587410944, > length=753664)] > GEOM_MIRROR: Device home1: provider ada2 disconnected. > (ada2:ahcich2:0:0:0): removing device entry > > > > did camcontrol reset 2, rescan 2 and ada2 reappeared > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada2: ATA-9 SATA 3.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) > GEOM_MIRROR: Component ada2 (device home1) broken, skipping. > GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). > > > started gmirror rebuild and it now works at full speed. > > GEOM_MIRROR: Device home1: rebuilding provider ada2. > > > What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk is > fine. I had a new WD drive recently that had a write error. Reallocated sector count did not go up, but it quickly failed the SMART self-test, short or long. See smartctl(8) about the -t parameters. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 05:46:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3670C40; Fri, 11 Jan 2013 05:46:07 +0000 (UTC) (envelope-from tretuliy2@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 59AC8FC9; Fri, 11 Jan 2013 05:46:06 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id l10so1428766oag.22 for ; Thu, 10 Jan 2013 21:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iLznxLRRWgzttZoFQMWQpy/523xMOJXLc0XEPCzZwhs=; b=Xk/myrUBFMqGkQKt6JvGr4BGfVoAKA5DQ2uB6Zf+wUP1xlIqiUGN8EbBoMWIC/gjAI KLQXXeCNQJ+q+K4Ub12vOjcLAMPPjyfG/PpFdkk3Mu3AwiRttcArZyZTtJophZ9vFBDq YgyC0qNiuOy5kVcYe+LSo2/Pfi4m11paSoi2gGyuOQGryaD6Gg0AFjVW7/wrIqlP2Xk8 NafCn88Hhfr7f5PymaJNPWi/H4aLAP/Cjfq4cjIhzo12VbMV/Mx9N8WlbYFFg5cIzzAW eDahc0ORaHs9+171ZpSK25VE2uRtBEn2ccBEx724S8vptdYXNLrLYqvOLqixdIoYTzhn 5yLw== MIME-Version: 1.0 Received: by 10.60.8.199 with SMTP id t7mr42229176oea.26.1357883166269; Thu, 10 Jan 2013 21:46:06 -0800 (PST) Sender: tretuliy2@gmail.com Received: by 10.76.69.68 with HTTP; Thu, 10 Jan 2013 21:46:05 -0800 (PST) Received: by 10.76.69.68 with HTTP; Thu, 10 Jan 2013 21:46:05 -0800 (PST) In-Reply-To: References: <201301101140.r0ABe1J0004000@freefall.freebsd.org> Date: Fri, 11 Jan 2013 07:46:05 +0200 X-Google-Sender-Auth: CmxXwGcLRdw2KYEg_h4xe7C71lk Message-ID: Subject: RE: kern/174749: Unexpected change of default route From: Vadim Urazaev To: =?ISO-8859-2?Q?Radek_Krej=E8a?= Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 05:46:07 -0000 Do some body know how can we debug kernel memory corruption on live system? We need to find out which function/subsystem is cause of this mess. Or maybe is there some way to lock particular memory area, where default gateway lies and watch which subsystem will cause system crash? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 07:18:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AFA001EA for ; Fri, 11 Jan 2013 07:18:09 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mx1.freebsd.org (Postfix) with ESMTP id 42695643 for ; Fri, 11 Jan 2013 07:18:08 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id em20so1469236lab.14 for ; Thu, 10 Jan 2013 23:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vQKdA3GnEmtKgZ0K7XcdgMI5gMZjwwlLpFfYIkwycFY=; b=wtD+xHDAItq51SX0omYjzdYUltaemXQQ29wkdJLsvQB7RznnFPlGpMLMZaU4EPlKal CMS5RvXLG+RRj6AEh/XLPeFMriqz7rI4HrijV5THul3Otr+enJdlQjehtsL8diGNK3v6 rsY1gRVIMCAO0ONHMYSew12+T0299avHYIeR8LeGyOG6LkcVNfEIWMPnJvsAkRvHEn4s P0aCbx6s8/eKEZ/R3L1bMIT2cNevna3t4kFKuaP5UqJbZHsKoq6jrlQmPKrDuFNlBbyu 7NZIRilN4pg0E0vBH4BhD7Zt09bSCCzdvVoXlizpD9O0m2GdCXl0vd8/MEwCk29B4lUO QW4A== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr72349645lab.47.1357888687812; Thu, 10 Jan 2013 23:18:07 -0800 (PST) Received: by 10.152.13.36 with HTTP; Thu, 10 Jan 2013 23:18:07 -0800 (PST) Date: Fri, 11 Jan 2013 09:18:07 +0200 Message-ID: Subject: Inconsistent TCP state in tcp_do_segment() From: Jacques Fourie To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:18:09 -0000 Hi, I've been using the kernel socket API and noticed that every once in a while the data received at the remote end of a TCP connection doesn't match the data sent locally using sosend(). I tracked it down to the piece of code in tcp_do_segment() starting at line 2665: (svn rev 245286) if (acked > so->so_snd.sb_cc) { tp->snd_wnd -= so->so_snd.sb_cc; sbdrop_locked(&so->so_snd, (int)so->so_snd.sb_cc); ourfinisacked = 1; } else { sbdrop_locked(&so->so_snd, acked); tp->snd_wnd -= acked; ourfinisacked = 0; } sowwakeup_locked(so); /* Detect una wraparound. */ if (!IN_RECOVERY(tp->t_flags) && SEQ_GT(tp->snd_una, tp->snd_recover) && SEQ_LEQ(th->th_ack, tp->snd_recover)) tp->snd_recover = th->th_ack - 1; /* XXXLAS: Can this be moved up into cc_post_recovery? */ if (IN_RECOVERY(tp->t_flags) && SEQ_GEQ(th->th_ack, tp->snd_recover)) { EXIT_RECOVERY(tp->t_flags); } tp->snd_una = th->th_ack; if (tp->t_flags & TF_SACK_PERMIT) { if (SEQ_GT(tp->snd_una, tp->snd_recover)) tp->snd_recover = tp->snd_una; } if (SEQ_LT(tp->snd_nxt, tp->snd_una)) tp->snd_nxt = tp->snd_una; The issue is that sowwakeup_locked() is called before all the tcpcb fields are updated to account for the current ACK processing as can be seen from the tp->snd_una = th->th_ack in line 2686. My code that uses the kernel socket API calls sosend() in the upcall path resulting from sowwakeup_locked() which in turn can lead to tcp_output() being called with inconsistent TCP state. If I move the call to sowwakeup_locked() to after the 'if (SEQ_LT(tp->snd_nxt, tp->snd_una))' line in the code snippet above the data corruption issue seems to be fixed. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 07:42:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BBD6FB66 for ; Fri, 11 Jan 2013 07:42:35 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6E874D for ; Fri, 11 Jan 2013 07:42:35 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id ej20so1482154lab.35 for ; Thu, 10 Jan 2013 23:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dukEiLiu3lhh/rAvM3eScUKnY6L4/swhqjusfml3tW0=; b=HQqEbvvhYR2PkQ+Lg/doH+/DHZW++RZfnJzTneSESsZhcL1EZiGtnWgdt9K0tm9Bu1 AMlr16/D/UDriAvAp8OtFgMIjDi+6z97i24OWVj8ym7xpwrh604ogg5u7B07fJ6NG/0J e35v0mww4eHI3yUzXkkeQLGla3QuF38DvAVmUg09dLiJo405CMgMHF/wlCq2qOUnGWED TCdafaZf9NRpINMFGiRikF0oK8kc3QhcALehvUWdtTI0utliuZsGQAMq4vloDyV8C5gC TBSeKZW+azJxmY/SF8sbZZWwLtppJZ2T7RT3UZU/Cgs82K6I+/4LiWyAecU8+jc6duC2 HEtA== MIME-Version: 1.0 Received: by 10.112.50.138 with SMTP id c10mr30583764lbo.104.1357889672191; Thu, 10 Jan 2013 23:34:32 -0800 (PST) Received: by 10.152.13.36 with HTTP; Thu, 10 Jan 2013 23:34:32 -0800 (PST) Date: Fri, 11 Jan 2013 09:34:32 +0200 Message-ID: Subject: Possible bug in m_split() when splitting M_EXT mbufs From: Jacques Fourie To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:42:35 -0000 Hi, Could someone please verify if m_split as in svn rev 245286 is doing the right thing in the scenario where a mbuf chain is split with len0 falling on a mbuf boundary and the mbuf in question being a M_EXT mbuf? Consider the following example where m0 is a mbuf chain consisting of 2 M_EXT mbufs, both 1448 bytes in length. Let len0 be 1448. The 'len0 > m->m_len' check will be false so the for loop will not be entered in this case. We now have len = 1448 and remain = 0 and m still points to the first mbuf in the chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will be allocated and initialized before the following piece of code is executed : extpacket: if (m->m_flags & M_EXT) { n->m_data = m->m_data + len; mb_dupcl(n, m); } else { bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); } n->m_len = remain; m->m_len = len; n->m_next = m->m_next; m->m_next = NULL; return (n); As m is a M_EXT mbuf the code in the if() clause will be executed. The problem is that m still points to the first mbuf so effectively the data pointer for n is assigned to the end of m's data pointer. It should actually point to the start of the data pointer of the next mbuf in the original m0 chain, right? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 08:13:03 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B65184A for ; Fri, 11 Jan 2013 08:13:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 76BD58BA for ; Fri, 11 Jan 2013 08:13:01 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r0B8CsQY046496; Fri, 11 Jan 2013 12:12:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r0B8CsK9046495; Fri, 11 Jan 2013 12:12:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Jan 2013 12:12:54 +0400 From: Gleb Smirnoff To: Jacques Fourie Subject: Re: Possible bug in m_split() when splitting M_EXT mbufs Message-ID: <20130111081254.GG82815@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:13:03 -0000 Jacques, On Fri, Jan 11, 2013 at 09:34:32AM +0200, Jacques Fourie wrote: J> Could someone please verify if m_split as in svn rev 245286 is doing the J> right thing in the scenario where a mbuf chain is split with len0 falling J> on a mbuf boundary and the mbuf in question being a M_EXT mbuf? Consider J> the following example where m0 is a mbuf chain consisting of 2 M_EXT mbufs, J> both 1448 bytes in length. Let len0 be 1448. The 'len0 > m->m_len' check J> will be false so the for loop will not be entered in this case. We now have J> len = 1448 and remain = 0 and m still points to the first mbuf in the J> chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will be J> allocated and initialized before the following piece of code is executed : J> J> extpacket: J> if (m->m_flags & M_EXT) { J> n->m_data = m->m_data + len; J> mb_dupcl(n, m); J> } else { J> bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); J> } J> n->m_len = remain; J> m->m_len = len; J> n->m_next = m->m_next; J> m->m_next = NULL; J> return (n); J> J> As m is a M_EXT mbuf the code in the if() clause will be executed. The J> problem is that m still points to the first mbuf so effectively the data J> pointer for n is assigned to the end of m's data pointer. It should J> actually point to the start of the data pointer of the next mbuf in the J> original m0 chain, right? Thanks for analysis, Jacques. IMHO, the following patch should suffice and won't break anything: Index: uipc_mbuf.c =================================================================== --- uipc_mbuf.c (revision 245223) +++ uipc_mbuf.c (working copy) @@ -1126,7 +1126,7 @@ u_int len = len0, remain; MBUF_CHECKSLEEP(wait); - for (m = m0; m && len > m->m_len; m = m->m_next) + for (m = m0; m && len >= m->m_len; m = m->m_next) len -= m->m_len; if (m == NULL) return (NULL); Can you please test it? -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 08:24:01 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E047D00 for ; Fri, 11 Jan 2013 08:24:01 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id A32E896A for ; Fri, 11 Jan 2013 08:23:59 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id r0B8NwgM046532; Fri, 11 Jan 2013 12:23:58 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r0B8Nww0046531; Fri, 11 Jan 2013 12:23:58 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 11 Jan 2013 12:23:58 +0400 From: Gleb Smirnoff To: Jacques Fourie Subject: Re: Inconsistent TCP state in tcp_do_segment() Message-ID: <20130111082358.GH82815@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:24:01 -0000 Jacques, On Fri, Jan 11, 2013 at 09:18:07AM +0200, Jacques Fourie wrote: J> I've been using the kernel socket API and noticed that every once in a J> while the data received at the remote end of a TCP connection doesn't match J> the data sent locally using sosend(). I tracked it down to the piece of J> code in tcp_do_segment() starting at line 2665: (svn rev 245286) J> J> if (acked > so->so_snd.sb_cc) { J> tp->snd_wnd -= so->so_snd.sb_cc; J> sbdrop_locked(&so->so_snd, (int)so->so_snd.sb_cc); J> ourfinisacked = 1; J> } else { J> sbdrop_locked(&so->so_snd, acked); J> tp->snd_wnd -= acked; J> ourfinisacked = 0; J> } J> sowwakeup_locked(so); J> /* Detect una wraparound. */ J> if (!IN_RECOVERY(tp->t_flags) && J> SEQ_GT(tp->snd_una, tp->snd_recover) && J> SEQ_LEQ(th->th_ack, tp->snd_recover)) J> tp->snd_recover = th->th_ack - 1; J> /* XXXLAS: Can this be moved up into cc_post_recovery? */ J> if (IN_RECOVERY(tp->t_flags) && J> SEQ_GEQ(th->th_ack, tp->snd_recover)) { J> EXIT_RECOVERY(tp->t_flags); J> } J> tp->snd_una = th->th_ack; J> if (tp->t_flags & TF_SACK_PERMIT) { J> if (SEQ_GT(tp->snd_una, tp->snd_recover)) J> tp->snd_recover = tp->snd_una; J> } J> if (SEQ_LT(tp->snd_nxt, tp->snd_una)) J> tp->snd_nxt = tp->snd_una; J> J> The issue is that sowwakeup_locked() is called before all the tcpcb fields J> are updated to account for the current ACK processing as can be seen from J> the tp->snd_una = th->th_ack in line 2686. My code that uses the kernel J> socket API calls sosend() in the upcall path resulting from J> sowwakeup_locked() which in turn can lead to tcp_output() being called with J> inconsistent TCP state. If I move the call to sowwakeup_locked() to after J> the 'if (SEQ_LT(tp->snd_nxt, tp->snd_una))' line in the code snippet above J> the data corruption issue seems to be fixed. Again I think that your analysis is correct, thanks! I have added Robert Watson to Cc of this email, so that he can review your suggestion. However, it seems to me that it isn't safe to call sosend() from the upcall directly. I suppose that if you run your code with WITNESS it will report lock order reversals. The correct way for your module is to run sosend() in separate context, for example using taskqueue(9) API, or running separate thread for that. -- Totus tuus, Glebius. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 08:53:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81B905B6; Fri, 11 Jan 2013 08:53:10 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id B2D03A58; Fri, 11 Jan 2013 08:53:09 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id gf7so1142942lbb.30 for ; Fri, 11 Jan 2013 00:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jlvuqVfAdEPXQYYS6/Ne6NJL16eCUle0vCwZM3EGSgc=; b=j1kUuG5OuVmqexoGkzKFUxM3rc0pbnG5nUaCMpJ8pSp5QK4TcPtHQNZzUB4/RdFTPj ZCJQdmcA5tuNxyn9q09CaOIw2x0RI7+IdPZTStfD/hNhxmGRWXTdRae3e6cDtQDh6egI +PSgQ4GmbUNfrOrwd4/IyOL50/wveNAJFgSBPOB5LQfOrL//E3oOHA9UJ2kczHG1dy9u YIunK68xYnQbKm8xXSOVdm9VrhwaTGt0BbVvtqu7Jv6mSc/fYRx07ujiVQ+9EuUq3rOW BRe8/jelUrL516k+l9LxTRF5aI4PIbLT/q5j29Xm08tV2lJCKO6AM4LijfWep/7HMfsh SuwA== MIME-Version: 1.0 Received: by 10.112.41.202 with SMTP id h10mr30573058lbl.20.1357894387073; Fri, 11 Jan 2013 00:53:07 -0800 (PST) Received: by 10.152.13.36 with HTTP; Fri, 11 Jan 2013 00:53:06 -0800 (PST) In-Reply-To: <20130111081254.GG82815@FreeBSD.org> References: <20130111081254.GG82815@FreeBSD.org> Date: Fri, 11 Jan 2013 10:53:06 +0200 Message-ID: Subject: Re: Possible bug in m_split() when splitting M_EXT mbufs From: Jacques Fourie To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:53:10 -0000 On Fri, Jan 11, 2013 at 10:12 AM, Gleb Smirnoff wrote: > Jacques, > > On Fri, Jan 11, 2013 at 09:34:32AM +0200, Jacques Fourie wrote: > J> Could someone please verify if m_split as in svn rev 245286 is doing the > J> right thing in the scenario where a mbuf chain is split with len0 > falling > J> on a mbuf boundary and the mbuf in question being a M_EXT mbuf? Consider > J> the following example where m0 is a mbuf chain consisting of 2 M_EXT > mbufs, > J> both 1448 bytes in length. Let len0 be 1448. The 'len0 > m->m_len' check > J> will be false so the for loop will not be entered in this case. We now > have > J> len = 1448 and remain = 0 and m still points to the first mbuf in the > J> chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will be > J> allocated and initialized before the following piece of code is > executed : > J> > J> extpacket: > J> if (m->m_flags & M_EXT) { > J> n->m_data = m->m_data + len; > J> mb_dupcl(n, m); > J> } else { > J> bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain); > J> } > J> n->m_len = remain; > J> m->m_len = len; > J> n->m_next = m->m_next; > J> m->m_next = NULL; > J> return (n); > J> > J> As m is a M_EXT mbuf the code in the if() clause will be executed. The > J> problem is that m still points to the first mbuf so effectively the data > J> pointer for n is assigned to the end of m's data pointer. It should > J> actually point to the start of the data pointer of the next mbuf in the > J> original m0 chain, right? > > Thanks for analysis, Jacques. > > IMHO, the following patch should suffice and won't break anything: > > Index: uipc_mbuf.c > =================================================================== > --- uipc_mbuf.c (revision 245223) > +++ uipc_mbuf.c (working copy) > @@ -1126,7 +1126,7 @@ > u_int len = len0, remain; > > MBUF_CHECKSLEEP(wait); > - for (m = m0; m && len > m->m_len; m = m->m_next) > + for (m = m0; m && len >= m->m_len; m = m->m_next) > len -= m->m_len; > if (m == NULL) > return (NULL); > > Can you please test it? I think that your patch may cause other issues - m now points to the first mbuf in the tail portion. The final piece of code under the extpacket: label will then set m->m_len to 0 for example. > > -- > Totus tuus, Glebius. > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 09:09:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 322D29C9; Fri, 11 Jan 2013 09:09:44 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id 858A0AE9; Fri, 11 Jan 2013 09:09:43 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fk20so1505494lab.8 for ; Fri, 11 Jan 2013 01:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ioos5t51dGxkZhVTwJh9K3m2ahD43YsIr8F4Zwa9ITE=; b=Tb5pYmulNnXy0JANWfnzdAKWim7u2VJyqR/tLJSNiHmSRTL0Y4IQZ/+lPH4ADA+B+N Q3SMrs+47a6wft7DP8+OIbgGFQxPijBFl/P2e5+Y9bXqT66FuTCo+ndxIlcWuHroZxT9 +varw8Fy9wcSczFII+nrNZycXbQXwL1fIzNRiJvHRxrgmu3iLchyH+TkipCz/7NIMMLT YaufWJju0mFBpRFN1v2jXv0YrJrrr888VgLvnyvPdf3nTRCKgcZbmQprgM4fXLsK4mhY kDYboIHBkc0wvPkYEekjEsxHNux/7UrY444cInJOt0roVNRaGxA+KD9B+iAl9FaQU0S9 NvUQ== MIME-Version: 1.0 Received: by 10.152.114.42 with SMTP id jd10mr9995020lab.31.1357894972373; Fri, 11 Jan 2013 01:02:52 -0800 (PST) Received: by 10.152.13.36 with HTTP; Fri, 11 Jan 2013 01:02:52 -0800 (PST) In-Reply-To: References: <20130111081254.GG82815@FreeBSD.org> Date: Fri, 11 Jan 2013 11:02:52 +0200 Message-ID: Subject: Re: Possible bug in m_split() when splitting M_EXT mbufs From: Jacques Fourie To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:09:44 -0000 On Fri, Jan 11, 2013 at 10:53 AM, Jacques Fourie wrote: > > > > On Fri, Jan 11, 2013 at 10:12 AM, Gleb Smirnoff wrote: > >> Jacques, >> >> On Fri, Jan 11, 2013 at 09:34:32AM +0200, Jacques Fourie wrote: >> J> Could someone please verify if m_split as in svn rev 245286 is doing >> the >> J> right thing in the scenario where a mbuf chain is split with len0 >> falling >> J> on a mbuf boundary and the mbuf in question being a M_EXT mbuf? >> Consider >> J> the following example where m0 is a mbuf chain consisting of 2 M_EXT >> mbufs, >> J> both 1448 bytes in length. Let len0 be 1448. The 'len0 > m->m_len' >> check >> J> will be false so the for loop will not be entered in this case. We now >> have >> J> len = 1448 and remain = 0 and m still points to the first mbuf in the >> J> chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will >> be >> J> allocated and initialized before the following piece of code is >> executed : >> J> >> J> extpacket: >> J> if (m->m_flags & M_EXT) { >> J> n->m_data = m->m_data + len; >> J> mb_dupcl(n, m); >> J> } else { >> J> bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), >> remain); >> J> } >> J> n->m_len = remain; >> J> m->m_len = len; >> J> n->m_next = m->m_next; >> J> m->m_next = NULL; >> J> return (n); >> J> >> J> As m is a M_EXT mbuf the code in the if() clause will be executed. The >> J> problem is that m still points to the first mbuf so effectively the >> data >> J> pointer for n is assigned to the end of m's data pointer. It should >> J> actually point to the start of the data pointer of the next mbuf in the >> J> original m0 chain, right? >> >> Thanks for analysis, Jacques. >> >> IMHO, the following patch should suffice and won't break anything: >> >> Index: uipc_mbuf.c >> =================================================================== >> --- uipc_mbuf.c (revision 245223) >> +++ uipc_mbuf.c (working copy) >> @@ -1126,7 +1126,7 @@ >> u_int len = len0, remain; >> >> MBUF_CHECKSLEEP(wait); >> - for (m = m0; m && len > m->m_len; m = m->m_next) >> + for (m = m0; m && len >= m->m_len; m = m->m_next) >> len -= m->m_len; >> if (m == NULL) >> return (NULL); >> >> Can you please test it? > > > I think that your patch may cause other issues - m now points to the first > mbuf in the tail portion. The final piece of code under the extpacket: > label will then set m->m_len to 0 for example. > >> > > >> -- >> Totus tuus, Glebius. >> > > I have been using the following patch that seems to fix the issue for me : diff --git a/sys/kern/uipc_mbuf.c b/sys/kern/uipc_mbuf.c index ab6163d..5c397fa 100644 --- a/sys/kern/uipc_mbuf.c +++ b/sys/kern/uipc_mbuf.c @@ -1132,6 +1132,23 @@ m_split(struct mbuf *m0, int len0, int wait) return (NULL); remain = m->m_len - len; if (m0->m_flags & M_PKTHDR) { + if (remain == 0) { + if (m->m_next == NULL) + return (NULL); + if (!(m->m_next->m_flags & M_PKTHDR)) { + MGETHDR(n, wait, m0->m_type); + if (n == NULL) + return (NULL); + MH_ALIGN(n, 0); + n->m_next = m->m_next; + } else + n = m->m_next; + m->m_next = NULL; + n->m_pkthdr.rcvif = m0->m_pkthdr.rcvif; + n->m_pkthdr.len = m0->m_pkthdr.len - len0; + m0->m_pkthdr.len = len0; + return (n); + } From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 11:15:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06E043BB for ; Fri, 11 Jan 2013 11:15:45 +0000 (UTC) (envelope-from cheunghonyu@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id E285B3F9 for ; Fri, 11 Jan 2013 11:15:44 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1TtcaO-0001tb-G3 for freebsd-hackers@freebsd.org; Fri, 11 Jan 2013 03:15:44 -0800 Date: Fri, 11 Jan 2013 03:15:44 -0800 (PST) From: zeissoctopus To: freebsd-hackers@freebsd.org Message-ID: <1357902944481-5776597.post@n5.nabble.com> Subject: dirty hack asmc for Macbook 3,1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:15:45 -0000 Dear All, My dirty hack just works but not perfect. --- /usr/src/sys/dev/asmc/asmcvar.h.original 2013-01-11 09:36:53.000000000 +0000 +++ /usr/src/sys/dev/asmc/asmcvar.h 2013-01-11 10:21:02.000000000 +0000 @@ -141,10 +141,22 @@ #define ASMC_MB_TEMPDESCS { "Enclosure Bottomside", \ "Northbridge Point 1", \ "Northbridge Point 2", "Heatsink 1", \ "Heatsink 2", "Memory Bank A", } +#define ASMC_MB31_TEMPS { "TB0T", "TN0P", "Th0H", "Th1H", \ + "TM0P", NULL } + +#define ASMC_MB31_TEMPNAMES { "enclosure", "northbridge1", \ + "heatsink1", "heatsink2", \ + "memory", } + +#define ASMC_MB31_TEMPDESCS { "Enclosure Bottomside", \ + "Northbridge Point 1", \ + "Heatsink 1", "Heatsink2", \ + "Memory Bank A", } + #define ASMC_MBP_TEMPS { "TB0T", "Th0H", "Th1H", "Tm0P", \ "TG0H", "TG0P", "TG0T", NULL } #define ASMC_MBP_TEMPNAMES { "enclosure", "heatsink1", \ "heatsink2", "memory", "graphics", \ --- /usr/src/sys/dev/asmc/asmc.c.original 2013-01-11 05:26:22.000000000 +0000 +++ /usr/src/sys/dev/asmc/asmc.c 2013-01-11 09:51:01.000000000 +0000 @@ -153,10 +153,16 @@ "MacBook2,1", "Apple SMC MacBook Core 2 Duo", ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, NULL, NULL, NULL, ASMC_MB_TEMPS, ASMC_MB_TEMPNAMES, ASMC_MB_TEMPDESCS }, + { + "MacBook3,1", "Apple SMC MacBook Core 2 Duo", + ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, NULL, NULL, NULL, + ASMC_MB31_TEMPS, ASMC_MB31_TEMPNAMES, ASMC_MB31_TEMPDESCS + }, + { "MacBookPro1,1", "Apple SMC MacBook Pro Core Duo (15-inch)", ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, ASMC_LIGHT_FUNCS, ASMC_MBP_TEMPS, ASMC_MBP_TEMPNAMES, ASMC_MBP_TEMPDESCS }, The output of this new asmc on Macbook 3,1 : dev.asmc.0.%desc: Apple SMC MacBook Core 2 Duo dev.asmc.0.%driver: asmc dev.asmc.0.%location: handle=\_SB_.PCI0.LPCB.SMC_ dev.asmc.0.%pnpinfo: _HID=APP0001 _UID=0 dev.asmc.0.%parent: acpi0 dev.asmc.0.fan.0.speed: 4535 dev.asmc.0.fan.0.safespeed: 0 dev.asmc.0.fan.0.minspeed: 1800 dev.asmc.0.fan.0.maxspeed: 6200 dev.asmc.0.fan.0.targetspeed: 4525 dev.asmc.0.temp.enclosure: 28 dev.asmc.0.temp.northbridge1: 52 dev.asmc.0.temp.heatsink1: 57 dev.asmc.0.temp.heatsink2: 55 dev.asmc.0.temp.memory: 51 dev.asmc.0.sms.x: -20 dev.asmc.0.sms.y: 45 dev.asmc.0.sms.z: 264 Regards, zeissoctopus -- View this message in context: http://freebsd.1045724.n5.nabble.com/dirty-hack-asmc-for-Macbook-3-1-tp5776597.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 12:04:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3A16F5E for ; Fri, 11 Jan 2013 12:04:49 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by mx1.freebsd.org (Postfix) with ESMTP id 79D377CB for ; Fri, 11 Jan 2013 12:04:49 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id eg20so1696475lab.30 for ; Fri, 11 Jan 2013 04:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ih9oi1dSsz1BS2E1NMFodQgctdWS7i39NNjCuVjf7jo=; b=ByACGO9aPMv01HGfhTGI/WYRVEecJL6qsIPD23SFZAzVm4pCDBNQ2vaEqyK2mSFmcs vmZBZNyOOF+f0uGZwX0CPtMxAF+WjI41VroyRi+37CTVCfogueYIfyPoxjCwH2KYWsoT fu5++2iwpPh/H2nCkqQbPjdhWe/W/6O+V6P+0OAYS4imDYoJMfbxWemc+B3Zef39BZdR zo2EqBF9Eux6Uy8pGjzGgGTA/VEL0WyFtFZ8+ngLjEczbvAJHuShIXNJnghOLku4p2jp mpP+1Obm4igY8zQicNeZmtB/QSPtn5aqnaRgcreg8XVZCCB+68hqzk6Tr7psdueZVQJf FqdA== MIME-Version: 1.0 Received: by 10.112.101.135 with SMTP id fg7mr30930986lbb.87.1357905888164; Fri, 11 Jan 2013 04:04:48 -0800 (PST) Received: by 10.112.139.71 with HTTP; Fri, 11 Jan 2013 04:04:48 -0800 (PST) Date: Fri, 11 Jan 2013 17:34:48 +0530 Message-ID: Subject: CTF wierdness when built for kernel modules From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 12:04:49 -0000 I am seeing some wierdness with the ctf sections built for the kernel modules, (this is in a proprietary toolchain env) but FreeBSD 10. To build the context, the module.kld is built, ctfmerge is run on the OBJS and the consolidated .SUNW_ctf is appended in module.kld. When I inspect the ctfdump op of module.kld I have this for e.g ... (func_one) returns: 22 args: (1984, 1739, 1986) (func_two) returns: 22 args: (2537, 22, 2534, 297) ... Now when the .ko.debug is built, -ld -m elf_i386 -Bshareable -o module.ko.debug module.kld and the ctfdump for the .SUNW_ctf again inspected (from module.ko.debug) here is the observation... ... (func_two) returns: 22 args: (1984, 1739, 1986) (func_one) returns: 22 args: (2537, 22, 2534, 297) ... What has happened is the position of func_one and func_two are exchanged, and the arguments of func_two are shown against func_one and vice-versa. This is not the case for all functions though...some are correct intact across this move from .kld to .ko Does ld -Bshareable do anything to mess this up? To mention when a I do a (gdb)ptype func_one or (gdb)ptype func_two from both module.kld and module.ko.debug they are correct. It is only in the CTF section that they are messed up... -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 17:34:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F378170 for ; Fri, 11 Jan 2013 17:34:58 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADA486F for ; Fri, 11 Jan 2013 17:34:56 +0000 (UTC) Received: (qmail 23025 invoked by uid 1000); 11 Jan 2013 12:34:45 -0500 Date: Fri, 11 Jan 2013 12:34:45 -0500 From: Larry Baird To: freebsd-hackers@freebsd.org Subject: Tracking FreeBSD development with SVNews Message-ID: <20130111173445.GA15153@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 11 Jan 2013 18:25:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:34:58 -0000 This is a testimonial for a tool for tracking FreeBSD that doesn't get enough publicity. The tool is SVNnews. Too see all FreeBSD modifications for the last week try: http://www.secnetix.de/olli/FreeBSD/svnews/ The real power is when you interested in looking at subsysystems. How about all of the modifications to FreeBSD 9 for the last week? http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/9 How about all the FreeBSD 9 kernel modifications for the last week? http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/9/sys Hopefully you get the idea. My thanks to Oliver for putting together this useful tool. -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 19:29:29 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BEC6E827 for ; Fri, 11 Jan 2013 19:29:29 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 29532CC0 for ; Fri, 11 Jan 2013 19:29:28 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0BJTPd0001329 for ; Fri, 11 Jan 2013 20:29:25 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0BAgYPZ009951; Fri, 11 Jan 2013 11:42:49 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 11 Jan 2013 11:42:34 +0100 (CET) From: Wojciech Puchar To: Warren Block Subject: Re: SATA disk disappears In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 11 Jan 2013 20:29:25 +0100 (CET) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:29:29 -0000 >> GEOM_MIRROR: Component ada2 (device home1) broken, skipping. >> GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). >> >> >> started gmirror rebuild and it now works at full speed. >> >> GEOM_MIRROR: Device home1: rebuilding provider ada2. >> >> >> What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk >> is fine. > > I had a new WD drive recently that had a write error. Reallocated sector > count did not go up, but it quickly failed the SMART self-test, short or > long. See smartctl(8) about the -t parameters. > this is WD "green" 3TB From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 11 21:47:12 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED4B06EF for ; Fri, 11 Jan 2013 21:47:12 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 912CD2F8 for ; Fri, 11 Jan 2013 21:47:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0BLl4d4001109; Fri, 11 Jan 2013 14:47:04 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0BLl3DS001106; Fri, 11 Jan 2013 14:47:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 11 Jan 2013 14:47:03 -0700 (MST) From: Warren Block To: Wojciech Puchar Subject: Re: SATA disk disappears In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 11 Jan 2013 14:47:04 -0700 (MST) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:47:13 -0000 On Fri, 11 Jan 2013, Wojciech Puchar wrote: >>> GEOM_MIRROR: Component ada2 (device home1) broken, skipping. >>> GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). >>> >>> >>> started gmirror rebuild and it now works at full speed. >>> >>> GEOM_MIRROR: Device home1: rebuilding provider ada2. >>> >>> >>> What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk >>> is fine. >> >> I had a new WD drive recently that had a write error. Reallocated sector >> count did not go up, but it quickly failed the SMART self-test, short or >> long. See smartctl(8) about the -t parameters. >> > this is WD "green" 3TB 1T Red here. The firmware is likely very similar. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 04:38:14 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB1E1525 for ; Sat, 12 Jan 2013 04:38:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mx1.freebsd.org (Postfix) with ESMTP id 611EB2FB for ; Sat, 12 Jan 2013 04:38:14 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id dr12so1118936wgb.11 for ; Fri, 11 Jan 2013 20:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hxPsLJa6nWs24VYSgHsNcTPwW3xftNIgqsCqz7TAbh4=; b=AG9FvHbymIfsnoyeBqPuZ+qcfLH0NJJXZJ9Dg7omYgGS4qrh7KskrlgCkt6f7ioE9o rG5XfvqlH7V/X6dSu8oS/GjkE+LKThYmqfxw485DEf/uXig6hdnlIQrjJGwCYGNhewNR a6/Q0wnu+CoUmz44PjnCzUiKMQ7dAMW+jpXvl1eBFzqDi8CVW+fM07ebJHkltGxWn3XP hroLNnfVgxt/upEjy1PslOQ3Ao0EXWzDZSEihfSUrkD+zsEoun+GZEczlNT1/A5mTF6Y He80M8NTCBBlOkb80Mb4o0mcPJ4KgZ2EWTfmDzWzywlIT8Fz9272UdxO0CdHWvGJbRFh em9Q== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr124700208wjc.1.1357965487150; Fri, 11 Jan 2013 20:38:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 11 Jan 2013 20:38:07 -0800 (PST) In-Reply-To: <1357902944481-5776597.post@n5.nabble.com> References: <1357902944481-5776597.post@n5.nabble.com> Date: Fri, 11 Jan 2013 20:38:07 -0800 X-Google-Sender-Auth: AbhGs1HSCFrfP4pBLZQ-bnZh_RA Message-ID: Subject: Re: dirty hack asmc for Macbook 3,1 From: Adrian Chadd To: zeissoctopus Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 04:38:15 -0000 Please file a PR? :) Thanks! ADrian On 11 January 2013 03:15, zeissoctopus wrote: > Dear All, > > My dirty hack just works but not perfect. > > --- /usr/src/sys/dev/asmc/asmcvar.h.original 2013-01-11 > 09:36:53.000000000 +0000 > +++ /usr/src/sys/dev/asmc/asmcvar.h 2013-01-11 10:21:02.000000000 +0000 > @@ -141,10 +141,22 @@ > #define ASMC_MB_TEMPDESCS { "Enclosure Bottomside", \ > "Northbridge Point 1", \ > "Northbridge Point 2", "Heatsink 1", \ > "Heatsink 2", "Memory Bank A", } > > +#define ASMC_MB31_TEMPS { "TB0T", "TN0P", "Th0H", "Th1H", \ > + "TM0P", NULL } > + > +#define ASMC_MB31_TEMPNAMES { "enclosure", "northbridge1", \ > + "heatsink1", "heatsink2", \ > + "memory", } > + > +#define ASMC_MB31_TEMPDESCS { "Enclosure Bottomside", \ > + "Northbridge Point 1", \ > + "Heatsink 1", "Heatsink2", \ > + "Memory Bank A", } > + > #define ASMC_MBP_TEMPS { "TB0T", "Th0H", "Th1H", "Tm0P", \ > "TG0H", "TG0P", "TG0T", NULL } > > #define ASMC_MBP_TEMPNAMES { "enclosure", "heatsink1", \ > "heatsink2", "memory", "graphics", \ > > > --- /usr/src/sys/dev/asmc/asmc.c.original 2013-01-11 > 05:26:22.000000000 +0000 > +++ /usr/src/sys/dev/asmc/asmc.c 2013-01-11 09:51:01.000000000 +0000 > @@ -153,10 +153,16 @@ > "MacBook2,1", "Apple SMC MacBook Core 2 Duo", > ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, NULL, NULL, NULL, > ASMC_MB_TEMPS, ASMC_MB_TEMPNAMES, ASMC_MB_TEMPDESCS > }, > > + { > + "MacBook3,1", "Apple SMC MacBook Core 2 Duo", > + ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, NULL, NULL, NULL, > + ASMC_MB31_TEMPS, ASMC_MB31_TEMPNAMES, ASMC_MB31_TEMPDESCS > + }, > + > { > "MacBookPro1,1", "Apple SMC MacBook Pro Core Duo (15-inch)", > ASMC_SMS_FUNCS, ASMC_FAN_FUNCS, ASMC_LIGHT_FUNCS, > ASMC_MBP_TEMPS, ASMC_MBP_TEMPNAMES, ASMC_MBP_TEMPDESCS > }, > > The output of this new asmc on Macbook 3,1 : > > dev.asmc.0.%desc: Apple SMC MacBook Core 2 Duo > dev.asmc.0.%driver: asmc > dev.asmc.0.%location: handle=\_SB_.PCI0.LPCB.SMC_ > dev.asmc.0.%pnpinfo: _HID=APP0001 _UID=0 > dev.asmc.0.%parent: acpi0 > dev.asmc.0.fan.0.speed: 4535 > dev.asmc.0.fan.0.safespeed: 0 > dev.asmc.0.fan.0.minspeed: 1800 > dev.asmc.0.fan.0.maxspeed: 6200 > dev.asmc.0.fan.0.targetspeed: 4525 > dev.asmc.0.temp.enclosure: 28 > dev.asmc.0.temp.northbridge1: 52 > dev.asmc.0.temp.heatsink1: 57 > dev.asmc.0.temp.heatsink2: 55 > dev.asmc.0.temp.memory: 51 > dev.asmc.0.sms.x: -20 > dev.asmc.0.sms.y: 45 > dev.asmc.0.sms.z: 264 > > Regards, > zeissoctopus > > > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/dirty-hack-asmc-for-Macbook-3-1-tp5776597.html > Sent from the freebsd-hackers mailing list archive at Nabble.com. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 08:24:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 181113FE for ; Sat, 12 Jan 2013 08:24:52 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA5AACD for ; Sat, 12 Jan 2013 08:24:50 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MgaEb-1TZMi42Xah-00Nxi3 for ; Sat, 12 Jan 2013 09:24:43 +0100 Received: (qmail invoked by alias); 12 Jan 2013 08:24:43 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp012) with SMTP; 12 Jan 2013 09:24:43 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX19+j/w7Zkx+/xwDcDISYX2KqT2vzSIvFJR7mKKIa+ /Lxz6yXi+lDqO9 From: Christian Gusenbauer To: freebsd-hackers@freebsd.org Subject: Re: SATA disk disappears Date: Sat, 12 Jan 2013 09:25:54 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301120925.55068.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 08:24:52 -0000 On Friday 11 January 2013 22:47:03 Warren Block wrote: > On Fri, 11 Jan 2013, Wojciech Puchar wrote: > >>> GEOM_MIRROR: Component ada2 (device home1) broken, skipping. > >>> GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). > >>> > >>> > >>> started gmirror rebuild and it now works at full speed. > >>> > >>> GEOM_MIRROR: Device home1: rebuilding provider ada2. > >>> > >>> > >>> What kind of hardware failure may it be? smartctl -a /dev/ada2 shows > >>> disk is fine. > >> > >> I had a new WD drive recently that had a write error. Reallocated > >> sector count did not go up, but it quickly failed the SMART self-test, > >> short or long. See smartctl(8) about the -t parameters. > > > > this is WD "green" 3TB > > 1T Red here. The firmware is likely very similar. The same here: brandnew WD 2T green, 9.1 stable, svn rev. 244773, not using GEOM. I had that problem two times within the last two weeks, but the smart self tests can not find any errors/bad sectors. Ciao, Christian. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 15:29:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85C2B20B for ; Sat, 12 Jan 2013 15:29:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5918ACDA for ; Sat, 12 Jan 2013 15:29:49 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 82A43B918; Sat, 12 Jan 2013 10:29:48 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: kldstat / kernel linker deadlock Date: Fri, 11 Jan 2013 16:13:38 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <50AED0B9.7040108@shatow.net> In-Reply-To: <50AED0B9.7040108@shatow.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301111613.38676.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 12 Jan 2013 10:29:48 -0500 (EST) Cc: Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 15:29:49 -0000 On Thursday, November 22, 2012 08:26:17 PM Bryan Drewery wrote: > On 8.3-RELEASE I've hit a deadlock with kldstat. > > I can't provide much information as procstat(1) locks up and I have > already rebooted the servers due to it breaking quite a bit in my setup. > > > # kldstat > > Id Refs Address Size Name > > load: 0.91 cmd: kldstat 9936 [kernel linker] 51.21r 0.00u 0.00s 0% 768k > > ^C > > load: 0.72 cmd: kldstat 9936 [kernel linker] 225.23r 0.00u 0.00s 0% 704k > > load: 0.72 cmd: kldstat 9936 [kernel linker] 225.39r 0.00u 0.00s 0% 704k > > load: 0.42 cmd: kldstat 9936 [kernel linker] 1837.24r 0.00u 0.00s 0% > > 692k > > Short list of affected processes (74 in all): > > root 3685 0.0 0.0 3264 700 ?? D 7:27PM 0:00.00 > > kldstat root 67061 0.0 0.0 3380 892 ?? D 7:27PM > > 0:00.00 /usr/bin/netstat -nrf inet root 5579 0.0 0.0 3380 > > 892 ?? D 7:37PM 0:00.00 /usr/bin/netstat -nrf inet root > > 6393 0.0 0.0 3264 704 ?? D 7:32PM 0:00.00 /sbin/kldstat -v > > root 99635 0.0 0.1 3324 1244 13 D+ 7:52PM 0:00.01 > > procstat -ka > > [... 69 more removed ...] > > I had 2 minutely cron entries that were running kldstat(1)/netstat(1). > > Guessing the kldstat(1) and netstat(1) deadlocked initially. Next time get a dump if at all possible. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 18:07:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8EE2F3AB for ; Sat, 12 Jan 2013 18:07:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2D100248 for ; Sat, 12 Jan 2013 18:07:22 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0CI7LnL008471; Sat, 12 Jan 2013 11:07:21 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0CI7Hmd008468; Sat, 12 Jan 2013 11:07:17 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 12 Jan 2013 11:07:17 -0700 (MST) From: Warren Block To: Christian Gusenbauer Subject: Re: SATA disk disappears In-Reply-To: <201301120925.55068.c47g@gmx.at> Message-ID: References: <201301120925.55068.c47g@gmx.at> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 12 Jan 2013 11:07:22 -0700 (MST) Cc: freebsd-hackers@freebsd.org, Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:07:23 -0000 On Sat, 12 Jan 2013, Christian Gusenbauer wrote: > On Friday 11 January 2013 22:47:03 Warren Block wrote: >> On Fri, 11 Jan 2013, Wojciech Puchar wrote: >>>>> GEOM_MIRROR: Component ada2 (device home1) broken, skipping. >>>>> GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). >>>>> >>>>> >>>>> started gmirror rebuild and it now works at full speed. >>>>> >>>>> GEOM_MIRROR: Device home1: rebuilding provider ada2. >>>>> >>>>> >>>>> What kind of hardware failure may it be? smartctl -a /dev/ada2 shows >>>>> disk is fine. >>>> >>>> I had a new WD drive recently that had a write error. Reallocated >>>> sector count did not go up, but it quickly failed the SMART self-test, >>>> short or long. See smartctl(8) about the -t parameters. >>> >>> this is WD "green" 3TB >> >> 1T Red here. The firmware is likely very similar. > > The same here: brandnew WD 2T green, 9.1 stable, svn rev. 244773, not using > GEOM. I had that problem two times within the last two weeks, but the smart > self tests can not find any errors/bad sectors. Hmm. The green drives are supposed to go to sleep for power saving, and then there's a multiple-second delay when they have to spin back up on access. That should not be a problem for gmirror, but maybe it is. sysutils/ataidle can turn on the spindown. Some drives do not accept that command, or claim to accept it but ignore it. Worth a try, though. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 18:10:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CF6C4FB for ; Sat, 12 Jan 2013 18:10:30 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5C527E for ; Sat, 12 Jan 2013 18:10:30 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0CIAThO008498; Sat, 12 Jan 2013 11:10:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0CIATYN008495; Sat, 12 Jan 2013 11:10:29 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 12 Jan 2013 11:10:29 -0700 (MST) From: Warren Block To: Christian Gusenbauer Subject: Re: SATA disk disappears In-Reply-To: Message-ID: References: <201301120925.55068.c47g@gmx.at> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 12 Jan 2013 11:10:29 -0700 (MST) Cc: freebsd-hackers@freebsd.org, Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:10:30 -0000 On Sat, 12 Jan 2013, Warren Block wrote: > Hmm. The green drives are supposed to go to sleep for power saving, and then > there's a multiple-second delay when they have to spin back up on access. > That should not be a problem for gmirror, but maybe it is. sysutils/ataidle > can turn on the spindown. Some drives do not accept that command, or claim > to accept it but ignore it. Worth a try, though. Make that: sysutils/ataidle can turn *off* the spindown. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 12 18:22:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AAE55822 for ; Sat, 12 Jan 2013 18:22:52 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by mx1.freebsd.org (Postfix) with ESMTP id 596D630B for ; Sat, 12 Jan 2013 18:22:52 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id t2so1786836qcq.14 for ; Sat, 12 Jan 2013 10:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c95AiYASSyD0drkihjQD9sMDB+VpfIknKNeLCqnRth4=; b=GUOKeQHtQQvrye7igHXxIFFSkVJmrLxBVkBAivUt6vGNkb3/lgwsNTJwZpBq4l/4dj kuqrdXLb1JkbIOIKdMcc4+jbu4tcpIPv0WaoswgCDvANggwORIPl3DlVKqYIVbMOwBJd WXtLMlRSjGiNX/A0jsC88ZOcuB8Letb0zwcfxkvhxVDMg3xxJBWXz0su5kBKMglswCEC aL0e0nxsW1kgnQUSOjL2/ARgcyh2GKh+prRRqT16WtVVZdxvECYGqz/UTYWf1+c/0aln X+1ktufNT6JSEGwv0oOak9wcNVMlryKIuO0Ihxf1aPkvMW7ogIW/ToWkEFx5/2CIYtwi EEZQ== MIME-Version: 1.0 Received: by 10.224.111.83 with SMTP id r19mr65664258qap.39.1358014971551; Sat, 12 Jan 2013 10:22:51 -0800 (PST) Received: by 10.49.128.168 with HTTP; Sat, 12 Jan 2013 10:22:51 -0800 (PST) In-Reply-To: References: <201301120925.55068.c47g@gmx.at> Date: Sat, 12 Jan 2013 12:22:51 -0600 Message-ID: Subject: Re: SATA disk disappears From: Adam Vande More To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 18:22:52 -0000 On Sat, Jan 12, 2013 at 12:10 PM, Warren Block wrote: > On Sat, 12 Jan 2013, Warren Block wrote: > > Hmm. The green drives are supposed to go to sleep for power saving, and >> then there's a multiple-second delay when they have to spin back up on >> access. That should not be a problem for gmirror, but maybe it is. >> sysutils/ataidle can turn on the spindown. Some drives do not accept that >> command, or claim to accept it but ignore it. Worth a try, though. >> > > Make that: sysutils/ataidle can turn *off* the spindown. > > Maybe just bumping kern.cam.ada.default_timeout to 45 or something might help while still allowing drive to function as designed. -- Adam Vande More