From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 06:47: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 023A515D; Sun, 16 Jun 2013 06:47:42 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 020321C54; Sun, 16 Jun 2013 06:47:40 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r5G6dhu6002346; Sun, 16 Jun 2013 08:39:43 +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 r5G6dhl0005705; Sun, 16 Jun 2013 08:39:43 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r5G6dg8K093496; Date: Sun, 16 Jun 2013 08:39:42 +0200 From: Andre Albsmeier To: John Baldwin Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616063942.GA72803@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201305311051.03157.jhb@freebsd.org> 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" 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, 16 Jun 2013 06:47:42 -0000 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. Some comments on what the crontab script does at 5:01 (I switched it from 5:15 to 5:01 for some reason): 1. Unmount all snapshots 2. Remove all /dev/md devices 3. Deleting the oldest snapshot 4. Generating a new snapshost 5. mdconfig and mount mount of all snapshots I assume the first LOR (sys_unmount) is related to the unmount and the second one (sys_unlink) to the rm. I have added some sleep(1) and sync(1) commands between the different steps but this didn't help. Now the log of three days, we can see another LOR after booting: --- cronjob start, day 1 --- Jun 11 05:01:00 typhon kernel: lock order reversal: Jun 11 05:01:00 typhon kernel: 1st 0xc53644c8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 Jun 11 05:01:00 typhon kernel: 2nd 0xc5361290 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 Jun 11 05:01:00 typhon kernel: KDB: stack backtrace: Jun 11 05:01:00 typhon kernel: db_trace_self_wrapper(c0815bdd,662f7366,765f7366,706f7366,3a632e73,...) at db_trace_self_wrapper+0x26/frame 0xec3c98d4 Jun 11 05:01:00 typhon kernel: kdb_backtrace(c063659b,c08198b4,c09e8bb0,586,ec3c99a0,...) at kdb_backtrace+0x2a/frame 0xec3c9930 Jun 11 05:01:00 typhon kernel: _witness_debugger(c08198b4,c5361290,c080d6e7,c4c29338,c0835390,...) at _witness_debugger+0x25/frame 0xec3c9948 Jun 11 05:01:00 typhon kernel: witness_checkorder(c5361290,9,c0835390,586,c53612b0,...) at witness_checkorder+0x86f/frame 0xec3c99a0 Jun 11 05:01:00 typhon kernel: __lockmgr_args(c5361290,80400,c53612b0,0,0,...) at __lockmgr_args+0x829/frame 0xec3c9a58 Jun 11 05:01:00 typhon kernel: vop_stdlock(ec3c9abc,246,c08bcd9c,80400,c5361238,...) at vop_stdlock+0x62/frame 0xec3c9a8c Jun 11 05:01:00 typhon kernel: VOP_LOCK1_APV(c08611e0,ec3c9abc,c09e8bb4,c0890120,c5361238,...) at VOP_LOCK1_APV+0xb5/frame 0xec3c9aa8 Jun 11 05:01:00 typhon kernel: _vn_lock(c5361238,80400,c0835390,586,ec3c9b14,...) at _vn_lock+0x5e/frame 0xec3c9adc Jun 11 05:01:00 typhon kernel: ffs_flushfiles(c5365d34,0,c67ec600,0,c5365d34,...) at ffs_flushfiles+0x133/frame 0xec3c9b1c Jun 11 05:01:00 typhon kernel: ffs_unmount(c5365d34,8000000,c0821043,513,c4c00c08,...) at ffs_unmount+0x180/frame 0xec3c9b5c Jun 11 05:01:00 typhon kernel: dounmount(c5365d34,8000000,c67ec600,494,c67e8378,...) at dounmount+0x423/frame 0xec3c9bac Jun 11 05:01:00 typhon kernel: sys_unmount(c67ec600,ec3c9ccc,c0846650,c081a478,206,...) at sys_unmount+0x3d1/frame 0xec3c9c48 Jun 11 05:01:00 typhon kernel: syscall(ec3c9d08) at syscall+0x24d/frame 0xec3c9cfc Jun 11 05:01:00 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xec3c9cfc Jun 11 05:01:00 typhon kernel: --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x180bf3e7, esp = 0xbfbfd61c, ebp = 0xbfbfd6e8 --- Jun 11 05:01:10 typhon kernel: lock order reversal: Jun 11 05:01:10 typhon kernel: 1st 0xc503545c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 Jun 11 05:01:10 typhon kernel: 2nd 0xc509eda8 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 Jun 11 05:01:10 typhon kernel: KDB: stack backtrace: Jun 11 05:01:10 typhon kernel: db_trace_self_wrapper(c0815bdd,735f7366,7370616e,2e746f68,36313a63,...) at db_trace_self_wrapper+0x26/frame 0xec3bd614 Jun 11 05:01:10 typhon kernel: kdb_backtrace(c063659b,c08198b4,c09e96f8,65a,ec3bd6e0,...) at kdb_backtrace+0x2a/frame 0xec3bd670 Jun 11 05:01:10 typhon kernel: _witness_debugger(c08198b4,c509eda8,c0808f48,c4c29470,c0831f9d,...) at _witness_debugger+0x25/frame 0xec3bd688 Jun 11 05:01:10 typhon kernel: witness_checkorder(c509eda8,9,c0831f9d,65a,0,...) at witness_checkorder+0x86f/frame 0xec3bd6e0 Jun 11 05:01:10 typhon kernel: __lockmgr_args(c509eda8,80000,0,0,0,...) at __lockmgr_args+0x829/frame 0xec3bd798 Jun 11 05:01:10 typhon kernel: ffs_snapremove(c509ed50,c4c23f88,c4c26140,4,c09e96f8,...) at ffs_snapremove+0x11f/frame 0xec3bd818 Jun 11 05:01:10 typhon kernel: ffs_truncate(c509ed50,0,0,c00,0,...) at ffs_truncate+0x637/frame 0xec3bda44 Jun 11 05:01:10 typhon kernel: ufs_inactive(ec3bdab8,c509ed50,c509ed50,c535d1bc,ec3bdad0,...) at ufs_inactive+0x1f8/frame 0xec3bda80 Jun 11 05:01:10 typhon kernel: VOP_INACTIVE_APV(c0882560,ec3bdab8,c08219ca,a00,c068657a,...) at VOP_INACTIVE_APV+0xa5/frame 0xec3bda98 Jun 11 05:01:10 typhon kernel: vinactive(c509ed50,c67ee300,c08219ca,8fe,0,...) at vinactive+0x112/frame 0xec3bdad0 Jun 11 05:01:10 typhon kernel: vputx(ec3bdc18,c069fcf4,c509ed50,ffffffdf,2,...) at vputx+0x2fc/frame 0xec3bdb0c Jun 11 05:01:10 typhon kernel: vput(c509ed50,ffffffdf,2,0,5,...) at vput+0x10/frame 0xec3bdb14 Jun 11 05:01:10 typhon kernel: kern_unlinkat(c67ee300,ffffff9c,bfbfdf32,0,0,...) at kern_unlinkat+0x274/frame 0xec3bdc18 Jun 11 05:01:10 typhon kernel: kern_unlink(c67ee300,bfbfdf32,0,ec3bdcfc,c07b310d,...) at kern_unlink+0x2f/frame 0xec3bdc34 Jun 11 05:01:10 typhon kernel: sys_unlink(c67ee300,ec3bdccc,c0846650,c081a4d8,246,...) at sys_unlink+0x22/frame 0xec3bdc48 Jun 11 05:01:10 typhon kernel: syscall(ec3bdd08) at syscall+0x24d/frame 0xec3bdcfc Jun 11 05:01:10 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xec3bdcfc Jun 11 05:01:10 typhon kernel: --- syscall (10, FreeBSD ELF32, sys_unlink), eip = 0x1814ee83, esp = 0xbfbfdd3c, ebp = 0xbfbfddb8 --- --- reboot on day 1 --- Jun 11 05:35:46 typhon kernel: Copyright (c) 1992-2013 The FreeBSD Project. Jun 11 05:35:46 typhon kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 11 05:35:46 typhon kernel: The Regents of the University of California. All rights reserved. Jun 11 05:35:46 typhon kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jun 11 05:35:46 typhon kernel: FreeBSD 9.1-STABLE #3: Sat Jun 8 11:02:16 CEST 2013 Jun 11 05:35:46 typhon kernel: root@server.ofw.tld:/usr/obj/src/src-9/sys/typhon i386 Jun 11 05:35:46 typhon kernel: gcc version 4.2.1 20070831 patched [FreeBSD] Jun 11 05:35:46 typhon kernel: WARNING: WITNESS option enabled, expect reduced performance. Jun 11 05:35:46 typhon kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Jun 11 05:35:46 typhon kernel: CPU: Pentium(R) Dual-Core CPU E6600 @ 3.06GHz (3071.98-MHz 686-class CPU) Jun 11 05:35:46 typhon kernel: Origin = "GenuineIntel" Id = 0x1067a Family = 0x6 Model = 0x17 Stepping = 10 Jun 11 05:35:46 typhon kernel: Features=0xbfebfbff Jun 11 05:35:46 typhon kernel: Features2=0x400e3bd Jun 11 05:35:46 typhon kernel: AMD Features=0x20100000 Jun 11 05:35:46 typhon kernel: AMD Features2=0x1 Jun 11 05:35:46 typhon kernel: TSC: P-state invariant, performance statistics Jun 11 05:35:46 typhon kernel: real memory = 2147483648 (2048 MB) Jun 11 05:35:46 typhon kernel: avail memory = 2096226304 (1999 MB) Jun 11 05:35:46 typhon kernel: Event timer "LAPIC" quality 400 Jun 11 05:35:46 typhon kernel: ACPI APIC Table: Jun 11 05:35:46 typhon kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jun 11 05:35:46 typhon kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Jun 11 05:35:46 typhon kernel: cpu0 (BSP): APIC ID: 0 Jun 11 05:35:46 typhon kernel: cpu1 (AP): APIC ID: 1 Jun 11 05:35:46 typhon kernel: ioapic0 irqs 0-23 on motherboard Jun 11 05:35:46 typhon kernel: acpi0: on motherboard Jun 11 05:35:46 typhon kernel: acpi0: Power Button (fixed) Jun 11 05:35:46 typhon kernel: acpi0: reservation of 0, a0000 (3) failed Jun 11 05:35:46 typhon kernel: acpi0: reservation of 100000, 7ff00000 (3) failed Jun 11 05:35:46 typhon kernel: cpu0: on acpi0 Jun 11 05:35:46 typhon kernel: cpu1: on acpi0 Jun 11 05:35:46 typhon kernel: attimer0: port 0x40-0x43 irq 0 on acpi0 Jun 11 05:35:46 typhon kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jun 11 05:35:46 typhon kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Jun 11 05:35:46 typhon kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Jun 11 05:35:46 typhon kernel: Event timer "RTC" frequency 32768 Hz quality 0 Jun 11 05:35:46 typhon kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jun 11 05:35:46 typhon kernel: Timecounter "HPET" frequency 14318180 Hz quality 950 Jun 11 05:35:46 typhon kernel: Event timer "HPET" frequency 14318180 Hz quality 450 Jun 11 05:35:46 typhon kernel: Event timer "HPET1" frequency 14318180 Hz quality 440 Jun 11 05:35:46 typhon kernel: Event timer "HPET2" frequency 14318180 Hz quality 440 Jun 11 05:35:46 typhon kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Jun 11 05:35:46 typhon kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jun 11 05:35:46 typhon kernel: pcib0: port 0xcf8-0xcff on acpi0 Jun 11 05:35:46 typhon kernel: pci0: on pcib0 Jun 11 05:35:46 typhon kernel: eccmon0: RAM ECC Monitor v0.13 on i975X (8086:277C), reporting tested Jun 11 05:35:46 typhon kernel: eccmon0: Capabilities: ECC detection and correction Jun 11 05:35:46 typhon kernel: eccmon0: Current mode: ECC detection and correction Jun 11 05:35:46 typhon kernel: eccmon0: Bank Size Type ILV ECC Jun 11 05:35:46 typhon kernel: eccmon0: 0 1024M DDR2 Y Y Jun 11 05:35:46 typhon kernel: eccmon0: 1 1024M DDR2 Y Y Jun 11 05:35:46 typhon kernel: eccmon0: Total RAM detected: 2048M Jun 11 05:35:46 typhon kernel: eccmon0: on hostb0 Jun 11 05:35:46 typhon kernel: eccmon0: attached Jun 11 05:35:46 typhon kernel: pcib1: irq 16 at device 1.0 on pci0 Jun 11 05:35:46 typhon kernel: pci4: on pcib1 Jun 11 05:35:46 typhon kernel: 3ware device driver for 9000 series storage controllers, version: 3.80.06.003 Jun 11 05:35:46 typhon kernel: twa0: <3ware 9000 series Storage Controller> port 0xd800-0xd8ff mem 0xfc000000-0xfdffffff,0xff9ff000-0xff9fffff irq 16 at device 0.0 on pci4 Jun 11 05:35:46 typhon kernel: twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 Jun 11 05:35:46 typhon kernel: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9690SA-8I, 128 ports, Firmware FH9X 4.10.00.027, BIOS BE9X 4.08.00.004 Jun 11 05:35:46 typhon kernel: pcib2: irq 16 at device 28.0 on pci0 Jun 11 05:35:46 typhon kernel: pci3: on pcib2 Jun 11 05:35:46 typhon kernel: pcib3: irq 19 at device 28.3 on pci0 Jun 11 05:35:46 typhon kernel: pci2: on pcib3 Jun 11 05:35:46 typhon kernel: mskc0: port 0xc800-0xc8ff mem 0xff8fc000-0xff8fffff irq 19 at device 0.0 on pci2 Jun 11 05:35:46 typhon kernel: msk0: on mskc0 Jun 11 05:35:46 typhon kernel: msk0: Ethernet address: 00:18:f3:87:86:60 Jun 11 05:35:46 typhon kernel: miibus0: on msk0 Jun 11 05:35:46 typhon kernel: e1000phy0: PHY 0 on miibus0 Jun 11 05:35:46 typhon kernel: e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jun 11 05:35:46 typhon kernel: pcib4: at device 30.0 on pci0 Jun 11 05:35:46 typhon kernel: pci1: on pcib4 Jun 11 05:35:46 typhon kernel: vgapci0: mem 0xff7fc000-0xff7fffff,0xfa000000-0xfa7fffff irq 21 at device 0.0 on pci1 Jun 11 05:35:46 typhon kernel: ahc0: port 0xb800-0xb8ff mem 0xff7fb000-0xff7fbfff irq 22 at device 1.0 on pci1 Jun 11 05:35:46 typhon kernel: ahc0: Bugs (0x0040): SCBCHAN_UPLOAD Jun 11 05:35:46 typhon kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Jun 11 05:35:46 typhon kernel: isab0: at device 31.0 on pci0 Jun 11 05:35:46 typhon kernel: isa0: on isab0 Jun 11 05:35:46 typhon kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 Jun 11 05:35:46 typhon kernel: ata0: at channel 0 on atapci0 Jun 11 05:35:46 typhon kernel: atapci1: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xffaffc00-0xffafffff irq 23 at device 31.2 on pci0 Jun 11 05:35:46 typhon kernel: ata2: at channel 0 on atapci1 Jun 11 05:35:46 typhon kernel: ata3: at channel 1 on atapci1 Jun 11 05:35:46 typhon kernel: ichsmb0: port 0x400-0x41f at device 31.3 on pci0 Jun 11 05:35:46 typhon kernel: smbus0: on ichsmb0 Jun 11 05:35:46 typhon kernel: smb0: on smbus0 Jun 11 05:35:46 typhon kernel: acpi_button0: on acpi0 Jun 11 05:35:46 typhon kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jun 11 05:35:46 typhon kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Jun 11 05:35:46 typhon kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jun 11 05:35:46 typhon kernel: atkbd0: irq 1 on atkbdc0 Jun 11 05:35:46 typhon kernel: atkbd0: [GIANT-LOCKED] Jun 11 05:35:46 typhon kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jun 11 05:35:46 typhon kernel: ichwd0 on isa0 Jun 11 05:35:46 typhon kernel: orm0: at iomem 0xc0000-0xc7fff,0xcd800-0xcdfff pnpid ORM0000 on isa0 Jun 11 05:35:46 typhon kernel: sc0: at flags 0x100 on isa0 Jun 11 05:35:46 typhon kernel: sc0: VGA <9 virtual consoles, flags=0x300> Jun 11 05:35:46 typhon kernel: vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 Jun 11 05:35:46 typhon kernel: coretemp0: on cpu0 Jun 11 05:35:46 typhon kernel: est0: on cpu0 Jun 11 05:35:46 typhon kernel: est0: Guessed bus clock (high) of 267 MHz Jun 11 05:35:46 typhon kernel: est0: Guessed high setting of 3071 MHz @ 1292 mV Jun 11 05:35:46 typhon kernel: est0: Guessed low setting of 1602 MHz @ 1052 mV Jun 11 05:35:46 typhon kernel: p4tcc0: on cpu0 Jun 11 05:35:46 typhon kernel: coretemp1: on cpu1 Jun 11 05:35:46 typhon kernel: est1: on cpu1 Jun 11 05:35:46 typhon kernel: est1: Guessed bus clock (high) of 267 MHz Jun 11 05:35:46 typhon kernel: est1: Guessed high setting of 3071 MHz @ 1292 mV Jun 11 05:35:46 typhon kernel: est1: Guessed low setting of 1602 MHz @ 1052 mV Jun 11 05:35:46 typhon kernel: p4tcc1: on cpu1 Jun 11 05:35:46 typhon kernel: Timecounters tick every 10.000 msec Jun 11 05:35:46 typhon kernel: Expensive timeout(9) function: 0xc04d8900(0xc4d8e800) 0.123587844 s Jun 11 05:35:46 typhon kernel: da10 at twa0 bus 0 scbus1 target 0 lun 0 Jun 11 05:35:46 typhon kernel: da10: Fixed Direct Access SCSI-5 device Jun 11 05:35:46 typhon kernel: da10: 100.000MB/s transfers Jun 11 05:35:46 typhon kernel: da10: 2860962MB (5859250176 512 byte sectors: 255H 63S/T 364721C) Jun 11 05:35:46 typhon kernel: SMP: AP CPU #1 Launched! Jun 11 05:35:46 typhon kernel: Timecounter "TSC-low" frequency 1535990772 Hz quality 1000 Jun 11 05:35:46 typhon kernel: WARNING: WITNESS option enabled, expect reduced performance. Jun 11 05:35:46 typhon kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Jun 11 05:35:46 typhon kernel: da1 at ahc0 bus 0 scbus0 target 1 lun 0 Jun 11 05:35:46 typhon kernel: da1: Fixed Direct Access SCSI-2 device Jun 11 05:35:46 typhon kernel: da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Jun 11 05:35:46 typhon kernel: da1: Command Queueing enabled Jun 11 05:35:46 typhon kernel: da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) Jun 11 05:35:46 typhon kernel: da0 at ahc0 bus 0 scbus0 target 0 lun 0 Jun 11 05:35:46 typhon kernel: da0: Fixed Direct Access SCSI-2 device Jun 11 05:35:46 typhon kernel: da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Jun 11 05:35:46 typhon kernel: da0: Command Queueing enabled Jun 11 05:35:46 typhon kernel: da0: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) Jun 11 05:35:46 typhon kernel: Trying to mount root from ufs:/dev/da0s1a [noatime,rw]... Jun 11 05:35:46 typhon kernel: WARNING: / was not properly dismounted Jun 11 05:38:10 typhon kernel: done. --- LOR after reboot --- Jun 11 05:38:12 typhon kernel: lock order reversal: Jun 11 05:38:12 typhon kernel: 1st 0xde887868 bufwait (bufwait) @ /src/src-9/sys/kern/vfs_bio.c:2725 Jun 11 05:38:12 typhon kernel: 2nd 0xc503559c snaplk (snaplk) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:2296 Jun 11 05:38:12 typhon kernel: 3rd 0xde887b10 bufwait (bufwait) @ /src/src-9/sys/kern/vfs_bio.c:2725 Jun 11 05:38:12 typhon kernel: KDB: stack backtrace: Jun 11 05:38:12 typhon kernel: db_trace_self_wrapper(c0815bdd,2f6e7265,5f736676,2e6f6962,37323a63,...) at db_trace_self_wrapper+0x26/frame 0xdebf63e0 Jun 11 05:38:12 typhon kernel: kdb_backtrace(c063659b,c08198cd,c09e9990,aa5,debf64ac,...) at kdb_backtrace+0x2a/frame 0xdebf643c Jun 11 05:38:12 typhon kernel: _witness_debugger(c08198cd,de887b10,c081fa43,c4c26140,c081ee1e,...) at _witness_debugger+0x25/frame 0xdebf6454 Jun 11 05:38:12 typhon kernel: witness_checkorder(de887b10,9,c081ee1e,aa5,0,...) at witness_checkorder+0x86f/frame 0xdebf64ac Jun 11 05:38:12 typhon kernel: __lockmgr_args(de887b10,81900,c509df18,c081f99f,60,...) at __lockmgr_args+0x829/frame 0xdebf6564 Jun 11 05:38:12 typhon kernel: getblk(c509de6c,fffff7f3,ffffffff,4000,0,...) at getblk+0x154/frame 0xdebf65b8 Jun 11 05:38:12 typhon kernel: breadn_flags(c509de6c,fffff7f3,ffffffff,4000,0,...) at breadn_flags+0x43/frame 0xdebf65e8 Jun 11 05:38:12 typhon kernel: bread(c509de6c,fffff7f3,ffffffff,4000,0,...) at bread+0x54/frame 0xdebf6618 Jun 11 05:38:12 typhon kernel: ffs_balloc_ufs2(c509de6c,918f8000,1,4000,c4c0fb00,...) at ffs_balloc_ufs2+0x16ee/frame 0xdebf67c4 Jun 11 05:38:12 typhon kernel: ffs_copyonwrite(c509d8e0,de887808,de887808,0,0,...) at ffs_copyonwrite+0x3ee/frame 0xdebf6840 Jun 11 05:38:12 typhon kernel: ffs_geom_strategy(c509d98c,de887808,0,de887808,3231b8,...) at ffs_geom_strategy+0xeb/frame 0xdebf685c Jun 11 05:38:12 typhon kernel: bufwrite(de887808,0,c0835390,832,0) at bufwrite+0x169/frame 0xdebf687c Jun 11 05:38:12 typhon kernel: ffs_bufwrite(de887808,c5119300,100,4000,0,...) at ffs_bufwrite+0x290/frame 0xdebf68a0 Jun 11 05:38:12 typhon kernel: ffs_update(c53aa238,1,c0835afd,152,0,...) at ffs_update+0x395/frame 0xdebf6910 Jun 11 05:38:12 typhon kernel: ffs_syncvnode(c53aa238,1,0,4c6,c53aa2e4,...) at ffs_syncvnode+0x591/frame 0xdebf696c Jun 11 05:38:12 typhon kernel: ffs_fsync(debf69bc,4ce,c08219ca,0,debf69cc,...) at ffs_fsync+0x2f/frame 0xdebf6994 Jun 11 05:38:12 typhon kernel: VOP_FSYNC_APV(c0882560,debf69bc,c088ffc0,c53aa238,1,...) at VOP_FSYNC_APV+0xa5/frame 0xdebf69ac Jun 11 05:38:12 typhon kernel: bufsync(c53aa2e4,1,c08219ca,4ce,c4fb3d00,...) at bufsync+0x38/frame 0xdebf69cc Jun 11 05:38:12 typhon kernel: bufobj_invalbuf(c53aa2e4,1,0,0,debf6c24,...) at bufobj_invalbuf+0xb5/frame 0xdebf6a04 Jun 11 05:38:12 typhon kernel: vinvalbuf(c53aa238,1,0,0,0,...) at vinvalbuf+0x2b/frame 0xdebf6a1c Jun 11 05:38:12 typhon kernel: vfs_donmount(c5023600,5,0,c52e3300,c52e3300,...) at vfs_donmount+0xabe/frame 0xdebf6c24 Jun 11 05:38:12 typhon kernel: sys_nmount(c5023600,debf6ccc,c0846650,c081a5d6,286,...) at sys_nmount+0x65/frame 0xdebf6c48 Jun 11 05:38:12 typhon kernel: syscall(debf6d08) at syscall+0x24d/frame 0xdebf6cfc Jun 11 05:38:12 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdebf6cfc Jun 11 05:38:12 typhon kernel: --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180d20c7, esp = 0xbfbfcdbc, ebp = 0xbfbfd318 --- --- cronjob start, day 2 --- Jun 12 05:01:00 typhon kernel: lock order reversal: Jun 12 05:01:00 typhon kernel: 1st 0xc515d290 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 Jun 12 05:01:00 typhon kernel: 2nd 0xc53aa058 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 Jun 12 05:01:00 typhon kernel: KDB: stack backtrace: Jun 12 05:01:00 typhon kernel: db_trace_self_wrapper(c0815bdd,662f7366,765f7366,706f7366,3a632e73,...) at db_trace_self_wrapper+0x26/frame 0xec36e8d4 Jun 12 05:01:00 typhon kernel: kdb_backtrace(c063659b,c08198b4,c09e9a20,586,ec36e9a0,...) at kdb_backtrace+0x2a/frame 0xec36e930 Jun 12 05:01:00 typhon kernel: _witness_debugger(c08198b4,c53aa058,c080d6e7,c4c29338,c0835390,...) at _witness_debugger+0x25/frame 0xec36e948 Jun 12 05:01:00 typhon kernel: witness_checkorder(c53aa058,9,c0835390,586,c53aa078,...) at witness_checkorder+0x86f/frame 0xec36e9a0 Jun 12 05:01:00 typhon kernel: __lockmgr_args(c53aa058,80400,c53aa078,0,0,...) at __lockmgr_args+0x829/frame 0xec36ea58 Jun 12 05:01:00 typhon kernel: vop_stdlock(ec36eabc,246,c08bcd9c,80400,c53aa000,...) at vop_stdlock+0x62/frame 0xec36ea8c Jun 12 05:01:00 typhon kernel: VOP_LOCK1_APV(c08611e0,ec36eabc,c09e9a24,c0890120,c53aa000,...) at VOP_LOCK1_APV+0xb5/frame 0xec36eaa8 Jun 12 05:01:00 typhon kernel: _vn_lock(c53aa000,80400,c0835390,586,ec36eb14,...) at _vn_lock+0x5e/frame 0xec36eadc Jun 12 05:01:00 typhon kernel: ffs_flushfiles(c504b000,0,c5414000,0,c504b000,...) at ffs_flushfiles+0x133/frame 0xec36eb1c Jun 12 05:01:00 typhon kernel: ffs_unmount(c504b000,8000000,c0821043,513,c4c00c08,...) at ffs_unmount+0x180/frame 0xec36eb5c Jun 12 05:01:00 typhon kernel: dounmount(c504b000,8000000,c5414000,494,c519e958,...) at dounmount+0x423/frame 0xec36ebac Jun 12 05:01:00 typhon kernel: sys_unmount(c5414000,ec36eccc,c0846650,c081a478,206,...) at sys_unmount+0x3d1/frame 0xec36ec48 Jun 12 05:01:00 typhon kernel: syscall(ec36ed08) at syscall+0x24d/frame 0xec36ecfc Jun 12 05:01:00 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xec36ecfc Jun 12 05:01:00 typhon kernel: --- syscall (22, FreeBSD ELF32, sys_unmount), eip = 0x180bf3e7, esp = 0xbfbfd61c, ebp = 0xbfbfd6e8 --- Jun 12 05:01:08 typhon kernel: lock order reversal: Jun 12 05:01:08 typhon kernel: 1st 0xc503559c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 Jun 12 05:01:08 typhon kernel: 2nd 0xc511b058 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 Jun 12 05:01:08 typhon kernel: KDB: stack backtrace: Jun 12 05:01:08 typhon kernel: db_trace_self_wrapper(c0815bdd,735f7366,7370616e,2e746f68,36313a63,...) at db_trace_self_wrapper+0x26/frame 0xec350614 Jun 12 05:01:08 typhon kernel: kdb_backtrace(c063659b,c08198b4,c09e9750,65a,ec3506e0,...) at kdb_backtrace+0x2a/frame 0xec350670 Jun 12 05:01:08 typhon kernel: _witness_debugger(c08198b4,c511b058,c0808f48,c4c29470,c0831f9d,...) at _witness_debugger+0x25/frame 0xec350688 Jun 12 05:01:08 typhon kernel: witness_checkorder(c511b058,9,c0831f9d,65a,0,...) at witness_checkorder+0x86f/frame 0xec3506e0 Jun 12 05:01:08 typhon kernel: __lockmgr_args(c511b058,80000,0,0,0,...) at __lockmgr_args+0x829/frame 0xec350798 Jun 12 05:01:08 typhon kernel: ffs_snapremove(c511b000,c4c23f88,c4c26140,4,c09e9750,...) at ffs_snapremove+0x11f/frame 0xec350818 Jun 12 05:01:08 typhon kernel: ffs_truncate(c511b000,0,0,c00,0,...) at ffs_truncate+0x637/frame 0xec350a44 Jun 12 05:01:08 typhon kernel: ufs_inactive(ec350ab8,c511b000,c511b000,c52fcd4c,ec350ad0,...) at ufs_inactive+0x1f8/frame 0xec350a80 Jun 12 05:01:08 typhon kernel: VOP_INACTIVE_APV(c0882560,ec350ab8,c08219ca,a00,c068657a,...) at VOP_INACTIVE_APV+0xa5/frame 0xec350a98 Jun 12 05:01:08 typhon kernel: vinactive(c511b000,c51a3c00,c08219ca,8fe,0,...) at vinactive+0x112/frame 0xec350ad0 Jun 12 05:01:08 typhon kernel: vputx(ec350c18,c069fcf4,c511b000,ffffffdf,2,...) at vputx+0x2fc/frame 0xec350b0c Jun 12 05:01:08 typhon kernel: vput(c511b000,ffffffdf,2,0,5,...) at vput+0x10/frame 0xec350b14 Jun 12 05:01:08 typhon kernel: kern_unlinkat(c51a3c00,ffffff9c,bfbfdf32,0,0,...) at kern_unlinkat+0x274/frame 0xec350c18 Jun 12 05:01:08 typhon kernel: kern_unlink(c51a3c00,bfbfdf32,0,ec350cfc,c07b310d,...) at kern_unlink+0x2f/frame 0xec350c34 Jun 12 05:01:08 typhon kernel: sys_unlink(c51a3c00,ec350ccc,c0846650,c081a4d8,246,...) at sys_unlink+0x22/frame 0xec350c48 Jun 12 05:01:08 typhon kernel: syscall(ec350d08) at syscall+0x24d/frame 0xec350cfc Jun 12 05:01:08 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xec350cfc Jun 12 05:01:08 typhon kernel: --- syscall (10, FreeBSD ELF32, sys_unlink), eip = 0x1814ee83, esp = 0xbfbfdd3c, ebp = 0xbfbfddb8 --- --- reboot on day 2 --- Jun 12 05:35:46 typhon kernel: Copyright (c) 1992-2013 The FreeBSD Project. Jun 12 05:35:46 typhon kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jun 12 05:35:46 typhon kernel: The Regents of the University of California. All rights reserved. Jun 12 05:35:46 typhon kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jun 12 05:35:46 typhon kernel: FreeBSD 9.1-STABLE #3: Sat Jun 8 11:02:16 CEST 2013 Jun 12 05:35:46 typhon kernel: root@server.ofw.tld:/usr/obj/src/src-9/sys/typhon i386 Jun 12 05:35:46 typhon kernel: gcc version 4.2.1 20070831 patched [FreeBSD] Jun 12 05:35:46 typhon kernel: WARNING: WITNESS option enabled, expect reduced performance. Jun 12 05:35:46 typhon kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Jun 12 05:35:46 typhon kernel: CPU: Pentium(R) Dual-Core CPU E6600 @ 3.06GHz (3071.99-MHz 686-class CPU) Jun 12 05:35:46 typhon kernel: Origin = "GenuineIntel" Id = 0x1067a Family = 0x6 Model = 0x17 Stepping = 10 Jun 12 05:35:46 typhon kernel: Features=0xbfebfbff Jun 12 05:35:46 typhon kernel: Features2=0x400e3bd Jun 12 05:35:46 typhon kernel: AMD Features=0x20100000 Jun 12 05:35:46 typhon kernel: AMD Features2=0x1 Jun 12 05:35:46 typhon kernel: TSC: P-state invariant, performance statistics Jun 12 05:35:46 typhon kernel: real memory = 2147483648 (2048 MB) Jun 12 05:35:46 typhon kernel: avail memory = 2096226304 (1999 MB) Jun 12 05:35:46 typhon kernel: Event timer "LAPIC" quality 400 Jun 12 05:35:46 typhon kernel: ACPI APIC Table: Jun 12 05:35:46 typhon kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jun 12 05:35:46 typhon kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Jun 12 05:35:46 typhon kernel: cpu0 (BSP): APIC ID: 0 Jun 12 05:35:46 typhon kernel: cpu1 (AP): APIC ID: 1 Jun 12 05:35:46 typhon kernel: ioapic0 irqs 0-23 on motherboard Jun 12 05:35:46 typhon kernel: acpi0: on motherboard Jun 12 05:35:46 typhon kernel: acpi0: Power Button (fixed) Jun 12 05:35:46 typhon kernel: acpi0: reservation of 0, a0000 (3) failed Jun 12 05:35:46 typhon kernel: acpi0: reservation of 100000, 7ff00000 (3) failed Jun 12 05:35:46 typhon kernel: cpu0: on acpi0 Jun 12 05:35:46 typhon kernel: cpu1: on acpi0 Jun 12 05:35:46 typhon kernel: attimer0: port 0x40-0x43 irq 0 on acpi0 Jun 12 05:35:46 typhon kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jun 12 05:35:46 typhon kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Jun 12 05:35:46 typhon kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Jun 12 05:35:46 typhon kernel: Event timer "RTC" frequency 32768 Hz quality 0 Jun 12 05:35:46 typhon kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jun 12 05:35:46 typhon kernel: Timecounter "HPET" frequency 14318180 Hz quality 950 Jun 12 05:35:46 typhon kernel: Event timer "HPET" frequency 14318180 Hz quality 450 Jun 12 05:35:46 typhon kernel: Event timer "HPET1" frequency 14318180 Hz quality 440 Jun 12 05:35:46 typhon kernel: Event timer "HPET2" frequency 14318180 Hz quality 440 Jun 12 05:35:46 typhon kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Jun 12 05:35:46 typhon kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jun 12 05:35:46 typhon kernel: pcib0: port 0xcf8-0xcff on acpi0 Jun 12 05:35:46 typhon kernel: pci0: on pcib0 Jun 12 05:35:46 typhon kernel: eccmon0: RAM ECC Monitor v0.13 on i975X (8086:277C), reporting tested Jun 12 05:35:46 typhon kernel: eccmon0: Capabilities: ECC detection and correction Jun 12 05:35:46 typhon kernel: eccmon0: Current mode: ECC detection and correction Jun 12 05:35:46 typhon kernel: eccmon0: Bank Size Type ILV ECC Jun 12 05:35:46 typhon kernel: eccmon0: 0 1024M DDR2 Y Y Jun 12 05:35:46 typhon kernel: eccmon0: 1 1024M DDR2 Y Y Jun 12 05:35:46 typhon kernel: eccmon0: Total RAM detected: 2048M Jun 12 05:35:46 typhon kernel: eccmon0: on hostb0 Jun 12 05:35:46 typhon kernel: eccmon0: attached Jun 12 05:35:46 typhon kernel: pcib1: irq 16 at device 1.0 on pci0 Jun 12 05:35:46 typhon kernel: pci4: on pcib1 Jun 12 05:35:46 typhon kernel: 3ware device driver for 9000 series storage controllers, version: 3.80.06.003 Jun 12 05:35:46 typhon kernel: twa0: <3ware 9000 series Storage Controller> port 0xd800-0xd8ff mem 0xfc000000-0xfdffffff,0xff9ff000-0xff9fffff irq 16 at device 0.0 on pci4 Jun 12 05:35:46 typhon kernel: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9690SA-8I, 128 ports, Firmware FH9X 4.10.00.027, BIOS BE9X 4.08.00.004 Jun 12 05:35:46 typhon kernel: pcib2: irq 16 at device 28.0 on pci0 Jun 12 05:35:46 typhon kernel: pci3: on pcib2 Jun 12 05:35:46 typhon kernel: pcib3: irq 19 at device 28.3 on pci0 Jun 12 05:35:46 typhon kernel: pci2: on pcib3 Jun 12 05:35:46 typhon kernel: mskc0: port 0xc800-0xc8ff mem 0xff8fc000-0xff8fffff irq 19 at device 0.0 on pci2 Jun 12 05:35:46 typhon kernel: msk0: on mskc0 Jun 12 05:35:46 typhon kernel: msk0: Ethernet address: 00:18:f3:87:86:60 Jun 12 05:35:46 typhon kernel: miibus0: on msk0 Jun 12 05:35:46 typhon kernel: e1000phy0: PHY 0 on miibus0 Jun 12 05:35:46 typhon kernel: e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jun 12 05:35:46 typhon kernel: pcib4: at device 30.0 on pci0 Jun 12 05:35:46 typhon kernel: pci1: on pcib4 Jun 12 05:35:46 typhon kernel: vgapci0: mem 0xff7fc000-0xff7fffff,0xfa000000-0xfa7fffff irq 21 at device 0.0 on pci1 Jun 12 05:35:46 typhon kernel: ahc0: port 0xb800-0xb8ff mem 0xff7fb000-0xff7fbfff irq 22 at device 1.0 on pci1 Jun 12 05:35:46 typhon kernel: ahc0: Bugs (0x0040): SCBCHAN_UPLOAD Jun 12 05:35:46 typhon kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Jun 12 05:35:46 typhon kernel: isab0: at device 31.0 on pci0 Jun 12 05:35:46 typhon kernel: isa0: on isab0 Jun 12 05:35:46 typhon kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 Jun 12 05:35:46 typhon kernel: ata0: at channel 0 on atapci0 Jun 12 05:35:46 typhon kernel: atapci1: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xffaffc00-0xffafffff irq 23 at device 31.2 on pci0 Jun 12 05:35:46 typhon kernel: ata2: at channel 0 on atapci1 Jun 12 05:35:46 typhon kernel: ata3: at channel 1 on atapci1 Jun 12 05:35:46 typhon kernel: ichsmb0: port 0x400-0x41f at device 31.3 on pci0 Jun 12 05:35:46 typhon kernel: smbus0: on ichsmb0 Jun 12 05:35:46 typhon kernel: smb0: on smbus0 Jun 12 05:35:46 typhon kernel: acpi_button0: on acpi0 Jun 12 05:35:46 typhon kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jun 12 05:35:46 typhon kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Jun 12 05:35:46 typhon kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jun 12 05:35:46 typhon kernel: atkbd0: irq 1 on atkbdc0 Jun 12 05:35:46 typhon kernel: atkbd0: [GIANT-LOCKED] Jun 12 05:35:46 typhon kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jun 12 05:35:46 typhon kernel: ichwd0 on isa0 Jun 12 05:35:46 typhon kernel: orm0: at iomem 0xc0000-0xc7fff,0xcd800-0xcdfff pnpid ORM0000 on isa0 Jun 12 05:35:46 typhon kernel: sc0: at flags 0x100 on isa0 Jun 12 05:35:46 typhon kernel: sc0: VGA <9 virtual consoles, flags=0x300> Jun 12 05:35:46 typhon kernel: vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 Jun 12 05:35:46 typhon kernel: coretemp0: on cpu0 Jun 12 05:35:46 typhon kernel: est0: on cpu0 Jun 12 05:35:46 typhon kernel: est0: Guessed bus clock (high) of 267 MHz Jun 12 05:35:46 typhon kernel: est0: Guessed high setting of 3071 MHz @ 1292 mV Jun 12 05:35:46 typhon kernel: est0: Guessed low setting of 1602 MHz @ 1052 mV Jun 12 05:35:46 typhon kernel: p4tcc0: on cpu0 Jun 12 05:35:46 typhon kernel: coretemp1: on cpu1 Jun 12 05:35:46 typhon kernel: est1: on cpu1 Jun 12 05:35:46 typhon kernel: est1: Guessed bus clock (high) of 267 MHz Jun 12 05:35:46 typhon kernel: est1: Guessed high setting of 3071 MHz @ 1292 mV Jun 12 05:35:46 typhon kernel: est1: Guessed low setting of 1602 MHz @ 1052 mV Jun 12 05:35:46 typhon kernel: p4tcc1: on cpu1 Jun 12 05:35:46 typhon kernel: Timecounters tick every 10.000 msec Jun 12 05:35:46 typhon kernel: Expensive timeout(9) function: 0xc04d8900(0xc4d8e800) 0.123575412 s Jun 12 05:35:46 typhon kernel: da10 at twa0 bus 0 scbus1 target 0 lun 0 Jun 12 05:35:46 typhon kernel: da10: Fixed Direct Access SCSI-5 device Jun 12 05:35:46 typhon kernel: da10: 100.000MB/s transfers Jun 12 05:35:46 typhon kernel: da10: 2860962MB (5859250176 512 byte sectors: 255H 63S/T 364721C) Jun 12 05:35:46 typhon kernel: SMP: AP CPU #1 Launched! Jun 12 05:35:46 typhon kernel: Timecounter "TSC-low" frequency 1535994291 Hz quality 1000 Jun 12 05:35:46 typhon kernel: WARNING: WITNESS option enabled, expect reduced performance. Jun 12 05:35:46 typhon kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Jun 12 05:35:46 typhon kernel: da1 at ahc0 bus 0 scbus0 target 1 lun 0 Jun 12 05:35:46 typhon kernel: da1: Fixed Direct Access SCSI-2 device Jun 12 05:35:46 typhon kernel: da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Jun 12 05:35:46 typhon kernel: da1: Command Queueing enabled Jun 12 05:35:46 typhon kernel: da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) Jun 12 05:35:46 typhon kernel: da0 at ahc0 bus 0 scbus0 target 0 lun 0 Jun 12 05:35:46 typhon kernel: da0: Fixed Direct Access SCSI-2 device Jun 12 05:35:46 typhon kernel: da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) Jun 12 05:35:46 typhon kernel: da0: Command Queueing enabled Jun 12 05:35:46 typhon kernel: da0: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) Jun 12 05:35:46 typhon kernel: Trying to mount root from ufs:/dev/da0s1a [noatime,rw]... Jun 12 05:35:46 typhon kernel: WARNING: / was not properly dismounted --- LOR after reboot --- Jun 12 05:38:09 typhon kernel: done. Jun 12 05:38:11 typhon kernel: lock order reversal: Jun 12 05:38:11 typhon kernel: 1st 0xde886080 bufwait (bufwait) @ /src/src-9/sys/kern/vfs_bio.c:2725 Jun 12 05:38:11 typhon kernel: 2nd 0xc4fdc0dc snaplk (snaplk) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:2296 Jun 12 05:38:11 typhon kernel: 3rd 0xde886328 bufwait (bufwait) @ /src/src-9/sys/kern/vfs_bio.c:2725 Jun 12 05:38:11 typhon kernel: KDB: stack backtrace: Jun 12 05:38:11 typhon kernel: db_trace_self_wrapper(c0815bdd,2f6e7265,5f736676,2e6f6962,37323a63,...) at db_trace_self_wrapper+0x26/frame 0xdebd23e0 Jun 12 05:38:11 typhon kernel: kdb_backtrace(c063659b,c08198cd,c09e9a40,aa5,debd24ac,...) at kdb_backtrace+0x2a/frame 0xdebd243c Jun 12 05:38:11 typhon kernel: _witness_debugger(c08198cd,de886328,c081fa43,c4c26140,c081ee1e,...) at _witness_debugger+0x25/frame 0xdebd2454 Jun 12 05:38:11 typhon kernel: witness_checkorder(de886328,9,c081ee1e,aa5,0,...) at witness_checkorder+0x86f/frame 0xdebd24ac Jun 12 05:38:11 typhon kernel: __lockmgr_args(de886328,81900,c510f1c8,c081f99f,60,...) at __lockmgr_args+0x829/frame 0xdebd2564 Jun 12 05:38:11 typhon kernel: getblk(c510f11c,fffff7f3,ffffffff,4000,0,...) at getblk+0x154/frame 0xdebd25b8 Jun 12 05:38:11 typhon kernel: breadn_flags(c510f11c,fffff7f3,ffffffff,4000,0,...) at breadn_flags+0x43/frame 0xdebd25e8 Jun 12 05:38:11 typhon kernel: bread(c510f11c,fffff7f3,ffffffff,4000,0,...) at bread+0x54/frame 0xdebd2618 Jun 12 05:38:11 typhon kernel: ffs_balloc_ufs2(c510f11c,918f8000,1,4000,c4c0fb00,...) at ffs_balloc_ufs2+0x16ee/frame 0xdebd27c4 Jun 12 05:38:11 typhon kernel: ffs_copyonwrite(c509cd50,de886020,de886020,0,0,...) at ffs_copyonwrite+0x3ee/frame 0xdebd2840 Jun 12 05:38:11 typhon kernel: ffs_geom_strategy(c509cdfc,de886020,0,de886020,3231b8,...) at ffs_geom_strategy+0xeb/frame 0xdebd285c Jun 12 05:38:11 typhon kernel: bufwrite(de886020,0,c0835390,832,0) at bufwrite+0x169/frame 0xdebd287c Jun 12 05:38:11 typhon kernel: ffs_bufwrite(de886020,c5118600,100,4000,0,...) at ffs_bufwrite+0x290/frame 0xdebd28a0 Jun 12 05:38:11 typhon kernel: ffs_update(c509d6a8,1,c0835afd,152,0,...) at ffs_update+0x395/frame 0xdebd2910 Jun 12 05:38:11 typhon kernel: ffs_syncvnode(c509d6a8,1,0,4c6,c509d754,...) at ffs_syncvnode+0x591/frame 0xdebd296c Jun 12 05:38:11 typhon kernel: ffs_fsync(debd29bc,4ce,c08219ca,0,debd29cc,...) at ffs_fsync+0x2f/frame 0xdebd2994 Jun 12 05:38:11 typhon kernel: VOP_FSYNC_APV(c0882560,debd29bc,c088ffc0,c509d6a8,1,...) at VOP_FSYNC_APV+0xa5/frame 0xdebd29ac Jun 12 05:38:11 typhon kernel: bufsync(c509d754,1,c08219ca,4ce,c503ba00,...) at bufsync+0x38/frame 0xdebd29cc Jun 12 05:38:11 typhon kernel: bufobj_invalbuf(c509d754,1,0,0,debd2c24,...) at bufobj_invalbuf+0xb5/frame 0xdebd2a04 Jun 12 05:38:11 typhon kernel: vinvalbuf(c509d6a8,1,0,0,0,...) at vinvalbuf+0x2b/frame 0xdebd2a1c Jun 12 05:38:11 typhon kernel: vfs_donmount(c506e300,5,0,c515ae80,c515ae80,...) at vfs_donmount+0xabe/frame 0xdebd2c24 Jun 12 05:38:11 typhon kernel: sys_nmount(c506e300,debd2ccc,c0846650,c081a5d6,286,...) at sys_nmount+0x65/frame 0xdebd2c48 Jun 12 05:38:11 typhon kernel: syscall(debd2d08) at syscall+0x24d/frame 0xdebd2cfc Jun 12 05:38:11 typhon kernel: Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xdebd2cfc Jun 12 05:38:11 typhon kernel: --- syscall (378, FreeBSD ELF32, sys_nmount), eip = 0x180d20c7, esp = 0xbfbfcdbc, ebp = 0xbfbfd318 --- Unfortunately, I had to disable the cronjob now since people started complaining that the box didn't survive a single night ;-). Thanks, -Andre From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 07:15: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 4ECA36A4; Sun, 16 Jun 2013 07:15:47 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by mx1.freebsd.org (Postfix) with ESMTP id CF1421D0C; Sun, 16 Jun 2013 07:15:46 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 07295535C38; Sun, 16 Jun 2013 08:55:01 +0200 (CEST) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 3450341C06B; Sun, 16 Jun 2013 08:54:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ncyqRdISyhxZ; Sun, 16 Jun 2013 08:54: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 3EC8841C05A; Sun, 16 Jun 2013 08:54:43 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 5F2B173A1C; Sat, 15 Jun 2013 23:54:41 -0700 (PDT) Date: Sat, 15 Jun 2013 23:54:41 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616065441.GA15175@icarus.home.lan> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130531172523.GA9188@bali> 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, 16 Jun 2013 07:15:47 -0000 On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > I'll try to arrange that. It'll take a bit since this > box is 200 km away... > > Maybe I'll find another one nearby to reproduce it... SPECIFICALLY regarding "lack of crash dumps": I need to see the following: * cat /etc/rc.conf * cat /etc/fstab I may need output from other commands, but shall deal with that when I see output from the above. Thanks. -- | 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 Jun 16 08:15: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 02D00572; Sun, 16 Jun 2013 08:15:34 +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 8D91C1EDD; Sun, 16 Jun 2013 08:15:33 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r5G82e69023384; Sun, 16 Jun 2013 10:02:40 +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 r5G82dsc027390; Sun, 16 Jun 2013 10:02:39 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r5G82dgq093692; Date: Sun, 16 Jun 2013 10:02:39 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616080239.GA73100@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> <20130616065441.GA15175@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130616065441.GA15175@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: "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, 16 Jun 2013 08:15:34 -0000 On Sun, 16-Jun-2013 at 08:54:41 +0200, Jeremy Chadwick wrote: > On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > > > I'll try to arrange that. It'll take a bit since this > > box is 200 km away... > > > > Maybe I'll find another one nearby to reproduce it... > > SPECIFICALLY regarding "lack of crash dumps": I need to see the > following: > > * cat /etc/rc.conf > * cat /etc/fstab > > I may need output from other commands, but shall deal with that when I > see output from the above. Thanks. No problem, see below... To make a long story short, the machine dumps core perfectly (tested that a while ago), but not when dealing with _this_ issue... I dump on da1s1b and savecore fetches it from there and puts it on /var (sitting on da0), that's faster. rc.conf (beware, rc.conf.local exists): --------------------------------------- rcshutdown_timeout=180 tmpmfs=YES tmpsize="$(( `/sbin/sysctl -n hw.usermem` / 3000000 ))m" tmpmfs_flags="$tmpmfs_flags -v 1 -n" background_fsck=NO nisdomainname=ofw.tld pflog_flags=-S syslogd_flags=-svv inetd_enable=YES inetd_flags=-l named_flags="-S 1000" named_chrootdir="" rwhod_enable=YES sshd_enable=YES amd_enable=YES amd_flags="-F /etc/amd.conf" nfs_client_enable=YES nfs_access_cache=2 mountd_flags=-n rpcbind_enable=YES ntpdate_enable=YES ntpdate_hosts=ntp ntpd_enable=YES ntpd_flags="-p /var/run/ntpd.pid" nis_client_enable=YES nis_client_flags="-s -S ofw.tld,nis-16-1,nis-16-2" nis_server_flags=-n nis_yppasswdd_flags="-t /var/yp/src/master.passwd -f -v" defaultrouter=192.168.16.2 keyrate=fast sendmail_flags="-bd -q5m" sendmail_submit_flags="$sendmail_flags -ODaemonPortOptions=Addr=localhost" sendmail_msp_queue_flags="-Ac -q30m" sendmail_rebuild_aliases=NO lpd_enable=YES lpd_flags=-s chkprintcap_enable=YES dumpdev=AUTO clear_tmp_X=NO ldconfig_paths=/usr/local/lib ldconfig_paths_aout="" entropy_file=/boot/entropy-file rc.conf.local: -------------- hostname=typhon.ofw.tld ifconfig_msk0="inet 192.168.24.1/21" ifconfig_msk0_alias0="inet 192.168.24.10/32" named_enable=YES nfs_server_enable=YES nis_client_flags="-s -S ofw.tld,nis-24-1,nis-24-2" nis_server_enable=YES defaultrouter=192.168.24.2 lpd_flags=-l dumpdev=/dev/da1s1b quota_enable=YES fstab: ------ /dev/da0s1a / ufs noatime,rw 0 1 /dev/da0s1b none swap sw 0 0 proc /proc procfs rw 0 0 /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 From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 08:49: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 5A645CA0; Sun, 16 Jun 2013 08:49:54 +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 00E9E1FB9; Sun, 16 Jun 2013 08:49:53 +0000 (UTC) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 06386A80B5; Sun, 16 Jun 2013 10:49:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0uc32x0YoAEd; Sun, 16 Jun 2013 10:49:40 +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 C7262A80B0; Sun, 16 Jun 2013 10:49:39 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id D4A4B73A1C; Sun, 16 Jun 2013 01:49:37 -0700 (PDT) Date: Sun, 16 Jun 2013 01:49:37 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616084937.GA17277@icarus.home.lan> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> <20130616065441.GA15175@icarus.home.lan> <20130616080239.GA73100@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130616080239.GA73100@bali> 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, 16 Jun 2013 08:49:54 -0000 On Sun, Jun 16, 2013 at 10:02:39AM +0200, Andre Albsmeier wrote: > On Sun, 16-Jun-2013 at 08:54:41 +0200, Jeremy Chadwick wrote: > > On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > > > > > I'll try to arrange that. It'll take a bit since this > > > box is 200 km away... > > > > > > Maybe I'll find another one nearby to reproduce it... > > > > SPECIFICALLY regarding "lack of crash dumps": I need to see the > > following: > > > > * cat /etc/rc.conf > > * cat /etc/fstab > > > > I may need output from other commands, but shall deal with that when I > > see output from the above. Thanks. > > No problem, see below... > > To make a long story short, the machine dumps core perfectly > (tested that a while ago), but not when dealing with _this_ > issue... > > I dump on da1s1b and savecore fetches it from there and puts > it on /var (sitting on da0), that's faster. > > rc.conf (beware, rc.conf.local exists): > --------------------------------------- > rcshutdown_timeout=180 > tmpmfs=YES > tmpsize="$(( `/sbin/sysctl -n hw.usermem` / 3000000 ))m" > tmpmfs_flags="$tmpmfs_flags -v 1 -n" > > background_fsck=NO > > nisdomainname=ofw.tld > pflog_flags=-S > > syslogd_flags=-svv > inetd_enable=YES > inetd_flags=-l > named_flags="-S 1000" > named_chrootdir="" > rwhod_enable=YES > sshd_enable=YES > amd_enable=YES > amd_flags="-F /etc/amd.conf" > nfs_client_enable=YES > nfs_access_cache=2 > mountd_flags=-n > rpcbind_enable=YES > > ntpdate_enable=YES > ntpdate_hosts=ntp > ntpd_enable=YES > ntpd_flags="-p /var/run/ntpd.pid" > > nis_client_enable=YES > nis_client_flags="-s -S ofw.tld,nis-16-1,nis-16-2" > nis_server_flags=-n > nis_yppasswdd_flags="-t /var/yp/src/master.passwd -f -v" > > defaultrouter=192.168.16.2 > > keyrate=fast > > sendmail_flags="-bd -q5m" > sendmail_submit_flags="$sendmail_flags -ODaemonPortOptions=Addr=localhost" > sendmail_msp_queue_flags="-Ac -q30m" > sendmail_rebuild_aliases=NO > > lpd_enable=YES > lpd_flags=-s > chkprintcap_enable=YES > dumpdev=AUTO > clear_tmp_X=NO > ldconfig_paths=/usr/local/lib > ldconfig_paths_aout="" > entropy_file=/boot/entropy-file > > > rc.conf.local: > -------------- > hostname=typhon.ofw.tld > ifconfig_msk0="inet 192.168.24.1/21" > ifconfig_msk0_alias0="inet 192.168.24.10/32" > > named_enable=YES > nfs_server_enable=YES > > nis_client_flags="-s -S ofw.tld,nis-24-1,nis-24-2" > nis_server_enable=YES > > defaultrouter=192.168.24.2 > > lpd_flags=-l > dumpdev=/dev/da1s1b > quota_enable=YES > > > fstab: > ------ > /dev/da0s1a / ufs noatime,rw 0 1 > /dev/da0s1b none swap sw 0 0 > proc /proc procfs rw 0 0 > /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 Thank you. Can you show me output from the following? * camcontrol devlist * gpart show -p da1 I'm pretty sure I see the problem, but I want to be extra sure. -- | 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 Jun 16 09:55: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 7DAB6786; Sun, 16 Jun 2013 09:55:40 +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 0B05B11BD; Sun, 16 Jun 2013 09:55:39 +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 r5G9tcve023882; Sun, 16 Jun 2013 11:55:38 +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 r5G9tc2O002267; Sun, 16 Jun 2013 11:55:38 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r5G9tcUi093944; Date: Sun, 16 Jun 2013 11:55:38 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616095538.GA73648@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> <20130616065441.GA15175@icarus.home.lan> <20130616080239.GA73100@bali> <20130616084937.GA17277@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130616084937.GA17277@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: "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, 16 Jun 2013 09:55:40 -0000 On Sun, 16-Jun-2013 at 10:49:37 +0200, Jeremy Chadwick wrote: > On Sun, Jun 16, 2013 at 10:02:39AM +0200, Andre Albsmeier wrote: > > On Sun, 16-Jun-2013 at 08:54:41 +0200, Jeremy Chadwick wrote: > > > On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > > > > > > > I'll try to arrange that. It'll take a bit since this > > > > box is 200 km away... > > > > > > > > Maybe I'll find another one nearby to reproduce it... > > > > > > SPECIFICALLY regarding "lack of crash dumps": I need to see the > > > following: > > > > > > * cat /etc/rc.conf > > > * cat /etc/fstab > > > > > > I may need output from other commands, but shall deal with that when I > > > see output from the above. Thanks. > > > > No problem, see below... > > > > To make a long story short, the machine dumps core perfectly > > (tested that a while ago), but not when dealing with _this_ > > issue... > > > > I dump on da1s1b and savecore fetches it from there and puts > > it on /var (sitting on da0), that's faster. > > > > rc.conf (beware, rc.conf.local exists): > > --------------------------------------- > > rcshutdown_timeout=180 > > tmpmfs=YES > > tmpsize="$(( `/sbin/sysctl -n hw.usermem` / 3000000 ))m" > > tmpmfs_flags="$tmpmfs_flags -v 1 -n" > > > > background_fsck=NO > > > > nisdomainname=ofw.tld > > pflog_flags=-S > > > > syslogd_flags=-svv > > inetd_enable=YES > > inetd_flags=-l > > named_flags="-S 1000" > > named_chrootdir="" > > rwhod_enable=YES > > sshd_enable=YES > > amd_enable=YES > > amd_flags="-F /etc/amd.conf" > > nfs_client_enable=YES > > nfs_access_cache=2 > > mountd_flags=-n > > rpcbind_enable=YES > > > > ntpdate_enable=YES > > ntpdate_hosts=ntp > > ntpd_enable=YES > > ntpd_flags="-p /var/run/ntpd.pid" > > > > nis_client_enable=YES > > nis_client_flags="-s -S ofw.tld,nis-16-1,nis-16-2" > > nis_server_flags=-n > > nis_yppasswdd_flags="-t /var/yp/src/master.passwd -f -v" > > > > defaultrouter=192.168.16.2 > > > > keyrate=fast > > > > sendmail_flags="-bd -q5m" > > sendmail_submit_flags="$sendmail_flags -ODaemonPortOptions=Addr=localhost" > > sendmail_msp_queue_flags="-Ac -q30m" > > sendmail_rebuild_aliases=NO > > > > lpd_enable=YES > > lpd_flags=-s > > chkprintcap_enable=YES > > dumpdev=AUTO > > clear_tmp_X=NO > > ldconfig_paths=/usr/local/lib > > ldconfig_paths_aout="" > > entropy_file=/boot/entropy-file > > > > > > rc.conf.local: > > -------------- > > hostname=typhon.ofw.tld > > ifconfig_msk0="inet 192.168.24.1/21" > > ifconfig_msk0_alias0="inet 192.168.24.10/32" > > > > named_enable=YES > > nfs_server_enable=YES > > > > nis_client_flags="-s -S ofw.tld,nis-24-1,nis-24-2" > > nis_server_enable=YES > > > > defaultrouter=192.168.24.2 > > > > lpd_flags=-l > > dumpdev=/dev/da1s1b > > quota_enable=YES > > > > > > fstab: > > ------ > > /dev/da0s1a / ufs noatime,rw 0 1 > > /dev/da0s1b none swap sw 0 0 > > proc /proc procfs rw 0 0 > > /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 > > Thank you. Can you show me output from the following? Thanks to you for looking into this... > > * camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus1 target 0 lun 0 (da10,pass2) > * gpart show -p da1 => 63 17849937 da1 MBR (8.5G) 63 17849937 da1s1 freebsd [active] (8.5G) And here is gpart show -p da1s1 => 0 17849937 da1s1 BSD (8.5G) 0 16 - free - (8.0k) 16 599984 da1s1a freebsd-ufs (293M) 600000 2000000 da1s1d freebsd-ufs (976M) 2600000 11000000 da1s1e freebsd-ufs (5.3G) 13600000 4249937 da1s1b freebsd-swap (2.0G) > > I'm pretty sure I see the problem, but I want to be extra sure. I am curious already! -Andre > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 10:30: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 ECF9CF80; Sun, 16 Jun 2013 10:30:23 +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 7863612E9; Sun, 16 Jun 2013 10:30:22 +0000 (UTC) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6943941C054; Sun, 16 Jun 2013 12:30:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fUE9gPA4w9nq; Sun, 16 Jun 2013 12:30:09 +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 4B6BE41C056; Sun, 16 Jun 2013 12:30:09 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6ED4773A1C; Sun, 16 Jun 2013 03:30:07 -0700 (PDT) Date: Sun, 16 Jun 2013 03:30:07 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130616103007.GA19957@icarus.home.lan> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> <20130616065441.GA15175@icarus.home.lan> <20130616080239.GA73100@bali> <20130616084937.GA17277@icarus.home.lan> <20130616095538.GA73648@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130616095538.GA73648@bali> 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, 16 Jun 2013 10:30:24 -0000 On Sun, Jun 16, 2013 at 11:55:38AM +0200, Andre Albsmeier wrote: > On Sun, 16-Jun-2013 at 10:49:37 +0200, Jeremy Chadwick wrote: > > On Sun, Jun 16, 2013 at 10:02:39AM +0200, Andre Albsmeier wrote: > > > On Sun, 16-Jun-2013 at 08:54:41 +0200, Jeremy Chadwick wrote: > > > > On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > > > > > > > > > I'll try to arrange that. It'll take a bit since this > > > > > box is 200 km away... > > > > > > > > > > Maybe I'll find another one nearby to reproduce it... > > > > > > > > SPECIFICALLY regarding "lack of crash dumps": I need to see the > > > > following: > > > > > > > > * cat /etc/rc.conf > > > > * cat /etc/fstab > > > > > > > > I may need output from other commands, but shall deal with that when I > > > > see output from the above. Thanks. > > > > > > No problem, see below... > > > > > > To make a long story short, the machine dumps core perfectly > > > (tested that a while ago), but not when dealing with _this_ > > > issue... > > > > > > I dump on da1s1b and savecore fetches it from there and puts > > > it on /var (sitting on da0), that's faster. > > > > > > rc.conf (beware, rc.conf.local exists): > > > --------------------------------------- > > > rcshutdown_timeout=180 > > > tmpmfs=YES > > > tmpsize="$(( `/sbin/sysctl -n hw.usermem` / 3000000 ))m" > > > tmpmfs_flags="$tmpmfs_flags -v 1 -n" > > > > > > background_fsck=NO > > > > > > nisdomainname=ofw.tld > > > pflog_flags=-S > > > > > > syslogd_flags=-svv > > > inetd_enable=YES > > > inetd_flags=-l > > > named_flags="-S 1000" > > > named_chrootdir="" > > > rwhod_enable=YES > > > sshd_enable=YES > > > amd_enable=YES > > > amd_flags="-F /etc/amd.conf" > > > nfs_client_enable=YES > > > nfs_access_cache=2 > > > mountd_flags=-n > > > rpcbind_enable=YES > > > > > > ntpdate_enable=YES > > > ntpdate_hosts=ntp > > > ntpd_enable=YES > > > ntpd_flags="-p /var/run/ntpd.pid" > > > > > > nis_client_enable=YES > > > nis_client_flags="-s -S ofw.tld,nis-16-1,nis-16-2" > > > nis_server_flags=-n > > > nis_yppasswdd_flags="-t /var/yp/src/master.passwd -f -v" > > > > > > defaultrouter=192.168.16.2 > > > > > > keyrate=fast > > > > > > sendmail_flags="-bd -q5m" > > > sendmail_submit_flags="$sendmail_flags -ODaemonPortOptions=Addr=localhost" > > > sendmail_msp_queue_flags="-Ac -q30m" > > > sendmail_rebuild_aliases=NO > > > > > > lpd_enable=YES > > > lpd_flags=-s > > > chkprintcap_enable=YES > > > dumpdev=AUTO > > > clear_tmp_X=NO > > > ldconfig_paths=/usr/local/lib > > > ldconfig_paths_aout="" > > > entropy_file=/boot/entropy-file > > > > > > > > > rc.conf.local: > > > -------------- > > > hostname=typhon.ofw.tld > > > ifconfig_msk0="inet 192.168.24.1/21" > > > ifconfig_msk0_alias0="inet 192.168.24.10/32" > > > > > > named_enable=YES > > > nfs_server_enable=YES > > > > > > nis_client_flags="-s -S ofw.tld,nis-24-1,nis-24-2" > > > nis_server_enable=YES > > > > > > defaultrouter=192.168.24.2 > > > > > > lpd_flags=-l > > > dumpdev=/dev/da1s1b > > > quota_enable=YES > > > > > > > > > fstab: > > > ------ > > > /dev/da0s1a / ufs noatime,rw 0 1 > > > /dev/da0s1b none swap sw 0 0 > > > proc /proc procfs rw 0 0 > > > /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 > > > > Thank you. Can you show me output from the following? > > Thanks to you for looking into this... > > > > > * camcontrol devlist > > at scbus0 target 0 lun 0 (da0,pass0) > at scbus0 target 1 lun 0 (da1,pass1) > at scbus1 target 0 lun 0 (da10,pass2) > > > * gpart show -p da1 > > => 63 17849937 da1 MBR (8.5G) > 63 17849937 da1s1 freebsd [active] (8.5G) > > And here is gpart show -p da1s1 > > => 0 17849937 da1s1 BSD (8.5G) > 0 16 - free - (8.0k) > 16 599984 da1s1a freebsd-ufs (293M) > 600000 2000000 da1s1d freebsd-ufs (976M) > 2600000 11000000 da1s1e freebsd-ufs (5.3G) > 13600000 4249937 da1s1b freebsd-swap (2.0G) > > > > > I'm pretty sure I see the problem, but I want to be extra sure. > > I am curious already! Okay, theory #1 shot down -- you have a valid da1s1b. I was curious because rc.conf had dumpdev=AUTO, rc.conf.local had dumpdev=/dev/da1s1b, and /etc/fstab made no mention of /dev/da1s1b (as swap). So I was thinking "oh, maybe he meant /dev/da0s1b" -- hence my camcontrol + gpart request. :-) I have 2 more possibilities in mind. Could I get... * Output from: sysctl -a hw | grep mem: * Output from: uname -a (you can hide the machine name if you want) * Output from: strings /boot/kernel/kernel | egrep ^option Thanks. -- | 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 Jun 16 15:11:31 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 C8EF98A8 for ; Sun, 16 Jun 2013 15:11:31 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0131BF3 for ; Sun, 16 Jun 2013 15:11:30 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GFBFl5011872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Jun 2013 17:11:16 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BDD593.5000102@xs4all.nl> Date: Sun, 16 Jun 2013 17:11:15 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Stable Subject: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 15:11:31 -0000 Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server with Intel driver has some issues that make it unusable for me. The new X server and Intel driver works extremely well, so kudos to whoever made this possible. Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the system randomly freezes after [...] syslogd: exiting on signal 15 I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to stop messages, but these never arrive. I paniced the machine in ddb, so I have a crash dump if someone want to look at it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have pasted it here but it is a bit verbose.) Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and ALT_BREAK_TO_DEBUGGER. Who knows what's going on here? Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 15:37: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 5AE1EFCF for ; Sun, 16 Jun 2013 15:37: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 DF73D1CB2 for ; Sun, 16 Jun 2013 15:37:12 +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 r5GFbAp5057007; Sun, 16 Jun 2013 18:37:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5GFbAp5057007 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5GFbALt057006; Sun, 16 Jun 2013 18:37:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Jun 2013 18:37:10 +0300 From: Konstantin Belousov To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130616153710.GT91021@kib.kiev.ua> References: <51BDD593.5000102@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6k8oSBQUGGHRSAt9" Content-Disposition: inline In-Reply-To: <51BDD593.5000102@xs4all.nl> 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 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, 16 Jun 2013 15:37:13 -0000 --6k8oSBQUGGHRSAt9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 16, 2013 at 05:11:15PM +0200, Michiel Boland wrote: > Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X s= erver=20 > with Intel driver has some issues that make it unusable for me. >=20 > The new X server and Intel driver works extremely well, so kudos to whoev= er made=20 > this possible. >=20 > Unfortunately, I am now experiencing random hangs on shutdown. On shutdow= n the=20 > system randomly freezes after >=20 > [...] syslogd: exiting on signal 15 >=20 > I would then expect to see 'Waiting (max 60 seconds) for system process '= XXX' to=20 > stop messages, but these never arrive. >=20 > I paniced the machine in ddb, so I have a crash dump if someone want to l= ook at=20 > it. The crashinfo is at http://barrytown.boland.org/core.txt (I would hav= e=20 > pasted it here but it is a bit verbose.) >=20 > Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, runni= ng=20 > 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DD= B and=20 > ALT_BREAK_TO_DEBUGGER. >=20 > Who knows what's going on here? I do not see anything related to i915 in the core.txt you provided. Next time the machine hangs, start with the output of ps command from ddb and 'show allpcpu', together with 'alltrace'. --6k8oSBQUGGHRSAt9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRvdumAAoJEJDCuSvBvK1BlYUP/RW61Sws1GkwiOpqqmkGZSXH OhThoRbSOun4nWWZ+BJeQrXztbX1EvHyAKx/fvImZImwQ9zYxIWB5nCiKEelEeU4 ddu0xtcRIgz/EL2QqsieOjMAzS20K3vfCulI0LhMt4hA98zrmZ33Z2t3yjIAzGu0 XevCPQUoH2ehACk7hthI1zSWxZr3rPeZaCLE1Chg2ih9YwUdn1Z3Pp8UduYdQy1G wZdiZKf4Z1Fqr8jCwpAV8GN5SRr786W6MKFQtgIHhOH75PvKnxRokrbJo8W7R4s+ i+NmFLq7FlLY4Z+OYsg8TKe9RKy3becWcOd+1duku+OB8meECOB3EngZPgzmFAOY DBhW/VJYcUKfV3/+puOe6H9Ud2WMGFXrLqJLQHdA62kI8AxWkvYzvo6GUQGbwwgG 40rEU+xKCSdIHIT3esHZNazoocgdB46Il0SPBl9f135GtrMHwJB+MnFG6+tkM4R7 IBEsvpTQQz/SpqKSaQPK7KSRHYN1zmeDsTAbdAbS/uqsRVzM3ziY+HKn9DWIZxlW tFQIabfc4zTOYrmTpqqqvhLwhvn6Pp38lbcWfV2jNKKHTE2n4uvoUH5pp03gTVEW jWaBt6uBCH4hDrYUKHEw27nT2Gjd/Hyfc3ZjOKC5eEflhk/sO3YWEPCbpbMte7bR TEtOiYQr20dI3XNTKk/F =PBaG -----END PGP SIGNATURE----- --6k8oSBQUGGHRSAt9-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 15:49:02 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 A0A3B1D9 for ; Sun, 16 Jun 2013 15:49:02 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 0153D1D0B for ; Sun, 16 Jun 2013 15:49:01 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GFmqMQ031371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 17:48:52 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BDDE64.2040801@xs4all.nl> Date: Sun, 16 Jun 2013 17:48:52 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> In-Reply-To: <20130616153710.GT91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 15:49:02 -0000 On 06/16/2013 17:37, Konstantin Belousov wrote: > On Sun, Jun 16, 2013 at 05:11:15PM +0200, Michiel Boland wrote: >> Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server >> with Intel driver has some issues that make it unusable for me. >> >> The new X server and Intel driver works extremely well, so kudos to whoever made >> this possible. >> >> Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the >> system randomly freezes after >> >> [...] syslogd: exiting on signal 15 >> >> I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to >> stop messages, but these never arrive. >> >> I paniced the machine in ddb, so I have a crash dump if someone want to look at >> it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have >> pasted it here but it is a bit verbose.) >> >> Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running >> 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and >> ALT_BREAK_TO_DEBUGGER. >> >> Who knows what's going on here? > > I do not see anything related to i915 in the core.txt you provided. > > Next time the machine hangs, start with the output of ps command from > ddb and 'show allpcpu', together with 'alltrace'. > Ok. I appended 'thread apply all bt' from kgdb to the core.txt, maybe there is something interesting in there. I did notice the following Thread 17 (Thread 100007): #0 cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1392 #1 0xffffffff80cbebbd in ipi_nmi_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1374 #2 0xffffffff80ccc159 in trap (frame=0xffffffff81424890) at /usr/src/sys/amd64/amd64/trap.c:211 #3 0xffffffff80cb55af in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:501 #4 0xffffffff80d0c029 in vga_txtmouse (scp=0xfffffe0005586600, x=320, y=200, on=) at cpufunc.h:186 Previous frame inner to this frame (corrupt stack?) Maybe the hang is caused by the removal of the text mouse cursor? (Just guessing here.) Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 15:55:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 136553EE for ; Sun, 16 Jun 2013 15:55:24 +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 944B91D3C for ; Sun, 16 Jun 2013 15:55:23 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 4377BA80BE; Sun, 16 Jun 2013 17:55:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XmvM4cXnqmEY; Sun, 16 Jun 2013 17:55:04 +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 59738A80B6; Sun, 16 Jun 2013 17:55:04 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 760D773A1C; Sun, 16 Jun 2013 08:55:02 -0700 (PDT) Date: Sun, 16 Jun 2013 08:55:02 -0700 From: Jeremy Chadwick To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130616155502.GA26171@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDDE64.2040801@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BDDE64.2040801@xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , 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, 16 Jun 2013 15:55:24 -0000 On Sun, Jun 16, 2013 at 05:48:52PM +0200, Michiel Boland wrote: > On 06/16/2013 17:37, Konstantin Belousov wrote: > >On Sun, Jun 16, 2013 at 05:11:15PM +0200, Michiel Boland wrote: > >>Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server > >>with Intel driver has some issues that make it unusable for me. > >> > >>The new X server and Intel driver works extremely well, so kudos to whoever made > >>this possible. > >> > >>Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the > >>system randomly freezes after > >> > >>[...] syslogd: exiting on signal 15 > >> > >>I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to > >>stop messages, but these never arrive. > >> > >>I paniced the machine in ddb, so I have a crash dump if someone want to look at > >>it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have > >>pasted it here but it is a bit verbose.) > >> > >>Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running > >>9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and > >>ALT_BREAK_TO_DEBUGGER. > >> > >>Who knows what's going on here? > > > >I do not see anything related to i915 in the core.txt you provided. > > > >Next time the machine hangs, start with the output of ps command from > >ddb and 'show allpcpu', together with 'alltrace'. > > > > Ok. > > I appended 'thread apply all bt' from kgdb to the core.txt, maybe > there is something interesting in there. > > I did notice the following > > Thread 17 (Thread 100007): > #0 cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1392 > #1 0xffffffff80cbebbd in ipi_nmi_handler () at > /usr/src/sys/amd64/amd64/mp_machdep.c:1374 > #2 0xffffffff80ccc159 in trap (frame=0xffffffff81424890) at > /usr/src/sys/amd64/amd64/trap.c:211 > #3 0xffffffff80cb55af in nmi_calltrap () at > /usr/src/sys/amd64/amd64/exception.S:501 > #4 0xffffffff80d0c029 in vga_txtmouse (scp=0xfffffe0005586600, > x=320, y=200, on=) at cpufunc.h:186 > Previous frame inner to this frame (corrupt stack?) > > Maybe the hang is caused by the removal of the text mouse cursor? > (Just guessing here.) vga_txtmouse comes from syscons(4). Are you making use of vidcontrol(1) in any way to set the system console (outside of X) to something that uses the VGA framebuffer? There are probably some loader.conf or rc.conf variables that control this (I do not know). Are you running moused(8)? Actually, I can see quite clearly that you are in your core.txt: Starting ums0 moused. Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) might be involved. -- | 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 Jun 16 16:01:59 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 D99047A4 for ; Sun, 16 Jun 2013 16:01:59 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id 56E4C1D8B for ; Sun, 16 Jun 2013 16:01:58 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GG1nRE034337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 18:01:49 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BDE16D.3080903@xs4all.nl> Date: Sun, 16 Jun 2013 18:01:49 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDDE64.2040801@xs4all.nl> <20130616155502.GA26171@icarus.home.lan> In-Reply-To: <20130616155502.GA26171@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Konstantin Belousov , 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, 16 Jun 2013 16:01:59 -0000 On 06/16/2013 17:55, Jeremy Chadwick wrote: [...] > Are you running moused(8)? Actually, I can see quite clearly that you > are in your core.txt: > > Starting ums0 moused. > > Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) > might be involved. > The moused is started by devd - I don't see a quick way of turning that off. As a workaround I'm trying to run a kernel with options SC_NO_SYSMOUSE to see if the hangs go away. Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 16:08:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C611A1E for ; Sun, 16 Jun 2013 16:08:08 +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 ED4841DD0 for ; Sun, 16 Jun 2013 16:08:07 +0000 (UTC) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id A676541C056; Sun, 16 Jun 2013 18:07:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id d0Zlu2Rr8pVp; Sun, 16 Jun 2013 18:07:54 +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 B772A41C06F; Sun, 16 Jun 2013 18:07:54 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id DC17073A1C; Sun, 16 Jun 2013 09:07:52 -0700 (PDT) Date: Sun, 16 Jun 2013 09:07:52 -0700 From: Jeremy Chadwick To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130616160752.GA26518@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDDE64.2040801@xs4all.nl> <20130616155502.GA26171@icarus.home.lan> <51BDE16D.3080903@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BDE16D.3080903@xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , 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, 16 Jun 2013 16:08:08 -0000 On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote: > On 06/16/2013 17:55, Jeremy Chadwick wrote: > [...] > > >Are you running moused(8)? Actually, I can see quite clearly that you > >are in your core.txt: > > > >Starting ums0 moused. > > > >Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) > >might be involved. > > > > The moused is started by devd - I don't see a quick way of turning that off. Comment out the relevant crap in devd.conf(5). Search for "ums" and comment out the two "notify" sections. > As a workaround I'm trying to run a kernel with > > options SC_NO_SYSMOUSE > > to see if the hangs go away. That's one way to do it, I guess. Be aware that I do not use X, however I have repeatedly seen mentioned on these lists problems/complexities from where people rely on moused(8) to "drive their mouse" while inside of X (or possibly that X and moused(8) are both simultaneously polling the mouse). There's apparently a very specific kind of X configuration you're supposed to use to get proper mouse/keyboard/HAL/HID/whatever support, and tons of people have it wrongt. Warren Block I think has some insights into this, or could maybe help shed some light on what I'm remembering. -- | 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 Jun 16 16:22:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 42A05FC4 for ; Sun, 16 Jun 2013 16:22:08 +0000 (UTC) (envelope-from prvs=1879f9e022=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 D9DF31E3B for ; Sun, 16 Jun 2013 16:22:07 +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 md50004376686.msg for ; Sun, 16 Jun 2013 17:22:00 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 16 Jun 2013 17:22:00 +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=1879f9e022=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <4AC4A120CAD74B398AED326376398E47@multiplay.co.uk> From: "Steven Hartland" To: "Michiel Boland" , "FreeBSD Stable" References: <51BDD593.5000102@xs4all.nl> Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Date: Sun, 16 Jun 2013 17:22:05 +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 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, 16 Jun 2013 16:22:08 -0000 ----- Original Message ----- From: "Michiel Boland" To: "FreeBSD Stable" Sent: Sunday, June 16, 2013 4:11 PM Subject: system sporadically hangs on shutdown after switching to WITH_NEW_XORG > Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server > with Intel driver has some issues that make it unusable for me. > > The new X server and Intel driver works extremely well, so kudos to whoever made > this possible. > > Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the > system randomly freezes after > > [...] syslogd: exiting on signal 15 > > I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to > stop messages, but these never arrive. > > I paniced the machine in ddb, so I have a crash dump if someone want to look at > it. The crashinfo is at http://barrytown.boland.org/core.txt (I would have > pasted it here but it is a bit verbose.) > > Machine has an Intel G41 chipset, with a SAMSUNG SSD 830 Series HD, running > 9.1-STABLE r251803. Serial console. GENERIC kernel, expect for options DDB and > ALT_BREAK_TO_DEBUGGER. > > Who knows what's going on here? Does setting the sysctl: hw.usb.no_shutdown_wait=1 help? 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 Sun Jun 16 17:05: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 18826B51 for ; Sun, 16 Jun 2013 17:05:15 +0000 (UTC) (envelope-from andyf@andyit.com.au) Received: from smtp.syd.comcen.com.au (smtp.syd.comcen.com.au [203.23.236.77]) by mx1.freebsd.org (Postfix) with ESMTP id AC0A21F93 for ; Sun, 16 Jun 2013 17:05:14 +0000 (UTC) Received: from hummer.af.speednet.com.au (115-69-4-237.dyn.comcen.net.au [115.69.4.237]) by smtp.syd.comcen.com.au (8.13.4/8.12.9) with ESMTP id r5GH0sLE052628; Mon, 17 Jun 2013 03:00:55 +1000 (EST) Received: from snuggles.af.speednet.com.au (snuggles.af.speednet.com.au [172.22.2.2]) by hummer.af.speednet.com.au (8.14.5/8.14.5) with ESMTP id r5GH0mrk050236; Mon, 17 Jun 2013 03:00:48 +1000 (EST) (envelope-from andyf@andyit.com.au) Message-ID: <51BDEF40.4060001@andyit.com.au> Date: Mon, 17 Jun 2013 03:00:48 +1000 From: Andy Farkas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120614 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-stable Subject: FreeBSD history Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.3, required 4, AWL -0.40, BAYES_50 0.00, RDNS_DYNAMIC 0.10) X-comcen-MailScanner-From: andyf@andyit.com.au Cc: jdc@koitsu.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, 16 Jun 2013 17:05:15 -0000 On 16/06/13 20:30, Jeremy Chadwick wrote: > * Output from: strings /boot/kernel/kernel | egrep ^option Thanks. I stumbled across this one about a week ago: strings /boot/kernel/kernel | head -1 and was wondering about the history of where it came from / what it means. I can see it was added to Makefile.i386 in September 1998 but the commit comment mentions the defunct alpha port and searching SVN for things in the Attic is a PITA. Also, according to http://svnweb.freebsd.org/base?view=revision&revision=1 FreeBSD is 20 years old! Is not a celebration / announcement warranted? -andyf From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 17:12:43 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 51A40FE3 for ; Sun, 16 Jun 2013 17:12:43 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id E9D21102D for ; Sun, 16 Jun 2013 17:12:42 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GHCX0J045077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 19:12:33 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BDF201.40703@xs4all.nl> Date: Sun, 16 Jun 2013 19:12:33 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> In-Reply-To: <20130616153710.GT91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 17:12:43 -0000 On 06/16/2013 17:37, Konstantin Belousov wrote: [...] > I do not see anything related to i915 in the core.txt you provided. > > Next time the machine hangs, start with the output of ps command from > ddb and 'show allpcpu', together with 'alltrace'. > Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown. I've appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands are from a different session - so the ddb output may not match with the kgdb output.) From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 17:46:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 552F4577 for ; Sun, 16 Jun 2013 17:46:54 +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 BEBDA10D3 for ; Sun, 16 Jun 2013 17:46:53 +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 r5GHkjtm083813; Sun, 16 Jun 2013 20:46:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5GHkjtm083813 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5GHkjRU083812; Sun, 16 Jun 2013 20:46:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Jun 2013 20:46:45 +0300 From: Konstantin Belousov To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130616174645.GY91021@kib.kiev.ua> References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDF201.40703@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PsVWHEfaXyN1A/K4" Content-Disposition: inline In-Reply-To: <51BDF201.40703@xs4all.nl> 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 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, 16 Jun 2013 17:46:54 -0000 --PsVWHEfaXyN1A/K4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 16, 2013 at 07:12:33PM +0200, Michiel Boland wrote: > On 06/16/2013 17:37, Konstantin Belousov wrote: > [...] > > I do not see anything related to i915 in the core.txt you provided. > > > > Next time the machine hangs, start with the output of ps command from > > ddb and 'show allpcpu', together with 'alltrace'. > > >=20 > Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown.= I've=20 > appended it to my core.txt. (See previous e-mail.) (Note that the ddb com= mands=20 > are from a different session - so the ddb output may not match with the k= gdb=20 > output.) >=20 Hm, how do you initiate the shutdown ? Show the exact command. Also, from the same moment of the hung system, enter the ddb and again do ps, alltrace and 'x rebooting'. --PsVWHEfaXyN1A/K4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRvfoEAAoJEJDCuSvBvK1BNJgP/20nIGkUiDjQZyWCavJ04RWX cE//tY5+SIN9uLd7uNZ2cqdCmmOLr8e7TiKp4zTwnACEPYpKAjfsW6sT2/JMPlST QGBAG1nAgwzHJUk/J/m+WiVGqrlO3/BkKKbx6zMKlz1yibIUAzXuljRHgaJ2Hz9O BdeOzI9/LGqase6gOi8X52ArAEFvGcltKJ3aiA1fVsRxZz/m8sXvCPLXtKpmT37U E+4kdroafE13HBSimLWq2ZwK3lNVpPfUb2LOk795va2EpMDCh8ihKedKjdfBk9hK ij+Pb1lVP7C14egVwq5u5/nSueSlBcLnMzgSXkvyJei9yVVipaDOwTZ4raONQ5Is dJ9fT9cnxiUKex+rvAWYBMCZtgVKFNB6bBBbrN5I2G6Mt4lI5Ofq4bZgSx5xmeJc h525VXDqY2UiKRnjlxookPK0q+e5s2Do5CPoqJ2jqn85gKQgq4Styhug0YmiGZoR /35aZM8OD1zG/UBlWFlHViserVYUIHaFPao6jMLLr9MthqNmUIqZiPtI0YREfNhA kFp1IVcy8kzCdq0NOGjK4bExGGhP2WJ2gwAflLLHsP5Yy9mcFZxa2Nqa3gLUnDjF St0gtT6ec9vKjHDI8spP7C2EZuajWJBSw5nDbYYJpQhK/T+RJMha0MspbaF1c9ah QItxdbGrW5zUyb5uO4UD =1feE -----END PGP SIGNATURE----- --PsVWHEfaXyN1A/K4-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 18:06:37 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 A0087C37 for ; Sun, 16 Jun 2013 18:06:37 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id 42AE311AA for ; Sun, 16 Jun 2013 18:06:36 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GI6LXO016769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 20:06:22 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BDFE9D.6040500@xs4all.nl> Date: Sun, 16 Jun 2013 20:06:21 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDF201.40703@xs4all.nl> <20130616174645.GY91021@kib.kiev.ua> In-Reply-To: <20130616174645.GY91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 18:06:37 -0000 On 06/16/2013 19:46, Konstantin Belousov wrote: > On Sun, Jun 16, 2013 at 07:12:33PM +0200, Michiel Boland wrote: >> On 06/16/2013 17:37, Konstantin Belousov wrote: >> [...] >>> I do not see anything related to i915 in the core.txt you provided. >>> >>> Next time the machine hangs, start with the output of ps command from >>> ddb and 'show allpcpu', together with 'alltrace'. >>> >> >> Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown. I've >> appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands >> are from a different session - so the ddb output may not match with the kgdb >> output.) >> > > Hm, how do you initiate the shutdown ? Show the exact command. > Also, from the same moment of the hung system, enter the ddb and > again do ps, alltrace and 'x rebooting'. > The exact command to generate the hangs from which I created the reports was 'shutdown -r now' FWIW - the saved core from the ddb-induced panic has (kgdb) print rebooting $1 = 1 From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 18:08: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 9AC77D46 for ; Sun, 16 Jun 2013 18:08:16 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2337011C4 for ; Sun, 16 Jun 2013 18:08:15 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GI7vni017903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jun 2013 20:08:01 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <51BDFEFD.8090005@boland.org> Date: Sun, 16 Jun 2013 20:07:57 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDF201.40703@xs4all.nl> <20130616174645.GY91021@kib.kiev.ua> <51BDFE9D.6040500@xs4all.nl> In-Reply-To: <51BDFE9D.6040500@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 18:08:16 -0000 On 06/16/2013 20:06, Michiel Boland wrote: > FWIW - the saved core from the ddb-induced panic has > > (kgdb) print rebooting > $1 = 1 > I realised instantly after I sent my message that this is meaningless - so please ignore that. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 18:10:05 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 2E84DE55 for ; Sun, 16 Jun 2013 18:10:05 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id E9C9011DE for ; Sun, 16 Jun 2013 18:10:04 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UoGgO-0004d8-1V; Sun, 16 Jun 2013 17:24:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r5GHO05B028160; Sun, 16 Jun 2013 11:24:00 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+UFWKngv81tFrWKruY/ISI Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Ian Lepore To: Jeremy Chadwick In-Reply-To: <20130616160752.GA26518@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDDE64.2040801@xs4all.nl> <20130616155502.GA26171@icarus.home.lan> <51BDE16D.3080903@xs4all.nl> <20130616160752.GA26518@icarus.home.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Jun 2013 11:24:00 -0600 Message-ID: <1371403440.4485.22.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Michiel Boland , Konstantin Belousov , 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, 16 Jun 2013 18:10:05 -0000 On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote: > On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote: > > On 06/16/2013 17:55, Jeremy Chadwick wrote: > > [...] > > > > >Are you running moused(8)? Actually, I can see quite clearly that you > > >are in your core.txt: > > > > > >Starting ums0 moused. > > > > > >Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) > > >might be involved. > > > > > > > The moused is started by devd - I don't see a quick way of turning that off. > > Comment out the relevant crap in devd.conf(5). Search for "ums" > and comment out the two "notify" sections. I don't understand why people treat devd as if it's some sort of evil virus that they're forced to live with (using phrases like "crap in devd.conf"). In general, the standard devd rules tend to fall into 3 categories: * use logger(1) to record some anomaly * kldload a module * invoke a standard /etc/rc.d script For moused, the devd rules invoke /etc/rc.d/moused, which implies that setting moused_enable=NO in rc.conf would be all that's needed to disable it. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 18:11:59 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 7DFBA10B for ; Sun, 16 Jun 2013 18:11:59 +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 1C3401218 for ; Sun, 16 Jun 2013 18:11:58 +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 r5GIBvBP088950; Sun, 16 Jun 2013 21:11:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5GIBvBP088950 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5GIBvEm088949; Sun, 16 Jun 2013 21:11:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Jun 2013 21:11:57 +0300 From: Konstantin Belousov To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130616181157.GZ91021@kib.kiev.ua> References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDF201.40703@xs4all.nl> <20130616174645.GY91021@kib.kiev.ua> <51BDFE9D.6040500@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P6d3k5Edf9pZm0D3" Content-Disposition: inline In-Reply-To: <51BDFE9D.6040500@xs4all.nl> 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 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, 16 Jun 2013 18:11:59 -0000 --P6d3k5Edf9pZm0D3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 16, 2013 at 08:06:21PM +0200, Michiel Boland wrote: > On 06/16/2013 19:46, Konstantin Belousov wrote: > > On Sun, Jun 16, 2013 at 07:12:33PM +0200, Michiel Boland wrote: > >> On 06/16/2013 17:37, Konstantin Belousov wrote: > >> [...] > >>> I do not see anything related to i915 in the core.txt you provided. > >>> > >>> Next time the machine hangs, start with the output of ps command from > >>> ddb and 'show allpcpu', together with 'alltrace'. > >>> > >> > >> Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdo= wn. I've > >> appended it to my core.txt. (See previous e-mail.) (Note that the ddb = commands > >> are from a different session - so the ddb output may not match with th= e kgdb > >> output.) > >> > > > > Hm, how do you initiate the shutdown ? Show the exact command. > > Also, from the same moment of the hung system, enter the ddb and > > again do ps, alltrace and 'x rebooting'. > > >=20 > The exact command to generate the hangs from which I created the reports = was >=20 > 'shutdown -r now' >=20 > FWIW - the saved core from the ddb-induced panic has >=20 > (kgdb) print rebooting > $1 =3D 1 I explicitely asked you to provide me with the consistent ps/alltrace and 'x rebooting' output. What you did is useless. In the ddb trace you appended, there is no thread which executes the reboot(2) system call. --P6d3k5Edf9pZm0D3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRvf/sAAoJEJDCuSvBvK1BZxoP/1JZjewWXbm/LihWzPOontc8 ojRpl/l1kdUga6LT37QhpR+nlVtCaWCVPePc+WH/jPaenkI9uIcSs2nrsJLn81F7 vHsiq8k636wm24m4DMGrt6SmoNPD4gf6GdkH7nPXqzC/irU6BqlKk4nOOXN8EIIX ZPI6rKy4aEQ2dlklBXE/rDIkD/qh8rBC8omoR0jTWTE8d39PqHJCgcCLqzffS9Q5 i81rAQrnFJto9tPqY98TLEgIu6jB3QtajhkSXkMgaZCXrMOG/3WymXDkzz7Z1/bP suYAPdr5uwiguc46vFWBiirn3lLjGKnAsxjgCUmWss1v8maT66KnIS4Kgq+nkMow fVkZuQ6UT0mWrywXC1aaHYL7H+6DPs1WaUe6CIfOdemJiPMQkXa8BlVQZEWZsEhU OrVvJ1Ae5AK+iNviXqUYBQKYvR0UKsEEcmGVgEPIgR0CUBMa24mgf9o85OQ+RIi6 603CW956kWK9thze8bRghlSnf9lyrUvDqOpU0ouPZIH/tmmITPH54uHudIInchqC SPx+BMGBCcl3jMlAlNv+xz7LN4mxzVRAwQ1QNsnmb/ltUQ3scH4GbFXm4Y/IDhgr R9OW5zZeoFf6lDCbGQDttQPEXxLqm/kYpdLD3la0RUPzPrkvVaCwqc1okkQreWr7 bYX4Hpz7nylr0PpNmRF1 =29K9 -----END PGP SIGNATURE----- --P6d3k5Edf9pZm0D3-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 16 18:31: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 58C8783F for ; Sun, 16 Jun 2013 18:31:36 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id D604112C6 for ; Sun, 16 Jun 2013 18:31:35 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5GIVPJY030264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 16 Jun 2013 20:31:26 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <51BE047D.2000405@boland.org> Date: Sun, 16 Jun 2013 20:31:25 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDF201.40703@xs4all.nl> <20130616174645.GY91021@kib.kiev.ua> <51BDFE9D.6040500@xs4all.nl> <51BDFEFD.8090005@boland.org> In-Reply-To: <51BDFEFD.8090005@boland.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 16 Jun 2013 18:31:36 -0000 So apparently the value of 'rebooting' is 0 at the time of the hang... db> x rebooting rebooting: 0 From owner-freebsd-stable@FreeBSD.ORG Mon Jun 17 11:06:52 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 8E7271FC for ; Mon, 17 Jun 2013 11:06:52 +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 661FE1C20 for ; Mon, 17 Jun 2013 11:06:52 +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 r5HB6qx6012875 for ; Mon, 17 Jun 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5HB6pTX012873 for freebsd-stable@FreeBSD.org; Mon, 17 Jun 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Jun 2013 11:06:51 GMT Message-Id: <201306171106.r5HB6pTX012873@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, 17 Jun 2013 11:06:52 -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 Jun 17 11:39: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 4ECA03E4 for ; Mon, 17 Jun 2013 11:39:23 +0000 (UTC) (envelope-from philipp.maechler@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [IPv6:2a00:d70:0:a::e0]) by mx1.freebsd.org (Postfix) with ESMTP id 15C081EFF for ; Mon, 17 Jun 2013 11:39:23 +0000 (UTC) Received: from [2001:1620:2013:1:b1d0:f4d7:d148:f6a2] (port=55139 helo=Philipps-MacBook-Pro.local) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UoXmM-0005Xe-9o for freebsd-stable@freebsd.org; Mon, 17 Jun 2013 13:39:22 +0200 Message-ID: <51BEF56F.4020800@hostpoint.ch> Date: Mon, 17 Jun 2013 13:39:27 +0200 From: Philipp Maechler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: HP Blade Gen 7 and 8 IO stall with ciss driver 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: Mon, 17 Jun 2013 11:39:23 -0000 hello Since a while we're experiencing completely I/O stalls / stopps with some HP Blade Hardware and FreeBDS 9.1. If it occurs, we have to power cycle the server to recover. The stalls occur only every few days to weeks, so it's difficult to reproduce them; we also tried to do a lot of I/O (e.g. scrubbing nonstop) but this didn't help to reproduce more often; taking load away from the productive machines helped them to reduce the frequency stalls further, but is not a solution. We figured out, that it's probably not a zfs relevated problem, because also any dd to the swap partitions stopp's. At the moment we are investigating and try different settings for the ciss driver like set to SIMPLE Mode instead of PERFORMANCE Mode and next maybe we change the heartbeat-Settings, even we DON'T see any normally mentioned error messages on the console or in the remote logs. Our main question: does anybody have similar experiences? Maybe on hp supported os? With best regards, Philipp Maechler Some more information: I/O Stall: The only solution to resolve the state is to "powercycle" the server. Any network traffic or processing stuff also like entering kernel debugger is possible, but shows only full I/O Queues... reproducing: scrubbing nonstop helps, but does result in a stall every week instead of every 4 weeks... so nothing like 'next hour'. Hardware: G7: hp blade BL465cG7: hp smart array p410i G8: hp blade BL465cG8: hp smart array P220i ciss0: port 0x4000-0x40ff mem 0xfdd00000-0xfddfffff,0xfdcf0000-0xfdcf03ff irq 44 at device 0.0 on pci3 ciss0: PERFORMANT Transport On all systems, we are already on the latest bios and firmware releases on controller's (G8: Raid Controller Firmware 3.54) . FreeBSD: 9.1-RELEASE-p3 / we also tried kind of a backport of some patches to ciss from head, didn't change anything. * driver: ciss We didn't try stuff like FB 8.3 because we'd like to have userland dtrace and it's lot of work for transferring productive systems to that - maybe we will have to in future. So the only question now: Is somebody else experiencing similar issues? Maybe on hp support os? -- Hostpoint AG | The Data Residence | St. Dionysstrasse 31 | Postfach | CH-8640 Rapperswil-Jona Tel +41 844 800777 | Fax +41 844 090909 | http://www.hostpoint.ch From owner-freebsd-stable@FreeBSD.ORG Mon Jun 17 13:25:50 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 8BF4A2D9; Mon, 17 Jun 2013 13:25:50 +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 F0DDD1693; Mon, 17 Jun 2013 13:25:49 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r5HD5YXb002947; Mon, 17 Jun 2013 15:05:34 +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 r5HD5YcQ015444; Mon, 17 Jun 2013 15:05:34 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r5HD5YEX098414; Date: Mon, 17 Jun 2013 15:05:34 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130617130534.GA88058@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130531172523.GA9188@bali> <20130616065441.GA15175@icarus.home.lan> <20130616080239.GA73100@bali> <20130616084937.GA17277@icarus.home.lan> <20130616095538.GA73648@bali> <20130616103007.GA19957@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130616103007.GA19957@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: "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, 17 Jun 2013 13:25:50 -0000 On Sun, 16-Jun-2013 at 12:30:07 +0200, Jeremy Chadwick wrote: > On Sun, Jun 16, 2013 at 11:55:38AM +0200, Andre Albsmeier wrote: > > On Sun, 16-Jun-2013 at 10:49:37 +0200, Jeremy Chadwick wrote: > > > On Sun, Jun 16, 2013 at 10:02:39AM +0200, Andre Albsmeier wrote: > > > > On Sun, 16-Jun-2013 at 08:54:41 +0200, Jeremy Chadwick wrote: > > > > > On Fri, May 31, 2013 at 07:25:23PM +0200, 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? > > > > > > > > > > > > I'll try to arrange that. It'll take a bit since this > > > > > > box is 200 km away... > > > > > > > > > > > > Maybe I'll find another one nearby to reproduce it... > > > > > > > > > > SPECIFICALLY regarding "lack of crash dumps": I need to see the > > > > > following: > > > > > > > > > > * cat /etc/rc.conf > > > > > * cat /etc/fstab > > > > > > > > > > I may need output from other commands, but shall deal with that when I > > > > > see output from the above. Thanks. > > > > > > > > No problem, see below... > > > > > > > > To make a long story short, the machine dumps core perfectly > > > > (tested that a while ago), but not when dealing with _this_ > > > > issue... > > > > > > > > I dump on da1s1b and savecore fetches it from there and puts > > > > it on /var (sitting on da0), that's faster. > > > > > > > > rc.conf (beware, rc.conf.local exists): > > > > --------------------------------------- > > > > rcshutdown_timeout=180 > > > > tmpmfs=YES > > > > tmpsize="$(( `/sbin/sysctl -n hw.usermem` / 3000000 ))m" > > > > tmpmfs_flags="$tmpmfs_flags -v 1 -n" > > > > > > > > background_fsck=NO > > > > > > > > nisdomainname=ofw.tld > > > > pflog_flags=-S > > > > > > > > syslogd_flags=-svv > > > > inetd_enable=YES > > > > inetd_flags=-l > > > > named_flags="-S 1000" > > > > named_chrootdir="" > > > > rwhod_enable=YES > > > > sshd_enable=YES > > > > amd_enable=YES > > > > amd_flags="-F /etc/amd.conf" > > > > nfs_client_enable=YES > > > > nfs_access_cache=2 > > > > mountd_flags=-n > > > > rpcbind_enable=YES > > > > > > > > ntpdate_enable=YES > > > > ntpdate_hosts=ntp > > > > ntpd_enable=YES > > > > ntpd_flags="-p /var/run/ntpd.pid" > > > > > > > > nis_client_enable=YES > > > > nis_client_flags="-s -S ofw.tld,nis-16-1,nis-16-2" > > > > nis_server_flags=-n > > > > nis_yppasswdd_flags="-t /var/yp/src/master.passwd -f -v" > > > > > > > > defaultrouter=192.168.16.2 > > > > > > > > keyrate=fast > > > > > > > > sendmail_flags="-bd -q5m" > > > > sendmail_submit_flags="$sendmail_flags -ODaemonPortOptions=Addr=localhost" > > > > sendmail_msp_queue_flags="-Ac -q30m" > > > > sendmail_rebuild_aliases=NO > > > > > > > > lpd_enable=YES > > > > lpd_flags=-s > > > > chkprintcap_enable=YES > > > > dumpdev=AUTO > > > > clear_tmp_X=NO > > > > ldconfig_paths=/usr/local/lib > > > > ldconfig_paths_aout="" > > > > entropy_file=/boot/entropy-file > > > > > > > > > > > > rc.conf.local: > > > > -------------- > > > > hostname=typhon.ofw.tld > > > > ifconfig_msk0="inet 192.168.24.1/21" > > > > ifconfig_msk0_alias0="inet 192.168.24.10/32" > > > > > > > > named_enable=YES > > > > nfs_server_enable=YES > > > > > > > > nis_client_flags="-s -S ofw.tld,nis-24-1,nis-24-2" > > > > nis_server_enable=YES > > > > > > > > defaultrouter=192.168.24.2 > > > > > > > > lpd_flags=-l > > > > dumpdev=/dev/da1s1b > > > > quota_enable=YES > > > > > > > > > > > > fstab: > > > > ------ > > > > /dev/da0s1a / ufs noatime,rw 0 1 > > > > /dev/da0s1b none swap sw 0 0 > > > > proc /proc procfs rw 0 0 > > > > /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 > > > > > > Thank you. Can you show me output from the following? > > > > Thanks to you for looking into this... > > > > > > > > * camcontrol devlist > > > > at scbus0 target 0 lun 0 (da0,pass0) > > at scbus0 target 1 lun 0 (da1,pass1) > > at scbus1 target 0 lun 0 (da10,pass2) > > > > > * gpart show -p da1 > > > > => 63 17849937 da1 MBR (8.5G) > > 63 17849937 da1s1 freebsd [active] (8.5G) > > > > And here is gpart show -p da1s1 > > > > => 0 17849937 da1s1 BSD (8.5G) > > 0 16 - free - (8.0k) > > 16 599984 da1s1a freebsd-ufs (293M) > > 600000 2000000 da1s1d freebsd-ufs (976M) > > 2600000 11000000 da1s1e freebsd-ufs (5.3G) > > 13600000 4249937 da1s1b freebsd-swap (2.0G) > > > > > > > > I'm pretty sure I see the problem, but I want to be extra sure. > > > > I am curious already! > > Okay, theory #1 shot down -- you have a valid da1s1b. I was curious > because rc.conf had dumpdev=AUTO, rc.conf.local had dumpdev=/dev/da1s1b, > and /etc/fstab made no mention of /dev/da1s1b (as swap). So I was > thinking "oh, maybe he meant /dev/da0s1b" -- hence my camcontrol + gpart > request. :-) > > I have 2 more possibilities in mind. Could I get... I know now why it didn't dump: I use two disks da0 and da1. da1 is a copy of da0 so people can simply unplug da0 in case of problems and work with da1 (which becomes da0 then). Since da1 is normally unused, I automatically spin it down after booting. For some reason, the drive does not start when FreeBSD-9 wants to dump on it. If I start it manually, dumping will work. Or if I use FreeBSD-7 it works as well. Something must have changed between 7 and 9 here... Anyway, I will configure my FreeBSD-9 machines to dump on da0 so maybe we'll get a crash dump finally... -Andre > > * Output from: sysctl -a hw | grep mem: > > * Output from: uname -a (you can hide the machine name if you want) > > * Output from: strings /boot/kernel/kernel | egrep ^option > > Thanks. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > -- A fool with a tool is still a fool. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 17 19:17: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 EA1CB4D7 for ; Mon, 17 Jun 2013 19:17:13 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8D30D19E8 for ; Mon, 17 Jun 2013 19:17:12 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5HJGvIr088547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jun 2013 21:16:57 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51BF60A8.6000503@xs4all.nl> Date: Mon, 17 Jun 2013 21:16:56 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Stable Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> In-Reply-To: <51BDD593.5000102@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 17 Jun 2013 19:17:14 -0000 On 06/16/2013 17:11, Michiel Boland wrote: > Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server > with Intel driver has some issues that make it unusable for me. > > The new X server and Intel driver works extremely well, so kudos to whoever made > this possible. > > Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the > system randomly freezes after > > [...] syslogd: exiting on signal 15 > > I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to > stop messages, but these never arrive. So it turns out that init hangs because vga_txtmouse (draw_txtmouse in fact) is hogging the clock swi. The routine is waiting for a vertical retrace which never arrives. (The new intel driver can't return to text console, so the screen just goes blank when X exits.) Some workarounds: - don't run moused (i.e. disable it in rc.conf and devd.conf) instead run the X server in combination with hald - do run moused, but then either - unplug the mouse before shutting down - build a kernel with VGA_NO_FONT_LOADING Of course the long-term fix is to remove the possibly infinite loop in draw_txtmouse. Thanks to Konstantin for his patience in helping me track this down. Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Mon Jun 17 19:31:00 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 79BA4E42 for ; Mon, 17 Jun 2013 19:31:00 +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 568401AB0 for ; Mon, 17 Jun 2013 19:31:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB456B953; Mon, 17 Jun 2013 15:30:59 -0400 (EDT) From: John Baldwin To: Andre Albsmeier Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Date: Mon, 17 Jun 2013 15:30:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> In-Reply-To: <20130616063942.GA72803@bali> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306171530.31208.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Jun 2013 15:30:59 -0400 (EDT) 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, 17 Jun 2013 19:31:00 -0000 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. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jun 17 19:37:30 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 CF41E442 for ; Mon, 17 Jun 2013 19:37:30 +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 2BFB31AF6 for ; Mon, 17 Jun 2013 19:37:29 +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 r5HJbQdb018758; Mon, 17 Jun 2013 22:37:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r5HJbQdb018758 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r5HJbQwI018757; Mon, 17 Jun 2013 22:37:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Jun 2013 22:37:26 +0300 From: Konstantin Belousov To: Michiel Boland Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130617193726.GR91021@kib.kiev.ua> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w2Q1kmhlT73y7Um/" Content-Disposition: inline In-Reply-To: <51BF60A8.6000503@xs4all.nl> 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 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, 17 Jun 2013 19:37:30 -0000 --w2Q1kmhlT73y7Um/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 17, 2013 at 09:16:56PM +0200, Michiel Boland wrote: > On 06/16/2013 17:11, Michiel Boland wrote: > > Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X= server > > with Intel driver has some issues that make it unusable for me. > > > > The new X server and Intel driver works extremely well, so kudos to who= ever made > > this possible. > > > > Unfortunately, I am now experiencing random hangs on shutdown. On shutd= own the > > system randomly freezes after > > > > [...] syslogd: exiting on signal 15 > > > > I would then expect to see 'Waiting (max 60 seconds) for system process= 'XXX' to > > stop messages, but these never arrive. >=20 > So it turns out that init hangs because vga_txtmouse (draw_txtmouse in fa= ct) is=20 > hogging the clock swi. The routine is waiting for a vertical retrace whic= h never=20 > arrives. (The new intel driver can't return to text console, so the scree= n just=20 > goes blank when X exits.) >=20 > Some workarounds: >=20 > - don't run moused (i.e. disable it in rc.conf and devd.conf) > instead run the X server in combination with hald >=20 > - do run moused, but then either >=20 > - unplug the mouse before shutting down >=20 > - build a kernel with VGA_NO_FONT_LOADING >=20 > Of course the long-term fix is to remove the possibly infinite loop in=20 > draw_txtmouse. >=20 > Thanks to Konstantin for his patience in helping me track this down. The following patch, although a hack, should fix the issue. Michiel tested it. diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c index 3cb3b78..e41a49f 100644 --- a/sys/dev/drm2/i915/intel_fb.c +++ b/sys/dev/drm2/i915/intel_fb.c @@ -207,6 +207,8 @@ static void intel_fbdev_destroy(struct drm_device *dev, } } =20 +extern int sc_txtmouse_no_retrace_wait; + int intel_fbdev_init(struct drm_device *dev) { struct intel_fbdev *ifbdev; @@ -229,6 +231,7 @@ int intel_fbdev_init(struct drm_device *dev) =20 drm_fb_helper_single_add_all_connectors(&ifbdev->helper); drm_fb_helper_initial_config(&ifbdev->helper, 32); + sc_txtmouse_no_retrace_wait =3D 1; return 0; } =20 diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c index 6e6663c..fc7f02f 100644 --- a/sys/dev/syscons/scvgarndr.c +++ b/sys/dev/syscons/scvgarndr.c @@ -395,6 +395,8 @@ vga_txtblink(scr_stat *scp, int at, int flip) { } =20 +int sc_txtmouse_no_retrace_wait; + #ifndef SC_NO_CUTPASTE =20 static void @@ -445,7 +447,9 @@ draw_txtmouse(scr_stat *scp, int x, int y) #if 1 /* wait for vertical retrace to avoid jitter on some videocards */ crtc_addr =3D scp->sc->adp->va_crtc_addr; - while (!(inb(crtc_addr + 6) & 0x08)) /* idle */ ; + while (!sc_txtmouse_no_retrace_wait && + !(inb(crtc_addr + 6) & 0x08)) + /* idle */ ; #endif c =3D scp->sc->mouse_char; vidd_load_font(scp->sc->adp, 0, 32, 8, font_buf, c, 4);=20 --w2Q1kmhlT73y7Um/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRv2V2AAoJEJDCuSvBvK1BnoYP/jpuSewCk+00USw6beL6CquJ /0Eug9CHqR2UTp+Yzc16acLYLLHMzHub3aAPErZg5SBm1YbciCHA4/5AGiAf8G0V hoouxWW8yki2MgGNeq5Op3sIjVHZBSuXYPIOOHi9clVhcHj0QLsX9ii0LTmlste+ Fa8KQyIjXAqQb/5YU5BuqNExagVmtm7FHxNtrcrqFnEZ1lNds8NoUxPP3roXCkx3 C4GtAanXk6e6Lx+ChuN8T66kXCyR89B05i5Vb4CToko2oc1WPvjgBxLguv5kMis6 NAGJZlwE0WoYkB9KGnqbg4kk12jih9JPe1rBw9hypg5gYoeNdaqqNHpQgl007wWu xYQMgXnXxR4lwfQKqGjGMlCUsYo/XlYlaxbo8o1213GxHqMX16gYaKR3VZFYmdAZ cauwsFZ7koUpgF6EfNHh4U3kHPqQlRle8P4rMV4ug++u9DanUjyRKMU8K7YC9nX7 kjMhzDrflM8iAHqQqOW4QCJ29bvt3nzu+u5DknPagU6VB3P7TKvDGz8FdqJWpDlk ts65MP5uEtX0zRw5l1EXGWZxMN09sVETtaRf1OiIi3ktuJwUD8RA1eOyVhIGWzro ZYS8hjNuLSO5I73z86w7XoRZvbW0eeeq3XyAPq63Cig5K5KDLSOsHF7DlvEOp2Fy bhissJ6cJUO7y6kw/T6Q =8GIf -----END PGP SIGNATURE----- --w2Q1kmhlT73y7Um/-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 05:28: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 CDCCA787; Tue, 18 Jun 2013 05:28:00 +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 66255191B; Tue, 18 Jun 2013 05:27:59 +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 r5I5RwTq017760; Tue, 18 Jun 2013 07:27:58 +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 r5I5RwnA014782; Tue, 18 Jun 2013 07:27:58 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.7/8.14.7) id r5I5RwRA001445; Date: Tue, 18 Jun 2013 07:27:58 +0200 From: Andre Albsmeier To: John Baldwin Subject: Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found Message-ID: <20130618052758.GA1467@bali> References: <20130531122611.GA6607@bali> <201305311051.03157.jhb@freebsd.org> <20130616063942.GA72803@bali> <201306171530.31208.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306171530.31208.jhb@freebsd.org> 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" 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, 18 Jun 2013 05:28:00 -0000 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. As described yesterday, I think I know why we don't get dumps: I dump on da1 and da1 is spun down. On FreeBSD-7 da1 started automatically in this case, on FreeBSD-9 it doesn't. I now dump on da0 which is running already... My suggestion is that I will try to get a dump now -- however, I have to arrange it with people using the machine. I'll come back when I have a dump ready... Thanks, -Andre > > -- > John Baldwin -- Win98: useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 06:06:18 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 273C8E6A; Tue, 18 Jun 2013 06:06:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id E37CD1A31; Tue, 18 Jun 2013 06:06:17 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I66GQh040093; Tue, 18 Jun 2013 06:06:16 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I66GAl040066; Tue, 18 Jun 2013 06:06:16 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 06:06:16 GMT Message-Id: <201306180606.r5I66GAl040066@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:06:18 -0000 TB --- 2013-06-18 03:05:14 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 03:05:14 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 03:05:14 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2013-06-18 03:05:14 - cleaning the object tree TB --- 2013-06-18 03:05:14 - /usr/local/bin/svn stat /src TB --- 2013-06-18 03:05:19 - At svn revision 251887 TB --- 2013-06-18 03:05:20 - building world TB --- 2013-06-18 03:05:20 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 03:05:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 03:05:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 03:05:20 - SRCCONF=/dev/null TB --- 2013-06-18 03:05:20 - TARGET=pc98 TB --- 2013-06-18 03:05:20 - TARGET_ARCH=i386 TB --- 2013-06-18 03:05:20 - TZ=UTC TB --- 2013-06-18 03:05:20 - __MAKE_CONF=/dev/null TB --- 2013-06-18 03:05:20 - cd /src TB --- 2013-06-18 03:05:20 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 03:05:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 06:00:06 UTC 2013 TB --- 2013-06-18 06:00:06 - generating LINT kernel config TB --- 2013-06-18 06:00:06 - cd /src/sys/pc98/conf TB --- 2013-06-18 06:00:06 - /usr/bin/make -B LINT TB --- 2013-06-18 06:00:06 - cd /src/sys/pc98/conf TB --- 2013-06-18 06:00:06 - /usr/sbin/config -m LINT TB --- 2013-06-18 06:00:06 - building LINT kernel TB --- 2013-06-18 06:00:06 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 06:00:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 06:00:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 06:00:06 - SRCCONF=/dev/null TB --- 2013-06-18 06:00:06 - TARGET=pc98 TB --- 2013-06-18 06:00:06 - TARGET_ARCH=i386 TB --- 2013-06-18 06:00:06 - TZ=UTC TB --- 2013-06-18 06:00:06 - __MAKE_CONF=/dev/null TB --- 2013-06-18 06:00:06 - cd /src TB --- 2013-06-18 06:00:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 06:00:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ale/if_ale.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 06:06:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 06:06:16 - ERROR: failed to build LINT kernel TB --- 2013-06-18 06:06:16 - 8300.59 user 919.64 system 10861.96 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 06:07:07 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 C611DF87; Tue, 18 Jun 2013 06:07:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5571A47; Tue, 18 Jun 2013 06:07:07 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I677bZ045569; Tue, 18 Jun 2013 06:07:07 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I677ct045566; Tue, 18 Jun 2013 06:07:07 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 06:07:07 GMT Message-Id: <201306180607.r5I677ct045566@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:07:07 -0000 TB --- 2013-06-18 03:05:14 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 03:05:14 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 03:05:14 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-06-18 03:05:14 - cleaning the object tree TB --- 2013-06-18 03:05:14 - /usr/local/bin/svn stat /src TB --- 2013-06-18 03:05:19 - At svn revision 251887 TB --- 2013-06-18 03:05:20 - building world TB --- 2013-06-18 03:05:20 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 03:05:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 03:05:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 03:05:20 - SRCCONF=/dev/null TB --- 2013-06-18 03:05:20 - TARGET=i386 TB --- 2013-06-18 03:05:20 - TARGET_ARCH=i386 TB --- 2013-06-18 03:05:20 - TZ=UTC TB --- 2013-06-18 03:05:20 - __MAKE_CONF=/dev/null TB --- 2013-06-18 03:05:20 - cd /src TB --- 2013-06-18 03:05:20 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 03:05:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 06:00:06 UTC 2013 TB --- 2013-06-18 06:00:06 - generating LINT kernel config TB --- 2013-06-18 06:00:06 - cd /src/sys/i386/conf TB --- 2013-06-18 06:00:06 - /usr/bin/make -B LINT TB --- 2013-06-18 06:00:06 - cd /src/sys/i386/conf TB --- 2013-06-18 06:00:06 - /usr/sbin/config -m LINT TB --- 2013-06-18 06:00:06 - building LINT kernel TB --- 2013-06-18 06:00:06 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 06:00:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 06:00:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 06:00:06 - SRCCONF=/dev/null TB --- 2013-06-18 06:00:06 - TARGET=i386 TB --- 2013-06-18 06:00:06 - TARGET_ARCH=i386 TB --- 2013-06-18 06:00:06 - TZ=UTC TB --- 2013-06-18 06:00:06 - __MAKE_CONF=/dev/null TB --- 2013-06-18 06:00:06 - cd /src TB --- 2013-06-18 06:00:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 06:00:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ale/if_ale.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 06:07:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 06:07:07 - ERROR: failed to build LINT kernel TB --- 2013-06-18 06:07:07 - 8392.74 user 916.47 system 10912.68 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 06:45:08 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 9C2A6804; Tue, 18 Jun 2013 06:45:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 654821B96; Tue, 18 Jun 2013 06:45:08 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I6j7jk037227; Tue, 18 Jun 2013 06:45:07 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I6j7NQ037224; Tue, 18 Jun 2013 06:45:07 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 06:45:07 GMT Message-Id: <201306180645.r5I6j7NQ037224@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:45:08 -0000 TB --- 2013-06-18 03:05:14 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 03:05:14 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 03:05:14 - starting RELENG_9 tinderbox run for amd64/amd64 TB --- 2013-06-18 03:05:14 - cleaning the object tree TB --- 2013-06-18 03:05:14 - /usr/local/bin/svn stat /src TB --- 2013-06-18 03:05:19 - At svn revision 251887 TB --- 2013-06-18 03:05:20 - building world TB --- 2013-06-18 03:05:20 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 03:05:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 03:05:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 03:05:20 - SRCCONF=/dev/null TB --- 2013-06-18 03:05:20 - TARGET=amd64 TB --- 2013-06-18 03:05:20 - TARGET_ARCH=amd64 TB --- 2013-06-18 03:05:20 - TZ=UTC TB --- 2013-06-18 03:05:20 - __MAKE_CONF=/dev/null TB --- 2013-06-18 03:05:20 - cd /src TB --- 2013-06-18 03:05:20 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 03:05:21 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jun 18 06:37:35 UTC 2013 TB --- 2013-06-18 06:37:35 - generating LINT kernel config TB --- 2013-06-18 06:37:35 - cd /src/sys/amd64/conf TB --- 2013-06-18 06:37:35 - /usr/bin/make -B LINT TB --- 2013-06-18 06:37:35 - cd /src/sys/amd64/conf TB --- 2013-06-18 06:37:35 - /usr/sbin/config -m LINT TB --- 2013-06-18 06:37:35 - building LINT kernel TB --- 2013-06-18 06:37:35 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 06:37:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 06:37:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 06:37:35 - SRCCONF=/dev/null TB --- 2013-06-18 06:37:35 - TARGET=amd64 TB --- 2013-06-18 06:37:35 - TARGET_ARCH=amd64 TB --- 2013-06-18 06:37:35 - TZ=UTC TB --- 2013-06-18 06:37:35 - __MAKE_CONF=/dev/null TB --- 2013-06-18 06:37:35 - cd /src TB --- 2013-06-18 06:37:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 06:37:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ale/if_ale.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 06:45:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 06:45:07 - ERROR: failed to build LINT kernel TB --- 2013-06-18 06:45:07 - 9910.51 user 1220.15 system 13193.48 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 08:00:31 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 617DEFBB; Tue, 18 Jun 2013 08:00:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0991305; Tue, 18 Jun 2013 08:00:31 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I80U0O079022; Tue, 18 Jun 2013 08:00:30 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I80UKZ079017; Tue, 18 Jun 2013 08:00:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 08:00:30 GMT Message-Id: <201306180800.r5I80UKZ079017@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 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: Tue, 18 Jun 2013 08:00:31 -0000 TB --- 2013-06-18 06:06:17 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 06:06:17 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 06:06:17 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-06-18 06:06:17 - cleaning the object tree TB --- 2013-06-18 06:06:17 - /usr/local/bin/svn stat /src TB --- 2013-06-18 06:06:34 - At svn revision 251887 TB --- 2013-06-18 06:06:35 - building world TB --- 2013-06-18 06:06:35 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 06:06:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 06:06:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 06:06:35 - SRCCONF=/dev/null TB --- 2013-06-18 06:06:35 - TARGET=ia64 TB --- 2013-06-18 06:06:35 - TARGET_ARCH=ia64 TB --- 2013-06-18 06:06:35 - TZ=UTC TB --- 2013-06-18 06:06:35 - __MAKE_CONF=/dev/null TB --- 2013-06-18 06:06:35 - cd /src TB --- 2013-06-18 06:06:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 06:06:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 07:52:44 UTC 2013 TB --- 2013-06-18 07:52:44 - generating LINT kernel config TB --- 2013-06-18 07:52:44 - cd /src/sys/ia64/conf TB --- 2013-06-18 07:52:44 - /usr/bin/make -B LINT TB --- 2013-06-18 07:52:44 - cd /src/sys/ia64/conf TB --- 2013-06-18 07:52:44 - /usr/sbin/config -m LINT TB --- 2013-06-18 07:52:44 - building LINT kernel TB --- 2013-06-18 07:52:44 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 07:52:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 07:52:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 07:52:44 - SRCCONF=/dev/null TB --- 2013-06-18 07:52:44 - TARGET=ia64 TB --- 2013-06-18 07:52:44 - TARGET_ARCH=ia64 TB --- 2013-06-18 07:52:44 - TZ=UTC TB --- 2013-06-18 07:52:44 - __MAKE_CONF=/dev/null TB --- 2013-06-18 07:52:44 - cd /src TB --- 2013-06-18 07:52:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 07:52:44 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ale/if_ale.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 08:00:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 08:00:30 - ERROR: failed to build LINT kernel TB --- 2013-06-18 08:00:30 - 5032.21 user 668.55 system 6853.28 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 08:39:56 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 7706C7F5; Tue, 18 Jun 2013 08:39:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 4104C171C; Tue, 18 Jun 2013 08:39:56 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I8dtdp006749; Tue, 18 Jun 2013 08:39:55 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I8dtfV006744; Tue, 18 Jun 2013 08:39:55 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 08:39:55 GMT Message-Id: <201306180839.r5I8dtfV006744@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:39:56 -0000 TB --- 2013-06-18 07:19:57 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 07:19:57 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 07:19:57 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2013-06-18 07:19:57 - cleaning the object tree TB --- 2013-06-18 07:19:57 - /usr/local/bin/svn stat /src TB --- 2013-06-18 07:20:08 - At svn revision 251887 TB --- 2013-06-18 07:20:09 - building world TB --- 2013-06-18 07:20:09 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 07:20:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 07:20:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 07:20:09 - SRCCONF=/dev/null TB --- 2013-06-18 07:20:09 - TARGET=sparc64 TB --- 2013-06-18 07:20:09 - TARGET_ARCH=sparc64 TB --- 2013-06-18 07:20:09 - TZ=UTC TB --- 2013-06-18 07:20:09 - __MAKE_CONF=/dev/null TB --- 2013-06-18 07:20:09 - cd /src TB --- 2013-06-18 07:20:09 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 07:20:10 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 08:36:04 UTC 2013 TB --- 2013-06-18 08:36:04 - generating LINT kernel config TB --- 2013-06-18 08:36:04 - cd /src/sys/sparc64/conf TB --- 2013-06-18 08:36:04 - /usr/bin/make -B LINT TB --- 2013-06-18 08:36:04 - cd /src/sys/sparc64/conf TB --- 2013-06-18 08:36:04 - /usr/sbin/config -m LINT TB --- 2013-06-18 08:36:05 - building LINT kernel TB --- 2013-06-18 08:36:05 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 08:36:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 08:36:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 08:36:05 - SRCCONF=/dev/null TB --- 2013-06-18 08:36:05 - TARGET=sparc64 TB --- 2013-06-18 08:36:05 - TARGET_ARCH=sparc64 TB --- 2013-06-18 08:36:05 - TZ=UTC TB --- 2013-06-18 08:36:05 - __MAKE_CONF=/dev/null TB --- 2013-06-18 08:36:05 - cd /src TB --- 2013-06-18 08:36:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 08:36:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ale/if_ale.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 08:39:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 08:39:55 - ERROR: failed to build LINT kernel TB --- 2013-06-18 08:39:55 - 3601.84 user 556.83 system 4797.80 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 09:01:00 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 4418A480; Tue, 18 Jun 2013 09:01:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7BB1872; Tue, 18 Jun 2013 09:00:59 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5I90xq2092616; Tue, 18 Jun 2013 09:00:59 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5I90xja092615; Tue, 18 Jun 2013 09:00:59 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 09:00:59 GMT Message-Id: <201306180900.r5I90xja092615@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc/powerpc 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: Tue, 18 Jun 2013 09:01:00 -0000 TB --- 2013-06-18 06:17:28 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 06:17:28 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 06:17:28 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2013-06-18 06:17:28 - cleaning the object tree TB --- 2013-06-18 06:17:28 - /usr/local/bin/svn stat /src TB --- 2013-06-18 06:17:34 - At svn revision 251887 TB --- 2013-06-18 06:17:35 - building world TB --- 2013-06-18 06:17:35 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 06:17:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 06:17:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 06:17:35 - SRCCONF=/dev/null TB --- 2013-06-18 06:17:35 - TARGET=powerpc TB --- 2013-06-18 06:17:35 - TARGET_ARCH=powerpc TB --- 2013-06-18 06:17:35 - TZ=UTC TB --- 2013-06-18 06:17:35 - __MAKE_CONF=/dev/null TB --- 2013-06-18 06:17:35 - cd /src TB --- 2013-06-18 06:17:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 06:17:35 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 08:57:22 UTC 2013 TB --- 2013-06-18 08:57:22 - generating LINT kernel config TB --- 2013-06-18 08:57:22 - cd /src/sys/powerpc/conf TB --- 2013-06-18 08:57:22 - /usr/bin/make -B LINT TB --- 2013-06-18 08:57:22 - cd /src/sys/powerpc/conf TB --- 2013-06-18 08:57:22 - /usr/sbin/config -m LINT TB --- 2013-06-18 08:57:22 - building LINT kernel TB --- 2013-06-18 08:57:22 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 08:57:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 08:57:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 08:57:22 - SRCCONF=/dev/null TB --- 2013-06-18 08:57:22 - TARGET=powerpc TB --- 2013-06-18 08:57:22 - TARGET_ARCH=powerpc TB --- 2013-06-18 08:57:22 - TZ=UTC TB --- 2013-06-18 08:57:22 - __MAKE_CONF=/dev/null TB --- 2013-06-18 08:57:22 - cd /src TB --- 2013-06-18 08:57:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 08:57:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ale/if_ale.c cc -c -O -pipe -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/amd/amd.c /src/sys/dev/amd/amd.c: In function 'amd_action': /src/sys/dev/amd/amd.c:431: error: 'CAM_SCATTER_VALID' undeclared (first use in this function) /src/sys/dev/amd/amd.c:431: error: (Each undeclared identifier is reported only once /src/sys/dev/amd/amd.c:431: error: for each function it appears in.) /src/sys/dev/amd/amd.c:436: error: 'CAM_DATA_PHYS' undeclared (first use in this function) /src/sys/dev/amd/amd.c:473: error: 'CAM_SG_LIST_PHYS' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 09:00:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 09:00:59 - ERROR: failed to build LINT kernel TB --- 2013-06-18 09:00:59 - 7933.20 user 847.80 system 9810.95 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 11:15: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 A5A687DF for ; Tue, 18 Jun 2013 11:15:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 105281FFB for ; Tue, 18 Jun 2013 11:15:03 +0000 (UTC) Received: (qmail 46731 invoked by uid 89); 18 Jun 2013 11:11:44 -0000 Received: by simscan 1.4.0 ppid: 46726, pid: 46728, t: 0.0422s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:17370 Received: from unknown (HELO suse3) (rainer@ultra-secure.de@212.71.117.1) by mail.ultra-secure.de with ESMTPA; 18 Jun 2013 11:11:44 -0000 Date: Tue, 18 Jun 2013 13:11:43 +0200 From: Rainer Duffner To: freebsd-stable@freebsd.org Subject: Problem with ftp-proxy Message-ID: <20130618131143.340dff14@suse3> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:15:04 -0000 Hi, I use ftp-proxy, together with the patch that starts multiple instances: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/158171 I use it in a combination with pure-ftpd on the backend-server. on the proxy: 1434 ?? Ss 0:17.06 /usr/sbin/ftp-proxy -vv -b 127.0.0.2 -R 192.168.91.42 92144 ?? Ss 0:00.06 /usr/sbin/ftp-proxy -vv -b 127.0.0.1 -R 192.168.91.41 Originally, the proxy was on FreeBSD 8.3. A while ago, I updated it to FreeBSD 9.1. Now, the customer, who hadn't logged in for a while complained that while they could still login, it was not possible to view contents of directories or transfer files. I have the following pf.conf: ext_if="em0" int_if="em1" backend_ip="10.10.113.70" ftp_host_prod="192.168.91.41" ftp_host_test="192.168.91.42" proxyip_prod="127.0.0.1" proxyip_test="127.0.0.2" nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" nat on $ext_if from !($ext_if) -> ($ext_if:0) # didn't have the above line previously, but it does not make a difference rdr pass log proto tcp from any to EXT_IP_PROD port ftp -> $proxyip_prod port 8021 rdr pass log proto tcp from any to EXT_IP_TEST port ftp -> $proxyip_test port 8021 anchor "ftp-proxy/*" pass out log proto tcp from $backend_ip to $ftp_host_prod port 21 pass out log proto tcp from $backend_ip to $ftp_host_test port 21 I tried switching pure-ftpd on the backend-server to FreeBSD's ftpd, but that didn't change anything. There is both an additional firewall in front of the proxy and in front of the backend-server - but they don't log any denied traffic. Neither does pf. When I connect to the EXT_IP_PROD on the proxy itself and try to list files, it takes a while before a timeout occurs, and then, on the 2nd try, it actually works. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 11:28: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 8AC18A2F for ; Tue, 18 Jun 2013 11:28:40 +0000 (UTC) (envelope-from javad.kouhi@gmail.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 135DA1108 for ; Tue, 18 Jun 2013 11:28:39 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id y6so3417018lbh.23 for ; Tue, 18 Jun 2013 04:28:33 -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=jYrtybLe9Z4R7LK1SkKLJWi0QxvoZX7WLVuNwSarQO0=; b=ErI3fgPomCwO7Yxw+w4jn7hHTj7sjgNQR3oslSNg7OGtOEY90MF9Rg9QBxURupI4GV X2FT6yQHmYERw6Its+Qydom0kuxtVJHkWmH6NlHjvTHqgi9JIhIsU6+VqBUkTcmpoSq2 ew3uFCvyCjYPW6KGCCKB9q/RsUwXh1BtfbINaSuF3KCQi0AJk9xNOYWOQEzYjo2gR48Z gcom2T1PZ4PxMF9oERljCuacWjM1H+lSUmxWa1eOmfizmlJlK6ox5lzO9828psSRFQln vIvaHS57bA4n3YlReOYy0oGKvkZsqMdiFYBEUM5SIS97ufOy6rMgQ5NqyjBdFVmW7gVC yPEg== MIME-Version: 1.0 X-Received: by 10.112.130.37 with SMTP id ob5mr864198lbb.77.1371554913423; Tue, 18 Jun 2013 04:28:33 -0700 (PDT) Received: by 10.114.19.236 with HTTP; Tue, 18 Jun 2013 04:28:33 -0700 (PDT) In-Reply-To: <20130617193726.GR91021@kib.kiev.ua> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> Date: Tue, 18 Jun 2013 15:58:33 +0430 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Javad Kouhi To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Michiel Boland , 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: Tue, 18 Jun 2013 11:28:40 -0000 Hi, I have exactly the same problem. I've tried to apply the above patch but it refused. I've checked out the last revision (251934) of -STABLE branch using Subversion. % git apply --check patch error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 error: sys/dev/drm2/i915/intel_fb.c: patch does not apply error: patch failed: sys/dev/syscons/scvgarndr.c:445 error: sys/dev/syscons/scvgarndr.c: patch does not apply How can I apply this patch? From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 11:32:57 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 CCBAEACA for ; Tue, 18 Jun 2013 11:32:57 +0000 (UTC) (envelope-from feld@feld.me) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id A1E381134 for ; Tue, 18 Jun 2013 11:32:56 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E97D020902; Tue, 18 Jun 2013 07:32:49 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 18 Jun 2013 07:32:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=77ClNfZwoTg7zaR5tVvPRW3Ozkk=; b=LgBMp7ExDHMx+TJRH9ZZA 9XE5W1lRQRcZNLd84jug1UO+EU4WhbrJAYc837z2aWtRpX8GpTix0Qt8CSDA6Tge 5rQDu55xqFdrv6qaWS0IzRcjwVbi29VVQVYsSZGs/qbDqe0PaEpL89d2AbHwbfca 0c/Ul7p4dke76HkIqSTkiU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :cc:mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=77ClNfZwoTg7zaR5tVvPRW3Ozkk=; b=UJ2K 3fKrLlKAw001GdP6xY1Sd8rBZYfylB3HWvM5MEZlvFYAIkFFl1dWUn8uuERC6bka aD2Ph7fDGCnT3SqkKvk7eSLCPWk6DUt+vqp3QNf+fh/YagY+R4ZP1JIoZ62XyuIH Z1idExrGmwoFmKB6hr+8FauNdPu0HEfB1wNSAdQ= X-Sasl-enc: 0DT4YLj6cTHSyKcXV8ILXxBzsbFLwLdKcTgAmDD6JUO7 1371555169 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id AEAA46801FF; Tue, 18 Jun 2013 07:32:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Problem with ftp-proxy References: <20130618131143.340dff14@suse3> Date: Tue, 18 Jun 2013 06:32:49 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20130618131143.340dff14@suse3> User-Agent: Opera Mail/12.15 (FreeBSD) Cc: Rainer Duffner 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, 18 Jun 2013 11:32:57 -0000 On Tue, 18 Jun 2013 06:11:43 -0500, Rainer Duffner wrote: > Hi, > > > I use ftp-proxy, together with the patch that starts multiple instances: > I recommend avoiding ftp-proxy and setting up static rules that you know will work. On our systems in pure-ftpd.conf we set PassivePortRange 3000 3200 and then on the system's firewall and every firewall in front we pass through ports 3000-3200. It's a simple solution that's guaranteed to work, and you don't have to debug what the proxy is doing. Also, most ftp-proxy software tends to do a very bad job once you start throwing in FTPES. We see this with customer firewalls all the time. These firewall services under the guise of "proxys", "fixups", or "Application Layer Gateways" are just inconsistent and unreliable no matter which vendor supplies it. Note, you may have to make the range larger if you expect more than 200 concurrent sessions. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 14:12: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 ADFCC5B7 for ; Tue, 18 Jun 2013 14:12:51 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4AA1BF9 for ; Tue, 18 Jun 2013 14:12:50 +0000 (UTC) Received: from charlemagne.boland.org (37-251-76-95.FTTH.ispfabriek.nl [37.251.76.95]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id r5IECYbF085694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jun 2013 16:12:36 +0200 (CEST) (envelope-from boland37@xs4all.nl) Message-ID: <51C06AD2.5030404@xs4all.nl> Date: Tue, 18 Jun 2013 16:12:34 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130615 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner 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, 18 Jun 2013 14:12:51 -0000 On 06/18/2013 13:28, Javad Kouhi wrote: > Hi, > > I have exactly the same problem. I've tried to apply the above patch > but it refused. I've checked out the last revision (251934) of > -STABLE branch using Subversion. > > % git apply --check patch > error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 > error: sys/dev/drm2/i915/intel_fb.c: patch does not apply > error: patch failed: sys/dev/syscons/scvgarndr.c:445 > error: sys/dev/syscons/scvgarndr.c: patch does not apply > > How can I apply this patch? I think you want to lose the '--check' option here. Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 14:30:37 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 4C408ED for ; Tue, 18 Jun 2013 14:30:37 +0000 (UTC) (envelope-from javad.kouhi@gmail.com) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id C7A2B1D39 for ; Tue, 18 Jun 2013 14:30:36 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t13so3684475lbd.1 for ; Tue, 18 Jun 2013 07:30: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; bh=XA50qFJjvzrgO0V/tcACqgw0UcFwY/78cTiUdofuPbU=; b=w+YPOCyz/pdnQV6s78DZyaM7fQAxsEpUd2qzWRawYYmaGM9+K9/hz8PLyYFyLyeHD1 54xh/f/xfhShnLClSUBenHqfegUNEtImOlpdsGJSfmdORZTiP0VQSrp/uK7ln9nNJfcK WNT1VqYn5B/+Ypvyku6+SSlXHXL3JrnlakfFdAWpkN7Koi+k8aq4VZwcFz9vG0/MWnh0 dQ2AKhNZAZDXj+q4occSufYJaFRCz2G+ugdjBW2UcC4vFId2ksMzFPMFay8UvRO1UjTl Ut0Cf1m92ZFafk/PLE8DhjsIomKgoT78g60+msvWpFauog9MxPb/jZmfsS6viYmYJBWF ClKA== MIME-Version: 1.0 X-Received: by 10.152.23.99 with SMTP id l3mr9033684laf.82.1371565830297; Tue, 18 Jun 2013 07:30:30 -0700 (PDT) Received: by 10.114.19.236 with HTTP; Tue, 18 Jun 2013 07:30:30 -0700 (PDT) In-Reply-To: <51C06AD2.5030404@xs4all.nl> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> Date: Tue, 18 Jun 2013 19:00:30 +0430 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Javad Kouhi To: Michiel Boland Content-Type: text/plain; charset=ISO-8859-1 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, 18 Jun 2013 14:30:37 -0000 Thanks for the reply, seems that our source trees are not same, I got this: % patch -p1 < /path/to/patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c |index 3cb3b78..e41a49f 100644 |--- a/sys/dev/drm2/i915/intel_fb.c |+++ b/sys/dev/drm2/i915/intel_fb.c -------------------------- Patching file sys/dev/drm2/i915/intel_fb.c using Plan A... Hunk #1 succeeded at 207 with fuzz 1. Hunk #2 failed at 231. 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/i915/intel_fb.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c |index 6e6663c..fc7f02f 100644 |--- a/sys/dev/syscons/scvgarndr.c |+++ b/sys/dev/syscons/scvgarndr.c -------------------------- Patching file sys/dev/syscons/scvgarndr.c using Plan A... Hunk #1 succeeded at 395. Hunk #2 failed at 447. 1 out of 2 hunks failed--saving rejects to sys/dev/syscons/scvgarndr.c.rej done And the git way: % git apply /path/to/patch error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 error: sys/dev/drm2/i915/intel_fb.c: patch does not apply error: patch failed: sys/dev/syscons/scvgarndr.c:445 error: sys/dev/syscons/scvgarndr.c: patch does not apply I have revision 251934 of -STABLE branch. (I updated my source tree about 3 hours ago using svn) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 14:47: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 01235A39 for ; Tue, 18 Jun 2013 14:47:44 +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 9B0F11E5A for ; Tue, 18 Jun 2013 14:47:43 +0000 (UTC) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 994AFA80D2; Tue, 18 Jun 2013 16:47:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id uFyerY01kgCI; Tue, 18 Jun 2013 16:47:24 +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 56898A8102; Tue, 18 Jun 2013 16:47:24 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6DE2473A31; Tue, 18 Jun 2013 07:47:22 -0700 (PDT) Date: Tue, 18 Jun 2013 07:47:22 -0700 From: Jeremy Chadwick To: Javad Kouhi Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130618144722.GA3446@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michiel Boland , 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, 18 Jun 2013 14:47:44 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 18, 2013 at 07:00:30PM +0430, Javad Kouhi wrote: > Thanks for the reply, seems that our source trees are not same, I got this: > > % patch -p1 < /path/to/patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c > |index 3cb3b78..e41a49f 100644 > |--- a/sys/dev/drm2/i915/intel_fb.c > |+++ b/sys/dev/drm2/i915/intel_fb.c > -------------------------- > Patching file sys/dev/drm2/i915/intel_fb.c using Plan A... > Hunk #1 succeeded at 207 with fuzz 1. > Hunk #2 failed at 231. > 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/i915/intel_fb.c.rej > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c > |index 6e6663c..fc7f02f 100644 > |--- a/sys/dev/syscons/scvgarndr.c > |+++ b/sys/dev/syscons/scvgarndr.c > -------------------------- > Patching file sys/dev/syscons/scvgarndr.c using Plan A... > Hunk #1 succeeded at 395. > Hunk #2 failed at 447. > 1 out of 2 hunks failed--saving rejects to sys/dev/syscons/scvgarndr.c.rej > done > > > And the git way: > > % git apply /path/to/patch > error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 > error: sys/dev/drm2/i915/intel_fb.c: patch does not apply > error: patch failed: sys/dev/syscons/scvgarndr.c:445 > error: sys/dev/syscons/scvgarndr.c: patch does not apply > > > I have revision 251934 of -STABLE branch. (I updated my source tree > about 3 hours ago using svn) I do not use git, I use svn, So I cannot help you with git "crap". Please revert your sys/dev/drm2/i915/intel_fb.c and sys/dev/syscons/scvgarndr.c back to r251934 (or newer) before following what I tell you below. The problem is either that: - The patch you were given is probably for a different FreeBSD release, thus the code/line numbers/info in the code break the fuzzy logic matching, - You copy-pasted the diff and because of tabs vs. spaces botched it, - git apply/patch/whatever is weird, - Multitudes of other possibilities I do not care to go into. The hack kib@ gave you is not hard to manually add yourself. It's very few lines of code. I'm very surprised you didn't try to manually add it yourself. So I have done that for you. First, the proof -- this is against r251939, by the way, but that shouldn't matter as nobody has touched this between r251934 and r251939: $ svn info Path: . Working Copy Root Path: /home/jdc/work/src URL: svn://svn.freebsd.org/base/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 251939 Node Kind: directory Schedule: normal Last Changed Author: marius Last Changed Rev: 251939 Last Changed Date: 2013-06-18 07:20:14 -0700 (Tue, 18 Jun 2013) $ svn status M sys/dev/drm2/i915/intel_fb.c M sys/dev/syscons/scvgarndr.c The diff itself is available here: http://jdc.koitsu.org/freebsd/sysmouse_vsync.diff I've also attached it here in Email (assuming the mailing list doesn't delete it). You should apply the patch using: cd /usr/src (or wherever your source is) patch -p0 < sysmouse_vsync.diff Assuming use of svn, you can revert this patch by doing: cd /usr/src (or wherever your source is) svn revert sys/dev/drm2/i915/intel_fb.c svn revert sys/dev/syscons/scvgarndr.c rm sys/dev/drm2/i915/intel_fb.c.orig rm sys/dev/syscons/scvgarndr.c.orig There is probably some other "magical" way to do all of this, but as anyone here knows, I do things manually because in general I do not trust VCSes or the "magic" they do under the hood; I prefer to do things that I know work. Good luck -- I cannot help with any other aspect to the issue. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | --uAKRQypu60I7Lcqm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="sysmouse_vsync.diff" Index: sys/dev/drm2/i915/intel_fb.c =================================================================== --- sys/dev/drm2/i915/intel_fb.c (revision 251939) +++ sys/dev/drm2/i915/intel_fb.c (working copy) @@ -207,6 +207,8 @@ static void intel_fbdev_destroy(struct drm_device } } +extern int sc_txtmouse_no_retrace_wait; + int intel_fbdev_init(struct drm_device *dev) { struct intel_fbdev *ifbdev; @@ -229,6 +231,7 @@ int intel_fbdev_init(struct drm_device *dev) drm_fb_helper_single_add_all_connectors(&ifbdev->helper); drm_fb_helper_initial_config(&ifbdev->helper, 32); + sc_txtmouse_no_retrace_wait = 1; return 0; } Index: sys/dev/syscons/scvgarndr.c =================================================================== --- sys/dev/syscons/scvgarndr.c (revision 251939) +++ sys/dev/syscons/scvgarndr.c (working copy) @@ -395,6 +395,8 @@ vga_txtblink(scr_stat *scp, int at, int flip) { } +int sc_txtmouse_no_retrace_wait; + #ifndef SC_NO_CUTPASTE static void @@ -445,7 +447,9 @@ draw_txtmouse(scr_stat *scp, int x, int y) #if 1 /* wait for vertical retrace to avoid jitter on some videocards */ crtc_addr = scp->sc->adp->va_crtc_addr; - while (!(inb(crtc_addr + 6) & 0x08)) /* idle */ ; + while (!sc_txtmouse_no_retrace_wait && + !(inb(crtc_addr + 6) & 0x08)) + /* idle */ ; #endif c = scp->sc->mouse_char; vidd_load_font(scp->sc->adp, 0, 32, 8, font_buf, c, 4); --uAKRQypu60I7Lcqm-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 15:14:23 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 EB9D3A11; Tue, 18 Jun 2013 15:14:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B1F871002; Tue, 18 Jun 2013 15:14:23 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5IFENKg088121; Tue, 18 Jun 2013 15:14:23 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5IFENnB088120; Tue, 18 Jun 2013 15:14:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Jun 2013 15:14:23 GMT Message-Id: <201306181514.r5IFENnB088120@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 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: Tue, 18 Jun 2013 15:14:24 -0000 TB --- 2013-06-18 13:01:09 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 13:01:09 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 13:01:09 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-06-18 13:01:09 - cleaning the object tree TB --- 2013-06-18 13:01:30 - /usr/local/bin/svn stat /src TB --- 2013-06-18 13:01:49 - At svn revision 251932 TB --- 2013-06-18 13:01:50 - building world TB --- 2013-06-18 13:01:50 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 13:01:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 13:01:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 13:01:50 - SRCCONF=/dev/null TB --- 2013-06-18 13:01:50 - TARGET=ia64 TB --- 2013-06-18 13:01:50 - TARGET_ARCH=ia64 TB --- 2013-06-18 13:01:50 - TZ=UTC TB --- 2013-06-18 13:01:50 - __MAKE_CONF=/dev/null TB --- 2013-06-18 13:01:50 - cd /src TB --- 2013-06-18 13:01:50 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 13:01:55 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jun 18 14:49:18 UTC 2013 TB --- 2013-06-18 14:49:18 - generating LINT kernel config TB --- 2013-06-18 14:49:18 - cd /src/sys/ia64/conf TB --- 2013-06-18 14:49:18 - /usr/bin/make -B LINT TB --- 2013-06-18 14:49:18 - cd /src/sys/ia64/conf TB --- 2013-06-18 14:49:18 - /usr/sbin/config -m LINT TB --- 2013-06-18 14:49:19 - building LINT kernel TB --- 2013-06-18 14:49:19 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 14:49:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 14:49:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 14:49:19 - SRCCONF=/dev/null TB --- 2013-06-18 14:49:19 - TARGET=ia64 TB --- 2013-06-18 14:49:19 - TARGET_ARCH=ia64 TB --- 2013-06-18 14:49:19 - TZ=UTC TB --- 2013-06-18 14:49:19 - __MAKE_CONF=/dev/null TB --- 2013-06-18 14:49:19 - cd /src TB --- 2013-06-18 14:49:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 18 14:49:19 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia32/ia32_trap.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/bus_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/busdma_machdep.c /src/sys/ia64/ia64/busdma_machdep.c: In function '_bus_dmamap_count_phys': /src/sys/ia64/ia64/busdma_machdep.c:490: error: 'paddr_max' undeclared (first use in this function) /src/sys/ia64/ia64/busdma_machdep.c:490: error: (Each undeclared identifier is reported only once /src/sys/ia64/ia64/busdma_machdep.c:490: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-18 15:14:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-18 15:14:23 - ERROR: failed to build LINT kernel TB --- 2013-06-18 15:14:23 - 5885.77 user 711.31 system 7993.82 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 18:05: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 EBED8939 for ; Tue, 18 Jun 2013 18:05:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id B6FE21AF2 for ; Tue, 18 Jun 2013 18:05:43 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so4883915obc.6 for ; Tue, 18 Jun 2013 11:05:43 -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=iQZwmEgDLu3g4qoEQ1Td2PZ/7NCcwaYepTdtAo+sPI4=; b=h8Gx/C2kHVsXM7yW4dpIRyUlr1/ugOSV4k+z1UT7UJI35SL1xCgjRHjFhORmOjX+52 AIJVfVqWR3T+Yvstx9LQgr3sTbxgcLl8xcBbwO+e+XGD0dmbgPGPYnqvF5IVQdPhYdY5 4ur69+BnxH2HXW5AegqrQKCliZTrCAHbcik6Jg8h1pmRXNQy8wMy2kce4U5Key5lYn0k ksEaPKBLpm1iUkxCBN5tI4AVz5MdGj/L4k5+XoDAlC8F1211J/kVoNnDphPbpKfCVcMp nJsZ+A7P31IUsnMtQcrAFH0+d5ag1YZSVVjtddEjhExzjpduhazOY3cBbWZfYbc3vwMj HX3g== MIME-Version: 1.0 X-Received: by 10.182.66.46 with SMTP id c14mr12694084obt.33.1371578743265; Tue, 18 Jun 2013 11:05:43 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Tue, 18 Jun 2013 11:05:43 -0700 (PDT) In-Reply-To: <20130618144722.GA3446@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> Date: Tue, 18 Jun 2013 11:05:43 -0700 X-Google-Sender-Auth: 1vpxMMC7IvkQtFeCqKAtVB2K1M0 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Kevin Oberman To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Michiel Boland , "freebsd-stable@freebsd.org Stable" , Javad Kouhi 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, 18 Jun 2013 18:05:44 -0000 On Tue, Jun 18, 2013 at 7:47 AM, Jeremy Chadwick wrote: > On Tue, Jun 18, 2013 at 07:00:30PM +0430, Javad Kouhi wrote: > > Thanks for the reply, seems that our source trees are not same, I got > this: > > > > % patch -p1 < /path/to/patch > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c > > |index 3cb3b78..e41a49f 100644 > > |--- a/sys/dev/drm2/i915/intel_fb.c > > |+++ b/sys/dev/drm2/i915/intel_fb.c > > -------------------------- > > Patching file sys/dev/drm2/i915/intel_fb.c using Plan A... > > Hunk #1 succeeded at 207 with fuzz 1. > > Hunk #2 failed at 231. > > 1 out of 2 hunks failed--saving rejects to > sys/dev/drm2/i915/intel_fb.c.rej > > Hmm... The next patch looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c > > |index 6e6663c..fc7f02f 100644 > > |--- a/sys/dev/syscons/scvgarndr.c > > |+++ b/sys/dev/syscons/scvgarndr.c > > -------------------------- > > Patching file sys/dev/syscons/scvgarndr.c using Plan A... > > Hunk #1 succeeded at 395. > > Hunk #2 failed at 447. > > 1 out of 2 hunks failed--saving rejects to > sys/dev/syscons/scvgarndr.c.rej > > done > > > > > > And the git way: > > > > % git apply /path/to/patch > > error: patch failed: sys/dev/drm2/i915/intel_fb.c:207 > > error: sys/dev/drm2/i915/intel_fb.c: patch does not apply > > error: patch failed: sys/dev/syscons/scvgarndr.c:445 > > error: sys/dev/syscons/scvgarndr.c: patch does not apply > > > > > > I have revision 251934 of -STABLE branch. (I updated my source tree > > about 3 hours ago using svn) > > I do not use git, I use svn, So I cannot help you with git "crap". > > Please revert your sys/dev/drm2/i915/intel_fb.c and > sys/dev/syscons/scvgarndr.c back to r251934 (or newer) before following > what I tell you below. > > The problem is either that: > > - The patch you were given is probably for a different FreeBSD release, > thus the code/line numbers/info in the code break the fuzzy logic > matching, > - You copy-pasted the diff and because of tabs vs. spaces botched it, > - git apply/patch/whatever is weird, > - Multitudes of other possibilities I do not care to go into. > > The hack kib@ gave you is not hard to manually add yourself. It's very > few lines of code. I'm very surprised you didn't try to manually add it > yourself. So I have done that for you. First, the proof -- this is > against r251939, by the way, but that shouldn't matter as nobody has > touched this between r251934 and r251939: > > $ svn info > Path: . > Working Copy Root Path: /home/jdc/work/src > URL: svn://svn.freebsd.org/base/stable/9 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 251939 > Node Kind: directory > Schedule: normal > Last Changed Author: marius > Last Changed Rev: 251939 > Last Changed Date: 2013-06-18 07:20:14 -0700 (Tue, 18 Jun 2013) > > $ svn status > M sys/dev/drm2/i915/intel_fb.c > M sys/dev/syscons/scvgarndr.c > > The diff itself is available here: > > http://jdc.koitsu.org/freebsd/sysmouse_vsync.diff > > I've also attached it here in Email (assuming the mailing list doesn't > delete it). > > You should apply the patch using: > > cd /usr/src (or wherever your source is) > patch -p0 < sysmouse_vsync.diff > > Assuming use of svn, you can revert this patch by doing: > > cd /usr/src (or wherever your source is) > svn revert sys/dev/drm2/i915/intel_fb.c > svn revert sys/dev/syscons/scvgarndr.c > rm sys/dev/drm2/i915/intel_fb.c.orig > rm sys/dev/syscons/scvgarndr.c.orig > > There is probably some other "magical" way to do all of this, but as > anyone here knows, I do things manually because in general I do not > trust VCSes or the "magic" they do under the hood; I prefer to do things > that I know work. > > Good luck -- I cannot help with any other aspect to the issue. > After some testing, I now believe that there are two failure modes causing hangs on shutdown on Intel_KMS systems. Data is mostly empirical, but it looks pretty clear to me. Failure 1: Shutdown proceeds through a significant portion of the shutdown before hanging shortly before syncing disks. Shutdown has passed the point of most userland capability, so no real access is available. Failure2: Shutdown hangs almost instantly. All disk activity ends and the system (userland) is frozen. ping still works, so the net has not been shutdown and the kernel is still responsive. I suspect that this patch only fixes one of the issues, but time will tell. (I thought I was ready to go on testing this until this morning's security announcement and just finished rebuilding the kernels again.) In all cases, the reboot(8) and halt(8) commands seems to work fine, but won't cleanly shutdown daemons and the like, so this is not a desirable solution. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 18:07:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E9D6A4C for ; Tue, 18 Jun 2013 18:07:12 +0000 (UTC) (envelope-from javad.kouhi@gmail.com) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id 144C01B12 for ; Tue, 18 Jun 2013 18:07:11 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t13so3911102lbd.1 for ; Tue, 18 Jun 2013 11:07:10 -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=6RNJWJSQ2kKogetg6eob5p2KVOY4rOHNM8HICe7Xxys=; b=RQymjPsaWZYBFFp6J7DiepuuRVlVXfv3jPJ926c8E/A6qBMND/d7SQSpBHQcrFwei5 nolhjS482kLTOPb2TKYHpFYy7BsasDDBzAjU9wJoqqrP35cscd1an3uFFfthv38beG/5 aZeWz/JVkoNV2pp6kIcjLGODYnSxYYXbGvTYUw8KRrobCs1sdlR5OwUqm8vxCX6c7/lP I4wRa4PsOL/GXaS6dYXn15HKYqGp/1Z6vZC/czhSlVVeolqCsP8aw/iwO70BVBGKxi08 AwkzeDwlsU+K3aWudEGsVl7PiAdEoReV0W0yufKh+MQV8uxqHXvbAwM+glNHC88cj9Dp HG/Q== MIME-Version: 1.0 X-Received: by 10.112.130.37 with SMTP id ob5mr1575907lbb.77.1371578830624; Tue, 18 Jun 2013 11:07:10 -0700 (PDT) Received: by 10.114.19.236 with HTTP; Tue, 18 Jun 2013 11:07:10 -0700 (PDT) In-Reply-To: <20130618144722.GA3446@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> Date: Tue, 18 Jun 2013 22:37:10 +0430 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Javad Kouhi To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: Michiel Boland , 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, 18 Jun 2013 18:07:12 -0000 On Tue, Jun 18, 2013 at 7:17 PM, Jeremy Chadwick wrote: > > I do not use git, I use svn, So I cannot help you with git "crap". > > Please revert your sys/dev/drm2/i915/intel_fb.c and > sys/dev/syscons/scvgarndr.c back to r251934 (or newer) before following > what I tell you below. > > The problem is either that: > > - The patch you were given is probably for a different FreeBSD release, > thus the code/line numbers/info in the code break the fuzzy logic > matching, > - You copy-pasted the diff and because of tabs vs. spaces botched it, > - git apply/patch/whatever is weird, > - Multitudes of other possibilities I do not care to go into. > > The hack kib@ gave you is not hard to manually add yourself. It's very > few lines of code. I'm very surprised you didn't try to manually add it > yourself. So I have done that for you. First, the proof -- this is > against r251939, by the way, but that shouldn't matter as nobody has > touched this between r251934 and r251939: > > $ svn info > Path: . > Working Copy Root Path: /home/jdc/work/src > URL: svn://svn.freebsd.org/base/stable/9 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 251939 > Node Kind: directory > Schedule: normal > Last Changed Author: marius > Last Changed Rev: 251939 > Last Changed Date: 2013-06-18 07:20:14 -0700 (Tue, 18 Jun 2013) > > $ svn status > M sys/dev/drm2/i915/intel_fb.c > M sys/dev/syscons/scvgarndr.c > > The diff itself is available here: > > http://jdc.koitsu.org/freebsd/sysmouse_vsync.diff > > I've also attached it here in Email (assuming the mailing list doesn't > delete it). > > You should apply the patch using: > > cd /usr/src (or wherever your source is) > patch -p0 < sysmouse_vsync.diff > > Assuming use of svn, you can revert this patch by doing: > > cd /usr/src (or wherever your source is) > svn revert sys/dev/drm2/i915/intel_fb.c > svn revert sys/dev/syscons/scvgarndr.c > rm sys/dev/drm2/i915/intel_fb.c.orig > rm sys/dev/syscons/scvgarndr.c.orig > > There is probably some other "magical" way to do all of this, but as > anyone here knows, I do things manually because in general I do not > trust VCSes or the "magic" they do under the hood; I prefer to do things > that I know work. > > Good luck -- I cannot help with any other aspect to the issue. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > Many thanks for the detailed answer. I've applied your patch and then rebuilt the world and kernel. To be honest, I tried to apply the patch manually but the syntax was too complex for me. Thanks for the help to apply the patch. Unfortunately, the original issue is still exist and shutdown(8) doesn't work properly. I'm a newbie and I don't know what informations I should provide, but here is some basic information: % uname -a FreeBSD minootux 9.1-STABLE FreeBSD 9.1-STABLE #0 r251946M: Tue Jun 18 21:16:56 IRDT 2013 root@minootux:/usr/obj/usr/src/sys/GIGABYTE amd64 % pkg_info -I -x xorg-server -x drm libdrm-2.4.44 Userspace interface to kernel Direct Rendering Module servi xorg-server-1.12.4,1 X.Org X server and related programs The machine is a laptop and the following link contains the details about the hardware: http://www.gigabyte.com/products/product-page.aspx?pid=3793#sp KMS and NEW_XORG are enabled in my /etc/make.conf. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 18:26: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 B19BDEC3 for ; Tue, 18 Jun 2013 18:26:00 +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 529731C2A for ; Tue, 18 Jun 2013 18:25:59 +0000 (UTC) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A338B1720A4; Tue, 18 Jun 2013 20:25:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QjZD5WjPV-8s; Tue, 18 Jun 2013 20:25:41 +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 7440F172085; Tue, 18 Jun 2013 20:25:40 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 9697C73A1C; Tue, 18 Jun 2013 11:25:38 -0700 (PDT) Date: Tue, 18 Jun 2013 11:25:38 -0700 From: Jeremy Chadwick To: Javad Kouhi Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130618182538.GA3380@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@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: Michiel Boland , 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, 18 Jun 2013 18:26:00 -0000 On Tue, Jun 18, 2013 at 10:37:10PM +0430, Javad Kouhi wrote: > On Tue, Jun 18, 2013 at 7:17 PM, Jeremy Chadwick wrote: > > > > I do not use git, I use svn, So I cannot help you with git "crap". > > > > Please revert your sys/dev/drm2/i915/intel_fb.c and > > sys/dev/syscons/scvgarndr.c back to r251934 (or newer) before following > > what I tell you below. > > > > The problem is either that: > > > > - The patch you were given is probably for a different FreeBSD release, > > thus the code/line numbers/info in the code break the fuzzy logic > > matching, > > - You copy-pasted the diff and because of tabs vs. spaces botched it, > > - git apply/patch/whatever is weird, > > - Multitudes of other possibilities I do not care to go into. > > > > The hack kib@ gave you is not hard to manually add yourself. It's very > > few lines of code. I'm very surprised you didn't try to manually add it > > yourself. So I have done that for you. First, the proof -- this is > > against r251939, by the way, but that shouldn't matter as nobody has > > touched this between r251934 and r251939: > > > > $ svn info > > Path: . > > Working Copy Root Path: /home/jdc/work/src > > URL: svn://svn.freebsd.org/base/stable/9 > > Repository Root: svn://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 251939 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: marius > > Last Changed Rev: 251939 > > Last Changed Date: 2013-06-18 07:20:14 -0700 (Tue, 18 Jun 2013) > > > > $ svn status > > M sys/dev/drm2/i915/intel_fb.c > > M sys/dev/syscons/scvgarndr.c > > > > The diff itself is available here: > > > > http://jdc.koitsu.org/freebsd/sysmouse_vsync.diff > > > > I've also attached it here in Email (assuming the mailing list doesn't > > delete it). > > > > You should apply the patch using: > > > > cd /usr/src (or wherever your source is) > > patch -p0 < sysmouse_vsync.diff > > > > Assuming use of svn, you can revert this patch by doing: > > > > cd /usr/src (or wherever your source is) > > svn revert sys/dev/drm2/i915/intel_fb.c > > svn revert sys/dev/syscons/scvgarndr.c > > rm sys/dev/drm2/i915/intel_fb.c.orig > > rm sys/dev/syscons/scvgarndr.c.orig > > > > There is probably some other "magical" way to do all of this, but as > > anyone here knows, I do things manually because in general I do not > > trust VCSes or the "magic" they do under the hood; I prefer to do things > > that I know work. > > > > Good luck -- I cannot help with any other aspect to the issue. > > > > -- > > | Jeremy Chadwick jdc@koitsu.org | > > | UNIX Systems Administrator http://jdc.koitsu.org/ | > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > > > Many thanks for the detailed answer. I've applied your patch and then > rebuilt the world and kernel. To be honest, I tried to apply the patch > manually but the syntax was too complex for me. Thanks for the help to > apply the patch. > > Unfortunately, the original issue is still exist and shutdown(8) > doesn't work properly. I'm a newbie and I don't know what informations > I should provide, but here is some basic information: > > % uname -a > FreeBSD minootux 9.1-STABLE FreeBSD 9.1-STABLE #0 r251946M: Tue Jun 18 > 21:16:56 IRDT 2013 root@minootux:/usr/obj/usr/src/sys/GIGABYTE > amd64 > > % pkg_info -I -x xorg-server -x drm > libdrm-2.4.44 Userspace interface to kernel Direct Rendering Module servi > xorg-server-1.12.4,1 X.Org X server and related programs > > The machine is a laptop and the following link contains the details > about the hardware: > http://www.gigabyte.com/products/product-page.aspx?pid=3793#sp > > KMS and NEW_XORG are enabled in my /etc/make.conf. First, what makes you think your issue is the same issue as reported by Michiel Boland? Let me point you to two of his posts (read them slowly and in full please): http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073821.html http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073839.html Second, the patch is not mine -- it's Konstantin's. I did not write the code/fix, nor do I understand it. All I did was provide a version of the same patch that applied cleanly on recent stable/9. (I'm sorry for needing to state this, but clear ownership of code/issues is important.) TL;DR -- The patch kib@ wrote was not for you, it was for Michiel. If the patch works for Michiel and fixes his issue, great. It sounds clearly, to me, like you have a different problem or an issue that manifests itself in the same manner but the root cause is different. Your issue should be handled separately (preferably in another thread). -- | 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 Jun 18 19:03:59 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 66535B17 for ; Tue, 18 Jun 2013 19:03:59 +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 37C8C1DE8 for ; Tue, 18 Jun 2013 19:03:59 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id xk17so5043488obc.10 for ; Tue, 18 Jun 2013 12:03:58 -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=hwLBVjgf6o1wy4/gOIIoEUVoRBasSXQwR9LW/bgqHNk=; b=p3ahjceCTP9EGLl+RAR3aM6E6YBdxyWl63v89ho59asl0NMS+f2ekGbp3YkvwCq2VT dFSDMyh9fOL0GLuIHRW90JUj/Eo1FyvLM3RDG51rteK0gWPmBlEzvIUNmyogdkQacf6x hk1uGO4i0eNRF70b5JUMH4Pvt+sUwlUGqKqqVfbSKwhVQ8QamTwLWup6TgHA25mRJ5qU g10Ma6bdXRrZHfPxuVRYxqirQTo/A/L9viGh+/nsjKzBtjXejiZF60Onp1njTGrmB/O6 ql32zKf0LXreM1LwhlQjTgG2Tz6wzWeDoHOaUSWxZQstPjxXOHaCtqZSQi3GFWwaKV9H SiwQ== MIME-Version: 1.0 X-Received: by 10.60.62.103 with SMTP id x7mr12778785oer.6.1371582238719; Tue, 18 Jun 2013 12:03:58 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Tue, 18 Jun 2013 12:03:58 -0700 (PDT) Date: Tue, 18 Jun 2013 12:03:58 -0700 X-Google-Sender-Auth: j0Hv5gRJGBACa5lEjqt5RlSW-gI Message-ID: Subject: include/c++/v1 still in BSD.include.dist as well as in obsolete_files From: Kevin Oberman To: "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=UTF-8 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, 18 Jun 2013 19:03:59 -0000 When I run "make check-old, the /usr/include/c++/v1 and v1/ext directories are listed as old, but they are still present in BSD.include.dist, so are recreated every time I installworld. Could these directories be removed from BSD.include.dist, as I am pretty sure that they ARE obsolete. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 20:30:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41C8A8F8 for ; Tue, 18 Jun 2013 20:30:28 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 881D811CC for ; Tue, 18 Jun 2013 20:30:26 +0000 (UTC) Received: (qmail 59806 invoked by uid 89); 18 Jun 2013 20:29:52 -0000 Received: by simscan 1.4.0 ppid: 59801, pid: 59803, t: 0.0598s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:17374 Received: from unknown (HELO ?212.71.117.84?) (rainer@ultra-secure.de@212.71.117.84) by mail.ultra-secure.de with ESMTPA; 18 Jun 2013 20:29:52 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Problem with ftp-proxy From: Rainer Duffner In-Reply-To: Date: Tue, 18 Jun 2013 22:29:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83C1CB74-FFB3-453B-8D7B-BFDC9ED6FA80@ultra-secure.de> References: <20130618131143.340dff14@suse3> To: "Mark Felder" 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: Tue, 18 Jun 2013 20:30:28 -0000 Am 18.06.2013 um 13:32 schrieb "Mark Felder" : > On Tue, 18 Jun 2013 06:11:43 -0500, Rainer Duffner = wrote: >=20 >> Hi, >>=20 >>=20 >> I use ftp-proxy, together with the patch that starts multiple = instances: >>=20 >=20 > I recommend avoiding ftp-proxy and setting up static rules that you = know will work. On our systems in pure-ftpd.conf we set >=20 > PassivePortRange 3000 3200 >=20 > and then on the system's firewall and every firewall in front we pass = through ports 3000-3200. It's a simple solution that's guaranteed to = work, and you don't have to debug what the proxy is doing. >=20 > Also, most ftp-proxy software tends to do a very bad job once you = start throwing in FTPES. We see this with customer firewalls all the = time. These firewall services under the guise of "proxys", "fixups", or = "Application Layer Gateways" are just inconsistent and unreliable no = matter which vendor supplies it. >=20 > Note, you may have to make the range larger if you expect more than = 200 concurrent sessions. Hi, thanks for the hint. I didn't get that to work right away, either=85. But while I worked through various documentations and tutorials, I = checked if net.inet.ip.forwarding was actually set to 1. It wasn't, even though sysctl.conf had it set. After re-applying it, things started to work again=85 Best Regards, Rainer= From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 21:11:12 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 E6EC33F0 for ; Tue, 18 Jun 2013 21:11:12 +0000 (UTC) (envelope-from javad.kouhi@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6C39E133B for ; Tue, 18 Jun 2013 21:11:12 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id v1so4084736lbd.32 for ; Tue, 18 Jun 2013 14:11:11 -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=zRfhp0H8YYNmFwmxjewo4LqZBxI5E3n5gLWzJfplTFk=; b=PvoFEdDlst1u2BWe/mK7Yzb0Zqcg32GBU92kV7m4uYXNjfGwSPvyRiQzOOkeChh6dS TcbaOCNEBec2/AyUZYRb6qTzrENfGWW5lzMvsLoUs/eDDa6y1nPuIZqdd30pAniTcczz LT8sB8GGq2jCBcaI+s7gjJvESAxRs8N4yghxMSSuik1M8I+y8a9Ztm2yMIMviEd9oDUg p6qn08b+VyTOwv3yraCZMi2/6ByKIVHes0t2/QuWcxfk/A63iECRPEXPdqsJz0tBr8D6 53ZtmIQFpBf8lmV5+SZDQpHUA81EPK6vuJDlZvHoAXeAnLBuj8DFIpFq6gbUWBck5DR/ L/iA== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr5853541laa.36.1371589870965; Tue, 18 Jun 2013 14:11:10 -0700 (PDT) Received: by 10.114.19.236 with HTTP; Tue, 18 Jun 2013 14:11:10 -0700 (PDT) In-Reply-To: <20130618182538.GA3380@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> <20130618182538.GA3380@icarus.home.lan> Date: Wed, 19 Jun 2013 01:41:10 +0430 Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Javad Kouhi To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: Michiel Boland , 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, 18 Jun 2013 21:11:13 -0000 I've read the posts again. Although the issue looks same as Michiel Boland (first link) but I'm not sure if the root of the issue is same as Michiel's too (second link). Anyway, it should be discussed in another thread as you said. > Second, the patch is not mine -- it's Konstantin's. I did not write the > code/fix, nor do I understand it. All I did was provide a version of > the same patch that applied cleanly on recent stable/9. (I'm sorry for > needing to state this, but clear ownership of code/issues is important.) That's understandable, thank you both. I didn't mean it that way. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 21:23: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 4605C9C3; Tue, 18 Jun 2013 21:23:03 +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 DB4961451; Tue, 18 Jun 2013 21:23:02 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::9922:25be:52a5:20a0] (unknown [IPv6:2001:7b8:3a7:0:9922:25be:52a5:20a0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1D5FC5C44; Tue, 18 Jun 2013 23:22:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: include/c++/v1 still in BSD.include.dist as well as in obsolete_files From: Dimitry Andric In-Reply-To: Date: Tue, 18 Jun 2013 23:22:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Kevin Oberman X-Mailer: Apple Mail (2.1508) Cc: Brooks Davis , "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: Tue, 18 Jun 2013 21:23:03 -0000 On Jun 18, 2013, at 21:03, Kevin Oberman wrote: > When I run "make check-old, the /usr/include/c++/v1 and v1/ext directories > are listed as old, but they are still present in BSD.include.dist, so are > recreated every time I installworld. > > Could these directories be removed from BSD.include.dist, as I am pretty > sure that they ARE obsolete. They are not obsolete, as they are part of libc++, but I don't think it is already possible to have parts of mtree files depend on WITH_XXX settings. So we can either remove the directories (but not the files) from ObsoleteFiles.inc, or attempt to amend mtree so it can handle conditional parts. Brooks, any idea if NetBSD's mtree supports that feature? :-) -Dimitry From owner-freebsd-stable@FreeBSD.ORG Tue Jun 18 21:28:33 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 86DD6149 for ; Tue, 18 Jun 2013 21:28:33 +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 118B815EB for ; Tue, 18 Jun 2013 21:28:33 +0000 (UTC) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5F24BA80B8; Tue, 18 Jun 2013 23:28:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eolomlAtjEFO; Tue, 18 Jun 2013 23:28: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 739B5A80BE; Tue, 18 Jun 2013 23:28:20 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 91DB173A1C; Tue, 18 Jun 2013 14:28:18 -0700 (PDT) Date: Tue, 18 Jun 2013 14:28:18 -0700 From: Jeremy Chadwick To: Javad Kouhi Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG Message-ID: <20130618212818.GA58803@icarus.home.lan> References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> <20130618182538.GA3380@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: Michiel Boland , 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, 18 Jun 2013 21:28:33 -0000 On Wed, Jun 19, 2013 at 01:41:10AM +0430, Javad Kouhi wrote: > I've read the posts again. Although the issue looks same as Michiel > Boland (first link) but I'm not sure if the root of the issue is same > as Michiel's too (second link). Anyway, it should be discussed in > another thread as you said. Let me be more clear: I have seen repeated reports from people complaining about "lockups when shutting down" many times over the years. The ones I remember: - Certain oddities with SCSI/SATA storage drivers and disks (many of these have been fixed) - ACPI-based reboot not working correctly on some motherboards (depends on hw.acpi.handle_reboot and sometimes hw.acpi.disable_on_reboot) -- not sure if this still pops up - USB layer causing issues, or possibly some USB CAM integration problem (this is still an ongoing one) - Now some sort of weird Intel graphics driver (and DRM?) quirk involving moused(8) and Vsync (the issue reported by Michiel) And I'm certain I'm forgetting others. What Kevin Oberman said also applies -- these are painful to debug because the system is already in a "shutting down" state where usability and accessibility becomes bare minimal, and you're kind of at your wits end. Booting verbose can help -- there are other messages printed to the VGA (and/or serial) console during the shutdown phase when verbose. All you can hope for is that the kernel is still alive and Ctrl-Alt-Esc to force a drop to DDB (assuming all of this is enabled in your kernel) works and that someone familiar with the FreeBSD kernel can help you debug it (possibly it's just easier to do that, type "panic", then issue "call doadump" to force a dump to swap at that point -- kib@ might have better recommendations). Serial console can also greatly help, because quite often there are pages upon pages of debugging information that are useful, otherwise you have to hope the VGA console keyboard is functional (even more tricky with USB) and that Scroll Lock + Page Up/Down function along with taking photos of the screen; doing it this way is stressful and painful for everyone involved. I hope this sheds some light on why I said what I did. :-) -- | 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 Jun 18 22:29:58 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 630DBEE2; Tue, 18 Jun 2013 22:29:58 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8D91856; Tue, 18 Jun 2013 22:29:57 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r5IMTuKs002130; Tue, 18 Jun 2013 17:29:56 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id r5IMTuu2002129; Tue, 18 Jun 2013 17:29:56 -0500 (CDT) (envelope-from brooks) Date: Tue, 18 Jun 2013 17:29:56 -0500 From: Brooks Davis To: Dimitry Andric Subject: Re: include/c++/v1 still in BSD.include.dist as well as in obsolete_files Message-ID: <20130618222956.GA1447@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kevin Oberman , Brooks Davis , "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: Tue, 18 Jun 2013 22:29:58 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 18, 2013 at 11:22:55PM +0200, Dimitry Andric wrote: > On Jun 18, 2013, at 21:03, Kevin Oberman wrote: > > When I run "make check-old, the /usr/include/c++/v1 and v1/ext director= ies > > are listed as old, but they are still present in BSD.include.dist, so a= re > > recreated every time I installworld. > >=20 > > Could these directories be removed from BSD.include.dist, as I am pretty > > sure that they ARE obsolete. >=20 > They are not obsolete, as they are part of libc++, but I don't think it > is already possible to have parts of mtree files depend on WITH_XXX > settings. So we can either remove the directories (but not the files) > from ObsoleteFiles.inc, or attempt to amend mtree so it can handle > conditional parts. >=20 > Brooks, any idea if NetBSD's mtree supports that feature? :-) It doesn't. The only way to do this currently is to create separate mtree files for each set of option directories. In the current world order this sucks because each parent directly must be specified with correct permissions so there's lots of opportunity to break things. I'm hoping to fix that some time soon by switch to new-format mtree files. You'd still have to use separate files, but at least they would only contain the relevant directories. -- Brooks --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRwN9jXY6L6fI4GtQRAtiMAJ9rdxaGTSclkYeKNkvtfcwYqFA6EwCg5Ng+ PiuJb0o4dl2MDThZCRPdWEs= =TvZg -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 01:03:52 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 B0F172A4; Wed, 19 Jun 2013 01:03:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 78A691F25; Wed, 19 Jun 2013 01:03:52 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5J13pf0004199; Wed, 19 Jun 2013 01:03:51 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5J13pE7004195; Wed, 19 Jun 2013 01:03:51 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Jun 2013 01:03:51 GMT Message-Id: <201306190103.r5J13pE7004195@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 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: Wed, 19 Jun 2013 01:03:52 -0000 TB --- 2013-06-18 22:51:34 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-18 22:51:34 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-18 22:51:34 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-06-18 22:51:34 - cleaning the object tree TB --- 2013-06-18 22:52:01 - /usr/local/bin/svn stat /src TB --- 2013-06-18 22:52:30 - At svn revision 251958 TB --- 2013-06-18 22:52:31 - building world TB --- 2013-06-18 22:52:31 - CROSS_BUILD_TESTING=YES TB --- 2013-06-18 22:52:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-18 22:52:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-18 22:52:31 - SRCCONF=/dev/null TB --- 2013-06-18 22:52:31 - TARGET=ia64 TB --- 2013-06-18 22:52:31 - TARGET_ARCH=ia64 TB --- 2013-06-18 22:52:31 - TZ=UTC TB --- 2013-06-18 22:52:31 - __MAKE_CONF=/dev/null TB --- 2013-06-18 22:52:31 - cd /src TB --- 2013-06-18 22:52:31 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 18 22:52:32 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jun 19 00:39:04 UTC 2013 TB --- 2013-06-19 00:39:04 - generating LINT kernel config TB --- 2013-06-19 00:39:04 - cd /src/sys/ia64/conf TB --- 2013-06-19 00:39:04 - /usr/bin/make -B LINT TB --- 2013-06-19 00:39:04 - cd /src/sys/ia64/conf TB --- 2013-06-19 00:39:04 - /usr/sbin/config -m LINT TB --- 2013-06-19 00:39:04 - building LINT kernel TB --- 2013-06-19 00:39:04 - CROSS_BUILD_TESTING=YES TB --- 2013-06-19 00:39:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-19 00:39:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-19 00:39:04 - SRCCONF=/dev/null TB --- 2013-06-19 00:39:04 - TARGET=ia64 TB --- 2013-06-19 00:39:04 - TARGET_ARCH=ia64 TB --- 2013-06-19 00:39:04 - TZ=UTC TB --- 2013-06-19 00:39:04 - __MAKE_CONF=/dev/null TB --- 2013-06-19 00:39:04 - cd /src TB --- 2013-06-19 00:39:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 19 00:39:04 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia32/ia32_trap.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/bus_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/busdma_machdep.c /src/sys/ia64/ia64/busdma_machdep.c: In function '_bus_dmamap_count_phys': /src/sys/ia64/ia64/busdma_machdep.c:490: error: 'paddr_max' undeclared (first use in this function) /src/sys/ia64/ia64/busdma_machdep.c:490: error: (Each undeclared identifier is reported only once /src/sys/ia64/ia64/busdma_machdep.c:490: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-19 01:03:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-19 01:03:51 - ERROR: failed to build LINT kernel TB --- 2013-06-19 01:03:51 - 5902.98 user 709.35 system 7937.58 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 10:35:28 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 DF4C7B23; Wed, 19 Jun 2013 10:35:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id A8B9E17CE; Wed, 19 Jun 2013 10:35:28 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5JAZR6o060240; Wed, 19 Jun 2013 10:35:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5JAZRiO060223; Wed, 19 Jun 2013 10:35:27 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Jun 2013 10:35:27 GMT Message-Id: <201306191035.r5JAZRiO060223@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 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: Wed, 19 Jun 2013 10:35:29 -0000 TB --- 2013-06-19 08:42:19 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-19 08:42:19 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-19 08:42:19 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-06-19 08:42:19 - cleaning the object tree TB --- 2013-06-19 08:42:39 - /usr/local/bin/svn stat /src TB --- 2013-06-19 08:43:12 - At svn revision 251990 TB --- 2013-06-19 08:43:13 - building world TB --- 2013-06-19 08:43:13 - CROSS_BUILD_TESTING=YES TB --- 2013-06-19 08:43:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-19 08:43:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-19 08:43:13 - SRCCONF=/dev/null TB --- 2013-06-19 08:43:13 - TARGET=ia64 TB --- 2013-06-19 08:43:13 - TARGET_ARCH=ia64 TB --- 2013-06-19 08:43:13 - TZ=UTC TB --- 2013-06-19 08:43:13 - __MAKE_CONF=/dev/null TB --- 2013-06-19 08:43:13 - cd /src TB --- 2013-06-19 08:43:13 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 19 08:43:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jun 19 10:29:46 UTC 2013 TB --- 2013-06-19 10:29:46 - generating LINT kernel config TB --- 2013-06-19 10:29:46 - cd /src/sys/ia64/conf TB --- 2013-06-19 10:29:46 - /usr/bin/make -B LINT TB --- 2013-06-19 10:29:47 - cd /src/sys/ia64/conf TB --- 2013-06-19 10:29:47 - /usr/sbin/config -m LINT TB --- 2013-06-19 10:29:47 - building LINT kernel TB --- 2013-06-19 10:29:47 - CROSS_BUILD_TESTING=YES TB --- 2013-06-19 10:29:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-19 10:29:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-19 10:29:47 - SRCCONF=/dev/null TB --- 2013-06-19 10:29:47 - TARGET=ia64 TB --- 2013-06-19 10:29:47 - TARGET_ARCH=ia64 TB --- 2013-06-19 10:29:47 - TZ=UTC TB --- 2013-06-19 10:29:47 - __MAKE_CONF=/dev/null TB --- 2013-06-19 10:29:47 - cd /src TB --- 2013-06-19 10:29:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 19 10:29:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/advansys/adwmcode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ae/if_ae.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/age/if_age.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/agp/agp.c /src/sys/dev/agp/agp.c: In function 'agp_generic_attach': /src/sys/dev/agp/agp.c:238: error: 'Maxmem' undeclared (first use in this function) /src/sys/dev/agp/agp.c:238: error: (Each undeclared identifier is reported only once /src/sys/dev/agp/agp.c:238: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-19 10:35:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-19 10:35:27 - ERROR: failed to build LINT kernel TB --- 2013-06-19 10:35:27 - 4943.86 user 658.59 system 6787.63 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 11:41: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 97BA6EBA for ; Wed, 19 Jun 2013 11:41:43 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp163.dfw.emailsrvr.com (smtp163.dfw.emailsrvr.com [67.192.241.163]) by mx1.freebsd.org (Postfix) with ESMTP id 69D4B1AB8 for ; Wed, 19 Jun 2013 11:41:43 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 1B0A9270A6D for ; Wed, 19 Jun 2013 07:36:05 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com [108.166.43.115]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id C903E270A81 for ; Wed, 19 Jun 2013 07:36:04 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 009071B814F for ; Wed, 19 Jun 2013 07:35:57 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id 942181B81A8 for ; Wed, 19 Jun 2013 07:35:56 -0400 (EDT) Message-ID: <51C1979D.3010305@ateamsystems.com> Date: Wed, 19 Jun 2013 18:35:57 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount 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, 19 Jun 2013 11:41:43 -0000 Hello -STABLE@, So I've seen this situation seemingly randomly on a number of both physical 9.1 boxes as well as VMs for I would say 6-9 months at least. I finally have a physical box here that reproduces it consistently that I can reboot easily (ie; not a production/client server). No matter what I do: reboot shutdown -p shutdown -r This specific server will stop at "All buffers synced" and not actually power down or reboot. KB input seems to be ignored. This server is a ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show this are using GMIRRORs for root/swap/boot (no ZFS). Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg When I reset the server it appears that disks were not dismounted cleanly ... on this ZFS box it comes back quick because ZFS is good like that but on the other servers with GMIRROR roots rebuilding the GMIRROR and fscking at the same time is murder on the disk/performance until it finishes. Another interesting thing is that this particular server runs slapd (OpenLDAP) which, when it comes back up, has a "corrupted" DB (easily fixed with db_recover, but still). This might be because FS commits aren't happening at the end. I can even manually stop slapd (service slapd stop) then run sync(8) (I assume this does something for ZFS too) and it still comes back as hosed if I reboot shortly after. If I start/stop slapd it's fine. So I feel like there is an FS/dismount thing going on here. Additional information: I also have some boxes which will reboot (ie; they don't freeze like some do at the end) but they don't dismount cleanly either and have to rebuild both GMIRROR and fsck. This might be a different issue, too. Anyone have any thoughts? Let me know if I can provide more details etc. -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 12:21:59 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 615BED74 for ; Wed, 19 Jun 2013 12:21:59 +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 DD52F1D40 for ; Wed, 19 Jun 2013 12:21:58 +0000 (UTC) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B7AAAA80F0; Wed, 19 Jun 2013 14:21:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IDUPL15MSMFb; Wed, 19 Jun 2013 14:21: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 relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7969EA80C0; Wed, 19 Jun 2013 14:21:45 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6BAA773A1C; Wed, 19 Jun 2013 05:21:43 -0700 (PDT) Date: Wed, 19 Jun 2013 05:21:43 -0700 From: Jeremy Chadwick To: Adam Strohl Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619122143.GA70813@icarus.home.lan> References: <51C1979D.3010305@ateamsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1979D.3010305@ateamsystems.com> 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: Wed, 19 Jun 2013 12:21:59 -0000 On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: > Hello -STABLE@, > > So I've seen this situation seemingly randomly on a number of both > physical 9.1 boxes as well as VMs for I would say 6-9 months at > least. I finally have a physical box here that reproduces it > consistently that I can reboot easily (ie; not a production/client > server). > > No matter what I do: > > reboot > shutdown -p > shutdown -r > > This specific server will stop at "All buffers synced" and not > actually power down or reboot. KB input seems to be ignored. This > server is a ZFS NAS (with GMIRROR for boot blocks) but the other > boxes which show this are using GMIRRORs for root/swap/boot (no > ZFS). > > Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg > > When I reset the server it appears that disks were not dismounted > cleanly ... on this ZFS box it comes back quick because ZFS is good > like that but on the other servers with GMIRROR roots rebuilding the > GMIRROR and fscking at the same time is murder on the > disk/performance until it finishes. 1. You mention "as well as VMs". Anything under a "virtual machine" or under a hypervisor is going to be very, very, **VERY** different than bare metal. So I hope the issues you're talking about above are on bare metal -- I will assume so. 2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. If you use stable/9 (RELENG_9) we need to see uname -a output (you can hide the machine name if you want). 3. Can we please have dmesg from this machine? The controller and some other hardware details matter. 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? 5. Does "sysctl hw.acpi.handle_reboot=1" help you? 6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? 7. If none of the above helps, can you please boot verbose mode and then when the system "locks up" on "shutdown -r now" take a picture of the VGA console? 8. Does the machine run moused(8) (check the process list please, do not rely on rc.conf) ? > Another interesting thing is that this particular server runs slapd > (OpenLDAP) which, when it comes back up, has a "corrupted" DB > (easily fixed with db_recover, but still). This might be because FS > commits aren't happening at the end. I can even manually stop > slapd (service slapd stop) then run sync(8) (I assume this does > something for ZFS too) and it still comes back as hosed if I reboot > shortly after. If I start/stop slapd it's fine. So I feel like > there is an FS/dismount thing going on here. sync(8) does not do what you think it does. Please read (not skim) this entire thread starting here: http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982 http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html Your problem is related to unclean shutdown; fix that and your issues go away. > Additional information: I also have some boxes which will reboot > (ie; they don't freeze like some do at the end) but they don't > dismount cleanly either and have to rebuild both GMIRROR and fsck. > This might be a different issue, too. Every issue needs to be handled/treated separately. -- | 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 Wed Jun 19 12:23: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 B3FACF22 for ; Wed, 19 Jun 2013 12:23:57 +0000 (UTC) (envelope-from prvs=1882457d64=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 43D3F1D67 for ; Wed, 19 Jun 2013 12:23:56 +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 md50004422421.msg for ; Wed, 19 Jun 2013 13:23:50 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 13:23:50 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <25FD8669685245B78692011930EBA77A@multiplay.co.uk> From: "Steven Hartland" To: "Adam Strohl" , References: <51C1979D.3010305@ateamsystems.com> Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Date: Wed, 19 Jun 2013 13:23:59 +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 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, 19 Jun 2013 12:23:57 -0000 OS version? ----- Original Message ----- From: "Adam Strohl" To: Sent: Wednesday, June 19, 2013 12:35 PM Subject: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount > Hello -STABLE@, > > So I've seen this situation seemingly randomly on a number of both > physical 9.1 boxes as well as VMs for I would say 6-9 months at least. > I finally have a physical box here that reproduces it consistently > that I can reboot easily (ie; not a production/client server). > > No matter what I do: > > reboot > shutdown -p > shutdown -r > > This specific server will stop at "All buffers synced" and not actually > power down or reboot. KB input seems to be ignored. This server is a > ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show > this are using GMIRRORs for root/swap/boot (no ZFS). > > Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg > > When I reset the server it appears that disks were not dismounted > cleanly ... on this ZFS box it comes back quick because ZFS is good like > that but on the other servers with GMIRROR roots rebuilding the GMIRROR > and fscking at the same time is murder on the disk/performance until it > finishes. > > Another interesting thing is that this particular server runs slapd > (OpenLDAP) which, when it comes back up, has a "corrupted" DB (easily > fixed with db_recover, but still). This might be because FS commits > aren't happening at the end. I can even manually stop slapd (service > slapd stop) then run sync(8) (I assume this does something for ZFS too) > and it still comes back as hosed if I reboot shortly after. If I > start/stop slapd it's fine. So I feel like there is an FS/dismount > thing going on here. > > Additional information: I also have some boxes which will reboot (ie; > they don't freeze like some do at the end) but they don't dismount > cleanly either and have to rebuild both GMIRROR and fsck. This might be > a different issue, too. > > Anyone have any thoughts? Let me know if I can provide more details etc. > > -- > Adam Strohl > http://www.ateamsystems.com/ > _______________________________________________ > 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" > ================================================ 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 Wed Jun 19 12:53: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 6BD0F729 for ; Wed, 19 Jun 2013 12:53:27 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp107.ord1c.emailsrvr.com (smtp107.ord1c.emailsrvr.com [108.166.43.107]) by mx1.freebsd.org (Postfix) with ESMTP id 3E95F1EF1 for ; Wed, 19 Jun 2013 12:53:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DD0D5981AE for ; Wed, 19 Jun 2013 08:53:19 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id 7997B981A2 for ; Wed, 19 Jun 2013 08:53:17 -0400 (EDT) Message-ID: <51C1A9BF.8030304@ateamsystems.com> Date: Wed, 19 Jun 2013 19:53:19 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> In-Reply-To: <20130619122143.GA70813@icarus.home.lan> 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, 19 Jun 2013 12:53:27 -0000 On 6/19/2013 19:21, Jeremy Chadwick wrote: > On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: >> Hello -STABLE@, >> >> So I've seen this situation seemingly randomly on a number of both >> physical 9.1 boxes as well as VMs for I would say 6-9 months at >> least. I finally have a physical box here that reproduces it >> consistently that I can reboot easily (ie; not a production/client >> server). >> >> No matter what I do: >> >> reboot >> shutdown -p >> shutdown -r >> >> This specific server will stop at "All buffers synced" and not >> actually power down or reboot. KB input seems to be ignored. This >> server is a ZFS NAS (with GMIRROR for boot blocks) but the other >> boxes which show this are using GMIRRORs for root/swap/boot (no >> ZFS). >> >> Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg >> >> When I reset the server it appears that disks were not dismounted >> cleanly ... on this ZFS box it comes back quick because ZFS is good >> like that but on the other servers with GMIRROR roots rebuilding the >> GMIRROR and fscking at the same time is murder on the >> disk/performance until it finishes. > > 1. You mention "as well as VMs". Anything under a "virtual machine" or > under a hypervisor is going to be very, very, **VERY** different than > bare metal. So I hope the issues you're talking about above are on bare > metal -- I will assume so. Nope, I see basically the same thing sometimes under ESXi 5.0 Hypervisor (and yes it worries me the implications of something so broad). Those unites I just haven't been able to isolate on a server which isn't critical. Lets focus on this server for now though per your suggestion below. > > 2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. > If you use stable/9 (RELENG_9) we need to see uname -a output (you can > hide the machine name if you want). Sorry, this ZFS box is 9.1-R P4 (kernel built today): FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun 19 15:31:12 ICT 2013 root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS amd64 > > 3. Can we please have dmesg from this machine? The controller and some > other hardware details matter. Sure take a look at the full log here: http://pastebin.com/k55gVVuU This includes a boot, then a reboot as I describe (you can see it logs the All Buffers Synced, etc) then powering back on. > > 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? Weirdly this allowed it to reboot on the first try (without needing to be reset), but not the second. The "Starting background file system checks in 60 seconds" message appeared ... that only happens when something is dirty, right? So the second try with just this I could ctrl alt del it and it responded .. kind of: http://i.imgur.com/POAIaNg.jpg Still had to reset it though. > > 5. Does "sysctl hw.acpi.handle_reboot=1" help you? No change, still responded to a ctrl alt del like above, but like that still needs to be reset and comes back dirty. > > 6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? No change. Same as above, ctrl alt del responds but needs a hard reset still. > > 7. If none of the above helps, can you please boot verbose mode and then > when the system "locks up" on "shutdown -r now" take a picture of the > VGA console? Lots of debug on boot obviously but not much different on shutdown/hang: http://i.imgur.com/SgzSsoP.jpg > > 8. Does the machine run moused(8) (check the process list please, do not > rely on rc.conf) ? ps -auxww | grep moused reveals nothing running (which is how I have things set). > >> Another interesting thing is that this particular server runs slapd >> (OpenLDAP) which, when it comes back up, has a "corrupted" DB >> (easily fixed with db_recover, but still). This might be because FS >> commits aren't happening at the end. I can even manually stop >> slapd (service slapd stop) then run sync(8) (I assume this does >> something for ZFS too) and it still comes back as hosed if I reboot >> shortly after. If I start/stop slapd it's fine. So I feel like >> there is an FS/dismount thing going on here. > > sync(8) does not do what you think it does. Please read (not skim) this > entire thread starting here: > > http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982 > http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html Groking this now .. > > Your problem is related to unclean shutdown; fix that and your issues go > away. Yeah that is my feeling as well. > >> Additional information: I also have some boxes which will reboot >> (ie; they don't freeze like some do at the end) but they don't >> dismount cleanly either and have to rebuild both GMIRROR and fsck. >> This might be a different issue, too. > > Every issue needs to be handled/treated separately. Sure, I just had run across some threads about that but will focus on this ZFS box (and see if anything that fixes here does anything with that once I can reliably reproduce it out of production). > -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 13:01:16 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 16E8EB96 for ; Wed, 19 Jun 2013 13:01:16 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id D7A841F6F for ; Wed, 19 Jun 2013 13:01:15 +0000 (UTC) Received: from dottie.dus.openit.net (dottie.dus.openit.net [IPv6:2001:aa8:fff3::fffd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id 5BA0D14E80 for ; Wed, 19 Jun 2013 15:01:14 +0200 (CEST) From: =?iso-8859-1?Q?Dennis_K=F6gel?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Date: Wed, 19 Jun 2013 15:01:14 +0200 Message-Id: To: freebsd-stable@freebsd.org 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: Wed, 19 Jun 2013 13:01:16 -0000 Hi, very periodically, we see I/O hangs for about 10 seconds, roughly once = per minute. Each time this happens, the I/O rate simply drops to zero, and all disk = access hangs; this is also very noticeable on the shell, for NFS clients = etc. Everything else (networking, kernel, =85) seems to continue = normally. Environment: FreeBSD 9.1R GENERIC on amd64, using ZFS, on a ARC1320 PCIe = with 24x Seagate ST33000650SS (3rd party arcsas.ko driver). It's easy to observe these hangs under write load, e.g. with 'zpool = iostat 1': void 22.4T 42.6T 34 2.73K 1.07M 293M void 22.4T 42.6T 20 2.74K 623K 289M void 22.4T 42.6T 144 2.62K 4.83M 279M void 22.4T 42.6T 13 2.60K 437K 283M void 22.4T 42.6T 0 0 0 0 <-- hang starts void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 0 0 0 void 22.4T 42.6T 0 296 4.00K 34.2M <-- hang ends void 22.4T 42.6T 2 2.64K 73.8K 288M void 22.4T 42.6T 8 3.12K 278K 329M Each time this happens, there is a completely unexplained spike of = interrupts on uhci0: 'systat -vm' then displays numbers around 270k. # vmstat -i | grep -E '(arcsas|uhci0|Total)' irq16: uhci0 1227020890 67708 irq24: arcsas0 12045211 664 Total 1266417827 69882 Things to note: - Booting an USB-less kernel or disabling all USB in the BIOS doesn't = change a thing (no interrupt spikes to be seen, but the hangs remain) - The hangs / interrupt spikes happen just as often when the system is = idle - Board is a Supermicro x8dth - There's two igb cards - Root is ZFS as well (separate pool though) - BIOS, Areca FW and driver already are latest versions - Putting the controller to a different slot doesn't change the = behaviour - We have two identical systems and both show the exact same symptoms, = so flaky hardware is probably not the issue Any ideas would be appreciated. Thanks, D.= From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 13:02:14 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 6DC95CAE for ; Wed, 19 Jun 2013 13:02:14 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp163.dfw.emailsrvr.com (smtp163.dfw.emailsrvr.com [67.192.241.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6F91F8F for ; Wed, 19 Jun 2013 13:02:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B16CC2704B9 for ; Wed, 19 Jun 2013 09:02:13 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp75.ord1c.emailsrvr.com (smtp75.ord1c.emailsrvr.com [108.166.43.75]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id EADD62705AA for ; Wed, 19 Jun 2013 09:02:12 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B8DE11E80DC for ; Wed, 19 Jun 2013 09:02:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id C88651E837E for ; Wed, 19 Jun 2013 09:01:41 -0400 (EDT) Message-ID: <51C1ABB5.6@ateamsystems.com> Date: Wed, 19 Jun 2013 20:01:41 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> In-Reply-To: <51C1A9BF.8030304@ateamsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 13:02:14 -0000 On 6/19/2013 19:53, Adam Strohl wrote: >> sync(8) does not do what you think it does. Please read (not skim) this >> entire thread starting here: >> >> http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982 >> >> http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html > > Groking this now .. Epic. So basically "mount -u -o ro " is really what I (and probably everyone else) wants and the man page needs a major overhaul + disclaimer (and possibly a recommendation to use "mount -u -o ro " instead). -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 13:15: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 5A9D0406 for ; Wed, 19 Jun 2013 13:15:11 +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 E84EA10C3 for ; Wed, 19 Jun 2013 13:15:09 +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 1UpHyi-0003gO-PJ; Wed, 19 Jun 2013 14:59:14 +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 1UpHyi-0006RP-LX; Wed, 19 Jun 2013 14:59:12 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "Adam Strohl" Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> Date: Wed, 19 Jun 2013 14:59:10 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <51C1A9BF.8030304@ateamsystems.com> User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: f0e1c9854a9562d49e95611d158cd3d0 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, 19 Jun 2013 13:15:11 -0000 On Wed, 19 Jun 2013 14:53:19 +0200, Adam Strohl wrote: > On 6/19/2013 19:21, Jeremy Chadwick wrote: >> On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: >>> Hello -STABLE@, >>> >>> So I've seen this situation seemingly randomly on a number of both >>> physical 9.1 boxes as well as VMs for I would say 6-9 months at >>> least. I finally have a physical box here that reproduces it >>> consistently that I can reboot easily (ie; not a production/client >>> server). Hi, My home computer had the same symptom (not rebooting after 'all buffers flushed' message) a couple of months ago. But I follow 9-STABLE and the problem is gone for a while now. Ronald. >>> >>> No matter what I do: >>> >>> reboot >>> shutdown -p >>> shutdown -r >>> >>> This specific server will stop at "All buffers synced" and not >>> actually power down or reboot. KB input seems to be ignored. This >>> server is a ZFS NAS (with GMIRROR for boot blocks) but the other >>> boxes which show this are using GMIRRORs for root/swap/boot (no >>> ZFS). >>> >>> Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg >>> >>> When I reset the server it appears that disks were not dismounted >>> cleanly ... on this ZFS box it comes back quick because ZFS is good >>> like that but on the other servers with GMIRROR roots rebuilding the >>> GMIRROR and fscking at the same time is murder on the >>> disk/performance until it finishes. >> >> 1. You mention "as well as VMs". Anything under a "virtual machine" or >> under a hypervisor is going to be very, very, **VERY** different than >> bare metal. So I hope the issues you're talking about above are on bare >> metal -- I will assume so. > > Nope, I see basically the same thing sometimes under ESXi 5.0 Hypervisor > (and yes it worries me the implications of something so broad). Those > unites I just haven't been able to isolate on a server which isn't > critical. Lets focus on this server for now though per your suggestion > below. > >> >> 2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. >> If you use stable/9 (RELENG_9) we need to see uname -a output (you can >> hide the machine name if you want). > > Sorry, this ZFS box is 9.1-R P4 (kernel built today): > > FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun 19 > 15:31:12 ICT 2013 root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS > amd64 > >> >> 3. Can we please have dmesg from this machine? The controller and some >> other hardware details matter. > > Sure take a look at the full log here: http://pastebin.com/k55gVVuU > > This includes a boot, then a reboot as I describe (you can see it logs > the All Buffers Synced, etc) then powering back on. > >> >> 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? > > Weirdly this allowed it to reboot on the first try (without needing to > be reset), but not the second. The "Starting background file system > checks in 60 seconds" message appeared ... that only happens when > something is dirty, right? > > So the second try with just this I could ctrl alt del it and it > responded .. kind of: > http://i.imgur.com/POAIaNg.jpg > > Still had to reset it though. > >> >> 5. Does "sysctl hw.acpi.handle_reboot=1" help you? > > No change, still responded to a ctrl alt del like above, but like that > still needs to be reset and comes back dirty. > >> >> 6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? > > No change. Same as above, ctrl alt del responds but needs a hard reset > still. > >> >> 7. If none of the above helps, can you please boot verbose mode and then >> when the system "locks up" on "shutdown -r now" take a picture of the >> VGA console? > > Lots of debug on boot obviously but not much different on shutdown/hang: > http://i.imgur.com/SgzSsoP.jpg > >> >> 8. Does the machine run moused(8) (check the process list please, do not >> rely on rc.conf) ? > > ps -auxww | grep moused reveals nothing running (which is how I have > things set). > >> >>> Another interesting thing is that this particular server runs slapd >>> (OpenLDAP) which, when it comes back up, has a "corrupted" DB >>> (easily fixed with db_recover, but still). This might be because FS >>> commits aren't happening at the end. I can even manually stop >>> slapd (service slapd stop) then run sync(8) (I assume this does >>> something for ZFS too) and it still comes back as hosed if I reboot >>> shortly after. If I start/stop slapd it's fine. So I feel like >>> there is an FS/dismount thing going on here. >> >> sync(8) does not do what you think it does. Please read (not skim) this >> entire thread starting here: >> >> http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982 >> http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html > > Groking this now .. > >> >> Your problem is related to unclean shutdown; fix that and your issues go >> away. > > Yeah that is my feeling as well. > >> >>> Additional information: I also have some boxes which will reboot >>> (ie; they don't freeze like some do at the end) but they don't >>> dismount cleanly either and have to rebuild both GMIRROR and fsck. >>> This might be a different issue, too. >> >> Every issue needs to be handled/treated separately. > > Sure, I just had run across some threads about that but will focus on > this ZFS box (and see if anything that fixes here does anything with > that once I can reliably reproduce it out of production). > >> > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 13:28:45 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 8131DB56 for ; Wed, 19 Jun 2013 13:28:45 +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 1947B11AA for ; Wed, 19 Jun 2013 13:28:44 +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 1UpIRE-00087x-Q0; Wed, 19 Jun 2013 15:28:43 +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 1UpIRF-0008OO-6R; Wed, 19 Jun 2013 15:28:41 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, =?utf-8?Q?Dennis_K=C3=B6gel?= Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) References: Date: Wed, 19 Jun 2013 15:28:39 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 4868b52b90b9144be14ceb212c82ef23 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, 19 Jun 2013 13:28:45 -0000 On Wed, 19 Jun 2013 15:01:14 +0200, Dennis Kögel wrote: > Hi, > > very periodically, we see I/O hangs for about 10 seconds, roughly once > per minute. > > Each time this happens, the I/O rate simply drops to zero, and all disk > access hangs; this is also very noticeable on the shell, for NFS clients > etc. Everything else (networking, kernel, …) seems to continue normally. > > Environment: FreeBSD 9.1R GENERIC on amd64, using ZFS, on a ARC1320 PCIe > with 24x Seagate ST33000650SS (3rd party arcsas.ko driver). > > It's easy to observe these hangs under write load, e.g. with 'zpool > iostat 1': > > void 22.4T 42.6T 34 2.73K 1.07M 293M > void 22.4T 42.6T 20 2.74K 623K 289M > void 22.4T 42.6T 144 2.62K 4.83M 279M > void 22.4T 42.6T 13 2.60K 437K 283M > void 22.4T 42.6T 0 0 0 0 <-- hang starts > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 0 0 0 > void 22.4T 42.6T 0 296 4.00K 34.2M <-- hang ends > void 22.4T 42.6T 2 2.64K 73.8K 288M > void 22.4T 42.6T 8 3.12K 278K 329M > > Each time this happens, there is a completely unexplained spike of > interrupts on uhci0: 'systat -vm' then displays numbers around 270k. > > # vmstat -i | grep -E '(arcsas|uhci0|Total)' > irq16: uhci0 1227020890 67708 > irq24: arcsas0 12045211 664 > Total 1266417827 69882 > > Things to note: > > - Booting an USB-less kernel or disabling all USB in the BIOS doesn't > change a thing (no interrupt spikes to be seen, but the hangs remain) > - The hangs / interrupt spikes happen just as often when the system is > idle > - Board is a Supermicro x8dth > - There's two igb cards > - Root is ZFS as well (separate pool though) > - BIOS, Areca FW and driver already are latest versions > - Putting the controller to a different slot doesn't change the behaviour > - We have two identical systems and both show the exact same symptoms, > so flaky hardware is probably not the issue > > Any ideas would be appreciated. > > Thanks, > D. First send more information about the system: - The content of /var/run/dmesg.boot. - Install /usr/ports/sysutils/zfs-stats and send the output of zfs-stats -a. - Send the output of zpool status + zpool list. - Did you configure compression or dedup on the pool? - Do you keep a lot of snapshots? - Do you run a cronjob every minute which does something with the pool? Gathers statistics or something like that. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 13:36: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 DBA101A4 for ; Wed, 19 Jun 2013 13:36:02 +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 C6A2B120C for ; Wed, 19 Jun 2013 13:36:01 +0000 (UTC) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1EBCD41C08F; Wed, 19 Jun 2013 15:35:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aHM13fDBbeIo; Wed, 19 Jun 2013 15:35:41 +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 DD1BF41C076; Wed, 19 Jun 2013 15:35:40 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id C1C1273A1C; Wed, 19 Jun 2013 06:35:38 -0700 (PDT) Date: Wed, 19 Jun 2013 06:35:38 -0700 From: Jeremy Chadwick To: Adam Strohl Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619133538.GA71689@icarus.home.lan> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1A9BF.8030304@ateamsystems.com> 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: Wed, 19 Jun 2013 13:36:03 -0000 On Wed, Jun 19, 2013 at 07:53:19PM +0700, Adam Strohl wrote: > On 6/19/2013 19:21, Jeremy Chadwick wrote: > >On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: > >>Hello -STABLE@, > >> > >>So I've seen this situation seemingly randomly on a number of both > >>physical 9.1 boxes as well as VMs for I would say 6-9 months at > >>least. I finally have a physical box here that reproduces it > >>consistently that I can reboot easily (ie; not a production/client > >>server). > >> > >>No matter what I do: > >> > >>reboot > >>shutdown -p > >>shutdown -r > >> > >>This specific server will stop at "All buffers synced" and not > >>actually power down or reboot. KB input seems to be ignored. This > >>server is a ZFS NAS (with GMIRROR for boot blocks) but the other > >>boxes which show this are using GMIRRORs for root/swap/boot (no > >>ZFS). > >> > >>Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg > >> > >>When I reset the server it appears that disks were not dismounted > >>cleanly ... on this ZFS box it comes back quick because ZFS is good > >>like that but on the other servers with GMIRROR roots rebuilding the > >>GMIRROR and fscking at the same time is murder on the > >>disk/performance until it finishes. > > > >1. You mention "as well as VMs". Anything under a "virtual machine" or > >under a hypervisor is going to be very, very, **VERY** different than > >bare metal. So I hope the issues you're talking about above are on bare > >metal -- I will assume so. > > Nope, I see basically the same thing sometimes under ESXi 5.0 > Hypervisor (and yes it worries me the implications of something so > broad). Those unites I just haven't been able to isolate on a > server which isn't critical. Lets focus on this server for now > though per your suggestion below. I'm sorry but I don't understand your first sentence -- the first part of your sentence says "nope" (I have to assume in reply to my "on bare metal" part), but then says "I see basically the same thing sometimes under ESXi" which implies an alternate environment in comparison (i.e. we *are* talking about bare metal). Consider me confused. :-) > >2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. > >If you use stable/9 (RELENG_9) we need to see uname -a output (you can > >hide the machine name if you want). > > Sorry, this ZFS box is 9.1-R P4 (kernel built today): > > FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun > 19 15:31:12 ICT 2013 > root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS amd64 I suggest trying stable/9 (and staying with it, for that matter). > >3. Can we please have dmesg from this machine? The controller and some > >other hardware details matter. > > Sure take a look at the full log here: http://pastebin.com/k55gVVuU > > This includes a boot, then a reboot as I describe (you can see it > logs the All Buffers Synced, etc) then powering back on. Thanks. I was mainly interested in the storage controller being used (in this case ahci(4)) and the disks being used (notorious ST3000DM001, known for excessively parking heads). AFAIK this isn't one of the controllers that was known for weird "quirky issues" pertaining to flushing data to disk on shutdown. I have to ask: is this FreeBSD box running under a HV? If it *is not* running under a HV, could we please get exact motherboard model and version (including BIOS version)? Sometimes (not always) you can get this from "kenv | grep smbios." I can also see you're running your own kernel. We'll get to that in a moment. > >4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? > > Weirdly this allowed it to reboot on the first try (without needing > to be reset), but not the second. I'm not surprised. Pleas re-try with stable/9; Hans has been constantly working on the USB stack and fixing major bugs. > The "Starting background file > system checks in 60 seconds" message appeared ... that only happens > when something is dirty, right? No it does not. That message is always printed when you use background fsck, which is the default. I do not advocate using background fsck, because it has been known (and may still do this -- I do not care to find out, I do not have time for unreliable filesystem nonsense) to not always fix all filesystem problems. Meaning: people using background fsck have been known to boot into single-user and issue "fsck" manually and find issues. Place background_fsck="no" in /etc/rc.conf. If the machine does not have a clean filesystem on boot-up, you'll know because the system will immediately begin fsck (in the foreground actively). You'll recognise that output if it happens, trust me. > So the second try with just this I could ctrl alt del it and it > responded .. kind of: > http://i.imgur.com/POAIaNg.jpg > > Still had to reset it though. This looks like a chicken-and-egg problem -- you're probably fighting with background fsck, as the message there indicate "some processes would not die". I'm just taking a guess though. I am now going to ask you for more information: 1. "gpart show -p xxx" where xxx is each disk you have in the system 2. gmirror list 3. Any/all details of your gmirror setup or other things you can think of when you set it up 4. Contents of /etc/fstab 5. Contents of /boot/loader.conf 6. Contents of /etc/rc.conf 7. Contents of /etc/sysctl.conf 8. Contents of /sys/amd64/conf/ATEAMSYSTEMS > >5. Does "sysctl hw.acpi.handle_reboot=1" help you? > > No change, still responded to a ctrl alt del like above, but like > that still needs to be reset and comes back dirty. > > > > >6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? > > No change. Same as above, ctrl alt del responds but needs a hard > reset still. Okay, thank you. > >7. If none of the above helps, can you please boot verbose mode and then > >when the system "locks up" on "shutdown -r now" take a picture of the > >VGA console? > > Lots of debug on boot obviously but not much different on shutdown/hang: > http://i.imgur.com/SgzSsoP.jpg It looks to me like the ACPI layer is still actively working at the time "all buffers are synced", meaning the actual reboot phase itself never happens. This to me starts to smell of an ACPI problem, but I do not have the skill set to debug this, and I'm also grasping at straws. There are many things that happen during that phase of operation, particularly the "USB shutdown" phase. But it all depends on your kernel config, which I've now asked for. > >8. Does the machine run moused(8) (check the process list please, do not > >rely on rc.conf) ? > > ps -auxww | grep moused reveals nothing running (which is how I have > things set). Okay thank you. > >>Another interesting thing is that this particular server runs slapd > >>(OpenLDAP) which, when it comes back up, has a "corrupted" DB > >>(easily fixed with db_recover, but still). This might be because FS > >>commits aren't happening at the end. I can even manually stop > >>slapd (service slapd stop) then run sync(8) (I assume this does > >>something for ZFS too) and it still comes back as hosed if I reboot > >>shortly after. If I start/stop slapd it's fine. So I feel like > >>there is an FS/dismount thing going on here. > > > >sync(8) does not do what you think it does. Please read (not skim) this > >entire thread starting here: > > > >http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982 > >http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html > > Groking this now .. > > > > >Your problem is related to unclean shutdown; fix that and your issues go > >away. > > Yeah that is my feeling as well. > > > > >>Additional information: I also have some boxes which will reboot > >>(ie; they don't freeze like some do at the end) but they don't > >>dismount cleanly either and have to rebuild both GMIRROR and fsck. > >>This might be a different issue, too. > > > >Every issue needs to be handled/treated separately. > > Sure, I just had run across some threads about that but will focus > on this ZFS box (and see if anything that fixes here does anything > with that once I can reliably reproduce it out of production). -- | 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 Wed Jun 19 13:41: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 F075C616 for ; Wed, 19 Jun 2013 13:41:58 +0000 (UTC) (envelope-from prvs=1882457d64=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 9425F126B for ; Wed, 19 Jun 2013 13:41:58 +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 md50004423193.msg for ; Wed, 19 Jun 2013 14:41:52 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 14:41:52 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <16D8225B6EAB407CB367449E075D7D57@multiplay.co.uk> From: "Steven Hartland" To: , "Adam Strohl" , "Ronald Klop" References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Date: Wed, 19 Jun 2013 14:41:59 +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 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, 19 Jun 2013 13:41:59 -0000 ----- Original Message ----- From: "Ronald Klop" > On Wed, 19 Jun 2013 14:53:19 +0200, Adam Strohl > wrote: > >> On 6/19/2013 19:21, Jeremy Chadwick wrote: >>> On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: >>>> Hello -STABLE@, >>>> >>>> So I've seen this situation seemingly randomly on a number of both >>>> physical 9.1 boxes as well as VMs for I would say 6-9 months at >>>> least. I finally have a physical box here that reproduces it >>>> consistently that I can reboot easily (ie; not a production/client >>>> server). > > Hi, > > My home computer had the same symptom (not rebooting after 'all buffers > flushed' message) a couple of months ago. But I follow 9-STABLE and the > problem is gone for a while now. avg@ did a lot of work on the ZFS vfs locking which fixed at least one hang on reboot for ZFS. I don't believe this is in 9.1-RELEASE, so you should test a stable/9 or 8.4-RELEASE (which is newer than 9.1-RELEASE) kernel. 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 Wed Jun 19 13:52:18 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 8E66F97F for ; Wed, 19 Jun 2013 13:52:18 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 59D6512D9 for ; Wed, 19 Jun 2013 13:52:18 +0000 (UTC) Received: from dottie.dus.openit.net (dottie.dus.openit.net [IPv6:2001:aa8:fff3::fffd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id C63B514EE6; Wed, 19 Jun 2013 15:52:17 +0200 (CEST) Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Dennis_K=F6gel?= In-Reply-To: Date: Wed, 19 Jun 2013 15:52:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ronald Klop X-Mailer: Apple Mail (2.1283) 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, 19 Jun 2013 13:52:18 -0000 Hi, Am 19.06.2013 um 15:28 schrieb Ronald Klop: > First send more information about the system: > - The content of /var/run/dmesg.boot. > - Install /usr/ports/sysutils/zfs-stats and send the output of = zfs-stats -a. > - Send the output of zpool status + zpool list. not sure if I should put them all in this mail? -- I've put them here: http://pub.neveragain.de/arcsas/sysinfo.txt > - Did you configure compression or dedup on the pool? > - Do you keep a lot of snapshots? > - Do you run a cronjob every minute which does something with the = pool? Gathers statistics or something like that. There's only a handful of datasets (three on one machine, six on the = other), and currently no snapshots. No deduplication. Some datasets on one machine have compression, the other machine doesn't = have compression turned on for any dataset. No minutely cronjobs, automated logons, nothing alike. Thanks! D.= From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 14:15:31 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 64B022AC for ; Wed, 19 Jun 2013 14:15:31 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp163.dfw.emailsrvr.com (smtp163.dfw.emailsrvr.com [67.192.241.163]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD831476 for ; Wed, 19 Jun 2013 14:15:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 468FD2702EB for ; Wed, 19 Jun 2013 10:15:30 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp99.ord1c.emailsrvr.com (smtp99.ord1c.emailsrvr.com [108.166.43.99]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id A33862702F5 for ; Wed, 19 Jun 2013 10:15:28 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 36EEE1B016A; Wed, 19 Jun 2013 10:15:22 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id 95BE41B0192; Wed, 19 Jun 2013 10:15:16 -0400 (EDT) Message-ID: <51C1BCF6.8090606@ateamsystems.com> Date: Wed, 19 Jun 2013 21:15:18 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> In-Reply-To: <20130619133538.GA71689@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:15:31 -0000 On 6/19/2013 20:35, Jeremy Chadwick wrote: >> Nope, I see basically the same thing sometimes under ESXi 5.0 >> Hypervisor (and yes it worries me the implications of something so >> broad). Those unites I just haven't been able to isolate on a >> server which isn't critical. Lets focus on this server for now >> though per your suggestion below. > > I'm sorry but I don't understand your first sentence -- the first part > of your sentence says "nope" (I have to assume in reply to my "on bare > metal" part), but then says "I see basically the same thing sometimes > under ESXi" which implies an alternate environment in comparison (i.e. > we *are* talking about bare metal). Consider me confused. :-) Basically: The issue is extremely similar if not the same root cause, be it a native or virtual server. This server though is native. > >>> 2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. >>> If you use stable/9 (RELENG_9) we need to see uname -a output (you can >>> hide the machine name if you want). >> >> Sorry, this ZFS box is 9.1-R P4 (kernel built today): >> >> FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun >> 19 15:31:12 ICT 2013 >> root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS amd64 > > I suggest trying stable/9 (and staying with it, for that matter). The issue is no binary updates and we have a large deploy base, so we've stuck with -R and use it internally because it's what we deploy. > >>> 3. Can we please have dmesg from this machine? The controller and some >>> other hardware details matter. >> >> Sure take a look at the full log here: http://pastebin.com/k55gVVuU >> >> This includes a boot, then a reboot as I describe (you can see it >> logs the All Buffers Synced, etc) then powering back on. > > Thanks. I was mainly interested in the storage controller being used > (in this case ahci(4)) and the disks being used (notorious ST3000DM001, > known for excessively parking heads). Yeah, was not my first choice but then again ... RAIDZ-2 :) HD supply chain here (Thailand) is weird considering how many are made here (and can't buy). Smartd screams about them possibly needing a firmware update (they don't according to Seagate). Had no issues aside from a failure a month or so again (it's an HD ... it happens). > AFAIK this isn't one of the > controllers that was known for weird "quirky issues" pertaining to > flushing data to disk on shutdown. > > I have to ask: is this FreeBSD box running under a HV? No, native/direct for sure on this one. > > If it *is not* running under a HV, could we please get exact motherboard > model and version (including BIOS version)? Sometimes (not always) you > can get this from "kenv | grep smbios." No problem I built this one personally: Asus P8B-X BIOS revision 6103 > > I can also see you're running your own kernel. We'll get to that in a > moment. It's GENERIC with the following added to the end: # -- Add Support for nicer console # options VESA options SC_PIXEL_MODE # -- PF Support # device pf device pflog device pfsync # -- Core temperature reporting # device coretemp # For Intel CPUs device smbios > >>> 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? >> >> Weirdly this allowed it to reboot on the first try (without needing >> to be reset), but not the second. > > I'm not surprised. Pleas re-try with stable/9; Hans has been constantly > working on the USB stack and fixing major bugs. Got it but probably not going to go this route as it means no more binary upgrades. While I can reboot it, it is the office NAS here and so 'testing out' -STABLE I think probably isn't going to happen. > >> The "Starting background file >> system checks in 60 seconds" message appeared ... that only happens >> when something is dirty, right? > > No it does not. That message is always printed when you use background > fsck, which is the default. Got it. > > I do not advocate using background fsck, because it has been known (and > may still do this -- I do not care to find out, I do not have time for > unreliable filesystem nonsense) to not always fix all filesystem > problems. Meaning: people using background fsck have been known to boot > into single-user and issue "fsck" manually and find issues. > > Place background_fsck="no" in /etc/rc.conf. If the machine does not > have a clean filesystem on boot-up, you'll know because the system will > immediately begin fsck (in the foreground actively). You'll recognise > that output if it happens, trust me. Preaching to the choir, we set this on all servers this one somehow did not have it set (I think due to ZFS making it unique and not copying our rc.conf template over properly). > >> So the second try with just this I could ctrl alt del it and it >> responded .. kind of: >> http://i.imgur.com/POAIaNg.jpg >> >> Still had to reset it though. > > This looks like a chicken-and-egg problem -- you're probably fighting > with background fsck, as the message there indicate "some processes > would not die". I'm just taking a guess though. Yeah. Even with no background fsck though I still see the issue (rebooted 4-5 times testing things further). I even rolled back to the -p3 kernel because this server was not doing this a month or two ago, and definitely not when it was put into production. I only just saw/noticed it doing this when rebooting for p4. > > I am now going to ask you for more information: > > 1. "gpart show -p xxx" where xxx is each disk you have in the system >>>> gpart show -p => 34 5860533101 ada0 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada0p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada0p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada1 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada1p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada1p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada2 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada2p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada2p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada3 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada3p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada3p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada4 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada4p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada4p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada5 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada5p1 freebsd-boot (128k) 296 1752 - free - (876k) 2048 5860530176 ada5p2 freebsd-zfs (2.7T) 5860532224 911 - free - (455k) Here also with labels so you get an idea of what the scheme here is: >>>> gpart show -p -l => 34 5860533101 ada0 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada0p1 boot0 (128k) 296 1752 - free - (876k) 2048 5860530176 ada0p2 root0 (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada1 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada1p1 boot1 (128k) 296 1752 - free - (876k) 2048 5860530176 ada1p2 root1 (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada2 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada2p1 boot2 (128k) 296 1752 - free - (876k) 2048 5860530176 ada2p2 root2 (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada3 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada3p1 boot3 (128k) 296 1752 - free - (876k) 2048 5860530176 ada3p2 root3 (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada4 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada4p1 boot4 (128k) 296 1752 - free - (876k) 2048 5860530176 ada4p2 root4 (2.7T) 5860532224 911 - free - (455k) => 34 5860533101 ada5 GPT (2.7T) 34 6 - free - (3.0k) 40 256 ada5p1 boot5 (128k) 296 1752 - free - (876k) 2048 5860530176 ada5p2 root5 (2.7T) 5860532224 911 - free - (455k) > 2. gmirror list >>>> gmirror list Geom name: boot State: COMPLETE Components: 6 Balance: load Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3404031251 Providers: 1. Name: mirror/boot Mediasize: 130560 (127k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 Consumers: 1. Name: ada0p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3045005471 2. Name: ada1p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 1 Flags: NONE GenID: 0 SyncID: 1 ID: 1958473873 3. Name: ada2p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 2 Flags: NONE GenID: 0 SyncID: 1 ID: 1208229558 4. Name: ada3p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 3 Flags: NONE GenID: 0 SyncID: 1 ID: 3928010527 5. Name: ada4p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 4 Flags: NONE GenID: 0 SyncID: 1 ID: 442340132 6. Name: ada5p1 Mediasize: 131072 (128k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1281187492 > 3. Any/all details of your gmirror setup or other things you can > think of when you set it up The only thing is that we use GMIRROR on the partition level because we use GPT (which is clear from the gpart output I think). I gmirror the boot partition only in this case as I use ZFS backed swap and ZFS root for this server. > 4. Contents of /etc/fstab >>>> cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# # NOTE: ZFS root is not managed here /dev/zvol/zroot/swap none swap sw 0 0 > 5. Contents of /boot/loader.conf >>>> cat /boot/loader.conf geom_mirror_load="YES" zfs_load="YES" vfs.root.mountfrom="zfs:zroot" aio_load="YES" if_lagg_load="YES" > 6. Contents of /etc/rc.conf # ---- Don't run FS check and let apps start # fsck_y_enable="YES" background_fsck="NO" # ---- Power management enables SpeedStep and TurboBoost # powerd_enable="YES" powerd_flags="-a hiadaptive" # ---- Networking # hostname="hostname" defaultrouter="xxx.xxx.xxx.3" # -- LACP ifconfig_em0="up" ifconfig_em1="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 xxx.xxx.xxx.212/24" # ---- Services # sshd_enable="YES" smartd_enable="YES" samba_enable="YES" zabbix_agentd_enable="YES" zfs_enable="YES" apcupsd_enable="YES" slapd_enable="YES" slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap://xxx.xxx.xxx.212/ ldap://127.0.0.1/"' slapd_sockets="/var/run/openldap/ldapi" # ---- Time Stuff # ntpd_enable="YES" ntpd_sync_on_start="YES" # ---- Mail # postfix_enable="YES" sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" > 7. Contents of /etc/sysctl.conf kern.maxfiles=25600 kern.maxfilesperproc=16384 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 > 8. Contents of /sys/amd64/conf/ATEAMSYSTEMS See above > >>> 5. Does "sysctl hw.acpi.handle_reboot=1" help you? >> >> No change, still responded to a ctrl alt del like above, but like >> that still needs to be reset and comes back dirty. >> >>> >>> 6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? >> >> No change. Same as above, ctrl alt del responds but needs a hard >> reset still. > > Okay, thank you. > >>> 7. If none of the above helps, can you please boot verbose mode and then >>> when the system "locks up" on "shutdown -r now" take a picture of the >>> VGA console? >> >> Lots of debug on boot obviously but not much different on shutdown/hang: >> http://i.imgur.com/SgzSsoP.jpg > > It looks to me like the ACPI layer is still actively working at the time > "all buffers are synced", meaning the actual reboot phase itself never > happens. This to me starts to smell of an ACPI problem, but I do not > have the skill set to debug this, and I'm also grasping at straws. > There are many things that happen during that phase of operation, > particularly the "USB shutdown" phase. Yeah. Originally I had even my UPS (APC) disconnected, the only USB device (via a port -- I realize there might be MB virtual ports) was a Dell KB. > > But it all depends on your kernel config, which I've now asked for. Yeah -- Adam Strohl http://www.ateamsystems.com/ From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 14:21:37 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 B70C34A1 for ; Wed, 19 Jun 2013 14:21:37 +0000 (UTC) (envelope-from prvs=1882457d64=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 5A2AD15E8 for ; Wed, 19 Jun 2013 14:21:37 +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 md50004423346.msg for ; Wed, 19 Jun 2013 15:21:36 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 15:21:36 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <5E09EEAA4AD54088B5B4C763CA01E967@multiplay.co.uk> From: "Steven Hartland" To: "Adam Strohl" , "Jeremy Chadwick" References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Date: Wed, 19 Jun 2013 15:21: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: 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, 19 Jun 2013 14:21:37 -0000 ----- Original Message ----- From: "Adam Strohl" To: "Jeremy Chadwick" Cc: Sent: Wednesday, June 19, 2013 3:15 PM Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount > On 6/19/2013 20:35, Jeremy Chadwick wrote: > >>> Nope, I see basically the same thing sometimes under ESXi 5.0 >>> Hypervisor (and yes it worries me the implications of something so >>> broad). Those unites I just haven't been able to isolate on a >>> server which isn't critical. Lets focus on this server for now >>> though per your suggestion below. >> >> I'm sorry but I don't understand your first sentence -- the first part >> of your sentence says "nope" (I have to assume in reply to my "on bare >> metal" part), but then says "I see basically the same thing sometimes >> under ESXi" which implies an alternate environment in comparison (i.e. >> we *are* talking about bare metal). Consider me confused. :-) > > Basically: The issue is extremely similar if not the same root cause, be > it a native or virtual server. This server though is native. > >> >>>> 2. We need to know what version of "9.1" you're using, i.e. 9.1-RELEASE. >>>> If you use stable/9 (RELENG_9) we need to see uname -a output (you can >>>> hide the machine name if you want). >>> >>> Sorry, this ZFS box is 9.1-R P4 (kernel built today): >>> >>> FreeBSD ilos.dsn 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #6: Wed Jun >>> 19 15:31:12 ICT 2013 >>> root@hostname:/usr/obj/usr/src/sys/ATEAMSYSTEMS amd64 >> >> I suggest trying stable/9 (and staying with it, for that matter). > > The issue is no binary updates and we have a large deploy base, so we've > stuck with -R and use it internally because it's what we deploy. You still need to test if stable/9 fixes your issue though as otherwise you don't know if the issue your seeing has already been fixed, and if its the old know ZFS vfs hang on shutdown, it has. 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 Wed Jun 19 14:28: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 BC0E370F for ; Wed, 19 Jun 2013 14:28:04 +0000 (UTC) (envelope-from prvs=1882457d64=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 5F8681634 for ; Wed, 19 Jun 2013 14:28:03 +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 md50004423360.msg for ; Wed, 19 Jun 2013 15:28:02 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 15:28:02 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: =?iso-8859-1?Q?Dennis_K=F6gel?= , "Ronald Klop" References: Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Date: Wed, 19 Jun 2013 15:28:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-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, 19 Jun 2013 14:28:04 -0000 Any timeouts show in /var/log/messages or in the areca event log? ----- Original Message ----- From: "Dennis Kgel" > Am 19.06.2013 um 15:28 schrieb Ronald Klop: >> First send more information about the system: >> - The content of /var/run/dmesg.boot. >> - Install /usr/ports/sysutils/zfs-stats and send the output of zfs-stats -a. >> - Send the output of zpool status + zpool list. > > not sure if I should put them all in this mail? -- I've put them here: > > http://pub.neveragain.de/arcsas/sysinfo.txt > >> - Did you configure compression or dedup on the pool? >> - Do you keep a lot of snapshots? >> - Do you run a cronjob every minute which does something with the pool? Gathers statistics or something like that. > > There's only a handful of datasets (three on one machine, six on the other), and currently no snapshots. No deduplication. > Some datasets on one machine have compression, the other machine doesn't have compression turned on for any dataset. > > No minutely cronjobs, automated logons, nothing alike. ================================================ 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 Wed Jun 19 14:29: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 A3F7A82E for ; Wed, 19 Jun 2013 14:29:13 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com [108.166.43.115]) by mx1.freebsd.org (Postfix) with ESMTP id 84640164F for ; Wed, 19 Jun 2013 14:29:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 195B21B80E0; Wed, 19 Jun 2013 10:29:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id 34ECC1B815F; Wed, 19 Jun 2013 10:29:06 -0400 (EDT) Message-ID: <51C1C033.2070608@ateamsystems.com> Date: Wed, 19 Jun 2013 21:29:07 +0700 From: Adam Strohl 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: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <5E09EEAA4AD54088B5B4C763CA01E967@multiplay.co.uk> In-Reply-To: <5E09EEAA4AD54088B5B4C763CA01E967@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , 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, 19 Jun 2013 14:29:13 -0000 On 6/19/2013 21:21, Steven Hartland wrote: > You still need to test if stable/9 fixes your issue though as otherwise > you don't know if the issue your seeing has already been fixed, and if > its the old know ZFS vfs hang on shutdown, it has. Thanks Steve, understood but probably not going to happen with this box. I can reboot this thing but it's our NAS and not a test bed. This problem on this machine isn't a big deal because its a server and not rebooted often (and easy to bring back). But I more was hoping it would let me easily test solutions to the issue since the other servers showing the issue are in client production with the mind that the VMs not use ZFS also show a similar/identical issue.... My gut says it appeared in/with 9.1 (We never saw this with 9.0 servers). It is also possible this is a different issue from those other servers and VMs. How far away is 9.2? ;-P Depending on how things go with Jeremy I'll probably have to wait this out unless I can get a test machine or VM where I can reproduce the issue AND upgrade it to -STABLE (again assuming it's even the same issue). From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 14:39: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 36071BC1 for ; Wed, 19 Jun 2013 14:39:01 +0000 (UTC) (envelope-from prvs=1882457d64=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 CD31A16CB for ; Wed, 19 Jun 2013 14:39:00 +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 md50004423384.msg for ; Wed, 19 Jun 2013 15:39:00 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 15:39:00 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Adam Strohl" References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <5E09EEAA4AD54088B5B4C763CA01E967@multiplay.co.uk> <51C1C033.2070608@ateamsystems.com> Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Date: Wed, 19 Jun 2013 15:39:07 +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: Jeremy Chadwick , 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, 19 Jun 2013 14:39:01 -0000 ----- Original Message ----- From: "Adam Strohl" To: "Steven Hartland" Cc: "Jeremy Chadwick" ; Sent: Wednesday, June 19, 2013 3:29 PM Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount > On 6/19/2013 21:21, Steven Hartland wrote: >> You still need to test if stable/9 fixes your issue though as otherwise >> you don't know if the issue your seeing has already been fixed, and if >> its the old know ZFS vfs hang on shutdown, it has. > > Thanks Steve, understood but probably not going to happen with this box. > I can reboot this thing but it's our NAS and not a test bed. This > problem on this machine isn't a big deal because its a server and not > rebooted often (and easy to bring back). But I more was hoping it would > let me easily test solutions to the issue since the other servers > showing the issue are in client production with the mind that the VMs > not use ZFS also show a similar/identical issue.... My gut says it > appeared in/with 9.1 (We never saw this with 9.0 servers). It is also > possible this is a different issue from those other servers and VMs. > > How far away is 9.2? ;-P > > Depending on how things go with Jeremy I'll probably have to wait this > out unless I can get a test machine or VM where I can reproduce the > issue AND upgrade it to -STABLE (again assuming it's even the same issue). Don't rule out there being more than one issue at play. 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 Wed Jun 19 14:39:31 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 ACB5ACC8 for ; Wed, 19 Jun 2013 14:39:31 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 7792A16E0 for ; Wed, 19 Jun 2013 14:39:31 +0000 (UTC) Received: from dottie.dus.openit.net (dottie.dus.openit.net [217.69.66.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id D44561105F; Wed, 19 Jun 2013 16:39:23 +0200 (CEST) Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Dennis_K=F6gel?= X-Priority: 3 In-Reply-To: Date: Wed, 19 Jun 2013 16:39:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org, Ronald Klop 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, 19 Jun 2013 14:39:31 -0000 Am 19.06.2013 um 16:28 schrieb Steven Hartland: > Any timeouts show in /var/log/messages or in the areca event log? System logs don't show anything suspicious. Areca CLI utility -> "event info" is empty as well. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 14:47:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80D7B1D1 for ; Wed, 19 Jun 2013 14:47:12 +0000 (UTC) (envelope-from prvs=1882457d64=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 2360E1776 for ; Wed, 19 Jun 2013 14:47:11 +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 md50004423428.msg for ; Wed, 19 Jun 2013 15:47:09 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 15:47:09 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> From: "Steven Hartland" To: =?iso-8859-1?Q?Dennis_K=F6gel?= References: Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Date: Wed, 19 Jun 2013 15:47:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Ronald Klop 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, 19 Jun 2013 14:47:12 -0000 ----- Original Message ----- From: "Dennis Kgel" > Am 19.06.2013 um 16:28 schrieb Steven Hartland: >> Any timeouts show in /var/log/messages or in the areca event log? > > System logs don't show anything suspicious. > > Areca CLI utility -> "event info" is empty as well. I'm not familar with that model of the areca but have you tried with the standard OS driver or does it not support that card? Also when you see hangs can you access the disk directly or not e.g. dd if=/dev/da0 of=/dev/null bs=1m count=10 ? 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 Wed Jun 19 15:02: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 E3322915 for ; Wed, 19 Jun 2013 15:02:21 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (hobbit.neveragain.de [217.69.77.34]) by mx1.freebsd.org (Postfix) with ESMTP id AA769188F for ; Wed, 19 Jun 2013 15:02:21 +0000 (UTC) Received: from dottie.dus.openit.net (dottie.dus.openit.net [IPv6:2001:aa8:fff3::fffd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id 8AAFA110A9; Wed, 19 Jun 2013 17:02:20 +0200 (CEST) Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Dennis_K=F6gel?= X-Priority: 3 In-Reply-To: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> Date: Wed, 19 Jun 2013 17:02:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27EED7A0-AB0B-43B5-8B7F-B424852DBD65@neveragain.de> References: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org, Ronald Klop 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, 19 Jun 2013 15:02:22 -0000 Am 19.06.2013 um 16:47 schrieb Steven Hartland: > I'm not familar with that model of the areca but have you tried > with the standard OS driver or does it not support that card? The ARC1320 (non-raid) unfortunately isn't supported by the in-tree = driver. > Also when you see hangs can you access the disk directly or not > e.g. dd if=3D/dev/da0 of=3D/dev/null bs=3D1m count=3D10 ? Interesting idea. The dd then hangs right until everything else resumes = as well. ^T during hang says: load: 12.39 cmd: dd 7847 [physrd] 6.36r 0.00u = 0.00s 0% 1632k From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 15:04:32 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 3E4CEB8C for ; Wed, 19 Jun 2013 15:04:32 +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 D5D9518C6 for ; Wed, 19 Jun 2013 15:04:31 +0000 (UTC) Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 7E03C41C07A; Wed, 19 Jun 2013 17:04:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id JKXuVV7J7MEP; Wed, 19 Jun 2013 17:04:17 +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 F256341C056; Wed, 19 Jun 2013 17:04:16 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id D209373A1D; Wed, 19 Jun 2013 08:04:14 -0700 (PDT) Date: Wed, 19 Jun 2013 08:04:14 -0700 From: Jeremy Chadwick To: Adam Strohl Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619150414.GA72566@icarus.home.lan> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1BCF6.8090606@ateamsystems.com> 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: Wed, 19 Jun 2013 15:04:32 -0000 On Wed, Jun 19, 2013 at 09:15:18PM +0700, Adam Strohl wrote: > On 6/19/2013 20:35, Jeremy Chadwick wrote: I've snipped out portions which aren't relevant at this point in the convo. I'm trying to be terse as much as possible here (honest). To recap for readers/mailing list: - Adam seems the same behaviour on systems on bare metal, as well as FreeBSD guests running under VMware ESXi 5.0 hypervisor. However, as I stated on the list just yesterday about "lock-ups on shutdown", every situation may be different and there is a well-established history of this problem on FreeBSD where each root cause (bugs) were completely different from one another. - The system we're discussing at this point in the thread is on bare metal -- specifically an Asus P8B-X motherboard, with BIOS version 6103, driven entirely by on-board Intel AHCI (not BIOS-level RAID). - Adam runs 9.1-RELEASE because of business needs pertaining to freebsd-update and binary updates. (I ask more about this for benefits of readers below, however -- because this situation comes up a lot and I want to know what real-world admins do) > >Thanks. I was mainly interested in the storage controller being used > >(in this case ahci(4)) and the disks being used (notorious ST3000DM001, > >known for excessively parking heads). > > Yeah, was not my first choice but then again ... RAIDZ-2 :) HD > supply chain here (Thailand) is weird considering how many are made > here (and can't buy). Smartd screams about them possibly needing a > firmware update (they don't according to Seagate). Had no issues > aside from a failure a month or so again (it's an HD ... it > happens). Absolutely understood -- and FYI, in case you need backup, your thought process/conclusion here is spot on (re: "it's a MHDD, failures happen"). Irrelevant to your shutdown problem: as for smartmontools bitching about the firmware: no vendors disclose what actual changes go into their drive firmware updates (vendors if you are reading this: I will have your souls...), so I have to read a bunch of end-user forums where nobody knows what they're talking about, and then of course find this "highly educational" *cough* article from Adaptec: http://ask.adaptec.com/app/answers/detail/a_id/17241/~/known-issues-with-seagate-barracuda-7200.14-desktop-drives The problem here is that there have been *so many* firmware bugs with Seagate's drives in the past 2 years or so that it's impossible for me to know which fixes what. You buy what you buy because that's what you buy, and that's cool -- but I avoid their stuff like the plague. Readers: if any of you have a ST[123]000DM001 drive running the CC24 firmware, and can confirm high head parking counts (SMART attribute 193), and are willing to upgrade your drive firmware to the latest then see if the LCC increments stop (or at least settle down to normal levels), I'd love to hear from you. I have been socially boycotting these models of drives because of that idiotic firmware design choice for quite some time now (not to mention the parking on those drives is audibly loud in a normal living room), and if the F/W actually inhibits the excessive parking then I have some drives to consider upgrading. :-) > >I can also see you're running your own kernel. We'll get to that in a > >moment. > > It's GENERIC with the following added to the end: > > # -- Add Support for nicer console > # > options VESA > options SC_PIXEL_MODE Can you try removing VESA and SC_PIXEL_MODE please? I know that sounds crazy ("what on earth would that have to do with it?"), but please try it. I can explain the justification if need be -- I'm being extra paranoid of something that got discovered here on -stable only a few days ago. It's a stretch, but I can see potential relevance. I can provide details/links later. > >>>4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? > >> > >>Weirdly this allowed it to reboot on the first try (without needing > >>to be reset), but not the second. > > > >I'm not surprised. Pleas re-try with stable/9; Hans has been constantly > >working on the USB stack and fixing major bugs. > > Got it but probably not going to go this route as it means no more > binary upgrades. While I can reboot it, it is the office NAS here > and so 'testing out' -STABLE I think probably isn't going to happen. I understand. I have a question relating to this below. > >Place background_fsck="no" in /etc/rc.conf. If the machine does not > >have a clean filesystem on boot-up, you'll know because the system will > >immediately begin fsck (in the foreground actively). You'll recognise > >that output if it happens, trust me. > > Preaching to the choir, we set this on all servers this one somehow > did not have it set (I think due to ZFS making it unique and not > copying our rc.conf template over properly). Where should I send my bill for services rendered? (Totally kidding -- just had some breakfast so feeling chipper :-) ) > >>So the second try with just this I could ctrl alt del it and it > >>responded .. kind of: > >>http://i.imgur.com/POAIaNg.jpg > >> > >>Still had to reset it though. > > > >This looks like a chicken-and-egg problem -- you're probably fighting > >with background fsck, as the message there indicate "some processes > >would not die". I'm just taking a guess though. > > Yeah. Even with no background fsck though I still see the issue > (rebooted 4-5 times testing things further). > > I even rolled back to the -p3 kernel because this server was not > doing this a month or two ago, and definitely not when it was put > into production. I only just saw/noticed it doing this when > rebooting for p4. Two questions: 1. Does 9.1-RELEASE-p3 have the issue? We really need to know this. If it's specific to -p4 then we can narrow down what the cause is. I'd ask for further testing if possible, because it would really help the kernel folks if we can narrow this down to a commit. 2. This is for me and the benefit of the readers: given that you cannot (will not) move to stable/9: what is your plan of action now? This issue for you is very important (I would rank it severe + high pri), so now you are in a rut. What is your next move? > >I am now going to ask you for more information: > > > >1. "gpart show -p xxx" where xxx is each disk you have in the system > {snipped} Looks fine to me -- and kudos on the proper alignment (since those drives are indeed 4KB sector drives). Also kudos to using GPT with these because of gmirror, and mirroring the partitions, solely to work around the gmirror metadata vs. GPT backup header problem. > >2. gmirror list > {snipped -- I think this looks okay, but I have only used gmirror > {2 or 3 times in my life} > > >3. Any/all details of your gmirror setup or other things you can > > think of when you set it up > > The only thing is that we use GMIRROR on the partition level because > we use GPT (which is clear from the gpart output I think). I > gmirror the boot partition only in this case as I use ZFS backed > swap and ZFS root for this server. This is irrelevant to the problem (fairly sure), but: I believe ZFS-backed swap has still been given "do not do this" status. I've never done it, I just read lots and lots and lots of discussions about it. I would have stuck it as a partition one of those drives, honestly. > > {snipping /etc/fstab and /boot/loader.conf} Looks good, except loader.conf and use of powerd(8) below (also irrelevant to your shutdown problem). > # ---- Power management enables SpeedStep and TurboBoost > # > powerd_enable="YES" > powerd_flags="-a hiadaptive" Probably irrelevant to the shutdown problem: TMK powerd(8) has anything to do with TurboBoost. It does have to do with SpeedStep, but you need some special variables in /boot/loader.conf for this to work, otherwise you're using "ACPI throttling" which is different (and actually, hmm, I wonder if that may be upsetting something during shutdown (!)). What you want are these, which makes use of CPU P-state throttling (i.e. EIST), and its very smooth and doesn't use ACPI throttling. I used this on our Intel production Supermicro servers *and* my generic desktop motherboards for years with absolute success: # Enable use of P-state CPU frequency throttling. # http://wiki.freebsd.org/TuningPowerConsumption # hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" As for my rc.conf and powerd, this is what I use: powerd_enable="yes" performance_cx_lowest="C2" economy_cx_lowest="C2" You may consider removing the last 2 lines -- in fact, I'm not sure of their relevancy outside of laptops. For frequency limit (i.e. don't go below XXXXMHz), there's a loader.conf tunable for that, so I think my own rc.conf might need some testing. Anyway, IT WORKS on my CPUs that support at lowest C2 mode (see sysctl cx_supported). > {snipping other stuff} > > Yeah. Originally I had even my UPS (APC) disconnected, the only USB > device (via a port -- I realize there might be MB virtual ports) was > a Dell KB. I still go to great lengths to use server boards that offer PS/2. (They started using pure USB for a while but the backlash was major) USB keyboard support on FreeBSD is still a joke (sorry Hans, it is). The USB layer is just too flaky in general -- still -- for me to trust it. I can't tell you how many times I nearly put my fist through the LCD of the console when going into single-user mode only to find that the USB keyboard didn't function. After that nonsense, it was back to classic PS/2 for me. -- | 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 Wed Jun 19 15:10: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 2A635E88 for ; Wed, 19 Jun 2013 15:10:16 +0000 (UTC) (envelope-from prvs=1882457d64=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 C05C21930 for ; Wed, 19 Jun 2013 15:10:15 +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 md50004423531.msg for ; Wed, 19 Jun 2013 16:10:14 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 16:10:14 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <4A59B81311B944C3A740BD65455E3E60@multiplay.co.uk> From: "Steven Hartland" To: =?iso-8859-1?Q?Dennis_K=F6gel?= References: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> <27EED7A0-AB0B-43B5-8B7F-B424852DBD65@neveragain.de> Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Date: Wed, 19 Jun 2013 16:10:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Ronald Klop 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, 19 Jun 2013 15:10:16 -0000 ----- Original Message ----- From: "Dennis Kgel" > > I'm not familar with that model of the areca but have you tried > > with the standard OS driver or does it not support that card? > > The ARC1320 (non-raid) unfortunately isn't supported by the in-tree driver. > > > Also when you see hangs can you access the disk directly or not > > e.g. dd if=/dev/da0 of=/dev/null bs=1m count=10 ? > > Interesting idea. The dd then hangs right until everything else resumes as well. > > ^T during hang says: load: 12.39 cmd: dd 7847 [physrd] 6.36r 0.00u 0.00s 0% 1632k So it sounds like your seeing device level hangs which indicates either a driver, HW, controller FW or disk level issue. You might want to try adding a seperate disk (different type) to the controller which isn't used and perform the same test to try and eliminate disk's as the source of the issue. Also see what "gstat -d" shows during this? Do you see a big spike of activity either side? 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 Wed Jun 19 15:17:45 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 589F8326 for ; Wed, 19 Jun 2013 15:17:45 +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 D4A9D19C1 for ; Wed, 19 Jun 2013 15:17:44 +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 0F627A80D2; Wed, 19 Jun 2013 17:17:28 +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 KJUUtnSiRICC; Wed, 19 Jun 2013 17:16:56 +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 52505A80F1; Wed, 19 Jun 2013 17:16:54 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 6DD3F73A1C; Wed, 19 Jun 2013 08:16:52 -0700 (PDT) Date: Wed, 19 Jun 2013 08:16:52 -0700 From: Jeremy Chadwick To: Dennis =?unknown-8bit?Q?K=F6gel?= Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) Message-ID: <20130619151652.GB72566@icarus.home.lan> References: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> <27EED7A0-AB0B-43B5-8B7F-B424852DBD65@neveragain.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27EED7A0-AB0B-43B5-8B7F-B424852DBD65@neveragain.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Steven Hartland , Ronald Klop 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, 19 Jun 2013 15:17:45 -0000 On Wed, Jun 19, 2013 at 05:02:20PM +0200, Dennis Kgel wrote: > Am 19.06.2013 um 16:47 schrieb Steven Hartland: > > I'm not familar with that model of the areca but have you tried > > with the standard OS driver or does it not support that card? > > The ARC1320 (non-raid) unfortunately isn't supported by the in-tree driver. Which model of the ARC1320 are you using (there are 2). I'm having trouble understanding their chart too: http://www.areca.us/products/sasnoneraid6g.htm Because the controllers claim to support up to 128 disks, via break-out cables, but I'm not sure. You aren't using any port multipliers, are you? > > Also when you see hangs can you access the disk directly or not > > e.g. dd if=/dev/da0 of=/dev/null bs=1m count=10 ? > > Interesting idea. The dd then hangs right until everything else resumes as well. > > ^T during hang says: load: 12.39 cmd: dd 7847 [physrd] 6.36r 0.00u 0.00s 0% 1632k Is this ***while** you have immense amounts of ZFS write I/O going to those drives (your zpool iostat was showing ~250-300MB/sec to the pool)? It's very important to note that the stats you showed were during writes. What we're trying to figure out here is where the blocking (waiting) is happening: a) the ZFS layer b) the storage driver layer ('arcsat', the 3rd-party unofficial driver) c) the CAM layer d) the GEOM layer e) something with the disk(s) f) something with memory I/O going on (say between the storage driver and ZFS, for lack of better way to phrase it) I have a very big Email written for you, but I wanted to let certain answers to Ronald's questions come out first. -rw------- 1 jdc users 5576 Jun 19 06:49 dennis_kgel_response.txt I need to re-word this and take into consideration some of the new stuff said up to now, but I don't know if I'll ahve the time for this (you should see my desktop right now, I have literally 4 IM messages to answer and my Email box is non-stop). The one I want to get out of the way right now is this: Can you please try putting this in /boot/loader.conf + reboot and see if the behaviour for you changes? vfs.zfs.no_write_throttle="1" Warning: this may actually exacerbate the problem worse, depending on what the nature/root cause is. Right now I'm of the opinion ZFS is actually doing the Right Thing(tm) and that the issue may be in Areca's driver, but that's hearsay until I have proof. But the write throttling stuff added semi-recently (by the Illumos folks, this is not a FreeBSD feature) has had some reports of problems where disabling it helped immensely. Important: 24 disks off a single controller is a lot of bandwidth. That controller may be overwhelmed, in which case you would see exactly this kind of behaviour as the controller is screaming "GOD HELP ME, I'M TRYING TO DO ALL THIS STUFF AND YOU KEEP THROWING I/O AT ME". :-) This is also why I ask about port multiplier usage. -- | 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 Wed Jun 19 15:53: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 37EE6E61 for ; Wed, 19 Jun 2013 15:53:54 +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 12C461BB2 for ; Wed, 19 Jun 2013 15:53:53 +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 2FD5937B499; Wed, 19 Jun 2013 10:53:47 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3bb9gZ4LS8zGHF; Wed, 19 Jun 2013 10:53:46 -0500 (CDT) Date: Wed, 19 Jun 2013 10:53:46 -0500 From: "Matthew D. Fuller" To: Jeremy Chadwick Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619155346.GG1940@over-yonder.net> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619150414.GA72566@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.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Adam Strohl 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, 19 Jun 2013 15:53:54 -0000 On Wed, Jun 19, 2013 at 08:04:14AM -0700 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > > Readers: if any of you have a ST[123]000DM001 drive running the CC24 > firmware, and can confirm high head parking counts (SMART attribute > 193), and are willing to upgrade your drive firmware to the latest then > see if the LCC increments stop (or at least settle down to normal > levels), I'd love to hear from you. I have been socially boycotting > these models of drives because of that idiotic firmware design choice > for quite some time now (not to mention the parking on those drives > is audibly loud in a normal living room), and if the F/W actually > inhibits the excessive parking then I have some drives to consider > upgrading. :-) > I dunno about firmware, but you can smack 'em with a big hammer... /etc/rc.local: for i in 0 1; do /sbin/camcontrol cmd ada${i} -a "EF 85 00 00 00 00 00 00 00 00 00 00" done x-ref: http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052997.html LCC was somewhere in the upper 400's (I wanna say 480-some?) a year and change ago when I dropped that in. It's 506/493 now on the two drives. -- 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 Wed Jun 19 16:16:52 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 309BBC80 for ; Wed, 19 Jun 2013 16:16:52 +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 AEFBD1CE4 for ; Wed, 19 Jun 2013 16:16:51 +0000 (UTC) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 27D0541C075; Wed, 19 Jun 2013 18:16:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id yuhZBPkzCUGY; Wed, 19 Jun 2013 18:16:38 +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 487B841C088; Wed, 19 Jun 2013 18:16:36 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 0758F73A1C; Wed, 19 Jun 2013 09:16:35 -0700 (PDT) Date: Wed, 19 Jun 2013 09:16:35 -0700 From: Jeremy Chadwick To: "Matthew D. Fuller" Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619161634.GA73965@icarus.home.lan> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> <20130619155346.GG1940@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619155346.GG1940@over-yonder.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Adam Strohl 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, 19 Jun 2013 16:16:52 -0000 On Wed, Jun 19, 2013 at 10:53:46AM -0500, Matthew D. Fuller wrote: > On Wed, Jun 19, 2013 at 08:04:14AM -0700 I heard the voice of > Jeremy Chadwick, and lo! it spake thus: > > > > > > Readers: if any of you have a ST[123]000DM001 drive running the CC24 > > firmware, and can confirm high head parking counts (SMART attribute > > 193), and are willing to upgrade your drive firmware to the latest then > > see if the LCC increments stop (or at least settle down to normal > > levels), I'd love to hear from you. I have been socially boycotting > > these models of drives because of that idiotic firmware design choice > > for quite some time now (not to mention the parking on those drives > > is audibly loud in a normal living room), and if the F/W actually > > inhibits the excessive parking then I have some drives to consider > > upgrading. :-) > > > > I dunno about firmware, but you can smack 'em with a big hammer... > > /etc/rc.local: > for i in 0 1; do > /sbin/camcontrol cmd ada${i} -a "EF 85 00 00 00 00 00 00 00 00 00 00" > done > > x-ref: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052997.html > > > LCC was somewhere in the upper 400's (I wanna say 480-some?) a year > and change ago when I dropped that in. It's 506/493 now on the two > drives. The above CDB + subcommand disables APM entirely. There is a lot more to APM than just parking heads (and in all honesty, APM should have nothing to do with parking heads). Disabling APM can actually have drastic effects on drive temperature (meaning there are certain chip and/or motor operations that said feature controls *in addition* to head parking), and other firmware-level features that aren't documented. Furthermore, that CDB does not work for all drives. There are Seagate drives -- I know because I bought some and returned them when the APM trick did not work -- that lack the LCC-disable tie-in to APM. The drive either rejected the CDB (ATA status code error returned), while others accepted it but nothing in 0xec (IDENTIFY) reported as got changed. The only model of drive I know that reliably works with this method is the WD Green/-GP drive, and the drive temperatures do increase. No idea on the Blues. (Another reason I recommend the Reds...) What *should* have happened is that a new 0xef subcommand should have been created for this. Subs range from 0x00-0xff. T13 spec shows that a huge number of them (I'd say 30% or more) are marked "Reserved" and an additional 30% or so are marked "Obsolete". And finally, 0x56-0x5c, 0xd6-0xdc and 0xe0 are "Vendor Specific". But looking at this from a more general view, the real issue is that these types of features should not have been introduced to begin with. The vendors introduced this problem, and now are marketing drives with said feature disabled, claiming "we fixed the problem that annoys so many of you!" -- the same problem **they introduced without asking anyone**. I will have -- and eat -- their souls. -- | 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 Wed Jun 19 16:34: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 4D8D351A for ; Wed, 19 Jun 2013 16:34:40 +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 284181DEF for ; Wed, 19 Jun 2013 16:34:39 +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 8D3B837B54F; Wed, 19 Jun 2013 11:34:39 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3bbBZl1CRrzGKF; Wed, 19 Jun 2013 11:34:39 -0500 (CDT) Date: Wed, 19 Jun 2013 11:34:39 -0500 From: "Matthew D. Fuller" To: Jeremy Chadwick Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619163439.GH1940@over-yonder.net> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> <20130619155346.GG1940@over-yonder.net> <20130619161634.GA73965@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619161634.GA73965@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.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Adam Strohl 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, 19 Jun 2013 16:34:40 -0000 On Wed, Jun 19, 2013 at 09:16:35AM -0700 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > The above CDB + subcommand disables APM entirely. There is a lot > more to APM than just parking heads (and in all honesty, APM should > have nothing to do with parking heads). Disabling APM can actually > have drastic effects on drive temperature (meaning there are certain > chip and/or motor operations that said feature controls *in > addition* to head parking), and other firmware-level features that > aren't documented. True enough, in concept. With all the drives sitting behind ventilation perfectly capable of dealing with 15kRPM drives, I don't worry about what that might do to the 7200's though... > Furthermore, that CDB does not work for all drives. There are > Seagate drives -- I know because I bought some and returned them > when the APM trick did not work -- that lack the LCC-disable tie-in > to APM. The drive either rejected the CDB (ATA status code error > returned), while others accepted it but nothing in 0xec (IDENTIFY) > reported as got changed. Well, I haven't seen it with these. Several of ada0: ATA-8 SATA 3.x device and some systems with CC4C too. > I will have -- and eat -- their souls. The problem with that is that the undigestible bits of "soul" just get passed right back into the ecosystem, and in a more concentrated form. Some might suggest that's already happened, and is got us here in the first place 8-} -- 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 Wed Jun 19 16:52: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 0B573CB0 for ; Wed, 19 Jun 2013 16:52: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 A38501FA5 for ; Wed, 19 Jun 2013 16:52:15 +0000 (UTC) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B2F7341C056; Wed, 19 Jun 2013 18:52:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id oANOGd3VHHd5; Wed, 19 Jun 2013 18:52:03 +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 953F941C064; Wed, 19 Jun 2013 18:52:02 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 7CE9B73A1C; Wed, 19 Jun 2013 09:52:00 -0700 (PDT) Date: Wed, 19 Jun 2013 09:52:00 -0700 From: Jeremy Chadwick To: "Matthew D. Fuller" Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619165200.GA74485@icarus.home.lan> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> <20130619155346.GG1940@over-yonder.net> <20130619161634.GA73965@icarus.home.lan> <20130619163439.GH1940@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619163439.GH1940@over-yonder.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Adam Strohl 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, 19 Jun 2013 16:52:16 -0000 On Wed, Jun 19, 2013 at 11:34:39AM -0500, Matthew D. Fuller wrote: > On Wed, Jun 19, 2013 at 09:16:35AM -0700 I heard the voice of > Jeremy Chadwick, and lo! it spake thus: > > > > The above CDB + subcommand disables APM entirely. There is a lot > > more to APM than just parking heads (and in all honesty, APM should > > have nothing to do with parking heads). Disabling APM can actually > > have drastic effects on drive temperature (meaning there are certain > > chip and/or motor operations that said feature controls *in > > addition* to head parking), and other firmware-level features that > > aren't documented. > > True enough, in concept. With all the drives sitting behind > ventilation perfectly capable of dealing with 15kRPM drives, I don't > worry about what that might do to the 7200's though... Justified in your environment, but not in mine -- where most of my systems (at home) are extremely quiet (1000-1200rpm fans, lots of noise dampening material, etc.). A 10C increase *during idle* is enough to make me wary. I also have extremely sensitive hearing, so drives clicking is something I can hear from quite a distance -- I guess working with them for so long over the years has made me sensitive to 'em. > > Furthermore, that CDB does not work for all drives. There are > > Seagate drives -- I know because I bought some and returned them > > when the APM trick did not work -- that lack the LCC-disable tie-in > > to APM. The drive either rejected the CDB (ATA status code error > > returned), while others accepted it but nothing in 0xec (IDENTIFY) > > reported as got changed. > > Well, I haven't seen it with these. Several of > ada0: ATA-8 SATA 3.x device > and some systems with CC4C too. The drives I was testing were STx000DM001. I don't remember if I had a DM002. I also don't remember the firmware version they had on them, but I do remember there were no updates available from Seagate at that time. On the other hand, their forum was *filled* with post after post about the issue, including one fellow whose drive in something like 3 months was almost reaching MTBF head park/reload count. But my point is this: 3.5" drives do not need this feature in 95% of environments. In desktop systems it's worthless -- in consumer desktops it accomplishes nothing but noise and annoyance and impacts I/O, and in business desktop desktop environments it serves no purpose because most places have their desktops go into sleep mode (so drive standby/sleep gets used). And in the server environment it's pure 100% worthless. With 2.5" drives I can see it being more useful, but only if the drive is used in a laptop. There are NASes (and now servers too!) which use 2.5" drives, and I sure as hell wouldn't want that happening there. So really it's just a bad feature all around that should be specific to one environment demographic; the vendors should have made a 2.5" drive "dedicated for laptops" that had this feature enabled, while disabld on all other drives (2.5" and 3.5"). What we got was nearly opposite. > > I will have -- and eat -- their souls. > > The problem with that is that the undigestible bits of "soul" just get > passed right back into the ecosystem, and in a more concentrated form. > > Some might suggest that's already happened, and is got us here in the > first place 8-} If you had what I do (moderate-to-severe IBS), you'd know that it definitely doesn't get passed back in a more concentrated form. First joke I've been able to make about my health condition, yeah! Ha! I kill me! -- Alf -- | 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 Wed Jun 19 17:05: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 640F22FF for ; Wed, 19 Jun 2013 17:05:01 +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 3DC5B10C1 for ; Wed, 19 Jun 2013 17:05:00 +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 17AFE37B5BD; Wed, 19 Jun 2013 12:05:00 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3bbCFl4JCwzGLl; Wed, 19 Jun 2013 12:04:59 -0500 (CDT) Date: Wed, 19 Jun 2013 12:04:59 -0500 From: "Matthew D. Fuller" To: Jeremy Chadwick Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount Message-ID: <20130619170459.GI1940@over-yonder.net> References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> <20130619155346.GG1940@over-yonder.net> <20130619161634.GA73965@icarus.home.lan> <20130619163439.GH1940@over-yonder.net> <20130619165200.GA74485@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619165200.GA74485@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.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, Adam Strohl 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, 19 Jun 2013 17:05:01 -0000 On Wed, Jun 19, 2013 at 09:52:00AM -0700 I heard the voice of Jeremy Chadwick, and lo! it spake thus: > > Justified in your environment, but not in mine -- where most of my > systems (at home) are extremely quiet (1000-1200rpm fans, lots of > noise dampening material, etc.). A 10C increase *during idle* is > enough to make me wary. Mmm. Well, some of them are in 1U cases, and so behind very loud little fans (but that's in a datacenter where *I* don't have to hear it). But the ones sitting beside me are behind <1kRPM fans (80 and 120 mm), and are around 28-30c (which is a tad high; the filters are overdue for cleaning). And ambient is probably 24-25. I'd be seriously creeped out if an *active* drive were 10 over ambient, much less if flipping some config setting moved anything 10. (this is also why I _hate_ laptops...) > On the other hand, their forum was *filled* with post after post > about the issue, including one fellow whose drive in something like > 3 months was almost reaching MTBF head park/reload count. Oh, sure. If you don't get the stupid things to stop, you can measure their life with an egg timer. The 400-some these drives got before I turned APM off happened in, like, an afternoon. > If you had what I do (moderate-to-severe IBS), you'd know that it > definitely doesn't get passed back in a more concentrated form. > First joke I've been able to make about my health condition, yeah! Well, if your diet consists of hard drive manufacturer's souls, it's no wonder your system got all screwed up! You gotta find something to eat with more moral fiber! ;p -- 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 Wed Jun 19 17:50: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 8B302697; Wed, 19 Jun 2013 17:50:48 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 316A11383; Wed, 19 Jun 2013 17:50:48 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r5JHoloc002157; Wed, 19 Jun 2013 11:50:47 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r5JHolOZ002154; Wed, 19 Jun 2013 11:50:47 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 19 Jun 2013 11:50:47 -0600 (MDT) From: Warren Block To: Ian Lepore Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG In-Reply-To: <1371403440.4485.22.camel@revolution.hippie.lan> Message-ID: References: <51BDD593.5000102@xs4all.nl> <20130616153710.GT91021@kib.kiev.ua> <51BDDE64.2040801@xs4all.nl> <20130616155502.GA26171@icarus.home.lan> <51BDE16D.3080903@xs4all.nl> <20130616160752.GA26518@icarus.home.lan> <1371403440.4485.22.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 19 Jun 2013 11:50:47 -0600 (MDT) Cc: Jeremy Chadwick , Michiel Boland , Konstantin Belousov , 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: Wed, 19 Jun 2013 17:50:48 -0000 On Sun, 16 Jun 2013, Ian Lepore wrote: > On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote: >> On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote: >>> On 06/16/2013 17:55, Jeremy Chadwick wrote: >>> [...] >>> >>>> Are you running moused(8)? Actually, I can see quite clearly that you >>>> are in your core.txt: >>>> >>>> Starting ums0 moused. >>>> >>>> Try turning that off. Don't ask me how, because devd(8) / devd.conf(5) >>>> might be involved. >>>> >>> >>> The moused is started by devd - I don't see a quick way of turning that off. >> >> Comment out the relevant crap in devd.conf(5). Search for "ums" >> and comment out the two "notify" sections. > > I don't understand why people treat devd as if it's some sort of evil > virus that they're forced to live with (using phrases like "crap in > devd.conf"). In general, the standard devd rules tend to fall into 3 > categories: > * use logger(1) to record some anomaly > * kldload a module > * invoke a standard /etc/rc.d script > > For moused, the devd rules invoke /etc/rc.d/moused, which implies that > setting moused_enable=NO in rc.conf would be all that's needed to > disable it. Seems that way, but it's misleading. Plug in a USB mouse, and devd will start moused anyway (with different options, but still...). ISTR that can be disabled with moused_enable="NO" moused_nondefault_enable="NO" I have not tested that lately. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 17:53:14 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 E38408DD for ; Wed, 19 Jun 2013 17:53:14 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from smtp163.dfw.emailsrvr.com (smtp163.dfw.emailsrvr.com [67.192.241.163]) by mx1.freebsd.org (Postfix) with ESMTP id AC24513B4 for ; Wed, 19 Jun 2013 17:53:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6D0CD270BC5 for ; Wed, 19 Jun 2013 13:53:13 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp83.ord1c.emailsrvr.com (smtp83.ord1c.emailsrvr.com [108.166.43.83]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id D8AF6270A11 for ; Wed, 19 Jun 2013 13:53:12 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5120C5013D for ; Wed, 19 Jun 2013 13:53:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: adam.strohl-AT-ateamsystems.com) with ESMTPSA id CFD4C500F1 for ; Wed, 19 Jun 2013 13:53:03 -0400 (EDT) Message-ID: <51C1F000.7090506@ateamsystems.com> Date: Thu, 20 Jun 2013 00:53:04 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <20130619133538.GA71689@icarus.home.lan> <51C1BCF6.8090606@ateamsystems.com> <20130619150414.GA72566@icarus.home.lan> In-Reply-To: <20130619150414.GA72566@icarus.home.lan> 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, 19 Jun 2013 17:53:15 -0000 On 6/19/2013 22:04, Jeremy Chadwick wrote: > On Wed, Jun 19, 2013 at 09:15:18PM +0700, Adam Strohl wrote: >> On 6/19/2013 20:35, Jeremy Chadwick wrote: > > I've snipped out portions which aren't relevant at this point in the > convo. I'm trying to be terse as much as possible here (honest). > > To recap for readers/mailing list: > > - Adam seems the same behaviour on systems on bare metal, as well as > FreeBSD guests running under VMware ESXi 5.0 hypervisor. However, > as I stated on the list just yesterday about "lock-ups on shutdown", > every situation may be different and there is a well-established > history of this problem on FreeBSD where each root cause (bugs) > were completely different from one another. > > - The system we're discussing at this point in the thread is on > bare metal -- specifically an Asus P8B-X motherboard, with BIOS > version 6103, driven entirely by on-board Intel AHCI (not BIOS-level > RAID). > > - Adam runs 9.1-RELEASE because of business needs pertaining to > freebsd-update and binary updates. (I ask more about this for > benefits of readers below, however -- because this situation comes > up a lot and I want to know what real-world admins do) > This is all correct. >>> Thanks. I was mainly interested in the storage controller being used >>> (in this case ahci(4)) and the disks being used (notorious ST3000DM001, >>> known for excessively parking heads). >> >> Yeah, was not my first choice but then again ... RAIDZ-2 :) HD >> supply chain here (Thailand) is weird considering how many are made >> here (and can't buy). Smartd screams about them possibly needing a >> firmware update (they don't according to Seagate). Had no issues >> aside from a failure a month or so again (it's an HD ... it >> happens). > > Absolutely understood -- and FYI, in case you need backup, your thought > process/conclusion here is spot on (re: "it's a MHDD, failures happen"). Indeed :-D > > Irrelevant to your shutdown problem: as for smartmontools bitching about > the firmware: no vendors disclose what actual changes go into their > drive firmware updates (vendors if you are reading this: I will have > your souls...), so I have to read a bunch of end-user forums where > nobody knows what they're talking about, and then of course find this > "highly educational" *cough* article from Adaptec: > > http://ask.adaptec.com/app/answers/detail/a_id/17241/~/known-issues-with-seagate-barracuda-7200.14-desktop-drives > Yeah I agree .. I tried to firmware upgrade them when I was building the system but it said they didn't qualify when using the boot ISO. I just checked the site and it says no firmware update available too when using their search by serial # tool. At this point I'm leery about updating given that I've got data on it anyway. I do occasionally (maybe once a week or two and they're in the same room as me/my office) hear one parking. I see nothing wrong in smart though, no dmesg errors and have noticed no issues with the array and it bench tests at around 850 MB/sec. Too bad 10 Gbit equipment isn't cheaper. Also when I bought the 6 for this array I got a 7th as a cold spare :P > The problem here is that there have been *so many* firmware bugs with > Seagate's drives in the past 2 years or so that it's impossible for me > to know which fixes what. You buy what you buy because that's what you > buy, and that's cool -- but I avoid their stuff like the plague. Yeah. I'd prefer WD myself but this place is swimming in "green" and now "red" drives. uhgl. << Snipping out the unrelated parts ... >> > Can you try removing VESA and SC_PIXEL_MODE please? I know that > sounds crazy ("what on earth would that have to do with it?"), but > please try it. I can explain the justification if need be -- I'm being > extra paranoid of something that got discovered here on -stable only a > few days ago. It's a stretch, but I can see potential relevance. I can > provide details/links later. No change unfortunately. > >>>>> 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? >>>> >>>> Weirdly this allowed it to reboot on the first try (without needing >>>> to be reset), but not the second. >>> >>> I'm not surprised. Pleas re-try with stable/9; Hans has been constantly >>> working on the USB stack and fixing major bugs. >> >> Got it but probably not going to go this route as it means no more >> binary upgrades. While I can reboot it, it is the office NAS here >> and so 'testing out' -STABLE I think probably isn't going to happen. > > I understand. I have a question relating to this below. > >>> Place background_fsck="no" in /etc/rc.conf. If the machine does not >>> have a clean filesystem on boot-up, you'll know because the system will >>> immediately begin fsck (in the foreground actively). You'll recognise >>> that output if it happens, trust me. >> >> Preaching to the choir, we set this on all servers this one somehow >> did not have it set (I think due to ZFS making it unique and not >> copying our rc.conf template over properly). > > Where should I send my bill for services rendered? (Totally kidding -- > just had some breakfast so feeling chipper :-) ) Ha! <> > > Two questions: > > 1. Does 9.1-RELEASE-p3 have the issue? We really need to know this. > If it's specific to -p4 then we can narrow down what the cause is. > I'd ask for further testing if possible, because it would really > help the kernel folks if we can narrow this down to a commit. I rolled back the kernel to p3 and saw no change and AFAIK there were only two files changed between p3 and p4 are in the kernel, so that would effectively be a complete rollback. I wish I had more conclusive documentation on times/occurrences, it wasn't until later did I start to see the pattern. > > 2. This is for me and the benefit of the readers: given that you cannot > (will not) move to stable/9: what is your plan of action now? This > issue for you is very important (I would rank it severe + high pri), > so now you are in a rut. What is your next move? Two things ... talk to a client about testing/rebooting one of their servers since it is part of a big pool and reliably shows the issue (and does not involve ZFS). They are affected by this too so I don't think it'll be too hard of a sell. I will also keep an eye out for any VMs I run across that do it and bring that up in a separate thread (and if whatever happens with the above does not apply). > >>> I am now going to ask you for more information: >>> >>> 1. "gpart show -p xxx" where xxx is each disk you have in the system >> {snipped} > > Looks fine to me -- and kudos on the proper alignment (since those > drives are indeed 4KB sector drives). Also kudos to using GPT with > these because of gmirror, and mirroring the partitions, solely to > work around the gmirror metadata vs. GPT backup header problem. Thanks. There is a huge lack of good clear documentation on this unforutnately. I wrote a two blog entries about this last year: http://www.ateamsystems.com/blog/Installing-FreeBSD-9-gmirror-GPT-partitions-raid-1 http://www.ateamsystems.com/blog/FreeBSD-Partition-Alignment-RAID-SSD-4k-Drive They remain one of the most populate things on our site heh. > >>> 2. gmirror list >> {snipped -- I think this looks okay, but I have only used gmirror >> {2 or 3 times in my life} >> >>> 3. Any/all details of your gmirror setup or other things you can >>> think of when you set it up >> >> The only thing is that we use GMIRROR on the partition level because >> we use GPT (which is clear from the gpart output I think). I >> gmirror the boot partition only in this case as I use ZFS backed >> swap and ZFS root for this server. > > This is irrelevant to the problem (fairly sure), but: I believe > ZFS-backed swap has still been given "do not do this" status. I've > never done it, I just read lots and lots and lots of discussions about > it. I would have stuck it as a partition one of those drives, honestly. This server has 32 GiB and really should never swap anyway was my view. It felt silly to do a 6-way GMIRROR of a GiB or two of swap basically. > >>> {snipping /etc/fstab and /boot/loader.conf} > > Looks good, except loader.conf and use of powerd(8) below (also > irrelevant to your shutdown problem). > >> # ---- Power management enables SpeedStep and TurboBoost >> # >> powerd_enable="YES" >> powerd_flags="-a hiadaptive" > > Probably irrelevant to the shutdown problem: TMK powerd(8) has anything > to do with TurboBoost. It does have to do with SpeedStep, but you need > some special variables in /boot/loader.conf for this to work, otherwise > you're using "ACPI throttling" which is different (and actually, hmm, I > wonder if that may be upsetting something during shutdown (!)). > > What you want are these, which makes use of CPU P-state throttling (i.e. > EIST), and its very smooth and doesn't use ACPI throttling. I used > this on our Intel production Supermicro servers *and* my generic desktop > motherboards for years with absolute success: > > # Enable use of P-state CPU frequency throttling. > # http://wiki.freebsd.org/TuningPowerConsumption > # > hint.p4tcc.0.disabled="1" > hint.acpi_throttle.0.disabled="1" VERY COOL. My research indicated (I wish I saved the mailing list threads) that basically TurboBoost doesn't engage without SpeedStep and powerd was what did that under FreeBSD. I've documented clear performance gains [with certain systems] http://www.ateamsystems.com/blog/Increase-FreeBSD-Performance-With-powerd so powerd does something. Maybe there is an auto mode? I'd love to think the performance gains would stack, too! I will have to test the above / below! > > As for my rc.conf and powerd, this is what I use: > > powerd_enable="yes" > performance_cx_lowest="C2" > economy_cx_lowest="C2" > > You may consider removing the last 2 lines -- in fact, I'm not sure of > their relevancy outside of laptops. For frequency limit (i.e. don't go > below XXXXMHz), there's a loader.conf tunable for that, so I think my > own rc.conf might need some testing. Anyway, IT WORKS on my CPUs that > support at lowest C2 mode (see sysctl cx_supported). For TurboBoost I know the deeper the sleeping, the better. So you want to use the max for your CPU so it can sleep inactive cores further to boost active ones more. > >> {snipping other stuff} >> >> Yeah. Originally I had even my UPS (APC) disconnected, the only USB >> device (via a port -- I realize there might be MB virtual ports) was >> a Dell KB. > > I still go to great lengths to use server boards that offer PS/2. (They > started using pure USB for a while but the backlash was major) USB > keyboard support on FreeBSD is still a joke (sorry Hans, it is). Heh. I miss my Keytronic ... and this MB does have PS/2 ... > > The USB layer is just too flaky in general -- still -- for me to trust > it. I can't tell you how many times I nearly put my fist through the > LCD of the console when going into single-user mode only to find that > the USB keyboard didn't function. After that nonsense, it was back to > classic PS/2 for me. > I have to agree here with massive issues with USB KVMs as well, but they also have issues even with BIOS sometimes so it's hard to tell where the blame lies in my eyes.. fortunately everything is KVM over IP now for the most part. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 19: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 A06C5D8B for ; Wed, 19 Jun 2013 19:44:42 +0000 (UTC) (envelope-from dk@neveragain.de) Received: from mail.neveragain.de (mail.neveragain.de [IPv6:2001:aa8:fffc::25]) by mx1.freebsd.org (Postfix) with ESMTP id 66F011B32 for ; Wed, 19 Jun 2013 19:44:42 +0000 (UTC) Received: from slick.hq.neveragain.de (ip-62-143-169-84.unitymediagroup.de [62.143.169.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.neveragain.de (Postfix) with ESMTPSA id 779951165F; Wed, 19 Jun 2013 21:44:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Weird I/O hangs (9.1R, arcsas, interrupt spikes on uhci0) From: =?iso-8859-1?Q?Dennis_K=F6gel?= In-Reply-To: <20130619151652.GB72566@icarus.home.lan> Date: Wed, 19 Jun 2013 21:44:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <464554DB-2903-44DE-9EAD-52CD0E3C2823@neveragain.de> References: <15E6A1D4AB1D43D49C1DA02EAF463126@multiplay.co.uk> <27EED7A0-AB0B-43B5-8B7F-B424852DBD65@neveragain.de> <20130619151652.GB72566@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1508) Cc: freebsd-stable@freebsd.org, Steven Hartland , Ronald Klop 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, 19 Jun 2013 19:44:42 -0000 Am 19.06.2013 um 17:16 schrieb Jeremy Chadwick : > Which model of the ARC1320 are you using (there are 2). It has four internal connectors, so it should be the ARC-1320ix-16. No port multipliers. >>> Also when you see hangs can you access the disk directly or not >>> e.g. dd if=3D/dev/da0 of=3D/dev/null bs=3D1m count=3D10 ? >>=20 >> Interesting idea. The dd then hangs right until everything else = resumes as well. >>=20 >> ^T during hang says: load: 12.39 cmd: dd 7847 [physrd] 6.36r 0.00u = 0.00s 0% 1632k >=20 > Is this ***while** you have immense amounts of ZFS write I/O going to > those drives (your zpool iostat was showing ~250-300MB/sec to the = pool)? > [...] It's important to note that the interrupt spikes (and the I/O hangs) = happen just as frequently on an idle system. Having a bunch of dd processes writiing + iostat just visualizes it = better. So, with or without actual write load: dd with if=3D/dev/daX (arcsas = device) hangs when the interrupt counters for uhci0 soar for these ~10 = seconds phases, as shown above. Noteworthy: dd'ing from if=3D/dev/ada1 (onboard controller) during such = a hang phase returns immediately, i.e. works fine. (ada1 is part of ZFS = -- the other 'zroot' pool -- but is not an arcsas device, so a driver = issue sounds more likely). > Can you please try putting this in /boot/loader.conf + reboot and > see if the behaviour for you changes? >=20 > vfs.zfs.no_write_throttle=3D"1" This produces quite interesting burst numbers, but does not affect the = problem behaviour at all. Am 19.06.2013 um 17:10 schrieb Steven Hartland = : > You might want to try adding a seperate disk (different type) > to the controller which isn't used and perform the same test to > try and eliminate disk's as the source of the issue. That's currently not an option, as the zpool already contains data; but = I tried against a disk on another controller, see above. > Also see what "gstat -d" shows during this? Do you see a big spike > of activity either side? The picture is pretty much the same as with zpool iostat: Healthy = values, all disks from 70-100% busy; during a hang phase, every column = just drops to zero -- except for L(q), which remains frozen at some low = value for the duration of the hang (e.g. 4 or 10). Sample outputs here: http://pub.neveragain.de/arcsas/gstat.txt Thanks, D.= From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 20:15: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 B40C3F7C; Wed, 19 Jun 2013 20:15:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 463A51CAA; Wed, 19 Jun 2013 20:15:10 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r5JKF9TA073573; Wed, 19 Jun 2013 20:15:09 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r5JKF9IU073564; Wed, 19 Jun 2013 20:15:09 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Jun 2013 20:15:09 GMT Message-Id: <201306192015.r5JKF9IU073564@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 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: Wed, 19 Jun 2013 20:15:10 -0000 TB --- 2013-06-19 18:20:57 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-06-19 18:20:57 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-06-19 18:20:57 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-06-19 18:20:57 - cleaning the object tree TB --- 2013-06-19 18:21:14 - /usr/local/bin/svn stat /src TB --- 2013-06-19 18:21:50 - At svn revision 251993 TB --- 2013-06-19 18:21:51 - building world TB --- 2013-06-19 18:21:51 - CROSS_BUILD_TESTING=YES TB --- 2013-06-19 18:21:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-19 18:21:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-19 18:21:51 - SRCCONF=/dev/null TB --- 2013-06-19 18:21:51 - TARGET=ia64 TB --- 2013-06-19 18:21:51 - TARGET_ARCH=ia64 TB --- 2013-06-19 18:21:51 - TZ=UTC TB --- 2013-06-19 18:21:51 - __MAKE_CONF=/dev/null TB --- 2013-06-19 18:21:51 - cd /src TB --- 2013-06-19 18:21:51 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 19 18:21:52 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jun 19 20:09:19 UTC 2013 TB --- 2013-06-19 20:09:19 - generating LINT kernel config TB --- 2013-06-19 20:09:19 - cd /src/sys/ia64/conf TB --- 2013-06-19 20:09:19 - /usr/bin/make -B LINT TB --- 2013-06-19 20:09:19 - cd /src/sys/ia64/conf TB --- 2013-06-19 20:09:19 - /usr/sbin/config -m LINT TB --- 2013-06-19 20:09:19 - building LINT kernel TB --- 2013-06-19 20:09:19 - CROSS_BUILD_TESTING=YES TB --- 2013-06-19 20:09:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-06-19 20:09:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-06-19 20:09:19 - SRCCONF=/dev/null TB --- 2013-06-19 20:09:19 - TARGET=ia64 TB --- 2013-06-19 20:09:19 - TARGET_ARCH=ia64 TB --- 2013-06-19 20:09:19 - TZ=UTC TB --- 2013-06-19 20:09:19 - __MAKE_CONF=/dev/null TB --- 2013-06-19 20:09:19 - cd /src TB --- 2013-06-19 20:09:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 19 20:09:19 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/advansys/adwmcode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ae/if_ae.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/age/if_age.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/agp/agp.c /src/sys/dev/agp/agp.c: In function 'agp_generic_attach': /src/sys/dev/agp/agp.c:238: error: 'Maxmem' undeclared (first use in this function) /src/sys/dev/agp/agp.c:238: error: (Each undeclared identifier is reported only once /src/sys/dev/agp/agp.c:238: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-06-19 20:15:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-06-19 20:15:09 - ERROR: failed to build LINT kernel TB --- 2013-06-19 20:15:09 - 4948.56 user 657.11 system 6852.28 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 22:24:07 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 A33AAE7F for ; Wed, 19 Jun 2013 22:24:07 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6375012A1 for ; Wed, 19 Jun 2013 22:24:07 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 846F22842F for ; Thu, 20 Jun 2013 00:17:37 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id A006F2842D for ; Thu, 20 Jun 2013 00:17:36 +0200 (CEST) Message-ID: <51C22E11.3020008@quip.cz> Date: Thu, 20 Jun 2013 00:17:53 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: freebsd-stable Stable Subject: sshd didn't run after upgrade to FreeBSD 8.4 Content-Type: text/plain; charset=ISO-8859-2; 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, 19 Jun 2013 22:24:07 -0000 The version of sshd in FreeBSD 8.4 is not backward compatible with older version from 8.3. OpenSSH_5.4p1 (on FreeBSD 8.3) OpenSSH_6.1p1 (on FreeBSD 8.4) # sshd -t /etc/ssh/sshd_config line 19: Missing argument. On line 19, there is: VersionAddendum It was OK in older versions. It will remove any default text appended to SSH protocol banner (for example 'FreeBSD-20120901'). On FreeBSD 8.4, there must be some string (any single character) I was really badly surprised that the machine was re-booted without ssh access! I think this change is worth to mention in Release Notes Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 22: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 BC50D1D7 for ; Wed, 19 Jun 2013 22:38:56 +0000 (UTC) (envelope-from prvs=1882457d64=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 61DE2132E for ; Wed, 19 Jun 2013 22:38:56 +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 md50004428476.msg for ; Wed, 19 Jun 2013 23:38:54 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 19 Jun 2013 23:38:54 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@FreeBSD.org Message-ID: <2C1F7970DE0443759EFA6872D65052B0@multiplay.co.uk> From: "Steven Hartland" To: "Miroslav Lachman" <000.fbsd@quip.cz>, "freebsd-stable Stable" References: <51C22E11.3020008@quip.cz> Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 Date: Wed, 19 Jun 2013 23:39:06 +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 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, 19 Jun 2013 22:38:56 -0000 Given its often critical nature ssh really should never fail due to a bad config line, it should ignore and continue. ----- Original Message ----- From: "Miroslav Lachman" <000.fbsd@quip.cz> To: "freebsd-stable Stable" Sent: Wednesday, June 19, 2013 11:17 PM Subject: sshd didn't run after upgrade to FreeBSD 8.4 > The version of sshd in FreeBSD 8.4 is not backward compatible with older > version from 8.3. > > OpenSSH_5.4p1 (on FreeBSD 8.3) > OpenSSH_6.1p1 (on FreeBSD 8.4) > > # sshd -t > /etc/ssh/sshd_config line 19: Missing argument. > > On line 19, there is: > VersionAddendum > > It was OK in older versions. It will remove any default text appended to > SSH protocol banner (for example 'FreeBSD-20120901'). > > On FreeBSD 8.4, there must be some string (any single character) > > I was really badly surprised that the machine was re-booted without ssh > access! > > I think this change is worth to mention in Release Notes > > Miroslav Lachman > _______________________________________________ > 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" > ================================================ 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 Wed Jun 19 23:04:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F1A1768 for ; Wed, 19 Jun 2013 23:04:26 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by mx1.freebsd.org (Postfix) with ESMTP id 38F8515EE for ; Wed, 19 Jun 2013 23:04:25 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id q19so3673537qeb.30 for ; Wed, 19 Jun 2013 16:04:25 -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=tuXGBxH9gKnSBYGM6dPXgtrjj40EkNkvjIwIhH1nxsA=; b=svSmuZa+PsAK7W/wD9QIuFqVe+2qZQ07a6awQAPXk5//ww9u8kvUd7UHCB+4uuxroS 8pm0V6VR/hioB1yVY5w4kZ9LQ7u78NpvAt9miTT/JcG4tRUi6A4sEosVCV3objMpQAOY 5/aXvk3I7k+mwIjfoivssD54Oyk7j+xocatmuGAD+za92y4JXAiZwjFido6UdRHYzdTr 5u8H2mA8T1G2ut99LxG27qjHtOD/w0lDOGRTOWbSoWJ9MkL1c2UtlMvw/bD+iWVUu5Zo ZvKIZwQ/2BJulddTT/AMUInzGMC9UU3X8nmVdA6Ez131uUuZeaWMAUt3Z8EMg+M7D9fD /oFA== MIME-Version: 1.0 X-Received: by 10.49.84.164 with SMTP id a4mr6510299qez.4.1371683065239; Wed, 19 Jun 2013 16:04:25 -0700 (PDT) Received: by 10.224.182.148 with HTTP; Wed, 19 Jun 2013 16:04:25 -0700 (PDT) In-Reply-To: <51C22E11.3020008@quip.cz> References: <51C22E11.3020008@quip.cz> Date: Thu, 20 Jun 2013 02:04:25 +0300 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Kimmo Paasiala To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable 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: Wed, 19 Jun 2013 23:04:26 -0000 On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > The version of sshd in FreeBSD 8.4 is not backward compatible with older > version from 8.3. > > OpenSSH_5.4p1 (on FreeBSD 8.3) > OpenSSH_6.1p1 (on FreeBSD 8.4) > > # sshd -t > /etc/ssh/sshd_config line 19: Missing argument. > > On line 19, there is: > VersionAddendum > > It was OK in older versions. It will remove any default text appended to SSH > protocol banner (for example 'FreeBSD-20120901'). > > On FreeBSD 8.4, there must be some string (any single character) > > I was really badly surprised that the machine was re-booted without ssh > access! > > I think this change is worth to mention in Release Notes > > Miroslav Lachman How did you update to 8.4? This sounds more like messing up the mergemaster(8)/freebsd-update merge procedure than a real problem with the config file. This is the source configuration file straight from SVN releng/8.4 branch and as you can see the VersionAddendum on line 115 is commented out there: http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup -Kimmo From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 23:29: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 49DC216A for ; Wed, 19 Jun 2013 23:29:33 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5061711 for ; Wed, 19 Jun 2013 23:29:32 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 55A242842F; Thu, 20 Jun 2013 01:29:31 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EAB172842B; Thu, 20 Jun 2013 01:29:29 +0200 (CEST) Message-ID: <51C23ED9.7070107@quip.cz> Date: Thu, 20 Jun 2013 01:29:29 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 References: <51C22E11.3020008@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable 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: Wed, 19 Jun 2013 23:29:33 -0000 Kimmo Paasiala wrote: > On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman<000.fbsd@quip.cz> wrote: >> The version of sshd in FreeBSD 8.4 is not backward compatible with older >> version from 8.3. >> >> OpenSSH_5.4p1 (on FreeBSD 8.3) >> OpenSSH_6.1p1 (on FreeBSD 8.4) >> >> # sshd -t >> /etc/ssh/sshd_config line 19: Missing argument. >> >> On line 19, there is: >> VersionAddendum >> >> It was OK in older versions. It will remove any default text appended to SSH >> protocol banner (for example 'FreeBSD-20120901'). >> >> On FreeBSD 8.4, there must be some string (any single character) >> >> I was really badly surprised that the machine was re-booted without ssh >> access! >> >> I think this change is worth to mention in Release Notes >> >> Miroslav Lachman > > How did you update to 8.4? This sounds more like messing up the > mergemaster(8)/freebsd-update merge procedure than a real problem with > the config file. > > This is the source configuration file straight from SVN releng/8.4 > branch and as you can see the VersionAddendum on line 115 is commented > out there: > > http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup It was upgraded by freebsd-update. It was intentionally left here as it was valid configuration for many years. That's why I think it should be mentioned in the Release Notes, that it is no longer valid configuration (empty VersionAddendum). The fact, that it is no longer in default sshd_config file doesn't mean it can't be used at all. It is still valid in the form which was in old default config: "VersionAddendum FreeBSD-20100308", but is no longer valid if empty. That's the point. (and empty VersionAddendum was widely used, it is not my invention) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 23:32: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 5CC842E6 for ; Wed, 19 Jun 2013 23:32:01 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 2507F1737 for ; Wed, 19 Jun 2013 23:32:01 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id e11so3386636qcx.38 for ; Wed, 19 Jun 2013 16:32:00 -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=SrgHYUswqKPtFtnV/reCa9CgIK0ZxqUz7yjEZPSh4QQ=; b=KQYYg/nfzQ64MLnHKycIpF+dgJW9byJlLorvZRp0BNxATqSNCVD5eI57nE91refgWs +moproI/de/NiN56zNu1FcAi5pBPpYF6MfpV6j8LKvYYwY+xDWq4eQtB5djjfC0/nLdu 56aMZChKCozY3t+vS37hQ9YU+ITFC6AMCeoVrMJxpdsGjzse7At5cXLnBsM6+sVY6URt 0rSWmR57geTtVXs2aQeO5mzfkGpu59mQQPXuBzlX55G1g5rcHt4PuJZetQ43dKvEwSqV ZGAGMPwYyZu9xmc1+X9ufGhRpwvn6LL9MIgbXughYnrHO4E2/ai4p9nyr1U0gMaCF61M P0Zw== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr1916876qcb.135.1371684720564; Wed, 19 Jun 2013 16:32:00 -0700 (PDT) Received: by 10.224.182.148 with HTTP; Wed, 19 Jun 2013 16:32:00 -0700 (PDT) In-Reply-To: <51C23ED9.7070107@quip.cz> References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> Date: Thu, 20 Jun 2013 02:32:00 +0300 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Kimmo Paasiala To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable 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: Wed, 19 Jun 2013 23:32:01 -0000 On Thu, Jun 20, 2013 at 2:29 AM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Kimmo Paasiala wrote: >> >> On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman<000.fbsd@quip.cz> >> wrote: >>> >>> The version of sshd in FreeBSD 8.4 is not backward compatible with older >>> version from 8.3. >>> >>> OpenSSH_5.4p1 (on FreeBSD 8.3) >>> OpenSSH_6.1p1 (on FreeBSD 8.4) >>> >>> # sshd -t >>> /etc/ssh/sshd_config line 19: Missing argument. >>> >>> On line 19, there is: >>> VersionAddendum >>> >>> It was OK in older versions. It will remove any default text appended to >>> SSH >>> protocol banner (for example 'FreeBSD-20120901'). >>> >>> On FreeBSD 8.4, there must be some string (any single character) >>> >>> I was really badly surprised that the machine was re-booted without ssh >>> access! >>> >>> I think this change is worth to mention in Release Notes >>> >>> Miroslav Lachman >> >> >> How did you update to 8.4? This sounds more like messing up the >> mergemaster(8)/freebsd-update merge procedure than a real problem with >> the config file. >> >> This is the source configuration file straight from SVN releng/8.4 >> branch and as you can see the VersionAddendum on line 115 is commented >> out there: >> >> >> http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup > > > It was upgraded by freebsd-update. It was intentionally left here as it was > valid configuration for many years. > That's why I think it should be mentioned in the Release Notes, that it is > no longer valid configuration (empty VersionAddendum). > > The fact, that it is no longer in default sshd_config file doesn't mean it > can't be used at all. It is still valid in the form which was in old default > config: "VersionAddendum FreeBSD-20100308", but is no longer valid if empty. > That's the point. > > (and empty VersionAddendum was widely used, it is not my invention) > > Miroslav Lachman You're missing my point totally. The line is commented out in the official source of 8.4 and there for I have very hard time believing that it would show up uncommented on a fresh 8.4 installation. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 23:37:07 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 C66FF6E6 for ; Wed, 19 Jun 2013 23:37:07 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id A372A1777 for ; Wed, 19 Jun 2013 23:37:07 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id rq2so5593856pbb.19 for ; Wed, 19 Jun 2013 16:37:07 -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=nDQsWHYROz2XhGvAxbPdw4t83YfzLcwrzJ1JG1mp0vM=; b=s2ASDsFC+wNI1ewt2LtNf2+E14BJSr8UhETXSStzLpdzrwgd5ZxnPomPcT9qvJyY/1 sStXq+b4f+AGzEyZsnqAOn9JFKMcy6KGXVA1GZ6B9LJMo43mdz3Vq925KJFmrkbsxJLx F5bL9qOvxZgQT+1Kbr8vMv6QHuIlmjDeGOtSXV7hRHhaR3ATQiMn5E7PRIapd7/dtzVN zZpIf6EKH+/eCGHG+nALsHHGFqi5Q7WCRoCECEkkT01ebGGvef/11GKU+91RSc2Rn8mR HavoJ7dC4HpaWr44d5/PL4PujCVNarZQkVynzXKWtaOmwTG0zGLVOVxq42ZfhiboM0er n2nw== MIME-Version: 1.0 X-Received: by 10.68.75.49 with SMTP id z17mr5028634pbv.169.1371685027432; Wed, 19 Jun 2013 16:37:07 -0700 (PDT) Received: by 10.70.31.195 with HTTP; Wed, 19 Jun 2013 16:37:07 -0700 (PDT) In-Reply-To: References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> Date: Wed, 19 Jun 2013 18:37:07 -0500 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Adam Vande More To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable Stable , Miroslav Lachman <000.fbsd@quip.cz> 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, 19 Jun 2013 23:37:07 -0000 On Wed, Jun 19, 2013 at 6:32 PM, Kimmo Paasiala wrote: > You're missing my point totally. The line is commented out in the > official source of 8.4 and there for I have very hard time believing > that it would show up uncommented on a fresh 8.4 installation. I don't think this warrants a mention in the Release Notes for exactly this point, however it should probably be mentioned in UPDATING. If nothing else, that would at least keep UPDATING consistent with previous ssh major upgrades. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Jun 19 23:40: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 A5661808 for ; Wed, 19 Jun 2013 23:40:42 +0000 (UTC) (envelope-from prvs=1882457d64=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 34BE8179C for ; Wed, 19 Jun 2013 23:40:41 +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 md50004428605.msg for ; Thu, 20 Jun 2013 00:40:40 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 20 Jun 2013 00:40:40 +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=1882457d64=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Kimmo Paasiala" , "Miroslav Lachman" <000.fbsd@quip.cz> References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 Date: Thu, 20 Jun 2013 00:40:48 +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 Cc: freebsd-stable 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: Wed, 19 Jun 2013 23:40:42 -0000 ----- Original Message ----- From: "Kimmo Paasiala" To: "Miroslav Lachman" <000.fbsd@quip.cz> Cc: "freebsd-stable Stable" Sent: Thursday, June 20, 2013 12:32 AM Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 > On Thu, Jun 20, 2013 at 2:29 AM, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> Kimmo Paasiala wrote: >>> >>> On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman<000.fbsd@quip.cz> >>> wrote: >>>> >>>> The version of sshd in FreeBSD 8.4 is not backward compatible with older >>>> version from 8.3. >>>> >>>> OpenSSH_5.4p1 (on FreeBSD 8.3) >>>> OpenSSH_6.1p1 (on FreeBSD 8.4) >>>> >>>> # sshd -t >>>> /etc/ssh/sshd_config line 19: Missing argument. >>>> >>>> On line 19, there is: >>>> VersionAddendum >>>> >>>> It was OK in older versions. It will remove any default text appended to >>>> SSH >>>> protocol banner (for example 'FreeBSD-20120901'). >>>> >>>> On FreeBSD 8.4, there must be some string (any single character) >>>> >>>> I was really badly surprised that the machine was re-booted without ssh >>>> access! >>>> >>>> I think this change is worth to mention in Release Notes >>>> >>>> Miroslav Lachman >>> >>> >>> How did you update to 8.4? This sounds more like messing up the >>> mergemaster(8)/freebsd-update merge procedure than a real problem with >>> the config file. >>> >>> This is the source configuration file straight from SVN releng/8.4 >>> branch and as you can see the VersionAddendum on line 115 is commented >>> out there: >>> >>> >>> http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup >> >> >> It was upgraded by freebsd-update. It was intentionally left here as it was >> valid configuration for many years. >> That's why I think it should be mentioned in the Release Notes, that it is >> no longer valid configuration (empty VersionAddendum). >> >> The fact, that it is no longer in default sshd_config file doesn't mean it >> can't be used at all. It is still valid in the form which was in old default >> config: "VersionAddendum FreeBSD-20100308", but is no longer valid if empty. >> That's the point. >> >> (and empty VersionAddendum was widely used, it is not my invention) >> >> Miroslav Lachman > > > You're missing my point totally. The line is commented out in the > official source of 8.4 and there for I have very hard time believing > that it would show up uncommented on a fresh 8.4 installation. I believe Miroslav is saying he left his old but previously working sshd_config as was when updating, so its a change to the code which now fails on an empty VersionAddendum, where it previously didn't hence the problem. 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 Wed Jun 19 23:52: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 4534CBB5 for ; Wed, 19 Jun 2013 23:52:22 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 0C12D1809 for ; Wed, 19 Jun 2013 23:52:21 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bv4so776283qab.11 for ; Wed, 19 Jun 2013 16:52:21 -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=TfNgKGZOlbCxXm3lL/6Pn+KEUslCXwl+whKHXhaDeWM=; b=Z85mzpdqEcKeXFk6QKs6mYViWoh/u/8SLfJhR2AbHBnkAAbo33oBVogoSlZKAGJk8Q ZFF/W7/JPBpPlIQGAh1pIX05g/pi/4Yc/kyNEPRRLzNyLJlHRrIXCNxjKqfLPRXndloL QhcoBK9j8DG7ZAKW9ZT9TcmEEgOMjh38GUSof/VBSp44zOOQSJ55T2NoijkPQqS86BUa ApsIzWB4H0IKL200EWsxW3Uw1JTHhP2ZcaxKdpL5AE96DGjs9biREuRulkYWfTcrdxaJ 8mMtFPnJ2piNy5VqYffMXm23PqArmt/Voxq6RgQmEWCsD220+B0D7kJ9axmv3nYpc/76 wsPg== MIME-Version: 1.0 X-Received: by 10.49.12.114 with SMTP id x18mr6433591qeb.25.1371685941556; Wed, 19 Jun 2013 16:52:21 -0700 (PDT) Received: by 10.224.182.148 with HTTP; Wed, 19 Jun 2013 16:52:21 -0700 (PDT) In-Reply-To: References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> Date: Thu, 20 Jun 2013 02:52:21 +0300 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Kimmo Paasiala To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable Stable , Miroslav Lachman <000.fbsd@quip.cz> 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, 19 Jun 2013 23:52:22 -0000 On Thu, Jun 20, 2013 at 2:40 AM, Steven Hartland wrote: > > > I believe Miroslav is saying he left his old but previously working > sshd_config as was when updating, so its a change to the code which > now fails on an empty VersionAddendum, where it previously didn't > hence the problem. > > Regards > Steve > > Err yes, your right. The proper way to specify empty VersionAddendum based on some googling seems to be now: VersionAddendum "" -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 00:09:35 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 4DAA72BA for ; Thu, 20 Jun 2013 00:09:35 +0000 (UTC) (envelope-from spork@bway.net) Received: from smtp1.bway.net (smtp1.v6.bway.net [IPv6:2607:d300:1::27]) by mx1.freebsd.org (Postfix) with ESMTP id 290A41901 for ; Thu, 20 Jun 2013 00:09:35 +0000 (UTC) Received: from [10.3.2.41] (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp1.bway.net (Postfix) with ESMTPSA id BD35295868; Wed, 19 Jun 2013 20:09:23 -0400 (EDT) References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 Date: Wed, 19 Jun 2013 20:09:23 -0400 To: Adam Vande More X-Mailer: Apple Mail (2.1085) Cc: Kimmo Paasiala , freebsd-stable Stable , Miroslav Lachman <000.fbsd@quip.cz> 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, 20 Jun 2013 00:09:35 -0000 On Jun 19, 2013, at 7:37 PM, Adam Vande More wrote: > On Wed, Jun 19, 2013 at 6:32 PM, Kimmo Paasiala = wrote: >=20 >> You're missing my point totally. The line is commented out in the >> official source of 8.4 and there for I have very hard time believing >> that it would show up uncommented on a fresh 8.4 installation. >=20 >=20 > I don't think this warrants a mention in the Release Notes for exactly = this > point, however it should probably be mentioned in UPDATING. If = nothing > else, that would at least keep UPDATING consistent with previous ssh = major > upgrades. +1 Even if you ran mergemaster and saw the change, without a comment above = the VersionAddendum line or mention in UPDATING, you might make any = number of assumptions about why it's commented out now. Given the = behavior (ie: sshd does not start) for those that have chosen in the = past not to tell the world what OS and build date they are running. Not really the best choice by the OpenSSH folks either, IMHO. I skim = the OpenSSH release notes sent to the -announce list and totally missed = this change. Charles >=20 > --=20 > Adam Vande More > _______________________________________________ > 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 Jun 20 00:15: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 83ECC64F for ; Thu, 20 Jun 2013 00:15:25 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 45AE21982 for ; Thu, 20 Jun 2013 00:15:25 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7162C2842F; Thu, 20 Jun 2013 02:15:24 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9735A2842B; Thu, 20 Jun 2013 02:15:23 +0200 (CEST) Message-ID: <51C2499B.2060209@quip.cz> Date: Thu, 20 Jun 2013 02:15:23 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Stable , 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, 20 Jun 2013 00:15:25 -0000 Kimmo Paasiala wrote: > On Thu, Jun 20, 2013 at 2:40 AM, Steven Hartland > wrote: >> >> >> I believe Miroslav is saying he left his old but previously working >> sshd_config as was when updating, so its a change to the code which >> now fails on an empty VersionAddendum, where it previously didn't >> hence the problem. Yes, this is my point - I left my old and previously working sshd_config with empty VersionAddendum. > Err yes, your right. The proper way to specify empty VersionAddendum > based on some googling seems to be now: > > > VersionAddendum "" This is not true, it will add two quotes to the banner: SSH-2.0-OpenSSH_6.1_hpn13v11 "" Default banner (no VersionAddendum in sshd_config): SSH-2.0-OpenSSH_6.1_hpn13v11 FreeBSD-20120901 So I am fine with: VersionAddendum - It will print: SSH-2.0-OpenSSH_6.1_hpn13v11 - I don't need really empty addendum, I just don't want to show FreeBSD version info and empty VersionAddendum was working for me many years. Now it breaks sshd after final reboot on two of our upgraded servers. So Release Notes or better UPDATING entry will warn other users before the same mistake. Thanks to the remote management / KVM on Sun Fire and Supermicro servers that I didn't need to drive to the datacenter and I can fix it remotely. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 00:24: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 339807C7 for ; Thu, 20 Jun 2013 00:24:45 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id EDECE19D2 for ; Thu, 20 Jun 2013 00:24:44 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id c11so3350664qcv.23 for ; Wed, 19 Jun 2013 17:24:44 -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=YbVJsqrg45RpNzpB+c1vx/bXkOJAd1K6TiAc8Ze2vsc=; b=OmncWfoKi43CbSNS1Pa4OmI8hoNrszjINeT+uBXZvcgDfXcPBBltaYAH4cs3aCXjsm jrat7vF7lmIR3etith9I4vEd6/9hOAHuopo3APzkMF0tWFiLn/6lkgmlLRgY5FZ7Ra1f K5F0PxYjmx3dLJpyb8S0pSEJbtJPg6wOpElX128WjM9iVx/93GbPkwkvdbFrb9cckf5+ ihTrkspSeLCfd4GzCr50YOj/e5viJU5wdb0FNMtZNw6e23Tpypz4dJbEnQdm7Ek7KzKf Lxi4lQqrConzsuoev6FlGvuvHygiImCQrIKfoCISkfPvMUkqGjoRVf+roTxwjvh7IO2r 401Q== MIME-Version: 1.0 X-Received: by 10.224.1.2 with SMTP id 2mr6548485qad.38.1371687884506; Wed, 19 Jun 2013 17:24:44 -0700 (PDT) Received: by 10.224.182.148 with HTTP; Wed, 19 Jun 2013 17:24:44 -0700 (PDT) In-Reply-To: <51C2499B.2060209@quip.cz> References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> <51C2499B.2060209@quip.cz> Date: Thu, 20 Jun 2013 03:24:44 +0300 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Kimmo Paasiala To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable Stable , 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, 20 Jun 2013 00:24:45 -0000 On Thu, Jun 20, 2013 at 3:15 AM, Miroslav Lachman <000.fbsd@quip.cz> wrote: > Kimmo Paasiala wrote: >> >> On Thu, Jun 20, 2013 at 2:40 AM, Steven Hartland >> wrote: >>> >>> >>> >>> I believe Miroslav is saying he left his old but previously working >>> sshd_config as was when updating, so its a change to the code which >>> now fails on an empty VersionAddendum, where it previously didn't >>> hence the problem. > > > Yes, this is my point - I left my old and previously working sshd_config > with empty VersionAddendum. > > >> Err yes, your right. The proper way to specify empty VersionAddendum >> based on some googling seems to be now: >> >> >> VersionAddendum "" > > > This is not true, it will add two quotes to the banner: > SSH-2.0-OpenSSH_6.1_hpn13v11 "" > > > Default banner (no VersionAddendum in sshd_config): > SSH-2.0-OpenSSH_6.1_hpn13v11 FreeBSD-20120901 > > > So I am fine with: > VersionAddendum - > > It will print: > SSH-2.0-OpenSSH_6.1_hpn13v11 - > > I don't need really empty addendum, I just don't want to show FreeBSD > version info and empty VersionAddendum was working for me many years. Now it > breaks sshd after final reboot on two of our upgraded servers. > > So Release Notes or better UPDATING entry will warn other users before the > same mistake. > > Thanks to the remote management / KVM on Sun Fire and Supermicro servers > that I didn't need to drive to the datacenter and I can fix it remotely. > > Miroslav Lachman Ok, this is crazy. If you put one space after the VersionAddendum keyword you get exactly what you want, an empty VersionAddendum string. If there's no space but a newline right after the VersionAddendum keyword, sshd(8) complains about the line and refuses to start. So this is ok (without the single quotes, they are just to show the endings of the lines): 'VersionAddendum ' But this is not: 'VersionAddendum' What are the OpenSSH devs thinking? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 08:26:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 143FFE9F for ; Thu, 20 Jun 2013 08:26:03 +0000 (UTC) (envelope-from javad.kouhi@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1101295 for ; Thu, 20 Jun 2013 08:26:02 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id eb20so5412017lab.1 for ; Thu, 20 Jun 2013 01:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=R9IZ1rzaFOrN7Ee3B4/pHRd36IxCzbdv7ODDeEJ2c0s=; b=hLIi9dVn+A5w8d4c8oZcuKC9L9wmGOCzF01OhpHanh+A81I22058Z3aALf+cXg6GwH 3mxXcbFXX3996k/fNWEbWpd2/GSUDfvjuwmrDG6wrovpOFy7MJnNuSfz9BzHnvgm3QKs pw7T3TONq/CMdSAmciGFjFvtwd75vg0VNf0oLNeW7Wjb6JuivbS0/Gc/QKUYwH/iL32V BoOU1jEN4yIH9vcBi/LeSwJzggtox+oU2/D/pREJfDLKdEgz+D+J2WwlFt6KCRsOGCVc HT48F3un2GasPpB1+aQI5PwwHiBRC4/IrvYNBQzIvM1Th+y43wAwhtHffPX4HrQaRF4c yizw== X-Received: by 10.112.125.199 with SMTP id ms7mr5003759lbb.29.1371716761475; Thu, 20 Jun 2013 01:26:01 -0700 (PDT) Received: from localhost ([2.181.105.241]) by mx.google.com with ESMTPSA id m1sm10676742lag.3.2013.06.20.01.25.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 20 Jun 2013 01:26:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Jeremy Chadwick" Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> <20130618182538.GA3380@icarus.home.lan> <20130618212818.GA58803@icarus.home.lan> Date: Thu, 20 Jun 2013 12:53:03 +0430 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Javad Kouhi" Message-ID: In-Reply-To: <20130618212818.GA58803@icarus.home.lan> User-Agent: Opera Mail/12.15 (FreeBSD) Cc: Michiel Boland , 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, 20 Jun 2013 08:26:03 -0000 On Wed, 19 Jun 2013 01:58:18 +0430, Jeremy Chadwick wrote: > On Wed, Jun 19, 2013 at 01:41:10AM +0430, Javad Kouhi wrote: >> I've read the posts again. Although the issue looks same as Michiel >> Boland (first link) but I'm not sure if the root of the issue is same >> as Michiel's too (second link). Anyway, it should be discussed in >> another thread as you said. > > Let me be more clear: > > I have seen repeated reports from people complaining about "lockups when > shutting down" many times over the years. The ones I remember: > > - Certain oddities with SCSI/SATA storage drivers and disks (many of > these have been fixed) > - ACPI-based reboot not working correctly on some motherboards > (depends on hw.acpi.handle_reboot and sometimes > hw.acpi.disable_on_reboot) -- not sure if this still pops up > - USB layer causing issues, or possibly some USB CAM integration > problem (this is still an ongoing one) > - Now some sort of weird Intel graphics driver (and DRM?) quirk > involving moused(8) and Vsync (the issue reported by Michiel) > > And I'm certain I'm forgetting others. > > What Kevin Oberman said also applies -- these are painful to debug > because the system is already in a "shutting down" state where usability > and accessibility becomes bare minimal, and you're kind of at your > wits end. > > Booting verbose can help -- there are other messages printed to the VGA > (and/or serial) console during the shutdown phase when verbose. > > All you can hope for is that the kernel is still alive and Ctrl-Alt-Esc > to force a drop to DDB (assuming all of this is enabled in your kernel) > works and that someone familiar with the FreeBSD kernel can help you > debug it (possibly it's just easier to do that, type "panic", then > issue "call doadump" to force a dump to swap at that point -- kib@ > might have better recommendations). > > Serial console can also greatly help, because quite often there are > pages upon pages of debugging information that are useful, otherwise you > have to hope the VGA console keyboard is functional (even more tricky > with USB) and that Scroll Lock + Page Up/Down function along with taking > photos of the screen; doing it this way is stressful and painful for > everyone involved. > > I hope this sheds some light on why I said what I did. :-) > Ok, I will compile a new kernel with DDB option. I will submit the crash info and dmesg output the next time it happens. (in a new thread) Thanks for your help. Regards, From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 09:54:31 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 25750F01 for ; Thu, 20 Jun 2013 09:54:31 +0000 (UTC) (envelope-from lee@dilkie.com) Received: from data.snhdns.com (data.snhdns.com [208.76.82.136]) by mx1.freebsd.org (Postfix) with ESMTP id E424818F0 for ; Thu, 20 Jun 2013 09:54:30 +0000 (UTC) Received: from [142.46.160.218] (port=50507 helo=[206.51.1.11]) by data.snhdns.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UpbAI-00019q-Br; Thu, 20 Jun 2013 05:28:26 -0400 Message-ID: <51C2CB42.4030301@dilkie.com> Date: Thu, 20 Jun 2013 05:28:34 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> <51C2499B.2060209@quip.cz> In-Reply-To: X-Enigmail-Version: 1.5.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - data.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dilkie.com X-Get-Message-Sender-Via: data.snhdns.com: authenticated_id: lee@dilkie.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Steven Hartland , freebsd-stable Stable , Miroslav Lachman <000.fbsd@quip.cz> 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, 20 Jun 2013 09:54:31 -0000 On 6/19/2013 8:24 PM, Kimmo Paasiala wrote: > Ok, this is crazy. If you put one space after the VersionAddendum > keyword you get exactly what you want, an empty VersionAddendum > string. If there's no space but a newline right after the > VersionAddendum keyword, sshd(8) complains about the line and refuses > to start. So this is ok (without the single quotes, they are just to > show the endings of the lines): > > 'VersionAddendum ' > > But this is not: > > 'VersionAddendum' > > What are the OpenSSH devs thinking? > > -Kimmo I'd call it a bug. -lee From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 12:23:18 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 229C8FBB for ; Thu, 20 Jun 2013 12:23:18 +0000 (UTC) (envelope-from emmanuel.cozic@sfr.fr) Received: from smtp11.services.sfr.fr (smtp11.services.sfr.fr [93.17.128.28]) by mx1.freebsd.org (Postfix) with ESMTP id E05DC1133 for ; Thu, 20 Jun 2013 12:23:17 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf1104.sfr.fr (SMTP Server) with ESMTP id 15E637000045 for ; Thu, 20 Jun 2013 14:14:08 +0200 (CEST) Received: from wsfrf1127 (wsfrf1127 [10.18.24.41]) by msfrf1104.sfr.fr (SMTP Server) with ESMTP id 0A9EA7000088 for ; Thu, 20 Jun 2013 14:14:08 +0200 (CEST) X-SFR-UUID: 20130620121408435.0A9EA7000088@msfrf1104.sfr.fr Date: Thu, 20 Jun 2013 14:14:08 +0200 (CEST) From: emmanuel cozic To: FreeBSD-stable@FreeBSD.org Message-ID: <27767375.35230.1371730448035.JavaMail.www@wsfrf1127> Subject: =?utf-8?Q?Problem_with_live_cd_:=C2=B0(?= MIME-Version: 1.0 X-SAVECOPY: true X-ORIGINATING-IP: 77.198.12.102 X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-REPLYTO: |~| Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: emmanuel cozic List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 12:23:18 -0000 Hi What is the login end the password for live cd FreeBSD 9.1, please ? Thank you Emmanuel France From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 12:47:22 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 2E907B94 for ; Thu, 20 Jun 2013 12:47:22 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id EDBCF1480 for ; Thu, 20 Jun 2013 12:47:21 +0000 (UTC) Received: from [172.29.180.39] (unknown [194.214.114.46]) by peterschmitt.fr (Postfix) with ESMTPSA id 84DDFB9C2 for ; Thu, 20 Jun 2013 14:47:16 +0200 (CEST) Message-ID: <51C2FA34.1040905@peterschmitt.fr> Date: Thu, 20 Jun 2013 14:48:52 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Problem with live cd =?ISO-8859-1?Q?=3A=B0=28?= References: <27767375.35230.1371730448035.JavaMail.www@wsfrf1127> In-Reply-To: <27767375.35230.1371730448035.JavaMail.www@wsfrf1127> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JTKUNPDRDVRXOSXIJIEF" 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, 20 Jun 2013 12:47:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JTKUNPDRDVRXOSXIJIEF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable root no password Le 20/06/2013 14:14, emmanuel cozic a =E9crit : > Hi >=20 > What is the login end the password for live cd FreeBSD 9.1, please ? >=20 > Thank you > Emmanuel >=20 > France > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >=20 --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | Thank you :) ------enig2JTKUNPDRDVRXOSXIJIEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJRwvo5AAoJEMtO2Sol0IImm+kH/ja1A+4+DlxGgrb+lXPWRuXS KdzBNYkAMYkoABx0KBcpX080kN8XmbWZc5+RbbWlctR49yE5yq+enJimbPNf5CFH BsWKvuFMNafdp03SQR4tV4J3FzKtMC/AcHqhXMM7WtzHWIF2jrbIHMntf5SwZPh+ f9eWdDI0qKzhDpDMlLvlUAIww3A4SNgnMZSFlz70p5VmgOMSVOp6jyLN7vzXym2P 7sBA5uIquNWOeXYhiZlTJpMkaHD85zvag+ycbrWneQpxTOMZgbXY+UhE/g1TqV5I 8BAqIDnz0+JlH3R0YwqpIcsJG30p96z2m1u1n/daoVzh+c+3ToyIkndXNx+edPQ= =17R/ -----END PGP SIGNATURE----- ------enig2JTKUNPDRDVRXOSXIJIEF-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 12:48:06 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 14186CB4 for ; Thu, 20 Jun 2013 12:48:06 +0000 (UTC) (envelope-from feld@feld.me) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id DC8AF15C5 for ; Thu, 20 Jun 2013 12:48:02 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 70F0720F11; Thu, 20 Jun 2013 08:47:56 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 20 Jun 2013 08:47:56 -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=vSEY6zKM/MS7/zuZmljU0SNv8us=; b=XBxsB2Y6jfm+qucIIGi4D Dz8D+Hog2++DaJG1XaIJEuRSaA8hTDtCv9HBxchuRAIRlAbj1iKrusSvr0+WIu8T G1lCoyNbUbfc/FYtAJ2dDeTAckrsWxH0Ojrw/OdO2lRfZNnmoMSNbun7nNlDcMUb yCVWyCfJKVnI9GOMJQmfVM= 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=vSEY6zKM/MS7/zuZmljU0SNv8us=; b=bdJv +0Ii1XDRod1b+4kwBTty8AvpD6U6AlKsWxqT60Rj/KRnBbjh0/NfEhj3HvsoL87L ofwDPkJzPh/WNYqrOlSeB5FsMaqKFhFPB3I9PhZebvRWpSEvUj/aBaDiIC0CetKm 0ZghAfBZrXSKobXpAzsCYNDNZ3zTFp587uaI9Zs= X-Sasl-enc: Y+u8EyZr+/0Di2lmp5+ZM7ds+F0ok4xG+xatseL2kk25 1371732472 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 598C3680445; Thu, 20 Jun 2013 08:47:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: FreeBSD-stable@freebsd.org, "emmanuel cozic" Subject: Re: =?utf-8?Q?Problem_with_live_cd_=3A=C2=B0=28?= References: <27767375.35230.1371730448035.JavaMail.www@wsfrf1127> Date: Thu, 20 Jun 2013 07:47:51 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <27767375.35230.1371730448035.JavaMail.www@wsfrf1127> 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: Thu, 20 Jun 2013 12:48:06 -0000 On Thu, 20 Jun 2013 07:14:08 -0500, emmanuel cozic wrote: > Hi > > What is the login end the password for live cd FreeBSD 9.1, please ? > There is no password. You should be able to use user "root" with a blank password. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 13:16:28 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 4FA40CC8 for ; Thu, 20 Jun 2013 13:16:28 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id DCF751857 for ; Thu, 20 Jun 2013 13:16:27 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r5KDCFDD048716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 15:12:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <51C2FFAA.7030707@omnilan.de> Date: Thu, 20 Jun 2013 15:12:10 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: ftp-proxy(8) doesn't respect "-a" (source address for outgoing control connection) X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC837EB179514C3D3E992DA90" 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, 20 Jun 2013 13:16:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC837EB179514C3D3E992DA90 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, according to man (8) ftp-proxy, "-a 1.2.3.4" should instruct ftp-proxy to use 1.2.3.4 as source address for outgoing control connections. But it doesn't. It seems to greatly ignor that directive, since I can pass any address, ieven if the machine doesn't own it. It always uses the EGRES interface's inet address - inet6 not tested. Any ideas why? Thanks, -Harry --------------enigC837EB179514C3D3E992DA90 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlHC/68ACgkQLDqVQ9VXb8hwIgCgqJPl14Z7GUBVmdouN7XVZTPr czYAn2RlkrtoUun+nxXVIkDQfbkqbCJy =k9tm -----END PGP SIGNATURE----- --------------enigC837EB179514C3D3E992DA90-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 16:59: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 7CD51139 for ; Thu, 20 Jun 2013 16:59:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 4595316DD for ; Thu, 20 Jun 2013 16:59:54 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so7569408obc.34 for ; Thu, 20 Jun 2013 09:59: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=DJLq6NRm19i9a0uZH1wepI844MBifMCSHhCez51+Nk0=; b=bCtX4/o7kI71u3o+GE+orWC5vR5adhiQfCyDMuR4BfWFjRsg1/MRZizEulhYJ6dOa5 QiSrZWO62JzZtw7ZWo+7FJ5G0C3pLFNcnivxmCWpEgOATwcae2OGgsZ3aPZxDLueNvvT sUxu54dBUjELEEzQDdAdY9Jui4a50QcvV7bCWuXU2n/Mt+iHeRgtQ8TZcGoHyjwupb6Q mNQuvWASbyK9t0QJoaBmq1D5cLLJK+F+nTCTfW2L/bH4cQ9046CcbwRctpZ3o+HJyWjG 3kWqtSHuDhm3T6mZV7T8N8Su8T2+cEUSN0Ll1exOitb12jAZ9Xi90K9zs89oo+TDX2Yd /OEQ== MIME-Version: 1.0 X-Received: by 10.60.146.242 with SMTP id tf18mr4599183oeb.115.1371747593891; Thu, 20 Jun 2013 09:59:53 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 20 Jun 2013 09:59:53 -0700 (PDT) In-Reply-To: References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> <51C06AD2.5030404@xs4all.nl> <20130618144722.GA3446@icarus.home.lan> <20130618182538.GA3380@icarus.home.lan> <20130618212818.GA58803@icarus.home.lan> Date: Thu, 20 Jun 2013 09:59:53 -0700 X-Google-Sender-Auth: mU0pUHfzuxS5gozX1nQI3WrEojg Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Kevin Oberman To: Javad Kouhi Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , Michiel Boland , "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: Thu, 20 Jun 2013 16:59:54 -0000 On Thu, Jun 20, 2013 at 1:23 AM, Javad Kouhi wrote: > On Wed, 19 Jun 2013 01:58:18 +0430, Jeremy Chadwick > wrote: > > On Wed, Jun 19, 2013 at 01:41:10AM +0430, Javad Kouhi wrote: >> >>> I've read the posts again. Although the issue looks same as Michiel >>> Boland (first link) but I'm not sure if the root of the issue is same >>> as Michiel's too (second link). Anyway, it should be discussed in >>> another thread as you said. >>> >> >> Let me be more clear: >> >> I have seen repeated reports from people complaining about "lockups when >> shutting down" many times over the years. The ones I remember: >> >> - Certain oddities with SCSI/SATA storage drivers and disks (many of >> these have been fixed) >> - ACPI-based reboot not working correctly on some motherboards >> (depends on hw.acpi.handle_reboot and sometimes >> hw.acpi.disable_on_reboot) -- not sure if this still pops up >> - USB layer causing issues, or possibly some USB CAM integration >> problem (this is still an ongoing one) >> - Now some sort of weird Intel graphics driver (and DRM?) quirk >> involving moused(8) and Vsync (the issue reported by Michiel) >> >> And I'm certain I'm forgetting others. >> >> What Kevin Oberman said also applies -- these are painful to debug >> because the system is already in a "shutting down" state where usability >> and accessibility becomes bare minimal, and you're kind of at your >> wits end. >> >> Booting verbose can help -- there are other messages printed to the VGA >> (and/or serial) console during the shutdown phase when verbose. >> >> All you can hope for is that the kernel is still alive and Ctrl-Alt-Esc >> to force a drop to DDB (assuming all of this is enabled in your kernel) >> works and that someone familiar with the FreeBSD kernel can help you >> debug it (possibly it's just easier to do that, type "panic", then >> issue "call doadump" to force a dump to swap at that point -- kib@ >> might have better recommendations). >> >> Serial console can also greatly help, because quite often there are >> pages upon pages of debugging information that are useful, otherwise you >> have to hope the VGA console keyboard is functional (even more tricky >> with USB) and that Scroll Lock + Page Up/Down function along with taking >> photos of the screen; doing it this way is stressful and painful for >> everyone involved. >> >> I hope this sheds some light on why I said what I did. :-) >> >> > > Ok, I will compile a new kernel with DDB option. I will submit the crash > info and dmesg output the next time it happens. (in a new thread) > > Thanks for your help. > > Regards, > Please note that head was just patched to fix the moused issue. The fix is also applicable to 9, but I don't know when it might be MFCed. Several people have reported that it does resolve the problem (which is an infinite loop in the kernel) and my first test seems to indicate that it works for me, but I can't be sure as the problem was sporadic. And, yes, I would LOVE to have a serial console back when Intel KMS is used! -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 18:28: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 C727CEFC for ; Thu, 20 Jun 2013 18:28:45 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [88.98.64.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8D84E1B58 for ; Thu, 20 Jun 2013 18:28:45 +0000 (UTC) Received: from filter.mx0.thekeelecentre.com (unknown [88.98.64.55]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 990BFB921; Thu, 20 Jun 2013 19:23:44 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([88.98.64.52]) by filter.mx0.thekeelecentre.com (filter.mx0.thekeelecentre.com [88.98.64.55]) (amavisd-new, port 10024) with ESMTP id 1Nr7m6QjCpIQ; Thu, 20 Jun 2013 18:23:42 +0000 (UTC) Received: from [10.0.2.11] (nat-gw.hl.tector.org.uk [88.96.67.61]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 84E42B963; Thu, 20 Jun 2013 19:23:41 +0100 (BST) Message-ID: <51C34861.4090501@thekeelecentre.com> Date: Thu, 20 Jun 2013 19:22:25 +0100 From: Richard Tector User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Strohl Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> In-Reply-To: <51C1979D.3010305@ateamsystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jdc@koitsu.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:28:45 -0000 On 19/06/2013 12:35, Adam Strohl wrote: > Hello -STABLE@, > > So I've seen this situation seemingly randomly on a number of both > physical 9.1 boxes as well as VMs for I would say 6-9 months at least. > I finally have a physical box here that reproduces it consistently > that I can reboot easily (ie; not a production/client server). > > No matter what I do: > > reboot > shutdown -p > shutdown -r > > This specific server will stop at "All buffers synced" and not actually > power down or reboot. KB input seems to be ignored. This server is a > ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show > this are using GMIRRORs for root/swap/boot (no ZFS). > > Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg > Hi, Just to add a 'me too'. I see this on two different boxes, both currently running recentish 9.1-STABLE, and it has definitely been an issue for me since at least 9.0-RELEASE. One of the boxes is a Dell R210 II with a single WD HDD - dmesg: http://daniel.thekeelecentre.com/dmesg.txt I've tried booting/rebooting without the USB KVM dongle attached too. Notes - does not run moused and no OpenLDAP. The second host I have the issue with is a home-build using a Tyan Toledo i3210W (S5211) and two Seagate HDDs - dmesg: http://daniel.thekeelecentre.com/dmesg-daffy.txt (yes, a disk has failed, but the reboot issue pre-dated this). Note - does not run moused, but did run slapd. I saw the same DB corruption as the OP. I can play with the latter box as it is no longer in use and will try the following suggestions from Jeremy later this evening: 4. Does "sysctl hw.usb.no_shutdown_wait=1" help you? 5. Does "sysctl hw.acpi.handle_reboot=1" help you? 6. Does "sysctl hw.acpi.disable_on_reboot=1" help you? Regards, Richard From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 21:19:32 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 BF4B9456; Thu, 20 Jun 2013 21:19:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 31F2717AF; Thu, 20 Jun 2013 21:19:32 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id j10so4099123qcx.31 for ; Thu, 20 Jun 2013 14:19:31 -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=8ewbsP4jJu27F5S0qDDQ2GwhpePTCh14wei1chRH8rA=; b=0EvWTqOZacwyAq6rrC+clzVr4U6aXotoxnzQR2pQ6qYFcx1IdfPCrj6s0DWOAdfKQG qsN7NcUvRe8++/qe6ZASbCN8EP6zVMyUPiGyyC/vT3JrYH3/vQHbb0y/dk1T106TDfJn qSBlwz03ZqgGqVhPmMnx0DIfjSaV9TcBV4dYge9wzqv9xBhYqSKJt9wXxG7NwWpyyqJC siWfjG9k2g2epj1NKw7tLm5zyQrygXAlBA3cbbq9jmlZw8UD1WWc7vZT/JNJ/YMZbYLx J+ixFOepxboccm0WtqBzugdkwRUAIvHtYSDDFxwFmOud2h8NdWehZl8mmaD4AYWMNTyg VThA== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr11124638qaz.12.1371763171775; Thu, 20 Jun 2013 14:19:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.5.65 with HTTP; Thu, 20 Jun 2013 14:19:31 -0700 (PDT) Date: Thu, 20 Jun 2013 14:19:31 -0700 X-Google-Sender-Auth: 08yK_w_fagDArl7LF5JBDq-PMyA Message-ID: Subject: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: freebsd-usb@freebsd.org, freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=089e0149ce0491d92d04df9c80d1 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: Thu, 20 Jun 2013 21:19:32 -0000 --089e0149ce0491d92d04df9c80d1 Content-Type: text/plain; charset=ISO-8859-1 Hi, FreeBSD-9 works fine on this Lenovo T400 - except that suspending with no USB devices plugged in result in no ports working after resume. If I have a device plugged in during suspend - on any port - then all the ports work fine after resume. I've attached usbconfig and acpidump output. here's what is logged in the kernel buffer during suspend and resume: Her'es the suspend: Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34 Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1 (disconnected) Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1 (disconnected) Jun 20 14:03:38 lucy kernel: ugen1.2: at usbus1 (disconnected) Jun 20 14:03:38 lucy kernel: ugen1.3: at usbus1 (disconnected) Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3 (disconnected) Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: ugen3.2: at usbus3 (disconnected) Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2 (disconnected) Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 1 refs Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry Jun 20 14:03:47 lucy kernel: ugen3.3: at usbus3 (disconnected) Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1 (disconnected) Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1 (disconnected) ..and resume: I wonder what these devices are? Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button status Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06) Jun 20 14:03:47 lucy kernel: [100067] uhub0: on usbus7 Jun 20 14:03:47 lucy kernel: [100046] uhub1: on usbus3 Jun 20 14:03:47 lucy kernel: [100031] uhub2: on usbus0 Jun 20 14:03:47 lucy kernel: [100036] uhub3: on usbus1 Jun 20 14:03:47 lucy kernel: [100057] uhub4: on usbus5 Jun 20 14:03:47 lucy kernel: [100052] uhub5: on usbus4 Jun 20 14:03:47 lucy kernel: [100062] uhub6: on usbus6 Jun 20 14:03:47 lucy kernel: [100041] uhub7: on usbus2 .. local APIC error? Jun 20 14:03:47 lucy kernel: CPU0: local APIC error 0x40 Jun 20 14:03:47 lucy acpi: resumed at 20130620 14:03:47 It probes the hubs fine though. Thanks! Adrian --089e0149ce0491d92d04df9c80d1 Content-Type: text/plain; charset=US-ASCII; name="usbconfig.txt" Content-Disposition: attachment; filename="usbconfig.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hi6gdf611 dWdlbjAuMTogPFVIQ0kgcm9vdCBIVUIgSW50ZWw+IGF0IHVzYnVzMCwgY2ZnPTAgbWQ9SE9TVCBz cGQ9RlVMTCAoMTJNYnBzKSBwd3I9U0FWRSAoMG1BKQp1Z2VuMS4xOiA8VUhDSSByb290IEhVQiBJ bnRlbD4gYXQgdXNidXMxLCBjZmc9MCBtZD1IT1NUIHNwZD1GVUxMICgxMk1icHMpIHB3cj1TQVZF ICgwbUEpCnVnZW4yLjE6IDxVSENJIHJvb3QgSFVCIEludGVsPiBhdCB1c2J1czIsIGNmZz0wIG1k PUhPU1Qgc3BkPUZVTEwgKDEyTWJwcykgcHdyPVNBVkUgKDBtQSkKdWdlbjMuMTogPEVIQ0kgcm9v dCBIVUIgSW50ZWw+IGF0IHVzYnVzMywgY2ZnPTAgbWQ9SE9TVCBzcGQ9SElHSCAoNDgwTWJwcykg cHdyPVNBVkUgKDBtQSkKdWdlbjQuMTogPFVIQ0kgcm9vdCBIVUIgSW50ZWw+IGF0IHVzYnVzNCwg Y2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAoMTJNYnBzKSBwd3I9U0FWRSAoMG1BKQp1Z2VuNS4xOiA8 VUhDSSByb290IEhVQiBJbnRlbD4gYXQgdXNidXM1LCBjZmc9MCBtZD1IT1NUIHNwZD1GVUxMICgx Mk1icHMpIHB3cj1TQVZFICgwbUEpCnVnZW42LjE6IDxVSENJIHJvb3QgSFVCIEludGVsPiBhdCB1 c2J1czYsIGNmZz0wIG1kPUhPU1Qgc3BkPUZVTEwgKDEyTWJwcykgcHdyPVNBVkUgKDBtQSkKdWdl bjcuMTogPEVIQ0kgcm9vdCBIVUIgSW50ZWw+IGF0IHVzYnVzNywgY2ZnPTAgbWQ9SE9TVCBzcGQ9 SElHSCAoNDgwTWJwcykgcHdyPVNBVkUgKDBtQSkKdWdlbjMuMjogPERUIDEwMSBHMiBLaW5nc3Rv bj4gYXQgdXNidXMzLCBjZmc9MCBtZD1IT1NUIHNwZD1ISUdIICg0ODBNYnBzKSBwd3I9T04gKDIw MG1BKQp1Z2VuMS4yOiA8RmluZ2VycHJpbnQgU2Vuc29yIHZlbmRvciAweDA4ZmY+IGF0IHVzYnVz MSwgY2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAoMTJNYnBzKSBwd3I9T04gKDEwMG1BKQp1Z2VuMy4z OiA8SW50ZWdyYXRlZCBDYW1lcmEgQ2hpY29ueSBFbGVjdHJvbmljcyBDby4sIEx0ZC4+IGF0IHVz YnVzMywgY2ZnPTAgbWQ9SE9TVCBzcGQ9SElHSCAoNDgwTWJwcykgcHdyPU9OICg1MDBtQSkKdWdl bjEuMzogPFRoaW5rUGFkIEJsdWV0b290aCB3aXRoIEVuaGFuY2VkIERhdGEgUmF0ZSBJSSBMZW5v dm8gQ29tcHV0ZXIgQ29ycD4gYXQgdXNidXMxLCBjZmc9MCBtZD1IT1NUIHNwZD1GVUxMICgxMk1i cHMpIHB3cj1PTiAoMTAwbUEpCg== --089e0149ce0491d92d04df9c80d1-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 20 23:54:50 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 207D1E1 for ; Thu, 20 Jun 2013 23:54:50 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id A20FA1D4D for ; Thu, 20 Jun 2013 23:54:49 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r5KNsfGw093422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 01:54:41 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r5KNt4f5002042; Fri, 21 Jun 2013 01:55:04 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r5KNt2mc002041; Fri, 21 Jun 2013 01:55:02 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Konstantin Belousov Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG In-Reply-To: <20130617193726.GR91021@kib.kiev.ua> (Konstantin Belousov's message of "Mon, 17 Jun 2013 22:37:26 +0300") References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Fri, 21 Jun 2013 01:55:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Michiel Boland , 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: Thu, 20 Jun 2013 23:54:50 -0000 Konstantin Belousov writes: > On Mon, Jun 17, 2013 at 09:16:56PM +0200, Michiel Boland wrote: >> On 06/16/2013 17:11, Michiel Boland wrote: >> > Hi. Recently I switched to WITH_NEW_XORG, primarily because the >> > stock X server >> > with Intel driver has some issues that make it unusable for me. >> > >> > The new X server and Intel driver works extremely well, so kudos >> > to whoever made >> > this possible. >> > >> > Unfortunately, I am now experiencing random hangs on shutdown. On >> > shutdown the >> > system randomly freezes after >> > >> > [...] syslogd: exiting on signal 15 >> > >> > I would then expect to see 'Waiting (max 60 seconds) for system >> > process 'XXX' to >> > stop messages, but these never arrive. >> >> So it turns out that init hangs because vga_txtmouse (draw_txtmouse in fact) is >> hogging the clock swi. The routine is waiting for a vertical retrace which never >> arrives. (The new intel driver can't return to text console, so the screen just >> goes blank when X exits.) >> >> Some workarounds: >> >> - don't run moused (i.e. disable it in rc.conf and devd.conf) >> instead run the X server in combination with hald >> >> - do run moused, but then either >> >> - unplug the mouse before shutting down >> >> - build a kernel with VGA_NO_FONT_LOADING >> >> Of course the long-term fix is to remove the possibly infinite loop in >> draw_txtmouse. >> >> Thanks to Konstantin for his patience in helping me track this down. > > The following patch, although a hack, should fix the issue. > Michiel tested it. > > diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c > index 3cb3b78..e41a49f 100644 > --- a/sys/dev/drm2/i915/intel_fb.c > +++ b/sys/dev/drm2/i915/intel_fb.c > @@ -207,6 +207,8 @@ static void intel_fbdev_destroy(struct drm_device *dev, > } > } > > +extern int sc_txtmouse_no_retrace_wait; > + > int intel_fbdev_init(struct drm_device *dev) > { > struct intel_fbdev *ifbdev; > @@ -229,6 +231,7 @@ int intel_fbdev_init(struct drm_device *dev) > > drm_fb_helper_single_add_all_connectors(&ifbdev->helper); > drm_fb_helper_initial_config(&ifbdev->helper, 32); > + sc_txtmouse_no_retrace_wait = 1; > return 0; > } > > diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c > index 6e6663c..fc7f02f 100644 > --- a/sys/dev/syscons/scvgarndr.c > +++ b/sys/dev/syscons/scvgarndr.c > @@ -395,6 +395,8 @@ vga_txtblink(scr_stat *scp, int at, int flip) > { > } > > +int sc_txtmouse_no_retrace_wait; > + > #ifndef SC_NO_CUTPASTE > > static void > @@ -445,7 +447,9 @@ draw_txtmouse(scr_stat *scp, int x, int y) > #if 1 > /* wait for vertical retrace to avoid jitter on some videocards */ > crtc_addr = scp->sc->adp->va_crtc_addr; > - while (!(inb(crtc_addr + 6) & 0x08)) /* idle */ ; > + while (!sc_txtmouse_no_retrace_wait && > + !(inb(crtc_addr + 6) & 0x08)) > + /* idle */ ; > #endif > c = scp->sc->mouse_char; > vidd_load_font(scp->sc->adp, 0, 32, 8, font_buf, c, 4); This patch fixes the shutdown hangs after KMS is initialised for me (on a Thinkpad X201 w recent 9-STABLE)! Thanks! 9.1-REL does not hang, however. Don't know whether this is interesting, but I bisected 9-STABLE to find out where the problem started (kernel only together with 9.1-REL userland). 9-STABLE up to and including r246775 works as it should, but starting with r246785, it hangs on shutdown. See (yes, it is mouse related!): http://svnweb.freebsd.org/base?view=revision&revision=246785 Just to be clear: These hangs _only_ occur if KMS gets initialised. When testing this, I booted, started kdm, and then chose shutdown in the kdm menu. moused was running. Bengt From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 04:54:46 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 3DE99B2F for ; Fri, 21 Jun 2013 04:54:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 0898B1950 for ; Fri, 21 Jun 2013 04:54:45 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id va7so8006803obc.27 for ; Thu, 20 Jun 2013 21:54: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=CwQ8xrAXvot+LZVMthrKE8mdRZjRzOOJwdhWh14glOg=; b=qiRNKzE9SvrTaQ2E6PwoIo3SES6Keu9f+9ZBFXOEmlRKePIBu0au7Gg38od95TLy0Y 62uc74ZlTcnJPKJQ1d22sbnJDTu2F+g0JC/s/bffDZ7DcLfoapYhrfvb6urZjDIkj+LL V/nnF5xtAbSDgCZEh7OlbIGWStWYVHREj+4FtHuD7XTwJMWL/7d25DNVsITNiced8hlM 46SAxenbt9p+4oVa95MhzYHr7oOWyFYnr7XF54NrJJxXcuAHvkRAA/2GyEw5mT/XFwl1 aiRs3+yt25LuCoYrPz3KIMyFFhHSVgK16QpYW5sEY9r2zc7GQXJHZ7VkEbwwdZPqaBGX CVvQ== MIME-Version: 1.0 X-Received: by 10.182.242.45 with SMTP id wn13mr2831236obc.30.1371790485547; Thu, 20 Jun 2013 21:54:45 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 20 Jun 2013 21:54:45 -0700 (PDT) In-Reply-To: References: <51BDD593.5000102@xs4all.nl> <51BF60A8.6000503@xs4all.nl> <20130617193726.GR91021@kib.kiev.ua> Date: Thu, 20 Jun 2013 21:54:45 -0700 X-Google-Sender-Auth: 1UCIzJ3mHKHHNDg8k-ItJqNN_bM Message-ID: Subject: Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG From: Kevin Oberman To: Bengt Ahlgren Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , Michiel Boland , 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: Fri, 21 Jun 2013 04:54:46 -0000 On Thu, Jun 20, 2013 at 4:55 PM, Bengt Ahlgren wrote: > Konstantin Belousov writes: > > > On Mon, Jun 17, 2013 at 09:16:56PM +0200, Michiel Boland wrote: > >> On 06/16/2013 17:11, Michiel Boland wrote: > >> > Hi. Recently I switched to WITH_NEW_XORG, primarily because the > >> > stock X server > >> > with Intel driver has some issues that make it unusable for me. > >> > > >> > The new X server and Intel driver works extremely well, so kudos > >> > to whoever made > >> > this possible. > >> > > >> > Unfortunately, I am now experiencing random hangs on shutdown. On > >> > shutdown the > >> > system randomly freezes after > >> > > >> > [...] syslogd: exiting on signal 15 > >> > > >> > I would then expect to see 'Waiting (max 60 seconds) for system > >> > process 'XXX' to > >> > stop messages, but these never arrive. > >> > >> So it turns out that init hangs because vga_txtmouse (draw_txtmouse in > fact) is > >> hogging the clock swi. The routine is waiting for a vertical retrace > which never > >> arrives. (The new intel driver can't return to text console, so the > screen just > >> goes blank when X exits.) > >> > >> Some workarounds: > >> > >> - don't run moused (i.e. disable it in rc.conf and devd.conf) > >> instead run the X server in combination with hald > >> > >> - do run moused, but then either > >> > >> - unplug the mouse before shutting down > >> > >> - build a kernel with VGA_NO_FONT_LOADING > >> > >> Of course the long-term fix is to remove the possibly infinite loop in > >> draw_txtmouse. > >> > >> Thanks to Konstantin for his patience in helping me track this down. > > > > The following patch, although a hack, should fix the issue. > > Michiel tested it. > > > > diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c > > index 3cb3b78..e41a49f 100644 > > --- a/sys/dev/drm2/i915/intel_fb.c > > +++ b/sys/dev/drm2/i915/intel_fb.c > > @@ -207,6 +207,8 @@ static void intel_fbdev_destroy(struct drm_device > *dev, > > } > > } > > > > +extern int sc_txtmouse_no_retrace_wait; > > + > > int intel_fbdev_init(struct drm_device *dev) > > { > > struct intel_fbdev *ifbdev; > > @@ -229,6 +231,7 @@ int intel_fbdev_init(struct drm_device *dev) > > > > drm_fb_helper_single_add_all_connectors(&ifbdev->helper); > > drm_fb_helper_initial_config(&ifbdev->helper, 32); > > + sc_txtmouse_no_retrace_wait = 1; > > return 0; > > } > > > > diff --git a/sys/dev/syscons/scvgarndr.c b/sys/dev/syscons/scvgarndr.c > > index 6e6663c..fc7f02f 100644 > > --- a/sys/dev/syscons/scvgarndr.c > > +++ b/sys/dev/syscons/scvgarndr.c > > @@ -395,6 +395,8 @@ vga_txtblink(scr_stat *scp, int at, int flip) > > { > > } > > > > +int sc_txtmouse_no_retrace_wait; > > + > > #ifndef SC_NO_CUTPASTE > > > > static void > > @@ -445,7 +447,9 @@ draw_txtmouse(scr_stat *scp, int x, int y) > > #if 1 > > /* wait for vertical retrace to avoid jitter on some videocards */ > > crtc_addr = scp->sc->adp->va_crtc_addr; > > - while (!(inb(crtc_addr + 6) & 0x08)) /* idle */ ; > > + while (!sc_txtmouse_no_retrace_wait && > > + !(inb(crtc_addr + 6) & 0x08)) > > + /* idle */ ; > > #endif > > c = scp->sc->mouse_char; > > vidd_load_font(scp->sc->adp, 0, 32, 8, font_buf, c, 4); > > This patch fixes the shutdown hangs after KMS is initialised for me (on > a Thinkpad X201 w recent 9-STABLE)! Thanks! > > 9.1-REL does not hang, however. Don't know whether this is interesting, > but I bisected 9-STABLE to find out where the problem started (kernel > only together with 9.1-REL userland). 9-STABLE up to and including > r246775 works as it should, but starting with r246785, it hangs on > shutdown. See (yes, it is mouse related!): > > http://svnweb.freebsd.org/base?view=revision&revision=246785 > > Just to be clear: These hangs _only_ occur if KMS gets initialised. > When testing this, I booted, started kdm, and then chose shutdown in the > kdm menu. moused was running. > > Bengt > See *251961* to see the work-around and an explanation of what it worked around. This goes away when return to console mode is available with KMS. The problem is as old as KMS support, but 246785triggered it most of the time when it was occasional before that. It's a race issue. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 07:22:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 472568A0 for ; Fri, 21 Jun 2013 07:22:47 +0000 (UTC) (envelope-from iphonein@ejobsitesoftware.webserversystems.com) Received: from ejobsitesoftware.webserversystems.com (50.22.7.205-static.reverse.softlayer.com [50.22.7.205]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFD91E59 for ; Fri, 21 Jun 2013 07:22:47 +0000 (UTC) Received: from iphonein by ejobsitesoftware.webserversystems.com with local (Exim 4.80) (envelope-from ) id 1Upvg9-0007Lg-NY for freebsd-stable@freebsd.org; Fri, 21 Jun 2013 02:22:41 -0500 To: freebsd-stable@freebsd.org Subject: =?utf-8?B?0J/RgNC+0LTQstC40LbQtdC90LjQtSDQv9GA0LXQtNC70L7QttC10L3QuNC5?= X-PHP-Script: iphoneindia.com/wp-content/plugins/mains.php for 10.103.156.232, 124.160.194.71 From: =?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0=?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Date: Fri, 21 Jun 2013 02:22:41 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ejobsitesoftware.webserversystems.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [571 571] / [47 12] X-AntiAbuse: Sender Address Domain - ejobsitesoftware.webserversystems.com 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, 21 Jun 2013 07:22:47 -0000 Доброe время суток! Меня зовут Константин. Наша фирма занимается продвижением любых товаров и услуг в сети. Есть к Вам предложение: Ваш товар или услугу можно написать в предложении и распространить его по email адресам. Стоимость услуги - совсем невысокая. В случае заинтересованности - я соберу для Вас базу по необходимым критериям. Было бы интересно Вам попробовать предлагаемый метод поиска клиентов? Заранее благодарен за ответ Константин. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 12:48: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 811C97C1; Fri, 21 Jun 2013 12:48:16 +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 D64DE1DFD; Fri, 21 Jun 2013 12:48:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r5LCm7ip073709; Fri, 21 Jun 2013 22:48:08 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 21 Jun 2013 22:48:07 +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: <20130621220013.X55167@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@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: Fri, 21 Jun 2013 12:48:16 -0000 On Thu, 20 Jun 2013 14:19:21 -0700, Adrian Chadd wrote: > Hi, > > FreeBSD-9 works fine on this Lenovo T400 - except that suspending with > no USB devices plugged in result in no ports working after resume. > > If I have a device plugged in during suspend - on any port - then all > the ports work fine after resume. > > I've attached usbconfig and acpidump output. No acpidump output on -stable or -acpi anyway .. likely best as an URL, if it comes down to ACPI. So the fingerprint reader, camera and bluetooth shown in your usbconfig don't serve as 'USB devices plugged in' in this regard? Do they work ok after resume, or not? > here's what is logged in the kernel buffer during suspend and resume: > > > Her'es the suspend: With all but the USB-related stuff dropped, I assume? > Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34 > Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1 > (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.2: at usbus1 (disconnected) > Jun 20 14:03:38 lucy kernel: ugen1.3: at usbus1 > (disconnected) > Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: ugen3.2: at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2 > (disconnected) > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0 > outstanding, 1 refs > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry > Jun 20 14:03:47 lucy kernel: ugen3.3: > at usbus3 (disconnected) > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect The last message is news to me. > Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1 > (disconnected) > Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1 > (disconnected) > > ..and resume: I wonder what these devices are? > > Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power > state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power > state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER No, the above are still on the suspend path, but logged on resume. I don't know what CDBS or EXP0,1,3,4 are. You've left out something like 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right? On 9(.1-R so far) I always get the same sort of messages for the cardbus slots on my T23, eg pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER, also for CBS1. I've supposed it meant there was no D2 setting for these and they seem to resume alright, later on: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 (& CBS1) I suppose you'd have lines setting state back to D0 on these, later on? > Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button status > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect > Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06) I hope 'slept' message is still in 10, I've seen a few listed without, and they're very handy if there's any resume delay, as I had up to 8.2 (plus exactly 60 seconds) unless I unloaded (in particular) UHCI and reloaded it on resume, needing a kernel w/out uhci, ohci and ehci, loading on boot and unload/reload in rc.suspend/resume. This however was fixed by 9.1 for me, the first release where suspend/resume works flawlessly on the T23. I haven't tried a recent 9-STABLE though. > Jun 20 14:03:47 lucy kernel: [100067] uhub0: class 9/0, rev 2.00/1.00, addr 1> on usbus7 > Jun 20 14:03:47 lucy kernel: [100046] uhub1: class 9/0, rev 2.00/1.00, addr 1> on usbus3 > Jun 20 14:03:47 lucy kernel: [100031] uhub2: class 9/0, rev 1.00/1.00, addr 1> on usbus0 > Jun 20 14:03:47 lucy kernel: [100036] uhub3: class 9/0, rev 1.00/1.00, addr 1> on usbus1 > Jun 20 14:03:47 lucy kernel: [100057] uhub4: class 9/0, rev 1.00/1.00, addr 1> on usbus5 > Jun 20 14:03:47 lucy kernel: [100052] uhub5: class 9/0, rev 1.00/1.00, addr 1> on usbus4 > Jun 20 14:03:47 lucy kernel: [100062] uhub6: class 9/0, rev 1.00/1.00, addr 1> on usbus6 > Jun 20 14:03:47 lucy kernel: [100041] uhub7: class 9/0, rev 1.00/1.00, addr 1> on usbus2 > > .. local APIC error? No idea. > Jun 20 14:03:47 lucy kernel: CPU0: local APIC error 0x40 > Jun 20 14:03:47 lucy acpi: resumed at 20130620 14:03:47 > > It probes the hubs fine though. But you get nothing at all if you plug something in? No messages? Well, the earlier resume issues on UHCI might still not be fixed? You could try a kernel without UHCI, with the unload/reload dance .. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 22:45: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 3D809A51 for ; Fri, 21 Jun 2013 22:45:44 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id CE21C1D47 for ; Fri, 21 Jun 2013 22:45:43 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id p60so6744399wes.41 for ; Fri, 21 Jun 2013 15:45:42 -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=bYpq1e7/5HiPStSTCMWEaBInIJtO3XyQ5h98IJ0QpqQ=; b=yt1w/oMxt8Y17rZRlgX3w+LB2bFfF7x/YIx8vqtbtG5D9Y1IFvCTtm4g3qIOvLX/Oa zqIDCWIInB+kzeOIUlwUyxlJygH9KDnUclw8DF7BKg/fx8qvHycjNDTJ7LUAAMkA6Sfc qc3E1TE8ORnlhOLBKPXiv0ivnEqsSdMdi730QZYeYThEMnpJT9QfsniX/b7+i0B4+CPe WLUcXBvXO0J9huwGUy1pRSet2nBQdpxJ79f54R+iIxqI12mJJz+Urwvy1HqljTGY/3vd 2B9PC6AVqQ5oIeeuBnnvFVZ8qSrHf31wj0oON75dEzWopvFttLRw3blxLiKsCy45ykyT Xh8A== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr10873185wjb.0.1371854742710; Fri, 21 Jun 2013 15:45:42 -0700 (PDT) Received: by 10.194.15.132 with HTTP; Fri, 21 Jun 2013 15:45:42 -0700 (PDT) Date: Fri, 21 Jun 2013 17:45:42 -0500 Message-ID: Subject: Issue with svn updates both source and ports. From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org 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: Fri, 21 Jun 2013 22:45:44 -0000 I've been using svn updates for some time with no problems rebuilding daily. Version of my last successful update. # uname -a FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #503 r252026: Thu Jun 20 06:41:28 CDT 2013 root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 # cd /usr/src && svn up /usr/src svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/usr/src' is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first. # cd /usr/ports && /usr/local/bin/svn up /usr/ports Updating '.': svn: E170000: Unrecognized URL scheme for ' https://svn0.us-west.freebsd.org/ports/head' Today was the first day that I have seen this. The error message leads me to believe that I am out of date but have tried to find a way to upgrade and haven't been successful. The ports versions have not changed for svn didn't update them today. Maybe I should update differently? Thanks, ed ---------------------------------------------------------------------------= ---------------------- --=20 Bienes Ra=EDces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/1= 02249989850215?sk=3Dphotos_albums From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 22:51: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 C8FB7FDB for ; Fri, 21 Jun 2013 22:51:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2691DA6 for ; Fri, 21 Jun 2013 22:51:41 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r5LMpZ0r052060; Fri, 21 Jun 2013 15:51:35 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r5LMpZHM052059; Fri, 21 Jun 2013 15:51:35 -0700 (PDT) (envelope-from david) Date: Fri, 21 Jun 2013 15:51:35 -0700 From: David Wolfskill To: "Edwin L. Culp W." Subject: Re: Issue with svn updates both source and ports. Message-ID: <20130621225135.GT31043@albert.catwhisker.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="owPIoVL9FiqC4k42" 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: Fri, 21 Jun 2013 22:51:42 -0000 --owPIoVL9FiqC4k42 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2013 at 05:45:42PM -0500, Edwin L. Culp W. wrote: > I've been using svn updates for some time with no problems rebuilding > daily. >=20 > Version of my last successful update. > # uname -a > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #5= 03 > r252026: Thu Jun 20 06:41:28 CDT 2013 > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > amd64 >=20 > # cd /usr/src && svn up /usr/src > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: The working copy at '/usr/src' > is too old (format 29) to work with client version '1.8.0 (r1490375)' > (expects format 31). You need to upgrade the working copy first. You need to do as the above message suggests: "svn upgrade /usr/src". (Note that "svn up" is short for "svn update", which is different from "svn upgrade".) This is a result of the svn client (now) being 1.8.x, vs. the last successful "svn up", when it was 1.7.x. > # cd /usr/ports && /usr/local/bin/svn up /usr/ports > Updating '.': > svn: E170000: Unrecognized URL scheme for ' > https://svn0.us-west.freebsd.org/ports/head' This is likely an issue of the new 1.8.x svn client not being built with SERF support. Please see ports/UPDATING, entry 20130619. > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --owPIoVL9FiqC4k42 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHE2PYACgkQmprOCmdXAD092gCfaTkVqaRRu0RXFG9xF4TMHztE 4VkAn1CJrTQ72Q7A1m9bdJn5wDF/+t5g =j8c/ -----END PGP SIGNATURE----- --owPIoVL9FiqC4k42-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 21 23:04:46 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 5E957381 for ; Fri, 21 Jun 2013 23:04:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 225D61E10 for ; Fri, 21 Jun 2013 23:04:45 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5BA7628427 for ; Sat, 22 Jun 2013 01:04:32 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 01C7E28426 for ; Sat, 22 Jun 2013 01:04:30 +0200 (CEST) Message-ID: <51C4DBFE.1010809@quip.cz> Date: Sat, 22 Jun 2013 01:04:30 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks) Content-Type: text/plain; charset=ISO-8859-2; 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, 21 Jun 2013 23:04:46 -0000 Beside my previous complaint about sshd not starting after upgrade from FreeBSD 8.3 to 8.4 due to incompatible change in parsing sshd_config with empty VersionAddendum [1], there is another more serious bug in newly imported SSH in base (OpenSSH_6.1p1) which I am not able to fix / workaround. In short: OpenSSH 6.1 is creating broken symlinks with sftp command on OpenSSH 5.4 server with chrooted account. It will always creates symlinks with pseudo absolute path instead of relative. SSH server (OpenSSH 5.4 on FreeBSD 8.3) is configured with the following settings for chrooting: Match User devel ChrootDirectory /usr/home ForceCommand internal-sftp And again, it was working fine with older version of FreeBSD / OpenSSH 5.4 client (sftp command). It is working with WinSCP too. The sftp command used for creating the symlink is: symlink temp temp_symlink Expected result shown by ls -l /usr/home/devel on server side is: temp_symlink -> temp Broken links by OpenSSH 6.1 client: temp_symlink -> /devel/temp So the symlink is not working outside of the sftp chrooted session (for example, Apache cannot read files from symlinked directory because only user "devel" is chrooted) I tried to enable DEBUG logging in sshd_config on the server side with following results: Expected behavior with OpenSSH 5.4 as sftp client subsystem request for sftp session opened for local user devel from [y.y.y.y] received client version 3 realpath "." symlink old "temp" new "/usr/home/devel/temp_symlink" sent status Success session closed for local user devel from [y.y.y.y] Broken behavior with OpenSSH 6.1 as sftp client subsystem request for sftp session opened for local user devel from [x.x.x.x] received client version 3 realpath "." opendir "/usr/home/devel" sent status End of file closedir "/usr/home/devel" sent status Success symlink old "/usr/home/devel/temp" new "/usr/home/devel/temp_symlink" sent status Success In both cases the sftp command is executed from simplified shellscript simulating much larger script for our application deployment: echo "symlink temp temp_symlink quit " | sftp devel@x.x.x.x The above debug output is the same with sftp-server and internal-sftp (in sshd_config). It does not matter if user account is chrooted or not - sftp command always creates symlink with an absolute path (with OpenSSH 6.1). With OpenSSH 5.4 client, it will create relative path symlinks as expected. So my questions are: 1) Is there some way to create relative symlinks with OpenSSH 6.1? 2) Was OpenSSH 6.1 tested before importing in to the base of FreeBSD 8.4 release? These two bugs seems serious to me. 3) Is there any chance to fix these bugs in FreeBSD repository, or do we need to be "bug to bug" compatible with other systems using OpenSSH 6.x? Miroslav Lachman [1] sshd didn't run after upgrade to FreeBSD 8.4 http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073898.html From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 00:12:29 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 4394BD2 for ; Sat, 22 Jun 2013 00:12:29 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id D13C91088 for ; Sat, 22 Jun 2013 00:12:28 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id ey16so1185841wid.5 for ; Fri, 21 Jun 2013 17:12:27 -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=14nsPHscEYSPRXoqBVMu+aikrtUcfSFqFthak7OG5iQ=; b=NMK4fhYn9uPsxEC74gM9lNxvwDXuNVmPo6CraWjbMeCp7cQlVROAE4Sf2tdv/kA/ph 1vRnMuZ9uBzzyyf1osPIWTlu0sUWnZwTK6L+8iQuLTbA1TPbRwqVeNQ/tHTCipe5aJvh 6SnO1sGByE3MDsamXedG5GQKnw7037AmSJmYamwPcZ6wCWQ1CwAR1VHWRhK5v6ozIAxl dt7r+fkl8O7HdkhCrfk18iXBDvpMnmouzootkAePK49QCUm8UjTGPS7jV7IrVopgwWj+ kg5nPdI7oh3wyOT6zjcsOM0DgO6J56tnKRV4vPKluMiu3SmNc06iwWMz3rRuVcT7G17E WOyQ== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr11025697wjb.0.1371859947112; Fri, 21 Jun 2013 17:12:27 -0700 (PDT) Received: by 10.194.15.132 with HTTP; Fri, 21 Jun 2013 17:12:27 -0700 (PDT) In-Reply-To: <20130621225135.GT31043@albert.catwhisker.org> References: <20130621225135.GT31043@albert.catwhisker.org> Date: Fri, 21 Jun 2013 19:12:27 -0500 Message-ID: Subject: Re: Issue with svn updates both source and ports. From: "Edwin L. Culp W." To: David Wolfskill 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: Sat, 22 Jun 2013 00:12:29 -0000 On Fri, Jun 21, 2013 at 5:51 PM, David Wolfskill wrot= e: > On Fri, Jun 21, 2013 at 05:45:42PM -0500, Edwin L. Culp W. wrote: > > I've been using svn updates for some time with no problems rebuilding > > daily. > > > > Version of my last successful update. > > # uname -a > > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 > #503 > > r252026: Thu Jun 20 06:41:28 CDT 2013 > > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > > amd64 > > > > # cd /usr/src && svn up /usr/src > > svn: E155036: Please see the 'svn upgrade' command > > svn: E155036: The working copy at '/usr/src' > > is too old (format 29) to work with client version '1.8.0 (r1490375)' > > (expects format 31). You need to upgrade the working copy first. > > You need to do as the above message suggests: "svn upgrade /usr/src". > (Note that "svn up" is short for "svn update", which is different from > "svn upgrade".) > David, thanks, you are a life saver. I had missed the above completely. > > This is a result of the svn client (now) being 1.8.x, vs. the last > successful "svn up", when it was 1.7.x. > > > # cd /usr/ports && /usr/local/bin/svn up /usr/ports > > Updating '.': > > svn: E170000: Unrecognized URL scheme for ' > > https://svn0.us-west.freebsd.org/ports/head' > > This is likely an issue of the new 1.8.x svn client not being built with > SERF support. Please see ports/UPDATING, entry 20130619. > > Now using 1.8 and making world. I seem to be coming out of this problem, thanks to you. In the morning I will see the final results and let you and the list know. Maybe someone else will miss understand these changes. Have a great weekend. ed > > ... > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > --=20 Bienes Ra=EDces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/1= 02249989850215?sk=3Dphotos_albums From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 00:54:46 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 309BDBC7 for ; Sat, 22 Jun 2013 00:54:46 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 029791286 for ; Sat, 22 Jun 2013 00:54:46 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A6C971B082; Fri, 21 Jun 2013 17:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1371862485; bh=IW3t3qla5YHXSgfkVfoaTNcAh03+rgNX5FqcKACqRrs=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=2bp5+jDo7r+16DhVmAZ9TATQ/TF8DEVgk1yJpApmPVaK7uFXeO2x4mkj33ziM2foh yuMYDKgxLAvfsrBztDMwCK223sl5ERhdDi1a17/OPawze9HPy+NxaIJ/L1Xdd2t/x6 w9ixjX1nN8L9LuknKx937NXD9ZODnqEJn3kzKpbk= Message-ID: <51C4F5D4.6000802@delphij.net> Date: Fri, 21 Jun 2013 17:54:44 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: Another bug in SSH in FreeBSD 8.4 (sftp cannot create relative symlinks) References: <51C4DBFE.1010809@quip.cz> In-Reply-To: <51C4DBFE.1010809@quip.cz> X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------000703050507020503070804" Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 00:54:46 -0000 This is a multi-part message in MIME format. --------------000703050507020503070804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/21/13 16:04, Miroslav Lachman wrote: > 1) Is there some way to create relative symlinks with OpenSSH 6.1? No. It seems like a regression and can not be worked around. I do have a patch (attached; against crypto/openssh/), and my test shows that it would fix the problem. > 2) Was OpenSSH 6.1 tested before importing in to the base of > FreeBSD 8.4 release? These two bugs seems serious to me. This code is not new: it was in OpenBSD 3 years ago, and in FreeBSD for more than 2 years (r221420 or 2011-05-04); OpenSSH 6.1 was imported last September. This issue you have just raised have been there since FreeBSD 9.0-RELEASE. So to me it seems like that the two issues are either rarely hit by the general public (counting myself in: I have never used sftp to create symbolic link remotely and have thus learned something new today), or those who hit this have choose to keep silent about it. Fortunately we have you noticed and reported the problem. As a community effort, we really *need* people to grab in-development snapshots and provide us the feedback. > 3) Is there any chance to fix these bugs in FreeBSD repository, or > do we need to be "bug to bug" compatible with other systems using > OpenSSH 6.x? I can not make a promise as I am not the maintainer. However, I have already reported this issue to upstream OpenBSD developers, so if this was accepted by the upstream, we will commit the change locally to fix the issue. Unfortunately, it is too late to fix this for 8.4-RELEASE, and unless we see widespread complain, I don't think the problem would affect a significant amount of users to warrant a "errata" for supported release (8.4-RELEASE, 9.1-RELEASE), however, if it would be fixed, the fix would be merged to 8-STABLE and 9-STABLE and will be shipped with future releases, if the fix enters the development branch before them. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRxPXUAAoJEG80Jeu8UPuzzRAH/AnNKnmsb6vX9LCNRsLtb2SG bk2J4lx5XLK3sCYEeSL/npBtpwShGLMRnfTeb7oAPBU0skzpppHDpvwp8aIZUAGB uMwMrln2YPKYfUJvtkPdUC+5Jm8OHnxwoYepOXkZSQy8R3ii1Q2Kpk9uGbez1i2i iFaP+bQoCJxX8NdTRE/WrPjpfgq8KvUOowBn21dGLZ+MGUL5RlffvrOgth8Py4rp ByekHuvwNz0i5wxILmriPKg04MhI8Ljy6Y8KxjZhn6v3fjEO7D5FvVlJP8us9iu0 AsFbnkBOvaYxJFDCmlh7u4fumCcsvtwmsmNbiqFRdQVbDuyMdvf880kNrmgCb5k= =vS/U -----END PGP SIGNATURE----- --------------000703050507020503070804 Content-Type: text/plain; charset=UTF-8; name="sftp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sftp.diff" Index: usr.bin/ssh/sftp.c =================================================================== RCS file: /home/openbsd/src/usr.bin/ssh/sftp.c,v retrieving revision 1.143 diff -u -p -u -r1.143 sftp.c --- usr.bin/ssh/sftp.c 18 Apr 2013 02:16:07 -0000 1.143 +++ usr.bin/ssh/sftp.c 22 Jun 2013 00:26:00 -0000 @@ -1313,7 +1313,6 @@ parse_dispatch_command(struct sftp_conn case I_SYMLINK: sflag = 1; case I_LINK: - path1 = make_absolute(path1, *pwd); path2 = make_absolute(path2, *pwd); err = (sflag ? do_symlink : do_hardlink)(conn, path1, path2); break; --------------000703050507020503070804-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 06:21:46 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 784F8364 for ; Sat, 22 Jun 2013 06:21:46 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC7A1E71 for ; Sat, 22 Jun 2013 06:21:46 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so21191386iea.32 for ; Fri, 21 Jun 2013 23:21: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:date:message-id:subject:from:to :cc:content-type; bh=3GZ0GD4wevrqTswNET/RuCpg1/uFEV3/1Z0L4sYGpoQ=; b=mSHH/ghUxxzeHBm/Dw14IvWQDvqqkBSX48eTAl9s+PjPx+iIVnOxtqQxzv0zh+/FjV cdCvq1l0z+nGcDN72u6f8y3naNcpPDmu3h8T59j94+N2SsN4VlVBdw3lAEc/gEg1g0LS o/lQwk/0U+Phoh9fvWFsyNCvKCSEN6wr0OKiKaDjFam07KTiGgFIa+sO+KK5TVePxVes xJvKkCAqTt6EcwVBpCSdyD6O+OgveeP/9ov3UqeyITAvJNbW2Nk3i53cTuO/Rwu+eWhZ TUkfueKzXX9sX1UO5UmttLN1V4dLoaQzAOosYC9p/7oWoXc+2iBS6l1AUx1fx6uvDF9k Tltg== MIME-Version: 1.0 X-Received: by 10.50.67.43 with SMTP id k11mr798609igt.26.1371882105922; Fri, 21 Jun 2013 23:21:45 -0700 (PDT) Received: by 10.50.221.179 with HTTP; Fri, 21 Jun 2013 23:21:45 -0700 (PDT) In-Reply-To: <51C2CB42.4030301@dilkie.com> References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> <51C2499B.2060209@quip.cz> <51C2CB42.4030301@dilkie.com> Date: Sat, 22 Jun 2013 01:21:45 -0500 Message-ID: Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Scot Hetzel To: Lee Dilkie Content-Type: text/plain; charset=ISO-8859-1 Cc: Kimmo Paasiala , Steven Hartland , Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable 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: Sat, 22 Jun 2013 06:21:46 -0000 On Thu, Jun 20, 2013 at 4:28 AM, Lee Dilkie wrote: > > On 6/19/2013 8:24 PM, Kimmo Paasiala wrote: >> Ok, this is crazy. If you put one space after the VersionAddendum >> keyword you get exactly what you want, an empty VersionAddendum >> string. If there's no space but a newline right after the >> VersionAddendum keyword, sshd(8) complains about the line and refuses >> to start. So this is ok (without the single quotes, they are just to >> show the endings of the lines): >> >> 'VersionAddendum ' >> >> But this is not: >> >> 'VersionAddendum' >> >> What are the OpenSSH devs thinking? >> >> -Kimmo > > I'd call it a bug. > crypto/openssh/servconf.c 1553 case sVersionAddendum: 1554 if (cp == NULL) 1555 fatal("%.200s line %d: Missing argument.", filename, 1556 linenum); 1557 len = strspn(cp, WHITESPACE); 1558 if (*activep && options->version_addendum == NULL) { 1559 if (strcasecmp(cp + len, "none") == 0) 1560 options->version_addendum = xstrdup(""); 1561 else if (strchr(cp + len, '\r') != NULL) 1562 fatal("%.200s line %d: Invalid argument", 1563 filename, linenum); 1564 else 1565 options->version_addendum = xstrdup(cp + len); 1566 } 1567 return 0; Looks like if you specify: VersionAddendum none it won't display the additional info. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 13:56:28 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 AD42F875 for ; Sat, 22 Jun 2013 13:56:28 +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 6F46F1ECC for ; Sat, 22 Jun 2013 13:56:28 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::751d:fc62:4355:d021] (unknown [IPv6:2001:7b8:3a7:0:751d:fc62:4355:d021]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BD55E5C43; Sat, 22 Jun 2013 15:56:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: sshd didn't run after upgrade to FreeBSD 8.4 From: Dimitry Andric In-Reply-To: Date: Sat, 22 Jun 2013 15:56:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <60F7DD16-087B-4BE1-B4B0-D37B7B62813B@FreeBSD.org> References: <51C22E11.3020008@quip.cz> <51C23ED9.7070107@quip.cz> <51C2499B.2060209@quip.cz> To: Kimmo Paasiala X-Mailer: Apple Mail (2.1508) Cc: Steven Hartland , freebsd-stable Stable , Miroslav Lachman <000.fbsd@quip.cz> 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, 22 Jun 2013 13:56:28 -0000 On Jun 20, 2013, at 02:24, Kimmo Paasiala wrote: ... > Ok, this is crazy. If you put one space after the VersionAddendum > keyword you get exactly what you want, an empty VersionAddendum > string. If there's no space but a newline right after the > VersionAddendum keyword, sshd(8) complains about the line and refuses > to start. So this is ok (without the single quotes, they are just to > show the endings of the lines): > > 'VersionAddendum ' > > But this is not: > > 'VersionAddendum' > > What are the OpenSSH devs thinking? I assume they did not take this scenario into account at all. The VersionAddendum setting had been a custom FreeBSD addition for some time, and was not available at all in upstream OpenSSH. When upstream decided to add it, they did not specifically care about backwards compatibility with (until that time) non-standard configuration files... -Dimitry From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 17:36: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 5AD50D68 for ; Sat, 22 Jun 2013 17:36:45 +0000 (UTC) (envelope-from edwinlculp@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 E6ECF16AE for ; Sat, 22 Jun 2013 17:36:44 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1438343wib.14 for ; Sat, 22 Jun 2013 10:36:44 -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 :content-type; bh=HmakvR7tuHx+xvme0zGBMR/a0gEMl/JleI9XPQMtZZ8=; b=wb8FuWBjJFdPyc3wAJwtre1E79c6LCbD2EVAy6eH2/B8e2M9i7e9S0/f2SoxWYAOPs 4W/vmOOG43ycdmbKht4MHw1p9OKDh1JazIBnkvsAqI0JJQkTBWlX52Q618KjmPcRqCTT N2rSFtTLPYY+Am2SB0i5Q2iowTTrOyKtp4QtLsQOXcQ46zfnLsDBLlVW+yswx38M8RKe U8jk36TjIpRq8G9kG+dKtboeQNw4VDz7uCcRcCw1PAmz3WRyeCup7eU47N/MClxMZLuJ YCrEs7ktShv9lBoTxlgy1yEXt3WFtmPmjZzO5CI+uynDtmFRdmBu4iAhdhHBnLfXbsxw Ej7g== MIME-Version: 1.0 X-Received: by 10.180.85.35 with SMTP id e3mr2009130wiz.30.1371922604072; Sat, 22 Jun 2013 10:36:44 -0700 (PDT) Received: by 10.194.15.132 with HTTP; Sat, 22 Jun 2013 10:36:44 -0700 (PDT) In-Reply-To: <20130622010951.GU31043@albert.catwhisker.org> References: <20130621225135.GT31043@albert.catwhisker.org> <20130622010951.GU31043@albert.catwhisker.org> Date: Sat, 22 Jun 2013 12:36:44 -0500 Message-ID: Subject: Fwd: Issue with svn updates both source and ports. From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=f46d041824f679a4d904dfc19f34 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, 22 Jun 2013 17:36:45 -0000 --f46d041824f679a4d904dfc19f34 Content-Type: text/plain; charset=ISO-8859-1 Thanks, David. I'm still not able to update my ports. I was able to build a new world with no problem. # uname -a FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #505 r252094: Sat Jun 22 06:48:06 CDT 2013 root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 but when I try to update my ports I get: # /usr/local/bin/svn up /usr/ports Updating '/usr/ports': svn: E170000: Unrecognized URL scheme for ' https://svn0.us-west.freebsd.org/ports/head' And I though I was finally using svn without problems. The only thing interesting about this error was it's needing neon that I rebuilt and reinstalled just in case but no prize. Thanks for suggestions. ed --f46d041824f679a4d904dfc19f34 Content-Type: application/pgp-signature Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: 3051d99542739373_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuMjAgKEZy ZWVCU0QpDQoNCmlFWUVBUkVDQUFZRkFsSEUrVjRBQ2drUW1wck9DbWRYQUQzVTh3Q2RIV2xxM0c1 TWpnR2VvNms3UlBZKzl0bVUNCnNpb0FuUlNIbklNdUhHUE5xQXVzTHUvQ3RiOFlJT1o1DQo9aDFt WQ0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= --f46d041824f679a4d904dfc19f34-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 17:44: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 62923F2B for ; Sat, 22 Jun 2013 17:44:15 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 21F8D1703 for ; Sat, 22 Jun 2013 17:44:14 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r5MHiDBW061452; Sat, 22 Jun 2013 10:44:13 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r5MHiD36061451; Sat, 22 Jun 2013 10:44:13 -0700 (PDT) (envelope-from david) Date: Sat, 22 Jun 2013 10:44:13 -0700 From: David Wolfskill To: "Edwin L. Culp W." Subject: Re: Fwd: Issue with svn updates both source and ports. Message-ID: <20130622174413.GY31043@albert.catwhisker.org> References: <20130621225135.GT31043@albert.catwhisker.org> <20130622010951.GU31043@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bW7Nw90iaNQhVLQB" 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: Sat, 22 Jun 2013 17:44:15 -0000 --bW7Nw90iaNQhVLQB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2013 at 12:36:44PM -0500, Edwin L. Culp W. wrote: > Thanks, David. >=20 > I'm still not able to update my ports. I was able to build a new world > with no problem. >=20 > # uname -a > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #505 > r252094: Sat Jun 22 06:48:06 CDT 2013 > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > amd64 Some progress; good.... > but when I try to update my ports I get: >=20 > # /usr/local/bin/svn up /usr/ports > Updating '/usr/ports': > svn: E170000: Unrecognized URL scheme for ' > https://svn0.us-west.freebsd.org/ports/head' >=20 > And I though I was finally using svn without problems. > The only thing interesting about this error was it's needing neon that I > rebuilt and reinstalled just in case but no prize. >=20 > Thanks for suggestions. Per the ports/UPDATING entry: =2E.. If you want to upgrade, and use http/https access to repositories, please check, that the SERF option is enabled, as NEON support is gone. =2E.. I suspect that you need to rebuild svn, and that you need to change the configuration for it first. If you use portmaster: portmaster --force-config devel/subversion should do that. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --bW7Nw90iaNQhVLQB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHF4m0ACgkQmprOCmdXAD16RwCfel+F9W6YOOmPawT+k0TPk8Q2 a04AnjvILVUedGEZhG3d1zoKviIAULUo =u+qn -----END PGP SIGNATURE----- --bW7Nw90iaNQhVLQB-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 19:09: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 99425407 for ; Sat, 22 Jun 2013 19:09:08 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 31FCE19C8 for ; Sat, 22 Jun 2013 19:09:08 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w57so7332356wes.1 for ; Sat, 22 Jun 2013 12:09:07 -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=H7gRE1bmgk3Ytf0/K5pOMhqo9LBn+wDg+InxI6Mky60=; b=Pyy/8eRhH/+UlzKTL5fvmFJrQSdBiwXBPEREIP9IhWvQuvvVYhz2PeqnRbd+eNtr2d MkEZoO334FhTbdnhKQCQAEwVvwGhHrypAVzbrqaqLJ7lsdogfoVQuDrPZrnRnNMOlWaD HxAOTyV0HEphS8eXtSN4vbNtubCdpGwe3YB4O6vRJNsjQ23rXpB7KTO020pZWyEb3QCJ M5omhhRzhY5O4H3zTLGYaX5xrxHG74f67/FxiWX3wWtdjeGeKimYi+sgHHkIYhTImxr1 GCrd2qCC40ep5Bz6Tjhjp8LAdcQR8MU6yT1NzjWQts+INqWpAf5ZK8VD7HEOQKtFaUFl LYHw== MIME-Version: 1.0 X-Received: by 10.180.198.80 with SMTP id ja16mr2084843wic.53.1371928147296; Sat, 22 Jun 2013 12:09:07 -0700 (PDT) Received: by 10.194.15.132 with HTTP; Sat, 22 Jun 2013 12:09:07 -0700 (PDT) In-Reply-To: <20130622174413.GY31043@albert.catwhisker.org> References: <20130621225135.GT31043@albert.catwhisker.org> <20130622010951.GU31043@albert.catwhisker.org> <20130622174413.GY31043@albert.catwhisker.org> Date: Sat, 22 Jun 2013 14:09:07 -0500 Message-ID: Subject: Re: Fwd: Issue with svn updates both source and ports. From: "Edwin L. Culp W." To: David Wolfskill 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: Sat, 22 Jun 2013 19:09:08 -0000 On Sat, Jun 22, 2013 at 12:44 PM, David Wolfskill wro= te: > On Sat, Jun 22, 2013 at 12:36:44PM -0500, Edwin L. Culp W. wrote: > > Thanks, David. > > > > I'm still not able to update my ports. I was able to build a new world > > with no problem. > > > > # uname -a > > FreeBSD home.encontacto.net 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #505 > > r252094: Sat Jun 22 06:48:06 CDT 2013 > > root@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO > > amd64 > > Some progress; good.... > > > but when I try to update my ports I get: > > > > # /usr/local/bin/svn up /usr/ports > > Updating '/usr/ports': > > svn: E170000: Unrecognized URL scheme for ' > > https://svn0.us-west.freebsd.org/ports/head' > > > > And I though I was finally using svn without problems. > > The only thing interesting about this error was it's needing neon that = I > > rebuilt and reinstalled just in case but no prize. > > > > Thanks for suggestions. > > Per the ports/UPDATING entry: > > ... > If you want to upgrade, and use http/https access to repositories, > please check, that the SERF option is enabled, as NEON support > is gone. > ... > > I suspect that you need to rebuild svn, and that you need to change the > configuration for it first. If you use portmaster: > > portmaster --force-config devel/subversion > > should do that. > > Reconfiguring and running portmaster --force-config devel/subversion has the problem solved. Thanks again, ed Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > --=20 Bienes Ra=EDces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/1= 02249989850215?sk=3Dphotos_albums From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 19:37: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 42EB8A1F for ; Sat, 22 Jun 2013 19:37:47 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by mx1.freebsd.org (Postfix) with ESMTP id DF01B1ABE for ; Sat, 22 Jun 2013 19:37:45 +0000 (UTC) Received: from [10.42.69.5] ([82.120.204.208]) by mwinf5d66 with ME id rXde1l0044WHsXE03XdeAb; Sat, 22 Jun 2013 21:37:38 +0200 Message-ID: <1371929857.9964.3.camel@Nerz-PC> Subject: slow bootloader on Dell R320 From: =?ISO-8859-1?Q?Lo=EFc?= BLOT To: freebsd-stable@freebsd.org Date: Sat, 22 Jun 2013 21:37:37 +0200 Organization: UNIX Experience Fr Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-n+rlUs22gJZs87q7vZlm" X-Mailer: Evolution 3.8.3 Mime-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: loic.blot@unix-experience.fr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 19:37:47 -0000 --=-n+rlUs22gJZs87q7vZlm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all ! Thanks for the very good support of Dell R320 hardware, perc H310 is well supported, BCM5720 seems to work correctly and performances are great. The only problem i have found is very strange. The FreeBSD bootloader take many times to load, 30sec-2minutes to boot the kernel and show the bootloader menu. After that, the system boots properly, at a normal speed. Is there any issue or optimization i can do ? The OpenBSD bootloader doesn't have this problem. Thanks you in advance --=20 Best regards, Lo=C3=AFc BLOT,=20 UNIX systems, security and network expert http://www.unix-experience.fr --=-n+rlUs22gJZs87q7vZlm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EABEIAAYFAlHF/QIACgkQh290DZyz8uZxrAEAwl3p9mSn+qYa8Xvn1ccmMPyg 7dftGhTeSgrFHLuM9fEA+gL4juJ2XPAqD8mEjkv3QZVUhQ6CC83PODHsCX0HKgfC =tV/X -----END PGP SIGNATURE----- --=-n+rlUs22gJZs87q7vZlm-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 20:49:28 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 84988AF5 for ; Sat, 22 Jun 2013 20:49:28 +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 431351D67 for ; Sat, 22 Jun 2013 20:49:27 +0000 (UTC) Received: from mfilter4-d.gandi.net (mfilter4-d.gandi.net [217.70.178.134]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id B90B3172090; Sat, 22 Jun 2013 22:49:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter4-d.gandi.net (mfilter4-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id z7wLpJpu1T9T; Sat, 22 Jun 2013 22:49:09 +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 E143A172092; Sat, 22 Jun 2013 22:49:08 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id E456773A1C; Sat, 22 Jun 2013 13:49:06 -0700 (PDT) Date: Sat, 22 Jun 2013 13:49:06 -0700 From: Jeremy Chadwick To: =?unknown-8bit?Q?Lo=EFc?= BLOT Subject: Re: slow bootloader on Dell R320 Message-ID: <20130622204906.GB74507@icarus.home.lan> References: <1371929857.9964.3.camel@Nerz-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1371929857.9964.3.camel@Nerz-PC> 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: Sat, 22 Jun 2013 20:49:28 -0000 On Sat, Jun 22, 2013 at 09:37:37PM +0200, Loc BLOT wrote: > Hi all ! > Thanks for the very good support of Dell R320 hardware, perc H310 is > well supported, BCM5720 seems to work correctly and performances are > great. > The only problem i have found is very strange. The FreeBSD bootloader > take many times to load, 30sec-2minutes to boot the kernel and show the > bootloader menu. After that, the system boots properly, at a normal > speed. > Is there any issue or optimization i can do ? > The OpenBSD bootloader doesn't have this problem. 1. What FreeBSD version exactly? (Please don't say "9.1", we need to know the full version, e.g. 9.1-RELEASE, or if you built your own we need uname -a output (you can hide the machine name)) 2. How many disks are in the machine? 3. Are any of the disks used for ZFS? There have been **many** improvements to the FreeBSD bootloader with regards to things taking a long time on boot-up in semi-recent days, but answers to the above questions will determine that. -- | 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 Sat Jun 22 21:00: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 3690ED62 for ; Sat, 22 Jun 2013 21:00:51 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by mx1.freebsd.org (Postfix) with ESMTP id D23251DEA for ; Sat, 22 Jun 2013 21:00:50 +0000 (UTC) Received: from [10.42.69.5] ([82.120.79.76]) by mwinf5d29 with ME id rYtC1l0051enCNi03YtDmN; Sat, 22 Jun 2013 22:53:13 +0200 Message-ID: <1371934392.9964.6.camel@Nerz-PC> Subject: Re: slow bootloader on Dell R320 From: =?ISO-8859-1?Q?Lo=EFc?= BLOT To: freebsd-stable@freebsd.org Date: Sat, 22 Jun 2013 22:53:12 +0200 In-Reply-To: <20130622204906.GB74507@icarus.home.lan> References: <1371929857.9964.3.camel@Nerz-PC> <20130622204906.GB74507@icarus.home.lan> Organization: UNIX Experience Fr Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-rHkNowxutydE2PySP3TV" X-Mailer: Evolution 3.8.3 Mime-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: loic.blot@unix-experience.fr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 21:00:51 -0000 --=-rHkNowxutydE2PySP3TV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jeremy, 1. it's a FreeBSD-9.1-p3 (RELEASE) (sorry i haven't the exact output because i'm not at work, but i'm sure of the release and version). 2. I have only 2 300GB disks in a RAID-1 on a perc H310 3. No ZFS was there, it's UFS2 without tuning options. --=20 Best regards, Lo=C3=AFc BLOT,=20 UNIX systems, security and network expert http://www.unix-experience.fr Le samedi 22 juin 2013 =C3=A0 13:49 -0700, Jeremy Chadwick a =C3=A9crit : > On Sat, Jun 22, 2013 at 09:37:37PM +0200, Loc BLOT wrote: > > Hi all ! > > Thanks for the very good support of Dell R320 hardware, perc H310 is > > well supported, BCM5720 seems to work correctly and performances are > > great. > > The only problem i have found is very strange. The FreeBSD bootloader > > take many times to load, 30sec-2minutes to boot the kernel and show the > > bootloader menu. After that, the system boots properly, at a normal > > speed. > > Is there any issue or optimization i can do ? > > The OpenBSD bootloader doesn't have this problem. >=20 > 1. What FreeBSD version exactly? (Please don't say "9.1", we need to > know the full version, e.g. 9.1-RELEASE, or if you built your own we > need uname -a output (you can hide the machine name)) >=20 > 2. How many disks are in the machine? >=20 > 3. Are any of the disks used for ZFS? >=20 > There have been **many** improvements to the FreeBSD bootloader with > regards to things taking a long time on boot-up in semi-recent days, but > answers to the above questions will determine that. >=20 --=-rHkNowxutydE2PySP3TV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EABEIAAYFAlHGDrgACgkQh290DZyz8ub2sgEA0HBNxymanE3bL8vNsUvj8OTC cT2GjMJpaJADh4ryWZIA/R8MZ68Nlq2Y4BVItGDFToii8iU1ot8CvnFDlOZWB9sq =lfSz -----END PGP SIGNATURE----- --=-rHkNowxutydE2PySP3TV-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 21:04: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 E8D2AF49 for ; Sat, 22 Jun 2013 21:04:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id AB1051E22 for ; Sat, 22 Jun 2013 21:04:51 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 65545153434; Sat, 22 Jun 2013 23:04:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ0y3Y7pGNMG; Sat, 22 Jun 2013 23:04:47 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:9cea:1099:a9e5:7143] (unknown [IPv6:2001:4cb8:3:1:9cea:1099:a9e5:7143]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 54AF3153437; Sat, 22 Jun 2013 23:04:47 +0200 (CEST) Message-ID: <51C61171.6020800@digiware.nl> Date: Sat, 22 Jun 2013 23:04:49 +0200 From: Willem Jan Withagen 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: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount References: <51C1979D.3010305@ateamsystems.com> <20130619122143.GA70813@icarus.home.lan> <51C1A9BF.8030304@ateamsystems.com> <16D8225B6EAB407CB367449E075D7D57@multiplay.co.uk> In-Reply-To: <16D8225B6EAB407CB367449E075D7D57@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Adam Strohl , Ronald Klop 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, 22 Jun 2013 21:04:52 -0000 On 19-6-2013 15:41, Steven Hartland wrote: > ----- Original Message ----- From: "Ronald Klop" > > > >> On Wed, 19 Jun 2013 14:53:19 +0200, Adam Strohl >> wrote: >> >>> On 6/19/2013 19:21, Jeremy Chadwick wrote: >>>> On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote: >>>>> Hello -STABLE@, >>>>> >>>>> So I've seen this situation seemingly randomly on a number of both >>>>> physical 9.1 boxes as well as VMs for I would say 6-9 months at >>>>> least. I finally have a physical box here that reproduces it >>>>> consistently that I can reboot easily (ie; not a production/client >>>>> server). >> >> Hi, >> >> My home computer had the same symptom (not rebooting after 'all >> buffers flushed' message) a couple of months ago. But I follow >> 9-STABLE and the problem is gone for a while now. > > avg@ did a lot of work on the ZFS vfs locking which fixed at least one > hang on reboot for ZFS. I don't believe this is in 9.1-RELEASE, so you > should test a stable/9 or 8.4-RELEASE (which is newer than 9.1-RELEASE) > kernel. I was one of the victims of this bug, a while back. Patched and ran a lot of diffs from avg@, even tried some stuff he wrote for -Current, but we got things working. And in the end it was integrated into -STABLE. So I'm running an unpatched -STABLE, and I did not have the problem since. Currently running: 9.1-STABLE FreeBSD 9.1-STABLE #172 r250288: Mon May 6 06:49:36 CEST 2013 And the system got rebooted only just this week for some maintenance. So either you take a look at the -Current code to see if more changes have been made, or perhaps ask avg@ for suggestions. --WjW From owner-freebsd-stable@FreeBSD.ORG Sat Jun 22 21:45:18 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 5A7F9DE7 for ; Sat, 22 Jun 2013 21:45:18 +0000 (UTC) (envelope-from prvs=1885c13778=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 F334D1F59 for ; Sat, 22 Jun 2013 21:45:17 +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 md50004467247.msg for ; Sat, 22 Jun 2013 22:44:42 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Jun 2013 22:44:42 +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=1885c13778=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <5A5790915A4748DF8FFDA581E1437910@multiplay.co.uk> From: "Steven Hartland" To: , References: <1371929857.9964.3.camel@Nerz-PC> Subject: Re: slow bootloader on Dell R320 Date: Sat, 22 Jun 2013 22:44:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit 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: Sat, 22 Jun 2013 21:45:18 -0000 ----- Original Message ----- From: "Loïc BLOT" > Hi all ! > Thanks for the very good support of Dell R320 hardware, perc H310 is > well supported, BCM5720 seems to work correctly and performances are > great. > The only problem i have found is very strange. The FreeBSD bootloader > take many times to load, 30sec-2minutes to boot the kernel and show the > bootloader menu. After that, the system boots properly, at a normal > speed. > Is there any issue or optimization i can do ? > The OpenBSD bootloader doesn't have this problem. Do you have a large amount of memory in the machine, if so try adding this to /boot/loader.conf hw.memtest.tests="0" 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 Sat Jun 22 22:13: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 893B27C7 for ; Sat, 22 Jun 2013 22:13:00 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by mx1.freebsd.org (Postfix) with ESMTP id 075A4108F for ; Sat, 22 Jun 2013 22:12:59 +0000 (UTC) Received: from [10.42.69.5] ([82.120.79.76]) by mwinf5d25 with ME id raCq1l00C1enCNi03aCrfZ; Sun, 23 Jun 2013 00:12:51 +0200 Message-ID: <1371939170.9964.8.camel@Nerz-PC> Subject: Re: slow bootloader on Dell R320 From: =?ISO-8859-1?Q?Lo=EFc?= BLOT To: freebsd-stable@freebsd.org Date: Sun, 23 Jun 2013 00:12:50 +0200 In-Reply-To: <5A5790915A4748DF8FFDA581E1437910@multiplay.co.uk> References: <1371929857.9964.3.camel@Nerz-PC> <5A5790915A4748DF8FFDA581E1437910@multiplay.co.uk> Organization: UNIX Experience Fr Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-HflfPl38IlpvmGeKA1Me" X-Mailer: Evolution 3.8.3 Mime-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: loic.blot@unix-experience.fr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 22:13:00 -0000 --=-HflfPl38IlpvmGeKA1Me Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, it's only a 8GB memory server, i haven't this problem with KVM/VWMare VM with this amount of memory For possible next questions, i haven't any loader.conf customizations --=20 Best regards, Lo=C3=AFc BLOT,=20 UNIX systems, security and network expert http://www.unix-experience.fr Le samedi 22 juin 2013 =C3=A0 22:44 +0100, Steven Hartland a =C3=A9crit : > ----- Original Message -----=20 > From: "Lo=C3=AFc BLOT" > > Hi all ! > > Thanks for the very good support of Dell R320 hardware, perc H310 is > > well supported, BCM5720 seems to work correctly and performances are > > great. > > The only problem i have found is very strange. The FreeBSD bootloader > > take many times to load, 30sec-2minutes to boot the kernel and show the > > bootloader menu. After that, the system boots properly, at a normal > > speed. > > Is there any issue or optimization i can do ? > > The OpenBSD bootloader doesn't have this problem. >=20 > Do you have a large amount of memory in the machine, if so try adding > this to /boot/loader.conf >=20 > hw.memtest.tests=3D"0" >=20 > Regards > Steve=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he person or entity to whom it is addressed. In the event of misdirection, = the recipient is prohibited from using, copying, printing or otherwise diss= eminating it or any information contained in it.=20 >=20 > 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. >=20 > _______________________________________________ > 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" --=-HflfPl38IlpvmGeKA1Me Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EABEIAAYFAlHGIWIACgkQh290DZyz8ua92gEAw7gomrSfblzFHZkE6UpbIsUq 2JH4lqnrqVPMHs9HPtEBAKSvTxqdacs5shJZKYCdzS38/4oS2P79QtS95hO1/qA5 =/Qya -----END PGP SIGNATURE----- --=-HflfPl38IlpvmGeKA1Me--