From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 05:51:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5410EF4; Sun, 7 Jul 2013 05:51:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 506F211D3; Sun, 7 Jul 2013 05:51:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r675pCpx063057; Sun, 7 Jul 2013 15:51:13 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 7 Jul 2013 15:51:12 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130707154526.O26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Lars Engels , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 05:51:25 -0000 On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > On 30 June 2013 07:22, Ian Smith wrote: [..] > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > Maybe someone who knows might comment on that? Does noone know what that signifies? Maybe it's not relevant to this. > > Just checking: you've tried other USB devices apart from uftdi0? > > Yup, there's no 5v on the port. I was rather taken aback to hear this. Would not this indicate a failure to reinitialise the basic underlying USB hardware on resume? More than a bit bemused, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 06:33:02 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0CB0F6CF; Sun, 7 Jul 2013 06:33:02 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id E3FB212B9; Sun, 7 Jul 2013 06:33:01 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 64EFA638D8; Sat, 6 Jul 2013 23:33:01 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 43573-08; Sat, 6 Jul 2013 23:33:01 -0700 (PDT) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id EDF02638D2; Sat, 6 Jul 2013 23:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1373178781; bh=g4fMP9F5ICMS2TNVh62uSCTPvXOHWtqdwmiYyOGpGvM=; h=Date:From:To:Subject; b=iBXVXNj7UJ+TgwRdLWkSb7+29s/N7DEoDDP1xuQNybJLzR+YUpFNIxIZHMQ9bZbmL PZaAAI1V3CHH79sp6IMEwj1vWk2XGJc++Q5i1ozwYZCPa6pYr2aqKEG93OVTuh3Izw HQYqKgHovePRUty/vLwHv7jeNzPxEEnApb0pXiuw= Message-ID: <51D90B9B.9080209@ixsystems.com> Date: Sat, 06 Jul 2013 23:32:59 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stable@freebsd.org, Andre Oppermann , re@freebsd.org Subject: status of autotuning freebsd for 9.2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 06:33:02 -0000 Andre, Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic 10gigE when sufficient memory exists. If you don't have time, then let me know and I'll see what I can do. -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 07:26:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BEC05D81; Sun, 7 Jul 2013 07:26:01 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3C59413B7; Sun, 7 Jul 2013 07:26:00 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r677Prc1011068; Sun, 7 Jul 2013 09:25:53 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r677PrTZ002303; Sun, 7 Jul 2013 09:25:53 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r677PrFc027795; Date: Sun, 7 Jul 2013 09:25:53 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130707072553.GA38133@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130704061550.GI91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:26:01 -0000 On Thu, 04-Jul-2013 at 08:15:50 +0200, Konstantin Belousov wrote: > On Thu, Jul 04, 2013 at 07:27:00AM +0200, Andre Albsmeier wrote: > > On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: > > > On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: > > > > On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: > > > > > On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: > > > > > > On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: > > > > > > > On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: > > > > > > > > Each day at 5:15 we are generating snapshots on various machines. > > > > > > > > This used to work perfectly under 7-STABLE for years but since > > > > > > > > we started to use 9.1-STABLE the machine reboots in about 10% > > > > > > > > of all cases. > > > > > > > > > > > > > > > > After rebooting we find a new snapshot file which is a bit > > > > > > > > smaller than the good ones and with different permissions > > > > > > > > It does not succeed a fsck. In this example it is the one > > > > > > > > whose name is beginning with s3: > > > > > > > > > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 > > > > > > > > -r-------- 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 > > > > > > > > -r--r----- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 > > > > > > > > > > > > > > > > After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel > > > > > > > > I see the following LORs (mksnap_ffs starts exactly at 5:15): > > > > > > > > > > > > > > > > May 29 05:15:00 palveli kernel: lock order reversal: > > > > > > > > May 29 05:15:00 palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 > > > > > > > > May 29 05:15:00 palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 > > > > > > > > May 29 05:15:04 palveli kernel: lock order reversal: > > > > > > > > May 29 05:15:04 palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 > > > > > > > > May 29 05:15:04 palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 > > > > > > > > > > > > > > > > Unfortunatley no corefiles are being generated ;-(. > > > > > > > > > > > > > > > > I have checked and even rebuilt the (UFS1) fs in question > > > > > > > > from scratch. I have also seen this happen on an UFS2 on > > > > > > > > another machine and on a third one when running "dump -L" > > > > > > > > on a root fs. > > > > > > > > > > > > > > > > Any hints of how to proceed? > > > > > > > > > > > > > > Would it be possible to setup a serial console that is logged on this machine > > > > > > > to see if it is panic'ing but failing to write out a crashdump? > > > > > > > > > > > > Couldn't attach the serial console yet ;-(. But I had people > > > > > > attach a KVMoverIP switch and enabled the various KDB options > > > > > > in the kernel. Now we can see a bit more (see below) -- no > > > > > > crashdump is being generated though. > > > > > > > > > > :( Unfortunately these LORs don't really help with discerning the cause of > > > > > the reboot. If you have remote power access (and still wanted to test this) > > > > > one option would be to change KDB to drop into the debugger on a panic. > > > > > Then you could connect over the KVM and take images of the original panic > > > > > along with a stack trace. > > > > > > > > After a few days of no problems, the box decided to crash > > > > during mksnap_ffs today ;-(. But now I have a crashdump, > > > > see below. Unfortunatley, I cannot upload the dump somewhere > > > > but if you ask me check whatever things I'll be happy to help. > > > > > > > > kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 > > > > 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 "i386-marcel-freebsd"... > > > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address = 0xcfb5e000 > > > > fault code = supervisor write, page not present > > > > instruction pointer = 0x20:0xc07cb2fe > > > > stack pointer = 0x28:0xd83545d0 > > > > frame pointer = 0x28:0xd835490c > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 12929 (mksnap_ffs) > > > > trap number = 12 > > > > panic: page fault > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd83543ec > > > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_backtrace+0x29/frame 0xd83543f8 > > > > panic(c0801bfa,c0845a01,c2bafae4,1,1,...) at panic+0xc9/frame 0xd835441c > > > > trap_fatal(c0ff6000,cfb5e000,2,0,265abf,...) at trap_fatal+0x353/frame 0xd835445c > > > > trap_pfault(140da,0,c2baf930,c08b6a40,c282145c,...) at trap_pfault+0x2d7/frame 0xd83544a4 > > > > trap(d8354590) at trap+0x41a/frame 0xd8354584 > > > > calltrap() at calltrap+0x6/frame 0xd8354584 > > > > --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd83545d0, ebp = 0xd835490c --- > > > > bcopy(c2b36548,c2f194e0,0,0,0,...) at bcopy+0x1a/frame 0xd835490c > > > > ffs_mount(c2b36548,c2db9000,ff,d8354c08,c2b665e4,...) at ffs_mount+0x15ee/frame 0xd8354a3c > > > > > > From the crash dump in kgdb, do > > > list *ffs_mount+0x15ee > > > > (kgdb) list *ffs_mount+0x15ee > > 0xc0748e8e is in ffs_mount (/src/src-9/sys/ufs/ffs/ffs_vfsops.c:483). > > 478 > > 479 /* > > 480 * If this is a snapshot request, take the snapshot. > > 481 */ > > 482 if (mp->mnt_flag & MNT_SNAPSHOT) > > 483 return (ffs_snapshot(mp, fspec)); > > 484 } > > 485 > > 486 /* > > 487 * Not an update, or updating the name: look up the name > > It is not useful, bcopy does not create a frame, so the real caller > of the failing bcopy gets lost. It could be uncovered with some > stack digging, but I believe it would be easier just fix bcopy. > > Please apply this patch and reproduce the panic again, then the kgdb > backtrace should be more useful. OK, here we go (looks better now): 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: dev = stripe/p, block = 592, fs = /palveli panic: ffs_blkfree_cg: freeing free block KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d70fc924,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd70fc8f4 kdb_backtrace(c081df13,c08a82e0,c0833a0b,d70fc930,d70fc930,...) at kdb_backtrace+0x29/frame 0xd70fc900 panic(c0833a0b,c2aae178,250,0,c2af80d4,...) at panic+0xc9/frame 0xd70fc924 ffs_blkfree_cg(250,0,8000,49f,d70fcad0,...) at ffs_blkfree_cg+0x399/frame 0xd70fc9c8 ffs_blkfree(c2b35100,c2af8000,c2b0d470,250,0,...) at ffs_blkfree+0xad/frame 0xd70fca00 indir_trunc(fffa3ff4,ffffffff,0,8000,0,...) at indir_trunc+0x658/frame 0xd70fcae0 indir_trunc(ffffdff3,ffffffff,c072df0a,c2d68d00,c087abd8,...) at indir_trunc+0x514/frame 0xd70fcbc0 handle_workitem_freeblocks(0,d70fcc4c,2,246,c2ab1000,...) at handle_workitem_freeblocks+0x2dc/frame 0xd70fcc24 process_worklist_item(0,0,0,c086ae78,0,...) at process_worklist_item+0x27a/frame 0xd70fcc6c softdep_process_worklist(c2b36548,0,54,c0835825,64,...) at softdep_process_worklist+0x91/frame 0xd70fcc9c softdep_flush(0,d70fcd08,0,c2aac2f0,0,...) at softdep_flush+0x3e4/frame 0xd70fcccc fork_exit(c0738bb0,0,d70fcd08) at fork_exit+0xa2/frame 0xd70fccf4 fork_trampoline() at fork_trampoline+0x8/frame 0xd70fccf4 --- trap 0, eip = 0, esp = 0xd70fcd40, ebp = 0 --- Uptime: 2d16h29m37s Physical memory: 503 MB Dumping 95 MB: 80 64 48 32 16 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc0717899 in ffs_blkfree_cg (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, size=32768, inum=1183, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2151 #4 0xc0717c8d in ffs_blkfree (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, size=32768, inum=1183, vtype=VREG, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2280 #5 0xc0730348 in indir_trunc (freework=0xc2f99100, dbn=1642816, lbn=-376844) at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7965 #6 0xc0730204 in indir_trunc (freework=0xc2f99100, dbn=1639680, lbn=-8205) at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7946 #7 0xc07324bc in handle_workitem_freeblocks (freeblks=0xc2fc1e00, flags=512) at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7588 #8 0xc0730dfa in process_worklist_item (mp=0xc2b36548, target=10, flags=512) at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1774 #9 0xc07360c1 in softdep_process_worklist (mp=0xc2b36548, full=0) at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1558 #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 #11 0xc05d1b82 in fork_exit (callout=0xc0738bb0 , arg=0x0, frame=0xd70fcd08) at /src/src-9/sys/kern/kern_fork.c:988 #12 0xc07ba904 in fork_trampoline () at /src/src-9/sys/i386/i386/exception.s:279 (kgdb) up 10 #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 1414 progress += softdep_process_worklist(mp, 0); -Andre From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 07:32:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 87CF5EBC; Sun, 7 Jul 2013 07:32:56 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF4E1469; Sun, 7 Jul 2013 07:32:55 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 24D177A172; Sun, 7 Jul 2013 09:32:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 084238ED850; Sun, 7 Jul 2013 09:32:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYb+-B2Yc4U0; Sun, 7 Jul 2013 09:32:52 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id C20FE8ED84F; Sun, 7 Jul 2013 09:32:51 +0200 (CEST) Subject: RE: USB ports on Lenovo T400 do not work after a suspend/resume From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Ian_Smith?= , =?utf-8?Q?Adrian_Chadd?= Date: Sun, 7 Jul 2013 09:32:51 +0200 Mime-Version: 1.0 In-Reply-To: <20130707154526.O26496@sola.nimnet.asn.au> References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-acpi=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-stable=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-usb=40freebsd=2Eorg?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:32:56 -0000 Hi,=0D=0A=0D=0AFYI: The USB stack will currently run a complete controlle= r reset upon resume, like during boot.=0D=0A=0D=0A--HPS=20=0D=0A=0D=0A=20= =0D=0A-----Original message-----=0D=0A> From:Ian Smith >=0D=0A> Sent: Sunday 7th July 2013 7= :52=0D=0A> To: Adrian Chadd >=0D=0A> Cc: freebsd-acpi@freebsd.org ; freebsd-stable@freebsd.org ; free= bsd-usb@freebsd.org =20=0D=0A> Subject: R= e: USB ports on Lenovo T400 do not work after a suspend/resume=0D=0A>=20=0D= =0A> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:=0D=0A> > On= 30 June 2013 07:22, Ian Smith > wrote:=0D=0A> [..]=0D=0A> > > Nothing of note that I can see= , if that usb hub-to-bus remapping is=0D=0A> > > normal. As you said, '= CPU0: local APIC error 0x40' looks maybe sus.=0D=0A> > > Maybe someone w= ho knows might comment on that=3F=0D=0A>=20=0D=0A> Does noone know what t= hat signifies=3F Maybe it's not relevant to this.=0D=0A>=20=0D=0A> > > = Just checking: you've tried other USB devices apart from uftdi0=3F=0D=0A>= >=20=0D=0A> > Yup, there's no 5v on the port.=0D=0A>=20=0D=0A> I was r= ather taken aback to hear this. Would not this indicate a=20=0D=0A> fail= ure to reinitialise the basic underlying USB hardware on resume=3F=0D=0A>= =20=0D=0A> More than a bit bemused, Ian=0D=0A> __________________________= _____________________=0D=0A> freebsd-acpi@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailman/list= info/freebsd-acpi =20=0D=0A> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@fr= eebsd.org "=0D=0A>=20=0D=0A= =0D=0A From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 07:36:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 902ADBD; Sun, 7 Jul 2013 07:36:43 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE6115BB; Sun, 7 Jul 2013 07:36:42 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id B10A67A185; Sun, 7 Jul 2013 09:36:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 9C9518ED852; Sun, 7 Jul 2013 09:36:41 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6E3vCOiERQs; Sun, 7 Jul 2013 09:36:40 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0A7CD8ED850; Sun, 7 Jul 2013 09:36:40 +0200 (CEST) Subject: RE: XHCI umass support breaks between r248085 and r252560 on 9-STABLE From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Alexandre_Kovalenko?= , =?utf-8?Q?freebsd-usb=40freebsd=2Eorg?= Date: Sun, 7 Jul 2013 09:36:39 +0200 Mime-Version: 1.0 In-Reply-To: <94A3DD2E-F2E2-4302-8197-BAB213641E2F@gmail.com> References: <94A3DD2E-F2E2-4302-8197-BAB213641E2F@gmail.com> X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?mav=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-stable=40freebsd=2Eorg?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:36:43 -0000 Hi,=0D=0A=0D=0ACheck for CAM/SCSI related changes. There has not been so = many USB changes recently. Possibly not USB related.=0D=0A=0D=0AThank you= ,=0D=0A=0D=0A--HPS=0D=0A=20=0D=0A-----Original message-----=0D=0A> From:A= lexandre Kovalenko >=0D= =0A> Sent: Thursday 4th July 2013 20:58=0D=0A> To: freebsd-usb@freebsd.or= g =20=0D=0A> Cc: freebsd-stable@freebsd.o= rg =20=0D=0A> Subject: XHCI umass supp= ort breaks between r248085 and r252560 on 9-STABLE=0D=0A>=20=0D=0A> Three= different external hard drives (Seagate, Western Digital and noname USB = 3.0 enclosure) refused to be recognized as the umass devices. Reverting /= usr/src/sys/dev/bsd/controller to r248085, building and loading just xhci= module makes drives appear again. Below are snippets from the log in bot= h cases:=0D=0A>=20=0D=0A> Non working:=0D=0A>=20=0D=0A> Jul 4 14:35:17 t= winhead kernel: xhci0: mem 0xfddfe000= -0xfddfffff irq 16 at device 0.0 on pci2=0D=0A> Jul 4 14:35:17 twinhead = kernel: xhci0: 64 byte context size.=0D=0A> Jul 4 14:35:17 twinhead kern= el: usbus0 on xhci0=0D=0A> Jul 4 14:35:17 twinhead kernel: usbus0: 5.0Gb= ps Super Speed USB v3.0=0D=0A> Jul 4 14:35:17 twinhead kernel: ugen0.1: = <0x1912> at usbus0=0D=0A> Jul 4 14:35:17 twinhead kernel: uhub0: <0x1912= XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0=0D=0A> Jul 4= 14:35:17 twinhead kernel: uhub0: 8 ports with 8 removable, self powered=0D= =0A> Jul 4 14:35:24 twinhead kernel: ugen0.2: at usbus0=0D=0A>= Jul 4 14:35:24 twinhead kernel: umass0: on usbus0=0D=0A> Jul 4 14:35:29 twinhead kernel: (pr= obe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20=0D=0A> Jul 4 = 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB requ= est completed with an error=0D=0A> Jul 4 14:35:29 twinhead kernel: (prob= e0:umass-sim0:0:0:0): Retrying command=0D=0A> Jul 4 14:35:30 twinhead ke= rnel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20=0D=0A= > Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status:= CCB request completed with an error=0D=0A> Jul 4 14:35:30 twinhead kern= el: (probe0:umass-sim0:0:0:0): Retrying command=0D=0A> Jul 4 14:35:35 tw= inhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00= =20=0D=0A> Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): CA= M status: CCB request completed with an error=0D=0A> Jul 4 14:35:35 twin= head kernel: (probe0:umass-sim0:0:0:0): Retrying command=0D=0A> Jul 4 14= :35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00= 00 24 00=20=0D=0A> Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0= :0:0): CAM status: CCB request completed with an error=0D=0A> Jul 4 14:3= 5:36 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command=0D=0A> = Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB:= 12 00 00 00 24 00=20=0D=0A> Jul 4 14:35:41 twinhead kernel: (probe0:uma= ss-sim0:0:0:0): CAM status: CCB request completed with an error=0D=0A> Ju= l 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 5, Retrie= s exhausted=0D=0A>=20=0D=0A> Working:=0D=0A>=20=0D=0A> Jul 4 14:40:20 tw= inhead kernel: ugen0.2: at usbus0 (disconnected)=0D=0A> Jul 4 = 14:40:20 twinhead kernel: umass0: at uhub0, port 2, addr 1 (disconnected)= =0D=0A> Jul 4 14:40:27 twinhead kernel: ugen0.2: at usbu= s0=0D=0A> Jul 4 14:40:27 twinhead kernel: umass0: on usbus0=0D=0A> Jul 4 14:40:= 27 twinhead kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00= 00 00 00 00 00 00 10 00 00=20=0D=0A> Jul 4 14:40:27 twinhead kernel: (p= robe0:umass-sim0:0:0:0): CAM status: SCSI Status Error=0D=0A> Jul 4 14:4= 0:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI status: Check Condi= tion=0D=0A> Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): S= CSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)=0D=0A= > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 22, U= nretryable error=0D=0A> Jul 4 14:40:27 twinhead kernel: da0 at umass-sim= 0 bus 0 scbus4 target 0 lun 0=0D=0A> Jul 4 14:40:27 twinhead kernel: da0= : Fixed Direct Access SCSI-5 device=20=0D=0A= > Jul 4 14:40:27 twinhead kernel: da0: 400.000MB/s transfers=0D=0A> Jul = 4 14:40:27 twinhead kernel: da0: 190782MB (390721968 512 byte sectors: 2= 55H 63S/T 24321C)=0D=0A> Jul 4 14:40:27 twinhead kernel: da0: quirks=3D0= x2=0D=0A>=20=0D=0A> I can provide additional information or tr= y patches as necessary.=0D=0A>=20=0D=0A> Alexandre "Sunny" Kovalenko (=D0= =9E=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 =D0=9A=D0=BE=D0=B2=D0= =B0=D0=BB=D0=B5=D0=BD=D0=BA=D0=BE)=0D=0A>=20=0D=0A> _____________________= __________________________=0D=0A> freebsd-usb@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailman/l= istinfo/freebsd-usb =20=0D=0A> To unsubscribe, send any mail to "freebsd-usb-unsubscribe@fr= eebsd.org "=0D=0A=0D=0A From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 07:41:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9236C2EA; Sun, 7 Jul 2013 07:41:17 +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 0826915E2; Sun, 7 Jul 2013 07:41:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r677fC2c063043; Sun, 7 Jul 2013 10:41:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r677fC2c063043 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r677fCqp063042; Sun, 7 Jul 2013 10:41:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Jul 2013 10:41:12 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130707074112.GD91021@kib.kiev.ua> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130707072553.GA38133@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FIrcIS49ZjgQdfhA" Content-Disposition: inline In-Reply-To: <20130707072553.GA38133@bali> 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-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:41:17 -0000 --FIrcIS49ZjgQdfhA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 07, 2013 at 09:25:53AM +0200, Andre Albsmeier wrote: > OK, here we go (looks better now): >=20 > 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 "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > dev =3D stripe/p, block =3D 592, fs =3D /palveli > panic: ffs_blkfree_cg: freeing free block > KDB: stack backtrace: > db_trace_self_wrapper(c08207eb,d70fc924,c05fdfc9,c081df13,c08a82e0,...) a= t db_trace_self_wrapper+0x26/frame 0xd70fc8f4 > kdb_backtrace(c081df13,c08a82e0,c0833a0b,d70fc930,d70fc930,...) at kdb_ba= cktrace+0x29/frame 0xd70fc900 > panic(c0833a0b,c2aae178,250,0,c2af80d4,...) at panic+0xc9/frame 0xd70fc924 > ffs_blkfree_cg(250,0,8000,49f,d70fcad0,...) at ffs_blkfree_cg+0x399/frame= 0xd70fc9c8 > ffs_blkfree(c2b35100,c2af8000,c2b0d470,250,0,...) at ffs_blkfree+0xad/fra= me 0xd70fca00 > indir_trunc(fffa3ff4,ffffffff,0,8000,0,...) at indir_trunc+0x658/frame 0x= d70fcae0 > indir_trunc(ffffdff3,ffffffff,c072df0a,c2d68d00,c087abd8,...) at indir_tr= unc+0x514/frame 0xd70fcbc0 > handle_workitem_freeblocks(0,d70fcc4c,2,246,c2ab1000,...) at handle_worki= tem_freeblocks+0x2dc/frame 0xd70fcc24 > process_worklist_item(0,0,0,c086ae78,0,...) at process_worklist_item+0x27= a/frame 0xd70fcc6c > softdep_process_worklist(c2b36548,0,54,c0835825,64,...) at softdep_proces= s_worklist+0x91/frame 0xd70fcc9c > softdep_flush(0,d70fcd08,0,c2aac2f0,0,...) at softdep_flush+0x3e4/frame 0= xd70fcccc > fork_exit(c0738bb0,0,d70fcd08) at fork_exit+0xa2/frame 0xd70fccf4 > fork_trampoline() at fork_trampoline+0x8/frame 0xd70fccf4 > --- trap 0, eip =3D 0, esp =3D 0xd70fcd40, ebp =3D 0 --- > Uptime: 2d16h29m37s > Physical memory: 503 MB > Dumping 95 MB: 80 64 48 32 16 >=20 > No symbol "stopped_cpus" in current context. > No symbol "stoppcbs" in current context. > #0 doadump (textdump=3D1) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump (textdump=3D1) at pcpu.h:249 > #1 0xc05fdddd in kern_reboot (howto=3D260) at /src/src-9/sys/kern/kern_s= hutdown.c:449 > #2 0xc05fe028 in panic (fmt=3D) at /src/src-9/sys/k= ern/kern_shutdown.c:637 > #3 0xc0717899 in ffs_blkfree_cg (ump=3D0xc2b35100, fs=3D0xc2af8000, devv= p=3D0xc2b0d470, bno=3D592,=20 > size=3D32768, inum=3D1183, dephd=3D0xd70fcad0) at /src/src-9/sys/ufs/= ffs/ffs_alloc.c:2151 > #4 0xc0717c8d in ffs_blkfree (ump=3D0xc2b35100, fs=3D0xc2af8000, devvp= =3D0xc2b0d470, bno=3D592,=20 > size=3D32768, inum=3D1183, vtype=3DVREG, dephd=3D0xd70fcad0) at /src/= src-9/sys/ufs/ffs/ffs_alloc.c:2280 > #5 0xc0730348 in indir_trunc (freework=3D0xc2f99100, dbn=3D1642816, lbn= =3D-376844) > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7965 > #6 0xc0730204 in indir_trunc (freework=3D0xc2f99100, dbn=3D1639680, lbn= =3D-8205) > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7946 > #7 0xc07324bc in handle_workitem_freeblocks (freeblks=3D0xc2fc1e00, flag= s=3D512) > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7588 > #8 0xc0730dfa in process_worklist_item (mp=3D0xc2b36548, target=3D10, fl= ags=3D512) > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1774 > #9 0xc07360c1 in softdep_process_worklist (mp=3D0xc2b36548, full=3D0) > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1558 > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.= c:1414 > #11 0xc05d1b82 in fork_exit (callout=3D0xc0738bb0 , arg=3D= 0x0, frame=3D0xd70fcd08) > at /src/src-9/sys/kern/kern_fork.c:988 > #12 0xc07ba904 in fork_trampoline () at /src/src-9/sys/i386/i386/exceptio= n.s:279 > (kgdb) up 10 > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.= c:1414 > 1414 progress +=3D softdep_process_worklist(mp= , 0); >=20 > -Andre This looks unrelated, and exactly this panic is usually has one of two causes: - corrupted filesystem, run fsck to recheck it; - faulty hardware, most likely RAM, but might be CPU/CPU cache/bus. Is it the same machine where the bcopy panic occured ? --FIrcIS49ZjgQdfhA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2RuXAAoJEJDCuSvBvK1BkrsP/A3g98hO9rMhBWUSVmnQSmLs QG4mJLN1AK2eowflKOPde6+nOVDcMnS8Z4vP2Mfagc7VF+3bmPY3FHO1s8H2BvAD RmPtH+z1eBLJJQKBwgiYxUgAwX/MoJU2cda3mmU1WrGYSJjxb9clLL9PKJfhFN6X Mju9BT92Uj0TZN74D15DTDTyTp8bgv9bYvm68DA9Ckf93nHdSqlQUGu66Kx5griF pyO2AXGtCYowxLeLkBfWEjL9uYTO5PTUGwBft817DVnZI2DmdG6SOj8crJiA0S5q nwpvkgKGNsjvsBSG2RnEW/f2vkpfwERJb47M9d9qgzE/FEyljmnnnIipYPFEJY4t ZKKDSoMDxzu+8sGZDgw2DJx9sNaOklnA6EVuVyGtdEjLyvZVmtsiiYPji0lBY7mA hzHibLoPQg5g5GwMHZHngBBYW/F+iNhhHcbZ3LPznvBE56QQwCuEW34FF9qYswrB qtfePkwidCzfFzc+C/kehtc+VZMZaQv5fP0ep1lm+krvipPd5Nkjqaly/7eDF6uH JbsFu4fEfa5D6ttXGIsKII+NMYepMqQfA1X8f7gFjiyrUn+dxkAL3H4MzE7mAbT8 nL1UBo1+eDBz8g5blZj63bN4CcDOtrnTQWM0cK3USwmope1YuBCv3u6BCPD9T+kV TMjpiYDWDSassU+lNraR =uQ1f -----END PGP SIGNATURE----- --FIrcIS49ZjgQdfhA-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 08:35:03 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 236314BB for ; Sun, 7 Jul 2013 08:35:03 +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 8F4A71A9E for ; Sun, 7 Jul 2013 08:35:02 +0000 (UTC) Received: (qmail 56551 invoked from network); 7 Jul 2013 09:26:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Jul 2013 09:26:15 -0000 Message-ID: <51D92826.1070707@freebsd.org> Date: Sun, 07 Jul 2013 10:34:46 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> In-Reply-To: <51D90B9B.9080209@ixsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 08:35:03 -0000 On 07.07.2013 08:32, Alfred Perlstein wrote: > Andre, > > Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I simply ran out of time on Friday and MFCing such a big change requires more testing. > I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic > 10gigE when sufficient memory exists. There was some debate with myself whether such a behavior changing MFC would be appropriate for a mid-stream stable release. I guess yes, though a number of people who currently set the parameters manually would have to remove their tuning settings. > If you don't have time, then let me know and I'll see what I can do. Can you help me with with testing? -- Andre From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 08:50:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1735F635; Sun, 7 Jul 2013 08:50:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C1D241AEB; Sun, 7 Jul 2013 08:50:38 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Uvkft-0007jb-O6; Sun, 07 Jul 2013 11:50:29 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Jeremy Chadwick Subject: Re: make buildworld is now 50% slower In-reply-to: <20130705145839.GB5449@icarus.home.lan> References: <20130705145839.GB5449@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 05 Jul 2013 07:58:39 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Jul 2013 11:50:29 +0300 From: Daniel Braniss Message-ID: Cc: "freebsd-stable@freebsd.org Stable" , Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 08:50:39 -0000 > On Fri, Jul 05, 2013 at 02:39:00PM +0200, Dimitry Andric wrote: > > [redirecting to the correct mailing list, freebsd-stable@ ...] > > > > On Jul 5, 2013, at 10:53, Daniel Braniss wrote: > > > after today's update of 9.1-STABLE I noticed that make build[world|kernel] are > > > taking conciderable more time, is it because the upgrade of clang? > > > and if so, is the code produced any better? > > > > > > before: > > > buildwordl: 26m4.52s real 2h28m32.12s user 36m6.27s sys > > > buildkernel: 7m29.42s real 23m22.22s user 4m26.26s sys > > > > > > today: > > > buildwordl: 34m29.80s real 2h38m9.37s user 37m7.61s sys > > > buildkernel: 15m31.52s real 22m59.40s user 4m33.06s sys > > > > Ehm, your user and sys times are not that much different at all, they > > add up to about 5% slower for buildworld, and 1% faster for build kernel. > > Are you sure nothing else is running on that machine, eating up CPU time > > while you are building? :) > > > > But yes, clang 3.3 is of course somewhat larger than 3.2. You might > > especially notice that, if you are using gcc, which is very slow at > > compiling C++. > > > > In any case, if you do not care about clang, just set WITHOUT_CLANG= in > > your /etc/src.conf, and you can shave off some build time. > > I just built world/kernel (stable/9 r252769) 5 hours ago. Results: > > time make -j4 buildworld = roughly 21 minutes on my hardware > time make -j4 buildkernel = roughly 8 minutes on my hardware > It's been a long time since I saw such numbers, maybe it's time to see where time is being spent, I will run it without clang to compare with your numbers. > These numbers are about the norm for me, meaning I do not see a > substantial increase in build times. > > Key point: I do not use/build/grok clang, i.e. WITHOUT_CLANG=true is in > my src.conf. But I am aware of the big clang change in r252723. > > If hardware details are wanted, ask, but I don't think it's relevant to > what the root cause is. > from what you are saying, I guess clang is not responsible. looking for my Sherlock Holmes hat. thanks, danny > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 09:24:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23CB2FF6 for ; Sun, 7 Jul 2013 09:24:55 +0000 (UTC) (envelope-from kaushalgoa@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id B338B1C38 for ; Sun, 7 Jul 2013 09:24:54 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id o10so2282210eaj.33 for ; Sun, 07 Jul 2013 02:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZJc8ucmJArd8HCA4mKtGT6miH1H5M0hKCy+tfaP1n5A=; b=RMcwK8l4vNKoXjCVG4cDv202P45RBwTuHqttshre7l/39d5JJZIpjbte2APG3RcBI1 kEcTbqYihxSx8bhSTr5EwLI86covUHWJ6rGPvBDSDLQKjiQBZJg7DHwOWtDavOHnenjK wr3M/IbHw3N2+KRvdHg5kek0/sHVgZNE2PDO33iJq9hDK0TjXqKQtByLdwVRFFbInDtS ImoHCO+tl59oFBHAV7AqRXBKEkl+c1bwRvtZmE6CFXrOwlZ0sRMlW527QrakAQhocsom 4WDqoKX+V3UFSNBVhySryVbzdt9BvpxJkmMivVbfKCYlniT7D+vrRPyheHBEK+i1kIyD hWUg== X-Received: by 10.14.2.73 with SMTP id 49mr19666786eee.118.1373189093622; Sun, 07 Jul 2013 02:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.138.141 with HTTP; Sun, 7 Jul 2013 02:24:33 -0700 (PDT) In-Reply-To: References: From: Kaushal Bhandankar Date: Sun, 7 Jul 2013 14:54:33 +0530 Message-ID: Subject: Fwd: ixgbe Jumbo race condition leading to Deadlock To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 09:24:55 -0000 In 82599, for a Jumbo packet of 9.5 K ( which consumes 5 descriptors of 2048 bytes each ), when does the Descriptor write back happen ? Does it happen per Descriptor or once per aggregated Descriptors ? Is it possible that all descriptors except last one to be written back and when you read RDH register, I get the last pending descriptor waiting inside 82599. We are using srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; In my setup, I am seeing that, I don't see EOP set even when I read 5 descriptors. Checking DD will return me an incomplete packet. What should I do in such a case ? References from Data sheet: -> Checking through DD bits eliminates a potential race condition: all descriptor data is posted internally prior to incrementing the head register and a read of the head register could potentially pass the descriptor waiting inside the 82599. Regards, Kaushal From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 10:17:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D993769C; Sun, 7 Jul 2013 10:17:36 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3AD1D73; Sun, 7 Jul 2013 10:17:36 +0000 (UTC) Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1BFEA17207C; Sun, 7 Jul 2013 12:17:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 67qBUqK024hG; Sun, 7 Jul 2013 12:17:16 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2216A172067; Sun, 7 Jul 2013 12:17:15 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 2273A73A31; Sun, 7 Jul 2013 03:17:14 -0700 (PDT) Date: Sun, 7 Jul 2013 03:17:14 -0700 From: Jeremy Chadwick To: Daniel Braniss Subject: Re: make buildworld is now 50% slower Message-ID: <20130707101714.GA51445@icarus.home.lan> References: <20130705145839.GB5449@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org Stable" , Dimitry Andric X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 10:17:36 -0000 On Sun, Jul 07, 2013 at 11:50:29AM +0300, Daniel Braniss wrote: > > On Fri, Jul 05, 2013 at 02:39:00PM +0200, Dimitry Andric wrote: > > > [redirecting to the correct mailing list, freebsd-stable@ ...] > > > > > > On Jul 5, 2013, at 10:53, Daniel Braniss wrote: > > > > after today's update of 9.1-STABLE I noticed that make build[world|kernel] are > > > > taking conciderable more time, is it because the upgrade of clang? > > > > and if so, is the code produced any better? > > > > > > > > before: > > > > buildwordl: 26m4.52s real 2h28m32.12s user 36m6.27s sys > > > > buildkernel: 7m29.42s real 23m22.22s user 4m26.26s sys > > > > > > > > today: > > > > buildwordl: 34m29.80s real 2h38m9.37s user 37m7.61s sys > > > > buildkernel: 15m31.52s real 22m59.40s user 4m33.06s sys > > > > > > Ehm, your user and sys times are not that much different at all, they > > > add up to about 5% slower for buildworld, and 1% faster for build kernel. > > > Are you sure nothing else is running on that machine, eating up CPU time > > > while you are building? :) > > > > > > But yes, clang 3.3 is of course somewhat larger than 3.2. You might > > > especially notice that, if you are using gcc, which is very slow at > > > compiling C++. > > > > > > In any case, if you do not care about clang, just set WITHOUT_CLANG= in > > > your /etc/src.conf, and you can shave off some build time. > > > > I just built world/kernel (stable/9 r252769) 5 hours ago. Results: > > > > time make -j4 buildworld = roughly 21 minutes on my hardware > > time make -j4 buildkernel = roughly 8 minutes on my hardware > > > > It's been a long time since I saw such numbers, maybe it's time > to see where time is being spent, I will run it without clang to compare with > your numbers. > > > These numbers are about the norm for me, meaning I do not see a > > substantial increase in build times. > > > > Key point: I do not use/build/grok clang, i.e. WITHOUT_CLANG=true is in > > my src.conf. But I am aware of the big clang change in r252723. > > > > If hardware details are wanted, ask, but I don't think it's relevant to > > what the root cause is. > > > > from what you are saying, I guess clang is not responsible. > looking for my Sherlock Holmes hat. Some points to those numbers I stated above: - System is an Intel Q9550 with 8GB of RAM - Single SSD (UFS2+SU+TRIM) is used for root, /usr, /var, /tmp, and swap - /usr/src is on ZFS (raidz1 + 3 disks) -- however I got equally small numbers when it was on the SSD - /usr/src is using compression=lz4 (to folks from -fs: yeah, I'm trying it out to see how much of an impact it has on interactivity. I can still tell when it kicks in, but it's way, way better than lzjb. Rather not get into that here) - Contents of /etc/src.conf (to give you some idea of what I disable): WITHOUT_ATM=true WITHOUT_BLUETOOTH=true WITHOUT_CLANG=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_KERBEROS=true WITHOUT_LIB32=true WITHOUT_LPR=true WITHOUT_NDIS=true WITHOUT_NETGRAPH=true WITHOUT_PAM_SUPPORT=true WITHOUT_PPP=true WITHOUT_SENDMAIL=true WITHOUT_WIRELESS=true WITH_OPENSSH_NONE_CIPHER=true It's WITHOUT_CLANG that cuts down the buildworld time by a *huge* amount (I remember when it got introduced, my buildworld jumped up to something like 40 minutes); the rest probably save a minute or two at most. - /etc/make.conf doesn't contain much that's relevant, other than: CPUTYPE?=core2 # For DTrace; also affects ports STRIP= CFLAGS+= -fno-omit-frame-pointer - I do some tweaks in /etc/sysctl.conf (mainly vfs.read_min and vfs.read_max), but I will admit I am not completely sure what those do quite yet (I just saw the commit from scottl@ a while back talking about how an increased vfs.read_min helps them at Netflix quite a lot). I also adjust kern.maxvnodes. - Some ZFS ARC settings are adjusted in /boot/loader.conf (I'm playing with some stuff I read in Andriy Gapon's ZFS PDF), but they definitely do not have a major impact on the numbers I listed off. - I do increase kern.maxdsiz, kern.dfldsiz, and kern.maxssiz in /boot/loader.conf to 2560M/2560M/256M respectively, but that was mainly from the days when I ran MySQL and needed a huge userland processes. All in all my numbers are low/small because of two things: the SSD, and WITHOUT_CLANG. Hope this gives you somewhere to start/stuff to ponder. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 10:26:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07763A53; Sun, 7 Jul 2013 10:26:42 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id B15201E3A; Sun, 7 Jul 2013 10:26:41 +0000 (UTC) Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id AA0BC172071; Sun, 7 Jul 2013 12:26:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TiBcnnYtprZp; Sun, 7 Jul 2013 12:26:29 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 09BE7172081; Sun, 7 Jul 2013 12:26:25 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 46AE973A31; Sun, 7 Jul 2013 03:26:24 -0700 (PDT) Date: Sun, 7 Jul 2013 03:26:24 -0700 From: Jeremy Chadwick To: Ian Smith Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-ID: <20130707102624.GB51445@icarus.home.lan> References: <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707154526.O26496@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707154526.O26496@sola.nimnet.asn.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Lars Engels , John Baldwin , freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 10:26:42 -0000 On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote: > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > > On 30 June 2013 07:22, Ian Smith wrote: > [..] > > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > > Maybe someone who knows might comment on that? > > Does noone know what that signifies? Maybe it's not relevant to this. It's too vague to know. The error comes from lapic_handle_error(), which is a generic/small routine which pulls the local APIC error status register. (Note I'm saying APIC, not ACPI -- two different things) apic_vector.S sets this up/makes use of this function, and its done as an interrupt handler. I think this is one of those situations where you have to know *what* is being set up/done at that moment in time for the error code to mean something. Maybe booting verbose would give more information as to what was being done that lead up to the line. I've CC'd John Baldwin who might have some ideas. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 10:56:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F662F2B for ; Sun, 7 Jul 2013 10:56:43 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1FB1F92 for ; Sun, 7 Jul 2013 10:56:42 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 34EF637B53D; Sun, 7 Jul 2013 05:47:32 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3bp61v3YVGzSYK; Sun, 7 Jul 2013 05:47:31 -0500 (CDT) Date: Sun, 7 Jul 2013 05:47:31 -0500 From: "Matthew D. Fuller" To: Jeremy Chadwick Subject: Re: make buildworld is now 50% slower Message-ID: <20130707104731.GA13386@over-yonder.net> References: <20130705145839.GB5449@icarus.home.lan> <20130707101714.GA51445@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707101714.GA51445@icarus.home.lan> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.8 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 10:56:43 -0000 Apropos of nothing, but... On Sun, Jul 07, 2013 at 03:17:14AM -0700 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > WITHOUT_LIB32=true suggests you're running amd64, which I'm pretty sure means > - I do increase kern.maxdsiz, kern.dfldsiz, and kern.maxssiz in > /boot/loader.conf to 2560M/2560M/256M respectively, but that was mainly > from the days when I ran MySQL and needed a huge userland processes. are not necessarily _in_creases, and may well be mostly _de_creases. e.g., on a RELENG_9 box with 8 gig of physical RAM: % sysctl kern.{max{d,s},dfld}siz kern.maxdsiz: 34359738368 kern.maxssiz: 536870912 kern.dfldsiz: 134217728 while a -CURRENT box with 16 has dfldsiz blown all the way up too. I don't recall doing anything to change them at all recently, and a glance over loader.conf, sysctl.conf, rc.local, and the kernel configs doesn't turn up anything. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 11:34:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A93AA8D for ; Sun, 7 Jul 2013 11:34:05 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 471DF1090 for ; Sun, 7 Jul 2013 11:34:04 +0000 (UTC) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6A8D141C061; Sun, 7 Jul 2013 13:33:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id cQoZWu5i+niK; Sun, 7 Jul 2013 13:33:46 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4E4FF41C05A; Sun, 7 Jul 2013 13:33:46 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 7219873A31; Sun, 7 Jul 2013 04:33:44 -0700 (PDT) Date: Sun, 7 Jul 2013 04:33:44 -0700 From: Jeremy Chadwick To: "Matthew D. Fuller" Subject: Re: make buildworld is now 50% slower Message-ID: <20130707113344.GA53765@icarus.home.lan> References: <20130705145839.GB5449@icarus.home.lan> <20130707101714.GA51445@icarus.home.lan> <20130707104731.GA13386@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707104731.GA13386@over-yonder.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 11:34:05 -0000 On Sun, Jul 07, 2013 at 05:47:31AM -0500, Matthew D. Fuller wrote: > Apropos of nothing, but... > > On Sun, Jul 07, 2013 at 03:17:14AM -0700 I heard the voice of > Jeremy Chadwick, and lo! it spake thus: > > > > WITHOUT_LIB32=true > > suggests you're running amd64, which I'm pretty sure means > > > - I do increase kern.maxdsiz, kern.dfldsiz, and kern.maxssiz in > > /boot/loader.conf to 2560M/2560M/256M respectively, but that was mainly > > from the days when I ran MySQL and needed a huge userland processes. > > are not necessarily _in_creases, and may well be mostly _de_creases. > e.g., on a RELENG_9 box with 8 gig of physical RAM: > > % sysctl kern.{max{d,s},dfld}siz > kern.maxdsiz: 34359738368 > kern.maxssiz: 536870912 > kern.dfldsiz: 134217728 > > while a -CURRENT box with 16 has dfldsiz blown all the way up too. I > don't recall doing anything to change them at all recently, and a > glance over loader.conf, sysctl.conf, rc.local, and the kernel configs > doesn't turn up anything. Thanks! The settings I mention are from "ancient times" -- specifically RELENG_6 on i386 (I know because I found an old mailing list post of mine discussing the settings with a user). The problem as I said was that mysqld would crap itself (crash and be quite loud about it) if the process allocated too much memory/became too large. I am fairly certain the issue related to the data size, **not** the stack size (but I didn't see the harm in increasing that either). It's good to know I can remove these on amd64. Yay, one less thing in loader.conf I have to deal with... :-) Thanks again! -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 12:13:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01B91404; Sun, 7 Jul 2013 12:13:57 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8B24A1217; Sun, 7 Jul 2013 12:13:56 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r67CDsDu011605; Sun, 7 Jul 2013 14:13:54 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r67CDsr7027734; Sun, 7 Jul 2013 14:13:54 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r67CDsor028591; Date: Sun, 7 Jul 2013 14:13:54 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130707121354.GA39055@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130707072553.GA38133@bali> <20130707074112.GD91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707074112.GD91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 12:13:57 -0000 On Sun, 07-Jul-2013 at 09:41:12 +0200, Konstantin Belousov wrote: > On Sun, Jul 07, 2013 at 09:25:53AM +0200, Andre Albsmeier wrote: > > OK, here we go (looks better now): > > > > 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 "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > dev = stripe/p, block = 592, fs = /palveli > > panic: ffs_blkfree_cg: freeing free block > > KDB: stack backtrace: > > db_trace_self_wrapper(c08207eb,d70fc924,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd70fc8f4 > > kdb_backtrace(c081df13,c08a82e0,c0833a0b,d70fc930,d70fc930,...) at kdb_backtrace+0x29/frame 0xd70fc900 > > panic(c0833a0b,c2aae178,250,0,c2af80d4,...) at panic+0xc9/frame 0xd70fc924 > > ffs_blkfree_cg(250,0,8000,49f,d70fcad0,...) at ffs_blkfree_cg+0x399/frame 0xd70fc9c8 > > ffs_blkfree(c2b35100,c2af8000,c2b0d470,250,0,...) at ffs_blkfree+0xad/frame 0xd70fca00 > > indir_trunc(fffa3ff4,ffffffff,0,8000,0,...) at indir_trunc+0x658/frame 0xd70fcae0 > > indir_trunc(ffffdff3,ffffffff,c072df0a,c2d68d00,c087abd8,...) at indir_trunc+0x514/frame 0xd70fcbc0 > > handle_workitem_freeblocks(0,d70fcc4c,2,246,c2ab1000,...) at handle_workitem_freeblocks+0x2dc/frame 0xd70fcc24 > > process_worklist_item(0,0,0,c086ae78,0,...) at process_worklist_item+0x27a/frame 0xd70fcc6c > > softdep_process_worklist(c2b36548,0,54,c0835825,64,...) at softdep_process_worklist+0x91/frame 0xd70fcc9c > > softdep_flush(0,d70fcd08,0,c2aac2f0,0,...) at softdep_flush+0x3e4/frame 0xd70fcccc > > fork_exit(c0738bb0,0,d70fcd08) at fork_exit+0xa2/frame 0xd70fccf4 > > fork_trampoline() at fork_trampoline+0x8/frame 0xd70fccf4 > > --- trap 0, eip = 0, esp = 0xd70fcd40, ebp = 0 --- > > Uptime: 2d16h29m37s > > Physical memory: 503 MB > > Dumping 95 MB: 80 64 48 32 16 > > > > No symbol "stopped_cpus" in current context. > > No symbol "stoppcbs" in current context. > > #0 doadump (textdump=1) at pcpu.h:249 > > 249 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump (textdump=1) at pcpu.h:249 > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > #3 0xc0717899 in ffs_blkfree_cg (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > size=32768, inum=1183, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2151 > > #4 0xc0717c8d in ffs_blkfree (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > size=32768, inum=1183, vtype=VREG, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2280 > > #5 0xc0730348 in indir_trunc (freework=0xc2f99100, dbn=1642816, lbn=-376844) > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7965 > > #6 0xc0730204 in indir_trunc (freework=0xc2f99100, dbn=1639680, lbn=-8205) > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7946 > > #7 0xc07324bc in handle_workitem_freeblocks (freeblks=0xc2fc1e00, flags=512) > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7588 > > #8 0xc0730dfa in process_worklist_item (mp=0xc2b36548, target=10, flags=512) > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1774 > > #9 0xc07360c1 in softdep_process_worklist (mp=0xc2b36548, full=0) > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1558 > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > #11 0xc05d1b82 in fork_exit (callout=0xc0738bb0 , arg=0x0, frame=0xd70fcd08) > > at /src/src-9/sys/kern/kern_fork.c:988 > > #12 0xc07ba904 in fork_trampoline () at /src/src-9/sys/i386/i386/exception.s:279 > > (kgdb) up 10 > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > 1414 progress += softdep_process_worklist(mp, 0); > > > > -Andre > > This looks unrelated, and exactly this panic is usually has one of two > causes: > - corrupted filesystem, run fsck to recheck it; root@palveli:~>fsck /dev/stripe/p ** /dev/stripe/p ** Last Mounted on /palveli ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 9895 files, 2039706 used, 15697693 free (5397 frags, 1961537 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** > - faulty hardware, most likely RAM, but might be CPU/CPU cache/bus. Well, of course I cannot prove that this is not the case. But the box runs flawlessly otherwise. RAM is ECC monitored, PSU is OK and airflow is OK. Sure, I can't look inside of CPU etc. > > Is it the same machine where the bcopy panic occured ? Yes. Let's see what it does the next days... -Andre From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 12:32:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94B9EC9A; Sun, 7 Jul 2013 12:32:39 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx1.freebsd.org (Postfix) with ESMTP id 37BF312C1; Sun, 7 Jul 2013 12:32:39 +0000 (UTC) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 3D1DDA80C4; Sun, 7 Jul 2013 14:32:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IVaxwZ6aiE6x; Sun, 7 Jul 2013 14:32:20 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B0BDFA80B4; Sun, 7 Jul 2013 14:32:19 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A7B8373A31; Sun, 7 Jul 2013 05:32:17 -0700 (PDT) Date: Sun, 7 Jul 2013 05:32:17 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130707123217.GA54979@icarus.home.lan> References: <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130707072553.GA38133@bali> <20130707074112.GD91021@kib.kiev.ua> <20130707121354.GA39055@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707121354.GA39055@bali> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 12:32:39 -0000 On Sun, Jul 07, 2013 at 02:13:54PM +0200, Andre Albsmeier wrote: > On Sun, 07-Jul-2013 at 09:41:12 +0200, Konstantin Belousov wrote: > > On Sun, Jul 07, 2013 at 09:25:53AM +0200, Andre Albsmeier wrote: > > > OK, here we go (looks better now): > > > > > > 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 "i386-marcel-freebsd"... > > > > > > Unread portion of the kernel message buffer: > > > dev = stripe/p, block = 592, fs = /palveli > > > panic: ffs_blkfree_cg: freeing free block > > > KDB: stack backtrace: > > > db_trace_self_wrapper(c08207eb,d70fc924,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd70fc8f4 > > > kdb_backtrace(c081df13,c08a82e0,c0833a0b,d70fc930,d70fc930,...) at kdb_backtrace+0x29/frame 0xd70fc900 > > > panic(c0833a0b,c2aae178,250,0,c2af80d4,...) at panic+0xc9/frame 0xd70fc924 > > > ffs_blkfree_cg(250,0,8000,49f,d70fcad0,...) at ffs_blkfree_cg+0x399/frame 0xd70fc9c8 > > > ffs_blkfree(c2b35100,c2af8000,c2b0d470,250,0,...) at ffs_blkfree+0xad/frame 0xd70fca00 > > > indir_trunc(fffa3ff4,ffffffff,0,8000,0,...) at indir_trunc+0x658/frame 0xd70fcae0 > > > indir_trunc(ffffdff3,ffffffff,c072df0a,c2d68d00,c087abd8,...) at indir_trunc+0x514/frame 0xd70fcbc0 > > > handle_workitem_freeblocks(0,d70fcc4c,2,246,c2ab1000,...) at handle_workitem_freeblocks+0x2dc/frame 0xd70fcc24 > > > process_worklist_item(0,0,0,c086ae78,0,...) at process_worklist_item+0x27a/frame 0xd70fcc6c > > > softdep_process_worklist(c2b36548,0,54,c0835825,64,...) at softdep_process_worklist+0x91/frame 0xd70fcc9c > > > softdep_flush(0,d70fcd08,0,c2aac2f0,0,...) at softdep_flush+0x3e4/frame 0xd70fcccc > > > fork_exit(c0738bb0,0,d70fcd08) at fork_exit+0xa2/frame 0xd70fccf4 > > > fork_trampoline() at fork_trampoline+0x8/frame 0xd70fccf4 > > > --- trap 0, eip = 0, esp = 0xd70fcd40, ebp = 0 --- > > > Uptime: 2d16h29m37s > > > Physical memory: 503 MB > > > Dumping 95 MB: 80 64 48 32 16 > > > > > > No symbol "stopped_cpus" in current context. > > > No symbol "stoppcbs" in current context. > > > #0 doadump (textdump=1) at pcpu.h:249 > > > 249 pcpu.h: No such file or directory. > > > in pcpu.h > > > (kgdb) where > > > #0 doadump (textdump=1) at pcpu.h:249 > > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > > #3 0xc0717899 in ffs_blkfree_cg (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > > size=32768, inum=1183, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2151 > > > #4 0xc0717c8d in ffs_blkfree (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > > size=32768, inum=1183, vtype=VREG, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2280 > > > #5 0xc0730348 in indir_trunc (freework=0xc2f99100, dbn=1642816, lbn=-376844) > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7965 > > > #6 0xc0730204 in indir_trunc (freework=0xc2f99100, dbn=1639680, lbn=-8205) > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7946 > > > #7 0xc07324bc in handle_workitem_freeblocks (freeblks=0xc2fc1e00, flags=512) > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7588 > > > #8 0xc0730dfa in process_worklist_item (mp=0xc2b36548, target=10, flags=512) > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1774 > > > #9 0xc07360c1 in softdep_process_worklist (mp=0xc2b36548, full=0) > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1558 > > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > > #11 0xc05d1b82 in fork_exit (callout=0xc0738bb0 , arg=0x0, frame=0xd70fcd08) > > > at /src/src-9/sys/kern/kern_fork.c:988 > > > #12 0xc07ba904 in fork_trampoline () at /src/src-9/sys/i386/i386/exception.s:279 > > > (kgdb) up 10 > > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > > 1414 progress += softdep_process_worklist(mp, 0); > > > > > > -Andre > > > > This looks unrelated, and exactly this panic is usually has one of two > > causes: > > - corrupted filesystem, run fsck to recheck it; > > root@palveli:~>fsck /dev/stripe/p > ** /dev/stripe/p > ** Last Mounted on /palveli > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 9895 files, 2039706 used, 15697693 free (5397 frags, 1961537 blocks, 0.0% fragmentation) > > ***** FILE SYSTEM IS CLEAN ***** Taken from your previous mail (showing only UFS stuff): http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073817.html >>>> fstab: >>>> ------ >>>> /dev/da0s1a / ufs noatime,rw 0 1 >>>> /dev/da0s1d /usr ufs noatime,rw 0 2 >>>> /dev/da0s1e /var ufs noatime,nosuid,rw 0 2 >>>> /dev/da10p1 /share2 ufs suiddir,groupquota,noatime,nosuid,rw 0 2 >>>> /dev/da10p2 /raid2 ufs userquota,noatime,nosuid,rw 0 2 Where is gstripe(8) in that picture? Are you **sure** this is the same system? Surely I'm missing something here... Can you provide details of the stripe, specifically "gstripe list" so I can see what the disks are and then ask you for "smartctl -a" output for each of them (to try and rule out disk-level problems that may be causing oddities at the layer underneathe the filesystem (sometimes fsck will not catch this))? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 15:57:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0F563A; Sun, 7 Jul 2013 15:57:50 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id C5FB2197E; Sun, 7 Jul 2013 15:57:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r67FvenY083581; Mon, 8 Jul 2013 01:57:41 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 8 Jul 2013 01:57:40 +1000 (EST) From: Ian Smith To: Jeremy Chadwick Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: <20130707102624.GB51445@icarus.home.lan> Message-ID: <20130708010728.I26496@sola.nimnet.asn.au> References: <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707154526.O26496@sola.nimnet.asn.au> <20130707102624.GB51445@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Adrian Chadd , freebsd-stable@freebsd.org, Lars Engels , John Baldwin , freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:57:50 -0000 On Sun, 7 Jul 2013 03:26:24 -0700, Jeremy Chadwick wrote: > On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote: > > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > > > On 30 June 2013 07:22, Ian Smith wrote: > > [..] > > > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > > > Maybe someone who knows might comment on that? > > > > Does noone know what that signifies? Maybe it's not relevant to this. > > It's too vague to know. The error comes from lapic_handle_error(), > which is a generic/small routine which pulls the local APIC error status > register. (Note I'm saying APIC, not ACPI -- two different things) Indeed; I've been familiar with PICs since c.'79. Googling to check what the 'A' stood for I found this .. from '97 but usefully descriptive perhaps: http://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt I also found this from March 2011 involving Mike Tancsa, you and jhb@ :) http://freebsd.1045724.n5.nabble.com/CPU0-local-APIC-error-0x40-CPU1-local-APIC-error-0x40-td3961805.html > apic_vector.S sets this up/makes use of this function, and its done as > an interrupt handler. Whether an (unserviced?) interrupt error is related to Adrian's symptom - apparent total failure of USB reinitialisation on resume, but only if no USB devices exist in the external slots - remains to be seen. hps@ has just confirmed that it should work the same as on boot, but then this error was flagged on boot - perhaps it also manifests on resume? > I think this is one of those situations where you have to know *what* is > being set up/done at that moment in time for the error code to mean > something. Maybe booting verbose would give more information as to what > was being done that lead up to the line. > > I've CC'd John Baldwin who might have some ideas. Thanks. We have verbose dmesg already. Thread starts (in -stable) at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073917.html and amidst some wild goose chases, pointer to verbose dmesg etc is at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/074018.html cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 16:43:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDCCDEF7; Sun, 7 Jul 2013 16:43:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2D21B43; Sun, 7 Jul 2013 16:43:25 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id cm16so1894825qab.14 for ; Sun, 07 Jul 2013 09:43:25 -0700 (PDT) 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=oqRSwjqjtjHnzuZyX+U/6kqA7lnvdRcadvBcb6zCPd0=; b=QHr1MjgupfLnw5jBRAuSYXbY7e+fJdBrzNvUhSlGXm7SftWIobORMdUMKBJH6GlNbv 7gmNrgvdrn65djQVePFACyHNaRb4pBuERhcWbd04P6WBQM7cO4lqehqV4G5RJ2isytN/ KSE563en5GVgaWXX2DGdSzM9rlT2nKhoYKmQ7KfGu9avKVE72nf3dgISwoaWXnjuVtnx UY8fD5Lfr6jHoNYbydhNQWSM2nNNlxji4cPfX1wxAV9YqrbISVJM4kPrwDlAURS/1KDs ZbiTwTZ3JixON+EqWErNpGiYa97s7M2tLsf3in2k+ESbuJaKttmA4DkXO6JySS+TmqI3 C1qQ== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr15352480qaz.12.1373215404960; Sun, 07 Jul 2013 09:43:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 09:43:24 -0700 (PDT) In-Reply-To: References: <20130707154526.O26496@sola.nimnet.asn.au> Date: Sun, 7 Jul 2013 09:43:24 -0700 X-Google-Sender-Auth: DxoDALKniHbkuQ_Q2nwEihem8Kg Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-acpi@freebsd.org" , "freebsd-stable@freebsd.org" , Ian Smith , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:43:25 -0000 I don't think it's a USB controller issue. Those ports are connected to USB hubs, right? I wonder if there's some ACPI nonsense that's resulting in the hubs not being powered up on resume. -adrian On 7 July 2013 00:32, Hans Petter Selasky wrote: > Hi, > > FYI: The USB stack will currently run a complete controller reset upon > resume, like during boot. > > --HPS > > > > -----Original message----- >> From:Ian Smith >> Sent: Sunday 7th July 2013 7:52 >> To: Adrian Chadd >> Cc: freebsd-acpi@freebsd.org; freebsd-stable@freebsd.org; >> freebsd-usb@freebsd.org >> Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume >> >> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: >> > On 30 June 2013 07:22, Ian Smith wrote: >> [..] >> > > Nothing of note that I can see, if that usb hub-to-bus remapping is >> > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. >> > > Maybe someone who knows might comment on that? >> >> Does noone know what that signifies? Maybe it's not relevant to this. >> >> > > Just checking: you've tried other USB devices apart from uftdi0? >> > >> > Yup, there's no 5v on the port. >> >> I was rather taken aback to hear this. Would not this indicate a >> failure to reinitialise the basic underlying USB hardware on resume? >> >> More than a bit bemused, Ian >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 17:10:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23A1CF8B for ; Sun, 7 Jul 2013 17:10:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id DC22F1C66 for ; Sun, 7 Jul 2013 17:10:43 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hf12so2745343vcb.15 for ; Sun, 07 Jul 2013 10:10:43 -0700 (PDT) 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=Y2ENQCxOjIir3SxA6WVeXn2dMgw+NYzGyr5qVQVsEqc=; b=pPZzXXN/7xo2kbzRn1UjGnvQHkwxYShpnFoXODVtycN99NvmAnu06CDwavU7RmB+33 ump9vbRt1GzATELC33Yqvrssw9yM9QiKU9gRw1wY9xWGKr5yTvWspntL1FDTWz79inFB mrMynNvXtjsvh/50wxLG4gvivVMbrUljFmZF8+4LXsZxTXIOqaeO/mJ4imQ1WbJv0eh6 4iDhlu9nwfvujuy2iUImfjtI5sQpZ0Q46bodFqeqKcMAp9WvRsUssex/HZDqEOKC7mtC 8RB7I50lAFlzDQeD1tHU679QrrOkeJKLCPc41d0VOs6GRzIScshgc/JmxoOztMT50ERJ ja9Q== MIME-Version: 1.0 X-Received: by 10.52.228.226 with SMTP id sl2mr10187172vdc.52.1373217043441; Sun, 07 Jul 2013 10:10:43 -0700 (PDT) Received: by 10.220.52.200 with HTTP; Sun, 7 Jul 2013 10:10:43 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Jul 2013 10:10:43 -0700 Message-ID: Subject: Re: ixgbe Jumbo race condition leading to Deadlock From: Jack Vogel To: Kaushal Bhandankar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:10:44 -0000 The "potential race condition" as the data sheet puts it, is only when you are trying to manage your RX ring by reading the RDH register, this is a bad idea anyway, none of our (Intel) drivers do this. Using the DD bit is what you want to do. The DD bit is set when the descriptor is written back, and that happens when the DMA is complete. The packet is incomplete until the descriptor with EOP set, in my code an mbuf chain is created, and as each new descriptor is processed the pointer to the head of the whole chain is kept in rxbuf->fmp, thus when you get to the EOP descriptor you will be ready to send the whole chain to the stack. Its good that you are using ONEBUF since packet split has hardware issues on 82599. Are you developing a new driver, or simply having issues using mine? Regards, Jack On Sun, Jul 7, 2013 at 2:24 AM, Kaushal Bhandankar wrote: > In 82599, for a Jumbo packet of 9.5 K ( which consumes 5 descriptors of > 2048 bytes each ), when does the Descriptor write back happen ? Does it > happen per Descriptor or once per aggregated Descriptors ? Is it possible > that all descriptors except last one to be written back and when you read > RDH register, I get the last pending descriptor waiting inside 82599. > We are using srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; > > In my setup, I am seeing that, I don't see EOP set even when I read 5 > descriptors. Checking DD will return me an incomplete packet. What should I > do in such a case ? > > References from Data sheet: > -> Checking through DD bits eliminates a potential race condition: all > descriptor data is posted internally prior to incrementing the head > register and a read of the head register could potentially pass the > descriptor waiting inside the 82599. > > Regards, > Kaushal > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 17:13:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B6EF2FD for ; Sun, 7 Jul 2013 17:13:48 +0000 (UTC) (envelope-from kaushalgoa@gmail.com) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id B84141C96 for ; Sun, 7 Jul 2013 17:13:47 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e49so2336448eek.34 for ; Sun, 07 Jul 2013 10:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yhAlKXwfbtaPujLLGDRvMwM2Yvz9J5GOPogmbcsYE7o=; b=XOeKXZYIcBb988oGDDrXeAdul+Zw29zLDvoqktWp6IYUMgzk4UCJIWpN+AlRn+sVKr 95TqFgkhngvr6oIwz8iy1A8d5WQoGwf3WERaDZpANWau0ISfowJvhdDuUG+ViYwKHbv8 Ki5MV9D5hKW5X1J4ADkcUeBDdrLkhQOvn8LrRTy+M2Ybrg0c1IddhxxctMi1PWVl8o62 DRD8oNgc2NeUcuSq41RdGP1xzfNQKCLiWDLyV3kho7PFmOwTH6h/FI4HwvReHw6RdpOe UjIO+2yh96Mv0xo3vnXNx90ze3O5T28ssPyh/N2vZFkmPkeu63Jl5IfjaqMs8hQcxno9 KQ7Q== X-Received: by 10.14.2.73 with SMTP id 49mr21034534eee.118.1373217226787; Sun, 07 Jul 2013 10:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.138.141 with HTTP; Sun, 7 Jul 2013 10:13:26 -0700 (PDT) In-Reply-To: References: From: Kaushal Bhandankar Date: Sun, 7 Jul 2013 22:43:26 +0530 Message-ID: Subject: Re: ixgbe Jumbo race condition leading to Deadlock To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:13:48 -0000 Hi Jack, Thanks for the explanation. Do you suggest that I keep reading rx descriptor with DD bit and keep them pending till I get the descriptor with EOP set ? How much max delay can be expected for the EOP descriptor to be written back ? Regards, Kaushal On Sun, Jul 7, 2013 at 10:40 PM, Jack Vogel wrote: > The "potential race condition" as the data sheet puts it, is only when you > are > trying to manage your RX ring by reading the RDH register, this is a bad > idea > anyway, none of our (Intel) drivers do this. Using the DD bit is what you > want > to do. The DD bit is set when the descriptor is written back, and that > happens > when the DMA is complete. > > The packet is incomplete until the descriptor with EOP set, in my code an > mbuf chain is created, and as each new descriptor is processed the pointer > to the head of the whole chain is kept in rxbuf->fmp, thus when you get to > the EOP descriptor you will be ready to send the whole chain to the stack. > > Its good that you are using ONEBUF since packet split has hardware issues > on 82599. > > Are you developing a new driver, or simply having issues using mine? > > Regards, > > Jack > > > > On Sun, Jul 7, 2013 at 2:24 AM, Kaushal Bhandankar wrote: > >> In 82599, for a Jumbo packet of 9.5 K ( which consumes 5 descriptors of >> 2048 bytes each ), when does the Descriptor write back happen ? Does it >> happen per Descriptor or once per aggregated Descriptors ? Is it possible >> that all descriptors except last one to be written back and when you read >> RDH register, I get the last pending descriptor waiting inside 82599. >> We are using srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; >> >> In my setup, I am seeing that, I don't see EOP set even when I read 5 >> descriptors. Checking DD will return me an incomplete packet. What should >> I >> do in such a case ? >> >> References from Data sheet: >> -> Checking through DD bits eliminates a potential race condition: all >> descriptor data is posted internally prior to incrementing the head >> register and a read of the head register could potentially pass the >> descriptor waiting inside the 82599. >> >> Regards, >> Kaushal >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 17:28:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D54E772 for ; Sun, 7 Jul 2013 17:28:09 +0000 (UTC) (envelope-from kaushalgoa@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 154D21D0B for ; Sun, 7 Jul 2013 17:28:08 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c1so2362358eek.18 for ; Sun, 07 Jul 2013 10:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uDSSC48pvpQLp8YWuiKQGnVAoEEHiUAd36yM87O9axk=; b=EIAADfzQt9HbcagH1c9WRkl770dw6uvEyzpRS8RJoETsCm5UsghwqXMER86+H10rPd g4wU0NNHDh7fNBJzpwrNRBgTSox/fkxF+jvytuEKMurT65ZGI3JaU3qkNjy3LrV7H1vL z/LkRd0k1SZZ0je4MXB6bU3E0torGbFrLpRVtogfBe7CC4frJiG52Ro7XAFYgRl78Ojr mx027HZdSv+iKOBYSwpOkPDAqRlgCl9LBSUQAal4y85bpNMIormOct244UuzTWzYdP19 JvQtfGfhSekAw5AFkORGbyut0y82cF8aTzPfJXhayjeLDM0QKHVc4WrSnhXxGxkuUEEU XmaA== X-Received: by 10.14.7.133 with SMTP id 5mr21408455eep.115.1373218088077; Sun, 07 Jul 2013 10:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.138.141 with HTTP; Sun, 7 Jul 2013 10:27:47 -0700 (PDT) In-Reply-To: References: From: Kaushal Bhandankar Date: Sun, 7 Jul 2013 22:57:47 +0530 Message-ID: Subject: Re: ixgbe Jumbo race condition leading to Deadlock To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:28:09 -0000 The solution is: I have a function which pre-calculates the buffers required for processing the packet. This is to eliminate any lack-of-memory errors during processing. In this function I loop over descriptors from next_to_check onwards. If I loop over some descriptors with DD set and do not see the EOP set till I reach 5 descriptors, I will return a failure and not change next_to_check etc. So that on the next read, or later hopefully descriptor with EOP would have been written back. This will ensure that race condition does not happen. Let me know if it sounds good. Regards, Kaushal On Sun, Jul 7, 2013 at 10:43 PM, Kaushal Bhandankar wrote: > Hi Jack, > Thanks for the explanation. Do you suggest that I keep reading rx > descriptor with DD bit and keep them pending till I get the descriptor with > EOP set ? How much max delay can be expected for the EOP descriptor to be > written back ? > > Regards, > Kaushal > > > On Sun, Jul 7, 2013 at 10:40 PM, Jack Vogel wrote: > >> The "potential race condition" as the data sheet puts it, is only when >> you are >> trying to manage your RX ring by reading the RDH register, this is a bad >> idea >> anyway, none of our (Intel) drivers do this. Using the DD bit is what you >> want >> to do. The DD bit is set when the descriptor is written back, and that >> happens >> when the DMA is complete. >> >> The packet is incomplete until the descriptor with EOP set, in my code an >> mbuf chain is created, and as each new descriptor is processed the pointer >> to the head of the whole chain is kept in rxbuf->fmp, thus when you get to >> the EOP descriptor you will be ready to send the whole chain to the stack. >> >> Its good that you are using ONEBUF since packet split has hardware issues >> on 82599. >> >> Are you developing a new driver, or simply having issues using mine? >> >> Regards, >> >> Jack >> >> >> >> On Sun, Jul 7, 2013 at 2:24 AM, Kaushal Bhandankar wrote: >> >>> In 82599, for a Jumbo packet of 9.5 K ( which consumes 5 descriptors of >>> 2048 bytes each ), when does the Descriptor write back happen ? Does it >>> happen per Descriptor or once per aggregated Descriptors ? Is it possible >>> that all descriptors except last one to be written back and when you read >>> RDH register, I get the last pending descriptor waiting inside 82599. >>> We are using srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; >>> >>> In my setup, I am seeing that, I don't see EOP set even when I read 5 >>> descriptors. Checking DD will return me an incomplete packet. What >>> should I >>> do in such a case ? >>> >>> References from Data sheet: >>> -> Checking through DD bits eliminates a potential race condition: all >>> descriptor data is posted internally prior to incrementing the head >>> register and a read of the head register could potentially pass the >>> descriptor waiting inside the 82599. >>> >>> Regards, >>> Kaushal >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 18:22:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DC812CB; Sun, 7 Jul 2013 18:22:10 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id BD00B1EB9; Sun, 7 Jul 2013 18:22:09 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id C80B27A164; Sun, 7 Jul 2013 20:22:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B27FD8ED91E; Sun, 7 Jul 2013 20:22:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsTsjjU6WgbT; Sun, 7 Jul 2013 20:22:00 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 779DC8ED91D; Sun, 7 Jul 2013 20:22:00 +0200 (CEST) Subject: RE: USB ports on Lenovo T400 do not work after a suspend/resume From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Adrian_Chadd?= Date: Sun, 7 Jul 2013 20:22:00 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-acpi=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-stable=40freebsd=2Eorg?= , =?utf-8?Q?Ian_Smith?= , =?utf-8?Q?freebsd-usb=40?= =?utf-8?Q?freebsd=2Eorg?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 18:22:10 -0000 Hi,=0D=0A=0D=0AThe USB code should re-attach the uhub driver to the root = HUB and any other HUBs after resume. Part of the attach code is to set th= e power on.=0D=0A=0D=0ASee /sys/dev/usb/usb_hub.c=0D=0A=0D=0AAnd:=0D=0A=0D= =0Agrep -r UHF_PORT_POWER /sys/dev/usb/=0D=0A=0D=0A--HPS=0D=0A=20=0D=0A=20= =0D=0A-----Original message-----=0D=0A> From:Adrian Chadd >=0D=0A> Sent: Sunday 7th July 2013 18= :43=0D=0A> To: Hans Petter Selasky >=0D=0A> Cc: freebsd-acpi@freebsd.org= ; freebsd-stable@freebsd.org ; Ian Smith >; freebsd-usb@freebsd.org =20=0D=0A> Subject: Re: USB ports on Lenovo T400 do not work after a = suspend/resume=0D=0A>=20=0D=0A> I don't think it's a USB controller issue= =2E=0D=0A>=20=0D=0A> Those ports are connected to USB hubs, right=3F I wo= nder if there's some=0D=0A> ACPI nonsense that's resulting in the hubs no= t being powered up on=0D=0A> resume.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>= -adrian=0D=0A>=20=0D=0A> On 7 July 2013 00:32, Hans Petter Selasky=0D=0A= > > wrote:=0D=0A> > Hi,=0D=0A> >=0D=0A> > FYI: The USB stack will curren= tly run a complete controller reset upon=0D=0A> > resume, like during boo= t.=0D=0A> >=0D=0A> > --HPS=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -----Origi= nal message-----=0D=0A> >> From:Ian Smith >=0D=0A> >> Sent: Sunday 7th July 2013 7:52=0D=0A> >= > To: Adrian Chadd >=0D=0A= > >> Cc: freebsd-acpi@freebsd.org ; fre= ebsd-stable@freebsd.org ;=0D=0A> >> f= reebsd-usb@freebsd.org =20=0D=0A> >> Subj= ect: Re: USB ports on Lenovo T400 do not work after a suspend/resume=0D=0A= > >>=0D=0A> >> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:=0D= =0A> >> > On 30 June 2013 07:22, Ian Smith > wrote:=0D=0A> >> [..]=0D=0A> >> > > Nothing of = note that I can see, if that usb hub-to-bus remapping is=0D=0A> >> > > n= ormal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus.=0D=0A= > >> > > Maybe someone who knows might comment on that=3F=0D=0A> >>=0D=0A= > >> Does noone know what that signifies=3F Maybe it's not relevant to t= his.=0D=0A> >>=0D=0A> >> > > Just checking: you've tried other USB devic= es apart from uftdi0=3F=0D=0A> >> >=0D=0A> >> > Yup, there's no 5v on t= he port.=0D=0A> >>=0D=0A> >> I was rather taken aback to hear this. Woul= d not this indicate a=0D=0A> >> failure to reinitialise the basic underly= ing USB hardware on resume=3F=0D=0A> >>=0D=0A> >> More than a bit bemused= , Ian=0D=0A> >> _______________________________________________=0D=0A> >>= freebsd-acpi@freebsd.org mailing list= =0D=0A> >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi =20=0D=0A> >> To unsubsc= ribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org "=0D=0A> >>=0D=0A> ____________________= ___________________________=0D=0A> freebsd-acpi@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailma= n/listinfo/freebsd-acpi =20=0D=0A> To unsubscribe, send any mail to "freebsd-acpi-unsubscr= ibe@freebsd.org "=0D=0A>=20= =0D=0A=0D=0A From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 18:24:13 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9710A48C; Sun, 7 Jul 2013 18:24:13 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3FC1EE4; Sun, 7 Jul 2013 18:24:12 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 9908B63FBE; Sun, 7 Jul 2013 11:24:12 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 95737-01; Sun, 7 Jul 2013 11:24:12 -0700 (PDT) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 2959863FB3; Sun, 7 Jul 2013 11:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1373221452; bh=SPrfY7P35f7UghJ1gVa5kkivVUt+obULHh093QA5EbE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ne8p/mqKRpoz+jDwoG+/I+BmdcWlV47/lQ5E64fAUoXIP8DbtKWmywpdxrD7DWiab YTC9/L0IXcCVBezUrjgBg5DkHkx5cNFLc0lrK9DF0jdiu2zLrX49UiAYQ+nCV3Fvaj 1ejUU5VYThP0T0crxy90oWNxVAjzRBZiQDici/HU= Message-ID: <51D9B24B.8070303@ixsystems.com> Date: Sun, 07 Jul 2013 11:24:11 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> In-Reply-To: <51D92826.1070707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 18:24:13 -0000 On 7/7/13 1:34 AM, Andre Oppermann wrote: > On 07.07.2013 08:32, Alfred Perlstein wrote: >> Andre, >> >> Are you going to have time to MFC things from -current for >> auto-tuning -stable before 9.2? > > I simply ran out of time on Friday and MFCing such a big change requires > more testing. > >> I fear (maybe unnecessarily?) that we are about to ship yet another >> release that can't do basic >> 10gigE when sufficient memory exists. > > There was some debate with myself whether such a behavior changing MFC > would be appropriate for a mid-stream stable release. I guess yes, > though > a number of people who currently set the parameters manually would have > to remove their tuning settings. > >> If you don't have time, then let me know and I'll see what I can do. > > Can you help me with with testing? > Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. -Alfred From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 20:10:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97C9E4D7; Sun, 7 Jul 2013 20:10:00 +0000 (UTC) (envelope-from bsd.gaijin@gmail.com) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 2FEC112FA; Sun, 7 Jul 2013 20:10:00 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id d10so2988080vea.10 for ; Sun, 07 Jul 2013 13:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=oKiH05wLm3qn4RP4TRTbr+qFC+Wi6f25ZwqKmWfPmEI=; b=gFs4ZOkEbJuMTNIsetA4sN6Oyt6n8uTkym+l2viW8M8arp2V6QS6Gn+YiOaSroGjmR 64D0mwdArTWNo/bjIGqPt5AUR7WfqLqc4aIcltrCi5M6kEXybrz/bxR+l+IJJodii3M+ aSjzz7C5BcHFk8kDJiRZNDQymfsVBofYW6i54hEr4Ent3KEWlJOySRCFKZY7U7SZjfu4 5WzGk3uRbmH/vtUpCbq5erhG7Ie/DLRxIRFINhPom4Ue+nzct46hTeWPsmpQS976mJxP n30xmCIgJXR3vD3udi6uHEpD6c2lFKtWto+4B/ctuuyYA+IFYTT2ScA5S5N80DTJgcpA 9Eaw== X-Received: by 10.58.34.178 with SMTP id a18mr12145762vej.86.1373227799597; Sun, 07 Jul 2013 13:09:59 -0700 (PDT) Received: from [10.0.3.5] (pool-71-187-55-117.nwrknj.fios.verizon.net. [71.187.55.117]) by mx.google.com with ESMTPSA id sw5sm12668929vdc.4.2013.07.07.13.09.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 13:09:58 -0700 (PDT) Subject: Re: XHCI umass support breaks between r248085 and r252560 on 9-STABLE Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Alexandre Kovalenko X-Priority: 3 (Normal) In-Reply-To: Date: Sun, 7 Jul 2013 16:09:56 -0400 Message-Id: <9478BFAE-550D-485C-97FD-6F669F5B88EE@gmail.com> References: <94A3DD2E-F2E2-4302-8197-BAB213641E2F@gmail.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1508) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: mav@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 20:10:00 -0000 I do apologize for the typo below, which made my message unclear: I = meant to say that I have reverted _/usr/src/sys/dev/usb/controller_ = directory, specifically the following files: root@twinhead:/usr/src/sys/dev/usb/controller # svn diff -r252560 | grep = Index: Index: xhci_pci.c Index: ohci_pci.c Index: xhci.c Index: usb_controller.c Index: xhcireg.h root@twinhead:/usr/src/sys/dev/usb/controller #=20 which (I think) are USB related and not CAM related. Please, let me know = if I am wrong. SIde question (I have been off the lists for a while): is it now = considered polite to top-post? It was frowned upon way back when=E2=80=A6 = if it still is not, I do apologize, but I can see no good way to fix it = at this point. Alexandre "Sunny" Kovalenko (=D0=9E=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0= =B4=D1=80 =D0=9A=D0=BE=D0=B2=D0=B0=D0=BB=D0=B5=D0=BD=D0=BA=D0=BE) On Jul 7, 2013, at 3:36 AM, Hans Petter Selasky = wrote: > Hi, >=20 > Check for CAM/SCSI related changes. There has not been so many USB = changes recently. Possibly not USB related. >=20 > Thank you, >=20 > --HPS > =20 > -----Original message----- > > From:Alexandre Kovalenko > > Sent: Thursday 4th July 2013 20:58 > > To: freebsd-usb@freebsd.org > > Cc: freebsd-stable@freebsd.org > > Subject: XHCI umass support breaks between r248085 and r252560 on = 9-STABLE > >=20 > > Three different external hard drives (Seagate, Western Digital and = noname USB 3.0 enclosure) refused to be recognized as the umass devices. = Reverting /usr/src/sys/dev/bsd/controller to r248085, building and = loading just xhci module makes drives appear again. Below are snippets = from the log in both cases: > >=20 > > Non working: > >=20 > > Jul 4 14:35:17 twinhead kernel: xhci0: mem 0xfddfe000-0xfddfffff irq 16 at device 0.0 on pci2 > > Jul 4 14:35:17 twinhead kernel: xhci0: 64 byte context size. > > Jul 4 14:35:17 twinhead kernel: usbus0 on xhci0 > > Jul 4 14:35:17 twinhead kernel: usbus0: 5.0Gbps Super Speed USB = v3.0 > > Jul 4 14:35:17 twinhead kernel: ugen0.1: <0x1912> at usbus0 > > Jul 4 14:35:17 twinhead kernel: uhub0: <0x1912 XHCI root HUB, class = 9/0, rev 3.00/1.00, addr 1> on usbus0 > > Jul 4 14:35:17 twinhead kernel: uhub0: 8 ports with 8 removable, = self powered > > Jul 4 14:35:24 twinhead kernel: ugen0.2: at usbus0 > > Jul 4 14:35:24 twinhead kernel: umass0: on usbus0 > > Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 > > Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: CCB request completed with an error > > Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command > > Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 > > Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: CCB request completed with an error > > Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command > > Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 > > Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: CCB request completed with an error > > Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command > > Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 > > Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: CCB request completed with an error > > Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying = command > > Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. = CDB: 12 00 00 00 24 00=20 > > Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: CCB request completed with an error > > Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 5, = Retries exhausted > >=20 > > Working: > >=20 > > Jul 4 14:40:20 twinhead kernel: ugen0.2: at usbus0 = (disconnected) > > Jul 4 14:40:20 twinhead kernel: umass0: at uhub0, port 2, addr 1 = (disconnected) > > Jul 4 14:40:27 twinhead kernel: ugen0.2: at usbus0 > > Jul 4 14:40:27 twinhead kernel: umass0: on usbus0 > > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): REPORT = LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00=20 > > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM = status: SCSI Status Error > > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI = status: Check Condition > > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI = sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) > > Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): Error = 22, Unretryable error > > Jul 4 14:40:27 twinhead kernel: da0 at umass-sim0 bus 0 scbus4 = target 0 lun 0 > > Jul 4 14:40:27 twinhead kernel: da0: = Fixed Direct Access SCSI-5 device=20 > > Jul 4 14:40:27 twinhead kernel: da0: 400.000MB/s transfers > > Jul 4 14:40:27 twinhead kernel: da0: 190782MB (390721968 512 byte = sectors: 255H 63S/T 24321C) > > Jul 4 14:40:27 twinhead kernel: da0: quirks=3D0x2 > >=20 > > I can provide additional information or try patches as necessary. > >=20 > > Alexandre "Sunny" Kovalenko (=D0=9E=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD= =D0=B4=D1=80 =D0=9A=D0=BE=D0=B2=D0=B0=D0=BB=D0=B5=D0=BD=D0=BA=D0=BE) > >=20 > > _______________________________________________ > > freebsd-usb@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > > To unsubscribe, send any mail to = "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 20:50:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8149CE88; Sun, 7 Jul 2013 20:50:01 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4004F161F; Sun, 7 Jul 2013 20:50:00 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 197816A6005; Sun, 7 Jul 2013 22:49:59 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id r67Knw0S069458; Sun, 7 Jul 2013 22:49:58 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r67KnvSB068983; Sun, 7 Jul 2013 22:49:57 +0200 (CEST) (envelope-from lars) Date: Sun, 7 Jul 2013 22:49:57 +0200 From: Lars Engels To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-ID: <20130707204957.GD88288@e-new.0x20.net> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCtUVa7WgqJFqiey" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 20:50:01 -0000 --jCtUVa7WgqJFqiey Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: > On 30 June 2013 07:22, Ian Smith wrote: >=20 > > After removing [numbers] (for WITNESS?), diff started making sense. > > The below is between the first and second suspend/resume cycles in > > dmesg-3.txt, encompassing the others. >=20 > Cool! >=20 > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > Maybe someone who knows might comment on that? > > > > Just checking: you've tried other USB devices apart from uftdi0? >=20 > Yup, there's no 5v on the port. Oh, BTW: can you check if you have power on the ports after the first resume and no power after all next resumes until you reboot your notebook? That's the situation I had and maybe it can lead to something. ;) --jCtUVa7WgqJFqiey Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHZ1HUACgkQKc512sD3afjaBQCfRFbhECzF/rGjcNvsb6oCYrTc xCsAoKg6UrgtLtAMOLTVstVF18b9Og8V =xpuU -----END PGP SIGNATURE----- --jCtUVa7WgqJFqiey-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 7 22:26:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CEE7AFC7 for ; Sun, 7 Jul 2013 22:26:52 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 5D528197E for ; Sun, 7 Jul 2013 22:26:51 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 8185E5C4ED for ; Mon, 8 Jul 2013 00:26:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id Wo37qlfxULha for ; Mon, 8 Jul 2013 00:26:44 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 503625C4EB for ; Mon, 8 Jul 2013 00:26:44 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id AD74750881 for ; Mon, 8 Jul 2013 00:26:43 +0200 (CEST) Message-ID: <51D9EB23.4070505@incore.de> Date: Mon, 08 Jul 2013 00:26:43 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Shutdown hangs on unmount of a gjournaled file system in 8-Stable Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 22:26:52 -0000 The problem occurs after an update of 8-stable from r248120 to r252111. Sometimes shutdown hangs: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. >From the kernel dump I see the deadlock occurs on unmount of a gjournaled file system. Involved are two processes db> ps pid ppid pgrp uid state wmesg wchan cmd 1 0 1 0 SLs mount dr 0xffffff007f7e559c [init] 18 0 0 0 SL suspwt 0xffffff007f7e5364 [g_journal switcher] (kgdb) info threads 158 Thread 100002 (PID=1: init) sched_switch (td=0xffffff000235e8e0, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 .... 217 Thread 100076 (PID=18: g_journal switcher) sched_switch (td=0xffffff0002bd6000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 (kgdb) thread 158 [Switching to thread 158 (Thread 100002)]#0 sched_switche(td=0xffffff000235e8e0, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 1932 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xffffff000235e8e0, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff80407836 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:466 #2 0xffffffff8043e0e2 in sleepq_wait (wchan=0xffffff007f7e559c, pri=80) at /usr/src/sys/kern/subr_sleepqueue.c:613 #3 0xffffffff80407fc6 in _sleep (ident=0xffffff007f7e559c, lock=0xffffff007f7e52f0, priority=, wmesg=0xffffffff8069f595 "mount drain", timo=0) at /usr/src/sys/kern/kern_synch.c:250 #4 0xffffffff8048ee42 in dounmount (mp=0xffffff007f7e52f0, flags=524288, td=) at /usr/src/sys/kern/vfs_mount.c:1266 #5 0xffffffff80493202 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3321 #6 0xffffffff803fec69 in boot (howto=) at /usr/src/sys/kern/kern_shutdown.c:428 #7 0xffffffff803fef86 in reboot (td=, uap=0xffffff8000238bb0) at /usr/src/sys/kern/kern_shutdown.c:191 #8 0xffffffff805db1b4 in amd64_syscall (td=0xffffff000235e8e0, traced=0) at subr_syscall.c:114 #9 0xffffffff805c282c in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 (kgdb) f 5 #5 0xffffffff80493202 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:3321 3321 error = dounmount(mp, MNT_FORCE, td); (kgdb) p mp->mnt_lockref $1=1 (kgdb) f 4 #4 0xffffffff8048ee42 in dounmount (mp=0xffffff007f7e52f0, flags=524288, td=) at /usr/src/sys/kern/vfs_mount.c:1266 1266 error = msleep(&mp->mnt_lockref, MNT_MTX(mp), PVFS, (kgdb) list 1261 if (flags & MNT_FORCE) 1262 mp->mnt_kern_flag |= MNTK_UNMOUNTF; 1263 error = 0; 1264 if (mp->mnt_lockref) { 1265 mp->mnt_kern_flag |= MNTK_DRAINING; 1266 error = msleep(&mp->mnt_lockref, MNT_MTX(mp), PVFS, 1267 "mount drain", 0); 1268 } 1269 MNT_IUNLOCK(mp); 1270 KASSERT(mp->mnt_lockref == 0, (kgdb) thread 217 [Switching to thread 217 (Thread 100076)]#0 sched_switch (td=0xffffff0002bd6000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 1932 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xffffff0002bd6000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff80407836 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:466 #2 0xffffffff8043e0e2 in sleepq_wait (wchan=0xffffff007f7e5364, pri=159) at /usr/src/sys/kern/subr_sleepqueue.c:613 #3 0xffffffff80407fc6 in _sleep (ident=0xffffff007f7e5364, lock=0xffffff007f7e52f0, priority=, wmesg=0xffffffff806a0813 "suspwt", timo=0) at /usr/src/sys/kern/kern_synch.c:250 #4 0xffffffff804a25f0 in vfs_write_suspend (mp=0xffffff007f7e52f0) at /usr/src/sys/kern/vfs_vnops.c:1277 #5 0xffffffff80c843bd in g_journal_switcher (arg=) at /usr/src/sys/modules/geom/geom_journal/../ ../../geom/journal/g_journal.c:2968 #6 0xffffffff803d326f in fork_exit (callout=0xffffffff80c838e0 , arg=0xffffffff80c8b140, frame=0xffffff8242e68c40) at /usr/src/sys/kern/kern_fork.c:872 #7 0xffffffff805c2a0e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 (kgdb) f 4 #4 0xffffffff804a25f0 in vfs_write_suspend (mp=0xffffff007f7e52f0) at /usr/src/sys/kern/vfs_vnops.c:1277 1277 (void) msleep(&mp->mnt_writeopcount, (kgdb) list 1272 while (mp->mnt_kern_flag & MNTK_SUSPEND) 1273 msleep(&mp->mnt_flag, MNT_MTX(mp), PUSER - 1, "wsuspfs", 0); 1274 mp->mnt_kern_flag |= MNTK_SUSPEND; 1275 mp->mnt_susp_owner = curthread; 1276 if (mp->mnt_writeopcount > 0) 1277 (void) msleep(&mp->mnt_writeopcount, 1278 MNT_MTX(mp), (PUSER - 1)|PDROP, "suspwt", 0); 1279 else 1280 MNT_IUNLOCK(mp); 1281 if ((error = VFS_SYNC(mp, MNT_SUSPEND)) != 0) (kgdb) p mp->mnt_writeopcount $2 = 1 The deadlock can be explained now: pid 1 (init) sleeps on "mount drain" because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal switcher) by calling vfs_busy(). pid 18 now sleeps on "suspwt" because mp->mnt_writeopcount was 1. This setting was done by pid 1 before going to sleep by calling vn_start_write() in dounmount(). I think the reason for this deadlock is the commit r249055 which seems not to be compatible with gjournal. Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 01:18:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1AF6C97F for ; Mon, 8 Jul 2013 01:18:22 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E5C3C1EC6 for ; Mon, 8 Jul 2013 01:18:21 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 16so8928623iea.17 for ; Sun, 07 Jul 2013 18:18:20 -0700 (PDT) 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:content-transfer-encoding; bh=RpYaKOzVHpPMw0su4RR2PadTK9P6R8qJmVQPDairGcA=; b=JlLnA5XocJQaU4PvQK6ngBzaOR4bhbb+bffJ9pCZeyODGb3V7LdoWiMS8dsmwuOTUx Mu2kL/0/rsgUw9qmwLhEBdYM+R3/nfU9xsKyJrTNMvP7NtXJZDbu36dbBTJhoYVWjU4C mt6JGMP8mzT9UJa6dftaopQaH18jW0x28jBAos9gvhESAn4LDRZWTZm3jvqUpaycSJVk eFqZ6HrP+Oqs4Zt/444Y96gHa0TFDH8i/c9lt4vEldlsrPmq5AiSHMcT9Sn1fNOmrulZ /wsDICXXyhad+TwEtHF/EIOm4nyDQaJ/rtKw4HkU8GnAq1aeeEVaSIlqu2Lo3bQcdNPt 3ucA== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr7900960igb.38.1373246300571; Sun, 07 Jul 2013 18:18:20 -0700 (PDT) Received: by 10.50.221.179 with HTTP; Sun, 7 Jul 2013 18:18:20 -0700 (PDT) In-Reply-To: <9478BFAE-550D-485C-97FD-6F669F5B88EE@gmail.com> References: <94A3DD2E-F2E2-4302-8197-BAB213641E2F@gmail.com> <9478BFAE-550D-485C-97FD-6F669F5B88EE@gmail.com> Date: Sun, 7 Jul 2013 20:18:20 -0500 Message-ID: Subject: Re: XHCI umass support breaks between r248085 and r252560 on 9-STABLE From: Scot Hetzel To: Alexandre Kovalenko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:18:22 -0000 On Sun, Jul 7, 2013 at 3:09 PM, Alexandre Kovalenko wrote: > > SIde question (I have been off the lists for a while): is it now consider= ed polite to top-post? It was frowned upon way back when=85 if it still is = not, I do apologize, but I can see no good way to fix it at this point. > > Side Answer: I believe that it preferred that you don't top-post on the lists. To get around GMail's top-post issue: - just delete the first 2 lines in the reply - scroll thru the quoted message deleting what isn't relevant to your reply - inline your responses to the relevant parts of the message --=20 DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 01:21:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B3C2BBA4 for ; Mon, 8 Jul 2013 01:21:55 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 8D98D1F00 for ; Mon, 8 Jul 2013 01:21:55 +0000 (UTC) Received: from [10.0.1.3] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r680u9PY076048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Jul 2013 17:56:09 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Sanity Check on Mac Mini From: Doug Hardie In-Reply-To: <7F72BB49-8810-42A4-AC4F-9B6D3E61C6EB@lafn.org> Date: Sun, 7 Jul 2013 17:56:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28915479-B712-4ED0-A041-B75F2F59FECA@lafn.org> References: <51CB1227-3A5F-4688-B48D-4D0E47A17572@lafn.org> <5138A742.3090200@wintek.com> <97F9BA96-A328-4EF9-8E39-A8160AF9EB7A@lafn.org> <71F173FA-CB9C-43B4-A702-ABA82268EA83@lafn.org> <428C87E0-7CF4-4664-9EF2-8CD582927AAB@lafn.org> <7F72BB49-8810-42A4-AC4F-9B6D3E61C6EB@lafn.org> To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:21:55 -0000 As I previously indicated, I have tested a couple more Minis and updated = the instructions with what I learned. Here is the revised version: 2.12 Installing FreeBSD on an Apple Mac Mini The Mac Mini is an attractive server platform. Its small, runs cool, = low powered, and reasonably cheap. There a variety of configurations = available. However, the bottom of the line seems to be a powerful = server. There are a few issues with installing FreeBSD on the mini. Mostly they = derive from the newer hardware it uses and that it uses EFI rather than = a BIOS for booting. There is not a simple install that will get the = unit working, but the additional steps required are quite simple. The = goal of these instructions is to get FreeBSD 9.1-Release running as a = headless server on a Late 2012 Mini, Model No A1347. Its probably = possible to setup the mini as a workstation, but that would require some = additional effort to test the display and mouse interfaces and find = fixes for any issues with those. The original intent was to have the server without system source so that = it could be maintained using freebsd-update. However, that will = probably have to wait until 9.2-Release is available. In the meantime, = freebsd-update has to be used with care since I believe it will replace = the modified bge files. 2.12.1 Preparing for the Install 2.12.1.1 Automatic Startup after Power is Restored Generally servers need to be automatically restarted after a power = failure. Start up the Mini in OS-X. If this is a new unit, I go = through the registration so that Apple has it on record for use with = AppleCare. Go to System Preferences and select Energy Saver. I set Put = hard disk to sleep when possible, Wake for network access, Allow power = button to put the computer to sleep, and most importantly - Start up = automatically after a power failure. Note, shutting down the computer = at this time will not permit it to come back on when power is applied. = You have to pull the power plug. Apparently this setting is a bit = mislabeled. Its more like Return the Power to the last status. These settings work properly with Mac OS-X. I have not found a way to = set the startup settings while running FreeBSD yet. These settings do = carry over to the FreeBSD install. However, you may need to lock the = energy saver preferences for that to happen. Shutdown the Mini. 2.12.1.2 Preparing FreeBSD for the installation You can select either the i386 or the amd64 distributions. Both have = been tested with these procedures and yield a working server. The = bottom of the line mini comes with 4 GB of memory installed. The i386 = distribution will only use 2 GB. The remainder will not be used. The = amd64 distribution builds larger binary modules, but it will use all the = memory. Download the 9.1 Release distribution Memstick Image. You will need to = copy that to a memstick. There are instructions in section 2.3.5 for = copying the image to the memstick. Obtain a display and USB keyboard = and connect them to the mini. With a browser go to svnweb.freebsd.org/base/head/sys/dev. Click on the = bge folder. Click on the name if_bge.c. Find Revision 245931. Click = on the download link and save the file. Go back to the bge page and click on if_bgereg.h. Find Revision 243686. = Click on the download link and save the file. Edit the saved = if_bgereg.h file and add the following to the end: #define PCIER_DEVICE_CAP 0x4 #define PCIER_DEVICE_CTL 0x8 #define PCIEM_CAP_MAX_PAYLOAD 0x00000007 #define PCIEM_CTL_RELAXED_ORD_ENABLE 0x0010 #define PCIEM_CTL_NOSNOOP_ENABLE 0x0800 #define PCIER_DEVICE_STA 0xa #define PCIEM_STA_CORRECTABLE_ERROR 0x0001 #define PCIEM_STA_NON_FATAL_ERROR 0x0002 #define PCIEM_STA_FATAL_ERROR 0x0004 #define PCIEM_STA_UNSUPPORTED_REQ 0x0008 There was a change to some of the names in if_bgereg.h after the 9.1 = Release was created, but before the corrections to the bge driver were = included. It would be possible to grab the appropriate earlier verion = of if_bgereg.h, however, when rebuilding the kernel, there are other = drivers that use the new names. This seems to be the easiest approach. = Also, it worked. Go back to the dev page and click on the mii folder. Click on brgphy.c. = Find revision 244482. Click on the download link and save the file. Copy the saved files to another memstick. 2.12.2 Installing the 9.1 Release Boot the mini using the memstick. Hold down the Option key on the = keyboard and power up the mini. You will hear the hardware check beep = and shortly thereafter the screen will show one or more boot icons. = Double click on the one named "Windows". It will have a USB icon. Continue through the normal installation procedure as detailed earlier = in this chapter. If you are building a FreeBSD only server, use the = entire disk. Also, be sure to install the system source. You will need = it later. You will need to setup the disk using MBR partitioning and not the = default GPT. This part is a bit involved, but not difficult. When = during the install process you get to the Partitioning screen, select = Guided. Then select the desired disk. I select Entire Disk as I only = want FreeBSD on the system. Find the correct disk in the Partition Editor. You will want to select = it and click on Modify. Change the partition type to MBR. Then when = back at the Partition Editor list, select the drive and click on Create. = You will need to then add the first item which will not have a mount = point. Tab to OK and click. Then click on Create again and add the / = slice (freebsd-ufs). The root partition must be first for the system to = be able to boot. Then Click on Create again and add a swap slice = (freebsd-swap). Then continue on through the normal install process. At the end of the install you will be asked to reboot the mini. Here is = where the first problem may occur. If you used the default GPT = partitioning, pop out the memstick and let the system reboot, it will = hang with an empty folder icon in the center of the display. The problem is that the EFI boot loader can't find anything to boot. = There are several approaches that may work. The Mac bless utility has = been used to bless the boot disk so the boot loader can find it. I = found the following instructions for this. However, they indicate that = MBR partitioning is still required. =20 a. We need to boot OSX from the install DVD again b. Choose a language =96> Utilities =96> Terminal c. Enter diskutil list =96> see the 64k? It is something like=20 =93/dev/disk0sX=94 d. Enter bless =96device /dev/diskXXX =96setBoot =96legacy = (where diskXXX is=20 the identifier you found one step before) e. Quit the =93installation process=94 f. Reboot into FreeBSD=20 The one way that has been shown to work is to make sure the memstick is = removed when you boot the mini. Once you get the empty folder icon, = plug the memstick back in. The system will shortly boot from the = internal disk. There is no known explanation for this phenomena other = than "it just works". If you used MBR partitioning, then on boot, the system will sit with a = blank screen for about a minute and then boot as normal. Perhaps = blessing the disk will speed this up. 2.12.3 Rebuilding the kernel to support the Ethernet Interface Once the system has been rebooted, you will notice that ifconfig may not = show the ethernet interface. There are at least two different chips = being used for that interface. Some of the units work right out of the = box. Others do not. I have two units and the only visible difference = is the Part No. Part Nu. MC815LL/A appears to be the older unit and the = bge interface worked on install. Part No MD387LL/A is newer and has the = newer chips that require the driver update. If the bge interface does not show, then the bge driver needs to be = updated to recognize the NIC. Mount the second memstick with the files = retrieved earlier and move them into the kernel source. I used the = following commands: cp -p brgphy.c /usr/src/sys/dev/mii cp -p if_bgereg.h /usr/src/sys/dev/bge cp -p if_bge.c /usr/src/sys/dev/bge then rebuild the kernel. Note the instructions here are for GENERIC, = but you can use KERNCONF to specify a custom kernel. cd /usr/src make buildkernel make installkernel Reboot the server as before. Now ifconfig will show bge0 and it will = work. The mini is now running a useable version of 9.1-Release. There = are still some items remaining to be resolved: Updating the kernel with = the recent security patches, Disabling Bluetooth and Wireless to save = power, and unattended rebooting. These issues are still being = addressed. 2.12.4 Running freebsd-update to get the Latest Security Updates Freebsd-update provides a very convenient was to keep the system up to = date with security updates. It does require that you remain on the = Release distribution and not use modified kernels. Since the mini = requires updates to the bge driver that will not be incorporated into = the 9.1-Release, the modified bge files need to be save somewhere other = than in /usr/src. Freebsd-update will replace them in their normal = locations with the "newer" ones that do not support the mini's NIC. I = saved a copy in my home directory along with a short script that copies = them into the kernel. Run: freebsd-update fetch Run: freebsd-update install Check the differences between the updated bge files and those in the = kernel source. If they have changed, the rebuild the kernel. At the = moment, the security updates have not affected the kernel so it did not = need to be rebuilt. 2.12.5 Disabling Bluetooth and Wireless Mac OS-X provides a way to disable both of these. Ifconfig does not = show either. The Wireless NIC is not attached to a driver so is status = is quite difficult to determine. My guess is that the appropriate = driver will need an update to enable it to be found and controlled. The = same seems to hold for the Bluetooth controller. 2.12.6 Other Versions of the Mac Mini I tried installing on a Mac Mini 1,1 (quite old) and was completely = unsuccessful. I use that machine as an off-site backup so about the = only thing it runs is rsync and cron. Both of those work under OS-X so = I left it that way. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 01:47:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3420B494; Mon, 8 Jul 2013 01:47:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C79551FC6; Mon, 8 Jul 2013 01:47:03 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id d13so5480129qak.9 for ; Sun, 07 Jul 2013 18:47:03 -0700 (PDT) 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=Q9kXV1UZOmOglVLUGGHePTC0SKFwfzoN7M43v67FSvw=; b=pTivoVDlc/mWWU6plQuaTNGrcn/1h8cJyniaRiveKPr9UYoYkL1xGs8HMC5861Y9Ej TZXxVCi0kOWVYaPye3vSxJo2nm7kTYsI9Dzn/px+x9hQQSQ/kf+ZU5buDdkqNVrnRKq3 Bg9K7ZUtbHhnXijPkR9LDgiNtiaQwgVmlxIfv4ycC1CRgb9hNQ535UpbCRkGJUe7qNK3 IVTMZMYn9mrIoXDKdJyUHskrO/Si/HHShx46YRevfgrxcGcZRfyJUTD24jQthuW9AsNX Dkjb+GIRhd4hnZfioHCLMM4q3vDDLG/3iXKDJwKVdO5W711+STRRCIc/RcuwstvE9y0G g9bg== MIME-Version: 1.0 X-Received: by 10.49.117.195 with SMTP id kg3mr13929647qeb.68.1373248023418; Sun, 07 Jul 2013 18:47:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 18:47:03 -0700 (PDT) In-Reply-To: <20130707204957.GD88288@e-new.0x20.net> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> Date: Sun, 7 Jul 2013 18:47:03 -0700 X-Google-Sender-Auth: 0i847bi-sS21nTIFcyBUCzOEboo Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:47:04 -0000 Nope, no power after first resume if i have nothing plugged in. Why? -adrian On 7 July 2013 13:49, Lars Engels wrote: > On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: >> On 30 June 2013 07:22, Ian Smith wrote: >> >> > After removing [numbers] (for WITNESS?), diff started making sense. >> > The below is between the first and second suspend/resume cycles in >> > dmesg-3.txt, encompassing the others. >> >> Cool! >> >> > Nothing of note that I can see, if that usb hub-to-bus remapping is >> > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. >> > Maybe someone who knows might comment on that? >> > >> > Just checking: you've tried other USB devices apart from uftdi0? >> >> Yup, there's no 5v on the port. > > Oh, BTW: can you check if you have power on the ports after the first > resume and no power after all next resumes until you reboot your > notebook? > That's the situation I had and maybe it can lead to something. ;) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 02:36:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 098E3E11 for ; Mon, 8 Jul 2013 02:36:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id D56B71189 for ; Mon, 8 Jul 2013 02:36:33 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y10so3602951pdj.14 for ; Sun, 07 Jul 2013 19:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=tU+2LNC4Hr2eWnbxN2H3p39aGf2pA8ZyRXDIzTmPK4M=; b=t1KSOOTUNWHPvzhd0sc0v+J9i2o2zeBfAK2Kop6G7fArtlhtDrk2eeJEMMcfFbGR4C SbGkOHmH9oN2KCl1skqaU6Oyxy0wczgQ5f0dpqBCF70k3082gvQ0KftgsWo+yECiRl4t 0Dnh1DJg7743wJyQEmS5PH4QjV1ZkYjqelNKyaWucVlICKpwOHPZ3pwLlZqZobZk0nmv puxzcXCALBQaf4+zl+oWQ0JDjVwX+37CU4ZcE+wN+SQeTri6IO6Pe27cLrYajrhV6MZo XDkpvx4iCi6CkFz/RK3H5m7b54kyjWv1pd9SgZIjcKCZ9qlAt/3dXreIKyHqOJ+4j+3G VGBA== X-Received: by 10.66.142.5 with SMTP id rs5mr13462732pab.168.1373250993492; Sun, 07 Jul 2013 19:36:33 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id kc8sm19595699pbc.18.2013.07.07.19.36.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 07 Jul 2013 19:36:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 08 Jul 2013 11:36:28 +0900 From: Yonghyeon PYUN Date: Mon, 8 Jul 2013 11:36:27 +0900 To: Doug Hardie Subject: Re: Sanity Check on Mac Mini Message-ID: <20130708023627.GA4258@michelle.cdnetworks.com> References: <51CB1227-3A5F-4688-B48D-4D0E47A17572@lafn.org> <5138A742.3090200@wintek.com> <97F9BA96-A328-4EF9-8E39-A8160AF9EB7A@lafn.org> <71F173FA-CB9C-43B4-A702-ABA82268EA83@lafn.org> <428C87E0-7CF4-4664-9EF2-8CD582927AAB@lafn.org> <7F72BB49-8810-42A4-AC4F-9B6D3E61C6EB@lafn.org> <28915479-B712-4ED0-A041-B75F2F59FECA@lafn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28915479-B712-4ED0-A041-B75F2F59FECA@lafn.org> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-stable@freebsd.org List" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 02:36:34 -0000 On Sun, Jul 07, 2013 at 05:56:09PM -0700, Doug Hardie wrote: > As I previously indicated, I have tested a couple more Minis and updated the instructions with what I learned. Here is the revised version: > [...] > 2.12.3 Rebuilding the kernel to support the Ethernet Interface > > Once the system has been rebooted, you will notice that ifconfig may not show the ethernet interface. There are at least two different chips being used for that interface. Some of the units work right out of the box. Others do not. I have two units and the only visible difference is the Part No. Part Nu. MC815LL/A appears to be the older unit and the bge interface worked on install. Part No MD387LL/A is newer and has the newer chips that require the driver update. > > If the bge interface does not show, then the bge driver needs to be updated to recognize the NIC. Mount the second memstick with the files retrieved earlier and move them into the kernel source. I used the following commands: > > cp -p brgphy.c /usr/src/sys/dev/mii > cp -p if_bgereg.h /usr/src/sys/dev/bge > cp -p if_bge.c /usr/src/sys/dev/bge > > then rebuild the kernel. Note the instructions here are for GENERIC, but you can use KERNCONF to specify a custom kernel. > > cd /usr/src > make buildkernel > make installkernel > > Reboot the server as before. Now ifconfig will show bge0 and it will work. The mini is now running a useable version of 9.1-Release. There are still some items remaining to be resolved: Updating the kernel with the recent security patches, Disabling Bluetooth and Wireless to save power, and unattended rebooting. These issues are still being addressed. > I'm not sure whether this bge(4) controller is sitting behind TB(Apple Thunderbolt) bridge. The Apple TB bridge has known performance issue and some BCM controllers have a work-around to mitigate it. The work-around is not enabled by default so I'm interested in bge(4) performance numbers on your box. If you can't get more than 920 ~ 930Mbps(950Mbps or higher with jumbo frame) please let me know. I didn't enable the work-around yet since it will hurt other BCM controllers when TB bridge is absent. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 05:00:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7404ADEE; Mon, 8 Jul 2013 05:00:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A8C3317D3; Mon, 8 Jul 2013 05:00:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6850XOb012097; Mon, 8 Jul 2013 15:00:34 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 8 Jul 2013 15:00:33 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130708140804.R26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Lars Engels , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:00:44 -0000 On Sun, 7 Jul 2013 18:47:03 -0700, Adrian Chadd wrote: > On 7 July 2013 13:49, Lars Engels wrote: > > On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: > >> On 30 June 2013 07:22, Ian Smith wrote: > >> > >> > After removing [numbers] (for WITNESS?), diff started making sense. > >> > The below is between the first and second suspend/resume cycles in > >> > dmesg-3.txt, encompassing the others. > >> > >> Cool! > >> > >> > Nothing of note that I can see, if that usb hub-to-bus remapping is > >> > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > >> > Maybe someone who knows might comment on that? > >> > > >> > Just checking: you've tried other USB devices apart from uftdi0? > >> > >> Yup, there's no 5v on the port. > > > > Oh, BTW: can you check if you have power on the ports after the first > > resume and no power after all next resumes until you reboot your > > notebook? > > That's the situation I had and maybe it can lead to something. ;) > Nope, no power after first resume if i have nothing plugged in. > > Why? Checking one more point .. do the USB ports come up ok if you originally boot with nothing plugged in? If so (or if not), does that local APIC error message appear the same then too? cheers, Ian PS OT: finally found a USB keyboard but I'd forgotten that my friend's machine is an SL500, not T500. Moreover, because its keyboard+trackpad etc is non-working (internally disconnected), I have no way to resume it without the kbd (and the 9.1-R memstick) plugged in. Even with kbd and memstick left in and using acpiconf -s3 it suspends ok but is hung after resume by dabbing power button; no screen and kbd is dead too - sorry, no help there. OTOH my son just bought a refurb T430 ('doze 7, beats 8 anyway) which I should get to play with a bit this week. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 05:43:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E00EF42B for ; Mon, 8 Jul 2013 05:43:13 +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 3A05D190C for ; Mon, 8 Jul 2013 05:43:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r685h2AA038382; Mon, 8 Jul 2013 08:43:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r685h2AA038382 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r685h1Oj038381; Mon, 8 Jul 2013 08:43:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Jul 2013 08:43:01 +0300 From: Konstantin Belousov To: Andreas Longwitz Subject: Re: Shutdown hangs on unmount of a gjournaled file system in 8-Stable Message-ID: <20130708054301.GI91021@kib.kiev.ua> References: <51D9EB23.4070505@incore.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HmXnia/qGvWh3jry" Content-Disposition: inline In-Reply-To: <51D9EB23.4070505@incore.de> 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-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:43:13 -0000 --HmXnia/qGvWh3jry Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 08, 2013 at 12:26:43AM +0200, Andreas Longwitz wrote: > The deadlock can be explained now: pid 1 (init) sleeps on "mount drain" > because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal > switcher) by calling vfs_busy(). pid 18 now sleeps on "suspwt" because > mp->mnt_writeopcount was 1. This setting was done by pid 1 before going > to sleep by calling vn_start_write() in dounmount(). >=20 > I think the reason for this deadlock is the commit r249055 which seems > not to be compatible with gjournal. Thank you for the analysis. I think 'not compatible' is some understatement. The situation clearly causes a deadlock, you are right. The vfs_busy(); vfs_write_suspend(); call sequence is somewhat dubious, in fact, exactly because unmount could start in between. I think that vfs_write_suspend() must avoid setting MNT_SUSPEND if unmount was started. Patch below, for HEAD, should fix the problem, by marking the callers of vfs_write_suspend(), which are not protected by the covered vnode lock, with the VS_SKIP_UNMOUNT flag. I believe that the conflicts on stable/8 should be trivial, if any. diff --git a/sys/geom/journal/g_journal.c b/sys/geom/journal/g_journal.c index a3c996c..3ce2785 100644 --- a/sys/geom/journal/g_journal.c +++ b/sys/geom/journal/g_journal.c @@ -2960,7 +2960,7 @@ g_journal_do_switch(struct g_class *classp) GJ_TIMER_STOP(1, &bt, "BIO_FLUSH time of %s", sc->sc_name); =20 GJ_TIMER_START(1, &bt); - error =3D vfs_write_suspend(mp); + error =3D vfs_write_suspend(mp, VS_SKIP_UNMOUNT); GJ_TIMER_STOP(1, &bt, "Suspend time of %s", mountpoint); if (error !=3D 0) { GJ_DEBUG(0, "Cannot suspend file system %s (error=3D%d).", diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index 7eac0ef..06e59f9 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -1668,8 +1668,7 @@ vn_finished_secondary_write(mp) * Request a filesystem to suspend write operations. */ int -vfs_write_suspend(mp) - struct mount *mp; +vfs_write_suspend(struct mount *mp, int flags) { int error; =20 @@ -1680,6 +1679,21 @@ vfs_write_suspend(mp) } while (mp->mnt_kern_flag & MNTK_SUSPEND) msleep(&mp->mnt_flag, MNT_MTX(mp), PUSER - 1, "wsuspfs", 0); + + /* + * Unmount holds a write reference on the mount point. If we + * own busy reference and drain for writers, we deadlock with + * the reference draining in the unmount path. Callers of + * vfs_write_suspend() must specify VS_SKIP_UNMOUNT if + * vfs_busy() reference is owned and caller is not in the + * unmount context. + */ + if ((flags & VS_SKIP_UNMOUNT) !=3D 0 && + (mp->mnt_kern_flag & MNTK_UNMOUNT) !=3D 0) { + MNT_IUNLOCK(mp); + return (EBUSY); + } + mp->mnt_kern_flag |=3D MNTK_SUSPEND; mp->mnt_susp_owner =3D curthread; if (mp->mnt_writeopcount > 0) diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index 42bfb65..b0cbcc0 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -398,6 +398,9 @@ extern int vttoif_tab[]; #define VR_START_WRITE 0x0001 /* vfs_write_resume: start write atomically = */ #define VR_NO_SUSPCLR 0x0002 /* vfs_write_resume: do not clear suspension = */ =20 +#define VS_SKIP_UNMOUNT 0x0001 /* vfs_write_suspend: fail if the + filesystem is being unmounted */ + #define VREF(vp) vref(vp) =20 #ifdef DIAGNOSTIC @@ -711,7 +714,7 @@ int vn_io_fault_pgmove(vm_page_t ma[], vm_offset_t offs= et, int xfersize, int vfs_cache_lookup(struct vop_lookup_args *ap); void vfs_timestamp(struct timespec *); void vfs_write_resume(struct mount *mp, int flags); -int vfs_write_suspend(struct mount *mp); +int vfs_write_suspend(struct mount *mp, int flags); int vop_stdbmap(struct vop_bmap_args *); int vop_stdfsync(struct vop_fsync_args *); int vop_stdgetwritemount(struct vop_getwritemount_args *); diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c index 9a9c88a..ad157aa 100644 --- a/sys/ufs/ffs/ffs_snapshot.c +++ b/sys/ufs/ffs/ffs_snapshot.c @@ -423,7 +423,7 @@ restart: */ for (;;) { vn_finished_write(wrtmp); - if ((error =3D vfs_write_suspend(vp->v_mount)) !=3D 0) { + if ((error =3D vfs_write_suspend(vp->v_mount, 0)) !=3D 0) { vn_start_write(NULL, &wrtmp, V_WAIT); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); goto out; diff --git a/sys/ufs/ffs/ffs_suspend.c b/sys/ufs/ffs/ffs_suspend.c index 3198c1a..a8c4578 100644 --- a/sys/ufs/ffs/ffs_suspend.c +++ b/sys/ufs/ffs/ffs_suspend.c @@ -206,7 +206,7 @@ ffs_susp_suspend(struct mount *mp) return (EPERM); #endif =20 - if ((error =3D vfs_write_suspend(mp)) !=3D 0) + if ((error =3D vfs_write_suspend(mp, VS_SKIP_UNMOUNT)) !=3D 0) return (error); =20 ump->um_writesuspended =3D 1; diff --git a/sys/ufs/ffs/ffs_vfsops.c b/sys/ufs/ffs/ffs_vfsops.c index 57f092c..a87fdfa 100644 --- a/sys/ufs/ffs/ffs_vfsops.c +++ b/sys/ufs/ffs/ffs_vfsops.c @@ -257,7 +257,7 @@ ffs_mount(struct mount *mp) return (error); for (;;) { vn_finished_write(mp); - if ((error =3D vfs_write_suspend(mp)) !=3D 0) + if ((error =3D vfs_write_suspend(mp, 0)) !=3D 0) return (error); MNT_ILOCK(mp); if (mp->mnt_kern_flag & MNTK_SUSPENDED) { @@ -1255,7 +1255,7 @@ ffs_unmount(mp, mntflags) */ for (;;) { vn_finished_write(mp); - if ((error =3D vfs_write_suspend(mp)) !=3D 0) + if ((error =3D vfs_write_suspend(mp, 0)) !=3D 0) return (error); MNT_ILOCK(mp); if (mp->mnt_kern_flag & MNTK_SUSPENDED) { --HmXnia/qGvWh3jry Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2lFlAAoJEJDCuSvBvK1Bs/wQAIsAa78Lxaj34I1LNgp01SAS E2xWUTHvCSEVQIUdMbopqtHagjEgMaIj2mJctYkBMOF6z5QkUh8wdeqq8KeI+EJh osBQEXZ7zUiXGN2o6PoSQP7+FRXakVX3r40jCzV0H5lvcpJ74I/lYuLz818swksf ufXMUxqsd6mQ6NOaOvwgt5ze6LW6y4aQ2h9GWXyeHey8a7Tg0NKcbqHoId+tDkIu hamLTkz/72OFnbvHlER5L5L0KSglmAk5aeuzySoBUk5g/SGFSDgHvdvAzZamdwsE zfZ0Ec2D+thooInS3yyq+gI0B2e9sxpWGekXS7s+S63GRA/0IITHBo0vpU8mPqUS 3JmecCvgsNGi43o/ddHAdyBH9nSw6Ew9RdCmuNk2P85LvAgBobCFkFlYdzI5V5cj FugG4FtKgv79wkYYcWB1FfeDFVOYs0+YeQME0uZNSyCJtpZaGNX0PT+o46hszQ2b IO+Oxnko5vSrfI6IzDOLEk0g6BsZe84YnILo1auLsQQGO6G9jlzp6vhWu+IZJKib pos4quRlvfkvkEbcIx4+9oKuHIbPv6uCHG3nQwpS+mIAAaSn+82LSiO0bFJ+wEzc U+QrwOAwMWdTLcusrziCHmFvU+mHDy4yvnzlWNTAt8zE5Nyso11HOnmHhIH+9rsZ oMojlqI9V98Ew8nEp4LS =fUQf -----END PGP SIGNATURE----- --HmXnia/qGvWh3jry-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 06:28:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 95BC5712; Mon, 8 Jul 2013 06:28:55 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id 20A3E1ACF; Mon, 8 Jul 2013 06:28:53 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r686SlJ0001963; Mon, 8 Jul 2013 08:28:47 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r686SkPH029571; Mon, 8 Jul 2013 08:28:47 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r686SkYY032383; Date: Mon, 8 Jul 2013 08:28:46 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130708062846.GA46217@bali> References: <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130707072553.GA38133@bali> <20130707074112.GD91021@kib.kiev.ua> <20130707121354.GA39055@bali> <20130707123217.GA54979@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707123217.GA54979@icarus.home.lan> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 06:28:55 -0000 On Sun, 07-Jul-2013 at 14:32:17 +0200, Jeremy Chadwick wrote: > On Sun, Jul 07, 2013 at 02:13:54PM +0200, Andre Albsmeier wrote: > > On Sun, 07-Jul-2013 at 09:41:12 +0200, Konstantin Belousov wrote: > > > On Sun, Jul 07, 2013 at 09:25:53AM +0200, Andre Albsmeier wrote: > > > > OK, here we go (looks better now): > > > > > > > > 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 "i386-marcel-freebsd"... > > > > > > > > Unread portion of the kernel message buffer: > > > > dev = stripe/p, block = 592, fs = /palveli > > > > panic: ffs_blkfree_cg: freeing free block > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper(c08207eb,d70fc924,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd70fc8f4 > > > > kdb_backtrace(c081df13,c08a82e0,c0833a0b,d70fc930,d70fc930,...) at kdb_backtrace+0x29/frame 0xd70fc900 > > > > panic(c0833a0b,c2aae178,250,0,c2af80d4,...) at panic+0xc9/frame 0xd70fc924 > > > > ffs_blkfree_cg(250,0,8000,49f,d70fcad0,...) at ffs_blkfree_cg+0x399/frame 0xd70fc9c8 > > > > ffs_blkfree(c2b35100,c2af8000,c2b0d470,250,0,...) at ffs_blkfree+0xad/frame 0xd70fca00 > > > > indir_trunc(fffa3ff4,ffffffff,0,8000,0,...) at indir_trunc+0x658/frame 0xd70fcae0 > > > > indir_trunc(ffffdff3,ffffffff,c072df0a,c2d68d00,c087abd8,...) at indir_trunc+0x514/frame 0xd70fcbc0 > > > > handle_workitem_freeblocks(0,d70fcc4c,2,246,c2ab1000,...) at handle_workitem_freeblocks+0x2dc/frame 0xd70fcc24 > > > > process_worklist_item(0,0,0,c086ae78,0,...) at process_worklist_item+0x27a/frame 0xd70fcc6c > > > > softdep_process_worklist(c2b36548,0,54,c0835825,64,...) at softdep_process_worklist+0x91/frame 0xd70fcc9c > > > > softdep_flush(0,d70fcd08,0,c2aac2f0,0,...) at softdep_flush+0x3e4/frame 0xd70fcccc > > > > fork_exit(c0738bb0,0,d70fcd08) at fork_exit+0xa2/frame 0xd70fccf4 > > > > fork_trampoline() at fork_trampoline+0x8/frame 0xd70fccf4 > > > > --- trap 0, eip = 0, esp = 0xd70fcd40, ebp = 0 --- > > > > Uptime: 2d16h29m37s > > > > Physical memory: 503 MB > > > > Dumping 95 MB: 80 64 48 32 16 > > > > > > > > No symbol "stopped_cpus" in current context. > > > > No symbol "stoppcbs" in current context. > > > > #0 doadump (textdump=1) at pcpu.h:249 > > > > 249 pcpu.h: No such file or directory. > > > > in pcpu.h > > > > (kgdb) where > > > > #0 doadump (textdump=1) at pcpu.h:249 > > > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > > > #3 0xc0717899 in ffs_blkfree_cg (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > > > size=32768, inum=1183, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2151 > > > > #4 0xc0717c8d in ffs_blkfree (ump=0xc2b35100, fs=0xc2af8000, devvp=0xc2b0d470, bno=592, > > > > size=32768, inum=1183, vtype=VREG, dephd=0xd70fcad0) at /src/src-9/sys/ufs/ffs/ffs_alloc.c:2280 > > > > #5 0xc0730348 in indir_trunc (freework=0xc2f99100, dbn=1642816, lbn=-376844) > > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7965 > > > > #6 0xc0730204 in indir_trunc (freework=0xc2f99100, dbn=1639680, lbn=-8205) > > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7946 > > > > #7 0xc07324bc in handle_workitem_freeblocks (freeblks=0xc2fc1e00, flags=512) > > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:7588 > > > > #8 0xc0730dfa in process_worklist_item (mp=0xc2b36548, target=10, flags=512) > > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1774 > > > > #9 0xc07360c1 in softdep_process_worklist (mp=0xc2b36548, full=0) > > > > at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1558 > > > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > > > #11 0xc05d1b82 in fork_exit (callout=0xc0738bb0 , arg=0x0, frame=0xd70fcd08) > > > > at /src/src-9/sys/kern/kern_fork.c:988 > > > > #12 0xc07ba904 in fork_trampoline () at /src/src-9/sys/i386/i386/exception.s:279 > > > > (kgdb) up 10 > > > > #10 0xc0738f94 in softdep_flush () at /src/src-9/sys/ufs/ffs/ffs_softdep.c:1414 > > > > 1414 progress += softdep_process_worklist(mp, 0); > > > > > > > > -Andre > > > > > > This looks unrelated, and exactly this panic is usually has one of two > > > causes: > > > - corrupted filesystem, run fsck to recheck it; > > > > root@palveli:~>fsck /dev/stripe/p > > ** /dev/stripe/p > > ** Last Mounted on /palveli > > ** Phase 1 - Check Blocks and Sizes > > ** Phase 2 - Check Pathnames > > ** Phase 3 - Check Connectivity > > ** Phase 4 - Check Reference Counts > > ** Phase 5 - Check Cyl groups > > 9895 files, 2039706 used, 15697693 free (5397 frags, 1961537 blocks, 0.0% fragmentation) > > > > ***** FILE SYSTEM IS CLEAN ***** > > Taken from your previous mail (showing only UFS stuff): > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073817.html > > >>>> fstab: > >>>> ------ > >>>> /dev/da0s1a / ufs noatime,rw 0 1 > >>>> /dev/da0s1d /usr ufs noatime,rw 0 2 > >>>> /dev/da0s1e /var ufs noatime,nosuid,rw 0 2 > >>>> /dev/da10p1 /share2 ufs suiddir,groupquota,noatime,nosuid,rw 0 2 > >>>> /dev/da10p2 /raid2 ufs userquota,noatime,nosuid,rw 0 2 > > Where is gstripe(8) in that picture? Are you **sure** this is the same > system? Surely I'm missing something here... It is the same system that produced the (bad) dump in my previous mail (the one with the bcopy problem). It is NOT the same system which we used for finding out why it didn't dump (which we found out now and which was due to the spun down da1). Just for the sake of clarity: There are two systems showing this problem when running the daily snapshot. Since users complained about these disruption, I have moved important stuff from one machine to the other (where I disabled the sanpshot generation) so I can concentrate on this one (the one to which belong the dumps) for finding the problem. > > Can you provide details of the stripe, specifically "gstripe list" so I > can see what the disks are and then ask you for "smartctl -a" output for > each of them (to try and rule out disk-level problems that may be > causing oddities at the layer underneathe the filesystem (sometimes fsck > will not catch this))? Here is "gstripe list": Geom name: p State: UP Status: Total=2, Online=2 Type: AUTOMATIC Stripesize: 32768 ID: 2179163030 Providers: 1. Name: stripe/p Mediasize: 72802893824 (67G) Sectorsize: 512 Stripesize: 32768 Stripeoffset: 0 Mode: r0w0e0 Consumers: 1. Name: da10 Mediasize: 36401479680 (33G) Sectorsize: 512 Mode: r0w0e0 Number: 0 2. Name: da11 Mediasize: 36401479680 (33G) Sectorsize: 512 Mode: r0w0e0 Number: 1 The disks are old but seem to work properly: da10 at ahc1 bus 0 scbus1 target 0 lun 0 da10: Fixed Direct Access SCSI-3 device da10: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da10: Command Queueing enabled da10: 34715MB (71096640 512 byte sectors: 255H 63S/T 4425C) da11 at ahc1 bus 0 scbus1 target 1 lun 0 da11: Fixed Direct Access SCSI-3 device da11: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da11: Command Queueing enabled da11: 34715MB (71096640 512 byte sectors: 255H 63S/T 4425C) On both disks the PER bit is set so I'll see any read error problems even if they were retried or ECC-corrected (which haven't been there for ages). When the snapshot problem appeared for the first time, I also rebuilt the fs from scratch. -Andre From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 11:23:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4ACC1E9; Mon, 8 Jul 2013 11:23:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id AFFE21BD6; Mon, 8 Jul 2013 11:23:42 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r688Rac1051041; Mon, 8 Jul 2013 08:27:36 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r688RZp0051038; Mon, 8 Jul 2013 08:27:35 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Jul 2013 08:27:35 GMT Message-Id: <201307080827.r688RZp0051038@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , Subject: [releng_8 tinderbox] source tree update failure Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:23:43 -0000 TB --- 2013-07-08 08:10:00 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-07-08 08:10:00 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 08:10:00 - starting RELENG_8 tinderbox run for none/none TB --- 2013-07-08 08:10:00 - checking out /src from svn://svn.freebsd.org/base/stable/8 TB --- 2013-07-08 08:10:00 - cd /tinderbox/RELENG_8/none/none TB --- 2013-07-08 08:10:00 - /usr/local/bin/svn cleanup /src TB --- 2013-07-08 08:10:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:12:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:12:35 - WARNING: sleeping 30 s and retrying... TB --- 2013-07-08 08:13:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:15:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:15:35 - WARNING: sleeping 60 s and retrying... TB --- 2013-07-08 08:16:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:19:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:19:05 - WARNING: sleeping 90 s and retrying... TB --- 2013-07-08 08:20:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:23:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:23:05 - WARNING: sleeping 120 s and retrying... TB --- 2013-07-08 08:25:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:27:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:27:35 - ERROR: unable to check out the source tree TB --- 2013-07-08 08:27:35 - 1.36 user 2.16 system 1055.66 real http://tinderbox.freebsd.org/tinderbox-freebsd8-update-RELENG_8-none-none.full From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 11:23:43 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 565501EF; Mon, 8 Jul 2013 11:23:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3CC1BD8; Mon, 8 Jul 2013 11:23:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id r688RaaD051040; Mon, 8 Jul 2013 08:27:36 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id r688RZsG051039; Mon, 8 Jul 2013 08:27:35 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 8 Jul 2013 08:27:35 GMT Message-Id: <201307080827.r688RZsG051039@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , Subject: [releng_8_4 tinderbox] source tree update failure Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:23:43 -0000 TB --- 2013-07-08 08:10:00 - tinderbox 2.10 running on freebsd-legacy2.sentex.ca TB --- 2013-07-08 08:10:00 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-08 08:10:00 - starting RELENG_8_4 tinderbox run for none/none TB --- 2013-07-08 08:10:00 - checking out /src from svn://svn.freebsd.org/base/releng/8.4 TB --- 2013-07-08 08:10:00 - cd /tinderbox/RELENG_8_4/none/none TB --- 2013-07-08 08:10:00 - /usr/local/bin/svn cleanup /src TB --- 2013-07-08 08:10:04 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:12:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:12:35 - WARNING: sleeping 30 s and retrying... TB --- 2013-07-08 08:13:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:15:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:15:35 - WARNING: sleeping 60 s and retrying... TB --- 2013-07-08 08:16:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:19:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:19:05 - WARNING: sleeping 90 s and retrying... TB --- 2013-07-08 08:20:35 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:23:05 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:23:05 - WARNING: sleeping 120 s and retrying... TB --- 2013-07-08 08:25:05 - /usr/local/bin/svn update /src TB --- 2013-07-08 08:27:35 - WARNING: /usr/local/bin/svn returned exit code 1 TB --- 2013-07-08 08:27:35 - ERROR: unable to check out the source tree TB --- 2013-07-08 08:27:35 - 1.44 user 1.98 system 1055.66 real http://tinderbox.freebsd.org/tinderbox-freebsd8-update-RELENG_8_4-none-none.full From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 11:40:40 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA01F208 for ; Mon, 8 Jul 2013 11:40:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C2ED712F2 for ; Mon, 8 Jul 2013 11:40:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r68BeXYa053981 for ; Mon, 8 Jul 2013 11:40:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68B6gFU046215 for freebsd-stable@FreeBSD.org; Mon, 8 Jul 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jul 2013 11:06:42 GMT Message-Id: <201307081106.r68B6gFU046215@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-stable@FreeBSD.org Subject: Current problem reports assigned to freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:40:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/179112 stable 9.1 installer panics with a kmem_malloc() failure on i 1 problem total. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 14:37:09 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B5F3CF8 for ; Mon, 8 Jul 2013 14:37:09 +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 EB9761610 for ; Mon, 8 Jul 2013 14:37:08 +0000 (UTC) Received: (qmail 62702 invoked from network); 8 Jul 2013 15:28:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 15:28:15 -0000 Message-ID: <51DACE93.9050608@freebsd.org> Date: Mon, 08 Jul 2013 16:37:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> In-Reply-To: <51D9B24B.8070303@ixsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:37:09 -0000 On 07.07.2013 20:24, Alfred Perlstein wrote: > On 7/7/13 1:34 AM, Andre Oppermann wrote: >> Can you help me with with testing? >> > Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff This is functional bundle MFC of these original commits: MFC r242029 (alfred): Allow autotune maxusers > 384 on 64 bit machines. MFC r242847 (alfred): Allow maxusers to scale on machines with large address space. MFC r243631 (andre): Base the mbuf related limits on the available physical memory or kernel memory, whichever is lower. The overall mbuf related memory limit must be set so that mbufs (and clusters of various sizes) can't exhaust physical RAM or KVM. At the same time divorce maxfiles from maxusers and set maxfiles to physpages / 8 with a floor based on maxusers. This way busy servers can make use of the significantly increased mbuf limits with a much larger number of open sockets. MFC r243639 (andre): Complete r243631 by applying the remainder of kern_mbuf.c that got lost while merging into the commit tree. MFC r243668 (andre): Using a long is the wrong type to represent the realmem and maxmbufmem variable as they may overflow on i386/PAE and i386 with > 2GB RAM. MFC r243995, r243996, r243997 (pjd): Style cleanups, Make use of the fact that uma_zone_set_max(9) already returns actual limit set. MFC r244080 (andre): Prevent long type overflow of realmem calculation on ILP32 by forcing calculation to be in quad_t space. Fix style issue with second parameter to qmin(). MFC r245469 (alfred): Do not autotune ncallout to be greater than 18508. MFC r245575 (andre): Move the mbuf memory limit calculations from init_param2() to tunable_mbinit() where it is next to where it is used later. MFC r246207 (andre): Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. MFC r249843 (andre): Base the calculation of maxmbufmem in part on kmem_map size instead of kernel_map size to prevent kernel memory exhaustion by mbufs and a subsequent panic on physical page allocation failure. -- Andre From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 14:41:47 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B785DE4F; Mon, 8 Jul 2013 14:41:47 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB21164C; Mon, 8 Jul 2013 14:41:47 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id xk17so5596385obc.10 for ; Mon, 08 Jul 2013 07:41:47 -0700 (PDT) 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=CVGhfwTglARovU86hlMZOKKYbI3+qi1ZmUmddkn+oa0=; b=Rt9B7Fb6hB1qZmHEow6SEE90XFvZWzyERttVK9arLpkdSo4Cwx1gZUhnxfUOwrkVtE YdrFElc9QGPlxpvaCJVdYLn0eliupXsswblgGYW5nI1pDXxxnH5KOYnGW9Nsi7EjBxwM r37ZK9iuDHC0hFxfXMZ1nG3FDBVbJyKT8aX7t+e8Xm7h5GfHMdDuH4wfWmoT3jusXGKZ p8u75aaJjJkdPUUHmPcIJCiG0AtsQVwn067bpbzfD7+889bW3micPE4bynTHu8A2GuY8 L21DiBhe+tEbJr2Kjb58dtS/Dreo0tZ5Zj7n4lHSKS9RhIGzWdlR3rGM1j5tiv54er5T FCdw== MIME-Version: 1.0 X-Received: by 10.60.146.134 with SMTP id tc6mr20229325oeb.95.1373294506987; Mon, 08 Jul 2013 07:41:46 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Mon, 8 Jul 2013 07:41:46 -0700 (PDT) In-Reply-To: <51DACE93.9050608@freebsd.org> References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> Date: Mon, 8 Jul 2013 10:41:46 -0400 Message-ID: Subject: Re: status of autotuning freebsd for 9.2 From: Outback Dingo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:41:47 -0000 On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann wrote: > On 07.07.2013 20:24, Alfred Perlstein wrote: > >> On 7/7/13 1:34 AM, Andre Oppermann wrote: >> >>> Can you help me with with testing? >>> >>> Yes. Please give me your proposed changes and I'll stand up a machine >> and give feedback. >> > > http://people.freebsd.org/~**andre/mfc-autotuning-20130708.**diff > > This is functional bundle MFC of these original commits: > > MFC r242029 (alfred): > > Allow autotune maxusers > 384 on 64 bit machines. > > MFC r242847 (alfred): > > Allow maxusers to scale on machines with large address space. > > MFC r243631 (andre): > > Base the mbuf related limits on the available physical memory or > kernel memory, whichever is lower. The overall mbuf related memory > limit must be set so that mbufs (and clusters of various sizes) > can't exhaust physical RAM or KVM. > > At the same time divorce maxfiles from maxusers and set maxfiles to > physpages / 8 with a floor based on maxusers. This way busy servers > can make use of the significantly increased mbuf limits with a much > larger number of open sockets. > > MFC r243639 (andre): > > Complete r243631 by applying the remainder of kern_mbuf.c that got > lost while merging into the commit tree. > > MFC r243668 (andre): > > Using a long is the wrong type to represent the realmem and maxmbufmem > variable as they may overflow on i386/PAE and i386 with > 2GB RAM. > > MFC r243995, r243996, r243997 (pjd): > > Style cleanups, Make use of the fact that uma_zone_set_max(9) already > returns actual limit set. > > MFC r244080 (andre): > > Prevent long type overflow of realmem calculation on ILP32 by forcing > calculation to be in quad_t space. Fix style issue with second parameter > to qmin(). > > MFC r245469 (alfred): > > Do not autotune ncallout to be greater than 18508. > > MFC r245575 (andre): > > Move the mbuf memory limit calculations from init_param2() to > tunable_mbinit() where it is next to where it is used later. > > MFC r246207 (andre): > > Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. > > MFC r249843 (andre): > > Base the calculation of maxmbufmem in part on kmem_map size > instead of kernel_map size to prevent kernel memory exhaustion > by mbufs and a subsequent panic on physical page allocation > failure. > > > would it be safe to throw a couple of high end storage systems into this testing pool ?? each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they are design to do it samba and nfs and ive been fighting performance with samba and nfs on these systems, Id be curious if autotuning might help, to be honest, theres so much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has it running efficiently. > -- > Andre > > > ______________________________**_________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@**freebsd.org > " > From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 14:51:53 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66A77B8 for ; Mon, 8 Jul 2013 14:51:53 +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 DDF1516B3 for ; Mon, 8 Jul 2013 14:51:52 +0000 (UTC) Received: (qmail 62760 invoked from network); 8 Jul 2013 15:42:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 15:42:58 -0000 Message-ID: <51DAD207.3090008@freebsd.org> Date: Mon, 08 Jul 2013 16:51:51 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Outback Dingo Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:51:53 -0000 On 08.07.2013 16:41, Outback Dingo wrote: > > > > On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann > wrote: > > On 07.07.2013 20:24, Alfred Perlstein wrote: > > On 7/7/13 1:34 AM, Andre Oppermann wrote: > > Can you help me with with testing? > > Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. > > > http://people.freebsd.org/~__andre/mfc-autotuning-20130708.__diff > > > This is functional bundle MFC of these original commits: > > MFC r242029 (alfred): > > Allow autotune maxusers > 384 on 64 bit machines. > > MFC r242847 (alfred): > > Allow maxusers to scale on machines with large address space. > > MFC r243631 (andre): > > Base the mbuf related limits on the available physical memory or > kernel memory, whichever is lower. The overall mbuf related memory > limit must be set so that mbufs (and clusters of various sizes) > can't exhaust physical RAM or KVM. > > At the same time divorce maxfiles from maxusers and set maxfiles to > physpages / 8 with a floor based on maxusers. This way busy servers > can make use of the significantly increased mbuf limits with a much > larger number of open sockets. > > MFC r243639 (andre): > > Complete r243631 by applying the remainder of kern_mbuf.c that got > lost while merging into the commit tree. > > MFC r243668 (andre): > > Using a long is the wrong type to represent the realmem and maxmbufmem > variable as they may overflow on i386/PAE and i386 with > 2GB RAM. > > MFC r243995, r243996, r243997 (pjd): > > Style cleanups, Make use of the fact that uma_zone_set_max(9) already > returns actual limit set. > > MFC r244080 (andre): > > Prevent long type overflow of realmem calculation on ILP32 by forcing > calculation to be in quad_t space. Fix style issue with second parameter > to qmin(). > > MFC r245469 (alfred): > > Do not autotune ncallout to be greater than 18508. > > MFC r245575 (andre): > > Move the mbuf memory limit calculations from init_param2() to > tunable_mbinit() where it is next to where it is used later. > > MFC r246207 (andre): > > Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. > > MFC r249843 (andre): > > Base the calculation of maxmbufmem in part on kmem_map size > instead of kernel_map size to prevent kernel memory exhaustion > by mbufs and a subsequent panic on physical page allocation > failure. > > > > would it be safe to throw a couple of high end storage systems into this testing pool ?? > each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they > are design to do it samba and nfs and ive been fighting performance with samba and > nfs on these systems, Id be curious if autotuning might help, to be honest, theres so > much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has > it running efficiently. I don't know enough about the limits of Samba setups. Testing this MFC may or may not significantly improve the performance, though at least we'll know that it doesn't hurt. -- Andre From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 18:09:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07FED92E; Mon, 8 Jul 2013 18:09:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 99A071F9F; Mon, 8 Jul 2013 18:09:21 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id o13so5837972qaj.3 for ; Mon, 08 Jul 2013 11:09:20 -0700 (PDT) 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=yJydbRwd6PxXwUMlvhN411HLag+l4AamyHGFS8x77c8=; b=FBJsw8DVFVFNWO3SIKSPj9+kO7yrOXZcBM7GlrgM8ag0F18ScN8wIKEWygsFhm3pWH zX6OWoBAkXsNOxZ2r7qrIJUOBmt5APWGlPSbRMkUjv5EyB1b6vqtjQ5kH5fJhiWnw8xG KiJtT05lUQqgOU9lJTsZhF2trDPOt8u9XCtvLM7vcih4rebQexIqMshET2AB69RJzQGl Y1wuF7HyKZgPjaE+N1K1n64Gy1F2bUkCV9yJPBEDxTO5FGTcMHDeTygxHlvBTtu+nELe 5ZSiXFP+iE2blVSPVGtLvdm74RQRSHvAH0ZJhX/0UoTpvJLZJr+qjTTyqP72G2iRmbf0 3O/g== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr17422401qeb.8.1373306960685; Mon, 08 Jul 2013 11:09:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Mon, 8 Jul 2013 11:09:20 -0700 (PDT) In-Reply-To: <20130708140804.R26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> Date: Mon, 8 Jul 2013 11:09:20 -0700 X-Google-Sender-Auth: S_B-uP8VnjrSV5MDjKn5BderDAI Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Lars Engels , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:09:22 -0000 On 7 July 2013 22:00, Ian Smith wrote: > Checking one more point .. do the USB ports come up ok if you originally > boot with nothing plugged in? If so (or if not), does that local APIC Yes. > error message appear the same then too? > No -adrian From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 21:26:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FDBD70B; Mon, 8 Jul 2013 21:26:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2361A0F; Mon, 8 Jul 2013 21:26:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E2F3B93B; Mon, 8 Jul 2013 17:26:07 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Date: Mon, 8 Jul 2013 14:19:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130630233640.Y23789@sola.nimnet.asn.au> In-Reply-To: <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201307081419.42478.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 08 Jul 2013 17:26:07 -0400 (EDT) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:26:08 -0000 On Sunday, June 30, 2013 10:22:09 am Ian Smith wrote: > On Sat, 29 Jun 2013, Adrian Chadd wrote: > > On 27 June 2013 04:58, Ian Smith wrote: > > > We don't yet know if this is a bus, ACPI &/or USB issue. Home yet? = :) > >=20 > > Yup: > >=20 > > http://people.freebsd.org/~adrian/usb/ > >=20 > > dmesg.boot =3D dmesg at startup > >=20 > > 1 - after powerup, usb device in > > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in > > 3 - after acpiconf -s3 suspend/resume, with a USB device removed > > before suspend/resume >=20 > After removing [numbers] (for WITNESS?), diff started making sense. =20 > The below is between the first and second suspend/resume cycles in=20 > dmesg-3.txt, encompassing the others. >=20 > Nothing of note that I can see, if that usb hub-to-bus remapping is=20 > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. =20 > Maybe someone who knows might comment on that? =46rom sys/amd64/include/apicreg.h: /* fields in ESR */ #define APIC_ESR_SEND_CS_ERROR 0x00000001 #define APIC_ESR_RECEIVE_CS_ERROR 0x00000002 #define APIC_ESR_SEND_ACCEPT 0x00000004 #define APIC_ESR_RECEIVE_ACCEPT 0x00000008 #define APIC_ESR_SEND_ILLEGAL_VECTOR 0x00000020 #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x00000040 #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 Receive illegal vector (if look in Intel's SDM manuals) means it got an interrupt vector < 32 (probably zero). Perhaps it asserted an interrupt in an I/O APIC before the I/O APIC was properly reset? Are you using MSI at all? =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 23:09:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8784416F; Mon, 8 Jul 2013 23:09:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 180581E28; Mon, 8 Jul 2013 23:09:25 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id 1so2673118qec.34 for ; Mon, 08 Jul 2013 16:09:24 -0700 (PDT) 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=BqHtD6EqVhfBpO+713df/dtZ4aqhj/S+USiMeHrxnrI=; b=cMwQGgHOSFtLDV3B1dqvaMeYZxP/gp1zEcqA7rIDrhJoUFAGtSvq8FmLVRiSn/P7mo GXEbvi9He1PSMrmMyujClO0AkRFmtN0L4NGw2n9tdTeAeJxJDglN81VXC46d9vML6z+y Y2maTZLpezR3u2i7uwsIsSOmrmPXjB6uYdnrdfqs62fl6kFuLxWz9V1Bbq0dKOEpzlyo tOO4ptg9eHtQ84+iIOFm9DkUvkHnqHf8/Pb78VRmlQnsmf0e0b9FAFdwJpAU+8h6xxpu KiQLDws7hQonSvpQERReJ50dGkjBt1V4w7eaGpk536x3udtPpZrQhoIoZHAyDDNQMnbu lOGg== MIME-Version: 1.0 X-Received: by 10.49.58.70 with SMTP id o6mr17799524qeq.1.1373324964711; Mon, 08 Jul 2013 16:09:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Mon, 8 Jul 2013 16:09:24 -0700 (PDT) In-Reply-To: <201307081419.42478.jhb@freebsd.org> References: <20130630233640.Y23789@sola.nimnet.asn.au> <201307081419.42478.jhb@freebsd.org> Date: Mon, 8 Jul 2013 16:09:24 -0700 X-Google-Sender-Auth: QP0zCszBEe4Geh31Xtl5La1WT_I Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:09:25 -0000 On 8 July 2013 11:19, John Baldwin wrote: > From sys/amd64/include/apicreg.h: This system runs an i386 kernel. > /* fields in ESR */ > #define APIC_ESR_SEND_CS_ERROR 0x00000001 > #define APIC_ESR_RECEIVE_CS_ERROR 0x00000002 > #define APIC_ESR_SEND_ACCEPT 0x00000004 > #define APIC_ESR_RECEIVE_ACCEPT 0x00000008 > #define APIC_ESR_SEND_ILLEGAL_VECTOR 0x00000020 > #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x00000040 > #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 > > Receive illegal vector (if look in Intel's SDM manuals) means it > got an interrupt vector < 32 (probably zero). Perhaps it asserted > an interrupt in an I/O APIC before the I/O APIC was properly reset? > Are you using MSI at all? I think iwn uses MSI. I'm sure other hardware in here does. I can dig through it and let you know. -adrian From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 08:24:15 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BAFD14A9; Tue, 9 Jul 2013 08:24:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACF21FB9; Tue, 9 Jul 2013 08:24:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r698O79j002244; Tue, 9 Jul 2013 12:24:07 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 9 Jul 2013 12:24:07 +0400 (MSK) From: Dmitry Morozovsky To: mav@FreeBSD.org Subject: Marvell 88SE91Ax simple patch Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 09 Jul 2013 12:24:07 +0400 (MSK) Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:24:15 -0000 Alexander, trying to activate eSATA port on my home file server I found that the following simple patch seems to work -- could you please add it, hopefully before 9.2-R? [excerpt from dmidecode]: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P8P67 LE [excerpt from pciconf (after applying the patch below)]: ahci0@pci0:8:0:0: class=0x01018f card=0x83ba1043 chip=0x91a01b4b rev=0x12 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88SE91A0 SATA 6Gb/s Controller' class = mass storage subclass = ATA none3@pci0:8:0:1: class=0x01018f card=0x91a41b4b chip=0x91a41b4b rev=0x12 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88SE91A4 SATA 6Gb/s Controller' class = mass storage subclass = ATA marck@hamster:/sys> svn diff dev/ahci Index: dev/ahci/ahci.c =================================================================== --- dev/ahci/ahci.c (revision 252889) +++ dev/ahci/ahci.c (working copy) @@ -234,6 +234,7 @@ {0x91301b4b, 0x00, "Marvell 88SE9130", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, {0x91721b4b, 0x00, "Marvell 88SE9172", AHCI_Q_NOBSYRES}, {0x91821b4b, 0x00, "Marvell 88SE9182", AHCI_Q_NOBSYRES}, + {0x91a01b4b, 0x00, "Marvell 88SE91Ax", AHCI_Q_NOBSYRES}, {0x92201b4b, 0x00, "Marvell 88SE9220", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, {0x92301b4b, 0x00, "Marvell 88SE9230", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, {0x92351b4b, 0x00, "Marvell 88SE9235", AHCI_Q_NOBSYRES}, -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 08:34:25 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6CA4B58 for ; Tue, 9 Jul 2013 08:34:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 703B5106A for ; Tue, 9 Jul 2013 08:34:25 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id fr10so4594089lab.18 for ; Tue, 09 Jul 2013 01:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K2K61eI4zeZflYxRfaqJ7PaUVH0vwqmJ2+UFg0oAfVc=; b=Sps4izGJUDFKXp40A3Ucy0vY3HnHx7XKXKIEvsp5lSHYeP+OeBcvvZil42Swvufd2E T/wFp2krRrETqe51csqel81YQ6dXcyns/rOd+j3uAfNE2rn3/I4mBkO0e5ZdlTm2BIw9 lbHLs+gZsCZAJm+2nAFUvf59ZUwhSq3BnvWJpEpJ/Aj+5cP7aUE2Mk5ALvkQcbs2qwKW ssZpPIfh2CbEzlCJsqux3KcVOAARzWtPe1vnoDXu+fCJvISYbc8NRAcuMqAuwQzJm9a2 pVa4LBufECiulrQnRgGks1OkyA3kwB0MPOO22DMcHoCHMY314A7As9/p8oMYir373wgp B6LQ== X-Received: by 10.112.198.10 with SMTP id iy10mr12314098lbc.38.1373358864333; Tue, 09 Jul 2013 01:34:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id x8sm8865461lae.10.2013.07.09.01.34.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 01:34:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <51DBCB0C.1060503@FreeBSD.org> Date: Tue, 09 Jul 2013 11:34:20 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dmitry Morozovsky Subject: Re: Marvell 88SE91Ax simple patch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 08:34:26 -0000 On 09.07.2013 11:24, Dmitry Morozovsky wrote: > Alexander, > > trying to activate eSATA port on my home file server I found that the following > simple patch seems to work -- could you please add it, hopefully before 9.2-R? > > marck@hamster:/sys> svn diff dev/ahci > Index: dev/ahci/ahci.c > =================================================================== > --- dev/ahci/ahci.c (revision 252889) > +++ dev/ahci/ahci.c (working copy) > @@ -234,6 +234,7 @@ > {0x91301b4b, 0x00, "Marvell 88SE9130", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, > {0x91721b4b, 0x00, "Marvell 88SE9172", AHCI_Q_NOBSYRES}, > {0x91821b4b, 0x00, "Marvell 88SE9182", AHCI_Q_NOBSYRES}, > + {0x91a01b4b, 0x00, "Marvell 88SE91Ax", AHCI_Q_NOBSYRES}, > {0x92201b4b, 0x00, "Marvell 88SE9220", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, > {0x92301b4b, 0x00, "Marvell 88SE9230", AHCI_Q_NOBSYRES|AHCI_Q_ALTSIG}, > {0x92351b4b, 0x00, "Marvell 88SE9235", AHCI_Q_NOBSYRES}, Committed to HEAD. Thanks. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 09:18:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4AC5E748; Tue, 9 Jul 2013 09:18:54 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 1E24612A3; Tue, 9 Jul 2013 09:18:53 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r699Ig1V067198; Tue, 9 Jul 2013 02:18:48 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r699IbPG067197; Tue, 9 Jul 2013 02:18:37 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 9 Jul 2013 02:18:37 -0700 (PDT) Message-ID: Date: Tue, 9 Jul 2013 02:18:37 -0700 (PDT) Subject: perl upgrade woes -- how to best reconcile? From: "Chris H" To: "freebsd-stable" , "svn-src-stable-8" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 09:18:54 -0000 Greetings, As my upgrade also required the change to subversion, it's been quite a challenge. I've nearly sorted out all the loose ends. But have a real issue with the path change for Perl. Yes, I've read UPDATING. For the most part, I upgraded all the ports via portmaster(8). But apparently that doesn't get it. While Perl seems to work, I receive a few errors, and have nearly no access to the (info|man)pages. An example error: perlinfo Date::Manip::Offset Subroutine path redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 29. Subroutine canonical_path redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 33. Subroutine perl_version redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 42. Subroutine perl_arch redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 47. Subroutine builds_port redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 51. Subroutine builds_standalone redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 66. How do I best sort this all out. I _really_ miss the perl_after_upgrade script, that used to accompany this process. Thank you for all your time, and consideration. --chris From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 09:32:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BB89EE0 for ; Tue, 9 Jul 2013 09:32:39 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDD51381 for ; Tue, 9 Jul 2013 09:32:39 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id o6so7740012oag.27 for ; Tue, 09 Jul 2013 02:32:39 -0700 (PDT) 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=XGC0sFSf5pYJbTzeJsAlW9SU6bluvC9w5VRRKCYdEWA=; b=GWRUZxHhIWi65yAP+B7IoXTfv1/lN5KoJx7LWg+3ERX+dB4iZbMysp4qbJb+hxMnWB dzev2o4VV2+Jr2fSxPbdxA5MXaFy81O7gxIKCVeQkOc/Pw0bRXuO0Ibe+22SzbB8YXk6 LEFiiHCJjdxzD+7BRe+rauoIQNC/flWnbQGJZfgyZiRaT2cjmn6ZYTs7gIgzrTzPNHoC LDBB4JXBXzY6pKNg0nkmXhysSy39qfbBETwGMowBLrfLwoVMIMku3ZkIIp6P3i5ZbVv/ oPrIJpuSrFLevcul33pcUPTXF1VFIXa/H1s1URUr2aptBIBqJt1xE3BFOjM+9GTlpBcC 8B+A== MIME-Version: 1.0 X-Received: by 10.60.146.134 with SMTP id tc6mr23080239oeb.95.1373362359091; Tue, 09 Jul 2013 02:32:39 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 02:32:39 -0700 (PDT) Date: Tue, 9 Jul 2013 05:32:39 -0400 Message-ID: Subject: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 09:32:39 -0000 as of stable today im seeing alot of new mps time outs 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC 2013 root@:/usr/obj/nas/usr/src/sys/ mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm 0xffffff80021a6b78 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID 983 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm 0xffffff80023e5b78 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID 983 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 09:37:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38347325 for ; Tue, 9 Jul 2013 09:37:52 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03b.sare.net (proxypop03b.sare.net [194.30.0.251]) by mx1.freebsd.org (Postfix) with ESMTP id 01C391456 for ; Tue, 9 Jul 2013 09:37:51 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 219B79DC6A2 for ; Tue, 9 Jul 2013 11:32:19 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: OCZ Vertex4 quirks Date: Tue, 9 Jul 2013 11:32:18 +0200 Message-Id: <2027F7EA-D5C0-4C72-AB29-74FC02B8AF74@sarenet.es> To: Stable Stable Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 09:37:52 -0000 Same as its brothers/sisters, it's optimized for 4 KB blocks. /* * OCZ Vertex 4 SSDs * 4k optimized */ { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ_VERTEX4*", "*"}, /*quirks/DA_Q_4K Borja. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 10:34:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9220B63C for ; Tue, 9 Jul 2013 10:34:29 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 5956F17F4 for ; Tue, 9 Jul 2013 10:34:28 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 7D8CB9DC6CC for ; Tue, 9 Jul 2013 12:34:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: OCZ Vertex4 quirks From: Borja Marcos In-Reply-To: <2027F7EA-D5C0-4C72-AB29-74FC02B8AF74@sarenet.es> Date: Tue, 9 Jul 2013 12:34:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <2027F7EA-D5C0-4C72-AB29-74FC02B8AF74@sarenet.es> To: Stable Stable X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:34:29 -0000 On Jul 9, 2013, at 11:32 AM, Borja Marcos wrote: > { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ_VERTEX4*", "*"}, Correction: I used an underscore by mistake. OCZ-VERTEX4 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 10:45:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E105D99E for ; Tue, 9 Jul 2013 10:45:46 +0000 (UTC) (envelope-from prvs=1902e20835=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 872901857 for ; Tue, 9 Jul 2013 10:45:46 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004862601.msg for ; Tue, 09 Jul 2013 11:45:39 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 09 Jul 2013 11:45:39 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1902e20835=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <38ECD628146842C3A6CCEDB066132FD1@multiplay.co.uk> From: "Steven Hartland" To: "Borja Marcos" , "Stable Stable" References: <2027F7EA-D5C0-4C72-AB29-74FC02B8AF74@sarenet.es> Subject: Re: OCZ Vertex4 quirks Date: Tue, 9 Jul 2013 11:45:51 +0100 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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:45:46 -0000 ----- Original Message ----- From: "Borja Marcos" > Same as its brothers/sisters, it's optimized for 4 KB blocks. > > /* > * OCZ Vertex 4 SSDs > * 4k optimized > */ > { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ_VERTEX4*", "*"}, > /*quirks/DA_Q_4K Thanks Borja committed under:- http://svnweb.freebsd.org/changeset/base/253091 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-stable@FreeBSD.ORG Tue Jul 9 10:53:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 71F5DAFA for ; Tue, 9 Jul 2013 10:53:23 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03BBE189E for ; Tue, 9 Jul 2013 10:53:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r69ArKKV090515 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Jul 2013 12:53:20 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <51DBEB9F.7020803@wenks.ch> Date: Tue, 09 Jul 2013 12:53:19 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: perl upgrade woes -- how to best reconcile? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:53:23 -0000 Hello Chris On 09.07.2013 11:18, Chris H wrote: > How do I best sort this all out. I _really_ miss the perl_after_upgrade script, that > used to accompany this process. I also had some challenges with this perl upgrade, but I used portupgrade. In the end I created a custom script based on the output from 'portupgrade -nrf perl' which did the following: #!/usr/local/bin/bash set -e portupgrade -f lang/perl5.12 portupgrade -f converters/p5-MIME-Base64 portupgrade -f devel/p5-Test-Harness portupgrade -f devel/p5-Locale-Maketext-Simple [...] This script does abort, when a single command fails, so you see what fails and you can fix it. Eventually you will need to check dependencies and rebuild one of the ports now, which is later in the script. When the failed port did build, then remove the already done ports from the script and restart it. At the end I also did check the folders in /usr/local/lib/perl5/ for left overs in the folders from the old perl version. I then used pkg_which to find out to which port the belongs and did also a portupgrade -f for this port too. In the end everything was fine, but it took a little more effort, as I had around 235 ports to rebuild. But as long as you stay with e.g. perl 5.12.x, it is easier then before with the perl_after_upgrade script for minor updates. The next big challenge then will be the upgrade to e.g. 5.14.x or 5.16.x. bye Fabian From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 10:54:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59D97BFB for ; Tue, 9 Jul 2013 10:54:21 +0000 (UTC) (envelope-from prvs=1902e20835=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 F2BF618B4 for ; Tue, 9 Jul 2013 10:54:20 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004862976.msg for ; Tue, 09 Jul 2013 11:54:17 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 09 Jul 2013 11:54:17 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1902e20835=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <5FEC27C8C0EA4D66A4BF9288566F0A4C@multiplay.co.uk> From: "Steven Hartland" To: "Borja Marcos" , "Stable Stable" References: <2027F7EA-D5C0-4C72-AB29-74FC02B8AF74@sarenet.es> Subject: Re: OCZ Vertex4 quirks Date: Tue, 9 Jul 2013 11:54:34 +0100 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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:54:21 -0000 ----- Original Message ----- From: "Borja Marcos" > On Jul 9, 2013, at 11:32 AM, Borja Marcos wrote: > >> { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "OCZ_VERTEX4*", "*"}, > > Correction: I used an underscore by mistake. > > OCZ-VERTEX4 I guessed as much given the Vertex 3 details, so commit should work ;-) 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-stable@FreeBSD.ORG Tue Jul 9 11:57:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3117FFE; Tue, 9 Jul 2013 11:57:58 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9661C1B1C; Tue, 9 Jul 2013 11:57:58 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2116E2084E; Tue, 9 Jul 2013 07:57:58 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 09 Jul 2013 07:57:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=ri7njp94sW0h629TJcLKoMCb26Q=; b=mgdrt+VL0HV5MKXDqGVV/ x9Lu5+DF2H47RxkZIux5G2O1Qk1wwI6hCYj20k/lZFx3OY0TGUGUpOrysjgzTVHz 0EmNnGG5G3S8uJszt50F+0cLuupEKQQ4uq1Bv6CXB7qgz3+C4eXsfx/O05cGeE1C TUSOKeMjvPLc1oW7hp/bJA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=ri7njp94sW0h629TJcLKoMCb26Q=; b=NUS5 zgolJXviS5wc++zEyT3p1aI91JeY52bpPgiqJyEayMyyedivrU7plD+B8lzJZdE0 0+UwMFHpNb/4s/fSKQotxn6CgM6Tm5gvJ8wbvs0SfoPXyk9g7JqsX5wXhWN342sK MG5tRzdyds7N526hBVQY7rt1YT0U79xFmM11VrA= X-Sasl-enc: 0TnlxEr1SLem33eOgzxuxhholiPyzMVJquhxAjnTY1cH 1373371077 Received: from markf.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id D0A6BC00E7F; Tue, 9 Jul 2013 07:57:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable , svn-src-stable-8 , "Chris H" Subject: Re: perl upgrade woes -- how to best reconcile? References: Date: Tue, 09 Jul 2013 06:57:57 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 11:57:58 -0000 On Tue, 09 Jul 2013 04:18:37 -0500, Chris H wrote: > How do I best sort this all out. I _really_ miss the perl_after_upgrade > script, that > used to accompany this process. I've had zero problems with upgrades to Perl, etc after I stopped compiling my packages in the host OS and started building the packages via poudriere and using pkgng (sysutils/pkg). pkg can detect when a perl upgrade is happening and is intelligent enough to reinstall all programs that require perl; poudriere is smart enough to rebuild and repackage them all. It's a match made in heaven and dead simple to use. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 12:39:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AE1D445 for ; Tue, 9 Jul 2013 12:39:16 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id A5E671D63 for ; Tue, 9 Jul 2013 12:39:15 +0000 (UTC) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id E424641C075; Tue, 9 Jul 2013 14:39:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id VCEEWJN4ZYYR; Tue, 9 Jul 2013 14:39:02 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1AD0F41C07E; Tue, 9 Jul 2013 14:39:02 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 3C3FB73A31; Tue, 9 Jul 2013 05:39:00 -0700 (PDT) Date: Tue, 9 Jul 2013 05:39:00 -0700 From: Jeremy Chadwick To: Outback Dingo Subject: Re: Stable/9 from today mpssas_scsiio timeouts Message-ID: <20130709123900.GA5828@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 12:39:16 -0000 On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > as of stable today im seeing alot of new mps time outs > > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC 2013 > root@:/usr/obj/nas/usr/src/sys/ > > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 > rev=0x03 hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > class = mass storage > subclass = SAS > > > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > 0xffffff80021a6b78 > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > mps0: mpssas_alloc_tm freezing simq > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 during > recovery ioc 8048 scsi 0 state c xfer 0 > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 count > 1 > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID 983 > mps0: mpssas_free_tm releasing simq > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe40:mps0:0:40:0): CAM status: Command timeout > (probe40:mps0:0:40:0): Retrying command > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > 0xffffff80023e5b78 > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > mps1: mpssas_alloc_tm freezing simq > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 during > recovery ioc 8048 scsi 0 state c xfer 0 > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 count > 1 > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID 983 > mps1: mpssas_free_tm releasing simq > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > (probe292:mps1:0:37:0): CAM status: Command timeout > (probe292:mps1:0:37:0): Retrying command 1. What revision were you running before (i.e. what were you on prior to the upgrade)? 2. Something in your /usr/src differs from stock r253035, hence the "M" at the end. What is it? Answer to #1 will help me narrow down the commits; there have been CAM and mps changes fairly recently. Otherwise you can dig through the commits yourself (you'll need to go through many, many pages, as there was a recent massive influx of SCTP changes (50+ commits)): http://www.freshbsd.org/?branch=RELENG_9&project=freebsd -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 13:44:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 404FE15C for ; Tue, 9 Jul 2013 13:44:42 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1042810D3 for ; Tue, 9 Jul 2013 13:44:42 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id o6so7837296oag.41 for ; Tue, 09 Jul 2013 06:44:41 -0700 (PDT) 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=b/q/RZV5ptkqYeTCfRlqEQLnNqj3DO/Y0k8BR4OkpiA=; b=GDRLoPNOYlQw0L5avia/72xp1/PDONwp/UWoeXwNwsnVbSr5/NiL8j/nra+q1fgyQs NBjMBvxHs/EB0p/K4BbX3Vzi3uAiK1Y/b7v1TKHFUf3f/HZgJv8FBqontJp5wepDuydE NUg5rfyz5sCXQvr3MvJxDSytuMtVX5ADyzs+uD5snH+HQsVp6tWMboAWae6TvsOZ91ZA M0lm42hh/OpLr9Ok+ZijUH0KagPMo3BP1Sycf0BQWG2bySxfkCswyYcwr8783EPjU8H7 ejqlaHG84YEUAg/g+woyJTwJSB+zSfO9uDG9UamUou+xPeYqKTMXN6DUdgb5O9Tyejvz kDOw== MIME-Version: 1.0 X-Received: by 10.60.102.41 with SMTP id fl9mr24319809oeb.37.1373377481650; Tue, 09 Jul 2013 06:44:41 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 06:44:41 -0700 (PDT) In-Reply-To: <20130709123900.GA5828@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> Date: Tue, 9 Jul 2013 09:44:41 -0400 Message-ID: Subject: Re: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:44:42 -0000 On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick wrote: > On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > as of stable today im seeing alot of new mps time outs > > > > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC 2013 > > root@:/usr/obj/nas/usr/src/sys/ > > > > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 > > rev=0x03 hdr=0x00 > > vendor = 'LSI Logic / Symbios Logic' > > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > class = mass storage > > subclass = SAS > > > > > > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > 0xffffff80021a6b78 > > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > mps0: mpssas_alloc_tm freezing simq > > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 983 > > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 during > > recovery ioc 8048 scsi 0 state c xfer 0 > > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 > count > > 1 > > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID > 983 > > mps0: mpssas_free_tm releasing simq > > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe40:mps0:0:40:0): CAM status: Command timeout > > (probe40:mps0:0:40:0): Retrying command > > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > 0xffffff80023e5b78 > > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > 983 > > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > mps1: mpssas_alloc_tm freezing simq > > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > 983 > > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 during > > recovery ioc 8048 scsi 0 state c xfer 0 > > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 > count > > 1 > > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID > 983 > > mps1: mpssas_free_tm releasing simq > > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe292:mps1:0:37:0): CAM status: Command timeout > > (probe292:mps1:0:37:0): Retrying command > > 1. What revision were you running before (i.e. what were you on prior to > the upgrade)? > i was on 253035 > > 2. Something in your /usr/src differs from stock r253035, hence the "M" > at the end. What is it? > > a KERNEL configuration > Answer to #1 will help me narrow down the commits; there have been CAM > and mps changes fairly recently. Otherwise you can dig through the > commits yourself (you'll need to go through many, many pages, as there > was a recent massive influx of SCTP changes (50+ commits)): > > http://www.freshbsd.org/?branch=RELENG_9&project=freebsd > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 13:47:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47A24299 for ; Tue, 9 Jul 2013 13:47:02 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1638F1105 for ; Tue, 9 Jul 2013 13:47:02 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j6so7997885oag.1 for ; Tue, 09 Jul 2013 06:47:01 -0700 (PDT) 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=wce1OWvS7QBftzdvtiU4zIHv6Ezj87Qo2cpt3SN3Ri8=; b=xK+RaDTdUpj6lLMkZRH0rzdpjDxrOvuoJsIuTDXM4JdUscIcQWn9K9xakfItb0Bt2X FdYT4bzZov0pi7fXoJK0yjUOKxCHKjczzdHK9JwfAipT4sF8Dc0b72ZMiUR9dgOOphho 1CBLzaXizyfdREcyh9X2/RfnSrDSioeeFUQiKbHlSGE/PI8+s3g+yh2pJofmqppCnD8d 0Kz8W4E7MT7sPFwgOC/hNbdzUZT7Ui0DDYhex99xKrsDeggOQL42kQmCtoLewYLlf2G8 m078hMg+WfzUVZamUjtDI/Z+lPswNYTmKoQfYDzuG5mSFT0uhi4cxRI3NXWtf0ZgSKr0 FMfA== MIME-Version: 1.0 X-Received: by 10.182.24.131 with SMTP id u3mr24280742obf.29.1373377621496; Tue, 09 Jul 2013 06:47:01 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 06:47:01 -0700 (PDT) In-Reply-To: References: <20130709123900.GA5828@icarus.home.lan> Date: Tue, 9 Jul 2013 09:47:01 -0400 Message-ID: Subject: Re: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:47:02 -0000 On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo wrote: > > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick wrote: > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: >> > as of stable today im seeing alot of new mps time outs >> > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC 2013 >> > root@:/usr/obj/nas/usr/src/sys/ >> > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 >> > rev=0x03 hdr=0x00 >> > vendor = 'LSI Logic / Symbios Logic' >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' >> > class = mass storage >> > subclass = SAS >> > >> > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm >> > 0xffffff80021a6b78 >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID >> 983 >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 >> > mps0: mpssas_alloc_tm freezing simq >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID >> 983 >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 during >> > recovery ioc 8048 scsi 0 state c xfer 0 >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 >> count >> > 1 >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID >> 983 >> > mps0: mpssas_free_tm releasing simq >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 >> > (probe40:mps0:0:40:0): CAM status: Command timeout >> > (probe40:mps0:0:40:0): Retrying command >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm >> > 0xffffff80023e5b78 >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID >> 983 >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 >> > mps1: mpssas_alloc_tm freezing simq >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID >> 983 >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 during >> > recovery ioc 8048 scsi 0 state c xfer 0 >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 >> count >> > 1 >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID >> 983 >> > mps1: mpssas_free_tm releasing simq >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 >> > (probe292:mps1:0:37:0): CAM status: Command timeout >> > (probe292:mps1:0:37:0): Retrying command >> >> 1. What revision were you running before (i.e. what were you on prior to >> the upgrade)? >> > > > Sorry I was on 252595 from July 3 > > >> >> 2. Something in your /usr/src differs from stock r253035, hence the "M" >> at the end. What is it? >> >> a KERNEL configuration > > > >> Answer to #1 will help me narrow down the commits; there have been CAM >> and mps changes fairly recently. Otherwise you can dig through the >> commits yourself (you'll need to go through many, many pages, as there >> was a recent massive influx of SCTP changes (50+ commits)): >> >> http://www.freshbsd.org/?branch=RELENG_9&project=freebsd >> >> -- >> | Jeremy Chadwick jdc@koitsu.org | >> | UNIX Systems Administrator http://jdc.koitsu.org/ | >> | Making life hard for others since 1977. PGP 4BD6C0CB | >> >> > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 14:05:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A7F1679 for ; Tue, 9 Jul 2013 14:05:37 +0000 (UTC) (envelope-from dcbsdx@hotmail.com) Received: from bay0-omc2-s17.bay0.hotmail.com (bay0-omc2-s17.bay0.hotmail.com [65.54.190.92]) by mx1.freebsd.org (Postfix) with ESMTP id 59F2911D3 for ; Tue, 9 Jul 2013 14:05:37 +0000 (UTC) Received: from BAY169-W135 ([65.54.190.123]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Jul 2013 07:05:30 -0700 X-TMN: [XOdRY/CbcpTtaYrF1OQxu4a/pPcdrSTQ] X-Originating-Email: [dcbsdx@hotmail.com] Message-ID: From: dcx dcy To: "freebsd-stable@freebsd.org" Subject: hme0 interface going up/down (dhclient ?) Date: Tue, 9 Jul 2013 14:05:30 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2013 14:05:30.0762 (UTC) FILETIME=[5F22B6A0:01CE7CAD] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:05:37 -0000 Hi all=2C=20 I am having an issue where my hme0 interface is always turning up = and down with dhclient requesting a lease. =20 I am thinking this could be the same issue described by Jeremy Chadwick on = June 9th: http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073711.html =20 Everything was fine on 8.2-STABLE and older versions. =20 =20 It was then upgraded directly to 9.0-STABLE and this is where I started hav= ing issues=AD. =20 I am currently running 9.1-STABLE (July 7th) and issue persists. =20 This is a Sun Netra T1 acting as my home gateway=2C hme0 is connected to a = Cisco switch.=20 I am normally using DHCP to get an ip from my ISP. =20 =20 For now=2C the only way it works is to set a static ip (I tried different = dhclient options ... sync=2C etc). =20 hme1 and ath0 (AR5413) is serving internal network. =20 Thank you. =20 Dominic. =20 =20 = From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 14:46:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0774410 for ; Tue, 9 Jul 2013 14:46:31 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9220C13C3 for ; Tue, 9 Jul 2013 14:46:31 +0000 (UTC) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 8012B172055; Tue, 9 Jul 2013 16:46:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id U37MKBwl4YZl; Tue, 9 Jul 2013 16:46:16 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 7ABB917209F; Tue, 9 Jul 2013 16:46:16 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id A6B6073A31; Tue, 9 Jul 2013 07:46:14 -0700 (PDT) Date: Tue, 9 Jul 2013 07:46:14 -0700 From: Jeremy Chadwick To: Outback Dingo Subject: Re: Stable/9 from today mpssas_scsiio timeouts Message-ID: <20130709144614.GA7538@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:46:32 -0000 On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo wrote: > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick wrote: > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > >> > as of stable today im seeing alot of new mps time outs > >> > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC 2013 > >> > root@:/usr/obj/nas/usr/src/sys/ > >> > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 > >> > rev=0x03 hdr=0x00 > >> > vendor = 'LSI Logic / Symbios Logic' > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > >> > class = mass storage > >> > subclass = SAS > >> > > >> > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > >> > 0xffffff80021a6b78 > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > >> 983 > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > >> > mps0: mpssas_alloc_tm freezing simq > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > >> 983 > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 during > >> > recovery ioc 8048 scsi 0 state c xfer 0 > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 > >> count > >> > 1 > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID > >> 983 > >> > mps0: mpssas_free_tm releasing simq > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > >> > (probe40:mps0:0:40:0): Retrying command > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > >> > 0xffffff80023e5b78 > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > >> 983 > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > >> > mps1: mpssas_alloc_tm freezing simq > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID > >> 983 > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 during > >> > recovery ioc 8048 scsi 0 state c xfer 0 > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code 0x0 > >> count > >> > 1 > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID > >> 983 > >> > mps1: mpssas_free_tm releasing simq > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > >> > (probe292:mps1:0:37:0): Retrying command > >> > >> 1. What revision were you running before (i.e. what were you on prior to > >> the upgrade)? > >> > > > > > > Sorry I was on 252595 from July 3 And does rolling back to r252595 resolve the problem for you? Because the only commit I see between r253035 and r252595 that might account for some kind of behavioural change, unless I missed one while skimming the commit history, is the following: r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 If at all possible, please try updating to r253037 or newer to see if that has some effect/improvement. Why I mention that commit: r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 Because the only mps(4) changes done in recent days are: http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log r253037 r251899 r251874 Else I'd say what you're experiencing is legitimate/unrelated to kernel changes. I can only speculate. The messages to me indicate that some part of the kernel is submitting a SCSI INQUIRY request to the underlying device(s) which results in a CAM timeout, i.e. the disk attached to the controller did not respond promptly (while the controller seemed to be alive/well). If these disks (which we do not know the type of -- no dmesg provided, etc.) are SSDs then TRIM behaviour is possibly causing the drive to take too long to perform its TRIM cleanup, or, the drives themselves are doing some kind of garbage collection which is taking quite a long time. Steven et all may have a different (and almost certainly more accurate) analysis. It would really help if you could provide "dmesg" from the machine, as well as any details about your setup (if ZFS, "zpool status", etc.), in addition to (if SSDs) "sysctl -a | grep -i trim". All this matters. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:04:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB7FC986 for ; Tue, 9 Jul 2013 15:04:38 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 92847164F for ; Tue, 9 Jul 2013 15:04:38 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so13095195iec.27 for ; Tue, 09 Jul 2013 08:04:38 -0700 (PDT) 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=YNZhqRNoOpWX4v0r4Q5xIlOEoB0sPbOas0C/MnEJLIo=; b=XVJcHjstKebn2BvnlhUOwqeQ7u/wKD0hXF9T6cSeuBqHP8e+i0tBIaYG90/9ddbxVP jvlBEKTcKqwyYOxb90OO9CUI/bQ+son2JSZg72OE9p/suXedyZ27aGWY+nQ6MbOSRZTb yU1HeFbArCeP7/KVqEZNIrG3R0iQNSv0Uv6eD2bcL4qPfXdkJ2MUnoqHzcAFg3bhAOxD a6rbw0hbEjWQnZg65cBkOy2ibHdrBxLMFhlszCg0cyNxCn+WnRY5ROlN1LZQkUdDHKsC kwSTQvmV0f4yNIhjtb1+PzkJNvjFJauIild7hg9VWWNK5h+EZPpfdrRp3WBlNzab3j47 Xa9Q== MIME-Version: 1.0 X-Received: by 10.42.226.3 with SMTP id iu3mr8293586icb.117.1373382278301; Tue, 09 Jul 2013 08:04:38 -0700 (PDT) Received: by 10.64.128.100 with HTTP; Tue, 9 Jul 2013 08:04:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 17:04:38 +0200 Message-ID: Subject: Re: hme0 interface going up/down (dhclient ?) From: Alban Hertroys To: dcx dcy Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:04:38 -0000 On 9 July 2013 16:05, dcx dcy wrote: > Hi all, > > I am having an issue where my hme0 interface is always turning up > and down with dhclient requesting a lease. > > > > I am thinking this could be the same issue described by Jeremy Chadwick on > June 9th: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073711.html > > Sounds like it. I recall someone warned that this issue would pop up with more (especially older) ethernet drivers. I was one of the people that ran into this on the em driver (Intel EtherExpress 100Mbit), which got a fairly prompt fix after I raised the issue. Since this is apparently caused by an interaction between the dhclient interface up/down detection mechanism and various wired ethernet interface drivers, it seems to me that it would help to be able to turn off dhclient's detection feature (or can we do that already?). The feature seems to be mostly useful for mobile devices (laptops and such) who tend to leave and enter different wireless network areas and need a new lease at that point. With wired interfaces, especially those that don't change physical location, the feature seems mostly pointless. Being able to turn it on or off at will seems useful and it would give other people running into this an easy way out. Regards, -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:20:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6BCEA160 for ; Tue, 9 Jul 2013 15:20:46 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 39F12177E for ; Tue, 9 Jul 2013 15:20:46 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so8214297oag.34 for ; Tue, 09 Jul 2013 08:20:45 -0700 (PDT) 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=L/2PxcTrKQuRUxZ2YJsciTdTP+zJAeVQfRIfDG5fk8E=; b=bdiy2KWA02enWT0HZ3Zeorh18BZy8r1TAI5s1cn/V85Ay9aGP55fLifhcsBoyRocrJ 5UAB5qzYXD7Vxmy4Z5I99RSrcCszT9gXmkqL4olnx87g36byh36/voT4GrqxbjbeCnnM jEpyxe65DL5ivGa5XOi6GPKlEV+UOf/73jLx97yqlm9RJFh1aQYCIw0q+jSx+G/jkD1t f33bk426o6/ftlcU1iNIVT3TS44s0zalW8qT9LiawwKs2ws4vY+ONkb5Vo6ayg+uqsGC XitE7jLJtCG/A45LUjiMuTxlAPiQG4TO8UslvwiY9NsQQ3Y98F3R7uAAxEIx97L9B7Tu M87w== MIME-Version: 1.0 X-Received: by 10.60.102.41 with SMTP id fl9mr24675124oeb.37.1373383245634; Tue, 09 Jul 2013 08:20:45 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 08:20:45 -0700 (PDT) In-Reply-To: <20130709144614.GA7538@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> <20130709144614.GA7538@icarus.home.lan> Date: Tue, 9 Jul 2013 11:20:45 -0400 Message-ID: Subject: Re: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:20:46 -0000 On Tue, Jul 9, 2013 at 10:46 AM, Jeremy Chadwick wrote: > On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo >wrote: > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick > wrote: > > > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > >> > as of stable today im seeing alot of new mps time outs > > >> > > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC > 2013 > > >> > root@:/usr/obj/nas/usr/src/sys/ > > >> > > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 > chip=0x00721000 > > >> > rev=0x03 hdr=0x00 > > >> > vendor = 'LSI Logic / Symbios Logic' > > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > >> > class = mass storage > > >> > subclass = SAS > > >> > > > >> > > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > >> > 0xffffff80021a6b78 > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > >> > mps0: mpssas_alloc_tm freezing simq > > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > during > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code > 0x0 > > >> count > > >> > 1 > > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting > TaskMID > > >> 983 > > >> > mps0: mpssas_free_tm releasing simq > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > > >> > (probe40:mps0:0:40:0): Retrying command > > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > >> > 0xffffff80023e5b78 > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > >> > mps1: mpssas_alloc_tm freezing simq > > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > during > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code > 0x0 > > >> count > > >> > 1 > > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting > TaskMID > > >> 983 > > >> > mps1: mpssas_free_tm releasing simq > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > > >> > (probe292:mps1:0:37:0): Retrying command > > >> > > >> 1. What revision were you running before (i.e. what were you on prior > to > > >> the upgrade)? > > >> > > > > > > > > > Sorry I was on 252595 from July 3 > > And does rolling back to r252595 resolve the problem for you? > > Because the only commit I see between r253035 and r252595 that might > account for some kind of behavioural change, unless I missed one while > skimming the commit history, is the following: > > r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 > > If at all possible, please try updating to r253037 or newer to see > if that has some effect/improvement. Why I mention that commit: > > r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 > > Because the only mps(4) changes done in recent days are: > > http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log > > r253037 > r251899 > r251874 > i can say this its between July 4, and 253048, im rolling back to 252723 to validate a good known working state > > Else I'd say what you're experiencing is legitimate/unrelated to kernel > changes. I can only speculate. > > The messages to me indicate that some part of the kernel is submitting a > SCSI INQUIRY request to the underlying device(s) which results in a CAM > timeout, i.e. the disk attached to the controller did not respond > promptly (while the controller seemed to be alive/well). > > If these disks (which we do not know the type of -- no dmesg provided, > etc.) are SSDs then TRIM behaviour is possibly causing the drive to take > too long to perform its TRIM cleanup, or, the drives themselves are > doing some kind of garbage collection which is taking quite a long time. > > Steven et all may have a different (and almost certainly more accurate) > analysis. > > It would really help if you could provide "dmesg" from the machine, as > well as any details about your setup (if ZFS, "zpool status", etc.), in > addition to (if SSDs) "sysctl -a | grep -i trim". All this matters. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:31:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0C22863 for ; Tue, 9 Jul 2013 15:31:13 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 923E31832 for ; Tue, 9 Jul 2013 15:31:13 +0000 (UTC) Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6840A41C090; Tue, 9 Jul 2013 17:31:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Bh3CzBUpKa79; Tue, 9 Jul 2013 17:31:00 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2931941C092; Tue, 9 Jul 2013 17:31:00 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 320F973A31; Tue, 9 Jul 2013 08:30:58 -0700 (PDT) Date: Tue, 9 Jul 2013 08:30:58 -0700 From: Jeremy Chadwick To: Outback Dingo Subject: Re: Stable/9 from today mpssas_scsiio timeouts Message-ID: <20130709153058.GA8769@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> <20130709144614.GA7538@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:31:14 -0000 On Tue, Jul 09, 2013 at 11:20:45AM -0400, Outback Dingo wrote: > On Tue, Jul 9, 2013 at 10:46 AM, Jeremy Chadwick wrote: > > > On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > > > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo > >wrote: > > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick > > wrote: > > > > > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > > >> > as of stable today im seeing alot of new mps time outs > > > >> > > > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC > > 2013 > > > >> > root@:/usr/obj/nas/usr/src/sys/ > > > >> > > > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 > > chip=0x00721000 > > > >> > rev=0x03 hdr=0x00 > > > >> > vendor = 'LSI Logic / Symbios Logic' > > > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > > >> > class = mass storage > > > >> > subclass = SAS > > > >> > > > > >> > > > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > > >> > 0xffffff80021a6b78 > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > SMID > > > >> 983 > > > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > > >> > mps0: mpssas_alloc_tm freezing simq > > > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > SMID > > > >> 983 > > > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > during > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code > > 0x0 > > > >> count > > > >> > 1 > > > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting > > TaskMID > > > >> 983 > > > >> > mps0: mpssas_free_tm releasing simq > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > > > >> > (probe40:mps0:0:40:0): Retrying command > > > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > > >> > 0xffffff80023e5b78 > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > SMID > > > >> 983 > > > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > > >> > mps1: mpssas_alloc_tm freezing simq > > > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > SMID > > > >> 983 > > > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > during > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code > > 0x0 > > > >> count > > > >> > 1 > > > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting > > TaskMID > > > >> 983 > > > >> > mps1: mpssas_free_tm releasing simq > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > > > >> > (probe292:mps1:0:37:0): Retrying command > > > >> > > > >> 1. What revision were you running before (i.e. what were you on prior > > to > > > >> the upgrade)? > > > >> > > > > > > > > > > > > Sorry I was on 252595 from July 3 > > > > And does rolling back to r252595 resolve the problem for you? > > > > Because the only commit I see between r253035 and r252595 that might > > account for some kind of behavioural change, unless I missed one while > > skimming the commit history, is the following: > > > > r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 > > > > If at all possible, please try updating to r253037 or newer to see > > if that has some effect/improvement. Why I mention that commit: > > > > r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 > > > > Because the only mps(4) changes done in recent days are: > > > > http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log > > > > r253037 > > r251899 > > r251874 > > > > i can say this its between July 4, and 253048, im rolling back to 252723 to > validate a good known working state Looking at your dmesg, it looks like the "errors" might be for SAS ports which don't have any actual devices (disks) attached to them, yet parts of the kernel (not sure which layer) are still trying to submit INQUIRY commands to those ports as if they did have disks attached. It looks like you see this behaviour on boot up, and then later during normal operation at some point (a LUN scan or rescan or "bus taste" might cause this to happen; for example I know that "zpool import" in effect can sometimes cause this behaviour -- on one of my systems "zpool import" would cause the servers' floppy drive to spin up/chunk briefly). I'm hoping Steven or mav@ might be able to confirm/deny my theory here. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:09:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31EF2BE1 for ; Tue, 9 Jul 2013 15:09:35 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id AF2F7169F for ; Tue, 9 Jul 2013 15:09:34 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id fb19so7074881obc.37 for ; Tue, 09 Jul 2013 08:09:34 -0700 (PDT) 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=EfAviAaQ0p7DtTcDzazQFaeJXB1E4797NyM5UHBRZ6o=; b=e5OlRv5X2OAFgK05PsBIwCRgXWRIMiw6WD4GV8BQOre1QzSf68+qP8SUYEd08lFvyG yMMlmOvpldjUElWk+smrDU+kqziR2S8KNP0gCR60F8FH4QrAvT0YE8lWsVTSscIVmJpP gNitoT9Nyu+YrLo64jMTWmZL83lK5WUT1+jiKGjD75j46wStxzG6whUVSO76vymjKC4o JEj4obFG7J2Qq7d8sVbjrGscs7YqYcYLpUTVDku95rTa6ajdJOj94bnUqV0LgerLs+U7 xEHddBbbtdBu5FPRjcDxtCdT74JawSgsx92kZBj9UEGIfWpfs9kJKke286wDxAvsZGiH wjyA== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr24821963obo.35.1373382574102; Tue, 09 Jul 2013 08:09:34 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 08:09:33 -0700 (PDT) In-Reply-To: <20130709144614.GA7538@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> <20130709144614.GA7538@icarus.home.lan> Date: Tue, 9 Jul 2013 11:09:33 -0400 Message-ID: Subject: Re: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: Jeremy Chadwick X-Mailman-Approved-At: Tue, 09 Jul 2013 15:42:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:09:35 -0000 On Tue, Jul 9, 2013 at 10:46 AM, Jeremy Chadwick wrote: > On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo >wrote: > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick > wrote: > > > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > >> > as of stable today im seeing alot of new mps time outs > > >> > > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 UTC > 2013 > > >> > root@:/usr/obj/nas/usr/src/sys/ > > >> > > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 > chip=0x00721000 > > >> > rev=0x03 hdr=0x00 > > >> > vendor = 'LSI Logic / Symbios Logic' > > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > >> > class = mass storage > > >> > subclass = SAS > > >> > > > >> > > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > >> > 0xffffff80021a6b78 > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > >> > mps0: mpssas_alloc_tm freezing simq > > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm 0xffffff80021587b0 > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > during > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a code > 0x0 > > >> count > > >> > 1 > > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting > TaskMID > > >> 983 > > >> > mps0: mpssas_free_tm releasing simq > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > > >> > (probe40:mps0:0:40:0): Retrying command > > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > >> > 0xffffff80023e5b78 > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > >> > mps1: mpssas_alloc_tm freezing simq > > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm 0xffffff80023977b0 > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > SMID > > >> 983 > > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > during > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a code > 0x0 > > >> count > > >> > 1 > > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting > TaskMID > > >> 983 > > >> > mps1: mpssas_free_tm releasing simq > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > > >> > (probe292:mps1:0:37:0): Retrying command > > >> > > >> 1. What revision were you running before (i.e. what were you on prior > to > > >> the upgrade)? > > >> > > > > > > > > > Sorry I was on 252595 from July 3 > > And does rolling back to r252595 resolve the problem for you? > > Because the only commit I see between r253035 and r252595 that might > account for some kind of behavioural change, unless I missed one while > skimming the commit history, is the following: > > r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 > > If at all possible, please try updating to r253037 or newer to see > if that has some effect/improvement. Why I mention that commit: > > r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 > > Because the only mps(4) changes done in recent days are: > > http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log > > r253037 > r251899 > r251874 > > Else I'd say what you're experiencing is legitimate/unrelated to kernel > changes. I can only speculate. > > The messages to me indicate that some part of the kernel is submitting a > SCSI INQUIRY request to the underlying device(s) which results in a CAM > timeout, i.e. the disk attached to the controller did not respond > promptly (while the controller seemed to be alive/well). > > If these disks (which we do not know the type of -- no dmesg provided, > etc.) are SSDs then TRIM behaviour is possibly causing the drive to take > too long to perform its TRIM cleanup, or, the drives themselves are > doing some kind of garbage collection which is taking quite a long time. > > Steven et all may have a different (and almost certainly more accurate) > analysis. > > It would really help if you could provide "dmesg" from the machine, as > well as any details about your setup (if ZFS, "zpool status", etc.), in > addition to (if SSDs) "sysctl -a | grep -i trim". All this matters. > > Its a dual node storage enclosure with dual LSI controllers per node, without geom_multipath enabled, with 32 SEAGATE SAS 3TB drivesin a zpool, and 2 STECs, not being used Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #0 r253048M: Mon Jul 8 23:51:04 UTC 2013 root@:/usr/obj/nas/usr/src/sys/NAS-amd64 amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz (2394.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping = 7 Features=0xbfebfbff Features2=0x1fbee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 137438953472 (131072 MB) avail memory = 132612501504 (126469 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 cpu4 (AP): APIC ID: 32 cpu5 (AP): APIC ID: 34 cpu6 (AP): APIC ID: 36 cpu7 (AP): APIC ID: 38 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20110527/tbfadt-638) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, 9d000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 47 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 47 at device 2.0 on pci0 pci2: on pcib2 ix0: port 0x4020-0x403f mem 0xd0f80000-0xd0ffffff,0xd1010000-0xd1013fff irq 32 at device 0.0 on pci2 ix0: port 0x4020-0x403f mem 0xd0f80000-0xd0ffffff,0xd1010000-0xd1013fff irq 32 at device 0.0 on pci2 ix0: Using MSIX interrupts with 7 vectors ix0: Ethernet address: 90:e2:ba:44:57:e4 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix1: port 0x4000-0x401f mem 0xd0f00000-0xd0f7ffff,0xd1000000-0xd1003fff irq 36 at device 0.1 on pci2 ix1: Using MSIX interrupts with 7 vectors ix1: Ethernet address: 90:e2:ba:44:57:e5 ix1: PCI Express Bus: Speed 5.0GT/s Width x8 pcib3: irq 47 at device 2.2 on pci0 pci4: on pcib3 pcib4: irq 16 at device 3.0 on pci0 pci5: on pcib4 pcib5: irq 16 at device 3.2 on pci0 pci6: on pcib5 mps0: port 0x3000-0x30ff mem 0xd0dc0000-0xd0dc3fff,0xd0d80000-0xd0dbffff irq 42 at device 0.0 on pci6 mps0: Firmware: 16.00.00.00, Driver: 14.00.00.01-fbsd mps0: IOCCapabilities: 1285c pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 4.5 (no driver attached) pci0: at device 4.6 (no driver attached) pci0: at device 4.7 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) pcib6: irq 16 at device 17.0 on pci0 pci7: on pcib6 isci0: port 0x2000-0x20ff mem 0xebc00000-0xebc03fff,0xeb800000-0xebbfffff irq 16 at device 0.0 on pci7 pci7: at device 0.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) ehci0: mem 0xd1710000-0xd17103ff irq 22 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 pcib7: irq 16 at device 28.0 on pci0 pci8: on pcib7 igb0: port 0x1020-0x103f mem 0xd1520000-0xd153ffff,0xd1550000-0xd1553fff irq 16 at device 0.0 on pci8 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:1e:67:3c:c2:4d igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0x1000-0x101f mem 0xd1500000-0xd151ffff,0xd1540000-0xd1543fff irq 17 at device 0.1 on pci8 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:1e:67:3c:c2:4e igb1: Bound queue 0 to cpu 0 igb1: Bound queue 1 to cpu 1 igb1: Bound queue 2 to cpu 2 igb1: Bound queue 3 to cpu 3 igb1: Bound queue 4 to cpu 4 igb1: Bound queue 5 to cpu 5 igb1: Bound queue 6 to cpu 6 igb1: Bound queue 7 to cpu 7 pcib8: irq 19 at device 28.7 on pci0 pci10: on pcib8 vgapci0: mem 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq 19 at device 0.0 on pci10 ehci1: mem 0xd1700000-0xd17003ff irq 20 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 pcib9: at device 30.0 on pci0 pci11: on pcib9 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5090-0x509f,0x5080-0x508f irq 21 at device 31.2 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) atapci1: port 0x5070-0x5077,0x5060-0x5063,0x5050-0x5057,0x5040-0x5043,0x5030-0x503f,0x5020-0x502f irq 22 at device 31.5 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 pcib10: on acpi0 pci128: on pcib10 pcib11: irq 71 at device 3.0 on pci128 pci129: on pcib11 pcib12: irq 71 at device 3.2 on pci128 pci130: on pcib12 mps1: port 0xc000-0xc0ff mem 0xec4c0000-0xec4c3fff,0xec480000-0xec4bffff irq 66 at device 0.0 on pci130 mps1: Firmware: 16.00.00.00, Driver: 14.00.00.01-fbsd mps1: IOCCapabilities: 1285c pci128: at device 4.0 (no driver attached) pci128: at device 4.1 (no driver attached) pci128: at device 4.2 (no driver attached) pci128: at device 4.3 (no driver attached) pci128: at device 4.4 (no driver attached) pci128: at device 4.5 (no driver attached) pci128: at device 4.6 (no driver attached) pci128: at device 4.7 (no driver attached) pci128: at device 5.0 (no driver attached) pci128: at device 5.2 (no driver attached) pcib13: on acpi0 pci127: on pcib13 pci127: at device 8.0 (no driver attached) pci127: at device 9.0 (no driver attached) pci127: at device 10.0 (no driver attached) pci127: at device 10.1 (no driver attached) pci127: at device 10.2 (no driver attached) pci127: at device 10.3 (no driver attached) pci127: at device 11.0 (no driver attached) pci127: at device 11.3 (no driver attached) pci127: at device 12.0 (no driver attached) pci127: at device 12.1 (no driver attached) pci127: at device 12.6 (no driver attached) pci127: at device 12.7 (no driver attached) pci127: at device 13.0 (no driver attached) pci127: at device 13.1 (no driver attached) pci127: at device 13.6 (no driver attached) pci127: at device 14.0 (no driver attached) pci127: at device 14.1 (no driver attached) pci127: at device 15.0 (no driver attached) pci127: at device 15.1 (no driver attached) pci127: at device 15.2 (no driver attached) pci127: at device 15.3 (no driver attached) pci127: at device 15.4 (no driver attached) pci127: at device 15.5 (no driver attached) pci127: at device 15.6 (no driver attached) pci127: at device 16.0 (no driver attached) pci127: at device 16.1 (no driver attached) pci127: at device 16.2 (no driver attached) pci127: at device 16.3 (no driver attached) pci127: at device 16.4 (no driver attached) pci127: at device 16.5 (no driver attached) pci127: at device 16.6 (no driver attached) pci127: at device 16.7 (no driver attached) pci127: at device 17.0 (no driver attached) pci127: at device 19.0 (no driver attached) pci127: at device 19.1 (no driver attached) pci127: at device 19.4 (no driver attached) pci127: at device 19.5 (no driver attached) pci127: at device 19.6 (no driver attached) pcib14: on acpi0 pci255: on pcib14 pci255: at device 8.0 (no driver attached) pci255: at device 9.0 (no driver attached) pci255: at device 10.0 (no driver attached) pci255: at device 10.1 (no driver attached) pci255: at device 10.2 (no driver attached) pci255: at device 10.3 (no driver attached) pci255: at device 11.0 (no driver attached) pci255: at device 11.3 (no driver attached) pci255: at device 12.0 (no driver attached) pci255: at device 12.1 (no driver attached) pci255: at device 12.6 (no driver attached) pci255: at device 12.7 (no driver attached) pci255: at device 13.0 (no driver attached) pci255: at device 13.1 (no driver attached) pci255: at device 13.6 (no driver attached) pci255: at device 14.0 (no driver attached) pci255: at device 14.1 (no driver attached) pci255: at device 15.0 (no driver attached) pci255: at device 15.1 (no driver attached) pci255: at device 15.2 (no driver attached) pci255: at device 15.3 (no driver attached) pci255: at device 15.4 (no driver attached) pci255: at device 15.5 (no driver attached) pci255: at device 15.6 (no driver attached) pci255: at device 16.0 (no driver attached) pci255: at device 16.1 (no driver attached) pci255: at device 16.2 (no driver attached) pci255: at device 16.3 (no driver attached) pci255: at device 16.4 (no driver attached) pci255: at device 16.5 (no driver attached) pci255: at device 16.6 (no driver attached) pci255: at device 16.7 (no driver attached) pci255: at device 17.0 (no driver attached) pci255: at device 19.0 (no driver attached) pci255: at device 19.1 (no driver attached) pci255: at device 19.4 (no driver attached) pci255: at device 19.5 (no driver attached) pci255: at device 19.6 (no driver attached) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xd9000-0xd9fff,0xda000-0xdafff,0xdb000-0xdbfff,0xdc000-0xdcfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled iSCSI boot driver version 0.2.6 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 ums0: on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 ugen1.4: at usbus1 ukbd1: on usbus1 kbd2 at ukbd1 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80020e0448 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 353 command timeout cm 0xffffff80020e0448 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80020e0448 allocated tm 0xffffff80020c4148 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 353 completed timedout cm 0xffffff80020e0448 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 1 abort TaskMID 353 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 1 finished recovery after aborting TaskMID 353 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff800232f070 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 350 command timeout cm 0xffffff800232f070 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff800232f070 allocated tm 0xffffff8002313148 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 350 completed timedout cm 0xffffff800232f070 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 1 abort TaskMID 350 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 1 finished recovery after aborting TaskMID 350 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff8002112510 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 978 command timeout cm 0xffffff8002112510 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff8002112510 allocated tm 0xffffff80020c4290 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 978 completed timedout cm 0xffffff8002112510 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 2 abort TaskMID 978 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 2 finished recovery after aborting TaskMID 978 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff8002361510 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 978 command timeout cm 0xffffff8002361510 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff8002361510 allocated tm 0xffffff8002313290 run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 978 completed timedout cm 0xffffff8002361510 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 2 abort TaskMID 978 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 2 finished recovery after aborting TaskMID 978 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff8002112658 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 979 command timeout cm 0xffffff8002112658 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff8002112658 allocated tm 0xffffff80020c43d8 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 979 completed timedout cm 0xffffff8002112658 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 3 abort TaskMID 979 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 3 finished recovery after aborting TaskMID 979 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff8002361658 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 979 command timeout cm 0xffffff8002361658 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff8002361658 allocated tm 0xffffff80023133d8 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 979 completed timedout cm 0xffffff8002361658 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 3 abort TaskMID 979 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 3 finished recovery after aborting TaskMID 979 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80021127a0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 980 command timeout cm 0xffffff80021127a0 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80021127a0 allocated tm 0xffffff80020c4520 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 980 completed timedout cm 0xffffff80021127a0 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 4 abort TaskMID 980 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 4 finished recovery after aborting TaskMID 980 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff80023617a0 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 980 command timeout cm 0xffffff80023617a0 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff80023617a0 allocated tm 0xffffff8002313520 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 980 completed timedout cm 0xffffff80023617a0 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 4 abort TaskMID 980 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 4 finished recovery after aborting TaskMID 980 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80021128e8 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 981 command timeout cm 0xffffff80021128e8 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80021128e8 allocated tm 0xffffff80020c4668 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 981 completed timedout cm 0xffffff80021128e8 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 5 abort TaskMID 981 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 5 finished recovery after aborting TaskMID 981 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Error 5, Retries exhausted mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff80023618e8 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 981 command timeout cm 0xffffff80023618e8 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff80023618e8 allocated tm 0xffffff8002313668 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 981 completed timedout cm 0xffffff80023618e8 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 5 abort TaskMID 981 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 5 finished recovery after aborting TaskMID 981 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Error 5, Retries exhausted ses0 at mps0 bus 0 scbus0 target 8 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 600.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 ENC Device ses1 at mps0 bus 0 scbus0 target 9 lun 0 ses1: Fixed Enclosure Services SCSI-5 device ses1: 600.000MB/s transfers ses1: Command Queueing enabled ses1: SCSI-3 ENC Device ses2 at mps0 bus 0 scbus0 target 10 lun 0 ses2: Fixed Enclosure Services SCSI-5 device ses2: 600.000MB/s transfers ses2: Command Queueing enabled ses2: SCSI-3 ENC Device ses3 at mps0 bus 0 scbus0 target 11 lun 0 ses3: Fixed Enclosure Services SCSI-5 device ses3: 600.000MB/s transfers ses3: Command Queueing enabled ses3: SCSI-3 ENC Device ses4 at mps0 bus 0 scbus0 target 12 lun 0 ses4: Fixed Enclosure Services SCSI-5 device ses4: 600.000MB/s transfers ses4: Command Queueing enabled ses4: SCSI-3 ENC Device ses5 at mps0 bus 0 scbus0 target 13 lun 0 ses5: Fixed Enclosure Services SCSI-5 device ses5: 600.000MB/s transfers ses5: Command Queueing enabled ses5: SCSI-3 ENC Device ses6 at mps0 bus 0 scbus0 target 14 lun 0 ses6: Fixed Enclosure Services SCSI-5 device ses6: 600.000MB/s transfers ses6: Command Queueing enabled ses6: SCSI-3 ENC Device ses7 at mps0 bus 0 scbus0 target 15 lun 0 ses7: Fixed Enclosure Services SCSI-5 device ses7: 600.000MB/s transfers ses7: Command Queueing enabled ses7: SCSI-3 ENC Device ses8 at mps1 bus 0 scbus6 target 8 lun 0 ses8: Fixed Enclosure Services SCSI-5 device ses8: 600.000MB/s transfers ses8: Command Queueing enabled ses8: SCSI-3 ENC Device ses9 at mps1 bus 0 scbus6 target 9 lun 0 ses9: Fixed Enclosure Services SCSI-5 device ses9: 600.000MB/s transfers ses9: Command Queueing enabled ses9: SCSI-3 ENC Device ses10 at mps1 bus 0 scbus6 target 10 lun 0 ses10: Fixed Enclosure Services SCSI-5 device ses10: 600.000MB/s transfers ses10: Command Queueing enabled ses10: SCSI-3 ENC Device ses11 at mps1 bus 0 scbus6 target 11 lun 0 ses11: Fixed Enclosure Services SCSI-5 device ses11: 600.000MB/s transfers ses11: Command Queueing enabled ses11: SCSI-3 ENC Device ses12 at mps1 bus 0 scbus6 target 12 lun 0 ses12: Fixed Enclosure Services SCSI-5 device ses12: 600.000MB/s transfers ses12: Command Queueing enabled ses12: SCSI-3 ENC Device ses13 at mps1 bus 0 scbus6 target 13 lun 0 ses13: Fixed Enclosure Services SCSI-5 device ses13: 600.000MB/s transfers ses13: Command Queueing enabled ses13: SCSI-3 ENC Device ses14 at mps1 bus 0 scbus6 target 14 lun 0 ses14: Fixed Enclosure Services SCSI-5 device ses14: 600.000MB/s transfers ses14: Command Queueing enabled ses14: SCSI-3 ENC Device ses15 at mps1 bus 0 scbus6 target 15 lun 0 ses15: Fixed Enclosure Services SCSI-5 device ses15: 600.000MB/s transfers ses15: Command Queueing enabled ses15: SCSI-3 ENC Device da0 at mps0 bus 0 scbus0 target 16 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 600.000MB/s transfers da0: Command Queueing enabled da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da2 at mps0 bus 0 scbus0 target 18 lun 0 da2: Fixed Direct Access SCSI-6 device da2: 600.000MB/s transfers da2: Command Queueing enabled da2: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da1 at mps0 bus 0 scbus0 target 17 lun 0 da1: Fixed Direct Access SCSI-6 device da1: 600.000MB/s transfers da1: Command Queueing enabled da1: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da4 at mps0 bus 0 scbus0 target 20 lun 0 da4: Fixed Direct Access SCSI-6 device da4: 600.000MB/s transfers da4: Command Queueing enabled da4: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da3 at mps0 bus 0 scbus0 target 19 lun 0 da3: Fixed Direct Access SCSI-6 device da3: 600.000MB/s transfers da3: Command Queueing enabled da3: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) ses7: pass33: Element descriptor: 'ArrayDevice00' ses7: pass33: SAS Device Slot Element: 1 Phys at Slot 0 ses7: phy 0: SAS device type 1 id 0 ses7: phy 0: protocols: Initiator( None ) Target( SSP ) ses7: phy 0: parent 5000ed572eeae5bf addr 5000c50055914a3d ses7: pass22: Element descriptor: 'ArrayDevice01' ses7: pass22: SAS Device Slot Element: 1 Phys at Slot 1 ses7: phy 0: SAS device type 1 id 0 ses7: phy 0: protocols: Initiator( None ) Target( SSP ) ses7: phy 0: parent 5000ed572eeae5bf addr 5000c5005596d2e1 ses7: pass34: Element descriptor: 'ArrayDevice02' ses7: pass34: SAS Device Slot Element: 1 Phys at Slot 2 ses7: phy 0: SAS device type 1 id 0 ses7: phy 0: protocols: Initiator( None ) Target( SSP ) ses7: phy 0: parent 5000ed572eeae5bf addr 5000c5005591435d ses7: pass23: Element descriptor: 'ArrayDevice03' ses7: pass23: SAS Device Slot Element: 1 Phys at Slot 3 ses7: phy 0: SAS device type 1 id 0 ses7: phy 0: protocols: Initiator( None ) Target( SSP ) ses7: phy 0: parent 5000ed572eeae5bf addr 5000c50055970dcd ses6: pass35: Element descriptor: 'ArrayDevice00' ses6: pass35: SAS Device Slot Element: 1 Phys at Slot 0 ses6: phy 0: SAS device type 1 id 0 ses6: phy 0: protocols: Initiator( None ) Target( SSP ) ses6: phy 0: parent 5000ed572eea93bf addr 5000c50041ea2bf5 ses6: pass20: Element descriptor: 'ArrayDevice01' ses6: pass20: SAS Device Slot Element: 1 Phys at Slot 1 ses6: phy 0: SAS device type 1 id 0 ses6: phy 0: protocols: Initiator( None ) Target( SSP ) ses6: phy 0: parent 5000ed572eea93bf addr 5000c50041e935bd ses6: pass36: Element descriptor: 'ArrayDevice02' ses6: pass36: SAS Device Slot Element: 1 Phys at Slot 2 ses6: phy 0: SAS device type 1 id 0 ses6: phy 0: protocols: Initiator( None ) Target( SSP ) ses6: phy 0: parent 5000ed572eea93bf addr 5000c50041e91de5 ses6: pass21: Element descriptor: 'ArrayDevice03' ses6: pass21: SAS Device Slot Element: 1 Phys at Slot 3 ses6: phy 0: SAS device type 1 id 0 ses6: phy 0: protocols: Initiator( None ) Target( SSP ) ses6: phy 0: parent 5000ed572eea93bf addr 5000c50055970425 ses0: pass24: Element descriptor: 'ArrayDevice00' ses0: pass24: SAS Device Slot Element: 1 Phys at Slot 0 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5000ed572a84eebf addr 5000c50055970b81 ses0: pass8,da0: Element descriptor: 'ArrayDevice01' ses0: pass8,da0: SAS Device Slot Element: 1 Phys at Slot 1 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5000ed572a84eebf addr 5000c50055913a19 ses0: pass26: Element descriptor: 'ArrayDevice02' ses0: pass26: SAS Device Slot Element: 1 Phys at Slot 2 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5000ed572a84eebf addr 5000c50055954155 ses0: phy 0: parent 5000ed572a84eebf addr 5000c50055954155 ses0: pass9,da1: Element descriptor: 'ArrayDevice03' ses0: pass9,da1: SAS Device Slot Element: 1 Phys at Slot 3 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5000ed572a84eebf addr 5000c5005596f7f1 ses0: pass25: Element descriptor: 'ArrayDevice04' ses0: pass25: SAS Device Slot Element: 1 Phys at Slot 4 ses0: phy 0: SAS device type 1 id 0 ses0: phy 0: protocols: Initiator( None ) Target( SSP ) ses0: phy 0: parent 5000ed572a84eebf addr 5000a72a3006fe49 ses1: pass27: Element descriptor: 'ArrayDevice00' ses1: pass27: SAS Device Slot Element: 1 Phys at Slot 0 ses1: phy 0: SAS device type 1 id 0 ses1: phy 0: protocols: Initiator( None ) Target( SSP ) ses1: phy 0: parent 5000ed572a857abf addr 5000c50055915121 ses1: pass10,da2: Element descriptor: 'ArrayDevice01' ses1: pass10,da2: SAS Device Slot Element: 1 Phys at Slot 1 ses1: phy 0: SAS device type 1 id 0 ses1: phy 0: protocols: Initiator( None ) Target( SSP ) ses1: phy 0: parent 5000ed572a857abf addr 5000c50041ea0879 ses1: pass28: Element descriptor: 'ArrayDevice02' ses1: pass28: SAS Device Slot Element: 1 Phys at Slot 2 ses1: phy 0: SAS device type 1 id 0 ses1: phy 0: protocols: Initiator( None ) Target( SSP ) ses1: phy 0: parent 5000ed572a857abf addr 5000c50041e9530d ses1: pass11,da3: Element descriptor: 'ArrayDevice03' ses1: pass11,da3: SAS Device Slot Element: 1 Phys at Slot 3 ses1: phy 0: SAS device type 1 id 0 ses1: phy 0: protocols: Initiator( None ) Target( SSP ) ses1: phy 0: parent 5000ed572a857abf addr 5000c50055913b95 ses4: pass39: Element descriptor: 'ArrayDevice00' ses4: pass39: SAS Device Slot Element: 1 Phys at Slot 0 ses4: phy 0: SAS device type 1 id 0 ses4: phy 0: protocols: Initiator( None ) Target( SSP ) ses4: phy 0: parent 5000ed572a84f7bf addr 5000c5005594fe65 ses4: pass16: Element descriptor: 'ArrayDevice01' ses4: pass16: SAS Device Slot Element: 1 Phys at Slot 1 ses4: phy 0: SAS device type 1 id 0 ses4: phy 0: protocols: Initiator( None ) Target( SSP ) ses4: phy 0: parent 5000ed572a84f7bf addr 5000c50041e9ef5d ses4: pass40: Element descriptor: 'ArrayDevice02' ses4: pass40: SAS Device Slot Element: 1 Phys at Slot 2 ses4: phy 0: SAS device type 1 id 0 ses4: phy 0: protocols: Initiator( None ) Target( SSP ) ses4: phy 0: parent 5000ed572a84f7bf addr 5000c50041ea0161 ses4: pass17: Element descriptor: 'ArrayDevice03' ses4: pass17: SAS Device Slot Element: 1 Phys at Slot 3 ses4: phy 0: SAS device type 1 id 0 ses4: phy 0: protocols: Initiator( None ) Target( SSP ) ses4: phy 0: parent 5000ed572a84f7bf addr 5000c500559141c9 ses2: pass29: Element descriptor: 'ArrayDevice00' ses2: pass29: SAS Device Slot Element: 1 Phys at Slot 0 ses2: phy 0: SAS device type 1 id 0 ses2: phy 0: protocols: Initiator( None ) Target( SSP ) ses2: phy 0: parent 5000ed572a855cbf addr 5000c50041e9ab6d ses2: pass12,da4: Element descriptor: 'ArrayDevice01' ses2: pass12,da4: SAS Device Slot Element: 1 Phys at Slot 1 ses2: phy 0: SAS device type 1 id 0 ses2: phy 0: protocols: Initiator( None ) Target( SSP ) ses2: phy 0: parent 5000ed572a855cbf addr 5000c50041e9ef15 ses2: pass30: Element descriptor: 'ArrayDevice02' ses2: pass30: SAS Device Slot Element: 1 Phys at Slot 2 ses2: phy 0: SAS device type 1 id 0 ses2: phy 0: SAS device type 1 id 0 ses2: phy 0: protocols: Initiator( None ) Target( SSP ) ses2: phy 0: parent 5000ed572a855cbf addr 5000c50041e910fd ses2: pass13,da5: Element descriptor: 'ArrayDevice03' ses2: pass13,da5: SAS Device Slot Element: 1 Phys at Slot 3 ses2: phy 0: SAS device type 1 id 0 ses2: phy 0: protocols: Initiator( None ) Target( SSP ) ses2: phy 0: parent 5000ed572a855cbf addr 5000c5005596e531 ses5: pass37: Element descriptor: 'ArrayDevice00' ses5: pass37: SAS Device Slot Element: 1 Phys at Slot 0 ses5: phy 0: SAS device type 1 id 0 ses5: phy 0: protocols: Initiator( None ) Target( SSP ) ses5: phy 0: parent 5000ed572a8548bf addr 5000c50041ea4d49 ses5: pass18: Element descriptor: 'ArrayDevice01' ses5: pass18: SAS Device Slot Element: 1 Phys at Slot 1 ses5: phy 0: SAS device type 1 id 0 ses5: phy 0: protocols: Initiator( None ) Target( SSP ) ses5: phy 0: parent 5000ed572a8548bf addr 5000c50041f10a8d ses5: pass38: Element descriptor: 'ArrayDevice02' ses5: pass38: SAS Device Slot Element: 1 Phys at Slot 2 ses5: phy 0: SAS device type 1 id 0 ses5: phy 0: protocols: Initiator( None ) Target( SSP ) ses5: phy 0: parent 5000ed572a8548bf addr 5000c50041ea4c65 ses5: pass19: Element descriptor: 'ArrayDevice03' ses5: pass19: SAS Device Slot Element: 1 Phys at Slot 3 ses5: phy 0: SAS device type 1 id 0 ses5: phy 0: protocols: Initiator( None ) Target( SSP ) ses5: phy 0: parent 5000ed572a8548bf addr 5000c5005596eda9 ses3: pass31: Element descriptor: 'ArrayDevice00' ses3: pass31: SAS Device Slot Element: 1 Phys at Slot 0 ses3: phy 0: SAS device type 1 id 0 ses3: phy 0: protocols: Initiator( None ) Target( SSP ) ses3: phy 0: parent 5000ed572a84e8bf addr 5000c50041ea4a85 ses3: pass14: Element descriptor: 'ArrayDevice01' ses3: pass14: SAS Device Slot Element: 1 Phys at Slot 1 ses3: phy 0: SAS device type 1 id 0 ses3: phy 0: protocols: Initiator( None ) Target( SSP ) ses3: phy 0: parent 5000ed572a84e8bf addr 5000c50055914a09 ses3: pass32: Element descriptor: 'ArrayDevice02' ses3: pass32: SAS Device Slot Element: 1 Phys at Slot 2 ses3: phy 0: SAS device type 1 id 0 ses3: phy 0: protocols: Initiator( None ) Target( SSP ) ses3: phy 0: parent 5000ed572a84e8bf addr 5000c5005595210d ses3: pass15: Element descriptor: 'ArrayDevice03' ses3: pass15: SAS Device Slot Element: 1 Phys at Slot 3 ses3: phy 0: SAS device type 1 id 0 ses3: phy 0: protocols: Initiator( None ) Target( SSP ) ses3: phy 0: parent 5000ed572a84e8bf addr 5000c50055948421 da5 at mps0 bus 0 scbus0 target 21 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 600.000MB/s transfers da5: Command Queueing enabled da5: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da8 at mps0 bus 0 scbus0 target 24 lun 0 da8: Fixed Direct Access SCSI-6 device da8: 600.000MB/s transfers da8: Command Queueing enabled da8: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da9 at mps0 bus 0 scbus0 target 25 lun 0 da9: Fixed Direct Access SCSI-6 device da9: 600.000MB/s transfers da9: Command Queueing enabled da9: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da6 at mps0 bus 0 scbus0 target 22 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 600.000MB/s transfers da6: Command Queueing enabled da6: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da10 at mps0 bus 0 scbus0 target 26 lun 0 da10: Fixed Direct Access SCSI-6 device da10: 600.000MB/s transfers da10: Command Queueing enabled da10: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da7 at mps0 bus 0 scbus0 target 23 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 600.000MB/s transfers da7: Command Queueing enabled da7: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da17 at mps0 bus 0 scbus0 target 33 lun 0 da17: Fixed Direct Access SCSI-6 device da17: 600.000MB/s transfers da17: Command Queueing enabled da17: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) da14 at mps0 bus 0 scbus0 target 30 lun 0 da14: Fixed Direct Access SCSI-6 device da14: 600.000MB/s transfers da14: Command Queueing enabled da14: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da16 at mps0 bus 0 scbus0 target 32 lun 0 da16: Fixed Direct Access SCSI-6 device da16: 600.000MB/s transfers da16: Command Queueing enabled da16: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da11 at mps0 bus 0 scbus0 target 27 lun 0 da11: Fixed Direct Access SCSI-6 device da11: 600.000MB/s transfers da11: Command Queueing enabled da11: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da12 at mps0 bus 0 scbus0 target 28 lun 0 da12: Fixed Direct Access SCSI-6 device da12: 600.000MB/s transfers da12: Command Queueing enabled da12: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da15 at mps0 bus 0 scbus0 target 31 lun 0 da15: Fixed Direct Access SCSI-6 device da15: 600.000MB/s transfers da15: Command Queueing enabled da15: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da13 at mps0 bus 0 scbus0 target 29 lun 0 da13: Fixed Direct Access SCSI-6 device da13: 600.000MB/s transfers da13: Command Queueing enabled da13: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da18 at mps0 bus 0 scbus0 target 34 lun 0 da18: Fixed Direct Access SCSI-6 device da18: 600.000MB/s transfers da18: Command Queueing enabled da18: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da21 at mps0 bus 0 scbus0 target 37 lun 0 da21: Fixed Direct Access SCSI-6 device da21: 600.000MB/s transfers da21: Command Queueing enabled da21: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da20 at mps0 bus 0 scbus0 target 36 lun 0 da20: Fixed Direct Access SCSI-6 device da20: 600.000MB/s transfers da20: Command Queueing enabled da20: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da19 at mps0 bus 0 scbus0 target 35 lun 0 da19: Fixed Direct Access SCSI-6 device da19: 600.000MB/s transfers da19: Command Queueing enabled da19: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da26 at mps0 bus 0 scbus0 target 43 lun 0 da26: Fixed Direct Access SCSI-6 device da26: 600.000MB/s transfers da26: Command Queueing enabled da26: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da27 at mps0 bus 0 scbus0 target 44 lun 0 da27: Fixed Direct Access SCSI-6 device da27: 600.000MB/s transfers da27: Command Queueing enabled da27: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da22 at mps0 bus 0 scbus0 target 38 lun 0 da22: Fixed Direct Access SCSI-6 device da22: 600.000MB/s transfers da22: Command Queueing enabled da22: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da25 at mps0 bus 0 scbus0 target 42 lun 0 da25: Fixed Direct Access SCSI-6 device da25: 600.000MB/s transfers da25: Command Queueing enabled da25: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da28 at mps0 bus 0 scbus0 target 45 lun 0 da28: Fixed Direct Access SCSI-6 device da28: 600.000MB/s transfers da28: Command Queueing enabled da28: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da29 at mps0 bus 0 scbus0 target 46 lun 0 da29: Fixed Direct Access SCSI-6 device da29: 600.000MB/s transfers da29: Command Queueing enabled da29: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da24 at mps0 bus 0 scbus0 target 41 lun 0 da24: Fixed Direct Access SCSI-6 device da24: 600.000MB/s transfers da24: Command Queueing enabled da24: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da23 at mps0 bus 0 scbus0 target 39 lun 0 da23: Fixed Direct Access SCSI-6 device da23: 600.000MB/s transfers da23: Command Queueing enabled da23: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da30 at mps0 bus 0 scbus0 target 47 lun 0 da30: Fixed Direct Access SCSI-6 device da30: 600.000MB/s transfers da30: Command Queueing enabled da30: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da33 at isci0 bus 0 scbus1 target 0 lun 0 da33: Fixed Direct Access SCSI-6 device da33: 300.000MB/s transfers da33: Command Queueing enabled da33: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) da31 at mps0 bus 0 scbus0 target 48 lun 0 da31: Fixed Direct Access SCSI-6 device da31: 600.000MB/s transfers da31: Command Queueing enabled da31: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da32 at mps0 bus 0 scbus0 target 49 lun 0 da32: Fixed Direct Access SCSI-6 device da32: 600.000MB/s transfers da32: Command Queueing enabled da32: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da36 at mps1 bus 0 scbus6 target 17 lun 0 da36: Fixed Direct Access SCSI-6 device da36: 600.000MB/s transfers da36: Command Queueing enabled da36: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da34 at isci0 bus 0 scbus1 target 1 lun 0 da34: Fixed Direct Access SCSI-6 device da34: 300.000MB/s transfers da34: Command Queueing enabled da34: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) da37 at mps1 bus 0 scbus6 target 18 lun 0 da37: Fixed Direct Access SCSI-6 device da37: 600.000MB/s transfers da37: Command Queueing enabled da37: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da38 at mps1 bus 0 scbus6 target 19 lun 0 da38: Fixed Direct Access SCSI-6 device da38: 600.000MB/s transfers da38: Command Queueing enabled da38: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da35 at mps1 bus 0 scbus6 target 16 lun 0 da35: Fixed Direct Access SCSI-6 device da35: 600.000MB/s transfers da35: Command Queueing enabled da35: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da39 at mps1 bus 0 scbus6 target 20 lun 0 da39: Fixed Direct Access SCSI-6 device da39: 600.000MB/s transfers da39: Command Queueing enabled da39: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da40 at mps1 bus 0 scbus6 target 21 lun 0 da40: Fixed Direct Access SCSI-6 device da40: 600.000MB/s transfers da40: Command Queueing enabled da40: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da41 at mps1 bus 0 scbus6 target 22 lun 0 da41: Fixed Direct Access SCSI-6 device da41: 600.000MB/s transfers da41: Command Queueing enabled da41: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da43 at mps1 bus 0 scbus6 target 24 lun 0 da43: Fixed Direct Access SCSI-6 device da43: 600.000MB/s transfers da43: Command Queueing enabled da43: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) da42 at mps1 bus 0 scbus6 target 23 lun 0 da42: Fixed Direct Access SCSI-6 device da42: 600.000MB/s transfers da42: Command Queueing enabled da42: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da46 at mps1 bus 0 scbus6 target 27 lun 0 da46: Fixed Direct Access SCSI-6 device da46: 600.000MB/s transfers da46: Command Queueing enabled da46: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da47 at mps1 bus 0 scbus6 target 28 lun 0 da47: Fixed Direct Access SCSI-6 device da47: 600.000MB/s transfers da47: Command Queueing enabled da47: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da48 at mps1 bus 0 scbus6 target 29 lun 0 da48: Fixed Direct Access SCSI-6 device da48: 600.000MB/s transfers da48: Command Queueing enabled da48: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da45 at mps1 bus 0 scbus6 target 26 lun 0 da45: Fixed Direct Access SCSI-6 device da45: 600.000MB/s transfers da45: Command Queueing enabled da45: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da44 at mps1 bus 0 scbus6 target 25 lun 0 da44: Fixed Direct Access SCSI-6 device da44: 600.000MB/s transfers da44: Command Queueing enabled da44: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da51 at mps1 bus 0 scbus6 target 32 lun 0 da51: Fixed Direct Access SCSI-6 device da51: 600.000MB/s transfers da51: Command Queueing enabled da51: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da52 at mps1 bus 0 scbus6 target 33 lun 0 da52: Fixed Direct Access SCSI-6 device da52: 600.000MB/s transfers da52: Command Queueing enabled da52: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da49 at mps1 bus 0 scbus6 target 30 lun 0 da49: Fixed Direct Access SCSI-6 device da49: 600.000MB/s transfers da49: Command Queueing enabled da49: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da50 at mps1 bus 0 scbus6 target 31 lun 0 da50: Fixed Direct Access SCSI-6 device da50: 600.000MB/s transfers da50: Command Queueing enabled da50: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da54 at mps1 bus 0 scbus6 target 35 lun 0 da54: Fixed Direct Access SCSI-6 device da54: 600.000MB/s transfers da54: Command Queueing enabled da54: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da53 at mps1 bus 0 scbus6 target 34 lun 0 da53: Fixed Direct Access SCSI-6 device da53: 600.000MB/s transfers da53: Command Queueing enabled da53: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) make_dev_physpath_alias: WARNING - Unable to alias pass10 to enc@n5000ed572a857abd/type@0/slot@2/elmdesc@ArrayDevice01/pass10 da64 at mps1 bus 0 scbus6 target 46 lun 0 da64: Fixed Direct Access SCSI-6 device da64: 600.000MB/s transfers da64: Command Queueing enabled da64: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da67 at mps1 bus 0 scbus6 target 49 lun 0 da67: Fixed Direct Access SCSI-6 device da67: 600.000MB/s transfers da67: Command Queueing enabled da67: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da66 at mps1 bus 0 scbus6 target 48 lun 0 da66: Fixed Direct Access SCSI-6 device da66: 600.000MB/s transfers da66: Command Queueing enabled da66: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da57 at mps1 bus 0 scbus6 target 39 lun 0 da57: Fixed Direct Access SCSI-6 device da57: 600.000MB/s transfers da57: Command Queueing enabled da57: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da65 at mps1 bus 0 scbus6 target 47 lun 0 da65: Fixed Direct Access SCSI-6 device da65: 600.000MB/s transfers da65: Command Queueing enabled da65: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da61 at mps1 bus 0 scbus6 target 43 lun 0 da61: Fixed Direct Access SCSI-6 device da61: 600.000MB/s transfers da61: Command Queueing enabled da61: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da58 at mps1 bus 0 scbus6 target 40 lun 0 da58: Fixed Direct Access SCSI-6 device da58: 600.000MB/s transfers da58: Command Queueing enabled da58: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da63 at mps1 bus 0 scbus6 target 45 lun 0 da63: Fixed Direct Access SCSI-6 device da63: 600.000MB/s transfers da63: Command Queueing enabled da63: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da60 at mps1 bus 0 scbus6 target 42 lun 0 da60: Fixed Direct Access SCSI-6 device da60: 600.000MB/s transfers da60: Command Queueing enabled da60: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da62 at mps1 bus 0 scbus6 target 44 lun 0 da62: Fixed Direct Access SCSI-6 device da62: 600.000MB/s transfers da62: Command Queueing enabled da62: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da59 at mps1 bus 0 scbus6 target 41 lun 0 da59: Fixed Direct Access SCSI-6 device da59: 600.000MB/s transfers da59: Command Queueing enabled da59: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da55 at mps1 bus 0 scbus6 target 36 lun 0 da55: Fixed Direct Access SCSI-6 device da55: 600.000MB/s transfers da55: Command Queueing enabled da55: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da56 at mps1 bus 0 scbus6 target 38 lun 0 da56: Fixed Direct Access SCSI-6 device da56: 600.000MB/s transfers da56: Command Queueing enabled da56: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #5 Launched! - path too long make_dev_physpath_alias: WARNING - Unable to alias pass11 to enc@n5000ed572a857abd/type@0/slot@4/elmdesc@ArrayDevice03/pass11 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass12 to enc@n5000ed572a855cbd/type@0/slot@2/elmdesc@ArrayDevice01/pass12 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass13 to enc@n5000ed572a855cbd/type@0/slot@4/elmdesc@ArrayDevice03/pass13 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass14 to enc@n5000ed572a84e8bd/type@0/slot@2/elmdesc@ArrayDevice01/pass14 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass15 to enc@n5000ed572a84e8bd/type@0/slot@4/elmdesc@ArrayDevice03/pass15 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass16 to enc@n5000ed572a84f7bd/type@0/slot@2/elmdesc@ArrayDevice01/pass16 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass17 to enc@n5000ed572a84f7bd/type@0/slot@4/elmdesc@ArrayDevice03/pass17 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass18 to enc@n5000ed572a8548bd/type@0/slot@2/elmdesc@ArrayDevice01/pass18 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass19 to enc@n5000ed572a8548bd/type@0/slot@4/elmdesc@ArrayDevice03/pass19 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass20 to enc@n5000ed572eea93bd/type@0/slot@2/elmdesc@ArrayDevice01/pass20 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass21 to enc@n5000ed572eea93bd/type@0/slot@4/elmdesc@ArrayDevice03/pass21 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass22 to enc@n5000ed572eeae5bd/type@0/slot@2/elmdesc@ArrayDevice01/pass22 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass23 to enc@n5000ed572eeae5bd/type@0/slot@4/elmdesc@ArrayDevice03/pass23 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass24 to enc@n5000ed572a84eebd/type@0/slot@1/elmdesc@ArrayDevice00/pass24 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass25 to enc@n5000ed572a84eebd/type@0/slot@5/elmdesc@ArrayDevice04/pass25 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass26 to enc@n5000ed572a84eebd/type@0/slot@3/elmdesc@ArrayDevice02/pass26 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass27 to enc@n5000ed572a857abd/type@0/slot@1/elmdesc@ArrayDevice00/pass27 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass28 to enc@n5000ed572a857abd/type@0/slot@3/elmdesc@ArrayDevice02/pass28 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass29 to enc@n5000ed572a855cbd/type@0/slot@1/elmdesc@ArrayDevice00/pass29 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass30 to enc@n5000ed572a855cbd/type@0/slot@3/elmdesc@ArrayDevice02/pass30 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass31 to enc@n5000ed572a84e8bd/type@0/slot@1/elmdesc@ArrayDevice00/pass31 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass32 to enc@n5000ed572a84e8bd/type@0/slot@3/elmdesc@ArrayDevice02/pass32 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass33 to enc@n5000ed572eeae5bd/type@0/slot@1/elmdesc@ArrayDevice00/pass33 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass34 to enc@n5000ed572eeae5bd/type@0/slot@3/elmdesc@ArrayDevice02/pass34 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass35 to enc@n5000ed572eea93bd/type@0/slot@1/elmdesc@ArrayDevice00/pass35 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass36 to enc@n5000ed572eea93bd/type@0/slot@3/elmdesc@ArrayDevice02/pass36 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass37 to enc@n5000ed572a8548bd/type@0/slot@1/elmdesc@ArrayDevice00/pass37 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass38 to enc@n5000ed572a8548bd/type@0/slot@3/elmdesc@ArrayDevice02/pass38 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass39 to enc@n5000ed572a84f7bd/type@0/slot@1/elmdesc@ArrayDevice00/pass39 - path too long make_dev_physpath_alias: WARNING - Unable to alias pass40 to enc@n5000ed572a84f7bd/type@0/slot@3/elmdesc@ArrayDevice02/pass40 - path too long Timecounter "TSC-low" frequency 1197139808 Hz quality 1000 make_dev_physpath_alias: WARNING - Unable to alias da18p1 to enc@n5000ed572a84eebd/type@0/slot@3/elmdesc@ArrayDevice02/da18p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da18p9 to enc@n5000ed572a84eebd/type@0/slot@3/elmdesc@ArrayDevice02/da18p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da19p1 to enc@n5000ed572a857abd/type@0/slot@1/elmdesc@ArrayDevice00/da19p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da19p9 to enc@n5000ed572a857abd/type@0/slot@1/elmdesc@ArrayDevice00/da19p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da20p1 to enc@n5000ed572a857abd/type@0/slot@3/elmdesc@ArrayDevice02/da20p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da20p9 to enc@n5000ed572a857abd/type@0/slot@3/elmdesc@ArrayDevice02/da20p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da21p1 to enc@n5000ed572a855cbd/type@0/slot@1/elmdesc@ArrayDevice00/da21p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da21p9 to enc@n5000ed572a855cbd/type@0/slot@1/elmdesc@ArrayDevice00/da21p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da22p1 to enc@n5000ed572a855cbd/type@0/slot@3/elmdesc@ArrayDevice02/da22p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da22p9 to enc@n5000ed572a855cbd/type@0/slot@3/elmdesc@ArrayDevice02/da22p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da23p1 to enc@n5000ed572a84e8bd/type@0/slot@1/elmdesc@ArrayDevice00/da23p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da23p9 to enc@n5000ed572a84e8bd/type@0/slot@1/elmdesc@ArrayDevice00/da23p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da24p1 to enc@n5000ed572a84e8bd/type@0/slot@3/elmdesc@ArrayDevice02/da24p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da24p9 to enc@n5000ed572a84e8bd/type@0/slot@3/elmdesc@ArrayDevice02/da24p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da25p1 to enc@n5000ed572eeae5bd/type@0/slot@1/elmdesc@ArrayDevice00/da25p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da25p9 to enc@n5000ed572eeae5bd/type@0/slot@1/elmdesc@ArrayDevice00/da25p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da26p1 to enc@n5000ed572eeae5bd/type@0/slot@3/elmdesc@ArrayDevice02/da26p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da26p9 to enc@n5000ed572eeae5bd/type@0/slot@3/elmdesc@ArrayDevice02/da26p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da27p1 to enc@n5000ed572eea93bd/type@0/slot@1/elmdesc@ArrayDevice00/da27p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da27p9 to enc@n5000ed572eea93bd/type@0/slot@1/elmdesc@ArrayDevice00/da27p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da28p1 to enc@n5000ed572eea93bd/type@0/slot@3/elmdesc@ArrayDevice02/da28p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da28p9 to enc@n5000ed572eea93bd/type@0/slot@3/elmdesc@ArrayDevice02/da28p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da29p1 to enc@n5000ed572a8548bd/type@0/slot@1/elmdesc@ArrayDevice00/da29p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da29p9 to enc@n5000ed572a8548bd/type@0/slot@1/elmdesc@ArrayDevice00/da29p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da30p1 to enc@n5000ed572a8548bd/type@0/slot@3/elmdesc@ArrayDevice02/da30p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da30p9 to enc@n5000ed572a8548bd/type@0/slot@3/elmdesc@ArrayDevice02/da30p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da31p1 to enc@n5000ed572a84f7bd/type@0/slot@1/elmdesc@ArrayDevice00/da31p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da31p9 to enc@n5000ed572a84f7bd/type@0/slot@1/elmdesc@ArrayDevice00/da31p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias da32p1 to enc@n5000ed572a84f7bd/type@0/slot@3/elmdesc@ArrayDevice02/da32p1 - path too long make_dev_physpath_alias: WARNING - Unable to alias da32p9 to enc@n5000ed572a84f7bd/type@0/slot@3/elmdesc@ArrayDevice02/da32p9 - path too long make_dev_physpath_alias: WARNING - Unable to alias gpt/zfs to enc@n5000ed572a84eebd/type@0/slot@3/elmdesc@ArrayDevice02/gpt/zfs - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/6447b93b-97dd-2368-b04d-bef15a18f858 to enc@n5000ed572a84eebd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/6447b93b-97dd-2368-b04d-bef15a18f858 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/8fe6e00c-b58d-98ee-cce7-e7aa29ee766b to enc@n5000ed572a84eebd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/8fe6e00c-b58d-98ee-cce7-e7aa29ee766b - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/2574c034-b2cd-4bcd-8e7a-b5be9ab0c19a to enc@n5000ed572a857abd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/2574c034-b2cd-4bcd-8e7a-b5be9ab0c19a - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/f5dd93df-a88a-30c7-ae6f-83908f7e3053 to enc@n5000ed572a857abd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/f5dd93df-a88a-30c7-ae6f-83908f7e3053 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/4c0e9e05-68c0-524f-ed85-d355d60b2d04 to enc@n5000ed572a857abd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/4c0e9e05-68c0-524f-ed85-d355d60b2d04 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/2f16ecee-0a64-b46b-f2ae-884613e7b6bb to enc@n5000ed572a857abd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/2f16ecee-0a64-b46b-f2ae-884613e7b6bb - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/24b450a4-0a27-986b-91aa-b7859abd62aa to enc@n5000ed572a855cbd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/24b450a4-0a27-986b-91aa-b7859abd62aa - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/99581d89-15c6-e9c0-ea37-89bf17b3e853 to enc@n5000ed572a855cbd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/99581d89-15c6-e9c0-ea37-89bf17b3e853 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/ad37cc50-6734-a0eb-be5a-b7442e80ba27 to enc@n5000ed572a855cbd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/ad37cc50-6734-a0eb-be5a-b7442e80ba27 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/168eb8db-6bc1-874e-d740-9ebbecd38e70 to enc@n5000ed572a855cbd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/168eb8db-6bc1-874e-d740-9ebbecd38e70 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/168eb8db-6bc1-874e-d740-9ebbecd38e70 to enc@n5000ed572a855cbd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/168eb8db-6bc1-874e-d740-9ebbecd38e70 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/dc63799e-3dde-f044-b74c-96dc622dc8d6 to enc@n5000ed572a84e8bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/dc63799e-3dde-f044-b74c-96dc622dc8d6 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/50024da5-9fd6-16e6-934c-f05b9a2561e2 to enc@n5000ed572a84e8bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/50024da5-9fd6-16e6-934c-f05b9a2561e2 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/0ba76c59-b366-6ccd-abbb-cda59287e629 to enc@n5000ed572a84e8bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/0ba76c59-b366-6ccd-abbb-cda59287e629 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/6435d2dc-bdb4-3d67-9ea3-d47b809eb043 to enc@n5000ed572a84e8bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/6435d2dc-bdb4-3d67-9ea3-d47b809eb043 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/9d596376-379d-c1eb-f06e-c7c3658158d3 to enc@n5000ed572eeae5bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/9d596376-379d-c1eb-f06e-c7c3658158d3 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/2043980d-a743-34c7-e120-a5fbbe8dadaa to enc@n5000ed572eeae5bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/2043980d-a743-34c7-e120-a5fbbe8dadaa - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/c59b0dd9-ebaf-65ef-d5eb-cb84920c12f8 to enc@n5000ed572eeae5bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/c59b0dd9-ebaf-65ef-d5eb-cb84920c12f8 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/795379c1-ee16-576e-e948-e46e79651bc3 to enc@n5000ed572eeae5bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/795379c1-ee16-576e-e948-e46e79651bc3 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/c9ebcd78-5dd1-1bee-d9ae-e08857686fb4 to enc@n5000ed572eea93bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/c9ebcd78-5dd1-1bee-d9ae-e08857686fb4 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/74ca086a-31be-9ee3-f762-ec64bde6f106 to enc@n5000ed572eea93bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/74ca086a-31be-9ee3-f762-ec64bde6f106 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/3b374122-f24f-9ae5-b8de-d2f093d46d73 to enc@n5000ed572eea93bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/3b374122-f24f-9ae5-b8de-d2f093d46d73 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/4672ba2c-74a7-74e8-9d4c-aaf66fecddd6 to enc@n5000ed572eea93bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/4672ba2c-74a7-74e8-9d4c-aaf66fecddd6 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/43bf100d-1477-46e1-dd75-89ee60fc7998 to enc@n5000ed572a8548bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/43bf100d-1477-46e1-dd75-89ee60fc7998 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/34c1cfdd-2a5e-144f-852e-9307cdabb9ee to enc@n5000ed572a8548bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/34c1cfdd-2a5e-144f-852e-9307cdabb9ee - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/ae4e5ff9-4916-d6c5-986a-c719b5ed292a to enc@n5000ed572a8548bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/ae4e5ff9-4916-d6c5-986a-c719b5ed292a - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/ab35b006-c679-c265-a7b3-9ad3da6b53eb to enc@n5000ed572a8548bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/ab35b006-c679-c265-a7b3-9ad3da6b53eb - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/35a90ee4-fa69-aec0-99a3-92007947ace7 to enc@n5000ed572a84f7bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/35a90ee4-fa69-aec0-99a3-92007947ace7 - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/d088d7fd-5c65-e044-ce09-91d53385d0dd to enc@n5000ed572a84f7bd/type@0 /slot@1/elmdesc@ArrayDevice00/gptid/d088d7fd-5c65-e044-ce09-91d53385d0dd - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/e0caaf4a-9044-5268-9ee3-8827c49a46fb to enc@n5000ed572a84f7bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/e0caaf4a-9044-5268-9ee3-8827c49a46fb - path too long make_dev_physpath_alias: WARNING - Unable to alias gptid/5835ec24-f12c-8a62-fec0-90fad62719ff to enc@n5000ed572a84f7bd/type@0 /slot@3/elmdesc@ArrayDevice02/gptid/5835ec24-f12c-8a62-fec0-90fad62719ff - path too long Trying to mount root from ufs:/dev/ufsid/51dafdebbf60d3a5 [rw]... GEOM_NOP: Device da0.nop created. make_dev_physpath_alias: WARNING - Unable to alias da0.nop to enc@n5000ed572a84eebd/type@0/slot@2/elmdesc@ArrayDevice01/da0.nop - path too long GEOM_NOP: Device da1.nop created. make_dev_physpath_alias: WARNING - Unable to alias da1.nop to enc@n5000ed572a84eebd/type@0/slot@4/elmdesc@ArrayDevice03/da1.nop - path too long GEOM_NOP: Device da2.nop created. make_dev_physpath_alias: WARNING - Unable to alias da2.nop to enc@n5000ed572a857abd/type@0/slot@2/elmdesc@ArrayDevice01/da2.nop - path too long GEOM_NOP: Device da3.nop created. make_dev_physpath_alias: WARNING - Unable to alias da3.nop to enc@n5000ed572a857abd/type@0/slot@4/elmdesc@ArrayDevice03/da3.nop - path too long GEOM_NOP: Device da4.nop created. make_dev_physpath_alias: WARNING - Unable to alias da4.nop to enc@n5000ed572a855cbd/type@0/slot@2/elmdesc@ArrayDevice01/da4.nop - path too long GEOM_NOP: Device da5.nop created. make_dev_physpath_alias: WARNING - Unable to alias da5.nop to enc@n5000ed572a855cbd/type@0/slot@4/elmdesc@ArrayDevice03/da5.nop - path too long GEOM_NOP: Device da6.nop created. make_dev_physpath_alias: WARNING - Unable to alias da6.nop to enc@n5000ed572a84e8bd/type@0/slot@2/elmdesc@ArrayDevice01/da6.nop - path too long GEOM_NOP: Device da7.nop created. make_dev_physpath_alias: WARNING - Unable to alias da7.nop to enc@n5000ed572a84e8bd/type@0/slot@4/elmdesc@ArrayDevice03/da7.nop - path too long GEOM_NOP: Device da8.nop created. make_dev_physpath_alias: WARNING - Unable to alias da8.nop to enc@n5000ed572a84f7bd/type@0/slot@2/elmdesc@ArrayDevice01/da8.nop - path too long GEOM_NOP: Device da9.nop created. make_dev_physpath_alias: WARNING - Unable to alias da9.nop to enc@n5000ed572a84f7bd/type@0/slot@4/elmdesc@ArrayDevice03/da9.nop - path too long GEOM_NOP: Device da10.nop created. make_dev_physpath_alias: WARNING - Unable to alias da10.nop to enc@n5000ed572a8548bd/type@0/slot@2/elmdesc@ArrayDevice01/da10.nop - path too long GEOM_NOP: Device da11.nop created. make_dev_physpath_alias: WARNING - Unable to alias da11.nop to enc@n5000ed572a8548bd/type@0/slot@4/elmdesc@ArrayDevice03/da11.nop - path too long GEOM_NOP: Device da12.nop created. make_dev_physpath_alias: WARNING - Unable to alias da12.nop to enc@n5000ed572eea93bd/type@0/slot@2/elmdesc@ArrayDevice01/da12.nop - path too long GEOM_NOP: Device da13.nop created. make_dev_physpath_alias: WARNING - Unable to alias da13.nop to enc@n5000ed572eea93bd/type@0/slot@4/elmdesc@ArrayDevice03/da13.nop - path too long GEOM_NOP: Device da14.nop created. make_dev_physpath_alias: WARNING - Unable to alias da14.nop to enc@n5000ed572eeae5bd/type@0/slot@2/elmdesc@ArrayDevice01/da14.nop - path too long GEOM_NOP: Device da15.nop created. make_dev_physpath_alias: WARNING - Unable to alias da15.nop to enc@n5000ed572eeae5bd/type@0/slot@4/elmdesc@ArrayDevice03/da15.nop - path too long GEOM_NOP: Device da16.nop created. make_dev_physpath_alias: WARNING - Unable to alias da16.nop to enc@n5000ed572a84eebd/type@0/slot@1/elmdesc@ArrayDevice00/da16.nop - path too long GEOM_NOP: Device da18.nop created. make_dev_physpath_alias: WARNING - Unable to alias da18.nop to enc@n5000ed572a84eebd/type@0/slot@3/elmdesc@ArrayDevice02/da18.nop - path too long GEOM_NOP: Device da19.nop created. make_dev_physpath_alias: WARNING - Unable to alias da19.nop to enc@n5000ed572a857abd/type@0/slot@1/elmdesc@ArrayDevice00/da19.nop - path too long GEOM_NOP: Device da20.nop created. make_dev_physpath_alias: WARNING - Unable to alias da20.nop to enc@n5000ed572a857abd/type@0/slot@3/elmdesc@ArrayDevice02/da20.nop - path too long GEOM_NOP: Device da21.nop created. make_dev_physpath_alias: WARNING - Unable to alias da21.nop to enc@n5000ed572a855cbd/type@0/slot@1/elmdesc@ArrayDevice00/da21.nop - path too long GEOM_NOP: Device da22.nop created. make_dev_physpath_alias: WARNING - Unable to alias da22.nop to enc@n5000ed572a855cbd/type@0/slot@3/elmdesc@ArrayDevice02/da22.nop - path too long GEOM_NOP: Device da23.nop created. make_dev_physpath_alias: WARNING - Unable to alias da23.nop to enc@n5000ed572a84e8bd/type@0/slot@1/elmdesc@ArrayDevice00/da23.nop - path too long GEOM_NOP: Device da24.nop created. make_dev_physpath_alias: WARNING - Unable to alias da24.nop to enc@n5000ed572a84e8bd/type@0/slot@3/elmdesc@ArrayDevice02/da24.nop - path too long GEOM_NOP: Device da25.nop created. make_dev_physpath_alias: WARNING - Unable to alias da25.nop to enc@n5000ed572eeae5bd/type@0/slot@1/elmdesc@ArrayDevice00/da25.nop - path too long GEOM_NOP: Device da26.nop created. make_dev_physpath_alias: WARNING - Unable to alias da26.nop to enc@n5000ed572eeae5bd/type@0/slot@3/elmdesc@ArrayDevice02/da26.nop - path too long GEOM_NOP: Device da27.nop created. make_dev_physpath_alias: WARNING - Unable to alias da27.nop to enc@n5000ed572eea93bd/type@0/slot@1/elmdesc@ArrayDevice00/da27.nop - path too long GEOM_NOP: Device da28.nop created. make_dev_physpath_alias: WARNING - Unable to alias da28.nop to enc@n5000ed572eea93bd/type@0/slot@3/elmdesc@ArrayDevice02/da28.nop - path too long GEOM_NOP: Device da29.nop created. make_dev_physpath_alias: WARNING - Unable to alias da29.nop to enc@n5000ed572a8548bd/type@0/slot@1/elmdesc@ArrayDevice00/da29.nop - path too long GEOM_NOP: Device da30.nop created. make_dev_physpath_alias: WARNING - Unable to alias da30.nop to enc@n5000ed572a8548bd/type@0/slot@3/elmdesc@ArrayDevice02/da30.nop - path too long GEOM_NOP: Device da31.nop created. make_dev_physpath_alias: WARNING - Unable to alias da31.nop to enc@n5000ed572a84f7bd/type@0/slot@1/elmdesc@ArrayDevice00/da31.nop - path too long GEOM_NOP: Device da32.nop created. make_dev_physpath_alias: WARNING - Unable to alias da32.nop to enc@n5000ed572a84f7bd/type@0/slot@3/elmdesc@ArrayDevice02/da32.nop - path too long mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff8002112a30 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 982 command timeout cm 0xffffff8002112a30 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff8002112a30 allocated tm 0xffffff80020c47b0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 982 completed timedout cm 0xffffff8002112a30 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 982 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting TaskMID 982 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff8002361a30 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 982 command timeout cm 0xffffff8002361a30 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff8002361a30 allocated tm 0xffffff80023137b0 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 982 completed timedout cm 0xffffff8002361a30 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 982 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting TaskMID 982 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80020da6c0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 280 command timeout cm 0xffffff80020da6c0 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80020da6c0 allocated tm 0xffffff80020c48f8 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 280 completed timedout cm 0xffffff80020da6c0 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 7 abort TaskMID 280 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 7 finished recovery after aborting TaskMID 280 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff8002319680 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 80 command timeout cm 0xffffff8002319680 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff8002319680 allocated tm 0xffffff80023138f8 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 80 completed timedout cm 0xffffff8002319680 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 7 abort TaskMID 80 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 7 finished recovery after aborting TaskMID 80 mps1: mpssas_free_tm releasing simq mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80020dbc88 allocated tm 0xffffff80020c4a40 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 297 completed timedout cm 0xffffff80020dbc88 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 8 abort TaskMID 297 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 8 finished recovery after aborting TaskMID 297 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff800231ac48 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 97 command timeout cm 0xffffff800231ac48 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff800231ac48 allocated tm 0xffffff8002313a40 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 97 completed timedout cm 0xffffff800231ac48 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 8 abort TaskMID 97 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 8 finished recovery after aborting TaskMID 97 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80020dd250 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 314 command timeout cm 0xffffff80020dd250 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80020dd250 allocated tm 0xffffff80020c4b88 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 314 completed timedout cm 0xffffff80020dd250 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 9 abort TaskMID 314 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 9 finished recovery after aborting TaskMID 314 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Retrying command mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff800231c4a0 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 116 command timeout cm 0xffffff800231c4a0 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff800231c4a0 allocated tm 0xffffff8002313b88 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 116 completed timedout cm 0xffffff800231c4a0 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 9 abort TaskMID 116 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 9 finished recovery after aborting TaskMID 116 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Retrying command mps0: mpssas_scsiio_timeout checking sc 0xffffff80020a1000 cm 0xffffff80020debf0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 334 command timeout cm 0xffffff80020debf0 ccb 0xfffffe002bc3b800 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff80020debf0 allocated tm 0xffffff80020c4cd0 (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 334 completed timedout cm 0xffffff80020debf0 ccb 0xfffffe002bc3b800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:40:0): SMID 10 abort TaskMID 334 status 0x4a code 0x0 count 1 (noperiph:mps0:0:40:0): SMID 10 finished recovery after aborting TaskMID 334 mps0: mpssas_free_tm releasing simq (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe40:mps0:0:40:0): CAM status: Command timeout (probe40:mps0:0:40:0): Error 5, Retries exhausted mps1: mpssas_scsiio_timeout checking sc 0xffffff80022f0000 cm 0xffffff800231d7d8 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 131 command timeout cm 0xffffff800231d7d8 ccb 0xfffffe002bfc7800 mps1: mpssas_alloc_tm freezing simq mps1: timedout cm 0xffffff800231d7d8 allocated tm 0xffffff8002313cd0 (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 SMID 131 completed timedout cm 0xffffff800231d7d8 ccb 0xfffffe002bfc7800 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps1:0:37:0): SMID 10 abort TaskMID 131 status 0x4a code 0x0 count 1 (noperiph:mps1:0:37:0): SMID 10 finished recovery after aborting TaskMID 131 mps1: mpssas_free_tm releasing simq (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe292:mps1:0:37:0): CAM status: Command timeout (probe292:mps1:0:37:0): Error 5, Retries exhausted zpool status pool: master state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM master ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0.nop ONLINE 0 0 0 da1.nop ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 da2.nop ONLINE 0 0 0 da3.nop ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 da4.nop ONLINE 0 0 0 da5.nop ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 da6.nop ONLINE 0 0 0 da7.nop ONLINE 0 0 0 mirror-4 ONLINE 0 0 0 da8.nop ONLINE 0 0 0 da9.nop ONLINE 0 0 0 mirror-5 ONLINE 0 0 0 da10.nop ONLINE 0 0 0 da11.nop ONLINE 0 0 0 mirror-6 ONLINE 0 0 0 da12.nop ONLINE 0 0 0 da13.nop ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 da14.nop ONLINE 0 0 0 da15.nop ONLINE 0 0 0 mirror-8 ONLINE 0 0 0 da16.nop ONLINE 0 0 0 da18.nop ONLINE 0 0 0 mirror-9 ONLINE 0 0 0 da19.nop ONLINE 0 0 0 da20.nop ONLINE 0 0 0 mirror-10 ONLINE 0 0 0 da21.nop ONLINE 0 0 0 da22.nop ONLINE 0 0 0 mirror-11 ONLINE 0 0 0 da23.nop ONLINE 0 0 0 da24.nop ONLINE 0 0 0 mirror-12 ONLINE 0 0 0 da25.nop ONLINE 0 0 0 da26.nop ONLINE 0 0 0 mirror-13 ONLINE 0 0 0 da27.nop ONLINE 0 0 0 da28.nop ONLINE 0 0 0 mirror-14 ONLINE 0 0 0 da29.nop ONLINE 0 0 0 da30.nop ONLINE 0 0 0 mirror-15 ONLINE 0 0 0 da31.nop ONLINE 0 0 0 da32.nop ONLINE 0 0 0 errors: No known data errors sysctl -a | grep -i trim vfs.zfs.vdev.trim_on_init: 1 vfs.zfs.vdev.trim_max_pending: 64 vfs.zfs.vdev.trim_max_bytes: 2147483648 vfs.zfs.trim.enabled: 1 vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 158 kstat.zfs.misc.zio_trim.failed: 0 pciconf -l -vvv hostb0@pci0:0:0:0: class=0x060000 card=0x358c8086 chip=0x3c008086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMI2' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x358c8086 chip=0x3c028086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 1a' class = bridge subclass = PCI-PCI pcib2@pci0:0:2:0: class=0x060400 card=0x358c8086 chip=0x3c048086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 2a' class = bridge subclass = PCI-PCI pcib3@pci0:0:2:2: class=0x060400 card=0x358c8086 chip=0x3c068086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 2c' class = bridge subclass = PCI-PCI pcib4@pci0:0:3:0: class=0x060400 card=0x358c8086 chip=0x3c088086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode' class = bridge subclass = PCI-PCI pcib5@pci0:0:3:2: class=0x060400 card=0x358c8086 chip=0x3c0a8086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 3c' class = bridge subclass = PCI-PCI none0@pci0:0:4:0: class=0x088000 card=0x358c8086 chip=0x3c208086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 0' class = base peripheral none1@pci0:0:4:1: class=0x088000 card=0x358c8086 chip=0x3c218086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 1' class = base peripheral none2@pci0:0:4:2: class=0x088000 card=0x358c8086 chip=0x3c228086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 2' class = base peripheral none3@pci0:0:4:3: class=0x088000 card=0x358c8086 chip=0x3c238086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 3' class = base peripheral none4@pci0:0:4:4: class=0x088000 card=0x358c8086 chip=0x3c248086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 4' class = base peripheral none5@pci0:0:4:5: class=0x088000 card=0x358c8086 chip=0x3c258086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 5' class = base peripheral none6@pci0:0:4:6: class=0x088000 card=0x358c8086 chip=0x3c268086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 6' class = base peripheral none7@pci0:0:4:7: class=0x088000 card=0x358c8086 chip=0x3c278086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 7' class = base peripheral none8@pci0:0:5:0: class=0x088000 card=0x358c8086 chip=0x3c288086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Address Map, VTd_Misc, System Management' class = base peripheral none9@pci0:0:5:2: class=0x088000 card=0x358c8086 chip=0x3c2a8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Control Status and Global Errors' class = base peripheral ioapic0@pci0:0:5:4: class=0x080020 card=0x358c8086 chip=0x3c2c8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge I/O APIC' class = base peripheral subclass = interrupt controller pcib6@pci0:0:17:0: class=0x060400 card=0x358c8086 chip=0x1d3e8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' device = 'Patsburg PCI Express Virtual Root Port' class = bridge subclass = PCI-PCI none10@pci0:0:22:0: class=0x078000 card=0x358c8086 chip=0x1d3a8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg MEI Controller' class = simple comms none11@pci0:0:22:1: class=0x078000 card=0x358c8086 chip=0x1d3b8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg MEI Controller' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x358c8086 chip=0x1d2d8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib7@pci0:0:28:0: class=0x060400 card=0x358c8086 chip=0x1d108086 rev=0xb6 hdr=0x01 vendor = 'Intel Corporation' device = 'Patsburg PCI Express Root Port 1' class = bridge subclass = PCI-PCI pcib8@pci0:0:28:7: class=0x060400 card=0x358c8086 chip=0x1d1e8086 rev=0xb6 hdr=0x01 vendor = 'Intel Corporation' device = 'Patsburg PCI Express Root Port 8' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x358c8086 chip=0x1d268086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib9@pci0:0:30:0: class=0x060401 card=0x358c8086 chip=0x244e8086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x358c8086 chip=0x1d418086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg LPC Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:2: class=0x01018a card=0x358c8086 chip=0x1d008086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg 4-Port SATA IDE Controller' class = mass storage subclass = ATA none12@pci0:0:31:3: class=0x0c0500 card=0x358c8086 chip=0x1d228086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg SMBus Host Controller' class = serial bus subclass = SMBus atapci1@pci0:0:31:5: class=0x010185 card=0x358c8086 chip=0x1d088086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg 2-Port SATA IDE Controller' class = mass storage subclass = ATA ix0@pci0:2:0:0: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet ix1@pci0:2:0:1: class=0x020000 card=0x000c8086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet mps0@pci0:6:0:0: class=0x010700 card=0x30201000 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS isci0@pci0:7:0:0: class=0x010700 card=0x358d8086 chip=0x1d698086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg 4-Port SATA/SAS Storage Control Unit' class = mass storage subclass = SAS none13@pci0:7:0:3: class=0x0c0500 card=0x358c8086 chip=0x1d708086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg SMBus Controller 0' class = serial bus subclass = SMBus igb0@pci0:8:0:0: class=0x020000 card=0x358c8086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet igb1@pci0:8:0:1: class=0x020000 card=0x358c8086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet vgapci0@pci0:10:0:0: class=0x030000 card=0x01038086 chip=0x0522102b rev=0x04 hdr=0x00 vendor = 'Matrox Graphics, Inc.' device = 'MGA G200e [Pilot] ServerEngines (SEP1)' class = display subclass = VGA pcib11@pci0:128:3:0: class=0x060400 card=0x358c8086 chip=0x3c088086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode' class = bridge subclass = PCI-PCI pcib12@pci0:128:3:2: class=0x060400 card=0x358c8086 chip=0x3c0a8086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Sandy Bridge IIO PCI Express Root Port 3c' class = bridge subclass = PCI-PCI none14@pci0:128:4:0: class=0x088000 card=0x358c8086 chip=0x3c208086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 0' class = base peripheral none15@pci0:128:4:1: class=0x088000 card=0x358c8086 chip=0x3c218086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 1' class = base peripheral none16@pci0:128:4:2: class=0x088000 card=0x358c8086 chip=0x3c228086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 2' class = base peripheral none17@pci0:128:4:3: class=0x088000 card=0x358c8086 chip=0x3c238086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 3' class = base peripheral none18@pci0:128:4:4: class=0x088000 card=0x358c8086 chip=0x3c248086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 4' class = base peripheral none19@pci0:128:4:5: class=0x088000 card=0x358c8086 chip=0x3c258086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 5' class = base peripheral none20@pci0:128:4:6: class=0x088000 card=0x358c8086 chip=0x3c268086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 6' class = base peripheral none21@pci0:128:4:7: class=0x088000 card=0x358c8086 chip=0x3c278086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DMA Channel 7' class = base peripheral none22@pci0:128:5:0: class=0x088000 card=0x358c8086 chip=0x3c288086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Address Map, VTd_Misc, System Management' class = base peripheral none23@pci0:128:5:2: class=0x088000 card=0x358c8086 chip=0x3c2a8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Control Status and Global Errors' class = base peripheral ioapic1@pci0:128:5:4: class=0x080020 card=0x358c8086 chip=0x3c2c8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge I/O APIC' class = base peripheral subclass = interrupt controller mps1@pci0:130:0:0: class=0x010700 card=0x30201000 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS none24@pci0:127:8:0: class=0x088000 card=0x358c8086 chip=0x3c808086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QPI Link 0' class = base peripheral none25@pci0:127:9:0: class=0x088000 card=0x358c8086 chip=0x3c908086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QPI Link 1' class = base peripheral none26@pci0:127:10:0: class=0x088000 card=0x358c8086 chip=0x3cc08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 0' class = base peripheral none27@pci0:127:10:1: class=0x088000 card=0x00008086 chip=0x3cc18086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 1' class = base peripheral none28@pci0:127:10:2: class=0x088000 card=0x358c8086 chip=0x3cc28086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 2' class = base peripheral none29@pci0:127:10:3: class=0x088000 card=0x358c8086 chip=0x3cd08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 3' class = base peripheral none30@pci0:127:11:0: class=0x088000 card=0x358c8086 chip=0x3ce08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Interrupt Control Registers' class = base peripheral none31@pci0:127:11:3: class=0x088000 card=0x358c8086 chip=0x3ce38086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Semaphore and Scratchpad Configuration Registers' class = base peripheral none32@pci0:127:12:0: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none33@pci0:127:12:1: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none34@pci0:127:12:6: class=0x088000 card=0x358c8086 chip=0x3cf48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller System Address Decoder 0' class = base peripheral none35@pci0:127:12:7: class=0x088000 card=0x358c8086 chip=0x3cf68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge System Address Decoder' class = base peripheral none36@pci0:127:13:0: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none37@pci0:127:13:1: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none38@pci0:127:13:6: class=0x088000 card=0x358c8086 chip=0x3cf58086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller System Address Decoder 1' class = base peripheral none39@pci0:127:14:0: class=0x088000 card=0x358c8086 chip=0x3ca08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Processor Home Agent' class = base peripheral none40@pci0:127:14:1: class=0x110100 card=0x358c8086 chip=0x3c468086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Processor Home Agent Performance Monitoring' class = dasp none41@pci0:127:15:0: class=0x088000 card=0x358c8086 chip=0x3ca88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Registers' class = base peripheral none42@pci0:127:15:1: class=0x088000 card=0x358c8086 chip=0x3c718086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller RAS Registers' class = base peripheral none43@pci0:127:15:2: class=0x088000 card=0x358c8086 chip=0x3caa8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 0' class = base peripheral none44@pci0:127:15:3: class=0x088000 card=0x358c8086 chip=0x3cab8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 1' class = base peripheral none45@pci0:127:15:4: class=0x088000 card=0x358c8086 chip=0x3cac8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 2' class = base peripheral none46@pci0:127:15:5: class=0x088000 card=0x358c8086 chip=0x3cad8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 3' class = base peripheral none47@pci0:127:15:6: class=0x088000 card=0x00008086 chip=0x3cae8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 4' class = base peripheral none48@pci0:127:16:0: class=0x088000 card=0x358c8086 chip=0x3cb08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0' class = base peripheral none49@pci0:127:16:1: class=0x088000 card=0x358c8086 chip=0x3cb18086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1' class = base peripheral none50@pci0:127:16:2: class=0x088000 card=0x358c8086 chip=0x3cb28086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 0' class = base peripheral none51@pci0:127:16:3: class=0x088000 card=0x358c8086 chip=0x3cb38086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 1' class = base peripheral none52@pci0:127:16:4: class=0x088000 card=0x358c8086 chip=0x3cb48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2' class = base peripheral none53@pci0:127:16:5: class=0x088000 card=0x358c8086 chip=0x3cb58086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3' class = base peripheral none54@pci0:127:16:6: class=0x088000 card=0x358c8086 chip=0x3cb68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 2' class = base peripheral none55@pci0:127:16:7: class=0x088000 card=0x358c8086 chip=0x3cb78086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 3' class = base peripheral none56@pci0:127:17:0: class=0x088000 card=0x00008086 chip=0x3cb88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DDRIO' class = base peripheral none57@pci0:127:19:0: class=0x088000 card=0x358c8086 chip=0x3ce48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge R2PCIe' class = base peripheral none58@pci0:127:19:1: class=0x110100 card=0x358c8086 chip=0x3c438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to PCI Express Performance Monitor' class = dasp none59@pci0:127:19:4: class=0x110100 card=0x358c8086 chip=0x3ce68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QuickPath Interconnect Agent Ring Registers' class = dasp none60@pci0:127:19:5: class=0x110100 card=0x358c8086 chip=0x3c448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor' class = dasp none61@pci0:127:19:6: class=0x088000 card=0x358c8086 chip=0x3c458086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor' class = base peripheral none62@pci0:255:8:0: class=0x088000 card=0x358c8086 chip=0x3c808086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QPI Link 0' class = base peripheral none63@pci0:255:9:0: class=0x088000 card=0x358c8086 chip=0x3c908086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QPI Link 1' class = base peripheral none64@pci0:255:10:0: class=0x088000 card=0x358c8086 chip=0x3cc08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 0' class = base peripheral none65@pci0:255:10:1: class=0x088000 card=0x00008086 chip=0x3cc18086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 1' class = base peripheral none66@pci0:255:10:2: class=0x088000 card=0x358c8086 chip=0x3cc28086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 2' class = base peripheral none67@pci0:255:10:3: class=0x088000 card=0x358c8086 chip=0x3cd08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Power Control Unit 3' class = base peripheral none68@pci0:255:11:0: class=0x088000 card=0x358c8086 chip=0x3ce08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Interrupt Control Registers' class = base peripheral none69@pci0:255:11:3: class=0x088000 card=0x358c8086 chip=0x3ce38086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Semaphore and Scratchpad Configuration Registers' class = base peripheral none70@pci0:255:12:0: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none71@pci0:255:12:1: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none72@pci0:255:12:6: class=0x088000 card=0x358c8086 chip=0x3cf48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller System Address Decoder 0' class = base peripheral none73@pci0:255:12:7: class=0x088000 card=0x358c8086 chip=0x3cf68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge System Address Decoder' class = base peripheral none74@pci0:255:13:0: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none75@pci0:255:13:1: class=0x088000 card=0x358c8086 chip=0x3ce88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Unicast Register 0' class = base peripheral none76@pci0:255:13:6: class=0x088000 card=0x358c8086 chip=0x3cf58086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller System Address Decoder 1' class = base peripheral none77@pci0:255:14:0: class=0x088000 card=0x358c8086 chip=0x3ca08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Processor Home Agent' class = base peripheral none78@pci0:255:14:1: class=0x110100 card=0x358c8086 chip=0x3c468086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Processor Home Agent Performance Monitoring' class = dasp none79@pci0:255:15:0: class=0x088000 card=0x358c8086 chip=0x3ca88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Registers' class = base peripheral none80@pci0:255:15:1: class=0x088000 card=0x358c8086 chip=0x3c718086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller RAS Registers' class = base peripheral none81@pci0:255:15:2: class=0x088000 card=0x358c8086 chip=0x3caa8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 0' class = base peripheral none82@pci0:255:15:3: class=0x088000 card=0x358c8086 chip=0x3cab8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 1' class = base peripheral none83@pci0:255:15:4: class=0x088000 card=0x358c8086 chip=0x3cac8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 2' class = base peripheral none84@pci0:255:15:5: class=0x088000 card=0x358c8086 chip=0x3cad8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 3' class = base peripheral none85@pci0:255:15:6: class=0x088000 card=0x00008086 chip=0x3cae8086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Target Address Decoder 4' class = base peripheral none86@pci0:255:16:0: class=0x088000 card=0x358c8086 chip=0x3cb08086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 0' class = base peripheral none87@pci0:255:16:1: class=0x088000 card=0x358c8086 chip=0x3cb18086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 1' class = base peripheral none88@pci0:255:16:2: class=0x088000 card=0x358c8086 chip=0x3cb28086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 0' class = base peripheral none89@pci0:255:16:3: class=0x088000 card=0x358c8086 chip=0x3cb38086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 1' class = base peripheral none90@pci0:255:16:4: class=0x088000 card=0x358c8086 chip=0x3cb48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 2' class = base peripheral none91@pci0:255:16:5: class=0x088000 card=0x358c8086 chip=0x3cb58086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller Channel 0-3 Thermal Control 3' class = base peripheral none92@pci0:255:16:6: class=0x088000 card=0x358c8086 chip=0x3cb68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 2' class = base peripheral none93@pci0:255:16:7: class=0x088000 card=0x358c8086 chip=0x3cb78086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Integrated Memory Controller ERROR Registers 3' class = base peripheral none94@pci0:255:17:0: class=0x088000 card=0x00008086 chip=0x3cb88086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge DDRIO' class = base peripheral none95@pci0:255:19:0: class=0x088000 card=0x358c8086 chip=0x3ce48086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge R2PCIe' class = base peripheral none96@pci0:255:19:1: class=0x110100 card=0x358c8086 chip=0x3c438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to PCI Express Performance Monitor' class = dasp none97@pci0:255:19:4: class=0x110100 card=0x358c8086 chip=0x3ce68086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge QuickPath Interconnect Agent Ring Registers' class = dasp none98@pci0:255:19:5: class=0x110100 card=0x358c8086 chip=0x3c448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to QuickPath Interconnect Link 0 Performance Monitor' class = dasp none99@pci0:255:19:6: class=0x088000 card=0x358c8086 chip=0x3c458086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Sandy Bridge Ring to QuickPath Interconnect Link 1 Performance Monitor' class = base peripheral usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA) ugen1.4: at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA) > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:46:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB57CE37 for ; Tue, 9 Jul 2013 15:46:24 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id B79CA1914 for ; Tue, 9 Jul 2013 15:46:24 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n9so8096395oag.22 for ; Tue, 09 Jul 2013 08:46:24 -0700 (PDT) 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=UQpcklbL/x//h5kRbj3SuVpgy9BDAY3nF4g2iQK9xC0=; b=pssP7WNW+na95jmKg8ynC6FUebh+hFzL/4ArfYkmvafCoNnkEfPWwhbGbGs38WMZUr /BsLzG1S1PsCZJK5Z+ftM9EiSKiMFCov48IG+srIP5GgkpWmiVDIw+mIboek90/w5Ybt ACAn2MTvJm2HyvIKDFDQjxGo0x4vQ8nAdvvKWIdVuAf6LxyCS2iW4mx+HTKBgTxlqHlE vnnbSbSJ0/qyqNWu6IaKaIYBJVosG64DEIziJZULuMly56ZwwqmPwi7HZMp5MlZIxIIS ws14vbKCyvrguBAYQ7OaKzoFLYgQJWnE1OdOgMr6ey65QkSomkFd9/lu4jXr9XU+jPHQ sU3g== MIME-Version: 1.0 X-Received: by 10.60.35.40 with SMTP id e8mr25006985oej.34.1373384784335; Tue, 09 Jul 2013 08:46:24 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Tue, 9 Jul 2013 08:46:24 -0700 (PDT) In-Reply-To: <20130709153058.GA8769@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> <20130709144614.GA7538@icarus.home.lan> <20130709153058.GA8769@icarus.home.lan> Date: Tue, 9 Jul 2013 11:46:24 -0400 Message-ID: Subject: Re: Stable/9 from today mpssas_scsiio timeouts From: Outback Dingo To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:46:25 -0000 On Tue, Jul 9, 2013 at 11:30 AM, Jeremy Chadwick wrote: > On Tue, Jul 09, 2013 at 11:20:45AM -0400, Outback Dingo wrote: > > On Tue, Jul 9, 2013 at 10:46 AM, Jeremy Chadwick wrote: > > > > > On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > > > > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo < > outbackdingo@gmail.com > > > >wrote: > > > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick > > > wrote: > > > > > > > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > > > >> > as of stable today im seeing alot of new mps time outs > > > > >> > > > > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 > UTC > > > 2013 > > > > >> > root@:/usr/obj/nas/usr/src/sys/ > > > > >> > > > > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 > > > chip=0x00721000 > > > > >> > rev=0x03 hdr=0x00 > > > > >> > vendor = 'LSI Logic / Symbios Logic' > > > > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > > > >> > class = mass storage > > > > >> > subclass = SAS > > > > >> > > > > > >> > > > > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > > > >> > 0xffffff80021a6b78 > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > > SMID > > > > >> 983 > > > > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > > > >> > mps0: mpssas_alloc_tm freezing simq > > > > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm > 0xffffff80021587b0 > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > > SMID > > > > >> 983 > > > > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > > during > > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a > code > > > 0x0 > > > > >> count > > > > >> > 1 > > > > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting > > > TaskMID > > > > >> 983 > > > > >> > mps0: mpssas_free_tm releasing simq > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > > > > >> > (probe40:mps0:0:40:0): Retrying command > > > > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > > > >> > 0xffffff80023e5b78 > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length > 36 > > > SMID > > > > >> 983 > > > > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > > > >> > mps1: mpssas_alloc_tm freezing simq > > > > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm > 0xffffff80023977b0 > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length > 36 > > > SMID > > > > >> 983 > > > > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > > during > > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a > code > > > 0x0 > > > > >> count > > > > >> > 1 > > > > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting > > > TaskMID > > > > >> 983 > > > > >> > mps1: mpssas_free_tm releasing simq > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > > > > >> > (probe292:mps1:0:37:0): Retrying command > > > > >> > > > > >> 1. What revision were you running before (i.e. what were you on > prior > > > to > > > > >> the upgrade)? > > > > >> > > > > > > > > > > > > > > > Sorry I was on 252595 from July 3 > > > > > > And does rolling back to r252595 resolve the problem for you? > > > > > > Because the only commit I see between r253035 and r252595 that might > > > account for some kind of behavioural change, unless I missed one while > > > skimming the commit history, is the following: > > > > > > r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 > > > > > > If at all possible, please try updating to r253037 or newer to see > > > if that has some effect/improvement. Why I mention that commit: > > > > > > r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 > > > > > > Because the only mps(4) changes done in recent days are: > > > > > > http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log > > > > > > r253037 > > > r251899 > > > r251874 > > > > > > > i can say this its between July 4, and 253048, im rolling back to 252723 > to > > validate a good known working state > > Looking at your dmesg, it looks like the "errors" might be for SAS ports > which don't have any actual devices (disks) attached to them, yet parts > of the kernel (not sure which layer) are still trying to submit INQUIRY > commands to those ports as if they did have disks attached. > > It looks like you see this behaviour on boot up, and then later during > normal operation at some point (a LUN scan or rescan or "bus taste" > might cause this to happen; for example I know that "zpool import" in > effect can sometimes cause this behaviour -- on one of my systems "zpool > import" would cause the servers' floppy drive to spin up/chunk briefly). > > I'm hoping Steven or mav@ might be able to confirm/deny my theory here. > I see it even trying to write to the pool via NFS or FTP, which even times out on large files now, it was all working, and there are 2 controllers setup in an HA configuration, but they did work fine before, so ill roll back and try an earlier kernel then walk forward till i hit the problem. my only issue was i moved forward to get the newer ixgbe driver and others just commited to stable then to find that SAS was now quirky, welcome to stable. Either way the overall performance on this box has been in question, just havent been able to confirm its the enclosure, the nic card, or the zpool which is degraded, but 40MB/s via NFS on a 10GBe nic isnt good. so tweaking and testing seems to be mute until the box is at least stable again. I do appreciate the insight, and will do whatevers needed to hammer down the issue so it can be resolved. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:56:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 753EB38B for ; Tue, 9 Jul 2013 15:56:32 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 38A7E19A2 for ; Tue, 9 Jul 2013 15:56:32 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r69FuRRf026881; Tue, 9 Jul 2013 11:56:27 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r69FuRnq026880; Tue, 9 Jul 2013 11:56:27 -0400 (EDT) (envelope-from wollman) Date: Tue, 9 Jul 2013 11:56:27 -0400 (EDT) From: Garrett Wollman Message-Id: <201307091556.r69FuRnq026880@hergotha.csail.mit.edu> To: feld@feld.me Subject: Re: perl upgrade woes -- how to best reconcile? In-Reply-To: References: Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 09 Jul 2013 11:56:27 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:56:32 -0000 In article , feld@feld.me writes: >I've had zero problems with upgrades to Perl, etc after I stopped >compiling my packages in the host OS and started building the packages via >poudriere and using pkgng (sysutils/pkg). pkg can detect when a perl >upgrade is happening and is intelligent enough to reinstall all programs >that require perl; poudriere is smart enough to rebuild and repackage them >all. It's a match made in heaven and dead simple to use. This. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 15:56:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E8C648F for ; Tue, 9 Jul 2013 15:56:56 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 3012519B3 for ; Tue, 9 Jul 2013 15:56:56 +0000 (UTC) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 7CEC741C084; Tue, 9 Jul 2013 17:56:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QRiK40EPqckO; Tue, 9 Jul 2013 17:56:43 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 4056341C076; Tue, 9 Jul 2013 17:56:43 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 7204773A31; Tue, 9 Jul 2013 08:56:41 -0700 (PDT) Date: Tue, 9 Jul 2013 08:56:41 -0700 From: Jeremy Chadwick To: Outback Dingo Subject: Re: Stable/9 from today mpssas_scsiio timeouts Message-ID: <20130709155641.GA9350@icarus.home.lan> References: <20130709123900.GA5828@icarus.home.lan> <20130709144614.GA7538@icarus.home.lan> <20130709153058.GA8769@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:56:56 -0000 On Tue, Jul 09, 2013 at 11:46:24AM -0400, Outback Dingo wrote: > On Tue, Jul 9, 2013 at 11:30 AM, Jeremy Chadwick wrote: > > > On Tue, Jul 09, 2013 at 11:20:45AM -0400, Outback Dingo wrote: > > > On Tue, Jul 9, 2013 at 10:46 AM, Jeremy Chadwick wrote: > > > > > > > On Tue, Jul 09, 2013 at 09:47:01AM -0400, Outback Dingo wrote: > > > > > On Tue, Jul 9, 2013 at 9:44 AM, Outback Dingo < > > outbackdingo@gmail.com > > > > >wrote: > > > > > > On Tue, Jul 9, 2013 at 8:39 AM, Jeremy Chadwick > > > > wrote: > > > > > > > > > > > >> On Tue, Jul 09, 2013 at 05:32:39AM -0400, Outback Dingo wrote: > > > > > >> > as of stable today im seeing alot of new mps time outs > > > > > >> > > > > > > >> > 9.1-STABLE FreeBSD 9.1-STABLE #0 r253035M: Mon Jul 8 16:34:28 > > UTC > > > > 2013 > > > > > >> > root@:/usr/obj/nas/usr/src/sys/ > > > > > >> > > > > > > >> > mps1@pci0:130:0:0: class=0x010700 card=0x30201000 > > > > chip=0x00721000 > > > > > >> > rev=0x03 hdr=0x00 > > > > > >> > vendor = 'LSI Logic / Symbios Logic' > > > > > >> > device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' > > > > > >> > class = mass storage > > > > > >> > subclass = SAS > > > > > >> > > > > > > >> > > > > > > >> > mps0: mpssas_scsiio_timeout checking sc 0xffffff8002145000 cm > > > > > >> > 0xffffff80021a6b78 > > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > > > SMID > > > > > >> 983 > > > > > >> > command timeout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > > > > >> > mps0: mpssas_alloc_tm freezing simq > > > > > >> > mps0: timedout cm 0xffffff80021a6b78 allocated tm > > 0xffffff80021587b0 > > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 length 36 > > > > SMID > > > > > >> 983 > > > > > >> > completed timedout cm 0xffffff80021a6b78 ccb 0xfffffe002bb5f800 > > > > during > > > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > > > >> > (noperiph:mps0:0:40:0): SMID 6 abort TaskMID 983 status 0x4a > > code > > > > 0x0 > > > > > >> count > > > > > >> > 1 > > > > > >> > (noperiph:mps0:0:40:0): SMID 6 finished recovery after aborting > > > > TaskMID > > > > > >> 983 > > > > > >> > mps0: mpssas_free_tm releasing simq > > > > > >> > (probe40:mps0:0:40:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > > > >> > (probe40:mps0:0:40:0): CAM status: Command timeout > > > > > >> > (probe40:mps0:0:40:0): Retrying command > > > > > >> > mps1: mpssas_scsiio_timeout checking sc 0xffffff8002384000 cm > > > > > >> > 0xffffff80023e5b78 > > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length > > 36 > > > > SMID > > > > > >> 983 > > > > > >> > command timeout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > > > > >> > mps1: mpssas_alloc_tm freezing simq > > > > > >> > mps1: timedout cm 0xffffff80023e5b78 allocated tm > > 0xffffff80023977b0 > > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 length > > 36 > > > > SMID > > > > > >> 983 > > > > > >> > completed timedout cm 0xffffff80023e5b78 ccb 0xfffffe002be14800 > > > > during > > > > > >> > recovery ioc 8048 scsi 0 state c xfer 0 > > > > > >> > (noperiph:mps1:0:37:0): SMID 6 abort TaskMID 983 status 0x4a > > code > > > > 0x0 > > > > > >> count > > > > > >> > 1 > > > > > >> > (noperiph:mps1:0:37:0): SMID 6 finished recovery after aborting > > > > TaskMID > > > > > >> 983 > > > > > >> > mps1: mpssas_free_tm releasing simq > > > > > >> > (probe292:mps1:0:37:0): INQUIRY. CDB: 12 00 00 00 24 00 > > > > > >> > (probe292:mps1:0:37:0): CAM status: Command timeout > > > > > >> > (probe292:mps1:0:37:0): Retrying command > > > > > >> > > > > > >> 1. What revision were you running before (i.e. what were you on > > prior > > > > to > > > > > >> the upgrade)? > > > > > >> > > > > > > > > > > > > > > > > > > Sorry I was on 252595 from July 3 > > > > > > > > And does rolling back to r252595 resolve the problem for you? > > > > > > > > Because the only commit I see between r253035 and r252595 that might > > > > account for some kind of behavioural change, unless I missed one while > > > > skimming the commit history, is the following: > > > > > > > > r252730 -- http://www.freshbsd.org/commit/freebsd/r252730 > > > > > > > > If at all possible, please try updating to r253037 or newer to see > > > > if that has some effect/improvement. Why I mention that commit: > > > > > > > > r253037 -- http://www.freshbsd.org/commit/freebsd/r253037 > > > > > > > > Because the only mps(4) changes done in recent days are: > > > > > > > > http://svnweb.freebsd.org/base/stable/9/sys/dev/mps/mps_sas.c?view=log > > > > > > > > r253037 > > > > r251899 > > > > r251874 > > > > > > > > > > i can say this its between July 4, and 253048, im rolling back to 252723 > > to > > > validate a good known working state > > > > Looking at your dmesg, it looks like the "errors" might be for SAS ports > > which don't have any actual devices (disks) attached to them, yet parts > > of the kernel (not sure which layer) are still trying to submit INQUIRY > > commands to those ports as if they did have disks attached. > > > > It looks like you see this behaviour on boot up, and then later during > > normal operation at some point (a LUN scan or rescan or "bus taste" > > might cause this to happen; for example I know that "zpool import" in > > effect can sometimes cause this behaviour -- on one of my systems "zpool > > import" would cause the servers' floppy drive to spin up/chunk briefly). > > > > I'm hoping Steven or mav@ might be able to confirm/deny my theory here. > > > > I see it even trying to write to the pool via NFS or FTP, which even times > out on large files > now, it was all working, and there are 2 controllers setup in an HA > configuration, but they did > work fine before, so ill roll back and try an earlier kernel then walk > forward till i hit the problem. > my only issue was i moved forward to get the newer ixgbe driver and others > just commited to stable > then to find that SAS was now quirky, welcome to stable. Either way the > overall performance > on this box has been in question, just havent been able to confirm its the > enclosure, the nic card, > or the zpool which is degraded, but 40MB/s via NFS on a 10GBe nic isnt > good. so tweaking and > testing seems to be mute until the box is at least stable again. I do > appreciate the insight, and will > do whatevers needed to hammer down the issue so it can be resolved. Again, I would strongly suggest trying r253037 or newer first. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 16:36:16 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B321D2A6; Tue, 9 Jul 2013 16:36:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4E41C01; Tue, 9 Jul 2013 16:36:16 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id C0BE578AC; Tue, 9 Jul 2013 16:36:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us C0BE578AC Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 9 Jul 2013 12:36:12 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: Heads-Up: Schedule for 9.2-RELEASE Message-ID: <20130709163612.GA24753@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:36:16 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It was brought to our attention that this was not announced on -stable before now. That is my fault. This is a reminder that the Code Slush (aka "Feature Freeze") for 9.2-RELEASE is in effect. The Code Slush is different from the Code Freeze in that you do not need to ask re@ permission for every commit, however with Code Slush we ask that you stop adding new features and focus more on fixing any issues in the existing code. As a reminder, the schedule for 9.2-RELEASE is as follows: stable/9 slush: July 6, 2013 stable/9 freeze: July 12, 2013 BETA1 build starts: July 19, 2013 BETA2 build starts: July 26, 2013 RC1 build starts: August 2, 2013 RC2 build starts: August 9, 2013 RC3 build starts: August 16, 2013 RELEASE build starts: August 23, 2013 RELEASE announcement: August 31, 2013 If you are aware of any problems in stable/9, please let re@ know. Glen On behalf of: re@ --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJR3Dv8AAoJEFJPDDeguUajlTwIAKsSSpvDYOWPvfuVfNswU5sz s6CAGB9XrwjZ0O0SeQjMW7MHZJStok1KqbFBpu4i7fqowjFtsBiWxsWr5/8OV+No J16YamnwcuR9duWqTZpcKg4dj2equpPCZF8ot0hibUHEsTnjEoWkLzr/F9oNsZqH dT/gNjVRxkS4gNqyozIVap+xQqNBHvOsxroKPD/TbRG3ABUZ9wiHeM96mhKqTojc 4PajHwrtafHBciQSdYtLd6yIiTStaBB8IbPPtHddnqggSWd6MH10L7dVim4yApUm 9Pp92xrEyjstbbq0XK1RLcklTIgUr7FWWim80TKYwWdIxnKiULx23E8w5bujysE= =D1LS -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 18:08:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0FB9159 for ; Tue, 9 Jul 2013 18:08:35 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7076C1144 for ; Tue, 9 Jul 2013 18:08:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UwcKy-00016X-GY for freebsd-stable@freebsd.org; Tue, 09 Jul 2013 20:08:28 +0200 Received: from p5482be42.dip0.t-ipconnect.de ([84.130.190.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Jul 2013 20:08:28 +0200 Received: from sperber by p5482be42.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Jul 2013 20:08:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Michael Sperber Subject: Weird regex behavior on 9.1-RELEASE on amd64 in 32-bit mode Date: Tue, 09 Jul 2013 20:08:22 +0200 Lines: 40 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5482be42.dip0.t-ipconnect.de User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b33 (darwin) Cancel-Lock: sha1:Qeq/Eb1PzJ2ISUC47HD2qC5IIo0= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:08:35 -0000 I noticed that scsh (which only runs in 32-bit mode) fails on amd64. I narrowed it down to a regex malfunction (I think). This program: ----snip---- #include #include int main(void) { regex_t r; int status = regcomp(&r, "/afs", REG_EXTENDED); size_t nmatch = 1 + r.re_nsub; regmatch_t pmatch[32]; status = regexec(&r, "/afs/informatik", nmatch, pmatch, 0); { int i; for(i = 0; i < nmatch; i--) { printf("%d: %d - %d\n", i, (int) pmatch[i].rm_so, (int) pmatch[i].rm_eo); } } return 0; } ----snip---- This giveds me: # gcc r.c # ./a.out 0: 0 - 4 # gcc -m32 r.c # ./a.out 0: 0 - 0 Is it me or is there a bug? Help would be much appreciated! -- Regards, Mike From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 18:23:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BC10B09 for ; Tue, 9 Jul 2013 18:23: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 928991229 for ; Tue, 9 Jul 2013 18:23:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r69INO2g095110; Tue, 9 Jul 2013 21:23:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r69INO2g095110 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r69INNUc095109; Tue, 9 Jul 2013 21:23:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jul 2013 21:23:23 +0300 From: Konstantin Belousov To: Michael Sperber Subject: Re: Weird regex behavior on 9.1-RELEASE on amd64 in 32-bit mode Message-ID: <20130709182323.GT91021@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VpUBlsHIhxZRXmtQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:23:34 -0000 --VpUBlsHIhxZRXmtQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2013 at 08:08:22PM +0200, Michael Sperber wrote: >=20 > I noticed that scsh (which only runs in 32-bit mode) fails on amd64. I > narrowed it down to a regex malfunction (I think). This program: >=20 > ----snip---- > #include > #include >=20 > int > main(void) > { > regex_t r; > int status =3D regcomp(&r, "/afs", REG_EXTENDED); > size_t nmatch =3D 1 + r.re_nsub; > regmatch_t pmatch[32]; > status =3D regexec(&r, "/afs/informatik", nmatch, pmatch, 0); > { > int i; > for(i =3D 0; i < nmatch; i--) { > printf("%d: %d - %d\n", i, (int) pmatch[i].rm_so, (int) pmatch[i].r= m_eo); > } > } > return 0; > } > ----snip---- >=20 > This giveds me: >=20 > # gcc r.c > # ./a.out > 0: 0 - 4 > # gcc -m32 r.c > # ./a.out > 0: 0 - 0 >=20 > Is it me or is there a bug? Help would be much appreciated! -m32 does not work on stable. You need HEAD. --VpUBlsHIhxZRXmtQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3FUbAAoJEJDCuSvBvK1BesIP/1+C2iJGUjRMYRRxiuRAd31H XomH7+JmKofREDqJqHggIVSe6buMyHrmSPamUgGc1tebTq/5eUnf1DzG5Kn97bN1 QO30joh495h1FK9mSbyv+GGhVlMQMpipTU5DfFpflRcfCzpnW7MRYjKMkJBTba5I 1gTUyx0HBEReF7e/1rOZ54BP2ND25owoHWvIz27uHKdTol6In5gvNbeQOs7E4j1o bwID21xh3A9YPReVD39zfFzfRIGwnnyITdQcm8r9P3Fp3tA0L4J5By9Vs4Y41ETm SdscRzfeX+l7kB/GrzDgjWOnOLS6OoNOZHhpPY+gIBIh3Ibe/qITu9Gd0zcvTSpg LS8IEvRwZjc1qsfYNpSn2W0mBKoNV7TnCL96AcIrfzYsu9xm6o+Q+WckhTDMqZdS idNES7/hd86Bv7iNQS+jWPO14AHl+FtMFbNFTh3p5POC11jN8cAtmdoz+mMNePuc ble5YCV84+Vz3Gr0YIbIw40Sl0/HbHjPUkN5U6lAIqPh4bltbBgogBp9fN0vnKNa SI0yDjD8HdvjA0vQYnrEHtTZRDvTMa/DsDJcT2goI5qI5y9NAirobppjJNPno8HD uMpeHOOOLoR1fdKs/sg2QiUibW/nfzlGAxPQCX5fMpuZravAO5N+FT1W+WBR9pkA sUr96oBO7AjZ4NMU9Rcz =Nn75 -----END PGP SIGNATURE----- --VpUBlsHIhxZRXmtQ-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 18:24:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 783A4C16 for ; Tue, 9 Jul 2013 18:24:19 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 375251242 for ; Tue, 9 Jul 2013 18:24:18 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r69IOEa8000519; Tue, 9 Jul 2013 11:24:20 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r69IO8A6000513; Tue, 9 Jul 2013 11:24:08 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 9 Jul 2013 11:24:08 -0700 (PDT) Message-ID: <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> In-Reply-To: <51DBEB9F.7020803@wenks.ch> References: <51DBEB9F.7020803@wenks.ch> Date: Tue, 9 Jul 2013 11:24:08 -0700 (PDT) Subject: Re: perl upgrade woes -- how to best reconcile? From: "Chris H" To: "Fabian Wenk" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:24:19 -0000 Greetings Fabian, and thank you for your reply. > Hello Chris > > On 09.07.2013 11:18, Chris H wrote: >> How do I best sort this all out. I _really_ miss the perl_after_upgrade script, that >> used to accompany this process. > > I also had some challenges with this perl upgrade, but I used > portupgrade. In the end I created a custom script based on the > output from 'portupgrade -nrf perl' which did the following: > > #!/usr/local/bin/bash > set -e > portupgrade -f lang/perl5.12 > portupgrade -f converters/p5-MIME-Base64 > portupgrade -f devel/p5-Test-Harness > portupgrade -f devel/p5-Locale-Maketext-Simple > [...] > > This script does abort, when a single command fails, so you see > what fails and you can fix it. Eventually you will need to check > dependencies and rebuild one of the ports now, which is later in > the script. When the failed port did build, then remove the > already done ports from the script and restart it. > > At the end I also did check the folders in /usr/local/lib/perl5/ > for left overs in the folders from the old perl version. I then > used pkg_which to find out to which port the belongs and did also > a portupgrade -f for this port too. Thanks for that. I also considered cobbling a script to reconcile things, but in the end, felt simply un-installing Perl and the some 200 modules would be both faster, and less prone to failure. > > In the end everything was fine, but it took a little more effort, > as I had around 235 ports to rebuild. But as long as you stay > with e.g. perl 5.12.x, it is easier then before with the > perl_after_upgrade script for minor updates. I ran into problems in my first attempt to use portmaster(8), issuing portmaster -a. It failed on a number of ports, and I was forced to run it several times. I had some difficulty with it given that not all the options are quite clear -- "-s", for example. One can only infer it's action(s) from the context it used within the man(1) page, it doesn't literally explain it's intent. In the end, I was forced to perform many "make reinstall" jobs, which left the dependency records _way_ out-of-whack -- pkg_info: pkg_info: corrupted record (pkgdep line without argument), ignoring. Forcing me to resolve the issue by cobbling && running the following: grep "^@pkgdep" /var/db/pkg/*/+CONTENTS | awk '{ if (NF != 2) { print $1 } }' | cut -d':' -f1 I redirected the output to a file, where I then "cat | sort -u" to another file, which left me with a list of the ports to reconcile. performing a "portmaster --check-depends" resolved the problem. I guess the only _sure-fire_ way to resolve my issue, is to catalog all of my installed Perl modules, and remove Perl 5.12, and the modules. re-install Perl 5.12.5, and cobble a script to install all the modules I currently have installed. My perl5 tree currently looks like: /usr/local/lib/perl5/5.12/man/ man3/ whatis /usr/local/lib/perl5/5.12.4/ man3/ whatis What a mess! In the end, I guess the moral of the story is; don't upgrade. I've been on BSD since the late 70's, and as such, am no stranger to the upgrade path. But recent experience seems to show, things aren't getting any easier (or necessarily better). :( > > The next big challenge then will be the upgrade to e.g. 5.14.x or > 5.16.x. I don't think I'm even willing to go there, after this mess. Thanks again, for taking the time to respond. --chris > > > bye > Fabian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 19:02:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9411C624 for ; Tue, 9 Jul 2013 19:02:38 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 66D1D1458 for ; Tue, 9 Jul 2013 19:02:38 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6BBB121034; Tue, 9 Jul 2013 15:02:31 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 09 Jul 2013 15:02:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=uicWA9QhI2R9qcMnnxdEF+puyaw=; b=OWoWQvWhuMQZcxyCKaC+f XrkB/n7xnRdmpb7TRBmC++u8sbDaIRm7NaZJuR4cNPRbqfAIwsN71x459HLoMgaC dJZ8kR6K8MXEbTsY+psh/EyYE5sxoVnKRnrS67X7duAg8Mu58Mpz9yfwQ7n1p9P5 JrVje+03JxIF3lBL1V/2So= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:cc:subject:references :date:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=uicWA9QhI2R9qcMnnxdEF+puyaw=; b=NNt4 YD4IGpMoVfdrMQtCIST4TAJqnailbzhz66fHZV5sLCgU3Chc90UuttdDJQtmGpqx ThnmfDG3QjnsLp3Aq18y0YF3+LfZTYezvUfz1H0bfbSKg4vpJxFJOKK7l/+2ctaP hIDccOnKto1UY0avaOaky+TOzcVZLIcQpGV+gU4= X-Sasl-enc: McEfWDXeDJZQ4Ll3+YgyUvzkXGgNf6kql/PQRsC9kICy 1373396550 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id C6096680279; Tue, 9 Jul 2013 15:02:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Chris H" Subject: Re: perl upgrade woes -- how to best reconcile? References: <51DBEB9F.7020803@wenks.ch> <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> Date: Tue, 09 Jul 2013 14:02:30 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> User-Agent: Opera Mail/12.15 (FreeBSD) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:02:38 -0000 Is there a reason you're avoiding poudriere/pkg ? It's simple to setup and extremely reliable. Your headaches go away because all of your package upgrades get built in a jail and you don't have a half-broken system while waiting for portmaster to run. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 19:29:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 244824C0 for ; Tue, 9 Jul 2013 19:29:40 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from h615406.serverkompetenz.net (h615406.serverkompetenz.net [81.169.143.132]) by mx1.freebsd.org (Postfix) with ESMTP id DAABE176E for ; Tue, 9 Jul 2013 19:29:39 +0000 (UTC) Received: from h615406.serverkompetenz.net (localhost [127.0.0.1]) by h615406.serverkompetenz.net (Postfix) with ESMTP id 99EA01706D; Tue, 9 Jul 2013 21:22:32 +0200 (MST) Received: from jellaby.local (p5482BE42.dip0.t-ipconnect.de [84.130.190.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by h615406.serverkompetenz.net (Postfix) with ESMTPSA id 57C921704A; Tue, 9 Jul 2013 21:22:32 +0200 (MST) Received: by jellaby.local (Postfix, from userid 2246) id 0EED5206AB10; Tue, 9 Jul 2013 21:22:15 +0200 (CEST) From: Michael Sperber To: Konstantin Belousov Subject: Re: Weird regex behavior on 9.1-RELEASE on amd64 in 32-bit mode References: <20130709182323.GT91021@kib.kiev.ua> Date: Tue, 09 Jul 2013 21:22:14 +0200 In-Reply-To: <20130709182323.GT91021@kib.kiev.ua> (Konstantin Belousov's message of "Tue, 9 Jul 2013 21:23:23 +0300") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b33 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:29:40 -0000 Thanks for the quick answer! Konstantin Belousov writes: > -m32 does not work on stable. You need HEAD. So I should have better luck with a binary compiled on i386, right? -- Regards, Mike From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 19:39:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB4A2998 for ; Tue, 9 Jul 2013 19:39:26 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 668C317FD for ; Tue, 9 Jul 2013 19:39:26 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 4141D5CABB; Tue, 9 Jul 2013 21:39:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id BLz07wJ5ErCz; Tue, 9 Jul 2013 21:39:24 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 1C30F5CAB3; Tue, 9 Jul 2013 21:39:24 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id AC89050881; Tue, 9 Jul 2013 21:39:23 +0200 (CEST) Message-ID: <51DC66EB.40109@incore.de> Date: Tue, 09 Jul 2013 21:39:23 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Shutdown hangs on unmount of a gjournaled file system in 8-Stable References: <51D9EB23.4070505@incore.de> <20130708054301.GI91021@kib.kiev.ua> In-Reply-To: <20130708054301.GI91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:39:26 -0000 Konstantin Belousov wrote: > On Mon, Jul 08, 2013 at 12:26:43AM +0200, Andreas Longwitz wrote: >> The deadlock can be explained now: pid 1 (init) sleeps on "mount drain" >> because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal >> switcher) by calling vfs_busy(). pid 18 now sleeps on "suspwt" because >> mp->mnt_writeopcount was 1. This setting was done by pid 1 before going >> to sleep by calling vn_start_write() in dounmount(). >> >> I think the reason for this deadlock is the commit r249055 which seems >> not to be compatible with gjournal. > Thank you for the analysis. I think 'not compatible' is some > understatement. The situation clearly causes a deadlock, you are right. > > The vfs_busy(); vfs_write_suspend(); call sequence is somewhat dubious, > in fact, exactly because unmount could start in between. I think that > vfs_write_suspend() must avoid setting MNT_SUSPEND if unmount was > started. Patch below, for HEAD, should fix the problem, by marking the > callers of vfs_write_suspend(), which are not protected by the covered > vnode lock, with the VS_SKIP_UNMOUNT flag. Agree. > I believe that the conflicts on stable/8 should be trivial, if any. Yes, I have adapted r244795, r244925 and r245286 from head and your patch for the umount hang to 8-Stable and everything looks fine. All my reboots worked as expected. By the way, because the source gjounal.c is involved: can you extend the panic message for Journal overflow a little bit: -> diff g_journal.c.orig g_journal.c 342,343c343,344 < panic("Journal overflow (joffset=%jd active=%jd inactive=%jd)", < (intmax_t)sc->sc_journal_offset, --- > panic("Journal overflow (id=%d joffset=%jd active=%jd inactive=%jd)", > sc->sc_id, (intmax_t)sc->sc_journal_offset, This was helpful for analyzing the still unsolved "suspwt" lock problem from kern/164252, please look at http://lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html -- Andreas Longwitz From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 20:44:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F29ABAB for ; Tue, 9 Jul 2013 20:44:04 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id E74D71B46 for ; Tue, 9 Jul 2013 20:44:03 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r69Khu5e010665; Tue, 9 Jul 2013 13:44:02 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r69Kho5g010661; Tue, 9 Jul 2013 13:43:50 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 9 Jul 2013 13:43:51 -0700 (PDT) Message-ID: <2256185130cc152bf871c46fb9e14056.authenticated@ultimatedns.net> In-Reply-To: References: <51DBEB9F.7020803@wenks.ch> <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> Date: Tue, 9 Jul 2013 13:43:51 -0700 (PDT) Subject: Re: perl upgrade woes -- how to best reconcile? From: "Chris H" To: "Mark Felder" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:44:04 -0000 Greetings Mark, and thank you for your reply. > Is there a reason you're avoiding poudriere/pkg ? It's simple to setup and > extremely reliable. Your headaches go away because all of your package > upgrades get built in a jail and you don't have a half-broken system while > waiting for portmaster to run. I was introduced to poudriere when I solicited recommendations from the list prior to this upgrade -- portupgrade(1) | portmaster(8) -- which is more effective for large upgrade? After examining this port, it was clear that my whole upgrade scheme would have to completely change. While it would be nice to build everything, and then "push" the builds onto the target box. This is not an immediate option. Tho it is my intention to create a box to produce packages targeted for all of my servers. While I realize that poudriere doesn't require a separate box to do this work, I wasn't willing to take on yet another change, just to perform this upgrade. As it was; I was going from 8.3-STABLE --> 8.4 && (cv)sup --> subversion 1.7 --> subversion 1.8 -- and this was just to get to 8.4. I made the solicitation to the list, because my normal choice was using portupgrade(1). But given that it wasn't all that uncommon to run into database issues, and sometimes even upgrading portupgrade itself; given the extra dependencies. I ultimately decided on portmaster(8) because it required nothing that the system didn't already provide. I also don't believe that when facing issues, that adding additional variables makes the process any more stable -- especially given that I'm already not dealing with a completely stable system. Anyway, you asked. So now you know. :) Thanks again, for taking the time to respond. --chris > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 9 22:50:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6112B1FD for ; Tue, 9 Jul 2013 22:50:51 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 3900511FE for ; Tue, 9 Jul 2013 22:50:51 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id a11so6644247iee.6 for ; Tue, 09 Jul 2013 15:50:50 -0700 (PDT) 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=lSQwYofrlZiREFQ3JvkHFWtnUx7TXGLZ7pmQl1QvEmU=; b=RPC3Kd6zpQPPHZW6x898J5Qszn/L2yzr69hoCarKLZZu6N4arst6WmmC3upYm/LhGw gUpuq4CmdvhTEgPxyj7G8qojJNMukaTNz2+fg0xI7+bMcuUHD4UkS/q5PY9V7/oleMjh vWxUU1COtn3jVC3edVvn8lgJrHhM6AgukViEq1hT/5TzNDexTanSY8WbBfq1LkDLLsS1 SeuyKZyxyAybP5wEHwtcYzBkCRGozye8R01aRvY6dlJVEoieDCTcPvFBqZ4DrVtLkRiS tRPZjh9qOejftUZZxJueNRCea2Dv1poZjz23q1c+PTUuKe9iwOMGIjvnft4nwintZX0e evRw== MIME-Version: 1.0 X-Received: by 10.42.73.66 with SMTP id r2mr555702icj.9.1373410250485; Tue, 09 Jul 2013 15:50:50 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Tue, 9 Jul 2013 15:50:50 -0700 (PDT) Date: Tue, 9 Jul 2013 18:50:50 -0400 X-Google-Sender-Auth: GOljlEcKHso9FVAjldEbFVKY49A Message-ID: Subject: Clang 3.3 libc++ problem on 9-STABLE From: J David To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:50:51 -0000 With SVN version r253119, we are seeing strange errors from iostream while attempting to use the new clang 3.3 with libc++ on 9-STABLE. This program: ------------------- start here ---------------------- #include int main() { std::cout << "This is a test." << std::endl; return 0; } ----------------- end here -------------------- Produces this output when compiled: $ clang++ -std=c++11 -stdlib=libc++ -v -o example example.cc FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd9.1 Thread model: posix "/usr/bin/clang++" -cc1 -triple x86_64-unknown-freebsd9.1 -emit-obj -mrelax-all -disable-free -main-file-name example.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -resource-dir /usr/bin/../lib/clang/3.3 -stdlib=libc++ -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /data/jdw -ferror-limit 19 -fmessage-length 80 -mstackrealign -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/example-fet9b9.o -x c++ example.cc clang -cc1 version 3.3 based upon LLVM 3.3 default target x86_64-unknown-freebsd9.1 ignoring nonexistent directory "/usr/bin/../lib/clang/3.3/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/include/clang/3.3 /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o example /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/example-fet9b9.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o /tmp/example-fet9b9.o: In function `std::__1::basic_ostream >& std::__1::operator<< >(std::__1::basic_ostream >&, char const*)': example.cc:(.text._ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc[_ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc]+0x4b0): undefined reference to `.LBB1_29' clang++: error: linker command failed with exit code 1 (use -v to see invocation) Compiling with either -std=c++11 or -stdlib=libc++ but not both yields a ton of linker errors about the mismatches between the header files and library contents. (Expected.) Compiling with neither produces a working executable using the Gnu 4.2 headers and libstdc++. So the problem appears specific to libc++. It feels like the linker command line (shown with -v above) being generated by clang++ isn't right. I might expect to see libcxxrt.so.1 there. (It is present in /lib.) But manually adding that doesn't appear to help. What I'm less sure of is whether this is a clang issue or whether "-std=c++11 -stdlib=libc++" are simply not the right flags to be using here. (Although they are what we widely use on other platforms, e.g. Mac, and appear to be trying to get the right include files and library here, namely /usr/include/c++/v1 and /usr/lib/libc++.so.) The system is built with what I understand to be the full suite of clang/libc++ options in /etc/make.conf: # Use clang CC=clang CXX=clang++ CPP=clang-cpp WITH_LIBCPLUSPLUS=yes Thanks for any advice! From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 01:44:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 717AC27A for ; Wed, 10 Jul 2013 01:44:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9261B2B for ; Wed, 10 Jul 2013 01:44:44 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id r10so5868519pdi.27 for ; Tue, 09 Jul 2013 18:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=rf66J0jEmWOw8Nh/CTPW/3hN/1EpFLxU+TqY2IbOIGo=; b=W6/SO3Qc6mrYSS9uI0r+Qk+htauFw3875lO9+thTnsaKt4L2DChPfJMB7UwQUqby8b 1EqgHHIlBi3F6gzIMbdQFCaoJL/LqOdHgZLlaV/FsXUzRop+rXVRdNN8Z0AqRi57cT16 4adl9Rt8u+4QvieI6Cup+vPdYz1TwMIXBJnZhNLZmVQD1IClun6Qzrg/sfFGSNxqAxj8 XdXPLnqhVNhI/EW44X962T+iLYAHZFlAUxEM75VvLZtIgaXMD90or5T3P6jUlNPi7PwQ eb79IeMhdbZJItVvaKyEekdlwHjE1D3IC4nXyC4iuezuSfhTG60Q8YwWu+qlCtgjclVl +/hw== X-Received: by 10.66.224.237 with SMTP id rf13mr31027704pac.26.1373420683792; Tue, 09 Jul 2013 18:44:43 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id we2sm33035774pab.0.2013.07.09.18.44.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:44:42 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Jul 2013 10:44:36 +0900 From: Yonghyeon PYUN Date: Wed, 10 Jul 2013 10:44:36 +0900 To: dcx dcy Subject: Re: hme0 interface going up/down (dhclient ?) Message-ID: <20130710014436.GA2753@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 01:44:44 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Jul 09, 2013 at 02:05:30PM +0000, dcx dcy wrote: > Hi all, > > I am having an issue where my hme0 interface is always turning up and down with dhclient requesting a lease. > > > > I am thinking this could be the same issue described by Jeremy Chadwick on June 9th: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073711.html > > > > Everything was fine on 8.2-STABLE and older versions. > > > > It was then upgraded directly to 9.0-STABLE and this is where I started having issues­. > > > > I am currently running 9.1-STABLE (July 7th) and issue persists. > > > > This is a Sun Netra T1 acting as my home gateway, hme0 is connected to a Cisco switch. > > I am normally using DHCP to get an ip from my ISP. > > > > For now, the only way it works is to set a static ip (I tried different dhclient options ... sync, etc). > > > > hme1 and ath0 (AR5413) is serving internal network. > Try attached patch and let me know whether it makes any difference for you. --/04w6evG8XlLl3ft Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="hme.diff" Index: sys/dev/hme/if_hme.c =================================================================== --- sys/dev/hme/if_hme.c (revision 253125) +++ sys/dev/hme/if_hme.c (working copy) @@ -742,6 +742,10 @@ hme_init_locked(struct hme_softc *sc) u_int32_t n, v; HME_LOCK_ASSERT(sc, MA_OWNED); + + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + return; + /* * Initialization sequence. The numbered steps below correspond * to the sequence outlined in section 6.3.5.1 in the Ethernet @@ -1324,6 +1328,7 @@ hme_eint(struct hme_softc *sc, u_int status) /* check for fatal errors that needs reset to unfreeze DMA engine */ if ((status & HME_SEB_STAT_FATAL_ERRORS) != 0) { HME_WHINE(sc->sc_dev, "error signaled, status=%#x\n", status); + sc->sc_ifp->if_drv_flags &= ~IFF_DRV_RUNNING; hme_init_locked(sc); } } @@ -1370,6 +1375,7 @@ hme_watchdog(struct hme_softc *sc) device_printf(sc->sc_dev, "device timeout (no link)\n"); ++ifp->if_oerrors; + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; hme_init_locked(sc); hme_start_locked(ifp); return (EJUSTRETURN); --/04w6evG8XlLl3ft-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 02:40:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89E28AAC for ; Wed, 10 Jul 2013 02:40:10 +0000 (UTC) (envelope-from dcbsdx@hotmail.com) Received: from bay0-omc2-s17.bay0.hotmail.com (bay0-omc2-s17.bay0.hotmail.com [65.54.190.92]) by mx1.freebsd.org (Postfix) with ESMTP id 77E671CF4 for ; Wed, 10 Jul 2013 02:40:10 +0000 (UTC) Received: from BAY169-W133 ([65.54.190.125]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Jul 2013 19:40:09 -0700 X-TMN: [Mo+3z6Hd5s1aAkYlc2bXcA9XcJ2NTCxA] X-Originating-Email: [dcbsdx@hotmail.com] Message-ID: From: dcx dcy To: "pyunyh@gmail.com" Subject: RE: hme0 interface going up/down (dhclient ?) Date: Wed, 10 Jul 2013 02:40:09 +0000 Importance: Normal In-Reply-To: <20130710014436.GA2753@michelle.cdnetworks.com> References: , <20130710014436.GA2753@michelle.cdnetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jul 2013 02:40:09.0661 (UTC) FILETIME=[CB7666D0:01CE7D16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 02:40:10 -0000 Hello=2C the patch corrected this issue. =20 Thank you very much for your help and time=2C it is appreciated! =20 Best Regards=2C =20 Dominic. =20 > From: pyunyh@gmail.com > Date: Wed=2C 10 Jul 2013 10:44:36 +0900 > To: dcbsdx@hotmail.com > CC: freebsd-stable@freebsd.org > Subject: Re: hme0 interface going up/down (dhclient ?) >=20 > On Tue=2C Jul 09=2C 2013 at 02:05:30PM +0000=2C dcx dcy wrote: > > Hi all=2C=20 > >=20 > > I am having an issue where my hme0 interface is always turning= up and down with dhclient requesting a lease. > >=20 > > =20 > >=20 > > I am thinking this could be the same issue described by Jeremy Chadwick= on June 9th: > >=20 > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073711.html > >=20 > > =20 > >=20 > > Everything was fine on 8.2-STABLE and older versions. =20 > >=20 > > =20 > >=20 > > It was then upgraded directly to 9.0-STABLE and this is where I started= having issues=AD. > >=20 > > =20 > >=20 > > I am currently running 9.1-STABLE (July 7th) and issue persists. > >=20 > > =20 > >=20 > > This is a Sun Netra T1 acting as my home gateway=2C hme0 is connected t= o a Cisco switch.=20 > >=20 > > I am normally using DHCP to get an ip from my ISP. =20 > >=20 > > =20 > >=20 > > For now=2C the only way it works is to set a static ip (I tried differ= ent dhclient options ... sync=2C etc). > >=20 > > =20 > >=20 > > hme1 and ath0 (AR5413) is serving internal network. > >=20 >=20 > Try attached patch and let me know whether it makes any difference > for you. = From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 06:47:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C937C3B for ; Wed, 10 Jul 2013 06:47:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 095C817AE for ; Wed, 10 Jul 2013 06:47:25 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id 10so5993608pdi.39 for ; Tue, 09 Jul 2013 23:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qhfZ4eaOpYUpUO0gp5emxLoXJx04Cc5gYGmSH59fIJM=; b=tF+YsxegvMqTzTZfaJ8eb4VEa6TXAkCfz305i/YBKvYPGYAMCZIYRAXYiIByEYRc/N 6/T0Z32APCKaTQeAZa5uOY9LlzlZJ3M2HF84Y9lLOkbmeu67E10C8qOg6BoZX34srKHE Siy/rUASdFD0Cqb7QZKYQKwaryS6DEAwGnSZzj4DI3Sukbkf80yf7tZWB3qb2SmxqXOE AgfhuzzcaylSkrZbooU22nVY7IVOJ7Cj0dlxf/pnmbXgBSHQJ69KGFIhb8WvJyUgWywJ 9WAQfJhmBrmLELQtpsBO4xZClKbXBUsriACGF5VizFRKyC6I/fpkdNlekO1vqzi0UlXq aydA== X-Received: by 10.66.37.77 with SMTP id w13mr32060008paj.73.1373438844895; Tue, 09 Jul 2013 23:47:24 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id sz6sm34426349pab.5.2013.07.09.23.47.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 23:47:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Jul 2013 15:47:17 +0900 From: Yonghyeon PYUN Date: Wed, 10 Jul 2013 15:47:17 +0900 To: dcx dcy Subject: Re: hme0 interface going up/down (dhclient ?) Message-ID: <20130710064717.GC2753@michelle.cdnetworks.com> References: <20130710014436.GA2753@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 06:47:25 -0000 On Wed, Jul 10, 2013 at 02:40:09AM +0000, dcx dcy wrote: > Hello, > the patch corrected this issue. > > Thank you very much for your help and time, it is appreciated! > > Best Regards, > > Dominic. > Thanks for testing. Committed in r253134. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 09:53:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ADD838E2 for ; Wed, 10 Jul 2013 09:53:39 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7217F1FE2 for ; Wed, 10 Jul 2013 09:53:39 +0000 (UTC) Received: from spaceball.andric.com (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 248545C43; Wed, 10 Jul 2013 11:53:38 +0200 (CEST) Message-ID: <51DD2F21.4050006@FreeBSD.org> Date: Wed, 10 Jul 2013 11:53:37 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: J David , freebsd-stable@freebsd.org Subject: Re: Clang 3.3 libc++ problem on 9-STABLE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 09:53:39 -0000 On 2013-07-10 00:50, J David wrote: > With SVN version r253119, we are seeing strange errors from iostream while > attempting to use the new clang 3.3 with libc++ on 9-STABLE. ... > /tmp/example-fet9b9.o: In function `std::__1::basic_ostream std::__1::char_traits >& std::__1::operator<< > >(std::__1::basic_ostream std::__1::char_traits >&, char const*)': > example.cc:(.text._ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc[_ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc]+0x4b0): > undefined reference to `.LBB1_29' > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) Sorry, this was my mistake in importing the fixes needed for llvm PR 16038. I missed one additional patch, which I imported in r253042. I will merge it to stable/9 on July 11th. -Dimitry From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 11:01:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1313840 for ; Wed, 10 Jul 2013 11:01:44 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 58E1F13BB for ; Wed, 10 Jul 2013 11:01:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r6AB1fkt035206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 10 Jul 2013 13:01:41 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <51DD3F14.9010500@wenks.ch> Date: Wed, 10 Jul 2013 13:01:40 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: perl upgrade woes -- how to best reconcile? References: <51DBEB9F.7020803@wenks.ch> <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> In-Reply-To: <44f72b29a68d30c276b13ee4a2730cc9.authenticated@ultimatedns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 11:01:44 -0000 Hello Chris On 09.07.2013 20:24, Chris H wrote: > Greetings Fabian, and thank you for your reply. You're welcome. > My perl5 tree currently looks like: > /usr/local/lib/perl5/5.12/man/ > man3/ > whatis > /usr/local/lib/perl5/5.12.4/ > man3/ > whatis > What a mess! If only whatis is left below 5.12.4, then you can remove the whole 5.12.4 folder. And also /usr/local/lib/perl5/site_perl/5.12.4/, if it does exist and does not contain anything relevant. > In the end, I guess the moral of the story is; don't upgrade. This is a bad idea, at least from the security point of view. > I've been on BSD since the late 70's, and as such, am no stranger > to the upgrade path. But recent experience seems to show, things > aren't getting any easier (or necessarily better). :( Sure, there are sometimes bumps on the road, but I had never any real show stopper and could always get it to work. I did install my two private servers back in 2007 with 6.x, upgraded to 7.x and just recently from 7.4 to 9.1. For the Ports I always used portupgrade. At least for the Ports it helps if you are doing it regularly, so the steps are not that huge. Important to always check /usr/ports/UPDATING. Currently I do upgrade the Ports around every 4 weeks, and additional when portaudit complains and I decide that I need to do it right now. >> The next big challenge then will be the upgrade to e.g. 5.14.x or >> 5.16.x. > > I don't think I'm even willing to go there, after this mess. As Mark pointed out, ports-mgmt/poudriere together with pkgng (ports-mgmt/pkg) looks promising. Sure something I did put on my todo list. > Thanks again, for taking the time to respond. You're welcome. PS: No need to use "reply all", reply only to the list is perfect, as I do filter e-mails based on the "List-Id" header line. bye Fabian From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 11:44:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 73CC5C6A; Wed, 10 Jul 2013 11:44:17 +0000 (UTC) (envelope-from trashcan@odo.in-berlin.de) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.60.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3288417E0; Wed, 10 Jul 2013 11:44:17 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mail.kaan-bock.invalid [10.10.10.1]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bqz803B3JzLFP; Wed, 10 Jul 2013 13:44:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at enfer-du-nord.net Received: from mx1.enfer-du-nord.net ([10.10.10.1]) by mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [10.10.10.1]) (amavisd-new, port 10024) with LMTP id oYkVwAnS9f0t; Wed, 10 Jul 2013 13:44:16 +0200 (CEST) Received: from mx1.enfer-du-nord.net (www.kaan-bock.invalid [10.10.10.2]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bqz7x02qhzLFD; Wed, 10 Jul 2013 13:44:12 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jul 2013 13:44:12 +0200 From: Michael Grimm To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: =?UTF-8?Q?ipv=36=5Faddrs=5FIF=20aliases=20in=20rc=2Econf=28?= =?UTF-8?Q?=35=29?= In-Reply-To: <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Message-ID: X-Sender: trashcan@odo.in-berlin.de User-Agent: Roundcube Webmail/0.9.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 11:44:17 -0000 Hi -- [Upcoming code freeze in stable] On 2013-04-13 22:15, Michael Grimm wrote: > On 13.04.2013, at 14:29, Kimmo Paasiala wrote: > [great deal of simplification by ipv6_addrs_IF] > >> Sorry to resurrect this thread but since nothing has happened in about >> three months I have to ask: What can I do to have this commited to >> HEAD? > > +1 > > Nowadays -where IPv6 becomes more and more available by ISPs- I > *really* > would like to see this simplification implemented, soon, very soon. The > current scheme is way to much error prone, and, its a pain in the ass! > > Thanks for the patch, > Michael Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. Regards, Michael From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 11:46:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0EAFF6F; Wed, 10 Jul 2013 11:46:13 +0000 (UTC) (envelope-from feld@feld.me) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A39C1813; Wed, 10 Jul 2013 11:46:13 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5BDC820A45; Wed, 10 Jul 2013 07:46:12 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 10 Jul 2013 07:46:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=mkT660NgTDYLF/wnWGO7lS7nz7o=; b=Eocc0BH2iUdXJo6CvX98I gmqWITB1SNRViYDHfnBGDI3roy6VXMs/L/kLiuV+n/4MbnRpWxOpuwrM41rcZ2HM oL0l+NfkzuZyod+Hrkbt8VQ++aeqwBWA1j522FgO3C4jvc58g9VvrDGBKBy4Lm9d XWNx9IALJLi69JfjbgJ2y4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=mkT660NgTDYLF/wnWGO7lS7nz7o=; b=t2A5 eF1n9153NjDgDRSd3PFhZCrtotxxtn73BL9NJTkEXKv+yaBB3U80mGGizDdrn11B pr5u1Y05yUeug01XHYl3uI63lsS6lO4HfF0D/J94zMfEpUPdjWg1PgT2T7NHZ+qx GsWwWi6VGJAOKKsaJISwaC+hBxNDPiJZ55mQ1ds= X-Sasl-enc: OuIWAZofUgC6xcl9cBR4kS8Wr7ARvQByZcCNi44Z62bk 1373456772 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A42E68021F; Wed, 10 Jul 2013 07:46:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, "Michael Grimm" Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Date: Wed, 10 Jul 2013 06:46:11 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 11:46:13 -0000 On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm wrote: > Will that patch make it into 9.2? If I am not mistaken, that patch isn't > in stable yet. I would also like to see this patch hit 9.x sooner than later. It's so painful when someone forgets to fix the alias numbering on servers with many, many IPv4 and IPv6 addresses... From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 15:52:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9EB75ED6; Wed, 10 Jul 2013 15:52:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 563C419B9; Wed, 10 Jul 2013 15:52:46 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id ta17so8598914obb.8 for ; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) 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=DQ/dOzjE4CCJ9/a1IBWmFd96ovOGOT2n6xceTmrbVzQ=; b=HO7ZMK73SOc/HKuxmhUxNrUuVkHy7v2L1KdUGlLnwp50xwsEeupeXNCqTq7ymuRbZY WEwYgryq+HfWuVbYa1FpsP4vIzSVYQIuHGoG8l64fuBXrLKSIsfH7VRupdctQ6c8/ECW NQyScFoYpwUO9gx+w4oBMxEbFdd33g1Ho7NyZDdODXEKb9ln97GYb6xTRrgr/gHPnE4+ TyTqoy/1aa/31tYMthQkw9307Ztz14i05hhEEoyaelUCymE+pWymrjSdepU3+A//mDuZ eS+HWPZHYY6Qpt23DPIjhhoSqldZbxOyRVyxQu70wLcYRPw3zkGwsVa/klmix+eHSBDz 5MoQ== MIME-Version: 1.0 X-Received: by 10.182.171.7 with SMTP id aq7mr27791558obc.103.1373471565665; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Wed, 10 Jul 2013 08:52:45 -0700 (PDT) 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> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> Date: Wed, 10 Jul 2013 08:52:45 -0700 X-Google-Sender-Auth: FEKe3C32sctKmByrR5bobS1Cxw8 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kevin Oberman To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:52:46 -0000 On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > trashcan@odo.in-berlin.de> wrote: > > Will that patch make it into 9.2? If I am not mistaken, that patch isn't >> in stable yet. >> > > I would also like to see this patch hit 9.x sooner than later. It's so > painful when someone forgets to fix the alias numbering on servers with > many, many IPv4 and IPv6 addresses... > Please, please, please, please, ...! Freeze is only two days away, so time for 9.2 is almost over and I can see no good reason NOT to get this done. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 10 16:28:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C532DB25; Wed, 10 Jul 2013 16:28:02 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 917021BFF; Wed, 10 Jul 2013 16:28:02 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so15216521ieb.24 for ; Wed, 10 Jul 2013 09:28:02 -0700 (PDT) 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=wtLjlkI8eLOt553G8qflCOB8m9ATMhG7jVBGrt7YSWE=; b=ujNGkSUff7QuFPEpwlg/4PLKwUd6a5OKs7TcSfnXp2tAOrsy8Lvko/sBWsgrv5kwT2 OAgqQhwKJSSGKakrSA051J88eoc9QF8Uae9rAOg9a5F2lQ5w0E5vL1+BVCmlcV8viRw9 /w+WHbRgCyrljDzz9JbpxAq1YpNOYLdE9nJUEETt4GyB09Bj/061TWplaFLpILMOatT1 h/K+BW5UVL5mIPh4Lgsh4xz3D1JV1qUS8NDCoz0Ye6yXbALubKTq+5CEUbB/vyNX108q 3Rx7KRlqaEneindXuUiTgqPBQhDuBCN5vm79uGd2XzNbJEqwxRA+4dTmnnBoAUiXnX/i aOTQ== MIME-Version: 1.0 X-Received: by 10.42.73.66 with SMTP id r2mr1613304icj.9.1373473682312; Wed, 10 Jul 2013 09:28:02 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.114.73 with HTTP; Wed, 10 Jul 2013 09:28:02 -0700 (PDT) In-Reply-To: <51DD2F21.4050006@FreeBSD.org> References: <51DD2F21.4050006@FreeBSD.org> Date: Wed, 10 Jul 2013 12:28:02 -0400 X-Google-Sender-Auth: CIpqXOoBWiTWXJrcBdNWUHUZyO4 Message-ID: Subject: Re: Clang 3.3 libc++ problem on 9-STABLE From: J David To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:28:02 -0000 On Wed, Jul 10, 2013 at 5:53 AM, Dimitry Andric wrote: > I missed one additional patch, which I imported in r253042. > Yes, I pulled that rev into my -STABLE and rebuilt and it is fine now. Thanks for your help and to you and everyone for all the hard work on clang! I strongly prefer it and am so happy it is available in 9.x now. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 06:51:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 28F82F83 for ; Thu, 11 Jul 2013 06:51:09 +0000 (UTC) (envelope-from dim@freebsd.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id E0FF915D4 for ; Thu, 11 Jul 2013 06:51:08 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::5ddb:3b65:6713:aa4] (unknown [IPv6:2001:7b8:3a7:0:5ddb:3b65:6713:aa4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F20A85C43; Thu, 11 Jul 2013 08:51:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Clang 3.3 libc++ problem on 9-STABLE From: Dimitry Andric In-Reply-To: Date: Thu, 11 Jul 2013 08:51:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: <5AC6D881-36CD-47FF-AB65-61B06B248CA2@freebsd.org> References: <51DD2F21.4050006@FreeBSD.org> To: J David X-Mailer: Apple Mail (2.1508) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:51:09 -0000 On Jul 10, 2013, at 18:28, J David wrote: > On Wed, Jul 10, 2013 at 5:53 AM, Dimitry Andric wrote: > >> I missed one additional patch, which I imported in r253042. >> > > Yes, I pulled that rev into my -STABLE and rebuilt and it is fine now. I merged the patch to stable/9 in r253192. -Dimitry From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 07:44:27 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6DA0D1DB for ; Thu, 11 Jul 2013 07:44:27 +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 BF19F1818 for ; Thu, 11 Jul 2013 07:44:26 +0000 (UTC) Received: (qmail 87663 invoked from network); 11 Jul 2013 08:35:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 08:35:03 -0000 Message-ID: <51DE6255.5000304@freebsd.org> Date: Thu, 11 Jul 2013 09:44:21 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> In-Reply-To: <51DACE93.9050608@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:44:27 -0000 On 08.07.2013 16:37, Andre Oppermann wrote: > On 07.07.2013 20:24, Alfred Perlstein wrote: >> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>> Can you help me with with testing? >>> >> Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. > > http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff Any feedback from testers on this? The MFC window is closing soon. -- Andre > This is functional bundle MFC of these original commits: > > MFC r242029 (alfred): > > Allow autotune maxusers > 384 on 64 bit machines. > > MFC r242847 (alfred): > > Allow maxusers to scale on machines with large address space. > > MFC r243631 (andre): > > Base the mbuf related limits on the available physical memory or > kernel memory, whichever is lower. The overall mbuf related memory > limit must be set so that mbufs (and clusters of various sizes) > can't exhaust physical RAM or KVM. > > At the same time divorce maxfiles from maxusers and set maxfiles to > physpages / 8 with a floor based on maxusers. This way busy servers > can make use of the significantly increased mbuf limits with a much > larger number of open sockets. > > MFC r243639 (andre): > > Complete r243631 by applying the remainder of kern_mbuf.c that got > lost while merging into the commit tree. > > MFC r243668 (andre): > > Using a long is the wrong type to represent the realmem and maxmbufmem > variable as they may overflow on i386/PAE and i386 with > 2GB RAM. > > MFC r243995, r243996, r243997 (pjd): > > Style cleanups, Make use of the fact that uma_zone_set_max(9) already > returns actual limit set. > > MFC r244080 (andre): > > Prevent long type overflow of realmem calculation on ILP32 by forcing > calculation to be in quad_t space. Fix style issue with second parameter > to qmin(). > > MFC r245469 (alfred): > > Do not autotune ncallout to be greater than 18508. > > MFC r245575 (andre): > > Move the mbuf memory limit calculations from init_param2() to > tunable_mbinit() where it is next to where it is used later. > > MFC r246207 (andre): > > Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. > > MFC r249843 (andre): > > Base the calculation of maxmbufmem in part on kmem_map size > instead of kernel_map size to prevent kernel memory exhaustion > by mbufs and a subsequent panic on physical page allocation > failure. > > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 08:09:51 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B20BB8AF; Thu, 11 Jul 2013 08:09:51 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 904CA1994; Thu, 11 Jul 2013 08:09:51 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 7DF6B63F66; Thu, 11 Jul 2013 01:09:50 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 73333-03-3; Thu, 11 Jul 2013 01:09:50 -0700 (PDT) Received: from Alfreds-MacBook-Pro-9.local (unknown [10.8.0.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id A15EE63DBB; Thu, 11 Jul 2013 01:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1373529632; bh=iz3OtJcS54JWX5R/pZY7kGP5rwi35YEinwn+JQ1ZgJw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=HvVS2B18+2Kj6wJfw+F3pegWvBNH5xBweU6bNnRFZSY3IGWzuH5y5SUYy+Nczj2/g Y1ZHLpuFR+nna2asXVpgeSHb+3UbC7bDAcP9XsMygtfVRFuvDyQ1OtFx59QLT8jNAe pKKNLULuHLeH0R7omgpybmEP7LUBoMuaXN68vJ1g= Message-ID: <51DE6620.4080301@ixsystems.com> Date: Thu, 11 Jul 2013 01:00:32 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> In-Reply-To: <51DE6255.5000304@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:09:51 -0000 On 7/11/13 12:44 AM, Andre Oppermann wrote: > On 08.07.2013 16:37, Andre Oppermann wrote: >> On 07.07.2013 20:24, Alfred Perlstein wrote: >>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>> Can you help me with with testing? >>>> >>> Yes. Please give me your proposed changes and I'll stand up a >>> machine and give feedback. >> >> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff > > Any feedback from testers on this? The MFC window is closing soon. > This week has been pretty intense. I've sent out a request to the team to apply this patch to as many machines as possible. I'm going to talk to the rest of the FreeNAS team about it as well shortly. -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 08:15:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34609B77; Thu, 11 Jul 2013 08:15:48 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mx1.freebsd.org (Postfix) with ESMTP id E14A119DB; Thu, 11 Jul 2013 08:15:47 +0000 (UTC) Received: from mail.wasikowski.net (mail.wasikowski.net [IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (Postfix) with ESMTP id E105813E3; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from mail.wasikowski.net ([IPv6:2001:6a0:1cb::b]) by mail.wasikowski.net (scan.wasikowski.net [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id PV2iGYNjasY2; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) Received: from [192.168.138.150] (83-144-115-210.static.chello.pl [83.144.115.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.wasikowski.net (Postfix) with ESMTPSA id 7F61713DF; Thu, 11 Jul 2013 10:15:38 +0200 (CEST) Message-ID: <51DE69AA.7060003@wasikowski.net> Date: Thu, 11 Jul 2013 10:15:38 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) References: <50D1C553.9060100@wasikowski.net> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:15:48 -0000 W dniu 2013-07-10 17:52, Kevin Oberman pisze: > On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > >> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < >> trashcan@odo.in-berlin.de> wrote: >> >> Will that patch make it into 9.2? If I am not mistaken, that patch isn't >>> in stable yet. >>> >> >> I would also like to see this patch hit 9.x sooner than later. It's so >> painful when someone forgets to fix the alias numbering on servers with >> many, many IPv4 and IPv6 addresses... >> > > Please, please, please, please, ...! > > Freeze is only two days away, so time for 9.2 is almost over and I can see > no good reason NOT to get this done. +1 to that, please commit it. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 09:08:27 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C9F6DD; Thu, 11 Jul 2013 09:08:27 +0000 (UTC) (envelope-from prvs=19047057b3=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 896F81C73; Thu, 11 Jul 2013 09:08:25 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004920175.msg; Thu, 11 Jul 2013 10:08:23 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 11 Jul 2013 10:08:23 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19047057b3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andre Oppermann" , "Alfred Perlstein" References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> Subject: Re: status of autotuning freebsd for 9.2 Date: Thu, 11 Jul 2013 10:08:43 +0100 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 Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:08:27 -0000 ----- Original Message ----- From: "Andre Oppermann" > On 08.07.2013 16:37, Andre Oppermann wrote: >> On 07.07.2013 20:24, Alfred Perlstein wrote: >>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>> Can you help me with with testing? >>>> >>> Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. >> >> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff > > Any feedback from testers on this? The MFC window is closing soon. Few things I've noticed most of which look like issues against the original patch and not the MFC but worth mentioning. 1. You've introduced a new tunable kern.maxmbufmem which is autosized but doesnt seem to be exposed via a sysctl so it looks like there is no way to determine what its actually set to? 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mbinit and the sysctl kern.ipc.nmbuf i.e. no 's'. 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of the other sysctls? 4. style issues: * @@ -178,11 +202,13 @@ ... if (newnmbjumbo9 > nmbjumbo9&& Finally out of interest what made us arrive at the various defaults for each type as it looks like the ratios have changed? 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-stable@FreeBSD.ORG Thu Jul 11 12:47:10 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0640F53 for ; Thu, 11 Jul 2013 12:47:10 +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 234201AB8 for ; Thu, 11 Jul 2013 12:47:09 +0000 (UTC) Received: (qmail 89015 invoked from network); 11 Jul 2013 13:37:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 13:37:44 -0000 Message-ID: <51DEA947.6060605@freebsd.org> Date: Thu, 11 Jul 2013 14:47:03 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Steven Hartland Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:47:10 -0000 On 11.07.2013 11:08, Steven Hartland wrote: > ----- Original Message ----- From: "Andre Oppermann" > >> On 08.07.2013 16:37, Andre Oppermann wrote: >>> On 07.07.2013 20:24, Alfred Perlstein wrote: >>>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>>> Can you help me with with testing? >>>>> >>>> Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. >>> >>> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff >> >> Any feedback from testers on this? The MFC window is closing soon. > > Few things I've noticed most of which look like issues against the original > patch and not the MFC but worth mentioning. > > 1. You've introduced a new tunable kern.maxmbufmem which is autosized but > doesnt seem to be exposed via a sysctl so it looks like there is no way > to determine what its actually set to? Good point. I've made it global and exposed as kern.ipc.maxmbufmem (RDTUN). > 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mbinit > and the sysctl kern.ipc.nmbuf i.e. no 's'. That's a typo, fixed. > 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of > the other sysctls? Yes, see above. > 4. style issues: > * @@ -178,11 +202,13 @@ > ... > if (newnmbjumbo9 > nmbjumbo9&& Thanks. All fixed in r253204. > Finally out of interest what made us arrive at the various defaults for each > type as it looks like the ratios have changed? Before it was an arbitrary mess. Mbufs were not limited at all and the others to some random multiple of maxusers with the net limit ending up at some 25,000 mbuf clusters by default. Now default overall limit is set at 50% of all available min(physical, kmem_map) memory to prevent mbufs from monopolizing kernel memory and leave some space for other kernel structures and buffers as well as user-space programs. It can be raised to 3/4 of available memory by the tunable. 2K and 4K (page size) mbuf clusters can each go up to 25% of this mbuf memory. The former is dominantly used on the receive path and the latter in the send path. 9K and 16K jumbo mbuf clusters can each go up to 12.5% of mbuf memory. They are only used in the receive path if large jumbo MTUs on a network interface are active. Both are special in that their memory is contiguous in KVM and physical memory. This becomes problematic due to memory fragmentation after a short amount of heavy system use. I hope to deprecate them for 10.0. Network interfaces should use 4K clusters instead and chain them together for larger packets. All modern NICs support that. Only the early and limited DMA engines without scatter-gather capabilities required contiguous physical memory. They are long gone by now. The limit for mbufs itselfs is 12.5% of mbuf memory and should be at least as many as the sum of the cluster types. Each cluster requires an mbuf to which it is attached. Two examples on the revised mbuf sizing limits: 1GB KVM: 512MB limit for mbufs 419,430 mbufs 65,536 2K mbuf clusters 32,768 4K mbuf clusters 9,709 9K mbuf clusters 5,461 16K mbuf clusters 16GB RAM: 8GB limit for mbufs 33,554,432 mbufs 1,048,576 2K mbuf clusters 524,288 4K mbuf clusters 155,344 9K mbuf clusters 87,381 16K mbuf clusters These defaults should be sufficient for even the most demanding network loads. For additional information see: http://svnweb.freebsd.org/changeset/base/243631 -- Andre From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 14:59:50 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDFEECAE; Thu, 11 Jul 2013 14:59:50 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id B1D46124B; Thu, 11 Jul 2013 14:59:50 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 7D887643E4; Thu, 11 Jul 2013 07:59:50 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 03941-08; Thu, 11 Jul 2013 07:59:50 -0700 (PDT) Received: from [10.0.1.103] (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 1F5F7643DF; Thu, 11 Jul 2013 07:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1373554790; bh=jH8ZgCenvxU5zjeRL7yWrsLBihrczicW0D0opoOPDUI=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=Igz5smKm6OVj91DP39TGuANL3UzDebH4lmlkae5bFVx+Gi9u9X/LWHiWsMOqNBvAr ZiEWj/4fbvJQJi5hW1fTMEVoAhkzMYZP6cglu+NArZ6plMH+QZdI7b/3W7nzKcMzHu s/DHAnO5rNedvLWgFRF6E5Ab1qbHU1F45Dkpkknc= References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> <51DEA947.6060605@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <51DEA947.6060605@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5D355B31-3160-44A3-ADF2-3397E8831DA2@ixsystems.com> X-Mailer: iPhone Mail (10B329) From: Alfred Perlstein Subject: Re: status of autotuning freebsd for 9.2 Date: Thu, 11 Jul 2013 07:59:48 -0700 To: Andre Oppermann Cc: "re@freebsd.org" , "stable@freebsd.org" , Steven Hartland , "nonesuch@longcount.org" , Peter Wemm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:59:50 -0000 Andre, Peter what about i386? =20 Ever since I touched this Peter has been worried about i386 and said we've b= roken the platform.=20 I'm going to boot some vms but maybe we ought to get some testing from Peter= on i386? Sent from my iPhone On Jul 11, 2013, at 5:47 AM, Andre Oppermann wrote: > On 11.07.2013 11:08, Steven Hartland wrote: >> ----- Original Message ----- From: "Andre Oppermann" >>=20 >>> On 08.07.2013 16:37, Andre Oppermann wrote: >>>> On 07.07.2013 20:24, Alfred Perlstein wrote: >>>>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>>>> Can you help me with with testing? >>>>> Yes. Please give me your proposed changes and I'll stand up a machine= and give feedback. >>>>=20 >>>> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff >>>=20 >>> Any feedback from testers on this? The MFC window is closing soon. >>=20 >> Few things I've noticed most of which look like issues against the origin= al >> patch and not the MFC but worth mentioning. >>=20 >> 1. You've introduced a new tunable kern.maxmbufmem which is autosized but= >> doesnt seem to be exposed via a sysctl so it looks like there is no way= >> to determine what its actually set to? >=20 > Good point. I've made it global and exposed as kern.ipc.maxmbufmem (RDTUN= ). >=20 >> 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mb= init >> and the sysctl kern.ipc.nmbuf i.e. no 's'. >=20 > That's a typo, fixed. >=20 >> 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of= >> the other sysctls? >=20 > Yes, see above. >=20 >> 4. style issues: >> * @@ -178,11 +202,13 @@ >> ... >> if (newnmbjumbo9 > nmbjumbo9&& >=20 > Thanks. All fixed in r253204. >=20 >> Finally out of interest what made us arrive at the various defaults for e= ach >> type as it looks like the ratios have changed? >=20 > Before it was an arbitrary mess. Mbufs were not limited at all and the ot= hers > to some random multiple of maxusers with the net limit ending up at some 2= 5,000 > mbuf clusters by default. >=20 > Now default overall limit is set at 50% of all available min(physical, kme= m_map) > memory to prevent mbufs from monopolizing kernel memory and leave some spa= ce for > other kernel structures and buffers as well as user-space programs. It ca= n be > raised to 3/4 of available memory by the tunable. >=20 > 2K and 4K (page size) mbuf clusters can each go up to 25% of this mbuf mem= ory. > The former is dominantly used on the receive path and the latter in the se= nd path. > 9K and 16K jumbo mbuf clusters can each go up to 12.5% of mbuf memory. Th= ey are > only used in the receive path if large jumbo MTUs on a network interface a= re active. > Both are special in that their memory is contiguous in KVM and physical me= mory. > This becomes problematic due to memory fragmentation after a short amount o= f heavy > system use. I hope to deprecate them for 10.0. Network interfaces should= use 4K > clusters instead and chain them together for larger packets. All modern N= ICs > support that. Only the early and limited DMA engines without scatter-gath= er > capabilities required contiguous physical memory. They are long gone by n= ow. >=20 > The limit for mbufs itselfs is 12.5% of mbuf memory and should be at least= as > many as the sum of the cluster types. Each cluster requires an mbuf to wh= ich > it is attached. >=20 > Two examples on the revised mbuf sizing limits: >=20 > 1GB KVM: > 512MB limit for mbufs > 419,430 mbufs > 65,536 2K mbuf clusters > 32,768 4K mbuf clusters > 9,709 9K mbuf clusters > 5,461 16K mbuf clusters >=20 > 16GB RAM: > 8GB limit for mbufs > 33,554,432 mbufs > 1,048,576 2K mbuf clusters > 524,288 4K mbuf clusters > 155,344 9K mbuf clusters > 87,381 16K mbuf clusters >=20 > These defaults should be sufficient for even the most demanding network lo= ads. >=20 > For additional information see: >=20 > http://svnweb.freebsd.org/changeset/base/243631 >=20 > --=20 > Andre >=20 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 15:12:55 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1ACCF5D7; Thu, 11 Jul 2013 15:12:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id 58A3C133F; Thu, 11 Jul 2013 15:12:54 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so7689910wib.2 for ; Thu, 11 Jul 2013 08:12:53 -0700 (PDT) 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=dcjFkXn75RV000bruC/uEgeTQCOJBjmYUqFttx4hRRk=; b=XKbRA6xOYpPe8J5ikpg6u70M42GC+lg4dtFDbYyPOa99SsscDtny0s7Ho8dIWs31Gb dRtrbX9XzSA2dBKbYeQNlQ0i1iAVDPuQTPZoM1k6CnVYwCbmDy99dWdaMY34obe5g/rb DQ94k3mkuzsXnrERIvgO6P7pdJrrHRYsLA834zmfowvTqiM4pM0XY4uAURjhoCKPx985 v9YIh/q00LKyMaZEm7cldPDX8mORIRM9Q/0+fzwnJiM6cA/fodKadypjrp5xOHn79oBd o187OkPkCpDiR9LKUWI6EdRka67LUxYCiaJsD0qinwRptHfkh8+LilPyQxye4LObyaUR +K2A== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr9496162wie.46.1373555573252; Thu, 11 Jul 2013 08:12:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 11 Jul 2013 08:12:53 -0700 (PDT) In-Reply-To: <5D355B31-3160-44A3-ADF2-3397E8831DA2@ixsystems.com> References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> <51DEA947.6060605@freebsd.org> <5D355B31-3160-44A3-ADF2-3397E8831DA2@ixsystems.com> Date: Thu, 11 Jul 2013 08:12:53 -0700 X-Google-Sender-Auth: ZKG7gZfIEemeg-bdaXzAro0ZtvU Message-ID: Subject: Re: status of autotuning freebsd for 9.2 From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "stable@freebsd.org" , "re@freebsd.org" , Peter Wemm , "nonesuch@longcount.org" , Steven Hartland , Andre Oppermann X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:12:55 -0000 Please test on VMs. I've tested -HEAD in i386 virtualbox all the way down to 128mb with no panics. I'll test with 64mb soon. It's easy to do. i think the i386 PAE stuff on ${LARGE} memory systems is still broken. Peter? -adrian On 11 July 2013 07:59, Alfred Perlstein wrote: > Andre, Peter what about i386? > > Ever since I touched this Peter has been worried about i386 and said we've broken the platform. > > I'm going to boot some vms but maybe we ought to get some testing from Peter on i386? > > Sent from my iPhone > > On Jul 11, 2013, at 5:47 AM, Andre Oppermann wrote: > >> On 11.07.2013 11:08, Steven Hartland wrote: >>> ----- Original Message ----- From: "Andre Oppermann" >>> >>>> On 08.07.2013 16:37, Andre Oppermann wrote: >>>>> On 07.07.2013 20:24, Alfred Perlstein wrote: >>>>>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>>>>> Can you help me with with testing? >>>>>> Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. >>>>> >>>>> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff >>>> >>>> Any feedback from testers on this? The MFC window is closing soon. >>> >>> Few things I've noticed most of which look like issues against the original >>> patch and not the MFC but worth mentioning. >>> >>> 1. You've introduced a new tunable kern.maxmbufmem which is autosized but >>> doesnt seem to be exposed via a sysctl so it looks like there is no way >>> to determine what its actually set to? >> >> Good point. I've made it global and exposed as kern.ipc.maxmbufmem (RDTUN). >> >>> 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mbinit >>> and the sysctl kern.ipc.nmbuf i.e. no 's'. >> >> That's a typo, fixed. >> >>> 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of >>> the other sysctls? >> >> Yes, see above. >> >>> 4. style issues: >>> * @@ -178,11 +202,13 @@ >>> ... >>> if (newnmbjumbo9 > nmbjumbo9&& >> >> Thanks. All fixed in r253204. >> >>> Finally out of interest what made us arrive at the various defaults for each >>> type as it looks like the ratios have changed? >> >> Before it was an arbitrary mess. Mbufs were not limited at all and the others >> to some random multiple of maxusers with the net limit ending up at some 25,000 >> mbuf clusters by default. >> >> Now default overall limit is set at 50% of all available min(physical, kmem_map) >> memory to prevent mbufs from monopolizing kernel memory and leave some space for >> other kernel structures and buffers as well as user-space programs. It can be >> raised to 3/4 of available memory by the tunable. >> >> 2K and 4K (page size) mbuf clusters can each go up to 25% of this mbuf memory. >> The former is dominantly used on the receive path and the latter in the send path. >> 9K and 16K jumbo mbuf clusters can each go up to 12.5% of mbuf memory. They are >> only used in the receive path if large jumbo MTUs on a network interface are active. >> Both are special in that their memory is contiguous in KVM and physical memory. >> This becomes problematic due to memory fragmentation after a short amount of heavy >> system use. I hope to deprecate them for 10.0. Network interfaces should use 4K >> clusters instead and chain them together for larger packets. All modern NICs >> support that. Only the early and limited DMA engines without scatter-gather >> capabilities required contiguous physical memory. They are long gone by now. >> >> The limit for mbufs itselfs is 12.5% of mbuf memory and should be at least as >> many as the sum of the cluster types. Each cluster requires an mbuf to which >> it is attached. >> >> Two examples on the revised mbuf sizing limits: >> >> 1GB KVM: >> 512MB limit for mbufs >> 419,430 mbufs >> 65,536 2K mbuf clusters >> 32,768 4K mbuf clusters >> 9,709 9K mbuf clusters >> 5,461 16K mbuf clusters >> >> 16GB RAM: >> 8GB limit for mbufs >> 33,554,432 mbufs >> 1,048,576 2K mbuf clusters >> 524,288 4K mbuf clusters >> 155,344 9K mbuf clusters >> 87,381 16K mbuf clusters >> >> These defaults should be sufficient for even the most demanding network loads. >> >> For additional information see: >> >> http://svnweb.freebsd.org/changeset/base/243631 >> >> -- >> Andre >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 16:11:41 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A603DB41; Thu, 11 Jul 2013 16:11:41 +0000 (UTC) (envelope-from prvs=19047057b3=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 EF36C17E1; Thu, 11 Jul 2013 16:11:40 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004924997.msg; Thu, 11 Jul 2013 17:11:33 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 11 Jul 2013 17:11:33 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=19047057b3=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <00288B90ECA2482E8E90BDF64C88B2EC@multiplay.co.uk> From: "Steven Hartland" To: "Andre Oppermann" References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> <51DE6255.5000304@freebsd.org> <51DEA947.6060605@freebsd.org> Subject: Re: status of autotuning freebsd for 9.2 Date: Thu, 11 Jul 2013 17:11:53 +0100 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 Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:11:41 -0000 ----- Original Message ----- From: "Andre Oppermann" To: "Steven Hartland" Cc: "Alfred Perlstein" ; ; ; Sent: Thursday, July 11, 2013 1:47 PM Subject: Re: status of autotuning freebsd for 9.2 > On 11.07.2013 11:08, Steven Hartland wrote: >> ----- Original Message ----- From: "Andre Oppermann" >> >>> On 08.07.2013 16:37, Andre Oppermann wrote: >>>> On 07.07.2013 20:24, Alfred Perlstein wrote: >>>>> On 7/7/13 1:34 AM, Andre Oppermann wrote: >>>>>> Can you help me with with testing? >>>>>> >>>>> Yes. Please give me your proposed changes and I'll stand up a machine and give feedback. >>>> >>>> http://people.freebsd.org/~andre/mfc-autotuning-20130708.diff >>> >>> Any feedback from testers on this? The MFC window is closing soon. >> >> Few things I've noticed most of which look like issues against the original >> patch and not the MFC but worth mentioning. >> >> 1. You've introduced a new tunable kern.maxmbufmem which is autosized but >> doesnt seem to be exposed via a sysctl so it looks like there is no way >> to determine what its actually set to? > > Good point. I've made it global and exposed as kern.ipc.maxmbufmem (RDTUN). > >> 2. There's a missmatch between the tuneable kern.ipc.nmbufs in tunable_mbinit >> and the sysctl kern.ipc.nmbuf i.e. no 's'. > > That's a typo, fixed. > >> 3. Should kern.maxmbufmem be kern.ipc.maxmbufmem to sit along side all of >> the other sysctls? > > Yes, see above. > >> 4. style issues: >> * @@ -178,11 +202,13 @@ >> ... >> if (newnmbjumbo9 > nmbjumbo9&& > > Thanks. All fixed in r253204. > >> Finally out of interest what made us arrive at the various defaults for each >> type as it looks like the ratios have changed? > > Before it was an arbitrary mess. Mbufs were not limited at all and the others > to some random multiple of maxusers with the net limit ending up at some 25,000 > mbuf clusters by default. > > Now default overall limit is set at 50% of all available min(physical, kmem_map) > memory to prevent mbufs from monopolizing kernel memory and leave some space for > other kernel structures and buffers as well as user-space programs. It can be > raised to 3/4 of available memory by the tunable. > > 2K and 4K (page size) mbuf clusters can each go up to 25% of this mbuf memory. > The former is dominantly used on the receive path and the latter in the send path. > 9K and 16K jumbo mbuf clusters can each go up to 12.5% of mbuf memory. They are > only used in the receive path if large jumbo MTUs on a network interface are active. > Both are special in that their memory is contiguous in KVM and physical memory. > This becomes problematic due to memory fragmentation after a short amount of heavy > system use. I hope to deprecate them for 10.0. Network interfaces should use 4K > clusters instead and chain them together for larger packets. All modern NICs > support that. Only the early and limited DMA engines without scatter-gather > capabilities required contiguous physical memory. They are long gone by now. > > The limit for mbufs itselfs is 12.5% of mbuf memory and should be at least as > many as the sum of the cluster types. Each cluster requires an mbuf to which > it is attached. > > Two examples on the revised mbuf sizing limits: > > 1GB KVM: > 512MB limit for mbufs > 419,430 mbufs > 65,536 2K mbuf clusters > 32,768 4K mbuf clusters > 9,709 9K mbuf clusters > 5,461 16K mbuf clusters > > 16GB RAM: > 8GB limit for mbufs > 33,554,432 mbufs > 1,048,576 2K mbuf clusters > 524,288 4K mbuf clusters > 155,344 9K mbuf clusters > 87,381 16K mbuf clusters > > These defaults should be sufficient for even the most demanding network loads. > > For additional information see: > > http://svnweb.freebsd.org/changeset/base/243631 Thanks for that Andre and thanks for doing this work its something thats been sorely needed for a long time. Am I right is saying there is now the new concept of max mbufs? If so can we get this added to the output of netstat -m if it already isn't? I also think this is worth a mention in UPDATING too given the "defaults" are now becoming sensible ;-) Regards Steve 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-stable@FreeBSD.ORG Thu Jul 11 16:44:33 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 432C197D; Thu, 11 Jul 2013 16:44:33 +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 3975D197B; Thu, 11 Jul 2013 16:44:31 +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 TAA10162; Thu, 11 Jul 2013 19:44:30 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxJyo-000NGZ-3h; Thu, 11 Jul 2013 19:44:30 +0300 Message-ID: <51DEE0B6.7070705@FreeBSD.org> Date: Thu, 11 Jul 2013 19:43:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable List , freebsd-toolchain@FreeBSD.org Subject: strange stable/9 buildworld failure X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:44:33 -0000 buildword was run as make -j8 buildworld and the it mysteriously failed like this: sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -l s liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** [libraries] Error code 2 I could not find any actual error message in the build log. /usr/obj was cleaned out before the build. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 17:20:11 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A41391E8; Thu, 11 Jul 2013 17:20:11 +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 B52D51B14; Thu, 11 Jul 2013 17:20: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 UAA10963; Thu, 11 Jul 2013 20:20:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxKXI-000NJn-Ri; Thu, 11 Jul 2013 20:20:08 +0300 Message-ID: <51DEE911.5070203@FreeBSD.org> Date: Thu, 11 Jul 2013 20:19:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable List , freebsd-toolchain@FreeBSD.org Subject: Re: strange stable/9 buildworld failure References: <51DEE0B6.7070705@FreeBSD.org> In-Reply-To: <51DEE0B6.7070705@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:20:11 -0000 on 11/07/2013 19:43 Andriy Gapon said the following: > > buildword was run as make -j8 buildworld and the it mysteriously failed like this: > > sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 > /usr/obj/usr/src/tmp/usr/lib > sh /usr/src/tools/install.sh -l s liblwres.so.80 > /usr/obj/usr/src/tmp/usr/lib/liblwres.so > 1 error > *** [libraries] Error code 2 > > > I could not find any actual error message in the build log. > /usr/obj was cleaned out before the build. > I was able to reproduce this exact failure 3 times in a row. Running buildworld without -j allowed the build to proceed further. Please note that my current userland is at (quite old) r248369, also stable/9. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 20:07:40 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62D0148B; Thu, 11 Jul 2013 20:07:40 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 29B8211F5; Thu, 11 Jul 2013 20:07:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::79f1:54a9:a312:39ee] (unknown [IPv6:2001:7b8:3a7:0:79f1:54a9:a312:39ee]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2E58E5C43; Thu, 11 Jul 2013 22:07:36 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: strange stable/9 buildworld failure From: Dimitry Andric In-Reply-To: <51DEE911.5070203@FreeBSD.org> Date: Thu, 11 Jul 2013 22:07:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81573088-D8B5-425F-B6A4-22DC66DE6EB5@FreeBSD.org> References: <51DEE0B6.7070705@FreeBSD.org> <51DEE911.5070203@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1508) Cc: freebsd-toolchain@FreeBSD.org, freebsd-stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:07:40 -0000 On Jul 11, 2013, at 19:19, Andriy Gapon wrote: > on 11/07/2013 19:43 Andriy Gapon said the following: >>=20 >> buildword was run as make -j8 buildworld and the it mysteriously = failed like this: >>=20 >> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 = liblwres.so.80 >> /usr/obj/usr/src/tmp/usr/lib >> sh /usr/src/tools/install.sh -l s liblwres.so.80 >> /usr/obj/usr/src/tmp/usr/lib/liblwres.so >> 1 error >> *** [libraries] Error code 2 >>=20 >>=20 >> I could not find any actual error message in the build log. >> /usr/obj was cleaned out before the build. >>=20 >=20 > I was able to reproduce this exact failure 3 times in a row. > Running buildworld without -j allowed the build to proceed further. > Please note that my current userland is at (quite old) r248369, also = stable/9. Hi Andriy, Can you please post the complete build log somewhere? Maybe there is something unexpected going wrong which does not show a clear error message? -Dimitry From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 21:37:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 879C9EB0; Thu, 11 Jul 2013 21:37:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 65C8B1741; Thu, 11 Jul 2013 21:37:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BF1A8B990; Thu, 11 Jul 2013 17:37:42 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: locks under printf(9) and WITNESS = panic? Date: Thu, 11 Jul 2013 16:21:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <77F3F7FC35D843ADA82D54EF37249ED0@multiplay.co.uk> In-Reply-To: <77F3F7FC35D843ADA82D54EF37249ED0@multiplay.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307111621.41665.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 11 Jul 2013 17:37:42 -0400 (EDT) Cc: stable@freebsd.org, Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:37:43 -0000 On Saturday, June 29, 2013 9:19:24 pm Steven Hartland wrote: > when booting stable/9 under a debug kernel with WITNESS > enabled and verbose I get the following panic.. > > It seems very much like the discussion from a year back on > current: http://lists.freebsd.org/pipermail/freebsd-current/2012- January/031375.html > > Any ideas? Yeah, that lock needs to be MTX_RECURSE (the cnputs_mtx). However, it only recurses under witness. *sigh* -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 11 21:43:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 494E81CD; Thu, 11 Jul 2013 21:43:49 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 0ADB7177F; Thu, 11 Jul 2013 21:43:49 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so19553194ied.28 for ; Thu, 11 Jul 2013 14:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AWfOZkZ1iXnb5BiUnGYgW1lQxbjrzHmiALTYgXKqVpg=; b=xdL6EBpPf4gk1iuLu+rhi0QAGn23Os5gPQoJwUuM/bdVgFy2D+uf2eXy7/j0A3ongK w1KWXA/mWWityS+vZTzrAUZTbp0zTPAECs/f5+CiFv5H9Ts0uWTRFpH+Dnh3hrSWI5hH Ozhgq9WEsG4MaSS64A4qNR5iKrl/yjr2S9Yj34X5Rdm3Ngp55u7x1SGqN5nmf0AnjO+A UN2PgN+TrjoWMkPhceMicfbGu+fz867taff5yZI6+DxnuNATaCn/fm5S/sttBhYaCGZf z3JyQdFp5s7oTeBYdc6Y22gCoupM5QXMK8Ox9WndLhI9fZmT2KuD2KhbbV4ZVtiOcV8o sSGQ== MIME-Version: 1.0 X-Received: by 10.43.73.7 with SMTP id yq7mr11635793icb.76.1373579028670; Thu, 11 Jul 2013 14:43:48 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.253.129 with HTTP; Thu, 11 Jul 2013 14:43:48 -0700 (PDT) In-Reply-To: <201307111621.41665.jhb@freebsd.org> References: <77F3F7FC35D843ADA82D54EF37249ED0@multiplay.co.uk> <201307111621.41665.jhb@freebsd.org> Date: Thu, 11 Jul 2013 14:43:48 -0700 X-Google-Sender-Auth: 3xjuGprOCrdW23tYTIv6U4djmG0 Message-ID: Subject: Re: locks under printf(9) and WITNESS = panic? From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Steven Hartland , stable@freebsd.org, freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:43:49 -0000 On Thu, Jul 11, 2013 at 1:21 PM, John Baldwin wrote: > On Saturday, June 29, 2013 9:19:24 pm Steven Hartland wrote: >> when booting stable/9 under a debug kernel with WITNESS >> enabled and verbose I get the following panic.. >> >> It seems very much like the discussion from a year back on >> current: http://lists.freebsd.org/pipermail/freebsd-current/2012- > January/031375.html >> >> Any ideas? > > Yeah, that lock needs to be MTX_RECURSE (the cnputs_mtx). However, it > only recurses under witness. *sigh* I have a patch to make mtx_lock_flags() to accept MTX_RECURSE. I will commit it as long as all the consumers code will be reviewed which should be any day. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 03:25:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14E4A3C3; Fri, 12 Jul 2013 03:25:13 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id D25DB16B1; Fri, 12 Jul 2013 03:25:12 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6C3P06q009288; Thu, 11 Jul 2013 20:25:06 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6C3OtNu009287; Thu, 11 Jul 2013 20:24:55 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 11 Jul 2013 20:24:55 -0700 (PDT) Message-ID: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> Date: Thu, 11 Jul 2013 20:24:55 -0700 (PDT) Subject: What are the ideal ranges for kern.ipc.shm*? From: "Chris H" To: "freebsd-amd64" , "freebsd-stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 03:25:13 -0000 Greetings, Over the years using the xfce4 desktop, I would occasionally receive SHM ERROR messages. As they never interfered (so's I could notice), I always put off attempting to track the cause down. However, now having performed a fairly major upgrade (~1yr since last), The error appears to greatly affect KDE4 (used to use kde3) applications I run within xfce4. The windows don't re-draw correctly, and I receive additional errors,as well: ... Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x0 QCoreApplication::postEvent: Unexpected null receiver ... After much searching, it would appear to be related to the kern.ipc.shm* values. pertinent details follow: FreeBSD udns 8.4-STABLE FreeBSD 8.4-STABLE #3: Tue Jul 2 13:41:21 PDT 2013 root@udns:/usr/obj/usr/src/sys/AMD64 amd64 with 64Gb ram, and 3 cores, and nvidia-driver-308.88_1. # ipcs -M shminfo: shmmax: 33554432 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 8192 (max amount of shared memory in pages) Thank you for all your time, and consideration. --chris From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 04:58:06 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AEA41665; Fri, 12 Jul 2013 04:58:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id BF80E1974; Fri, 12 Jul 2013 04:58:05 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C4vhGp070377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 13:57:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C4vfOc051570; Fri, 12 Jul 2013 13:57:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 12 Jul 2013 13:56:21 +0900 (JST) Message-Id: <20130712.135621.1408565802386368060.hrs@allbsd.org> To: rkoberman@gmail.com, feld@feld.me, trashcan@odo.in-berlin.de Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_12_13_56_21_2013_046)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 12 Jul 2013 13:57:55 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 04:58:06 -0000 ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin Oberman wrote in : rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: rk> rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < rk> > trashcan@odo.in-berlin.de> wrote: rk> > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch isn't rk> >> in stable yet. rk> >> rk> > rk> > I would also like to see this patch hit 9.x sooner than later. It's so rk> > painful when someone forgets to fix the alias numbering on servers with rk> > many, many IPv4 and IPv6 addresses... rk> > rk> rk> Please, please, please, please, ...! rk> rk> Freeze is only two days away, so time for 9.2 is almost over and I can see rk> no good reason NOT to get this done. r252015 was merged to stable/9 today. -- Hiroki ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHfjHUACgkQTyzT2CeTzy0thACdE+jtHh/MenoksycA1kaOIono Y8EAoLpJ37td0h3pQSB1ugZNDBB9conv =AdW8 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_12_13_56_21_2013_046)---- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 05:14:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4DAE39FB; Fri, 12 Jul 2013 05:14:26 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id F372619EE; Fri, 12 Jul 2013 05:14:25 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id k7so12519852oag.9 for ; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) 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=roqFDgiQGc+Ag6fy7hlhkT3YyEXlPRH8+lx/iEYLSiY=; b=x7Eq2+iAePYypAqqXWrvTIr6y9nVs4R1+V2ThAdtDwmz1Yt5W1n/3d8if/W/fEz6nF LHfbYYY8rcP7ApFk+b3MLk7COckxB58isp2xUc26HQrtGksCvspRSpwhcs43JeBi8a/u CVzw+pYnBdbopxq4kfFaXeb1mVAQVS51T8bZip2QN5EN/OtapnOZmcPb1WgLtyr/t8ns 5AReMqNIKezG3GS7dSafgkLxbTbu+0KXoNZETqO1VGBtz/zFtOpn1PDCOMjzR+ZMXCiA 3JNWnhMEHpIrTrZ6IW38gHMnXcbaWQmrMSGUzpRz9tlNJE/xCKVNvIjp3DTnPQprbLSW c32A== MIME-Version: 1.0 X-Received: by 10.60.52.165 with SMTP id u5mr34180680oeo.15.1373606065538; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 11 Jul 2013 22:14:25 -0700 (PDT) In-Reply-To: <20130712.135621.1408565802386368060.hrs@allbsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> Date: Thu, 11 Jul 2013 22:14:25 -0700 X-Google-Sender-Auth: FjS5GM5xIioW26jaY-2H8BAJUZ4 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kevin Oberman To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current , "freebsd-stable@freebsd.org Stable" , Michael Grimm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:14:26 -0000 On Thu, Jul 11, 2013 at 9:56 PM, Hiroki Sato wrote: > Kevin Oberman wrote > in : > > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > rk> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > rk> > trashcan@odo.in-berlin.de> wrote: > rk> > > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch > isn't > rk> >> in stable yet. > rk> >> > rk> > > rk> > I would also like to see this patch hit 9.x sooner than later. It's > so > rk> > painful when someone forgets to fix the alias numbering on servers > with > rk> > many, many IPv4 and IPv6 addresses... > rk> > > rk> > rk> Please, please, please, please, ...! > rk> > rk> Freeze is only two days away, so time for 9.2 is almost over and I can > see > rk> no good reason NOT to get this done. > > r252015 was merged to stable/9 today. > > -- Hiroki > Just under the wire! I'm sure that I am not the only one who appreciates it. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 05:24:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8F4DC5B; Fri, 12 Jul 2013 05:24:48 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E64F1A3C; Fri, 12 Jul 2013 05:24:47 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r6C5OeYJ011751; Fri, 12 Jul 2013 07:24:40 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r6C5Oea0010148; Fri, 12 Jul 2013 07:24:40 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r6C5Oe2v051447; Date: Fri, 12 Jul 2013 07:24:40 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130712052440.GA97779@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130704172528.GL91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:24:49 -0000 On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > OK, patch is applied. I will reboot the machine later > > and see what happens tomorrow in the morning. However, > > it might take a few days since the last 2 weeks all was > > fine. > > > > BTW, should this patch be used in general or is it just > > for debugging? My understanding is that it is something > > which could stay in the code... > > Patch is to improve debugging. > > I probably commit it after the issue is closed. Arguments against > the commit is that the change imposes small performance penalty > due to save and restore of the %ebp (I doubt that this is measureable > by any means). Also, arguably, such change should be done for all > functions in support.s, but bcopy() is the hot spot. Got a new one, 2 hours old ;-) 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcd5ec000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd82e45cc frame pointer = 0x28:0xd82e45d4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 18714 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 trap(d82e458c) at trap+0x41a/frame 0xd82e4580 calltrap() at calltrap+0x6/frame 0xd82e4580 --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- Uptime: 4d20h0m44s Physical memory: 503 MB Dumping 104 MB: 89 73 57 41 25 9 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. #0 doadump (textdump=1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:1044 #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) at /src/src-9/sys/i386/i386/trap.c:957 #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 "s5-2013.07.12-03.15.01") at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) at /src/src-9/sys/kern/vfs_mount.c:948 #11 0xc068a8e3 in sys_nmount (td=0xc2b06620, uap=0xd82e4ccc) at /src/src-9/sys/kern/vfs_mount.c:417 #12 0xc07cd7ae in syscall (frame=0xd82e4d08) at subr_syscall.c:135 #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/exception.s:270 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Hth, -Andre From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 05:51:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 980418BB for ; Fri, 12 Jul 2013 05:51:36 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 313D01B4C for ; Fri, 12 Jul 2013 05:51:36 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id z15so6114072ead.35 for ; Thu, 11 Jul 2013 22:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=gU4m4jht7cMBuyTu/xj3w2kmKOltqJXvDgNCSmYgYqM=; b=qy6j5aTjylHV5DglHBCKOQxXje9J7SKXZGH4EFnZklpWP0a94VlO/t6VpEWGqkCO6M SN2QHCHynQyIGmU+AyebW7x75WyVO3YmAtQzcgzFaBFYTPyfcM6076fLHTkIKVJJUA3K k90YB/+C/9/aQgHzwyPhs3BtuuYSAhQoleudtkG3EyI2LjsdHMqYsXJv+E7Mwfsq4bbj b+g3ZtSf/F7EJk4e46RLa6y41eak4J5MjzY8u83h35zGuhNQG46aPwGzM9PqIIfsYtEA FggWUCYaAuNFyUZTppQsXTwB7EB8ycWZ6B20Q/IQ7SUggptYS2BMCRpexrqh/aHv+i+G AcmQ== X-Received: by 10.15.31.9 with SMTP id x9mr45161090eeu.103.1373608295262; Thu, 11 Jul 2013 22:51:35 -0700 (PDT) Received: from limbo.xim.bz ([46.150.100.6]) by mx.google.com with ESMTPSA id n5sm75266536eed.9.2013.07.11.22.51.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 22:51:34 -0700 (PDT) Message-ID: <51DF9964.2020103@gmail.com> Date: Fri, 12 Jul 2013 08:51:32 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: stable/9 fails to compile: kmem_alloc_contig bad definition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:51:36 -0000 Hello. /usr/local/libexec/ccache/world/cc -c -O -pipe -march=native -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector /usr/src/sys/vm/vm_contig.c /usr/src/sys/vm/vm_contig.c:319:1: error: conflicting types for 'kmem_alloc_contig' kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, ^ /usr/src/sys/vm/vm_extern.h:46:13: note: previous declaration is here vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, ^ 1 error generated. vm_extern.h: vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, vm_paddr_t high, unsigned long alignment, unsigned long boundary, vm_memattr_t memattr); Why boundary is unsigned long and not vm_paddr_t? vm_contig.c: vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, vm_paddr_t high, u_long alignment, vm_paddr_t boundary, vm_memattr_t memattr) -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 06:01:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0093B02; Fri, 12 Jul 2013 06:01:17 +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 4C4791BB5; Fri, 12 Jul 2013 06:01:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6C61DEa071074; Fri, 12 Jul 2013 09:01:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6C61DEa071074 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6C61CwI071073; Fri, 12 Jul 2013 09:01:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jul 2013 09:01:12 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130712060112.GY91021@kib.kiev.ua> References: <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> <20130712052440.GA97779@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YACgKm7aulUA0QKG" Content-Disposition: inline In-Reply-To: <20130712052440.GA97779@bali> 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-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:01:18 -0000 --YACgKm7aulUA0QKG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: > On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > > OK, patch is applied. I will reboot the machine later > > > and see what happens tomorrow in the morning. However, > > > it might take a few days since the last 2 weeks all was > > > fine. > > >=20 > > > BTW, should this patch be used in general or is it just > > > for debugging? My understanding is that it is something > > > which could stay in the code... > >=20 > > Patch is to improve debugging. > >=20 > > I probably commit it after the issue is closed. Arguments against > > the commit is that the change imposes small performance penalty > > due to save and restore of the %ebp (I doubt that this is measureable > > by any means). Also, arguably, such change should be done for all > > functions in support.s, but bcopy() is the hot spot. >=20 > Got a new one, 2 hours old ;-) >=20 > 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 "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0xcd5ec000 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc07cb2fe > stack pointer =3D 0x28:0xd82e45cc > frame pointer =3D 0x28:0xd82e45d4 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 18714 (mksnap_ffs) > trap number =3D 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) a= t db_trace_self_wrapper+0x26/frame 0xd82e43e8 > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_ba= cktrace+0x29/frame 0xd82e43f4 > panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 > trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame = 0xd82e4458 > trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/= frame 0xd82e44a0 > trap(d82e458c) at trap+0x41a/frame 0xd82e4580 > calltrap() at calltrap+0x6/frame 0xd82e4580 > --- trap 0xc, eip =3D 0xc07cb2fe, esp =3D 0xd82e45cc, ebp =3D 0xd82e45d4 = --- > bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82= e45d4 > ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0x= d82e490c > ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee= /frame 0xd82e4a3c > vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0= x196b/frame 0xd82e4c2c > sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmoun= t+0x63/frame 0xd82e4c50 > syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc > --- syscall (378, FreeBSD ELF32, sys_nmount), eip =3D 0x180bdf37, esp =3D= 0xbfbfd65c, ebp =3D 0xbfbfddd8 --- > Uptime: 4d20h0m44s > Physical memory: 503 MB > Dumping 104 MB: 89 73 57 41 25 9 >=20 > No symbol "stopped_cpus" in current context. > No symbol "stoppcbs" in current context. > #0 doadump (textdump=3D1) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump (textdump=3D1) at pcpu.h:249 > #1 0xc05fdddd in kern_reboot (howto=3D260) at /src/src-9/sys/kern/kern_s= hutdown.c:449 > #2 0xc05fe028 in panic (fmt=3D) at /src/src-9/sys/k= ern/kern_shutdown.c:637 > #3 0xc07cd1d3 in trap_fatal (frame=3D0xd82e458c, eva=3D3445538816) > at /src/src-9/sys/i386/i386/trap.c:1044 > #4 0xc07cd4b7 in trap_pfault (frame=3D0xd82e458c, usermode=3D0, eva=3D34= 45538816) > at /src/src-9/sys/i386/i386/trap.c:957 > #5 0xc07ce05a in trap (frame=3D0xd82e458c) at /src/src-9/sys/i386/i386/t= rap.c:555 > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 > #8 0xc072be13 in ffs_snapshot (mp=3D0xc2b35a90, snapfile=3D0xc2ed0400 "s= 5-2013.07.12-03.15.01") > at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 > #9 0xc0748e8e in ffs_mount (mp=3D0xc2b35a90) at /src/src-9/sys/ufs/ffs/f= fs_vfsops.c:483 > #10 0xc068a72b in vfs_donmount (td=3D0xc2b06620, fsflags=3D271659272, fso= ptions=3D0xc2b74d80) > at /src/src-9/sys/kern/vfs_mount.c:948 > #11 0xc068a8e3 in sys_nmount (td=3D0xc2b06620, uap=3D0xd82e4ccc) at /src/= src-9/sys/kern/vfs_mount.c:417 > #12 0xc07cd7ae in syscall (frame=3D0xd82e4d08) at subr_syscall.c:135 > #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/excepti= on.s:270 > #14 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) Please show me the first 100 lines of the output of dumpfs(8) on the filesystem where snapshot creation caused the panic. --YACgKm7aulUA0QKG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR35uoAAoJEJDCuSvBvK1BrNsP/j3lkZ95daE6qdrV1sp7sdDz FdqXHqPj20W0aog9f7/5kf3Q6+LZM1Jlx43+fhfuXkUZ0+vWBvfo9npaoseNjho7 GZyH3EyTS9TBJSQfPJwZxQ0DRHosy5YCoqYbFCqf/LIzdFD9dR93dcfZDI7WIdwA 3F84k3193CbREKNdII5CqJuq3GqilVvyWbX5mDXIpvPraHvDiMUZLJbCA6aW43RS 2Ij8MzZFOjwpAuOeP+5yeOGC2QGkMdKD9orWT1QDaYr7f9Wv8wm6qhPqMDj1gFLz I84EC7kzzWkbv8DbnkVaxd7buZQIj28SVQ6ASPRWz4rERTP9JJlvV9Q3okf/Urll 8d+bTfVNidKaR5Hot5XUHF9C9g6R/AqNGJ7/iz0tF4dL0rG3zcr4a2au5OQFm03D fNGl47mFbaxy+L9DGH0QxSAtqS2G3LHHME+oGY4LTHslq7nEojn+5c/gJR0hI6EA CPj6GU9oRFIpoV+6JeIYhhxWT7curPCtEmjXiOtUYFFNtYfWsAWTYuNDZ9amHAxO OOfwldpSogOmS4EomoWLY6FXmYOCcj7iJ9XlSeUAbbyLNx4GIJmUeY49eSvkvZ9c Pgu0Mp6I44zYEHNYKpzbCA53sXTDhMycLtura4Pe+rcy5ooXc/eg2AueAmeUIF23 F+LqalUcINN4iWcdvFEq =Bd04 -----END PGP SIGNATURE----- --YACgKm7aulUA0QKG-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 06:05:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B8465D68; Fri, 12 Jul 2013 06:05:34 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 35F0A1BE2; Fri, 12 Jul 2013 06:05:33 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r6C65RRT001379; Fri, 12 Jul 2013 08:05:27 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r6C65RAT017934; Fri, 12 Jul 2013 08:05:27 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r6C65RuK051699; Date: Fri, 12 Jul 2013 08:05:27 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130712060527.GA483@bali> References: <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> <20130712052440.GA97779@bali> <20130712060112.GY91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130712060112.GY91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:05:34 -0000 On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: > On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: > > On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > > > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > > > OK, patch is applied. I will reboot the machine later > > > > and see what happens tomorrow in the morning. However, > > > > it might take a few days since the last 2 weeks all was > > > > fine. > > > > > > > > BTW, should this patch be used in general or is it just > > > > for debugging? My understanding is that it is something > > > > which could stay in the code... > > > > > > Patch is to improve debugging. > > > > > > I probably commit it after the issue is closed. Arguments against > > > the commit is that the change imposes small performance penalty > > > due to save and restore of the %ebp (I doubt that this is measureable > > > by any means). Also, arguably, such change should be done for all > > > functions in support.s, but bcopy() is the hot spot. > > > > Got a new one, 2 hours old ;-) > > > > 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 "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xcd5ec000 > > fault code = supervisor write, page not present > > instruction pointer = 0x20:0xc07cb2fe > > stack pointer = 0x28:0xd82e45cc > > frame pointer = 0x28:0xd82e45d4 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 18714 (mksnap_ffs) > > trap number = 12 > > panic: page fault > > KDB: stack backtrace: > > db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 > > panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 > > trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 > > trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 > > trap(d82e458c) at trap+0x41a/frame 0xd82e4580 > > calltrap() at calltrap+0x6/frame 0xd82e4580 > > --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- > > bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 > > ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c > > ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c > > vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c > > sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 > > syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc > > --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- > > Uptime: 4d20h0m44s > > Physical memory: 503 MB > > Dumping 104 MB: 89 73 57 41 25 9 > > > > No symbol "stopped_cpus" in current context. > > No symbol "stoppcbs" in current context. > > #0 doadump (textdump=1) at pcpu.h:249 > > 249 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump (textdump=1) at pcpu.h:249 > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) > > at /src/src-9/sys/i386/i386/trap.c:1044 > > #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) > > at /src/src-9/sys/i386/i386/trap.c:957 > > #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 > > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 > > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 > > #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 "s5-2013.07.12-03.15.01") > > at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 > > #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 > > #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) > > at /src/src-9/sys/kern/vfs_mount.c:948 > > #11 0xc068a8e3 in sys_nmount (td=0xc2b06620, uap=0xd82e4ccc) at /src/src-9/sys/kern/vfs_mount.c:417 > > #12 0xc07cd7ae in syscall (frame=0xd82e4d08) at subr_syscall.c:135 > > #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/exception.s:270 > > #14 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > Please show me the first 100 lines of the output of dumpfs(8) on the > filesystem where snapshot creation caused the panic. OK, dumpfs /dev/stripe/p | head -100: magic 11954 (UFS1) time Fri Jul 12 08:02:40 2013 id [ 517fa356 4ecc9335 ] ncg 82 size 17774144 blocks 17737399 bsize 32768 shift 15 mask 0xffff8000 fsize 4096 shift 12 mask 0xfffff000 frag 8 shift 3 fsbtodb 3 minfree 8% optim time symlinklen 60 maxbpg 4096 maxcontig 4 contigsumsize 4 nbfree 1958555 ndir 695 nifree 1123668 nffree 5395 cpg 1 bpg 27415 fpg 219320 ipg 13824 nindir 8192 inopb 256 nspf 8 maxfilesize 18016597801566207 sbsize 4096 cgsize 32768 cgoffset 0 cgmask 0xffffffff csaddr 456 cssize 4096 rotdelay 0ms rps 60 trackskew 0 interleave 1 nsect 1754560 npsect 1754560 spc 1754560 sblkno 8 cblkno 16 iblkno 24 dblkno 456 cgrotor 50 fmod 0 ronly 0 clean 0 metaspace 0 avgfpdir 64 avgfilesize 16384 flags soft-updates fsmnt /palveli volname swuid 0 providersize 17774144 cs[].cs_(nbfree,ndir,nifree,nffree): (6,43,12636,563) (0,82,12780,534) (0,21,13512,313) (10299,81,12257,612) (18212,74,13467,297) (9782,206,10086,2351) (0,115,12467,419) (0,0,13824,2) (25472,73,13487,275) (0,0,13824,13) (23074,0,13824,0) (27335,0,13824,0) (27359,0,13824,0) (0,0,13824,9) (27268,0,13824,0) (27353,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (10758,0,13824,7) (27353,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27321,0,13824,0) (27359,0,13824,0) (27341,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27341,0,13824,0) (27357,0,13824,0) (27353,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27353,0,13824,0) (27353,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (27359,0,13824,0) (27347,0,13824,0) (1097,0,13824,0) cylinders in last group 1 blocks in last group 1153 cg 0: magic 90255 tell 10000 time Fri Jul 12 08:02:20 2013 cgx 0 ncyl 1 niblk 13824 ndblk 219320 nbfree 6 ndir 43 nifree 12636 nffree 563 rotor 204848 irotor 1187 frotor 204848 frsum 13 20 18 20 22 14 26 sum of frsum: 563 clusters 1-3: 4 1 0 clusters size 4 and over: 0 clusters free: 26198, 26219-26220, 26226, 26775, 26798 inodes used: 0-1186, 1188 blks free: 457-458, 1028-1030, 1094-1095, 1590-1591, 4077-4079, 8258-8262, 9241-9247, 13710-13711, 13763-13767, 14241-14247, 14385-14391, 14433-14439, 20761-20767, 20857-20863, 20907-20911, 21051-21055, 21098-21103, 21193-21199, 21262-21263, 28404-28406, 28497-28503, 28545-28551, 28882-28884, 28933-28935, 28982-28983, 29028-29029, 29073-29077, 30021-30023, 30036-30038, 30067-30070, 36569-36573, 36617-36623, 36713-36719, 36761-36767, 42941-42943, 43124-43126, 43169-43175, 43313-43319, 43490-43495, 43537-43543, 54337-54343, 54386-54391, 54481-54486, 54529-54535, 54577-54583, 54817-54821, 56186-56191, 56549-56551, 56957-56958, 57373-57375, 57733-57734, 58045-58046, 58535, 59865-59871, 59913-59919, 59961-59967, 64762-64767, 65330-65335, 65379-65383, 66450-66454, 66810-66814, 67874-67878, 72902-72903, 73622-73623, 73982-73983, 78009-78015, 78057-78063, 78107-78111, 78428-78431, 92620-92623, 94311, 95071, 95823, 96207, 97343, 98103, 99281-99286, 100242-100246, 100986-100991, 101730-101735, 102474-102479, 103220-103223, 103982-103983, 105502-105503, 106849-106855, 107596-107599, 107964-107967, 108708-108711, 109444-109447, 109820-109823, 110188-110191, 110556-110559, 110924-110927, 111660-111663, 112345-112351, 112393-112399, 113570-113575, 114662-114663, 114685-114687, 114699-114703, 114747-114751, 114797-114799, 114810-114815, 114870-114871, 114954-114959, 115291-115295, 115307-115311, 115348-115351, 115357-115359, 116293-116295, 116342, 119981-119983, 120013-120015, 122603-122607, 122628-122631, 122748-122751, 122805-122807, 124235-124239, 189915-189919, 189956-189959, 189999, 190052-190055, 190067-190071, 190611-190615, 190671, 190678, 190687, 193116-193119, 193135, 193254-193255, 193324-193327, 193350-193351, 193390-193391, 209584-209591, 209752-209767, 209808-209815, 214200-214207, 214384-214391 cg 1: magic 90255 tell 358c8000 time Tue Apr 30 13:01:34 2013 cgx 1 ncyl 1 niblk 13824 ndblk 219320 nbfree 0 ndir 82 nifree 12780 nffree 534 rotor 0 irotor 1043 frotor 4624 frsum 9 4 25 32 35 22 1 sum of frsum: 534 clusters 1-3: 0 0 0 clusters size 4 and over: 0 clusters free: inodes used: 0-1043 blks free: 459-463, 2804-2807, 3674-3679, 3755-3759, 4436-4439, 4466-4468, 4490-4494, 4523-4526, 4629, 4667-4671, 4682-4684, 4722-4726, 4738-4742, 4779-4783, 4796-4798, 4827-4830, 4842-4846, 4858-4863, 4876-4879, 4908-4911, 4940-4941, 4954-4959, 5002-5006, 5019-5023, 5038-5039, 5082-5087, 5133-5135, 5244-5247, 5259-5263, 5274-5279, 5290-5293, 5309-5311, 5335, 5348-5351, 5364-5367, 5397-5399, From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 06:35:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCE908B9; Fri, 12 Jul 2013 06:35:45 +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 0A2391D24; Fri, 12 Jul 2013 06:35:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6C6ZZZH078077; Fri, 12 Jul 2013 09:35:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6C6ZZZH078077 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6C6ZXba078062; Fri, 12 Jul 2013 09:35:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jul 2013 09:35:33 +0300 From: Konstantin Belousov To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130712063533.GZ91021@kib.kiev.ua> References: <201306171530.31208.jhb@freebsd.org> <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> <20130712052440.GA97779@bali> <20130712060112.GY91021@kib.kiev.ua> <20130712060527.GA483@bali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9LeopJxB+v54xXdZ" Content-Disposition: inline In-Reply-To: <20130712060527.GA483@bali> 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: Kirk McKusick , "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:35:45 -0000 --9LeopJxB+v54xXdZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 08:05:27AM +0200, Andre Albsmeier wrote: > On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: > > On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: > > > On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > > > > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > > > > OK, patch is applied. I will reboot the machine later > > > > > and see what happens tomorrow in the morning. However, > > > > > it might take a few days since the last 2 weeks all was > > > > > fine. > > > > >=20 > > > > > BTW, should this patch be used in general or is it just > > > > > for debugging? My understanding is that it is something > > > > > which could stay in the code... > > > >=20 > > > > Patch is to improve debugging. > > > >=20 > > > > I probably commit it after the issue is closed. Arguments against > > > > the commit is that the change imposes small performance penalty > > > > due to save and restore of the %ebp (I doubt that this is measureab= le > > > > by any means). Also, arguably, such change should be done for all > > > > functions in support.s, but bcopy() is the hot spot. > > >=20 > > > Got a new one, 2 hours old ;-) > > >=20 > > > 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 con= ditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for de= tails. > > > This GDB was configured as "i386-marcel-freebsd"... > > >=20 > > > Unread portion of the kernel message buffer: > > >=20 > > >=20 > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address =3D 0xcd5ec000 > > > fault code =3D supervisor write, page not present > > > instruction pointer =3D 0x20:0xc07cb2fe > > > stack pointer =3D 0x28:0xd82e45cc > > > frame pointer =3D 0x28:0xd82e45d4 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 18714 (mksnap_ffs) > > > trap number =3D 12 > > > panic: page fault > > > KDB: stack backtrace: > > > db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,..= =2E) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 > > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kd= b_backtrace+0x29/frame 0xd82e43f4 > > > panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4= 418 > > > trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/fr= ame 0xd82e4458 > > > trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x= 2d7/frame 0xd82e44a0 > > > trap(d82e458c) at trap+0x41a/frame 0xd82e4580 > > > calltrap() at calltrap+0x6/frame 0xd82e4580 > > > --- trap 0xc, eip =3D 0xc07cb2fe, esp =3D 0xd82e45cc, ebp =3D 0xd82e4= 5d4 --- > > > bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0= xd82e45d4 > > > ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/fram= e 0xd82e490c > > > ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x= 15ee/frame 0xd82e4a3c > > > vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmou= nt+0x196b/frame 0xd82e4c2c > > > sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_n= mount+0x63/frame 0xd82e4c50 > > > syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc > > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc > > > --- syscall (378, FreeBSD ELF32, sys_nmount), eip =3D 0x180bdf37, esp= =3D 0xbfbfd65c, ebp =3D 0xbfbfddd8 --- > > > Uptime: 4d20h0m44s > > > Physical memory: 503 MB > > > Dumping 104 MB: 89 73 57 41 25 9 > > >=20 > > > No symbol "stopped_cpus" in current context. > > > No symbol "stoppcbs" in current context. > > > #0 doadump (textdump=3D1) at pcpu.h:249 > > > 249 pcpu.h: No such file or directory. > > > in pcpu.h > > > (kgdb) where > > > #0 doadump (textdump=3D1) at pcpu.h:249 > > > #1 0xc05fdddd in kern_reboot (howto=3D260) at /src/src-9/sys/kern/ke= rn_shutdown.c:449 > > > #2 0xc05fe028 in panic (fmt=3D) at /src/src-9/s= ys/kern/kern_shutdown.c:637 > > > #3 0xc07cd1d3 in trap_fatal (frame=3D0xd82e458c, eva=3D3445538816) > > > at /src/src-9/sys/i386/i386/trap.c:1044 > > > #4 0xc07cd4b7 in trap_pfault (frame=3D0xd82e458c, usermode=3D0, eva= =3D3445538816) > > > at /src/src-9/sys/i386/i386/trap.c:957 > > > #5 0xc07ce05a in trap (frame=3D0xd82e458c) at /src/src-9/sys/i386/i3= 86/trap.c:555 > > > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s= :170 > > > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 > > > #8 0xc072be13 in ffs_snapshot (mp=3D0xc2b35a90, snapfile=3D0xc2ed040= 0 "s5-2013.07.12-03.15.01") > > > at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 > > > #9 0xc0748e8e in ffs_mount (mp=3D0xc2b35a90) at /src/src-9/sys/ufs/f= fs/ffs_vfsops.c:483 > > > #10 0xc068a72b in vfs_donmount (td=3D0xc2b06620, fsflags=3D271659272,= fsoptions=3D0xc2b74d80) > > > at /src/src-9/sys/kern/vfs_mount.c:948 > > > #11 0xc068a8e3 in sys_nmount (td=3D0xc2b06620, uap=3D0xd82e4ccc) at /= src/src-9/sys/kern/vfs_mount.c:417 > > > #12 0xc07cd7ae in syscall (frame=3D0xd82e4d08) at subr_syscall.c:135 > > > #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/exc= eption.s:270 > > > #14 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > >=20 > > Please show me the first 100 lines of the output of dumpfs(8) on the > > filesystem where snapshot creation caused the panic. >=20 > OK, dumpfs /dev/stripe/p | head -100: >=20 > magic 11954 (UFS1) time Fri Jul 12 08:02:40 2013 > id [ 517fa356 4ecc9335 ] > ncg 82 size 17774144 blocks 17737399 > bsize 32768 shift 15 mask 0xffff8000 > fsize 4096 shift 12 mask 0xfffff000 > frag 8 shift 3 fsbtodb 3 > minfree 8% optim time symlinklen 60 > maxbpg 4096 maxcontig 4 contigsumsize 4 > nbfree 1958555 ndir 695 nifree 1123668 nffree 5395 > cpg 1 bpg 27415 fpg 219320 ipg 13824 > nindir 8192 inopb 256 nspf 8 maxfilesize 18016597801566207 > sbsize 4096 cgsize 32768 cgoffset 0 cgmask 0xffffffff > csaddr 456 cssize 4096 > rotdelay 0ms rps 60 trackskew 0 interleave 1 > nsect 1754560 npsect 1754560 spc 1754560 > sblkno 8 cblkno 16 iblkno 24 dblkno 456 > cgrotor 50 fmod 0 ronly 0 clean 0 > metaspace 0 avgfpdir 64 avgfilesize 16384 > flags soft-updates=20 > fsmnt /palveli > volname swuid 0 providersize 17774144 UFS1, weird. I believe I see the problem. UFS1 superblock is not aligned on the fs block boundary, and bcopy() call tried to do the full block copy. In fact, when the snapshotting operation did not trap, you probably get a data corruption in the unrelated buffer. Please try the patch below. diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c index ad157aa..c37706b 100644 --- a/sys/ufs/ffs/ffs_snapshot.c +++ b/sys/ufs/ffs/ffs_snapshot.c @@ -792,7 +792,7 @@ out1: brelse(nbp); } else { loc =3D blkoff(fs, fs->fs_sblockloc); - bcopy((char *)copy_fs, &nbp->b_data[loc], fs->fs_bsize); + bcopy((char *)copy_fs, &nbp->b_data[loc], (u_int)fs->fs_sbsize); bawrite(nbp); } /* --9LeopJxB+v54xXdZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR36O1AAoJEJDCuSvBvK1B7+YQAIR1dGnTbZCC6B0iGFbECx4m EsEk/d8pAB0TKwBCQzugfvhHReULkNTcZYbYg/kFXYxvO09iMzYave20oA0g55Uc XkVfLefjhIi3zNfEsyj23jcgHsl/9PjLo1TAuJTgC5WGWPHBEA/pN8nCXanSmhct fjZxTNX2URDd/26tO+SrGYGczs733AgLodSEBHg2whDklWC8kQpmy/JlVBlmFtWq r3qZGXzGOuxd/8W/sW1rFuPMnGemxKP5btjS3k0g4mH5rr38u7v7MsgVNRVpHuhp MUte5xc+XeeG5FHi+vqIJiX+A0uJmEvaM2X/Cu43XGQYlqKO1kEHQHKgb3FVFfOM 44p3SJnguNlnb9ThTUKG+aToxOUjZc/DdFm4t4Wxx5qU0TyHBqy6ewMemgsD52bs zxeHcb6Tvmn9hpfoamzYMj2uXaDX9ZXRpAyKD/avVB2ExRdITohM7o5obWcDdZPD j3WYofVD55Q6jYE5yKsjt83I7GmAe0FlPLCoOi/G9QVCWOtmNxD0HTXtxBWYYKZ5 QzhAWVd+itB965rJFJ+xS1FxRLOvSXSDT342gm9LoIh2VGwSfEo7F+eMQyDbRgJC RQ8r7sRccn5gPrC5wM700+EsTHIebWtD1Sq5S5yR6HdxPlSRa3Y+0si11wFFn2rm URDw/bUacx5fhMy3hn/w =Jsti -----END PGP SIGNATURE----- --9LeopJxB+v54xXdZ-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 06:52:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE635E83; Fri, 12 Jul 2013 06:52:46 +0000 (UTC) (envelope-from trashcan@odo.in-berlin.de) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.60.26]) by mx1.freebsd.org (Postfix) with ESMTP id 95C001E32; Fri, 12 Jul 2013 06:52:46 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mail.kaan-bock.invalid [10.10.10.1]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bs4Zb47y3zLLM; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at enfer-du-nord.net Received: from mx1.enfer-du-nord.net ([10.10.10.1]) by mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [10.10.10.1]) (amavisd-new, port 10024) with LMTP id dvBYt91V8hj7; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) Received: from mx1.enfer-du-nord.net (www.kaan-bock.invalid [10.10.10.2]) by mx1.enfer-du-nord.net (Postfix) with ESMTP id 3bs4Zb141BzLLC; Fri, 12 Jul 2013 08:52:39 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 12 Jul 2013 08:52:39 +0200 From: Michael Grimm To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: =?UTF-8?Q?ipv=36=5Faddrs=5FIF=20aliases=20in=20rc=2Econf=28?= =?UTF-8?Q?=35=29?= In-Reply-To: <20130712.135621.1408565802386368060.hrs@allbsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> Message-ID: <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> X-Sender: trashcan@odo.in-berlin.de User-Agent: Roundcube Webmail/0.9.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:52:46 -0000 On 2013-07-12 6:56, Hiroki Sato wrote: > Kevin Oberman wrote > in > : > > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > rk> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > rk> > trashcan@odo.in-berlin.de> wrote: > rk> > > rk> > Will that patch make it into 9.2? If I am not mistaken, that > patch isn't > rk> >> in stable yet. > rk> >> > rk> > > rk> > I would also like to see this patch hit 9.x sooner than later. > It's so > rk> > painful when someone forgets to fix the alias numbering on > servers with > rk> > many, many IPv4 and IPv6 addresses... > rk> > > rk> > rk> Please, please, please, please, ...! > rk> > rk> Freeze is only two days away, so time for 9.2 is almost over and I > can see > rk> no good reason NOT to get this done. > > r252015 was merged to stable/9 today. Thanks! This is highly appreciated. A first glance at network.subr tells me that much more has been modified/simplified regarding alias definitions, great. Regards, Michael From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 07:04:25 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DFDDA698; Fri, 12 Jul 2013 07:04:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 3E54F1FB0; Fri, 12 Jul 2013 07:04:25 +0000 (UTC) Received: from alph.d.allbsd.org (p2049-ipbf1102funabasi.chiba.ocn.ne.jp [122.26.101.49]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C749br083292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 16:04:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r6C7490M052950; Fri, 12 Jul 2013 16:04:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 12 Jul 2013 16:03:58 +0900 (JST) Message-Id: <20130712.160358.1330135778606339435.hrs@allbsd.org> To: trashcan@odo.in-berlin.de Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Hiroki Sato In-Reply-To: <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> <201306200229.r5K2TnfR085621@svn.freebsd.org> References: <20130712.135621.1408565802386368060.hrs@allbsd.org> <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jul_12_16_03_58_2013_117)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 12 Jul 2013 16:04:20 +0900 (JST) X-Spam-Status: No, score=-89.3 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:04:25 -0000 ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Grimm wrote in <4c07217dc9200841dfd065a6d52849eb@mx1.enfer-du-nord.net>: tr> On 2013-07-12 6:56, Hiroki Sato wrote: tr> > Kevin Oberman wrote tr> > in : tr> > rk> On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: tr> > rk> tr> > rk> > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < tr> > rk> > trashcan@odo.in-berlin.de> wrote: tr> > rk> > tr> > rk> > Will that patch make it into 9.2? If I am not mistaken, that patch isn't tr> > rk> >> in stable yet. tr> > rk> >> tr> > rk> > tr> > rk> > I would also like to see this patch hit 9.x sooner than later. It's so tr> > rk> > painful when someone forgets to fix the alias numbering on servers with tr> > rk> > many, many IPv4 and IPv6 addresses... tr> > rk> > tr> > rk> tr> > rk> Please, please, please, please, ...! tr> > rk> tr> > rk> Freeze is only two days away, so time for 9.2 is almost over and I can see tr> > rk> no good reason NOT to get this done. tr> > r252015 was merged to stable/9 today. tr> tr> Thanks! This is highly appreciated. A first glance at network.subr tells me that tr> much more has been modified/simplified regarding alias definitions, great. Please let me know if the existing configurations and/or the new formats do not work. The following is a summary of the supported rc.conf variables, FYI: Hiroki Sato wrote in <201306200229.r5K2TnfR085621@svn.freebsd.org>: hr> A summary of the supported ifconfig_* variables is as follows: hr> hr> # IPv4 configuration. hr> ifconfig_em0="inet 192.168.0.1" hr> # IPv6 configuration. hr> ifconfig_em0_ipv6="inet6 2001:db8::1/64" hr> # IPv4 address range spec. Now deprecated. hr> ipv4_addr_em0="10.2.1.1-10" hr> # IPv6 alias. hr> ifconfig_em0_alias0="inet6 2001:db8:5::1 prefixlen 70" hr> # IPv4 alias. hr> ifconfig_em0_alias1="inet 10.2.2.1/24" hr> # IPv4 alias with range spec w/o AF keyword (backward compat). hr> ifconfig_em0_alias2="10.3.1.1-10/32" hr> # IPv6 alias with range spec. hr> ifconfig_em0_alias3="inet6 2001:db8:20-2f::1/64" hr> # ifconfig_IF_aliases is just like ifconfig_IF_aliasN. hr> ifconfig_em0_aliases="inet 10.3.3.201-204/24 inet6 2001:db8:210-213::1/64 inet 10.1.1.1/24" hr> # IPv6 alias (backward compat) hr> ipv6_ifconfig_em0_alias0="inet6 2001:db8:f::1/64" hr> # IPv6 alias w/o AF keyword (backward compat) hr> ipv6_ifconfig_em0_alias1="2001:db8:f:1::1/64" hr> # IPv6 prefix. hr> ipv6_prefix_em0="2001:db8::/64" -- Hiroki ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlHfql4ACgkQTyzT2CeTzy3INwCeKjaEbDXoDCva3qwaYQu0wCVR aBUAn23bflmEp/UV4CqMXFyPs5d8sucN =VSMm -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul_12_16_03_58_2013_117)---- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 07:07:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95D3C92D; Fri, 12 Jul 2013 07:07:22 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id 219621022; Fri, 12 Jul 2013 07:07:21 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r6C77JjI030547; Fri, 12 Jul 2013 09:07:19 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r6C77JRC024055; Fri, 12 Jul 2013 09:07:19 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r6C77Ju3051962; Date: Fri, 12 Jul 2013 09:07:19 +0200 From: Andre Albsmeier To: Konstantin Belousov Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130712070719.GA895@bali> References: <20130704051409.GA22021@bali> <20130704052440.GG91021@kib.kiev.ua> <20130704052659.GA23398@bali> <20130704061550.GI91021@kib.kiev.ua> <20130704142919.GA1798@bali> <20130704172528.GL91021@kib.kiev.ua> <20130712052440.GA97779@bali> <20130712060112.GY91021@kib.kiev.ua> <20130712060527.GA483@bali> <20130712063533.GZ91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130712063533.GZ91021@kib.kiev.ua> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kirk McKusick , "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:07:22 -0000 On Fri, 12-Jul-2013 at 08:35:33 +0200, Konstantin Belousov wrote: > On Fri, Jul 12, 2013 at 08:05:27AM +0200, Andre Albsmeier wrote: > > On Fri, 12-Jul-2013 at 08:01:12 +0200, Konstantin Belousov wrote: > > > On Fri, Jul 12, 2013 at 07:24:40AM +0200, Andre Albsmeier wrote: > > > > On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: > > > > > On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: > > > > > > OK, patch is applied. I will reboot the machine later > > > > > > and see what happens tomorrow in the morning. However, > > > > > > it might take a few days since the last 2 weeks all was > > > > > > fine. > > > > > > > > > > > > BTW, should this patch be used in general or is it just > > > > > > for debugging? My understanding is that it is something > > > > > > which could stay in the code... > > > > > > > > > > Patch is to improve debugging. > > > > > > > > > > I probably commit it after the issue is closed. Arguments against > > > > > the commit is that the change imposes small performance penalty > > > > > due to save and restore of the %ebp (I doubt that this is measureable > > > > > by any means). Also, arguably, such change should be done for all > > > > > functions in support.s, but bcopy() is the hot spot. > > > > > > > > Got a new one, 2 hours old ;-) > > > > > > > > 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 "i386-marcel-freebsd"... > > > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address = 0xcd5ec000 > > > > fault code = supervisor write, page not present > > > > instruction pointer = 0x20:0xc07cb2fe > > > > stack pointer = 0x28:0xd82e45cc > > > > frame pointer = 0x28:0xd82e45d4 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 18714 (mksnap_ffs) > > > > trap number = 12 > > > > panic: page fault > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper(c08207eb,d82e4418,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd82e43e8 > > > > kdb_backtrace(c081df13,c08a82e0,c0801bfa,d82e4424,d82e4424,...) at kdb_backtrace+0x29/frame 0xd82e43f4 > > > > panic(c0801bfa,c0845a01,c2b067d4,1,1,...) at panic+0xc9/frame 0xd82e4418 > > > > trap_fatal(c0ff6000,cd5ec000,2,0,c08b6bf4,...) at trap_fatal+0x353/frame 0xd82e4458 > > > > trap_pfault(baa8454b,21510,0,c2b06620,c08b6bf0,...) at trap_pfault+0x2d7/frame 0xd82e44a0 > > > > trap(d82e458c) at trap+0x41a/frame 0xd82e4580 > > > > calltrap() at calltrap+0x6/frame 0xd82e4580 > > > > --- trap 0xc, eip = 0xc07cb2fe, esp = 0xd82e45cc, ebp = 0xd82e45d4 --- > > > > bcopy(c36ed000,cd5e6000,8000,8000,c281b980,...) at bcopy+0x1a/frame 0xd82e45d4 > > > > ffs_snapshot(c2b35a90,c2ed0400,0,0,0,...) at ffs_snapshot+0x2933/frame 0xd82e490c > > > > ffs_mount(c2b35a90,c322e200,ff,d82e4c08,c2ccbc8c,...) at ffs_mount+0x15ee/frame 0xd82e4a3c > > > > vfs_donmount(c2b06620,10313108,0,c2b74d80,c2b74d80,...) at vfs_donmount+0x196b/frame 0xd82e4c2c > > > > sys_nmount(c2b06620,d82e4ccc,c2b06908,d82e4c6c,c0605015,...) at sys_nmount+0x63/frame 0xd82e4c50 > > > > syscall(d82e4d08) at syscall+0x2ce/frame 0xd82e4cfc > > > > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xd82e4cfc > > > > --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180bdf37, esp = 0xbfbfd65c, ebp = 0xbfbfddd8 --- > > > > Uptime: 4d20h0m44s > > > > Physical memory: 503 MB > > > > Dumping 104 MB: 89 73 57 41 25 9 > > > > > > > > No symbol "stopped_cpus" in current context. > > > > No symbol "stoppcbs" in current context. > > > > #0 doadump (textdump=1) at pcpu.h:249 > > > > 249 pcpu.h: No such file or directory. > > > > in pcpu.h > > > > (kgdb) where > > > > #0 doadump (textdump=1) at pcpu.h:249 > > > > #1 0xc05fdddd in kern_reboot (howto=260) at /src/src-9/sys/kern/kern_shutdown.c:449 > > > > #2 0xc05fe028 in panic (fmt=) at /src/src-9/sys/kern/kern_shutdown.c:637 > > > > #3 0xc07cd1d3 in trap_fatal (frame=0xd82e458c, eva=3445538816) > > > > at /src/src-9/sys/i386/i386/trap.c:1044 > > > > #4 0xc07cd4b7 in trap_pfault (frame=0xd82e458c, usermode=0, eva=3445538816) > > > > at /src/src-9/sys/i386/i386/trap.c:957 > > > > #5 0xc07ce05a in trap (frame=0xd82e458c) at /src/src-9/sys/i386/i386/trap.c:555 > > > > #6 0xc07ba88c in calltrap () at /src/src-9/sys/i386/i386/exception.s:170 > > > > #7 0xc07cb2fe in bcopy () at /src/src-9/sys/i386/i386/support.s:198 > > > > #8 0xc072be13 in ffs_snapshot (mp=0xc2b35a90, snapfile=0xc2ed0400 "s5-2013.07.12-03.15.01") > > > > at /src/src-9/sys/ufs/ffs/ffs_snapshot.c:793 > > > > #9 0xc0748e8e in ffs_mount (mp=0xc2b35a90) at /src/src-9/sys/ufs/ffs/ffs_vfsops.c:483 > > > > #10 0xc068a72b in vfs_donmount (td=0xc2b06620, fsflags=271659272, fsoptions=0xc2b74d80) > > > > at /src/src-9/sys/kern/vfs_mount.c:948 > > > > #11 0xc068a8e3 in sys_nmount (td=0xc2b06620, uap=0xd82e4ccc) at /src/src-9/sys/kern/vfs_mount.c:417 > > > > #12 0xc07cd7ae in syscall (frame=0xd82e4d08) at subr_syscall.c:135 > > > > #13 0xc07ba8f1 in Xint0x80_syscall () at /src/src-9/sys/i386/i386/exception.s:270 > > > > #14 0x00000033 in ?? () > > > > Previous frame inner to this frame (corrupt stack?) > > > > > > Please show me the first 100 lines of the output of dumpfs(8) on the > > > filesystem where snapshot creation caused the panic. > > > > OK, dumpfs /dev/stripe/p | head -100: > > > > magic 11954 (UFS1) time Fri Jul 12 08:02:40 2013 > > id [ 517fa356 4ecc9335 ] > > ncg 82 size 17774144 blocks 17737399 > > bsize 32768 shift 15 mask 0xffff8000 > > fsize 4096 shift 12 mask 0xfffff000 > > frag 8 shift 3 fsbtodb 3 > > minfree 8% optim time symlinklen 60 > > maxbpg 4096 maxcontig 4 contigsumsize 4 > > nbfree 1958555 ndir 695 nifree 1123668 nffree 5395 > > cpg 1 bpg 27415 fpg 219320 ipg 13824 > > nindir 8192 inopb 256 nspf 8 maxfilesize 18016597801566207 > > sbsize 4096 cgsize 32768 cgoffset 0 cgmask 0xffffffff > > csaddr 456 cssize 4096 > > rotdelay 0ms rps 60 trackskew 0 interleave 1 > > nsect 1754560 npsect 1754560 spc 1754560 > > sblkno 8 cblkno 16 iblkno 24 dblkno 456 > > cgrotor 50 fmod 0 ronly 0 clean 0 > > metaspace 0 avgfpdir 64 avgfilesize 16384 > > flags soft-updates > > fsmnt /palveli > > volname swuid 0 providersize 17774144 > > UFS1, weird. Hmm, why? I like UFS1 on my old and good (but small) SCSI disks as long as I do not use ACLs or similar stuff. > > I believe I see the problem. UFS1 superblock is not aligned on the > fs block boundary, and bcopy() call tried to do the full block copy. > In fact, when the snapshotting operation did not trap, you probably > get a data corruption in the unrelated buffer. OK, and this could probably explain why I saw a panic when running a "dump -L /" on another machine which also got a UFS1. > > Please try the patch below. Patch applied, thanks. I also ran a snapshot operation which succeeded. Now let's see what the future shows... I'll see if I can retry the "dump -L" on my several other UFS1 boxes in the next days... Thanks, -Andre > > diff --git a/sys/ufs/ffs/ffs_snapshot.c b/sys/ufs/ffs/ffs_snapshot.c > index ad157aa..c37706b 100644 > --- a/sys/ufs/ffs/ffs_snapshot.c > +++ b/sys/ufs/ffs/ffs_snapshot.c > @@ -792,7 +792,7 @@ out1: > brelse(nbp); > } else { > loc = blkoff(fs, fs->fs_sblockloc); > - bcopy((char *)copy_fs, &nbp->b_data[loc], fs->fs_bsize); > + bcopy((char *)copy_fs, &nbp->b_data[loc], (u_int)fs->fs_sbsize); > bawrite(nbp); > } > /* -- Unix is very userfriendly. It's just picky who its friends are. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 07:44:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0966C149; Fri, 12 Jul 2013 07:44:04 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) by mx1.freebsd.org (Postfix) with ESMTP id 992DC11ED; Fri, 12 Jul 2013 07:44:03 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UxY1D-00040C-Lo; Fri, 12 Jul 2013 09:43:56 +0200 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UxY1D-0002Uz-Hw; Fri, 12 Jul 2013 09:43:55 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-amd64 , freebsd-stable , "Chris H" Subject: Re: What are the ideal ranges for kern.ipc.shm*? References: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> Date: Fri, 12 Jul 2013 09:43:52 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> User-Agent: Opera Mail/12.16 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.1 X-Scan-Signature: 729ef2e9e2cd27dd49f9ca04774c95e6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:44:04 -0000 On Fri, 12 Jul 2013 05:24:55 +0200, Chris H wrote: > Greetings, > Over the years using the xfce4 desktop, I would occasionally receive > SHM ERROR messages. As they never interfered (so's I could notice), I > always put off attempting to track the cause down. However, now having > performed a fairly major upgrade (~1yr since last), The error appears > to greatly affect KDE4 (used to use kde3) applications I run within > xfce4. The windows don't re-draw correctly, and I receive additional > errors,as well: > ... > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > QCoreApplication::postEvent: Unexpected null receiver > ... > After much searching, it would appear to be related to the > kern.ipc.shm* values. > pertinent details follow: > FreeBSD udns 8.4-STABLE FreeBSD 8.4-STABLE #3: Tue Jul 2 13:41:21 PDT > 2013 > root@udns:/usr/obj/usr/src/sys/AMD64 amd64 > with 64Gb ram, and 3 cores, and nvidia-driver-308.88_1. > # ipcs -M > shminfo: > shmmax: 33554432 (max shared memory segment size) > shmmin: 1 (min shared memory segment size) > shmmni: 192 (max number of shared memory identifiers) > shmseg: 128 (max shared memory segments per process) > shmall: 8192 (max amount of shared memory in pages) My 9.1-STABLE amd64 with 4GB RAM has these default settings: ipcs -M shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 1024 (max number of shared memory identifiers) shmseg: 1024 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) Regards, Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 07:52:03 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E6065BC; Fri, 12 Jul 2013 07:52:03 +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 40CA512A7; Fri, 12 Jul 2013 07:52:01 +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 KAA24076; Fri, 12 Jul 2013 10:51:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxY8v-0001N1-Aa; Fri, 12 Jul 2013 10:51:53 +0300 Message-ID: <51DFB561.60906@FreeBSD.org> Date: Fri, 12 Jul 2013 10:50:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: strange stable/9 buildworld failure References: <51DEE0B6.7070705@FreeBSD.org> <51DEE911.5070203@FreeBSD.org> <81573088-D8B5-425F-B6A4-22DC66DE6EB5@FreeBSD.org> In-Reply-To: <81573088-D8B5-425F-B6A4-22DC66DE6EB5@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@FreeBSD.org, freebsd-stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:52:03 -0000 on 11/07/2013 23:07 Dimitry Andric said the following: > On Jul 11, 2013, at 19:19, Andriy Gapon wrote: >> on 11/07/2013 19:43 Andriy Gapon said the following: >>> >>> buildword was run as make -j8 buildworld and the it mysteriously failed like this: >>> >>> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 >>> /usr/obj/usr/src/tmp/usr/lib >>> sh /usr/src/tools/install.sh -l s liblwres.so.80 >>> /usr/obj/usr/src/tmp/usr/lib/liblwres.so >>> 1 error >>> *** [libraries] Error code 2 >>> >>> >>> I could not find any actual error message in the build log. >>> /usr/obj was cleaned out before the build. >>> >> >> I was able to reproduce this exact failure 3 times in a row. >> Running buildworld without -j allowed the build to proceed further. >> Please note that my current userland is at (quite old) r248369, also stable/9. > > Hi Andriy, > > Can you please post the complete build log somewhere? Maybe there is > something unexpected going wrong which does not show a clear error > message? Sorry for the noise, all, it was a pilot error indeed. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 08:56:15 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD172B0B; Fri, 12 Jul 2013 08:56:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C9506177D; Fri, 12 Jul 2013 08:56:14 +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 LAA25573; Fri, 12 Jul 2013 11:56:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxZ9A-0001Sy-Ec; Fri, 12 Jul 2013 11:56:12 +0300 Message-ID: <51DFC488.3020607@FreeBSD.org> Date: Fri, 12 Jul 2013 11:55:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Baldwin Subject: Re: locks under printf(9) and WITNESS = panic? References: <77F3F7FC35D843ADA82D54EF37249ED0@multiplay.co.uk> <201307111621.41665.jhb@freebsd.org> In-Reply-To: <201307111621.41665.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Steven Hartland , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:56:15 -0000 on 11/07/2013 23:21 John Baldwin said the following: > On Saturday, June 29, 2013 9:19:24 pm Steven Hartland wrote: >> when booting stable/9 under a debug kernel with WITNESS >> enabled and verbose I get the following panic.. >> >> It seems very much like the discussion from a year back on >> current: http://lists.freebsd.org/pipermail/freebsd-current/2012- > January/031375.html >> >> Any ideas? > > Yeah, that lock needs to be MTX_RECURSE (the cnputs_mtx). However, it > only recurses under witness. *sigh* > In my tree I have this commit: commit 9ef2a49ec43e6ebf429e4dae3bf230a09ae106f1 Author: Andriy Gapon Date: Fri May 18 12:58:13 2012 +0300 [test] mark all locks in printf(9) call tree as no-witness ... to avoid warnings because of complex interactions between printf(9) being called from arbitrary contexts and syscons code making non-trivial calls into other subsystems (e.g. callout) for terminal emulation purposes. And also secondary problems resulting from witness(9) using printf(9) to warn about problem in the latter and thus causing its recursion. diff --git a/sys/dev/syscons/syscons.c b/sys/dev/syscons/syscons.c index bfbbff7..8539d27 100644 --- a/sys/dev/syscons/syscons.c +++ b/sys/dev/syscons/syscons.c @@ -3299,7 +3299,7 @@ init_scp(sc_softc_t *sc, int vty, scr_stat *scp) scp->history_pos = 0; scp->history_size = 0; - mtx_init(&scp->scr_lock, "scrlock", NULL, MTX_SPIN); + mtx_init(&scp->scr_lock, "scrlock", NULL, MTX_SPIN | MTX_NOWITNESS); } int diff --git a/sys/dev/syscons/syscons.h b/sys/dev/syscons/syscons.h index 353b67f..fbe20f0 100644 --- a/sys/dev/syscons/syscons.h +++ b/sys/dev/syscons/syscons.h @@ -537,7 +537,7 @@ typedef struct { #define SC_VIDEO_LOCKINIT(sc) \ mtx_init(&(sc)->video_mtx, "syscons video lock", NULL, \ - MTX_SPIN | MTX_RECURSE); + MTX_SPIN | MTX_RECURSE | MTX_NOWITNESS); #define SC_VIDEO_LOCK(sc) \ do { \ if (!cold) \ diff --git a/sys/dev/uart/uart_core.c b/sys/dev/uart/uart_core.c index b6bed03..8396f7a 100644 --- a/sys/dev/uart/uart_core.c +++ b/sys/dev/uart/uart_core.c @@ -413,7 +413,7 @@ uart_bus_attach(device_t dev) */ sc->sc_leaving = 1; - mtx_init(&sc->sc_hwmtx_s, "uart_hwmtx", NULL, MTX_SPIN); + mtx_init(&sc->sc_hwmtx_s, "uart_hwmtx", NULL, MTX_SPIN | MTX_NOWITNESS); if (sc->sc_hwmtx == NULL) sc->sc_hwmtx = &sc->sc_hwmtx_s; diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c index 02ad77a..9ee7e1e 100644 --- a/sys/kern/subr_witness.c +++ b/sys/kern/subr_witness.c @@ -632,7 +632,6 @@ static struct witness_order_list_entry order_lists[] = { #endif { "rm.mutex_mtx", &lock_class_mtx_spin }, { "sio", &lock_class_mtx_spin }, - { "scrlock", &lock_class_mtx_spin }, #ifdef __i386__ { "cy", &lock_class_mtx_spin }, #endif @@ -641,7 +640,6 @@ static struct witness_order_list_entry order_lists[] = { { "rtc_mtx", &lock_class_mtx_spin }, #endif { "scc_hwmtx", &lock_class_mtx_spin }, - { "uart_hwmtx", &lock_class_mtx_spin }, { "fast_taskqueue", &lock_class_mtx_spin }, { "intr table", &lock_class_mtx_spin }, #ifdef HWPMC_HOOKS @@ -657,7 +655,6 @@ static struct witness_order_list_entry order_lists[] = { { "td_contested", &lock_class_mtx_spin }, { "callout", &lock_class_mtx_spin }, { "entropy harvest mutex", &lock_class_mtx_spin }, - { "syscons video lock", &lock_class_mtx_spin }, #ifdef SMP { "smp rendezvous", &lock_class_mtx_spin }, #endif -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 09:38:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2D72192; Fri, 12 Jul 2013 09:38:56 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 18E9219CF; Fri, 12 Jul 2013 09:38:55 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so7897715wgh.33 for ; Fri, 12 Jul 2013 02:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bq2P/5UgVaslEAc1iigrH1cX1U1dRiEXy4FvT6fUSSs=; b=FAjU60+NHO11CH6X4B52m9DZ0lIkv7yQ3s/snhBFgS5/sTnrvjKi/PejnfV822DJbl ifUvHogFp+0FDkjgjl6rkhSmrZqNP8EQmTGScI6V8mZyOz5UMncNqRdoZxz7mRBKA4nL tfklQ89K7CG+2BFxVWWRcg3wKtHK4QhdKVe7WMIra0q7NUpe+aS8xr/NAv4FKj9vxEdW d36SXXavFavG15bVD7n4OFQiWdARchvOeK5BDbZ6f3pb/8V4GpLQ/eV3LsFKPSUKTr/W xcIY7/Yo4dXHVJRGZajH821Zx7MOgVo5RCWDaj1EQOoo0PVTLDsBB8U7dNZP8WU7+FgQ e3lw== X-Received: by 10.194.20.97 with SMTP id m1mr23394954wje.31.1373621934297; Fri, 12 Jul 2013 02:38:54 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.217.117.136 with HTTP; Fri, 12 Jul 2013 02:38:33 -0700 (PDT) In-Reply-To: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> References: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> From: Alberto Villa Date: Fri, 12 Jul 2013 11:38:33 +0200 X-Google-Sender-Auth: xAA5a70zvC8kZ_2QBVP_RTF8I1Q Message-ID: Subject: Re: What are the ideal ranges for kern.ipc.shm*? To: Chris H Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable , freebsd-amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:38:56 -0000 On Fri, Jul 12, 2013 at 5:24 AM, Chris H wrote: > Greetings, > Over the years using the xfce4 desktop, I would occasionally receive > SHM ERROR messages. As they never interfered (so's I could notice), I > always put off attempting to track the cause down. However, now having > performed a fairly major upgrade (~1yr since last), The error appears > to greatly affect KDE4 (used to use kde3) applications I run within > xfce4. The windows don't re-draw correctly, and I receive additional > errors,as well: > ... > Resource id: 0x0 > X Error: BadDrawable (invalid Pixmap or Window parameter) 9 > Major opcode: 62 (X_CopyArea) > Resource id: 0x0 > ... > After much searching, it would appear to be related to the > kern.ipc.shm* values. $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message Qt paint engine makes common use of shared memory. To avoid MIT-SHM errors (i.e., blank windows), you probably need to raise shared memory limits in loader.conf(5). The following should be safe values for the KDE Plasma Desktop: kern.ipc.shmall=32768 kern.ipc.shmmni=1024 kern.ipc.shmseg=1024 -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 12:17:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 393DC9DC for ; Fri, 12 Jul 2013 12:17:47 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id B6E9E10D0 for ; Fri, 12 Jul 2013 12:17:46 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fo12so7538646lab.25 for ; Fri, 12 Jul 2013 05:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ee+IpUYZsYFifF86ScDlflqCflAw14dVSjMv6b+mbe0=; b=KGZJ7HJt218xLmYcbN/MEdzqQ9lcaZBrF5SAmLrssbIpSnmaQxXC0nI9zU8ey3wBK/ Yb7gfP1jjUnDDXEiM6a7IKvK4RYwvVhDgJJM4qHO67mI5HUJ11+SCu0iAkvLe+TNwNoV IapnQod/SIlMMJuQ6o1mHKlNGsWmL6vHH1UCBz3HJRwTQwn52k+t6T0VhcI19LswRZ8j uebA88mEW2Izja/E4FLeLbFWc9zWNbaHyHAnLzCUPwk4PmxzCTufCFoApgPzeQ+iUEfq YyImFZ2KmG4XwL9aIMMYqw1MnLXusL9IzhOzwUK44Ff+Jzvg24CSx12bf9VEwMhFETrl SCqg== X-Received: by 10.152.6.228 with SMTP id e4mr19142979laa.61.1373631465694; Fri, 12 Jul 2013 05:17:45 -0700 (PDT) Received: from [192.168.1.139] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id c4sm14374855lae.7.2013.07.12.05.17.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 05:17:45 -0700 (PDT) Message-ID: <51DFF3E7.6060103@gmail.com> Date: Fri, 12 Jul 2013 15:17:43 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130710 Thunderbird/17.0.7 MIME-Version: 1.0 CC: freebsd-stable@freebsd.org Subject: Re: [resolved] stable/9 fails to compile: kmem_alloc_contig bad definition - radeon kms patches References: <51DF9964.2020103@gmail.com> In-Reply-To: <51DF9964.2020103@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:17:47 -0000 12.07.2013 08:51, Volodymyr Kostyrko wrote: > vm_extern.h: > vm_offset_t kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, > vm_paddr_t low, vm_paddr_t high, unsigned long alignment, > unsigned long boundary, vm_memattr_t memattr); > > Why boundary is unsigned long and not vm_paddr_t? > > vm_contig.c: > vm_offset_t > kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, > vm_paddr_t high, u_long alignment, vm_paddr_t boundary, > vm_memattr_t memattr) > That was caused by radeon drm patches found at https://wiki.freebsd.org/AMD_GPU -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 13:40:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE89C7D5; Fri, 12 Jul 2013 13:40:27 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7368D16FD; Fri, 12 Jul 2013 13:40:26 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r6CDeLIU041047; Fri, 12 Jul 2013 06:40:27 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r6CDeG0J041041; Fri, 12 Jul 2013 06:40:16 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Fri, 12 Jul 2013 06:40:16 -0700 (PDT) Message-ID: <7a0e92dcb2921d9b6bf29476baf09e47.authenticated@ultimatedns.net> In-Reply-To: References: <4640843f1a35075d295f99aa9e8ed951.authenticated@ultimatedns.net> Date: Fri, 12 Jul 2013 06:40:16 -0700 (PDT) Subject: Re: What are the ideal ranges for kern.ipc.shm*? From: "Chris H" To: "freebsd-stable" , "freebsd-amd64" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:40:27 -0000 Greetings Alberto, and thank you for the reply. > On Fri, Jul 12, 2013 at 5:24 AM, Chris H wrote: >> Greetings, >> Over the years using the xfce4 desktop, I would occasionally receive >> SHM ERROR messages. As they never interfered (so's I could notice), I >> always put off attempting to track the cause down. However, now having >> performed a fairly major upgrade (~1yr since last), The error appears >> to greatly affect KDE4 (used to use kde3) applications I run within >> xfce4. The windows don't re-draw correctly, and I receive additional >> errors,as well: >> ... >> Resource id: 0x0 >> X Error: BadDrawable (invalid Pixmap or Window parameter) 9 >> Major opcode: 62 (X_CopyArea) >> Resource id: 0x0 >> ... >> After much searching, it would appear to be related to the >> kern.ipc.shm* values. > > $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message > > Qt paint engine makes common use of shared memory. To avoid MIT-SHM > errors (i.e., blank windows), you probably need to raise shared memory > limits in loader.conf(5). The following should be safe values for the > KDE Plasma Desktop: > > kern.ipc.shmall=32768 > kern.ipc.shmmni=1024 > kern.ipc.shmseg=1024 Yes, I followed those instructions when I received the message after the upgrade from qt3 --> qt4. Entering those numbers in loader.conf(5) caused the server to freeze and re-boot ~20 seconds after starting X. --chris > -- > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 14:55:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A7794AE for ; Fri, 12 Jul 2013 14:55:48 +0000 (UTC) (envelope-from jose.fontaine0527@orange.fr) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5961AB6 for ; Fri, 12 Jul 2013 14:55:46 +0000 (UTC) Received: from [27.248.164.135] ([27.248.164.135]) by mwinf5d13 with ME id zSuW1l00P2vbomK03SvYRq; Fri, 12 Jul 2013 16:55:40 +0200 Message-ID: <72ba7892f5fb67f8208940bfbec53275@mwinf5d13.me-wanadoo.net> Content-Type: multipart/mixed; boundary="===============0749775196==" MIME-Version: 1.0 Subject: Re: To: freebsd-stable@freebsd.org From: "Info" Date: Fri, 12 Jul 2013 20:25:20 +0530 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: idhouse@outlook.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 14:55:48 -0000 You will not see this in a MIME-aware mail reader. --===============0749775196== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Re: --===============0749775196== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="iclaims.docx" UEsDBBQABgAIAAAAIQDhD46/jQEAACkGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lEtPwkAUhfcm/odmtoYOuDDGUFj4WCqJmLgdprcwcV6Ze0H5994WaIyPEkU2TZrmfufcM6czHL85 m60goQm+EIO8LzLwOpTGzwvxNL3rXYoMSflS2eChEGtAMR6dngyn6wiY8bTHQiyI4pWUqBfgFOYh gucvVUhOEb+muYxKv6g5yPN+/0Lq4Ak89ahmiNHwgQ0kU0I2UYnulWMdqZdIwT07Kw2Bm6QQcZAz VGTXm+naQCFUjNZoRWxfrnz5SboXqspoKINeOhbMW2jNg0QG8KxmytHwBiq1tJTdvrG1TRoJLP5O brtlzpONJVyY2KXQvc/W2XfpvIZUynatbsz+WGpaTEEDIp+7s3lLdsr4XUI/+vBLN4PEkwefzxcj LXqvCaS1Bfx/BxtulzyH1dRTchcP1oe6fiWUPT6PTw39MX8EIk7/GMtvyV3rN1Uk/vFBNs/D/9IG s1ey4mtgqmYWDs78S+ta9F4TrzB7PFr6H+BdRtr+6ZD+EMbuzqqnv2mdbC760TsAAAD//wMAUEsD BBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9h yH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99r eG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1 jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDP JZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD/ /wMAUEsDBBQABgAIAAAAIQDX5gieIAEAAEQEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTT0vEMBDF74LfIczdpl11 Fdl0LyLsVSt4TdvpH2ySkkzVfnvDyna7uHQvuQTmhcz7ZV6y2f6ojn2hda3RApIoBoa6MGWrawHv 2cvNIzBHUpeyMxoFjOhgm15fbV6xk+QPuabtHfNdtBPQEPVPnLuiQSVdZHrUfqcyVknypa15L4tP WSNfxfGa23kPSE96sl0pwO7KW2DZ2Hvny71NVbUFPptiUKjpjAV3NHb+AiyTtkYS8FdHnhH4efuH kPbkx4JH933J92uyxLAKyaAHlaP18R45JmkJIgkJUQyOjPrwY5+iiCI+qbwlVIsjWYekqYymTObd LJpJWhrJfUiIb8zfkMgHM3ufM3EJ5C4kiPtHcVAOCPzk76e/AAAA//8DAFBLAwQUAAYACAAAACEA Z5z1124NAAAKmAAAEQAAAHdvcmQvZG9jdW1lbnQueG1s7F3bcts4En3fqv0HlB62kipfKNmWbO1Y s7JkZVwTX8r2VGYeIRKyOCYJFghKVp72N/ZtqvZP8in7JdsNkoook4ycC8WEcCqWxQtANhp9Od0N /PTzk+uQGROBzb3TRnPPaBDmmdyyvYfTxm/3o93jBgkk9SzqcI+dNhYsaPzc+/vffpp3LW6GLvMk gSa8oDuDs1Mp/e7+fmBOmUuDPe4zD05OuHCphK/iYd+l4jH0d03u+lTaY9ux5WK/ZRjtRtwMP22E wuvGTey6til4wCcSb+nyycQ2WfyR3CE26Te6cxg/supxXzAHnoF7wdT2g6Q193Nbg1ecJo3Mil5i 5jrJdXN/k94sQecwHq4TPfacC8sX3GRBAEeH0clli02jqO+YgNjE8o5NHiHdZ/IkLrW9ZTPIHWvj vxy8PRi8/ajvfWzq44sALXrAS2NuLfDTJ/Mu8KJ1e9owjNZB22j1G8mhGxhowzgedZrt0fLgkE1o 6Mjnl9/gIeP8aDBsqR78G4EdBFML2ptR57RhOowKbMjkDoe2aSg5fp3YDpwdqZ/GvrrJpyaQGs7R iWT4GHidY+Mrtw6XX25DBw6oZtRtPJR4zduZA1erLptReyJ6FjHingyw1cC07dPGvWDjEKaOJJd3 2AGjgewHNoUztssCcsXm5Ja7FGg+7077XpBxjxk8v1o9zDj6PQjUp3rl5KmMIf7DRiXMWzaIyCHZ k2wuD97bHhB51IoJ8j65t2UkRwb4Juoto2P7MJL4nvCpaI+fz4b46PDg+Ex1rUb9U0OcvlwP8ZIh KjzEQ6PVPgAtEk/sTw0xzNejM9AG0eVqiOMpr5in/Fn8p5nwtQnKjomI3/XcXp3bMFiZ44tDVith ByK0d4EiTyrBp1TOkjSokYYnnaP+ScLet6nZUEdqodXXDUC/gub0BQuYmLFGz7NsSobUdhakiJgH HeMQLccs0VJHYvZ+4WHANMVWrBCw+N7nWSZgdgqlOJUL85wLz3fbZDAF30fQh9CXdJ0XwQjnk3OB 81sufGDgwGeOcyepkJGSSM18zaxA68QoRAF5ScXDGq9mU/TcszLombYFtSTt7awRU3Nf/sTPmfF6 hje+ltuHMxyFJ31cUD8U9hpzFs70TFcx3/FPS1btMqxACLlwwBYAAO0kLJ2hHPGDAM/aPEkJ8RjO 0vZuhALI3pA5U5s0m4AVNosI1z5uGgethiZcQrgdcoE+Vh7NKuGWliiiYk8ArVPlN1aKUbZFh0wt XCSCEqqtYPJppV0B1axxuzXcbls4SalcnaNvhxAAIu9sz2OiUO+mDcxquJql0k/hJM+kI+KZmjQx hNR7xwgVjDw41CKSE9vDsDdZ8JDIKZXqjymdMTLnHhxhJAhdwifkw3+bOxCoxP9vzm7Iq2uPkUuI QEJcmrwRDO48E7aEQCu54aFnkTsIQUBU8eE19EDuoR2lyMm1h6FG0ve8kDrkRnAXH4EAlzh0zIWK c5O5Laeq7/NQ8DzdvxI3TQR6/cyBHIGhpUQRmgqQXsS4QcLB1IYZoZgR8yyKOO7swBi2VLj5eSC4 ziqKAPxM7imAz28ED32UGAPMnfEWRdSsvVTOm78gmKkN8hnkJkRKkJoXGNP1IOfiHReONbctEONA cjm1A+Bc+z0j8MeDPWMeAduRCDjJXYhLQUuQyRLfYYMzNbMtEL3BDgG5jx3YgviQV8U9kMfjEFJ1 IF+HWGzGHO6rtCnshnkAkZnMLRrMzqhjHA+q5byWan3IHmaZwVhFVGVWaCp9BoT1HeoFeynqZbot aT/kdsVDSTs0FfBQsvMNthFFL3GQcdAibGIJeNXP6NBWdk4KGcYS/uChSM3zFTgZTdYqQnwlTiAg UXYqhTZZi03W2HG6t81HMAKuQncMYMDvhZw2MM5P6q2Ph0X00cZn7/fd5vHJbquISitJjT+4bkfp bRhfZKSlzTdtpEVZ4JXK5C6a9QmOtGJ2Z4xobImjtx/bgmUm6//gk3DFwK4znPIreOrfYVJpuYZk 75ExHwFrwDEis8iLzCKTexMASDxpg+uNUMqMA5hi8XDsMGI61FaItq9QE+oCXC2JFTK8EtvyoZyF sCcARWwoMWN7ZASDQcaAh8wJgNeP6OHjdVDrBAEZcAWmnCjE3OMyap0p5AaBlagLuB3xdYTdsV1T 4gU8fhL1/NGFtusyq0gZp0GAGgZ4ZM+mksHMwBAB4lyTUADaIgCwcugirbvXHK8iwV8LUaPd9ly3 vTi/+sNf94DD8vGfMHMBYEWgFWavSx8BgiUw6akSKwCQPsC5OGimSlGFhbLCAcgVivLgL59xHyQQ dRyQBSpKBrxLfvOgUQEo76sRhMNI3wXBY1LsAsNfPtshWFyH3/sTdQYB2Y9tvIYO4Enijj2ohiMt YwER42CPIBhBoMTVhso+GhDmwBsI7kHzDsyhQH0HWQSnaCzOonbgDf/AmHMcpsPazT1AoAmURMJc S0TXDoTtPElNqXBqJVcDeE0sfRVkho8Mbxf1Ti0LiiaCWIou43sTCPtxrBkt9P6HfeOsc1BrYDmK 0io0+X///k9QpCNqL+dkr5uiTybQXqRJM9yA9OXKsdNuwLaKcYs4PGPs0pfrsQMUenuF1OmJlLZg P3fs/Du5ALUaV3W/tQN5Q6EUSlB/GtXjgFsQBW1s52ONe1wQDuculqX2qmwc5MXyBu3Zf7VCixXP Phno+oXOcoIfV9Rl3bQNVJrW0rPns9eqKBHu0LMH4Fao1Iodjn7kT6TsvDV/v3lgnBmdWnsNX98O 3siW0hJFS5TPXwCoRKEaSRSAf0VhlqKWJNvyqLUk0ZLku5EklxyWCWRxao62TAqWM/kWCJ22TL7t unwlqmXt6yhfp/9QuESStkrWrJIV/08DS/ECZRtgSu3DZn+k1gZ9XtGUAHUrCVEZcva83em3Dxsr CVHabtN223djt12bZoiLPBcX/mlxq8UtGCZx+mV2Lk391E5x4syl2EsrIMiYfdFahLFmSdRQ/egr e7d0Gjpr3mQ2EbOXH9Qk3KzeKJumeYtkaqr2fqWet74wUzYRnzNmHSfyh782msV5HHd0aHSOz5SR /YOXACAqfyPoIw2mG1EsZq/MgHnRPE20SrFzE7tHL3FudNKITho5/Wok+Lj6c+/VCNZuMG1aHK5K lyylU6xqkeiek2SzborWuIJf9gBc9OTrlHzNFKDts6PBUU7udYYATV+uci3jQysCtEz5iKU7sAUO m8CuMJ1kE5gfXIFq/Bzx82yz/2YK24OtpdqtAMe4QkMV5ee47BpaNMIM4yR3tdpKWPBboUrn+OC4 dXKYSxlkoSKzc1sqeCvEOklpmJWJVl/+Sa+2kKl00zGWtAWXoXTTl+cUOHwyJFOmVtYKOAGSS91b r8QYPuqPcyw8TOegrkgAlJMG2Jb9wy/O0X3pHoPl0iHbEMn1RpAunQOjfbJudccHX6A/voguzc5B +yhzt0W1QD3Udrrsbkot2E/obBTV2QQbbLc474YgwtTOR7gtqMPwVpCCsUiAAm8LCrsD9i9cAZvz R9ySM0+JIKmquFFZqfxVHIK52GCLskro4lJpJntvuYT1NAvTfmvPWTkuFCncva2OzJRedyLTpFur e1zBnNNntPX2bBPhsl3fBD7JHMeTM2MwPMq2WDJM8/TlenCrPbgv3AI4DRSpwY1bqDvYWTrWkMzZ Ff+iEoooIsS4/N3McwFQsuFPoc1dsFX2C9yTH2Pf+FxKj65vyeD6anRxe9m/v7i+IoP+27e5bl+F 2LVkUxxh5t3vk91KppSGnjfeMVn2cqFnhRpUVoKVzFIboNFpM+eTaHT6cmUVxYeqZBVVZ/cCbSt5 CAFCmkv0u0K2kgKwiQWbA5ky2kqlSE2lfb30PKmjVdT7ZLZShWyeSpnomsteoOdVJlNulEmz2JPr dAOfmhCn8WENTiZmrNHLdUOqEn36NkvUfXHwKRMTbBdstJGBCaYv17ARd2lsAZRo+yaAUeaAfjkO GI9xlSzebeRcaNs2ZdvaZYcyMAvj6vr+vEtGsNnfJJQhLEEPAXU3xDWgseR1hzxGWw2YU2Y+Rovp X3hj/kT+QV3/n+TOpy7sFOjgus+4YaBgD6EDK0OHvgULseMC0LDYs/d/AAAA//9sUu1ugzAMfBWU B1iBftGpIHWt2K9OqO0LQHAhEiSIuGPr088O7dSpEyLEPp99PqF05Q1Ka/52vbqC10MDuYX1ZHjF hM8+WdPh0WtVecj6WPh+lC6DRSocko0FqdFoqSq3UqlYnHooLrIG9PZHQWnqiRurckJUC9b7gME7 mDbXDNYbbf/hSPtcPeGZhTulaQzr+swb0rTjh5thDS1sGYsFwhcGv8mT0hiLNBSObq93bujfM1ve wPUbc7z+uB8mL38sIaRjKRYkZqzCucPe7PxwMY146LNht+SRSFw6n02jt52zsauOrGeIRRCGM5/p Nd3nEd2d3K7a5zwHTReLle8qelXV1CjwIxcWBtG0FEcrFzdwfkBryEsgT5a0GvU5G4MPYXVBF96m kbdshe1yCSPFiSiNfO9VSUijNGQKJYmcLhyJHBnNcH9NYcpvdyHKpQWNyQ8AAAD//wMAUEsDBBQA BgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2Hcg dG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+w R1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGE tL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5Vltd ijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQ w1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8A sO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU3 5/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNE LYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fev nj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcm zosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2e ihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbt Y3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKk IyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU +GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+Q BxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5 hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2ct tLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qi QYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN 4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twt xgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk 8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWF tfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7 mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QL N3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB 1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSV qRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2 L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w /1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt 2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTcl gaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQDaJenQ+gUAANEUAAARAAAAd29yZC9z ZXR0aW5ncy54bWycWNuO20YMfS/QfzD83I3nPpKRTSBpNL0gaYs6+QDZlm0hukGS19l+fSnbirPt cRD0yTI55JCHZzgSX7/9XJWzp7zri6Z+nPNXbD7L602zLer94/zjB/8QzGf9kNXbrGzq/HH+nPfz t29+/OH1adnnw0DL+hm5qPtl8zg/dvWy3xzyKusfqmLTNX2zGx42TbVsdrtik19/5leL7nF+GIZ2 uVhcjV41bV6Tt13TVdnQv2q6/eJi6ZrNscrrYSEYM4suL7OBAu4PRdtP3qr/6422OkxOnr6VxFNV TutOnH1r5TXdU9Ntv1h8T3ijQds1m7zvCdmqvKRbZUU9uenL7/FzwfNdse6y7vkrJ2+obH83TTU7 Ldu82xCgVHPG5otRQRs3u9WQDTmp+zYvyzMJNmWe0fan5b7Lqiqjol0kZ5ttvsuO5fAhW6+GpqVF TxkFaMXV5eaQddlmyLtVm23IW9LUQ9eU07pt83szJE3VdpTwJQgiS5sNZ9/EyW0/BjY+/NU0w2TG mLRMMXOxGLU3DRMscQ5rOGcJ1BgtDfZmtU8EtAmNUtcs/xVBrKJIQ5tYJQrHlmgZKWiTMubuaHTi cGxeJCaE3ryOOEcazngUwHy4ZDGz0EZqaaM7Gm9SqFE8jWHU3MpA4H2sTu94C3QUSbhPaMMQRxAT Q3CmifUYN+6E5x7u45QOcNQpkwbyTQgWp7CmQthAQ3SENExArIVR1BNRbMJYq7Em5DFmvIiVUHif 1OgY4iaFsgyy6v45JbqnEmYq6fxoyF7FrbYwHyWFEZAHShmtYoSOslZ4WDkVMBfjfRKRpvBsq0TH CeSbSolvsNrKC4fZq7n1YYCi1orZAOajlQxih20Igjsak1q8D/VwB9HRiUkiWDntjU2gN0PdxcKa GqE8xtpI43HfMYpHHjLRWEIUstcEnGG+mUAKzDcTa+rLCFGTsDSEZ9tQv/Y409QKXFPjpRGQO5ar MIERWMlMiDVjsWEE1mgWQ+5Q11E4ahtSdBBrmzCLT6N1TBnIENIkGtbHptTkcdRepilkr/WKhXds LAtgfQJuA/x+EAgpAhhbILVNIa8DY++gE1hhPcQgsEphvgUBtXjYd4JAeuMREwNHDIEYBN5ybBMy Q/RF3kKpggTiFiqThrDzhSG15XuaGCMaRoq6FYxgvJ2xt1hEAmIQJsaHkKO0jbd3NFqE8M6KtHEc dr4otEQeFHXkdMrgyYqZjJhCNjFXiYEYxJI5AWOLjdAaYhAHdAXDHhLTewi+mZKQcQnzSWIlPYya Xjk17teOCYNr6ghqfGM4qziDUbvARgxm6kKrI8heF7HYwp5I16xxkNeOwsZvT87xEO+TMuE9xC0V 9IYP2ZvSHZPA7pLSRRdBHqSGujxEhzSRgfWhNurxu1gamMhib7F2uO+ksXEh5HXqTKIxBl5KDW3o OpcaVsFzrTXMxwt6d8AaKWIOzzY1PolPibfK4ip4q+/cGD5S1MrRCfYROcOZOhZwA22cEEpATSrt 5YtycfnkpW/fajkOJ/7spidP38+z6vKRnWTVuiuy2ftxfEEfzNVy3X2Ki3rSr3Mao+Rfa1bH9aR8 eLgo+iorS0/f6JOCJhcXzbboW5fvzo7L91m3v3k+g14tOyilicBvX7yNE4a8+7lrju3F66nL2l/r LYmnDfn1M7paFvXwrqgmeX9cryarmqYYX6mO9faPp250uLgBdFoONHjKR4TeZfV+mgjk9cPH1bj0 tNyU3WocTuXvs7alYQQtWe/547ws9oeBjxOOgf5ts+7T+c96L646cdbRv1F3/pNtxsxo9fVhXHB5 pFXXh5tMTjJ5k6lJpm4yPcn0TWYmmRllh2ca29BY5hMNgabHUb5ryrI55dtfJuHj/D+iCwj9IWtz qus4tSGCNcuz4DrG6WdPy/wzzYTybTHQ3K8ttlX2mUZE1NjPbL4uL7Pn5ji8WDy6Gle3L6SzbTZk ZH+u1Qtjqh0NmV4Gc1pu801BjFw9V+vblOjVJfKy6IdV3tJAaWg6yvk8afrp7Pk2i3zzDwAAAP// AwBQSwMEFAAGAAgAAAAhAIwBJMowCQAA0UUAAA8AAAB3b3JkL3N0eWxlcy54bWzcXMFy2zgSvW/V /gOLd49lyWNNXKNMOc54k6pMJhPZtWeIgixWKEJLUnE8X7+NBghRJEF2m/QeNofYBIh+DXTjNaTg 5dfffuyS4LvM8lili/Dip0kYyDRS6zh9XIQP93dnv4RBXoh0LRKVykX4LPPwt7f//MevT9d58ZzI PAADaX6dLcJtUeyvz8/zaCt3Iv9J7WUKfRuV7UQBj9njudps4ki+V9FhJ9PifDqZXJ1nMhEFgOfb eJ+H1toTxdqTytb7TEUyz8HbXWLs7USchm/BvbWK3suNOCRFrh+zL5l9tE/4406lRR48XYs8iuN7 cBymuItTlX24SfM4hB4p8uImj0Vr51a/1doT5UXF2rt4HYfnGjH/G2x+F8kinE7LllvtwUlbItLH sk2mZw/LqieL0DWtwO4iFNnZ8kYbO8dplj8r092fTB6e0JW9iGDhAEdsCgkBhHhonCTWgZ7Or8qH r4cEGsShUBYEDQBY1Sw81lYc4gpRXposgV65+aSib3K9LKBjESIWND58/JLFKouL50X45o3GhMal 3MUf4vVa6qS0bQ/pNl7Lf29l+pDL9bH9rztMMWsxUoe0APev5pgFSb7+/Uck9zrFwHQqdIQ/6wGJ NptXcNChQ3z0xjTUULHxPyXkhYlhK8pWCr2NAvS/EwhnfRgMNNUzqk4A7bJ8nQ03cTncxM/DTWDy DluL+XAvgDyHRsTkRiUr6UEtVGSSr7oOszcdKatHNLKod0QjaXpHNHKkd0QjJXpHNDKgd0Qj4L0j GvHtHdEIZ+eISCBx1bNohqtB2tj3cZFIPb6TgC4GUp0tNcEXkYnHTOy3gS6sdbe7yHJ5WBU0V5FO X06WyyJT6WPvikB11lv3xZz8+26/FXkMJ5qepZ8OXPp7sUpk8K8sXvdC/WySrzEnPJi0lrAviYjk ViVrmQX38oeJKGP8ZxUszSmj17mBYf0UP26LYLnFktsLduVZdP9KGPuf4hzXoHMzXXmm0mecFMMr T176jf8h1/FhVy4N4TRyZficEeYaBLrYvUSXOkTN3dU7Cx0AyhRMueBPAe0T/DfFhW9fx5jivylF L7RP8N8Urhfax/zoji+bad6L7FtA2l5z9t69VYnKNoek3AO99DBn72AHQZsCexM7+ySSmLN38Al9 BjdRBJ/cKHnKjsWRRxko7HAYFNxs9Lmwg1KjvQvGjNgBqmFNGVjDuJYBxCbdr/J7rL944hYDZGl3 1uzdzjPPCkAJIp2h/zqoov8MPfVwHhXlYwpfl+QyoKHNPDuPimbzydQ7RoyHFT4G0LAKyAAaVgoZ QJ788J95XE2kgwwvjgwsNi27KoZpR2bmOZuZHRCvBIxUNwnnL8/u9edCs24SUNgBatZNAgo7OrVa 5uomAWu0uknA8lQNf4yqnMqZFLtuVoHcSYAwo3HImwA0DnkTgMYhbwLQcPLuBxmPvAlYbG5wnFol bwIQvsL5qO+AquRNAGJzg2E7+51RWffQSveH2xHIm4DCDlCTvAko7Oj4yJuAha9wMqGG5aiOgDUO eROAxiFvAtA45E0AGoe8CUDjkDcBaDh594OMR94ELDY3OE6tkjcBiE0PDqhK3gQgfIXDDa3kjbv+ 1cmbgMIOUJO8CSjs6NQI1R1SCVjsANWwHHkTsPAVTjJYLExuzqTGIW/CjMYhbwLQOORNABqHvAlA w8m7H2Q88iZgsbnBcWqVvAlAbHpwQFXyJgCxuaGVvHEzvjp5E1DYAWqSNwGFHZ0aoTqeI2CxA1TD cuRNwMJ8GUzeBCB85aVAnBmNQ96EGY1D3gSgccibADScvPtBxiNvAhabGxynVsmbAMSmBwdUJW8C EJsbWskb98irkzcBhR2gJnkTUNjRqRGqI28CFjtANSxHdQSsccibAISJOZi8CUD4yguAcBdxwjQO eRNmNA55E4CGk3c/yHjkTcBic4Pj1Cp5E4DY9OCAquRNAGJzg75nC/dFyddTLzxJQL1nUN5qIANO PUGiAtoJfpUbmYGSSfbfDhkIWM6QgehJD+oU3yn1LaBd7J55EoQMFa+SWOGV7me8pVMRIszmHUqC +z9vgw9GANMYhyl1evMG1ENVuRDKk7RwCPwsnvcg2dmXN8u1NRAIaV2XlQChDu0jCIKsrEcP1jof eBFFVbYZ/93WouLvoHlbl+9MJr+8v3xzi9oI8AVN9jjhYO00p6g3qgKXAiAr9FoJkC39qVVIDbdA cvWtbC/N3W5FZhb4KN8o37EaDv9sZvPJ5eTKDG/IvVYSRHmwphdG72Ueb0DelZu72nZdrSrMvoVP zZesWOwS/01MP5yKxZ6u1aHQzZ++J6XzKAMw6jG9xCDMwx8nUrxFeB/vQFz4WT4FX9VO4BWxUorX 2olSvNaeKG82YwKszN+3Of48KvNmduHyv4/KPNMGXqO7/hSJIGoiAjldR55atYS7wIZaiXrWeiQV 6GozIay04ngAN++dXPCFJr/fhZYRdPiMMoPODRbgK96MtSnb56G7kocTKFaJyQ745WOqdysoQzHV DCusfwgDCP23Mkn+EJhLhdr7X03kpjC9FxM8StVMrVRRqJ1/fIZKA/SkzQAscdUZ86gn4V/79LBb yQykgh3r/1npI0iDYkBgge2etAA9Jfb0rbrft5N8jg45LA0qOuvce8Ja9Vy2ncE0OJJajQ1b9wT6 3saN3iwzHafMXuXC/2Oy6QjOUx4X8ixRj6qRQJUuXG1yWHxrTEylY/WE8p7pGDdc++B6eJ412ZG6 DYDdT84ELZkTaS0BkAOW8An8ubuzyVg2ajE6UCn4DEvBqRZuSaxErb6LbPPQxSh157TDg90wK4OK pZI5ra68lHKVPJ9tFNyvzhrxfzrp5U3bF0didnb4LPb7RJ5FKoX/NKGQ6zN9ZpIN39vfeu05nByS XTq9E0miVIr6vXpO2T4j7mtzr3p4rjJxxeiR019n5zXOr/Zg6o6coPb3nT8h3na4j/nFFo6XuvCW B0jXgOdG84QrczwgXrQcEE3beHujvsBdkRtaVitYlszcx7yS1TwU6ttn/mO9W97/0Xq37wl9aHLn 78buxW97jt19+6KZ9qA4wUE0jrUZGuMBVx9PF+EcZMFoAYimAOHtQSRWSAutZVIfyaz8LX/7XwAA AP//AwBQSwMEFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4ACAFjdXN0b21YbWwvX3JlbHMvaXRlbTEu eG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEz8GKAjEMBuC74DuU 3J3OeBCR6XhZFryJuOC1dDIzxWlTmij69hZPKyzsMQn5/qTdP8Ks7pjZUzTQVDUojI56H0cDP+fv 1RYUi429nSmigScy7Lvloj3hbKUs8eQTq6JENjCJpJ3W7CYMlitKGMtkoByslDKPOll3tSPqdV1v dP5tQPdhqkNvIB/6BtT5mUry/zYNg3f4Re4WMMofEdrdWChcwnzMlLjINo8oBrxgeLeaqtwLumv1 x3/dCwAA//8DAFBLAwQUAAYACAAAACEA1uQTpP8DAACKFwAAEgAAAHdvcmQvbnVtYmVyaW5nLnht bMxY3W7TMBS+R+IdqkiT4GLLT7O2q+gQW6kEAoRgiOs0cVcL/0S221IueRkegcfiFTi2k8ylIe22 Vsoulsbn+Njf55Oc7+TFy++UdJZISMzZyAvPAq+DWMozzG5H3pebyenA60iVsCwhnKGRt0bSe3n5 9MmL1ZAt6BQJcOxADCaHSzDPlcqHvi/TOaKJPOM5YmCccUETBbfi1qeJ+LbIT1NO80ThKSZYrf0o CHpeEYaPvIVgwyLEKcWp4JLPlJ4y5LMZTlFxKWeIfda1M8c8XVDElFnRF4jAHjiTc5zLMhp9aDSA OC+DLJtALCkp/Vb5PqtlIlkBz5TYba+4yHLBUyQljI6tsYoYBk1rFwTqENWMfbawuWa5E5pgVoXR 6fHP+VeHdwaH59u1fR3qDghwcQnJlEylEkmqPixoZ+PuTTbyAuPCJM7AtkwIJOq4H4e98cDz9WS6 IAq/Q0tEbtY5Kn3MKNGj1kvRnJS26+Dqun81vrYWstQGDJdyLUh5oUrn0HpBvk9oNThdEIJUNf8G fa9Mf37+rsbfpmUUgmaFe/5R6F0rwFxcSx9YwoPfOZcjrx8FOop/54iZxq/jWCvczBN2ax7Vbq/0 LqILu4iYcKYkeCYyxXjkfV7TKYf0g6mvgNCNAcwgcIZmCdBpAcgf4GgIrzZj4sKmgCy9eZe6UIdV 8HTBQ6VfBqE5tkdRyQ9AZBjHJTcl5S6Txqz5uC+V13whMBKdD2jl8Pnv6GNJjQ5P6p+fvw5AaxRW KVdHqzE/hNavkM+6/MALuUrSzbHHUtptLaWDQVOmRtrcTkrjtlIK78UmSo25nZSet5XSuFsVg7oH 35jbSSlozEMXqMO8S8+DxhJlzO2ktN9aSvuN5elcm9tJKXRc7czSXtxYnoy5LZSCQnVaCq1UnVvY pHOnOwwrVd0OI+5fTbqTqND+9R3GfD0VOHuvu4//9Bmvx1Cz437Rp7hi2WSfykk68uIofNULutGe cjlDKaZJ0dRASLf1eHYSPt9H27kCWDca9zq2+bYASznhAoKYXiEwf3obcAo7+wVDAbz/LoIgvHhg 6hO+QuIdUgqJCr1Ly0l0Vo03dGQuK7vagvoWyKp1F9LVYyB94jRh1c43EHXrEAl8O99sMl1IW5I8 rJ5n0zTWQ7Jq2YEUTB4IqSlxT+I6PFs98wacHXK4Ho5Vqg6c4yXd+b0h7ZKj9ZCsUnQhHSvpenWI mpNuSw7ulXRWqTmQjpN0/To8jUm3S4rVn5BVSQ6c4yXd4P6QdkihekhWpbiQjpV0F3WImpNuS4r8 J+kAmiMEtEqAL3BQxuD/nSpwPN7oD3C2xhXlDTy3ptlCXjvNyAlY1UyzV/sN/fIvAAAA//8DAFBL AwQUAAYACAAAACEAgVuvZeAAAABVAQAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbCCiJAAo oCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckMFqwzAMhu+DvkPQ3bWbZIkpcQp1 KPQ6NtjVdZzEENvBdsrG2LvPYafuuJP4JKTvR83pw8zZXfmgnWVw2BPIlJWu13Zk8PZ6QRSyEIXt xeysYmAdnNrdU9OHYy+iCNF5dY3KZKmhU712DL74M6nJoc5RR/gZlbSgiFY8R7wueEHLS1WV3Tdk SW3TmcBginE5YhzkpIwIe7com4aD80bEhH7Ebhi0VJ2Tq1E24pyQCss16c27maHd8vxuv6ghPOIW bfX6v5abvs3ajV4s0yfgtsF/VBs/vKL9AQAA//8DAFBLAwQUAAYACAAAACEAJoIx81IBAAB6AgAA EQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA hJJRT4MwFIXfTfwPpO/QAnMuBFh0Zk8uzojR+Na0dxuRlqatY/v3FtiQRRMfb8/pd8+9bTo/iMrb gzZlLTMUBgR5IFnNS7nN0Gux9GfIM5ZKTqtaQoaOYNA8v75KmUpYrWGtawXalmA8R5ImYSpDO2tV grFhOxDUBM4hnbiptaDWlXqLFWWfdAs4ImSKBVjKqaW4BfpqIKITkrMBqb501QE4w1CBAGkNDoMQ /3gtaGH+vNApI6co7VG5mU5xx2zOenFwH0w5GJumCZq4i+Hyh/h99fjSjeqXst0VA5SnnCVMA7W1 zhdPq/Xdc4pHR+36Kmrsym16UwK/Pw6u30pr1rAv2zfKw5sUj2vXqJur7wbcc0mTfq6z8hYvHool yiMSxj6Z+hEpwlkymSSEfLSpLu63yfsDccr2L/HWQQsSJ9HtJfEMyLvEl78l/wYAAP//AwBQSwME FAAGAAgAAAAhAIpYLvaUAAAA5gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACigIAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyPQQrCMBBFrxJygKa4cFHaQkFdiQjZuHCTpJMm kGRKMgV7e4OIJ3D534cHr9edxC0bKExCAEMwS9oDDPw53afmIa+cfcBNxQorYxdvybHz7Mlj4uwV QyqdHrgjWjshinEQVWlwhVQ/izkqqjMvAq31Bk5otgiJxKFtj0J7HTwuWa1u/8r+ohp78Usb3wAA AP//AwBQSwMEFAAGAAgAAAAhADRLSftVAgAATwkAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUlU2P 2jAQhu+V+h8i37txTPjUwoqlcGsP3VQ9m+AQS7Ed2Q5Z/n3HSfjYErpkt61UIgiMncnk4X1n7h+e RebtmDZcySkK7jDymIzVhsvtFH2PVp9GyDOWyg3NlGRTtGcGPcw+frgvJ4mS1nhwvTQTPUWptfnE 902cMkHNncqZhLVEaUEt/NRbXyUJj9lnFReCSesTjAe+Zhm1cG+T8tygJlt5S7ZS6U2uVcyMgWJF VucTlEs0a6rzyomkAqp+2ou1yqp4TqUyLIClHc2mCPfhCDCB9xAP4NzHQ+S7BHFKtWH2uJHU4YQK nu0PUa0ElfVCzm2cHuI7qjldZ6xeMnwLC4VZY7hh80J1JADoLyPkYk/vZSSu8ozOroII5DlmhvL9 +u+5ABFxwYz3lZXet6pyt+FXIgQoDHAPSITwJvAtbCeC/wyRJRRO5qvVicgCIsNRGDSRE5FxE2kl Uj1/UOe5nchCFZoz7Zi06oOALnp4DBycNggw6UJDqA3TbQJJ+DPbXKrjKovev2DxA4zknG9aSfQP Ajud23XR6hRaWFVv/y+MsqAZX2veCoLgVSUFJ4kQxAGf7SBaDWJKbkwnEkvXIci5QUIIzBfHSCeD jCuj3W6QiKbQKq6AeIRO4RC4XhG+HYRUNtIFi/Y5q3pvN4kcvHHeA+vuegIDc63qwNc7B8ZVv+kA RrN1AdPOel+efoPH6eNw/F2dVL4ko2HzqO/E0VUnCyrAMNeE4kZJLRM3Wro5pvuQnTsUZHk2Upxj MA4fL9ro68IIXiXRTFsz+wkAAP//AwBQSwMEFAAGAAgAAAAhAHZJYZfoAQAASQ8AABQAAAB3b3Jk L3dlYlNldHRpbmdzLnhtbOxXS2/bMAy+D9h/MHRfLfkpB3EKZEV36R7Yut0VW4kF2KIhqfHSXz/G Trd0zYAlgLeLT5YokqI+0vrE+fX3pva20lgFOifsihJP6gJKpTc5+Xp/+4YTzzqhS1GDljnZSUuu F69fzbtZJ1dfpHOoaT30ou3M5KRyrp35vi0q2Qh7Ba3UuLYG0wiHU7PxYb1WhbyB4qGR2vkBpYlv ZC0cRmAr1Vpy8Nb9jbcOTNkaKKS1GEhTD/4aoTRZYIyl2trD1+tmqsQjZmka8ThmUa+wgnJ3o7a4 uBU1rhJ/r94IcyfX7klKf0o/q011QnwP7UvdJTgHzW9yDGhZmv0e7peNRmgJKtrHnGACcNCKAsHu xwXUgMCKBwdDGPVRZOdZrp5FdJ6tOT75OaZ+n4XDoff5eFupunyelIAGMc0oy4akTPC/SPqo8DMa pTRkcRz0/8QE/z+GP8t4QqM4YBP8p6+8Uas/DDmNojBNJ/THQ39ggcV8+D5xwCXSnk6QI/dkHiQZ ZxmLkyl146VueEWdYG2eBGlGKZ9Y4w8vtVGvrTjgPE15Sqfa/w+1z0IeBYzG2XT1jFj8l/DDBQyz b0agdapRj/IWzNJAZ6XpO0HsTHcf9bf3d/1M1DV0nz68wwluc9QAL34AAAD//wMAUEsDBBQABgAI AAAAIQDcXUQ83gEAANoDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CLrHtJzASA2KQeGgyKFtDFhJzltqZROlSIJkjLhf 36UUK3SbU3SafWB2OLviNy+9Lg7og7KmLqvZvCzQSNsqs6vLh+bbxXVZhAimBW0N1uURQ3kjPn/i G28d+qgwFERhQl3uY3QrxoLcYw9hRmVDlc76HiKFfsds1ymJt1Y+92giW8znS4YvEU2L7YWbCMuR cXWIHyVtrUz6wmNzdCRY8AZ7pyGi+JnkaM6mBG9sBN2oHsWS0lPAN7DDICrORsCfrG+DWFwtOBsh X+/Bg4xknqgur+ecZQn+1TmtJETyVfxQ0ttgu1jcDw4UiYCzvIWTK1uUz17FoyCqPOTflUlSSMuI SJuHnQe3D+IyCZwivpWgcU1vFx3ogJy9JfgdQtrrBhQp5oe4OqCM1hdB/aHNLsriFwRMjtXlAbwC E8m51DYGA9YuRC8aFTVxU22MB5i35VhdJRepl8B5Y0qOGqhwrm6YEO47elt8R2yVix00jFIzORmc ZvzDura9A3Ok4RMig3+HB9fY23Qtrx6eJ7O9P6m43zqQaTvL6kt+AVmJb+lQsKWVngjfEvyO/PY6 TaXrMTtsTz3/F9JNPY6/qqgWszl9wxGdcnQJ0z8k/gIAAP//AwBQSwECLQAUAAYACAAAACEA4Q+O v40BAAApBgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAAMYDAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQDX5gieIAEAAEQEAAAcAAAAAAAAAAAAAAAAAOoGAAB3b3JkL19yZWxzL2RvY3VtZW50Lnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhAGec9dduDQAACpgAABEAAAAAAAAAAAAAAAAATAkAAHdvcmQv ZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAA6RYA AHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQDaJenQ+gUAANEUAAARAAAAAAAA AAAAAAAAALIdAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQCMASTKMAkAANFFAAAP AAAAAAAAAAAAAAAAANsjAAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAo AQAAHgAAAAAAAAAAAAAAAAA4LQAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANbkE6T/AwAAihcAABIAAAAAAAAAAAAAAAAAPi8AAHdvcmQvbnVtYmVyaW5nLnht bFBLAQItABQABgAIAAAAIQCBW69l4AAAAFUBAAAYAAAAAAAAAAAAAAAAAG0zAABjdXN0b21YbWwv aXRlbVByb3BzMS54bWxQSwECLQAUAAYACAAAACEAJoIx81IBAAB6AgAAEQAAAAAAAAAAAAAAAACr NAAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAilgu9pQAAADmAAAAEwAAAAAAAAAA AAAAAAA0NwAAY3VzdG9tWG1sL2l0ZW0xLnhtbFBLAQItABQABgAIAAAAIQA0S0n7VQIAAE8JAAAS AAAAAAAAAAAAAAAAACE4AAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAdklhl+gB AABJDwAAFAAAAAAAAAAAAAAAAACmOgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAA ACEA3F1EPN4BAADaAwAAEAAAAAAAAAAAAAAAAADAPAAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAA DwAPANQDAADUPwAAAAA= --===============0749775196==-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 12 17:54:18 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1ECAEAF5 for ; Fri, 12 Jul 2013 17:54:18 +0000 (UTC) (envelope-from sz@dev.md) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id DB94512FE for ; Fri, 12 Jul 2013 17:54:17 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so5234087qej.37 for ; Fri, 12 Jul 2013 10:54:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=E2it5iayinvId/oCfIM6v1L60mKpNoJGmfKfRIJc9ec=; b=fbT4gg6nAhiDXBMetYpbz/IjEFVRUFxrJ38LgZQPeWjRy5t7MXyqtx6BkGmXC05isf 80F1y3egNQL3a2aTZ/ExJ6Ijz/XIoqYjqBNA6HvsPbhmqbzFYtOvIitqnK3NaD4XSwJS Y+X6XAi2+jL8K/uWxhjf2wo2p9qAUaZrNCZq9RrTUse8N2oZWzEE/6eJsQFKdsf6CHQl s/7IZnoEHhXV/PSuDUdPbdWdOcWaPI/zi+7zED1GqT6Yf7x9joSLFiAazfwIFVKjkccU tWfcyoy+J/iLs8rIyd19pjwn8/YLPaIvo7aK4tdYBb6o4X7xpnzm0OOME/uj6/vCW31K xOzw== MIME-Version: 1.0 X-Received: by 10.49.95.97 with SMTP id dj1mr35798934qeb.46.1373651656691; Fri, 12 Jul 2013 10:54:16 -0700 (PDT) Sender: sz@dev.md Received: by 10.224.174.2 with HTTP; Fri, 12 Jul 2013 10:54:16 -0700 (PDT) X-Originating-IP: [178.168.23.87] Date: Fri, 12 Jul 2013 20:54:16 +0300 X-Google-Sender-Auth: Dh8J9nkcsA1ZzCtFEF97G7d4iwc Message-ID: Subject: From: Sebastian Zavadschi To: stable@FreeBSD.org X-Gm-Message-State: ALoCoQmSaXfmvpGFP8YL9ny0C51M7nEMO1GpPBetbh71WX2HS1D7kMxIx5MC2aiaN2OJqYncRnPf Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:54:18 -0000 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 07:44:17 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3FB0ACE4 for ; Sat, 13 Jul 2013 07:44:17 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id BECEF162D for ; Sat, 13 Jul 2013 07:44:16 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id fr10so8333732lab.18 for ; Sat, 13 Jul 2013 00:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=5yTVUDFxgv0MvVwxGw2Pqr627gTGmlptNM7WTFbmbqQ=; b=CaQY8u1Km4qZpVfFKBs0ziX4XNRnOQ8XVLGhtwdPfOfLxRNaQl9ikjzjAvvm9aMKfQ le2bjEd+igA6YnPB77S4Kax3SZd6uZREj1lMGYHAuaGrmk+kIfEkub6xMARHJ0a6yoZX D/n+5H9l+Iydvylw7OL3HbFmCcXGGlhSxJ8qd6KjjEl2ZI5Fipmmu6TKuUzhZsxVRd4n qLmRx+0rOjAkHOx3Y0vMQboNO0PPIuf8DoZ54JdOmj6N1n1TZK9iYL3tatw7zCMebDPd vPX/KGpplBtTo+up5T5QWAscNxHnjBEV9mxLxeZli1T5DN8gJUQ552DvqS2K7dQBrJt2 GaNw== X-Received: by 10.152.29.41 with SMTP id g9mr20931195lah.44.1373701455590; Sat, 13 Jul 2013 00:44:15 -0700 (PDT) Received: from alex.super ([195.238.246.110]) by mx.google.com with ESMTPSA id n3sm15593566lag.9.2013.07.13.00.44.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jul 2013 00:44:14 -0700 (PDT) From: "Alex V. Petrov" To: stable@freebsd.org Subject: ls -U don't work? Date: Sat, 13 Jul 2013 15:44:08 +0800 Message-ID: <8704004.oreYQuEkVL@alex.super> User-Agent: KMail/4.10.5 (FreeBSD/9.2-PRERELEASE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 07:44:17 -0000 subj: ls -Ul total 0 -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:26 000 -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 111 -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 222 -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 333 locale: LANG=3Dru_RU.UTF-8 LC_CTYPE=3D"ru_RU.UTF-8" LC_COLLATE=3D"ru_RU.UTF-8" LC_TIME=3D"ru_RU.UTF-8" LC_NUMERIC=3D"ru_RU.UTF-8" LC_MONETARY=3D"ru_RU.UTF-8" LC_MESSAGES=3D"ru_RU.UTF-8" LC_ALL=3D FreeBSD: 9.2-PRERELEASE #98 r253272: Sat Jul 13 02:34:54 KRAT 2013 amd64 --=20 ----- Alex V. Petrov From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 08:10:02 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8AA81AF; Sat, 13 Jul 2013 08:10:02 +0000 (UTC) (envelope-from alfred@ixsystems.com) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF4E16C4; Sat, 13 Jul 2013 08:10:02 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 81E8966CAA; Sat, 13 Jul 2013 01:09:52 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 69228-07-2; Sat, 13 Jul 2013 01:09:52 -0700 (PDT) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 740C466958; Sat, 13 Jul 2013 00:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1373701664; bh=2Fp8q1b602q4nnoLCcaEBtWsv6zwAjDtRND3Ka76i+k=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CK2KQxQvPC3fSJ3BKcFsDYxkDqz6YO7udbt43u8InIY/TMTGXiRtE2G6Y5Dm+QsMO diIHXj13hxrjZaVPXPHb2ut32QJvDjLtD/kKwyrRi4tx5to1Ob6oBJMC1eYm0hYKLb pMiqEFsMdoMFM/iNZBiB2IlmX0+fboGucldlCfTY= Message-ID: <51E1061F.3050804@ixsystems.com> Date: Sat, 13 Jul 2013 00:47:43 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> In-Reply-To: <51D92826.1070707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 08:10:02 -0000 Andre, we have a number of people running this patch in the following configurations: 6-8GB ram + 10gigE ethernet using iozone over NFS. We're rolling it into the PCBSD rolling update as well. I'm thinking it makes sense to roll this into the 9.2 release to give us more scalability. -Alfred On 7/7/13 1:34 AM, Andre Oppermann wrote: > On 07.07.2013 08:32, Alfred Perlstein wrote: >> Andre, >> >> Are you going to have time to MFC things from -current for >> auto-tuning -stable before 9.2? > > I simply ran out of time on Friday and MFCing such a big change requires > more testing. > >> I fear (maybe unnecessarily?) that we are about to ship yet another >> release that can't do basic >> 10gigE when sufficient memory exists. > > There was some debate with myself whether such a behavior changing MFC > would be appropriate for a mid-stream stable release. I guess yes, > though > a number of people who currently set the parameters manually would have > to remove their tuning settings. > >> If you don't have time, then let me know and I'll see what I can do. > > Can you help me with with testing? > -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 09:45:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 31E27D2B for ; Sat, 13 Jul 2013 09:45:32 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C45B218DD for ; Sat, 13 Jul 2013 09:45:31 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hj3so1429613wib.16 for ; Sat, 13 Jul 2013 02:45:30 -0700 (PDT) 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:content-transfer-encoding; bh=XEQwYK+9nG5CRR1azQp9vGiCOanBzVkl3XN+WXOcBGA=; b=sOmgwkNXoVGZtPUvvTBaeB6IrdPL9TXqAzXZqt6GChmSLuz6nOogvaz7gY6EM0pRjk GbScJSA2HZIudbAg3CJoaJ/ZsTM49AdaxqNHuh80HSHHOgOfthxCKAPTS2s6OEbVIe/i XcKbMobLf/4du9SDrxJHmASj60P21lMF+ZTAQzoEjkS9nk22YBwtjQBevWFiItdKHgwv FyOCIQ6GDb3eES2cGB1RaQR6KHjq5NT+Xg+nuTW4jTBDj4vwCIg7ersfHjP0cRmaAdw2 b14A4KUdJVXmUugb9vDdFno5QZM+l576iYH0WNjKp9/PlwQOXa1Zeb0hlTWF3LK3YrqV k6tg== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr3798392wic.50.1373708730774; Sat, 13 Jul 2013 02:45:30 -0700 (PDT) Received: by 10.216.82.70 with HTTP; Sat, 13 Jul 2013 02:45:30 -0700 (PDT) In-Reply-To: <8704004.oreYQuEkVL@alex.super> References: <8704004.oreYQuEkVL@alex.super> Date: Sat, 13 Jul 2013 13:45:30 +0400 Message-ID: Subject: Re: ls -U don't work? From: Sergey Kandaurov To: "Alex V. Petrov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 09:45:32 -0000 2013/7/13 Alex V. Petrov : > subj: > ls -Ul So, what's the problem? Looking at code, I'd suggest to try adding -t to actually enable sorting, otherwise it just prints dates but not sorts. > total 0 > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:26 000 > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 111 > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 222 > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 333 > -t enables sorting (by modified date by default), -U further specifies to sort by birth time. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 10:30:41 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D18DF4FF for ; Sat, 13 Jul 2013 10:30:41 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 585C019F5 for ; Sat, 13 Jul 2013 10:30:41 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id x10so8217654lbi.5 for ; Sat, 13 Jul 2013 03:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=FjIL00vrkYTN1lLl2MrVuRxGLfo3LMEs+eKMkhkfIZw=; b=C4ikErCdrwQy7ov0MB7Z3E6InWqc+V2lWCrTqKiovBZMHjJShAazu/6nWNsxs4+7UM EnPtcX+3OdczPQQXahTCihQ+a7+GG18kavw9x7bA0RRN+gWZj1vZFzF1kol80mU+WpVY G6DY5XTocQWrZmOg0JkECPYMbwm9glhBBB7A/KQTMciOnKHJj3aSoyr32DZDa94pbEi1 8kHy4G1nK17eYqfwrSc5jZc+dhtgsNRetzEzqyD6ayhfbbm7VnLJUFVS28EU/Rh4rzt9 nsE//PntxN7m9jQ5YCx55bGEcQuq+5/bg2lagobLUymn3++LYyNxmOLa7C0khUqX4OA5 +AxQ== X-Received: by 10.152.27.137 with SMTP id t9mr21382879lag.28.1373711440169; Sat, 13 Jul 2013 03:30:40 -0700 (PDT) Received: from alex.super ([195.238.246.110]) by mx.google.com with ESMTPSA id v18sm15236559lbd.5.2013.07.13.03.30.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jul 2013 03:30:39 -0700 (PDT) From: "Alex V. Petrov" To: Sergey Kandaurov , stable@freebsd.org Subject: Re: ls -U don't work? Date: Sat, 13 Jul 2013 18:30:35 +0800 Message-ID: <2813184.tAUhP2F1j4@alex.super> User-Agent: KMail/4.10.5 (FreeBSD/9.2-PRERELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <8704004.oreYQuEkVL@alex.super> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 10:30:41 -0000 =D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 13 =D0=B8=D1=8E= =D0=BB=D1=8F 2013 13:45:30 =D0=92=D1=8B =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB=D0=B8: > 2013/7/13 Alex V. Petrov : > > subj: > > ls -Ul >=20 > So, what's the problem? Looking at code, > I'd suggest to try adding -t to actually enable sorting, > otherwise it just prints dates but not sorts. >=20 > > total 0 > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:26 000 > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 111 > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 222 > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 333 >=20 > -t enables sorting (by modified date by default), > -U further specifies to sort by birth time. What is the meaning of '-U'?I thought '-U' =3D '-tr' man ls: "-U Use time when file was created for sorting or printing." ----- Alex V. Petrov From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 16:20:39 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 51BB944E for ; Sat, 13 Jul 2013 16:20:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 1F45B182D for ; Sat, 13 Jul 2013 16:20:39 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id xk17so12498065obc.10 for ; Sat, 13 Jul 2013 09:20:38 -0700 (PDT) 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=iNtEb/bwjSaLIlP7P4aApXI+ERyF56oSGc//pXHcLvM=; b=pGumE316QSt1o9AJSKQU9qmUYbOeMRx0xxNit4ouNhi/fW/0LlyWtGrtmUsCv/gpL7 hnoVBmbAKk8U40Rk4EnRWJffjq/I1lO+Zi302Ey94pmFvCWhlBD+IwWCTCkS0L+338QI 4cMPdQHaJ4863oRJYgg5+YKWCyNhpEhDHiNCHY1ugOjI6Y5bO06suNZmLNto7Mv5n8Fg 1S7JVTcILVSXdK98zmKxPrFcKAigAOloOsWiwAGRZQCOpNxnGQ5mWMUPdHIXkA9KkCe5 bLxBwe32RSxdGAZ+INjatMwyy/C4zndrrRnI0EUqtQhKYdJGtksS3R2auFq7yqgKfOHD FF7w== MIME-Version: 1.0 X-Received: by 10.60.102.202 with SMTP id fq10mr17432760oeb.42.1373732438190; Sat, 13 Jul 2013 09:20:38 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Sat, 13 Jul 2013 09:20:38 -0700 (PDT) In-Reply-To: <2813184.tAUhP2F1j4@alex.super> References: <8704004.oreYQuEkVL@alex.super> <2813184.tAUhP2F1j4@alex.super> Date: Sat, 13 Jul 2013 09:20:38 -0700 X-Google-Sender-Auth: TaNJ4SxGu8NHClq0As3gws-4Tfk Message-ID: Subject: Re: ls -U don't work? From: Kevin Oberman To: "Alex V. Petrov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org Stable" , Sergey Kandaurov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 16:20:39 -0000 On Sat, Jul 13, 2013 at 3:30 AM, Alex V. Petrov wrot= e: > =D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 13 =D0=B8=D1=8E= =D0=BB=D1=8F 2013 13:45:30 =D0=92=D1=8B =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB=D0=B8: > > 2013/7/13 Alex V. Petrov : > > > subj: > > > ls -Ul > > > > So, what's the problem? Looking at code, > > I'd suggest to try adding -t to actually enable sorting, > > otherwise it just prints dates but not sorts. > > > > > total 0 > > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:26 000 > > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 111 > > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 222 > > > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 333 > > > > -t enables sorting (by modified date by default), > > -U further specifies to sort by birth time. > > What is the meaning of '-U'?I thought '-U' =3D '-tr' > > man ls: > "-U Use time when file was created for sorting or printing." > > ----- > Alex V. Petrov > No, '-U' tells ls(1) to use ctime for all timestamps. By default it uses mtime. So 'ls -U' will print ctime, but to sort by ctime you need 'ls -Ut' or 'ls -Utr'. --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Jul 13 16:56:13 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35931D52 for ; Sat, 13 Jul 2013 16:56:13 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id BB2BC193D for ; Sat, 13 Jul 2013 16:56:12 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id ji1so4125690bkc.38 for ; Sat, 13 Jul 2013 09:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=9d12fGjrJ6jiDIOpLCzfiSCIV9tZmqPGNfQgVf4ZIDI=; b=OIcJISpxJxGCs+AGY3DRkJahWSuJ+uvIU0LU0+/CXIzjK4m9rSFp0ibYdihg3t5+3/ HWmw1sRcglNKnTxkOeQFoKHGF0fKEZczLsV4a7AGlYWpiEQRW1jI5ozUuEZ0/F2mZrf9 SO68XEfMi4W5wLFIodH3kxZfkORA8r/hS0jwir+ka73ni9qVZy8QwZ9cj5ros8LiNahb sqB6umXmt32N1y49QFAQqMih47UkWumaub6if8OXz55eJpA5fIB0Wc9OLpE/AlaT65go rivEK37svIzISZx3T4gGycLnIExFvmTwyT1j0RV0gAzb+SOOWFJFXlgTRW/Q5Jv7+OBQ a60g== X-Received: by 10.205.12.67 with SMTP id ph3mr6834333bkb.87.1373734571752; Sat, 13 Jul 2013 09:56:11 -0700 (PDT) Received: from alex.super ([195.238.246.110]) by mx.google.com with ESMTPSA id hn4sm10233141bkc.2.2013.07.13.09.56.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jul 2013 09:56:10 -0700 (PDT) From: "Alex V. Petrov" To: Kevin Oberman Subject: Re: ls -U don't work? Date: Sun, 14 Jul 2013 00:56:05 +0800 Message-ID: <6087961.Jy4hGFOKS8@alex.super> User-Agent: KMail/4.10.5 (FreeBSD/9.2-PRERELEASE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <8704004.oreYQuEkVL@alex.super> <2813184.tAUhP2F1j4@alex.super> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org Stable" , Sergey Kandaurov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 16:56:13 -0000 =D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 13 =D0=B8=D1=8E= =D0=BB=D1=8F 2013 09:20:38 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0= =B0=D1=82=D0=B5=D0=BB=D1=8C Kevin Oberman =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: On Sat, Jul 13, 2013 at 3:30 AM, Alex V. Petrov wrote: =D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 13 =D0=B8=D1=8E= =D0=BB=D1=8F 2013 13:45:30 =D0=92=D1=8B =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB=D0=B8: > 2013/7/13 Alex V. Petrov <_alexvpetrov@gmail.com_>:> > subj:> > ls -U= l>> So, what's=20 the problem? Looking at code,> I'd suggest to try adding -t to actually= enable sorting,>=20 otherwise it just prints dates but not sorts.>> > total 0> > -rw-r--r--= 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB=20 15:26 000> > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 11= 1> > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB=20 15:25 222> > -rw-r--r-- 1 alex alex 0 13 =D0=B8=D1=8E=D0=BB 15:25 33= 3>> -t enables sorting (by modified=20 date by default),> -U further specifies to sort by birth time. What is the meaning of '-U'?I thought '-U' =3D '-tr' man ls:"-U Use time when file was created for sorting or printing.= " -----Alex V. Petrov No, '-U' tells ls(1) to use ctime for all timestamps. By default it use= s mtime. So 'ls -U' will=20 print ctime, but to sort by ctime you need 'ls -Ut' or 'ls -Utr'.=20 -- R. Kevin Oberman, Network EngineerE-mail: rkoberman@gmail.com[2] Yes. I knew already.Thank you. --=20 ----- Alex V. Petrov -------- [1] mailto:alexvpetrov@gmail.com [2] mailto:rkoberman@gmail.com