From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 00:08:42 2013 Return-Path: Delivered-To: freebsd-current@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 59466547 for ; Sun, 13 Jan 2013 00:08:42 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31CB1EB5 for ; Sun, 13 Jan 2013 00:08:42 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TuB7w-000O1D-04; Sat, 12 Jan 2013 19:08:40 -0500 Date: Sat, 12 Jan 2013 19:08:39 -0500 From: Gary Palmer To: "xenophon\\+freebsd" Subject: Re: Expanding ZFS RAIDZ on the fly? Message-ID: <20130113000839.GB54865@in-addr.com> References: <50EFBAEA.3070200@zedat.fu-berlin.de> <20130111140557.GA63102@psconsult.nl> <20130111233428.GA54865@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 00:08:42 -0000 On Sat, Jan 12, 2013 at 04:11:18PM -0500, xenophon\+freebsd wrote: > > -----Original Message----- > > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > > current@freebsd.org] On Behalf Of Gary Palmer > > Sent: Friday, January 11, 2013 6:34 PM > > > > BPR doesn't look likely, unfortunately. > > I wonder how other SANs implement restriping. The HP P4000/P4500 can > restripe logical units, and it even maintains data redundancy in the > process. Probably more relevantly, NetApp can do it in WAFL, and WAFL uses a number of concepts similar to ZFS in is design (witness the Sun/NetApp patent punch up). From what I understand of the NetApp method, they add the space to the pool and as data is written to the volume, some of it is written to the new disks. Because WAFL is a COW storage system, like ZFS, even if no new data is added, just modified in place, over time the storage is balanced out among members of the aggregate (pool). There is also a command to forcibly rebalance the data from memory. I don't know enough about ZFS to know why something similar can't be done Gary From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 01:27:21 2013 Return-Path: Delivered-To: freebsd-current@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 EA7F59E4; Sun, 13 Jan 2013 01:27:21 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by mx1.freebsd.org (Postfix) with ESMTP id 614C812A; Sun, 13 Jan 2013 01:27:20 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id d1so52647eab.6 for ; Sat, 12 Jan 2013 17:27:13 -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=cxuceI3Z5Y0rUWb4KYKLm0SwRLwOas9V8xMk1EfI5ow=; b=pbetGIgfGqgVHupe/L7hfFPyHxK7YR71M4+LSTEnWnqMJZRXmVeWCxXGk4U8vk+mIJ 8ukBmmM1tpbAvjwUeUJJfdncFXbxCZBHIO2k5gN7WJwIbpfXP1T+JkkQu4Lc65A5mBeQ pyu+P8z+kCV893gIz4KLWw1v/1jMcMhZxCVeUw2TzFpRBT/nnlc1Bg3UMH4od4tDcg4n 5HnRMIuJuy9dCAGepDci9iasA59Do11r6tCl0Q9ehKK3pxW4nTOy39p/KULux4iibdsg B0hIJiLtmnuqLaU0EBG5XolVfL1SuLKuFY3b3fEFBRU6UOx8zw0u7q18K49tucVSw3Cy v90w== MIME-Version: 1.0 Received: by 10.14.174.198 with SMTP id x46mr215803238eel.23.1358040433062; Sat, 12 Jan 2013 17:27:13 -0800 (PST) Received: by 10.14.221.132 with HTTP; Sat, 12 Jan 2013 17:27:12 -0800 (PST) Received: by 10.14.221.132 with HTTP; Sat, 12 Jan 2013 17:27:12 -0800 (PST) In-Reply-To: <1358015380.81432.0.camel@powernoodle> References: <1358015380.81432.0.camel@powernoodle> Date: Sat, 12 Jan 2013 17:27:12 -0800 Message-ID: Subject: Re: Fixing clang warnings in hwpmc From: hiren panchasara To: sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current , Fabien Thomas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 01:27:22 -0000 On Jan 12, 2013 10:29 AM, "Sean Bruno" wrote: > > On Mon, 2013-01-07 at 16:34 -0800, hiren panchasara wrote: > > http://www.strugglingcoder.info/patches/hwpmc_clang_warnings.txt > > > > A trivial patch to fix a couple of clang warnings. > > > > Thanks, > > Hiren > > > Ack. compiles good. Commit in progress. Thanks a lot! Hiren > > Sean From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 17:57:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2979D94; Sun, 13 Jan 2013 17:57: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 F267418D; Sun, 13 Jan 2013 17:57: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 r0DHuvuL073195; Sun, 13 Jan 2013 19:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0DHuvuL073195 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0DHuvQo073194; Sun, 13 Jan 2013 19:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Jan 2013 19:56:56 +0200 From: Konstantin Belousov To: Glen Barber Subject: Re: [panic] Unknown caching mode 8198 in sys/amd64/amd64/pmap.c Message-ID: <20130113175656.GC2561@kib.kiev.ua> References: <20130111200952.GA1359@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+vLU48aB4xoY1VIb" Content-Disposition: inline In-Reply-To: <20130111200952.GA1359@glenbarber.us> 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-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 17:57:03 -0000 --+vLU48aB4xoY1VIb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 11, 2013 at 03:09:52PM -0500, Glen Barber wrote: > Hi, >=20 > I'm running a relatively recent -CURRENT: >=20 > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # uname -a > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #50 r244773: Mon Dec > 31 16:07:53 EST 2012 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 >=20 > I ran into this panic twice over the past 24 hours. Both times, > Chromium was the program I was actively using, with a few ssh sessions > in the background. >=20 > Below follows kgdb session and hopefully useful information. Any advice > on how to further debug this would be appreciated. >=20 > Glen >=20 >=20 > Script started on Fri Jan 11 14:58:16 2013 > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/crash/= vmcore.6 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > panic: Unknown caching mode 8198 >=20 > cpuid =3D 3 > KDB: stack backtrace: > #0 0xffffffff80605a76 at kdb_backtrace+0x66 > #1 0xffffffff805cbbbb at panic+0x13b > #2 0xffffffff80879748 at pmap_cache_bits+0x58 > #3 0xffffffff80880fb4 at pmap_enter+0xa4 > #4 0xffffffff8084ed25 at vm_fault_hold+0x1a15 > #5 0xffffffff8084f8d3 at vm_fault+0x73 > #6 0xffffffff8088593a at trap_pfault+0x13a > #7 0xffffffff80886184 at trap+0x4f4 > #8 0xffffffff8086f853 at calltrap+0x8 > Uptime: 1d14h30m4s > Dumping 4646 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%.= =2E91% >=20 > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/= boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /= bootdir/boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boo= tdir/boot/kernel/geom_eli.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_eli.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /bootdi= r/boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boo= tdir/boot/kernel/coretemp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /b= ootdir/boot/kernel/acpi_video.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi_video.ko > Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdir/= boot/kernel/sem.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sem.ko > Reading symbols from /boot/kernel/acpi_asus.ko...Reading symbols from /bo= otdir/boot/kernel/acpi_asus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi_asus.ko > Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /bootdi= r/boot/kernel/aesni.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/aesni.ko > Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/b= oot/kernel/pf.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pf.ko > Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /boot= dir/boot/kernel/i915kms.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/i915kms.ko > Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /bootdi= r/boot/kernel/iicbb.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/iicbb.ko > Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /bootd= ir/boot/kernel/iicbus.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/iicbus.ko > Reading symbols from /boot/kernel/iic.ko...Reading symbols from /bootdir/= boot/kernel/iic.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/iic.ko > Reading symbols from /boot/kernel/agp.ko...Reading symbols from /bootdir/= boot/kernel/agp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/agp.ko > Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /bootdir= /boot/kernel/drm2.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm2.ko > Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. > Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko > #0 doadump (textdump=3D) at pcpu.h:229 > 229 __asm("movq %%gs:%1,%0" : "=3Dr" (td) > (kgdb) bt > #0 doadump (textdump=3D) at pcpu.h:229 > #1 0xffffffff805cb724 in kern_reboot (howto=3D260) at /usr/src/sys/kern/= kern_shutdown.c:446 > #2 0xffffffff805cbba5 in panic (fmt=3D) at /usr/src= /sys/kern/kern_shutdown.c:753 > #3 0xffffffff80879748 in pmap_cache_bits (mode=3D, = is_pde=3D) > at /usr/src/sys/amd64/amd64/pmap.c:863 > #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D346= 36066816, access=3D,=20 > m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) > at /usr/src/sys/amd64/amd64/pmap.c:3456 > #5 0xffffffff8084ed25 in vm_fault_hold (map=3D0xfffffe01bfa66310, vaddr= =3D34636066816, fault_type=3D1 '\001',=20 > fault_flags=3D, m_hold=3D0x0) at /usr/src/sys/vm= /vm_fault.c:914 > #6 0xffffffff8084f8d3 in vm_fault (map=3D0xfffffe01bfa66310, vaddr=3D346= 36066816,=20 > fault_type=3D, fault_flags=3D0) at /usr/src/sys/= vm/vm_fault.c:224 > #7 0xffffffff8088593a in trap_pfault (frame=3D0xffffff8239b37ac0, usermo= de=3D1) > at /usr/src/sys/amd64/amd64/trap.c:756 > #8 0xffffffff80886184 in trap (frame=3D0xffffff8239b37ac0) at /usr/src/s= ys/amd64/amd64/trap.c:363 > #9 0xffffffff8086f853 in calltrap () at /usr/src/sys/amd64/amd64/excepti= on.S:228 > #10 0x000000080b0f2200 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) frame 3 > #3 0xffffffff80879748 in pmap_cache_bits (mode=3D, = is_pde=3D) > at /usr/src/sys/amd64/amd64/pmap.c:863 > 863 panic("Unknown caching mode %d\n", mode); > (kgdb) list *0xffffffff80879748 > 0xffffffff80879748 is at /usr/src/sys/amd64/amd64/pmap.c:863. > 858 pmap_cache_bits(int mode, boolean_t is_pde) > 859 { > 860 int cache_bits, pat_flag, pat_idx; > 861 =20 > 862 if (mode < 0 || mode >=3D PAT_INDEX_SIZE || pat_index[mod= e] < 0) > 863 panic("Unknown caching mode %d\n", mode); > 864 =20 > 865 /* The PAT bit is different for PTE's and PDE's. */ > 866 pat_flag =3D is_pde ? PG_PDE_PAT : PG_PTE_PAT; > 867 =20 > (kgdb) frame 4 > #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D346= 36066816, access=3D,=20 > m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) > at /usr/src/sys/amd64/amd64/pmap.c:3456 > 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); > (kgdb) p *m > $1 =3D {pageq =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffffff80d2f1b8}, li= stq =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0xfffffe023dfc1b08}, left =3D 0xfffffe023dfc1af8, right = =3D 0x0, object =3D 0xfffffe00219a93a0,=20 > pindex =3D 2905, phys_addr =3D 8809881600, md =3D {pv_list =3D {tqh_fir= st =3D 0x0, tqh_last =3D 0xfffffe023dfc1bb8},=20 > pat_mode =3D 8198}, queue =3D 255 '?', segind =3D 10 '\n', hold_count= =3D 0, order =3D 13 '\r', pool =3D 0 '\0',=20 > cow =3D 0, wire_count =3D 0, aflags =3D 0 '\0', oflags =3D 1 '\001', fl= ags =3D 0, act_count =3D 0 '\0', busy =3D 0 '\0',=20 > valid =3D 255 '?', dirty =3D 0 '\0'} > (kgdb) list *0xffffffff80880fb4 > 0xffffffff80880fb4 is in pmap_enter (/usr/src/sys/amd64/amd64/pmap.c:3461= ). > 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); > 3457 =20 > 3458 mpte =3D NULL; > 3459 =20 > 3460 lock =3D NULL; > 3461 rw_rlock(&pvh_global_lock); > 3462 PMAP_LOCK(pmap); > 3463 =20 > 3464 /* > 3465 * In the case that a page table page is not > (kgdb) root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # ^D >=20 > Script done on Fri Jan 11 14:58:54 2013 Show the output of p *(struct vm_object *)0xfffffe00219a93a0. Do you use zfs or drm2/i915 driver ? --+vLU48aB4xoY1VIb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8vVoAAoJEJDCuSvBvK1Bqj8P/3v448gxIjd5YEbexVek4ixo dH5Q0zUhpqusMelEPBM3JMbgq+ffDU7Gt5OGU4TviPHkEQeEKfoT1crMUBeY+Wqk gxO1ceWBhQ5dVjSZgbGpKlqE6gH+uxNbDlBHwu75V7nVPuNKTZsdsNDeK0R96fwo mpzjDDDAjAlTnMYAR6VwDIl080uZ9lpB8Sjjlc+Ncbi3DjshPIPsvmMcKMPnWvVD x9e5zSI09utHv7FPO062g8vOCUiYqG8nEDATGt9OZsMXTkfjqEVNpjHRa7VSHofi YkBoJtSFjAtbfmY18iDefYqtVmbxg98CWvqm7yGVZv3/FXls+glIjvjLKhhf6nAl Sy8Q5NpxmyFFgL1O3gXbIZ806yvgeVCbrR4DYJtk/vB3cuK7KIci0EQJ379D6V6f W/mcNDZQwLYRStuDX/iaGDtDE2d7JlhCP1D0tRvjavjszqE/MGUhMGXdbrwhEoAz bfU0bvuwRtrZW6xukaicTtot2w9JzbZ9g/l/Mr3GDNzoTWEt6/tpccRhRvYCVI78 N3P3RAh41BwdloV+JYEZxNN+Lh6MX3sgLC2JujrG50L1yA3xQXw4dIcua/LP7LNx yCI5+veS/ksiO6GPTKirf+cXCrHZcQvh5Z1Z7pFomIwUNdvpFqNcFxn3vhA+BZJ8 nZCoFD/dsiHYnZ2GmPkL =u8t4 -----END PGP SIGNATURE----- --+vLU48aB4xoY1VIb-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 18:09:42 2013 Return-Path: Delivered-To: freebsd-current@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 5E1BB202; Sun, 13 Jan 2013 18:09:42 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 04201205; Sun, 13 Jan 2013 18:09:41 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r0DI9enr013768; Sun, 13 Jan 2013 19:09:40 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r0DI9eUL013767; Sun, 13 Jan 2013 19:09:40 +0100 (CET) (envelope-from marius) Date: Sun, 13 Jan 2013 19:09:40 +0100 From: Marius Strobl To: Alexander Motin Subject: Re: [RFC/RFT] calloutng Message-ID: <20130113180940.GM26039@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50EBF921.2000304@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:09:42 -0000 On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: > On 06.01.2013 17:23, Marius Strobl wrote: > > On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote: > >> On 26.12.2012 01:21, Marius Strobl wrote: > >>> On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > >>>> Experiments with dummynet shown ineffective support for very short > >>>> tick-based callouts. New version fixes that, allowing to get as many > >>>> tick-based callout events as hz value permits, while still be able to > >>>> aggregate events and generating minimum of interrupts. > >>>> > >>>> Also this version modifies system load average calculation to fix some > >>>> cases existing in HEAD and 9 branches, that could be fixed with new > >>>> direct callout functionality. > >>>> > >>>> http://people.freebsd.org/~mav/calloutng_12_17.patch > >>>> > >>>> With several important changes made last time I am going to delay commit > >>>> to HEAD for another week to do more testing. Comments and new test cases > >>>> are welcome. Thanks for staying tuned and commenting. > >>> > >>> FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > >>> try on sparc64 and it at least survives a buildworld there. However, > >>> with the patched kernels, buildworld times seem to increase slightly but > >>> reproducible by 1-2% (I only did four runs but typically buildworld > >>> times are rather stable and don't vary more than a minute for the > >>> same kernel and source here). Is this an expected trade-off (system > >>> time as such doesn't seem to increase)? > >> > >> I don't think build process uses significant number of callouts to > >> affect results directly. I think this additional time could be result of > >> the deeper next event look up, done by the new code, that is practically > >> useless for sparc64, which effectively has no cpu_idle() routine. It > >> wouldn't affect system time and wouldn't show up in any statistics > >> (except PMC or something alike) because it is executed inside timer > >> hardware interrupt handler. If my guess is right, that is a part that > >> probably still could be optimized. I'll look on it. Thanks. > >> > >>> Is there anything specific to test? > >> > >> Since the most of code is MI, for sparc64 I would mostly look on related > >> MD parts (eventtimers and timecounters) to make sure they are working > >> reliably in more stressful conditions. I still have some worries about > >> possible deadlock on hardware where IPIs are used to fetch present time > >> from other CPU. > > > > Well, I've just learnt two things the hard way: > > a) We really need the mutex in that path. > > b) Assuming that the initial synchronization of the counters is good > > enough and they won't drift considerably accross the CPUs so we can > > always use the local one makes things go south pretty soon after > > boot. At least with your calloutng_12_26.patch applied. > > Do you think it means they are not really synchronized for some reason? There's definitely no hardware in place which would synchronize them. I've no idea how to properly measure the difference between two tick counters, but I think it's rarther their drift and not the software synchronization we do when starting APs that is causing problems. Mainly, because I can't really think of a better algorithm for doing the latter when startiing the APs. The symptoms are that bout 30 to 60 seconds after that I start to see weird timeouts from device drivers. I'd need to check how long these timeouts actually are to see whether it could be a problem right from the start though. In any case, it seems foolish to think that synchronizing them once would be sufficient and they won't drift until shutdown. Linux probably also doesn't keep re-synchronize them without a reason. Just using a single timecounter source simply appears to be the better choice. > > > I'm not really sure what to do about that. Earlier you already said > > that sched_bind(9) also isn't an option in case if td_critnest > 1. > > To be honest, I don't really unerstand why using a spin lock in the > > timecounter path makes sparc64 the only problematic architecture > > for your changes. The x86 i8254_get_timecount() also uses a spin lock > > so it should be in the same boat. > > The problem is not in using spinlock, but in waiting for other CPU while > spinlock is held. Other CPU may also hold spinlock and wait for > something, causing deadlock. i8254 code uses spinlock just to atomically > access hardware registers, so it causes no problems. Okay, but wouldn't that be a general problem then? Pretty much anything triggering an IPI holds smp_ipi_mtx while doing so and the lower level IPI stuff waits for other CPU(s), including on x86. > > > The affected machines are equipped with a x86-style south bridge > > which exposes a powermanagment unit (intended to be used as a SMBus > > bridge only in these machines) on the PCI bus. Actually, this device > > also includes an ACPI power management timer. However, I've just > > spent a day trying to get that one working without success - it > > just doesn't increment. Probably its clock input isn't connected as > > it's not intended to be used in these machines. > > That south bridge also includes 8254 compatible timers on the ISA/ > > LPC side, but are hidden from the OFW device tree. I can hack these > > devices into existence and give it a try, but even if that works this > > likely would use the same code as the x86 i8254_get_timecount() so I > > don't see what would be gained with that. > > > > The last thing in order to avoid using the tick counter as timecounter > > in the MP case I can think of is that the Broadcom MACs in the affected > > machines also provide a counter driven by a 1 MHz clock. If that's good > > enough for a timecounter I can hook these up (in case these work ...) > > and hack bge(4) to not detach in that case (given that we can't detach > > timecounters ...). > > i8254 on x86 is also just a bit above 1MHz. > > >> Here is small tool we are using for test correctness and performance of > >> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c > >> > > > > I've run Ian's set of tests on a v215 with and without your > > calloutng_12_26.patch and on a v210 (these uses the IPI approach) > > with the latter also applied. > > I'm not really sure what to make out of the numbers. > > > > v215 w/o v215 w/ v210 w/ > > ---------- ---------------- ---------------- ---------------- > > select 1 1999.61 1 23.87 1 29.97 > > poll 1 1999.70 1 1069.61 1 1075.24 > > usleep 1 1999.86 1 23.43 1 28.99 > > nanosleep 1 999.92 1 23.28 1 28.66 > > kqueue 1 1000.12 1 1071.13 1 1076.35 > > kqueueto 1 999.56 1 26.33 1 31.34 > > syscall 1 1.89 1 1.92 1 2.88 FYI, these are the results of the v215 (btw., these (ab)use a bus cycle counter of the host-PCI-bridge as timecounter) with your calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: select 1 23.82 poll 1 1008.23 usleep 1 23.31 nanosleep 1 23.17 kqueue 1 1010.35 kqueueto 1 26.26 syscall 1 1.91 select 300 307.72 poll 300 1008.23 usleep 300 307.64 nanosleep 300 23.21 kqueue 300 1010.49 kqueueto 300 26.27 syscall 300 1.92 select 3000 3009.95 poll 3000 3013.33 usleep 3000 3013.56 nanosleep 3000 23.17 kqueue 3000 3011.09 kqueueto 3000 26.24 syscall 3000 1.91 select 30000 30013.51 poll 30000 30010.63 usleep 30000 30010.64 nanosleep 30000 36.91 kqueue 30000 30012.38 kqueueto 30000 39.90 syscall 30000 1.90 select 300000 300017.52 poll 300000 300013.00 usleep 300000 300012.64 nanosleep 300000 307.59 kqueue 300000 300017.07 kqueueto 300000 310.24 syscall 300000 1.93 > > Numbers are not bad, respecting the fact that to protect from lost > interrupts eventtimer code on sparc64 now sets minimal programming > interval to 15us. It was made to reduce race window between the timer > read-modify-write and some long NMIs. Uhm, there are no NMIs on sparc64. Does it make sense to bypass this adjustment on sparc64? > May be with rereading counter > after programming comparator (same as done for HPET, reading which is > probably much more expensive) this value could be reduced. > I see. There are some bigger fish to fry at the moment though :) Marius From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 18:33:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C628A9F4; Sun, 13 Jan 2013 18:33:42 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 58607321; Sun, 13 Jan 2013 18:33:42 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id EE43323F763; Sun, 13 Jan 2013 13:33:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us EE43323F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sun, 13 Jan 2013 13:33:38 -0500 From: Glen Barber To: Konstantin Belousov Subject: Re: [panic] Unknown caching mode 8198 in sys/amd64/amd64/pmap.c Message-ID: <20130113183338.GJ1359@glenbarber.us> References: <20130111200952.GA1359@glenbarber.us> <20130113175656.GC2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JsihDCElWRmQcbOr" Content-Disposition: inline In-Reply-To: <20130113175656.GC2561@kib.kiev.ua> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:33:42 -0000 --JsihDCElWRmQcbOr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2013 at 07:56:56PM +0200, Konstantin Belousov wrote: > On Fri, Jan 11, 2013 at 03:09:52PM -0500, Glen Barber wrote: > > Hi, > >=20 > > I'm running a relatively recent -CURRENT: > >=20 > > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # uname -a > > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #50 r244773: Mon Dec > > 31 16:07:53 EST 2012 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 > >=20 > > I ran into this panic twice over the past 24 hours. Both times, > > Chromium was the program I was actively using, with a few ssh sessions > > in the background. > >=20 > > Below follows kgdb session and hopefully useful information. Any advice > > on how to further debug this would be appreciated. > >=20 > > Glen > >=20 > >=20 > > Script started on Fri Jan 11 14:58:16 2013 > > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/cras= h/vmcore.6 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "amd64-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > > panic: Unknown caching mode 8198 > >=20 > > cpuid =3D 3 > > KDB: stack backtrace: > > #0 0xffffffff80605a76 at kdb_backtrace+0x66 > > #1 0xffffffff805cbbbb at panic+0x13b > > #2 0xffffffff80879748 at pmap_cache_bits+0x58 > > #3 0xffffffff80880fb4 at pmap_enter+0xa4 > > #4 0xffffffff8084ed25 at vm_fault_hold+0x1a15 > > #5 0xffffffff8084f8d3 at vm_fault+0x73 > > #6 0xffffffff8088593a at trap_pfault+0x13a > > #7 0xffffffff80886184 at trap+0x4f4 > > #8 0xffffffff8086f853 at calltrap+0x8 > > Uptime: 1d14h30m4s > > Dumping 4646 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81= %..91% > >=20 > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdi= r/boot/kernel/zfs.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/zfs.ko > > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from= /bootdir/boot/kernel/opensolaris.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/opensolaris.ko > > Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /b= ootdir/boot/kernel/geom_eli.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/geom_eli.ko > > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot= dir/boot/kernel/linux.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/linux.ko > > Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /b= ootdir/boot/kernel/coretemp.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/coretemp.ko > > Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from = /bootdir/boot/kernel/acpi_video.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/acpi_video.ko > > Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdi= r/boot/kernel/sem.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/sem.ko > > Reading symbols from /boot/kernel/acpi_asus.ko...Reading symbols from /= bootdir/boot/kernel/acpi_asus.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/acpi_asus.ko > > Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /boot= dir/boot/kernel/aesni.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/aesni.ko > > Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir= /boot/kernel/pf.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/pf.ko > > Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /bo= otdir/boot/kernel/i915kms.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/i915kms.ko > > Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /boot= dir/boot/kernel/iicbb.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/iicbb.ko > > Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /boo= tdir/boot/kernel/iicbus.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/iicbus.ko > > Reading symbols from /boot/kernel/iic.ko...Reading symbols from /bootdi= r/boot/kernel/iic.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/iic.ko > > Reading symbols from /boot/kernel/agp.ko...Reading symbols from /bootdi= r/boot/kernel/agp.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/agp.ko > > Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /bootd= ir/boot/kernel/drm2.ko.symbols...done. > > done. > > Loaded symbols for /boot/kernel/drm2.ko > > Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...do= ne. > > Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko > > #0 doadump (textdump=3D) at pcpu.h:229 > > 229 __asm("movq %%gs:%1,%0" : "=3Dr" (td) > > (kgdb) bt > > #0 doadump (textdump=3D) at pcpu.h:229 > > #1 0xffffffff805cb724 in kern_reboot (howto=3D260) at /usr/src/sys/ker= n/kern_shutdown.c:446 > > #2 0xffffffff805cbba5 in panic (fmt=3D) at /usr/s= rc/sys/kern/kern_shutdown.c:753 > > #3 0xffffffff80879748 in pmap_cache_bits (mode=3D= , is_pde=3D) > > at /usr/src/sys/amd64/amd64/pmap.c:863 > > #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D3= 4636066816, access=3D,=20 > > m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) > > at /usr/src/sys/amd64/amd64/pmap.c:3456 > > #5 0xffffffff8084ed25 in vm_fault_hold (map=3D0xfffffe01bfa66310, vadd= r=3D34636066816, fault_type=3D1 '\001',=20 > > fault_flags=3D, m_hold=3D0x0) at /usr/src/sys/= vm/vm_fault.c:914 > > #6 0xffffffff8084f8d3 in vm_fault (map=3D0xfffffe01bfa66310, vaddr=3D3= 4636066816,=20 > > fault_type=3D, fault_flags=3D0) at /usr/src/sy= s/vm/vm_fault.c:224 > > #7 0xffffffff8088593a in trap_pfault (frame=3D0xffffff8239b37ac0, user= mode=3D1) > > at /usr/src/sys/amd64/amd64/trap.c:756 > > #8 0xffffffff80886184 in trap (frame=3D0xffffff8239b37ac0) at /usr/src= /sys/amd64/amd64/trap.c:363 > > #9 0xffffffff8086f853 in calltrap () at /usr/src/sys/amd64/amd64/excep= tion.S:228 > > #10 0x000000080b0f2200 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) frame 3 > > #3 0xffffffff80879748 in pmap_cache_bits (mode=3D= , is_pde=3D) > > at /usr/src/sys/amd64/amd64/pmap.c:863 > > 863 panic("Unknown caching mode %d\n", mode); > > (kgdb) list *0xffffffff80879748 > > 0xffffffff80879748 is at /usr/src/sys/amd64/amd64/pmap.c:863. > > 858 pmap_cache_bits(int mode, boolean_t is_pde) > > 859 { > > 860 int cache_bits, pat_flag, pat_idx; > > 861 =20 > > 862 if (mode < 0 || mode >=3D PAT_INDEX_SIZE || pat_index[m= ode] < 0) > > 863 panic("Unknown caching mode %d\n", mode); > > 864 =20 > > 865 /* The PAT bit is different for PTE's and PDE's. */ > > 866 pat_flag =3D is_pde ? PG_PDE_PAT : PG_PTE_PAT; > > 867 =20 > > (kgdb) frame 4 > > #4 0xffffffff80880fb4 in pmap_enter (pmap=3D0xfffffe01bfa66440, va=3D3= 4636066816, access=3D,=20 > > m=3D0xfffffe023dfc1b70, prot=3D, wired=3D) > > at /usr/src/sys/amd64/amd64/pmap.c:3456 > > 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); > > (kgdb) p *m > > $1 =3D {pageq =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffffff80d2f1b8}, = listq =3D {tqe_next =3D 0x0,=20 > > tqe_prev =3D 0xfffffe023dfc1b08}, left =3D 0xfffffe023dfc1af8, righ= t =3D 0x0, object =3D 0xfffffe00219a93a0,=20 > > pindex =3D 2905, phys_addr =3D 8809881600, md =3D {pv_list =3D {tqh_f= irst =3D 0x0, tqh_last =3D 0xfffffe023dfc1bb8},=20 > > pat_mode =3D 8198}, queue =3D 255 '?', segind =3D 10 '\n', hold_cou= nt =3D 0, order =3D 13 '\r', pool =3D 0 '\0',=20 > > cow =3D 0, wire_count =3D 0, aflags =3D 0 '\0', oflags =3D 1 '\001', = flags =3D 0, act_count =3D 0 '\0', busy =3D 0 '\0',=20 > > valid =3D 255 '?', dirty =3D 0 '\0'} > > (kgdb) list *0xffffffff80880fb4 > > 0xffffffff80880fb4 is in pmap_enter (/usr/src/sys/amd64/amd64/pmap.c:34= 61). > > 3456 newpte |=3D pmap_cache_bits(m->md.pat_mode, 0); > > 3457 =20 > > 3458 mpte =3D NULL; > > 3459 =20 > > 3460 lock =3D NULL; > > 3461 rw_rlock(&pvh_global_lock); > > 3462 PMAP_LOCK(pmap); > > 3463 =20 > > 3464 /* > > 3465 * In the case that a page table page is not > > (kgdb) root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # ^D > >=20 > > Script done on Fri Jan 11 14:58:54 2013 >=20 > Show the output of p *(struct vm_object *)0xfffffe00219a93a0. > Do you use zfs or drm2/i915 driver ? >=20 Yes, I use both drm2/i915 and zfs. Requested kgdb output follows. Thanks, Glen Script started on Sun Jan 13 13:31:20 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/crash/vm= core.6 [...] 229 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) p *(struct vm_object *)0xfffffe00219a93a0 $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xffffffff8099b7a2 "vm object= ", lo_flags =3D 21168128, lo_data =3D 0,=20 lo_witness =3D 0x0}, mtx_lock =3D 4}, object_list =3D {tqe_next =3D 0= xfffffe011479c570,=20 tqe_prev =3D 0xfffffe0139f833c0}, shadow_head =3D {lh_first =3D 0x0}, s= hadow_list =3D { le_next =3D 0xfffffe00914d9740, le_prev =3D 0xfffffe001569ca28}, memq = =3D {tqh_first =3D 0xfffffe023cec1758,=20 tqh_last =3D 0xfffffe023dfc1b80}, root =3D 0xfffffe023dfc1b70, size =3D= 3026, generation =3D 1, ref_count =3D 2,=20 shadow_count =3D 0, memattr =3D 6 '\006', type =3D 0 '\0', flags =3D 1228= 8, pg_color =3D 64558,=20 paging_in_progress =3D 1, resident_page_count =3D 1928, backing_object = =3D 0x0, backing_object_offset =3D 0,=20 pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D {lh_f= irst =3D 0x0}, cache =3D 0x0, handle =3D 0x0,=20 un_pager =3D {vnp =3D {vnp_size =3D 5, writemappings =3D 0}, devp =3D {de= vp_pglist =3D {tqh_first =3D 0x5,=20 tqh_last =3D 0x0}, ops =3D 0x0}, sgp =3D {sgp_pglist =3D {tqh_first= =3D 0x5, tqh_last =3D 0x0}}, swp =3D { swp_bcount =3D 5}}, cred =3D 0xfffffe00155d0c00, charge =3D 12394496} (kgdb) root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # ^D Script done on Sun Jan 13 13:31:46 2013 --JsihDCElWRmQcbOr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ8v4CAAoJEFJPDDeguUaj3tkIAItuvGsr1cQGSaxmsY2o1ZCs d75kMfW7vJlYibNBfP+9WPVjeS4jhGC5mxk+Fdg4yjQtoQZrbWYgYLK416T3LpHz 8/Cl+pnyVp/+i5/tBAy8KxFKr6S2nZTYXpcpT3l/7aFtwlQKHaJyttrQXKhH/biR Fk+hAh2TWbBldsp5Pfdcpy5NV2Xa6AOC9ftaMuqdGWYrgtrlsoxB8ibS90aA3Ts1 km0jDKnfyTwni6iDWnUIK9yfS89ErFpg2QMp/ghxcCt24AGR25IUHbI+nEmY8EtY 03XFdp+8RFT3iqypruDT0G/S7OyWo4LJPiotUycSM4VMwntHUSsaJyBsijrdQK8= =lqK3 -----END PGP SIGNATURE----- --JsihDCElWRmQcbOr-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 18:55:12 2013 Return-Path: Delivered-To: freebsd-current@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 6F4B5EAC; Sun, 13 Jan 2013 18:55:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC863FB; Sun, 13 Jan 2013 18:55:11 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn14so830794wib.10 for ; Sun, 13 Jan 2013 10:55:10 -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=f8xvoNkQ5kqQ9akf+3/9C+QOsx4vvXFCJCR801MT2DU=; b=M1sXrUecpxR1qTMXDDtuXPwQy2eMe03yUbjmY66H69XNJttjknFgg8Fk+lTbZDSAyz 48kurb6jtZg4Z3JT3+g8bskvSD/Pg9vxwCmWPEyYoFxdi8Hrw6HIorv7BLKuvp2uJHCs vvpiQEeZz7MboaED1c7E+k+EciRkqPB9fs0mYx/BlclHpE2K6JEuWPo6Z4cICmR3zjrX 4ZwcbtORT1A4a0/zWJ0Ewi5HXbr9UnY9NTLKOiVKtTa9gP2XwFnASqXkh385+c5xzj/w NDlSX5az/HEzKtSW8o4yd+i3Ywh1+wws11quXPGS7aD9okkhgGcdfRyFCgt2MqbehC82 /XrA== MIME-Version: 1.0 Received: by 10.194.179.34 with SMTP id dd2mr131372291wjc.1.1358103310344; Sun, 13 Jan 2013 10:55:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 13 Jan 2013 10:55:10 -0800 (PST) In-Reply-To: <20130113180940.GM26039@alchemy.franken.de> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> Date: Sun, 13 Jan 2013 10:55:10 -0800 X-Google-Sender-Auth: y_O2qpKyw-1LJ7nR9CGn2iV6RF4 Message-ID: Subject: Re: [RFC/RFT] calloutng From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 18:55:12 -0000 Ok, So everyone - what _could_ be brought into -HEAD right now, without any actual change in code behaviour? eg, what kind of refactoring could be done to reduce the amount of diffs between the branch and -HEAD? Adrian From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 19:36:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0526FA78; Sun, 13 Jan 2013 19:36:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7347D1; Sun, 13 Jan 2013 19:36:17 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1649854bkc.13 for ; Sun, 13 Jan 2013 11:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xnpo7wm3oLZBzu3p4xEheCFDqChL1rJ2MXnnQ28rbWI=; b=fHIB2TsZnamwzmqWX07BS1phKbBERZPf0+5EAoV2pkD4srNZVXf1LJkzvYZz1KP1Io j5WE1Nh+V28n+kEn0Fc5z4wq8Dg0EzJeqvhXwhkeqtbK4rO+ReEgllxyc2XRkBv4WQ+i exz4GSXEw6lqB3j5WswF19TH6T0IhBNwT4owMcLwGna2ezu42BcxNM4wGmoXcdZkMokX MZVVajiJoT42mf2Vuo2TfPphSTNXiZqtLDNWeJqT5k8TrFNh7zhMm/TC7av5vZZ/YTC1 2aMWfLG4IP+cOAEiY0ykthDgN94r6yu3H8qNKCU7mGHSQ879sa+fgHN0zVR7xEh1f/bq ZJxw== X-Received: by 10.204.131.74 with SMTP id w10mr37768753bks.4.1358105776764; Sun, 13 Jan 2013 11:36:16 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id y11sm8181416bkw.8.2013.01.13.11.36.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 11:36:15 -0800 (PST) Sender: Alexander Motin Message-ID: <50F30CAB.3000001@FreeBSD.org> Date: Sun, 13 Jan 2013 21:36:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> In-Reply-To: <20130113180940.GM26039@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 19:36:19 -0000 On 13.01.2013 20:09, Marius Strobl wrote: > On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: >> On 06.01.2013 17:23, Marius Strobl wrote: >>> I'm not really sure what to do about that. Earlier you already said >>> that sched_bind(9) also isn't an option in case if td_critnest > 1. >>> To be honest, I don't really unerstand why using a spin lock in the >>> timecounter path makes sparc64 the only problematic architecture >>> for your changes. The x86 i8254_get_timecount() also uses a spin lock >>> so it should be in the same boat. >> >> The problem is not in using spinlock, but in waiting for other CPU while >> spinlock is held. Other CPU may also hold spinlock and wait for >> something, causing deadlock. i8254 code uses spinlock just to atomically >> access hardware registers, so it causes no problems. > > Okay, but wouldn't that be a general problem then? Pretty much > anything triggering an IPI holds smp_ipi_mtx while doing so and > the lower level IPI stuff waits for other CPU(s), including on > x86. The problem is general. But now it works because single smp_ipi_mtx is used in all cases where IPI result is waited. As soon as spinning happens with interrupts still enabled, there is no deadlocks. But problem reappears if any different lock is used, or locks are nested. In existing code in HEAD and 9 timecounters are never called with spin mutex held. I intentionally tried to avoid that in existing eventtimers code. Callout code same time can be called in any environment with any locks held. And new callout code may need to know precise current time in any of those conditions. Attempt to use an IPI and wait there can be fatal. >>> The affected machines are equipped with a x86-style south bridge >>> which exposes a powermanagment unit (intended to be used as a SMBus >>> bridge only in these machines) on the PCI bus. Actually, this device >>> also includes an ACPI power management timer. However, I've just >>> spent a day trying to get that one working without success - it >>> just doesn't increment. Probably its clock input isn't connected as >>> it's not intended to be used in these machines. >>> That south bridge also includes 8254 compatible timers on the ISA/ >>> LPC side, but are hidden from the OFW device tree. I can hack these >>> devices into existence and give it a try, but even if that works this >>> likely would use the same code as the x86 i8254_get_timecount() so I >>> don't see what would be gained with that. >>> >>> The last thing in order to avoid using the tick counter as timecounter >>> in the MP case I can think of is that the Broadcom MACs in the affected >>> machines also provide a counter driven by a 1 MHz clock. If that's good >>> enough for a timecounter I can hook these up (in case these work ...) >>> and hack bge(4) to not detach in that case (given that we can't detach >>> timecounters ...). >> >> i8254 on x86 is also just a bit above 1MHz. >> >>>> Here is small tool we are using for test correctness and performance of >>>> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c >>>> >>> >>> I've run Ian's set of tests on a v215 with and without your >>> calloutng_12_26.patch and on a v210 (these uses the IPI approach) >>> with the latter also applied. >>> I'm not really sure what to make out of the numbers. >>> >>> v215 w/o v215 w/ v210 w/ >>> ---------- ---------------- ---------------- ---------------- >>> select 1 1999.61 1 23.87 1 29.97 >>> poll 1 1999.70 1 1069.61 1 1075.24 >>> usleep 1 1999.86 1 23.43 1 28.99 >>> nanosleep 1 999.92 1 23.28 1 28.66 >>> kqueue 1 1000.12 1 1071.13 1 1076.35 >>> kqueueto 1 999.56 1 26.33 1 31.34 >>> syscall 1 1.89 1 1.92 1 2.88 > > FYI, these are the results of the v215 (btw., these (ab)use a bus > cycle counter of the host-PCI-bridge as timecounter) with your > calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: > select 1 23.82 > poll 1 1008.23 > usleep 1 23.31 > nanosleep 1 23.17 > kqueue 1 1010.35 > kqueueto 1 26.26 > syscall 1 1.91 > select 300 307.72 > poll 300 1008.23 > usleep 300 307.64 > nanosleep 300 23.21 > kqueue 300 1010.49 > kqueueto 300 26.27 > syscall 300 1.92 > select 3000 3009.95 > poll 3000 3013.33 > usleep 3000 3013.56 > nanosleep 3000 23.17 > kqueue 3000 3011.09 > kqueueto 3000 26.24 > syscall 3000 1.91 > select 30000 30013.51 > poll 30000 30010.63 > usleep 30000 30010.64 > nanosleep 30000 36.91 > kqueue 30000 30012.38 > kqueueto 30000 39.90 > syscall 30000 1.90 > select 300000 300017.52 > poll 300000 300013.00 > usleep 300000 300012.64 > nanosleep 300000 307.59 > kqueue 300000 300017.07 > kqueueto 300000 310.24 > syscall 300000 1.93 It seems that extra delay is only about 10-17us. >> Numbers are not bad, respecting the fact that to protect from lost >> interrupts eventtimer code on sparc64 now sets minimal programming >> interval to 15us. It was made to reduce race window between the timer >> read-modify-write and some long NMIs. > > Uhm, there are no NMIs on sparc64. Does it make sense to bypass this > adjustment on sparc64? If it is not possible or not good to to stop timer during programming, there will always be some race window between code execution and timer ticking. So some minimal safety range should be reserved. Though it probably can be significantly reduced. In case of x86/HPET there is additional factor of NMI, that extends race to unpredictable level and so makes additional post-read almost mandatory. >> May be with rereading counter >> after programming comparator (same as done for HPET, reading which is >> probably much more expensive) this value could be reduced. > > I see. There are some bigger fish to fry at the moment though :) :) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 20:05:14 2013 Return-Path: Delivered-To: freebsd-current@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 88FE02F6; Sun, 13 Jan 2013 20:05:14 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4E08F8F3; Sun, 13 Jan 2013 20:05:14 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id h2so3369089oag.21 for ; Sun, 13 Jan 2013 12:05:08 -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:cc:content-type; bh=rQHAFtlJ9rJfcbcsZhBEHK1KYqnYmL8cNmpZri0c+tc=; b=ZdM3PzmuJlY8ypkARyFz3NveMZxo3Vg5sggAoM7W0kNicMsSB9LdqEH6AFrRupLYVY g+Fi+ZT49dbuXh/S5Vt0vWajmF4ZBJytA5gHE8r6WBpdOn2Bbygb/FvQd3PhPUps1vTl w9kvG3S6s2CTVVz+x7jyfUFqpOy1alwPwTDLh/ShEHVML5vkp9gBVn/CCGAq/2mDWmMj DaJ67fPBV7iScOvJIkjgzPSgB7j5K7baGjA2qFC95SYDQO4ILUw1n81VVfwewwlUHMXe FvFdD83aau6UGSqzymJXjkgj2cXoB/ubH3ZXf2Tx4LLCPsQUBUnVhYo6yMeWnMjJOxLj MfnA== MIME-Version: 1.0 Received: by 10.182.146.107 with SMTP id tb11mr59356040obb.30.1358107508750; Sun, 13 Jan 2013 12:05:08 -0800 (PST) Received: by 10.76.107.241 with HTTP; Sun, 13 Jan 2013 12:05:08 -0800 (PST) Date: Sun, 13 Jan 2013 12:05:08 -0800 Message-ID: Subject: Strange input device (ukbd/ums) and signal handling problems with X11 on CURRENT From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-x11@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 20:05:14 -0000 (Sorry for the cross-post, but this applies to -current and -x11) I recently installed CURRENT on my workstation at home again and I'm running into issues where in X11 it will stop registering certain mouse events (left-mouse clicking in particular) on my MS Intellimouse (in fact, it was working before I started typing the email, and now it stopped again... might be because of the middle mouse button on my wheel because that's the only thing I really did). Some of the issues appear to be tied to the keyboard too (using the Alt-Tab key combination doesn't always switch windows), so maybe it's a deadlock of some kind in Xorg? I say this because issuing some commands to xinit on a console (^T -> SIGINFO) screws up Xorg when I switch back to VTY-9 (it fails to render the screen). I run into this frequently with Firefox (maybe with its focus stealing?) compared to other apps, and sometimes I can do some minor keyboard gymnastics in order to get things back to a sane state. I don't run into these issues on the 9-STABLE machine I use at work, but granted, there's a software/hardware delta. I need some help figuring out how to diagnose the issue (apart from xev -- which isn't providing me with a lot of info), as truss is useless and turning on ktrace is like getting a fire hose worth of unhelpful info. I have a pretty bleeding edge ports tree with minor modifications (but not in any areas that should be causing this). In order to diagnose the problem, I've tried the following steps: 1. Restart moused (no change). 2. Unplugging and replugging devices (no change). 3. Built ports with clang and gcc (no change) [going back to building ports with clang BTW]. 4. Tried multiple DEs/WMs (Fluxbox, LXDE, XFCE4). Run into the same issue at various points in time on all 3 (it's particularly painful with Fluxbox for some odd reason because I generally can right-mouse click in fluxbox, but can't do much else apart from that). Other things I could try and building ukbd/ums as a module instead of building it into the kernel to see if the device is getting into a wonky state and reloading the device gets it back to a sane one. I've attached other hopefully helpful details at the bottom of the page. Thanks! -Garrett Version: FreeBSD fallout.local 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r+96bb463: Tue Jan 8 00:39:55 PST 2013 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd64 xorg.conf snippet: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Some relevant packages: $ pkg info | egrep 'nvidia|xorg' linux-f10-xorg-libs-7.4_1 Xorg libraries (Linux Fedora 10) nvidia-driver-304.64 NVidia graphics card binary drivers for hardware OpenGL rendering nvidia-settings-310.14 Display Control Panel for X NVidia driver xorg-7.5.2 X.Org complete distribution metaport xorg-apps-7.5.2 X.org apps meta-port xorg-cf-files-1.0.4 X.org cf files for use with imake builds xorg-docs-1.6,1 X.org documentation files xorg-drivers-7.5.2 X.org drivers meta-port xorg-fonts-7.5.1 X.org fonts meta-port xorg-fonts-100dpi-7.5.1 X.Org 100dpi bitmap fonts xorg-fonts-75dpi-7.5.1 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-7.5.1 X.Org Cyrillic bitmap fonts xorg-fonts-miscbitmaps-7.5.1 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-7.5.1 X.Org TrueType fonts xorg-fonts-type1-7.5.1 X.Org Type1 fonts xorg-libraries-7.5.1 X.org libraries meta-port xorg-macros-1.16.1 X.Org development aclocal macros xorg-server-1.7.7_6,1 X.Org X server and related programs Xorg.0.log snippet: (**) Option "Protocol" "auto" (**) Option "Device" "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse usbconfig: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen7.1: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen5.2: at usbus5, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON My KERNCONF can be found here: https://gitorious.org/gcooper-scratch/gcooper-scratch/blobs/master/fallout/root/FALLOUT From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 21:57:48 2013 Return-Path: Delivered-To: current@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 9117643F; Sun, 13 Jan 2013 21:57:48 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id C4953F30; Sun, 13 Jan 2013 21:57:47 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so1646387eek.7 for ; Sun, 13 Jan 2013 13:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=8V6EMSvWZJHUHgX+nB2s8cmYorP75cnsxIo71lYpa9Q=; b=m5CkMLAzJXQ+DDnjIDKqi6G7ahaHL2Cs63ci9ZeOlEft71CYwjPOns1KQLtmte06/k G98GCiCDPuTww2Ry7EIOCBs9E4VuNCCiYSHVaiZMW7slfHNUPmkS2s/zDmBMCH3f9osh L7HMwL9zBlkfPPyU3q4jfGhHGMzg/GqxwcPsArNN33z1LWywuu50tBV0SjaYgIoj7Pqt 0NyGFcmWI/EVIgTiQXRWOu/KcFMuiBUGaMJ1Gu6pWhjqheH9Eh/6pEC58yQn8e3xPXvx bbVAjO5fqtVROlgFqOjsk4W2PeGEiBcjGmECDaCQku2SsfdOCDCeiRR+5xT4qb8zKtNn /UEQ== X-Received: by 10.14.204.70 with SMTP id g46mr198174046eeo.15.1358114261321; Sun, 13 Jan 2013 13:57:41 -0800 (PST) Received: from spongya (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPS id 6sm19115718eea.3.2013.01.13.13.57.39 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 13:57:40 -0800 (PST) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sun, 13 Jan 2013 22:57:14 +0100 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report April-June, 2012 Message-ID: <20130113225714.0083627d@spongya> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 21:57:48 -0000 FreeBSD Quarterly Status Report April-June, 2012 Introduction This report covers FreeBSD-related projects between April and June 2012. This quarter was highlighted by having a new Core Team elected, which took office on July 11th to start its work with a relatively high number of new members. Note that this is the second of the three reports planned for 2012. Thanks to all the reporters for the excellent work! This report contains 17 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between July and December 2012 is February 17th, 2013. __________________________________________________________________ Projects Userland Programs * FreeBSD Services Control (fsc) * Replacing the Regular Expression Code FreeBSD Team Reports * FreeBSD Documentation Project * The FreeBSD Core Team * The FreeBSD Port Management Team Kernel * FreeBSD/at91 Improvements Network Infrastructure * Multipath TCP (MPTCP) for FreeBSD * SMP-Friendly pf(4) Documentation * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor Ports * BSD-licensed Sort Utility (GNU sort(1) Replacement) * FreeBSD Haskell Ports * KDE/FreeBSD * Portbuilder * Redports * Xorg on FreeBSD Miscellaneous * BSD-Day 2012 __________________________________________________________________ BSD-Day 2012 URL: http://bsdday.eu/2012 URL: http://www.youtube.com/playlist?list=3DPL13D5471D8ECF08C9 URL: https://picasaweb.google.com/116452848880746560170/BSDDay2012?authk= ey=3DGv1sRgCN3twLrxuaeongE Contact: G=C3=A1bor P=C3=A1li For this year, we moved the time of the event earlier by six months, so it was held on May 5, 2012 and it was co-located with the Austrian Linuxweeks (Linuxwochen =C3=96sterreich) in Vienna. We had many sponsors, like the freshly joined FreeBSD Foundation, iXsystems, FreeBSDMall, BSD Magazine, allBSD.de Projekt, that enabled us to continue our previously launched series of multi-project BSD developer summits all around Central Europe. To kick off, there was a "stammtisch" (local beer meetup) organized in the downtown of Vienna, at Kolar on the Friday evening before the event -- as usual. Then it was followed by the event on Saturday that brought many interesting topics from the world of FreeBSD, OpenBSD and NetBSD: running NetBSD as an embedded system for managing VOIP applications, introduction to the Capsicum security framework, relayd(8), the load balancer and proxy solution for OpenBSD, status update of the developments around the FreeBSD ports tree, using DVCSs in clouds, firewalling with pfSense, and mfsBSD. Please consult the links in the report for the details. __________________________________________________________________ BSD-licensed Sort Utility (GNU sort(1) Replacement) URL: http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/ URL: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Contact: Oleg Moskalenko Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n BSD sort(1) has been made the default sort utility in 10-CURRENT. It is compatible with the latest GNU sort(1), version 8.15, except that the multi-threaded mode is not enabled by default. Open tasks: 1. When the track record of the BSD sort(1) allows, remove GNU sort(1) from -CURRENT. 2. Improve reliability of the multi-threaded sort and investigate the possibility of making it the default compilation mode. 3. Investigate possibility of factoring out the sort functionality into a standalone library so that other utilities can also make use of it. __________________________________________________________________ FreeBSD Documentation Project URL: http://wiki.freebsd.org/GoogleCodeIn/2011Status URL: http://wiki.freebsd.org/201208DevSummit URL: http://wiki.freebsd.org/DocIdeaList Contact: We continue to make progress in committing the work produced as part of Google Code-In 2011; an overview of the status is at http://wiki.freebsd.org/GoogleCodeIn/2011Status. Doc committers and GCIN mentors are encouraged to go through the list and help shepherd outstanding tasks into the tree. We are planning a full day of Documentation Summit on the day preceding the August 2012 DevSummit in Cambridge, UK. This follows a successful DocSummit day held at BSDCan in May 2012. Further details are available at: http://wiki.freebsd.org/201208DevSummit. A doc sprint took place over IRC (#bsddocs on EFnet) in early July, setting out plans for reviving the marketing team and a strong desire for a new, more organized website. A lot of progress and momentum has built up with creating and updating documentation and website content over the last few months. Also read the doceng report for the recent infrastructure improvements. Anyone wishing to help with this effort is welcome to join us and say hello either on the freebsd-doc mailing list, or #bsddocs on EFnet IRC. Open tasks: 1. Review the website content and remove outdated parts or update when applicable. 2. Go through the doc idea list on the wiki and start working them out. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ Contact: G=C3=A1bor P=C3=81LI Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2012.2.0.0, GHC to 7.4.1 as well as updated existing ports to their latest stable versions. We also added a number of new Haskell ports, and their count in FreeBSD Ports tree is now 336. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC bootstrap tarball. 3. Commit pending Haskell ports to the FreeBSD Ports tree. 4. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD Services Control (fsc) Contact: Tom Rhodes FSC has been moved into the ports system (see sysutils/fsc) and continues to improve outside of the ports tree. Some interesting work is being done in the area of services control, system boot, and a simplification of the process. Stay tuned for more information in status reports that follow. Open tasks: 1. Test, test, test. Feedback is really important to this project. __________________________________________________________________ FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor URL: http://www.arm.com/products/processors/cortex-a/cortex-a15.php URL: http://www.arm.com/products/tools/models/fast-models.php Contact: Zbigniew Bodek Contact: Rafal Jaworowski Contact: Tomasz Nowicki ARM Fast Models is platform which helps software developers debug systems in parallel with SoC design, speeding up and improving system development. This work is bringing up FreeBSD on ARM Fast Models system based on ARM Cortex-A15 and peripheral components. It works in single user mode, using a compiled-in kernel RAM disk minimal root file system. Current FreeBSD support includes: * L1, L2 cache, Branch Predictor * Dual-core (SMP) support setup in WB cache mode * Cortex-A15 integrated Generic Timer * Drivers for ARM peripheral components: + PL011 UART controller + PL390 GIC - Generic Interrupt Controller + SP804 Dual Timer Next steps: * Quad-core (SMP) support * Multi-user mode __________________________________________________________________ FreeBSD/at91 Improvements URL: http://wiki.freebsd.org/FreeBSDAtmel Contact: Warner Losh FreeBSD's Atmel support has languished for some time. A number of improvements were urgently needed as demand for newer SoCs has materialized. New SoC support is not hard, but it does wind up copying a lot of code. I have started down the path to make it easier to do. I had planned on making it table driven. But then I discovered with dts files that Atmel was producing. So, I plan on moving to using Atmel's .dsti files, or variations on them. They have .dsti files for all the AT91SAM9 parts. This should allow us to support new SoCs and boards faster. However, there are some challenges with this approach. Pin multiplexing seems undefined in Atmel's dts file. Only a few of the devices are well-defined at the present time. And the encoding seems to be immature. So we have a target-rich port that is quite ripe for refactoring. Open tasks: 1. Update the base system libfdt to a version that supports include. 2. Write a .dtsi for Atmel AT91RM9200. 3. Write .dti files for all supported boards. 4. Help sort out the pin multiplexing issue. 5. Refactor existing board files to make new ones easier in the interim. 6. Knock yourself out and implement board support for new CPUs. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The team has made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.8.3, 4.8.4 (in ports) and 4.8.95 (in area51) * Qt: 4.8.1, 4.8.2 * PyQt: 4.9.1; SIP: 4.13.2; QScintilla 2.6.1 * KDevelop: 2.3.1; KDevPlatform: 1.3.1 * Calligra: 2.4.2, 2.4.3 * Amarok: 2.5.90 (in area51) * CMake: 2.8.8 * Digikam (and KIPI-plugins): 2.6.0 As a result -- according to PortScout -- kde@ has 393 ports, of which 91% are up-to-date. The team is always looking for more testers and porters so please contact us and visit our home page. Open tasks: 1. Test KDE SC 4.8.95. 2. Test KDE PIM 4.8.95. 3. Update out-of-date ports, see PortScout for a list. __________________________________________________________________ Multipath TCP (MPTCP) for FreeBSD URL: http://caia.swin.edu.au/newtcp/mptcp/ URL: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-09 URL: http://mptcp.info.ucl.ac.be/ Contact: Nigel Williams Contact: Lawrence Stewart Contact: Grenville Armitage Work is underway to create an IETF draft-compatible Multipath TCP implementation for the FreeBSD kernel. A key goal of the project is to create a research platform to investigate a range of multipath related transport issues including congestion control, retransmission strategy and packet scheduling policy. We also aim to provide full interoperability with the Linux kernel implementation being developed at Universit=C3=A9 catholique de Louvain. We expect to release code and results at the project's home page as it progresses. __________________________________________________________________ Portbuilder URL: https://github.com/DragonSA/portbuilder URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/README URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/TODO Contact: David Naylor Since the last update there has been 2 feature releases and 4 bug-fix releases. A highlight of the changes made: * Support has been added for: * -j: controlling concurrency per stage * pkgng: next generation package manager * installing packages via repository * dynamic defaults (loaded from /etc/make.conf) * new options framework (aka OptionsNG) Some of the fixes include: * correct assertions * correct build logic * retry when kevent receives EINTR * correctly detecting installed ports * many fixes in the build logic A benchmark was run timing portbuilder against a standard ports build of KDE (x11/kde4) in a clean chroot(8) environment. Portbuilder achieved a build time of 2:21:16 compared to ports build time of 4:47:21 for an decreased build time of 51% from using portbuilder. __________________________________________________________________ Redports URL: http://www.redports.org/ Contact: Bernhard Froehlich There was good progress in the last half a year and a lot of support from different parties to make redports a stable and fast service. A long known security concern within tinderbox was raised at the BSD-Day in Vienna which was addressed by beat. That improves security and isolation of the concurrent running jobs a lot and gives me peace of mind. We also recently got two beefy machines from the FreeBSD Foundation which increases computing power a lot. So no more backlogs and your jobs finish much quicker. But as usual now that we have enough power I was able to make another promise come true and integrated Ports QAT functionality into redports. Ports QAT was an automated services that did a buildtest after each commit to the official FreeBSD ports tree. If a build fails it sends out mails and logfiles to the committer. That finds bad commits quickly and allows the committer to fix it before the first user notices. The former service stopped about 2 years ago and we had no proper replacement for that task at hand. Now that this is fully integrated into redports it also gives us all the nice benefits of a common platform. Open tasks: 1. Automatic build incoming patches from Ports PRs in redports and send results to GNATS database. 2. People want an GCC testing environment on redports where all ports are build with lang/gcc47. To make that happen we need to patch the ports framework to handle that and correctly bootstrap with base GCC. This also gives us the possibility to build all our binary packages with a modern gcc and is easy to use for regular users. Contributors? __________________________________________________________________ Replacing the Regular Expression Code URL: http://laurikari.net/tre/ Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n It has been decided to implement the optimizations and extensions as a more isolated layer and not directly in TRE itself. Since the last report there has been some progress in this direction and the code has been significantly refactored. It does not work yet in this new form but it is close to a working state. Apart from this, the multiple pattern matching needs some debugging and some minor features are missing. Open tasks: 1. Finish multiple pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Test performance, standard-compliance and correct behavior. __________________________________________________________________ SMP-Friendly pf(4) URL: http://svnweb.freebsd.org/base/projects/pf/head/ URL: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html Contact: Gleb Smirnoff The project is aimed at moving the pf(4) packet filter out of single mutex, as well as in general improving of its FreeBSD port. The project is near its finish, the code is planned to go into head after more testing and benchmarking. If you are interested in details, please see the corresponding email thread on freebsd-pf (see links). Open tasks: 1. Rewrite the pf(4) ioctl() interface so that it does not utilize in-kernel structures. That would make ABI more stable and ease future development. __________________________________________________________________ The FreeBSD Core Team URL: http://docs.FreeBSD.org/cgi/mid.cgi?1342030291.6001.80.camel Contact: Core Team The FreeBSD Project is pleased to announce the completion of the 2012 Core Team election. The FreeBSD Core Team acts as the project's "Board of Directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The Core Team has been elected by FreeBSD developers every 2 years since 2000. Peter Wemm rejoins the Core Team after a two-year hiatus, with new members Thomas Abthorpe, Gavin Atkinson, David Chisnall, Attilio Rao and Martin Wilke joining incumbents John Baldwin, Konstantin Belousov and Hiroki Sato. The complete newly elected core team is: * Thomas Abthorpe * Gavin Atkinson * John Baldwin * Konstantin Belousov * David Chisnall * Attilio Rao * Hiroki Sato * Peter Wemm * Martin Wilke The new Core Team would like to thank outgoing members Wilko Bulte, Brooks Davis, Warner Losh, Pav Lucistnik, Colin Percival and Robert Watson for their service over the past two (and in some cases, many more) years. The Core Team would also especially like to thank Dag-Erling Sm=C3=B8rgr= av for running the election. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Our translation work has slightly moved on to handbook from the www/ja (CVS) or htdocs (SVN) subtree, since almost translated web page contents were updated to the latest English counterparts. During this period, we translated the 8.3-RELEASE announcement and published it in a timely manner. Newsflash and some other updates in the English version were also translated as soon as possible. For FreeBSD Handbook, translation work of the "cutting-edge" and "printing" sections have been completed. Some updates in the "linuxemu" and "serialcomms" section were done. At this moment, "bsdinstall", "cutting-edge", "desktop", "install", "introduction", "kernelconfig", "mirrors", "multimedia", "pgpkeys", "ports", "printing", and "x11" chapters are synchronized with the English versions. Open tasks: 1. Further translation work of outdated documents in ja_JP.eucJP subtree. __________________________________________________________________ The FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly approaches 24,000 ports. The PR count still is close to 1200. In Q2 we added 7 new committers and took in one commit bit for safe keeping. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * automake update * cmake update * xorg update * png update * Fix make reinstall * Implement USE_QT4 in bsd.ports.mk * KDE4 update * XFCE4 update * bison update * perl5.14 as default * ruby1.9 as default * ruby1.8 update * bsdsort regression test A lot of focus during this period was put into getting the ports tree into a ready state for FreeBSD 9.1. A significant step forward was the implementation of OptionsNG. A record number of Port Managers attended BSDCan 2012, with five being present to partake in the week of events, culminating in a portmgr PR closing session that dealt with 18 PRs in one day. You can see a group photo at . While you are there, please click on the "Like" icon. Beat Gaetzi has been doing ongoing tests with the ports tree to ensure a smooth transition from CVS to Subversion. The tree was successfully migrated the weekend of June 14, 2012. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help fixing ports broken on CURRENT. (List needs updating, too.) 3. Looking for help with Tier-2 architectures. 4. ports broken by src changes. 5. ports failing on pointyhat. 6. ports failing on pointyhat-west. 7. ports that are marked as BROKEN. 8. When did that port break? 9. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: Martin Wilke Contact: Koop Mast Contact: Niclas Zeising Contact: Eitan Adler During the beginning of this period, an update to the xorg distribution for FreeBSD was made, dubbed xorg 7.5.2. This update included a new flag, WITH_NEW_XORG, to get a more recent xorg distribution for those with modern hardware. To get KMS support for recent Intel graphics chipsets WITH_KMS must also be set. This requires a recent FreeBSD 10-CURRENT or FreeBSD 9-STABLE. Open tasks: 1. Switch to use FreeGLUT instead of libGLUT, since the latter is old and has there is no upstream support or releases any more. Work on this is mostly done. 2. Update the xorg distribution to what is in the development repository. The xorg project recently did a new release, and the development repository contains this release. It needs more testing before it can be merged, and a CFT was sent out in the beginning of June. Work on this is ongoing. 3. Decide how to handle the new and old xorg distributions. In recent xorg, a lot of legacy driver support has been dropped, therefore we need to maintain two xorg distributions to not loose a lot of hardware drivers. Currently, this is done by setting the flag WITH_NEW_XORG in /etc/make.conf, but a more practical solution is needed. This is especially important since the flag is not very user friendly, and since there currently will be no official packages for the new distribution. __________________________________________________________________ (c) 1995-2013 The FreeBSD Project. All rights reserved. From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 23:10:12 2013 Return-Path: Delivered-To: freebsd-current@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 2850BE4E; Sun, 13 Jan 2013 23:10:12 +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 042FC3C8; Sun, 13 Jan 2013 23:10:04 +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 r0DNA3Pj075876; Sun, 13 Jan 2013 16:10:04 -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 r0DNA1nf001260; Sun, 13 Jan 2013 16:10:01 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: <50F30CAB.3000001@FreeBSD.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jan 2013 16:10:01 -0700 Message-ID: <1358118601.32417.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:10:12 -0000 On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: [...] > > > > Uhm, there are no NMIs on sparc64. Does it make sense to bypass this > > adjustment on sparc64? > > If it is not possible or not good to to stop timer during programming, > there will always be some race window between code execution and timer > ticking. So some minimal safety range should be reserved. Though it > probably can be significantly reduced. In case of x86/HPET there is > additional factor of NMI, that extends race to unpredictable level and > so makes additional post-read almost mandatory. > > >> May be with rereading counter > >> after programming comparator (same as done for HPET, reading which is > >> probably much more expensive) this value could be reduced. > > > > I see. There are some bigger fish to fry at the moment though :) > Speaking of the HPET code, it seems to me that its restart logic can fire the same event twice. Is that harmless? -- Ian From owner-freebsd-current@FreeBSD.ORG Sun Jan 13 23:18:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C93A18D; Sun, 13 Jan 2013 23:18:38 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD4461E; Sun, 13 Jan 2013 23:18:37 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id d1so300707eab.6 for ; Sun, 13 Jan 2013 15:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GC8+rsuCb6k06K5jKC3zmOB0/sW2RHVaHFU6jwa6lrc=; b=iXLR8FWA1PNxzBvUMhT/VpU7Q1HYGwF9WvzAYltyiNOLEBWvSUIogIROHUrCuWR1KP SgtxmVUlocCKMb6sYb0TCEf+Be4lloq9J2smJVLR+7wgsg1aqnEWU6T3L7fWtw2JpyiM LbuBjUEcy/EwMT5pxBmCVZOxLDtTXUC7MVKZY7LDmQucSzq634Rdtz9HrNOH24ly4pPd xZc4k6T+/U7fcB9WiI/xAfJtEgP9Nj5Nww/fLuKKtvqQLaTmi8sXUHEYjGF3gzFVPwPs lSmsyNJTbVEriz+T+4fWJg8sZnzTbn+DaG3YDQ7t7bZynnieY8ebHkfCsvpOeM0JK8Qh lbdg== X-Received: by 10.14.219.72 with SMTP id l48mr225048018eep.37.1358119116209; Sun, 13 Jan 2013 15:18:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id f49sm19300520eep.12.2013.01.13.15.18.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 15:18:35 -0800 (PST) Sender: Alexander Motin Message-ID: <50F340C8.2040905@FreeBSD.org> Date: Mon, 14 Jan 2013 01:18:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <1358118601.32417.41.camel@revolution.hippie.lan> In-Reply-To: <1358118601.32417.41.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Davide Italiano , freebsd-arch@freebsd.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 23:18:38 -0000 On 14.01.2013 01:10, Ian Lepore wrote: > On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote: >> On 13.01.2013 20:09, Marius Strobl wrote: > [...] >>> >>> Uhm, there are no NMIs on sparc64. Does it make sense to bypass this >>> adjustment on sparc64? >> >> If it is not possible or not good to to stop timer during programming, >> there will always be some race window between code execution and timer >> ticking. So some minimal safety range should be reserved. Though it >> probably can be significantly reduced. In case of x86/HPET there is >> additional factor of NMI, that extends race to unpredictable level and >> so makes additional post-read almost mandatory. >> >>>> May be with rereading counter >>>> after programming comparator (same as done for HPET, reading which is >>>> probably much more expensive) this value could be reduced. >>> >>> I see. There are some bigger fish to fry at the moment though :) >> > > Speaking of the HPET code, it seems to me that its restart logic can > fire the same event twice. Is that harmless? It is much less harmful then not fire and loose interrupt completely, and as result stuck for indefinite time. I have no better ideas, while this seems works well. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 00:38:39 2013 Return-Path: Delivered-To: freebsd-current@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 9E13BDC0; Mon, 14 Jan 2013 00:38:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 730E686C; Mon, 14 Jan 2013 00:38:38 +0000 (UTC) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E0caxA016303; Mon, 14 Jan 2013 11:38:36 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0E0cKsQ030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 11:38:22 +1100 Date: Mon, 14 Jan 2013 11:38:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin Subject: Re: [RFC/RFT] calloutng In-Reply-To: <50F30CAB.3000001@FreeBSD.org> Message-ID: <20130114102118.V1045@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=E6GVPthl c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=_g3VQHKJVn_i_Cvtq8kA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 X-Mailman-Approved-At: Mon, 14 Jan 2013 00:56:42 +0000 Cc: Davide Italiano , freebsd-arch@FreeBSD.org, FreeBSD Current , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 00:38:39 -0000 On Sun, 13 Jan 2013, Alexander Motin wrote: > On 13.01.2013 20:09, Marius Strobl wrote: >> On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: >>> On 06.01.2013 17:23, Marius Strobl wrote: >>>> I'm not really sure what to do about that. Earlier you already said >>>> that sched_bind(9) also isn't an option in case if td_critnest > 1. >>>> To be honest, I don't really unerstand why using a spin lock in the >>>> timecounter path makes sparc64 the only problematic architecture >>>> for your changes. The x86 i8254_get_timecount() also uses a spin lock >>>> so it should be in the same boat. >>> >>> The problem is not in using spinlock, but in waiting for other CPU while >>> spinlock is held. Other CPU may also hold spinlock and wait for >>> something, causing deadlock. i8254 code uses spinlock just to atomically >>> access hardware registers, so it causes no problems. >> >> Okay, but wouldn't that be a general problem then? Pretty much >> anything triggering an IPI holds smp_ipi_mtx while doing so and >> the lower level IPI stuff waits for other CPU(s), including on >> x86. > > The problem is general. But now it works because single smp_ipi_mtx is > used in all cases where IPI result is waited. As soon as spinning > happens with interrupts still enabled, there is no deadlocks. But > problem reappears if any different lock is used, or locks are nested. > > In existing code in HEAD and 9 timecounters are never called with spin > mutex held. I intentionally tried to avoid that in existing eventtimers > code. Er, timecounters are called with a spin mutex held in existing code: though it is dangerous to do so, timecounters are called from fast interrupt handlers for very timekeeping-critical purposes: - to implement the TIOCTIMESTAMP ioctl (except this is broken in -current). This was a primitive version of pps timestamping. - for pps timestamping. The interrupt handler (which should be a fast interrupt handler to minimize latency) calls pps_capture() which calls tc_get_timecount() and does other "lock-free" accesses to the timecounter state. This still works in -current (at least there is still code for it). OTOH, all drivers that call pps_capture() from their interrupt handler then immediately call pps_event(). This has always been very broken, and became even more broken with SMPng. pps_event() does many more timecounter and pps accesses whose locking is unclear at best, and in some configurations it calls hardpps(), which is only locked by Giant, despite comments in kern_ntptime.c still saying that it (and many other functions in kern_ntptime.c) must be called at splclock() or higher. splclock() is of course now null, but the locking requirements in kern_ntptime.c haven't changed much. kern_ntptime.c always needed to be locked by the equivalent of a spin mutex, which is stronger locking than was given by splclock(). pps_event() would have to aquire the spin mutex before calling hardpps(), although this is bad for fast interrupt handlers. The correct implementation is probably to only do the capture part from fast interrupt handlers. > Callout code same time can be called in any environment with any > locks held. And new callout code may need to know precise current time > in any of those conditions. Attempt to use an IPI and wait there can be > fatal. Callout code can't be called from such a general "any" environment as timecounter code. Not from a fast interrupt handler. Not from an NMI or IPI handler. I hope. But timecounter code has a good chance of working even for the last 2 environments, due to its design requirement of working in the first. The spinlock in the i8254 timecounter certainly breaks some cases. For example, suppose the lock is held for a timecounter read from normal context. It masks hardware interrupts on the current CPU (except in my version). It doesn't mask NMIs or other traps. So if the NMI or other trap handler does a timecounter hardware call, there is deadlock in at least the !SMP case. In my version, it blocks normal interrupts later if they occur, but doesn't block fast interrupts, so the pps_capture() call would deadlock if it occurs, like a timecounter call from an NMI. I avoid this by not using pps in any fast interrupt handler, and by only using the i8254 timecounter for testing. I do use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock interrupt handlers are all non-fast to avoid this and other locking problems. >> FYI, these are the results of the v215 (btw., these (ab)use a bus >> cycle counter of the host-PCI-bridge as timecounter) with your >> calloutng_12_17.patch and kern.timecounter.alloweddeviation=0: >> select 1 23.82 >> poll 1 1008.23 >> usleep 1 23.31 >> nanosleep 1 23.17 >> kqueue 1 1010.35 >> kqueueto 1 26.26 >> syscall 1 1.91 >> select 300 307.72 >> poll 300 1008.23 >> usleep 300 307.64 >> nanosleep 300 23.21 Please fix the tv_nsec initialization so that we can see if nanosleep() and kqueue() work. (The nanosleep() timeout here is actually 300 nsec, so 23.21 usec being shorter than 300 usec is not a kernel bug.) >> kqueue 300 1010.49 >> kqueueto 300 26.27 >> syscall 300 1.92 >> ... > > It seems that extra delay is only about 10-17us. Sometimes only 7. But 23-26 for short timeouts. For long timeouts, it should be closer to 0 extra, since the overhead for scheduling and handling timer interrupts is smaller than the timeout so it can be subtracted from the timeout to get accuracy. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 12:18:42 2013 Return-Path: Delivered-To: freebsd-current@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 95E298D7 for ; Mon, 14 Jan 2013 12:18:42 +0000 (UTC) (envelope-from tomek.cedro@gmail.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 28CB4EBF for ; Mon, 14 Jan 2013 12:18:41 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fh20so3772340lab.34 for ; Mon, 14 Jan 2013 04:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=xp3T4CMvFkVQMWtStv4WbxIHACX1CSuBrYFLz4C/Rew=; b=zDBagOTHO3WzqleQW+7e+yAhmuW1XNiiUO43FEtuApNIhP+gI6AjJmhWuo2rk37fWC pQeTlGNW4UDQVLyj5dLzOnTRZVQRy/oaTla+6gO5Riq1g15UnfZNCr3HZ4aRHotQbie4 CyeH5eOa4qfnWZ/HsSUCc/cynHlVrHxdYz4xcqql+V+LUlzzOrkIVatuwONvfknBeMhj k+eNByq4olPltVx8nK8F7FHrTLFJLE3YbyspPXl/w1KCOHOMFpyE3LjtMaBziW8RyW5v RTEMaHo47TKO3Cgzoy0SCyHLVsqYw1Ae6HMEgqPYRcnVJGF++lNYzR5VLmLxbTM1adVx DLbA== MIME-Version: 1.0 Received: by 10.112.51.175 with SMTP id l15mr33868288lbo.5.1358165914784; Mon, 14 Jan 2013 04:18:34 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.0.45 with HTTP; Mon, 14 Jan 2013 04:18:34 -0800 (PST) Date: Mon, 14 Jan 2013 13:18:34 +0100 X-Google-Sender-Auth: 8ADJggUqgXDeckv7V0OlYZjQCCA Message-ID: Subject: Hardware VM support for Jails From: CeDeROM To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 14 Jan 2013 12:31:56 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:18:42 -0000 Hello :-) I was wondering if there is a hardware accelerated Jail using Virtualization CPU extensions in BSD or everything is done in Kernel by software? SUSE is advertising their "light virtualization" (no hardware emulation) I was wondering if BSD has this capabilities too ;-) What would be benefit for this over Jail? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 12:39:18 2013 Return-Path: Delivered-To: freebsd-current@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 9DA9C297 for ; Mon, 14 Jan 2013 12:39:18 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (feld.me [66.170.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7B29CFA9 for ; Mon, 14 Jan 2013 12:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=6TsL9tWhAISOJMdZm/FQtooEYdAB4pZG/kNM1jdjslU=; b=DimHKL83eyMyqrZS6o88aMLzmovWDWMW14GKWTMHV3xqHez8XiAsWLlEBxSc6sUjTbTA6rXOJOPc5ZxfyV6G7R63Sr7So+B44i/K6Z+q275BFlAHwVoocE0Zeti028DB; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TujJp-000MW8-Ao; Mon, 14 Jan 2013 06:39:14 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1358167152-86286-86284/5/2; Mon, 14 Jan 2013 12:39:12 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: freebsd-current@freebsd.org, cederom@tlen.pl Subject: Re: Hardware VM support for Jails References: Date: Mon, 14 Jan 2013 06:39:12 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: User-Agent: Opera Mail/12.12 (FreeBSD) X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 12:39:18 -0000 On Mon, 14 Jan 2013 06:18:34 -0600, wrote: > Hello :-) > > I was wondering if there is a hardware accelerated Jail using > Virtualization CPU extensions in BSD or everything is done in Kernel > by software? SUSE is advertising their "light virtualization" (no > hardware emulation) I was wondering if BSD has this capabilities too > ;-) What would be benefit for this over Jail? > The jails don't need to use these CPU extensions because jails are just like running the native OS. There really aren't any abstraction layers hindering performance. From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 14:06:57 2013 Return-Path: Delivered-To: freebsd-current@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 4A4BE161 for ; Mon, 14 Jan 2013 14:06:57 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by mx1.freebsd.org (Postfix) with ESMTP id CD0FBA37 for ; Mon, 14 Jan 2013 14:06:56 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id fs13so3893141lab.37 for ; Mon, 14 Jan 2013 06:06:55 -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=PvEouxS8qS3Dsnl3xp7fYRuxr2XWtzyPUNdu8p0vKK8=; b=mA1H1spdxV+ARvT5UEppMHaCjtyYhHft3j29OVeXAWGCHBOmypz3Pp2TbQ/rWjbUsT ZJMG1dsWFsuHs+5ECoIWwzHvcr7LF1wbJijEDXw73klYCHwPTjPTx2UuD1WPrkuWZtak zu7Z3sx7pMh4VlF62oG6owQNrvDldhSp5yAirzsCuvRv9Z+Hjyv4S6FF18ZEiPhw9be2 F6lvJL/ZaeTaLM1XXgb6PEgYzrfvR5yW71ptmr4paWRQN1raTUuMvVHtdPAq2h6gb09v BtvJO6kl9/kAQg74t4nZ5zZFTiKo9QZiIRFG7qTlEh6r0A/ZusfJ1CGAuX1fGHTrQQsh GAcg== MIME-Version: 1.0 Received: by 10.112.87.40 with SMTP id u8mr35031305lbz.50.1358172415285; Mon, 14 Jan 2013 06:06:55 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.0.45 with HTTP; Mon, 14 Jan 2013 06:06:55 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Jan 2013 15:06:55 +0100 X-Google-Sender-Auth: NdT9PSUWLw9AOF1jJlBeF9w0lu8 Message-ID: Subject: Re: Hardware VM support for Jails From: CeDeROM To: Mark Felder Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:06:57 -0000 Good to know thank you! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 19:37:14 2013 Return-Path: Delivered-To: freebsd-current@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 5116862E; Mon, 14 Jan 2013 19:37:14 +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 2874B34E; Mon, 14 Jan 2013 19:37:14 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7C0C3B963; Mon, 14 Jan 2013 14:37:10 -0500 (EST) From: John Baldwin To: attilio@freebsd.org Subject: Re: Spurious witness warning when destroying spin mtx Date: Mon, 14 Jan 2013 14:03:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201301141403.45905.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 14:37:13 -0500 (EST) Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:37:14 -0000 On Saturday, November 24, 2012 10:01:39 am Attilio Rao wrote: > On Sat, Nov 24, 2012 at 3:08 AM, Ryan Stone wrote: > > Today I saw a spurious witness warning for "acquiring duplicate lock of > > same type". The root cause is that when running mtx_destroy on a spinlock > > that is held by the current thread, mtx_destroy calls spinlock_exit() > > before calling WITNESS_UNLOCK, which opens up a window in which the CPU can > > be interrupted and attempt to acquire another spinlock of the same type as > > the one being destroyed. This patch should fix it: > > I seriously wonder why right now we don't assume the lock is unheld. > There are likely historically reasons for that, but I would like to > know which one are those and eventually fix them out. > FWIK, all the other locking primitives assume the lock is already > unheld when destroying and I think it would be good to have that for > mutexes as well. That is simply behavior we inherited from BSD/OS. I didn't find it all that useful so all of the other locking primitives I've added since then have not had this behavior. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 21:39:19 2013 Return-Path: Delivered-To: freebsd-current@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 A19CDA29 for ; Mon, 14 Jan 2013 21:39:19 +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 76BEECCA for ; Mon, 14 Jan 2013 21:39:19 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA5D7B945 for ; Mon, 14 Jan 2013 16:39:18 -0500 (EST) From: John Baldwin To: FreeBSD Current Subject: [PATCH] Add rusage reporting to procstat Date: Mon, 14 Jan 2013 16:39:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301141639.17783.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 14 Jan 2013 16:39:18 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:39:19 -0000 This patch adds a new -r flag to dump the resource usage information (what you would get from getrusage() or wait()) for a given process. Sample output: % procstat -r $$ PID COMM TYPE VALUE 1428 tcsh user time 00:00:00.050182 1428 tcsh system time 00:00:00.040145 1428 tcsh maximum RSS 3328 B 1428 tcsh integral shared memory 2844 B 1428 tcsh integral unshared data 6372 B 1428 tcsh integral unshared stack 1152 B 1428 tcsh page reclaims 1306 1428 tcsh page faults 12 1428 tcsh swaps 0 1428 tcsh block reads 50 1428 tcsh block writes 0 1428 tcsh messages sent 172 1428 tcsh messages received 0 1428 tcsh signals received 33 1428 tcsh voluntary context switches 1167 1428 tcsh involuntary context switches 1 http://www.FreeBSD.org/~jhb/patches/procstat_rusage.patch Any thoughts, etc.? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 22:44:51 2013 Return-Path: Delivered-To: freebsd-current@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 2C6B9800; Mon, 14 Jan 2013 22:44:51 +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 C1488C5; Mon, 14 Jan 2013 22:44:50 +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 r0EMignN084485; Tue, 15 Jan 2013 00:44:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0EMignN084485 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0EMig05084484; Tue, 15 Jan 2013 00:44:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jan 2013 00:44:42 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: [PATCH] Add rusage reporting to procstat Message-ID: <20130114224442.GO2561@kib.kiev.ua> References: <201301141639.17783.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PkntWmqUzlIrpeQX" Content-Disposition: inline In-Reply-To: <201301141639.17783.jhb@freebsd.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: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 22:44:51 -0000 --PkntWmqUzlIrpeQX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 14, 2013 at 04:39:17PM -0500, John Baldwin wrote: > This patch adds a new -r flag to dump the resource usage information (wha= t you=20 > would get from getrusage() or wait()) for a given process. Sample output: >=20 > % procstat -r $$ > PID COMM TYPE VALUE =20 > 1428 tcsh user time 00:00:00.050182 =20 > 1428 tcsh system time 00:00:00.040145 =20 > 1428 tcsh maximum RSS 3328 B > 1428 tcsh integral shared memory 2844 B > 1428 tcsh integral unshared data 6372 B > 1428 tcsh integral unshared stack 1152 B > 1428 tcsh page reclaims 1306 =20 > 1428 tcsh page faults 12 =20 > 1428 tcsh swaps 0 =20 > 1428 tcsh block reads 50 =20 > 1428 tcsh block writes 0 =20 > 1428 tcsh messages sent 172 =20 > 1428 tcsh messages received 0 =20 > 1428 tcsh signals received 33 =20 > 1428 tcsh voluntary context switches 1167 =20 > 1428 tcsh involuntary context switches 1 =20 >=20 > http://www.FreeBSD.org/~jhb/patches/procstat_rusage.patch >=20 > Any thoughts, etc.? It looks fine, but use of the human-oriented resource values, together with spaces in names, makes the parsing of the output unfeasible. The patch only reports the process-cumulative rusage, and not the per-thread rusage, it seems. --PkntWmqUzlIrpeQX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9IpZAAoJEJDCuSvBvK1Bl9QP/3Pcudnpcq8tVWNJlf6wGR+o 7lMwcqrpptidDZE/Zx+ooW+Vi19MVISb7eU18Oc1X4IPtmKvoqkDcmFlWnJPcXmX IRYj+Yrh8qzbV2dUiUEZJjHGt9yYxyqGFlQc99DbykoROCUrrXhckPRvr0jBJsqO QHNk8JkA5jzU98poj2IL8DMNSmyRvAsd4oXDCrveHrIZ1pqAZhKc2MXhygI/itgn 0DVOZ5xMSkTcBRy3jmP++sXA335wPhw2P4Y4d5f7bI1CPZP2i/W6utGNDeteUffF orP1OkioRha4qXT1YBNN6kal2SNAI/CRWEBuJ1aeEWniRh/Puej9RkMfMgvyHzqA PaqAZTQEETFgpI29V1wuLniia/bu0UJypTQOU6/B1hzFsRMFyMuFqSnD0u+Ftki4 Xhn7sjyZi5BVRWvR59OcbP/1NxNObfsVgrIljs9MwwLiSpG3RAjjz/Bv42SrJ2Pj eC3HEFaFjvLI+uwOG1DsNYLRFHXLNqD4/5em5b+CMGD82YB4dSPOzmZtTsUPsF4w 0y5EaV68USuvl3No8R9Sqz53wa1SA5d3TMgnrciN+8TPX86PWq1+Tq6a5wrlyGlc P+6hzTOHn+ep9RZC3sAb4hKpFT6zoJnZCeQobPEzYFS43GrmUqRS3YRJ+Zl0V/3k mStmnb8hYw5iWbIVvG7d =zaq+ -----END PGP SIGNATURE----- --PkntWmqUzlIrpeQX-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 14 23:57:10 2013 Return-Path: Delivered-To: freebsd-current@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 CA00B7FD for ; Mon, 14 Jan 2013 23:57:10 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 88F403ED for ; Mon, 14 Jan 2013 23:57:10 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0ENv4m8030036 for ; Mon, 14 Jan 2013 18:57:09 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50F49B50.3080507@m5p.com> Date: Mon, 14 Jan 2013 18:57:04 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: ctfconvert again Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 14 Jan 2013 18:57:09 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:57:10 -0000 So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting past the ctfconvert problem that causes a build of 10-CURRENT to say: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] while compiling every kernel source file. Then I checked out head as of 245422 into a different partition and tried "make buildworld" (ran okay) and "make buildkernel" (failed with the same error as before). Do I have to build an early version of head before I can build the current version of head? -- George Mitchell From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 00:00:49 2013 Return-Path: Delivered-To: freebsd-current@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 D9B7DA87 for ; Tue, 15 Jan 2013 00:00:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6B65267D for ; Tue, 15 Jan 2013 00:00:48 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id gg13so3382541lbb.34 for ; Mon, 14 Jan 2013 16:00:47 -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=bb5Lc91Z2QQwJ3sZ/2CbBUT4HdeYOwSZHhyVXVfwWQY=; b=lhRYJwcq3qGLimfP4WcrbL5fR0PQG2wmAXcISozkQb1Mi2oM9x55XVs848zIFJqPgQ CZGHrrTVRTKoPBilpCBM+kQx7FYXZ4lcrg/O8uqYLH027cjsfGDmC/c6GLj1JkoV8U5X S5HIcGSP9GhhTaRoJ73GWeCJFPAxLIs5qUy8ZCuCxEuoZxH16lKW2Z6q6VQMg1BuvDke yY+f8n674mrE+S8PG8c8izHATX0BGicH6qUq61QyQYg6PXLzpaeGPLmpU/r/9BPaJiit ORRfLPiEa7Osx6ypu3nh3GarO02sbM97WW0HYV5Iv5jpLGilfzykVsCxYHvT0I4I/Ysh 1CRg== MIME-Version: 1.0 Received: by 10.152.45.229 with SMTP id q5mr83420715lam.34.1358208047729; Mon, 14 Jan 2013 16:00:47 -0800 (PST) Received: by 10.114.81.40 with HTTP; Mon, 14 Jan 2013 16:00:47 -0800 (PST) In-Reply-To: <50F49B50.3080507@m5p.com> References: <50F49B50.3080507@m5p.com> Date: Mon, 14 Jan 2013 16:00:47 -0800 Message-ID: Subject: Re: ctfconvert again From: Freddie Cash To: George Mitchell Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:00:49 -0000 The following built without any issues, including GENERIC and a custom kernel. I was pleasantly surprised that it was so easy to update from 9.0-RELEASE to 10.0-CURRENT. I was expecting a lot more manual fiddling and twiddling. [fcash@nexus2 /usr/src]$ uname -a FreeBSD nexus2.sd73.bc.ca 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245195: Thu Jan 10 10:29:16 PST 2013 root@nexus2.sd73.bc.ca:/usr/obj/usr/src/sys/NEXUS i386 [fcash@nexus2 ~]$ cd /usr/src [fcash@nexus2 /usr/src]$ svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245195 Node Kind: directory Schedule: normal Last Changed Author: cognet Last Changed Rev: 245192 Last Changed Date: 2013-01-08 14:55:39 -0800 (Tue, 08 Jan 2013) [fcash@nexus2 /usr/src]$ cat /etc/src.conf # Things to build that may not be built automatically WITH_IDEA=true # Build the 128-bit IDEA cipher support WITH_OPENSSH_NONE_CIPHER=true # Enable the "none" cipher in base OpenSSH # Things to not build WITHOUT_ATM=true # Don't build Asynchronous Transfer Mode support WITHOUT_BLUETOOTH=true # Don't build Bluetooth support WITHOUT_CALENDAR=true # Don't build calendar(1) WITHOUT_CTM=true # Don't build CVS-to-mail programs WITHOUT_CVS=true # Don't build cvs(1) and related tools WITHOUT_GAMES=true # Don't build the BSD games WITHOUT_HTML=true # Don't build the HTML docs WITHOUT_I4B=true # Don't build ISDB support WITHOUT_INET6=true # Don't build IPv6 support WITHOUT_INET6_SUPPORT=true # Don't build any of the other IPv6-related bits WITHOUT_IPFILTER=true # Don't build the old IPFilter packet filter WITHOUT_IPX=true # Don't build IPX protocol support WITHOUT_IPX_SUPPORT=true # Don't build any of the other IPX-related bits WITHOUT_LIBKSE=true # Don't build the old M:N threading support WITHOUT_NCP=true # Don't build Netware Control Protocol support WITHOUT_PPP=true # Don't build PPP support WITHOUT_PROFILE=true # Don't build profiled libraries WITHOUT_RCS=true # Don't build rcs(1) and related tools WITHOUT_SYSINSTALL=true # Don't build sysinstall(8) and related tools WITHOUT_WIRELESS=true # Don't build 802.11-related wireless tools WITHOUT_WIRELESS_SUPPORT=true # Don't build support tools for wireless [fcash@nexus2 /usr/src]$ cat /etc/make.conf # $FreeBSD: src/share/examples/etc/make.conf,v 1.265.2.8 2006/09/13 08:39:16 des Exp $ CPUTYPE?= opteron KERNCONF?= NEXUS GENERIC # Things to disable NO_DOCUPDATE=true NO_PORTSUPDATE=true NO_WWWUPDATE=true # Things to enable SVN_UPDATE=true # Use svn(1) to update /usr/src #BOOT_COMCONSOLE_PORT # (str) The port address to use for the console if the boot # blocks have been configured to use a serial console instead # of the keyboard/video card. # # BOOT_COMCONSOLE_SPEED # (int) The baud rate to use for the console if the boot # blocks have been configured to use a serial console instead # of the keyboard/video card. MALLOC_PRODUCTION=true # Documentation # The list of languages and encodings to build and install DOC_LANG= en_US.ISO8859-1 # Global Port Options WITHOUT_GUI= yes WITHOUT_X11= yes WITHOUT_GNOME= yes WITHOUT_IPV6= yes WITHOUT_INET6= yes # added by use.perl 2013-01-11 09:09:08 PERL_VERSION=5.16.2 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 00:20:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 280502E0 for ; Tue, 15 Jan 2013 00:20:42 +0000 (UTC) (envelope-from prvs=172763643c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A418D75D for ; Tue, 15 Jan 2013 00:20:41 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001710927.msg for ; Tue, 15 Jan 2013 00:20:38 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 15 Jan 2013 00:20:38 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=172763643c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <38C9A294A26F4B3CACC0191DEE722B21@multiplay.co.uk> From: "Steven Hartland" To: "George Mitchell" , References: <50F49B50.3080507@m5p.com> Subject: Re: ctfconvert again Date: Tue, 15 Jan 2013 00:21:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:20:42 -0000 ----- Original Message ----- From: "George Mitchell" To: Sent: Monday, January 14, 2013 11:57 PM Subject: ctfconvert again > So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting > past the ctfconvert problem that causes a build of 10-CURRENT to say: > > ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at > [dwarf_init_attr(400)] > > while compiling every kernel source file. Then I checked out head as > of 245422 into a different partition and tried "make buildworld" (ran > okay) and "make buildkernel" (failed with the same error as before). > > Do I have to build an early version of head before I can build the > current version of head? -- George Mitchell I believe the location of ctfconvert which is used is broken so unless your system has a version of ctfconvert which includes the attr fix you will always get this :( The reason I believe this is:- make buildenv Entering world for amd64:amd64 # which ctfconvert /usr/bin/ctfconvert # which cc /usr/obj/usr/home/smh/freebsd/base/head/tmp/usr/bin/cc So where I believe ctfconvert should be being picked up from the toolchain its not. I've had a quick dig in the Makefile's but I don't know them well at all and so couldn't find an easy fix :( The workaround I'm using is: make -DNO_CTF buildkernel If someone who better knows the make system could suggest a patch so that ctfconvert (and potentially other tools) are build and detected in the toolchain that would be most appreciated. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 00:12:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DA42F3B for ; Tue, 15 Jan 2013 00:12:34 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id C20D46FE for ; Tue, 15 Jan 2013 00:12:33 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0F0CSpH030188 for ; Mon, 14 Jan 2013 19:12:33 -0500 (EST) (envelope-from george@m5p.com) Message-ID: <50F49EEC.7010503@m5p.com> Date: Mon, 14 Jan 2013 19:12:28 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ctfconvert again References: <50F49B50.3080507@m5p.com> In-Reply-To: <50F49B50.3080507@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 14 Jan 2013 19:12:33 -0500 (EST) X-Mailman-Approved-At: Tue, 15 Jan 2013 00:21:00 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:12:34 -0000 On 01/14/13 18:57, George Mitchell wrote: > So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting > past the ctfconvert problem that causes a build of 10-CURRENT to say: > > ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at > [dwarf_init_attr(400)] > > while compiling every kernel source file. Then I checked out head as > of 245422 into a different partition and tried "make buildworld" (ran > okay) and "make buildkernel" (failed with the same error as before). I should mention this is an amd64 build, in case that matters. > > Do I have to build an early version of head before I can build the > current version of head? -- George Mitchell > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 00:23:48 2013 Return-Path: Delivered-To: freebsd-current@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 6DFE15A0 for ; Tue, 15 Jan 2013 00:23:48 +0000 (UTC) (envelope-from prvs=172763643c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 140E1798 for ; Tue, 15 Jan 2013 00:23:47 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001710961.msg for ; Tue, 15 Jan 2013 00:23:46 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 15 Jan 2013 00:23:46 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=172763643c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <84ADA364C97442B0BF06DB0BE4E6799C@multiplay.co.uk> From: "Steven Hartland" To: "Freddie Cash" , "George Mitchell" References: <50F49B50.3080507@m5p.com> Subject: Re: ctfconvert again Date: Tue, 15 Jan 2013 00:24:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: FreeBSD-Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:23:48 -0000 ----- Original Message ----- From: "Freddie Cash" > The following built without any issues, including GENERIC and a custom > kernel. I was pleasantly surprised that it was so easy to update from > 9.0-RELEASE to 10.0-CURRENT. I was expecting a lot more manual fiddling > and twiddling. To be clear it builds fine it just moans about "Unimplemented code at [dwarf_init_attr(400)]" LOTS. So its not that the build fails but that you get lots of invalid "warnings" which make it very difficult to see any valid warnings, cant see the wood for the trees :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 01:08:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0870C204 for ; Tue, 15 Jan 2013 01:08:59 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 9C664950 for ; Tue, 15 Jan 2013 01:08:58 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0F18qa2030656; Mon, 14 Jan 2013 20:08:57 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50F4AC24.7060401@m5p.com> Date: Mon, 14 Jan 2013 20:08:52 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: Steven Hartland Subject: Re: ctfconvert again References: <50F49B50.3080507@m5p.com> <38C9A294A26F4B3CACC0191DEE722B21@multiplay.co.uk> In-Reply-To: <38C9A294A26F4B3CACC0191DEE722B21@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 14 Jan 2013 20:08:58 -0500 (EST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:08:59 -0000 On 01/14/13 19:21, Steven Hartland wrote: > > ----- Original Message ----- From: "George Mitchell" > > To: > Sent: Monday, January 14, 2013 11:57 PM > Subject: ctfconvert again > > >> So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting >> past the ctfconvert problem that causes a build of 10-CURRENT to say: >> >> ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at >> [dwarf_init_attr(400)] >> >> while compiling every kernel source file. Then I checked out head as >> of 245422 into a different partition and tried "make buildworld" (ran >> okay) and "make buildkernel" (failed with the same error as before). >> >> Do I have to build an early version of head before I can build the >> current version of head? -- George Mitchell > > I believe the location of ctfconvert which is used is broken so unless > your system has a version of ctfconvert which includes the attr fix > you will always get this :( > > The reason I believe this is:- > make buildenv > Entering world for amd64:amd64 > # which ctfconvert > /usr/bin/ctfconvert > # which cc > /usr/obj/usr/home/smh/freebsd/base/head/tmp/usr/bin/cc > > So where I believe ctfconvert should be being picked up from the > toolchain its not. > > I've had a quick dig in the Makefile's but I don't know them well at > all and so couldn't find an easy fix :( > > The workaround I'm using is: > make -DNO_CTF buildkernel Works like a charm; thanks! -- George Mitchell > > If someone who better knows the make system could suggest a patch > so that ctfconvert (and potentially other tools) are build and > detected in the toolchain that would be most appreciated. > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing > or otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 02:48:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05F307B9; Tue, 15 Jan 2013 02:48:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id D5477D95; Tue, 15 Jan 2013 02:48:15 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id xa7so2566600pbc.28 for ; Mon, 14 Jan 2013 18:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=hk+6J0wzVLC2hcsJk8YkRKvbWYp6j9YR8CoVDV+3ZqQ=; b=Bvw/Vc6KfGIbnybxNM/tKHTW2ztyBLtdLNP7NguaYQUFShyEgY09xedXOCXC4AlyK0 BrjKsPfIU5CKaDfA8G49mrJemkpLcjwTNAjATBeUcoXAeEnIRqXNJh/7zedH4ahzsR7H 6BHWJtmor4fVo4g1qXBMDBani0yX2tfLp8NjjM2cuo2Dly855IC8YURsXpjW7BJTvhBF tl3dgbqizWud6a10R2sOSQ7H80YENnhm1JelLKo5dBkHyoI2rbOfEVa1PaPhtyxTnIJQ i0dTQF8/Ia7FPyPibinCKkzcBHvrK8QxcIdfP5iPbS59LhSp1Ufns7UdG15vkhy3lTog vhog== X-Received: by 10.66.88.37 with SMTP id bd5mr237623993pab.75.1358218095370; Mon, 14 Jan 2013 18:48:15 -0800 (PST) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPS id oj5sm9265802pbb.47.2013.01.14.18.48.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 18:48:14 -0800 (PST) From: Garrett Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: ktrace -d broken on current/stable-9 Date: Mon, 14 Jan 2013 18:48:13 -0800 Message-Id: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> To: FreeBSD Current Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: kib@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:48:16 -0000 I tried using ktrace on a kernel compiled a week ago, and it = appears to not be following forks like it should on amd64: # ktrace -d ./regress -l rename_file move_files_into_dir move_file_from_dir_to_file = move_file_from_dir_to_existing_file move_file_from_dir_to_existing_dir = move_file_from_dir_to_dir rename_dir move_dir_to_dir_name = move_dir_to_dir move_file_from_dir_to_empty_dir = move_file_from_dir_to_nonempty_dir move_dir_to_existing_file = move_file_from_dir_to_dir move_file_from_dir_to_dir = move_file_from_dir_to_dir move_fifo_from_dir_to_dir rename_file move_files_into_dir move_file_from_dir_to_file = move_file_from_dir_to_existing_file move_file_from_dir_to_existing_dir = move_file_from_dir_to_dir rename_dir move_dir_to_dir_name = move_dir_to_dir move_file_from_dir_to_empty_dir = move_file_from_dir_to_nonempty_dir move_dir_to_existing_file = move_file_from_dir_to_dir move_file_from_dir_to_dir = move_file_from_dir_to_dir move_fifo_from_dir_to_dir = rename_file_cross_device move_files_into_dir_cross_device = move_file_from_dir_to_file_cross_device = move_file_from_dir_to_existing_file_cross_device = move_file_from_dir_to_existing_dir_cross_device = move_file_from_dir_to_dir_cross_device rename_dir_cross_device = move_dir_to_dir_name_cross_device move_dir_to_dir_cross_device = move_file_from_dir_to_empty_dir_cross_device = move_file_from_dir_to_nonempty_dir_cross_device = move_dir_to_existing_file_cross_device = move_file_from_dir_to_dir_cross_device = move_file_from_dir_to_dir_cross_device = move_file_from_dir_to_dir_cross_device = move_fifo_from_dir_to_dir_cross_device Content-Type: application/X-atf-tp; version=3D"1" ident: rename_file descr: Rename file ident: move_files_into_dir descr: Move files into directory Executing command [ mv 1/2/3/fa fb ] # uname -a FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #2 = r+73182f4: Sun Jan 6 13:41:52 PST 2013 = root@fuji-current.local:/usr/obj/usr/src/sys/FUJI i386 # kdump | awk '$1 ~ /25/' | sort -u -k 1 -n 25195 ktrace RET ktrace 0 Not sure how it broke, but it was working a couple months ago = (in particular I remember it working either around October or November), = and the bug seems to have worked its way back to 9-STABLE (I'm running = into the same problem if I do ktrace -d, enter a shell, then exec = another shell from that shell). Haven't spent the time to bisect the = commits looking for the culprit (yet), but if need be I'll trace down = the culprit sometime this week. truss works, so it doesn't seem like ptrace(2) is broken. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 03:39:18 2013 Return-Path: Delivered-To: freebsd-current@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 B0368B48; Tue, 15 Jan 2013 03:39:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7F590147; Tue, 15 Jan 2013 03:39:18 +0000 (UTC) Received: by mail-da0-f53.google.com with SMTP id x6so2063928dac.40 for ; Mon, 14 Jan 2013 19:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Id7UE1ITSKHw89dm8WJ7m3ziLLnkPVJmID/UU1Zuis4=; b=zSnSXjN2RGqFtF1sUplPdRyz/RQkACXoaRzbtww5yf3WWmI/FgOkAG4jgcoM9U3/jq EpI6v43gSwcNxQlYVc0SCFQK1dplA/vQXcOyRq+RTeOzlJczvvvE+mNOiDrUu8EpdEUw 4xIPmNRNr1DUcJXZ4TEKn6kokN4OwZoGFUu25HEoLuAKnkBSnTMSjNCyJpindKxSWne9 T9nBOhj+XSRoP+8ZOAYybnDyjW/GXTdbG/5OeppuCbcIiBeBN/cwJsBkhmPQc4HbUH+X NKy8+USe/0z6Y6K5eh2hrdLz8bRiYm5UMx+tJUuVCtZ09qfFV5MlKDDFLbtumSjNnAW/ 2wng== X-Received: by 10.68.132.98 with SMTP id ot2mr260119096pbb.39.1358221158096; Mon, 14 Jan 2013 19:39:18 -0800 (PST) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPS id rv8sm1479553pbc.27.2013.01.14.19.39.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 19:39:17 -0800 (PST) Subject: Re: ktrace -d broken on current/stable-9 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> Date: Mon, 14 Jan 2013 19:39:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4099FD6F-1F1B-481F-ABE7-F710551768CE@gmail.com> References: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1283) Cc: kib@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 03:39:18 -0000 BTW, the brokenness can be seen in the fact that the PID does = not change across execs, but it seems to affect output as well as I was = not able to see syscall output from write when it printed out = "Executing" as shown in the snippet below. Thanks, -Garrett On Jan 14, 2013, at 6:48 PM, Garrett Cooper wrote: > I tried using ktrace on a kernel compiled a week ago, and it = appears to not be following forks like it should on amd64: >=20 > # ktrace -d ./regress -l > rename_file move_files_into_dir move_file_from_dir_to_file = move_file_from_dir_to_existing_file move_file_from_dir_to_existing_dir = move_file_from_dir_to_dir rename_dir move_dir_to_dir_name = move_dir_to_dir move_file_from_dir_to_empty_dir = move_file_from_dir_to_nonempty_dir move_dir_to_existing_file = move_file_from_dir_to_dir move_file_from_dir_to_dir = move_file_from_dir_to_dir move_fifo_from_dir_to_dir > rename_file move_files_into_dir move_file_from_dir_to_file = move_file_from_dir_to_existing_file move_file_from_dir_to_existing_dir = move_file_from_dir_to_dir rename_dir move_dir_to_dir_name = move_dir_to_dir move_file_from_dir_to_empty_dir = move_file_from_dir_to_nonempty_dir move_dir_to_existing_file = move_file_from_dir_to_dir move_file_from_dir_to_dir = move_file_from_dir_to_dir move_fifo_from_dir_to_dir = rename_file_cross_device move_files_into_dir_cross_device = move_file_from_dir_to_file_cross_device = move_file_from_dir_to_existing_file_cross_device = move_file_from_dir_to_existing_dir_cross_device = move_file_from_dir_to_dir_cross_device rename_dir_cross_device = move_dir_to_dir_name_cross_device move_dir_to_dir_cross_device = move_file_from_dir_to_empty_dir_cross_device = move_file_from_dir_to_nonempty_dir_cross_device = move_dir_to_existing_file_cross_device = move_file_from_dir_to_dir_cross_device = move_file_from_dir_to_dir_cross_device = move_file_from_dir_to_dir_cross_device = move_fifo_from_dir_to_dir_cross_device > Content-Type: application/X-atf-tp; version=3D"1" >=20 > ident: rename_file > descr: Rename file >=20 > ident: move_files_into_dir > descr: Move files into directory >=20 > Executing command [ mv 1/2/3/fa fb ] >=20 > # uname -a > FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #2 = r+73182f4: Sun Jan 6 13:41:52 PST 2013 = root@fuji-current.local:/usr/obj/usr/src/sys/FUJI i386 > # kdump | awk '$1 ~ /25/' | sort -u -k 1 -n > 25195 ktrace RET ktrace 0 >=20 > Not sure how it broke, but it was working a couple months ago = (in particular I remember it working either around October or November), = and the bug seems to have worked its way back to 9-STABLE (I'm running = into the same problem if I do ktrace -d, enter a shell, then exec = another shell from that shell). Haven't spent the time to bisect the = commits looking for the culprit (yet), but if need be I'll trace down = the culprit sometime this week. > truss works, so it doesn't seem like ptrace(2) is broken. > Thanks, > -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 03:56:46 2013 Return-Path: Delivered-To: freebsd-current@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 EB1C72F9 for ; Tue, 15 Jan 2013 03:56:46 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm5-vm1.bullet.mail.gq1.yahoo.com (nm5-vm1.bullet.mail.gq1.yahoo.com [98.136.218.176]) by mx1.freebsd.org (Postfix) with SMTP id A4DF1246 for ; Tue, 15 Jan 2013 03:56:46 +0000 (UTC) Received: from [98.137.12.63] by nm5.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jan 2013 03:53:19 -0000 Received: from [208.71.42.201] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jan 2013 03:53:19 -0000 Received: from [127.0.0.1] by smtp212.mail.gq1.yahoo.com with NNFMP; 15 Jan 2013 03:53:19 -0000 X-Yahoo-Newman-Id: 455041.25537.bm@smtp212.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AeGihoUVM1m9PmWPQ2uUpT_vl13EHV1ykiE5LPMa3DVCxSd .7_p4d084u0ltVHsgGX8TkaaXqmArypCv6nc8FAFd9yUqedEmqS3w2L1d6LJ i0sXyMBn0hxbdvO6LYXljT_8TfeKg7I0coGJgypCPip.NQtXfxowBNhJU8HI AjsttW10nhnTJ0sNhvRFbxsgwxOdldMAndf0MJisc5NOIPO531wKsa_yQwc6 FU2YwPof9w0Jvh.J4t2YR3qVKyd2cARJ4awuwIjbjEbHvmGmY2.6dJMVQGLM 7XxJBZ2WzToTzQI2m6wuO6kot43M.bRgoqisOnsc4jLw8o0bvwC6yZPpqD4G YxIy40JGtddojVNYU8bknZ0re9MAb1QqXIX8HGt5qgz1is.JTDwGB8ruIvgB 3ymDog8ATKBi2pVzNfc47saNhiGNKp4OFw8k3Q3RWhAVEJu5fTX9B9bfG92n gXfDtUqL0CzcSV6xOIogkdB6jkJiysR4BB56lMzeBInVwZQwdMYWEnPjymAI iXY4SnuvQNi.T3kY_bq9YuoRhoNQCcJWO7r7d00mXZQJnC6hPdCE0IatPBuN 4b_sji99iHRNVhWyKIT03IQTLWevutiXT1zTjKE0- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.101] (pfg@200.118.157.7 with plain) by smtp212.mail.gq1.yahoo.com with SMTP; 14 Jan 2013 19:53:19 -0800 PST Message-ID: <50F4D2AF.2020700@FreeBSD.org> Date: Mon, 14 Jan 2013 22:53:19 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: ctfconvert again Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 03:56:47 -0000 > So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting > past the ctfconvert problem that causes a build of 10-CURRENT to say: > > ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at > [dwarf_init_attr(400)] > > while compiling every kernel source file. Then I checked out head as > of 245422 into a different partition and tried "make buildworld" (ran > okay) and "make buildkernel" (failed with the same error as before). > > Do I have to build an early version of head before I can build the > current version of head? -- George Mitchell > FWIW; While looking at NetBSD's Dtrace enhancements I found that this is caused[1] by a known bug in gcc. It was fixed in our base gcc recently and MFC'd. Last time I looked, upstream gcc hasn't fixed it, and I am trying to get the illumos guys to review the NetBSD workaround before we adopt it. cheers, Pedro. [1] https://github.com/jsonn/src/commit/924b243eee68869ee5ed48f2b2fab9815c4f4e82 From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 07:53:57 2013 Return-Path: Delivered-To: freebsd-current@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 3A6BE7A9 for ; Tue, 15 Jan 2013 07:53:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 048A9222 for ; Tue, 15 Jan 2013 07:53:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9] (unknown [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 590635C37; Tue, 15 Jan 2013 08:53:56 +0100 (CET) Message-ID: <50F50B14.5090102@FreeBSD.org> Date: Tue, 15 Jan 2013 08:53:56 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: George Mitchell Subject: Re: ctfconvert again References: <50F49B50.3080507@m5p.com> In-Reply-To: <50F49B50.3080507@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:53:57 -0000 On 2013-01-15 00:57, George Mitchell wrote: > So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting > past the ctfconvert problem that causes a build of 10-CURRENT to say: > > ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at > [dwarf_init_attr(400)] > > while compiling every kernel source file. Then I checked out head as > of 245422 into a different partition and tried "make buildworld" (ran > okay) and "make buildkernel" (failed with the same error as before). This is because clang outputs dwarf attributes which libdwarf did not understand before r239872. However, that fix to libdwarf did not make it into 9.1-RELEASE, unfortunately. To fix it locally, you can apply r239872 to your local source tree, and then rebuild and reinstall libdwarf. The proper solution would be to make ctfconvert a bootstrap tool for the kernel build, but it is more complicated... From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 07:58:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFD64993; Tue, 15 Jan 2013 07:58:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADE7325D; Tue, 15 Jan 2013 07:58:30 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9] (unknown [IPv6:2001:7b8:3a7:0:d8d8:1399:7768:60b9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 135395C44; Tue, 15 Jan 2013 08:58:30 +0100 (CET) Message-ID: <50F50C25.5090308@FreeBSD.org> Date: Tue, 15 Jan 2013 08:58:29 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Pedro Giffuni Subject: Re: ctfconvert again References: <50F4D2AF.2020700@FreeBSD.org> In-Reply-To: <50F4D2AF.2020700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:58:31 -0000 On 2013-01-15 04:53, Pedro Giffuni wrote: >> So I updated my FreeBSD machine to 9.1-RELEASE in the hope of getting >> past the ctfconvert problem that causes a build of 10-CURRENT to say: >> >> ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at >> [dwarf_init_attr(400)] >> >> while compiling every kernel source file. Then I checked out head as >> of 245422 into a different partition and tried "make buildworld" (ran >> okay) and "make buildkernel" (failed with the same error as before). >> >> Do I have to build an early version of head before I can build the >> current version of head? -- George Mitchell >> > FWIW; > > While looking at NetBSD's Dtrace enhancements I found that > this is caused[1] by a known bug in gcc. It was fixed in our base gcc > recently and MFC'd. > > Last time I looked, upstream gcc hasn't fixed it, and I am trying > to get the illumos guys to review the NetBSD workaround before > we adopt it. No, this is most likely not a gcc issue. I am fairly certain it is fixed by commit r239872 to libdwarf, but as I noted in another reply, this fix did not make it into 9.1-RELEASE. From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 13:43:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00F6FE5D; Tue, 15 Jan 2013 13:42:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id AB67B903; Tue, 15 Jan 2013 13:42:59 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Tv6rX-00027W-HD; Tue, 15 Jan 2013 17:47:35 +0400 Date: Tue, 15 Jan 2013 17:47:35 +0400 From: Slawa Olhovchenkov To: John Baldwin Subject: Re: [PATCH] Add rusage reporting to procstat Message-ID: <20130115134735.GA7708@zxy.spb.ru> References: <201301141639.17783.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301141639.17783.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:43:00 -0000 On Mon, Jan 14, 2013 at 04:39:17PM -0500, John Baldwin wrote: > This patch adds a new -r flag to dump the resource usage information (what you > would get from getrusage() or wait()) for a given process. Sample output: > > % procstat -r $$ > PID COMM TYPE VALUE > 1428 tcsh user time 00:00:00.050182 > 1428 tcsh system time 00:00:00.040145 > 1428 tcsh maximum RSS 3328 B maximum RSS -- 3328 _bytes_? You kidding. > 1428 tcsh integral shared memory 2844 B > 1428 tcsh integral unshared data 6372 B > 1428 tcsh integral unshared stack 1152 B > 1428 tcsh page reclaims 1306 > 1428 tcsh page faults 12 > 1428 tcsh swaps 0 > 1428 tcsh block reads 50 > 1428 tcsh block writes 0 > 1428 tcsh messages sent 172 > 1428 tcsh messages received 0 > 1428 tcsh signals received 33 > 1428 tcsh voluntary context switches 1167 > 1428 tcsh involuntary context switches 1 > > http://www.FreeBSD.org/~jhb/patches/procstat_rusage.patch > > Any thoughts, etc.? > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 13:56:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D5CE3D9; Tue, 15 Jan 2013 13:56:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD1DC99D; Tue, 15 Jan 2013 13:56:19 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Tv74T-0002Bc-8c; Tue, 15 Jan 2013 18:00:57 +0400 Date: Tue, 15 Jan 2013 18:00:57 +0400 From: Slawa Olhovchenkov To: David Chisnall Subject: Re: [PATCH] Add rusage reporting to procstat Message-ID: <20130115140057.GA67643@zxy.spb.ru> References: <201301141639.17783.jhb@freebsd.org> <20130115134735.GA7708@zxy.spb.ru> <8815BAF7-3B4C-4EBD-A332-AF58BE644DDF@theravensnest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8815BAF7-3B4C-4EBD-A332-AF58BE644DDF@theravensnest.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:56:20 -0000 On Tue, Jan 15, 2013 at 01:49:01PM +0000, David Chisnall wrote: > On 15 Jan 2013, at 13:47, Slawa Olhovchenkov wrote: > > > maximum RSS -- 3328 _bytes_? You kidding. > > I think this is a bug in our getrusage. I've seen similar (<4KB) > things in a program that mmap()s 12KB of input, allocates a load of > heap memory for metadata, uses a bunch of stack, and then exits. > I find it is quite odd that the figure isn't a multiple of the page > size, because the resident set can't be anything other than an > integer number of pages.. man getrusage ru_maxrss the maximum resident set size utilized (in kilobytes). Dimensions of the other fields may be also wrong. From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 15:52:35 2013 Return-Path: Delivered-To: freebsd-current@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 36286D6B; Tue, 15 Jan 2013 15:52:35 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id A5130174; Tue, 15 Jan 2013 15:52:34 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id d17so134401eek.10 for ; Tue, 15 Jan 2013 07:52:33 -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=DL873V5Db53Zs/0T0tfxHx4YQVjfcll3bEbGPHabpPE=; b=Mzdq5YWuCgQK3k9Uc0Fh6wfmzGRnQD+YJvvy/fKDJAU1AFu1vlcF5GpRGv8irGketx zq7piFRWC30jNobjv/cHs20H18NCCBRA//K3OklgONUhYZoyK5t4w5RaHooD8ZvGFwnt dVA2403dZbeSxSklnl2d4ey7Rq8cBe7WMPW81vpoKHdNIjKCBkey27UKnWPpdHE/fTqq rxIFLPPG6Ny7JeHeCSfdhyN1sDNbMwknLeoMSP1O7iLDOWPUQxdGNV/soDmiqVmKbrBp YOFRyUJ/V1HBREKN9KR3a7JziOR1doqps2bQc9xR69NJ19POmSDQKhqxHnv1p5Ix0g+6 i54w== MIME-Version: 1.0 Received: by 10.14.174.198 with SMTP id x46mr242696104eel.23.1358265153597; Tue, 15 Jan 2013 07:52:33 -0800 (PST) Received: by 10.14.221.132 with HTTP; Tue, 15 Jan 2013 07:52:33 -0800 (PST) Received: by 10.14.221.132 with HTTP; Tue, 15 Jan 2013 07:52:33 -0800 (PST) Date: Tue, 15 Jan 2013 07:52:33 -0800 Message-ID: Subject: Clang warning patches From: hiren panchasara To: freebsd-current , sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:52:35 -0000 Hi Sean, These are a few more patches. Mainly in src/sys/dev/ Thanks in advance! Hiren http://www.strugglingcoder.info/patches/clang_warnings_dev_acpi_support.txt http://www.strugglingcoder.info/patches/clang_warnings_dev_ata.txt http://www.strugglingcoder.info/patches/clang_warnings_dev_bktr.txt http://www.strugglingcoder.info/patches/clang_warnings_dev_bwn.txt http://www.strugglingcoder.info/patches/clang_warnings_dev_drm.txt From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 20:27:59 2013 Return-Path: Delivered-To: freebsd-current@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 92AF78D6 for ; Tue, 15 Jan 2013 20:27:59 +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 71E47646 for ; Tue, 15 Jan 2013 20:27:59 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C7ED5B953; Tue, 15 Jan 2013 15:27:58 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: [PATCH] Add rusage reporting to procstat Date: Tue, 15 Jan 2013 14:50:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301141639.17783.jhb@freebsd.org> <20130114224442.GO2561@kib.kiev.ua> In-Reply-To: <20130114224442.GO2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301151450.26985.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jan 2013 15:27:58 -0500 (EST) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:27:59 -0000 On Monday, January 14, 2013 5:44:42 pm Konstantin Belousov wrote: > On Mon, Jan 14, 2013 at 04:39:17PM -0500, John Baldwin wrote: > > This patch adds a new -r flag to dump the resource usage information (what you > > would get from getrusage() or wait()) for a given process. Sample output: > > > > % procstat -r $$ > > PID COMM TYPE VALUE > > 1428 tcsh user time 00:00:00.050182 > > 1428 tcsh system time 00:00:00.040145 > > 1428 tcsh maximum RSS 3328 B > > 1428 tcsh integral shared memory 2844 B > > 1428 tcsh integral unshared data 6372 B > > 1428 tcsh integral unshared stack 1152 B > > 1428 tcsh page reclaims 1306 > > 1428 tcsh page faults 12 > > 1428 tcsh swaps 0 > > 1428 tcsh block reads 50 > > 1428 tcsh block writes 0 > > 1428 tcsh messages sent 172 > > 1428 tcsh messages received 0 > > 1428 tcsh signals received 33 > > 1428 tcsh voluntary context switches 1167 > > 1428 tcsh involuntary context switches 1 > > > > http://www.FreeBSD.org/~jhb/patches/procstat_rusage.patch > > > > Any thoughts, etc.? > > It looks fine, but use of the human-oriented resource values, together > with spaces in names, makes the parsing of the output unfeasible. Yes, but that is par for the course with procstat. If we wanted to add a global flag to request machine-readable output and update the various procstat backends to honor it, I think that would be a great project. > The patch only reports the process-cumulative rusage, and not the per-thread > rusage, it seems. Yes, this is true. It operates on the process-wide kinfo that procstat has handy. It would not be too hard to add a thread mode (-H flag perhaps?) to have it request the kinfo_proc structures for all threads and then output those separately. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 22:53:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72E6236A; Tue, 15 Jan 2013 22:53:09 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 21BFFF3D; Tue, 15 Jan 2013 22:53:09 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D28243592EB; Tue, 15 Jan 2013 23:53:05 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id AEB042848C; Tue, 15 Jan 2013 23:53:05 +0100 (CET) Date: Tue, 15 Jan 2013 23:53:05 +0100 From: Jilles Tjoelker To: Garrett Cooper Subject: Re: ktrace -d broken on current/stable-9 Message-ID: <20130115225305.GA12294@stack.nl> References: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current , kib@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:53:09 -0000 On Mon, Jan 14, 2013 at 06:48:13PM -0800, Garrett Cooper wrote: > I tried using ktrace on a kernel compiled a week ago, and it appears > to not be following forks like it should on amd64: > # ktrace -d ./regress -l > [snip] > Not sure how it broke, but it was working a couple months ago (in > particular I remember it working either around October or November), > and the bug seems to have worked its way back to 9-STABLE (I'm running > into the same problem if I do ktrace -d, enter a shell, then exec > another shell from that shell). Haven't spent the time to bisect the > commits looking for the culprit (yet), but if need be I'll trace down > the culprit sometime this week. > truss works, so it doesn't seem like ptrace(2) is broken. ktrace -d is not really useful in the synopsis with a command. It only means that the child processes of ktrace (at a time just before it executes the utility) should be traced as well. This is almost always an empty set, unless you do things like cmd1 & ktrace -d cmd2 which will trace cmd2 and part of cmd1. You probably want ktrace -i. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 23:10:51 2013 Return-Path: Delivered-To: freebsd-current@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 877EECFA; Tue, 15 Jan 2013 23:10:51 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5D08C10A; Tue, 15 Jan 2013 23:10:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0FNAmTR047279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 15:10:48 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0FNAlC9047278; Tue, 15 Jan 2013 15:10:47 -0800 (PST) (envelope-from jmg) Date: Tue, 15 Jan 2013 15:10:47 -0800 From: John-Mark Gurney To: hiren panchasara Subject: Re: Clang warning patches Message-ID: <20130115231047.GD1410@funkthat.com> Mail-Followup-To: hiren panchasara , freebsd-current , sbruno@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 15 Jan 2013 15:10:48 -0800 (PST) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:10:51 -0000 hiren panchasara wrote this message on Tue, Jan 15, 2013 at 07:52 -0800: > http://www.strugglingcoder.info/patches/clang_warnings_dev_bktr.txt This patch does not look correct at all... It is simply removing code.. How is is good that after we failed to set the tv_freq that we continue on? What is the warning that we are fixing here? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 23:22:17 2013 Return-Path: Delivered-To: freebsd-current@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 88548FD9; Tue, 15 Jan 2013 23:22:17 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 61C101DD; Tue, 15 Jan 2013 23:22:17 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0FNMGGs047429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 15:22:16 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0FNMGgS047428; Tue, 15 Jan 2013 15:22:16 -0800 (PST) (envelope-from jmg) Date: Tue, 15 Jan 2013 15:22:16 -0800 From: John-Mark Gurney To: hiren panchasara , freebsd-current , sbruno@freebsd.org Subject: Re: Clang warning patches Message-ID: <20130115232216.GE1410@funkthat.com> Mail-Followup-To: hiren panchasara , freebsd-current , sbruno@freebsd.org References: <20130115231047.GD1410@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130115231047.GD1410@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 15 Jan 2013 15:22:16 -0800 (PST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:22:17 -0000 John-Mark Gurney wrote this message on Tue, Jan 15, 2013 at 15:10 -0800: > hiren panchasara wrote this message on Tue, Jan 15, 2013 at 07:52 -0800: > > http://www.strugglingcoder.info/patches/clang_warnings_dev_bktr.txt > > This patch does not look correct at all... It is simply removing code.. > > How is is good that after we failed to set the tv_freq that we continue > on? > > What is the warning that we are fixing here? I forgot to look at the intermediate variable that tv_channel was being assigned to... Turns out it's an unsigned int, while tv_channel is returning an int... We should fix this properly by changing temp to be an int, or moving the check inline instead of removing it blindly... I think I still have an old bktr card that I can throw in to do some basic testing... After doing some code sperlunking, looks like this bug was introduced w/ the original driver 15 years ago... And no one noticed even after moving the code around a few times... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 23:35:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3F52F631 for ; Tue, 15 Jan 2013 23:35:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 29F3A2B7 for ; Tue, 15 Jan 2013 23:35:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r0FNZPq2018503 for ; Tue, 15 Jan 2013 15:35:25 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r0FNZP0A018502 for freebsd-current@freebsd.org; Tue, 15 Jan 2013 15:35:25 -0800 (PST) (envelope-from sgk) Date: Tue, 15 Jan 2013 15:35:25 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Missing compile_et and kerberos breaks buildworld Message-ID: <20130115233525.GA18192@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:35:31 -0000 It seems that buildworld depends on the existence of /usr/bin/compile_et if one wants to build WITH_KERBEROS on a system that has never had Kerberos support. I discovered this issue when des@ removed the NOFOO and NO_FOO options, and the NO_KERBEROS="YES" in my /etc/make.conf was neutered. The system in question has never had kerneros installed. One can emulate the problem as follows: % mv /usr/bin/compile_et /usr/bin/compile_et.old % cd /usr/src % make buildworld (a few hours later ... boom) ===> kerberos5/lib/libasn1 (buildincludes) compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et: No such file or directory *** [asn1_err.h] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5/lib. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5. *** [includes] Error code 1 Stop in /usr/src/kerberos5. *** [kerberos5.includes__D] Error code 1 Stop in /usr/src. *** [_includes] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. The obvious step of installing compile_et gives % cd /usr/src/usr.bin/compile_et % make depend yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y lex -t /usr/src/usr.bin/compile_et/../../contrib/com_err/lex.l > lex.c rm -f .depend mkdep -f .depend -a -I. -I/usr/src/usr.bin/compile_et/../../contrib/com_err -std=gnu99 /usr/src/usr.bin/compile_et/../../contrib/com_err/compile_et.c parse.c lex.c /usr/src/usr.bin/compile_et/../../contrib/com_err/compile_et.c:39:20: error: getarg.h: No such file or directory /usr/src/usr.bin/compile_et/../../contrib/com_err/compile_et.c:41:19: error: roken.h: No such file or directory mkdep: compile failed *** [.depend] Error code 1 so it appears that I need to build and install libroken to get the headers getarg.h and roken.h installed in /usr/include. % cd /usr/src/kerberos5/lib/libroken % make depend make-roken > roken.h make-roken: not found *** [roken.h] Error code 127 Stop in /usr/src/kerberos5/lib/libroken. Ok. Let's try building make-roken. % cd /usr/src/kerberos5/tools/make-roken % make depend && make && make install Hooray, that worked. % cd /usr/src/kerberos5/lib/libroken % make depend Hooray, again. % make (boom) cc -O2 -pipe -march=opteron -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -c /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c -o copyhostent.o /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' *** [copyhostent.o] Error code 1 Stop in /usr/src/kerberos5/lib/libroken. :( % make clean && make depend % make && make install That worked! (Apparently, something in the previous buildworld made cc unhappy.) % cd /usr/src/usr.bin/compile_et % make (boom) cc -O2 -pipe -march=opteron -I. -I/usr/src/usr.bin/compile_et/../../contrib/com_err -std=gnu99 -fstack-protector -Wno-pointer-sign -o compile_et compile_et.o parse.o lex.o -lroken /usr/obj/usr/src/usr.bin/compile_et/../../kerberos5/lib/libvers/libvers.a cc: /usr/obj/usr/src/usr.bin/compile_et/../../kerberos5/lib/libvers/libvers.a: No such file or directory *** [compile_et] Error code 1 % cd /usr/src/kerberos5/lib/libvers % make depend && make && make install Ok. % cd /usr/src/usr.bin/compile_et % make clean && make depend && make && make install % cd /usr/src % make buildenv Entering world for amd64:amd64 # which compile_et /usr/bin/compile_et # exit Whoops. That can't be right. % make -DNO_CLEAN buildworld and buildworld seems to be back on-track. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 23:40:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0459E7BF; Tue, 15 Jan 2013 23:40:35 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6C168308; Tue, 15 Jan 2013 23:40:33 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id n10so277809eaa.30 for ; Tue, 15 Jan 2013 15:40:33 -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 :content-type; bh=ucUXDLZwritb6V087Pvq6OzwM4WzBT+eGNcJA+uGTWU=; b=aT0pRbqg1cRWdiNuT6np1IqXICiZJ2WzeyyQU78i4p85eZoIKLhssUJw66FSCqpuuE XVkIoitf+C92NYWEK5fTZDb0nHuQ2AlkC7xxbXevyosYs7mZH4iy8SoyQyIh1COtODiS g8qno9PnwY83QBpxla4rcX8KXJdETFoRaLsJH2bu1j3D4AfvqTLF3p0cFEIhn/0XPVIT 4FOBPFbaHdLeHNNIs+g70oXrLZj5he3/wuchb7e4UWXuT6bdzCh+m1hYBaoJMD1Y4nyz CDzUeG0emELkUMT0+9frgRqRmvE7XyK8NF0LGbovwKlGD09tebyNIBKufWICne/0AW/l 2tcw== MIME-Version: 1.0 Received: by 10.14.2.66 with SMTP id 42mr246699507eee.7.1358293233055; Tue, 15 Jan 2013 15:40:33 -0800 (PST) Received: by 10.14.221.132 with HTTP; Tue, 15 Jan 2013 15:40:32 -0800 (PST) In-Reply-To: <20130115232216.GE1410@funkthat.com> References: <20130115231047.GD1410@funkthat.com> <20130115232216.GE1410@funkthat.com> Date: Tue, 15 Jan 2013 15:40:32 -0800 Message-ID: Subject: Re: Clang warning patches From: hiren panchasara To: hiren panchasara , freebsd-current , sbruno@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:40:35 -0000 On Tue, Jan 15, 2013 at 3:22 PM, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Tue, Jan 15, 2013 at 15:10 -0800: >> hiren panchasara wrote this message on Tue, Jan 15, 2013 at 07:52 -0800: >> > http://www.strugglingcoder.info/patches/clang_warnings_dev_bktr.txt >> >> This patch does not look correct at all... It is simply removing code.. >> >> How is is good that after we failed to set the tv_freq that we continue >> on? >> >> What is the warning that we are fixing here? > > I forgot to look at the intermediate variable that tv_channel was being > assigned to... Turns out it's an unsigned int, while tv_channel is > returning an int... We should fix this properly by changing temp to > be an int, or moving the check inline instead of removing it blindly... I agree. My bad. I should have looked at it a little more carefully. Turning temp to "int" looks fine. All function returns being assigned to temp are int. > > I think I still have an old bktr card that I can throw in to do some > basic testing... I will update the patch in a bit. I do not have the hardware but let me know if I can help you in testing. Thanks, Hiren > > After doing some code sperlunking, looks like this bug was introduced > w/ the original driver 15 years ago... And no one noticed even after > moving the code around a few times... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Jan 15 23:44:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1785941; Tue, 15 Jan 2013 23:44:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 98E3B353; Tue, 15 Jan 2013 23:44:43 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id EC6FA23F763; Tue, 15 Jan 2013 18:44:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us EC6FA23F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Tue, 15 Jan 2013 18:44:39 -0500 From: Glen Barber To: Steve Kargl Subject: Re: Missing compile_et and kerberos breaks buildworld Message-ID: <20130115234439.GA1313@glenbarber.us> References: <20130115233525.GA18192@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20130115233525.GA18192@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:44:43 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 03:35:25PM -0800, Steve Kargl wrote: > It seems that buildworld depends on the existence of > /usr/bin/compile_et if one wants to build WITH_KERBEROS > on a system that has never had Kerberos support. I > discovered this issue when des@ removed the NOFOO and > NO_FOO options, and the NO_KERBEROS=3D"YES" in my > /etc/make.conf was neutered. The system in question > has never had kerneros installed. One can emulate > the problem as follows: >=20 For what it is worth, reverting the removal of NO_FOO, et. al, will not fix your issue. I ran into this several months ago, and found out "the hard way" that many of our ports require kerberos, even if they do not advertise it - so building without kerberos on the system would fail. I started digging into it, and found what you found - compile_et does not get built prior to building the kerberos bits. It actually gets quite worse from there. I do not recall the details off-hand, but I recall doing 'make obj all install' in somewhat this order: - secure/ - include/ - kerberos5/ [some steps may be missing] Once I had compile_et, install_et, and a few things I do not recall right now, I could then go through and do a full buildworld/installworld. I never got much further in tracking this down. :( Glen --J/dobhs11T7y2rNN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ9ennAAoJEFJPDDeguUajda0H/jQsKvifW5rFIPa1b0U8Nb6s mMEcALOql0xXXtK56BcVbt89ntLjrDNYsLqpG5xQLzqu0InuUvEMDRtx23N5P+HC jQF3Pj9gIFIxdSRMc0fifDme0+j0eNZ6DFJIvF0uVwaNrWf9ftOfDam+ZYS0DEny tZS4H9wCVPX0VGcTsE5hdHMgJ4dPDKhwqPY09nNuVICjUVwps/ivsC7dYs8rnX3C zndynOLThJlgTGsBIiH4aiRJaZlWGG12Ex8dNw4Q0kjkWqjn94nIBDGBWE6LpKrP JIN/4zaKWAg424r0M3vC4OSA6dk/nTrQCz2llK/AitwRoUwRK4m+4YGqcz5vM1Y= =OEvk -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 00:46:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09B1F2CD; Wed, 16 Jan 2013 00:46:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id AE539976; Wed, 16 Jan 2013 00:46:02 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r0G0k1oI018836; Tue, 15 Jan 2013 16:46:01 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r0G0k13s018835; Tue, 15 Jan 2013 16:46:01 -0800 (PST) (envelope-from sgk) Date: Tue, 15 Jan 2013 16:46:01 -0800 From: Steve Kargl To: Glen Barber Subject: Re: Missing compile_et and kerberos breaks buildworld Message-ID: <20130116004601.GA18747@troutmask.apl.washington.edu> References: <20130115233525.GA18192@troutmask.apl.washington.edu> <20130115234439.GA1313@glenbarber.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130115234439.GA1313@glenbarber.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:46:03 -0000 On Tue, Jan 15, 2013 at 06:44:39PM -0500, Glen Barber wrote: > On Tue, Jan 15, 2013 at 03:35:25PM -0800, Steve Kargl wrote: > > It seems that buildworld depends on the existence of > > /usr/bin/compile_et if one wants to build WITH_KERBEROS > > on a system that has never had Kerberos support. I > > discovered this issue when des@ removed the NOFOO and > > NO_FOO options, and the NO_KERBEROS="YES" in my > > /etc/make.conf was neutered. The system in question > > has never had kerneros installed. One can emulate > > the problem as follows: > > > > For what it is worth, reverting the removal of NO_FOO, et. al, will not > fix your issue. Actually, it would because the NO_KERBEROS="YES" in /etc/make.conf would bypass building kerberos. :-) And yes, I've changed NO_KERBEROS to WITHOUT_KERBEROS and buildworld survives. I'm now looking into just how broken is bootstrapping kerberos. > I ran into this several months ago, and found out "the > hard way" that many of our ports require kerberos, even if they do not > advertise it - so building without kerberos on the system would fail. > > I started digging into it, and found what you found - compile_et does > not get built prior to building the kerberos bits. Thanks for confirming my fears. > It actually gets quite worse from there. Yep. :( I just hit cc -O2 -pipe -march=opteron -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 -I/usr/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD -Dnet_write=telnet_net_write -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /usr/obj/usr/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err /usr/obj/usr/src/tmp/usr/lib/libroken.so: undefined reference to `unvis@FBSD_1.0cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [telnetd] Error code 1 > I do not recall the details > off-hand, but I recall doing 'make obj all install' in somewhat this > order: > > - secure/ > - include/ > - kerberos5/ > [some steps may be missing] Thanks for a possible roadmap. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 01:03:29 2013 Return-Path: Delivered-To: freebsd-current@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 7232B9A1; Wed, 16 Jan 2013 01:03:29 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 39F7CA6A; Wed, 16 Jan 2013 01:03:29 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 0C59A23F763; Tue, 15 Jan 2013 20:03:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.1 onyx.glenbarber.us 0C59A23F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Tue, 15 Jan 2013 20:02:58 -0500 From: Glen Barber To: Steve Kargl Subject: Re: Missing compile_et and kerberos breaks buildworld Message-ID: <20130116010258.GC1313@glenbarber.us> References: <20130115233525.GA18192@troutmask.apl.washington.edu> <20130115234439.GA1313@glenbarber.us> <20130116004601.GA18747@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WfZ7S8PLGjBY9Voh" Content-Disposition: inline In-Reply-To: <20130116004601.GA18747@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 01:03:29 -0000 --WfZ7S8PLGjBY9Voh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 04:46:01PM -0800, Steve Kargl wrote: > > It actually gets quite worse from there. >=20 > Yep. :( > I just hit >=20 > cc -O2 -pipe -march=3Dopteron -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD= _ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 -I/usr/src/libexec/telnetd/../../= contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD -Dnet_write= =3Dtelnet_net_write -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unu= sed-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -W= no-switch -Wno-switch-enum -o telnetd global.o slc.o state.o sys_term.o te= lnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /usr/obj/usr/src/li= bexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -= lkrb5 -lhx509 -lasn1 -lroken -lcom_err > /usr/obj/usr/src/tmp/usr/lib/libroken.so: undefined reference to `unvis@F= BSD_1.0cc: error: linker command failed with exit code 1 (use -v to see inv= ocation) > *** [telnetd] Error code 1 >=20 This looks somewhat familiar. I vaguely recall setting WITHOUT_TELNET to get past this. Once buildworld finished successfully, I removed it from src.conf, and things built afterwards. > > I do not recall the details > > off-hand, but I recall doing 'make obj all install' in somewhat this > > order: > >=20 > > - secure/ > > - include/ > > - kerberos5/ > > [some steps may be missing] >=20 > Thanks for a possible roadmap. =20 >=20 I wish I had more useful details to provide. I'm going based on memory at this point. One other thing - make sure WITHOUT_GSSAPI (for ports) does not exist in make.conf. That bit me on two of the three machines I went through this nightmare. Glen PS: I thought I filed a PR with details on this, but it seems not to be the case. :( --WfZ7S8PLGjBY9Voh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ9fxCAAoJEFJPDDeguUajZsQH/3QJ+Lsqmz8BhjieO0SkVqS5 ovZWYfLk/XX0ouISvFakvAxUK8ETIEFiTf4kIcndc03wexWOHf1jNCDyWAGWZSfe zaWoUAJUwJMIPQIqD30wkBRXTqFJHexMLk/fzIAWncZbyoPr+9YB6pQnnIu9covt R1kY8BjZIHI/KDIUUJMOgf8SBBCMqjD0HNDfWai4IHE24OvsZ83D33eYcRKeAwnX Q8R26hw++K897jzgtw2LK5QKzjTTkOWWweZCkgqB+Xu/1MS9DKoP6dXgpSAVXFHh 06FcKjdtFzorpi29L109dR77J8/YUg4xw3wRPcSuutuLrNUcgCb9t4hR0pGzWjs= =dGe7 -----END PGP SIGNATURE----- --WfZ7S8PLGjBY9Voh-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 02:29:46 2013 Return-Path: Delivered-To: freebsd-current@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 0EC1210F; Wed, 16 Jan 2013 02:29:46 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by mx1.freebsd.org (Postfix) with ESMTP id 90E63EF6; Wed, 16 Jan 2013 02:29:45 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j6so920595oag.12 for ; Tue, 15 Jan 2013 18:29:39 -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=IJ38bvejiMrbXKCRZqKzs5G800bbyWxAGmyOfaAWxWA=; b=D0j51EtPmywAQ6QmHqeKVmgViuku138iIsFG7x3tSVlMMw/VOZk7Bdo3QDKJZRuJ1g 0p8H+LIB7IF1NWcnpemdWxdRhASflMJdnXGZDLouYYNm9NGcZUsXlLhs2Jff5ZaB2V8f btl8rwu4Ct7aR+Sy9fJWvX8SJqtVeze9D0guYUBYJZjpGLy0CBzotpgIEfwLzKhhIpf8 NMVT9evRpaKsqDAAG2EfESeTXsQb988Nfv7C64gDJ0XkUcA7xnW0iAgDrQAEfFJ25c3o QBrgDygTg152y1OFOnStJtewQ4bmk3dxQHLqgNb3oEcHZgxkNzU4tLY/mMui193MNDgG QNYg== MIME-Version: 1.0 Received: by 10.60.171.175 with SMTP id av15mr55906067oec.75.1358303379218; Tue, 15 Jan 2013 18:29:39 -0800 (PST) Received: by 10.76.128.68 with HTTP; Tue, 15 Jan 2013 18:29:39 -0800 (PST) In-Reply-To: <50F50C25.5090308@FreeBSD.org> References: <50F4D2AF.2020700@FreeBSD.org> <50F50C25.5090308@FreeBSD.org> Date: Tue, 15 Jan 2013 21:29:39 -0500 Message-ID: Subject: Re: ctfconvert again From: Ryan Stone To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Pedro Giffuni , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:29:46 -0000 I am working on a fix for this. It shouldn't be too bad, as we already build a cross-ctfconvert in certain cases. I just need to get some machines running older FreeBSD versions to test on to confirm that the fix worked. Should be able to test tomorrow, assuming that I am finally able to coerce old releases of FreeBSD to build on my -CURRENT machine. From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 02:42:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25FA5365 for ; Wed, 16 Jan 2013 02:42:29 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id E0CFCF7A for ; Wed, 16 Jan 2013 02:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=eqs2n06On0YQeKjRjXbKeIdVOXefP/D8jxjyeQTdY9I=; b=r1j0nCruacs7QF34VQrAI2oQ8UT+BdFNZi9AybATe0VUOwa2PLQAy1mCN8J4F5n0hBvz0AoMtuHLXo8JhEGOFNB6jBzjrRb/rvBTD+PypsfokZ8n/+EU3zh8uxSoMCp3BuPhvQpvWcbbc2SsUIIkGSq+pzULwHr+5aB+ywKejWk=; Received: from lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net ([2001:470:1f0e:3ad::2]:51659) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TvIxP-0007CB-GU for freebsd-current@freebsd.org; Tue, 15 Jan 2013 20:42:28 -0600 Date: Tue, 15 Jan 2013 20:42:24 -0600 (CST) From: Larry Rosenman To: freebsd-current@freebsd.org Subject: panic: pmap_insert_pt_page: pindex already inserted (r245473) 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-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:42:29 -0000 I've just gotten this panic on a -CURRENT (r245473): freebsd10-zfs dumped core - see /var/crash/vmcore.0 Tue Jan 15 20:32:15 CST 2013 FreeBSD freebsd10-zfs 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r245473: Tue Jan 15 19:45:27 CST 2013 root@freebsd10-zfs:/usr/obj/usr/src/sys/BORG-DTRACE amd64 panic: pmap_insert_pt_page: pindex already inserted GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: pmap_insert_pt_page: pindex already inserted cpuid = 1 KDB: enter: panic Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/acl_nfs4.ko...Reading symbols from /boot/kernel/acl_nfs4.ko.symbols...done. done. Loaded symbols for /boot/kernel/acl_nfs4.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/modules/vboxguest.ko...done. Loaded symbols for /boot/modules/vboxguest.ko #0 doadump (textdump=934624608) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=934624608) at pcpu.h:229 #1 0xffffffff8030a722 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:578 #2 0xffffffff8030a3fa in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff8030a1b2 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff8030cb00 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff805691c3 in kdb_trap (type=10, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80740993 in trap (frame=0xffffff8437b540d0) at /usr/src/sys/amd64/amd64/trap.c:579 I have the core.txt.0 at: http://www.lerctr.org/~ler/core.txt.0 This is in a VirtualBox VM running on a -CURRENT host. What else do you need? I do have the core..... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 02:55:16 2013 Return-Path: Delivered-To: freebsd-current@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 9678379D; Wed, 16 Jan 2013 02:55:16 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5CFCD96; Wed, 16 Jan 2013 02:55:16 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id n16so938566oag.9 for ; Tue, 15 Jan 2013 18:55:11 -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=/+/mgRkKV/tyjsPZwIa/UZDtr5ordNP4/pbYyJWIP4I=; b=IML7tMizihFnxeRmduSfMZUxN8tBTTrfCXR3ue8Rol/qP6ggB95JmBMrB7KjNNRxJB /j8kyXqEgxmWKSOWpFdsxY/cTc3Hp5hGZZbiCckBc27vTWTMYUIl1ZjevzKcUBNrczei DIqlo+tEP9eXp6VS5am3XOJ9/Cd9JSN62fWRYRY2ugF7JI5TBjSDzBYRoQj8W163CsyC mxAPW8jtiXMgA/s7wDockyc8eUkS3AJwZbDCvacuQk0zQ/jpKJmd3ysNu+pwlmcHsVVD LPmvrWHCllbDIIRFQhNGi+eP7uChzMcvBR+cksm3FfG160j4E9l0kjC3cTvZmrnJ0TCJ YeJw== MIME-Version: 1.0 Received: by 10.60.0.165 with SMTP id 5mr58176161oef.128.1358304911619; Tue, 15 Jan 2013 18:55:11 -0800 (PST) Received: by 10.76.107.241 with HTTP; Tue, 15 Jan 2013 18:55:11 -0800 (PST) In-Reply-To: <20130115225305.GA12294@stack.nl> References: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> <20130115225305.GA12294@stack.nl> Date: Tue, 15 Jan 2013 18:55:11 -0800 Message-ID: Subject: Re: ktrace -d broken on current/stable-9 From: Garrett Cooper To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:55:16 -0000 On Tue, Jan 15, 2013 at 2:53 PM, Jilles Tjoelker wrote: > On Mon, Jan 14, 2013 at 06:48:13PM -0800, Garrett Cooper wrote: >> I tried using ktrace on a kernel compiled a week ago, and it appears >> to not be following forks like it should on amd64: > >> # ktrace -d ./regress -l >> [snip] > >> Not sure how it broke, but it was working a couple months ago (in >> particular I remember it working either around October or November), >> and the bug seems to have worked its way back to 9-STABLE (I'm running >> into the same problem if I do ktrace -d, enter a shell, then exec >> another shell from that shell). Haven't spent the time to bisect the >> commits looking for the culprit (yet), but if need be I'll trace down >> the culprit sometime this week. > >> truss works, so it doesn't seem like ptrace(2) is broken. > > ktrace -d is not really useful in the synopsis with a command. It only > means that the child processes of ktrace (at a time just before it > executes the utility) should be traced as well. This is almost always an > empty set, unless you do things like > cmd1 & ktrace -d cmd2 > which will trace cmd2 and part of cmd1. > > You probably want ktrace -i. Dangit -- forgot about that option. Ok, PEBKAC award for me. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 05:15:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E7B27A4; Wed, 16 Jan 2013 05:15:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1B76A87D; Wed, 16 Jan 2013 05:15:17 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so597102wgh.19 for ; Tue, 15 Jan 2013 21:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=nyffFEU7b1yKrcNQVeyY/zr3oNHAng2WWBWoLIwWU1g=; b=pzkfBq7yWVVGHBMvpIBm5RMXV5Y+cGkdaDOMH+iiV+SbCeuJNi1fxKgOxmGnxmtfAa QW3DAmY3WiUJczbzeAdEB40+/J1GnF1TeranCxZ3x8d/zpYfyDOo8tmKwdAJmbYW/Nb2 Loawm0JKrQ1gkm8d3aknt09rR8m3BoM8KPRwa5d2ZgOAD8+HWcPZb1dsR2mD2M/i/gjv fZb3H2vhwXQwYngj8EIrYz86hQH2PodPr06wGHQKRKlvkbgUcuyPUY8e8gVOEuOmzf6v PuP7+CoUybZjv7oBZNBV2HYGySMd0N5iJGUVZ6Z+OGoaZkadlLF4FkhZI9VI/u3KMX5C G6uw== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr7420563wiv.33.1358313311570; Tue, 15 Jan 2013 21:15:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 21:15:11 -0800 (PST) Date: Tue, 15 Jan 2013 21:15:11 -0800 X-Google-Sender-Auth: A98CtrDRxI-7miMqNDazmcNBKHg Message-ID: Subject: [RFC] support -b when starting gdb From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 05:15:18 -0000 Hi, There doesn't seem to be a blessed way to set the baudrate from inside gdb/kgdb. It seems to be set from '-b' on the command line. However kgdb doesn't have this support. This patch adds -b support so kgdb so I can override the default speed (9600 it seems) to speak kgdb over serial to a 115200 console MIPS device. The MIPS stuff has other issues; I'll talk about those later. Thanks, Adrian Index: gnu/usr.bin/gdb/kgdb/main.c =================================================================== --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) @@ -333,11 +333,24 @@ args.argv = malloc(sizeof(char *)); args.argv[0] = argv[0]; - while ((ch = getopt(argc, argv, "ac:d:fn:qr:vw")) != -1) { + while ((ch = getopt(argc, argv, "ab:c:d:fn:qr:vw")) != -1) { switch (ch) { case 'a': annotation_level++; break; + case 'b': + { + int i; + char *p; + + i = strtol (optarg, &p, 0); + if (i == 0 && p == optarg) + warnx("warning: could not set baud rate to `%s'.\n", + optarg); + else + baud_rate = i; + } + break; case 'c': /* use given core file. */ if (vmcore != NULL) { warnx("option %c: can only be specified once", From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 06:30:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A9BC88F; Wed, 16 Jan 2013 06:30:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id DCF73B55; Wed, 16 Jan 2013 06:30:43 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so606245wge.34 for ; Tue, 15 Jan 2013 22:30:37 -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=/8uS09CjKBm65kRjO6rRQGIsaPrzoU5E9d/xMY5BKmE=; b=N6rA4sae8eN2PRwo1AZRg4qpzsF6DkP6pU6a7FwBWob9cCjlbWSPbC/omO9zDSVvoG giOQfiq/uvK25ikLRlz220kXAo0kt1qQIz7ehOGIfQa2yJnPTKgrrDyqpu3gbpME44qw hUbN1mb5SZR95EAmaxAhEr4/4dvgs60g0UgOTDkXR0yRUAXlHFJ/j8aPWk8f7ALRyXWI jO3KSmOG8nstmezlq8jsByQMMW72CHS0VuvORweS1JgR+W9PFfDciZ3adOiwWzvPjq0O iRXzKuiV5sCy5nJVlmKCjXcnqu0lf78BRhsgEdTFl++cLlmPLt1nQ5zXMQcc+MypB3Cs weVw== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr58373093wjd.59.1358317837316; Tue, 15 Jan 2013 22:30:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 22:30:37 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 22:30:37 -0800 X-Google-Sender-Auth: ehIyRbgPAMOlRWOlEBTI9Hujejo Message-ID: Subject: Re: [RFC] support -b when starting gdb From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 06:30:44 -0000 Also, I found 'set remotebaud' and 'set debug remote 1' to do this. I'd like to add the code just to support the same -b flag as gdb (so -r can also be used with a non-standard serial port.) Thanks, Adrian On 15 January 2013 21:15, Adrian Chadd wrote: > Hi, > > There doesn't seem to be a blessed way to set the baudrate from inside > gdb/kgdb. It seems to be set from '-b' on the command line. > > However kgdb doesn't have this support. > > This patch adds -b support so kgdb so I can override the default speed > (9600 it seems) to speak kgdb over serial to a 115200 console MIPS > device. > > The MIPS stuff has other issues; I'll talk about those later. > > Thanks, > > > > Adrian > > > Index: gnu/usr.bin/gdb/kgdb/main.c > =================================================================== > --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) > +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) > @@ -333,11 +333,24 @@ > args.argv = malloc(sizeof(char *)); > args.argv[0] = argv[0]; > > - while ((ch = getopt(argc, argv, "ac:d:fn:qr:vw")) != -1) { > + while ((ch = getopt(argc, argv, "ab:c:d:fn:qr:vw")) != -1) { > switch (ch) { > case 'a': > annotation_level++; > break; > + case 'b': > + { > + int i; > + char *p; > + > + i = strtol (optarg, &p, 0); > + if (i == 0 && p == optarg) > + warnx("warning: could not set baud > rate to `%s'.\n", > + optarg); > + else > + baud_rate = i; > + } > + break; > case 'c': /* use given core file. */ > if (vmcore != NULL) { > warnx("option %c: can only be specified once", From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 10:34:42 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EB2EF92; Wed, 16 Jan 2013 10:34:42 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F872B61; Wed, 16 Jan 2013 10:34:41 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r0GAYeBJ047468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Jan 2013 11:34:40 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 16 Jan 2013 11:34:40 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20130116103439.GS35868@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org, hackers@FreeBSD.org References: <20121215132246.GH69724@acme.spoerlein.net> <20121230113834.GG69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline In-Reply-To: <20121230113834.GG69724@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 10:34:42 -0000 --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This has been completed, your next pull will result in a non-fastforwardable change and I'd advise you to re-branch from origin/master instead. If you run into any trouble, don't hesitate to contact me directly. Thanks and sorry for the inconvenience, Uli On Sun, 2012-12-30 at 12:38:34 +0100, Ulrich Sp=C3=B6rlein wrote: > Just a reminder that this re-roll will happen in almost two weeks. >=20 > Thanks to a couple of volunteers, I now have independent confirmation > that the process is deterministic and repeatable and the switch can > progress as planned. >=20 > Regards, > Uli >=20 > On Sat, 2012-12-15 at 14:22:46 +0100, Ulrich Sp=C3=B6rlein wrote: > > Bad news everyone, > >=20 > > tl;dr The git mirror of the source repository needs to be re-rolled to > > make the conversion deterministically repeatable, this will change > > pretty much all git commit hashes. > >=20 > > The re-roll will be done January 15, 2013. > >=20 > > Not affected are the ports and doc repositories, nor is the svn_head > > (for use with git-svn) affected. > >=20 > >=20 > > Background > >=20 > > The converter (svn2git) was handing commits and objects to git's > > fast-import in arbitrary order, this makes merge commits have an > > arbitrary order of their parent commits and thus these merge commits > > have changing commit hashes for each converter run. > >=20 > > This has been fixed, but requires us to move all the branches over to > > this deterministic scheme, which will change all their commit hashes. > > None of the contents of these commits change, so rebasing/remerging your > > work into these branches is possible without running into any merge > > conflicts. > >=20 > >=20 > > We need your help > >=20 > > A goal of these conversions is to have them repeatable by you (yes, > > you!), so the correctness of the conversion can be verified. There are > > also no backups of the conversion runs, as they should be repeatable > > anyway. > >=20 > > We need 2-3 volunteers to run these conversions themselves and verify > > that the produced commit hashes match the published ones. The necessary > > steps to do this are documented on the Wiki under > >=20 > > http://wiki.freebsd.org/GitWorkflow#History > >=20 > > Please send me your output of git show-ref in a private mail, thanks. > >=20 > > Cheers, > > Uli > >=20 > > PS: This re-roll has nothing to do with the recent security incident. >=20 >=20 --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAEBAgAGBQJQ9oI/AAoJEKOmmGRKr4LOZw8H+QHI37qmjUjjiNZuR2HlHCUy oR1vfHi8HxFhHVvklo93K/1Qc6PnuxvzqCaeUPtr2JlqDN8l3HpI6RfGyJ5fw2Ja qy9/EBsyWhLsMHzKUsJhV7rm1Z/2Z0DqpxIhywy4TvghVBdL/5Vwzv/BtzFBrpyD 3kKfbbGStoDEkc54hP+P1/3B/6UUpXk0Hush9xrw2PkwPUWlbwjlz/iBgN6jhOkX KC8UtM9XNz5XOUGVSOR3Qb6psl5Fk9Qg9VcXVHVvtdth5LvvLglEU48WICpo65SP rJ8a3AkEyGjet1oUyiM5YZ5Bc5z1GoZn83iC1PganHA7cOR0HdLC1wCKkUkWrXI= =CSit -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 13:24:14 2013 Return-Path: Delivered-To: current@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 27ACE1B1; Wed, 16 Jan 2013 13:24:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F3FC27BB; Wed, 16 Jan 2013 13:24:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0GDO6g7029981; Wed, 16 Jan 2013 08:24:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0GDO654029966; Wed, 16 Jan 2013 13:24:06 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Jan 2013 13:24:06 GMT Message-Id: <201301161324.r0GDO654029966@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 13:24:14 -0000 TB --- 2013-01-16 12:35:24 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-16 12:35:24 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-16 12:35:24 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-01-16 12:35:24 - cleaning the object tree TB --- 2013-01-16 12:35:24 - /usr/local/bin/svn stat /src TB --- 2013-01-16 12:35:27 - At svn revision 245495 TB --- 2013-01-16 12:35:28 - building world TB --- 2013-01-16 12:35:28 - CROSS_BUILD_TESTING=YES TB --- 2013-01-16 12:35:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-16 12:35:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-16 12:35:28 - SRCCONF=/dev/null TB --- 2013-01-16 12:35:28 - TARGET=powerpc TB --- 2013-01-16 12:35:28 - TARGET_ARCH=powerpc64 TB --- 2013-01-16 12:35:28 - TZ=UTC TB --- 2013-01-16 12:35:28 - __MAKE_CONF=/dev/null TB --- 2013-01-16 12:35:28 - cd /src TB --- 2013-01-16 12:35:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jan 16 12:35:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/MicrosoftCXXABI.cpp -o MicrosoftCXXABI.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/MicrosoftMangle.cpp -o MicrosoftMangle.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"powerpc64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/NestedNameSpecifier.cpp -o NestedNameSpecifier.o /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/NestedNameSpecifier.cpp: In member function 'void clang::NestedNameSpecifier::print(llvm::raw_ostream&, const clang::PrintingPolicy&) const': /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/NestedNameSpecifier.cpp:223: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [NestedNameSpecifier.o] Error code 1 Stop in /src/lib/clang/libclangast. *** [all] Error code 1 Stop in /src/lib/clang. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-16 13:24:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-16 13:24:06 - ERROR: failed to build world TB --- 2013-01-16 13:24:06 - 2372.48 user 375.88 system 2921.88 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 15:36:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF6C74B6 for ; Wed, 16 Jan 2013 15:36:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0769F for ; Wed, 16 Jan 2013 15:36:01 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so2752372ieb.31 for ; Wed, 16 Jan 2013 07:35:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=tAms8dfU28PihyxzJF7t7q0DLQGJ50AMDAga/Tqxtak=; b=cgMbCbgWjv3XKSwM/DuvzRMmgNw5iIzZMYaTpdmD+rw90kq2+kuySDphvA19kYSPPr DaDW1OCIbGRTuhE+GSgeoPsYAmorAU3axvWRvrm7wUzgDw2qyGLMteVzYMEPxOXYIHwr WsFGhR8vBDMD9Ztv8UO10TBsAyvqn5kOoFoH5iobKeahuzpf8WWuTk+pb616ZGQiaiiY EhF1WSBh+SbuezMA+TGgV3LI+QMAomvftZP44lfs9QmIWJ9/BTZY8QMWHLhkuOx/Abk6 cVi2thr4uoI0WxmHh7fS17oPNY15S+1x8LRv7Lnunm2J2avwSlNk/foRXbKU8eMoX+OO TO5Q== X-Received: by 10.50.190.162 with SMTP id gr2mr5105579igc.65.1358350555145; Wed, 16 Jan 2013 07:35:55 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id uj6sm5010562igb.4.2013.01.16.07.35.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 07:35:54 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] support -b when starting gdb Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 16 Jan 2013 08:35:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnavaLw/J5TE69n2OZ9oysjA7u8ZpNzj/0ZnH2tkF2A+ZgJdlJeaAxGqChKswch0lrv63MK Cc: freebsd-hackers@freebsd.org, freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 15:36:01 -0000 How does 'set remotebaud' not do what you want? Warner On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: > Hi, >=20 > There doesn't seem to be a blessed way to set the baudrate from inside > gdb/kgdb. It seems to be set from '-b' on the command line. >=20 > However kgdb doesn't have this support. >=20 > This patch adds -b support so kgdb so I can override the default speed > (9600 it seems) to speak kgdb over serial to a 115200 console MIPS > device. >=20 > The MIPS stuff has other issues; I'll talk about those later. >=20 > Thanks, >=20 >=20 >=20 > Adrian >=20 >=20 > Index: gnu/usr.bin/gdb/kgdb/main.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 > --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) > +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) > @@ -333,11 +333,24 @@ > args.argv =3D malloc(sizeof(char *)); > args.argv[0] =3D argv[0]; >=20 > - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) { > + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D -1) = { > switch (ch) { > case 'a': > annotation_level++; > break; > + case 'b': > + { > + int i; > + char *p; > + > + i =3D strtol (optarg, &p, 0); > + if (i =3D=3D 0 && p =3D=3D optarg) > + warnx("warning: could not set baud > rate to `%s'.\n", > + optarg); > + else > + baud_rate =3D i; > + } > + break; > case 'c': /* use given core file. */ > if (vmcore !=3D NULL) { > warnx("option %c: can only be specified = once", > _______________________________________________ > 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-current@FreeBSD.ORG Wed Jan 16 16:05:08 2013 Return-Path: Delivered-To: freebsd-current@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 D1ED1D5D; Wed, 16 Jan 2013 16:05:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAD92FD; Wed, 16 Jan 2013 16:05:08 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so633383dan.9 for ; Wed, 16 Jan 2013 08:05:08 -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=XYH3yi/pVxg1MX0/aberFWCl9l/GHojyVdJSlz/mxb4=; b=zEsg+t+rcFaJPCSpKOuunuZ/4uLpllfiD8MKUZpffMXZH85BxVSUje3ydhoz2/wRsz OJTjja97Pd00XMvUW7TGXMR5WjwRsclj2rjeOWcIEmoHdWQxxp/zP3POTtXMOFDtIvSO pVLtNYJj7JeSTdp6srmeR/YXjPb8Gj2AJHaepgsfdsClexnE4pAHJj4DX8WRGz7PPWg+ SRQ28oqQxbFGxRoEGCNdm9BHzU3PLQrjhAYLJF4+ClLLyhDDWxaAoR1bE8H2f2ffZxD5 Ut3GxgQ4Ry96tjz00Nr7brvs8DCOFV3EevICuoCfXfkRxDNR5N/zX4Uka6qxkTaFI8Oq 4GvQ== X-Received: by 10.68.245.67 with SMTP id xm3mr3903540pbc.152.1358352308365; Wed, 16 Jan 2013 08:05:08 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id q4sm10179120paz.20.2013.01.16.08.05.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 08:05:07 -0800 (PST) References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: [RFC] support -b when starting gdb Date: Wed, 16 Jan 2013 08:05:06 -0800 To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 16:05:08 -0000 On Jan 16, 2013, at 7:35 AM, Warner Losh wrote: > How does 'set remotebaud' not do what you want? >=20 > Warner >=20 > On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: >=20 >> Hi, >>=20 >> There doesn't seem to be a blessed way to set the baudrate from inside >> gdb/kgdb. It seems to be set from '-b' on the command line. >>=20 >> However kgdb doesn't have this support. >>=20 >> This patch adds -b support so kgdb so I can override the default speed >> (9600 it seems) to speak kgdb over serial to a 115200 console MIPS >> device. >>=20 >> The MIPS stuff has other issues; I'll talk about those later. >>=20 >> Thanks, >>=20 >>=20 >>=20 >> Adrian >>=20 >>=20 >> Index: gnu/usr.bin/gdb/kgdb/main.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 >> --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) >> +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) >> @@ -333,11 +333,24 @@ >> args.argv =3D malloc(sizeof(char *)); >> args.argv[0] =3D argv[0]; >>=20 >> - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) { >> + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D -1) { >> switch (ch) { >> case 'a': >> annotation_level++; >> break; >> + case 'b': >> + { >> + int i; >> + char *p; >> + >> + i =3D strtol (optarg, &p, 0); >> + if (i =3D=3D 0 && p =3D=3D optarg) >> + warnx("warning: could not set baud >> rate to `%s'.\n", >> + optarg); >> + else >> + baud_rate =3D i; >> + } >> + break; >> case 'c': /* use given core file. */ >> if (vmcore !=3D NULL) { >> warnx("option %c: can only be specified onc= e", It's more of a convenience factor and easier to script command line argument= s IMO. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 16:11:14 2013 Return-Path: Delivered-To: freebsd-current@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 2A9DC22B for ; Wed, 16 Jan 2013 16:11:14 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id B316A401 for ; Wed, 16 Jan 2013 16:11:13 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id y2so1171713lbk.31 for ; Wed, 16 Jan 2013 08:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=267KERktWdH+GBPxcNng8jTrBl/AjKT4h9m+4q3STJw=; b=On1Uy/a1KeeSSJpCCIbmSQDONarCHMdAeGl0T+N907kri4sufGuIYxGkcj2/2FOWj7 TJn3+e0Zuv7yGTsYhjQX4QLPwCw3HBma1kdrCRzQHkndLvnr3jigzLcIb6KUuUsvShjc 8tUTO1ddQfJwill7kWzKwVa+WYQmCJoIsptVe4Ns2wY/TPQCc+hO2LbREhH43ixUglME iy2/OH/f5WS2GIxh/9sbiSSDRSwqIrKQCP7qCfNE41+m8j2BFLVYxZ6laNw/w85Jaetu w0idF2RNZfHnGX9yNdWztKfGxbttkpBmHXLFPJRTNpPOdm09HjpjRfH42w5JL5KzLyvl wtcQ== MIME-Version: 1.0 X-Received: by 10.152.122.39 with SMTP id lp7mr1740907lab.0.1358352672393; Wed, 16 Jan 2013 08:11:12 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.114.0.45 with HTTP; Wed, 16 Jan 2013 08:11:12 -0800 (PST) Date: Wed, 16 Jan 2013 17:11:12 +0100 X-Google-Sender-Auth: q8mW1jOSM9OqaS5_gbSuWSuuMYQ Message-ID: Subject: bluetooth a2dp audio From: CeDeROM To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 16:11:14 -0000 Hello :-) Is anyone working on A2DP Audio Profil/Device for Bluetooth devices? The bluetooth layer is working. Audio can use different dsp devices and has very nice control interface. I guess to make it work it would be necessary to create dsp device that could sink data, transform it into a2dp codec and send to bluetooth device.. Where should I start to look for information on this subject? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 17:52:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC602D92 for ; Wed, 16 Jan 2013 17:52:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBE5E0D for ; Wed, 16 Jan 2013 17:52:47 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id d13so1379475qak.18 for ; Wed, 16 Jan 2013 09:52:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=XAhSP1O+XHJJvMqOsBZuZgAq4miDMH9V8XqZpNoLvxU=; b=ZOOeA6ib68dYiJhqDB0im1hMixNXp6NgyH05taiCQUlRWOWlXHkzmfC5AVJIzXA5TY PsjNhbQzeu8NYQiwVk/dv9EzFt49WLiNwvD88DcE8f2bq535T4TzJwSYohRlI377WGCr zLVEkL0zb74SjbCswt0u1hF1/qcplLUgwojmvOgnoWrP6tVz9tHpBDwFer6lLi3936fW /XB7HDfhgYs6dIwm2r111VikdckNer5F/Jnve6c9nnfR9IQV8YwQUxCalE5ZmP8EEwv6 mDW+hBc3u3w92G3o3wuN5vXGwo98QhdPx1WDA0Pz2fdPLSgzwjR4hoF6sPA+nQz8KuQn wUnA== X-Received: by 10.49.49.226 with SMTP id x2mr2452224qen.45.1358358761153; Wed, 16 Jan 2013 09:52:41 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x9sm13235807qen.1.2013.01.16.09.52.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 09:52:39 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] support -b when starting gdb Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> Date: Wed, 16 Jan 2013 10:52:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlEbVIRG8x7kI0+kkG0n6PvhX4YRH+PgXZ3/NQClsg4pKOvJAN7yRXL/yX4TuS8fc7Fd1/j Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:52:48 -0000 On Jan 16, 2013, at 9:05 AM, Garrett Cooper wrote: > On Jan 16, 2013, at 7:35 AM, Warner Losh wrote: >=20 >> How does 'set remotebaud' not do what you want? >>=20 >> Warner >>=20 >> On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: >>=20 >>> Hi, >>>=20 >>> There doesn't seem to be a blessed way to set the baudrate from = inside >>> gdb/kgdb. It seems to be set from '-b' on the command line. >>>=20 >>> However kgdb doesn't have this support. >>>=20 >>> This patch adds -b support so kgdb so I can override the default = speed >>> (9600 it seems) to speak kgdb over serial to a 115200 console MIPS >>> device. >>>=20 >>> The MIPS stuff has other issues; I'll talk about those later. >>>=20 >>> Thanks, >>>=20 >>>=20 >>>=20 >>> Adrian >>>=20 >>>=20 >>> Index: gnu/usr.bin/gdb/kgdb/main.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 >>> --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) >>> +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) >>> @@ -333,11 +333,24 @@ >>> args.argv =3D malloc(sizeof(char *)); >>> args.argv[0] =3D argv[0]; >>>=20 >>> - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) = { >>> + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D = -1) { >>> switch (ch) { >>> case 'a': >>> annotation_level++; >>> break; >>> + case 'b': >>> + { >>> + int i; >>> + char *p; >>> + >>> + i =3D strtol (optarg, &p, 0); >>> + if (i =3D=3D 0 && p =3D=3D optarg) >>> + warnx("warning: could not set baud >>> rate to `%s'.\n", >>> + optarg); >>> + else >>> + baud_rate =3D i; >>> + } >>> + break; >>> case 'c': /* use given core file. */ >>> if (vmcore !=3D NULL) { >>> warnx("option %c: can only be specified = once", >=20 > It's more of a convenience factor and easier to script command line = arguments IMO. True, but he said there was no way to do it... I have this in my setup = scripts when I have to do serial debugging... Warner From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 18:24:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 73F01CC for ; Wed, 16 Jan 2013 18:24:16 +0000 (UTC) (envelope-from develloper.unix@hotmail.fr) Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.190.88]) by mx1.freebsd.org (Postfix) with ESMTP id 61A92BA for ; Wed, 16 Jan 2013 18:24:16 +0000 (UTC) Received: from BAY002-W27 ([65.54.190.124]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 10:23:10 -0800 X-EIP: [IlYHeyf5Wap6TNQvhcb1r8FPos4lU5vI] X-Originating-Email: [develloper.unix@hotmail.fr] Message-ID: From: Quentin SCHWERKOLT To: "freebsd-current@freebsd.org" Subject: Reboot by reloading kernel (reboot without reset hardware) Date: Wed, 16 Jan 2013 19:23:10 +0100 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2013 18:23:10.0200 (UTC) FILETIME=[89CD3F80:01CDF416] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:24:16 -0000 Hi=2C I would know if FreeBSD kernel has a functionality or a syscall which allow= rebooting without resetting hardware like kexec on Linux. If there are an equivalent=2C how can I use it? Otherwise there are any plan for implement it? Cordially. Q. Schwerkolt = From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 18:24:57 2013 Return-Path: Delivered-To: freebsd-current@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 7790727F; Wed, 16 Jan 2013 18:24:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DF8FCE1; Wed, 16 Jan 2013 18:24:56 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so1049090wgb.17 for ; Wed, 16 Jan 2013 10:24:55 -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=V4AO9x+tqfor9DwWeHFvTp+4JaEhu4COJ6yCsQouJAM=; b=RhfRPrsWt+Xtb5gpKhHP62gR22VD0S9/LHWmDdeFUrfpIfgPvsvrccMTw54tMtn/GH 0quYQyZIHJr8k7uSWMwzmkP6Hpd5br4YM/4c8rBO/S3iSahMTZilxWKJgez+Nlzpl9xh vFTHxJ7zGVlh7niiNetrky20wOFXFhs2cBM0BfyLQt1H5QAoac9Jqs7ZqwkLMEy3IGGP MB0nDRfoVXYMNjfQiV91ScrvH0piatdecjvgjsm/jzhVGVQHyAC93L3EH7gW8sL1lR08 BZKEraOg0hoxVf6b6xGUoAmzYJ9aXFdIEcIpSiTdJZ+gpAuJwElo0bdiMNSQGage7GsN KWjQ== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr11447670wiv.33.1358360695803; Wed, 16 Jan 2013 10:24:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 16 Jan 2013 10:24:55 -0800 (PST) In-Reply-To: <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> Date: Wed, 16 Jan 2013 10:24:55 -0800 X-Google-Sender-Auth: UCnwpyFmMS1Hp84BNE6HyKADy8I Message-ID: Subject: Re: [RFC] support -b when starting gdb From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:24:57 -0000 It wasn't listed anywhere in the documentation / wiki. I only found it after I had posted that patch. eg: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html I had to do a whole lot of searching to finally discover that particular option. And yes, it'd be nice to have -b so I can use -b and -r to instantly open up a remote gdb session. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 18:43:08 2013 Return-Path: Delivered-To: freebsd-current@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 A2D44903; Wed, 16 Jan 2013 18:43:08 +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 815C2219; Wed, 16 Jan 2013 18:43:08 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9B13B976; Wed, 16 Jan 2013 13:43:07 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC] support -b when starting gdb Date: Wed, 16 Jan 2013 11:17:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301161117.23253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Jan 2013 13:43:07 -0500 (EST) Cc: freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:43:08 -0000 On Wednesday, January 16, 2013 1:30:37 am Adrian Chadd wrote: > Also, I found 'set remotebaud' and 'set debug remote 1' to do this. > > I'd like to add the code just to support the same -b flag as gdb (so > -r can also be used with a non-standard serial port.) I think adding -b is fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jan 16 20:11:56 2013 Return-Path: Delivered-To: freebsd-current@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 78563499 for ; Wed, 16 Jan 2013 20:11:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6EDEA03 for ; Wed, 16 Jan 2013 20:11:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA04177; Wed, 16 Jan 2013 22:11:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TvZKx-000OZ8-AU; Wed, 16 Jan 2013 22:11:51 +0200 Message-ID: <50F70985.9040905@FreeBSD.org> Date: Wed, 16 Jan 2013 22:11:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Quentin SCHWERKOLT Subject: Re: Reboot by reloading kernel (reboot without reset hardware) References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:11:56 -0000 on 16/01/2013 20:23 Quentin SCHWERKOLT said the following: > Hi, > > I would know if FreeBSD kernel has a functionality or a syscall which allow rebooting without resetting hardware like kexec on Linux. > If there are an equivalent, how can I use it? > Otherwise there are any plan for implement it? Please see the following thread which includes a patch: http://thread.gmane.org/gmane.os.freebsd.current/145897/focus=145899 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 05:24:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3FB583A5; Thu, 17 Jan 2013 05:24:39 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A1D6E3DB; Thu, 17 Jan 2013 05:24:38 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so1355014wgb.17 for ; Wed, 16 Jan 2013 21:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sOL5zdmsXoEMzeF3vXfwy+lge44rcvlI1Ez0NUQrhsE=; b=xyeLeaOZ4sSOHmBFXmLvaAf3A2B+HTj62bRj+kgnDgdL/gy5qHOUBMXrsY+VNIVjye AXP9byrWxUPFdPJk/EuRsW468qUYmV1HV2V9MyAGGOiGizrRVgo0NbkE3arm0O6mXxY6 ztJzcVPX2Ku2keY7rYcoLSWL1KR7yeAr9C2QpXsEGtOUrOyhIkHxS2c4CkkETT/ecRpD G5JNNS+xjvjNlmihG878bF7kcH++RwKPM0/YJCjUPrGDoQB8mjaT8DFaFivgkzvpfROP Vr1uNXTEDv9FCs491RDQMBwvKoM3b+3yu+2jLAZdkANSLiJMxfmXcM67kcorGtmk/xUg vbnw== MIME-Version: 1.0 X-Received: by 10.194.21.70 with SMTP id t6mr6064283wje.42.1358400277499; Wed, 16 Jan 2013 21:24:37 -0800 (PST) Received: by 10.216.172.197 with HTTP; Wed, 16 Jan 2013 21:24:35 -0800 (PST) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> Date: Thu, 17 Jan 2013 07:24:35 +0200 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: Phil Kulin Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 05:24:39 -0000 On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin wrote: > 2012/12/26 Kimmo Paasiala : > >> I've revised the patch again and updated it at gihub, >> https://gist.github.com/4362018. It can now be applied at top level >> of sources (/usr/src typically). It now does the deconfiguration in >> reverse order of the configuration, meaning the aliases configured >> with ipv6_addrs_IF are removed before the ones configured with >> ifconfig_IF_aliasN="inet6 ...". > > Adapted for FreeBSD 8.2, works fine: > > --- network.subr.orig 2011-02-17 05:19:39.000000000 +0300 > +++ network.subr 2012-12-28 00:46:38.000000000 +0400 > @@ -312,6 +312,12 @@ afexists() > # 1 otherwise. > ipv6if() > { > + # Test for $ipv6_addrs_IF. If it exists then the > + # interface should be configured for IPv6 > + _tmpargs=$(get_if_var $_if ipv6_addrs_IF) > + if [ -n "${_tmpargs}" ]; then > + return 0 > + fi > if ! checkyesno ipv6_enable; then > return 1 > fi > @@ -948,7 +954,12 @@ network6_interface_setup() > rtsol_interface=no > ifconfig $i inet6 ${ipv6_ifconfig} alias > fi > - > + ipv6_addrs=`get_if_var $i ipv6_addrs_IF` > + if [ -n "${ipv6_addrs}" ]; then > + rtsol_available=no > + rtsol_interface=no > + ipv6_addrs_common ${i} alias > + fi > # Wireless NIC cards are virtualized through the wlan interface > if ! is_wired_interface ${i}; then > case "${i}" in > @@ -1178,3 +1189,39 @@ network6_getladdr() > esac > done > } > + > +ipv6_addrs_common() > +{ > + local _ret _if _action _ip6prefix _ip6prefixes > + local _ip6addr _prefixlen > + local _range _ip6net _ip6low _ip6high > + _ret=1 > + _if=$1 > + _action=$2 > + # get the prefixes from ipv6_addrs_IF variable > + _ip6prefixes=`get_if_var $_if ipv6_addrs_IF` > + for _ip6prefix in ${_ip6prefixes}; do > + _ip6addr=${_ip6prefix%%/*} > + _prefixlen=${_ip6prefix##*/} > + _range=${_ip6addr##*:} > + _ip6net=${_ip6addr%:*} > + _ip6low=${_range%-*} > + _ip6high=${_range#*-} > + # If deleting an alias, set _prefixlen to null string. > + if [ "${_action}" = "-alias" ]; then > + _prefixlen="" > + else > + _prefixlen="prefixlen $_prefixlen" > + fi > + _ip6high=$(("0x${_ip6high}")) > + _ip6count=$(("0x${_ip6low}")) > + while [ "${_ip6count}" -le "${_ip6high}" ]; do > + # Re-uses the _ip6addr variable from above > + _ip6addr=$(printf "%x" "${_ip6count}") > + eval "ifconfig ${_if} inet6 > ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}" > + _ip6count=$((${_ip6count}+1)) > + _ret=0 > + done > + done > + return $_ret > +} > > > -- > Non nobis Domine non nobis sed Nomini Tuo da gloriam > Phil Kulin I don't have an 8.X system to test but I guess it's fine. Any more interest in this? I'd love to see this added, not because I wrote it but because I want to contribute in any way I can. -Kimmo From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 11:18:52 2013 Return-Path: Delivered-To: freebsd-current@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 71CA55AF for ; Thu, 17 Jan 2013 11:18:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 092B03D2 for ; Thu, 17 Jan 2013 11:18:51 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 367543672; Thu, 17 Jan 2013 12:18:43 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Subject: Re: bluetooth a2dp audio Date: Thu, 17 Jan 2013 12:20:06 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: CeDeROM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 11:18:52 -0000 On Wednesday 16 January 2013 17:11:12 CeDeROM wrote: > Hello :-) > > Is anyone working on A2DP Audio Profil/Device for Bluetooth devices? > > The bluetooth layer is working. Audio can use different dsp devices > and has very nice control interface. I guess to make it work it would > be necessary to create dsp device that could sink data, transform it > into a2dp codec and send to bluetooth device.. > > Where should I start to look for information on this subject? > > Best regards :-) > Tomek Hi, You might want to look at my Virtual OSS from I4B SVN, which creates an entire /dev/vdsp device from userspace using cuse4bsd! svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b Look for voss in i4b/trunk/virtual_oss . --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 12:31:18 2013 Return-Path: Delivered-To: freebsd-current@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 BD2D98A0 for ; Thu, 17 Jan 2013 12:31:18 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8029BC for ; Thu, 17 Jan 2013 12:31:18 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id i20so2025375qad.3 for ; Thu, 17 Jan 2013 04:31:17 -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=oi6R16C40ZwMuBBGCGH2Vo2Y7kXzTrz8b6lXCCAfIa8=; b=YMErJQKZOtK8+f1Lr2I8fC0ofqb4ApWRGl+3bju/s7zKS/RNzzNVlvq63l+IyN0Pah Jqkxcghw3yv8CfwypGyKSps5LlBdb+ZoL+YmqXOUfn50Lv/I5KX70Ghew7jY7NmO7HVM 4gZWkRVfeu1HCf2sGXIQYnFypYoTSxSULk5ai7u/FxhWLwQZaLCzahXbZ2G214gvRcMR 8ZvIgtv4in85zRTKa0IxmTN2l9Uhb3wjqqzBXM6t2Ld8vuMv+CBfaJVjOVhjjkTR0FYH IX9qxqnazLfzVoxmQaLkO5zs9gT18EzH8prbNJ6W3gkylFhANF6LDWVY3183Uk28OS8g G2ug== MIME-Version: 1.0 X-Received: by 10.224.209.193 with SMTP id gh1mr5408596qab.86.1358425877671; Thu, 17 Jan 2013 04:31:17 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Thu, 17 Jan 2013 04:31:17 -0800 (PST) In-Reply-To: <201301171220.06326.hselasky@c2i.net> References: <201301171220.06326.hselasky@c2i.net> Date: Thu, 17 Jan 2013 13:31:17 +0100 X-Google-Sender-Auth: PDgUaABZp7BINc1bmIt7RSkuDnE Message-ID: Subject: Re: bluetooth a2dp audio From: CeDeROM To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:31:18 -0000 On Thu, Jan 17, 2013 at 12:20 PM, Hans Petter Selasky wrote: > You might want to look at my Virtual OSS from I4B SVN, which creates an entire > /dev/vdsp device from userspace using cuse4bsd! Thank you Hans!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 14:14:03 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5896E1C; Thu, 17 Jan 2013 14:14:03 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B258FFD; Thu, 17 Jan 2013 14:13:50 +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 r0HEDoDc091020; Thu, 17 Jan 2013 07:13:50 -0700 (MST) (envelope-from ian@FreeBSD.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 r0HEDltk006354; Thu, 17 Jan 2013 07:13:47 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Bruce Evans In-Reply-To: <20130114102118.V1045@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130114102118.V1045@besplex.bde.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2013 07:13:47 -0700 Message-ID: <1358432027.32417.213.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Marius Strobl , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:14:04 -0000 On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote: > On Sun, 13 Jan 2013, Alexander Motin wrote: > > > On 13.01.2013 20:09, Marius Strobl wrote: > >> On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote: [...] > > > > In existing code in HEAD and 9 timecounters are never called with spin > > mutex held. I intentionally tried to avoid that in existing eventtimers > > code. > > Er, timecounters are called with a spin mutex held in existing code: > though it is dangerous to do so, timecounters are called from fast > interrupt handlers for very timekeeping-critical purposes: > - to implement the TIOCTIMESTAMP ioctl (except this is broken in > -current). This was a primitive version of pps timestamping. > - for pps timestamping. The interrupt handler (which should be a fast > interrupt handler to minimize latency) calls pps_capture() which > calls tc_get_timecount() and does other "lock-free" accesses to the > timecounter state. This still works in -current (at least there is > still code for it). > Unfortunately, calling pps_capture() in the primary interrupt context is no longer an option with the stock pps driver. Ever since the ppbus rewrite all ppbus children must use threaded handlers. I tried to fix that a couple different ways, and both ended up with crazy-complex code scattered around the ppbus family just to support the rarely-used pps capture. It would have been easier to do if filter and threaded interrupt handlers had the same function signature. I ended up writting a separate driver that can be used instead of ppc + ppbus + pps, since anyone who cares about precise pps capture is unlikely to be sharing the port with a printer or plip device or some such. > OTOH, all drivers that call pps_capture() from their interrupt handler > then immediately call pps_event(). This has always been very broken, > and became even more broken with SMPng. pps_event() does many more > timecounter and pps accesses whose locking is unclear at best, and > in some configurations it calls hardpps(), which is only locked by > Giant, despite comments in kern_ntptime.c still saying that it (and > many other functions in kern_ntptime.c) must be called at splclock() > or higher. splclock() is of course now null, but the locking > requirements in kern_ntptime.c haven't changed much. kern_ntptime.c > always needed to be locked by the equivalent of a spin mutex, which > is stronger locking than was given by splclock(). pps_event() would > have to aquire the spin mutex before calling hardpps(), although > this is bad for fast interrupt handlers. The correct implementation > is probably to only do the capture part from fast interrupt handlers. > In my rewritten dedicated pps driver I call pps_capture() from the filter handler and pps_event() from the threaded handler. I never found any good documentation on the low-level details of this stuff, and there isn't enough good example code to work from. My hazy memory is that I ended up studying the pps_capture() and pps_event() code enough to infer that their design intent seems to be to allow you to capture with no locking and do the event processing later in some sort of deferred or threaded context. > > Callout code same time can be called in any environment with any > > locks held. And new callout code may need to know precise current time > > in any of those conditions. Attempt to use an IPI and wait there can be > > fatal. > > Callout code can't be called from such a general "any" environment as > timecounter code. Not from a fast interrupt handler. Not from an NMI > or IPI handler. I hope. But timecounter code has a good chance of > working even for the last 2 environments, due to its design requirement > of working in the first. > > The spinlock in the i8254 timecounter certainly breaks some cases. > For example, suppose the lock is held for a timecounter read from > normal context. It masks hardware interrupts on the current CPU (except > in my version). It doesn't mask NMIs or other traps. So if the NMI > or other trap handler does a timecounter hardware call, there is > deadlock in at least the !SMP case. In my version, it blocks normal > interrupts later if they occur, but doesn't block fast interrupts, so > the pps_capture() call would deadlock if it occurs, like a timecounter > call from an NMI. I avoid this by not using pps in any fast interrupt > handler, and by only using the i8254 timecounter for testing. I do > use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock > interrupt handlers are all non-fast to avoid this and other locking > problems. Hrm, now you've got me a bit worried about capturing in the primary context. Not that I have much option, on a 300mhz Geode and similar wimpy embedded processors there's enough latency on a theaded handler that the pps signal can be de-asserted by time the handler runs (precision timing gear often outputs a very narrow pps pulse, 1 - 10uS isn't uncommon). I know I don't have to worry about NMIs on the systems in question, but I'm not so sure about "other trap handler". > [...] > > Bruce -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 15:36:52 2013 Return-Path: Delivered-To: freebsd-current@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 11D6BEC9 for ; Thu, 17 Jan 2013 15:36:52 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id DB34E8CB for ; Thu, 17 Jan 2013 15:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:To:From:Date; bh=fnjlyc55qfG7PysvV1bn98txcsPctE1gFb8SSjUJsJ4=; b=gaCpj4NSUxh3vpU7LLVYBk1/b7hgEhpdTlOv5uFNaBski1TTOX1m6dwyggz2VulkCTasojpsrV7gsz3tMKzEaNu7I93PMN5ac/+pDCg6MOgM3f3fW9Y7GsfhlB+YVYs0XMBy8KEK1TiJtNisVcaBEs9vC6NrbpMMVz4Kb4xw4R0=; Received: from lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net ([2001:470:1f0e:3ad::2]:19862) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TvrWM-000Peo-LT for freebsd-current@freebsd.org; Thu, 17 Jan 2013 09:36:51 -0600 Date: Thu, 17 Jan 2013 09:36:45 -0600 (CST) From: Larry Rosenman To: freebsd-current@freebsd.org Subject: Re: panic: pmap_insert_pt_page: pindex already inserted (r245473) 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-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 15:36:52 -0000 On Tue, 15 Jan 2013, Larry Rosenman wrote: > I've just gotten this panic on a -CURRENT (r245473): > > > freebsd10-zfs dumped core - see /var/crash/vmcore.0 > > Tue Jan 15 20:32:15 CST 2013 > > FreeBSD freebsd10-zfs 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r245473: Tue Jan > 15 19:45:27 CST 2013 root@freebsd10-zfs:/usr/obj/usr/src/sys/BORG-DTRACE > amd64 > > panic: pmap_insert_pt_page: pindex already inserted I just got the same panic on a 9.1-STABLE VM on the same host: freebsd9-zfs dumped core - see /var/crash/vmcore.2 Thu Jan 17 09:24:46 CST 2013 FreeBSD freebsd9-zfs 9.1-STABLE FreeBSD 9.1-STABLE #0 r245459: Thu Jan 17 04:18:43 CST 2013 root@freebsd9-zfs:/usr/obj/usr/src/sys/GENERIC amd64 panic: pmap_insert_pt_page: pindex already inserted GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: pmap_insert_pt_page: pindex already inserted cpuid = 1 KDB: stack backtrace: Anyone want to help me look at these? I have both the -CURRENT and 9.1-STABLE cores available, and can provide SSH access to both VM's and the host. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 16:05:51 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59504B7A; Thu, 17 Jan 2013 16:05:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3554FA75; Thu, 17 Jan 2013 16:05:51 +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 r0HG5o8w092227; Thu, 17 Jan 2013 09:05:50 -0700 (MST) (envelope-from ian@FreeBSD.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 r0HG5mdZ006465; Thu, 17 Jan 2013 09:05:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Davide Italiano In-Reply-To: <1356909223.54953.74.camel@revolution.hippie.lan> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jan 2013 09:05:47 -0700 Message-ID: <1358438747.32417.223.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Marius Strobl , Alexander Motin , FreeBSD Current , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:05:51 -0000 On Sun, 2012-12-30 at 16:13 -0700, Ian Lepore wrote: > On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote: > >[...] > > > > I grabbed testsleep.c to test an arm event timer implementation, and had > to fix a couple nits... kqueueto was missing from the names[] array, and > I had to add a "* 1000" to a couple places where usec was stuffed into a > timespec's tv_nsec. > > I also tested the calloutng_12_17 patches and the kqueue stuff behaved > very strangely. Then I noticed you had a 12_26 patchset so I tested > that (after crudely fixing a couple uninitialized var warnings), and it > all looks good on this arm (Raspberry Pi). I'll attach the results. > > It's so sweet to be able to do precision sleeps. > > -- Ian > > > plain text document attachment (calloutng_test.txt) > for t in 1 300 3000 30000 300000 ; do > for m in select poll usleep nanosleep kqueue kqueueto syscall ; do > ./testsleep $t $m > done > done > > > With calloutng_12_26.patch... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 55.79 1 50.96 1 61.32 > poll 1 1109.46 1 1107.86 1 1114.38 > usleep 1 56.33 1 72.90 1 62.78 > nanosleep 1 52.66 1 55.23 1 64.23 > kqueue 1 1114.23 1 1113.81 1 1121.21 > kqueueto 1 65.44 1 71.00 1 75.01 > syscall 1 4.70 1 4.45 1 4.55 > select 300 355.79 300 357.76 300 362.35 > poll 300 1107.85 300 1122.55 300 1115.62 > usleep 300 355.28 300 357.28 300 360.79 > nanosleep 300 354.49 300 355.82 300 360.62 > kqueue 300 1112.57 300 1118.13 300 1117.16 > kqueueto 300 375.98 300 378.62 300 395.61 > syscall 300 4.41 300 4.45 300 4.54 > select 3000 3246.75 3000 3246.74 3000 3252.72 > poll 3000 3238.10 3000 3229.12 3000 3250.10 > usleep 3000 3242.47 3000 3237.06 3000 3249.61 > nanosleep 3000 3238.79 3000 3231.55 3000 3248.11 > kqueue 3000 3240.01 3000 3236.07 3000 3247.60 > kqueueto 3000 3265.36 3000 3267.22 3000 3274.96 > syscall 3000 4.69 3000 4.44 3000 4.50 > select 30000 31714.60 30000 31941.17 30000 32467.69 > poll 30000 31522.76 30000 31983.00 30000 32497.81 > usleep 30000 31459.67 30000 31980.76 30000 32458.71 > nanosleep 30000 31431.02 30000 31982.22 30000 32525.20 > kqueue 30000 31466.75 30000 31873.90 30000 31973.54 > kqueueto 30000 31564.67 30000 32522.35 30000 32475.59 > syscall 30000 4.70 30000 4.73 30000 4.89 > select 300000 319133.02 300000 311562.33 300000 309918.62 > poll 300000 319604.27 300000 311422.94 300000 310000.76 > usleep 300000 319314.60 300000 311269.69 300000 309996.34 > nanosleep 300000 319497.58 300000 311425.40 300000 309997.13 > kqueue 300000 309995.55 300000 303980.27 300000 309908.82 > kqueueto 300000 319505.88 300000 311424.97 300000 309996.16 > syscall 300000 4.41 300000 4.45 300000 4.89 > > > With no patches... > > HZ=100 HZ=250 HZ=1000 > ---------- ---------------- ---------------- ---------------- > select 1 19941.70 1 7989.10 1 1999.16 > poll 1 19904.61 1 7987.32 1 1999.78 > usleep 1 19904.95 1 7993.30 1 1999.96 > nanosleep 1 19905.64 1 7993.71 1 1999.72 > kqueue 1 10001.61 1 4004.00 1 1000.27 > kqueueto 1 19904.00 1 7993.03 1 1999.54 > syscall 1 4.04 1 4.05 1 4.75 > select 300 19904.66 300 7998.39 300 2000.27 > poll 300 19904.35 300 7993.47 300 1999.86 > usleep 300 19903.96 300 7994.11 300 1999.81 > nanosleep 300 19904.48 300 7993.77 300 1999.80 > kqueue 300 10001.68 300 4004.18 300 1000.31 > kqueueto 300 19997.86 300 7993.37 300 1999.59 > syscall 300 4.01 300 4.00 300 4.32 > select 3000 19904.80 3000 7998.85 3000 3998.43 > poll 3000 19904.92 3000 8005.93 3000 3999.39 > usleep 3000 19904.50 3000 7992.88 3000 3999.44 > nanosleep 3000 19904.84 3000 7993.34 3000 3999.36 > kqueue 3000 10001.58 3000 4003.97 3000 3000.72 > kqueueto 3000 19903.56 3000 7993.24 3000 3999.34 > syscall 3000 4.02 3000 4.37 3000 4.29 > select 30000 39905.02 30000 35991.79 30000 31051.77 > poll 30000 39905.49 30000 35980.35 30000 30995.64 > usleep 30000 39903.78 30000 35979.48 30000 30995.23 > nanosleep 30000 39904.55 30000 35981.61 30000 30995.87 > kqueue 30000 30002.73 30000 32019.54 30000 30004.83 > kqueueto 30000 39903.59 30000 35979.64 30000 30996.05 > syscall 30000 4.44 30000 4.04 30000 4.31 > select 300000 310001.23 300000 303995.86 300000 300994.30 > poll 300000 309902.73 300000 303981.58 300000 300996.17 > usleep 300000 309903.64 300000 303980.17 300000 300997.42 > nanosleep 300000 309903.32 300000 303980.36 300000 300993.64 > kqueue 300000 300002.77 300000 300019.46 300000 300006.90 > kqueueto 300000 309903.31 300000 303978.10 300000 300996.84 > syscall 300000 4.01 300000 4.04 300000 4.29 Davide asked me in a private followup (long ago) to try the same test with linux running on the same hardware. I finally got around to downloading a linux image for the Raspberry Pi today and did so. The image I used was 2012-12-16-wheezy-raspbian.zip SHA-1 514974a5fcbbbea02151d79a715741c2159d4b0a The test code was the same as last time, except for commenting out the kqueue stuff. Here are the results... 1 79.80 select 1 1077.37 poll 1 74.87 usleep 1 74.83 nanosleep 1 0.00 1 0.00 1 0.87 syscall 300 379.89 select 300 1077.70 poll 300 374.97 usleep 300 374.75 nanosleep 300 0.00 300 0.00 300 0.85 syscall 3000 3085.27 select 3000 3081.32 poll 3000 3081.20 usleep 3000 3081.06 nanosleep 3000 0.00 3000 0.00 3000 0.88 syscall 30000 30093.14 select 30000 30090.79 poll 30000 30090.05 usleep 30000 30088.43 nanosleep 30000 0.00 30000 0.00 30000 0.86 syscall 300000 300351.35 select 300000 300346.16 poll 300000 300097.34 usleep 300000 300097.29 nanosleep 300000 0.00 300000 0.00 300000 0.85 syscall -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 17:02:40 2013 Return-Path: Delivered-To: current@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 F2C9D5E8; Thu, 17 Jan 2013 17:02:39 +0000 (UTC) (envelope-from sergey.dyatko@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 2CE7BF1D; Thu, 17 Jan 2013 17:02:38 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id ej20so2877803lab.21 for ; Thu, 17 Jan 2013 09:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=yCd5I3y+/5YahSWD1nSZwWpX6qcKaoqDi4lA4iMBtYc=; b=SFu9tyo1xpGNbErgSuT2TRxCI+d/pEhMk46KnOOwZtw/Nh0BEC3EueUeyD3TopIMQ1 Gvy/0qlhdlupH5C2itrqHrpqgwFC8BZHlmlf+L8mY93Bwr65jHfQWUv/qaKn1wu10HyM XODrGfj36TKX7duIzAQWTfERuSSyd+wwwsDPQv9x0QGYk3rJxFt4cGXrNpt18n3Bk9Dd tyH4JhccYoltyO4SbY2bcuXrBuwnawvaLXc+FHo3vxQzEa+M9/s1otlZpT9n7bK8wpUu Lap+a1MCfDaz0mqt8TB7akM9kqldb3+GpuvmXtuTtlax2OgK7EzX5H4A+ZbEmdcuqCpe iFGA== X-Received: by 10.152.125.136 with SMTP id mq8mr5534927lab.41.1358442158007; Thu, 17 Jan 2013 09:02:38 -0800 (PST) Received: from laptop ([178.125.240.29]) by mx.google.com with ESMTPS id f2sm1088115lbz.4.2013.01.17.09.02.36 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:02:37 -0800 (PST) Date: Thu, 17 Jan 2013 20:02:34 +0300 From: "Sergey V. Dyatko" To: Subject: panic: solaris assert: sa.sa_magic == 0x2F505A Message-ID: <20130117200234.416338fb@laptop> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:02:40 -0000 Hi, today I got panic on my laptop, running head, amd64 r245462. unfortunately I don't know how it can be reproduced so I will be grateful for any hints full core-file can be found here: http://svn.freebsd.by/files/core20130117.txt Konstantin, I added you to CC because you was last touched zfs_vfsops.c, I'm sorry if I was wrong :) -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 17:03:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7BB8709 for ; Thu, 17 Jan 2013 17:03:47 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4057FF37 for ; Thu, 17 Jan 2013 17:03:46 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r0HH6Dp3062496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 18:06:13 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <50F82E61.4020601@omnilan.de> Date: Thu, 17 Jan 2013 18:01:21 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD current Subject: patch to inherit sticky bit X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9E489660CC66C058FA4279D" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9E489660CC66C058FA4279D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Dear developers, I'm really missing the possibility to get the sticky bit inherited. I'm using zfs these days, together with nfs4acls and it almost does things like real world users expect. I never understood why write permission to a directory allowes file unlinking inside, even if the user has no write permission on that file..= =2E With addidional acls, this is even worse. One simple solution is the sticky bit. But I can't inherit it with nfs4ac= ls. How would a patch best accomplish that? Should mkdir respect the sticky bit? How is current group inheritance with mkdir implemented? I'd really need a sysctl or kernel compile option which enables sticky bit inheritance. Thanks for any help, -Harry --------------enigC9E489660CC66C058FA4279D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlD4LmcACgkQLDqVQ9VXb8j2oACfc7AxE/z1MRX5hUeEqnHGD0lr 2NUAoLxCtJSw2cZX+SbPUTeGQmbc97KG =E+bI -----END PGP SIGNATURE----- --------------enigC9E489660CC66C058FA4279D-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 17:46:12 2013 Return-Path: Delivered-To: current@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 3DC89D47; Thu, 17 Jan 2013 17:46:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 38503691; Thu, 17 Jan 2013 17:46:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA14810; Thu, 17 Jan 2013 19:46:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TvtXU-0000Mc-H6; Thu, 17 Jan 2013 19:46:08 +0200 Message-ID: <50F838DE.6080908@FreeBSD.org> Date: Thu, 17 Jan 2013 19:46:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Sergey V. Dyatko" Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A References: <20130117200234.416338fb@laptop> In-Reply-To: <20130117200234.416338fb@laptop> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:46:12 -0000 on 17/01/2013 19:02 Sergey V. Dyatko said the following: > Hi, > > today I got panic on my laptop, running head, amd64 r245462. > unfortunately I don't know how it can be reproduced so I will be > grateful for any hints > > full core-file can be found here: > http://svn.freebsd.by/files/core20130117.txt Do you have a real core file (vmcore*)? > Konstantin, I added you to CC because you was last touched > zfs_vfsops.c, I'm sorry if I was wrong :) > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 17:50:34 2013 Return-Path: Delivered-To: current@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 30E1BEAE for ; Thu, 17 Jan 2013 17:50:34 +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 9FC626BE for ; Thu, 17 Jan 2013 17:50:33 +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 r0HHoQTg090841; Thu, 17 Jan 2013 19:50:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0HHoQTg090841 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0HHoPtm090840; Thu, 17 Jan 2013 19:50:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Jan 2013 19:50:25 +0200 From: Konstantin Belousov To: "Sergey V. Dyatko" Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A Message-ID: <20130117175025.GR2522@kib.kiev.ua> References: <20130117200234.416338fb@laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SWsnvgFfkTS2ATo5" Content-Disposition: inline In-Reply-To: <20130117200234.416338fb@laptop> 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: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:50:34 -0000 --SWsnvgFfkTS2ATo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 08:02:34PM +0300, Sergey V. Dyatko wrote: > Hi, >=20 > today I got panic on my laptop, running head, amd64 r245462. > unfortunately I don't know how it can be reproduced so I will be > grateful for any hints >=20 > full core-file can be found here: > http://svn.freebsd.by/files/core20130117.txt >=20 > Konstantin, I added you to CC because you was last touched > zfs_vfsops.c, I'm sorry if I was wrong :) I doubt that it is related. My change only modified the vnode created for zfs inode, not zfs inode itself. Your panic indicates some zfs structures corruption. --SWsnvgFfkTS2ATo5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ+DngAAoJEJDCuSvBvK1BK9wP/1J2Sm8eTVHfVHKZ0DzIqf04 ssRO+mmaKkPmM/dstys6emuhCDYc74gaLPem1x7e6w+CPZu2DqOnLx9UXViSNwyN xHGyPgoN5WazJEWbyLl2JUP67Fl16zmNlOhfmGMjcg0e/a3MjHZsTSq5a831BKQ4 +uiHQ4i5GS0xThoSo98CpJ6ob9vV9UmZXK6BMfPBO8Sr4jEp1jraXyBq/lMsqI6U pZgO8bhfu1RPHN+ts6L+scR08+LTk2f1ew58Mx23gEmvqHPqN4YebtNYfbUGYSXm otRsWMFja6fJOzLumFbEfKo4z8iws/eMznXfB536zvhcOqx65ziWz175HHocU5Zv Rx7dFtHAr40IkHstJG4yeKBlv9jUzZNaUugCIQZaFSoYXPdV/4jOmYlSCDX7nYp5 3sRW5I5KmCi8rePMxIPNP4fNluyowaAfYGn7+v9ieAmWxlzHGQ4oixsHeSdesV63 XzmcyK0qxC59owk2qtBKIGMb3jRAA2k+/YMynmmZGAbh+GlDBxRushsZqXMpHEYz C+mpbBJFWlIlvoxoZbtEhDX+KTywamaiYmdwbmdD+YDd5pAW40sf3azx2IRLWBJt h2Gh3cR6+XkqVgWeM722aNMlxhPW2j2yH/i2kEXxrRx76C8Od0DRlSVw/AweDCUZ lNkDOgbUyUTatUs4qOku =AhWy -----END PGP SIGNATURE----- --SWsnvgFfkTS2ATo5-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 17:52:26 2013 Return-Path: Delivered-To: current@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 78320FE1; Thu, 17 Jan 2013 17:52:26 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id BFD576E4; Thu, 17 Jan 2013 17:52:25 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a12so1099816eaa.27 for ; Thu, 17 Jan 2013 09:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=Bu+JN5aaiwWDCrPBNGg3yVipnZBxhaDyF2V6QC29JDE=; b=KlHi+bUCQQlqjvn1abrE1yi9zkmmsZrbJfxnZJF0uFsHaOCr400RU39WDauS0qZcvq vxVdXLOiuLdfeFbnCzrfHbwClZ8T2KUZqLBDZDK98Rb5On5bxEq4JLQIV/oRwJrZ8+1f XiiqDhJEPCSblFIZjmaxyQt602Ka/ZGqoS6u7WleqKLQFGiGsPlDFVGj7m5BAbgzJkoC P5bRPo+AHsOcsJnUdDKqrRk3w7w3uwAbu36wCEIMIs/mzlujA04EGqhZvnrRyMEEO03F UHG9jElu4AiZoEOLTceySF/TqAPYkoEILbUliDCKMHDdECh4UV+gH2K9HCc+0JixY00L M+qg== X-Received: by 10.14.173.69 with SMTP id u45mr16214693eel.21.1358445139549; Thu, 17 Jan 2013 09:52:19 -0800 (PST) Received: from laptop ([178.125.240.29]) by mx.google.com with ESMTPS id z8sm3485445eeo.11.2013.01.17.09.52.18 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:52:18 -0800 (PST) Date: Thu, 17 Jan 2013 20:52:17 +0300 From: "Sergey V. Dyatko" To: Andriy Gapon Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A Message-ID: <20130117205217.63bd5969@laptop> In-Reply-To: <50F838DE.6080908@FreeBSD.org> References: <20130117200234.416338fb@laptop> <50F838DE.6080908@FreeBSD.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:52:26 -0000 On Thu, 17 Jan 2013 19:46:06 +0200 Andriy Gapon wrote: > on 17/01/2013 19:02 Sergey V. Dyatko said the following: > > Hi, > > > > today I got panic on my laptop, running head, amd64 r245462. > > unfortunately I don't know how it can be reproduced so I will be > > grateful for any hints > > > > full core-file can be found here: > > http://svn.freebsd.by/files/core20130117.txt > > Do you have a real core file (vmcore*)? > yes > > Konstantin, I added you to CC because you was last touched > > zfs_vfsops.c, I'm sorry if I was wrong :) > > > > -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 18:29:04 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76CDCC8C; Thu, 17 Jan 2013 18:29:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 62CBA88F; Thu, 17 Jan 2013 18:29:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA15126; Thu, 17 Jan 2013 20:29:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TvuCy-0000QT-JV; Thu, 17 Jan 2013 20:29:00 +0200 Message-ID: <50F842EB.6000209@FreeBSD.org> Date: Thu, 17 Jan 2013 20:28:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Sergey V. Dyatko" Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A References: <20130117200234.416338fb@laptop> <50F838DE.6080908@FreeBSD.org> <20130117205217.63bd5969@laptop> In-Reply-To: <20130117205217.63bd5969@laptop> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:29:04 -0000 on 17/01/2013 19:52 Sergey V. Dyatko said the following: > On Thu, 17 Jan 2013 19:46:06 +0200 > Andriy Gapon wrote: > >> on 17/01/2013 19:02 Sergey V. Dyatko said the following: >>> Hi, >>> >>> today I got panic on my laptop, running head, amd64 r245462. >>> unfortunately I don't know how it can be reproduced so I will be >>> grateful for any hints >>> >>> full core-file can be found here: >>> http://svn.freebsd.by/files/core20130117.txt >> >> Do you have a real core file (vmcore*)? >> > yes In frame 5 please do 'p *dn', in frame 4 please do 'i args', 'i local'. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 18:37:44 2013 Return-Path: Delivered-To: current@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 03DF722D; Thu, 17 Jan 2013 18:37:44 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3AA900; Thu, 17 Jan 2013 18:37:43 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a14so1163783eaa.37 for ; Thu, 17 Jan 2013 10:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=h0TEnHiWuPmw45ixvhmFGySPqhwAZ/fBGt2x02JR9Gk=; b=cfaSTa26WAGt3m/5IkuR/pTFqKfnTqFtNPlNG7XVIcb/h12X9sK8jQqpxBmguakdNl z/iy81QhINrS8dosv6fv3a64Ja1YOVsnthDS7FwUSNZga3ssM2+E5TSE+Ng93ErL7yIF 8JLjZZlIJIxP84BE0q9XoLaiJcpfSxrTHtWs+CXibxf8j0Cy0EdcHGyeGf+nD9JllWQ2 cfsfmKB0ucbVJgsaeildF/1hIzktO8uX08qo4j1A0YMyavJ4x42lREPfxBeGQD4PgiJg 6ipSiMBWWMbhBX4g71QJCsHoj14pCjZGw+pbhZVBHdjeuSHpFaeYg8XJopUq1HXcXYS5 xujg== X-Received: by 10.14.209.131 with SMTP id s3mr16492143eeo.28.1358447862233; Thu, 17 Jan 2013 10:37:42 -0800 (PST) Received: from laptop ([178.125.240.29]) by mx.google.com with ESMTPS id b49sm3665808eem.16.2013.01.17.10.37.41 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 10:37:41 -0800 (PST) Date: Thu, 17 Jan 2013 21:37:39 +0300 From: "Sergey V. Dyatko" To: Andriy Gapon Subject: Re: panic: solaris assert: sa.sa_magic == 0x2F505A Message-ID: <20130117213739.545e06f1@laptop> In-Reply-To: <50F842EB.6000209@FreeBSD.org> References: <20130117200234.416338fb@laptop> <50F838DE.6080908@FreeBSD.org> <20130117205217.63bd5969@laptop> <50F842EB.6000209@FreeBSD.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:37:44 -0000 On Thu, 17 Jan 2013 20:28:59 +0200 Andriy Gapon wrote: > on 17/01/2013 19:52 Sergey V. Dyatko said the following: > > On Thu, 17 Jan 2013 19:46:06 +0200 > > Andriy Gapon wrote: > > > >> on 17/01/2013 19:02 Sergey V. Dyatko said the following: > >>> Hi, > >>> > >>> today I got panic on my laptop, running head, amd64 r245462. > >>> unfortunately I don't know how it can be reproduced so I will be > >>> grateful for any hints > >>> > >>> full core-file can be found here: > >>> http://svn.freebsd.by/files/core20130117.txt > >> > >> Do you have a real core file (vmcore*)? > >> > > yes > > In frame 5 please do 'p *dn', in frame 4 please do 'i args', 'i > local'. > http://svn.freebsd.by/files/kgdb_over_email.txt p.s. look at irc client (rusnet) :) -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 19:50:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34885C7A; Thu, 17 Jan 2013 19:50:35 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id DAA00DB2; Thu, 17 Jan 2013 19:50:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=fuDfaYiyG4lQGzg9GZXjOAYcBfJcgUsGgpLXYou8gsA=; b=etSpzxeJ9+NJPlGkrq44QgFR3hK98kjztUwbfUEK7toSeMZo+mKwfLbQct8PG/Um4jsuSpAgtFomA8e+xQWj4GVeHg0Sp2qQdmStHKeft/dwRdumD9T7B+an+Yi5amu8FDGVqsa57j4ZHzKmtgExJ/9rFsa3wVPVWC/T4nzYNl8=; Received: from localhost.lerctr.org ([127.0.0.1]:39885 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TvvTo-000HGT-Gn; Thu, 17 Jan 2013 13:50:32 -0600 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 17 Jan 2013 13:50:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Jan 2013 13:50:28 -0600 From: Larry Rosenman To: , Subject: My panic in amd64/pmap Message-ID: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.4 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:50:35 -0000 I've now seen this panic: pmap_insert_pt_page: pindex already inserted on 9.1-RELEASE, 9.1-STABLE, and 10.0-CURRENT I've got vmcore's from the 9.1-STABLE and 10.0-CURRENT VM's available as well as sources. I have the core.txt.* files available at: http://www.lerctr.org/~ler/core.txt.0 (10.0) http://www.lerctr.org/~ler/core.txt.2 (9.1-S) I'm not sure what other debug info you need. I can provide SSH access to both VM's as well as the host. These are all in VirtualBox 4.2.6 VM's Any help would be appreciated. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 21:22:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CBC65EB for ; Thu, 17 Jan 2013 21:22:15 +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 457D9188 for ; Thu, 17 Jan 2013 21:22:15 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8C072B953 for ; Thu, 17 Jan 2013 16:22:14 -0500 (EST) From: John Baldwin To: current@freebsd.org Subject: [PATCH] Adjust 'ps H' to include kthread names by default Date: Thu, 17 Jan 2013 16:22:09 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301171622.09624.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 Jan 2013 16:22:14 -0500 (EST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:22:15 -0000 Running 'ps axH' on a current system results in a lot of kthreads with not very useful names (unless you add -c): PID TT STAT TIME COMMAND 0 ?? DLs 1:09.52 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 0:03.82 [kernel] 0 ?? DLs 1:15.14 [kernel] 0 ?? DLs 0:00.00 [kernel] 0 ?? DLs 39:24.55 [kernel] 0 ?? DLs 0:00.04 [kernel] This patch changes this to: PID TT STAT TIME COMMAND 0 ?? DLs 1:09.53 [kernel/swapper] 0 ?? DLs 0:00.00 [kernel/firmware tas] 0 ?? DLs 0:00.00 [kernel/ffs_trim tas] 0 ?? DLs 0:00.00 [kernel/acpi_task_0] 0 ?? DLs 0:00.00 [kernel/acpi_task_1] 0 ?? DLs 0:00.00 [kernel/acpi_task_2] 0 ?? DLs 0:00.00 [kernel/aiod_bio tas] 0 ?? DLs 0:03.82 [kernel/thread taskq] 0 ?? DLs 1:15.19 [kernel/nvidia taskq] 0 ?? DLs 0:00.00 [kernel/kqueue taskq] 0 ?? DLs 39:26.82 [kernel/em0 taskq] 0 ?? DLs 0:00.04 [kernel/mca taskq] In theory this will affect any process for which an argv can't be fetched, but in practice it mostly helps with kthreads. Index: ps.c =================================================================== --- ps.c (revision 245225) +++ ps.c (working copy) @@ -141,7 +141,7 @@ static void *expand_list(struct listinfo *); static const char * fmt(char **(*)(kvm_t *, const struct kinfo_proc *, int), - KINFO *, char *, int); + KINFO *, char *, char *, int); static void free_list(struct listinfo *); static void init_list(struct listinfo *, addelem_rtn, int, const char *); static char *kludge_oldps_options(const char *, char *, const char *); @@ -1163,11 +1163,12 @@ static const char * fmt(char **(*fn)(kvm_t *, const struct kinfo_proc *, int), KINFO *ki, - char *comm, int maxlen) + char *comm, char *thread, int maxlen) { const char *s; - s = fmt_argv((*fn)(kd, ki->ki_p, termwidth), comm, maxlen); + s = fmt_argv((*fn)(kd, ki->ki_p, termwidth), comm, + ki->ki_p->ki_numthreads > 1 ? thread : NULL, maxlen); return (s); } @@ -1195,7 +1196,7 @@ ki->ki_args = strdup(""); else if (UREADOK(ki) || (ki->ki_p->ki_args != NULL)) ki->ki_args = strdup(fmt(kvm_getargv, ki, - ki->ki_p->ki_comm, MAXCOMLEN)); + ki->ki_p->ki_comm, ki->ki_p->ki_tdname, MAXCOMLEN)); else asprintf(&ki->ki_args, "(%s)", ki->ki_p->ki_comm); if (ki->ki_args == NULL) @@ -1206,7 +1207,7 @@ if (needenv) { if (UREADOK(ki)) ki->ki_env = strdup(fmt(kvm_getenvv, ki, - (char *)NULL, 0)); + (char *)NULL, (char *)NULL, 0)); else ki->ki_env = strdup("()"); if (ki->ki_env == NULL) Index: fmt.c =================================================================== --- fmt.c (revision 245225) +++ fmt.c (working copy) @@ -105,7 +105,7 @@ } const char * -fmt_argv(char **argv, char *cmd, size_t maxlen) +fmt_argv(char **argv, char *cmd, char *thread, size_t maxlen) { size_t len; char *ap, *cp; @@ -122,9 +122,14 @@ cp = malloc(len); if (cp == NULL) errx(1, "malloc failed"); - if (ap == NULL) - sprintf(cp, "[%.*s]", (int)maxlen, cmd); - else if (strncmp(cmdpart(argv[0]), cmd, maxlen) != 0) + if (ap == NULL) { + if (showthreads && thread != NULL) { + asprintf(&ap, "%s/%s", cmd, thread); + sprintf(cp, "[%.*s]", (int)maxlen, ap); + free(ap); + } else + sprintf(cp, "[%.*s]", (int)maxlen, cmd); + } else if (strncmp(cmdpart(argv[0]), cmd, maxlen) != 0) sprintf(cp, "%s (%.*s)", ap, (int)maxlen, cmd); else strcpy(cp, ap); Index: extern.h =================================================================== --- extern.h (revision 245225) +++ extern.h (working copy) @@ -51,7 +51,7 @@ char *elapseds(KINFO *, VARENT *); char *emulname(KINFO *, VARENT *); VARENT *find_varentry(VAR *); -const char *fmt_argv(char **, char *, size_t); +const char *fmt_argv(char **, char *, char *, size_t); double getpcpu(const KINFO *); char *kvar(KINFO *, VARENT *); char *label(KINFO *, VARENT *); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 21:47:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED22C1CA; Thu, 17 Jan 2013 21:47:48 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by mx1.freebsd.org (Postfix) with ESMTP id B88BA2B6; Thu, 17 Jan 2013 21:47:48 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.84,488,1355119200"; d="scan'208";a="16017360" Message-ID: <50F8713F.1030200@vangyzen.net> Date: Thu, 17 Jan 2013 15:46:39 -0600 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Adjust 'ps H' to include kthread names by default References: <201301171622.09624.jhb@freebsd.org> In-Reply-To: <201301171622.09624.jhb@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:47:49 -0000 On 01/17/2013 15:22, John Baldwin wrote: > Running 'ps axH' on a current system results in a lot of kthreads with not > very useful names (unless you add -c): > > PID TT STAT TIME COMMAND > 0 ?? DLs 1:09.52 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:03.82 [kernel] > 0 ?? DLs 1:15.14 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 39:24.55 [kernel] > 0 ?? DLs 0:00.04 [kernel] > > This patch changes this to: > > PID TT STAT TIME COMMAND > 0 ?? DLs 1:09.53 [kernel/swapper] > 0 ?? DLs 0:00.00 [kernel/firmware tas] > 0 ?? DLs 0:00.00 [kernel/ffs_trim tas] > 0 ?? DLs 0:00.00 [kernel/acpi_task_0] > 0 ?? DLs 0:00.00 [kernel/acpi_task_1] > 0 ?? DLs 0:00.00 [kernel/acpi_task_2] > 0 ?? DLs 0:00.00 [kernel/aiod_bio tas] > 0 ?? DLs 0:03.82 [kernel/thread taskq] > 0 ?? DLs 1:15.19 [kernel/nvidia taskq] > 0 ?? DLs 0:00.00 [kernel/kqueue taskq] > 0 ?? DLs 39:26.82 [kernel/em0 taskq] > 0 ?? DLs 0:00.04 [kernel/mca taskq] > > In theory this will affect any process for which an argv can't be fetched, but > in practice it mostly helps with kthreads. Yes, please, and thank you. The patch looks fine to me. > Index: ps.c > =================================================================== > --- ps.c (revision 245225) > +++ ps.c (working copy) > @@ -141,7 +141,7 @@ > static void *expand_list(struct listinfo *); > static const char * > fmt(char **(*)(kvm_t *, const struct kinfo_proc *, int), > - KINFO *, char *, int); > + KINFO *, char *, char *, int); > static void free_list(struct listinfo *); > static void init_list(struct listinfo *, addelem_rtn, int, const char *); > static char *kludge_oldps_options(const char *, char *, const char *); > @@ -1163,11 +1163,12 @@ > > static const char * > fmt(char **(*fn)(kvm_t *, const struct kinfo_proc *, int), KINFO *ki, > - char *comm, int maxlen) > + char *comm, char *thread, int maxlen) > { > const char *s; > > - s = fmt_argv((*fn)(kd, ki->ki_p, termwidth), comm, maxlen); > + s = fmt_argv((*fn)(kd, ki->ki_p, termwidth), comm, > + ki->ki_p->ki_numthreads > 1 ? thread : NULL, maxlen); > return (s); > } > > @@ -1195,7 +1196,7 @@ > ki->ki_args = strdup(""); > else if (UREADOK(ki) || (ki->ki_p->ki_args != NULL)) > ki->ki_args = strdup(fmt(kvm_getargv, ki, > - ki->ki_p->ki_comm, MAXCOMLEN)); > + ki->ki_p->ki_comm, ki->ki_p->ki_tdname, MAXCOMLEN)); > else > asprintf(&ki->ki_args, "(%s)", ki->ki_p->ki_comm); > if (ki->ki_args == NULL) > @@ -1206,7 +1207,7 @@ > if (needenv) { > if (UREADOK(ki)) > ki->ki_env = strdup(fmt(kvm_getenvv, ki, > - (char *)NULL, 0)); > + (char *)NULL, (char *)NULL, 0)); > else > ki->ki_env = strdup("()"); > if (ki->ki_env == NULL) > Index: fmt.c > =================================================================== > --- fmt.c (revision 245225) > +++ fmt.c (working copy) > @@ -105,7 +105,7 @@ > } > > const char * > -fmt_argv(char **argv, char *cmd, size_t maxlen) > +fmt_argv(char **argv, char *cmd, char *thread, size_t maxlen) > { > size_t len; > char *ap, *cp; > @@ -122,9 +122,14 @@ > cp = malloc(len); > if (cp == NULL) > errx(1, "malloc failed"); > - if (ap == NULL) > - sprintf(cp, "[%.*s]", (int)maxlen, cmd); > - else if (strncmp(cmdpart(argv[0]), cmd, maxlen) != 0) > + if (ap == NULL) { > + if (showthreads && thread != NULL) { > + asprintf(&ap, "%s/%s", cmd, thread); > + sprintf(cp, "[%.*s]", (int)maxlen, ap); > + free(ap); > + } else > + sprintf(cp, "[%.*s]", (int)maxlen, cmd); > + } else if (strncmp(cmdpart(argv[0]), cmd, maxlen) != 0) > sprintf(cp, "%s (%.*s)", ap, (int)maxlen, cmd); > else > strcpy(cp, ap); > Index: extern.h > =================================================================== > --- extern.h (revision 245225) > +++ extern.h (working copy) > @@ -51,7 +51,7 @@ > char *elapseds(KINFO *, VARENT *); > char *emulname(KINFO *, VARENT *); > VARENT *find_varentry(VAR *); > -const char *fmt_argv(char **, char *, size_t); > +const char *fmt_argv(char **, char *, char *, size_t); > double getpcpu(const KINFO *); > char *kvar(KINFO *, VARENT *); > char *label(KINFO *, VARENT *); > > From owner-freebsd-current@FreeBSD.ORG Thu Jan 17 22:15:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB16BD78 for ; Thu, 17 Jan 2013 22:15:56 +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 9A95D8B5 for ; Thu, 17 Jan 2013 22:15:56 +0000 (UTC) Received: from unknowna826d93748ea.att.net (99-127-230-127.lightspeed.sntcca.sbcglobal.net [99.127.230.127]) by elvis.mu.org (Postfix) with ESMTPSA id 240011A3C33 for ; Thu, 17 Jan 2013 14:15:56 -0800 (PST) Message-ID: <50F87819.3060605@mu.org> Date: Thu, 17 Jan 2013 14:15:53 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [PATCH] Adjust 'ps H' to include kthread names by default References: <201301171622.09624.jhb@freebsd.org> In-Reply-To: <201301171622.09624.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 22:15:56 -0000 On 1/17/13 1:22 PM, John Baldwin wrote: > Running 'ps axH' on a current system results in a lot of kthreads with not > very useful names (unless you add -c): > > PID TT STAT TIME COMMAND > 0 ?? DLs 1:09.52 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 0:03.82 [kernel] > 0 ?? DLs 1:15.14 [kernel] > 0 ?? DLs 0:00.00 [kernel] > 0 ?? DLs 39:24.55 [kernel] > 0 ?? DLs 0:00.04 [kernel] > > This patch changes this to: > > PID TT STAT TIME COMMAND > 0 ?? DLs 1:09.53 [kernel/swapper] > 0 ?? DLs 0:00.00 [kernel/firmware tas] > 0 ?? DLs 0:00.00 [kernel/ffs_trim tas] > 0 ?? DLs 0:00.00 [kernel/acpi_task_0] > 0 ?? DLs 0:00.00 [kernel/acpi_task_1] > 0 ?? DLs 0:00.00 [kernel/acpi_task_2] > 0 ?? DLs 0:00.00 [kernel/aiod_bio tas] > 0 ?? DLs 0:03.82 [kernel/thread taskq] > 0 ?? DLs 1:15.19 [kernel/nvidia taskq] > 0 ?? DLs 0:00.00 [kernel/kqueue taskq] > 0 ?? DLs 39:26.82 [kernel/em0 taskq] > 0 ?? DLs 0:00.04 [kernel/mca taskq] Nice! Looks good. -Alfred From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 05:45:49 2013 Return-Path: Delivered-To: freebsd-current@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 69D1BECC for ; Fri, 18 Jan 2013 05:45:49 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id E6780E2C for ; Fri, 18 Jan 2013 05:45:48 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id r0I5jlOs017896 for ; Fri, 18 Jan 2013 14:45:47 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id r0I5jka16587 for ; Fri, 18 Jan 2013 14:45:46 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id r0I5jkwN024042; Fri, 18 Jan 2013 14:45:46 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id r0I5jksA024022; Fri, 18 Jan 2013 14:45:46 +0900 Date: Fri, 18 Jan 2013 14:45:38 +0900 (JST) Message-Id: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> To: freebsd-current@FreeBSD.org Subject: deadlock between g_event and a thread on removing a device. From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 05:45:49 -0000 Hi, When I removed a device (ex. /dev/da0), I have encounterd a dead-lock between ``g_event'' thread and a thread that is opening device file (I call this thread as A). Would you refer the following? When the device is removed between dev_refthread() and g_dev_open(), thread A incremented dev->si_threadcount, but can't acquire topology_lock. On the other hand, g_event is waiting to set dev->si_threadcount to 0 with topology_lock. Regards, Kohji Okuno <<< Thread A >>> ... devfs_open() { ... dsw = dev_refthread(dev, &ref); <= increment dev->si_threadcount ... error = dsw->d_open(...); <= call g_dev_open() ... dev_relthread(dev, ref); <= decrement dev->si_threadcount } g_dev_open() { ... g_topology_lock(); <= Thread A couldn't acquire ... topology_lock. } <<< g_event >>> g_run_events() { ... g_topology_lock(); <= g_event acuired topology_lock here. ... one_event() ... } one_event() g_orphan_register() g_dev_orphan() destroy_dev() destroy_dev() destroy_devl() { ... while (dev->si_threadcount != 0) { <= this count was incremented by Thread A /* Use unique dummy wait ident */ msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); } ... } From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 07:51:33 2013 Return-Path: Delivered-To: freebsd-current@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 1771FC2D for ; Fri, 18 Jan 2013 07:51:33 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id CE7B526E for ; Fri, 18 Jan 2013 07:51:32 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1Tw6Ua-0003sn-LI for freebsd-current@FreeBSD.org; Fri, 18 Jan 2013 09:36:00 +0200 Date: Fri, 18 Jan 2013 09:36:00 +0200 From: Vitalij Satanivskij To: freebsd-current@FreeBSD.org Subject: panic after r244584 Message-ID: <20130118073600.GA70874@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 07:51:33 -0000 Hello. After upgrading server from old hardware/software to freebsd current (## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/245479), system hung's with message - panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) Screen shot can be found here - http://quad.org.ua/IMAG0055.jpg Old system was 8.2-STABLE FreeBSD 8.2-STABLE All hardware, except drive from massive, was changed. Drives has gpt label's and belong to zfs pool. For now we back to more old version of freebsd (HEAD dated Nov 26 2012). As I undertand problem with white space in si_name, so - are any way to fix this problem?. Intresting that 3 another servers with same version freebsd and hardware was modified without problem's; Another question - how/where I can see si_name for my devices on running system? From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 08:30:21 2013 Return-Path: Delivered-To: current@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 7933CBC0; Fri, 18 Jan 2013 08:30:21 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7CF3647; Fri, 18 Jan 2013 08:30:20 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a12so1391988eaa.13 for ; Fri, 18 Jan 2013 00:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=viSMj4aRh/1IE42UoqEln4bB7zZNkRFfdPtxjfUbm2U=; b=ZyrvKV2icFWbjDpmcOR4PfEeYtJU4q7EiFaR0MrLD7nee+8XnJZQ35OHS8Z6XqNTKI sIAgAjnmJdmSUd57reyjTI1AWHsrNAGNlPosh3eaEBmGRn0jxRDQVI5l2dPGA/ErJh8F q3m55v2Ubw4mSs7gNw8GavCfUNJMYWTEOPM4QwmLAqvjw88bAtTfnFuVnfigd1KfkMkY 3TSoas9lkAO4G6sQC9Kc31Rul4xb+Y7F+vcXFJkTyrdufPpPRgweACkONRLRyV0R/Axt P5FKZfGxNzVEtyeJfEx66jXL9WoP0OvnFilDFbMfAnhY3GEgMdXJn/fnD2dWbq/KkKk+ vWVA== X-Received: by 10.14.202.3 with SMTP id c3mr23917094eeo.4.1358497819847; Fri, 18 Jan 2013 00:30:19 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id l3sm6277712een.14.2013.01.18.00.30.18 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 18 Jan 2013 00:30:19 -0800 (PST) Date: Fri, 18 Jan 2013 11:30:17 +0300 From: "Sergey V. Dyatko" To: Subject: buildworld is broken ? Message-ID: <20130118113017.4932e9e7@laptop> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jkim@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 08:30:21 -0000 Hi, subj head, amd64 Revision: 245588 protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmopcode.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 Stop in /usr/src/usr.sbin/acpi. *** [all] Error code 1 Stop in /usr/src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 09:44:32 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06417BA9; Fri, 18 Jan 2013 09:44:32 +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 88FF5A24; Fri, 18 Jan 2013 09:44:30 +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 r0I9iOxo007300; Fri, 18 Jan 2013 13:44:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r0I9iOmd007299; Fri, 18 Jan 2013 13:44:24 +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, 18 Jan 2013 13:44:24 +0400 From: Gleb Smirnoff To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130118094424.GD2331@FreeBSD.org> References: <20130118073600.GA70874@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130118073600.GA70874@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 09:44:32 -0000 On Fri, Jan 18, 2013 at 09:36:00AM +0200, Vitalij Satanivskij wrote: V> Hello. V> V> After upgrading server from old hardware/software to freebsd current (## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/245479), V> system hung's with message - V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) EINVAL (22) is caused by space character in the si_name: si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7 ^ I think Alexander (in Cc) has idea on why did that happen and how should that be fixed. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:39:36 2013 Return-Path: Delivered-To: freebsd-current@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 7BA6F806; Fri, 18 Jan 2013 11:39:36 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id D9133C; Fri, 18 Jan 2013 11:39:35 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TwAII-000FmS-7w ; Fri, 18 Jan 2013 13:39:34 +0200 Date: Fri, 18 Jan 2013 13:39:34 +0200 From: Vitalij Satanivskij To: Alexander Motin Subject: Re: panic after r244584 Message-ID: <20130118113934.GA60441@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F93165.60809@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jh@freebsd.org, Vitalij Satanivskij , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: satan@ukr.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:39:36 -0000 Alexander Motin wrote: AM> On 18.01.2013 11:44, Gleb Smirnoff wrote: AM> > On Fri, Jan 18, 2013 at 09:36:00AM +0200, Vitalij Satanivskij wrote: AM> > V> After upgrading server from old hardware/software to freebsd current (## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/245479), AM> > V> system hung's with message - AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) AM> > AM> > EINVAL (22) is caused by space character in the si_name: AM> > AM> > si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7 AM> > AM> > I think Alexander (in Cc) has idea on why did that happen and how AM> > should that be fixed. AM> AM> The panic is triggered by the check added by the recent r244584 change. AM> The space in device name came from the enclosure device, and I guess it AM> may be quite often situation. Using human readable name supposed to help AM> system administrators, but with spaces banned that may be a problem. AM> That's was not created by human, it was generated (I think so) by system. May be problem not in r244584 at all but in incorect generation of the si_name ? More info drive (actualy drives, all 36 have same problem) inserted in backplane on supermicro chasis with "LSI CORP SAS2X36 0417" on board. All of them attached to lsi sas 9211-4i controler in HBA mode. From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:44:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A55E2B42; Fri, 18 Jan 2013 11:44:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by mx1.freebsd.org (Postfix) with ESMTP id DEAB2B9; Fri, 18 Jan 2013 11:44:03 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id j5so1920006bkw.40 for ; Fri, 18 Jan 2013 03:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tf9h1qcLsoKTIaeeFucptiuCeQdW4mtPZloAjNejNF4=; b=e+6/z1/9c31YZDGW09LTj2DvBcJb7c52zaHYfac0xHqREbeM0V3yFewtb75O7z6pXh xhs8OufAXsRUdJCAG2rAzFCz6Z8P0o9Rn66iFAzXqoW9iip6KcRW4mQuvtuZYNIdXYSn 8TNZlGGGZSWWWfmI3thdDs4P/U8BrPxSRoc23xWOlu/Du0fmEQRiNJJrIzieU+TEJViN 0rNC++rHrgqWzQu1H5MIdSxHRFnx0NxRUqwHt6eXSMpXlKSNEHo6PC0PdCk4LHkP9xpZ BB0FKD/ElY/WEjZ6AaUt6cSJEfU1IHB4RybyUKSAFWVMaQTS699Dh+edou+KxxFWtu9O zjHg== X-Received: by 10.204.150.137 with SMTP id y9mr2409540bkv.103.1358509442616; Fri, 18 Jan 2013 03:44:02 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o7sm3511392bkv.13.2013.01.18.03.44.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 03:44:01 -0800 (PST) Sender: Alexander Motin Message-ID: <50F9357F.8040109@FreeBSD.org> Date: Fri, 18 Jan 2013 13:43:59 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: satan@ukr.net Subject: Re: panic after r244584 References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> In-Reply-To: <20130118113934.GA60441@hell.ukr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jh@freebsd.org, Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:44:04 -0000 On 18.01.2013 13:39, Vitalij Satanivskij wrote: > Alexander Motin wrote: > AM> On 18.01.2013 11:44, Gleb Smirnoff wrote: > AM> > On Fri, Jan 18, 2013 at 09:36:00AM +0200, Vitalij Satanivskij wrote: > AM> > V> After upgrading server from old hardware/software to freebsd current (## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/245479), > AM> > V> system hung's with message - > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > AM> > > AM> > EINVAL (22) is caused by space character in the si_name: > AM> > > AM> > si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7 > AM> > > AM> > I think Alexander (in Cc) has idea on why did that happen and how > AM> > should that be fixed. > AM> > AM> The panic is triggered by the check added by the recent r244584 change. > AM> The space in device name came from the enclosure device, and I guess it > AM> may be quite often situation. Using human readable name supposed to help > AM> system administrators, but with spaces banned that may be a problem. > > That's was not created by human, it was generated (I think so) by system. These strings are flashed into enclosure firmware by manufacturer. > May be problem not in r244584 at all but in incorect generation of the si_name ? May be. But before r244584 it didn't cause panics and most of people were happy, except devctl consumers, who can't parse these events properly. > More info > > drive (actualy drives, all 36 have same problem) inserted in backplane on supermicro chasis with "LSI CORP SAS2X36 0417" on board. > > All of them attached to lsi sas 9211-4i controler in HBA mode. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:47:15 2013 Return-Path: Delivered-To: current@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 C879BD9D; Fri, 18 Jan 2013 11:47:15 +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 409B2E8; Fri, 18 Jan 2013 11:47:14 +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 r0IBlDHe008086; Fri, 18 Jan 2013 15:47:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id r0IBlDcG008085; Fri, 18 Jan 2013 15:47:13 +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, 18 Jan 2013 15:47:13 +0400 From: Gleb Smirnoff To: "Sergey V. Dyatko" Subject: Re: buildworld is broken ? Message-ID: <20130118114713.GH2331@FreeBSD.org> References: <20130118113017.4932e9e7@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130118113017.4932e9e7@laptop> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org, jkim@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:47:15 -0000 On Fri, Jan 18, 2013 at 11:30:17AM +0300, Sergey V. Dyatko wrote: S> subj S> head, amd64 Revision: 245588 Works for me: Revision: 245593 Last Changed Rev: 245584 Last Changed Date: 2013-01-18 06:36:06 +0400 (ÐÔ, 18 ÑÎ× 2013) Also, there is not tinderbox complaints on the mailing list. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:49:27 2013 Return-Path: Delivered-To: freebsd-current@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 69AD1ECC; Fri, 18 Jan 2013 11:49:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by mx1.freebsd.org (Postfix) with ESMTP id A91C3108; Fri, 18 Jan 2013 11:49:26 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id j4so1934815bkw.34 for ; Fri, 18 Jan 2013 03:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l1AQB+dVAHYI+9U73rbl3scEQd1Wqu3f2TtLYZfMQFA=; b=QPOiCdvXRXjpJkDYHOmQuqD2es3aI1Z26ctuWadwvc+QhT+98NmW+doa6Dfz0lej3G dHwXz6Wxs0s9q5X3aEa4xzXF9nZ4Rk9jY0V7H9FY53QmZnxxgtU1gcqEm3Z7m8s3HyKc ZtnbxH+0J9rnUUXyYYvhKsS6ZHoPyqgX3z5rBDmbeEmHlgCwfQFyfrrHk0ZiRkl55GrX UlP70S1FAG2MrvQLOudftCB19zJbN+R4Nji4ylm9nLJ1s2a78c1Fpy9TbVCdggSvSaIo ruSL22qn4LUkrxF/fqBur0HV+qjwPGTZxEFxa6JpqoFxHO1UB35V4WCrKKVDw3laomnA 7C7w== X-Received: by 10.204.130.210 with SMTP id u18mr2344591bks.129.1358508393538; Fri, 18 Jan 2013 03:26:33 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id e22sm3458778bke.14.2013.01.18.03.26.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 03:26:32 -0800 (PST) Sender: Alexander Motin Message-ID: <50F93165.60809@FreeBSD.org> Date: Fri, 18 Jan 2013 13:26:29 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: panic after r244584 References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> In-Reply-To: <20130118094424.GD2331@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Vitalij Satanivskij , freebsd-current@FreeBSD.org, jh@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:49:27 -0000 On 18.01.2013 11:44, Gleb Smirnoff wrote: > On Fri, Jan 18, 2013 at 09:36:00AM +0200, Vitalij Satanivskij wrote: > V> After upgrading server from old hardware/software to freebsd current (## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/245479), > V> system hung's with message - > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > > EINVAL (22) is caused by space character in the si_name: > > si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7 > > I think Alexander (in Cc) has idea on why did that happen and how > should that be fixed. The panic is triggered by the check added by the recent r244584 change. The space in device name came from the enclosure device, and I guess it may be quite often situation. Using human readable name supposed to help system administrators, but with spaces banned that may be a problem. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:55:45 2013 Return-Path: Delivered-To: current@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 1F538D0; Fri, 18 Jan 2013 11:55:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EC61A152; Fri, 18 Jan 2013 11:55:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0IBtbfT098061; Fri, 18 Jan 2013 06:55:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0IBtbia098054; Fri, 18 Jan 2013 11:55:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Jan 2013 11:55:37 GMT Message-Id: <201301181155.r0IBtbia098054@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:55:45 -0000 TB --- 2013-01-18 10:27:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-18 10:27:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-18 10:27:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-18 10:27:26 - cleaning the object tree TB --- 2013-01-18 10:27:26 - /usr/local/bin/svn stat /src TB --- 2013-01-18 10:27:29 - At svn revision 245589 TB --- 2013-01-18 10:27:30 - building world TB --- 2013-01-18 10:27:30 - CROSS_BUILD_TESTING=YES TB --- 2013-01-18 10:27:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-18 10:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-18 10:27:30 - SRCCONF=/dev/null TB --- 2013-01-18 10:27:30 - TARGET=ia64 TB --- 2013-01-18 10:27:30 - TARGET_ARCH=ia64 TB --- 2013-01-18 10:27:30 - TZ=UTC TB --- 2013-01-18 10:27:30 - __MAKE_CONF=/dev/null TB --- 2013-01-18 10:27:30 - cd /src TB --- 2013-01-18 10:27:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 18 10:27:34 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmbuffer.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmdeferred.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmnames.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmopcode.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /src/usr.sbin/acpi/iasl. *** [all] Error code 1 Stop in /src/usr.sbin/acpi. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-18 11:55:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-18 11:55:37 - ERROR: failed to build world TB --- 2013-01-18 11:55:37 - 4029.16 user 947.42 system 5290.92 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 12:09:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11EB39BC; Fri, 18 Jan 2013 12:09:36 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1E807280; Fri, 18 Jan 2013 12:09:34 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id gj3so2676542lbb.11 for ; Fri, 18 Jan 2013 04:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=InzoZ1ptPeSppmSLrii4V+gUkjKyFV6CTPtVFvJWpR8=; b=NSciawposB7EmfRfah5YUrb2Zp0MCUtw7HXBW+MqeH4URTxZj5M7ZCCtFKJ/HB24+j GSpKP/TJsHugvW5SzJQCjfZaL58+Pvw5sTHX7Oq9ta4otq8YgaNJUUc1Zz6AaQY7JDGQ x7lTh5dJTF0zKaaNM/C/jly2F7kyjogfhhORt9EqzDFCWhaRsmVow7MlNl9NQ6FfIZ/H sq8eZh+cpkmM5/AtAmA6YcoQaINWYyIaG7irYQ73TZ5H7PcL2fmEAI5x2gLtcwpGHwea NeJTPKYiUDZDmTWkV44xkLNROptfU7zIihla/ehiVO8lkye8GPI0IDrpH2dLoLxwWRIe /bcQ== X-Received: by 10.152.144.71 with SMTP id sk7mr8217488lab.29.1358510485130; Fri, 18 Jan 2013 04:01:25 -0800 (PST) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id ox6sm1932929lab.16.2013.01.18.04.01.23 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 18 Jan 2013 04:01:24 -0800 (PST) Date: Fri, 18 Jan 2013 15:01:21 +0300 From: "Sergey V. Dyatko" To: Gleb Smirnoff Subject: Re: buildworld is broken ? Message-ID: <20130118150121.3d36ced6@laptop> In-Reply-To: <20130118114713.GH2331@FreeBSD.org> References: <20130118113017.4932e9e7@laptop> <20130118114713.GH2331@FreeBSD.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: current@FreeBSD.org, jkim@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 12:09:36 -0000 On Fri, 18 Jan 2013 15:47:13 +0400 Gleb Smirnoff wrote: > On Fri, Jan 18, 2013 at 11:30:17AM +0300, Sergey V. Dyatko wrote: > S> subj > S> head, amd64 Revision: 245588 > > Works for me: > > Revision: 245593 > Last Changed Rev: 245584 > Last Changed Date: 2013-01-18 06:36:06 +0400 (ÐÔ, 18 ÑÎ× 2013) > strange :( laptop# cd /usr/src/usr.sbin/acpi/iasl laptop# make cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. > Also, there is not tinderbox complaints on the mailing list. > Subject: [head tinderbox] failure on ia64/ia64 Date: Fri, 18 Jan 2013 11:55:37 GMT -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 11:11:38 2013 Return-Path: Delivered-To: freebsd-current@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 8FED5180; Fri, 18 Jan 2013 11:11:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.freebsd.org (Postfix) with ESMTP id B86BCF10; Fri, 18 Jan 2013 11:11:37 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail27.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r0IBBIhL001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 22:11:20 +1100 Date: Fri, 18 Jan 2013 22:11:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: [RFC/RFT] calloutng In-Reply-To: <1358432027.32417.213.camel@revolution.hippie.lan> Message-ID: <20130118202123.Y1839@besplex.bde.org> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <20130106152313.GD26039@alchemy.franken.de> <50EBF921.2000304@FreeBSD.org> <20130113180940.GM26039@alchemy.franken.de> <50F30CAB.3000001@FreeBSD.org> <20130114102118.V1045@besplex.bde.org> <1358432027.32417.213.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zty1sKHG c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=mUAV9h2nInsA:10 a=_K3Ihd90oorLvW07haYA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 X-Mailman-Approved-At: Fri, 18 Jan 2013 12:48:22 +0000 Cc: Davide Italiano , Alexander Motin , freebsd-arch@freebsd.org, FreeBSD Current , Bruce Evans , Marius Strobl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:11:38 -0000 On Thu, 17 Jan 2013, Ian Lepore wrote: > On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote: >> Er, timecounters are called with a spin mutex held in existing code: >> though it is dangerous to do so, timecounters are called from fast >> interrupt handlers for very timekeeping-critical purposes: >> - to implement the TIOCTIMESTAMP ioctl (except this is broken in >> -current). This was a primitive version of pps timestamping. >> - for pps timestamping. The interrupt handler (which should be a fast >> interrupt handler to minimize latency) calls pps_capture() which >> calls tc_get_timecount() and does other "lock-free" accesses to the >> timecounter state. This still works in -current (at least there is >> still code for it). > > Unfortunately, calling pps_capture() in the primary interrupt context is > no longer an option with the stock pps driver. Ever since the ppbus > rewrite all ppbus children must use threaded handlers. I tried to fix > that a couple different ways, and both ended up with crazy-complex code Hmm, I didn't notice that ppc supported pps (I try not to look at it since it is ugly :-), and don't know of any version of it that uses non-threaded handlers (except in FreeBSD-4 before, where normal interrupt handlers were non-threaded, so ppc had their high latency but not the even higher latency and overheads of threaded handlers). OTOH, my x86 RTC interrupt handler is threaded and supports pps, and I haven't noticed any latency problems with this. It just can't possibly give the < ~1 usec jitter that FreeBSD-[3-4] could give ~15 years ago using a fast interrupt handler (there must be only 1 device using a fast interrupt handler, with this dedicated to pps, else the multiple fast interrupt handlers will give latency much larger than ~1 usec to each other. I don't actually use this for anything except testing whether the RTC can be used for a poor man's pps. > scattered around the ppbus family just to support the rarely-used pps > capture. It would have been easier to do if filter and threaded > interrupt handlers had the same function signature. > > I ended up writting a separate driver that can be used instead of ppc + > ppbus + pps, since anyone who cares about precise pps capture is > unlikely to be sharing the port with a printer or plip device or some > such. Probably all pps handlers should be special. On x86 with reasonable timecounter hardware, say a TSC, it takes about 10 instructions for an entire pps interrupt handler: XintrN: pushl %eax pushl %edx rdtsc # Need some ugliness for EIO here or later. ss:movl %eax,ppscap # Hopefully lock-free via time-domain locking. ss:movl %edx,ppscap+4 popl %edx popl %eax iret After capturing the timecounter hardware value here, you convert it to a pps event at leisure. But since this only happens once per second, it wouldn't be very inefficient to turn the interrupt handler into a slow high-latency one, even a threaded one, to handle the pps event and/or other devices attached to the interrupt. >> OTOH, all drivers that call pps_capture() from their interrupt handler >> then immediately call pps_event(). This has always been very broken, >> and became even more broken with SMPng. pps_event() does many more >> timecounter and pps accesses whose locking is unclear at best, and >> in some configurations it calls hardpps(), which is only locked by >> Giant, despite comments in kern_ntptime.c still saying that it (and >> many other functions in kern_ntptime.c) must be called at splclock() >> or higher. splclock() is of course now null, but the locking >> requirements in kern_ntptime.c haven't changed much. kern_ntptime.c >> always needed to be locked by the equivalent of a spin mutex, which >> is stronger locking than was given by splclock(). pps_event() would >> have to aquire the spin mutex before calling hardpps(), although >> this is bad for fast interrupt handlers. The correct implementation >> is probably to only do the capture part from fast interrupt handlers. > > In my rewritten dedicated pps driver I call pps_capture() from the > filter handler and pps_event() from the threaded handler. I never found That seems right. > any good documentation on the low-level details of this stuff, and there > isn't enough good example code to work from. My hazy memory is that I THere seem to be no good examples. > ended up studying the pps_capture() and pps_event() code enough to infer > that their design intent seems to be to allow you to capture with no > locking and do the event processing later in some sort of deferred or > threaded context. That seems to be the design, but there are no examples of separating the event from the capture. I think the correct locking is: - capture in a fast interrupt handler, into a per-device state that is locked by whatever locks all of the state accessed by the fast interrupt handler - switch to a less critical context later: - lock this step agains reentrance from itself - re-acquire the fast interrupt handler's lock, as strictly necessary to access the state locked by that, and copy it to local state. Release the fast interrupt handler's lock. This locking can probably be skipped since the capture only happens once per second and it is possible to arrange doing this step somewhere in between the captures, but that would be more complicated and fragile. - acquire the lock that protects all the state accessed by pps_event(). This is currently Giant for at least the hardpps() parts. This restricts the contexts that can call pps_capture(). Of course, kern_ntptime.c should use finer locking than Giant, so as to not restrict its callers so much. Its Giant locking is also violated by calling ntp_update_second() from the tc_windup() filter. It's surprising that the races here are so rarely harmful that no one has reported them being lost. Maybe they are only lost on leap seconds synchronized with new moons. >> ... >> The spinlock in the i8254 timecounter certainly breaks some cases. >> For example, suppose the lock is held for a timecounter read from >> normal context. It masks hardware interrupts on the current CPU (except >> in my version). It doesn't mask NMIs or other traps. So if the NMI >> or other trap handler does a timecounter hardware call, there is >> deadlock in at least the !SMP case. In my version, it blocks normal >> interrupts later if they occur, but doesn't block fast interrupts, so >> the pps_capture() call would deadlock if it occurs, like a timecounter >> call from an NMI. I avoid this by not using pps in any fast interrupt >> handler, and by only using the i8254 timecounter for testing. I do >> use pps in a (nonstandard) x86 RTC clock interrupt handler. My clock >> interrupt handlers are all non-fast to avoid this and other locking >> problems. > > Hrm, now you've got me a bit worried about capturing in the primary > context. Not that I have much option, on a 300mhz Geode and similar > wimpy embedded processors there's enough latency on a theaded handler > that the pps signal can be de-asserted by time the handler runs > (precision timing gear often outputs a very narrow pps pulse, 1 - 10uS > isn't uncommon). This reminds me that the old Centronics printer interface has similar timing. This caused "lost" printer interrupts on x86 (due to the 8259 not latching them?), and the polling to recover from this was handled poorly by drivers in 386BSD and Linux. If the hardware does latch things, then there would still be a problem determining if the interrupt is for you if it is shared. In the Centronics interface mapped to x86, the interrupt signal can be polled for, but it is of course hard to see since it is short. > I know I don't have to worry about NMIs on the systems in question, but > I'm not so sure about "other trap handler". There aren't many except machine check and debugger traps on x86. Ones like pagefaults shouldn't occur while holding locks. Bruce From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 13:20:01 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B452E63; Fri, 18 Jan 2013 13:20:01 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 4C30E7D3; Fri, 18 Jan 2013 13:20:01 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 0C997139811; Fri, 18 Jan 2013 15:19:55 +0200 (EET) Date: Fri, 18 Jan 2013 15:19:54 +0200 From: Jaakko Heinonen To: Alexander Motin Subject: Re: panic after r244584 Message-ID: <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F9357F.8040109@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net, Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:20:01 -0000 On 2013-01-18, Alexander Motin wrote: > > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > > AM> The panic is triggered by the check added by the recent r244584 change. > > AM> The space in device name came from the enclosure device, and I guess it > > AM> may be quite often situation. Using human readable name supposed to help > > AM> system administrators, but with spaces banned that may be a problem. > > > > That's was not created by human, it was generated (I think so) by system. > > These strings are flashed into enclosure firmware by manufacturer. You can't rely on that any string can be safely used as a device name even if spaces were allowed. Consider for example duplicate names and "../". Where these names are generated? The original report didn't contain a backtrace. -- Jaakko From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 13:26:35 2013 Return-Path: Delivered-To: freebsd-current@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 E9624BF; Fri, 18 Jan 2013 13:26:35 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by mx1.freebsd.org (Postfix) with ESMTP id 9996B81D; Fri, 18 Jan 2013 13:26:34 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id q16so2024454bkw.19 for ; Fri, 18 Jan 2013 05:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dLNygEFn0AjhS3K2QkqS1Oi9ORCYYsUDQz4qvKQyI40=; b=ADYDYamILmn1Po5rrFnB+90X2ia9yhasMPi/ES/tUdfnqEbRHpQeo+n3/qXtKKatfI eRj+a01hbobREbmJDBcS79qlh68tx483l1oSufGFy1E33dXgTFMUkEnmRFLS/yL1nrZQ 60Z1WpP97cQKTaBBrU2fxu6JUTn1PBauIM0QXSndJisw0rIb7xkZuhK/mkJ+KE83hBzH 1ZQe/gHqGWzd2vnOIuInK2i26ZVc3RfvTsBK+gECuJAnwm5p2tA188IuhqC7xE5u3dOY dPOq4rKo7WXg1YYax5IcQT8wWADcAWpgPjtKYyNpQVrorDUkhQtcIMUnoj5soEGpG6bk PnuA== X-Received: by 10.204.148.134 with SMTP id p6mr2453836bkv.75.1358515588382; Fri, 18 Jan 2013 05:26:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id f24sm3825786bkv.7.2013.01.18.05.26.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 05:26:27 -0800 (PST) Sender: Alexander Motin Message-ID: <50F94D80.7000809@FreeBSD.org> Date: Fri, 18 Jan 2013 15:26:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jaakko Heinonen Subject: Re: panic after r244584 References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> In-Reply-To: <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Justin T. Gibbs" , satan@ukr.net, Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:26:36 -0000 On 18.01.2013 15:19, Jaakko Heinonen wrote: > On 2013-01-18, Alexander Motin wrote: >>> AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > >>> AM> The panic is triggered by the check added by the recent r244584 change. >>> AM> The space in device name came from the enclosure device, and I guess it >>> AM> may be quite often situation. Using human readable name supposed to help >>> AM> system administrators, but with spaces banned that may be a problem. >>> >>> That's was not created by human, it was generated (I think so) by system. >> >> These strings are flashed into enclosure firmware by manufacturer. > > You can't rely on that any string can be safely used as a device name > even if spaces were allowed. Consider for example duplicate names and > "../". > > Where these names are generated? The original report didn't contain a > backtrace. At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are impossible there, as previous name components are unique. Special characters haven't yet seen, but I think theoretically possible. Interesting what Solaris does in such cases, mangles them somehow or removes completely? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 13:34:19 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22A7C36E; Fri, 18 Jan 2013 13:34:19 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 12C8B879; Fri, 18 Jan 2013 13:34:18 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TwC5H-0001uC-Az ; Fri, 18 Jan 2013 15:34:15 +0200 Date: Fri, 18 Jan 2013 15:34:15 +0200 From: Vitalij Satanivskij To: Jaakko Heinonen Subject: Re: panic after r244584 Message-ID: <20130118133415.GA7189@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net, Alexander Motin , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:34:19 -0000 Jaakko Heinonen wrote: JH> On 2013-01-18, Alexander Motin wrote: JH> > > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) JH> JH> > > AM> The panic is triggered by the check added by the recent r244584 change. JH> > > AM> The space in device name came from the enclosure device, and I guess it JH> > > AM> may be quite often situation. Using human readable name supposed to help JH> > > AM> system administrators, but with spaces banned that may be a problem. JH> > > JH> > > That's was not created by human, it was generated (I think so) by system. JH> > JH> > These strings are flashed into enclosure firmware by manufacturer. JH> JH> You can't rely on that any string can be safely used as a device name JH> even if spaces were allowed. Consider for example duplicate names and JH> "../". JH> JH> Where these names are generated? The original report didn't contain a JH> backtrace. Yes. No backtrace, because of switching off all debuging in kernel. For now I can't use that's server for testing, but there are another servers waiting for upgrade. I will try to reproduce problem with kernel debuger enabled. From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 13:49:56 2013 Return-Path: Delivered-To: freebsd-current@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 D0DD7674; Fri, 18 Jan 2013 13:49:56 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2064E91E; Fri, 18 Jan 2013 13:49:56 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TwCKQ-00023U-JL ; Fri, 18 Jan 2013 15:49:54 +0200 Date: Fri, 18 Jan 2013 15:49:54 +0200 From: Vitalij Satanivskij To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130118134954.GA7848@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <20130118133415.GA7189@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130118133415.GA7189@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jaakko Heinonen , Alexander Motin , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 13:49:56 -0000 May be just do sanitizing for elmpriv->descr? something like change whitespace to "_" or just delete it? Vitalij Satanivskij wrote: VS> Jaakko Heinonen wrote: VS> JH> On 2013-01-18, Alexander Motin wrote: VS> JH> > > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) VS> JH> VS> JH> > > AM> The panic is triggered by the check added by the recent r244584 change. VS> JH> > > AM> The space in device name came from the enclosure device, and I guess it VS> JH> > > AM> may be quite often situation. Using human readable name supposed to help VS> JH> > > AM> system administrators, but with spaces banned that may be a problem. VS> JH> > > VS> JH> > > That's was not created by human, it was generated (I think so) by system. VS> JH> > VS> JH> > These strings are flashed into enclosure firmware by manufacturer. VS> JH> VS> JH> You can't rely on that any string can be safely used as a device name VS> JH> even if spaces were allowed. Consider for example duplicate names and VS> JH> "../". VS> JH> VS> JH> Where these names are generated? The original report didn't contain a VS> JH> backtrace. VS> VS> Yes. No backtrace, because of switching off all debuging in kernel. VS> VS> For now I can't use that's server for testing, but there are another servers waiting for upgrade. VS> VS> I will try to reproduce problem with kernel debuger enabled. VS> VS> VS> _______________________________________________ VS> freebsd-current@freebsd.org mailing list VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 14:17:17 2013 Return-Path: Delivered-To: freebsd-current@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 AC625B09; Fri, 18 Jan 2013 14:17:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C3F2AA45; Fri, 18 Jan 2013 14:17:16 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA21697; Fri, 18 Jan 2013 16:17:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50F95964.6060706@FreeBSD.org> Date: Fri, 18 Jan 2013 16:17:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Larry Rosenman Subject: Re: My panic in amd64/pmap References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> In-Reply-To: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 14:17:17 -0000 on 17/01/2013 21:50 Larry Rosenman said the following: > I've now seen this panic: > pmap_insert_pt_page: pindex already inserted > > on 9.1-RELEASE, 9.1-STABLE, and 10.0-CURRENT > > I've got vmcore's from the 9.1-STABLE and 10.0-CURRENT VM's available > as well as sources. > > I have the core.txt.* files available at: > http://www.lerctr.org/~ler/core.txt.0 (10.0) > http://www.lerctr.org/~ler/core.txt.2 (9.1-S) > > I'm not sure what other debug info you need. > > I can provide SSH access to both VM's as well as the host. > > These are all in VirtualBox 4.2.6 VM's > > Any help would be appreciated. Hmm, I wonder if VirtualBox is hitting the same popcnt bug that was fixed in qemu... Could you please try a patch from here http://thread.gmane.org/gmane.comp.emulators.qemu/174532/focus=174567 ? It should be applied to src/recompiler/target-i386/translate.c, make sure that it goes to a section marked as 'case 0x1b8: /* SSE4.2 popcnt */'. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:09:27 2013 Return-Path: Delivered-To: freebsd-current@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 5542AF8D; Fri, 18 Jan 2013 15:09:27 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 22098EA1; Fri, 18 Jan 2013 15:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=4MYdPDN/oJvYmTfoMM8U+qs/PK+O0jir6HG6LVq0zHY=; b=gAMlefbkivRiGGpSBmbGRs6YAXIymIzLDKXJN4XTVKj26mzZZFaf+1b3IIYHafXGqzozEFrjeIOQnaYmrFpQEjKYyZ73GJReRbvNAxuVTaKrfHeJSaFbCdCxTvVElkmHbdUPm5pyQm4mQcyCg2uTFuAt4npjWHBjpyJ9AvpATRU=; Received: from localhost.lerctr.org ([127.0.0.1]:62358 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TwDZN-0000L3-Mq; Fri, 18 Jan 2013 09:09:26 -0600 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 18 Jan 2013 09:09:25 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Jan 2013 09:09:25 -0600 From: Larry Rosenman To: Andriy Gapon Subject: Re: My panic in amd64/pmap In-Reply-To: <50F95964.6060706@FreeBSD.org> References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> Message-ID: <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.4 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:09:27 -0000 On 2013-01-18 08:17, Andriy Gapon wrote: > on 17/01/2013 21:50 Larry Rosenman said the following: >> I've now seen this panic: >> pmap_insert_pt_page: pindex already inserted >> >> on 9.1-RELEASE, 9.1-STABLE, and 10.0-CURRENT >> >> I've got vmcore's from the 9.1-STABLE and 10.0-CURRENT VM's >> available >> as well as sources. >> >> I have the core.txt.* files available at: >> http://www.lerctr.org/~ler/core.txt.0 (10.0) >> http://www.lerctr.org/~ler/core.txt.2 (9.1-S) >> >> I'm not sure what other debug info you need. >> >> I can provide SSH access to both VM's as well as the host. >> >> These are all in VirtualBox 4.2.6 VM's >> >> Any help would be appreciated. > > Hmm, I wonder if VirtualBox is hitting the same popcnt bug that was > fixed in qemu... > > Could you please try a patch from here > http://thread.gmane.org/gmane.comp.emulators.qemu/174532/focus=174567 > ? > > It should be applied to src/recompiler/target-i386/translate.c, make > sure that it > goes to a section marked as 'case 0x1b8: /* SSE4.2 popcnt */'. Should this be on the host or the guest? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:11:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78CE81E0; Fri, 18 Jan 2013 15:11:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by mx1.freebsd.org (Postfix) with ESMTP id A8992EC4; Fri, 18 Jan 2013 15:11:02 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jf20so2064213bkc.2 for ; Fri, 18 Jan 2013 07:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2DB98MW0QQecxFngd0FGNvThYTOxY/Z6IoNcXpONCco=; b=WK3fyWAVFQjNGo31ZcTceonDygQuPlaH+goyEOrZZPPPVp/Ls8C9oFVS+Fyw5wTety htJUdCF+J62N4dEk9JBVK9C1LSq6ofSraV4NM/TKCtWRhhggtglJFR8rRoTs9u7BrZiA OX53kCYqKlqoS2/G8HWd9gAlhcq/EJq7jV42HXX6trT3+BVMxH+4TfeKw7a9EoaMlZzr tS+8+Vlj92SAm6wCMjuOUQqAHdOwy6xNuvq3ctZWQJBMR1ZJ/aicVC+B1KXvTMPoVtOK t1swNXOou6IDgbTc3VoysHhu8kRPY11yG0DopvpE3W202DZyP74YZ4rNMoF0RipaITkO JjWw== X-Received: by 10.204.12.202 with SMTP id y10mr2716307bky.51.1358521861629; Fri, 18 Jan 2013 07:11:01 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id q22sm4167884bkv.16.2013.01.18.07.10.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 07:11:00 -0800 (PST) Sender: Alexander Motin Message-ID: <50F96602.2090903@FreeBSD.org> Date: Fri, 18 Jan 2013 17:10:58 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vitalij Satanivskij Subject: Re: panic after r244584 References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <20130118133415.GA7189@hell.ukr.net> <20130118134954.GA7848@hell.ukr.net> In-Reply-To: <20130118134954.GA7848@hell.ukr.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jaakko Heinonen , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:11:03 -0000 On 18.01.2013 15:49, Vitalij Satanivskij wrote: > May be just do sanitizing for elmpriv->descr? > > something like change whitespace to "_" or just delete it? Yes, that is not difficult. The only question is how to stay consistent, compatible, user-readable. > Vitalij Satanivskij wrote: > VS> Jaakko Heinonen wrote: > VS> JH> On 2013-01-18, Alexander Motin wrote: > VS> JH> > > AM> > V> panic: make_dev_alias_v: bad si_name (error=22 si_name=enc@n5003048000bab37d/tpe0/slot@1/elmdesc@Slot 01/pass7) > VS> JH> > VS> JH> > > AM> The panic is triggered by the check added by the recent r244584 change. > VS> JH> > > AM> The space in device name came from the enclosure device, and I guess it > VS> JH> > > AM> may be quite often situation. Using human readable name supposed to help > VS> JH> > > AM> system administrators, but with spaces banned that may be a problem. > VS> JH> > > > VS> JH> > > That's was not created by human, it was generated (I think so) by system. > VS> JH> > > VS> JH> > These strings are flashed into enclosure firmware by manufacturer. > VS> JH> > VS> JH> You can't rely on that any string can be safely used as a device name > VS> JH> even if spaces were allowed. Consider for example duplicate names and > VS> JH> "../". > VS> JH> > VS> JH> Where these names are generated? The original report didn't contain a > VS> JH> backtrace. > VS> > VS> Yes. No backtrace, because of switching off all debuging in kernel. > VS> > VS> For now I can't use that's server for testing, but there are another servers waiting for upgrade. > VS> > VS> I will try to reproduce problem with kernel debuger enabled. > VS> > VS> > VS> _______________________________________________ > VS> freebsd-current@freebsd.org mailing list > VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current > VS> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:19:25 2013 Return-Path: Delivered-To: freebsd-current@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 D5F724AD; Fri, 18 Jan 2013 15:19:25 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id 505AFF1B; Fri, 18 Jan 2013 15:19:25 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TwDj1-0002uZ-Lt ; Fri, 18 Jan 2013 17:19:23 +0200 Date: Fri, 18 Jan 2013 17:19:23 +0200 From: Vitalij Satanivskij To: Alexander Motin Subject: Re: panic after r244584 Message-ID: <20130118151923.GA11174@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <20130118133415.GA7189@hell.ukr.net> <20130118134954.GA7848@hell.ukr.net> <50F96602.2090903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F96602.2090903@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Gleb Smirnoff , freebsd-current@FreeBSD.org, Jaakko Heinonen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:19:25 -0000 Alexander Motin wrote: AM> On 18.01.2013 15:49, Vitalij Satanivskij wrote: AM> > May be just do sanitizing for elmpriv->descr? AM> > AM> > something like change whitespace to "_" or just delete it? AM> AM> Yes, that is not difficult. The only question is how to stay consistent, AM> compatible, user-readable. AM> Ok, now I have kernel dump kgdb /boot/kernel/kernel vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: da0 at mps0 bus 0 scbus7 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) panic: make_dev_alias_v: bad si_name (error=22, si_name=enc@n5003048000baa87d/type@0/slot@a/elmdesc@Slot 10/pass7) cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9b9ec84760 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9b9ec84810 vpanic() at vpanic+0x127/frame 0xffffff9b9ec84850 panic() at panic+0x43/frame 0xffffff9b9ec848b0 make_dev_alias_v() at make_dev_alias_v+0x1d0/frame 0xffffff9b9ec84900 make_dev_alias_p() at make_dev_alias_p+0x37/frame 0xffffff9b9ec84960 make_dev_physpath_alias() at make_dev_physpath_alias+0x14a/frame 0xffffff9b9ec849c0 pass_add_physpath() at pass_add_physpath+0xbd/frame 0xffffff9b9ec849f0 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xffffff9b9ec84a40 taskqueue_thread_loop() at taskqueue_thread_loop+0x6c/frame 0xffffff9b9ec84a70 fork_exit() at fork_exit+0x84/frame 0xffffff9b9ec84ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff9b9ec84ab0 --- trap 0, rip = 0, rsp = 0xffffff9b9ec84b70, rbp = 0 --- KDB: enter: panic From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:20:29 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CFBF6E5; Fri, 18 Jan 2013 15:20:29 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) by mx1.freebsd.org (Postfix) with ESMTP id BE382F40; Fri, 18 Jan 2013 15:20:28 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1TwDk3-0002vK-Tn ; Fri, 18 Jan 2013 17:20:27 +0200 Date: Fri, 18 Jan 2013 17:20:27 +0200 From: Vitalij Satanivskij To: Vitalij Satanivskij Subject: Re: panic after r244584 Message-ID: <20130118152027.GB11174@hell.ukr.net> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <20130118133415.GA7189@hell.ukr.net> <20130118134954.GA7848@hell.ukr.net> <50F96602.2090903@FreeBSD.org> <20130118151923.GA11174@hell.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130118151923.GA11174@hell.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jaakko Heinonen , Alexander Motin , Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:20:29 -0000 Vitalij Satanivskij wrote: VS> Alexander Motin wrote: VS> AM> On 18.01.2013 15:49, Vitalij Satanivskij wrote: VS> AM> > May be just do sanitizing for elmpriv->descr? VS> AM> > VS> AM> > something like change whitespace to "_" or just delete it? VS> AM> VS> AM> Yes, that is not difficult. The only question is how to stay consistent, VS> AM> compatible, user-readable. VS> AM> VS> VS> Ok, now I have kernel dump VS> VS> kgdb /boot/kernel/kernel vmcore.0 VS> GNU gdb 6.1.1 [FreeBSD] VS> Copyright 2004 Free Software Foundation, Inc. VS> GDB is free software, covered by the GNU General Public License, and you are VS> welcome to change it and/or distribute copies of it under certain conditions. VS> Type "show copying" to see the conditions. VS> There is absolutely no warranty for GDB. Type "show warranty" for details. VS> This GDB was configured as "amd64-marcel-freebsd"... VS> VS> Unread portion of the kernel message buffer: VS> da0 at mps0 bus 0 scbus7 target 8 lun 0 VS> da0: Fixed Direct Access SCSI-6 device VS> da0: 300.000MB/s transfers VS> da0: Command Queueing enabled VS> da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) VS> panic: make_dev_alias_v: bad si_name (error=22, si_name=enc@n5003048000baa87d/type@0/slot@a/elmdesc@Slot 10/pass7) VS> cpuid = 0 VS> KDB: stack backtrace: VS> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9b9ec84760 VS> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9b9ec84810 VS> vpanic() at vpanic+0x127/frame 0xffffff9b9ec84850 VS> panic() at panic+0x43/frame 0xffffff9b9ec848b0 VS> make_dev_alias_v() at make_dev_alias_v+0x1d0/frame 0xffffff9b9ec84900 VS> make_dev_alias_p() at make_dev_alias_p+0x37/frame 0xffffff9b9ec84960 VS> make_dev_physpath_alias() at make_dev_physpath_alias+0x14a/frame 0xffffff9b9ec849c0 VS> pass_add_physpath() at pass_add_physpath+0xbd/frame 0xffffff9b9ec849f0 VS> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xffffff9b9ec84a40 VS> taskqueue_thread_loop() at taskqueue_thread_loop+0x6c/frame 0xffffff9b9ec84a70 VS> fork_exit() at fork_exit+0x84/frame 0xffffff9b9ec84ab0 VS> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff9b9ec84ab0 VS> --- trap 0, rip = 0, rsp = 0xffffff9b9ec84b70, rbp = 0 --- VS> KDB: enter: panic VS> VS> And of couse (kgdb) bt #0 doadump (textdump=0) at pcpu.h:229 #1 0xffffffff8034002e in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0xffffffff8033fada in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff8033f892 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff80342240 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff808b9753 in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80c0d3b8 in trap (frame=0xffffff9b9ec84740) at /usr/src/sys/amd64/amd64/trap.c:579 #7 0xffffffff80bf6512 in calltrap () at exception.S:228 #8 0xffffffff808b8f3e in kdb_enter (why=0xffffffff80e7adb1 "panic", msg=) at cpufunc.h:63 #9 0xffffffff80885a47 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:746 #10 0xffffffff80885ab3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:682 #11 0xffffffff8083add0 in make_dev_alias_v (flags=, cdev=0xfffffe0031b78cd0, pdev=, fmt=, ap=0xffffff9b9ec84940) at /usr/src/sys/kern/kern_conf.c:925 #12 0xffffffff8083ae27 in make_dev_alias_p (flags=-1631041792, cdev=0x80, pdev=0xffffffff80e72a0a, fmt=0x80
) at /usr/src/sys/kern/kern_conf.c:968 #13 0xffffffff8083af7a in make_dev_physpath_alias (flags=8, cdev=0xfffffe0031b78cd0, pdev=0xfffffe042bb8f000, old_alias=0x0, physpath=) at /usr/src/sys/kern/kern_conf.c:1025 #14 0xffffffff80308b7d in pass_add_physpath (context=0xfffffe04fe563a00, pending=) at /usr/src/sys/cam/scsi/scsi_pass.c:258 #15 0xffffffff808c8050 in taskqueue_run_locked (queue=0xfffffe002fddf800) at /usr/src/sys/kern/subr_taskqueue.c:312 #16 0xffffffff808c87ec in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:501 #17 0xffffffff80855444 in fork_exit (callout=0xffffffff808c8780 , arg=0xffffffff81502690, frame=0xffffff9b9ec84ac0) at /usr/src/sys/kern/kern_fork.c:991 #18 0xffffffff80bf6a4e in fork_trampoline () at exception.S:602 #19 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) what next I can do to investigate problem? From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:28:30 2013 Return-Path: Delivered-To: freebsd-current@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 635EBB50; Fri, 18 Jan 2013 15:28:30 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19E05FD3; Fri, 18 Jan 2013 15:28:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=xeBTeOUYjd3wEfxbYiuV5wf9fCAwc7CoG6pxgLGyiHQ=; b=jlvWyhXvGckM0UUf8xL8Vy4LYaU2qf5NVAGqRM4WpWlygF27nCMc4u/pawRooGiNwxD1XXWD+8H2G7+C8pw4fO93E9L41ETWtDAeAHnWuEvaOzFlD99+pzMXiJ7VmZUMJbbPB3r3AsxeovTd25qffiSeF5ZsVBZ2Fy2Xr92Iq5I=; Received: from localhost.lerctr.org ([127.0.0.1]:40876 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TwDro-0000oB-OP; Fri, 18 Jan 2013 09:28:29 -0600 Received: from [32.97.110.60] by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 18 Jan 2013 09:28:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Jan 2013 09:28:28 -0600 From: Larry Rosenman To: Andriy Gapon Subject: Re: My panic in amd64/pmap In-Reply-To: <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.org> References: <38def6b37be1a3128fb1b64595e9044e@webmail.lerctr.org> <50F95964.6060706@FreeBSD.org> <6f1d46304fbcc6e32f51109f6ab4c60d@webmail.lerctr.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/0.8.4 X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:28:30 -0000 On 2013-01-18 09:09, Larry Rosenman wrote: > On 2013-01-18 08:17, Andriy Gapon wrote: >> on 17/01/2013 21:50 Larry Rosenman said the following: >>> I've now seen this panic: >>> pmap_insert_pt_page: pindex already inserted >>> >>> on 9.1-RELEASE, 9.1-STABLE, and 10.0-CURRENT >>> >>> I've got vmcore's from the 9.1-STABLE and 10.0-CURRENT VM's >>> available >>> as well as sources. >>> >>> I have the core.txt.* files available at: >>> http://www.lerctr.org/~ler/core.txt.0 (10.0) >>> http://www.lerctr.org/~ler/core.txt.2 (9.1-S) >>> >>> I'm not sure what other debug info you need. >>> >>> I can provide SSH access to both VM's as well as the host. >>> >>> These are all in VirtualBox 4.2.6 VM's >>> >>> Any help would be appreciated. >> >> Hmm, I wonder if VirtualBox is hitting the same popcnt bug that was >> fixed in qemu... >> >> Could you please try a patch from here >> >> http://thread.gmane.org/gmane.comp.emulators.qemu/174532/focus=174567 >> ? >> >> It should be applied to src/recompiler/target-i386/translate.c, make >> sure that it >> goes to a section marked as 'case 0x1b8: /* SSE4.2 popcnt */'. > > Should this be on the host or the guest? Never mind, it's in VirtualBox itself. The line is at ~~line 8020 in the same file. I've patched it and am recompiling VirtualBox. If I don't see the panic for a few days, I'll submit a PR. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 15:29:47 2013 Return-Path: Delivered-To: freebsd-current@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 769ACD05 for ; Fri, 18 Jan 2013 15:29:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CB90CFF9 for ; Fri, 18 Jan 2013 15:29:46 +0000 (UTC) Received: (qmail 54728 invoked from network); 18 Jan 2013 16:51:56 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Jan 2013 16:51:56 -0000 Message-ID: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 16:29:43 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers Subject: kmem_map auto-sizing and size dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:29:47 -0000 The autotuning work is reaching into many places of the kernel and while trying to tie up all lose ends I've got stuck in the kmem_map and how it works or what its limitations are. During startup the VM is initialized and an initial kernel virtual memory map is setup in kmem_init() covering the entire KVM address range. Only the kernel itself is actually allocated within that map. A bit later on a number of other submaps are allocated (clean_map, buffer_map, pager_map, exec_map). Also in kmeminit() (in kern_malloc.c, different from kmem_init) the kmem_map is allocated. The (inital?) size of the kmem_map is determined by some voodoo magic, a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. However it seems to work out to an effective kmem_map_size of about 58MB on my 16GB AMD64 dev machine: vm.kvm_size: 549755809792 vm.kvm_free: 530233421824 vm.kmem_size: 16,594,300,928 vm.kmem_size_min: 0 vm.kmem_size_max: 329,853,485,875 vm.kmem_size_scale: 1 vm.kmem_map_size: 59,518,976 vm.kmem_map_free: 16,534,777,856 The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing else that uses UMA for memory allocation. Mbuf memory too is managed by UMA which obtains the backing kernel memory from the kmem_map. The limits of the various mbuf memory types have been considerably raised recently and may make use of 50-75% of all physically present memory, or available KVM space, whichever is smaller. Now my questions/comments are: Does the kmem_map automatically extend itself if more memory is requested? Should it be set to a larger initial value based on min(physical,KVM) space available? The use of nmbclusters for the initial kmem_map size calculation isn't appropriate anymore due to it being set up later and nmbclusters isn't the only mbuf relevant mbuf type. We make significant use of page sized mbuf clusters too. The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is confusing and not easy to reconcile. Either we need some more detailing more aspects or less. Plus perhaps sysctl subtrees to better describe the hierarchy of the maps. Why are separate kmem submaps being used? Is it to limit memory usage of certain subsystems? Are those limits actually enforced? -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 16:25:06 2013 Return-Path: Delivered-To: freebsd-current@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 B081B202; Fri, 18 Jan 2013 16:25:06 +0000 (UTC) (envelope-from alan.l.cox@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 DBE7D389; Fri, 18 Jan 2013 16:25:05 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fk20so4091650lab.36 for ; Fri, 18 Jan 2013 08:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bUjt+EpzYBD1d9QBZu1H3cOP8+CaZ0JU8HdUQSJ0bV0=; b=hDhqozb1v8ZrNcN7u2JqfvPLs8MXwgGCUuDQItjAsaxYDRuueG45m2nZVQssf2NPm1 rYZuE9eA0d0qmHPEnbhXmp6j7OI0FNor6pUCFWdxqRbC8t81afyFY7gsAXlEiyDKyEx2 vgKzGktfa+glEFlWEUXQ5CfCPH4QVVGITrGfR+Cazv9vKNS/Bnd8aG1w9zhbKaM89Z7L mow7gbOye1tEpNCjRG9GL2BWwpSj7WJYo5bQg/SbKRumaOvPtp5oAOXhuFf2wY2wMi9u p3ftVh4ZvtuUlkY5pxf/V2YkcyypprsBMabjkJPxQGnbScunRmijmlJxZIU+Cga2XZyE uHMQ== MIME-Version: 1.0 X-Received: by 10.112.14.46 with SMTP id m14mr4013713lbc.98.1358526304638; Fri, 18 Jan 2013 08:25:04 -0800 (PST) Received: by 10.114.21.197 with HTTP; Fri, 18 Jan 2013 08:25:04 -0800 (PST) In-Reply-To: <50F96A67.9080203@freebsd.org> References: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 10:25:04 -0600 Message-ID: Subject: Re: kmem_map auto-sizing and size dependencies From: Alan Cox To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:25:06 -0000 I'll follow up with detailed answers to your questions over the weekend. For now, I will, however, point out that you've misinterpreted the tunables. In fact, they say that your kmem map can hold up to 16GB and the current used space is about 58MB. Like other things, the kmem map is auto-sized based on the available physical memory and capped so as not to consume too much of the overall kernel address space. Regards, Alan On Fri, Jan 18, 2013 at 9:29 AM, Andre Oppermann wrote: > The autotuning work is reaching into many places of the kernel and > while trying to tie up all lose ends I've got stuck in the kmem_map > and how it works or what its limitations are. > > During startup the VM is initialized and an initial kernel virtual > memory map is setup in kmem_init() covering the entire KVM address > range. Only the kernel itself is actually allocated within that > map. A bit later on a number of other submaps are allocated (clean_map, > buffer_map, pager_map, exec_map). Also in kmeminit() (in kern_malloc.c, > different from kmem_init) the kmem_map is allocated. > > The (inital?) size of the kmem_map is determined by some voodoo magic, > a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. > However it seems to work out to an effective kmem_map_size of about 58MB > on my 16GB AMD64 dev machine: > > vm.kvm_size: 549755809792 > vm.kvm_free: 530233421824 > vm.kmem_size: 16,594,300,928 > vm.kmem_size_min: 0 > vm.kmem_size_max: 329,853,485,875 > vm.kmem_size_scale: 1 > vm.kmem_map_size: 59,518,976 > vm.kmem_map_free: 16,534,777,856 > > The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing > else that uses UMA for memory allocation. > > Mbuf memory too is managed by UMA which obtains the backing kernel memory > from the kmem_map. The limits of the various mbuf memory types have > been considerably raised recently and may make use of 50-75% of all > physically > present memory, or available KVM space, whichever is smaller. > > Now my questions/comments are: > > Does the kmem_map automatically extend itself if more memory is requested? > > Should it be set to a larger initial value based on min(physical,KVM) > space > available? > > The use of nmbclusters for the initial kmem_map size calculation isn't > appropriate anymore due to it being set up later and nmbclusters isn't the > only mbuf relevant mbuf type. We make significant use of page sized mbuf > clusters too. > > The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is > confusing and not easy to reconcile. Either we need some more detailing > more aspects or less. Plus perhaps sysctl subtrees to better describe the > hierarchy of the maps. > > Why are separate kmem submaps being used? Is it to limit memory usage of > certain subsystems? Are those limits actually enforced? > > -- > Andre > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 16:26:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1076A407; Fri, 18 Jan 2013 16:26:11 +0000 (UTC) (envelope-from mdf356@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 9733D3DA; Fri, 18 Jan 2013 16:26:10 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id t2so2537499qcq.14 for ; Fri, 18 Jan 2013 08:26:04 -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=dyi654dEMV3T/5Id1ivoDxrLLhIsmvWJmuXhkMp/Oe4=; b=ON39WagYTPdzEj0v2rBYkmgZFs14G/RJdBSjXOI5Mln0OTO3b3WyHNMykEj+vSJYXV wrte5gxg0ThQE4nt790GDrF3od8RmqMYuIIMiJbaV4Atfb5bpgeUlAIJjfNTcLaCIYHC K8bvKBiwxkn74rGsbgiFZ4sAYFihwJ9LnhzEfNhrfEZqfUrmmCgbJopmn6wYPKUDqH9F Kv2rb9UD0ITBlPZIqE/Kq9WPhJH9OyYzlagNHCsya9aCf5BbQI0BnDHJr4IgFCw547wm ZsLCKmNapqRrH1IjszPsG2fv3wLmExXpX4Sx4ceAFqFn+ErxGbkVp/6ZqDrwhuxlywAK G0qw== MIME-Version: 1.0 X-Received: by 10.224.17.193 with SMTP id t1mr9796155qaa.89.1358526364372; Fri, 18 Jan 2013 08:26:04 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.156.18 with HTTP; Fri, 18 Jan 2013 08:26:04 -0800 (PST) In-Reply-To: <50F96A67.9080203@freebsd.org> References: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 08:26:04 -0800 X-Google-Sender-Auth: cv1G1jW4Z8UYSMJow_1pgYk2gzI Message-ID: Subject: Re: kmem_map auto-sizing and size dependencies From: mdf@FreeBSD.org To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:26:11 -0000 On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann wrote: > The (inital?) size of the kmem_map is determined by some voodoo magic, > a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. > However it seems to work out to an effective kmem_map_size of about 58MB > on my 16GB AMD64 dev machine: > > vm.kvm_size: 549755809792 > vm.kvm_free: 530233421824 > vm.kmem_size: 16,594,300,928 > vm.kmem_size_min: 0 > vm.kmem_size_max: 329,853,485,875 > vm.kmem_size_scale: 1 > vm.kmem_map_size: 59,518,976 > vm.kmem_map_free: 16,534,777,856 > > The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing > else that uses UMA for memory allocation. > > Mbuf memory too is managed by UMA which obtains the backing kernel memory > from the kmem_map. The limits of the various mbuf memory types have > been considerably raised recently and may make use of 50-75% of all > physically > present memory, or available KVM space, whichever is smaller. > > Now my questions/comments are: > > Does the kmem_map automatically extend itself if more memory is requested? Not that I recall. > Should it be set to a larger initial value based on min(physical,KVM) space > available? It needs to be smaller than the physical space, because the only limit on the kernel's use of (pinned) memory is the size of the map. So if it is too large there is nothing to stop the kernel from consuming all available memory. The lowmem handler is called when running out of virtual space only (i.e. a failure to allocate a range in the map). > The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is > confusing and not easy to reconcile. Either we need some more detailing > more aspects or less. Plus perhaps sysctl subtrees to better describe the > hierarchy of the maps. > > Why are separate kmem submaps being used? Is it to limit memory usage of > certain subsystems? Are those limits actually enforced? I mostly know about memguard, since I added memguard_fudge(). IIRC some of the submaps are used. The memguard_map specifically is used to know whether an allocation is guarded or not, so at free(9) it can be handled as normal malloc() or as memguard. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 16:56:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7387C42 for ; Fri, 18 Jan 2013 16:56:33 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 964557B4 for ; Fri, 18 Jan 2013 16:56:33 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so3864593obc.41 for ; Fri, 18 Jan 2013 08:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=sSKQrlO/Sg0RcB3RXS4D1DLT9V2vo6ycA9tc3fNBhhs=; b=zewwNG0Nf0vjQKdw0SSKkvZDmsii0Cnck/DWKegqHJzUrNRAti5xyIHitt8WlwvQBt 1PIjH/XLZ1MMREBWaEN8qP+Z0+rN4i1dgOYx8vr/thYmpaKiv+lF9M0PKErRFZ31w8jZ KwFqpesYp0PTZpQGBsYSNwOdNH+mXcHPqKqd3gA/ODTY9QiFWLrAa/NUT+fUGrWLqygr nekAbGWU4Ay7BbsjNo9X4LC46L2dGBtjyttuo9WgFz7giyWdNbDn9ShCtyrmL/3PIsnC MLpQ2T6Qb4XrUPCkXxmLd/iyB9FT8pg8twfrCizvTz3L3ta4ehlvrzQWLYHAE6K8Sg/u f1YQ== MIME-Version: 1.0 X-Received: by 10.60.12.72 with SMTP id w8mr7646956oeb.83.1358528187620; Fri, 18 Jan 2013 08:56:27 -0800 (PST) Received: by 10.76.128.68 with HTTP; Fri, 18 Jan 2013 08:56:27 -0800 (PST) Date: Fri, 18 Jan 2013 11:56:27 -0500 Message-ID: Subject: ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter() From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:56:33 -0000 I have been experiencing occasional deadlocks on FreeBSD 8.2 systems using the ULE scheduler. The root cause in every case has been that ULE's TDQ_LOCK for cpu 0 is owned by a thread that is not running. I have been investigating the issue, and I believe that I see the issue. The problem occurs if the interrupt that drives statclock does not call critical_enter() upon calling into statclock(). The lapic timer does use critical_enter(), so default configurations would not see this. I have local patches to use the RTC to drive statclock, and from a quick reading of the eventtimer code in -CURRENT the same thing is possible there. The RTC code does not call statclock within a critical section. So here's the bug: 1) A thread with interrupts enabled, running on CPU 0, with td_owepreempt=1 and td_critnest=1 calls critical_exit(): void critical_exit(void) { // ... if (td->td_critnest == 1) { td->td_critnest = 0; if (td->td_owepreempt && !kdb_active) { // Irrelevant bits snipped 2) td_critnest is set to 0, and then the RTC interrupt fires. 3) rtcintr calls into statclock (8.2) or statclock_cnt(head) with td_critnest still 0 (on head it goes through the eventtimer code, but it ends up in statclock eventually). 4) statclock takes the thread_lock on curthread, then calls sched_clock(). sched_clock calls sched_balance(); static void sched_balance(void) { // snip... tdq = TDQ_SELF(); TDQ_UNLOCK(tdq); sched_balance_group(cpu_top); TDQ_LOCK(tdq); } TDQ_UNLOCK does a spinlock_exit which does a critical_exit. td_critnest will be decremented back to 0 and td_owepreempt is still 1, so this triggers a preemption. Note that this TDQ_UNLOCK is (intentionally) unlocking the thread_lock done by statclock. 5) thread migrates to any other CPU, call it CPU n. tdq is now stale. TDQ_LOCK takes the lock for CPU 0 (but really it's intending to re-take the thread_lock, although a thread_lock() here would be equally incorrect -- sched_balance's caller is going to be mucking around with the TDQ when sched_balance returns). 6) The thread returns to statclock. statclock does a thread_unlock(). The td_lock is TDQ_LOCK(n), which we don't hold. We mangle the stat of TDQ_LOCK(n) and leave TDQ_LOCK(0) held. The simplest solution would be to do a critical_enter() in sched_balance, although that would be superfluous in the normal case where the lapic timer is driving statclock. I'm not sure if there's other code in the eventtimers infrastructure that's assuming that a preemption or migration is impossible while handling an event. A quick look at kern_clocksource.c turns up worrying comments like "Handle all events for specified time on this CPU" and uses of curcpu, so there may well be other issues lurking here. It looks to me that the safest thing to do would be to push the critical_enter() into the eventtimer code or even all the way back to the interrupt handlers (mirroring what the lapic code already does). From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 18:17:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D118278D for ; Fri, 18 Jan 2013 18:17:36 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 32012DD3 for ; Fri, 18 Jan 2013 18:17:35 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gw10so3313825lab.41 for ; Fri, 18 Jan 2013 10:17:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding:x-gm-message-state; bh=7Aoxe3x2I2itnC4gNGQGlr2cCm0SokFB+ZzcdtHndJ0=; b=UdlGJNT7ykAR+poD59CT5vT5QSxC41JN3EIl49JHR8v4iAd4QzCN7OCCM+G7qhsoyd X+EeW7+vAoNuJOe+iJmF+wgARCJC8o7J2Yac76aj/AT8Xxi5iLTVgu67pHbPFqAJQ9uj nSdi7MfIhO3Ch+A4QNTQ4XreP2d/Dm4mI0xl3Gkbs3JSC1cqV0/haSp1aI4UmrmhV1dh oPKJSEWZLavB1NfCBa6nWAy6f1ebpDaTVin0gs9zASu+rKGlTJpuunMTqImkhHhp6kXY Yxk+SlR0kJzuPniX8hrn5VusUdNLtEWH1qpgA9afnXdQzHV55S2RSUBce3MJyAxpZRwL zTsQ== X-Received: by 10.152.125.136 with SMTP id mq8mr9330812lab.41.1358533049430; Fri, 18 Jan 2013 10:17:29 -0800 (PST) Received: from [192.168.1.2] ([89.169.163.3]) by mx.google.com with ESMTPS id ox6sm2338305lab.16.2013.01.18.10.17.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 10:17:28 -0800 (PST) Message-ID: <50F991B7.3000204@freebsd.org> Date: Fri, 18 Jan 2013 22:17:27 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: jkim@freebsd.org, current@freebsd.org Subject: -current broken in acpi/iasl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkjAfqN3lxwKYm+pnQ2C0IK0XLVSQibjMLzvVuAlh4/m59mDlI3xseIvbItn5TWCAmlvNFk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:17:36 -0000 ===> usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 18:34:30 2013 Return-Path: Delivered-To: current@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 57404521; Fri, 18 Jan 2013 18:34:30 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id BFB73EF0; Fri, 18 Jan 2013 18:34:29 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1874701eek.5 for ; Fri, 18 Jan 2013 10:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding; bh=H90GFm3QOx5EpHKT9rvSLI9C1u/TLU+oT7Y2/URVYUM=; b=cyXRTd3nuMtwUyXDg9wLjHKdA2DcfMJUa4ver6KC78FTOgC0biHasxgAkXX3hxAs1x Ag8v/8dNTr55BMZDO3giWvBUxA3CVPx7zzUBXVUWZrxr8pIiGAalGxYlNYXNwNsVEdMD ZejdPvmtGyDL1PgvTUw+TmUSJhiHndhUneVDw2U8Mo2/k+uc5mTdMm73l6a8Yw9+B83s XMGZzlBPsPiS3HtNDLGFsqFWlaNsc8XAgVCizqMLHMyqcsKnLn1fI6O4euMlr9dQHptX SOxdqe7f4Y0wmi2GfgFC0ZvbwHcnMnGb/PBg3xJjNTK/8MoCjEUIRNITVrMrtbF+yFb4 8ePA== X-Received: by 10.14.206.197 with SMTP id l45mr28984818eeo.17.1358534068882; Fri, 18 Jan 2013 10:34:28 -0800 (PST) Received: from laptop ([178.125.79.21]) by mx.google.com with ESMTPS id 6sm8494792eea.3.2013.01.18.10.34.27 (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 18 Jan 2013 10:34:28 -0800 (PST) Date: Fri, 18 Jan 2013 21:34:26 +0300 From: "Sergey V. Dyatko" To: current@freebsd.org Subject: Re: -current broken in acpi/iasl Message-ID: <20130118213426.7f4a650d@laptop> In-Reply-To: <50F991B7.3000204@freebsd.org> References: <50F991B7.3000204@freebsd.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:34:30 -0000 On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov wrote: > ===> usr.sbin/acpi/iasl (all) > cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. > -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c > cc1: warnings being treated as errors > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: > In function 'AcpiDmIsResourceTemplate': > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: > warning: dereferencing type-punned pointer will break strict-aliasing > rules *** [dmresrc.o] Error code 1 > > Stop in /usr/src/usr.sbin/acpi/iasl. > *** [all] Error code 1 > according to rumors buildworld done successfully with the clang. But I didn't test it. Look at "buildworld is broken ?" thread -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 18:37:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFA2B90F for ; Fri, 18 Jan 2013 18:37:36 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id A6027F44 for ; Fri, 18 Jan 2013 18:37:36 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r0IIbZxi049130 for ; Fri, 18 Jan 2013 10:37:35 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r0IIbZaZ049129 for current@freebsd.org; Fri, 18 Jan 2013 10:37:35 -0800 (PST) (envelope-from david) Date: Fri, 18 Jan 2013 10:37:35 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: -current broken in acpi/iasl Message-ID: <20130118183735.GE1858@albert.catwhisker.org> References: <50F991B7.3000204@freebsd.org> <20130118213426.7f4a650d@laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Sb9NMHsr/6ruU3h" Content-Disposition: inline In-Reply-To: <20130118213426.7f4a650d@laptop> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:37:36 -0000 --/Sb9NMHsr/6ruU3h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote: > On Fri, 18 Jan 2013 22:17:27 +0400 > Andrey Chernov wrote: >=20 > > =3D=3D=3D> usr.sbin/acpi/iasl (all) > > cc -O2 -pipe -march=3Dcore2 -DACPI_ASL_COMPILER -I. > > -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=3Dgnu99 > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer-sign -c > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/= disassembler/dmresrc.c > > cc1: warnings being treated as errors > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/= disassembler/dmresrc.c: > > In function 'AcpiDmIsResourceTemplate': > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/= disassembler/dmresrc.c:419: > > warning: dereferencing type-punned pointer will break strict-aliasing > > rules *** [dmresrc.o] Error code 1 > >=20 > > Stop in /usr/src/usr.sbin/acpi/iasl. > > *** [all] Error code 1 > >=20 >=20 > according to rumors buildworld done successfully with the clang. But I > didn't test it. Look at "buildworld is broken ?" thread=20 > ... My "head" (10.0-CURRENT) builds (on my laptop & build machine) were uneventful; e.g.: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796 r2455= 84M/245600: Fri Jan 18 06:07:23 PST 2013 root@g1-227.catwhisker.org:/us= r/obj/usr/src/sys/CANARY i386 And yes, I use clang. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/Sb9NMHsr/6ruU3h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD5lm8ACgkQmprOCmdXAD3kswCfVPGMzayucF80gPhmuprR8jPp WNsAn0+q0noyk6mgCN+6mbK9h4knwUqK =4Rph -----END PGP SIGNATURE----- --/Sb9NMHsr/6ruU3h-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 18:39:02 2013 Return-Path: Delivered-To: current@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 6AC5EA60; Fri, 18 Jan 2013 18:39:02 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2B3F64; Fri, 18 Jan 2013 18:39:02 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r0IId10C004121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 10:39:01 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r0IId13P004120; Fri, 18 Jan 2013 10:39:01 -0800 (PST) (envelope-from jmg) Date: Fri, 18 Jan 2013 10:39:01 -0800 From: John-Mark Gurney To: "Sergey V. Dyatko" Subject: Re: -current broken in acpi/iasl Message-ID: <20130118183901.GS1410@funkthat.com> Mail-Followup-To: "Sergey V. Dyatko" , current@freebsd.org, Jung-uk Kim References: <50F991B7.3000204@freebsd.org> <20130118213426.7f4a650d@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130118213426.7f4a650d@laptop> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 18 Jan 2013 10:39:01 -0800 (PST) Cc: current@freebsd.org, Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:39:02 -0000 Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300: > On Fri, 18 Jan 2013 22:17:27 +0400 > Andrey Chernov wrote: > > > ===> usr.sbin/acpi/iasl (all) > > cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. > > -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 > > -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer-sign -c > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c > > cc1: warnings being treated as errors > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: > > In function 'AcpiDmIsResourceTemplate': > > /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: > > warning: dereferencing type-punned pointer will break strict-aliasing > > rules *** [dmresrc.o] Error code 1 > > > > Stop in /usr/src/usr.sbin/acpi/iasl. > > *** [all] Error code 1 > > > > according to rumors buildworld done successfully with the clang. But I > didn't test it. Look at "buildworld is broken ?" thread Looks like this broken when jkim imported the latest ACPICA code base: https://svnweb.freebsd.org/base?view=revision&revision=245582 I've forward the tinderbox failure to him, so hopefully he'll fix it shortly... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 18:41:28 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7AF7DB8A for ; Fri, 18 Jan 2013 18:41:28 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id EDC36F84 for ; Fri, 18 Jan 2013 18:41:27 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id n8so1161658lbj.3 for ; Fri, 18 Jan 2013 10:41:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :openpgp:content-type:x-gm-message-state; bh=VIsid4qjtRlWaEKaa63rAeowAaRUpQfrs7KWJ+MQlfQ=; b=buGay+gTJocpwJqDADvWnfr3C7ThOvoZ5t8TywBluKbwxGQ9L+3nPALuCa3iftLjCA k7PlO+iOjJE33ezn8iEAZlzTQv9XNIxA/FuxYq3N9/BrlXAGNAdv7faKeFM6A8Eoz3Kl xzSryL0FjTItyAenLiRgm2c9sgoqdmnbs7syKlnHlwQjIWf6LwaTvrHKAd5p9eGUJVLt HgJfKo01yXqtiXEVsicDmaa/zb0xEYlo9HWVx0mvk47RDbZi8N6rO1ZuqlIeOEjJafzS JpXA5tLFxhRs3mgf5s3gcogLY6z0l9WhrG265gBRf+uqjAGd6Gslx09BMUzELY4OoE/l QDQA== X-Received: by 10.112.87.40 with SMTP id u8mr4184818lbz.50.1358534486458; Fri, 18 Jan 2013 10:41:26 -0800 (PST) Received: from [192.168.1.2] ([89.169.163.3]) by mx.google.com with ESMTPS id iw6sm2366580lab.2.2013.01.18.10.41.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 10:41:25 -0800 (PST) Message-ID: <50F9974D.9040307@freebsd.org> Date: Fri, 18 Jan 2013 22:41:17 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Wolfskill , jkim@freebsd.org Subject: Re: -current broken in acpi/iasl References: <50F991B7.3000204@freebsd.org> <20130118213426.7f4a650d@laptop> <20130118183735.GE1858@albert.catwhisker.org> In-Reply-To: <20130118183735.GE1858@albert.catwhisker.org> OpenPGP: id=964474DD Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2STAHDSIEFHPNJISLXTRU" X-Gm-Message-State: ALoCoQkaLjIjNRHeDqHIASXymYEr/oYAcX4CHwWa55fj4U9p3GigJf6XgKAlYODqdoZlqxQH67zb Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:41:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2STAHDSIEFHPNJISLXTRU Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 18.01.2013 22:37, David Wolfskill wrote: > On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote: >> On Fri, 18 Jan 2013 22:17:27 +0400 >> Andrey Chernov wrote: >> >>> =3D=3D=3D> usr.sbin/acpi/iasl (all) >>> cc -O2 -pipe -march=3Dcore2 -DACPI_ASL_COMPILER -I. >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=3Dgnu99 >>> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >>> -Wno-uninitialized -Wno-pointer-sign -c >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/component= s/disassembler/dmresrc.c >>> cc1: warnings being treated as errors >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/component= s/disassembler/dmresrc.c: >>> In function 'AcpiDmIsResourceTemplate': >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/component= s/disassembler/dmresrc.c:419: >>> warning: dereferencing type-punned pointer will break strict-aliasing= >>> rules *** [dmresrc.o] Error code 1 >>> >>> Stop in /usr/src/usr.sbin/acpi/iasl. >>> *** [all] Error code 1 >>> >> >> according to rumors buildworld done successfully with the clang. But I= >> didn't test it. Look at "buildworld is broken ?" thread=20 >> ... >=20 > My "head" (10.0-CURRENT) builds (on my laptop & build machine) were > uneventful; e.g.: >=20 > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796 r= 245584M/245600: Fri Jan 18 06:07:23 PST 2013 root@g1-227.catwhisker.o= rg:/usr/obj/usr/src/sys/CANARY i386 >=20 > And yes, I use clang. >=20 > Peace, > david >=20 I have no clang bloat, it happens with good old gcc. ------enig2STAHDSIEFHPNJISLXTRU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iEYEARECAAYFAlD5l1UACgkQVg5YK5ZEdN0RLACfSMaXdKt1C7ulB/bkRuMf0D/5 mNgAn0E/zy75xezPK+zNVP6HO+8EFEpn =J6kw -----END PGP SIGNATURE----- ------enig2STAHDSIEFHPNJISLXTRU-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 19:54:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 851053AE for ; Fri, 18 Jan 2013 19:54:31 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 45C57286 for ; Fri, 18 Jan 2013 19:54:30 +0000 (UTC) Received: from [78.35.163.76] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TwI1A-0000pQ-37 for freebsd-current@freebsd.org; Fri, 18 Jan 2013 20:54:24 +0100 Date: Fri, 18 Jan 2013 20:54:03 +0100 From: Fabian Keil To: FreeBSD Current Subject: "make buildworld" failures with NO_KERBEROS= Message-ID: <20130118205403.3f3f4c5a@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/nCKpmEk6LLRAVWo6Q1Qz=Zf"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 19:54:31 -0000 --Sig_/nCKpmEk6LLRAVWo6Q1Qz=Zf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recently "make buildworld" started failing for me: --------8<-------- =3D=3D=3D> include/xlocale (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _inttypes= .h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time.h _= wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale =3D=3D=3D> kerberos5 (includes) set -e; cd /usr/src/kerberos5; /usr/obj/usr/src/make.amd64/make buildinclud= es; /usr/obj/usr/src/make.amd64/make installincludes =3D=3D=3D> kerberos5/doc (buildincludes) =3D=3D=3D> kerberos5/lib (buildincludes) =3D=3D=3D> kerberos5/lib/libasn1 (buildincludes) compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/= asn1_err.et compile_et: No such file or directory *** [asn1_err.h] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5/lib. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5. *** [includes] Error code 1 Stop in /usr/src/kerberos5. *** [kerberos5.includes__D] Error code 1 Stop in /usr/src. *** [_includes] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. --------8<-------- I was still using the recently de-supported NO_KERBEROS=3D and changing it to WITHOUT_KERBEROS=3D got it working again. I'm still wondering if this is the expected behaviour, though. Shouldn't buildworld create a usable compile_et instead of relying on compile_et's existence in /usr/bin? Fabian --Sig_/nCKpmEk6LLRAVWo6Q1Qz=Zf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD5qGkACgkQBYqIVf93VJ2agQCfXyujbg/10h4K4FbMs4UqW3oT gDwAn2AUTCZV4lgfZhs1b8jfwgyGiivz =yCVl -----END PGP SIGNATURE----- --Sig_/nCKpmEk6LLRAVWo6Q1Qz=Zf-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 20:07:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9301A840 for ; Fri, 18 Jan 2013 20:07:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 60AA0308 for ; Fri, 18 Jan 2013 20:07:14 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id r0IK7A23035424; Fri, 18 Jan 2013 12:07:10 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id r0IK7AGO035423; Fri, 18 Jan 2013 12:07:10 -0800 (PST) (envelope-from sgk) Date: Fri, 18 Jan 2013 12:07:10 -0800 From: Steve Kargl To: Fabian Keil Subject: Re: "make buildworld" failures with NO_KERBEROS= Message-ID: <20130118200710.GA35388@troutmask.apl.washington.edu> References: <20130118205403.3f3f4c5a@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130118205403.3f3f4c5a@fabiankeil.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:07:14 -0000 On Fri, Jan 18, 2013 at 08:54:03PM +0100, Fabian Keil wrote: > Recently "make buildworld" started failing for me: > > --------8<-------- > ===> include/xlocale (installincludes) > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _inttypes.h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time.h _wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale > ===> kerberos5 (includes) > set -e; cd /usr/src/kerberos5; /usr/obj/usr/src/make.amd64/make buildincludes; /usr/obj/usr/src/make.amd64/make installincludes > ===> kerberos5/doc (buildincludes) > ===> kerberos5/lib (buildincludes) > ===> kerberos5/lib/libasn1 (buildincludes) > compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et > compile_et: No such file or directory > *** [asn1_err.h] Error code 1 > See the thread started here: http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039083.html AFAICT, it is an ordering issue. usr.bin/compile_et needs to be a bootstrap tool, but it depends on some bits from kerberos5 and building kerberos5 needs compile_et. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 20:50:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80B19789 for ; Fri, 18 Jan 2013 20:50:31 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA9572E for ; Fri, 18 Jan 2013 20:50:30 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id z53so1106767wey.34 for ; Fri, 18 Jan 2013 12:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/gs/YLaIFIp25J1hb/Wh5fsLfcU+AegCZmV4YdYpT7g=; b=huBreQnSUpnlD5BPQR76ZyjUHMezSLWG++mapsZT5Qzc/3s929SsIkopX4bVuCpGq1 WxrTGKQdq4GnCiGLefWz9sMp3Gn10R+USxVTnpfSwty3GCDFR6ZLLx5JMEAqr1pY8vRG o5WaDJ51M32RRDNM9JL0V3E4zJnlHWJVSZTvj7pAIfYkXQtivxv665UefLyUkAy5GZ3B jbnBAC21wgDkDM8QCur5Ig3s0vabIpVck3fX8wnYiIXltMAyS7gVtXtNPkAtz7ZRiHny Hs/7tJVBW5QGYocM0XwDnrw33g4O1ypp7qrD5yEZUtTdOEeXsHY9TjQ8OxVb7TYzf/ZJ RRBw== MIME-Version: 1.0 X-Received: by 10.180.101.99 with SMTP id ff3mr5680339wib.21.1358542230257; Fri, 18 Jan 2013 12:50:30 -0800 (PST) Received: by 10.216.100.194 with HTTP; Fri, 18 Jan 2013 12:50:30 -0800 (PST) In-Reply-To: <50EF3FEC.60605@delphij.net> References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> <50EB870D.3020306@delphij.net> <50EF3FEC.60605@delphij.net> Date: Fri, 18 Jan 2013 14:50:30 -0600 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Brandon Gooch To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:50:31 -0000 On Thu, Jan 10, 2013 at 4:25 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > To all: this became more and more hard to replicate lately. I've > tried these options and the most important progress is that it's > possible to get a crashdump when debug.debugger_on_panic=0 and I > managed to get a backtrace which indicates the panic occur when trying > to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait -> > propagate_priority, but after I've added some instruments to the > surrounding code and enabled INVARIANT and/or WITNESS, it mysteriously > went away. > > Reverting my instruments code and update to latest svn makes the issue > disappear for one day. I've hit it again today but unfortunately > didn't get a successful dump and after reboot I can't reproduce it > again :( > > Still trying... > Any updates Xin? I was actually hitting what I believe to be exactly the same issue as you on one of my systems, and, as you've seen, adding any extra debugging or diagnostics seemed to eliminate the issue. I was able to generate quite a few vmcores and still have these sitting around in my filesystem (along with the kernels that helped produce them). I can recreate this crash on my system by compiling the NVIDIA driver with clang at -01 and above. Although it's been noted that this issue has been seen in scenarios without an NIVIDIA driver in the mix, whatever is happening in the kernel to cause the panic is somehow triggered by this, at least on my system. -Brandon From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 20:56:44 2013 Return-Path: Delivered-To: freebsd-current@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 87D20D37 for ; Fri, 18 Jan 2013 20:56:44 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2CA792 for ; Fri, 18 Jan 2013 20:56:44 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B40131E4B4; Fri, 18 Jan 2013 12:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1358542603; bh=8Wop4HCKYo4r05si3M4zKhF36HXv3tkRpX02O6rAXAo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=iF3pGs9cI5Wh3cyVvNZrtHxfZp8aXgXBEF2aeEOP+sUugkWSaG7mFosyE8evbheDW YoRqGuv0V8ZqW3ZY9k5pB+QqUUM0ufYiELE9jKcYhgMhEek6MyBnKWwI+MT4APg9d9 8xvkg847tIu5nqAcWznPEWG8NQSXtqRWz0O2Dyns= Message-ID: <50F9B70A.5040305@delphij.net> Date: Fri, 18 Jan 2013 12:56:42 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brandon Gooch Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> <50EB870D.3020306@delphij.net> <50EF3FEC.60605@delphij.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@freebsd.org, d@delphij.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:56:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/18/13 12:50, Brandon Gooch wrote: > On Thu, Jan 10, 2013 at 4:25 PM, Xin Li > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > To all: this became more and more hard to replicate lately. I've > tried these options and the most important progress is that it's > possible to get a crashdump when debug.debugger_on_panic=0 and I > managed to get a backtrace which indicates the panic occur when > trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait > -> propagate_priority, but after I've added some instruments to > the surrounding code and enabled INVARIANT and/or WITNESS, it > mysteriously went away. > > Reverting my instruments code and update to latest svn makes the > issue disappear for one day. I've hit it again today but > unfortunately didn't get a successful dump and after reboot I can't > reproduce it again :( > > Still trying... > > > Any updates Xin? No, it mysteriously disappeared for now. According to my understanding to recent svn commits, I didn't see anybody committing something that fixes it but I can no longer panic my system, with or without debugging code :( > I was actually hitting what I believe to be exactly the same issue > as you on one of my systems, and, as you've seen, adding any extra > debugging or diagnostics seemed to eliminate the issue. > > I was able to generate quite a few vmcores and still have these > sitting around in my filesystem (along with the kernels that helped > produce them). > > I can recreate this crash on my system by compiling the NVIDIA > driver with clang at -01 and above. Although it's been noted that > this issue has been seen in scenarios without an NIVIDIA driver in > the mix, whatever is happening in the kernel to cause the panic is > somehow triggered by this, at least on my system. I'm not sure if this is the same problem. Could you please try using gcc to compile the nVIdia driver and see if that "fixes" the problem? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJQ+bcKAAoJEG80Jeu8UPuz5D8H/RFSmPv2nNqGmLCNZpElesN5 IYHWTNwxekFLC5M/jeYCLePLGEozBqOBzryrVr1xslvIJJf2w0NLCEIzyC+kdWy9 ksi+DihihuwqEp7BIieQi/HQkwhFKxm0SmovPYu8Al3rFFyazuMCHstuToWyT9sN OV8ZjyinFIyb8EPqm7V6Ziwi7A6sApHO5SlQXscqANrT03FrU4I8tseNzdDX9uwQ zzewf05rkcko771Vk7JI9Xwu7VHZ+eN4NbujBhuVhMWw+utZSJFOf67o11JZw9B0 aM1PCfZef2NM9OfAN40JTY4/Hjk6TSygJKu3mGd3R5tjcRywU0ypwPXgOsUxlVg= =3Kk8 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 18 21:51:33 2013 Return-Path: Delivered-To: current@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 BD259391; Fri, 18 Jan 2013 21:51:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 93FBC9AF; Fri, 18 Jan 2013 21:51:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0ILpVqP026205; Fri, 18 Jan 2013 16:51:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0ILpVw8026162; Fri, 18 Jan 2013 21:51:31 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Jan 2013 21:51:31 GMT Message-Id: <201301182151.r0ILpVw8026162@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:51:33 -0000 TB --- 2013-01-18 20:22:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-18 20:22:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-18 20:22:39 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-18 20:22:39 - cleaning the object tree TB --- 2013-01-18 20:23:50 - /usr/local/bin/svn stat /src TB --- 2013-01-18 20:23:54 - At svn revision 245609 TB --- 2013-01-18 20:23:55 - building world TB --- 2013-01-18 20:23:55 - CROSS_BUILD_TESTING=YES TB --- 2013-01-18 20:23:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-18 20:23:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-18 20:23:55 - SRCCONF=/dev/null TB --- 2013-01-18 20:23:55 - TARGET=ia64 TB --- 2013-01-18 20:23:55 - TARGET_ARCH=ia64 TB --- 2013-01-18 20:23:55 - TZ=UTC TB --- 2013-01-18 20:23:55 - __MAKE_CONF=/dev/null TB --- 2013-01-18 20:23:55 - cd /src TB --- 2013-01-18 20:23:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 18 20:23:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmbuffer.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmdeferred.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmnames.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmopcode.c cc -O2 -pipe -DACPI_ASL_COMPILER -I. -I/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /src/usr.sbin/acpi/iasl. *** [all] Error code 1 Stop in /src/usr.sbin/acpi. *** [all] Error code 1 Stop in /src/usr.sbin. *** [usr.sbin.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-18 21:51:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-18 21:51:26 - ERROR: failed to build world TB --- 2013-01-18 21:51:26 - 4028.99 user 952.67 system 5326.66 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 00:39:50 2013 Return-Path: Delivered-To: current@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 8AD5CE23 for ; Sat, 19 Jan 2013 00:39:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD8596; Sat, 19 Jan 2013 00:39:50 +0000 (UTC) Message-ID: <50F9EB03.5030306@FreeBSD.org> Date: Fri, 18 Jan 2013 19:38:27 -0500 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130116 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Sergey V. Dyatko" , current@freebsd.org Subject: Re: -current broken in acpi/iasl References: <50F991B7.3000204@freebsd.org> <20130118213426.7f4a650d@laptop> <20130118183901.GS1410@funkthat.com> In-Reply-To: <20130118183901.GS1410@funkthat.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:39:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote: > Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 > +0300: >> On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov >> wrote: >> >>> ===> usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 >>> -DACPI_ASL_COMPILER -I. >>> -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 >>> -fstack-protector -Wsystem-headers -Werror -Wall >>> -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c >>> >>> cc1: warnings being treated as errors >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: >>> >>> In function 'AcpiDmIsResourceTemplate': >>> /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: >>> >>> warning: dereferencing type-punned pointer will break strict-aliasing >>> rules *** [dmresrc.o] Error code 1 >>> >>> Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 >>> >> >> according to rumors buildworld done successfully with the clang. >> But I didn't test it. Look at "buildworld is broken ?" thread > > Looks like this broken when jkim imported the latest ACPICA code > base: > https://svnweb.freebsd.org/base?view=revision&revision=245582 > > I've forward the tinderbox failure to him, so hopefully he'll fix > it shortly... It should be fixed now (r245636). Sorry for the breakage. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ+esDAAoJECXpabHZMqHOypgIAILl0S2cvEdTQWXJ4PWase07 yKA+DPHYAUx09JHbnLfEeA+KLFUz2jnX7dYR9ohSMcsnkI1/AH/z8dkFc3NLPUQw TXh1edQyXaYr0WK+3sW81Tl5thka5VwjznoJj1r/Og8Nrx/xYUYCEtpPsjDU1hW0 8T897m6MqOSZokWs4dyOt1ZWoncGRTHgC5tCzjcmAuiOTIkZ7hdLNXKu1nm+cgcy LNEvJf/d1bz6UzQ9xxCxG+HttZhi4YL8uAAYMHZtydM+Zp5yZskajyNmDkThSMhu LrUohDfMLk84DkyoAfzojr90o8tk6TujfHR+osF3oj9NkDi6o6VK0AVs1yKPg5c= =poDO -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 05:58:16 2013 Return-Path: Delivered-To: freebsd-current@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 EC63E791 for ; Sat, 19 Jan 2013 05:58:16 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 73DFFB79 for ; Sat, 19 Jan 2013 05:58:16 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hq12so1013300wib.2 for ; Fri, 18 Jan 2013 21:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PGH9UYV62l65y8Mlr+XMjE/UxVqVuQvViXLASxzlH08=; b=dCcaStNQ6lk83oUF2ZFAhqVfYfaPDpR3YKm8DPWcb+KGPFh1k3LaaxZEOyl22QbOz6 ePGvi9qcN9PS4qkWX/rYeoWSNNqkMpyv6h7M0e1Uvnz/cqQFXAeXiFiORMzyp39PIN3d Tbx+aRkl8Fk+E8v17ZSQELiqkjajsJcN6TZqA/yrJW8eOp4R15GgFd3i++eqKdIel03L MnxzkpRL4WUWeut7OcZ95jdYbrRGy3B4V6+si7Keq9HA00Ys7vXKrTTdFFJikgN9jEkf vW3rBW/6nfMeLl1n9WgMZWniIqaGlTqXDCJOQMQdHDcqFXIb6w2UBB8buKhxRoWnpkJr I0ZA== MIME-Version: 1.0 X-Received: by 10.180.99.165 with SMTP id er5mr11908783wib.1.1358575094595; Fri, 18 Jan 2013 21:58:14 -0800 (PST) Received: by 10.216.100.194 with HTTP; Fri, 18 Jan 2013 21:58:14 -0800 (PST) In-Reply-To: <50F9B70A.5040305@delphij.net> References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> <50EB870D.3020306@delphij.net> <50EF3FEC.60605@delphij.net> <50F9B70A.5040305@delphij.net> Date: Fri, 18 Jan 2013 23:58:14 -0600 Message-ID: Subject: Re: sysctl -a causes kernel trap 12 From: Brandon Gooch To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 05:58:17 -0000 On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/18/13 12:50, Brandon Gooch wrote: > > On Thu, Jan 10, 2013 at 4:25 PM, Xin Li > > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > > > To all: this became more and more hard to replicate lately. I've > > tried these options and the most important progress is that it's > > possible to get a crashdump when debug.debugger_on_panic=0 and I > > managed to get a backtrace which indicates the panic occur when > > trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait > > -> propagate_priority, but after I've added some instruments to > > the surrounding code and enabled INVARIANT and/or WITNESS, it > > mysteriously went away. > > > > Reverting my instruments code and update to latest svn makes the > > issue disappear for one day. I've hit it again today but > > unfortunately didn't get a successful dump and after reboot I can't > > reproduce it again :( > > > > Still trying... > > > > > > Any updates Xin? > > No, it mysteriously disappeared for now. According to my > understanding to recent svn commits, I didn't see anybody committing > something that fixes it but I can no longer panic my system, with or > without debugging code :( > > > I was actually hitting what I believe to be exactly the same issue > > as you on one of my systems, and, as you've seen, adding any extra > > debugging or diagnostics seemed to eliminate the issue. > > > > I was able to generate quite a few vmcores and still have these > > sitting around in my filesystem (along with the kernels that helped > > produce them). > > > > I can recreate this crash on my system by compiling the NVIDIA > > driver with clang at -01 and above. Although it's been noted that > > this issue has been seen in scenarios without an NIVIDIA driver in > > the mix, whatever is happening in the kernel to cause the panic is > > somehow triggered by this, at least on my system. > > I'm not sure if this is the same problem. Could you please try using > gcc to compile the nVIdia driver and see if that "fixes" the problem? > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > Indeed, a gcc compiled NVIDIA module eliminates the issue, sorry if I hadn't mentioned this earlier. What was happening to me at first was that my system would just hang while booting. I was able to figure out that it was during /etc/rc.d/initrandom. I actually got to a point where I removed the call to sysctl -a from 'better_than_nothing()' in /etc/rc.d/initrandom to have a booting system. I finally had a situation where I could get a panic by adding SW_WATCHDOG to my kernel and running watchdogd(8). For me, this panic would come and go seemingly at random as well, and I couldn't fumble my way around in the debugger to learn much of anything when I first started seeing it. I just started a process of modularizing everything I could in my kernel config, then loading modules 1-by-1 and booting over-and-over until I finally found what appeared to be the problem, which was the NVIDIA module compiled with clang. Oh, another thing: at times it seemed as though it was the number of modules loaded, as I could get the hang with 41 modules loaded, but not 40 or 42?! I admit, when I was seeing that behavior, I hadn't eliminated the NVIDIA driver from my loaded modules. I need to revisit the panic situation to confirm this particular strangeness. Here's the last panic I had: Unread portion of the kernel message buffer: = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1175 (sysctl) (kgdb) bt #0 doadump (textdump=1694704112) at pcpu.h:229 #1 0xffffffff802fab82 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:578 #2 0xffffffff802fa85a in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0xffffffff802fa612 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xffffffff802fcf60 in db_trap (type=, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff804a7b93 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff807157c5 in trap_fatal (frame=0xffffff8865032670, eva=) at /usr/src/sys/amd64/amd64/trap.c:867 #7 0xffffffff80715adb in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:698 #8 0xffffffff8071529b in trap (frame=0xffffff8865032670) at /usr/src/sys/amd64/amd64/trap.c:463 #9 0xffffffff806ff382 in calltrap () at exception.S:228 #10 0xffffffff8047bd50 in sysctl_sysctl_next_ls (lsp=, name=0xffffff8865032a80, namelen=, next=0xffffff8865032898, len=0xffffff8865032904, level=3) at /usr/src/sys/kern/kern_sysctl.c:759 #11 0xffffffff8047be5e in sysctl_sysctl_next_ls (lsp=0xfffffe000d3f0080, name=0xffffff8865032a7c, namelen=, next=0xffffff8865032894, len=0xffffff8865032904, level=2) at /usr/src/sys/kern/kern_sysctl.c:786 #12 0xffffffff8047be5e in sysctl_sysctl_next_ls (lsp=0xfffffe000d3f0080, name=0xffffff8865032a78, namelen=, next=0xffffff8865032890, len=0xffffff8865032904, level=1) at /usr/src/sys/kern/kern_sysctl.c:786 #13 0xffffffff8047bca3 in sysctl_sysctl_next (oidp=, arg1=0xffffff8865032a78, arg2=4, req=0xffffff88650329a8) at /usr/src/sys/kern/kern_sysctl.c:808 #14 0xffffffff8047b03f in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 #15 0xffffffff8047b5d8 in userland_sysctl (td=, name=0xffffff8865032a70, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=1694706064) at /usr/src/sys/kern/kern_sysctl.c:1623 #16 0xffffffff8047b3c4 in sys___sysctl (td=0xfffffe001e2d4900, uap=0xffffff8865032b80) at /usr/src/sys/kern/kern_sysctl.c:1549 #17 0xffffffff807160f7 in amd64_syscall (td=0xfffffe001e2d4900, traced=0) at subr_syscall.c:135 #18 0xffffffff806ff66b in Xfast_syscall () at exception.S:387 #19 0x000000080093697a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal Any ideas on where to look through this vmcore? -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 08:12:55 2013 Return-Path: Delivered-To: current@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 9499D449; Sat, 19 Jan 2013 08:12:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5A89681; Sat, 19 Jan 2013 08:12:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0J8CsWI015082; Sat, 19 Jan 2013 03:12:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0J8Cs5H015081; Sat, 19 Jan 2013 08:12:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Jan 2013 08:12:54 GMT Message-Id: <201301190812.r0J8Cs5H015081@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 08:12:55 -0000 TB --- 2013-01-19 06:14:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-19 06:14:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-19 06:14:02 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-19 06:14:02 - cleaning the object tree TB --- 2013-01-19 06:14:53 - /usr/local/bin/svn stat /src TB --- 2013-01-19 06:14:56 - At svn revision 245648 TB --- 2013-01-19 06:14:57 - building world TB --- 2013-01-19 06:14:57 - CROSS_BUILD_TESTING=YES TB --- 2013-01-19 06:14:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-19 06:14:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-19 06:14:57 - SRCCONF=/dev/null TB --- 2013-01-19 06:14:57 - TARGET=ia64 TB --- 2013-01-19 06:14:57 - TARGET_ARCH=ia64 TB --- 2013-01-19 06:14:57 - TZ=UTC TB --- 2013-01-19 06:14:57 - __MAKE_CONF=/dev/null TB --- 2013-01-19 06:14:57 - cd /src TB --- 2013-01-19 06:14:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 19 06:15:02 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 19 07:51:47 UTC 2013 TB --- 2013-01-19 07:51:47 - generating LINT kernel config TB --- 2013-01-19 07:51:47 - cd /src/sys/ia64/conf TB --- 2013-01-19 07:51:47 - /usr/bin/make -B LINT TB --- 2013-01-19 07:51:47 - cd /src/sys/ia64/conf TB --- 2013-01-19 07:51:47 - /usr/sbin/config -m LINT TB --- 2013-01-19 07:51:47 - building LINT kernel TB --- 2013-01-19 07:51:47 - CROSS_BUILD_TESTING=YES TB --- 2013-01-19 07:51:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-19 07:51:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-19 07:51:47 - SRCCONF=/dev/null TB --- 2013-01-19 07:51:47 - TARGET=ia64 TB --- 2013-01-19 07:51:47 - TARGET_ARCH=ia64 TB --- 2013-01-19 07:51:47 - TZ=UTC TB --- 2013-01-19 07:51:47 - __MAKE_CONF=/dev/null TB --- 2013-01-19 07:51:47 - cd /src TB --- 2013-01-19 07:51:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 19 07:51:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-19 08:12:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-19 08:12:54 - ERROR: failed to build LINT kernel TB --- 2013-01-19 08:12:54 - 5415.30 user 1216.92 system 7132.05 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 08:27:54 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B5A24605; Sat, 19 Jan 2013 08:27:54 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 5839AEC; Sat, 19 Jan 2013 08:27:53 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id B02981514AB; Sat, 19 Jan 2013 10:27:41 +0200 (EET) Date: Sat, 19 Jan 2013 10:27:40 +0200 From: Jaakko Heinonen To: Alexander Motin Subject: Re: panic after r244584 Message-ID: <20130119082739.GA1956@a91-153-116-96.elisa-laajakaista.fi> References: <20130118073600.GA70874@hell.ukr.net> <20130118094424.GD2331@FreeBSD.org> <50F93165.60809@FreeBSD.org> <20130118113934.GA60441@hell.ukr.net> <50F9357F.8040109@FreeBSD.org> <20130118131954.GA3868@a91-153-116-96.elisa-laajakaista.fi> <50F94D80.7000809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F94D80.7000809@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Justin T. Gibbs" , satan@ukr.net, Gleb Smirnoff , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 08:27:54 -0000 On 2013-01-18, Alexander Motin wrote: > At cam/scsi/ses_set_physpath.c ses_set_physpath(). Duplicate names are > impossible there, as previous name components are unique. Special > characters haven't yet seen, but I think theoretically possible. I see two possible solutions for the problem. 1) Replace non-printable, space and '/' characters for example with '_'. '/' should be replaced anyway. 2) Apply the patches in http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html to allow spaces again. I haven't committed the patches because I think that there isn't full consensus that it's right thing to do and also I personally prefer not to have spaces in device names. -- Jaakko From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 13:35:23 2013 Return-Path: Delivered-To: freebsd-current@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 41D3625C for ; Sat, 19 Jan 2013 13:35:23 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.freebsd.org (Postfix) with ESMTP id ED39FBFD for ; Sat, 19 Jan 2013 13:35:22 +0000 (UTC) Received: from [78.35.133.73] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TwYXO-0002RQ-7o; Sat, 19 Jan 2013 14:32:46 +0100 Date: Sat, 19 Jan 2013 14:32:16 +0100 From: Fabian Keil To: Steve Kargl Subject: Re: "make buildworld" failures with NO_KERBEROS= Message-ID: <20130119143216.22e59a95@fabiankeil.de> In-Reply-To: <20130118200710.GA35388@troutmask.apl.washington.edu> References: <20130118205403.3f3f4c5a@fabiankeil.de> <20130118200710.GA35388@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/peCZrg=VVu+8NKStqsZ/+DH"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 13:35:23 -0000 --Sig_/peCZrg=VVu+8NKStqsZ/+DH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Steve Kargl wrote: > On Fri, Jan 18, 2013 at 08:54:03PM +0100, Fabian Keil wrote: > > Recently "make buildworld" started failing for me: > >=20 > > --------8<-------- > > =3D=3D=3D> include/xlocale (installincludes) > > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _intt= ypes.h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time= .h _wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale > > =3D=3D=3D> kerberos5 (includes) > > set -e; cd /usr/src/kerberos5; /usr/obj/usr/src/make.amd64/make buildin= cludes; /usr/obj/usr/src/make.amd64/make installincludes > > =3D=3D=3D> kerberos5/doc (buildincludes) > > =3D=3D=3D> kerberos5/lib (buildincludes) > > =3D=3D=3D> kerberos5/lib/libasn1 (buildincludes) > > compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/a= sn1/asn1_err.et > > compile_et: No such file or directory > > *** [asn1_err.h] Error code 1 > >=20 >=20 > See the thread started here: > http://lists.freebsd.org/pipermail/freebsd-current/2013-January/039083.ht= ml Thanks. Fabian --Sig_/peCZrg=VVu+8NKStqsZ/+DH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD6oG0ACgkQBYqIVf93VJ3eDQCgwMXxgidkd2O7WrxFl4YW8dF0 f58AnAm1rmuprHjO/BWgmkmxi9/G/46H =+gM7 -----END PGP SIGNATURE----- --Sig_/peCZrg=VVu+8NKStqsZ/+DH-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 15:04:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5511EFAB; Sat, 19 Jan 2013 15:04:27 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id E50A6F15; Sat, 19 Jan 2013 15:04:26 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0JF4KbQ092237; Sat, 19 Jan 2013 10:04:25 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50FAB5F4.509@m5p.com> Date: Sat, 19 Jan 2013 10:04:20 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: Circular port dependency References: <50EF6935.3070000@m5p.com> <20130111082226.GA2969@reks> <50F0B13B.1050708@m5p.com> In-Reply-To: <50F0B13B.1050708@m5p.com> Content-Type: multipart/mixed; boundary="------------060204020609010307000507" X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Sat, 19 Jan 2013 10:04:26 -0500 (EST) Cc: Gleb Kurtsou X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:04:27 -0000 This is a multi-part message in MIME format. --------------060204020609010307000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/11/13 19:41, George Mitchell wrote: > On 01/11/13 03:22, Gleb Kurtsou wrote: >> On (10/01/2013 20:21), George Mitchell wrote: >>> I grabbed the ports tree as of 308518, the RELEASE_9_1_0 tag. >>> devel/libtool won't build, because it requires autom4te during the >>> configure phase. So I put "BUILD_DEPENDS= autom4te:devel/autoconf" >>> in the Makefile. But autoconf depends on gmake, which depends on >>> gettext, which depends on libiconv, which depends on libtool. >>> What to do? >> [...] It turns out that my problem was due to compiling on the Raspberry Pi, a machine that is slow enough that this post-configure target in the port's top-level Makefile: post-configure: @${FIND} ${WRKSRC} -type f | ${XARGS} ${TOUCH} -f could end up setting the last write time for config.status earlier than the last write time for configure, thereby triggering this make rule in the port's own Makefile: $(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) $(SHELL) ./config.status --recheck It's this "--recheck" that would cause the build to try to run autom4ke, leading to the circular dependency. So the correct fix is as attached, guaranteeing that the config.status modification time will always be later. I'm not entirely sure why the post-configure rule is there in the first place, and svnweb.freebsd.org refuses to show me anything in ports/head/devel below liglogging. I was trying to look at the log for ports/devel/Makefile to see how the post-configure rule got there, because simply removing it also appears to make the build succeed. But I assume it's there for some reason, and this fix seems to be less antagonistic than removing the whole rule. -- George --------------060204020609010307000507 Content-Type: text/plain; charset=us-ascii; name="libtool-Makefile.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="libtool-Makefile.patch" --- Makefile.orig 2013-01-10 19:56:02.000000000 -0500 +++ Makefile 2013-01-19 09:44:24.000000000 -0500 @@ -34,6 +34,6 @@ ${WRKSRC}/configure ${WRKSRC}/libltdl/configure post-configure: - @${FIND} ${WRKSRC} -type f | ${XARGS} ${TOUCH} -f + @${FIND} ${WRKSRC} -type f -name config.status | ${XARGS} ${TOUCH} -f .include --------------060204020609010307000507-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 15:10:58 2013 Return-Path: Delivered-To: freebsd-current@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 502FB410; Sat, 19 Jan 2013 15:10:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 10490FA9; Sat, 19 Jan 2013 15:10:58 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 238B823F763; Sat, 19 Jan 2013 10:10:56 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.4 onyx.glenbarber.us 238B823F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sat, 19 Jan 2013 10:10:54 -0500 From: Glen Barber To: freebsd-current@FreeBSD.org Subject: Fatal trap 12 with process cambio on USB attach Message-ID: <20130119151054.GA1301@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:10:58 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I am running one-day-old -CURRENT: root@nucleus:~ # uname -a FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #51 r245605: Fri Jan 18 11:25:40 EST 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 I attached a MicroSDHC flash card with a MicroSD->USB adapter, and the system crashed with a kernel page fault. I am certain the SDHC card should work, as it works in other FreeBSD machines. kgdb session follows. Please let me know if I can provide further information. Thanks, Glen Script started on Sat Jan 19 10:03:27 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # kgdb kernel.debug /var/crash/vm= core.8 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: umass0:4:0:-1: Attached to scbus4 Fatal trap 12: page fault while in kernel mode cpuid =3D 6; apic id =3D 06 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff802933c9 stack pointer =3D 0x28:0xffffff80003098e0 frame pointer =3D 0x28:0xffffff8000309910 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi2: cambio) trap number =3D 12 panic: page fault cpuid =3D 6 KDB: stack backtrace: #0 0xffffffff80608966 at kdb_backtrace+0x66 #1 0xffffffff805cea9b at panic+0x13b #2 0xffffffff808880a0 at trap_fatal+0x290 #3 0xffffffff80888411 at trap_pfault+0x221 #4 0xffffffff808889c4 at trap+0x344 #5 0xffffffff80872213 at calltrap+0x8 #6 0xffffffff802934a5 at camq_remove+0x65 #7 0xffffffff80298c4f at xpt_run_dev_sendq+0xef #8 0xffffffff802995a0 at camisr_runqueue+0x290 #9 0xffffffff802997bf at camisr+0xff #10 0xffffffff8059fe4d at intr_event_execute_handlers+0xfd #11 0xffffffff805a165e at ithread_loop+0x9e #12 0xffffffff8059ca1f at fork_exit+0x11f #13 0xffffffff8087273e at fork_trampoline+0xe Uptime: 41s Dumping 551 out of 7951 MB:..3%..12%..21%..32%..41%..53%..61%..73%..82% (CT= RL-C to abort) ..93% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/bo= ot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bo= otdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /bootd= ir/boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /bootdir/= boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /bootd= ir/boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boo= tdir/boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /bootdir/bo= ot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/kernel/acpi_asus.ko...Reading symbols from /boot= dir/boot/kernel/acpi_asus.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_asus.ko Reading symbols from /boot/kernel/aesni.ko...Reading symbols from /bootdir/= boot/kernel/aesni.ko.symbols...done. done. Loaded symbols for /boot/kernel/aesni.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/boo= t/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /bootdi= r/boot/kernel/i915kms.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915kms.ko Reading symbols from /boot/kernel/iicbb.ko...Reading symbols from /bootdir/= boot/kernel/iicbb.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbb.ko Reading symbols from /boot/kernel/iicbus.ko...Reading symbols from /bootdir= /boot/kernel/iicbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/iicbus.ko Reading symbols from /boot/kernel/iic.ko...Reading symbols from /bootdir/bo= ot/kernel/iic.ko.symbols...done. done. Loaded symbols for /boot/kernel/iic.ko Reading symbols from /boot/kernel/agp.ko...Reading symbols from /bootdir/bo= ot/kernel/agp.ko.symbols...done. done. Loaded symbols for /boot/kernel/agp.ko Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /bootdir/b= oot/kernel/drm2.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm2.ko Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko #0 doadump (textdump=3D) at pcpu.h:229 229 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) bt #0 doadump (textdump=3D) at pcpu.h:229 #1 0xffffffff805ce604 in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:446 #2 0xffffffff805cea85 in panic (fmt=3D) at /usr/src/s= ys/kern/kern_shutdown.c:753 #3 0xffffffff808880a0 in trap_fatal (frame=3D0xc, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:872 #4 0xffffffff80888411 in trap_pfault (frame=3D0xffffff8000309830, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:789 #5 0xffffffff808889c4 in trap (frame=3D0xffffff8000309830) at /usr/src/sys= /amd64/amd64/trap.c:463 #6 0xffffffff80872213 in calltrap () at /usr/src/sys/amd64/amd64/exception= =2ES:228 #7 0xffffffff802933c9 in heap_down (queue_array=3D0xfffffe01c90223f8, inde= x=3D,=20 num_entries=3D0) at /usr/src/sys/cam/cam_queue.c:357 #8 0xffffffff802934a5 in camq_remove (queue=3D0xfffffe000359e880, index=3D= -1) at /usr/src/sys/cam/cam_queue.c:185 #9 0xffffffff80298c4f in xpt_run_dev_sendq (bus=3D0xfffffe01c909ed00) at c= am_queue.h:210 #10 0xffffffff802995a0 in camisr_runqueue (V_queue=3D)= at /usr/src/sys/cam/cam_xpt.c:5102 #11 0xffffffff802997bf in camisr (dummy=3D) at /usr/sr= c/sys/cam/cam_xpt.c:5002 #12 0xffffffff8059fe4d in intr_event_execute_handlers (p=3D, ie=3D0xfffffe00031ccc00) at /usr/src/sys/kern/kern_intr.c:1272 #13 0xffffffff805a165e in ithread_loop (arg=3D0xfffffe0002f5a800) at /usr/s= rc/sys/kern/kern_intr.c:1285 #14 0xffffffff8059ca1f in fork_exit (callout=3D0xffffffff805a15c0 , arg=3D0xfffffe0002f5a800,=20 frame=3D0xffffff8000309ac0) at /usr/src/sys/kern/kern_fork.c:991 #15 0xffffffff8087273e in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:602 #16 0x0000000000000000 in ?? () (kgdb) frame 7 #7 0xffffffff802933c9 in heap_down (queue_array=3D0xfffffe01c90223f8, inde= x=3D,=20 num_entries=3D0) at /usr/src/sys/cam/cam_queue.c:357 357 if (queue_array[i]->priority =3D=3D queue_array[j]->priorit= y) (kgdb) list *0xffffffff802933c9 0xffffffff802933c9 is in heap_down (/usr/src/sys/cam/cam_queue.c:357). 352 * equal too, or greater than j respectively. 353 */ 354 static __inline int 355 queue_cmp(cam_pinfo **queue_array, int i, int j) 356 { 357 if (queue_array[i]->priority =3D=3D queue_array[j]->priorit= y) 358 return ( queue_array[i]->generation 359 - queue_array[j]->generation ); 360 else 361 return ( queue_array[i]->priority (kgdb) frame 8 #8 0xffffffff802934a5 in camq_remove (queue=3D0xfffffe000359e880, index=3D= -1) at /usr/src/sys/cam/cam_queue.c:185 185 heap_down(queue->queue_array, index, queue->entries= - 1); (kgdb) list *0xffffffff802934a5 0xffffffff802934a5 is in camq_remove (/usr/src/sys/cam/cam_queue.c:187). 182 if (queue->entries !=3D index) { 183 queue->queue_array[index] =3D queue->queue_array[qu= eue->entries]; 184 queue->queue_array[index]->index =3D index; 185 heap_down(queue->queue_array, index, queue->entries= - 1); 186 } 187 removed_entry->index =3D CAM_UNQUEUED_INDEX; 188 queue->entries--; 189 return (removed_entry); 190 } 191 =20 (kgdb) frame 9 #9 0xffffffff80298c4f in xpt_run_dev_sendq (bus=3D0xfffffe01c909ed00) at c= am_queue.h:210 210 camq_remove(&ccbq->queue, ccb->ccb_h.pinfo.index); (kgdb) list *0xffffffff80298c4f 0xffffffff80298c4f is in xpt_run_dev_sendq (cam_queue.h:211). 206 =20 207 static __inline int 208 cam_ccbq_remove_ccb(struct cam_ccbq *ccbq, union ccb *ccb) 209 { 210 camq_remove(&ccbq->queue, ccb->ccb_h.pinfo.index); 211 if (ccbq->queue.qfrozen_cnt[CAM_PRIORITY_TO_RL( 212 ccb->ccb_h.pinfo.priority)] > 0) { 213 ccbq->devq_openings--; 214 ccbq->held--; 215 return (1); (kgdb) frame 10 #10 0xffffffff802995a0 in camisr_runqueue (V_queue=3D)= at /usr/src/sys/cam/cam_xpt.c:5102 5102 xpt_run_dev_sendq(ccb_h->path->bus); (kgdb) list *0xffffffff802995a0 0xffffffff802995a0 is in camisr_runqueue (/usr/src/sys/cam/cam_xpt.c:5102). 5097 && (ccb_h->status & CAM_DEV_QFRZN)) { 5098 xpt_release_devq(ccb_h->path, /*count*/1, 5099 /*run_queue*/TRUE); 5100 ccb_h->status &=3D ~CAM_DEV_QFRZN; 5101 } else if (runq) { 5102 xpt_run_dev_sendq(ccb_h->path->bus); 5103 } 5104 =20 5105 /* Call the peripheral driver's callback */ 5106 (*ccb_h->cbfcnp)(ccb_h->path->periph, (union ccb *)= ccb_h); (kgdb) p *ccb_h $1 =3D {pinfo =3D {priority =3D 896, generation =3D 29, index =3D -1}, xpt_= links =3D {le =3D {le_next =3D 0x0, le_prev =3D 0x0},=20 sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0= }, stqe =3D {stqe_next =3D 0x0}}, sim_links =3D { le =3D {le_next =3D 0x0, le_prev =3D 0xfffffe0185688c28}, sle =3D {sle_= next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0xfffffe0185688c28}, stqe =3D {stqe_next =3D 0x0}}, peri= ph_links =3D {le =3D {le_next =3D 0x0,=20 le_prev =3D 0x0}, sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0= x0, tqe_prev =3D 0x0}, stqe =3D { stqe_next =3D 0x0}}, retry_count =3D 4, cbfcnp =3D 0xffffffff802d6dd0= , func_code =3D XPT_SCSI_IO,=20 status =3D 1, path =3D 0xfffffe0006f878a0, path_id =3D 4, target_id =3D 0= , target_lun =3D 0, flags =3D 64,=20 periph_priv =3D {entries =3D {{ptr =3D 0x1, field =3D 1, bytes =3D "\001\= 000\000\000\000\000\000"}, {ptr =3D 0x0,=20 field =3D 0, bytes =3D "\000\000\000\000\000\000\000"}}, bytes =3D = "\001", '\0' },=20 sim_priv =3D {entries =3D {{ptr =3D 0x0, field =3D 0, bytes =3D "\000\000= \000\000\000\000\000"}, {ptr =3D 0x0,=20 field =3D 0, bytes =3D "\000\000\000\000\000\000\000"}}, bytes =3D = '\0' }, timeout =3D 5000,=20 timeout_ch =3D {callout =3D 0x0}} (kgdb) root@nucleus:/usr/obj/usr/src/sys/NUCLEUS # ^D Script done on Sat Jan 19 10:04:19 2013 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ+rd+AAoJEFJPDDeguUajEpUH/jTWrhMCe4eXDEYIRyzukpTY K/pjnk4AuWAhIKISg9ubcngoZ3HxB2htNuyyO1krQmSOJNbg1YZOByaaEdAajIT2 71slwFYeQxlXIUXvtN3TQw1RXlSW+rSIwxW8uS3wNWGNBAJhYXsuv8Zk+8Gq0Y44 YJ7PrzLfYd5OKBOyJKiAGA3H9N9G3ZEcb7JKVi0aeqkmXZRg0wErjmc5nzFy3HSs rTB03mTJvtrH52+XHVM1Wq0x3pgPVrjTPZht5Cy3IsPB/WadD6oak2GxYvxjMlcF tU7rdxTvr7Po0mr/wzENnqBqY4X3lWmvFD4IhHe0GTQocP9K7N8blYNQ5h/2FdM= =gNHE -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 14:47:10 2013 Return-Path: Delivered-To: freebsd-current@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 8B55ECA4 for ; Sat, 19 Jan 2013 14:47:10 +0000 (UTC) (envelope-from bland@bbnest.net) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4815DE87 for ; Sat, 19 Jan 2013 14:47:09 +0000 (UTC) Received: from eee.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 669CC18220 for ; Sat, 19 Jan 2013 23:26:50 +0900 (JST) Received: from nest.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) (authenticated bits=0) by eee.bbnest.net (8.14.6/8.14.5) with ESMTP id r0JEQaoj004807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 19 Jan 2013 23:26:37 +0900 (JST) (envelope-from bland@bbnest.net) From: Alexander Nedotsukov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: ZFS + usb in trouble? Message-Id: Date: Sat, 19 Jan 2013 23:26:39 +0900 To: FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Jan 19 23:26:50 2013 X-DSPAM-Confidence: 0.9992 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50faad2a48082118611110 X-Mailman-Approved-At: Sat, 19 Jan 2013 15:45:21 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 14:47:10 -0000 Hi All, Just a note that after catch up with -current my zfs pool kissed good = bye. I'll omit details about its last days and go strait to the final = state: Creating pool from scratch: #zpool create tank raidz da{1..3} #zpool status pool: tank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 errors: No known data errors #zfs list NAME USED AVAIL REFER MOUNTPOINT tank 140K 3,56T 40,0K /tank Let's use some space out of it. #dd if=3D/dev/zero of=3D/tank/foo ^C250939+0 records in 250938+0 records out 128480256 bytes transferred in 30.402453 secs (4225983 bytes/sec) Oops... #zpool status pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are = unaffected. action: Determine if the device needs to be replaced, and clear the = errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 5K in 0h0m with 0 errors on Sat Jan 19 23:11:20 = 2013 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da1 ONLINE 0 0 1 da2 ONLINE 0 0 0 da3 ONLINE 0 0 1 At some state (more data copied) it is enough to do another scrub run to = trigger new cksum errors / unrecoverable file loss. I do not see any error messages from kernel and smartctl output has zero = error counters. Full memtest cycle seems to be all right. Kernel built with gcc is suffering from same sympthoms. Tried to create raidz pool out of files and it worked fine (even placed = one chunk to UFS made out of da0).=20 Any idea what it can be? Last kernel which did work was back from October 2012. Thanks, Alexander.= From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 16:49:42 2013 Return-Path: Delivered-To: freebsd-current@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 67BA9AE2; Sat, 19 Jan 2013 16:49:42 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 16287685; Sat, 19 Jan 2013 16:49:41 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id fk10so3152826vcb.30 for ; Sat, 19 Jan 2013 08:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=QESmdYC2Sd2Qmn7rQHjMDExwwUsr+jsMX6f0JlmKci8=; b=UUO3iZwSC6BF8GLRCQGuaisr98D4o1lTRv2BqBI+jRqbOJ5qiI/DR2C8wDcJbZOga5 Ubt+sFgdxRmRvb7UcEkD+KcsVAHCiZcrfq9RlWx0/xh2G7By8hvpI1JG9SovLCls+ZBb v+69hAI38iSRgdy3BQ9DjQAjOJH7GfSnkbFaZNevacDb2yzNXfk+jeZ1ggu6J0mAbrOk aTCKDGq/44cC1flt2DilT2gNe1YZ7AL+RqTqDzTr7Au9Pktn0Va0H7+U0uurQOCrHOvb ZFfSh2TWb2RmzcvLxsNrlg60GzGmkui47PfyWMytCJ4/Yumb44X/7lJ+q3sWi8URiN0W CB1A== X-Received: by 10.52.36.244 with SMTP id t20mr12043083vdj.132.1358614175673; Sat, 19 Jan 2013 08:49:35 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id fb16sm4412225veb.9.2013.01.19.08.49.34 (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 19 Jan 2013 08:49:34 -0800 (PST) Date: Sat, 19 Jan 2013 11:49:24 -0500 From: Alexander Kabaev To: Glen Barber Subject: Re: Fatal trap 12 with process cambio on USB attach Message-ID: <20130119114924.49747e16@kan.dyndns.org> In-Reply-To: <20130119151054.GA1301@glenbarber.us> References: <20130119151054.GA1301@glenbarber.us> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/NZiugf=Cph_MKEXlzaQ45P/"; protocol="application/pgp-signature" Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 16:49:42 -0000 --Sig_/NZiugf=Cph_MKEXlzaQ45P/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 19 Jan 2013 10:10:54 -0500 Glen Barber wrote: > Hi, >=20 > I am running one-day-old -CURRENT: >=20 > root@nucleus:~ # uname -a > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #51 r245605: Fri > Jan 18 11:25:40 EST 2013 > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 >=20 > I attached a MicroSDHC flash card with a MicroSD->USB adapter, and the > system crashed with a kernel page fault. I am certain the SDHC card > should work, as it works in other FreeBSD machines. >=20 > kgdb session follows. Please let me know if I can provide further > information. >=20 > Thanks, >=20 > Glen >=20 This is likely the same crash that is fixed by in r245647: http://svnweb.freebsd.org/changeset/base/245647 --=20 Alexander Kabaev --Sig_/NZiugf=Cph_MKEXlzaQ45P/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQ+s6dQ6z1jMm+XZYRAit0AKCOBZYicOYnZ7hGHAgZUoYncrLa5QCfbwP4 Sq8sa2Qjp36XTeAIECzT0Dc= =jbuo -----END PGP SIGNATURE----- --Sig_/NZiugf=Cph_MKEXlzaQ45P/-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 18:11:31 2013 Return-Path: Delivered-To: current@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 419B6E54; Sat, 19 Jan 2013 18:11:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 03B30AB1; Sat, 19 Jan 2013 18:11:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r0JIBNuh069748; Sat, 19 Jan 2013 13:11:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0JIBNR1069686; Sat, 19 Jan 2013 18:11:23 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Jan 2013 18:11:23 GMT Message-Id: <201301191811.r0JIBNR1069686@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 18:11:31 -0000 TB --- 2013-01-19 16:13:11 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-19 16:13:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-19 16:13:11 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-19 16:13:11 - cleaning the object tree TB --- 2013-01-19 16:15:10 - /usr/local/bin/svn stat /src TB --- 2013-01-19 16:15:14 - At svn revision 245668 TB --- 2013-01-19 16:15:15 - building world TB --- 2013-01-19 16:15:15 - CROSS_BUILD_TESTING=YES TB --- 2013-01-19 16:15:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-19 16:15:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-19 16:15:15 - SRCCONF=/dev/null TB --- 2013-01-19 16:15:15 - TARGET=ia64 TB --- 2013-01-19 16:15:15 - TARGET_ARCH=ia64 TB --- 2013-01-19 16:15:15 - TZ=UTC TB --- 2013-01-19 16:15:15 - __MAKE_CONF=/dev/null TB --- 2013-01-19 16:15:15 - cd /src TB --- 2013-01-19 16:15:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 19 16:15:20 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 19 17:50:55 UTC 2013 TB --- 2013-01-19 17:50:55 - generating LINT kernel config TB --- 2013-01-19 17:50:55 - cd /src/sys/ia64/conf TB --- 2013-01-19 17:50:55 - /usr/bin/make -B LINT TB --- 2013-01-19 17:50:55 - cd /src/sys/ia64/conf TB --- 2013-01-19 17:50:55 - /usr/sbin/config -m LINT TB --- 2013-01-19 17:50:55 - building LINT kernel TB --- 2013-01-19 17:50:55 - CROSS_BUILD_TESTING=YES TB --- 2013-01-19 17:50:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-19 17:50:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-19 17:50:55 - SRCCONF=/dev/null TB --- 2013-01-19 17:50:55 - TARGET=ia64 TB --- 2013-01-19 17:50:55 - TARGET_ARCH=ia64 TB --- 2013-01-19 17:50:55 - TZ=UTC TB --- 2013-01-19 17:50:55 - __MAKE_CONF=/dev/null TB --- 2013-01-19 17:50:55 - cd /src TB --- 2013-01-19 17:50:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 19 17:50:55 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-19 18:11:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-19 18:11:23 - ERROR: failed to build LINT kernel TB --- 2013-01-19 18:11:23 - 5387.36 user 1219.68 system 7092.53 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 19 18:44:30 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D2FF30F; Sat, 19 Jan 2013 18:44:30 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 025C6BEA; Sat, 19 Jan 2013 18:44:30 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 6926623F763; Sat, 19 Jan 2013 13:44:28 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.7.4 onyx.glenbarber.us 6926623F763 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Date: Sat, 19 Jan 2013 13:44:26 -0500 From: Glen Barber To: Alexander Kabaev Subject: Re: Fatal trap 12 with process cambio on USB attach Message-ID: <20130119184426.GB1301@glenbarber.us> References: <20130119151054.GA1301@glenbarber.us> <20130119114924.49747e16@kan.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <20130119114924.49747e16@kan.dyndns.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 18:44:30 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 19, 2013 at 11:49:24AM -0500, Alexander Kabaev wrote: > On Sat, 19 Jan 2013 10:10:54 -0500 > Glen Barber wrote: >=20 > > Hi, > >=20 > > I am running one-day-old -CURRENT: > >=20 > > root@nucleus:~ # uname -a > > FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #51 r245605: Fri > > Jan 18 11:25:40 EST 2013 > > root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 > >=20 > > I attached a MicroSDHC flash card with a MicroSD->USB adapter, and the > > system crashed with a kernel page fault. I am certain the SDHC card > > should work, as it works in other FreeBSD machines. > >=20 > > kgdb session follows. Please let me know if I can provide further > > information. > >=20 > > Thanks, > >=20 > > Glen > >=20 >=20 > This is likely the same crash that is fixed by in r245647: >=20 > http://svnweb.freebsd.org/changeset/base/245647 Thanks, I'll give it a shot. Glen --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQ+umKAAoJEFJPDDeguUaj9mEH/1kSS0yyujQRDD9lKePUozo6 G40BPr2kkz1SCfRuXmCUIYrYFg9wN7bG8Ov34e1dlj9E9XDm7+lDnSVl/G620lA4 j1Q/qEWxZfo1mWr/7wCmTYO60TToaS/bY+Hq3tcKPQDl4p/RH0LD32V+cetRbIki zdX7Ed1C2iQN94hsm5ZdZeb1iL56b6U2zUTobTmncq/mmXNAUpm7dEWmEpQXErg3 AIMTON+1NVUsLHkORg4Gt7B2GKvgmloV/SmsmwOsiSmOce5T1yQbzEfoJXwqApFJ uq+6NiW09KU6JFUqOP9raIGbs6CEuiiH2zGsQTsX5JFeHvGeNpfzM1Z4nZkQzEI= =9Lwh -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp--