From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 09:23:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E227D106566C for ; Sun, 12 Aug 2012 09:23:41 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3BEEB8FC08 for ; Sun, 12 Aug 2012 09:23:40 +0000 (UTC) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id 88E4ADF3794 for ; Sun, 12 Aug 2012 10:23:38 +0100 (BST) Received: by weyx56 with SMTP id x56so2268799wey.13 for ; Sun, 12 Aug 2012 02:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.209.87 with SMTP id r65mr388323weo.42.1344763415479; Sun, 12 Aug 2012 02:23:35 -0700 (PDT) Received: by 10.194.39.39 with HTTP; Sun, 12 Aug 2012 02:23:35 -0700 (PDT) Date: Sun, 12 Aug 2012 10:23:35 +0100 Message-ID: From: Matt Smith To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unable to cleanly unmount root filesystem on 9.1 amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 09:23:42 -0000 I am running the latest code which I compiled from RELENG_9_1, although I can see that RELENG_9 is pretty much identical at this point too. I'm using the amd64 architecture on an Intel Atom D525 motherboard. I'm using UFS2 with softupdates and softupdates journalling enabled. And it's mounted via glabel. It works fine except when I try and reboot or shutdown the machine I get this error: Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfffffe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfffffe000000729ca00 flags (VI(0x200)) v_object 0xfffffe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfffffe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 My gpart: => 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) I have also tried changing this to /dev/ada0p2 in case it was an issue with using labels and it does the same thing. I had no problems with it unmounting from the USB install stick that I used which was 9.1-BETA1, it's only started doing this since I updated it to RELENG_9_1. I did make a custom kernel file when I did that as well, but I don't think I've taken anything important out of it. Any ideas? Regards, Matt. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 11:03:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17874106564A for ; Sun, 12 Aug 2012 11:03:10 +0000 (UTC) (envelope-from frimik@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DEBD08FC0C for ; Sun, 12 Aug 2012 11:03:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so5867696pbb.13 for ; Sun, 12 Aug 2012 04:03:09 -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=2en7fIMvsGzSGFSH6uSWYi0Hcrdzp1Gl3YBgexM+YTg=; b=hMVRQQblbq/QI6KsHDvdVaxnkY0rgMHNIzHCRbeVegxZz+ZgYjJ5dBmItaRlC4LMzo wUHfaOriXuQJUEN7FPiqkOLOFN51Je99p+0hsQ+Yq3gfBCm99onQ7G2kqSEuAlY/Z9Dl B6SO+qv+2SBVo9KwjMhJZWpl89kEbmt0k4thLMnDtiv14tkHDvc9W+pJz93PmpdJgOAA 5RTjlYxQYVhCv4ckW7l7iQKjcThen1YgMbX1LXlicbPHTgFlfAPulp4obLnbbeep/oNF oELzLeL1JWEyRxdz6rkeBiqkaUgH3Z8kbMDWybGMTX3L4FX13U/HemGHClI5fx6aZBNb grqA== MIME-Version: 1.0 Received: by 10.68.134.228 with SMTP id pn4mr11504384pbb.147.1344769389447; Sun, 12 Aug 2012 04:03:09 -0700 (PDT) Received: by 10.66.16.229 with HTTP; Sun, 12 Aug 2012 04:03:09 -0700 (PDT) In-Reply-To: References: <1342733091.12482.12.camel@home.bonett.org> Date: Sun, 12 Aug 2012 13:03:09 +0200 Message-ID: From: Mikael Fridh To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Cc: greg@bonett.org, freebsd-stable@freebsd.org Subject: Re: kernel panic caused by zfs/sa.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 11:03:10 -0000 On Thu, Jul 19, 2012 at 11:36 PM, Olivier Smedts wrote: > 2012/7/19 Greg Bonett : >> Hello, >> >> I'm experiencing a kernel panic that appears to be caused by zfs. >> >> No errors are making it into /var/log/messages, but here is the error >> message that appears on my screen after panic (transcribed): >> >> panic solaris assert BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC, >> file: /src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c, line 1262 Happening pretty much daily. This was previously an old 8.2 patched with an early zpool v28. Recently upgraded it to 9.0. I guess next I will attempt recreating all filesystems... if it's as you say -- a filesystem problem and not caused by hardware issues... faction.local.int dumped core - see /var/crash/vmcore.9 Sat Aug 11 11:28:55 CEST 2012 FreeBSD faction.local.int 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #1: Mon Jul 16 22:59:11 CEST 2012 root@faction.local.int:/usr/obj/usr/src/sys/GENERIC amd64 panic: solaris assert: BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c, line: 1262 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: solaris assert: BSWAP_32(sa_hdr_phys->sa_magic) == SA_MAGIC, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c, line: 1262 cpuid = 0 KDB: stack backtrace: #0 0xffffffff808680fe at kdb_backtrace+0x5e #1 0xffffffff80832cb7 at panic+0x187 #2 0xffffffff8141fb8e at sa_build_index+0x2ee #3 0xffffffff8141fc65 at sa_handle_get_from_db+0xd5 #4 0xffffffff8144c8f1 at zfs_znode_sa_init+0xd1 #5 0xffffffff8144d93a at zfs_znode_alloc+0xba #6 0xffffffff8144df5f at zfs_zget+0x2af #7 0xffffffff81462f48 at zfs_dirent_lock+0x488 #8 0xffffffff814631d9 at zfs_dirlook+0x69 #9 0xffffffff8147346b at zfs_lookup+0x26b #10 0xffffffff81473cc1 at zfs_freebsd_lookup+0x81 #11 0xffffffff808b2be3 at vfs_cache_lookup+0xf3 #12 0xffffffff80b7dbb0 at VOP_LOOKUP_APV+0x40 #13 0xffffffff808b9fa4 at lookup+0x464 #14 0xffffffff808bb056 at namei+0x4d6 #15 0xffffffff808cadf3 at kern_statat_vnhook+0xb3 #16 0xffffffff808cafb5 at kern_statat+0x15 #17 0xffffffff808cb07a at sys_lstat+0x2a Uptime: 18h15m30s Dumping 1739 out of 3306 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff808327f5 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:442 #2 0xffffffff80832ca1 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:607 #3 0xffffffff8141fb8e in sa_build_index (hdl=Variable "hdl" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c:1262 #4 0xffffffff8141fc65 in sa_handle_get_from_db (os=0xfffffe0007619400, db=0xfffffe000ef8fd20, userp=0xfffffe00b016d4b0, hdl_type=Variable "hdl_type" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/sa.c:1367 #5 0xffffffff8144c8f1 in zfs_znode_sa_init (zfsvfs=0xfffffe00074f6000, zp=0xfffffe00b016d4b0, db=0xfffffe000ef8fd20, obj_type=DMU_OT_SA, sa_hdl=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:601 #6 0xffffffff8144d93a in zfs_znode_alloc (zfsvfs=0xfffffe00074f6000, db=0xfffffe000ef8fd20, blksz=Variable "blksz" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:683 #7 0xffffffff8144df5f in zfs_zget (zfsvfs=0xfffffe00074f6000, obj_num=437071, zpp=0xffffff80fa343498) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1247 #8 0xffffffff81462f48 in zfs_dirent_lock (dlpp=0xffffff80fa3434a0, dzp=0xfffffe0039fa0960, name=0xffffff80fa343580 "CVS", zpp=0xffffff80fa343498, flag=Variable "flag" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:317 #9 0xffffffff814631d9 in zfs_dirlook (dzp=0xfffffe0039fa0960, name=0xffffff80fa343580 "CVS", vpp=0xffffff80fa343940, flags=Variable "flags" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:411 #10 0xffffffff8147346b in zfs_lookup (dvp=0xfffffe0071cdd960, nm=0xffffff80fa343580 "CVS", vpp=0xffffff80fa343940, cnp=0xffffff80fa343968, nameiop=0, cr=0xfffffe0017432b00, td=0xfffffe002725f460, flags=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1404 #11 0xffffffff81473cc1 in zfs_freebsd_lookup (ap=0xffffff80fa3436c0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:5758 #12 0xffffffff808b2be3 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #13 0xffffffff80b7dbb0 in VOP_LOOKUP_APV (vop=0xffffffff814e6fc0, a=0xffffff80fa3437c0) at vnode_if.c:123 #14 0xffffffff808b9fa4 in lookup (ndp=0xffffff80fa343900) at vnode_if.h:54 #15 0xffffffff808bb056 in namei (ndp=0xffffff80fa343900) at /usr/src/sys/kern/vfs_lookup.c:297 #16 0xffffffff808cadf3 in kern_statat_vnhook (td=0xfffffe002725f460, flag=Variable "flag" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2422 #17 0xffffffff808cafb5 in kern_statat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2403 #18 0xffffffff808cb07a in sys_lstat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2466 #19 0xffffffff80b17e90 in amd64_syscall (td=0xfffffe002725f460, traced=0) at subr_syscall.c:131 #20 0xffffffff80b03537 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #21 0x000000080093ccac in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 14:57:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4869A106564A for ; Sun, 12 Aug 2012 14:57:49 +0000 (UTC) (envelope-from wajih.ahmed@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1E608FC08 for ; Sun, 12 Aug 2012 14:57:48 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1147364bkc.13 for ; Sun, 12 Aug 2012 07:57:47 -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=GkNXPlKpj/3C7GlBL1zsTFvF7gzxbSPr5jBrcfFlEaQ=; b=xHsLAqj+biEWueoH+sj3ijgE6B2LUfFOt8RtqdEapZF5X8QpoHe4NzrMuEXvI4jun1 8IDds3KhdYLe5Tda6AuqfT9JHjz+Uuh/4b7EPfJDst3LO3uUhWC8daSo8YMvnC7gInLq KjYAo97cdvyh4Ym11zx/UKWExOe8znpkBaB3BGzhGhkrAfbLQ3d8O/kijTZIk4bWM5Ia WQgDsX5pFCx9GXOlH3KDZQQ+QTaTR+ihkf+D2gUKscPou2VZH8kpDc/AKiG/EAvdEjoW Iyn576zl7USEKomyTh3zOKz7znUqHd1miV9ddtsnGZXPnbcBPOO2UwAXBGw16737oiNV BMbw== MIME-Version: 1.0 Received: by 10.204.154.202 with SMTP id p10mr3183293bkw.105.1344783467362; Sun, 12 Aug 2012 07:57:47 -0700 (PDT) Received: by 10.204.38.141 with HTTP; Sun, 12 Aug 2012 07:57:47 -0700 (PDT) Date: Sun, 12 Aug 2012 10:57:47 -0400 Message-ID: From: Wajih Ahmed To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 14:57:49 -0000 I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS recogonizes the drive. I am using the USB image to boot in verbose mode. Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for any typos as i am reading this off the console): ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial number... ada0: 100.0000MB/s transfers (UDMA5, PIO 512bytes) Then i see these errors (ada0:ata0:0:0:0): ATA status error .....READ_DMA. ACB: c8 .... .....CAM status: ATA status error .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) .....RES: 51 ..... As a result the disk is rendered unusable and i cannot write (partition) to it. I did test the drive with a linux boot disk and i was able to format it. So my question is how can i make this drive work? Do i need to pass something to the kernel at boot to lower the speed of the drive. Maybe to UDMA66? Any help will be really appreciated. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 15:46:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8621065687 for ; Sun, 12 Aug 2012 15:46:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9E08FC15 for ; Sun, 12 Aug 2012 15:46:04 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta11.emeryville.ca.mail.comcast.net with comcast id lq5t1j0030x6nqcABrlyAU; Sun, 12 Aug 2012 15:45:58 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta12.emeryville.ca.mail.comcast.net with comcast id lrlx1j00R4NgCEG8Yrlxjf; Sun, 12 Aug 2012 15:45:58 +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 q7CFjtDf013027; Sun, 12 Aug 2012 09:45:55 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Wajih Ahmed In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Aug 2012 09:45:55 -0600 Message-ID: <1344786355.1186.32.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 15:46:04 -0000 On Sun, 2012-08-12 at 10:57 -0400, Wajih Ahmed wrote: > I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA > drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS > recogonizes the drive. I am using the USB image to boot in verbose mode. > Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for any > typos as i am reading this off the console): > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 device > ada0: Serial number... > ada0: 100.0000MB/s transfers (UDMA5, PIO 512bytes) > > Then i see these errors > > (ada0:ata0:0:0:0): ATA status error > .....READ_DMA. ACB: c8 .... > .....CAM status: ATA status error > .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > .....RES: 51 ..... > > > As a result the disk is rendered unusable and i cannot write (partition) to > it. I did test the drive with a linux boot disk and i was able to format > it. > > So my question is how can i make this drive work? Do i need to pass > something to the kernel at boot to lower the speed of the drive. Maybe to > UDMA66? Any help will be really appreciated. Whenever I've seen ICRC errors, it has been caused by using a 40-wire cable at speeds faster than UDMA33 [1]. A potential fix is to force the mode in loader.conf: hint.ata.0.mode="UDMA33" [1] I've also seen ICRC errors when there was no cable involved at all, such as with a surface-mount compact flash socket on a circuit board that has 50 pins spaced even closer together than a standard ata cable. I have no real proof that such closely-spaced pins cause the same kind of signal crosstalk as a 40-wire cable (they're close, but the length of the parallel wires is just a couple millimeters), but forcing the driver to UDMA33 or less always seems to fix the problem. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 16:29:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7F7106564A for ; Sun, 12 Aug 2012 16:29:26 +0000 (UTC) (envelope-from wajih.ahmed@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 487A68FC08 for ; Sun, 12 Aug 2012 16:29:25 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1160550bkc.13 for ; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8FK8XfkFfHTmPk9QUz6r1wL+Bht0m8oZiu1vYL6150g=; b=geKhtq85ONQIM5s1mOl+aOHpOavVsYQPH27Kv5+Sko/no2+akZgPU0birUaCD9aFZi PYvLGerpYKPrpo3omqcvFHhXtdKZtFx9e2juUshrNSWpCp7ZssNcUD+ga9BBhWSrASk0 ILTdO7sXhtEyPC1rH6F8IhWU4582wsY8/A6hdweK3hDVXmGL9mPQxRh6cjQEOVUJAKeR e9Oh5cjNpYhSS5q1imgq7T/ho02vOA9xtOhZ1YyngXwwkNRax0E+9Q/nKvypC+pR5XgP ry8CVY8GuDlhIOLpqBqSzJnM5WW83r05Oz0OohfuKX6ejphJstKGGdRRqxrvFgFIFABq gcxQ== MIME-Version: 1.0 Received: by 10.204.157.6 with SMTP id z6mr3208037bkw.25.1344788964684; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) Received: by 10.204.38.141 with HTTP; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) In-Reply-To: <1344786355.1186.32.camel@revolution.hippie.lan> References: <1344786355.1186.32.camel@revolution.hippie.lan> Date: Sun, 12 Aug 2012 12:29:24 -0400 Message-ID: From: Wajih Ahmed To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 16:29:26 -0000 Thank you. I'll try it out. One question though. How do i modify the loader.conf on the usb image from which i am booting? Is there somethign i can change in the boot loader? If this is RTFM kindly point me to it. On Sun, Aug 12, 2012 at 11:45 AM, Ian Lepore wrote: > On Sun, 2012-08-12 at 10:57 -0400, Wajih Ahmed wrote: > > I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA > > drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS > > recogonizes the drive. I am using the USB image to boot in verbose mode. > > Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for any > > typos as i am reading this off the console): > > > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-7 device > > ada0: Serial number... > > ada0: 100.0000MB/s transfers (UDMA5, PIO 512bytes) > > > > Then i see these errors > > > > (ada0:ata0:0:0:0): ATA status error > > .....READ_DMA. ACB: c8 .... > > .....CAM status: ATA status error > > .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > > .....RES: 51 ..... > > > > > > As a result the disk is rendered unusable and i cannot write (partition) > to > > it. I did test the drive with a linux boot disk and i was able to format > > it. > > > > So my question is how can i make this drive work? Do i need to pass > > something to the kernel at boot to lower the speed of the drive. Maybe > to > > UDMA66? Any help will be really appreciated. > > Whenever I've seen ICRC errors, it has been caused by using a 40-wire > cable at speeds faster than UDMA33 [1]. A potential fix is to force the > mode in loader.conf: > > hint.ata.0.mode="UDMA33" > > [1] I've also seen ICRC errors when there was no cable involved at all, > such as with a surface-mount compact flash socket on a circuit board > that has 50 pins spaced even closer together than a standard ata cable. > I have no real proof that such closely-spaced pins cause the same kind > of signal crosstalk as a 40-wire cable (they're close, but the length of > the parallel wires is just a couple millimeters), but forcing the driver > to UDMA33 or less always seems to fix the problem. > > -- Ian > > > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 16:36:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93D64106566C for ; Sun, 12 Aug 2012 16:36:51 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 75F578FC15 for ; Sun, 12 Aug 2012 16:36:51 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta12.emeryville.ca.mail.comcast.net with comcast id lops1j0010b6N64ACscl3X; Sun, 12 Aug 2012 16:36:45 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta03.emeryville.ca.mail.comcast.net with comcast id lsck1j00i4NgCEG8PsclyU; Sun, 12 Aug 2012 16:36:45 +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 q7CGahFQ013050; Sun, 12 Aug 2012 10:36:43 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Wajih Ahmed In-Reply-To: References: <1344786355.1186.32.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Aug 2012 10:36:42 -0600 Message-ID: <1344789402.1186.35.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 16:36:51 -0000 On Sun, 2012-08-12 at 12:29 -0400, Wajih Ahmed wrote: > Thank you. I'll try it out. One question though. How do i modify the > loader.conf on the usb image from which i am booting? Is there somethign i > can change in the boot loader? If this is RTFM kindly point me to it. You can enter the value interactively in the loader. Just hit a key while it's doing the boot countdown to get the interactive prompt, and enter set hint.ata.0.mode="UDMA33" boot -- Ian From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 16:42:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B8CB106566C for ; Sun, 12 Aug 2012 16:42:47 +0000 (UTC) (envelope-from wajih.ahmed@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AEEB8FC08 for ; Sun, 12 Aug 2012 16:42:46 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1162553bkc.13 for ; Sun, 12 Aug 2012 09:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mUXAAGQIGGXVsU93MuAd3+PcTO0J+PXCWNqg0o2H/3A=; b=Y2YXTcsqb6Y3xq1EBEZkbMKjFMyOANLsj0gDKU4f41frllRxOLRKyQCHz2SyEfx5XY 2rszqTH/faGPcg9uIaE+Nh/I7URwxOjxuf+K+7qOBeak4ZoeCpH/t/DiDvmylJuDTNE3 lSSD8TENfZ3k8WDofJkM5srd0He+mzVbGONFxgW7u6nwCAmYTz/ieoU6iA3GmrAPwPPe qxihw2Bly3k5W7CEj08Vv7sVkoBTJovehNi0hf5kFsItLJAIX6305kW4NfBTo99mOWDf prIaV3VvRy2eJzKtbV4viy7lWP0/nUPWx76BLOi6W+ZE7hchKPSG14lzKRI0d6YNMlUY nL7A== MIME-Version: 1.0 Received: by 10.204.157.22 with SMTP id z22mr3240420bkw.4.1344789765666; Sun, 12 Aug 2012 09:42:45 -0700 (PDT) Received: by 10.204.38.141 with HTTP; Sun, 12 Aug 2012 09:42:45 -0700 (PDT) In-Reply-To: References: <1344786355.1186.32.camel@revolution.hippie.lan> Date: Sun, 12 Aug 2012 12:42:45 -0400 Message-ID: From: Wajih Ahmed To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 16:42:47 -0000 Ok at the boot loader prompt i did as you suggested set hint.ata.0.mode="UDMA33" And that change did take effect as evedint by ada0: 33.300MB/s transfers (UDMA2, PIO 512bytes) Unfortunately i still get the error .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) Regards, On Sun, Aug 12, 2012 at 12:29 PM, Wajih Ahmed wrote: > Thank you. I'll try it out. One question though. How do i modify the > loader.conf on the usb image from which i am booting? Is there somethign i > can change in the boot loader? If this is RTFM kindly point me to it. > > > > > On Sun, Aug 12, 2012 at 11:45 AM, Ian Lepore < > freebsd@damnhippie.dyndns.org> wrote: > >> On Sun, 2012-08-12 at 10:57 -0400, Wajih Ahmed wrote: >> > I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA >> > drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS >> > recogonizes the drive. I am using the USB image to boot in verbose >> mode. >> > Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for >> any >> > typos as i am reading this off the console): >> > >> > ada0 at ata0 bus 0 scbus0 target 0 lun 0 >> > ada0: ATA-7 device >> > ada0: Serial number... >> > ada0: 100.0000MB/s transfers (UDMA5, PIO 512bytes) >> > >> > Then i see these errors >> > >> > (ada0:ata0:0:0:0): ATA status error >> > .....READ_DMA. ACB: c8 .... >> > .....CAM status: ATA status error >> > .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) >> > .....RES: 51 ..... >> > >> > >> > As a result the disk is rendered unusable and i cannot write >> (partition) to >> > it. I did test the drive with a linux boot disk and i was able to >> format >> > it. >> > >> > So my question is how can i make this drive work? Do i need to pass >> > something to the kernel at boot to lower the speed of the drive. Maybe >> to >> > UDMA66? Any help will be really appreciated. >> >> Whenever I've seen ICRC errors, it has been caused by using a 40-wire >> cable at speeds faster than UDMA33 [1]. A potential fix is to force the >> mode in loader.conf: >> >> hint.ata.0.mode="UDMA33" >> >> [1] I've also seen ICRC errors when there was no cable involved at all, >> such as with a surface-mount compact flash socket on a circuit board >> that has 50 pins spaced even closer together than a standard ata cable. >> I have no real proof that such closely-spaced pins cause the same kind >> of signal crosstalk as a 40-wire cable (they're close, but the length of >> the parallel wires is just a couple millimeters), but forcing the driver >> to UDMA33 or less always seems to fix the problem. >> >> -- Ian >> >> >> > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 17:01:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD5AA1065781 for ; Sun, 12 Aug 2012 17:01:29 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 9E02D8FC0C for ; Sun, 12 Aug 2012 17:01:29 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta13.emeryville.ca.mail.comcast.net with comcast id loqS1j0050cQ2SLADt1UJY; Sun, 12 Aug 2012 17:01:29 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta10.emeryville.ca.mail.comcast.net with comcast id lt0R1j00E4NgCEG8Wt0S3D; Sun, 12 Aug 2012 17:00:26 +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 q7CH0NC8013070; Sun, 12 Aug 2012 11:00:23 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Wajih Ahmed In-Reply-To: References: <1344786355.1186.32.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Aug 2012 11:00:23 -0600 Message-ID: <1344790823.1186.37.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Aug 2012 17:01:29 -0000 On Sun, 2012-08-12 at 12:42 -0400, Wajih Ahmed wrote: > Ok at the boot loader prompt i did as you suggested > > set hint.ata.0.mode="UDMA33" > > And that change did take effect as evedint by > > ada0: 33.300MB/s transfers (UDMA2, PIO 512bytes) > > Unfortunately i still get the error > > .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > > Regards, It's probably worth trying an even slower mode, such as UDMA16, and for testing purposes maybe even PIO4, but it's starting to sound like maybe the problem is something else. -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 01:25:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8271106564A for ; Mon, 13 Aug 2012 01:25:26 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id AF28C8FC08 for ; Mon, 13 Aug 2012 01:25:26 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q7D1PHEr025241; Sun, 12 Aug 2012 18:25:17 -0700 (PDT) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: Garrett Cooper In-Reply-To: <665261FA-CD50-4476-B899-09DA56B944E7@gmail.com> References: <1344802894.5402.11.camel@btw.pki2.com> <1344803398.5537.9.camel@btw.pki2.com> <1344804827.5402.17.camel@btw.pki2.com> <665261FA-CD50-4476-B899-09DA56B944E7@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 12 Aug 2012 18:25:17 -0700 Message-ID: <1344821117.5402.25.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q7D1PHEr025241 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: freebsd-stable@freebsd.org Subject: Re: Panic 9 .1-PRERELEASE on HP Servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 01:25:27 -0000 On Sun, 2012-08-12 at 15:40 -0700, Garrett Cooper wrote: > On Aug 12, 2012, at 1:53 PM, Dennis Glatting wrote: > > > On Sun, 2012-08-12 at 13:37 -0700, Garrett Cooper wrote: > >> On Sun, Aug 12, 2012 at 1:29 PM, Dennis Glatting wrote: > >>> Looks like my screen shot was stripped. You can find it here: > >>> > >>> http://www.pki2.com/hp.JPG > >>> > >>> > >>> Also: > >>> > >>> Granny> cc -v > >>> Using built-in specs. > >>> Target: amd64-undermydesk-freebsd > >>> Configured with: FreeBSD/amd64 system compiler > >>> Thread model: posix > >>> gcc version 4.2.1 20070831 patched [FreeBSD] > >> > >> What was the actual panic message/assert that was hit? > >> Thanks, > > > > > > The iLO scroll back is very limited (the machine is also 1,200 miles > > away so a serial interface isn't possible). This new, second snap shot > > (http://www.pki2.com/hp2.JPG) I scrolled back as far as I can. > > Still can't see the exact cause :/; show msgbuf should help identify > what the exact panic string was. http://www.pki2.com/bpbt2.JPG I removed the ipmi driver and rebooted the machine five times without further problem. I won't be able to test the second machine until later in the week. > -Garrett > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 08:47:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62D891065672 for ; Mon, 13 Aug 2012 08:47:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CE6AF8FC19 for ; Mon, 13 Aug 2012 08:47:29 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7D8la2F068941; Mon, 13 Aug 2012 11:47:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7D8lOb2004486; Mon, 13 Aug 2012 11:47:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7D8lO3C004485; Mon, 13 Aug 2012 11:47:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Aug 2012 11:47:24 +0300 From: Konstantin Belousov To: Dennis Glatting Message-ID: <20120813084724.GB2352@deviant.kiev.zoral.com.ua> References: <1344802894.5402.11.camel@btw.pki2.com> <1344803398.5537.9.camel@btw.pki2.com> <1344804827.5402.17.camel@btw.pki2.com> <665261FA-CD50-4476-B899-09DA56B944E7@gmail.com> <1344821117.5402.25.camel@btw.pki2.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: <1344821117.5402.25.camel@btw.pki2.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Garrett Cooper , freebsd-stable@freebsd.org Subject: Re: Panic 9 .1-PRERELEASE on HP Servers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 08:47:30 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 12, 2012 at 06:25:17PM -0700, Dennis Glatting wrote: > http://www.pki2.com/bpbt2.JPG >=20 > I removed the ipmi driver and rebooted the machine five times without > further problem. I won't be able to test the second machine until later > in the week. >=20 I suspect that your trouble could be mitigated by r239128. --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAovxwACgkQC3+MBN1Mb4iZHwCfdahZk0sOEYxCe2UQkSbYbMtq BoYAoOKxvKSzcgGXE73Mt8VrBwnUdImo =5Nho -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 10:42:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 047AC1065676 for ; Mon, 13 Aug 2012 10:42:57 +0000 (UTC) (envelope-from stryqx@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B10BB8FC15 for ; Mon, 13 Aug 2012 10:42:56 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so4286028vcb.13 for ; Mon, 13 Aug 2012 03:42:55 -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=5Lh8BrJJoh3PXMrTKYme8mIgPRb2oU8CWtrNY2OL1x8=; b=V0dVwNRqAQH7gfkLnBmugU79tDntzzdczgBhjJoDGlw0VlTt9PWzIfKkGTRp/Wweqc O7l+c2Nd07armm0vMTyIo6Q310fS+uz4FzB5FcXW5irZE8qRx9WEVnwufmFVQuDczG8R GIrYAJRYMX+u7/BeSXvMRzHt7FOEx+AlxEtpJZlULK854hWxo8KeH2uenKfm+ikZDuHi /N0Gao1zP0b3sb+CrT+pCnwn1mSLjeuQG9wIEOWgos9yuDd6uNNdVR1vEuoieUxfgpeR xdl9v9iNox+YGczd4oA6x8KAdOGOOWrWlPhFBSF21jOcF8CIsICnI0tKHxjUOd+KFiTf vzOA== MIME-Version: 1.0 Received: by 10.58.65.10 with SMTP id t10mr8939242ves.48.1344854575500; Mon, 13 Aug 2012 03:42:55 -0700 (PDT) Received: by 10.58.144.199 with HTTP; Mon, 13 Aug 2012 03:42:55 -0700 (PDT) Date: Mon, 13 Aug 2012 20:42:55 +1000 Message-ID: From: Chris Knight To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Hyper-V Integration Components Patch for FreeBSD 8.2, 8.3, 9.0 and 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 10:42:57 -0000 Hello, I've created some patchsets based on the beta release of the Hyper-V integration components for FreeBSD. The patchsets are for 8.2, 8.3, 9.0 and 9.1-BETA1 and can be found here: http://blog.chrisara.com.au/2012/08/hyper-v-integration-components-for_13.html Although the Hyper-V kernel modules compile, they'll cause a kernel panic if loaded, but I got them built cleanly to allow for easy kernel swapping using nextboot. Using GEOM labels makes it easy to swap between a Hyper-V enabled kernel and a non-Hyper-V enabled kernel. It's also worth noting that the Hyper-V network driver is flaky - UDP works fairly well, but TCP is very flaky. Haven't yet got to the root cause of this. The storage performance increase is very nice, as is the heartbeat and shutdown capabilities. I've yet to check if KVP functionality is included. -- Regards, Chris Knight From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 11:50:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A1C9106564A for ; Mon, 13 Aug 2012 11:50:35 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3692B8FC14 for ; Mon, 13 Aug 2012 11:50:33 +0000 (UTC) Received: by vbmv11 with SMTP id v11so4400047vbm.13 for ; Mon, 13 Aug 2012 04:50:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7W8qX7kWr2h7bObnWLagvW6HRCnmyOjujdyAxBL4mjQ=; b=lXsopVxMACEJvs22uXN5mrBMueIxtCpjZQM3NU3jiC1frdeD4VDToMEqI0Kctjc2dS rgxLfC69xLRHW82OBKDO/x4fzHT58wlqMlzaXNgWv4REtHjeJFWns4P9rKUkxk5PyjGr 06yG7OdEAq+5DOz94LemrzT9o3sKU+hHgfo1igkOd+RqC9klQWreRgSipp47jZQium3+ MGBUC32QZEPmb4rPxPGpzpJu2MKWtu4ngqhB7e3jTBOUikHhiGo5NNKjXBd5N5JDBX9c 4nqcDj1xCikdctENSMcJhvt3+WHYCs4DWMF4TUdNJRrNoK7dWZOoJ9zt7gEXXCzemmGT XJ2A== MIME-Version: 1.0 Received: by 10.220.157.65 with SMTP id a1mr8028713vcx.39.1344858633112; Mon, 13 Aug 2012 04:50:33 -0700 (PDT) Received: by 10.58.168.242 with HTTP; Mon, 13 Aug 2012 04:50:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Aug 2012 21:50:33 +1000 Message-ID: From: Antony Mawer To: Chris Knight X-Gm-Message-State: ALoCoQmmkt+VLUzulzmsrnyNJCsDbzAJJmEaM2381QV2HtBT4jdGjLba+Cec//8aXWSH98pWUmk0 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: Hyper-V Integration Components Patch for FreeBSD 8.2, 8.3, 9.0 and 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 11:50:35 -0000 Great, really looking forward to trying this out! Have you noticed any difference with larger file systems using the HyperV block driver? Since 8.x the standard file systems seem to suffer corruption with > 40gb, which is a show stopper for our clients wanting to deploy on HyperV. I hoped this might solve the problem...? -- Antony On Monday, August 13, 2012, Chris Knight wrote: > Hello, > > I've created some patchsets based on the beta release of the Hyper-V > integration components for FreeBSD. > > The patchsets are for 8.2, 8.3, 9.0 and 9.1-BETA1 and can be found here: > > http://blog.chrisara.com.au/2012/08/hyper-v-integration-components-for_13.html > > Although the Hyper-V kernel modules compile, they'll cause a kernel > panic if loaded, but I got them built cleanly to allow for easy kernel > swapping using nextboot. > Using GEOM labels makes it easy to swap between a Hyper-V enabled > kernel and a non-Hyper-V enabled kernel. > > It's also worth noting that the Hyper-V network driver is flaky - UDP > works fairly well, but TCP is very flaky. Haven't yet got to the root > cause of this. > > The storage performance increase is very nice, as is the heartbeat and > shutdown capabilities. I've yet to check if KVP functionality is > included. > > > -- > Regards, > Chris Knight > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 17:40:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1DBE1065673 for ; Mon, 13 Aug 2012 17:40:44 +0000 (UTC) (envelope-from kinathlon-web@ozon.sk) Received: from ns.ozon.sk (ns.ozon.sk [176.9.79.240]) by mx1.freebsd.org (Postfix) with ESMTP id B58D38FC12 for ; Mon, 13 Aug 2012 17:40:44 +0000 (UTC) Received: by ns.ozon.sk (Postfix, from userid 10046) id F05609105F73; Mon, 13 Aug 2012 19:34:03 +0200 (CEST) To: freebsd-stable@freebsd.org From: Mark Peters MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20120813174043.F05609105F73@ns.ozon.sk> Date: Mon, 13 Aug 2012 19:34:03 +0200 (CEST) Subject: Order.. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ausvva@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:40:45 -0000 My name is Mark Peters,I want to place an order in your store,I will like to know if you ship to Philippines. Do you have credit card facility?Get back to me with your website..I will await your prompt response. Best Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 17:47:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898D31065672 for ; Mon, 13 Aug 2012 17:47:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7FC8FC19 for ; Mon, 13 Aug 2012 17:47:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE483B95D; Mon, 13 Aug 2012 13:47:16 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 13 Aug 2012 12:34:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208131234.53905.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:16 -0400 (EDT) Cc: "mnln.l4" Subject: Re: Kernel panic at early boot time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 17:47:17 -0000 On Wednesday, August 08, 2012 8:26:56 pm mnln.l4 wrote: > I finally have some time to take a closer look at this issue. Yes, it > is caused by SMI#. DragonflyBSD has tried to fix the similar problem > (see http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/bb467734fc407e2c2de7f8314c63dd9f708f4df4) > > But Windows and Linux don't cause such problem on my machine. > > I compared MP initialization code between FreeBSD, Linux and NetBSD. I > believe the problem is FreeBSD doesn't wait for 10ms between IPI_INIT > assert and IPI_INIT deassert (though FreeBSD waits for 10ms after > IPI_INIT deassert). After inserting 10ms wait time, the issue is > solved. BTW, Intel's MP spec 1.4 doesn't explain very well either. I think the confusion is that we have an extra IPI step (deassert INIT IPI) that we did have the wait after. Your patch is correct and I've committed it (well, a variant, I put the DELAY() after the lapic_ipi_wait()). I think we should actually just remove the deassert INIT IPI entirely as I can find no reference in either the MP spec or otherwise that says that it should be used. It is also ignored on all modern processors. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 17:47:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594AE1065675 for ; Mon, 13 Aug 2012 17:47:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1A18FC1A for ; Mon, 13 Aug 2012 17:47:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A242FB9BD; Mon, 13 Aug 2012 13:47:17 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 13 Aug 2012 13:45:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208131345.55377.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:17 -0400 (EDT) Cc: Chris Knight Subject: Re: Hyper-V Integration Components Patch for FreeBSD 8.2, 8.3, 9.0 and 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Aug 2012 17:47:18 -0000 On Monday, August 13, 2012 6:42:55 am Chris Knight wrote: > Hello, > > I've created some patchsets based on the beta release of the Hyper-V > integration components for FreeBSD. > > The patchsets are for 8.2, 8.3, 9.0 and 9.1-BETA1 and can be found here: > http://blog.chrisara.com.au/2012/08/hyper-v-integration-components- for_13.html > > Although the Hyper-V kernel modules compile, they'll cause a kernel > panic if loaded, but I got them built cleanly to allow for easy kernel > swapping using nextboot. > Using GEOM labels makes it easy to swap between a Hyper-V enabled > kernel and a non-Hyper-V enabled kernel. > > It's also worth noting that the Hyper-V network driver is flaky - UDP > works fairly well, but TCP is very flaky. Haven't yet got to the root > cause of this. > > The storage performance increase is very nice, as is the heartbeat and > shutdown capabilities. I've yet to check if KVP functionality is > included. Can you post these to virtualization@ as well? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 09:54:52 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7805106564A; Tue, 14 Aug 2012 09:54:52 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw11.york.ac.uk (mail-gw11.york.ac.uk [144.32.129.150]) by mx1.freebsd.org (Postfix) with ESMTP id 37B8E8FC08; Tue, 14 Aug 2012 09:54:51 +0000 (UTC) Received: from buffy-128.york.ac.uk ([144.32.128.160]:50950 helo=buffy.york.ac.uk) by mail-gw11.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1T1Dpq-0006Wn-6h; Tue, 14 Aug 2012 10:54:50 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.5/8.14.5) with ESMTP id q7E9smV0047497; Tue, 14 Aug 2012 10:54:48 +0100 (BST) (envelope-from gavin@FreeBSD.org) From: Gavin Atkinson To: Maksim Yevmenkin In-Reply-To: References: <501D52AD.4010105@protected-networks.net> Content-Type: text/plain; charset="ASCII" Date: Tue, 14 Aug 2012 10:41:51 +0100 Message-ID: <1344937311.47389.1.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: geom mirror now rebuilding on every reboot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Aug 2012 09:54:52 -0000 On Mon, 2012-08-06 at 08:34 -0700, Maksim Yevmenkin wrote: > Michael, > > > Something in -current and recently MFC'd to -stable is causing all of my > > gmirror drives to rebuild on reboot :-( > > > > Being remote and these being production machines, I suspect SVN r237929 > > and r237930 in -current and SVN r238500 to -stable but haven't yet been > > able to prove it. > > > > Is anyone else seeing this? > > yes, i've seem something similar only much, much worse. one of our > production systems completely kept loosing its gmirror volumes on > every reboot. it looked like gmirror metadata were completely > corrupted. rebuilding mirrors and reverting back to previous kernel > seemed to work. someone else is tracking it down. Have they managed to track this down to a commit or range of commits yet? Thanks, Gavin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 16:50:39 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ED1C106566B for ; Tue, 14 Aug 2012 16:50:39 +0000 (UTC) (envelope-from lordcow@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 52D888FC15 for ; Tue, 14 Aug 2012 16:50:37 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.5/8.14.5) with ESMTP id q7EGYghF050026 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2012 18:34:42 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.5/8.14.5/Submit) id q7EGYbWR050025 for stable@freebsd.org; Tue, 14 Aug 2012 18:34:37 +0200 (SAST) (envelope-from lordcow) Date: Tue, 14 Aug 2012 18:34:37 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20120814163437.GA47679@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lordcow.org Cc: Subject: unrecognised external drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Aug 2012 16:50:39 -0000 Hi all, I bought a Western Digital external drive a few months ago but it gets kicked out 20 seconds after I plug it in. I've updated to the latest 8.3-STABLE: $ uname -a FreeBSD file 8.3-STABLE FreeBSD 8.3-STABLE #0: Sun Aug 12 12:45:04 SAST 2012 root@file:/usr/obj/usr/src/sys/COWNEL amd64 Aug 12 15:49:55 file kernel: ugen4.2: at usbus4 Aug 12 15:49:55 file kernel: umass0: on usbus4 Aug 12 15:49:55 file kernel: umass0: SCSI over Bulk-Only; quirks = 0x4101 Aug 12 15:49:55 file kernel: umass0:5:0:-1: Attached to scbus5 Aug 12 15:50:15 file kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4 Aug 12 15:50:15 file kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Aug 12 15:50:15 file kernel: (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs Aug 12 15:50:15 file kernel: (da0:umass-sim0:0:0:0): removing device entry and Aug 12 16:10:15 file kernel: ugen4.2: at usbus4 (disconnected) Aug 12 16:10:15 file kernel: umass0: at uhub4, port 5, addr 2 (disconnected) Aug 12 16:10:38 file kernel: ugen4.2: at usbus4 Aug 12 16:10:38 file kernel: umass0: on usbus4 Aug 12 16:10:38 file kernel: umass0: SCSI over Bulk-Only; quirks = 0x4101 Aug 12 16:10:38 file kernel: umass0:5:0:-1: Attached to scbus5 Aug 12 16:10:57 file kernel: (da0:umass-sim0:0:0:0): got CAM status 0x4 Aug 12 16:10:57 file kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Aug 12 16:10:57 file kernel: Aug 12 16:10:57 file kernel: (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs Aug 12 16:10:57 file kernel: (da0:umass-sim0:0:0:0): removing device entry Aug 12 16:12:55 file kernel: ugen4.2: at usbus4 (disconnected) Aug 12 16:12:55 file kernel: umass0: at uhub4, port 6, addr 2 (disconnected) My kernel is slightly stripped but the relevant parts are included afaik - other drives mount fine. Same thing happens with a GENERIC but older kernel: $ uname -a FreeBSD imap1 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Jun 7 07:51:08 SAST 2012 root@imap1:/usr/obj/usr/src/sys/GENERIC amd64 Aug 13 09:58:20 imap1 kernel: ugen1.4: at usbus1 Aug 13 09:58:20 imap1 kernel: umass1: on usbus1 Aug 13 09:58:20 imap1 kernel: umass1: SCSI over Bulk-Only; quirks = 0x4101 Aug 13 09:58:20 imap1 kernel: umass1:19:1:-1: Attached to scbus19 Aug 13 09:58:39 imap1 kernel: (da1:umass-sim1:1:0:0): got CAM status 0x4 Aug 13 09:58:39 imap1 kernel: (da1:umass-sim1:1:0:0): fatal error, failed to attach to device Aug 13 09:58:39 imap1 kernel: (da1:umass-sim1:1:0:0): lost device - 0 outstanding, 3 refs Aug 13 09:58:40 imap1 kernel: (da1:umass-sim1:1:0:0): removing device entry Aug 13 09:59:06 imap1 kernel: ugen1.4: at usbus1 (disconnected) Aug 13 09:59:06 imap1 kernel: umass1: at uhub1, port 3, addr 4 (disconnected) The drive works on linux, is it not supported on FreeBSD? Some info from the linux machine: Aug 14 18:27:32 fire kernel: [338650.300883] scsi 6:0:0:0: Direct-Access WD Elements 1042 1007 PQ: 0 ANSI: 6 lsusb -v: Bus 002 Device 003: ID 1058:1042 Western Digital Technologies, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1058 Western Digital Technologies, Inc. idProduct 0x1042 bcdDevice 10.07 iManufacturer 1 Western Digital iProduct 2 Elements 1042 iSerial 5 575846314331324537303135 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 USB Mass Storage bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 6 MSC Bulk-Only Transport Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 19:34:50 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BCB01065677; Tue, 14 Aug 2012 19:34:50 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id E1CBA8FC14; Tue, 14 Aug 2012 19:34:49 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 5186B6FADE; Tue, 14 Aug 2012 15:25:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aU6dhOPytIn; Tue, 14 Aug 2012 15:25:41 -0400 (EDT) Received: from daemon.localdomain (daemon.egr.msu.edu [35.9.44.65]) by mail.egr.msu.edu (Postfix) with ESMTP id 21E236FAD6; Tue, 14 Aug 2012 15:25:41 -0400 (EDT) Received: by daemon.localdomain (Postfix, from userid 21281) id 1DDD33F2BD; Tue, 14 Aug 2012 15:25:41 -0400 (EDT) Date: Tue, 14 Aug 2012 15:25:41 -0400 From: Adam McDougall To: Alexander Motin Message-ID: <20120814192540.GV68639@egr.msu.edu> References: <4F9CCEF2.6050609@FreeBSD.org> <20120429155512.M91148@sola.nimnet.asn.au> <4F9CDE91.1060300@FreeBSD.org> <4F9D2F0C.4050501@FreeBSD.org> <20120429122714.GA56829@ravenloft.kiev.ua> <4F9D3DF8.9000800@FreeBSD.org> <20120429133056.GA58422@ravenloft.kiev.ua> <4F9D4491.2060007@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="reI/iBAAp9kzkmX4" Content-Disposition: inline In-Reply-To: <4F9D4491.2060007@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: High load event idl. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Aug 2012 19:34:50 -0000 --reI/iBAAp9kzkmX4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Apr 29, 2012 at 04:39:29PM +0300, Alexander Motin wrote: On 04/29/12 16:30, Alex Kozlov wrote: > On Sun, Apr 29, 2012 at 04:11:20PM +0300, Alexander Motin wrote: >> On 04/29/12 15:27, Alex Kozlov wrote: >>> On Sun, Apr 29, 2012 at 03:07:40PM +0300, Alexander Motin wrote: >>>> On 04/29/12 15:04, Oliver Pinter wrote: >>>>> Removing dummynet from kernel don't chanage anything, that is releated >>>>> to load average. The loadavg hold to 0.70 +/- 0.2. (single user : sh + >>>>> top) >>>> >>>> New ktr dump? >>> I have similar issue on one of my laptops. Should I provide ktr dump? >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027133.html >> In your case HPET also shares interrupt with other devices. I suspect >> that may be a reason. Every time when swi thread runs loadavg, other CPU >> runs shared interrupt handler, that is accounted as result. Please show >> your verbose dmesg. > Attached. In your case HPET could solely use IRQ22 that seems free now. After recent changes in ACPI code it is detected before PCI devices and so doesn't avoids sharing. You may try to hint it specific IRQ by adding to loader,conf line: hint.hpet.0.allowed_irqs="0x00400000" -- Alexander Motin I think I am having the same issue on my Sun Fire x4150 servers. It goes away when I sysctl kern.eventtimer.timer=LAPIC but I'm hesitant to use local workarounds in case they become pessimistic in the future. I'm not sure all of my systems would have the same free irqs (including after potential addition of expansion cards) so it might be a pain to determine an appropriate allowed_irqs setting for each. I tried hint.hpet.0.allowed_irqs="0x00000000" for the sake of experiment and that just results in LAPIC being used since HPET is removed from kern.eventtimer.choice. I've attached a verbose dmesg (will probably be stripped from the list, hence the Cc:). Is there a limit to how high the irq can be set or could I perhaps set it high enough that it is unlikely to conflict with other hardware? Is there a chance we can find an automatic fix for this issue, or should I just stick with LAPIC at the expense of whatever the HPET event timer gets me? Or something else? I feel the partially random load average level makes it difficult to measure a low load and can be misleading during problem debugging. Thanks. PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 11 root 127 0 0 0 0 0 0.00% intr{irq20: hpet0 uhc} 11 root 74 0 0 0 0 0 0.00% intr{swi4: clock} 0 root 30 0 0 0 0 0 0.00% kernel{em0 que} 13 root 20 0 0 0 0 0 0.00% yarrow 11 root 10 0 0 0 0 0 0.00% intr{swi4: clock} 11 root 8 0 0 0 0 0 0.00% intr{swi4: clock} 11 root 5 0 0 0 0 0 0.00% intr{swi4: clock} Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt cow 83 total 24 306 4 128 83 54 zfod uart0 4 ozfod mpt0 16 0.0%Sys 0.0%Intr 0.0%User 0.0%Nice 100%Idle %ozfod mpt1 17 | | | | | | | | | | | daefr mpt3 18 prcfr mpt4 19 dtbuf totfr 66 hpet0 uhci --reI/iBAAp9kzkmX4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-verbose-ike2.txt" Table 'FACP' at 0xdffc0290 Table 'APIC' at 0xdffc0390 APIC: Found table at 0xdffc0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 5 ACPI ID 4: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 2 ACPI ID 5: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 6 ACPI ID 6: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 3 ACPI ID 7: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 7 ACPI ID 8: enabled SMP: Added CPU 7 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #4: Sun Aug 5 18:42:03 EDT 2012 root@chavez2:/usr/obj/usr/src/sys/AMD64-9 amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8103a000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff8103a220. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff8103a8c8. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff8103aef8. Calibrating TSC clock ... TSC clock: 2327548482 Hz CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (2327.55-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000009bfff, 573440 bytes (140 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x000000000106e000 - 0x00000000dffaffff, 3740540928 bytes (913218 pages) 0x00000000dffbe000 - 0x00000000dffbffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x000000020fff9fff, 4563378176 bytes (1114106 pages) avail memory = 8234450944 (7852 MB) INTR: Adding local APIC 0 as a target Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff800024a000 x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 5 APIC: CPU 3 has ACPI ID 7 APIC: CPU 4 has ACPI ID 2 APIC: CPU 5 has ACPI ID 4 APIC: CPU 6 has ACPI ID 6 APIC: CPU 7 has ACPI ID 8 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0xfa680 00024 (v02 ACPIAM) ACPI: XSDT 0xdffc0100 0008C (v01 A M I XSDT0917 03000903 MSFT 00000097) ACPI: FACP 0xdffc0290 000F4 (v03 A M I FACP0917 03000903 MSFT 00000097) ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000420/0x0 (20110527/tbfadt-586) ACPI Warning: Invalid length for Pm2ControlBlock: 0, using default 8 (20110527/tbfadt-638) ACPI: DSDT 0xdffc04f0 04BBD (v01 1ADQW 1ADQW060 00000060 INTL 20051117) ACPI: FACS 0xdffce000 00040 ACPI: APIC 0xdffc0390 000C8 (v01 A M I APIC0917 03000903 MSFT 00000097) ACPI: SPCR 0xdffc0460 00050 (v01 A M I SPCR0917 03000903 MSFT 00000097) ACPI: MCFG 0xdffc04b0 0003C (v01 A M I OEMMCFG 03000903 MSFT 00000097) ACPI: SSDT 0xdffc50b0 0002A (v01 OEM_ID OEMTBLID 00000001 INTL 20051117) ACPI: OEMB 0xdffce040 00061 (v01 A M I OEMB0917 03000903 MSFT 00000097) ACPI: HPET 0xdffc50e0 00038 (v01 A M I OEMHPET 03000903 MSFT 00000097) ACPI: TCPA 0xdffc5120 00032 (v01 A M I TBLOEMID 00000001 MSFT 00000097) ACPI: SSDT 0xdffe1e10 01259 (v01 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xdffc5160 00130 (v01 AMIER AMI_EINJ 03000903 MSFT 00000097) ACPI: BERT 0xdffc52f0 00030 (v01 AMIER AMI_BERT 03000903 MSFT 00000097) ACPI: ERST 0xdffc5320 001B0 (v01 AMIER AMI_ERST 03000903 MSFT 00000097) ACPI: HEST 0xdffc54d0 000A8 (v01 AMIER AMI_HEST 03000903 MSFT 00000097) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 9, Interrupt 24 at 0xfec80000 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic5: Routing NMI -> LINT1 lapic5: LINT1 trigger: edge lapic5: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic6: Routing NMI -> LINT1 lapic6: LINT1 trigger: edge lapic6: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic7: Routing NMI -> LINT1 lapic7: LINT1 trigger: edge lapic7: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 Event-channel device installed. snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 nfslock: pseudo-device null: random: module_register_init: MOD_LOAD (vesa, 0xffffffff807e3530, 0) error 19 kbd: new array size 4 kbd1 at kbdmux0 mem: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed cpu0: Processor \\_PR_.CPU1 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x32, should be 0x2F (20110527/tbutils-282) ACPI: SSDT 0xdffe1380 00630 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00630 (v01 PmRef P001Cst 00003001 INTL 20051117) cpu1: Processor \\_PR_.CPU2 (ACPI ID 2) -> APIC ID 4 cpu1: on acpi0 ACPI: SSDT 0xdffe19b0 0009C (v01 PmRef P002Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P002Cst 00003000 INTL 20051117) cpu2: Processor \\_PR_.CPU3 (ACPI ID 3) -> APIC ID 1 cpu2: on acpi0 ACPI: SSDT 0xdffe1a50 0009C (v01 PmRef P003Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P003Cst 00003000 INTL 20051117) cpu3: Processor \\_PR_.CPU4 (ACPI ID 4) -> APIC ID 5 cpu3: on acpi0 ACPI: SSDT 0xdffe1af0 0009C (v01 PmRef P004Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P004Cst 00003000 INTL 20051117) cpu4: Processor \\_PR_.CPU5 (ACPI ID 5) -> APIC ID 2 cpu4: on acpi0 ACPI: SSDT 0xdffe1b90 0009C (v01 PmRef P005Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P005Cst 00003000 INTL 20051117) cpu5: Processor \\_PR_.CPU6 (ACPI ID 6) -> APIC ID 6 cpu5: on acpi0 ACPI: SSDT 0xdffe1c30 0009C (v01 PmRef P006Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P006Cst 00003000 INTL 20051117) cpu6: Processor \\_PR_.CPU7 (ACPI ID 7) -> APIC ID 3 cpu6: on acpi0 ACPI: SSDT 0xdffe1cd0 0009C (v01 PmRef P007Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P007Cst 00003000 INTL 20051117) cpu7: Processor \\_PR_.CPU8 (ACPI ID 8) -> APIC ID 7 cpu7: on acpi0 ACPI: SSDT 0xdffe1d70 0009C (v01 PmRef P008Cst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0009C (v01 PmRef P008Cst 00003000 INTL 20051117) attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 51 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xca1 pcib0: decoding 4 range 0xca4-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xdffff pcib0: decoding 3 range 0xe0000000-0xffbfffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x25d8, revid=0xb1 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e2, revid=0xb1 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e3, revid=0xb1 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f8, revid=0xb1 domain=0, bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e5, revid=0xb1 domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f9, revid=0xb1 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e7, revid=0xb1 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f0, revid=0xb1 domain=0, bus=0, slot=16, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0xb1 domain=0, bus=0, slot=16, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0xb1 domain=0, bus=0, slot=16, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f1, revid=0xb1 domain=0, bus=0, slot=17, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f3, revid=0xb1 domain=0, bus=0, slot=19, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f5, revid=0xb1 domain=0, bus=0, slot=21, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f6, revid=0xb1 domain=0, bus=0, slot=22, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2690, revid=0x09 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2688, revid=0x09 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 map[20]: type I/O Port, range 32, base 0xd800, size 5, enabled pcib0: allocated type 4 (0xd800-0xd81f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2689, revid=0x09 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xd400, size 5, enabled pcib0: allocated type 4 (0xd400-0xd41f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 23 found-> vendor=0x8086, dev=0x268a, revid=0x09 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0xd000, size 5, enabled pcib0: allocated type 4 (0xd000-0xd01f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 20 found-> vendor=0x8086, dev=0x268b, revid=0x09 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=7 map[20]: type I/O Port, range 32, base 0xcc00, size 5, enabled pcib0: allocated type 4 (0xcc00-0xcc1f) for rid 20 of pci0:0:29:3 pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 21 found-> vendor=0x8086, dev=0x268c, revid=0x09 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfdfff800, size 10, enabled pcib0: allocated type 3 (0xfdfff800-0xfdfffbff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x244e, revid=0xd9 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1b (6750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2670, revid=0x09 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x269e, revid=0x09 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 map[20]: type I/O Port, range 32, base 0xfff0, size 4, enabled found-> vendor=0x8086, dev=0x2681, revid=0x09 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0047, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xec00, size 3, enabled pcib0: allocated type 4 (0xec00-0xec07) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0xe800, size 2, enabled pcib0: allocated type 4 (0xe800-0xe803) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0xe400, size 3, enabled pcib0: allocated type 4 (0xe400-0xe407) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0xe000, size 2, enabled pcib0: allocated type 4 (0xe000-0xe003) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib0: allocated type 4 (0xdc00-0xdc1f) for rid 20 of pci0:0:31:2 map[24]: type Memory, range 32, base 0xfdfffc00, size 10, enabled pcib0: allocated type 3 (0xfdfffc00-0xfdffffff) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x269b, revid=0x09 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0141, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type I/O Port, range 32, base 0x300, size 5, enabled pcib0: allocated type 4 (0x300-0x31f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 22 pcib1: at device 2.0 on pci0 pcib0: allocated type 4 (0x6000-0x7fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xfba00000-0xfc0fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 6 pcib1: I/O decode 0x6000-0x7fff pcib1: memory decode 0xfba00000-0xfc0fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x3500, revid=0x01 domain=0, bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x350c, revid=0x01 domain=0, bus=1, slot=0, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib2: irq 16 at device 0.0 on pci1 pcib1: allocated I/O port range (0x6000-0x7fff) for rid 1c of pcib2 pcib1: allocated memory range (0xfba00000-0xfc0fffff) for rid 20 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 5 pcib2: I/O decode 0x6000-0x7fff pcib2: memory decode 0xfba00000-0xfc0fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x3510, revid=0x01 domain=0, bus=2, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x3518, revid=0x01 domain=0, bus=2, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: at device 0.0 on pci2 pcib2: allocated I/O port range (0x6000-0x6fff) for rid 1c of pcib3 pcib2: allocated memory range (0xfba00000-0xfbffffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0x6000-0x6fff pcib3: memory decode 0xfba00000-0xfbffffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10b5, dev=0x8114, revid=0xbc domain=0, bus=3, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0157, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfbffe000, size 13, enabled pcib3: allocated memory range (0xfbffe000-0xfbffffff) for rid 10 of pci0:3:0:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: mem 0xfbffe000-0xfbffffff irq 16 at device 0.0 on pci3 pcib3: allocated I/O port range (0x6000-0x6fff) for rid 1c of pcib4 pcib3: allocated memory range (0xfba00000-0xfbefffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x6000-0x6fff pcib4: memory decode 0xfba00000-0xfbefffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1000, dev=0x0030, revid=0x08 domain=0, bus=4, slot=8, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x06 (1500 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x6800, size 8, enabled pcib4: allocated I/O port range (0x6800-0x68ff) for rid 10 of pci0:4:8:0 map[14]: type Memory, range 64, base 0xfbee0000, size 17, enabled pcib4: allocated memory range (0xfbee0000-0xfbefffff) for rid 14 of pci0:4:8:0 map[1c]: type Memory, range 64, base 0xfbec0000, size 17, enabled pcib4: allocated memory range (0xfbec0000-0xfbedffff) for rid 1c of pci0:4:8:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: slot 8 INTA is routed to irq 16 found-> vendor=0x1000, dev=0x0030, revid=0x08 domain=0, bus=4, slot=8, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x06 (1500 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x6400, size 8, enabled pcib4: allocated I/O port range (0x6400-0x64ff) for rid 10 of pci0:4:8:1 map[14]: type Memory, range 64, base 0xfbea0000, size 17, enabled pcib4: allocated memory range (0xfbea0000-0xfbebffff) for rid 14 of pci0:4:8:1 map[1c]: type Memory, range 64, base 0xfbe80000, size 17, enabled pcib4: allocated memory range (0xfbe80000-0xfbe9ffff) for rid 1c of pci0:4:8:1 pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 17 pcib4: slot 8 INTB is routed to irq 17 mpt0: port 0x6800-0x68ff mem 0xfbee0000-0xfbefffff,0xfbec0000-0xfbedffff irq 16 at device 8.0 on pci4 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 mpt0: MPI Version=1.2.14.0 mpt0: chain depth limited to 48 (from 2550) mpt0: Maximum Segment Count: 336, Maximum CAM Segment Count: 33 mpt0: MsgLength=15 IOCNumber = 0 mpt0: IOCFACTS: GlobalCredits=255 BlockSize=8 bytes Request Frame Size 96 bytes Max Chain Depth 48 mpt0: IOCFACTS: Num Ports 1, FWImageSize 40752, Flags=0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt1: port 0x6400-0x64ff mem 0xfbea0000-0xfbebffff,0xfbe80000-0xfbe9ffff irq 17 at device 8.1 on pci4 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 mpt1: MPI Version=1.2.14.0 mpt1: chain depth limited to 48 (from 2550) mpt1: Maximum Segment Count: 336, Maximum CAM Segment Count: 33 mpt1: MsgLength=15 IOCNumber = 1 mpt1: IOCFACTS: GlobalCredits=255 BlockSize=8 bytes Request Frame Size 96 bytes Max Chain Depth 48 mpt1: IOCFACTS: Num Ports 1, FWImageSize 40752, Flags=0 mpt1: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt1: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pcib5: at device 2.0 on pci2 pcib2: allocated I/O port range (0x7000-0x7fff) for rid 1c of pcib5 pcib2: allocated memory range (0xfc000000-0xfc0fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x7000-0x7fff pcib5: memory decode 0xfc000000-0xfc0fffff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x1096, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfc0e0000, size 17, enabled pcib5: allocated memory range (0xfc0e0000-0xfc0fffff) for rid 10 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0x7c00, size 5, enabled pcib5: allocated I/O port range (0x7c00-0x7c1f) for rid 18 of pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1096, revid=0x01 domain=0, bus=5, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfc0c0000, size 17, enabled pcib5: allocated memory range (0xfc0c0000-0xfc0dffff) for rid 10 of pci0:5:0:1 map[18]: type I/O Port, range 32, base 0x7800, size 5, enabled pcib5: allocated I/O port range (0x7800-0x781f) for rid 18 of pci0:5:0:1 pcib5: matched entry for 5.0.INTB pcib5: slot 0 INTB hardwired to IRQ 19 em0: port 0x7c00-0x7c1f mem 0xfc0e0000-0xfc0fffff irq 18 at device 0.0 on pci5 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 54 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: bpf attached em0: Ethernet address: 00:1b:24:f0:7d:6c em1: port 0x7800-0x781f mem 0xfc0c0000-0xfc0dffff irq 19 at device 0.1 on pci5 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 55 em1: using IRQ 257 for MSI em1: Using an MSI interrupt em1: bpf attached em1: Ethernet address: 00:1b:24:f0:7d:6d pcib6: at device 0.3 on pci1 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: at device 3.0 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: no prefetched decode pcib7: could not get PCI interrupt routing table for \\_SB_.PCI0.NPE3 - AE_NOT_FOUND pci7: on pcib7 pci7: domain=0, physical bus=7 pcib8: at device 4.0 on pci0 pcib0: allocated type 4 (0x8000-0x8fff) for rid 1c of pcib8 pcib0: allocated type 3 (0xfc100000-0xfc5fffff) for rid 20 of pcib8 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0x8000-0x8fff pcib8: memory decode 0xfc100000-0xfc5fffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x1000, dev=0x0058, revid=0x04 domain=0, bus=8, slot=0, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0x8800, size 8, enabled pcib8: allocated I/O port range (0x8800-0x88ff) for rid 10 of pci0:8:0:0 map[14]: type Memory, range 64, base 0xfc5fc000, size 14, enabled pcib8: allocated memory range (0xfc5fc000-0xfc5fffff) for rid 14 of pci0:8:0:0 map[1c]: type Memory, range 64, base 0xfc5e0000, size 16, enabled pcib8: allocated memory range (0xfc5e0000-0xfc5effff) for rid 1c of pci0:8:0:0 pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 17 mpt2: port 0x8800-0x88ff mem 0xfc5fc000-0xfc5fffff,0xfc5e0000-0xfc5effff irq 17 at device 0.0 on pci8 mpt2: attempting to allocate 1 MSI-X vectors (1 supported) msi: routing MSI-X IRQ 258 to local APIC 0 vector 56 mpt2: using IRQ 258 for MSI-X mpt2: MPI Version=1.5.20.0 mpt2: chain depth limited to 34 (from 2040) mpt2: Maximum Segment Count: 306, Maximum CAM Segment Count: 33 mpt2: MsgLength=20 IOCNumber = 0 mpt2: IOCFACTS: GlobalCredits=277 BlockSize=8 bytes Request Frame Size 128 bytes Max Chain Depth 34 mpt2: IOCFACTS: Num Ports 1, FWImageSize 0, Flags=0x2 mpt2: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: No Handlers For Any Event Notify Frames. Event 0xf (ACK not required). mpt2: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt2: 0 Active Volumes (2 Max) mpt2: 0 Hidden Drive Members (14 Max) mpt2: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pcib9: at device 5.0 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: no prefetched decode pci9: on pcib9 pci9: domain=0, physical bus=9 pcib10: at device 6.0 on pci0 pcib0: allocated type 4 (0x9000-0x9fff) for rid 1c of pcib10 pcib0: allocated type 3 (0xfc600000-0xfcbfffff) for rid 20 of pcib10 pcib10: domain 0 pcib10: secondary bus 10 pcib10: subordinate bus 11 pcib10: I/O decode 0x9000-0x9fff pcib10: memory decode 0xfc600000-0xfcbfffff pcib10: no prefetched decode pci10: on pcib10 pci10: domain=0, physical bus=10 found-> vendor=0x10b5, dev=0x8114, revid=0xbc domain=0, bus=10, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0157, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfcbfe000, size 13, enabled pcib10: allocated memory range (0xfcbfe000-0xfcbfffff) for rid 10 of pci0:10:0:0 pcib10: matched entry for 10.0.INTA pcib10: slot 0 INTA hardwired to IRQ 18 pcib11: mem 0xfcbfe000-0xfcbfffff irq 18 at device 0.0 on pci10 pcib10: allocated I/O port range (0x9000-0x9fff) for rid 1c of pcib11 pcib10: allocated memory range (0xfc600000-0xfcafffff) for rid 20 of pcib11 pcib11: domain 0 pcib11: secondary bus 11 pcib11: subordinate bus 11 pcib11: I/O decode 0x9000-0x9fff pcib11: memory decode 0xfc600000-0xfcafffff pcib11: no prefetched decode pci11: on pcib11 pci11: domain=0, physical bus=11 found-> vendor=0x1000, dev=0x0030, revid=0x08 domain=0, bus=11, slot=8, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x06 (1500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x9800, size 8, enabled pcib11: allocated I/O port range (0x9800-0x98ff) for rid 10 of pci0:11:8:0 map[14]: type Memory, range 64, base 0xfcae0000, size 17, enabled pcib11: allocated memory range (0xfcae0000-0xfcafffff) for rid 14 of pci0:11:8:0 map[1c]: type Memory, range 64, base 0xfcac0000, size 17, enabled pcib11: allocated memory range (0xfcac0000-0xfcadffff) for rid 1c of pci0:11:8:0 pcib10: matched entry for 10.0.INTA pcib10: slot 0 INTA hardwired to IRQ 18 pcib11: slot 8 INTA is routed to irq 18 found-> vendor=0x1000, dev=0x0030, revid=0x08 domain=0, bus=11, slot=8, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x06 (1500 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x9400, size 8, enabled pcib11: allocated I/O port range (0x9400-0x94ff) for rid 10 of pci0:11:8:1 map[14]: type Memory, range 64, base 0xfcaa0000, size 17, enabled pcib11: allocated memory range (0xfcaa0000-0xfcabffff) for rid 14 of pci0:11:8:1 map[1c]: type Memory, range 64, base 0xfca80000, size 17, enabled pcib11: allocated memory range (0xfca80000-0xfca9ffff) for rid 1c of pci0:11:8:1 pcib10: matched entry for 10.0.INTB pcib10: slot 0 INTB hardwired to IRQ 19 pcib11: slot 8 INTB is routed to irq 19 mpt3: port 0x9800-0x98ff mem 0xfcae0000-0xfcafffff,0xfcac0000-0xfcadffff irq 18 at device 8.0 on pci11 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 57 mpt3: MPI Version=1.2.14.0 mpt3: chain depth limited to 48 (from 2550) mpt3: Maximum Segment Count: 336, Maximum CAM Segment Count: 33 mpt3: MsgLength=15 IOCNumber = 0 mpt3: IOCFACTS: GlobalCredits=255 BlockSize=8 bytes Request Frame Size 96 bytes Max Chain Depth 48 mpt3: IOCFACTS: Num Ports 1, FWImageSize 40752, Flags=0 mpt3: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt3: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt4: port 0x9400-0x94ff mem 0xfcaa0000-0xfcabffff,0xfca80000-0xfca9ffff irq 19 at device 8.1 on pci11 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 58 mpt4: MPI Version=1.2.14.0 mpt4: chain depth limited to 48 (from 2550) mpt4: Maximum Segment Count: 336, Maximum CAM Segment Count: 33 mpt4: MsgLength=15 IOCNumber = 1 mpt4: IOCFACTS: GlobalCredits=255 BlockSize=8 bytes Request Frame Size 96 bytes Max Chain Depth 48 mpt4: IOCFACTS: Num Ports 1, FWImageSize 40752, Flags=0 mpt4: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt4: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pcib12: at device 7.0 on pci0 pcib12: domain 0 pcib12: secondary bus 12 pcib12: subordinate bus 12 pcib12: no prefetched decode pci12: on pcib12 pci12: domain=0, physical bus=12 pcib13: irq 17 at device 28.0 on pci0 pcib0: allocated type 4 (0xa000-0xafff) for rid 1c of pcib13 pcib0: allocated type 3 (0xfcc00000-0xfcdfffff) for rid 20 of pcib13 pcib13: domain 0 pcib13: secondary bus 13 pcib13: subordinate bus 13 pcib13: I/O decode 0xa000-0xafff pcib13: memory decode 0xfcc00000-0xfcdfffff pcib13: no prefetched decode pci13: on pcib13 pci13: domain=0, physical bus=13 found-> vendor=0x8086, dev=0x105e, revid=0x06 domain=0, bus=13, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfcde0000, size 17, enabled pcib13: allocated memory range (0xfcde0000-0xfcdfffff) for rid 10 of pci0:13:0:0 map[14]: type Memory, range 32, base 0xfcdc0000, size 17, enabled pcib13: allocated memory range (0xfcdc0000-0xfcddffff) for rid 14 of pci0:13:0:0 map[18]: type I/O Port, range 32, base 0xac00, size 5, enabled pcib13: allocated I/O port range (0xac00-0xac1f) for rid 18 of pci0:13:0:0 pcib13: matched entry for 13.0.INTA pcib13: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x105e, revid=0x06 domain=0, bus=13, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfcd80000, size 17, enabled pcib13: allocated memory range (0xfcd80000-0xfcd9ffff) for rid 10 of pci0:13:0:1 map[14]: type Memory, range 32, base 0xfcd60000, size 17, enabled pcib13: allocated memory range (0xfcd60000-0xfcd7ffff) for rid 14 of pci0:13:0:1 map[18]: type I/O Port, range 32, base 0xa800, size 5, enabled pcib13: allocated I/O port range (0xa800-0xa81f) for rid 18 of pci0:13:0:1 pcib13: matched entry for 13.0.INTB pcib13: slot 0 INTB hardwired to IRQ 17 em2: port 0xac00-0xac1f mem 0xfcde0000-0xfcdfffff,0xfcdc0000-0xfcddffff irq 16 at device 0.0 on pci13 em2: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 59 em2: using IRQ 259 for MSI em2: Using an MSI interrupt em2: bpf attached em2: Ethernet address: 00:1b:24:f0:7d:6e em3: port 0xa800-0xa81f mem 0xfcd80000-0xfcd9ffff,0xfcd60000-0xfcd7ffff irq 17 at device 0.1 on pci13 em3: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 260 to local APIC 0 vector 60 em3: using IRQ 260 for MSI em3: Using an MSI interrupt em3: bpf attached em3: Ethernet address: 00:1b:24:f0:7d:6f uhci0: port 0xd800-0xd81f irq 22 at device 29.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 61 uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: port 0xd400-0xd41f irq 23 at device 29.1 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 62 uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: port 0xd000-0xd01f irq 20 at device 29.2 on pci0 uhci2: LegSup = 0x2f00 usbus2 on uhci2 uhci3: port 0xcc00-0xcc1f irq 21 at device 29.3 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 63 uhci3: LegSup = 0x2f00 usbus3 on uhci3 ehci0: mem 0xfdfff800-0xfdfffbff irq 22 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib14: at device 30.0 on pci0 pcib0: allocated type 4 (0xb000-0xbfff) for rid 1c of pcib14 pcib0: allocated type 3 (0xfce00000-0xfdefffff) for rid 20 of pcib14 pcib14: domain 0 pcib14: secondary bus 14 pcib14: subordinate bus 14 pcib14: I/O decode 0xb000-0xbfff pcib14: memory decode 0xfce00000-0xfdefffff pcib14: no prefetched decode pcib14: Subtractively decoded bridge. pci14: on pcib14 pci14: domain=0, physical bus=14 found-> vendor=0x1a03, dev=0x2000, revid=0x00 domain=0, bus=14, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfd000000, size 23, enabled pcib14: allocated memory range (0xfd000000-0xfd7fffff) for rid 10 of pci0:14:5:0 map[14]: type Memory, range 32, base 0xfdee0000, size 17, enabled pcib14: allocated memory range (0xfdee0000-0xfdefffff) for rid 14 of pci0:14:5:0 map[18]: type I/O Port, range 32, base 0xbc00, size 7, enabled pcib14: allocated I/O port range (0xbc00-0xbc7f) for rid 18 of pci0:14:5:0 pcib14: matched entry for 14.5.INTA pcib14: slot 5 INTA hardwired to IRQ 16 vgapci0: port 0xbc00-0xbc7f mem 0xfd000000-0xfd7fffff,0xfdee0000-0xfdefffff irq 16 at device 5.0 on pci14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 31.1 on pci0 pcib0: allocated type 4 (0x1000-0x100f) for rid 20 of atapci0 atapci0: Lazy allocation of 0x10 bytes rid 0x20 type 4 at 0x1000 ata0: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 64 ahci0: port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc1f mem 0xfdfffc00-0xfdffffff irq 21 at device 31.2 on pci0 ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ ALP AL 3Gbps SSC PSC 32cmd 6ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: ahcich1: at channel 1 on ahci0 ahcich1: Caps: ahcich2: at channel 2 on ahci0 ahcich2: Caps: ahcich3: at channel 3 on ahci0 ahcich3: Caps: ahcich4: at channel 4 on ahci0 ahcich4: Caps: ahcich5: at channel 5 on ahci0 ahcich5: Caps: pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 65 uart1: fast interrupt uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 66 uart0: fast interrupt acpi0: wakeup code va 0xffffff8423240000 pa 0x90000 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd0800-0xd17ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 5 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 5 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 5 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 5 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 5 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 5 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 5 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 5 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 5 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 5 of orm0 isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc67ff,0xc6800-0xc77ff,0xc7800-0xc87ff,0xce800-0xcf7ff,0xd0800-0xd17ff on isa0 sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 pcib0: allocated type 4 (0x3d0-0x3db) for rid 0 of vga0 pcib0: allocated type 3 (0xb8000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbdc0: at port 0x60,0x64 on isa0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x410 Device configuration finished. procfs registered ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining pflog0: bpf attached lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 (noperiph:mpt0:0:-1:-1): reset bus ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered (noperiph:mpt1:0:-1:-1): reset bus (noperiph:mpt3:0:-1:-1): reset bus (noperiph:mpt4:0:-1:-1): reset bus ata0: reset tp1 mask=03 ostat0=7f ostat1=00 ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x0 ahcich0: AHCI reset... ahcich0: SATA connect timeout time=10000us status=00000000 ahcich0: AHCI reset: device not found ahcich1: AHCI reset... ahcich1: SATA connect timeout time=10000us status=00000000 ahcich1: AHCI reset: device not found ahcich2: AHCI reset... ahcich2: SATA connect timeout time=10000us status=00000000 ahcich2: AHCI reset: device not found ahcich3: AHCI reset... ahcich3: SATA connect timeout time=10000us status=00000000 ahcich3: AHCI reset: device not found ahcich4: AHCI reset... ahcich4: SATA connect timeout time=10000us status=00000000 ahcich4: AHCI reset: device not found ahcich5: AHCI reset... ahcich5: SATA connect timeout time=10000us status=00000000 ahcich5: AHCI reset: device not found uhub4: 8 ports with 8 removable, self powered GEOM: new disk da0 da8 at mpt3 bus 0 scbus4 target 0 lun 0 da8: Fixed Direct Access SCSI-3 device da8: Serial Number 091AD57C57DAA100 da8: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da8: Command Queueing enabled da8: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da9 at mpt3 bus 0 scbus4 target 0 lun 1 da9: Fixed Direct Access SCSI-3 device da9: Serial Number 091AD54757FFF800 da9: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da9: Command Queueing enabled da9: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da10 at mpt3 bus 0 scbus4 target 0 lun 2 da10: Fixed Direct Access SCSI-3 device da10: Serial Number 091AD568F2ABAD00 da10: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da10: Command Queueing enabled da10: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da11 at mpt3 bus 0 scbus4 target 0 lun 3 da11: Fixed Direct Access SCSI-3 device da11: Serial Number 091AD52AF8D1F900 da11: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da11: Command Queueing enabled da11: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da12 at mpt3 bus 0 scbus4 target 0 lun 4 da12: Fixed Direct Access SCSI-3 device da12: Serial Number 091AD561DFF19C00 da12: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da12: Command Queueing enabled da12: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da13 at mpt3 bus 0 scbus4 target 0 lun 5 da13: Fixed Direct Access SCSI-3 device da13: Serial Number 091AD56B4B606800 da13: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da13: Command Queueing enabled da13: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da14 at mpt3 bus 0 scbus4 target 0 lun 6 da14: Fixed Direct Access SCSI-3 device da14: Serial Number 091AD52B0A15DD00 da14: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da14: Command Queueing enabled da14: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da0 at mpt2 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number 0394G5TY 3NM4G5TY da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da2 at mpt2 bus 0 scbus2 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: Serial Number 11952BEZ 3NM52BEZ da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da3 at mpt2 bus 0 scbus2 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device da3: Serial Number 449814DD 3NM814DD da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da6 at mpt2 bus 0 scbus2 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: Serial Number 0794S0M2 3NM4S0M2 da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da1 at mpt2 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: Serial Number 0394F1BA 3NM4F1BA da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da5 at mpt2 bus 0 scbus2 target 5 lun 0 da5: Fixed Direct Access SCSI-5 device da5: Serial Number 0794RL0S 3NM4RL0S da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da7 at mpt2 bus 0 scbus2 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device da7: Serial Number 0794LMPR 3NM4LMPR da7: 300.000MB/s transfers da7: Command Queueing enabled da7: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da4 at mpt2 bus 0 scbus2 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: Serial Number 0794RZ5X 3NM4RZ5X da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) da15 at mpt3 bus 0 scbus4 target 0 lun 7 da15: Fixed Direct Access SCSI-3 device da15: Serial Number 091AD5233EE83300 da15: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da15: Command Queueing enabled da15: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da16 at mpt4 bus 0 scbus5 target 0 lun 0 da16: Fixed Direct Access SCSI-3 device da16: Serial Number 091AD574DA09BC00 da16: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da16: Command Queueing enabled da16: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da17 at mpt4 bus 0 scbus5 target 0 lun 1 da17: Fixed Direct Access SCSI-3 device da17: Serial Number 091AD576D9211500 da17: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da17: Command Queueing enabled da17: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da18 at mpt4 bus 0 scbus5 target 0 lun 2 da18: Fixed Direct Access SCSI-3 device da18: Serial Number 091AD54979445700 da18: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da18: Command Queueing enabled da18: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da19 at mpt4 bus 0 scbus5 target 0 lun 3 da19: Fixed Direct Access SCSI-3 device da19: Serial Number 091AD5726CD60500 da19: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da19: Command Queueing enabled da19: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da20 at mpt4 bus 0 scbus5 target 0 lun 4 da20: Fixed Direct Access SCSI-3 device da20: Serial Number 091AD56BEA6A1900 da20: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da20: Command Queueing enabled da20: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da21 at mpt4 bus 0 scbus5 target 0 lun 5 da21: Fixed Direct Access SCSI-3 device da21: Serial Number 091AD518015A3E00 da21: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da21: Command Queueing enabled da21: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da22 at mpt4 bus 0 scbus5 target 0 lun 6 da22: Fixed Direct Access SCSI-3 device da22: Serial Number 091AD54DCAB1D100 da22: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da22: Command Queueing enabled da22: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) da23 at mpt4 bus 0 scbus5 target 0 lun 7 da23: Fixed Direct Access SCSI-3 device da23: Serial Number 091AD56B5804EC00 da23: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) da23: Command Queueing enabled da23: 476679MB (976238592 512 byte sectors: 255H 63S/T 60768C) pass0 at mpt2 bus 0 scbus2 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number 0394G5TY 3NM4G5TY pass0: 300.000MB/s transfers pass0: Command Queueing enabled pass1 at mpt2 bus 0 scbus2 target 1 lun 0 pass1: Fixed Direct Access SCSI-5 device pass1: Serial Number 0394F1BA 3NM4F1BA pass1: 300.000MB/s transfers pass1: Command Queueing enabled pass2 at mpt2 bus 0 scbus2 target 2 lun 0 pass2: Fixed Direct Access SCSI-5 device pass2: Serial Number 11952BEZ 3NM52BEZ pass2: 300.000MB/s transfers pass2: Command Queueing enabled pass3 at mpt2 bus 0 scbus2 target 3 lun 0 pass3: Fixed Direct Access SCSI-5 device pass3: Serial Number 449814DD 3NM814DD pass3: 300.000MB/s transfers pass3: Command Queueing enabled pass4 at mpt2 bus 0 scbus2 target 4 lun 0 pass4: Fixed Direct Access SCSI-5 device pass4: Serial Number 0794RZ5X 3NM4RZ5X pass4: 300.000MB/s transfers pass4: Command Queueing enabled pass5 at mpt2 bus 0 scbus2 target 5 lun 0 pass5: Fixed Direct Access SCSI-5 device pass5: Serial Number 0794RL0S 3NM4RL0S pass5: 300.000MB/s transfers pass5: Command Queueing enabled pass6 at mpt2 bus 0 scbus2 target 6 lun 0 pass6: Fixed Direct Access SCSI-5 device pass6: Serial Number 0794S0M2 3NM4S0M2 pass6: 300.000MB/s transfers pass6: Command Queueing enabled pass7 at mpt2 bus 0 scbus2 target 7 lun 0 pass7: Fixed Direct Access SCSI-5 device pass7: Serial Number 0794LMPR 3NM4LMPR pass7: 300.000MB/s transfers pass7: Command Queueing enabled pass8 at mpt3 bus 0 scbus4 target 0 lun 0 pass8: Fixed Direct Access SCSI-3 device pass8: Serial Number 091AD57C57DAA100 pass8: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass8: Command Queueing enabled pass9 at mpt3 bus 0 scbus4 target 0 lun 1 pass9: Fixed Direct Access SCSI-3 device pass9: Serial Number 091AD54757FFF800 pass9: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass9: Command Queueing enabled pass10 at mpt3 bus 0 scbus4 target 0 lun 2 pass10: Fixed Direct Access SCSI-3 device pass10: Serial Number 091AD568F2ABAD00 pass10: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass10: Command Queueing enabled pass11 at mpt3 bus 0 scbus4 target 0 lun 3 pass11: Fixed Direct Access SCSI-3 device pass11: Serial Number 091AD52AF8D1F900 pass11: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass11: Command Queueing enabled pass12 at mpt3 bus 0 scbus4 target 0 lun 4 pass12: Fixed Direct Access SCSI-3 device pass12: Serial Number 091AD561DFF19C00 pass12: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass12: Command Queueing enabled pass13 at mpt3 bus 0 scbus4 target 0 lun 5 pass13: Fixed Direct Access SCSI-3 device pass13: Serial Number 091AD56B4B606800 pass13: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass13: Command Queueing enabled pass14 at mpt3 bus 0 scbus4 target 0 lun 6 pass14: Fixed Direct Access SCSI-3 device pass14: Serial Number 091AD52B0A15DD00 pass14: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass14: Command Queueing enabled pass15 at mpt3 bus 0 scbus4 target 0 lun 7 pass15: Fixed Direct Access SCSI-3 device pass15: Serial Number 091AD5233EE83300 pass15: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass15: Command Queueing enabled pass16 at mpt4 bus 0 scbus5 target 0 lun 0 pass16: Fixed Direct Access SCSI-3 device GEOM: new disk da1 GEOM: new disk da2 GEOM: new disk da3 GEOM: new disk da4 GEOM: new disk da5 GEOM: new disk da6 GEOM: new disk da7 GEOM: new disk da8 GEOM: new disk da9 GEOM: new disk da10 GEOM: new disk da11 GEOM: new disk da12 GEOM: new disk da13 GEOM: new disk da14 GEOM: new disk da15 GEOM: new disk da16 GEOM: new disk da17 GEOM: new disk da18 GEOM: new disk da19 GEOM: new disk da20 GEOM: new disk da21 GEOM: new disk da22 GEOM: new disk da23 pass16: Serial Number 091AD574DA09BC00 pass16: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass16: Command Queueing enabled pass17 at mpt4 bus 0 scbus5 target 0 lun 1 pass17: Fixed Direct Access SCSI-3 device pass17: Serial Number 091AD576D9211500 pass17: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass17: Command Queueing enabled pass18 at mpt4 bus 0 scbus5 target 0 lun 2 pass18: Fixed Direct Access SCSI-3 device pass18: Serial Number 091AD54979445700 pass18: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass18: Command Queueing enabled pass19 at mpt4 bus 0 scbus5 target 0 lun 3 pass19: Fixed Direct Access SCSI-3 device pass19: Serial Number 091AD5726CD60500 pass19: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass19: Command Queueing enabled pass20 at mpt4 bus 0 scbus5 target 0 lun 4 pass20: Fixed Direct Access SCSI-3 device pass20: Serial Number 091AD56BEA6A1900 pass20: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass20: Command Queueing enabled pass21 at mpt4 bus 0 scbus5 target 0 lun 5 pass21: Fixed Direct Access SCSI-3 device pass21: Serial Number 091AD518015A3E00 pass21: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass21: Command Queueing enabled pass22 at mpt4 bus 0 scbus5 target 0 lun 6 pass22: Fixed Direct Access SCSI-3 device pass22: Serial Number 091AD54DCAB1D100 pass22: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass22: Command Queueing enabled pass23 at mpt4 bus 0 scbus5 target 0 lun 7 pass23: Fixed Direct Access SCSI-3 device pass23: Serial Number 091AD56B5804EC00 pass23: 320.000MB/s transfers (160.000MHz, offset 127, 16bit) pass23: Command Queueing enabled SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 2 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 3 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 4 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 5 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 6 vector 48 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 7 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 2 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 4 vector 49 msi: Assigning MSI IRQ 256 to local APIC 5 vector 49 msi: Assigning MSI IRQ 257 to local APIC 6 vector 49 msi: Assigning MSI-X IRQ 258 to local APIC 7 vector 49 msi: Assigning MSI IRQ 260 to local APIC 1 vector 50 SMP: passed TSC synchronization test TSC timecounter discards lower 8 bit(s) Timecounter "TSC-low" frequency 9091986 Hz quality 1000 GEOM_MIRROR: Device mirror/swap launched (2/2). Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:13:0:-1: Attached to scbus13 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass24 at umass-sim0 bus 0 scbus13 target 0 lun 0 pass24: Removable CD-ROM SCSI-0 device pass24: 40.000MB/s transfers GEOM: new disk cd0 cd0 at umass-sim0 bus 0 scbus13 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open ugen4.3: at usbus4 uhub5: on usbus4 uhub5: MTT enabled Root mount waiting for: usbus4 uhub5: 4 ports with 4 removable, self powered Trying to mount root from zfs:rpool/ROOT/freebsd-ike2 []... ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ums0: on usbus1 start_init: trying /sbin/init [20] em0: Link is up 1000 Mbps Full Duplex [20] em0: link state changed to UP --reI/iBAAp9kzkmX4-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 19:40:53 2012 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DDD8106564A for ; Tue, 14 Aug 2012 19:40:53 +0000 (UTC) (envelope-from marcel.postleb@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 1B28D8FC0A for ; Tue, 14 Aug 2012 19:40:53 +0000 (UTC) Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout1.freenet.de with esmtpa (ID marcel.postleb@freenet.de) (port 25) (Exim 4.76 #1) id 1T1Myy-0003bx-1c for FreeBSD-stable@FreeBSD.org; Tue, 14 Aug 2012 21:40:52 +0200 Received: from localhost ([::1]:39575 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID marcel.postleb@freenet.de) (Exim 4.76 #1) id 1T1Myx-0000n0-Th for FreeBSD-stable@FreeBSD.org; Tue, 14 Aug 2012 21:40:52 +0200 Received: from [195.4.92.18] (port=38427 helo=8.mx.freenet.de) by mjail0.freenet.de with esmtpa (ID marcel.postleb@freenet.de) (Exim 4.76 #1) id 1T1MwK-0007Dm-RD for FreeBSD-stable@FreeBSD.org; Tue, 14 Aug 2012 21:38:08 +0200 Received: from stacr.webair.com ([67.55.68.196]:52224 helo=freenet.de) by 8.mx.freenet.de with esmtpa (ID marcel.postleb@freenet.de) (port 25) (Exim 4.76 #1) id 1T1MwK-0003lj-Jg for FreeBSD-stable@FreeBSD.org; Tue, 14 Aug 2012 21:38:08 +0200 Date: Tue, 14 Aug 2012 15:38:10 +0300 From: =?windows-1251?Q?=C8=ED=F7=E8=EA_=C2=E8=EA=E0=F8?= Organization: rcdmxsf X-Priority: 3 (Normal) Message-ID: <684947233.20120814153810@freenet.de> To: FreeBSD-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: Subject: =?windows-1251?b?5+Tg8O7i4Cwg7O7pIOfg//Y=?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Aug 2012 19:40:53 -0000 Õàþøêè òâîþ ýëåêòðîíêó ìíå ïîäñêàçàëà Ëèäêà.) åñëè ñêó÷àåøü è åñòü æåëàíèå ïîäðóæèòüñÿ, çàõîäü íà ìîþ ñòðàíèöó http://erovkontakt.ru From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 20:58:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCF09106564A for ; Tue, 14 Aug 2012 20:58:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 536D58FC12 for ; Tue, 14 Aug 2012 20:58:40 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so618615lbb.13 for ; Tue, 14 Aug 2012 13:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4VGpOHrI7ITerbAV5W1cpDMcm1Ugu6S7nHPnbfFWBVc=; b=VYiB6nlugNdY0dIYSa17NkcwhI8MlOO7yBBO3GNHClUM5Uv/7Kc9utAEKEEmV1ah/+ vBFB9pBrIcWLPsKe6cW8t3a41X6JRiypH9CgnkeelsoNIS64WYurmfcBMoWxEuenWa3T VTbqMMAbxQXRLJDTvFHMkvzq1p/rWIlfxF0MxnGAQST4lJtEcy6MX+yS2FGw1xWE9p6q 7zd940fSk2A2wiN+CPOSFtIx1eHfm/p39nvjwNK7RDU3kjHAXLgdg+56mzzX68wXQ5u6 Xbu9xP0QCSWjnOTOVrViSMjviPs1WBQAvPuJc0H1tgntWAgrjKOPHEFgrkhwEORqnfzo 9Sjw== Received: by 10.112.102.68 with SMTP id fm4mr3631450lbb.19.1344977919814; Tue, 14 Aug 2012 13:58:39 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (213-227-240-37.static.vega-ua.net. [213.227.240.37]) by mx.google.com with ESMTPS id nf5sm3299980lab.3.2012.08.14.13.58.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 13:58:38 -0700 (PDT) Sender: Alexander Motin Message-ID: <502ABBFC.9090602@FreeBSD.org> Date: Tue, 14 Aug 2012 23:58:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adam McDougall References: <4F9CCEF2.6050609@FreeBSD.org> <20120429155512.M91148@sola.nimnet.asn.au> <4F9CDE91.1060300@FreeBSD.org> <4F9D2F0C.4050501@FreeBSD.org> <20120429122714.GA56829@ravenloft.kiev.ua> <4F9D3DF8.9000800@FreeBSD.org> <20120429133056.GA58422@ravenloft.kiev.ua> <4F9D4491.2060007@FreeBSD.org> <20120814192540.GV68639@egr.msu.edu> In-Reply-To: <20120814192540.GV68639@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: High load event idl. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Aug 2012 20:58:41 -0000 On 14.08.2012 22:25, Adam McDougall wrote: > On Sun, Apr 29, 2012 at 04:39:29PM +0300, Alexander Motin wrote: > > On 04/29/12 16:30, Alex Kozlov wrote: > > On Sun, Apr 29, 2012 at 04:11:20PM +0300, Alexander Motin wrote: > >> On 04/29/12 15:27, Alex Kozlov wrote: > >>> On Sun, Apr 29, 2012 at 03:07:40PM +0300, Alexander Motin wrote: > >>>> On 04/29/12 15:04, Oliver Pinter wrote: > >>>>> Removing dummynet from kernel don't chanage anything, that is releated > >>>>> to load average. The loadavg hold to 0.70 +/- 0.2. (single user : sh + > >>>>> top) > >>>> > >>>> New ktr dump? > >>> I have similar issue on one of my laptops. Should I provide ktr dump? > >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027133.html > >> In your case HPET also shares interrupt with other devices. I suspect > >> that may be a reason. Every time when swi thread runs loadavg, other CPU > >> runs shared interrupt handler, that is accounted as result. Please show > >> your verbose dmesg. > > Attached. > > In your case HPET could solely use IRQ22 that seems free now. After > recent changes in ACPI code it is detected before PCI devices and so > doesn't avoids sharing. You may try to hint it specific IRQ by adding to > loader,conf line: > hint.hpet.0.allowed_irqs="0x00400000" > > -- > Alexander Motin > > I think I am having the same issue on my Sun Fire x4150 servers. It > goes away when I sysctl kern.eventtimer.timer=LAPIC but I'm hesitant to > use local workarounds in case they become pessimistic in the future. > I'm not sure all of my systems would have the same free irqs (including > after potential addition of expansion cards) so it might be a pain to > determine an appropriate allowed_irqs setting for each. I tried > hint.hpet.0.allowed_irqs="0x00000000" for the sake of experiment and > that just results in LAPIC being used since HPET is removed from > kern.eventtimer.choice. I've attached a verbose dmesg (will probably be > stripped from the list, hence the Cc:). > > Is there a limit to how high the irq can be set or could I perhaps set > it high enough that it is unlikely to conflict with other hardware? Is > there a chance we can find an automatic fix for this issue, or should I > just stick with LAPIC at the expense of whatever the HPET event timer > gets me? Or something else? I feel the partially random load average > level makes it difficult to measure a low load and can be misleading > during problem debugging. Thanks. HPET theoretically can use any IRQ from 0 to 31. Practically there could be different limitations. It is BIOS duty to tell us which IRQs are allowed to use. In your case IRQs 20-23 are allowed. Unluckily now system just gives to the HPET driver the first from the range. Problem with LAPIC timer is that it stops working when CPU goes to C3 or deeper idle state. These states are not enabled by default, so unless you enabled them explicitly, it is safe to use LAPIC. In any case present 9-STABLE system should prevent you from using unsafe C-state if LAPIC timer is used. From all other perspectives LAPIC is preferable, as it is faster and easier to operate then HPET. Latest CPUs fixed the LAPIC timer problem, so I don't think that switching to it will be pessimistic in foreseeable future. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 01:59:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A815106566C for ; Wed, 15 Aug 2012 01:59:06 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id C52DB8FC12 for ; Wed, 15 Aug 2012 01:59:05 +0000 (UTC) Received: from X220.ovitrap.com ([39.214.2.220]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q7F1wd6u026414; Tue, 14 Aug 2012 19:58:53 -0600 Date: Wed, 15 Aug 2012 08:58:35 +0700 From: Erich Dollansky To: Gareth de Vaux Message-ID: <20120815085835.1bf59738@X220.ovitrap.com> In-Reply-To: <20120814163437.GA47679@lordcow.org> References: <20120814163437.GA47679@lordcow.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: unrecognised external drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 01:59:06 -0000 Hi, On Tue, 14 Aug 2012 18:34:37 +0200 Gareth de Vaux wrote: > idVendor 0x1058 Western Digital Technologies, Inc. > idProduct 0x1042 could it be that the kernel does not know this product? You can check the sources (usbdevs should be the name of the file) and add this ID by copying an entry from another WD product which could be the same. This works some times but also can fail some time. Erich From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 08:36:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0A251065674 for ; Wed, 15 Aug 2012 08:36:15 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 92C088FC18 for ; Wed, 15 Aug 2012 08:36:15 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 17E45861AE for ; Wed, 15 Aug 2012 10:36:13 +0200 (CEST) Message-ID: <502B5F7D.6000909@bsdforen.de> Date: Wed, 15 Aug 2012 10:36:13 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 08:36:15 -0000 For a while now "acpiconf -i0" always shows the battery state that was correct when booting the system. It's never updated. It's not bothersome as long as I'm plugged in, but when I take my system out to the test track it's risky to sail blind. I only have a couple of seconds to shut down before the power runs out entirely when the power LED starts blinking. What am I running: FreeBSD mobileKamikaze.norad 9.0-STABLE FreeBSD 9.0-STABLE #1: Sat Jun 16 11:09:48 CEST 2012 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 amd64 Hardware: hw.model: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz This is an ICH8 based HP6510b. > kldstat -v|grep acpi 31 acpi/acpi_cmbat 46 acpi/acpi_timer 45 cpu/acpi_throttle 44 acpi/acpi_tz 37 pcib/acpi_pci 33 acpi/acpi_ec 43 acpi/acpi_smbat 42 acpi/acpi_sysresource 36 acpi/acpi_lid 35 acpi/acpi_isab 285 acpi/atdma 282 acpi/attimer 280 acpi/atrtc 30 acpi/acpi_button 138 acpi/ppc 265 acpi/psmcpnp 263 acpi/atkbdc 255 acpi/fpupnp 254 root/nexus_acpi 41 cpu/acpi_perf 34 acpi/hpet 40 pci/acpi_pcib 39 acpi/acpi_pcib 32 acpi/cpu 154 acpi/uart 28 nexus/acpi 29 acpi/acpi_acad 38 acpi/acpi_pci_link 15 1 0xffffffff80eea000 62f0 acpi_hp.ko (/boot/kernel/acpi_hp.ko) 15 acpi_wmi/acpi_hp 16 2 0xffffffff80ef1000 5da0 acpi_wmi.ko (/boot/kernel/acpi_wmi.ko) 14 acpi/acpi_wmi -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 08:40:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88682106566B for ; Wed, 15 Aug 2012 08:40:37 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4008FC08 for ; Wed, 15 Aug 2012 08:40:37 +0000 (UTC) Received: by obbun3 with SMTP id un3so2440479obb.13 for ; Wed, 15 Aug 2012 01:40:36 -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=Y1M3WazdCKAFslTSwIlioP31S9L+i2zFaoEcpwV+ahw=; b=G2we/udyW2iwymg9Eu9750VygoEPjoV38AznPpuuOin9Iav5NSIUHdJzAqi9yEKNKb /VsXlVd4WoWWIq9PGvyBM32ODzUE7988JNw+3mZMmpeKv1oDXmM7UpF5d9FU88RQQX79 CtT8ts3wW0xLtQ4AHP8d8zH5d3Kk2ikxyv9KuawD/1t6LN36x6LnaeoVFhSumHQ8fane mhR4QieyAHav0GpV3vFrLBNTU0Qrh2QyAF/Nms8UAneps4fGOUai0M91xB28NDl2hYxY MsjbK6DU50F0iS4oKFSW0xOxLyAKltNUIwK6tz0Ebq1v8KJQhX/hWq0VIqBfRRn0tSAI jQbQ== MIME-Version: 1.0 Received: by 10.60.29.3 with SMTP id f3mr715640oeh.91.1345020036808; Wed, 15 Aug 2012 01:40:36 -0700 (PDT) Received: by 10.60.16.4 with HTTP; Wed, 15 Aug 2012 01:40:36 -0700 (PDT) In-Reply-To: <502B5F7D.6000909@bsdforen.de> References: <502B5F7D.6000909@bsdforen.de> Date: Wed, 15 Aug 2012 10:40:36 +0200 Message-ID: From: Andreas Nilsson To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 08:40:37 -0000 On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey wrote: > For a while now "acpiconf -i0" always shows the battery state that > was correct when booting the system. It's never updated. > > snip It wont solve the problem, but does the sysctl hw.acpi.battery.time update correctly? Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 08:45:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 391BB1065674 for ; Wed, 15 Aug 2012 08:45:46 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id EB48B8FC17 for ; Wed, 15 Aug 2012 08:45:45 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id D81F985FBC; Wed, 15 Aug 2012 10:45:44 +0200 (CEST) Message-ID: <502B61B8.4040304@bsdforen.de> Date: Wed, 15 Aug 2012 10:45:44 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: Andreas Nilsson References: <502B5F7D.6000909@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 08:45:46 -0000 On 15/08/2012 10:40, Andreas Nilsson wrote: > On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey wrote: >> For a while now "acpiconf -i0" always shows the battery state that >> was correct when booting the system. It's never updated. >> >> snip > > It wont solve the problem, but does the sysctl hw.acpi.battery.time update > correctly? Thanks for the fast reply, right now it shows -1 (the system was plugged in during boot). I just unplugged it and it still shows -1: > sysctl hw.acpi.battery hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 09:07:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D0C8106566B for ; Wed, 15 Aug 2012 09:07:09 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 613E18FC16 for ; Wed, 15 Aug 2012 09:07:09 +0000 (UTC) Received: by obbun3 with SMTP id un3so2479638obb.13 for ; Wed, 15 Aug 2012 02:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cQO3NCIGDjm2KLu0UVUT/8TQBq9Wx29ybZexccPyWzg=; b=zTYSHB0doWXYBjP7iJ5XWoeL/hwMuJ+c19RbjGiVOnL/Hm38Al+fSFL6gLtU8HjqNO T9OyHFo6yV1KQ9yZiSecv7rHbqMZrFV7T4s9ruNH319k+qjGeSbfqyx/LaZwiTHifTED T6Cb5ylUi/Mmb3MbsU9jmx15paZ0+fb5eAHcR4dzqGGqIRpJtTUFmqnRGqIkp9Xpj4pv 2/v/1n9WwBePL62KXkueCSN1eUqhddijK5cilQQPc0rSI+e+GnmQZT1wYJ8ZiW8OkTjR 6uyW4Bkp3YsHRSCIgjqqEq1vmo/WXPko1EgsZZpnZ1H7tXLArlLBnhOWBoogVrI6ucYc z0iw== MIME-Version: 1.0 Received: by 10.60.29.169 with SMTP id l9mr791801oeh.14.1345021628842; Wed, 15 Aug 2012 02:07:08 -0700 (PDT) Received: by 10.60.16.4 with HTTP; Wed, 15 Aug 2012 02:07:08 -0700 (PDT) In-Reply-To: <502B61B8.4040304@bsdforen.de> References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> Date: Wed, 15 Aug 2012 11:07:08 +0200 Message-ID: From: Andreas Nilsson To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 09:07:09 -0000 On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey wrote: > On 15/08/2012 10:40, Andreas Nilsson wrote: > >> On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey > >wrote: >> >>> For a while now "acpiconf -i0" always shows the battery state that >>> was correct when booting the system. It's never updated. >>> >>> snip >>> >> >> It wont solve the problem, but does the sysctl hw.acpi.battery.time update >> correctly? >> > > Thanks for the fast reply, right now it shows -1 (the system was plugged > in during boot). > > I just unplugged it and it still shows -1: > >> sysctl hw.acpi.battery >> > hw.acpi.battery.life: 99 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 0 > hw.acpi.battery.units: 2 > hw.acpi.battery.info_expire: 5 > > > -- > 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 on usenet and in e-mail? > Sounds like there is some acpi-problem then. On my thinkpad it takes maybe five seconds for it to go from -1 to an estimate. Also hw.acpi.battery.state=0 for me equals "AC plugged in and battery full". I have this in my .xinitrc to monitor my battery ( in a loop which then uses xsetroot to show the info ): case `sysctl -n hw.acpi.battery.state` in 0) batstate="AC full" ;; 1) batstate="`sysctl -n hw.acpi.battery.time` m" ;; 2) batstate="AC charing" ;; Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 09:16:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 165FB106564A for ; Wed, 15 Aug 2012 09:16:44 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 82F908FC16 for ; Wed, 15 Aug 2012 09:16:43 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 96932403DF for ; Wed, 15 Aug 2012 11:16:41 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 89213403D7; Wed, 15 Aug 2012 11:16:41 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 03D33403E9; Wed, 15 Aug 2012 11:16:38 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3WxlRT6C0xz8gtM; Wed, 15 Aug 2012 11:16:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id IWFYog-n6ZLp; Wed, 15 Aug 2012 11:16:35 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3WxlRR4r8sz8gtL; Wed, 15 Aug 2012 11:16:35 +0200 (CEST) Received: from [IPv6:2001:470:dca9:1::4] (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3WxlRR3tT3z9Ctj; Wed, 15 Aug 2012 11:16:35 +0200 (CEST) Message-ID: <502B68EA.5040907@daemonic.se> Date: Wed, 15 Aug 2012 11:16:26 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Andreas Nilsson References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Dominic Fandrey , freebsd-stable@freebsd.org Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 09:16:44 -0000 On 2012-08-15 11:07, Andreas Nilsson wrote: > On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey wrote: >> On 15/08/2012 10:40, Andreas Nilsson wrote: >>> On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey >>> wrote: >>>> For a while now "acpiconf -i0" always shows the battery state that >>>> was correct when booting the system. It's never updated. >>>> >>> It wont solve the problem, but does the sysctl hw.acpi.battery.time update >>> correctly? >>> >> >> Thanks for the fast reply, right now it shows -1 (the system was plugged >> in during boot). >> >> I just unplugged it and it still shows -1: >> >>> sysctl hw.acpi.battery >>> >> hw.acpi.battery.life: 99 >> hw.acpi.battery.time: -1 >> hw.acpi.battery.state: 0 >> hw.acpi.battery.units: 2 >> hw.acpi.battery.info_expire: 5 > > Sounds like there is some acpi-problem then. On my thinkpad it takes maybe > five seconds for it to go from -1 to an estimate. Also > hw.acpi.battery.state=0 for me equals "AC plugged in and battery full". Just a short "aol". I'm seeing the same issue, also on a HP laptop, a HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact model). It has been this way for as long as I can remember (at least a year), but I haven't checked into the matter more closely. Are you running the latest current? I haven't updated in a while, so perhaps the issue has been resolved... Regards! -- Niclas From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 09:40:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9983E1065674 for ; Wed, 15 Aug 2012 09:40:28 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 5331F8FC15 for ; Wed, 15 Aug 2012 09:40:27 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 14ECB86187; Wed, 15 Aug 2012 11:40:26 +0200 (CEST) Message-ID: <502B6E8A.5080601@bsdforen.de> Date: Wed, 15 Aug 2012 11:40:26 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: Niclas Zeising References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> In-Reply-To: <502B68EA.5040907@daemonic.se> Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Andreas Nilsson Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 09:40:28 -0000 On 15/08/2012 11:16, Niclas Zeising wrote: > On 2012-08-15 11:07, Andreas Nilsson wrote: >> On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey wrote: >>> On 15/08/2012 10:40, Andreas Nilsson wrote: >>>> On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey >>>> wrote: >>>>> For a while now "acpiconf -i0" always shows the battery state that >>>>> was correct when booting the system. It's never updated. >>>>> >>>> It wont solve the problem, but does the sysctl hw.acpi.battery.time update >>>> correctly? >>>> >>> >>> Thanks for the fast reply, right now it shows -1 (the system was plugged >>> in during boot). >>> >>> I just unplugged it and it still shows -1: >>> >>>> sysctl hw.acpi.battery >>>> >>> hw.acpi.battery.life: 99 >>> hw.acpi.battery.time: -1 >>> hw.acpi.battery.state: 0 >>> hw.acpi.battery.units: 2 >>> hw.acpi.battery.info_expire: 5 >> >> Sounds like there is some acpi-problem then. On my thinkpad it takes maybe >> five seconds for it to go from -1 to an estimate. Also >> hw.acpi.battery.state=0 for me equals "AC plugged in and battery full". > > Just a short "aol". I'm seeing the same issue, also on a HP laptop, a > HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact > model). It has been this way for as long as I can remember (at least a > year), but I haven't checked into the matter more closely. There was a time when this actually worked for me. I should have reacted instantly when the problem came up, but I had a race car to build ... FSAE. > Are you > running the latest current? I haven't updated in a while, so perhaps > the issue has been resolved... Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 shortly before a 10.0 release. Regards -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 09:43:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDB89106566B for ; Wed, 15 Aug 2012 09:43:23 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 524448FC12 for ; Wed, 15 Aug 2012 09:43:23 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 94DFA86184; Wed, 15 Aug 2012 11:43:22 +0200 (CEST) Message-ID: <502B6F3A.9090207@bsdforen.de> Date: Wed, 15 Aug 2012 11:43:22 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: Andreas Nilsson References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 09:43:23 -0000 On 15/08/2012 11:07, Andreas Nilsson wrote: > On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey wrote: > >> On 15/08/2012 10:40, Andreas Nilsson wrote: >> >>> On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey >>> wrote: >>> >>>> For a while now "acpiconf -i0" always shows the battery state that >>>> was correct when booting the system. It's never updated. >>>> >>>> snip >>>> >>> >>> It wont solve the problem, but does the sysctl hw.acpi.battery.time update >>> correctly? >>> >> >> Thanks for the fast reply, right now it shows -1 (the system was plugged >> in during boot). >> >> I just unplugged it and it still shows -1: >> >>> sysctl hw.acpi.battery >>> >> hw.acpi.battery.life: 99 >> hw.acpi.battery.time: -1 >> hw.acpi.battery.state: 0 >> hw.acpi.battery.units: 2 >> hw.acpi.battery.info_expire: 5 >> > > Sounds like there is some acpi-problem then. On my thinkpad it takes maybe > five seconds for it to go from -1 to an estimate. You can tune this with hw.acpi.battery.info_expire. But 5 seconds sounds like an OKish value to me. > Also > hw.acpi.battery.state=0 for me equals "AC plugged in and battery full". That was the correct state while the system was booting. -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 17:05:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352F81065672 for ; Wed, 15 Aug 2012 17:05:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id E208E8FC08 for ; Wed, 15 Aug 2012 17:05:30 +0000 (UTC) Received: from zidane.cc.vt.edu (zidane.cc.vt.edu [198.82.163.227]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q7FGRoOA030794 for ; Wed, 15 Aug 2012 12:27:50 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by zidane.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id UEO92355; Wed, 15 Aug 2012 12:27:50 -0400 (EDT) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q7FGRoM9001256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Aug 2012 12:27:50 -0400 From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Aug 2012 12:27:49 -0400 Message-Id: <6DFEFF91-F9A9-4C64-8D1C-FB7A73BC7A2E@gromit.dlib.vt.edu> To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=zidane.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020207.502BCE06.0068,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: Subject: uhci0 excessive interrupts---how can I disable or reset specific USB port? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 17:05:31 -0000 I am running FreeBSD/amd64 9-STABLE (built Mon Jul 23 10:45:51 EDT 2012) = on a Dell Optiplex 760 and, today, noticed I had almost 30% system CPU = load in top even when the system was idle. A perusal of vmstat revealed = the cause to be excessive interrupts on uhci0, even though nothing was = plugged into that USB port: # vmstat -i interrupt total rate irq4: uart0 22 0 irq16: uhci0 617002282738 310969 irq23: uhci3 ehci1 83 0 irq256: hpet0:t0 135818421 68 irq257: hpet0:t1 2222659301 1120 irq264: em0 29529304 14 irq265: ahci0 11132506 5 Total 619401422375 312178 Because I am only using the front USB ports on that hardware, I thought = I would disable the other (rear) USB ports in the BIOS. I rebooted and = duly disabled them. However, when FreeBSD booted, it appeared to ignore = the BIOS setting: all the USB ports were probed as usual. (The high = interrupts had vanished, though that might have been due to FreeBSD = correctly shutting down the controllers at shutdown, or just the act of = rebooting itself.) I added "hint.uhci.0.disabled=3D1" to /boot/loader.conf (hoping it would = disable uhci0), but, again all the USB ports appeared in the boot = probes. (However, it *appears* as if uhci0 has been disabled because = the "irq16: uhci0" line no longer appears in "vmstat -i". However, all = the same ugen devices appear in /dev.) Is there a way of disabling a specific USB controller that you don't = want to use? If so, how? I looked at usbconfig, but that appears to me = to be more about controlling devices plugged in to a USB port rather = than the port itself. The "reset" command of usbconfig appears to be = about resetting USB devices, not ports. If I can't disable a specific USB port, is there a way to reset it = without rebooting? If I ever get another crazy interrupt storm like I = noticed today it would be nice to be able to stop it without having to = do a reboot. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 15 18:48:14 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02D58106564A; Wed, 15 Aug 2012 18:48:14 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id AF2838FC08; Wed, 15 Aug 2012 18:48:13 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1T1ifo-000L8B-Fl; Wed, 15 Aug 2012 22:50:32 +0400 Date: Wed, 15 Aug 2012 22:50:32 +0400 From: Slawa Olhovchenkov To: current@FreeBSD.org, stable@FreeBSD.org Message-ID: <20120815185032.GB88729@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Subject: ftpd reset restart position (REST) at any command X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Aug 2012 18:48:14 -0000 I try using mirror 2.9 (old, very old perl script) to mirror ftp site in passive mode and see don't working restart transfer: server ignored 'REST pos' command. This because in ftpcmd.y cleared restart_point: cmd_list : /* empty */ | cmd_list cmd { if (fromname) free(fromname); fromname = NULL; restart_point = 0; } | cmd_list rcmd ; (cmd is any command execept RNFR and REST) and mirror in passive mode used next command sequence: REST pos PASV RETR file RFC 3659 allow this, but not recomeded: "The server-PI may react to a badly positioned REST command by .... save the restart value and apply it to the next data transfer command ..." Why this case (save the restart value) is bad choice? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 05:40:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A9F106564A for ; Thu, 16 Aug 2012 05:40:31 +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 87E028FC0C for ; Thu, 16 Aug 2012 05:40:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q7G5dmnw074486; Thu, 16 Aug 2012 15:39:49 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Aug 2012 15:39:48 +1000 (EST) From: Ian Smith To: Dominic Fandrey In-Reply-To: <502B6E8A.5080601@bsdforen.de> Message-ID: <20120816150334.C93465@sola.nimnet.asn.au> References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> <502B6E8A.5080601@bsdforen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Niclas Zeising , freebsd-stable@freebsd.org, Andreas Nilsson Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 05:40:31 -0000 On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: > On 15/08/2012 11:16, Niclas Zeising wrote: > > On 2012-08-15 11:07, Andreas Nilsson wrote: > > > On Wed, Aug 15, 2012 at 10:45 AM, Dominic Fandrey > > > wrote: > > > > On 15/08/2012 10:40, Andreas Nilsson wrote: > > > > > On Wed, Aug 15, 2012 at 10:36 AM, Dominic Fandrey > > > > > > > > > > wrote: > > > > > > For a while now "acpiconf -i0" always shows the battery state that > > > > > > was correct when booting the system. It's never updated. > > > > > > > > > > > It wont solve the problem, but does the sysctl hw.acpi.battery.time > > > > > update > > > > > correctly? > > > > > > > > > > > > > Thanks for the fast reply, right now it shows -1 (the system was > > > > plugged > > > > in during boot). > > > > > > > > I just unplugged it and it still shows -1: > > > > > > > > > sysctl hw.acpi.battery > > > > > > > > > hw.acpi.battery.life: 99 > > > > hw.acpi.battery.time: -1 > > > > hw.acpi.battery.state: 0 > > > > hw.acpi.battery.units: 2 > > > > hw.acpi.battery.info_expire: 5 > > > > > > Sounds like there is some acpi-problem then. On my thinkpad it takes > > > maybe > > > five seconds for it to go from -1 to an estimate. Also > > > hw.acpi.battery.state=0 for me equals "AC plugged in and battery full". > > > > Just a short "aol". I'm seeing the same issue, also on a HP laptop, a > > HP 6910p with a Core2Duo 2.0GHz processor (can't remember the exact > > model). It has been this way for as long as I can remember (at least a > > year), but I haven't checked into the matter more closely. > > There was a time when this actually worked for me. I should have > reacted instantly when the problem came up, but I had a race car > to build ... FSAE. I found your correspondence here last December about that, "Re: battery display broken". Looks like it's still the same problem, you were on 9-stable then too. When did it used to work? On either normal or verbose boot messages, are there any ACPI errors logged? This smells a bit like some of the Embedded Controller issues that were coming up late 2010, most resolved by some patches by avg@. Someone then worked around some EC issue using debug.acpi.ec.polled mode rather than relying on notifications, I vaguely recall. You said then you run only one battery, so hw.acpi.battery.units is also still wrong? > > Are you > > running the latest current? I haven't updated in a while, so perhaps > > the issue has been resolved... > > Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 > shortly before a 10.0 release. If there's any indication of ACPI errors on boot (or later) this would be worthy of a PR, especially as you're not alone in this, on HP gear. I suppose you've checked HP for any more recent BIOS &/or EC updates? cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 08:24:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92267106566B for ; Thu, 16 Aug 2012 08:24:55 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4C69E8FC08 for ; Thu, 16 Aug 2012 08:24:54 +0000 (UTC) Received: from mobileKamikaze.norad (iz-aix-213a.HS-Karlsruhe.DE [193.196.64.213]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 7049C86187; Thu, 16 Aug 2012 10:24:46 +0200 (CEST) Message-ID: <502CAE4E.70402@bsdforen.de> Date: Thu, 16 Aug 2012 10:24:46 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: Ian Smith References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> <502B6E8A.5080601@bsdforen.de> <20120816150334.C93465@sola.nimnet.asn.au> In-Reply-To: <20120816150334.C93465@sola.nimnet.asn.au> Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Niclas Zeising , freebsd-stable@freebsd.org, Andreas Nilsson Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 08:24:55 -0000 On 16/08/2012 07:39, Ian Smith wrote: > On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: > ... > I found your correspondence here last December about that, "Re: battery > display broken". Looks like it's still the same problem, you were on > 9-stable then too. When did it used to work? Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had worked then, or I'd have PRed a regression. It stopped working around the beginning of this FSAE season. Probably between September and December. > On either normal or verbose boot messages, are there any ACPI errors > logged? This smells a bit like some of the Embedded Controller issues > that were coming up late 2010, most resolved by some patches by avg@. This is from the verbose dmesg: # dmesg | grep -i bat battery0: on acpi0 battery1: on acpi0 battery0: battery initialization start battery1: battery initialization start battery0: battery initialization done, tried 1 times battery1: battery initialization failed, giving up Looks right to me. Greping for acpi or fail doesn't yield anything interesting. There is a bunch of errors during shutdown, I have a dmesg with verbose boot, shutdown and normal boot prepared, for whoever wants to look at it. > Someone then worked around some EC issue using debug.acpi.ec.polled mode > rather than relying on notifications, I vaguely recall. You said then > you run only one battery, so hw.acpi.battery.units is also still wrong? Yes, it's wrong. There is an option to swap out the optical drive for a battery, I think. But I still have my optical drive. > > > Are you > > > running the latest current? I haven't updated in a while, so perhaps > > > the issue has been resolved... > > > > Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 > > shortly before a 10.0 release. > > If there's any indication of ACPI errors on boot (or later) this would > be worthy of a PR, especially as you're not alone in this, on HP gear. > I suppose you've checked HP for any more recent BIOS &/or EC updates? The bios version reported by dmidecode matches the latest download from HP: Vendor: Hewlett-Packard Version: 68DDU Ver. F.15 Release Date: 01/15/2009 Regards -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 09:38:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C692E106566B; Thu, 16 Aug 2012 09:38:56 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0FA8FC0C; Thu, 16 Aug 2012 09:38:55 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2947355vbm.13 for ; Thu, 16 Aug 2012 02:38:54 -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=QpozmDd/9I1kBL70H80WsirZO57IJxSMk4E/svELwws=; b=KvNwX+B4jbtq0E1qkexJ3chawtzPiP1wXjc9nyP31kIgSC0cHsUZHBbeUwOX3t/eua mJVcbQCZJzSrWr98KFDvYC6NyWjw/O/tSdCtr0MqCVGGwvBrndChzNLv7tbmuJt825bt 8EACv0H6XOm0hlyl1Bm0+kPBOMPj9QKcPyhkthmx0lEkF0rP3Ev0ztDyuO2itVcupJpz 3a0TY0pcQdwzjPoT6w1/wKoMzdQb7ZLk7j/dCqT6Osyksm/BHOGXU/1QEYA/CencoojD HTMUglPINDjQ3YReWL3i29ZpVRLHdgWQ7xF9pNZ56FUsIrjesE1jfDJEWfWXCL26EA/u 7V2g== MIME-Version: 1.0 Received: by 10.58.74.198 with SMTP id w6mr266700vev.22.1345109934407; Thu, 16 Aug 2012 02:38:54 -0700 (PDT) Received: by 10.220.157.8 with HTTP; Thu, 16 Aug 2012 02:38:54 -0700 (PDT) In-Reply-To: References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com> Date: Thu, 16 Aug 2012 12:38:54 +0300 Message-ID: From: George Kontostanos To: FreeBSD Stable , freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 09:38:56 -0000 After contacting the manufacturer we got this response: ------ My apologies for the wrong information provided in my previous email. I was under the impression that this OS is still supported but after checking with our developer, FreeBSD is currently not supported with the LSI Megaraid Cards due to some issue with the driver we've provided. It will be supported in our upcoming releases which may come by the end of this year. Please check back on our website during that time frame for the FreeBSD driver. Once again please accept my apologies for the inconvenience. ----- -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 10:41:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AC1106564A for ; Thu, 16 Aug 2012 10:41:49 +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 0708A8FC12 for ; Thu, 16 Aug 2012 10:41:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q7GAfWIa084548; Thu, 16 Aug 2012 20:41:33 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 16 Aug 2012 20:41:32 +1000 (EST) From: Ian Smith To: Dominic Fandrey In-Reply-To: <502CAE4E.70402@bsdforen.de> Message-ID: <20120816203444.F93465@sola.nimnet.asn.au> References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> <502B6E8A.5080601@bsdforen.de> <20120816150334.C93465@sola.nimnet.asn.au> <502CAE4E.70402@bsdforen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Niclas Zeising , freebsd-stable@freebsd.org, Andreas Nilsson Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 10:41:49 -0000 On Thu, 16 Aug 2012 10:24:46 +0200, Dominic Fandrey wrote: > On 16/08/2012 07:39, Ian Smith wrote: > > On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: > > ... > > I found your correspondence here last December about that, "Re: battery > > display broken". Looks like it's still the same problem, you were on > > 9-stable then too. When did it used to work? > > Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had > worked then, or I'd have PRed a regression. I was referring to this thread, which I then also had a stab at: http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064953.html > It stopped working around the beginning of this FSAE season. Probably > between September and December. > > > On either normal or verbose boot messages, are there any ACPI errors > > logged? This smells a bit like some of the Embedded Controller issues > > that were coming up late 2010, most resolved by some patches by avg@. > > This is from the verbose dmesg: > # dmesg | grep -i bat > battery0: on acpi0 > battery1: on acpi0 > battery0: battery initialization start > battery1: battery initialization start > battery0: battery initialization done, tried 1 times > battery1: battery initialization failed, giving up > > Looks right to me. Greping for acpi or fail doesn't yield anything > interesting. Ok. Several others reported things like: ACPI Error: Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc43284e0), AE_NO_HARDWARE_RESPONSE (20100915/psparse-633) acpi_ec0: EcRead: failed waiting to get data See also kern/162859 mentioned in the above thread, which seems similar. > There is a bunch of errors during shutdown, I have a dmesg with verbose > boot, shutdown and normal boot prepared, for whoever wants to look at it. If you take it any further, that might be handy .. > > Someone then worked around some EC issue using debug.acpi.ec.polled mode > > rather than relying on notifications, I vaguely recall. You said then > > you run only one battery, so hw.acpi.battery.units is also still wrong? > > Yes, it's wrong. There is an option to swap out the optical drive for a > battery, I think. But I still have my optical drive. Just more grist for the mill. My Thinkpad also can take another battery in the optical drive bay, but only shows one battery unless it's fitted. > > > > Are you > > > > running the latest current? I haven't updated in a while, so perhaps > > > > the issue has been resolved... > > > > > > Nay, I stick to the RELENG_ branches. I'll switch to RELENG_10 > > > shortly before a 10.0 release. > > > > If there's any indication of ACPI errors on boot (or later) this would > > be worthy of a PR, especially as you're not alone in this, on HP gear. > > I suppose you've checked HP for any more recent BIOS &/or EC updates? > > The bios version reported by dmidecode matches the latest download > from HP: > Vendor: Hewlett-Packard > Version: 68DDU Ver. F.15 > Release Date: 01/15/2009 Ah well, it was woth a shot :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 11:11:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAC6C106564A; Thu, 16 Aug 2012 11:11:06 +0000 (UTC) (envelope-from prvs=1575e57813=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 2D6298FC15; Thu, 16 Aug 2012 11:11:05 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Aug 2012 12:10:54 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50021276661.msg; Thu, 16 Aug 2012 12:10:52 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1575e57813=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> From: "Steven Hartland" To: "George Kontostanos" , "FreeBSD Stable" , References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com> Date: Thu, 16 Aug 2012 12:11:12 +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: Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 11:11:06 -0000 ----- Original Message ----- From: "George Kontostanos" To: "FreeBSD Stable" ; Sent: Thursday, August 16, 2012 10:38 AM Subject: Re: LSI 9240-4i 4K alignment > After contacting the manufacturer we got this response: > > ------ > My apologies for the wrong information provided in my previous email. > I was under the impression that this OS is still supported but after > checking with our developer, FreeBSD is currently not supported with > the LSI Megaraid Cards due to some issue with the driver we've > provided. It will be supported in our upcoming releases which may come > by the end of this year. Please check back on our website during that > time frame for the FreeBSD driver. > Once again please accept my apologies for the inconvenience. > ----- I would ask them if they have a fix, as if they do there's nothing stopping you building a custom kernel with the update. Its quite common for big companies to not "officially" support until a release but that doesn't mean they don't have a fix if you know what I mean :) In addition to this we're running LSI 2008 based controllers here on 8.2-RELEASE + manually merged in mps driver with ZFS just fine. They aren't running 4k aligned but they are working well. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 14:11:28 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E441F106566B for ; Thu, 16 Aug 2012 14:11:28 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 244548FC0A for ; Thu, 16 Aug 2012 14:11:27 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.5/8.14.5) with ESMTP id q7GEBEkU018916 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 16:11:14 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.5/8.14.5/Submit) id q7GEB87M018915; Thu, 16 Aug 2012 16:11:08 +0200 (SAST) (envelope-from lordcow) Date: Thu, 16 Aug 2012 16:11:08 +0200 From: Gareth de Vaux To: Erich Dollansky Message-ID: <20120816141108.GA18761@lordcow.org> Mail-Followup-To: Erich Dollansky , stable@freebsd.org References: <20120814163437.GA47679@lordcow.org> <20120815085835.1bf59738@X220.ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120815085835.1bf59738@X220.ovitrap.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lordcow.org Cc: stable@freebsd.org Subject: Re: unrecognised external drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 14:11:29 -0000 On Wed 2012-08-15 (08:58), Erich Dollansky wrote: > On Tue, 14 Aug 2012 18:34:37 +0200 > > idVendor 0x1058 Western Digital Technologies, Inc. > > idProduct 0x1042 > > could it be that the kernel does not know this product? > > You can check the sources (usbdevs should be the name of the file) and > add this ID by copying an entry from another WD product which could be > the same. Thanx, I changed product WESTERN EXTHDD 0x0400 External HDD to product WESTERN EXTHDD 0x1042 External HDD in usbdevs and rebuilt, but hasn't helped. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 15:36:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E9F1065672; Thu, 16 Aug 2012 15:36:37 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DEFE08FC17; Thu, 16 Aug 2012 15:36:36 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3324169vbm.13 for ; Thu, 16 Aug 2012 08:36:36 -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=+J5uX+1YowPhijShqRLzJr5ZHGHUUdCV3Z2DI3acPr8=; b=aD0wTpwAZ6Hz6+z3sN4JLdwX+D+7lJqykfNXrGOIguh+DFd0zb/e5p4JSTXau4YNAE 88g9cNyUtI2F9xs6xKxnhTNSbLffyBy4yy+IL74yyIYRKpe0fs99Oc3G3EcC8aBu0X4N c4695DFK71u+md2ozKM2aQH2kp9KlU1Q0+8VdFMoEoAhBRkd4Id/owwUSHNq5VDMcJME srcGQRroNs32kUM2Qtvm3hoTC9lJPoerS2wKIrQb4eWuFWHybNMpUfkK+5vO5VdhoCRo rBtpBD/vV3muPiIb0RfhufNqVEoCulvr2MvtOg4FrClYLosMg3yGQtEbck24JmwZpioX ycow== MIME-Version: 1.0 Received: by 10.52.65.171 with SMTP id y11mr592698vds.104.1345131396073; Thu, 16 Aug 2012 08:36:36 -0700 (PDT) Received: by 10.220.157.8 with HTTP; Thu, 16 Aug 2012 08:36:36 -0700 (PDT) In-Reply-To: <5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com> <5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> Date: Thu, 16 Aug 2012 18:36:36 +0300 Message-ID: From: George Kontostanos To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 15:36:37 -0000 On Thu, Aug 16, 2012 at 2:11 PM, Steven Hartland wrote: > ----- Original Message ----- From: "George Kontostanos" > > To: "FreeBSD Stable" ; > > Sent: Thursday, August 16, 2012 10:38 AM > Subject: Re: LSI 9240-4i 4K alignment > > > >> After contacting the manufacturer we got this response: >> >> ------ >> My apologies for the wrong information provided in my previous email. >> I was under the impression that this OS is still supported but after >> checking with our developer, FreeBSD is currently not supported with >> the LSI Megaraid Cards due to some issue with the driver we've >> provided. It will be supported in our upcoming releases which may come >> by the end of this year. Please check back on our website during that >> time frame for the FreeBSD driver. >> Once again please accept my apologies for the inconvenience. >> ----- > > > I would ask them if they have a fix, as if they do there's nothing > stopping you building a custom kernel with the update. You are right but it seems more cost effective to get a new controller that has support under the mps driver. > Its quite common for big companies to not "officially" support until a > release but that doesn't mean they don't have a fix if you know what I > mean :) I know. The problem with that controller is that for some reason it doesn't like gpart. I have gnoped the drives directly and it seems to be working so far. > In addition to this we're running LSI 2008 based controllers here on > 8.2-RELEASE + manually merged in mps driver with ZFS just fine. They > aren't running 4k aligned but they are working well. > Right, they fall under the mps driver like the following: LSI Logic SAS2004 (4 Port SAS) LSI Logic SAS2008 (8 Port SAS) LSI Logic SAS2108 (8 Port SAS) LSI Logic SAS2116 (16 Port SAS) LSI Logic SAS2208 (8 Port SAS) I have worked in the past with some of those and never had a problem. > Regards > Steve > Cheers -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 16:23:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81A0A1065686 for ; Thu, 16 Aug 2012 16:23:44 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id C3C068FC12 for ; Thu, 16 Aug 2012 16:23:43 +0000 (UTC) Received: from mobileKamikaze.norad (iz-aix-213a.HS-Karlsruhe.DE [193.196.64.213]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 586AB860DD; Thu, 16 Aug 2012 18:23:40 +0200 (CEST) Message-ID: <502D1E8C.7060406@bsdforen.de> Date: Thu, 16 Aug 2012 18:23:40 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120807 Thunderbird/14.0 MIME-Version: 1.0 To: Ian Smith References: <502B5F7D.6000909@bsdforen.de> <502B61B8.4040304@bsdforen.de> <502B68EA.5040907@daemonic.se> <502B6E8A.5080601@bsdforen.de> <20120816150334.C93465@sola.nimnet.asn.au> <502CAE4E.70402@bsdforen.de> <20120816203444.F93465@sola.nimnet.asn.au> In-Reply-To: <20120816203444.F93465@sola.nimnet.asn.au> Content-Type: text/plain; charset=ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Niclas Zeising , freebsd-stable@freebsd.org, Andreas Nilsson Subject: Re: battery state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 16:23:44 -0000 On 16/08/2012 12:41, Ian Smith wrote:> On Thu, 16 Aug 2012 10:24:46 +0200, Dominic Fandrey wrote: > > On 16/08/2012 07:39, Ian Smith wrote: > > > On Wed, 15 Aug 2012 11:40:26 +0200, Dominic Fandrey wrote: > > > ... > > > I found your correspondence here last December about that, "Re: battery > > > display broken". Looks like it's still the same problem, you were on > > > 9-stable then too. When did it used to work? > > > > Hmm, I switched to RELENG_9 shortly before the 9.0 release. It had > > worked then, or I'd have PRed a regression. > > I was referring to this thread, which I then also had a stab at: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064953.html That never progressed to a technical level so it only suffices to reduce the time frame. I don't remember any more. I know I'm made this more difficult by not having written a PR right when it happened. I appologize for this. I don't see what I can do to mitigate it, though. > > > It stopped working around the beginning of this FSAE season. Probably > > between September and December. > > > > > On either normal or verbose boot messages, are there any ACPI errors > > > logged? This smells a bit like some of the Embedded Controller issues > > > that were coming up late 2010, most resolved by some patches by avg@. > > > > This is from the verbose dmesg: > > # dmesg | grep -i bat > > battery0: on acpi0 > > battery1: on acpi0 > > battery0: battery initialization start > > battery1: battery initialization start > > battery0: battery initialization done, tried 1 times > > battery1: battery initialization failed, giving up > > > > Looks right to me. Greping for acpi or fail doesn't yield anything > > interesting. > > Ok. Several others reported things like: > ACPI Error: Method parse/execution failed [\\_SB_.BAT0._BST] (Node > 0xc43284e0), AE_NO_HARDWARE_RESPONSE (20100915/psparse-633) > acpi_ec0: EcRead: failed waiting to get data Nothing like this occurs. > See also kern/162859 mentioned in the above thread, which seems similar. It looks like it's exactly my problem. > > > There is a bunch of errors during shutdown, I have a dmesg with verbose > > boot, shutdown and normal boot prepared, for whoever wants to look at it. > > If you take it any further, that might be handy .. I just sent the dmesg to kern/162859. > > > Someone then worked around some EC issue using debug.acpi.ec.polled mode > > > rather than relying on notifications, I vaguely recall. ... I also tried that. It works exactly once. I.e. the system polls one new battery state. Which then becomes permanent. Turning it off and on repeatedly doesn't win me new states. Regards -- 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 on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 16:27:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA685106564A; Thu, 16 Aug 2012 16:27:13 +0000 (UTC) (envelope-from prvs=1575e57813=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 3A9D98FC15; Thu, 16 Aug 2012 16:27:12 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Aug 2012 17:26:16 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50021285099.msg; Thu, 16 Aug 2012 17:26:14 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1575e57813=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> From: "Steven Hartland" To: "George Kontostanos" References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com><5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> Date: Thu, 16 Aug 2012 17:26:35 +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 , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 16:27:14 -0000 ----- Original Message ----- From: "George Kontostanos" > > I know. The problem with that controller is that for some reason it > doesn't like gpart. I have gnoped the drives directly and it seems to > be working so far. It still really smells like something higher up the layers than the controller tbh. >> In addition to this we're running LSI 2008 based controllers here on >> 8.2-RELEASE + manually merged in mps driver with ZFS just fine. They >> aren't running 4k aligned but they are working well. >> > > Right, they fall under the mps driver like the following: > > LSI Logic SAS2004 (4 Port SAS) > LSI Logic SAS2008 (8 Port SAS) > LSI Logic SAS2108 (8 Port SAS) > LSI Logic SAS2116 (16 Port SAS) > LSI Logic SAS2208 (8 Port SAS) Confused as your 9240-4i is a SAS2008 based card so you "shouldnt" be seeing any difference as it should be supported just fine under mps. The cards we have here are 9211-8i if that helps. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 16:30:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E739D106564A for ; Thu, 16 Aug 2012 16:30:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79ED38FC14 for ; Thu, 16 Aug 2012 16:30:18 +0000 (UTC) Received: by weyx56 with SMTP id x56so2317169wey.13 for ; Thu, 16 Aug 2012 09:30:17 -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=XIx7n1CVQYyoU0E+6ETDUFcCSMNSa4bTBdLtPCy9OsM=; b=aMcg5XRVGLMlCAOgE+e+msmhP8UuCKCooLORyA7tEXG9dCqNp/P0mTgdb3+gv/ddSR gqdWIyaI0CUGfnkxrf5H3zwnSkjEc+RNidhly0iHuI4Xj3FkUdz7X6SDgb89y6Vh48TV 13BSop04oNUiWXvh4HPksMyXIY0ud3SN2AEa+/Vgp7Vq6lWJAbCx+s81qOHXPK7ZLbdl gFSlyb8F6yZEVpUMhO5fojVDY9Rci3CTM4JfiGlhfgbRt3T4gNWcOcA4I86QA8/yjbXO 2jthmEX2l2sWU+fYO/dzS6HC+15yqPwjcqntS3hon4lo3+EQKve2ghlNal3Z5aDHaNhy +L/A== MIME-Version: 1.0 Received: by 10.216.237.161 with SMTP id y33mr885543weq.62.1345134617269; Thu, 16 Aug 2012 09:30:17 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Thu, 16 Aug 2012 09:30:17 -0700 (PDT) Date: Thu, 16 Aug 2012 09:30:17 -0700 Message-ID: From: Kevin Oberman To: "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=UTF-8 Subject: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 16:30:19 -0000 I have a GPT formatted disk where I recently expanded the size of a partition. I used "gpart resize -i 6 ada1" first to expand the partition to use the remaining free space and then growfs to modify the FFS file system to use the full partition. This was all done in single-user mode, of course, but when I enter "exit" to bring the system up, it failed to mount /usr. This was because /dev/ufs/usr did not exist! I assumed that gpart "lost" the label when it resized the partition (which looked like a minor bug to me), but I have been completely unable to re-create the label. I first tried tunefs and then glabel. (The handbook says glabel can be used, though the glabel man page is explicit that it can't.) Both complete with no errors, but neither fixes the problem. I still don't see any /dev/usf/usr. "glabel list" does not even list the geom. I do get the following GEOM messages in dmesg: GEOM: ada1p2: invalid disklabel. GEOM: ufsid/4df4feeda0ce6d5c: invalid disklabel. GEOM: ufs/root: invalid disklabel. GEOM: gpt/root: invalid disklabel. GEOM: gptid/43f0eafd-ba3a-11e0-b70a-f0def166a11e: invalid disklabel. but /dev/ufs/root works fine to mount /, and I have always snen these errors and have never been able to figure out what is causing them. I ended up entering the actual drive node (/dev/ada1p6) into my fstab. This works, but brings back the old issues of having to edit the fstab any time the drive is moved. Does anyone have any idea how to get the labels to work again? I'm not even sure what tool displays what label as I can label with glabel, tunefs, and newfs -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 16:52:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DDC6106564A for ; Thu, 16 Aug 2012 16:52:42 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F40408FC0C for ; Thu, 16 Aug 2012 16:52:41 +0000 (UTC) Received: by obbun3 with SMTP id un3so5265964obb.13 for ; Thu, 16 Aug 2012 09:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OB99HKNuDWyBB/gILmtTqjQdpWxhG80DBKUy8aHVQpQ=; b=SpBARdC3MuyUZ2wfz5K/wpKntpAhhFCY6dluYOWVl6t1aTaVcMg4BaThgKqTdy6o9a QZwZGHwlI48VOuc62YPpd0h1A8bFDNkanlXAFQVdgk6LjA4eNeH1ZFFGLBwsQJ3WGPaE aY8jbIhGbjvoc6HtNMJW78yao9li21XwdC+CSNnjB+GfGxjyp2mNIXu8ReoDsOpJMc3W DXx1USK7u5r58dCFZC+RO2NclTydZsTMd8/Ogar0fqZGIlyVr32wM/sN+ehbgnVNChTm V2xm42Wui3ms/rrGoFPLp+o3+aPGLJXT9PCOC9zTAoZERyas2kbctyLZa9aEHyyxErvM vaxQ== MIME-Version: 1.0 Received: by 10.182.164.103 with SMTP id yp7mr1579346obb.26.1345135961244; Thu, 16 Aug 2012 09:52:41 -0700 (PDT) Received: by 10.76.101.212 with HTTP; Thu, 16 Aug 2012 09:52:41 -0700 (PDT) X-Originating-IP: [209.66.78.50] In-Reply-To: References: Date: Thu, 16 Aug 2012 12:52:41 -0400 Message-ID: From: Mark Saad To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkdqhwnXbTnKL6ypWuiPzcxKUzgmV1MOl8V6ZNGwYXLWG2wJ8Klm5AuY8hp8fFpelF+7XZP Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 16:52:42 -0000 On Thu, Aug 16, 2012 at 12:30 PM, Kevin Oberman wrote: > I have a GPT formatted disk where I recently expanded the size of a > partition. I used "gpart resize -i 6 ada1" first to expand the > partition to use the remaining free space and then growfs to modify > the FFS file system to use the full partition. This was all done in > single-user mode, of course, but when I enter "exit" to bring the > system up, it failed to mount /usr. This was because /dev/ufs/usr did > not exist! > > I assumed that gpart "lost" the label when it resized the partition > (which looked like a minor bug to me), but I have been completely > unable to re-create the label. I first tried tunefs and then glabel. > (The handbook says glabel can be used, though the glabel man page is > explicit that it can't.) Both complete with no errors, but neither > fixes the problem. I still don't see any /dev/usf/usr. "glabel list" > does not even list the geom. > > I do get the following GEOM messages in dmesg: > GEOM: ada1p2: invalid disklabel. > GEOM: ufsid/4df4feeda0ce6d5c: invalid disklabel. > GEOM: ufs/root: invalid disklabel. > GEOM: gpt/root: invalid disklabel. > GEOM: gptid/43f0eafd-ba3a-11e0-b70a-f0def166a11e: invalid disklabel. > > but /dev/ufs/root works fine to mount /, and I have always seen these > errors and have never been able to figure out what is causing them. > > I ended up entering the actual drive node (/dev/ada1p6) into my > fstab. This works, but brings back the old issues of having to edit > the fstab any time the drive is moved. > > Does anyone have any idea how to get the labels to work again? I'm not > even sure what tool displays what label as I can label with glabel, > tunefs, and newfs > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.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" Kevin I believe the UFS or geom_labels are stuck at the end of the partition so , I can see how it would wipe them out if you resized it. Can you run "glabel status" and "glabel list" send us the results ? -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 17:01:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74B7E106564A for ; Thu, 16 Aug 2012 17:01:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F24C48FC0C for ; Thu, 16 Aug 2012 17:01:03 +0000 (UTC) Received: by weyx56 with SMTP id x56so2340545wey.13 for ; Thu, 16 Aug 2012 10:01:03 -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=f5QrM8D4bmnR76lMituyrqhG8wln0duOIVDdOapWyMY=; b=rvLNnChA90YPG8LXqrSQScvsw4v0OwQCAx/jzFybSBtGz8aiknwjSgjQyuu90S+OYe L8yKFbGMxzcSeaivK4RWS6klbZ2Fp3PKS9hX6JZmz97IzvS63aw5kMVgol1WY78uHTzC Ue96KGemRrqzrPs8usns5hwhJyQkvVYUnH5vQQBUU7ysSX8yyFJgqWmU65oUtwTDBnAw RzLqAb5QTZ3aVNTN+vE0lT0uVIC6d1rjTBhVCy0Squ/Taf0FgCidtQMfhgeB/f8DRwNR yemiz36mko9IapMZ8lf5BB6FykQKTspIQtqQKbxDXwEXMup8LJadCN696BevNT0YUqQE hr6A== MIME-Version: 1.0 Received: by 10.180.78.170 with SMTP id c10mr7590319wix.3.1345136462906; Thu, 16 Aug 2012 10:01:02 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Thu, 16 Aug 2012 10:01:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Aug 2012 10:01:02 -0700 Message-ID: From: Kevin Oberman To: Mark Saad Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 17:01:04 -0000 On Thu, Aug 16, 2012 at 9:52 AM, Mark Saad wrote: > On Thu, Aug 16, 2012 at 12:30 PM, Kevin Oberman wrote: >> I have a GPT formatted disk where I recently expanded the size of a >> partition. I used "gpart resize -i 6 ada1" first to expand the >> partition to use the remaining free space and then growfs to modify >> the FFS file system to use the full partition. This was all done in >> single-user mode, of course, but when I enter "exit" to bring the >> system up, it failed to mount /usr. This was because /dev/ufs/usr did >> not exist! >> >> I assumed that gpart "lost" the label when it resized the partition >> (which looked like a minor bug to me), but I have been completely >> unable to re-create the label. I first tried tunefs and then glabel. >> (The handbook says glabel can be used, though the glabel man page is >> explicit that it can't.) Both complete with no errors, but neither >> fixes the problem. I still don't see any /dev/usf/usr. "glabel list" >> does not even list the geom. >> >> I do get the following GEOM messages in dmesg: >> GEOM: ada1p2: invalid disklabel. >> GEOM: ufsid/4df4feeda0ce6d5c: invalid disklabel. >> GEOM: ufs/root: invalid disklabel. >> GEOM: gpt/root: invalid disklabel. >> GEOM: gptid/43f0eafd-ba3a-11e0-b70a-f0def166a11e: invalid disklabel. >> >> but /dev/ufs/root works fine to mount /, and I have always seen these >> errors and have never been able to figure out what is causing them. >> >> I ended up entering the actual drive node (/dev/ada1p6) into my >> fstab. This works, but brings back the old issues of having to edit >> the fstab any time the drive is moved. >> >> Does anyone have any idea how to get the labels to work again? I'm not >> even sure what tool displays what label as I can label with glabel, >> tunefs, and newfs >> -- >> R. Kevin Oberman, Network Engineer >> E-mail: kob6558@gmail.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" > > Kevin > I believe the UFS or geom_labels are stuck at the end of the > partition so , I can see how it would wipe them out if you resized it. > Can you run "glabel status" and "glabel list" send us the results ? Mark, Thanks for looking at this. I assume that "gpart resize" would take care of moving the geom metadata to the new last sector of the geom, but glabel does not seem to know it is there at all: (The partition in question is ada1p6.) > glabel status Name Status Components ntfs/SYSTEM_DRV N/A ada0s1 ntfs/Windows7_OS N/A ada0s2 ntfs/Lenovo_Recovery N/A ada0s3 ntfs/Media N/A ada0s4 gptid/12c41a54-ba3a-11e0-b70a-f0def166a11e N/A ada1p1 ufs/root N/A ada1p2 ufs/var N/A ada1p4 ufs/tmp N/A ada1p5 gpt/Aux N/A ada1p7 gptid/aef508e9-bbbb-11e0-abd6-f0def166a11e N/A ada1p7 > glabel list Geom name: ada0s1 Providers: 1. Name: ntfs/SYSTEM_DRV Mediasize: 1258291200 (1.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 2457600 length: 1258291200 index: 0 Consumers: 1. Name: ada0s1 Mediasize: 1258291200 (1.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e2 Geom name: ada0s2 Providers: 1. Name: ntfs/Windows7_OS Mediasize: 113291296768 (105G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1259339776 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 221272064 length: 113291296768 index: 0 Consumers: 1. Name: ada0s2 Mediasize: 113291296768 (105G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1259339776 Mode: r1w1e2 Geom name: ada0s3 Providers: 1. Name: ntfs/Lenovo_Recovery Mediasize: 16777216000 (15G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2646605824 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 32768000 length: 16777216000 index: 0 Consumers: 1. Name: ada0s3 Mediasize: 16777216000 (15G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2646605824 Mode: r1w1e2 Geom name: ada0s4 Providers: 1. Name: ntfs/Media Mediasize: 188743629312 (175G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2881518592 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 368639901 length: 188743629312 index: 0 Consumers: 1. Name: ada0s4 Mediasize: 188743629312 (175G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2881518592 Mode: r1w1e2 Geom name: ada1p1 Providers: 1. Name: gptid/12c41a54-ba3a-11e0-b70a-f0def166a11e Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 128 length: 65536 index: 0 Consumers: 1. Name: ada1p1 Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 Geom name: ada1p2 Providers: 1. Name: ufs/root Mediasize: 1073741824 (1.0G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 2097152 length: 1073741824 index: 0 Consumers: 1. Name: ada1p2 Mediasize: 1073741824 (1.0G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 Geom name: ada1p4 Providers: 1. Name: ufs/var Mediasize: 5231345664 (4.9G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 10217472 length: 5231345664 index: 0 Consumers: 1. Name: ada1p4 Mediasize: 5231345664 (4.9G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 Geom name: ada1p5 Providers: 1. Name: ufs/tmp Mediasize: 536870912 (512M) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 1048576 length: 536870912 index: 0 Consumers: 1. Name: ada1p5 Mediasize: 536870912 (512M) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 Geom name: ada1p7 Providers: 1. Name: gpt/Aux Mediasize: 659313926144 (614G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 1287722512 length: 659313926144 index: 0 Consumers: 1. Name: ada1p7 Mediasize: 659313926144 (614G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 Geom name: ada1p7 Providers: 1. Name: gptid/aef508e9-bbbb-11e0-abd6-f0def166a11e Mediasize: 659313926144 (614G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 1287722512 length: 659313926144 index: 0 Consumers: 1. Name: ada1p7 Mediasize: 659313926144 (614G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 17:53:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7404106564A; Thu, 16 Aug 2012 17:53:26 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3348FC08; Thu, 16 Aug 2012 17:53:26 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3480806vbm.13 for ; Thu, 16 Aug 2012 10:53: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=9FOtEofFYRovLRInz0a+x464CkVSDZYDNhxGcqRXYko=; b=R5BVnhc4PSa8+lYk+jLUZoYPY2nosFTco+nKDfdGrGu2qpD123cZYwqFR+OTafDE8f KC0RcEipVVySBiuTNf+VNVdCrsgV1H8WIQaz9jC/7Um5LynmfmZbe9tBxTuxFDDRPNPJ tY/j27id5rz6ng8dZrf6Zn4qrl2NFJUAVsCpYDgqAKZByILO8flPhhJ1mryJbmdbFgJN yaby58W5NinDhZEfWHBrc8BALyCX6tKhbNUkVdUtJnBPdKl13jI4H0MYdWzDB5ub0MUF gWWcesKndXUn1wKJXuSJFNbGQE7uZUlZBh+QXpkuJk2k7D4YEX70XPcWNDTvCP6rQLOn z2Xw== MIME-Version: 1.0 Received: by 10.221.11.197 with SMTP id pf5mr969699vcb.29.1345139605552; Thu, 16 Aug 2012 10:53:25 -0700 (PDT) Received: by 10.220.157.8 with HTTP; Thu, 16 Aug 2012 10:53:25 -0700 (PDT) In-Reply-To: <00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com> <5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> <00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> Date: Thu, 16 Aug 2012 20:53:25 +0300 Message-ID: From: George Kontostanos To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 17:53:27 -0000 On Thu, Aug 16, 2012 at 7:26 PM, Steven Hartland wrote: > ----- Original Message ----- From: "George Kontostanos" > >> >> >> I know. The problem with that controller is that for some reason it >> doesn't like gpart. I have gnoped the drives directly and it seems to >> be working so far. > > It still really smells like something higher up the layers than the > controller tbh. We have tried many combinations with different drives. Any other suggestions? > >>> In addition to this we're running LSI 2008 based controllers here on >>> 8.2-RELEASE + manually merged in mps driver with ZFS just fine. They >>> aren't running 4k aligned but they are working well. >>> >> >> Right, they fall under the mps driver like the following: >> >> LSI Logic SAS2004 (4 Port SAS) >> LSI Logic SAS2008 (8 Port SAS) >> LSI Logic SAS2108 (8 Port SAS) >> LSI Logic SAS2116 (16 Port SAS) >> LSI Logic SAS2208 (8 Port SAS) > > > Confused as your 9240-4i is a SAS2008 based card so you "shouldnt" be > seeing any difference as it should be supported just fine under mps. > > The cards we have here are 9211-8i if that helps. You are right, the chip specs say: LSISAS2108 RAID-on-Chip The drives are identified as mfisyspd0, mfisyspd1, etc. > > 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. > -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 17:53:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9983210656EC for ; Thu, 16 Aug 2012 17:53:41 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2133D8FC14 for ; Thu, 16 Aug 2012 17:53:40 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2620471wgb.31 for ; Thu, 16 Aug 2012 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=AiZynRFV8Rq8DqFcBPD+gNlwwgXXZUaO8CzkIDXeSxs=; b=rR4SI6NjXC4U6klxi0fJVI0d/TWs3jeDSpH7aghwMUGE6aTVxt1IZ0rFP35I8H9ZoY X9lxUhHO1SfX+9lPwrO7iFaFIaOPXBu0rV4+//7ErSxN97gYFktp+yYEp1e7dAZo8ZFc 1qmw0zlPvTnhiJerPh4NrAiMv6JPm5e7IvFHgtv2j2WzJcCwChsO/k+rNtiYG9m6p755 v4duzoP9+QxRm2q6lNWkqIlvugwWiX4qE6plL3Obs2IY38Vgk05XKL17H0seMdEpJgPJ S+NcgLRqhMs8u+ZRX3b8KWXEbz/QkOIqGaR6mYp3pg/U4+CRSVydLDqyE30PAnl70dze vKLQ== Received: by 10.216.242.204 with SMTP id i54mr965177wer.94.1345139620087; Thu, 16 Aug 2012 10:53:40 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.223.153.200 with HTTP; Thu, 16 Aug 2012 10:53:19 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 16 Aug 2012 19:53:19 +0200 X-Google-Sender-Auth: v1bjoOlvJchIjLI5S6IABL71rOI Message-ID: To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 17:53:41 -0000 On Thu, Aug 16, 2012 at 6:30 PM, Kevin Oberman wrote: > I have a GPT formatted disk where I recently expanded the size of a > partition. I used "gpart resize -i 6 ada1" first to expand the > partition to use the remaining free space and then growfs to modify > the FFS file system to use the full partition. This was all done in > single-user mode, of course, but when I enter "exit" to bring the > system up, it failed to mount /usr. This was because /dev/ufs/usr did > not exist! I've met the same problem, check this PR for a dirty workaround: http://www.freebsd.org/cgi/query-pr.cgi?pr=165962 Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 18:45:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1661106566B; Thu, 16 Aug 2012 18:45:18 +0000 (UTC) (envelope-from prvs=1575e57813=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 3795C8FC14; Thu, 16 Aug 2012 18:45:17 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Aug 2012 19:45:08 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50021287705.msg; Thu, 16 Aug 2012 19:45:07 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1575e57813=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "George Kontostanos" References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com><5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk><00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> Date: Thu, 16 Aug 2012 19:45:28 +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 , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 18:45:19 -0000 ----- Original Message ----- From: "George Kontostanos" gkontos.mail@gmail.com >> It still really smells like something higher up the layers than the >> controller tbh. > > We have tried many combinations with different drives. Any other suggestions? See below >> Confused as your 9240-4i is a SAS2008 based card so you "shouldnt" be >> seeing any difference as it should be supported just fine under mps. >> >> The cards we have here are 9211-8i if that helps. > > You are right, the chip specs say: LSISAS2108 RAID-on-Chip Hmm LSI's website says its a LSISAS2008 not a LSISAS2108 http://www.lsi.com/channel/products/storagecomponents/Pages/MegaRAIDSAS9240-4i.aspx > The drives are identified as mfisyspd0, mfisyspd1, etc. Are you actually using HW RAID volumns then instead of direct disks? If so I would advice configuring the disks as passthrough. What does pciconf -lv say? On boot I see the following here to 2008 chip controller:- == /var/run/dmesg.boot == mps0: port 0xe000-0xe0ff mem 0xfaf3c000-0xfaf3ffff,0xfaf40000-0xfaf7ffff irq 26 at device 0.0 on pci7 mps0: Firmware: 11.00.00.00 mps0: IOCCapabilities: 185c mps0: [ITHREAD] == pciconf -lv == mps0@pci0:7:0:0: class=0x010700 card=0x30201000 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = SAS I suspect reading around that the MegaRAID cards are have SAS chips on board but are superseed by the RAID part hence mfi vs mps I wonder if you could flash with the IT firmware instead of IR to make it show as mps instead of mfi? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 18:51:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A665106564A; Thu, 16 Aug 2012 18:51:46 +0000 (UTC) (envelope-from prvs=1575e57813=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 B03078FC15; Thu, 16 Aug 2012 18:51:45 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Aug 2012 19:51:43 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50021287836.msg; Thu, 16 Aug 2012 19:51:38 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1575e57813=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <3711745674C24A98A4AE726EC6342721@multiplay.co.uk> From: "Steven Hartland" To: "George Kontostanos" References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com><5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk><00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> Date: Thu, 16 Aug 2012 19:51:59 +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 , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 18:51:46 -0000 ----- Original Message ----- From: "George Kontostanos" > You are right, the chip specs say: LSISAS2108 RAID-on-Chip > > The drives are identified as mfisyspd0, mfisyspd1, etc. The following might be interesting to you:- http://forums.servethehome.com/showthread.php?599-LSI-RAID-Controller-and-HBA-Complete-Listing-Plus-OEM-Models Which states:- LSI MegaRAID SAS 9240-4i 1x4 port internal SAS vertical, no cache, no BBU, RAID 0, 1, 10 and 5, can be crossflashed to LSI9211 IT/IR This is insteresting as this is the card we're using but in the 8 port version under mps :) So based on that a simple firmware flash may be all you need. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 20:02:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60C57106566C; Thu, 16 Aug 2012 20:02:35 +0000 (UTC) (envelope-from s-tlk@s-tlk.org) Received: from mail.s-tlk.org (s-tlk.org [178.63.70.119]) by mx1.freebsd.org (Postfix) with ESMTP id 20ACF8FC0A; Thu, 16 Aug 2012 20:02:34 +0000 (UTC) Received: from [10.0.3.6] (unknown [10.0.3.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.s-tlk.org (Postfix) with ESMTPSA id 0EFE3AE0F74; Thu, 16 Aug 2012 21:56:01 +0200 (CEST) Date: Thu, 16 Aug 2012 21:56:00 +0200 (CEST) From: Michael Schnell X-X-Sender: michi@priv.s-tlk.org To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-ports@freebsd.org Subject: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 20:02:35 -0000 Hi, I don't know if this came up already, but not as far as I know. So, I was thinking it would be nice to add a mechanism to pkgng, which enables the user to get the ports tree corresponding to the current repository. At least I've the problem that I really like the idea of the pkgng system, but I need a few custom build packages. For instance rawtherapee is not working for me with OpenMP, so I have to disable it to get it working, or I made some patches for openbox, which of course then needs to be compiled. In order to get not in conflict with a more recent ports tree the exact version of the repository build would be nice. At the moment I can think of two ways to implement it. The easiest way would be to add the ports tree as a packages into the repository. A more complicated thing is to add a mechanism to portsnap synchronised with the pkgng system to direct fetch it, or at least a revision number of the current repo, so you can check it out of the subversion. How do you guys feel about this? Greetings Michael From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 20:12:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45E951065674 for ; Thu, 16 Aug 2012 20:12:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7D48FC15 for ; Thu, 16 Aug 2012 20:12:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F065B95D for ; Thu, 16 Aug 2012 16:12:40 -0400 (EDT) From: John Baldwin To: stable@freebsd.org Date: Thu, 16 Aug 2012 16:11:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Message-Id: <201208161611.11357.jhb@freebsd.org> X-Length: 1810 X-UID: 27365 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 16 Aug 2012 16:12:40 -0400 (EDT) Cc: Subject: [PATCH] Make ida(4) MPSAFE and a host of other fixes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 20:12:42 -0000 ida(4) is a driver for older Compaq RAID adapters (PCI and EISA). It is one of the few remaining non-MPSAFE storage drivers. I have a patch to add locking to it, but while doing that I fixed several other issues including incorrect bus_dma support (it didn't handle deferred callbacks and EINPROGRESS at all). It also did not pre-allocate dma maps but attempted to create them on the fly (despite a comment claiming that it did pre-allocate them). It now probes disks using a configintrhook rather than using polled commands. The drive number for each logical disk is passed to the child disk device via ivars. I've added bus_dma sync ops for the hardware QCB accesses. I've also reworked it's queuing mechanism so that it should now queue multiple commands to the controller (before it only queued one command at a time even though it had free QCBs). The patch compiles, but I have no hardware to test it. Given that this is an old driver, if I can't find anyone to test it, I will remove it from HEAD after committing the fixes (so if someone shows up in the future there is a better base to start from). http://www.FreeBSD.org/~jhb/patches/ida_locking_dma.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 20:12:42 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA3F1065677 for ; Thu, 16 Aug 2012 20:12:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A40468FC16 for ; Thu, 16 Aug 2012 20:12:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D636BB95E for ; Thu, 16 Aug 2012 16:12:40 -0400 (EDT) From: John Baldwin To: stable@freebsd.org Date: Thu, 16 Aug 2012 16:12:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Message-Id: <201208161612.37290.jhb@freebsd.org> X-Length: 939 X-UID: 27390 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 16 Aug 2012 16:12:40 -0400 (EDT) Cc: Subject: [PATCH] Add locking to mlx(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 20:12:42 -0000 I have patches to add locking to mlx(4) and mark it MPSAFE. The patches are from HEAD but should apply to 8 or 9. If you test it on 8 or 9 please enable INVARIANTS for at least the initial testing. Thanks. Given that this is a driver for older hardware, if no one is able to test these patches, then I will remove the driver from HEAD after committing these fixes. http://www.FreeBSD.org/~jhb/patches/mlx_locking.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 20:24:17 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F124106566B for ; Thu, 16 Aug 2012 20:24:17 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3648FC16 for ; Thu, 16 Aug 2012 20:24:16 +0000 (UTC) Received: from seedling.local (host86-180-66-20.range86-180.btcentralplus.com [86.180.66.20]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q7GKOC9j079851 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 21:24:12 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q7GKOC9j079851 Authentication-Results: smtp.infracaninophile.co.uk/q7GKOC9j079851; dkim=none (no signature); dkim-adsp=none X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host host86-180-66-20.range86-180.btcentralplus.com [86.180.66.20] claimed to be seedling.local Message-ID: <502D56E4.2080705@FreeBSD.org> Date: Thu, 16 Aug 2012 21:24:04 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FC7886DD4A652E2CFD96DD1" X-Virus-Scanned: clamav-milter 0.97.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 20:24:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FC7886DD4A652E2CFD96DD1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16/08/2012 20:56, Michael Schnell wrote: > Hi, > I don't know if this came up already, but not as far as I know. So, I > was thinking it would be nice to add a mechanism to pkgng, which enable= s > the user to get the ports tree corresponding to the current repository.= >=20 > At least I've the problem that I really like the idea of the pkgng > system, but I need a few custom build packages. For instance rawtherape= e > is not working for me with OpenMP, so I have to disable it to get it > working, or I made some patches for openbox, which of course then needs= > to be compiled. In order to get not in conflict with a more recent > ports tree the exact version of the repository build would be nice. >=20 > At the moment I can think of two ways to implement it. The easiest way > would be to add the ports tree as a packages into the repository. A mor= e > complicated thing is to add a mechanism to portsnap synchronised with > the pkgng system to direct fetch it, or at least a revision number of > the current repo, so you can check it out of the subversion. >=20 > How do you guys feel about this? Could you open an issue on github please? [*] https://github.com/pkgng/pkgng/issues?state=3Dopen Adding a package with a complete ports tree is an ... interesting ... idea. Maybe doable --- but it would be a huge package. Adding some metadata to the repo catalogue to show eg. the SVN revision number of the ports tree used to generate the packages would be a pretty reasonable approach. However, one of the development aims for pkgng is to make it much easier for people to maintain their own packages of the particular software that is important to them, but be able to use a regular public repository for pretty much anything else. That implies being able to handle a mix of packages compiled from different ports trees much better than is the case at the moment. If we get that right, keeping ports trees in precise synch as you describe shouldn't be any great issue. Cheers, Matthew [*] A pull request with patches would be even better, but we're glad of any good ideas. --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig8FC7886DD4A652E2CFD96DD1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAtVusACgkQ8Mjk52CukIzoYACfWXwnsHcVnKVuuOC4KsBPIvk0 QC4An2XnylNWadvzcTHffsevaIDocBPz =RshU -----END PGP SIGNATURE----- --------------enig8FC7886DD4A652E2CFD96DD1-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 20:57:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1D2F106566C for ; Thu, 16 Aug 2012 20:57:00 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 176898FC0A for ; Thu, 16 Aug 2012 20:56:59 +0000 (UTC) Received: by ghrr13 with SMTP id r13so4185162ghr.13 for ; Thu, 16 Aug 2012 13:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=luNeXi6a/9l9AGcId7DJKwdYCgzORxKtJO3cKq76fO8=; b=TkxkDAVS0H2TPhhkVWiijAJoXM6M6ZDXwylCN0q82SaNuRFXkyei0chqiOU7EaD8pl ZuNsVlHRCojOWjjBJKm+xv8PuGPgk7l/M121oPRwlZ4DNdPQml6h+woh9sOcSmggQx1D bknCK+Iqvc5fFNjxN51C/K5GlXCiSqyLDUfPCuRyUF/figs48749CJHQqx7UzmzGAC89 R9SSbiWMctmpVeIou960FZF+rwH9EdgCgehgISZXmQzj+uKT3qr9CEz2A+0mQ7LGTDzE fEURC66n8O1Dhd5+0cMPVZ20fpY5y0bNDQIdQHs/DE4aSJtaUda85mMjx6mubmO1BR9i i+VA== Received: by 10.50.186.196 with SMTP id fm4mr3281781igc.1.1345150619343; Thu, 16 Aug 2012 13:56:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.145.101 with HTTP; Thu, 16 Aug 2012 13:56:39 -0700 (PDT) From: Gabor Radnai Date: Thu, 16 Aug 2012 22:56:39 +0200 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GEOM_RAID in GENERIC 9.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 20:57:01 -0000 Hi, Unfortunately I am a less experienced user so no clue how to disable GEOM_RAID but i am hit by this issue. My zfs setup is totally messed up. Would appreciate if you could share the trick. Thanks in advance. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 21:59:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A6E106564A; Thu, 16 Aug 2012 21:59:29 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52B4D8FC17; Thu, 16 Aug 2012 21:59:29 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so3643781vcb.13 for ; Thu, 16 Aug 2012 14:59:28 -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=i15GE3V0SUnY8as4AOFCmYFOAXhYTIXcvu33alGpSjM=; b=wqal/6EpQ9wdedY/g76dJqsbW/BezhhDB/sRPer2FFthryanW58UiuQpy7Nweug+/f XytbqUqMqs27SQrKdxQAilRpT9IKXTH1a6dp6VZiIsNEX5SJXr+A+mI8G9ZhNu20XyF7 qxumwBh3YDyoYXky1g0yJX3gF71Q7hz42SfBpRR4YraWtjTjzt8VOlOsOrrDGg/n0Lx7 31UdVH9IIMO1Yxxov+RRsEvuvM8iO5CqVNFr6ZvMvCLgAoPJcuVYPtFG2CYipJ7pSe4I PzmqBOD9K8pVm5SqBDSHj3qFl5079/sd+eAqiaUzOiiVSvW20+y40UYHYaRBhTMMaHXh jRag== MIME-Version: 1.0 Received: by 10.52.24.9 with SMTP id q9mr1072275vdf.22.1345154368413; Thu, 16 Aug 2012 14:59:28 -0700 (PDT) Received: by 10.220.157.8 with HTTP; Thu, 16 Aug 2012 14:59:28 -0700 (PDT) In-Reply-To: <3711745674C24A98A4AE726EC6342721@multiplay.co.uk> References: <50E70CD3-2D8A-4B49-8BB1-381FB6779A71@transactionware.com> <5433111728EF4748A35DB4ED19E10CD2@multiplay.co.uk> <00BFCA9D569640E08E243CCBC61CF287@multiplay.co.uk> <3711745674C24A98A4AE726EC6342721@multiplay.co.uk> Date: Fri, 17 Aug 2012 00:59:28 +0300 Message-ID: From: George Kontostanos To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , freebsd-hardware@freebsd.org Subject: Re: LSI 9240-4i 4K alignment X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 21:59:29 -0000 On Thu, Aug 16, 2012 at 9:51 PM, Steven Hartland wrote: > ----- Original Message ----- From: "George Kontostanos" > > >> You are right, the chip specs say: LSISAS2108 RAID-on-Chip >> >> The drives are identified as mfisyspd0, mfisyspd1, etc. > > > The following might be interesting to you:- > http://forums.servethehome.com/showthread.php?599-LSI-RAID-Controller-and-HBA-Complete-Listing-Plus-OEM-Models > > Which states:- > LSI MegaRAID SAS 9240-4i 1x4 port internal SAS vertical, > no cache, no BBU, RAID 0, 1, 10 and 5, can be crossflashed > to LSI9211 IT/IR > > This is insteresting as this is the card we're using but > in the 8 port version under mps :) > > So based on that a simple firmware flash may be all you > need. > > > 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. > mfi0@pci0:1:0:0: class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 9240' class = mass storage subclass = RAID The controller is configured as jbod. I will follow your advice regarding the firmware. Thanks for your help! -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 22:07:19 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA421065672; Thu, 16 Aug 2012 22:07:19 +0000 (UTC) (envelope-from s-tlk@s-tlk.org) Received: from mail.s-tlk.org (s-tlk.org [178.63.70.119]) by mx1.freebsd.org (Postfix) with ESMTP id 17D5F8FC0C; Thu, 16 Aug 2012 22:07:18 +0000 (UTC) Received: from [10.0.3.6] (unknown [10.0.3.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.s-tlk.org (Postfix) with ESMTPSA id 232B3AE0F74; Fri, 17 Aug 2012 00:07:17 +0200 (CEST) Date: Fri, 17 Aug 2012 00:07:17 +0200 (CEST) From: Michael Schnell X-X-Sender: michi@priv.s-tlk.org To: Matthew Seaman In-Reply-To: <502D56E4.2080705@FreeBSD.org> Message-ID: References: <502D56E4.2080705@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@FreeBSD.org Subject: Re: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 22:07:19 -0000 On Thu, 16 Aug 2012, Matthew Seaman wrote: > On 16/08/2012 20:56, Michael Schnell wrote: >> Hi, >> I don't know if this came up already, but not as far as I know. So, I >> was thinking it would be nice to add a mechanism to pkgng, which enables >> the user to get the ports tree corresponding to the current repository. >> >> At least I've the problem that I really like the idea of the pkgng >> system, but I need a few custom build packages. For instance rawtherapee >> is not working for me with OpenMP, so I have to disable it to get it >> working, or I made some patches for openbox, which of course then needs >> to be compiled. In order to get not in conflict with a more recent >> ports tree the exact version of the repository build would be nice. >> >> At the moment I can think of two ways to implement it. The easiest way >> would be to add the ports tree as a packages into the repository. A more >> complicated thing is to add a mechanism to portsnap synchronised with >> the pkgng system to direct fetch it, or at least a revision number of >> the current repo, so you can check it out of the subversion. >> >> How do you guys feel about this? > > Could you open an issue on github please? [*] > > https://github.com/pkgng/pkgng/issues?state=open Okay done. Unfortunately I don't have a test system yet, then I would have tried to test some of the ideas. At the moment I'm just evaluating pkg. > Adding a package with a complete ports tree is an ... interesting ... > idea. Maybe doable --- but it would be a huge package. Adding some > metadata to the repo catalogue to show eg. the SVN revision number of > the ports tree used to generate the packages would be a pretty > reasonable approach. I don't think it will be so large, when you look at the size of the compressed tar balls coming with portsnap. ;-) Something around 65 MiB if I remember correctly? > However, one of the development aims for pkgng is to make it much easier > for people to maintain their own packages of the particular software > that is important to them, but be able to use a regular public > repository for pretty much anything else. That implies being able to > handle a mix of packages compiled from different ports trees much better > than is the case at the moment. If we get that right, keeping ports > trees in precise synch as you describe shouldn't be any great issue. That was my idea. Otherwise I have to guess the revision, or check out the ports tree quickly after an upgrade of the packages and still I had some mismatch there. Greetings Michael From owner-freebsd-stable@FreeBSD.ORG Thu Aug 16 22:11:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98860106566B for ; Thu, 16 Aug 2012 22:11:49 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2476F8FC0A for ; Thu, 16 Aug 2012 22:11:48 +0000 (UTC) Received: by weyx56 with SMTP id x56so2549819wey.13 for ; Thu, 16 Aug 2012 15:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=STFt044i6JKGcuxiUKxLfwlTQkSZsbUbouE2VsEGiwo=; b=E+OiFuqHyrvYTW2eiyVkhVj9vO+VCps8ZX6IOykO+dLwIANApvvPuF/PZdjPWtBM9S hjFdCC5WmLvELeP/Un/gddQK34af+XexpA/ROPCERhOdHisXYlFufHQDU7Tw+fW/OoQh CL559LoncTPcCkDFW30xy+ZsV2WwBoRYKwRhYhjk558qCfHAnTiAC/tllNO0hhTbATg8 FN3Hvn1gg5oBUu+NKCkLEsa8G9i5d0v2NLkrIOBdJHefx5kIpY59eMh1akD9iBVNNLfd A0ivZb8te0r+cj5540jGvncoK0rSzUb3kb/+5zMehj0cNCUSffdnMujs2Oi+5bW2+Klk bNVg== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr9384387wiy.20.1345155107868; Thu, 16 Aug 2012 15:11:47 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Thu, 16 Aug 2012 15:11:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Aug 2012 15:11:47 -0700 Message-ID: From: Kevin Oberman To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Aug 2012 22:11:49 -0000 On Thu, Aug 16, 2012 at 10:53 AM, Olivier Cochard-Labb=C3=A9 wrote: > On Thu, Aug 16, 2012 at 6:30 PM, Kevin Oberman wrote: >> I have a GPT formatted disk where I recently expanded the size of a >> partition. I used "gpart resize -i 6 ada1" first to expand the >> partition to use the remaining free space and then growfs to modify >> the FFS file system to use the full partition. This was all done in >> single-user mode, of course, but when I enter "exit" to bring the >> system up, it failed to mount /usr. This was because /dev/ufs/usr did >> not exist! > > I've met the same problem, check this PR for a dirty workaround: Yep. It is certainly a dirty fix, but it should work. Looks like glabel is doing the right thing, though a message would have been nice. Rebuilding now. Thanks so much! --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 03:25:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52052106566B; Fri, 17 Aug 2012 03:25:38 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED1C18FC12; Fri, 17 Aug 2012 03:25:37 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3458803qcs.13 for ; Thu, 16 Aug 2012 20:25:37 -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=g+aiJk7rPfwXX9yGlYYoUeg7EHEPMKeQv2D9m1H0H9w=; b=q2gdbkk7WNeYHU39u1cLsitRLIcvtjUOtlbZEOC/d8MNzg0ttiOBmjFKpumG8hPsSi apJqTJYlsXCC2f5shqBAaXXXK8ZZ0m6IgBr6ZAv7dZ4CGcuC70qGCAx6NQw2tINgAMo8 lV1qEeF4S8wGTfKR6KOK9lBVdzr0nUn1i1SOZM4L0B1FV625j7hOsI8q30n1ZqvhHzme 27fvqflw1k6htophjCWbXJolx5ksYbx5CKAi+HI+IatPin+5o2upcSqrkHUAFGZJOY3n 7MM0Z0lZATiWKyCOgJDR0tUc2ePbmuIiCQaLQMCA4tCX2vXBrLzZUKF1dLWsTeQpSAf6 DPMw== MIME-Version: 1.0 Received: by 10.229.135.21 with SMTP id l21mr2539998qct.7.1345173936882; Thu, 16 Aug 2012 20:25:36 -0700 (PDT) Received: by 10.49.16.132 with HTTP; Thu, 16 Aug 2012 20:25:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Aug 2012 06:25:36 +0300 Message-ID: From: Kimmo Paasiala To: Michael Schnell Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 03:25:38 -0000 On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell wrote: > Hi, > I don't know if this came up already, but not as far as I know. So, I > was thinking it would be nice to add a mechanism to pkgng, which enables > the user to get the ports tree corresponding to the current repository. > > At least I've the problem that I really like the idea of the pkgng > system, but I need a few custom build packages. For instance rawtherapee > is not working for me with OpenMP, so I have to disable it to get it > working, or I made some patches for openbox, which of course then needs > to be compiled. In order to get not in conflict with a more recent > ports tree the exact version of the repository build would be nice. > > At the moment I can think of two ways to implement it. The easiest way > would be to add the ports tree as a packages into the repository. A more > complicated thing is to add a mechanism to portsnap synchronised with > the pkgng system to direct fetch it, or at least a revision number of > the current repo, so you can check it out of the subversion. > > How do you guys feel about this? > > > Greetings > Michael > Why not just include the SVN revision of the ports tree that was used to create the packages in the package metadata? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 03:27:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0AD106564A; Fri, 17 Aug 2012 03:27:49 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41E358FC18; Fri, 17 Aug 2012 03:27:49 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3460038qcs.13 for ; Thu, 16 Aug 2012 20:27:48 -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=5d3TKJd9rYdjH9zzTC2oLniXqaO2xuFBBAcU/3orgpM=; b=OZLBgIi8Kdpc0cdUc8cS/usZygyH7NPiNwFtg4UDlaWooKScAavKBgsiUGxBUPtZK4 ZIQW4gf2OBfZcfZLUnkAFhpZ/0NnVXFqqTQTvSJIZOg1l5mQ0faitIuQ+rvmKZmrZtTN W5Qdtz56u9eyPWuZrIySJXlDmexHnDWYO8f8EdKBmykDpVWXzW3ClPjSbKxzKY/vTJNd ZHf69obVCi9FDZY5WIrKMhYx8kE/ZG1xqhAbzuSduRuHFwhJZsLSIqs+PrASwp72es+M 6+bG77Sm0eDz2c/ezZYFFQLrLehpuyN/lbIKruAGuvskf3fis2gOMjnmj38wPyruwUAs tbjw== MIME-Version: 1.0 Received: by 10.229.106.130 with SMTP id x2mr2527616qco.121.1345174061142; Thu, 16 Aug 2012 20:27:41 -0700 (PDT) Received: by 10.49.16.132 with HTTP; Thu, 16 Aug 2012 20:27:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Aug 2012 06:27:41 +0300 Message-ID: From: Kimmo Paasiala To: Michael Schnell Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 03:27:49 -0000 On Fri, Aug 17, 2012 at 6:25 AM, Kimmo Paasiala wrote: > On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell wrote: >> Hi, >> I don't know if this came up already, but not as far as I know. So, I >> was thinking it would be nice to add a mechanism to pkgng, which enables >> the user to get the ports tree corresponding to the current repository. >> >> At least I've the problem that I really like the idea of the pkgng >> system, but I need a few custom build packages. For instance rawtherapee >> is not working for me with OpenMP, so I have to disable it to get it >> working, or I made some patches for openbox, which of course then needs >> to be compiled. In order to get not in conflict with a more recent >> ports tree the exact version of the repository build would be nice. >> >> At the moment I can think of two ways to implement it. The easiest way >> would be to add the ports tree as a packages into the repository. A more >> complicated thing is to add a mechanism to portsnap synchronised with >> the pkgng system to direct fetch it, or at least a revision number of >> the current repo, so you can check it out of the subversion. >> >> How do you guys feel about this? >> >> >> Greetings >> Michael >> > > Why not just include the SVN revision of the ports tree that was used > to create the packages in the package metadata? > > -Kimmo And of course in the repository metadata as you proposed, sorry not enough coffee yet :P -Kimmo From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 03:33:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58683106564A for ; Fri, 17 Aug 2012 03:33:55 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C24078FC14 for ; Fri, 17 Aug 2012 03:33:54 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so2252689lbb.13 for ; Thu, 16 Aug 2012 20:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TrEgfXyX+KDGmBVqPt1vXCy4IOf88FSwtlVnIHp7NqM=; b=oejej+ZG3ocOsdkmLNnVpsd1lb3z41oAqKBxxdqRnc4foRUu9h9BXlH8WJp2Arx2pg LKUgLoV4ASKYIWXxTe8X0rMWHwni5B3j3ELAJ7vRo067K1wFb3De4/hgtmUpbeSMAwp6 ncAW0LaI/ua7X1S2qPcTfIyn+fhki7BVQp4DUIvSHCCs2MOxD+ylaxo3D1XoJzau7EsH bTJuCQHXtB2SNBKFsM9XV7NJdTnTuHB1A3gp1k43Sik3Z4e8p5EFMXZEUxOxyiJDsmbB 513MZcJhQjdXD9FpGi+4hPzz2PU2bB+JV74y03CE0SfmYaOQq9OR66n7e5kUjMImshpD n6Hw== MIME-Version: 1.0 Received: by 10.152.131.42 with SMTP id oj10mr3281406lab.49.1345174433211; Thu, 16 Aug 2012 20:33:53 -0700 (PDT) Received: by 10.112.129.168 with HTTP; Thu, 16 Aug 2012 20:33:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Aug 2012 20:33:53 -0700 Message-ID: From: Kevin Oberman To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Geom label lost after expanding partition X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 03:33:55 -0000 On Thu, Aug 16, 2012 at 3:11 PM, Kevin Oberman wrote: > On Thu, Aug 16, 2012 at 10:53 AM, Olivier Cochard-Labb=C3=A9 > wrote: >> On Thu, Aug 16, 2012 at 6:30 PM, Kevin Oberman wrote= : >>> I have a GPT formatted disk where I recently expanded the size of a >>> partition. I used "gpart resize -i 6 ada1" first to expand the >>> partition to use the remaining free space and then growfs to modify >>> the FFS file system to use the full partition. This was all done in >>> single-user mode, of course, but when I enter "exit" to bring the >>> system up, it failed to mount /usr. This was because /dev/ufs/usr did >>> not exist! >> >> I've met the same problem, check this PR for a dirty workaround: > > Yep. It is certainly a dirty fix, but it should work. Looks like > glabel is doing the right thing, though a message would have been > nice. > > Rebuilding now. Thanks so much! As I expected, it works fine. I've got my /dev/ufs/usr back! Thanks! --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 08:44:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15CCC106564A for ; Fri, 17 Aug 2012 08:44:25 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D339B8FC0A for ; Fri, 17 Aug 2012 08:44:24 +0000 (UTC) Received: by obbun3 with SMTP id un3so6678630obb.13 for ; Fri, 17 Aug 2012 01:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=h3cXxyCIeuDmFIJWifgrY9iSkHUrPCk5a9m+7W90XUA=; b=E3J5nFsFeCec+/7UVtoMS1d9nhILX4qwMQGuA4RklPd67HDDPzI4deKr+6txnCIuWe dDcyeWWDkdr4GOh5xmuqMYOJGATg0fmu9HAQxpLKVNs4Th4MWC9aQ7zXSCNHWhHHcRYt ebvBzZUL4RxFISjAo7pQuYwUw6qLB/0Lwi6zXC1lgemlaYixQtyuWjKIKqcOjSd14iZb 1HWbOSRyixy1++71aRM748BcKAytITnI+0zFqxMFNu3eozYTHMoqzA+4W94Ng6CPWaay uhMVtXU1Hd6WrBIiJlXq1zqs71obZ0i/Dd9UiGG99kDgpCmRirkOTTiP6in192Tewgmh s/PQ== Received: by 10.50.186.196 with SMTP id fm4mr1069918igc.1.1345193064064; Fri, 17 Aug 2012 01:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.145.101 with HTTP; Fri, 17 Aug 2012 01:44:03 -0700 (PDT) From: Gabor Radnai Date: Fri, 17 Aug 2012 10:44:03 +0200 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: GEOM_RAID in GENERIC 9.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 08:44:25 -0000 Sorry the content of original mail I replied to was missed. For clarity here it is: >On 30.07.2012 11:04, Eugene M. Zheganin wrote: >> >> I am aware about how this thing works and what it does. However, every >> time I upgrade new server I got hit by it again and again, simply >> forgetting to remove it from the kernel's config. >> >> I'm afraid this thing will hit lots of FreeBSD installations after the >> release; it may be easily removed but still it will poison the life of >> many engineers and I really think it's a bomb, and should be removed >> from GENERIC. >> >Okay, I feel like I need to clarify this, as some decent guys pointed me >out that I'm very unclear and even rude (sorry for that, that's >unintentional). > >GEOM_RAID was inserted instead of ataraid, but ataraid wasn't messing >with zpooled disks: with GEOM_RAID the kernel takes both (in case of >mirrored pool) providers, and mountroot just fails, as it sees no zfs pool. > >Plus, it's even more. This time I have "disabled" the raid in it's >"BIOS" before installing FreeBSD. After mountroot failed, I booted 9.0-R >from usb flash, trying to avoid any surgery with kernel files, like >manual install from another machine. I was curious if I will be able to >resolve this issue using base utilities. So, I loaded geom_raid via >'graid load', kernel said like 'Doh... I have ada0/ada1 spare disks', >then I tried to remove the softraid label remains with 'graid remove' - >and it failed, because there's no array at all, only "spares". So, the >'graid status' is empty, 'graid list' is empty' and it's obvious that >some surgery is needed. > >And I'm not disappointed that it's happened to me, no, because I know >how to resolve this. >But the thing that I'm really afraid of is that this default option will >hit the less experienced engineers. > >Eugene. My reply again then: Unfortunately I am a less experienced user so no clue how to disable GEOM_RAID but i am hit by this issue. My zfs setup is totally messed up. Would appreciate if you could share the trick. Additionally: building a new kernel solves the issue naturally but is there anything more convenient solution? What is your trick? Thanks in advance, Gabor (and sorry for messing up the mail thread) From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 09:37:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D6E106567B for ; Fri, 17 Aug 2012 09:37:31 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7C59A8FC0A for ; Fri, 17 Aug 2012 09:37:31 +0000 (UTC) Received: from From: Ferdinand Goldmann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 11:29:04 +0200 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: libmilter broken in FreeBSD8 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 09:37:31 -0000 Hello! I've been using a mail setup consisting of sendmail, milter-ahead, = milter-greylist and MIMEDefang running on FreeBSD for years. Recently I installed a new server running FreeBSD 8.3-RELEASE-p3. To my = bewilderment, I am now running into problems with milter-ahead and milter-greylist, as = they do not see the macros that sendmail should hand them via the milter = interface anymore. (Like client_resolve, rcpt_host, and so on ...). To sort things out, I've setup both a FreeBSD 7 and a FreeBSD 8 test = installation. I am using the _exact_ _same_ _configuration_ in both test installations = (basically the same I am using on my FreeBSD 7 production servers). To my even bigger bewilderment, the milters work as expected on FreeBSD = 7, while they fail on FreeBSD 8. Debugging information suggests that the milters are handed empty = variables on FreeBSD 8: rcpt_host=3D'' rcpt_mailer=3D'' Has anyone experienced similiar problems? I find it hard to believe that = this seems to be suddenly broken ...? Cheers, Ferdinand --=20 >> Ferdinand Goldmann >> Johannes Kepler University Linz - Server Systems/Information = Management >> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024683925 Fax: = 00437024689397 >> A lack of planning on your part doesn't constitute an emergency on my = part. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 09:42:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93098106566B for ; Fri, 17 Aug 2012 09:42:40 +0000 (UTC) (envelope-from bsd-unix@embarqmail.com) Received: from mailrelay.embarq.synacor.com (mailrelay.embarq.synacor.com [208.47.184.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA178FC12 for ; Fri, 17 Aug 2012 09:42:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=embarqmail.com; s=s012408; c=relaxed/simple; q=dns/txt; i=@embarqmail.com; t=1345195353; h=From:Subject:Date:To:Mime-Version:Content-Type; bh=v0MNWvWRkWVgt07rizZLyMdvqZY=; b=IHAavL2/9+3BpyvpoL0narwc8KVP1HML4L/wqe944ExcPmhTuG9raLQXhnVq981e RLDvaZVUu0HEGU48CgDgQvJMTPY9LiLxNCn0+JaEuCGWte/MeTwS4O8oX5ryu72M; X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=E4JPVNhl c=1 sm=0 a=Ox2yDYyBu3Pdez2sjuIefw==:17 a=fV4xQn8aG1cA:10 a=1poGYrevpj8A:10 a=kj9zAlcOel0A:10 a=f_rBqEVidLgA:10 a=1oqGTYSLAAAA:8 a=pGLkceISAAAA:8 a=fA_PuPstAAAA:8 a=7Dw7ozE-t28SgoN0LGsA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=2Ar7-VhXjRkA:10 a=Ox2yDYyBu3Pdez2sjuIefw==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.embarq.synacor.com smtp.user=rpratt1950@embarqmail.com; auth=pass (LOGIN) Received: from [74.4.87.190] ([74.4.87.190:50070] helo=tv.weeeble.com) by mailrelay.embarq.synacor.com (envelope-from ) (ecelerity 2.2.3.47 r(39797/39798)) with ESMTPA id A4/28-17989-85D0E205; Fri, 17 Aug 2012 05:22:33 -0400 Date: Fri, 17 Aug 2012 05:22:31 -0400 From: Randy Pratt To: Kimmo Paasiala Message-Id: <20120817052231.e8d319c9.bsd-unix@embarqmail.com> In-Reply-To: References: X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd6.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org, Michael Schnell Subject: Re: Get ports tree of the current pkgng repository X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 09:42:40 -0000 On Fri, 17 Aug 2012 06:25:36 +0300 Kimmo Paasiala wrote: > On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell wrote: > > Hi, > > I don't know if this came up already, but not as far as I know. So, I > > was thinking it would be nice to add a mechanism to pkgng, which enables > > the user to get the ports tree corresponding to the current repository. > > > > At least I've the problem that I really like the idea of the pkgng > > system, but I need a few custom build packages. For instance rawtherapee > > is not working for me with OpenMP, so I have to disable it to get it > > working, or I made some patches for openbox, which of course then needs > > to be compiled. In order to get not in conflict with a more recent > > ports tree the exact version of the repository build would be nice. > > > > At the moment I can think of two ways to implement it. The easiest way > > would be to add the ports tree as a packages into the repository. A more > > complicated thing is to add a mechanism to portsnap synchronised with > > the pkgng system to direct fetch it, or at least a revision number of > > the current repo, so you can check it out of the subversion. > > > > How do you guys feel about this? > > > > > > Greetings > > Michael > > > > Why not just include the SVN revision of the ports tree that was used > to create the packages in the package metadata? I asked this same question about syncronizing the ports tree with CVS a long time ago. At the time it seemed that manual tweaking was done to get the packages built so there was no actual tree that matched the package repository. I hope this is no longer the case since mixing ports and packages is likely to cause some mismatch eventually if there is no syncronization. I quit using packages because of this over ten years ago. I'd like to see a way to easily be able to mix building ports and using packages without problems. Randy From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 12:48:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EEB71065670 for ; Fri, 17 Aug 2012 12:48:01 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id DF1168FC17 for ; Fri, 17 Aug 2012 12:47:59 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7e0]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q7HClvpM013120 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2012 18:47:57 +0600 (YEKT) (envelope-from eugene@zhegan.in) Message-ID: <502E3D7D.8040105@zhegan.in> Date: Fri, 17 Aug 2012 18:47:57 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Fri, 17 Aug 2012 18:47:57 +0600 (YEKT) X-Spam-Status: No hits=1.3 bayes=0.5 testhits RDNS_NONE=1.274 autolearn=no version=3.3.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: GEOM_RAID in GENERIC 9.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 12:48:01 -0000 Hi. On 17.08.2012 14:44, Gabor Radnai wrote: > Sorry the content of original mail I replied to was missed. For > clarity here it is: > > [...] > My reply again then: > > Unfortunately I am a less experienced user so no clue how to disable > GEOM_RAID but i am hit by this issue. My zfs setup is totally messed up. > Would appreciate if you could share the trick. > > Additionally: building a new kernel solves the issue naturally but is there > anything more convenient solution? What is your trick? > > Your choice could be: - boot old kernel (even 8.x), compile a new one without GEOM_RAID and install/boot it - take the LiveCD, boot it, copy a kernel from the network without a GEOM_RAID instead your kernel - use usb stick with an installed FreeBSD (it must be using GEOM_RAID-free kernel) in order to do the same thing etc I did the thing with usb stick. There's also a way to clear the GEOM_RAID metadata from your disks, but I didn't manage how to do this (asked a couple of questions here though) so I won't be giving any advice about it. Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 12:51:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BD64106564A for ; Fri, 17 Aug 2012 12:51:49 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id A76028FC08 for ; Fri, 17 Aug 2012 12:51:48 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7e0]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q7HCpk15013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2012 18:51:46 +0600 (YEKT) (envelope-from eugene@zhegan.in) Message-ID: <502E3E62.309@zhegan.in> Date: Fri, 17 Aug 2012 18:51:46 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Fri, 17 Aug 2012 18:51:46 +0600 (YEKT) X-Spam-Status: No hits=3.7 bayes=0.5 testhits RDNS_NONE=1.274, TO_NO_BRKTS_DIRECT=2.455 autolearn=no version=3.3.2 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: NMI button X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 12:51:49 -0000 Hi. Guys, I have a IBM system x 3560 server, it hangs, I was told to use the NMI button when it hangs, I found it and pressed, nothing happened. I reset the server, and pressed a NMI button after entering a multiuser. Nothing happened. FreeBSD 9.1-PRERELEASE Now questions: - what should happen upon a NMI keypress ? I thought FreeBSD should panic and enter ddb (default sysctl settings). Am I wrong ? This kernel has kdb/ddb. - does someone have IBM system x servers ? what happens when you press NMI (IBM said it should reset, so be careful if you'll decide to experiment). Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 17 16:09:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FDC41065672 for ; Fri, 17 Aug 2012 16:09:33 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0657C8FC16 for ; Fri, 17 Aug 2012 16:09:32 +0000 (UTC) Received: from Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ferdinand Goldmann In-Reply-To: Date: Fri, 17 Aug 2012 18:09:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C3E9DB3-229F-4D95-A9C2-C85AE065D824@jku.at> References: To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1084) Subject: Re: libmilter broken in FreeBSD8 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Aug 2012 16:09:33 -0000 Following up on my own posting here... I solved the mystery. A bug in MIMDEdefang is to blame, see here: = http://www.mail-archive.com/mimedefang@lists.roaringpenguin.com/msg14658.h= tml By adding the macros to the mimedefang invocation via the -a command = line switch I was able to solve the problem. So anyone of you upgrading to a newer version of MIMEdefang, be careful. = :-) Cheers, Ferdinand On 17.08.2012, at 11:29, Ferdinand Goldmann wrote: > Hello! >=20 > I've been using a mail setup consisting of sendmail, milter-ahead, = milter-greylist > and MIMEDefang running on FreeBSD for years. >=20 > Recently I installed a new server running FreeBSD 8.3-RELEASE-p3. To = my bewilderment, > I am now running into problems with milter-ahead and milter-greylist, = as they do > not see the macros that sendmail should hand them via the milter = interface anymore. > (Like client_resolve, rcpt_host, and so on ...). >=20 > To sort things out, I've setup both a FreeBSD 7 and a FreeBSD 8 test = installation. > I am using the _exact_ _same_ _configuration_ in both test = installations (basically > the same I am using on my FreeBSD 7 production servers). > To my even bigger bewilderment, the milters work as expected on = FreeBSD 7, while they > fail on FreeBSD 8. >=20 > Debugging information suggests that the milters are handed empty = variables on FreeBSD 8: > rcpt_host=3D'' rcpt_mailer=3D'' >=20 > Has anyone experienced similiar problems? I find it hard to believe = that this seems > to be suddenly broken ...? >=20 > Cheers, > Ferdinand > --=20 >>> Ferdinand Goldmann >>> Johannes Kepler University Linz - Server Systems/Information = Management >>> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024683925 Fax: = 00437024689397 >>> A lack of planning on your part doesn't constitute an emergency on = my part. >=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" >=20 --=20 >> Ferdinand Goldmann >> Johannes Kepler University Linz - Server Systems/Information = Management >> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024683925 Fax: = 00437024689397 >> A lack of planning on your part doesn't constitute an emergency on my = part.